coding-philosophy-cce

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 同时编辑同一文件会静默覆盖。

参考

更详细的示例和论证：

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

环境依赖

依赖	用途	安装方式	磁盘	必需
无	—	—	—	—