additive-bias-defense

对于“我们应该添加这个吗？”这个问题，默认答案是否定的。 举证责任在添加方。

加法偏见防御

注（#444）： Frontmatter 声明的是 provides.guidance，而非 provides.contract。这些审视问题由合作技能（pensive:code-refinement、conserve:unbloat、 imbue:scope-guard）自愿嵌入后使用；leyline 中没有验证器或钩子 直接强制执行这些问题。如果未来的贡献者添加了强制机制，请恢复 contract 标签，并在此处链接验证器路径。

不适用场景

• 移除已经合入的臃肿内容（使用 conserve:bloat-detector）
• 评估某个功能是否值得构建（使用 imbue:scope-guard）

问题

大模型天生倾向于添加内容。它们会重复造轮子、增加 不必要的复杂性、臆造问题并修改 测试来为其辩护，还会偏离优先事项。本契约提供 系统性的防御。

审视问题

适用于每项拟议的添加（代码、文件、 抽象、错误处理、配置）：

1. 优先级契合度：这是否偏离了 当前优先事项？
2. 关键性：此时此刻是否必须实现？
3. 简洁性：是否存在更简单或更优雅的 解决方案？
4. 证据：有什么证据能证明确实需要此项 （而非仅凭假设）？
5. 后果：如果不添加此项，会有什么问题？

如果提议者无法用具体证据回答问题 4 和 5， 则添加此项缺乏正当理由。

反模式检测

模式	信号	质疑
重复造轮子	新增的工具函数／辅助函数与现有代码重叠	“X 是否已经能做到？”
臆造问题	修复某个没有复现证据的 Bug	“请在修复前展示失败的测试”
操纵测试	修改测试以符合行为，而非规范	“是规范变了，还是你改了测试？”
复杂性蔓延	为单一用例引入抽象	“这是第 3 次使用，还是第 1 次？”
偏离优先级	工作内容无法追溯到当前任务／规范	“这满足了哪项要求？”
过度打磨	错误处理或灵活性超出需求	“没有它会有什么问题？”

举证责任裁定

应用审视问题并检测反模式后，给出裁定：

裁定	含义	操作
justified	证据支持此项添加	继续
needs_evidence	看似合理，但尚未证实	提供证据或移除
unjustified	没有证据，可能是偏见所致	移除或给出正当理由

集成契约

面向审查的技能必须通过以下方式参照本契约：

1. 对每项添加应用 5 个审视问题
2. 扫描 6 种反模式
3. 给出举证责任裁定
4. 在输出中包含裁定

使用此契约的技能

技能	集成点
attune:war-room	控方顾问角色使用审视问题
sanctum:pr-review	对每个新增文件／函数提出质疑
pensive:code-refinement	重构须通过“第 3 次使用”检验
conserve:unbloat	将发现的问题纳入待移除项
attune:mission-orchestrator	在用户审查前扫描计划章节
imbue:justify	审视问题扩展审计协议

相关技能

• imbue:karpathy-principles - “简洁至上”和“精准修改”原则在更高层次的四原则综合中调用本契约
• 完整的门控技能联合图，请参阅 docs/quality-gates.md#skill-level-quality-gate-composition

减法原则

少依赖 AI 和最初的思路。 挑战自己，想出更优雅的 实现方式或更简单的解决方案。

接受任何添加之前，先问：“我能否通过删除代码而非添加代码 来实现这个目标？”如果可以， 优先采用减法方案。

退出标准

• 对每项拟议新增内容应用全部 5 个审查问题； 问题 4（证据）和 5（后果）须以具体证据作答， 而非基于假设
• 检查全部 6 种反模式（重复造轮子、臆造问题、 操纵测试、复杂度膨胀、偏离优先级、过度包装）；如有匹配项， 须标明对应的模式标签
• 为每项新增内容给出举证责任判定： justified、needs_evidence 或 unjustified；判定 须出现在使用该技能的输出中
• 应用减法原则：在接受任何净增行数的改动之前， 至少检查一次“能否通过删减代码实现这一目标？”