在架构设计、代码评审或工程文化咨询时…

当需要从系统层面思考软件工艺（DRY、正交性、曳光弹、契约式设计、破窗效应、可逆性、估算与知识组合）而非仅写代码时使用。

适用场景

解决思路

1. 按七条快速诊断逐条打分：每条答“是”约得 1.4 分（7 条全是为 10 分），然后分档：9-10 分表示所有原则成立（DRY 知识、正交分层、可用的曳光切片、边界契约、无破窗、可逆的供应商/数据库选择、区间估算）；5-6 分表示有 1-2 处违规并造成真实变更成本（如业务逻辑耦合数据库、单点估算）；≤3 分表示普遍重复、全局状态或累积破窗，熵正在取胜。始终给出分数、指出未通过的行，并给出 Action 列中的具体修复以达到 10/10。
2. DRY：确保每一条知识在系统中有单一、无歧义、权威的表示；DRY 针对知识而非代码，重复的逻辑、业务规则或配置比重复语法更危险。区分四类重复：强加的（环境迫使）、无意的（开发者未察觉）、急躁的（懒得抽象）、开发者之间的（多人重复）。不要 DRY 仅外观相似但服务不同业务规则的代码块。避免用注释复述代码（违反 DRY，应解释“为什么”而非“是什么”）。数据库模式、API 规范、文档应从一个来源生成。
3. 正交性：设计自包含、独立、单一明确职责的组件，使一个组件的变化不影响另一个。自问：“如果大幅改变某函数背后的需求，会影响多少模块？”答案应为一个。消除无关事物之间的影响（如日志变更绝不应破坏计费）。采用分层架构（表现层、领域逻辑、数据访问）。避免全局数据，每个消费者都会与全局状态耦合。避免强制继承其类的框架，因为会降低正交性。
4. 曳光弹与原型：曳光弹是连接系统所有层的端到端实现，功能最少但是生产代码（保留）；原型是对单一风险方面的聚焦探索（丢弃）。当“在黑暗中射击”（需求模糊、架构未验证）时使用曳光弹。若曳光弹未命中，调整后再次发射，迭代成本低。明确将原型标记为一次性，绝不让其变成生产代码。应用示例：新项目用垂直切片（按钮→API→DB→响应）；不确定技术用 spike 原型（如先测 WebSocket 性能）；微服务用 walking skeleton（Hello-world 服务走完整 CI/CD 流水线）。
5. 契约式设计与断言式编程：通过前置条件（调用前必须为真）、后置条件（保证调用后为真）、不变式（始终为真）定义并强制模块的权利与责任。契约被违反时立即大声失败（死程序不说谎）。前置条件是调用者责任（如“我只接受正整数”）；后置条件是例程的保证（如“我将返回排序列表”）；不变式始终为真（如“账户余额永不为负”）。对“绝不应发生”的事用断言，对“可能发生”的事用错误处理。在动态语言中通过运行时检查和守卫子句实现契约。应用示例：函数入口用前置条件守卫（如 `assert age >= 0, "Age cannot be negative"`）；类状态在每次变更后调用 `validate!`；API 边界在处理前按 schema 验证请求体。
6. 破窗效应：不要留下未修复的破窗（糟糕设计、错误决策、劣质代码）。若无法立即修复，就先“封板”：带工单的 TODO、禁用功能、桩。做变革的催化剂：向人们展示未来可用的一瞥（石头汤）。警惕缓慢退化（温水煮青蛙），持续监控技术债指标。第一个 hack 最昂贵，因为它为后续所有 hack 开了许可。应用示例：遗留代码在加功能前先用干净接口包裹坏代码；代码评审对新债零容忍，拒绝无工单的 `// TODO: fix later`；每个 sprint 分配 20% 技术债预算修复破窗。
7. 可逆性与灵活性：没有最终决定。构建系统时让数据库、框架、供应商、架构、部署目标都易于改变，变更成本应与变更范围成比例。将第三方依赖抽象在自己的接口后，绝不让供应商 API 泄漏到业务逻辑。用“岔路口”测试：能否在一周内从 Postgres 切换到 DynamoDB？若不能则已耦合。元数据驱动系统（配置文件、功能开关）比硬编码逻辑更灵活。YAGNI 也适用于过早抽象，不要构建尚不需要的灵活性。可逆性不是预测未来，而是不把自己逼入死角。应用示例：数据库用 Repository 模式（业务逻辑调用 `repo.save(user)` 而非 `pg.query(...)`）；外部 API 用适配器/包装器（`PaymentGateway` 接口包装 Stripe，日后可换 Braintree）；功能开关做运行时切换（新结账流程置于开关后，秒级回滚）。
8. 估算与知识组合：通过理解范围、建立模型、分解组件、分配区间来可靠估算。像管理金融组合一样管理学习：定期投资、多样化、再平衡。先问“这个估算用于什么？”——上下文决定精度（预算规划 vs. sprint 规划）。使用 PERT：(乐观 + 4×最可能 + 悲观) / 6。分解为组件分别估算，总和比单一猜测更准。维护估算日志，对比估算与实际并校准。组合规则：定期投资（每周学习）、超越自身技术栈多样化、混合安全与投机押注、尽早学习新兴技术（低买）。应用示例：sprint 规划用区间估算（“3-5 天”并附置信度，而非单一数字）；新技术用时间盒 spike（“评估 2 天，之后才能正确估算”）；学习每周投入（每周 1 小时学新语言、工具或领域）。
9. 避免常见错误：不要 DRY 外观相似但目的不同的代码（会耦合无关概念）；不要跳过曳光弹逐层构建（集成问题会晚暴露、无端到端反馈）；不要因“以后重构”而忽视破窗（熵加速、以后永不到来、士气下降）；不要给出单点承诺式估算（虚假精度会侵蚀信任）；不要一开始就把一切做“灵活”（过度工程、无证据的抽象）；不要为性能移除生产断言（断言能捕获的 bug 会静默损坏数据，移除前先基准测试）；不要为方便使用全局状态（破坏正交性，一切耦合一切）。

适用边界 · 注意事项

• 仅需要代码级质量或重构技巧时（应改用 clean-code 或 refactoring-patterns 技能）
• 需要针对具体工具、云厂商或付费服务的操作指导时（本技能为通用工艺原则）
• 团队尚未有基本工程实践、需要先建立基础流程时，直接套用全部七条可能过于抽象