清单的用法
评审最容易失败的方式，是把它开成演示会：方案讲完，大家提几个零散问题，最后以“总体可以，注意优化”结束。
清单的作用是把评审变成逐项确认。十二组、六十问，不必每次都问完；按方案的风险挑三到五组深问，其余快速过。
每组给四样东西：问题、通过判据、常见驳回理由、整改建议。通过判据尽量写成“能看到什么”，而不是“感觉没问题”。
一、能力与契约
问题：
- 这项能力对外承诺的行为是什么？用一句话能说清吗？
- 六个面（输入、输出、质量、延迟、成本、失败）分别写在哪？
- 质量由谁验收？样本量多大？多久复核一次？
- 不可用时，用户看到的是缺失、变弱还是阻塞？
- 业务方依赖的是契约，还是某个具体模型？
通过判据：能拿出一页契约，六个面都有具体取值；质量指标有负责人与复核周期。
常见驳回：“效果还不错”“先上线再看看”。这类回答说明质量面还没定义。
整改建议：先补质量验收方案，再排开发。没有验收标准的能力，等于没有完成定义。
二、网关职责
问题：
- 哪些逻辑在网关，哪些在业务服务？边界写在哪份文档里？
- 密钥存在哪？会不会进入客户端、日志或提示？
- 配额按什么维度计？租户、用户还是能力？
- 网关是否保存会话状态？扩容时会不会丢？
- 供应商私有错误码是在网关转换，还是透传给业务？
通过判据：网关职责表存在；密钥不出服务端；配额维度与计费口径一致。
常见驳回：“先都放在网关，以后再拆。”拆的成本通常比一开始划清更高。
整改建议：先画一张职责表，把业务规则从网关移出去，再讨论平台化。
三、路由与模型组合
问题：
- 这次请求为什么落在这个模型上？能给出规则吗？
- 路由考虑哪些维度？任务、租户、区域、成本、健康各占什么权重？
- 主模型不可用时切到谁？切换后质量下降多少？
- 路由决策是否记录？出问题能否复盘？
- 模型档案（价格、延迟、上下文）多久更新一次？
通过判据：给定一次真实请求，能解释选择理由；切换路径有质量与成本对照。
常见驳回：“多接几家总没错。”接了不用、或用了不测，等于多维护几套密钥。
整改建议：先定义两到三个模型的分工，再做健康切换；不要一开始就铺满所有供应商。
四、流式
问题：
- 首帧、增量、计量、结束、错误五类事件是否都有定义？
- 首帧之后失败怎么处理？会不会自动重试导致重复文本？
- 用户取消后，上游是否停止生成？是否停止计费？
- 流式协议是自定义事件，还是透传供应商私有格式？
- 弱网与断线重连时，客户端看到什么？
通过判据：五类事件有字段表；取消链路端到端打通；客户端不依赖供应商事件名。
常见驳回：“流式就是边生成边显示。”这只描述了正常路径。
整改建议：先补错误与取消路径，再做首屏优化。
五、提示与上下文
问题：
- 提示是代码字符串，还是可版本化的产物？
- 提示有所有者吗？改坏了怎么回滚？
- 变量如何注入？用户内容会不会被当成系统指令？
- 上下文超出预算时，先丢什么、后丢什么？
- 提示版本与模型版本的组合是否记录？
通过判据：提示有版本号与变更记录；注入方式区分指令与数据；裁剪规则明确。
常见驳回：“提示就是一段文字，改起来很快。”改得快，坏得也快。
整改建议：把提示纳入发布流程，至少做到可回滚与可灰度。
六、结构化输出
问题：
- 输出结构有 schema 吗？在哪校验？
- 校验失败分几类？每类怎么处理？
- 修复最多几次？修复预算是否计入总预算？
- 修复失败后给用户什么？
- 枚举越界与字段缺失是否区别对待？
通过判据：失败分类表存在；修复次数有上限；兜底路径明确。
常见驳回：“让模型返回 JSON 就行了。”模型返回的经常是“像 JSON 的文本”。
整改建议：先加校验与失败分类，再谈自动修复。
七、预算与成本
问题：
- 延迟预算怎么拆？首字与完整分别是多少？
- token 预算怎么算？输入与输出分别设上限吗？
- 单次成本上限与租户月度上限分别是多少？
- 重试是否消耗同一份预算？
- 成本异常时，多久能发现？靠账单还是靠实时计量？
通过判据：三类预算都有数值；重试与预算关系明确；成本可按请求归因。
常见驳回：“月底看账单就知道了。”账单只能告诉你超了，不能告诉你为什么。
整改建议：先在网关做实时计量，再做预算告警。
八、缓存
问题：
- 缓存的键包含哪些字段？租户与权限在键里吗？
- 哪些变更会让缓存失效？提示改版算不算？
- 语义缓存的误命中如何评估？
- 缓存命中时，响应里的降级字段怎么标？
- 个性化结果有没有被做成全局缓存？
通过判据：键字段表存在；失效规则可执行；命中结果标注来源。
常见驳回：“加个 Redis 就行。”键设计错了，缓存会变成串数据。
整改建议：先定义键与失效，再选存储。
九、降级
问题：
- 每个能力的降级等级是什么？可缺、可弱还是必须阻塞？
- 触发条件是什么？错误率、延迟还是人工开关？
- 降级后用户看到什么文案？
- 恢复条件是什么？自动恢复还是人工确认？
- 降级开关有没有清理计划？
通过判据：能力与等级对照表存在；触发与恢复都可观察；开关有退出条件。
常见驳回：“降级就是返回空。”空结果会让用户以为功能坏了。
整改建议：先给每个能力定等级与文案，再实现开关。
十、安全边界
问题：
- 密钥如何隔离？不同租户是否共用？
- 哪些数据可以出域？字段白名单在哪？
- 提示注入的防护在哪一层？用户内容如何处理？
- 工具调用的权限由谁校验？模型能否直接执行？
- 输出拦截误杀后，用户怎么申诉？
通过判据：数据出域有白名单；工具调用执行方校验；拦截有审计与申诉路径。
常见驳回：“模型不会那么聪明。”攻击者会。
整改建议：先明确信任边界，再补检测与拦截。
十一、观测与计量
问题：
- 一次请求记录哪些字段？请求 ID、能力、租户、模型、耗时、用量、结果齐吗？
- 失败请求是否也记录？采样会不会把错误采掉？
- 耗时能否拆到排队、首字、生成、后处理？
- 计量口径与账单口径是否一致？
- 出故障时，能否在十分钟内定位到能力与模型？
通过判据：字段表存在；错误全量记录；耗时分解可见。
常见驳回：“日志里有。”日志里有，不等于能查。
整改建议：先定义最小观测契约，再谈大盘与告警。
十二、演进与治理
问题：
- 换模型需要改业务代码吗？
- 新能力接入要经过哪些步骤？有没有模板？
- 提示、模型、契约的变更如何灰度与回滚？
- 临时方案有没有退出条件与负责人？
- 这一卷的哪些结论会在下一卷被推翻？依据是什么？
通过判据：换模型不改业务；接入有模板；变更可回滚；临时方案有清理计划。
常见驳回：“以后再说。”以后通常不会来。
整改建议：把退出条件写进 ADR，指定负责人与复查日期。
三十分钟评审流程
| 时间 | 动作 | 产出 |
|---|---|---|
| 0–5 分钟 | 方案方讲能力、用户与失败姿态 | 一句话能力定义 |
| 5–15 分钟 | 按风险挑三组深问 | 三到五个待确认项 |
| 15–25 分钟 | 逐项给结论：通过、有条件通过、驳回 | 结论与条件 |
| 25–30 分钟 | 指定负责人、复查日期与证据 | 行动项 |
评审不是打分。结论只有三种：通过、有条件通过、驳回。有条件通过必须写清条件与验证方式，否则等于通过。
结论模板
方案: chat.reply v2 接入评审
结论: 有条件通过
条件: 1) 补齐质量抽检方案（负责人：消息团队，日期：11 月 8 日）
2) 补首帧后失败的用户文案（负责人：前端，日期：11 月 6 日）
3) 压测单租户月度成本上限（负责人：平台，日期：11 月 12 日）
风险: 切换模型后质量下降幅度未知，暂不做自动切换
复查: 2026-11-15，带抽检结果与成本报表
模板的价值在于留下证据。三个月后回看，能知道当时担心什么、验证了什么、哪些担心成真了。
评审中最常见的三个误区
误区一：把清单当打分表。 六十问不必全问，也不该按通过率排名。清单是提问工具，不是 KPI。
误区二：只评审新方案。 存量能力更需要评审：它们没有契约、没有预算、没有降级，但因为“一直在跑”而被跳过。
误区三：评审完没有复查。 有条件通过的条件如果没人跟，等于无条件通过。复查日期与证据要求，是清单里最重要的两行。
小结
这份清单覆盖的是卷一建立的判断：能力要有契约，网关要有边界，路由要可解释，流式要能取消，提示要能回滚，输出要能校验，预算要能归因，缓存要能失效，降级要能解释，安全要有边界，观测要能排障，演进要有出口。
六十问不必一次问完。挑最贵的、最不可逆的、最没人负责的那几组先问。评审的目的不是证明方案好，而是找出它会在哪里坏。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。