按承诺的交付类型评分

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

一项任务承诺修复代码并运行回归，另一项只做需求访谈。修复的交付物是文件和运行结果，访谈的交付物是轮次与已澄清需求；不能都只看结尾“我遵循了流程”。

具体做法

在运行前声明交付类型及对应预期，核对真实任务而不只看kind标签。执行任务提供可操作夹具和必要权限，评分读取编辑、命令结果及产物；对话任务评估提问、等待和需求澄清，不虚加代码要求。混合任务分别检查两类证据。处理工具拒绝和缺文件，不能靠叙述补成执行成功。

反例

修复和访谈都按最终总结评分；修复称测试通过就给分，访谈没写文件就失败。

改进写法

修复案例检查真实失败测试、修改、重跑与最终产物；访谈检查实际提问和等待回答及未解需求。若访谈还承诺保存spec，就另检查文件。根据实际交付选择证据，不用dialogue标签豁免文件要求。

为什么这样改

评分对象必须匹配承诺产物。执行轨迹能区分实施与叙述，对话轮次则能检验访谈本身；标签错误会让看似合理的评分测到无关行为。

如何验证

教学“已修好”但没有修改或测试证据不能通过修复预期；合格访谈可无文件。若要求保存spec且未保存，混合任务仍失败。记录kind、规范预期与逐项证据，不能把dry-run计划当运行轨迹。

适用边界

轨迹也可能不完整，需核对原始材料；真实结果仍要独立产物检查。对话与执行常混合，不应滥用类型豁免。冻结来源的工具允许列表和权限方式只是当时实现，不能用于当前任务扩大权限。