← 交付方法总览
质量体系可泛化原则
验收 Rubric
交付质量
给开放式回答定义可评分的维度，让「这个答案好不好」变成多个可以分别判定的问题。单一好坏判断无法指导修复，分维度评分才能指出该改哪一层。
什么时候需要它
- 评审时对同一个回答有不同看法，且说不清分歧在哪
- 修复方向不明确，因为只知道答案不好、不知道差在哪
核心内容
它决定什么
公开的是判断与判据。客户口径、私有阈值和内部示例不在其中。
拆成可分别判定的维度
是否切题、是否有据、是否完整、是否正确拒答、格式是否合规、语气是否合适——分开评分，才能把一次不满意定位到具体缺陷。
有据性单独成维
回答听起来对但没有来源支撑，是最危险的一类失败，因为它最不容易被察觉。有据性必须独立评分，不能并进「正确性」里。
正确拒答也要给分
在数据不足或超出边界时明确说不知道，是正确行为而不是失败。如果拒答一律扣分，模型会被推向编造。
每个维度要有可操作的判定说明
「切题」需要写清楚什么算切题、什么算擦边，否则两个评分者会给出系统性不同的分数。
维度要与修复动作对应
有据性低对应检索层，格式不合规对应结构层约束，语气问题对应提示层。评分维度如果映射不到任何修复动作，说明它设计得不对。
怎么判断它真的到位
- 两名评分者对同一批样本的打分差异在可接受范围内
- 每个维度都能对应到至少一个具体的修复方向
- 拒答场景有独立用例，且拒答被判为正确
常见误区
- 只用一个总体好坏分，修复时无从下手
- 把有据性混进正确性，编造被当成小瑕疵
- 维度定义含糊，不同评分者系统性打出不同的分
这套方法怎么落到你的项目
这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时，从 AI Agent 生产就绪审查与路线图 入手，或先用 生产上线前深检 定位薄弱环节。