做法是先看清能力边界在哪，再决定方向。调研的产出不是资料汇编，而是一个能执行的判断， 并且要能说清为什么不选另一条路。
| 场景 | 判断与理由 |
|---|---|
| 对话质量 | 竞品有自研韩语模型而我方只有通用 API，追赶模型这条路走不通，改为按模型档位做分层策略 |
| 商业化 | 竞品的阶梯好感度太像进度条，用户攻略成功后失去动力，改为光谱与波动的关系动态系统 |
| 出海 | 调研结论落到功能优先级：免费额度与内容尺度是前期抓人的要素，UGC 生态与活人感才是长期竞争力 |
标准是研发拿到文档不用再问一遍就能实现。AI 链路比普通功能难写，要交代的不只是接口和字段。 写规格时固定回答四个问题：
配套的一件事是把定不了的边界前置成待定清单。 含糊的默认值会被按字面实现，上线后才发现不对。
顺序是先定什么算好，再谈优化。这一步最容易被跳过，因为它不产出可见的功能， 跳过之后所有改动都变成凭感觉。
| 关注点 | 具体做法 |
|---|---|
| 指标口径 | 可用率的分母排除网络失败；机械复用率对类型组合做排序归一化。口径错了后面所有结论都是错的 |
| 控变量 | 选差异极大的三个角色测同一套 prompt，防止只在一个样本上调好看 |
| 硬约束脚本化 | 上下文预算这类量化要求不写在 prompt 里靠模型自觉，而是跑批后用脚本校验并标出超标项 |
| 怀疑评测方法 | 数据反常时先查测量方法。召回率被测成 0.23 而实际是 0.83，原因是场景串起来跑造成上下文污染 |
核心是分清哪些问题该我改、哪些是模型的天花板。判断错了会在死路上反复投入。
我用的判据是同一缺陷在两个版本上的出现率是否接近：接近说明改 prompt 无效，属模型固有倾向； 差异大说明 prompt 能控。归因之后分流处置，可控的改 prompt，固有的转工程兜底。 这一次的结果是将输出质量补足到稳定可用。
上线阶段的日常还包括埋点上报验证、问题清单勾兑、封板跟进、版本质量复盘与分渠道数据归因，详见产研交付。
一次性解决的问题不算解决。这个环节要回答别人能不能复用，以及下次遇到同类问题会不会再花一遍时间。
从消融实验里长出的那条规律最能说明这个环节的价值：要模型照着做就给可照抄的结构示例， 要它少做则给原则而非清单。它不只适用于当时那个 prompt，后续所有迭代都在用。