### 最致命的问题：无法应对"考古"需求
3 min read
AI
本文分析了传统需求规范工具（如speckit/openspec）在处理需要历史上下文（“考古”）需求时的致命缺陷，即缺乏对历史经验、业务边界和配置知识的自动检索能力，导致高度依赖人工review和认知负担。文章进而提出AI工程化的解决思路，核心是通过分层管理上下文、自动加载历史经验并持续沉淀知识，使AI能在完整信息下决策，实现知识复利和边际成本递减，而非单纯约束流程。
最致命的问题：无法应对"考古"需求
speckit 和 openspec 都有一个共同盲区：流程从零开始。
speckit 流程：
Constitution 定义原则 → Specify 定义需求 → Plan 设计方案 → ...
但真实需求必须"考古"：
├── 这个商品创建以前有什么坑？
├── 现有玩法能力有哪些？
├── 导航小结页的 Banner 怎么弹？
├── Apollo 配置有什么特殊处理？
└── 雅典娜 20 种商品类型的配置方式各不同
缺失能力：没有"上下文检索"机制，无法自动关联历史经验、已有能力、已知陷阱。
AI 生成 spec 时能看到的：
- ✅ 代码仓库
- ✅ project.md/Constitution
- ✅ 用户意图
AI 看不到（但需要知道）的：
- ❌ 业务边界（涉及哪些服务？）
- ❌ 历史经验（以前怎么做的？有什么坑？）
- ❌ 配置规范（Apollo 特殊要求？）
- ❌ 平台知识（雅典娜 20 种商品配置注意事项）
- ❌ 协作约束（依赖其他团队接口？合规要求？）
结果：依赖人 review 时逐步想起来告诉 AI，45 分钟 + 持续的认知负担。
AI 工程化如何破局？（预告） 面对上述问题，AI 工程化的解决思路是什么？这里先做个预告，详细方案见第五节。
| 企业现实问题 | speckit/openspec 的困境 | AI 工程化的解法 |
|---|---|---|
| 需求动态变化 | 假设一次性规划，变更成本高 | 需求以"进行中"状态管理，支持随时调整，阶段性沉淀 |
| 多线并行博弈 | 线性流程，Delta 冲突报错终止 | Agent 自主决策路由，Skill 独立执行，不强依赖顺序 |
| 考古需求 | 无上下文检索，AI 只能看到代码 | context/ |
| 分层管理历史经验，按阶段自动加载 | ||
| 配置/平台知识 | 需要人 review 时口述 | 沉淀为 context/tech/ |
| ，AI 执行时主动提醒 | ||
| 冲突解决成本 | 人工对比、手工修改、认知负担重 | 不依赖"合并"，而是"覆盖+沉淀"，冲突时 AI 辅助决策 |
| 边际成本恒定 | 每次 45 分钟，无复利 | 首次建立 context，后续复用，边际成本递减 |
核心差异：
speckit/openspec 的思路：
规范化流程 → 约束 AI 行为 → 期望产出质量
↓
问题：流程本身不适配企业现实，约束越多越僵化
AI 工程化的思路：
上下文完整性 → AI 决策质量 → 自动沉淀经验 → 下次更好
↓
解法：不是约束 AI，而是给 AI 完整信息 + 让知识复利
一个具体例子——同样是"商品发放"需求：
speckit 模式（第 3 次做）：
1. Constitution → 写项目原则（已有，跳过）
2. Specify → 写需求规范（45 分钟，人逐步想起遗漏告诉 AI）
3. Plan → 写技术方案（人提醒：Apollo 有坑、钱包要区分）
4. Tasks → 生成任务（人补充：雅典娜配置注意事项）
5. Implement → 执行（遇到问题再排查）
耗时：45 分钟 + 排查时间，知识留在人脑
AI 工程化模式（第 3 次做）：
1. /req-dev "商品发放需求"
2. Agent 识别意图 → 自动加载 context/experience/商品发放历史问题.md
3. Agent 提醒："历史上有钱包选择、Apollo 配置、雅典娜商品类型三个坑点"
4. 人确认："对，继续"
5. Skill 执行 → 自动校验 → 生成代码 → 沉淀新发现
耗时：10 分钟，知识沉淀到 context/
后续章节将详细展开这套方案的设计原理和落地实践