规则，只要项目特有的判断

规则不要多，三五条就够，每条都得是“这个项目里 Codex 猜不到”的判断。

例子：列表查询统一走 getList，不各自在页面里发请求；组件内不直接改写 props 来源的对象，要提交走 emit；接口异常统一抛到入口，业务代码里不散落 catch 吞掉。这类规则写进 skill 时，最好再注明它在哪个文件、哪个组件里最先出现，Codex 查得到实例，而不是对着一句抽象条文自己发挥。

这些规则放进通用编程规范里没有意义，但它们是这个项目反复出现的场景。Codex 从需求里读不出来，才需要 skill 告诉它。

反例，Codex 只有看到反例才知道边界

规则只说“应该怎样”，Codex 经常不知道“不怎样”长什么样。每条规则配一个错写和一个对写，是 skill 里最值钱的部分。

结构示意：

// 错：页面里直接发请求，绕过列表入口
const res = await request({ url: '/list', params });
list.value = res.data;
​
// 对：走项目统一的列表入口
const res = await getList({ page: 1, size: 10 });
list.value = res.data.records;

反例的价值在于把边界显性化。Codex 看到错写，才知道规则挡的是什么；只给对写，它容易在相近的场景里继续发挥。一组正反例放在一起，规则就从抽象的描述变成了可对照的实物：Codex 写新代码时，先在脑子里把这组例子过一遍，落下的位置更像哪个错写，自己就该停一停。

验收，告诉它写完怎么自查

规则后面要跟验收方式。哪些静态能查，哪些要跑页面才能确认。

静态能查的：命名、入口调用、是否直接改了 props。这些 Codex 写完自己过一遍就能判。

要运行确认的：异常是否真的被入口兜住、提交是否重复。这些不能靠读代码下结论，要标成“跑一遍确认”。

验收写清楚，skill 就从“要求”变成了“可检查”，Codex 交付前能照着过一遍。

长度和加载方式

代码类 skill 要短。三五条规则配反例和验收，内容控制在能一次读完的范围。规则越多，Codex 越记不全，优先级越糊，这和需求分层是同一个道理。

加载方式有两种：一种是在任务里声明“按项目代码规范 skill 处理”，一种是把要点写进 AGENTS.md 让它常驻。前者灵活，后者默认在场。项目大、规范稳定时，后者更省心。

边界：管怎么写，不管写什么

代码类 skill 管的是“怎么写”，不是“写什么”。业务需求、交互逻辑、接口语义，这些还是要靠任务上下文说清楚，skill 补不了。

它也不能替代人审。规则覆盖不到的场景，仍然要靠人去判断。skill 的价值是让 Codex 大部分时候走对路，不是保证永远不会偏。

写在最后

一个代码类 skill，规则定方向、反例划边界、验收给标准，三块缺一不可。写得好，Codex 写代码时有据可依，质量稳得住。

下一篇进入实际演示：拿一个真实的前端编码场景，把它的代码共识完整写成一份 skill，看 Codex 照做之后代码长什么样。

本系列持续更新。这一篇起，方向从“推荐本地工具”转向“自己造代码类 skill”，更靠近代码质量本身。