我把 Codex 协作经验，整理成了一套公共 Skills

最近我越来越明显地感觉到：AI 编程真正拉开差距的，不只是模型强不强，而是你有没有一套稳定的协作系统。

同一个 Codex，有的人用起来像高级搜索框，有的人用起来像靠谱的工程同事。差别往往不在某一句神奇 prompt，而在于：项目规则、任务交接、验证标准、风险门禁、错误复盘，这些东西有没有被沉淀下来。

一句话概括：Skill 是把反复提醒 AI 的工作习惯，做成可复用的能力。

Skill 不是提示词，是工作制度

我理解的 Skill，不是"写一段更长的 prompt"，而是 Codex 的专业工作说明书。

平时我们和 AI 协作，经常会反复强调这些事：

• 新项目先读规则，不要上来就改。

• 不要把聊天历史当长期记忆，重要信息写进项目文件。

• 长任务要能交接，不能一断会话就从头来。

• 改完不算完成，要跑验证，要说明没测什么。

• 权限、日期、通知、迁移、部署这些高风险地方，要额外检查。

• 遇到回归和事故，要记录根因和漏检点，下次别再踩。

这些规则如果每次都靠人提醒，很快就会变成负担。所以我把它们整理成了一套公共 Skills，让 Codex 在对应场景里自动按这套流程工作。

我这套公共 Skills 想解决什么？

我遇到的问题不是"AI 不会写代码"。更多时候，问题出在协作过程本身：

• 上下文越来越长，聊天变慢，恢复也慢。

• 前面讨论过的项目事实，换个会话又要重新解释。

• 任务做到一半，状态散在聊天里，没有稳定交接文件。

• AI 改完代码就想收工，但实际上还没验证。

• 高风险逻辑容易漏边界，比如权限、时区、通知、数据迁移。

• 同一个坑踩过一次，没有沉淀成下一次的检查项。

所以这套 Skills 的目标不是让 Codex "话更多"，而是让它工作更像工程同事：知道先读什么、状态写到哪里、改完怎么验证、出错后怎么复盘。

这套公共 Skills 的六类协作能力

第一类：项目治理，先把协作入口建起来

project-governance 是整套体系的入口。它负责在项目里创建一组协作文件，让新会话不用依赖完整聊天历史。

• AGENTS.md

  ：项目级入口，告诉 Codex 新会话先读什么。

• PROJECT_CONTEXT.md

  ：稳定项目事实，比如技术栈、目录结构、运行命令。

• SECRETS.local.md

  ：本地敏感信息，默认加入忽略，不进入公共规则。

新项目里，我可以直接说：

Init_project

它会检查并创建缺失的治理文件。这个动作的意义是：先搭项目制度，再开始让 AI 干活。

第二类：任务交接，解决长会话和断点续做

长任务最怕状态散在聊天里。聊久了，上下文会变重；换新会话，又容易丢细节。

所以我加了两类交接文件：

• ACTIVE_TASK.md

  ：当前任务草稿，记录目标、验收、相关文件、已运行命令、发现、阻塞和下一步。

• SESSION_SUMMARY.md

  ：替换式会话摘要，保留当前状态、近期变更、决策、未决事项和下次检查项。

当任务变长，或者准备开新会话时，我可以说：

Handoff

Codex 会优先用内置脚本更新交接文件。这样下一次不是靠"模型记得"，而是靠项目文件恢复。

第三类：发布验证，写完不等于完成

release-validation 的核心原则很简单：Implementation is not completion。

代码写完只是其中一步。真正说"完成"之前，需要有验收标准和验证证据：

• 这个任务的触发条件是什么？

• 用户可见结果是什么？

• 跑了哪些测试或检查？

• 哪些通过了？

• 哪些没测，为什么没测？

• 还有什么残余风险？

这会逼着 Codex 不只是"把文件改了"，而是把任务走到可交付状态。

第四类：风险门禁，高风险改动要额外检查

quality-gates 负责挑出高风险场景的检查项。它不是让最终回答变长，而是让 Codex 在关键地方别漏。

比如这些场景就需要门禁：

• 权限和可见性：前端可以提醒，但服务端必须最终约束。

• 表单和隐藏状态：页面看到的值，要和提交 payload 一致。

• 日期和截止时间：时区、before / at / after、跨天、月末都要说清楚。

• 通知：触发事件、收件人、去重、聚合、失败日志都要定义。

• 定时任务和异步任务：首次运行、重复运行、重试、last-run 标记都要检查。

• 迁移和部署：已有数据、可重复执行、回滚路径和健康检查都不能漏。

这类 Skill 的价值在于，它把"老工程师脑子里的风险清单"显性化了。

第五类：后端工程，别只改一层

backend-engineering 负责让 Codex 用后端工程的方式看问题。

后端改动最怕只盯着一个函数。一个字段、一个状态、一个接口，背后可能牵涉：

• 数据库 schema 和 migration；

• 请求参数和响应契约；

• 服务端校验和权限；

• 前端或其他 API 消费者；

• 日志、通知、外部集成；

• 重试、幂等、并发和旧数据。

这个 Skill 的作用，是让 Codex 把数据模型、API 边界、持久化、副作用和部署行为放在一起验证。

第六类：问题复盘，把错误变成下次的检查项

这块是我觉得最值得强调的。

很多 AI 协作的问题，不是当下修不好，而是同一个坑下次还会再踩 。所以我在项目治理里加入了 CODING_NOTES.md。

它不是普通笔记，而是事故和回归经验库。结构是：

• Symptom / 现象

  ：发生了什么。

• Root Cause / 根因

  ：为什么发生。

• Missed Check / 漏检

  ：什么检查本可以发现。

• Prevention / 预防

  ：下次要搜索、测试或验证什么。

release-validation 里也有 Failure Protocol：如果用户反馈回归，先承认这是验证遗漏，然后查日志和数据，不要猜；修复后把可复用经验写回项目 notes；最后重新跑相关验收场景。

这让 Codex 不只是"完成这一次任务"，还会把真实错误变成未来任务的检查项。

这套 Skills 的好处

对我来说，它最大的价值不是少写几句提示词，而是把协作变稳定了。

• 新项目启动更快

  ：一句 Init_project 建好协作入口。

• 长任务更容易续上

  ：当前状态写进 ACTIVE_TASK.md 和 SESSION_SUMMARY.md。

• 完成标准更清楚

  ：不再把"改完文件"当作"完成任务"。

• 高风险改动更稳

  ：权限、日期、通知、迁移、部署都有对应检查。

• 后端改动更完整

  ：API、schema、DB、权限、副作用一起看。

• 错误能沉淀

  ：事故、回归、漏检点进入 CODING_NOTES.md，下次先读。

适合谁用？

如果你只是偶尔问 AI 一个代码问题，这套东西可能有点重。

但如果你经常让 Codex 做这些事，它会很有价值：

• 长期维护一个项目；

• 频繁跨会话继续工作；

• 让 AI 直接改代码、跑命令、做验证；

• 涉及后端、数据库、部署、通知、权限；

• 希望把踩过的坑沉淀成下次自动检查的规则。

最后

我现在越来越觉得，AI 编程不是单纯"模型替人写代码"，而是人、模型、项目规则、验证流程一起组成的软件生产系统。

这套公共 Skills 做的事，就是把我反复提醒 Codex 的协作习惯，整理成一个可复用的系统：能启动项目、能交接任务、能验证发布、能识别风险、能做后端工程判断，也能把错误沉淀下来。

**一句话总结：**不要只让 AI 记住这次聊天，要让它在下个项目、下个会话、下个错误之后，仍然按更好的方法工作。

关注我并留言，获取Public-Skills