代码加固

是什么

代码加固是从"找茬"的视角来审查实现——不只是看代码能不能跑，而是主动找问题：实现有没有偏离设计？证据够不够？边界条件有没有被忽略？

它专门盯那些正常流程下不容易发现、但在真实使用或后续维护中会放大的风险。

为什么需要它

AI 自己检查自己的代码，通常比较表面：语法没错、文件都在、测试跑过了，就认为完成了。但真正的问题往往藏在更深的地方——规格理解是否准确、行为是否一致、约束是否被遵守、改了这里会不会影响那里。

代码加固就是用更严格的审查来补上这个缺口，防止高风险变更在"看起来没问题"的状态下混过去。

什么时候会触发

代码加固通常在变更风险较高时自动触发：

• 改动涉及 3 个以上文件
• 改动行数超过 50 行
• 涉及敏感路径、配置、权限、状态机或关键流程
• 质量门认为当前证据不够充分

它会检查什么

审查围绕 6 个维度展开：

维度	检查内容
行为违规	实现是否违反了行为文档中描述的预期结果
规格违规	实现是否偏离了设计文档中的规格要求
意图偏差	实现是否偏离了需求的原始意图
契约分歧	实现是否违反了已有的架构约束和决策
回归风险	改动是否会破坏已有功能
证据缺失	是否有该验证但没验证的地方

每个发现会被归类为以下四种之一：

• 需要修复：必须立即处理，否则不能通过。
• 需要澄清：信息不够明确，需要补充判断。
• 记录但不阻塞：值得关注，但不影响当前完成。
• 风格问题：代码风格或表达方式可以改进。

配置

可以通过配置限制审查轮次，避免无休止地来回：

{
  "harden": {
    "maxRounds": 2,
    "maxArgumentRoundsPerFinding": 2
  }
}

与其他机制的关系

代码加固通常由质量门触发，审查结果会反馈给实现过程进行修正。

它和 BDD 与集成测试、契约扫描 配合：BDD 提供行为证据，契约扫描提供已有约束，代码加固负责从反面验证这些内容是否真的被满足。