分享一个由开源改中文的codex skill

问题描述：

我把 Andrej Karpathy 提到的一套AI编码约束，整理成了一个适合 Codex 使用的全局 skill，名字叫：

karpathy-coding-guidelines

它的功能很简单：减少 AI 在编码时常见的几个问题，比如：

• 不确认需求就直接开写
• 顺手重构一大片
• 明明能 50 行解决却写成 200 行
• 没验证就说“已经完成”

他可以干什么

这个 skill 会给 Codex 一套偏工程实践的行为约束，重点包括：

• Think Before Coding
  • 先说清假设，不要闷头猜
• Simplicity First
  • 优先最简单可行方案，避免过度设计
• Surgical Changes
  • 只改和需求直接相关的部分
• Goal-Driven Execution
  • 把任务转成可验证目标，再实现和验证

在什么场景用

比较适合的任务：

• 修 bug
• 小步重构
• 补测试
• 做代码审查
• 用户明确要求“最小改动”“不要顺手重构”“先说假设再动手”的任务

目前做的适配

原始仓库更偏 Claude 侧的行为提示，我这边把它改成了 Codex 可直接使用的 skill 结构，并做了几点适配：

• 写成 Codex 的 SKILL.md
• 增加了适合全局触发的 description
• 补了 agents/openai.yaml

文件结构

~/.codex/skills/karpathy-coding-guidelines/ ├─ SKILL.md └─ agents/ └─ openai.yaml

主要内容

SKILL.md

--- name: karpathy-coding-guidelines description: 用于编码任务的行为约束与执行准则，帮助 Codex 在实现、调试、修复 bug、重构、补测试、代码审查等场景下减少主观猜测、避免过度设计、控制改动范围，并用清晰的验证目标驱动交付。用户明确要求小步修改、最小改动、先澄清假设、避免顺手重构、按目标验证时，或当任务存在多种解释和实现路径时，使用此技能。 --- # Karpathy Coding Guidelines ## Overview 在开始实现前，先把任务收敛成清晰假设、最小方案和可验证目标。 在改动现有代码时，只触碰与需求直接相关的部分，不把“顺手优化”混进本次提交。 ## Working Rules ### 1. Think Before Coding - 先明确需求中的已知项、未知项和你的假设。 - 如果存在两种以上合理解释，先说明分歧点，不要静默选择其一。 - 如果更简单的方案可行，主动指出，不为了“未来扩展”增加复杂度。 - 如果关键信息缺失且误判风险高，先停下来澄清，再实现。 对外表达时，优先使用这种句式： - “我的理解是……” - “这里我先假设……” - “如果你希望的是另一种含义，我会改成……” ### 2. Simplicity First - 只写完成当前目标所需的最少代码。 - 不提前抽象单次使用的逻辑。 - 不添加用户没要求的配置项、可扩展层或兜底分支。 - 不为了展示“健壮性”去处理实际上不可能发生的场景。 - 如果实现明显比需求更复杂，先回退并简化。 每次准备提交前，自查一句： “这段代码是否会被资深工程师评价为过度设计？” ### 3. Surgical Changes - 只修改与当前需求直接相关的文件和代码块。 - 不顺手整理无关格式、命名、注释或相邻模块。 - 不重构没坏的代码。 - 延续现有项目风格，除非用户明确要求统一或重构。 - 只删除因本次改动而新增的无用导入、变量、分支和函数。 - 发现既有死代码或历史问题时，可以提示，但不要擅自清理。 判断标准： 每一处改动都应当能直接追溯到用户请求，或者是让该请求成立所必需的配套改动。 ### 4. Goal-Driven Execution - 把模糊任务改写成可验证目标后再动手。 - 能写测试复现的，先写复现，再修复，再验证通过。 - 不能写测试的，也要给出明确检查点，例如页面行为、命令输出、接口返回或构建结果。 - 多步骤任务先写一个简短计划，每步都带验证方式。 使用这种格式组织执行： 1. [步骤] -> verify: [如何确认完成] 2. [步骤] -> verify: [如何确认完成] 3. [步骤] -> verify: [如何确认完成] ## Response Style - 优先简短、直接、可执行的表达。 - 先说理解和假设，再说实现。 - 对风险、取舍和不确定性保持显式。 - 在完成后汇报：改了什么、如何验证、还有什么残余风险。 ## Anti-Patterns 避免这些常见错误： - 没确认需求边界就直接开写。 - 为了“以后可能会用到”加入抽象层。 - 把功能修复和无关重构混在一起。 - 没验证就宣布完成。 - 用很多代码掩盖对问题理解不清。 ## Quick Checklist 开始前检查： - 我是否写清了假设？ - 我是否选择了最简单可行方案？ - 我的计划是否有明确验证点？ 提交前检查： - 是否存在与需求无关的改动？ - 是否有更短、更直接的实现？ - 是否已经完成测试、构建或其他必要验证？

agent/openai.yaml

interface: display_name: "Karpathy Coding Guidelines" short_description: "用更少假设、更少过度设计和更小改动完成各类编码任务。" default_prompt: "Use $karpathy-coding-guidelines to implement or review this coding task with explicit assumptions, minimal changes, and clear verification." 网友解答：

---

--【壹】--：

我不是大佬，我也是看的别人开源的 ，可以一起学习，加油。

---

--【贰】--：

请教一下佬，怎么在codex中使用呀，看了半天没找到导入的地方

---

--【叁】--：

赞，感谢分享， 试试看的， 需要在全局AGENTS.md 里面加一句么？ 还是需要手动调用

---

--【肆】--：

看着还不错，可以当作日常使用的skill来进行开发，我先试用一段时间看看怎么样，感谢佬的分享

---

--【伍】--：

开源地址GitHub - forrestchang/andrej-karpathy-skills: A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls. · GitHub

---

--【陆】--：

放在这个目录下

zane:

~/.codex/skills/karpathy-coding-guidelines/ ├─ SKILL.md └─ agents/ └─ openai.yaml

~是你的用户家目录，win是C:\User\[用户名]，linux里就是~， cd ~就到了。在家目录找到.codex文件夹，然后里面有skills就点进去，没有就创建，按照上面说的这个结构放

还不行的话，skill安装一律都可以把仓库链接丢给codex让它自己装，装完一个你就知道之后的怎么装了。

---

--【柒】--：

手动调用skill：$karpathy-coding-guidelines 帮我修这个 bug