luochang212/cc-enhance/coding-philosophy-cce

来自 cc-enhance。-cce 后缀表示此技能由 cc-enhance 项目安装，避免与本地同名技能冲突。

哲学

代码有两种运动方向。写新代码是熵增——向系统添加新东西。审代码是熵减——在添加之前阻止劣质增量，在添加之后清理冗余。

两者共享一个根基：收益必须大于副作用。

开发（熵增）

写新代码的核心张力：每行代码都是负债。它今天解决问题，明天就要被维护、理解、调试。

做 vs 不做

核心原则

• 用最少代码解决问题。不要加没人要的功能。不要为单次使用建抽象。不要为不可能发生的场景写错误处理。
• 依赖尽量用最新稳定版。代码会逐渐腐化，一开始就是最新版，可以让代码保质期更长一些。
• 只碰必须碰的。不改相邻代码。不修不是你搞坏的东西。只删你的改动导致不再需要的 import。
• 从第一性原理出发。把问题剥到可验证的事实。「大家都这么做」不是事实。
• 一致性是承重结构。设计决策改变时，找到每个假设旧方案的地方——旧代码是还没暴露的 bug。
• 识别局部最优。当增量改动暴露出更彻底的解决方案时，停下来和用户讨论，不要默默把小任务变成大规模重构。
• 测试跟着代码走。在同一轮改动中写好测试。「不重要所以不用测」的代码才是最容易出 bug 的。

审查（熵减）

代码审查的核心张力：不是所有问题都值得修。每次修改都有引入 bug、破坏一致性、让代码变复杂的风险。

永远值得修

• lint/typecheck 错误
• 未使用的 import
• 死代码分支（相同分支的三元表达式、不可达代码）
• 误导性命名
• 无意义包装（只转发给另一个函数的 useCallback、和另一个函数完全相同签名的函数体）

值得评估（收益 > 副作用？）

• 重复逻辑——相同的非平凡表达式出现在 2+ 处
• 重复的 JSX 结构
• 近乎相同的函数
• 跨文件的重复样板

通常不值得修

• 会分别演化的两处重复
• 简单 HTML 外壳的重复
• 单次使用的抽象机会
• 有语义差异的机械重复——不同层职责的相同字段 struct、含义不同的相同值
• 项目级模式的半修复——修一个留一个制造不一致
• 不减少重复的「提取到文件」

判断启发式

审查流程

结构：Summary → Critical（bug/安全/破坏性）→ Improvements → Nitpicks → Conclusion（Approve / Request Changes）

并行读，顺序写。审查时并行读所有文件收集发现。修复时顺序写——两个 agent 同时编辑同一文件会静默覆盖。

参考

更详细的示例和论证：

• references/dev.md — 开发哲学完整版
• references/review.md — 审查哲学完整版，含审查流程和语调建议

环境依赖