之前推荐过几个 skill，有的管 UI 风格，有的管图标来源，有的管后端接口，有的管移动端页面。它们有一个共同点，都在解决“选什么”的问题：用什么图标、什么配色、什么组件、按哪套后端规范对齐。这些问题答清楚，产出物会变得统一，可代码本身怎么组织、函数怎么拆、状态归谁管，它们基本不管。

可要让 Codex 写出质量更高的代码，光会选还不够。真正决定代码干不干净的，是“怎么写”那一侧。这一篇开始，把注意力从选工具转到管代码上。

工具类 skill 管选择，代码类 skill 管行为

工具类 skill 回答的是“用什么”：用哪个图标库、哪种配色、哪个组件。它约束的是产出物的外观和来源，代码本身长什么样，它管得不多。

代码类 skill 回答的是“怎么写”：函数怎么命名、状态归谁管、异常在哪兜、边界怎么处理。它约束的是编码行为本身，直接决定代码的结构和可维护性。

同一个需求，Codex 工具选得再对，也可能写出一段结构混乱的代码。反过来，代码类约束到位，即使工具普通，代码也能保持在一个稳定的质量线以上。

这两类 skill 的分工一句话就能说清：选得对，不等于写得对。

代码质量的高低，恰恰取决于“怎么写”

代码质量从来不是靠选对工具堆出来的。命名统一、职责清晰、边界完整、异常不吞，这些是编码行为，不是选择行为。

而编码行为，是 Codex 默认最没有依据的部分。页面结构、字段、接口它能从上下文推断，但“这个项目里函数习惯怎么命名”“状态一般归到哪个层”，它从需求里读不出来。

读不出来的部分，就只能靠猜。猜的结果，就是这个项目的代码和那个项目的代码长得一模一样，都像通用 AI 答案，而不是像这个项目。质量上的差距，就在这里慢慢拉开：功能都对，结构却哪哪都不对味。返工一次两次还能接受，长期下来，每个页面都要人重新梳理结构，提效就变成了替 Codex 收拾。

代码类 skill 的本质，是项目的代码共识

所以代码类 skill 要沉淀的，不是泛泛的编程规范。它是“这个项目里代码应该长什么样”的共识：这里用哪个模式、那里禁止什么写法、接口在哪一层调用。

它可能只有几条，但每条都对应这个项目里真实反复出现的场景。它把 Codex 从“猜这个项目怎么写”变成“查这个项目的规矩”，这是工具类 skill 给不了的。

常见误区：把规则堆叠当成代码类 skill

代码类 skill 最容易写歪的地方，是把一堆通用编程建议塞进去：变量名要有意义、函数要短、不要重复代码。

这些都对，但对 Codex 没有约束力，因为它已经知道了，说了等于没说。真正有约束力的规则，是这个项目特有的判断：这里为什么用这个模式、那里为什么不允许那种写法。

通用规则谁都懂，项目共识才需要沉淀。

写在最后

工具类 skill 让 Codex 选得对，代码类 skill 让它写得对。对“质量更高的代码”来说，后者的分量重得多。

下一篇不讲推荐，讲怎么做：把项目的代码共识写成一个能用的代码类 skill，规则、反例、验收三块各写什么，Codex 才会真的照做。

本系列持续更新。之前几篇推荐的是本地装好的工具类 skill，这几篇起转向更关键的一类：自己写的、约束编码行为的代码类 skill。