把一条有用的判断，
写成可复核的笔记。

我们的客服摘要总是跑偏。我把指令、工单历史、制度片段和输出规则分开画出来后，发现问题不在措辞，而是模型根本没有收到最新的退款例外条款。这张图省掉了一轮无效的 Prompt 优化。

我给版本说明助手准备了 6 条普通案例、2 条混乱输入、1 条空变更记录和 1 条安全敏感案例。第 10 条让发布暂停了，但也明确告诉我该补哪条护栏。10 条有意设计的案例，比 50 条随机样例更有用。

先写拒收条件改变了我们的内容简报：产品描述只要虚构功能、漏掉来源 SKU，或把不确定性藏起来，就直接退回。评审不再争论语气“感觉对不对”，而是检查同一份契约。

希望后续增加一组评分者校准练习：三份看起来相近、却应该得到不同结论的回答。这样当两位评审对“证据是否充分”意见不一致时，会更容易把这一课带回团队使用。

一页任务简报在客户工作坊前暴露了一个分歧：运营想要建议，法务只接受带来源的摘要、不能给建议。把合格输出写清楚后，冲突在成本还很低的时候就被看见了。

适用性矩阵让我排除了“查询固定奖学金截止日期”这种任务，但“比较不同项目的资格条款”似乎仍适合 AI。这里是否应该拆成两步：先确定性检索，再让 AI 做带引用的比较？

对我最有帮助的是把来源资料和对话历史分开。团队以前把两者都叫“上下文”，结果忽略了已批准的品牌事实与用户先前的猜测，其实沿着完全不同的可信路径进入模型。

如果每个风险级别再配一个反例，这张矩阵会更适合产品评审。团队通常都承认可能出错，但会对错误是否可撤销产生分歧；一份填写好的对照案例能把这个取舍讲得更具体。

我把恢复手册用在图片标注流程上，才发现“停止”只能阻止新任务，却不会保存失败批次。补上状态检查点后，这次恢复测试终于像一次真实运行演练，而不是填文档。

我们把人工复核放在面向客户的动作之前，但评审者目前只能看到草拟消息。这个检查点是否还应该同时展示来源证据、不确定性说明，以及批准后会执行的具体动作？