大海
4.4 KiB
失败点和人工修复点
2026-06-05 — Software Generator MVP v1 真实需求验证
测试方法
用 3 个真实软件需求（BookShelf 读书管理、TeamFlow 团队看板、MealPrep 备餐管理）跑完整链路，暴露了 benchmark 未能发现的核心缺陷。
🔴 P0 — 致命缺陷
1. project-intake-agent 域匹配覆盖用户输入
现象: 所有真实需求都被映射到预定义模板（note/ecommerce），用户的具体需求被完全忽略。
| 输入需求 | 生成结果 | 期望 |
|---|---|---|
| BookShelf 读书管理 | NoteApp (note) | BookShelf (book) |
| TeamFlow 团队看板 | NoteApp (note) | TeamFlow (project) |
| MealPrep 备餐管理 | ShopApp (ecommerce) | MealPrep (health) |
根因: matchDomain() 函数优先级高于实际输入解析。当输入文本命中某个域的关键词（如"管理"→ note/ecommerce），就直接使用该域的模板，不再解析用户的具体需求。
影响: 10 个 benchmark 领域能通过，是因为它们的输入文本恰好匹配了预定义域。真实需求无法通过。
修复方向:
- 用户输入应优先于域匹配
- 域匹配应作为 fallback，而非 override
- 需要增加"自定义域"路径，当匹配度低时走纯需求解析
2. Features/Pages/APIs 数量为 0
现象: BookShelf PRD 生成了 0 个 features、0 个 pages、0 个 APIs（后端仍有 routes，但不是从 PRD 来的）。
根因: 当域匹配命中预定义模板时，模板的 features/pages/apis 被使用。但这些模板的字段可能为空或未正确填充。
影响: 前端和后端生成器依赖 PRD 中的 features/pages/apis 来决定生成什么。当这些为空时，生成器使用默认模板（note/ecommerce），导致生成的项目与需求完全不匹配。
3. Benchmark 只验证结构，不验证语义
现象: 10/10 benchmark 全部通过，但真实需求全部失败。
根因: 回归测试验证的是：
- ✅ 有没有 package.json
- ✅ 有没有 routes/ 目录
- ✅ 有没有 auth.ts
- ❌ 不验证生成的内容是否匹配输入需求
影响: benchmark 给出了虚假的安全感。系统能生成"看起来正确"的项目，但内容与需求无关。
🟡 P1 — 高优先级
4. 域匹配阈值过低
现象: "做一个备餐管理系统" 被匹配到 ecommerce，matchConfidence 未设置。
修复: 提高匹配阈值，增加"无匹配"的处理路径。
5. 中文需求解析能力不足
现象: 详细的中文需求描述（包含具体功能点、字段名、业务逻辑）被忽略。
修复: 需要增强 NLU 层，从中文需求中提取实体、功能点、业务规则。
🟢 P2 — 中优先级
6. 3 个 benchmark 领域的 PRD 特性数偏低
现象: project-mgmt/asset/appointment 只生成 3 个特性（其他领域 5-7 个）。
影响: 回归测试阈值已从 4 降到 3，但仍是质量问题。
7. 项目名称不从输入提取
现象: 输入"叫 BookShelf"，生成的项目名是 "NoteApp"。
修复: 增加项目名称提取逻辑，识别"叫 XXX"、"命名为 XXX"等模式。
人工修复点
修复 1: 自定义域路径
在 project-intake-agent.mjs 中增加分支：当用户输入包含详细功能描述时，走"需求解析"路径而非"域匹配"路径。
// 伪代码
if (inputHasDetailedFeatures(input)) {
// 直接解析用户需求，不走域匹配
return parseCustomRequirements(input);
} else {
// 走域匹配模板
return matchDomain(input);
}
修复 2: 域匹配降级
当域匹配置信度低于阈值时，使用通用模板而非强制匹配。
修复 3: 需求关键词提取
从输入中提取：
- 项目名称（"叫 XXX"、"命名为 XXX"）
- 实体（"书籍"、"客户"、"任务"）
- 功能（"添加"、"管理"、"统计"）
- 字段（"书名、作者、ISBN"）
总结
| 类别 | 数量 | 说明 |
|---|---|---|
| P0 致命 | 3 | 真实需求无法生成正确项目 |
| P1 高 | 2 | 域匹配和中文解析 |
| P2 中 | 2 | PRD 质量和命名 |
结论: MVP v1 的管线架构（7 个 Agent 链路）是正确的，但 project-intake-agent 的域匹配逻辑是瓶颈。修复域匹配后，系统应能处理真实需求。
下一步: 修复 P0 缺陷，重新用 3 个真实案例验证。