最近把 Codex CLI 和它那套 Skills 机制重新梳理了一遍顺手做了一个定制简历生成器。起因很简单我受够了每次投不同公司都要手动改简历更烦那种让 AI 直接“看着办”的改法——改完经常人设飘了、技能堆成山面试一聊就穿帮。所以我的诉求很明确让 AI 按我写死的规则干活把简历生成这件事变成一个可复用、可版本管理的标准流程而这正好是 Codex Skills 最擅长做的事。很多人看到 “Awesome Codex Skills” 这个说法第一反应是去 GitHub 上找现成的技能合集。社区里确实有人维护类似 awesome 列表把各种实用的 Skill 集中起来分享。但我的建议是你可以先下载别人的技能感受一下规范但真正高频使用的场景最好自己做。定制简历生成器就是一个绝佳的练手项目——它涉及数据管理、模板设计、指令编排、多场景输出一套走下来基本能把 Skills 的开发套路摸透。这篇文章我会把从环境准备到 Skill 开发、再到日常维护的完整路径写出来适合对 Codex 有一定了解、想把 AI 工作流固化下来的开发者参考。1. 为什么我用 Codex Skills 而不是普通 Prompt1.1 从“聊天辅助”到“固定技能”如果你只用普通对话让 Codex 帮你写简历那体验大概率是第一版还行第二版开始放飞自我第三版给你编出来一个根本没待过的公司。原因不是 Codex 笨而是普通 Prompt 没有任何约束结构模型只能基于上下文自由发挥。而 Skills 的本质是把“角色 规则 工作流 参考模板”打包成一个固定的技能文件。我在实际使用中最大的感受是Skill 相当于你给 AI 写了一份“员工手册”。它不再需要你每次都重复交代“只准用我给你的经历”“动词开头”“不要超过一页”而是通过SKILL.md里的结构化说明让 Codex 一读到这个技能就被强制进入对应的工作模式。这种方式比普通 Prompt 稳定太多尤其是简历这种对真实性要求极高的内容。有人可能会问那我用一套设计好的 Prompt 模板不也一样吗区别在于普通 Prompt 需要你每次粘贴、维护、更新而且一旦角色设定和业务规则太多对话长度一长就容易被“遗忘”。Skill 文件是独立存在的Codex 会在加载技能时把规则注入上下文你不需要重复粘贴只负责更新技能文件里的内容。长期用下来省事程度非常明显。1.2 简历生成器到底在解决什么我拆了一下自己的真实需求发现简历自动化不是简单地把内容输出成 Markdown 而已。我真正需要解决的是三个痛点第一数据源统一。我的基本信息、教育经历、工作项目它们散落在各种旧简历、LinkedIn、招聘网站里每次更新都要逐个改。我希望有一份唯一的简历数据源其他格式都是从这里“渲染”出来的。第二场景产物多样。同一个我投后端岗位、投技术管理岗、投英文公司简历侧重点完全不一样。后端岗突出技术栈和性能优化管理岗突出带团队和项目推动英文岗则需要完整的英文表达和海外格式习惯。我不可能维护三份独立简历那会是一场维护噩梦。第三风格可控又不过度包装。简历销售自己没问题但前提是“基于真实信息的合理表达”。AI 很容易把“参与开发”写成“主导架构升级”把一次小优化写成“性能提升 300%”。如果没有硬性约束生成出来的简历好看但危险。所以这个项目不是一个简单的“AI 帮你写简历”玩具而是一套带约束的“简历生成流水线”。它需要解决数据层、模板层、指令层三件事而这三件事恰好可以对应 Skills 的目录结构、模板资产和SKILL.md指令。这也是我觉得 Codex Skills 天生适合做这件事的原因。2. 准备环境安装 Codex 与认识 Skill 目录2.1 前置依赖与安装步骤在动手写 Skill 之前先把 Codex CLI 装好。我的本机环境是 macOS如果你用的是 Linux 或者 Windows 的 WSL操作基本一致。Codex CLI 官方推荐通过 npm 安装所以第一步是确认 Node.js 和 Git 已经就位。Node.js 版本建议 18 以上。你可以在终端里跑一下node -v git --version如果 Node.js 还没有安装去官网下载 LTS 版本即可这里不建议用太老的版本因为 Codex CLI 后续依赖的包可能对 Node 版本有要求。Git 是安装和更新 Codex 时的配套工具一般开发机都有。接下来全局安装 Codex CLInpm install -g openai/codex装完以后验证一下codex --version看到版本号就说明 CLI 装好了。然后需要登录你的 OpenAI 账号让 Codex 能调用模型接口codex login按提示在浏览器里完成授权即可。登录状态可以通过codex login status查看。这里提醒一句如果你之前已经装过旧版本建议先npm update -g openai/codex更新到最新版因为 Skills 功能在早期版本里并不完整用旧版容易出现识别不了SKILL.md的问题。2.2 Skill 目录与文件规范Codex 的 Skill 本质上就是一个包含SKILL.md文件的目录这个目录里还可以放模板、脚本、数据文件等辅助资源。Codex 扫描技能时有两种常见位置用户级目录~/.codex/skills/项目级目录.codex/skills/我自己的习惯是把通用的、所有项目都用得上的技能放在~/.codex/skills把跟特定代码库绑定的技能放在对应仓库的.codex/skills下面。简历生成器属于个人通用技能所以我放在~/.codex/skills/resume-generator/。目录结构大概是这样的~/.codex/skills/ └── resume-generator/ ├── SKILL.md ├── assets/ │ ├── resume_data.yaml │ └── templates/ │ ├── concise.md │ ├── detailed.md │ └── english.mdSKILL.md是这个技能的核心文件代码块开头有一段 YAML frontmatter里面声明技能的name和description。Codex 就是通过description来判断用户请求是否匹配某个技能所以这段描述要写得直白、动作导向、覆盖足够多的触发场景。比如--- name: resume-generator description: 根据用户的简历数据生成定制简历支持按岗位方向筛选经历、切换详细程度、输出英文版本适用于求职、跳槽、校招、英文简历等场景。 ---frontmatter 后面的正文是技能的完整指令写法比较自由但我强烈建议保留几个固定小节比如“目标”“输入”“工作流”“铁律”。这样 Codex 在解析的时候能够稳定地找到规则你后续维护也不会看花眼。这里多提一嘴社区里像 superpower skills 这类项目会把多个基础技能叠在一起实现类似“角色 工具集”的效果。如果你想让简历生成器更强大完全可以再给它挂上一个“Markdown 格式化技能”或者“排版检查技能”让多个SKILL.md协作。不过新手不建议一上来就做复杂组合先把单个技能跑顺再叠加。3. 定制简历生成器的核心设计3.1 数据层用 YAML 管理你的“素材库”我把整个技能的设计分成四层数据层、指令层、模板层、约束层。先讲数据层。很多人在简历生成上踩坑根源就是让 AI 从聊天记录里抽取个人信息这非常不可靠。正确做法是先准备一份结构化的简历数据文件Skill 只负责读取和渲染不做任何猜测。我用 YAML 作为数据格式因为它的可读性比 JSON 好而且缩进结构天然适合表达嵌套关系。下面是一个简化后的resume_data.yaml示例personal: name: 张三 phone: 13800000000 email: zhangsanexample.com city: 上海 title: 后端工程师 summary: 5年后端开发经验专注于高并发服务、分布式系统与云原生架构具备从0到1搭建系统以及带领小型团队的经验。 skills: - name: Go level: expert - name: Kubernetes level: advanced - name: PostgreSQL level: advanced - name: Redis level: advanced experiences: - company: 某科技公司 period: 2022.06 - 至今 role: 高级后端工程师 highlights: - 主导订单中台重构支撑日均千万级请求接口平均延迟降低40% - 设计多级缓存方案将热点数据查询P99从120ms优化到35ms - company: 某互联网公司 period: 2019.07 - 2022.05 role: 后端工程师 highlights: - 参与用户增长系统的开发实现日活数据实时统计 - 推动服务容器化改造部署效率提升约3倍 projects: - name: 分布式任务调度平台 role: 核心开发者 description: 自研分布式任务调度系统支持秒级定时任务与失败重试 highlights: - 基于etcd实现任务选主与故障转移 - 调度集群支持水平扩容至千台级别 education: - school: 某某大学 degree: 本科 major: 计算机科学与技术 period: 2015.09 - 2019.06这里有几个细节需要注意。第一highlights下面尽量写已经包含量化结果的事实数字必须真实因为在后面的约束层我会禁止 AI 新增数字。第二skills给一个等级字段方便 Skill 根据不同岗位调整技能顺序。第三数据文件里不要放描述性的“自我评价”长文那应该在生成阶段根据岗位动态生成否则容易产生矛盾。把简历数据从对话里抽离出来还有一个额外好处你可以直接把这个 YAML 文件纳入版本管理每次更新都留痕心里有底。3.2 指令层SKILL.md 的工作流编排数据文件只是素材真正让 Codex“动手”的是SKILL.md里面的指令。我的经验是不要只写“帮我生成简历”这句话那等于没写。你需要把整个流程拆成若干步骤并用明确顺序告诉 Codex 先做什么、再做什么。我设计的流程可以概括为五步读取数据 - 解析岗位方向 - 筛选经历 - 按模板填充 - 输出修改摘要。下面是一份核心工作流的示例## 工作流 1. 读取 assets/resume_data.yaml解析出个人信息、技能清单、工作经历、项目经历、教育经历。 2. 根据用户指定的目标岗位判断本岗位最关心的技术栈与能力维度。 3. 从工作经历与项目经历中筛选最相关的3-5条按照匹配度从高到低排序不相关经历可以保留标题但简写。 4. 根据用户选择或默认配置选定模板模板文件位于 assets/templates/ 目录。 5. 将筛选后的内容填入模板所有经历描述的动词开头尽量保留数据中的量化指标。 6. 输出简历正文最后以“修改摘要”的形式输出50字以内的调整说明。写工作流的时候要特别注意“可验证性”。比如第 3 条里我用了“3-5条”这就比“适量”要明确得多。再比如“动词开头”Codex 对这种具体指令的执行效果远超“写得专业一点”这种模糊表达。指令越容易验证输出越稳定。3.3 模板层三种简历风格怎么组织模板层决定了简历的最终长相。我这里准备了三个模板文件concise.md适合大多数互联网公司投递强调一页内浓缩信息detailed.md适合项目经历复杂、需要展开描述的场景english.md则用英文输出适配外企岗位。每个模板文件的本质是一个 Markdown 骨架里面用类似“变量占位”的方式标注内容位置。特别说明的是Codex 并不像传统模板引擎那样做真正的变量替换它更像“参考这个结构来写”。所以模板写清楚层级关系就够了。以concise.md为例# 姓名 - 目标职位 - 电话xxx - 邮箱xxx - 城市xxx ## 个人简介 两到三句话突出最匹配目标岗位的年限、核心方向与代表性成果。 ## 核心技能 按岗位相关度排序列出 5-8 项技能格式为“技能名熟练度”。 ## 工作经历 ### 公司名时间段 - 职位 - 动词开头的成果描述优先保留量化数字 - 每家公司最多列 3 条 ## 项目经历 ### 项目名 - 角色 - 项目背景一句话 - 你的贡献一到两条 ## 教育经历 学校 | 专业 | 学位 | 时间段注意我在模板里穿插了对 Codex 的“格式提示”比如“每家公司最多列 3 条”这样它填充内容时心里有数。如果你有一个特别满意的 PDF 版式也可以用 HTML 模板放进去但 Markdown 最通用、最容易排查问题所以我建议第一版先用 Markdown。3.4 约束层防止 AI 过度美化这是整份 Skill 里最不能省的部分。AI 生成简历最大的风险是“幻觉”尤其当你的简历数据文件里有少量空白或模糊描述时模型会非常主动地帮你脑补。我的做法是在SKILL.md里单列一个“铁律”小节用最直接的禁止性语句写清楚不能做什么。我目前的铁律包括这几条严禁新增数据源中不存在的公司、学校、项目、技能。严禁夸大年限、职级与业绩数字所有数字必须来自resume_data.yaml。如果某段经历缺少量化数据直接写“待补充”并列出缺失字段不要自己编造。中文简历不超过 1 页 A4英文简历不超过 1 页 Letter。输出格式必须是用户指定的模板格式不得自行发明段落结构。这些铁律其实就是在给模型画“安全红线”。你会发现在加了这个约束之后简历的真实性有了质的提升。每次拿到输出我只需要核对“修改摘要”和原始数据文件整个人都轻松了。3.5 多场景输出与自定义指令除了上面四个固定层我还会在SKILL.md里预留一个“自定义指令”小节用来处理一些临时需求比如“强调我的 Go 语言能力”“弱化教学经历”“针对某家公司的岗位描述进行关键词匹配”等等。Skill 之所以比固定模板灵活就是因为它允许你在会话中追加额外要求而这些要求会和 Skill 里的规则合并执行。在自定义指令里我比较推荐加一条“将目标公司的 JD 粘贴给 Codex”。Codex 可以基于 JD 里的关键词重新排序技能、重写项目描述的重点甚至微调个人简介。这个方法比单纯“生成简历”效果好非常多因为它让 AI 的筛选逻辑有了真实的依据而不是靠猜。4. 实操从零构建一个简历生成 Skill4.1 创建目录与 SKILL.md 完整示例下面我给出一个可以直接照着用的完整SKILL.md示例。你可以根据自己的情况进行修改但结构建议保留。因为 Codex 对这种分节式指令的解析稳定度最高。--- name: resume-generator description: 根据用户的简历数据生成定制简历支持按岗位方向筛选经历、切换详细程度、输出英文版本适用于求职、跳槽、校招、英文简历等场景。 --- # 简历生成器 ## 目标 基于 assets/resume_data.yaml 中的真实信息生成一份符合用户要求的简历。不得编造任何经历、指标、公司或职位信息。 ## 输入 - 用户提供目标岗位、简历风格concise / detailed / english、目标公司名称与 JD可选。 - 数据文件assets/resume_data.yaml所有信息以该文件为准。 ## 工作流 1. 读取 assets/resume_data.yaml解析出个人信息、技能清单、工作经历、项目经历、教育经历。 2. 根据用户指定的目标岗位判断本岗位最关心的能力维度。 3. 从工作经历与项目经历中筛选最相关的3-5条按照匹配度从高到低排序不相关经历可以保留标题但简写。 4. 根据用户选择或默认配置选定模板模板文件位于 assets/templates/ 目录。 5. 将筛选后的内容填入模板所有经历描述使用动词开头尽量保留数据文件中的量化指标。 6. 输出简历正文最后以“修改摘要”的形式输出50字以内的调整说明。 ## 模板选择 - 默认使用 assets/templates/concise.md - 当用户提到“详细版”“项目多”或“需要两页”时使用 assets/templates/detailed.md - 当用户提到“英文”“外企”“English”时使用 assets/templates/english.md ## 铁律 - 严禁新增数据源中不存在的公司、学校、项目、技能。 - 严禁夸大年限、职级与业绩数字所有数字必须来自 resume_data.yaml。 - 如果某段经历缺少量化数据直接写“待补充”并列出缺失字段。 - 中文简历不超过 1 页 A4英文简历不超过 1 页 Letter。 - 输出格式必须严格遵循选定的模板结构。 ## 自定义指令 - 用户可以在对话中追加指令例如“强调某技能”“弱化某段经历”“按照 JD 调整技能排序”。 - 如果用户提供了 JD先提取 JD 中高频出现的关键词再据此重排技能与经历描述的优先级。第四部分是实操要确保一步步。我会给出步骤创建目录写入 SKILL.md编辑 resume_data.yaml测试调用4.2 让 Codex 调用这个 Skill目录和文件都准备好之后调用方式很简单。打开终端在任意目录启动codex然后在对话里输入类似这样的指令使用简历生成器生成一份针对“高级 Go 后端开发工程师”岗位的中文简历。Codex 看到“简历生成器”这几个字会根据SKILL.md的description自动匹配到刚才新建的技能然后把你带到对应的指令环境里。如果它没有识别到可能需要手动检查一下技能存放目录是不是在~/.codex/skills下面。我第一次测试时最激动的瞬间就是看到它真的从resume_data.yaml里读数据而不是问我“你的工作经验是什么”。这说明技能路径已经生效。之后我再追一句“换成英文版”它也能正确拉取english.md模板重新输出。整个过程大概 20 秒过去我手动改英文简历要花半小时。这里有个小技巧如果你想让 Codex 每次都默认读取某个数据文件可以提前在对话里说清楚“使用我的标准简历数据”。但如果你已经把路径写死在SKILL.md的工作流里这句反而冗余说了也不影响。4.3 多场景生成与后续维护第一次生成成功之后你的简历数据文件、模板文件和 SKILL.md 已经形成了一个小生态。日常维护的重点不再是“改简历”而是“改数据”。比如项目多了一个新亮点你只需要更新resume_data.yaml里的highlights之后任何场景重新生成都会自动带上。我还会把整个~/.codex/skills/resume-generator目录扔进 Git 仓库进行版本管理。每轮求职季开始前打一个 tag比如v2025.01万一需要回看当年投了哪些重点内容直接切版本。简历数据反而不容易丢也不用再忍受十几个“最终版”“最终最终版”的 Word 文档。多场景生成的另一个扩展是你可以让 Codex 根据同一个数据文件生成求职信、作品集简介、面试自我介绍甚至领英简介。这些内容虽然格式不同但底层依赖的素材完全一样。只要在SKILL.md里把“输出类型”作为一个可选项其他指令和工作流稍微调整就能一鱼多吃。我目前已经把求职信生成也挂到了同一个 Skill 下面效果不错。5. 常见问题与排查技巧实录5.1 Codex 识别不到 Skill 怎么办这是我被问得最多的一个问题。现象是你在对话里输入“使用简历生成器”Codex 像没听见一样继续普通对话。排查顺序建议如下第一步看目录是不是放错了Codex 默认只扫描~/.codex/skills和.codex/skills其他目录不会被发现第二步看SKILL.md的 frontmatter 是否规范比如description是否缺失或写得太抽象第三步看有没有出现多个同名name如果用户级和项目级同时存在同名技能可能会出现加载冲突。还有一个容易被忽略的点如果你在添加 Skill 之前就已经开启了当前的 Codex 会话那么它可能不会立刻识别新技能。我遇到这种情况时一般直接重启一个对话速度最快。对比下来新技能识别问题大部分是路径或 frontmatter 问题跟模型本身关系不大。5.2 生成结果格式不稳定怎么处理Codex 有时候会发挥过头明明指定了concise.md模板它还是给你加一个“自我评价”模块或者把项目经历写成了散文。我的解决方案是在模板里直接加入“反例”或“禁止项”。比如模板底部可以追加一行禁止输出自我介绍式长段落、自我评价、与岗位无关的爱好和证书。这类负面清单通常比正面描述更加有效。另一个办法是在模板里给一个“示例输出”让 Codex 模仿示例的结构。示例不需要完整给一小段就行模型能很快对齐格式。这也是我用过之后觉得最稳定的一招。5.3 输出内容过长或过短怎么办简历长度失控也很常见。尤其是项目经历写太多、工作经历写太细最后变成两页半小作文。我在SKILL.md的铁律里已经写死了页数限制但实际情况是模型对“一页”的感知很弱。我后来改为更明确的“字数控制”中文简历正文控制在 800 到 1000 字英文控制在 450 到 600 词。这个数字是 A4 单页比较合理的估算范围。如果你觉得自己的模板字体或行距不同可以自己在SKILL.md中调整数字。但核心思路是用可计算的数字替代模糊的“简短”“精炼”Codex 的服从度会好很多。5.4 我踩过的其他坑与应对经验最后分享几个实践中总结的小经验。第一不要把敏感个人资料写进数据文件再发给 Codex。虽然 Codex 的数据使用有相关说明但简历这种包含电话、邮箱、教育经历的信息我还是建议只用脱敏后的测试数据做开发真正要生成简历的时候再换成完整数据并在使用后及时清理会话。不要因为图省事把隐私数据长期放在测试环境里。第二给每个岗位生成时尽量在对话中附带 JD。这个习惯改变了我整个使用体验。以前我靠自己的理解让 Codex 筛重点很多时候筛得不对现在直接把 JD 丢进去让 Codex 提取高频关键词技能排序和经历描述立刻变得有针对性。JD 里出现 5 次“高并发”我的简历里就不会只字不提。第三Skill 文件不要一次写得过于复杂。刚开始做一个能跑通的 MVP只覆盖“中文简洁版”一种场景就够了。跑通之后再加英文模板、再加详细版、再加求职信。如果你一开始就把所有功能塞进SKILL.md出了问题大概率不知道是哪个环节写错了。我自己拆过好几次后来发现最稳的开发路径是“最小可用技能 - 验证 - 增量扩展”。第四注意自己的 Codex 登录状态。偶尔会出现auth token is unavailable之类的报错一般重新执行codex login就能解决不用慌张。这套定制简历生成器做下来我个人最满意的地方是它把“求职季加班”变成了“更新一条数据记录”。我现在更新简历的流程就是改resume_data.yaml然后让 Codex 跑一遍目标岗位版本整个过程不超过两分钟。而且因为我严格控制了数据源简历再也不会出现“AI 帮我发明了一段经历”的史诗级事故。其实这套思路也不局限于简历生成周报、合同初稿、项目验收文档、发布说明几乎任何“格式固定 内容来自个人记录 需要多场景输出”的事情都可以做成一个 Skill。如果你也折腾出了自己的技能欢迎一起交流至少我现在是彻底离不开这套流程了。
