标签： Codex

Codex 画架构图：接上 Draw.io MCP，AI 自己出图

介绍项目架构或者业务流程的时候，一段文字读者容易看累，一张图的理解成本低得多。Draw.io 本来就是画这类图的常用工具，官方发布自己的 MCP 之后，把它接进 Codex，画图这一步也能交出去。

它擅长画哪几类图

图类型典型用途流程图走一遍业务流程的先后顺序架构图讲清系统模块之间的关系思维导图把[……]

继续阅读

Codex 一句话生成 PPT：装上这个 Skill 就能用

手上有现成的社区 Skill，装它却是件麻烦事。手动整理目录，放对位置，检查依赖，一套下来半小时就没了。把 Skill 的仓库地址交给 Codex，让它自己读仓库，判断依赖，完成安装。这件事就压缩成一句话。

第一步：让 Codex 装，别自己整理目录

社区里不少开发者会把自己做好的 Skill 放[……]

继续阅读

Codex 怎么带进团队用？AGENTS.md 管规则，PR 模板管留痕

一个人用 Codex，规则记在自己脑子里就够了。多个人一起用，规则就得写进仓库，否则每个人拿到的结果都不一样。团队接入的重点其实就三件事：规则写清楚，验证跑起来，案例沉淀下来。

先弄清权限是怎么组合出来的

团队里最容易吵起来的是它能干什么这个问题。这个答案由三样东西拼出来，都在配置项里。

配置项管什[……]

继续阅读

Codex 从需求到交付（下）：提交、写 PR、复盘一条链收口

测试通过，审查也过了，这时候最容易松一口气说一句完成了。但真正的链路还差两步，把这次修改正式提交，把这次经验沉淀下来。

只做到代码能跑，短期看没问题，长期会出现一个麻烦。每次都像第一次做，重复的解释和重复的坑会一直在。

commit 要说明这次改了什么

commit 不是随便写一句 update 就[……]

继续阅读

Codex 从需求到交付（中）：小步改、认真验，改动不失控

计划确认之后才动代码。最容易出问题的地方是一次性让它全部实现，页面和样式一起动。最后项目看起来变了，你却判断不出哪里出了岔子。更稳的方式是一次只改一个功能点，改完就检查一段。

一次只改一个功能点

比如优化首页，不要一次性说优化整个首页，可以拆成几步。

步骤修改内容第一步只优化首屏标题和副标题第二步只[……]

继续阅读

Codex 从需求到交付（上）：需求怎么拆，它才不跑偏

把一句话的需求丢给 Codex，比如「帮我优化首页」，它很可能同时动 UI 和文案，连布局一起改。顺手还删掉一些它觉得没用的代码。改得快，但你不知道它改了哪里，也不知道能不能放心交付。

稳定的做法是让需求先经过拆解，再进入执行。整条链路走六步。

六步法

步骤名称目的1需求拆解先让它知道要做的项目是什[……]

继续阅读

Codex 哪些活该丢云上跑？云端和本地怎么分工

Codex 有本地、工作树和云端几种跑法，代码放在哪个位置，占用的资源也不一样。本地项目改的是你电脑里的文件，工作树改的是本地的一份副本，云端则是把 GitHub 上的仓库拉到一个云端容器里处理。

判断一个任务该放哪儿，看两件事就够了。这个活离不离得开你的电脑，以及它是否需要 GitHub。

三种运[……]

继续阅读

Codex 记不住项目？记忆系统怎么配，不用每次重讲

每新开一个对话窗口，Codex 面前就是一张白纸。它不知道这个项目用什么命令，哪些目录是边界，哪些文件不能改。团队平时怎么验证结果，它同样不清楚。上一轮刚解释过的东西，它一条都不记得。

稳定的做法是把要反复说明的项目信息写成文件，让它每次开工前自己读一遍。

这份记忆存在一个 Markdown 文件里[……]

继续阅读

Codex 怎么同时推多条任务线？线程管理和工作树讲清

Codex 里的一次对话就是一个 thread。你手动开一条，让它改一个功能，这是最顺手的用法。真实项目里往往不止一条线在跑，一个 bug 等着修，一个方案还想试试，还有个后台任务在等结果。

全塞进同一个对话，问题就来了。线程各自带着独立上下文，混在一起之后，前面聊过的结论会把后面的判断带偏，比较典[……]

继续阅读

Codex Hooks（下）：怎么写、怎么排查，进阶用法举例

知道 Hook 能在哪些时机触发之后，剩下的事是把它写出来。一份配置只有三层，真正干活的是 handler 里的命令。什么时候触发由事件决定，匹配哪些场景交给 matcher，这两层看一遍就会，麻烦在第三层。

脚本从标准输入拿到一段 JSON，用退出码和输出告诉 Codex 该不该继续。返回格式写错[……]

继续阅读