大海
132 lines
4.4 KiB
Markdown
132 lines
4.4 KiB
Markdown
# 失败点和人工修复点
|
||
|
||
> 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` 中增加分支：当用户输入包含详细功能描述时，走"需求解析"路径而非"域匹配"路径。
|
||
|
||
```javascript
|
||
// 伪代码
|
||
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 个真实案例验证。
|