断言先行与小步构建

用于把行为要求落实为可回归的代码，按风险选择测试方式与反馈频率。

适用时采用测试驱动开发（TDD）

对规则明确的新逻辑、可复现缺陷和核心不变量，优先先写能失败的断言，再做最小实现，最后整理代码并复跑测试。观察失败原因，避免测试因环境错误失败，或本来通过却被当成复现。

例如修复重复提交：用相同业务键重复调用，断言副作用仅一次；增加约束或条件更新后重跑。数据库并发风险不能只靠内存 mock 单测，还需针对真实数据库语义验证。

探索性集成、视觉调整或纯配置修改，可先做最小实验、静态检查或人工观察，再补适合长期保留的验证。用户要求先跑通时，按约定调整测试代码的投入顺序，仍先明确实验边界、关键行为和必要保护。先跑通不等于先部署再补恢复设计；也不要为形式上的 TDD 写检测不到目标错误的测试。

让代码结构对应职责

• 单一职责：函数或模块围绕一项明确能力组织，修改主要来自同一类原因；会独立变化的规则分别承接。
• 按职责拆分：一项能力可以包含多个步骤。拆分应减少调用方需要了解的细节，复用共同处理；不按行数或步骤数量拆函数。
• 走读检查：沿调用链核对职责，重点看修改一项规则是否牵动无关代码，是否有重复处理或多余转发。

例如，主函数分发命令，标签处理函数负责参数、过滤和输出；修改标签展示规则只影响后者，对外仍保留一个入口。

按行为切片，不按文件计数

一个可验证切片可跨路由、逻辑和测试多个文件。每次改动对应清楚的行为或结构变化，在关键假设、接口和副作用边界尽早反馈，而非每改一个文件跑全套测试。

按影响面选择最小有效反馈：类型变化跑编译检查，规则变化跑相关单测，协议变化跑契约或集成测试，共享基础能力变化扩大回归。切片完成后检查差异，移除调试残留和无关修改。

工程自治与依赖管理

适用的既有约定继续沿用；范围内可基于证据纠正实现，更新共同记录中的重要决定。函数拆分、内部命名和测试组织不需重新申请蓝图。

新增依赖检查已有能力、兼容、许可、安全与维护成本，遵守安装权限并维护锁文件。引入新服务、外部费用、显著运维负担或改变业务承诺时先确认，不把范围变化当实现细节。

验证失败应修复原因，不删除断言、吞掉错误或用假数据制造通过。修正错误测试时说明行为依据，保留覆盖真实要求的断言。