3
构建期
Build在输出本身就不确定的前提下，怎么推进开发？
与传统项目的关键差异
构建期最反直觉的一点是——评测不能等开发完了再做。传统项目里开发先于测试是常态，因为代码逻辑是确定的，错了能定位修复。AI 项目里"代码"本身（提示词或模型权重）在持续调整，每次调整都可能在已通过的场景上回归出错。所以评测必须从开发第一天就并行运行，且要有自动化回归。
这一阶段的另一个关键决策是技术路线：Prompt Engineering、RAG、微调、Agent 编排，每条路径的成本结构、维护负担、迭代速度都不一样。早期选错，中后期改回来代价巨大。
相关内容与 yymuse Agent 落地地图的 B 线（技术框架视角）有较多复用，可交叉参考。
核心交付物
- 技术路线决策记录（Prompt / RAG / Fine-tune / Agent）
- 系统架构文档（含 HITL 节点与 Observability 设计）
- 提示词版本管理规范
- 回归评测流水线
常见坑
- 开发完了才开始写评测用例，无法判断回归
- 技术路线选型仅凭技术偏好，未做成本结构分析
- 缺少 Observability，线上问题无法溯源
- 提示词版本散落在个人电脑，无法回滚
阶段通过条件
构建期通过条件
满足以下所有条件方可进入上线期：
- 技术路线已锁定：Prompt / RAG / Fine-tune / Agent 路径已选定，决策记录含成本结构对比
- 回归评测流水线运行正常：每次提示词或模型变更自动触发评测，评测集通过率 ≥ 定义期设定的准入线
- 系统架构文档完成：含 HITL（人机协作）节点设计、Observability 埋点方案、故障降级路径
- 提示词版本管理就绪：所有提示词纳入版本控制，每次变更关联评测结果
- 开发环境评测基线确立：当前版本在评测集上的得分作为上线对比基线
- 技术路线已锁定，决策记录含成本对比
- 回归评测流水线运行，通过率 ≥ 准入线
- 系统架构文档完成（含 HITL + Observability）
- 提示词版本管理就绪，变更关联评测结果
- 开发环境评测基线确立