[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-75456":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":8,"htmlUrl":8,"language":8,"languages":8,"totalLinesOfCode":8,"stars":9,"forks":10,"watchers":11,"openIssues":12,"contributorsCount":12,"subscribersCount":12,"size":12,"stars1d":13,"stars7d":14,"stars30d":15,"stars90d":12,"forks30d":12,"starsTrendScore":16,"compositeScore":17,"rankGlobal":8,"rankLanguage":8,"license":8,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":18,"topics":21,"createdAt":8,"pushedAt":8,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":12,"starSnapshotCount":12,"syncStatus":13,"lastSyncTime":25,"discoverSource":26},75456,"Before-You-Ask-Codex-to-Code","Haaareally\u002FBefore-You-Ask-Codex-to-Code","Haaareally",null,137,1,115,0,2,3,22,6,0.9,false,"main",true,[],"2026-06-12 02:03:34","# Before You Ask Codex to Code\n\n简体中文 | [English](.\u002FREADME.en.md)\n\n\u003Cp align=\"center\">\n  \u003Ci>“授人以鱼不如授人以渔”\u003C\u002Fi>\u003Cbr>\n  \u003Csub>老子\u003C\u002Fsub>\n\u003C\u002Fp>\n\n这是一个开源的 Codex 使用讲解。本项目的重点不是针对某个非常具体的场景给一套 skills 或配置模板，而是告诉大家：哪些方法能显著提高 Codex 使用体验、一定程度降低模型幻觉，以及如何和 Codex 逐步磨合。这个 repo 里真正更有帮助的不是文件本身，而是下面这些经验总结，希望你耐心看完。本人主要用 Codex 做一些研究性质的工作，这就是本文的使用背景。\n\n## 1. 使用 Codex，以及和 Codex 磨合\n\n我一开始并不想先介绍一堆文件和配置参数。我更想先讲一个前提：Codex 是一个助手，他不是你项目的大脑，更不是领导者。相反，你才是。\n\n先和 Codex 把架构和技术点聊透，再让他写代码，往往才是更稳的第一步。如果一上来就让他“自己想然后自己写”，那大概率会出错，不管是立刻运行时报错，还是未来埋下更深层的问题。\n\n我的第一个想法，也是我觉得最重要的一点，就是：***一定一定要先和 Codex 一起打磨想法和架构***。你要先理解一些关键架构和技术点，再把自己的判断和顾虑说出来，让他带着这些前提去思考。也许这听起来没有某些 skills 那么“高级”，但相信我，和这条建议相比，后面很多技巧都只能算锦上添花。\n\n关于如何用好 Codex，其实我们更需要的是**采纳一些共性的使用技巧，然后多用、多反馈给 Codex**。\n\n下面这个循环，比“一上来就让 Codex 直接写完”更接近真实且高质量的使用方式：\n\n```mermaid\nflowchart TB\n    A[\"使用一些基础的\u003Cbr\u002F>AGENTS.md 和 prompt 技巧\"]\n    B[\"开始和 Codex 聊\u003Cbr\u002F>技术点、边界和架构想法\"]\n    C[\"聊得差不多后，给出反馈\u003Cbr\u002F>并让 Codex 开始写代码\"]\n    D[\"任务过程中碰到问题\u003Cbr\u002F>发现新约束或新共识\"]\n    E[\"把稳定结论和通用规则\u003Cbr\u002F>反馈进 AGENTS.md\"]\n    F[\"继续接着聊技术点\u003Cbr\u002F>实现方式和下一轮方向\"]\n\n    A --> B --> C --> D --> E --> F\n    F --> C\n```\n\n这个流程里有三个点尤其重要：\n\n- `prompt` 负责把这一次任务讲清楚。\n- `AGENTS.md` 负责把多次任务里反复出现的共识沉淀下来。\n- 反馈不是“修修补补”，而是在逐步建立你和 Codex 的协作方式。\n\n因此不难看出，Vibe Coding 不是什么特别复杂、也不是什么能玩出无限花样的技术，但在当下阶段，你确实不能指望它在没有你介入的情况下，从“有想法”到“写代码”再到“完全落地跑通”一气呵成。***把现在的 Vibe Coding 当成打怪升级更合适：先拿一套新手村装备，慢慢打怪，慢慢磨练你驾驭它的能力，最后它就会像你身上的装备和武器一样，带你去完成更难的任务。***\n\n## 2. 基础配置\n\n先记住一个核心原则：`~\u002F.codex\u002Fconfig.toml` 放个人长期偏好（**人话：让 Codex 写代码时的默认权限等设置**），`.codex\u002Fconfig.toml` 放仓库级行为（**人话：特定文件夹里你想让 Codex 获取的权限**）。官方最佳实践也明确建议把个人默认配置和 repo 配置分层维护，而不是把所有东西都塞进一次性的 prompt 里。\n\nCodex 使用大概有以下几种方式：\n\n- Desktop Codex：适合本地开发，最大的优点是功能全面。一些 Plugins 可以直接浏览安装，非常方便。不过如果你只是刚开始用 Codex，其实下面这些使用方法差别没有那么大。个人觉得最有用的是做一个 Automation，每天整理技术前沿信息。\n- IDE Extension：适合边看文件边提问。科研任务很多时候需要 SSH 连接，我个人觉得 Extension 里的 Codex 也完全够用。*如果不够用，那就去服务器那边用 Codex CLI 起一些对话，完成 Extension 不太方便做的配置；过一会你通常也能在 Extension 里看到 CLI 开起来的对话。*\n- CLI：适合 shell-heavy 工作流、脚本化使用、远程环境。我自己不算常用，但**功能和 Desktop Codex 差别不大**。\n\n推荐先用一个保守但实用的起步配置：\n\n```toml\nmodel = \"gpt-5.4\"\napproval_policy = \"on-request\"\nsandbox_mode = \"workspace-write\"\n\n[sandbox_workspace_write]\nnetwork_access = false\nwritable_roots = [\"YOUR_PROJECT_PATH\"]\n```\n\n这套配置的意思很简单：\n\n- `model = \"gpt-5.4\"`：官方示例配置里给多数用户的推荐模型。这里我也建议大家基本就用这个模型，效果足够，token 也不会烧得太快。\n- `approval_policy = \"on-request\"`：需要时再请求你批准。如果你胆子比较大、又需要一堆窗口一起跑任务，也可以换成 `\"never\"`。\n- `sandbox_mode = \"workspace-write\"`：允许在当前工作区改代码，但不越界。\n- `network_access = false`：默认不放网络，只有确实需要时再开。不是我们常规理解里的“完全离线”，很多时候正常的 search 能力依然够用。\n- `writable_roots = [\"YOUR_PROJECT_PATH\"]`：这里可以理解为给 Codex 指定额外可写的项目路径。\n\n## 3. 关于 AGENTS.md文件和 Skills\n\n### `AGENTS.md` 是仓库长期规则\n\n这个文件本质上就是 Codex 必须遵守的一些规范。**但不要觉得你必须先找到一份别人写好的、特别成熟的 AGENTS.md才能开始用。** 你完全可以先按我下面建议包含的内容写一个初版。什么时候模型开始“不听话”了，或者 prompt 已经压不住问题了，再根据自己的实际情况慢慢修自己的版本。\n\n因此，`AGENTS.md` 最适合放这些内容：\n\n- 项目背景和目标\n- 必跑命令，例如 `test`、`lint`、`build`\n- 代码风格、目录约定、命名规范\n- 风险边界，例如“不要改 schema”“不要碰线上配置”\n- 完成定义，例如“必须补测试”“必须更新 docs”\n\nCodex 甚至大部分模型在完成任务时，遇到少见问题，或者一个任务拖得太久，幻觉都会变得比较严重。同时，因为 context 会不断压缩，一些规矩也会慢慢被忘掉。\n\n这里结合我的经验，给大家两个我觉得非常值得加进去的方向，能够有效**缓解模型幻觉和复杂任务里的上下文消耗过快**：\n\n```md\n# AGENTS.md\n\n## Communication style\n- Be objective, rigorous, and critical.\n- Do not flatter, overpraise, or agree too quickly.\n- Maintain a sober, evidence-seeking tone when discussing ideas; do not present speculative claims as established facts.\n\n## Workflow\n- Do not rely only on internal model knowledge for research discussions when external evidence is important.\n\n## Coding workflow\n- Before writing substantial code, first propose a minimal implementation plan.\n- Prefer the smallest runnable slice first.\n- Keep changes localized unless a broader refactor is explicitly requested.\n\n## Tool usage\n- Use external tools such as GitHub or paper\u002Fdocument access when external evidence is needed.\n- When discussing ideas, related work, or external implementations, proactively search for relevant evidence when it is likely to improve accuracy or sharpen criticism.\n- Use subagents only for clearly separable tasks.\n- Avoid spawning subagents for casual brainstorming or small edits.\n- For complex tasks, it is acceptable to spawn a small number of subagents when doing so materially improves parallel exploration, implementation, or verification.\n```\n\n上面这些点，很多时候都能让 Codex 少一点阿谀奉承，多一点辩证思考；在面对稍微复杂一点、或者没太多人做过的任务时，也能一定程度减轻幻觉，并降低 context 消耗速度。\n\n至于原理，其实不难理解。你可以把它想成一个人干活：如果不借助外部资料和别人做过的成果，就很容易钻牛角尖，这就是模型幻觉；如果又没人配合，很多东西都得自己硬记，那 context 自然就会越拖越长。\n\n### `Skills` 是可复用工作流\n\n先说一个很个人的观点：**你的大部分任务都不需要 skills，并且很多别人开源出来的 skills，对你来说很可能弊大于利。** 图一乐可以，真干起活来会出现各种问题。***如果你没有特别垂直、特别稳定的任务流，完全可以先跳过这个现在很火的技术。***\n\n当然，官方对 skills 的定义仍然很清楚：它是 reusable workflows。它不是“再写一份提示词”，而是把一类重复任务沉淀成可触发、可复用、可分发的能力包。\n\n一个 skill 目录通常长这样：\n\n```text\n.agents\u002Fskills\u002Frelease-notes\u002F\n├── SKILL.md\n├── references\u002F\n│   └── checklist.md\n└── scripts\u002F\n    └── collect_changes.sh\n```\n\n如果你现在还在饶有兴致地看 skills，我的建议是：先到这里就行。等你真的有这类需求了，再专门去学也不迟。\n\n## 4. 关于额外的功能\n\n### MCP\n\nMCP 适合把外部文档、内部工具、知识库、系统接口接进 Codex。官方文档给出的配置方式很直接：\n\n- 用 `codex mcp` 管理\n- 或者直接改 `config.toml`\n- 既可以配全局，也可以只配在可信项目里\n\n举个非常直白的例子：GitHub 的 MCP，和你用了我的基础 AGENTS.md 再让 Codex 去 GitHub 上搜索，有什么区别？一个最容易理解的区别就是：GitHub MCP 能让 agent 访问到你的一些私有 repo，而普通的 web search 只能搜到公开 repo。至于要不要专门去折腾 MCP，你可以自己衡量。\n\n### Plugins\n\n你自己把一个任务打磨到很好用，再打包给别人，让别人也能舒服地复用这套流程，这就是 Plugins 很实用的地方。本质上它就是一种可安装、可分发的打包能力。\n\n适合上插件的场景：\n\n- 团队里很多人都需要同一组 skills\n- 你想把 GitHub、Slack、Drive 之类的外部连接打包交付\n- 你已经有一套稳定工作流，想让别人一装就能用\n\n### Subagents\n\n上面说到，subagents 能在一定程度缓解 context 飞速消耗；除此之外，也能让一些复杂任务跑得更快。**本质上就是你之前对接的 Codex main agent 现在当组长了，有了一个小团队一起干活。** 速度通常会更快，但你付的“工资”也就是 token，通常也会更多，这很容易理解。\n\n至于怎么开始让 Codex 用 subagents，除了像我上面说的那样在 AGENTS.md 里稍微约束一下，你也可以直接在 prompt 里说“任务有点复杂，开 2-3 个 subagents”。如果你想写得更细一点，可以这样说：\n\n```text\n先理解这个仓库，再用 2-3 个 subagents 并行做以下事情：\n1. 梳理核心模块和调用链\n2. 找出和本次改动相关的测试与风险点\n3. 给出最小可行实现方案\n最后由主 agent 汇总结论并实施。\n```\n\n但你指定 subagents 的工作，和让 Codex 自己分配任务，效果差别大吗？我只能说要看情况。我个人习惯让 Codex 自己去分配 subagents，就好比我是老板，我不想直接管下面每个人具体干什么，我更希望一个组长来对我汇报。\n\n### Automations\n\n官方支持在 *Codex App* 里跑 recurring tasks，并且可以和 skills 组合使用。适合做这些事：\n\n- 每天巡检错误日志或失败 CI\n- 定期汇总最近代码变更\n- 定时检查依赖、文档、告警、review 队列\n\n如果某件事已经稳定到“不需要你每次重新解释”，那它就不该一直靠手动 prompt 重复触发，而应该被做成 automation。\n\n*如果你没有上面这些需求，还有个挺有意思的玩法：每天早上让它当你的新闻速递。如果你对某些信息不感兴趣，也可以直接写进给它的指令里。*\n\n## 5. 总结\n\n看到这里，你应该也能感觉到：Codex 这种 Vibe Coding 没有神秘到需要掌握一大堆玄学技术。Codex 更像是一座桥，连接的是人的语言、想法和代码实现。你的想法和经验永远是第一位的。因此，与其一下子追着别人好用的“武器”跑，不如先把自己的“装备”磨好，多用、多反馈、慢慢迭代，这才更像真正的 Vibe Coding。\n\n## 6. 致谢\n\n感谢 [@GuoLuPM](https:\u002F\u002Fgithub.com\u002FGuoLuPM)。他还开源了一个很有意思的 [skills](https:\u002F\u002Fgithub.com\u002FGuoLuPM\u002Fskills) 项目，在开发过程中当满足触发条件时，就会启用对应的 skills，感兴趣的可以玩一下。\n\n## 参考资料\n\n- [Codex Quickstart](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fquickstart)\n- [AGENTS.md Guide](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fguides\u002Fagents-md)\n- [Skills](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fskills)\n- [Subagents](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fsubagents)\n- [MCP](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fmcp)\n- [Plugins](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fplugins)\n- [Automations](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fapp\u002Fautomations)\n- [Codex App Features](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fapp\u002Ffeatures)\n- [Agent Approvals & Security](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Fagent-approvals-security)\n- [Best Practices](https:\u002F\u002Fdevelopers.openai.com\u002Fcodex\u002Flearn\u002Fbest-practices)\n","该项目旨在提供关于如何高效使用Codex进行代码生成的指导。核心功能和技术特点包括与Codex共同打磨想法和架构、采用基础配置以确保安全性和效率，以及通过`AGENTS.md`文件记录项目规则来降低模型幻觉。适合于需要利用AI辅助编程的研究人员或开发者，在日常开发中提高与Codex合作的质量与效率。通过遵循项目推荐的方法论，用户可以逐步优化与Codex的合作模式，实现更高效稳定的代码生成过程。","2026-06-11 03:52:51","CREATED_QUERY"]