我第一次意识到很多人不是不会用 Codex，而是开场就把话说偏了，是在看一个很常见的场景：编辑器刚打开，左边一堆文件夹还没看清，右边输入框里已经敲下“帮我做一个完整的登录功能”。这句话看起来很省事，像把题目直接甩给一个反应很快的人。可问题也刚好出在这里。你把它当成一支会自动写完的笔，它就只能顺着字面往前冲；你把它当成一个能一起看题的同桌，它反而更容易帮到你。
我后来越来越愿意用“同桌”这个比喻来理解 Codex。因为同桌不是你说一句“把这题做了”就能稳稳答对的人，他得先知道你现在学的是哪一章，用的是哪套公式，老师前面讲到了哪一步，题目里哪个条件不能乱改。Codex 也是这样。它不是不能写代码，而是你越早让它看懂项目，它写出来的东西越像这个项目里本来就会出现的东西，越不容易看起来很努力，实际却跑偏。
新手常卡住的，不是按钮，是开场那句话
很多人第一次用 Codex，卡的点表面上像是“它怎么没按我想的做”，其实更深一层是“我把一个太大的任务，直接丢给了一个还没进教室的人”。这不是工具反应慢，而是任务边界一开始就糊了。你说“加个功能”，它不知道你要改前端还是后端，不知道这个项目用什么框架，也不知道你能接受改多少文件。看起来你给了目标，其实只给了结果，没有给上下文。
这张图里那些现象很能说明问题。真正卡住新手的，通常不是“按钮在哪”，而是任务说得太大，项目背景没交代，验收标准也没写清。你让它“修一下报错”，它可能真把报错消掉了，但顺手改坏了别的地方。你让它“优化页面”，它可能改得很勤快，可你打开一看，风格已经不像原来的项目。这里有个很实在的判断标准：如果一句话里只有“做什么”，没有“在哪做、按什么规则做、做到什么算完成”，那它大概率会往宽里猜。Codex 最怕的不是难题，而是模糊题。
所以我现在看别人提问，会先盯住一件事：他是在给命令，还是在交代现场。前者像喊一句“把教室打扫干净”，后者像说“先看黑板附近，拖把在门后，只处理今天留下的纸团，桌椅先别动”。不是你说得越多越好，而是你给的信息要能帮它判断边界。这个边界一清楚，后面很多来回折返都会少掉。
我会先让它做小事，不急着让它证明自己
这个用法很实在。跟 Codex 开始协作时，我更愿意让它先做几件小事，看它理解项目有没有偏。不是一上来让它交整套答案，而是让它先把题目复述一遍，看看它到底看到了什么。
这几件事看着慢，实际是在省后面的时间。我通常会先让它读目录。因为目录像课本目录，先知道项目分成哪几块，它才不至于进错门。接着我会让它说理解，用人话讲清楚“这个项目大概干什么，相关代码可能在哪”。这一步特别像同桌给你复述题意，你一听就知道他是真懂了，还是只认出了几个关键词。再往下，让它把任务拆开，说出准备先改哪一小块、为什么从这儿下手。到了这里，它才开始动代码，而且是小步修改，不是一口气铺满半个项目。改完以后，还要跑检查，看看报错、测试、构建有没有受影响。
这里最关键的，不是这几个动作的名字，而是顺序。很多人上来就想看结果，像考试时还没审题就急着落笔。可写代码跟解大题很像，前面十分钟看起来没在“产出”，其实是在避免后面四十分钟全白忙。真正省时间的方式，是让工具做能检查的小事，人负责判断要不要继续。你要是把这层分工想明白，就不会老盯着“它能不能一次写完”，而会开始看“它现在理解得准不准”。
真正有用的提示，不是更厉害的话术，而是更清楚的边界
很多新手会误以为，自己缺的是一套“高阶提示词”。我更愿意这样理解：不是你不会说魔法咒语，而是你还没学会像交接工作那样说话。Codex 接任务时，最吃得消的信息其实很朴素：项目是干什么的，准备改哪个文件或哪一层，哪些东西别碰，改到什么程度就收手，做完用什么方式检查。
这张图里的比喻挺准。把 Codex 当许愿池，你会想用一句话换一个完整结果；把它当同桌，你就会自然补上“课本翻到哪一页”。这两种用法的差别，不是礼貌问题，而是结果质量的问题。前一种听起来省力，其实把大量判断都留给了它；后一种看起来多说了几句，实际是在替项目守边界。
如果你不知道边界该怎么说，可以连续追问自己几件事。这个功能是加在现有逻辑上，还是新开一块？我希望它沿用原来的写法，还是允许引入新方案？我现在更在意速度，还是更在意改动范围小？如果它改动超过三个文件，我还接不接受？这几句不像“技巧”，更像把脑子里模糊的要求翻译成人能执行的话。你一旦能把这些说出来，Codex 给你的结果就会稳定很多。
还有一个容易忽略的点：验收标准。很多跑偏，不是发生在写的那一刻，而是发生在你没有定义“什么算完成”。比如你说“把页面修好”，这个“修好”到底是能显示就行，还是交互也要通，还是样式得跟原项目一致？看起来只是多补一句，实际上它决定了工具会把力气花在哪。你不写，它就只能猜。
把它放在合适的位置，你会少很多失望
我现在不太把 Codex 看成“替我写代码的人”，而更像“能快速进组的协作者”。这个位置一摆正，很多失望会自然减少。因为你会知道，问题不在于它有没有本事，而在于你有没有先让它理解现场。就像一个新转来的同学，再聪明，也得先看看你们班作业写到哪、老师要求是什么、这题用哪种写法更合适。
这也是为什么我不太建议一上来就让它写完整功能。不是完整功能不能做，而是那样太像把一整张卷子拍给同桌，说“你全做了吧”。看起来效率高，其实最容易把误解放大。更稳的做法，是先让它说明项目，再改最小一块。你从一小块里看它会不会读目录，会不会沿用原来的风格，会不会在不确定时先说明假设。一个人是不是靠谱，往往不是看他第一下写得多快，而是看他有没有边看边校准。
如果你是刚开始接触 Codex，我会先看三件事。它能不能把项目说清楚，能不能把任务拆小，能不能在改完后给出可检查的结果。前两件决定它有没有真的看懂，后一件决定你能不能放心接着往下做。至于账号、地区、访问这些问题，确实会影响能不能用、好不好用，但那是进入门口之前的判断，不是协作方法本身。能进来之后，真正拉开差距的，还是你怎么开第一句话。
说到底，Codex 不是许愿池，扔进一句话不会自动长出一套贴合项目的代码。它更像一个反应很快、执行力很强的同桌。你让它先看懂项目，再开始动手，它给你的回报通常不是“神奇”，而是稳定。对新手来说，这种稳定比偶尔撞对一次有用得多。因为你慢慢会知道，自己不是在赌运气，而是在学一种能复用的协作方式。
暂无评论内容