衡量标准是需求能否准确落地。前面四个域产出的方案，最终都要经过这一层才能变成用户能用的东西。 AI 产品在这一层格外容易出问题，因为模型行为不确定，很多边界在写 PRD 时根本没法拍死。
AI 功能的需求里总有一部分「现在定不了」的东西，比如敏感词检测该严到什么程度、 多久无新评论才触发一次生成。我的做法是不假装它们已经明确，而是在 PRD 里单列需求确认项， 写清待定的是什么、谁来定、什么时候定。
这比写一个含糊的默认值更省事。含糊的默认值会被研发按字面实现，上线后才发现不对； 而列成待定项，它就必须在评审时被讨论掉。这显著减少了因默认理解不同造成的返工。
AI 链路的规格比普通功能难写，因为要交代的不只是接口和字段，还有 prompt 全文、上下文怎么拼、 模型失败时怎么降级。我的标准是后端拿到文档能 1:1 复刻，不用再来问一遍。
| 层面 | 要交代什么 |
|---|---|
| Prompt | 逐环节的完整文本，不是描述而是可直接用的原文 |
| 上下文拼接 | 哪些字段注入、注入顺序、每轮保留多少轮历史 |
| 失败处理 | 重试次数、并发限制、解析失败的兜底策略、超时后的降级路径 |
| 验收标准 | 什么指标达到什么数值算这个需求做完了 |
同时参与技术评审，在会上为策略做辩护。记忆系统的方案就是这样过的： 我负责策略层的设计与取舍，研发负责工程实现，双方在评审里对齐字段增减与链路改动。
埋点是我定义并跟到底的环节，不是丢给研发就算完。实际要做的包括定义埋点需求、 分优先级测试上报是否正确、核对公共参数、以及在数据不对时定位是埋点问题还是链路问题。
上线阶段的日常还有几项：
需要什么工具就自己写，不排队等研发。这几个都是先解决自己的问题，后来给团队用起来的。
| 工具 | 解决什么 |
|---|---|
| Prompt 实验台 | 支持多模型、多版本并排与按字段开关的消融实验。团队原本没有这类平台，改动只能靠肉眼比对 |
| 生图调试网页 | 部署后可直接调画风 prompt 并批量对比出图，不必每次找研发或手动跑脚本 |
| 批量生产与校验脚本 | 串起四段式内容生产链路，并在跑批后自动统计注入字段字符数、标出超预算的角色 |
技术栈都是原生 JS 加 Node 或 Python，够用就行。工具不算产出，它让评测和批量生产跑起来才算。