共计 1757 个字符，预计需要花费 5 分钟才能阅读完成。
很多人刚开始用 Codex，让它写页面、修 bug、解释报错、补测试。
这当然有用，但远远不是 Codex 的完整形态。
真正高效的人，是给 Codex 配好一套能力系统。
你可以理解成：模型是大脑，skills、规则、工具、验证流程，是它的手、眼睛、记忆和工作方法。
新手想让 Codex 提效百倍，最该补齐的是下面 8 种能力。
Codex 的效率系统，至少分三层
第一层是 skills：负责具体任务流程。
比如写 PR、修 CI、做 Figma 还原、生成 PDF、处理表格、写安全审计报告。
第二层是 AGENTS.md：负责项目规则。
比如这个仓库用 pnpm，改前端必须跑 npm test，API 不允许破坏兼容性，安全模块不能随便改权限。
第三层是 MCP 和 plugins：负责连接外部世界。
比如查最新文档、访问 Figma、操作 GitHub issue、读取 Notion、看 Sentry 日志、用浏览器验证页面。
所以，高手不是“装一堆 skills”，而是把这三层分清楚：流程放 skill，长期规则放 AGENTS.md，外部工具接 MCP/plugin。
新手最该装的不是 8 个 skills，而是 8 类能力
第一类：skill 创建能力。
先装或使用 skill-creator。你真正需要的不是别人列的神技，而是把自己的高频流程封装起来。比如“每次写小红书脚本都先拆爆款结构”“每次做产品页都先生成信息架构”。
第二类：skill 安装与发现能力。
视频里提到的 Find-skill 类工具，本质是 skill discovery。现在更稳的做法是用官方的 skill installer 或插件目录，从可信来源安装，再检查内容。
第三类：产品规划能力。
这类 skill 应该帮你把“我要做个功能”拆成用户、场景、需求、边界、验收标准。没有这一步，Codex 很容易快速产出一堆不该写的代码。
第四类：规格到实现能力。
好用的 PM/spec skill 应该能把需求转成 issue、任务列表、接口约定、UI 状态和测试点。它让 Codex 从“猜需求”变成“按规格交付”。
第五类：前端设计能力。
不是让 Codex 随机美化，而是让它懂业务类型。SaaS 要克制、密集、可扫描；作品集要突出视觉；游戏要交互和动效。审美类 skill 的价值是减少“AI 味模板页”。
第六类：视觉验证能力。
前端一定要配 screenshot、Playwright、浏览器检查类 skill。没有验证的 UI 生成，基本都是开盲盒。
第七类：工程闭环能力。
包括修 CI、处理 PR 评论、生成 changelog、跑测试、定位 Sentry 错误。真正省时间的是这些脏活累活，不是炫技 demo。
第八类：部署与交付能力。
Vercel、Netlify、Cloudflare、Render 这类 deploy skill，可以让 Codex 不只写代码，还能把项目推到可访问状态。
最容易踩的坑：把 skills 当插件商店乱装
skills 不是越多越好。一个坏 skill 可能比没有 skill 更危险。
原因很简单：SKILL.md 不是普通说明文档，它会影响 Codex 什么时候选择这个 skill、如何理解任务、是否运行脚本、是否访问文件。研究里已经指出，skill 的自然语言描述本身就可能成为供应链攻击面。
所以装 skill 要看 5 件事：
它的 description 是否过度泛化；
它有没有脚本，脚本会不会联网、改文件、读隐私；
它是否要求不必要的权限；
它是否来自可信仓库；
它是否真的对应你的高频任务。我的建议是：先少装，装一类用一类。每装一个 skill，都让它服务一个明确工作流。
真正的提效公式
Codex 提效不是：
更强模型 + 更长提示词 = 更好结果。
而是：
明确目标 + 固定流程 + 项目规则 + 工具连接 + Git 回滚 = 可重复交付。
这里 Git 特别重要。因为 Codex 会批量改文件，没有版本管理，你很难判断它到底改了什么。
好的使用方式是：每次让 Codex 做一个相对独立的任务，完成后看 diff、跑测试、再提交。失败了就回滚，不要在一锅粥里继续修。
总结
新手想让 Codex 提效百倍，不是靠一句神级提示词，而是补齐这 8 种能力：
工作流封装、skill 发现、项目规则、产品规划、前端设计、审美判断、工具连接、验证回滚。
当这些能力配齐以后，Codex 就不再只是“帮你写代码的人”，而是一个能理解流程、遵守规则、调用工具、持续交付的 AI 工作系统。
