逛GitHub上那份awesome-codex-skills仓库的时候我的第一反应是好东西真多。第二反应是能直接拿来用的其实不多。这倒不是社区Skill质量不行而是这类文件天然带着作者的工作习惯别人整理的内容未必搭得上你的流程。“定制简历生成器”就是典型的例子——信息结构、措辞风格、输出格式每个人都不一样。与其到处找现成方案不如自己动手写一个把简历生成的完整流程固化成一个Codex Skill。这篇文章就是我的完整搭建记录从Skills机制拆解到落地代码再到问题排查希望能给你一份能直接抄作业的参考。如果你还没接触过Codex Skills简单说它就像给AI助手提前装好的“操作手册”。你告诉它要做什么它按照技能文件里写好的步骤和约束执行。我做的这个Skill输入是你的个人资料和岗位信息输出是一份排版整齐、重点突出的简历。整个过程可反复使用每次投递新岗位只需要更新岗位信息AI会自动调整描述重点。涉及的核心问题只有一个怎么把“我平时是怎么改简历的”这件事翻译成Codex能稳定执行的文件。1. 项目定位为什么做“定制简历生成器”1.1 简历的痛点从来都在“改”上我观察过身边不少开发者和产品经理简历基本有三类问题。第一类是格式不统一同一个人的经历有的版本是Markdown有的版本是Word还有的直接从招聘网站导出一份PDF每次投递都要重新排版。第二类是信息散落项目经历散在GitHub、技术博客、本地文档里真正要更新简历的时候东翻西找经常漏掉半年前做过的一个关键项目。第三类是描述不精准同一个项目投技术岗时该强调性能指标投管理岗时该强调团队协调简历上却只有一套固定说法。这些痛点的核心不是“写不出一份简历”而是“每次都要重写一遍”。Codex Skills恰好能把“重写”这个流程自动化简历数据源只维护一份岗位信息变化时由AI按规则重新组织语言和结构。这个思路最早我是用普通对话实现的但每次都要把长长的工作经历规范和输出格式要求粘贴一遍效率太低而且模型偶尔会“忘掉”你前面提过的约束。于是我把规则全部挪进SKILL.md用文件代替对话上下文问题一次性解决。1.2 Skill方案和模板网站、直接对话的差别模板网站的简历生成器我也用过特点是快缺点是上限低。你很难让它针对特定岗位调整项目描述顺序更难把LaTeX级别的排版控制权拿回来。这类工具是一锤子买卖交付完就结束简历里的信息更新了下次还得重新填一遍表单。而用Codex Skills做的生成器本质上是一个“持续成长的自动化流程”数据源在Git仓库里维护Skill文件在配置目录里管理AI负责中间的组织与渲染工作。每次投递都是对流程的一次验证发现问题就改Skill文件迭代不需要重找工具。至于“直接跟ChatGPT对话生成简历”问题在于上下文不固定。这次对话里你要重新解释工作经历格式、项目描述风格、投递岗位要求下次对话又要重复一遍而且每次生成的结果风格可能都不一样。Skill把这一切固定在文件里AI每次自动加载省掉的是反复描述需求的时间换来的是输出质量的一致性。这也正是Skills机制相对普通提示词的核心价值。1.3 适合谁来参考这篇指南适合这么几类人一是已经装了Codex CLI、想知道Skills怎么真正落地的人二是对简历有要求、愿意花一点时间把流程自动化的人三是对“AI自主完成多步骤任务”感兴趣想通过一个具体案例理解Skill机制的开发者。建模比赛论文排版、项目周报撰写、作品集整理这些场景和简历生成是同一套思路读完你完全可以迁移过去。2. Skills机制拆解先搞懂它怎么工作2.1 Skill本质是一本“操作手册”要理解Codex Skills可以先把它想象成新员工入职手册。公司招人不会只说一句“你去干活”而是给一份手册里面有流程、有规范、有示例。Skill对Codex来说就是这份手册它放在固定目录下里面有一个核心文件叫SKILL.md用自然语言写清楚技能的目标、适用范围、执行步骤和注意事项。和普通提示词的区别在于提示词是临时的、消耗在对话上下文里的用完就丢Skill是持久的、落在文件系统里的可以被多个对话加载可以进Git做版本管理也可以分享给其他人。这有点像把一段频繁使用的代码从脚本里抽出来封装成独立模块——一次编写多处复用。对经常处理重复性文档工作的人来说掌握这个机制比记住几个提示词更有价值。2.2 一个Skill的标准目录结构最常见的Skill结构大致是这样~/.codex/skills/resume-builder/ ├── SKILL.md # 技能主文件必填 ├── templates/ # 输出模板 │ ├── modern.md │ └── minimal.tex ├── examples/ # 示例数据帮助AI理解格式 │ └── sample-profile.yaml └── scripts/ # 可选辅助脚本 └── render.py目录名就是技能名SKILL.md里写规则其他文件都是规则的补充资源。Codex遇到与Skill匹配的任务时会把SKILL.md的内容作为上下文注入给模型必要时还能读取templates和examples里的文件作为参照。关键在于SKILL.md写得越清晰AI的执行就越可控。你要是只写一句“帮我生成简历”那输出质量基本靠运气写成上面这种带步骤带约束的形式输出就稳定得多。2.3 触发机制什么时候会加载根据我的实测Codex判断是否使用某个Skill主要看用户请求涉及的任务是否落在技能覆盖范围内。所以我在SKILL.md里专门写了一段“触发条件”告诉模型什么场景下必须调用它。不同版本的Codex对Skill的加载策略有差异但把触发条件写清楚命中的概率总是更高。提示别指望AI主动猜测你的意图。在Skill文件里明确写“当用户要求生成、更新、优化简历或要求根据JD修改简历时必须使用本技能”效果远好过一个含糊的描述。2.4 为什么Skills适合“简历”这类流程化任务简历生成有几个特点步骤固定收集信息、分析岗位、组织内容、渲染排版、规则明确时间倒序、量化结果、STAR描述、输出可预期Markdown、LaTeX或PDF。这种任务非常适合Skill化。它不像写小说那样需要发散也不像调试代码那样需要临场应变更像“用一条流水线把原材料加工成产品”而流水线的参数是可以预先定义的。我当时顺手试过一个扩展方向把LaTeX排版规范也写进Skill。AI生成的不再是通用HTML而是直接给出一份符合学术模板风格的TeX源码编译出来就是排版干净的双栏简历。这个扩展点放到第4章细说但它已经证明了一件事——只要任务里有“固定流程固定规则固定输出”这三个特征就值得做成Skill。3. 实操从零搭建定制简历生成器3.1 第一步设计Skill目录与全局配置我先规划了目录结构放进Codex的全局Skills目录。这样在任何项目目录下启动Codex都能调用不用每个项目复制一份。创建目录的命令很简单mkdir -p ~/.codex/skills/resume-builder/{templates,examples,scripts}这里有个选择要注意Codex同时支持全局目录和项目级目录一般是项目下的.codex/skills加载时优先项目级。我的经验是简历数据往往和工作目录不在一起Skill本身也跟具体项目无关所以放全局更合适。如果你只打算在某个特定项目里用放项目级也行只是换设备或者换项目时别忘了同步。这个优先级规则也是第5章排查“Skill没生效”的重要线索。3.2 第二步编写核心的SKILL.md这是最关键的一步。我直接给出我的版本你复制后改一改就能用# Resume Builder Skill ## Purpose 根据用户输入的个人资料YAML格式和目标岗位JD生成一份定制化的简历。 输出支持Markdown和LaTeX两种格式默认输出Markdown。 ## Trigger Conditions - 用户要求“生成简历”“更新简历”“根据JD优化简历”“投递XX岗位”时触发。 - 当用户给出岗位链接、JD文本或仅提供岗位名称时本技能应主动询问或推断岗位关键词。 ## Input Requirements 1. 个人资料文件必须是YAML格式字段包含basic、education、experience、projects、skills、certificates。 2. 岗位信息用户可直接粘贴JD文本或提供岗位名称由AI补充常见要求。 ## Workflow ### Step 1: 解析输入 - 若用户未提供个人资料路径默认查找当前目录下的profile.yaml。 - 校验必填字段缺失时列出缺失项不猜测。 ### Step 2: 分析JD - 从JD中抽取高频技能词、职责动词、行业术语。 - 将抽取结果与个人经历进行匹配标注每一项经历与岗位的关联度。 ### Step 3: 简历改写 - 按时间倒序排列经历。 - 每个项目/经历描述采用STAR结构情景、任务、行动、结果。 - 结果部分必须量化例如“将接口响应时间从800ms优化到120ms”。 - 根据JD调整项目排序与岗位最相关的内容往前放。 ### Step 4: 渲染输出 - 默认渲染为Markdown文件名为{姓名}_{岗位关键词}_Resume.md。 - 若用户指定LaTeX版本输出.tex文件并调用scripts/render.py检查括号和转义符。 - 不编造不存在的教育背景和公司信息。 ## Constraints - 严禁虚构任何工作经历、教育背景、项目成果。 - 简历长度控制在一页A4以内Markdown按约800字中文以内把握。 - 不修改YAML源文件只读取。 - 生成结束后给出3条针对该岗位的修改建议。 ## Examples - examples/sample-profile.yaml 为基础数据样例可参考字段格式。我解释一下为什么这么写。Purpose段让AI快速理解技能方向。Trigger Conditions解决“什么时候必用”的问题。Workflow是整个Skill的灵魂它把生成简历拆成了解析、分析、改写、渲染四个步骤每步都有明确动作与约束。Constraints段是踩过坑之后才加的特别是“不编造经历”和“不修改源文件”这两条能有效防止模型过度发挥。Examples段则给AI一个具体参考当YAML数据字段不够规范时它能参照样例自行理解。3.3 第三步设计YAML数据模板简历数据源是最重要的资产我建议放进Git仓库维护。示例结构如下basic: name: 张三 title: 高级前端工程师 phone: 138-0013-8000 email: zhangsanexample.com location: 上海 github: https://github.com/zhangsan blog: https://zhangsan.dev education: - school: 某某大学 degree: 本科 major: 计算机科学与技术 start: 2012-09 end: 2016-06 experience: - company: 某互联网公司 role: 前端工程师 start: 2020-03 end: 至今 summary: 负责商家中台的前端架构与团队协作 achievements: - 主导灰度发布平台重构将版本发布耗时从平均30分钟缩短至8分钟 - 推动组件库建设沉淀30通用组件团队开发效率提升40% projects: - name: 低代码表单引擎 role: 核心开发者 description: 面向内部业务的动态表单解决方案 highlights: - 设计了JSON Schema驱动的表单协议支持20控件类型 - 通过动态渲染优化首屏加载体积减少42% skills: - category: 前端 items: [TypeScript, React, Vue, Webpack] - category: 工程化 items: [CI/CD, Monorepo, 性能优化]字段含义不难理解。有一点值得专门提醒achievements和highlights我设计成列表而不是长文本段落。这样AI改写的时候是以每一条为单位处理比让它从一大段自然文字里抽取信息更精准。这是我实际测试总结出来的经验——数据粒度越细AI越不容易漏信息输出结果也越接近你的原始表述。3.4 第四步选择输出模板我的Skill支持Markdown和LaTeX两种渲染。Markdown适合快速投递和在线粘贴LaTeX适合对排版有执念的场合。Markdown模板定义得很简单# {name} {title} | {location} | {phone} | {email} ## 教育背景 - {school} · {degree} · {major} ({start} - {end}) ## 工作经历 ### {company} · {role} ({start} - {end}) - {achievement_item} ## 项目经历 ### {project_name} · {role} - {highlight_item} ## 技能 - **{category}**{items}LaTeX模板就不全量贴出来了重点说几个我踩过的坑。一是中文简历必须指定xelatex配合ctexart文档类否则编译出来全是乱码二是模板里滥用加粗命令会影响中文排版应该靠字号和间距控制层次三是TeX转义符必须单独处理所以我写了scripts/render.py在生成.tex之后先自动检查一遍括号匹配和特殊字符有问题就直接反馈给AI修改。对不熟悉LaTeX的人这一步能省下大量手工调错时间。3.5 第五步接入Codex并完成首次调用把目录放到skills路径后我在工作目录里放了一份profile.yaml然后启动Codex输入“根据这份简历数据生成一份前端岗位简历JD是负责PC端后台系统研发技术栈包括React、TypeScript要求有性能优化经验。”实测结果令人满意。AI自动读取了YAML抽取JD里的关键词“React”“TypeScript”“性能优化”把低代码表单引擎项目排在更靠前的位置并用STAR结构改写了高亮条目。最终生成的文件名自动成了“张三_前端工程师_Resume.md”。第一次跑通时我就意识到这个Skill真正省下的不是“写简历”的时间而是“每次投递前重新整理和调整简历”的重复劳动。原来一个下午的体力活压缩成了十几秒的等待。4. 进阶让简历生成器更懂“岗位匹配”4.1 岗位JD解析从“读JD”到“提取关键词清单”基础版Skill已经够用但要提升匹配度得在JD分析上下功夫。我的做法是在SKILL.md的Step 2里追加一项要求AI输出“岗位关键词清单”并把清单与个人技能做交集运算。比如算法岗JD里出现“TensorFlow”“模型压缩”Skill会要求AI检查profile.yaml里有没有对应条目没有的话在生成结果末尾提示“建议补充相关经历”。这一步相当于给AI增加了一个“差距分析”环节。它不只是把简历翻出来重排而是告诉你你离这个岗位还缺什么。我实际投递时靠这个提示补过项目关键词面试邀约率有肉眼可见的变化。对不怎么做求职的人来说可能感知不强但常年换工作或者跨方向转型的人这一条真的能救命。4.2 STAR结构化改写把“做了某事”变成“拿到结果”很多人的简历问题不是没经历而是描述太弱。“负责登录模块开发”这种表述在HR眼里约等于没写。我在Skill里强制要求STAR结构并给AI定了一条改写规则动作要具体结果要量化技术方案要点名。同样一条经历改写前后差别很大改写前负责登录模块开发。改写后设计并实现基于OAuth2.0的统一登录模块支持手机号和第三方扫码两种方式上线后登录成功率稳定在99.9%以上。这种改写不是AI凭空编造而是从YAML里的高亮条目提取细节后重新组织句子。前提是数据源里你得真的记了这些信息。这也是为什么我反复强调数据结构要细——没有细节再强的模型也写不出有说服力的文字。4.3 多版本简历管理一份数据N份简历投不同公司、不同方向简历需要不同版本。我在Skill里增加了一个输出规则文件名包含岗位关键词防止覆盖。进一步我还在数据源里增加了一个可选字段targets用来标记某些经历只能用于特定岗位类型。比如给算法岗的简历不展开前端组件库经历给全栈岗则保留。这个“按目标过滤”的逻辑写在SKILL.md里## Optional Filtering 当个人资料中存在targets字段时只输出包含当前岗位关键词或all标记的经历条目。这样一份profile.yaml可以同时服务算法岗、后端岗、全栈岗AI在生成时会自动过滤不相关内容。我现在维护一份数据源半年内投过三个方向的岗位简历主体数据结构基本没动过变的只是每次生成的侧重点。4.4 扩展把同一套思路复制到其他场景简历生成器这个Skill一旦跑通你会发现它的架构可以平移到很多地方。例如竞赛论文排版Skill输入实验数据和图表说明输出LaTeX格式的论文初稿周报生成Skill输入任务列表输出按重要性排序的上周总结和下周计划作品集整理Skill输入项目链接和截图输出带统一封面的演示文稿。建模比赛时我就复用同样的思路写过一个论文排版Skill把学校模板的页眉、字体、章节格式全部写进SKILL.mdAI出初稿之后编译一次就能通过大部分格式要求。这和简历生成的底层逻辑完全一致模板与控制规则前置AI在限定空间内做内容组织。你已经会写简历生成器就等于会写这一类所有工具。5. 常见问题与排查实录5.1 问题速查表用了一段时间我把遇到过的典型问题和解决方案整理成了一张表症状可能原因解决方案请求与简历无关时也触发SkillTrigger Conditions写得宽泛收紧触发条件限定“简历”“JD”“投递”等关键词生成的简历格式错乱模板占位符与数据字段名不匹配检查templates模板与YAML字段统一命名格式中文长简历超过一页长度控制不生效明确写“中文正文约800字以内”并让AI删除低相关条目Skill完全没有生效目录位置或SKILL.md文件名不对确认路径在全局或项目skills目录文件名严格为SKILL.md输出中出现虚构内容缺少“不编造”约束在Constraints中加入“严禁虚构经历、数据、公司信息”生成文件覆盖上一版本缺少按岗位命名的规则在Workflow中强制文件名为“姓名_岗位关键词_日期”这张表不是凭空写的每一项我都实际踩过。特别是“虚构内容”那个问题早期我的Skill没写约束AI在处理空缺字段时居然会补充“某公司高级工程师”这类虚构信息差点出事。加上硬性约束之后AI的行为立刻规范了很多。写任何Skill都一样约束阶段宁可写得严一点。5.2 环境与配置类问题有几个高频环境问题值得专门提。一是提示本地代理切换失败通常出现在切换网络环境之后重启Codex CLI一般能恢复还不行就检查系统HTTP代理环境变量是否有旧配置残留。二是提示auth token不可用这是登录态失效重新执行登录流程即可。三是想接入第三方模型服务比如DeepSeek等需要在配置文件里正确设置base_url和api_key注意不要与本地代理设置冲突。这些问题本身和Skill无关但如果你在Windows桌面版上使用还会偶尔遇到“正在重新连接”的提示。我的经验是直接重启进程比反复等待更省时间对需要连续调用Skill的场景也更友好。环境问题往往不是代码问题别在配置文件里浪费太多时间。5.3 排查Skill未生效的结构化流程如果你确认Skill没生效别急着重装按顺序排查检查目录名和SKILL.md文件名是否完全符合规范大小写也要注意。检查SKILL.md头部是否有Purpose段描述是否清晰明白。启动Codex后输入一个与Skill相关的极简请求比如“生成一份简历”看AI是否引用到Skill。如果仍未生效查看Codex日志里Skill的加载记录确认路径是否正确。最后再简化Skill目录只保留SKILL.md一个文件排除辅助文件的干扰。这套流程能解决九成以上的加载问题。剩下的一成多半和版本有关Codex升级后部分Skill路径规则会变化需要同步调整目录结构。保持关注更新日志比反复重装更有效。5.4 模型选择与Token限制的取舍生成简历这类任务上下文不算太长但如果你把整个SKILL.md、模板、YAML数据、JD全文一次性塞进去长一点的岗位描述很容易冲高Token用量。我自己的做法是SKILL.md控制在150行以内模板控制在50行以内YAML数据控制在300行以内。超出这个量级Token开销就不太划算了而且模型处理超长上下文时注意力会被稀释反而容易忽略关键约束。在模型选择上日常用默认模型生成简历完全够用追求更精细的措辞调整时可以在Skill里加一个“精修模式”要求AI对每一条经历给出两版措辞供选择。实测下来这个模式对面试准备很有帮助比一次性生成更深入。核心原则是数据量控制好模型选对档位输出质量就有保证。我个人在实际操作中的体会是用Codex Skills做定制简历生成器最大的收获不是那份简历本身而是我重新梳理了一遍自己的职业信息。数据源在GitHub上维护Skill文件在本地备份每次投递都像在跑一条成熟的流水线。这个项目做出来之后我养成了一个习惯——每完成一个项目就顺手补进YAML等真要投简历的时候打开Codex敲一句“生成简历并按JD优化”十几秒后拿到的就是一版有重点、有量化、格式统一的初稿。最后再分享一个小技巧第一版Skill别追求大而全先只做Markdown输出跑通流程之后再去折腾LaTeX和多版本管理。Skill的迭代和写代码一样先让它跑起来再慢慢优化。定制简历生成器只是起点同样的思路放到论文、周报、作品集上都会很顺手。