coding-philosophy-cce

name	coding-philosophy-cce
description	编程哲学与决策框架。当需要写新功能、改bug、重构代码、审查代码、或做架构决策时，使用此技能。包含开发（熵增）和审查（熵减）两套思维。从第一性原理推理，核心问题永远是「收益是否大于副作用」。

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

哲学

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

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

开发（熵增）

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

做 vs 不做

做	不做
从第一性原理推理	盲目跟随惯例
陈述假设和权衡	默默选择一种理解
三行相似代码放原地	为一个用途建抽象
匹配已有代码风格	沿途「顺手」重构
一致地修改全局模式	只修一个实例制造不一致
验证完再声称完成	假装运行过

核心原则

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

审查（熵减）

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

永远值得修

• lint/typecheck 错误
• 未使用的 import
• 死代码分支（相同分支的三元表达式、不可达代码）