Coding Philosophy Cce
编程哲学与决策框架。当需要写新功能、改bug、重构代码、审查代码、或做架构决策时，使用此技能。包含开发（熵增）和审查（熵减）两套思维。从第一性原理推理，核心问题永远是「收益是否大于副作用」。
Install
$ agentstack add skill-luochang212-cc-enhance-coding-philosophy-cce ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Links to your public security report.[](https://agentstack.voostack.com/security/report/skill-luochang212-cc-enhance-coding-philosophy-cce) Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
> 来自 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) — 审查哲学完整版，含审查流程和语调建议
环境依赖
| 依赖 | 用途 | 安装方式 | 磁盘 | 必需 | |------|------|----------|------|------| | 无 | — | — | — | — |
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: luochang212
- Source: luochang212/cc-enhance
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.