用工程环境提高交付质量

继续看相关机制：F30 · 代码检索不能只靠“语义相近”F35 · 读指标，先问它的分母是谁

让代码环境成为可靠的信息与反馈系统

本篇对应Harness Engineering。模型能力之外，仓库知识是否可发现、工具是否清晰、测试是否能运行，都会影响最终交付。官方文章提供特定团队经验，不是通用效率承诺。[S065]

原创对照：项目A只有一句“严格遵守规范”；项目B提供模块入口、路径约定、可运行测试与重要边界。后者给出可操作证据，而不是要求模型凭空理解。

把规则放在合适位置

全局入口提供地图，模块文档提供局部事实，Skill提供专业方法，测试和静态检查落实稳定约束。相同规则复制在多处会产生冲突，需要明确权威来源。[S122][S139]

不是所有规则都应写成强制检查。约束稳定且违反后果严重时适合自动化；需要情境判断时保留原则与证据，避免把复杂问题硬编码为脆弱规则。

从失败模式决定流程

简单Bug有明确复现与局部补丁时，可以快速修改验证。跨模块约定不清时，需要调查；高风险变更需要更强独立检查。固定Analysis→Task→Review并非对所有任务都最优。

代码审查应提高健康度，不因非关键不完美无限阻塞。小且明确的问题可以直接修复再验证，重要设计分歧再回到决策。[S136][S137]

长任务交接必须可恢复

交接保留目标、当前代码、已完成内容、验证与待办。文字说“功能完成”不足够，必须知道对应版本。任务恢复也不能盲目重复外部动作。[S130][S142]

原创例子：补丁已应用、测试未运行。新会话应先确认文件，再运行验证；不能重新应用补丁后声称重复执行就是更安全。

工程机制也要接受回归测试

Prompt、工具、上下文裁剪和模型配置都可能改变质量。官方产品复盘表明Harness调整也会造成回退，因此长任务、压缩、恢复和边界任务需要覆盖。[S141]

完成本篇后，应该能对每项规则回答：防什么错误、有没有证据、执行成本多少、模型或环境变化后是否仍需要。