Codex 在编程方面常用的 Skill
Codex 真正好用的地方，不只是“让它写一段代码”。
更准确地说：
1 | Codex 更像一个可以调用不同 Skill 的工程协作台。 |
不同 Skill 解决不同问题。
有的负责写代码，有的负责做前端设计，有的负责安全审计，有的负责查文档，有的负责跑浏览器验证，有的负责写计划和拆任务。
如果只是把 Codex 当成一个聊天机器人，那会浪费它一半以上的能力。
一、Code：最基础，也是最常用的编程 Skill
如果只选一个编程相关 Skill，那一定是：
1 | Code |
它适合处理最常见的开发任务：
- 阅读项目结构
- 理解已有代码
- 修改 Bug
- 新增功能
- 跑测试
- 看 Git diff
- 整理最终改动说明
这个 Skill 的核心价值不是“会写代码”，而是：
1 | 它会按工程流程做事。 |
比如你让 Codex 修一个问题，它不会只看报错行，而是会先看相关文件、上下文、调用链，然后再决定怎么改。
这点非常重要。
因为真实项目里，很多 Bug 都不是一行代码的问题，而是状态、数据结构、组件边界、配置项一起造成的。
二、frontend-design：做页面时很有用
如果你在做博客、后台管理系统、工具页、组件页面，frontend-design 就很有用。
它不是单纯帮你写 CSS。
它更像是在帮你做这些事：
- 判断页面应该是什么气质
- 选择布局方式
- 控制间距、字号、颜色层级
- 避免页面看起来像模板
- 处理移动端和桌面端的差异
比如这次博客首页调整，就不是简单地“加几个按钮”。
更好的做法是：
1 | 先判断首页最重要的信息是什么，再决定视觉层级。 |
所以分类入口放在首页顶部，文章列表做成 PC 两列，标签和分类完整显示。
这样页面不是更花，而是更容易扫。
三、browser：前端改完必须看一眼
前端代码最大的问题是：
1 | 构建通过，不代表页面好看。 |
有些问题只有打开浏览器才看得出来：
- 文字是否换行
- 按钮是否挤压
- 移动端是否溢出
- 暗色模式是否看不清
- 图片有没有加载失败
- 页面顶部是否留白太多
这时候 browser Skill 就很重要。
它可以打开本地页面，比如：
1 | http://localhost:4000/ |
然后检查真实页面效果。
我认为这是 Codex 做前端时最容易被低估的能力。
很多 AI 写出来的页面，第一眼看代码没问题，但打开之后就会发现：间距怪、层级乱、移动端崩。
让 Codex 写完之后自己打开页面检查，相当于多了一轮视觉 QA。
四、security-auditor：涉及登录、接口、权限时必用
如果项目里出现这些东西：
- 登录注册
- JWT
- Cookie
- CORS
- 上传文件
- 用户权限
- 数据库查询
- Webhook
- 第三方回调
那就应该考虑使用：
1 | security-auditor |
这个 Skill 不是为了让代码“看起来更安全”，而是帮你从攻击面去检查问题。
比如：
- 是否有 XSS 风险
- 是否有 SQL 注入风险
- 是否把 secret 写进前端
- 是否信任了用户输入
- 是否有越权访问
- CORS 是否开得太宽
普通开发时很容易忽略这些点。
尤其是快速写功能的时候，最容易出现一句：
1 | 先这样，后面再补安全。 |
但安全问题通常不会等你“后面再补”。
五、architecture-designer：不要一上来就写代码
有些任务不适合直接开写。
比如：
- 新增一个完整模块
- 重构旧系统
- 设计权限模型
- 设计多端同步
- 设计缓存策略
- 设计任务队列
这时候应该先用：
1 | architecture-designer |
它的作用是先把系统边界想清楚。
很多复杂功能失败，不是因为代码写不出来，而是一开始就没有想清楚：
- 数据怎么流动
- 状态放在哪里
- 谁负责校验
- 出错后怎么恢复
- 哪些逻辑应该复用
- 哪些东西不能耦合
Codex 如果直接写代码，可能会很快。
但如果方向错了，越快越麻烦。
所以复杂功能最好先设计，再实现。
六、writing-plans 和 executing-plans：适合大任务
当一个需求超过一两个文件时，我一般更推荐使用两个 Skill：
1 | writing-plans |
前者负责写计划。
后者负责按计划执行。
这对于大型改动很有帮助。
比如：
- 先列出要改哪些文件
- 每一步为什么要改
- 怎么验证
- 哪些地方可能有风险
- 完成后怎么检查
很多人用 AI 编程，最大的问题是让 AI 一次性改太多。
结果就是：
1 | 代码看似都改了，但你不知道它到底改了什么。 |
计划型 Skill 的好处是把过程拆开，让每一步都有边界。
这对真实项目非常重要。
七、git-essentials：提交前的最后一道整理
写完代码之后，不要急着提交。
可以让 Codex 用 git-essentials 帮你检查：
- 当前有哪些改动
- 哪些文件是新增的
- 有没有不该提交的文件
- diff 是否符合预期
- commit 信息怎么写更清楚
尤其是博客、前端项目、Node 项目里，经常会混进：
1 | node_modules |
这些东西不应该传到 GitHub。
所以 Git 相关 Skill 虽然不“炫”，但非常实用。
八、openai-docs / cloudflare / workers-best-practices：查官方资料时用
当任务涉及某个具体平台时，最好不要只靠记忆。
比如：
- OpenAI API
- Cloudflare Workers
- Durable Objects
- Wrangler
- Agents SDK
这些东西更新很快。
这时候应该用对应的文档类 Skill。
比如：
1 | openai-docs |
这类 Skill 的价值是：
1 | 尽量按官方文档和最佳实践来写，而不是凭印象写。 |
对于变化快的平台，这一点非常关键。
因为旧写法可能还能跑，但已经不是推荐写法。
九、imagegen：写文章和做页面时的配图工具
如果你在写博客、做落地页、做产品页面，imagegen 也很有用。
它适合生成：
- 文章配图
- 首页视觉图
- 产品概念图
- 技术流程插画
- 简单的场景图
但要注意一点：
1 | 图片里尽量不要放需要准确阅读的文字。 |
因为生成图里的文字很容易变形。
更好的方式是让图片表达氛围和结构，把准确的信息放在 Markdown 或页面文案里。
这篇文章里的配图就是这种思路：
1 | 用图表达 Codex Skill 工作流，但不依赖图中文字。 |
十、我更推荐的 Codex Skill 使用顺序
如果是一个真实开发任务，我更推荐这样的顺序：
1 | 1. Code：先看项目和上下文 |
这个顺序不是固定的。
但它有一个核心原则：
1 | 不要让一个 Skill 干所有事。 |
不同 Skill 有不同职责。
把它们组合起来，Codex 才更像一个完整的开发搭档。
总结
Codex 的强大，不在于它能一次性生成多少代码。
真正有价值的是：
1 | 它可以在不同阶段切换不同工作方式。 |
写代码时用 Code。
做页面时用 frontend-design。
查问题时用 browser。
做安全检查时用 security-auditor。
设计系统时用 architecture-designer。
提交前用 git-essentials。
写文章和做配图时用 imagegen。
如果把这些 Skill 用好，Codex 就不只是一个“帮你补全代码”的工具。
它更像一个可以陪你从想法、实现、验证到提交的工程助手。