| name | coding-philosophy-cce |
| description | 编程哲学与决策框架。当需要写新功能、改bug、重构代码、审查代码、或做架构决策时，使用此技能。包含开发（熵增）和审查（熵减）两套思维。从第一性原理推理，核心问题永远是「收益是否大于副作用」。 |
来自 cc-enhance。-cce 后缀表示此技能由 cc-enhance 项目安装，避免与本地同名技能冲突。
哲学
代码有两种运动方向。写新代码是熵增——向系统添加新东西。审代码是熵减——在添加之前阻止劣质增量，在添加之后清理冗余。
两者共享一个根基：收益必须大于副作用。
开发（熵增）
写新代码的核心张力：每行代码都是负债。它今天解决问题，明天就要被维护、理解、调试。
做 vs 不做
| 做 | 不做 |
|---|
| 从第一性原理推理 | 盲目跟随惯例 |
| 陈述假设和权衡 | 默默选择一种理解 |
| 三行相似代码放原地 | 为一个用途建抽象 |
| 匹配已有代码风格 | 沿途「顺手」重构 |
| 一致地修改全局模式 | 只修一个实例制造不一致 |
| 验证完再声称完成 | 假装运行过 |
核心原则
- 用最少代码解决问题。不要加没人要的功能。不要为单次使用建抽象。不要为不可能发生的场景写错误处理。
- 依赖尽量用最新稳定版。代码会逐渐腐化，一开始就是最新版，可以让代码保质期更长一些。
- 只碰必须碰的。不改相邻代码。不修不是你搞坏的东西。只删你的改动导致不再需要的 import。
- 从第一性原理出发。把问题剥到可验证的事实。「大家都这么做」不是事实。
- 一致性是承重结构。设计决策改变时，找到每个假设旧方案的地方——旧代码是还没暴露的 bug。
- 识别局部最优。当增量改动暴露出更彻底的解决方案时，停下来和用户讨论，不要默默把小任务变成大规模重构。
- 测试跟着代码走。在同一轮改动中写好测试。「不重要所以不用测」的代码才是最容易出 bug 的。
审查（熵减）
代码审查的核心张力：不是所有问题都值得修。每次修改都有引入 bug、破坏一致性、让代码变复杂的风险。
永远值得修
- lint/typecheck 错误
- 未使用的 import
- 死代码分支（相同分支的三元表达式、不可达代码）
- 误导性命名
- 无意义包装（只转发给另一个函数的
useCallback、和另一个函数完全相同签名的函数体）
值得评估（收益 > 副作用？）
- 重复逻辑——相同的非平凡表达式出现在 2+ 处
- 重复的 JSX 结构
- 近乎相同的函数
- 跨文件的重复样板
通常不值得修
- 会分别演化的两处重复
- 简单 HTML 外壳的重复
- 单次使用的抽象机会
- 有语义差异的机械重复——不同层职责的相同字段 struct、含义不同的相同值
- 项目级模式的半修复——修一个留一个制造不一致
- 不减少重复的「提取到文件」
判断启发式
| 原则 | 说明 |
|---|
| 显式 > 短 | 一组相似函数共享平凡结构，不值得用工厂函数包装。可见的重复好于不可见的意图 |
| 语义重复 ≠ 机械重复 | 两层有相同字段但属于不同契约——这是隔离，不是浪费 |
| 不要为假想的未来设计 | 没有辅助函数、抽象层、配置开关，除非现在就有第二个调用方 |
| 修复规模和问题规模匹配 | 两行 bug 不值得重构整个模块。测试标准：只修问题本身，下一个人还能理解吗？能→补丁，不能→重构 |
| 遵循已有模式，要么全改 | 有问题模式要么是项目级惯例要么是项目级问题。没造成实际 bug 别碰，造成了单独一个 commit 全改 |
审查流程
结构：Summary → Critical（bug/安全/破坏性）→ Improvements → Nitpicks → Conclusion（Approve / Request Changes）
并行读，顺序写。审查时并行读所有文件收集发现。修复时顺序写——两个 agent 同时编辑同一文件会静默覆盖。
参考
更详细的示例和论证：
环境依赖
