# Coding Philosophy Cce

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

- Skill: `luochang212/coding-philosophy-cce` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add luochang212/coding-philosophy-cce`
- Raw SKILL.md: https://api.skillmd.com/api/skills/luochang212/coding-philosophy-cce/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: luochang212 (https://skillmd.com/u/luochang212)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/luochang212/coding-philosophy-cce

---


> 来自 [cc-enhance](https://github.com/luochang212/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/dev.md) — 开发哲学完整版
- [references/review.md](references/review.md) — 审查哲学完整版，含审查流程和语调建议

## 环境依赖

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