我见过一种很常见的开场：项目刚打开，Codex 也刚装好，手还停在键盘上，人已经开始想象后面的画面了。比如“帮我把这个功能做完”“顺手把目录整理一下”“再看看哪里能优化”。这时候最容易出问题，不是在后面一小时，而是在前十分钟。因为人一兴奋，就会把边界说得很糊，工具一接话，就可能直接往下冲。
我后来越来越愿意把 Codex 当成一个刚接手你项目的临时帮手，不是你脑子里那个“它应该懂我意思”的分身。你要是交代得清楚，它确实能省掉不少重复动作；你要是只丢一句“你先改改看”，那后面很可能不是省时间，而是你花更多时间去收残局。这个题真正卡住的地方，不是“刚装上 Codex 怎么用”，而是“第一天该给它什么范围，什么动作先别碰”。
这张图能帮人看清一个现实：很多人搜“刚装上 Codex 怎么用”，表面上是在找入口，实际是在找一种放心感。总想知道有没有一句通用指令，发出去它就能乖乖干活。可真实情况更像开车前上路，不是车能不能动，而是你有没有先把刹车、方向和禁行路段讲明白。新手翻车，多半不是不会说话，而是把“能不能改”“能改到哪”“改完怎么检查”这几件事混成一团了。
第一天别追求大活，先看它会不会停
我更愿意把第一天的目标定得很小：不是让 Codex 证明自己多强，而是先看它会不会在不清楚的时候停下来问。这个判断挺准，因为真正危险的，不是工具做得慢，而是它做得太顺，顺到你还没反应过来，它已经把几个文件一起改了。
很多人一开始会把问题想成“我要不要信它”，其实不是这个问法。更像是：它现在拿到的信息，够不够支撑它动手？如果你是老师，把一道题交给学生，题目里条件都没说全，学生却立刻往下写，写得再快你也不敢放心。Codex 也是一样。第一天你更该观察的，不是答案漂不漂亮，而是它遇到模糊处会不会停、会不会复述、会不会把不确定的地方挑出来。
所以我会把第一条规矩立得很简单：不清楚先问。听着像一句空话，其实很好判断。你把任务说完以后，它如果直接开干，你就继续追问自己几句：我有没有说哪些文件别碰？有没有说先读再改？有没有说只做一个小点，不要顺手扩展？这些问题里，只要有两三个还是空白，那它现在最该做的不是修改，而是确认。真正省时间的方式，是让工具做能检查的小事，人负责判断要不要继续。
危险动作不是不能做，是先别偷跑
第二条规矩，我会放在“危险动作停下”。这个用法很实在，因为很多失控场面，都不是代码本身有多难，而是动作太大了。删除、覆盖、批量改名、直接提交，这些都像下坡路上突然踩一脚油门，看起来一下子推进很多，其实你还没来得及看清前面。
这张图那个比喻我很认同。像借车给朋友开，不是不给他开，是先说清楚哪条路不能走。你不会一上车就来一句“你看着开吧”，然后自己低头玩手机。Codex 也一样，不是不能让它试，而是先给围栏。看起来像是在限制它，其实是在保护你的项目边界。
这里最容易误会的一点是，很多人把“让它大胆一点”理解成“让它自己决定大动作”。这就偏了。大胆，应该是大胆去读、去分析、去列方案，不是大胆去删文件、改结构、发提交。尤其是刚装好的第一天，你对它在这个项目里的理解深度还没摸清楚，这时候让它碰高风险动作，像是刚认识一个代打，就把主号账号密码和仓库钥匙一起交出去。不是说一定出事，而是你根本没有建立判断面。
国内访问、账号、地区、限制这些话题，也适合放在这个位置看。它们不是“怎么绕过去”的教程点，而是风险提醒。只要一个任务开始牵扯账号登录、令牌、远程权限、仓库推送，你就该自动放慢。判断标准很简单：这一步一旦做错，影响是不是会从“改坏一个文件”变成“改坏一个环境”或者“把记录带到外部”。只要答案偏向后者，就让它停下，先问清，再决定要不要继续。
真正让人安心的，不是改完了，而是你看得见
第三条规矩，我会定成“每次修改能看见”。很多新手不放心 Codex，根子不是它改错过什么，而是改完以后自己不知道该看哪里。界面里一堆变动，文件名变了，内容也变了，脑子就会乱。这时候最有效的做法，不是让它解释得更花，而是把修改压到足够小，小到你能一眼看懂差异。
这张图里的顺序我会直接拿来做第一天的节奏：打开项目，交代边界，让它复述，做小修改，看差异。你会发现，关键不在“做小修改”这四个字，而在前后的夹层。前面先交代边界，后面立刻看差异，这样中间那一步才有意义。不然它改了，你也只能凭感觉说“好像可以”。
这里有个很好用的判断法：不是看它一次能干多少，而是看你一次能审多少。这个区别很大。很多任务从工具视角看可以一口气做完，但从人的视角看，根本没法确认。比如同时改十几个文件，哪怕每处都不大，你也很难判断哪些是这次任务本来就该动的，哪些只是它顺手扩出去的。反过来，如果你让它先改一个按钮文案、一段提示、一处样式、一段函数命名，你就很容易看出它有没有理解上下文。
我后来发现，能看见差异这件事，本身就是一种刹车。因为一旦你准备认真看改动，很多模糊指令就说不出口了。你会自然把要求说得更具体：只改这个目录，别动配置；先读完相关文件，再提方案；没有确认前不要删除和提交。听上去像是在增加沟通成本，其实是在把返工成本提前挡住。第一天尤其如此，你要的不是“它已经会做很多事”，而是“你知道它做了什么”。
三条规矩立住以后，兴奋感反而更能用
很多人刚装上 Codex，最想试的是“让它随便跑一把，看看到底多强”。这个心情我能理解，但经验上看，兴奋感要留一点刹车。不是让它随便试试，而是让它在围栏里试。这个差别，看起来只是语气不同，其实决定了后面是省心还是补锅。
你可以把这三条规矩连起来理解。不清楚先问，是在防“它以为自己懂了”；危险动作停下，是在防“它懂了一半就往前冲”；每次修改能看见，是在防“它做完了你却接不住”。主线其实只有一条：第一天不要急着把项目交给 Codex，而是先看你们能不能形成一种可检查的配合。工具不是来替你承担判断的，它更像一个执行很快的助手。你说得清，它就推进；你发现风险，它就停；你要求可见，它就留下痕迹。
如果你今天刚装上 Codex，我会建议你把第一轮任务压到很小，甚至小得有点不过瘾都没关系。比如只动一个页面的一处文案，只修一个确定的小 bug，只让它先读文件再复述理解。因为第一天真正该建立的，不是“它能帮我做完多少”，而是“我知道怎么让它在边界里工作”。这套感觉一旦有了，后面你再把任务放大，心里是有尺子的。
说到底，刚装上 Codex 不是不能马上用，而是别一上来就把它当成能替你兜底的人。先把规矩立好，后面的效率才站得住。真正让人安心的那种快，从来不是一口气冲出去，而是每走一步，你都知道自己还握着方向盘。
暂无评论内容