04
逐队详细测试报告
每队含：客观验收（绿标=实测通过）+ 评委优缺点。全部基于本机真实运行，非纸面评估。
🥇 文档瀑布 · BMAD 式analyst → PM(PRD) → architect → dev → QA/tea，文档逐级交接 ｜ 角色提示词取自 BMAD 真实 SKILL.md
✓ 服务启动✓ POST 接口✓ GET stats✓ GET leads
✓ 路径穿越被挡(404)✓ 单测 18/1810 文件 · 455 行
优势
- 真分工真交接：BRIEF(BA)→PRD(PM 含对简报待决项的裁定表)→ARCHITECTURE(架构,引基线PRD)→code(Dev)→QA_REPORT(Verdict:PASS)，每份文档标注上下游，AC 验收编号贯穿文档与代码注释
- 代码工程质量四队最高(满分)：209 行单文件清晰分层；phone 正则校验、intent 白名单归一、save 用 tmp+os.replace 原子写、写操作加 threading.Lock、坏 JSON 全容错
- 测试 18/18 复跑确认：覆盖纯函数 + 存储健壮性(损坏/缺失 JSON) + 真实 HTTP 端到端，DATA_FILE 重定向不污染真库
不足
- 前端仅留资页，无线索列表/统计可视化界面(GET /stats 与 /leads 有 API 无配套展示页)
- index.html 提交按钮用 childNodes[0].nodeValue 改文本节点略脆，且残留一行死代码
- 18 测试偏重业务函数，接口层主要靠 1 个 e2e 用例，HTTP 层 403/404 分支无独立断言
评委定性：BMAD 文档瀑布范式的标杆产物——六份带真实上下游交接的过程文档，驱动出零依赖、清晰分层、实测全通(3 接口 + 18 测试)的高质量成品；唯前端缺数据展示页、接口层测试略薄。
🥈 真团队状态机 · GPT-Pilot 式spec_writer → architect → tech_lead(拆 epic) → developer → reviewer ｜ 角色提示词取自 GPT-Pilot 真实 system.prompt
✓ 服务启动✓ POST 接口✓ GET stats(4键恒存在)✓ GET leads(中文不转义)
✓ 单测 6/6(含 e2e)9 文件 · 362 行
优势
- 代码质量满分：薄 Handler 路由层 + 无副作用纯函数核心(load/save/validate/add/compute 全 path 入参)，纯函数可被临时文件隔离测试，坏 JSON 三路降级，严守零 pip 依赖
- 状态机协同是真的：TASK→SPEC(含数据模型表+唯一事实来源声明)→ARCH→TASKS(tech_lead 拆 E1-E6 epic 带依赖序)→实现→REVIEW(逐项判定)，规格逐字落到代码
- 前端 750px 移动端品质在线：inputmode/maxlength/autocomplete 细节、教育品牌渐变、成功/失败/网络异常三态提示、提交按钮防重复
不足
- 测试用例偏少(6 个)，HTTP 集成仅 1 条 e2e；坏 JSON body 走 400 分支、未知路径 404、并发写入均无断言
- id 自增用 len(leads)+1 而非持久游标，未来支持删除会 id 碰撞；save 整体覆盖写无文件锁，高并发有读改写竞态
- 前端 intent 下拉与后端白名单两处硬编码未共享常量，新增意向需双改易漏
评委定性：GPT-Pilot 状态机的标杆样本——规格→架构→任务→实现→评审全链路过程文档真实可溯，代码分层最干净、容错与校验健壮；唯测试广度与并发写入健壮性留有提升空间。
🥉 扁平委派 · VoltAgent 式orchestrator(冻结接口契约) → ui-designer / backend / frontend / test 专家按需委派 ｜ 角色提示词取自 VoltAgent 真实 .md
✓ 服务启动✓ POST 接口✓ GET stats✓ GET leads
✓ 单测 13/13✓ 防目录穿越9 文件 · 462 行
优势
- 测试设计最专业：双层覆盖——纯函数单元层 + 起真实 ThreadingHTTPServer(随机端口)的 HTTP 集成层，tempfile 临时数据 + setUp 每例清空，13/13 复跑全过
- 契约驱动协同清晰：orchestrator 先写 PLAN.md 冻结接口契约(请求体/校验/响应码/记录结构)，再分派四专家并行；UIDESIGN.md 给出完整 design token 交接给前端
- 代码扎实：纯函数全抽离便于复用，校验严谨，静态资源 normpath+startswith 防穿越，数据文件走环境变量便于隔离
不足
- 契约执行有偏差：PLAN.md 承诺交付 tests/__init__.py 但实际未生成——扁平委派下契约回归校验有疏漏
- UI 实际 max-width 420px，与团队既定 750px 设计宽度标准不一致(口头声称 750 但落地是窄卡片)
- 仓库残留开发产物(_smoke_leads.json / leads.json / __pycache__)未清理；成功 POST 返 200 而非更规范的 201
评委定性：扁平委派交付了可直接运行、四接口实测全通、13/13 测试真过的高质量零依赖产物，契约驱动协同清晰；仅有 __init__.py 漏交付与 UI 宽度未达 750px 等小瑕疵。
单 Agent 全栈（基线 / 对照组）一人包办：UI/前端/后端/测试，不分阶段、不写交接文档
✓ 服务启动✓ POST 接口✓ GET stats✓ GET leads
✓ 单测 5/55 文件 · 166 行
优势
- 基线质量过硬：零依赖直起 ThreadingHTTPServer，四接口实测全通，5 个单测复跑全过；用最少代码(166 行)最快交付
- 工程细节扎实：save 用 tmp+os.replace 原子写、手机号正则、意向白名单、LEADS_FILE 环境变量做测试隔离、单测直调纯函数不起服务
- 前端与立大志品牌契合(深蓝+鎏金)、移动端友好(inputmode/实时过滤手机号)、合规文案不含效果保证承诺
不足
- 协同过程基本缺失(仅 3 分)：无任何过程文档、分阶段交接、角色分工或评审记录——符合对照组定位，但也说明单 Agent 不产出可追溯的协作资产
- 测试仅 5 例且只覆盖纯业务函数，HTTP 层(路由/解析失败/404/静态服务)无任何端到端断言
- leads.json 全量 load+append+rewrite，无文件锁，数据量大时写放大，不具扩展性
评委定性：单 Agent 基线交付质量过硬、最快最省，工程细节到位；但协同过程与可追溯资产基本缺失、测试深度最浅——印证了多 Agent 团队的增量价值正来自这两点。