第一步：进入你的项目根目录，启动 Codex 在终端里先 cd 到项目文件夹，再运行 codex。这一步没别的好说，但很多人会忘——如果你不在项目目录里启动它，它就看不到你的代码。 第二步：让它生成项目说明书 直接敲 /init。它会自动扫一遍你的项目结构，生成一份“入职文档”。但你不能全靠它自动生成，生成完之后你得打开看看，把关键信息补全，比如包管理工具用的是哪个、启动和测试分别跑什么命令、哪些目录是绝对禁区。 第三步：查一下它当前的配置状态 敲 /status 看一眼，确认它挂的是哪个模型、权限开到什么程度、能操作的目录范围对不对。这是你每次开始干活前的一个安全检查，花不了几秒，但能避免它改错地方。 第四步：先让它看，不准改 明确告诉它：“先别动任何代码，帮我梳理一下这个项目的整体结构，告诉我怎么启动、怎么跑测试、有哪些核心模块、哪几个目录最不能碰。”这一步是在让它熟悉地形，同时也让你验证它理解得对不对。它说错了你马上纠正，比改完代码再返工强得多。 第五步：遇到大任务，先要求出方案 拿一个具体场景举例：登录页提交后 loading 图标一直转、不消失。不要说“帮我修这个 bug”，而是用 /plan 开头，告诉它：“定位一下可能相关的文件，分析原因，给一个改动量最小的修复思路，暂时不要写代码。”它给出的方案你先过目，方向偏了你马上能把控，而不是等它改了一大堆再后悔。 第六步：方案确认了，再放行让它改 你认可它的思路之后，再说“按刚才的方案执行，尽量保持改动范围小”。这个顺序很关键——永远是你先点头，它再动手。 第七步：别看它口头总结，直接看差异 改完之后敲 /diff。它能告诉你到底动了哪些文件、增删了什么内容、有没有多出不该有的文件。这一步不能省，因为 AI 的总结会漏东西，diff 不会骗你。 第八步：切换视角，让它自己审一遍 提交代码前再跑一次 /review。它会切换到审查模式，重新打量刚才的改动，检查有没有引入新 bug、有没有破坏原有功能、有没有遗漏边界情况或安全隐患。 整套流程总结下来就四个字：读、想、改、收。先让它读项目，再让它想方案，然后让它动手改，最后你来验收。别图省事一上来就开全自动，稳扎稳打才是最节省时间的方式。 #大模型 #开发者选项 #AI工具 #codex