kaizen-continuous-improvementlisted

## 何时使用 适用于日常工程改进，贯穿写码、重构、架构设计、错误处理与代码评审。核心信条：许多小改进胜过一次大变更；错误在设计期预防，而非靠事后修补。 **不该用（负边界）：** - 不为追求「一次到位的完美」而停滞——本法主张今天够好、明天更好。 - 不做大爆炸式推倒重写；改进必须可拆分、可逐步验证。 - 不做无度量的提前优化与「以防万一」的过度抽象——先有证据再加复杂度。 - 任务��界、权限、安全约束或成功标准不清时，先停下来问清楚，再动手。 ## 步骤 四支柱，按需取用： **1. 持续改进（Kaizen）——增量优于革命** - 每次只做能提升质量的「最小可行变更」，验证通过后再做下一个。 - 顺手改善：随手修小问题、删死代码、更新过时注释（限定在当前 scope 内）。 - 三遍迭代法，不要一次全做：第一遍让它跑通 → 第二遍让它清晰 → 第三遍让它健壮/高效。 - 重构时一次只治一种坏味道，每步提交、保持测试常绿，到「够好」（收益递减）就停。 - 评审时建议增量改进而非重写，按 关键 → 重要 → 锦上添花 排序，接受「比之前更好」。 **2. 防错（Poka-Yoke）——让错误无法发生** 分层防御，越靠左（越早）越好：① 类型系统（编译期）→ ② 边界校验（运行期、尽早）→ ③ 守卫/前置条件 → ④ 错误边界（优雅降级）。 - 用类型让非法状态不可表达（联合类型带状态数据、`NonEmptyArray<T>`、品牌类型 `PositiveNumber`）。 - 在系统边界校验一次，内部到处安全使用；绝不「先用后校验」。 - 用早返回守卫表达并强制前置条件，快速且响亮地失败，给出清晰错误信息。 - 配置「必填优于带默认的可选」，启动时校验全部配置，失败就让部署/启动挂掉，而非到生产请求时才炸。 **3. 标准化工作——沿用已被证明的模式** - 一致性优于聪明：沿用代码库既有模式，不重复造轮子；新模式需显著更优且团队共识。 - 文档与代码同处：README 写架构、CLAUDE.md 写约定、注释写「为什么」而非「做什么」、复杂模式配示例。 - 自动化标准：Linter 管风格、类型检查管契约、测试管行为、CI/CD 管质量门禁。 - 落地前先搜代码库有无现成解法、查 CLAUDE.md 约定；破例需讨论并更新文档。 **4. 准时制（JIT / YAGNI）——只造此刻需要的** - 只实现当前需求，删掉「以后可能用到」的投机代码。 - 用「能跑通的最简方案」起步，需求变了再加复杂度。 - 优化先剖析后动手：先 profile 定位瓶颈，度量前后差异，接受「够好」的性能。 - 抽象遵循「三次法则」：同类场景出现 3+ 次再抽象；宁可重复，不要错误的抽象。 ## 指令 - 始终做最小可验证变更，做完一个验证一个再继续。 - 永远让代码比你看到时更好（leave it better）。 - 把校验放在边界、放在使用之前；让正确路径显而易见、错误路径难以走通。 - 沿用既有模式；引入新模式必须更优且达成共识，并更新文档。 - 没度量不优化，没出现 3+ 次不抽象，删除一切「以防万一」的代码。 ## 示例 三遍迭代（TypeScript，源自原技能）： ```typescript // 第一遍：跑通 const calculateTotal = (items: Item[]) => { let total = 0; for (let i = 0; i < items.length; i++) to