核心原则
以满足真实需求的最小、清晰、可靠实现为目标。不要为了防范想象中的问题而增加复杂度，也不要为了证明代码正确而进行无休止的验证。
一、禁止过度防御
- 不要为缺乏现实依据、发生概率极低的竞态条件、异常路径或边界情况提前增加复杂逻辑。
- 如果认为额外防御确有必要，先说明具体故障机制、发生条件、实际影响和实现成本。没有依据时，不得编造风险概率。
- 不要以「更加健壮」「以防万一」为理由，擅自扩大修改范围。
- 已有代码能够可靠处理的问题，不要再增加一层包装、检查或兜底。
二、避免重复校验
- 外部输入应在明确的信任边界进行必要校验。
- 已经过验证、类型和约束明确的内部数据，不要在每个函数中重复校验。
- 只有数据跨越新的信任边界、约束发生变化或存在真实风险时，才增加相应检查。
- 不要为理论上不可能出现的内部状态编写大量防御分支。
三、坚持最小实现
- 优先使用简单、直接、容易理解的实现。
- 不要提前抽象只使用一次的函数。
- 只有逻辑需要复用、确实复杂，或者代表一个清楚的业务概念时，才提取独立函数。
- 不为未来可能出现的需求预先设计框架、接口或扩展层。
- 优先复用仓库已有能力，不重复造轮子。
四、保持代码结构清晰
- 主函数优先呈现正常业务流程。
- 必要的校验、异常处理和实现细节可以放在清楚命名的辅助函数中。
- 不要让正常流程淹没在大量条件判断、兜底分支和错误处理里。
- 不为了减少代码行数而牺牲可读性，也不为了形式上的架构完整而增加代码。
五、减少无价值注释
- 注释主要解释不明显的约束、设计原因和反直觉行为。
- 不给显而易见的代码逐行添加说明。
- 优先通过准确命名和清晰结构表达意图。
- 不生成没有必要的大段说明性注释。
六、尊重现有项目
- 遵循仓库已经采用的架构、命名、依赖和开发流程。
- 不擅自引入新的工具、框架、依赖或工作流。
- 自动生成的文件不得直接手工修改，应修改源文件后重新生成。
- 修复问题时只修改必要部分，不顺手重构无关代码。
七、测试真实实现
- 测试应验证真实业务行为，不要把实现逻辑复制一份放进测试代码。
- 优先采用能够覆盖真实行为的测试，避免为每个假设性分支编写测试。
- 尽量减少 Mock；只有隔离外部依赖、不可控环境等确有必要时才使用。
- 不为了提高测试数量或覆盖率数字而制造没有实际价值的测试。
八、禁止过度验证
- 实现前明确完成标准，实现后进行与风险相称的必要验证。
- 不要每修改几行代码就执行一遍完整测试、审计或构建。
- 优先批量完成相关修改，再集中运行最直接、最有价值的检查。
- 对已经通过验证、且未受到后续修改影响的部分，不重复测试。
- 发现问题时针对失败原因修复，不自动扩大为全项目排查。
- 核心需求已实现、必要检查已通过、没有已知阻断问题时，立即交付并停止。
- 不把反复验证当成工作成果，也不为了追求理论上的零风险而无限增加工作量。
九、必要的安全与正确性边界
精简代码不意味着忽视真实风险。
涉及安全、权限、数据丢失、外部不可信输入、资金操作或不可逆变更时，必须保留必要的防护和验证。
但任何额外复杂度都应有清楚的理由，而不是仅仅因为「理论上可能出错」。
最终执行准则
先理解需求，再完成最小实现，然后做必要验证，满足完成标准后立即停止。
- 不为假想风险堆砌防御代码。
- 不为只用一次的逻辑提前抽象。
- 不为显而易见的实现添加冗余注释。
- 不为形式上的完整性引入无关架构。
- 不为测试而测试，不为验证而验证。
- 不擅自扩大任务范围。
代码的质量来自正确、清晰、可靠且容易维护，而不是防御分支、抽象层和测试数量。