🎉 init: 小龙的工作空间

cases/failure-report.md

@@ -0,0 +1,131 @@
+# 失败点和人工修复点
+
+> 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 个真实案例验证。