夜雨聆风用了三个月AI写代码，我终于明白了，开头定生死
事情是这样的。
最近这几个月，我几乎是泡在AI编程工具里的。Codex、Claude Code、Cursor，三个轮流用，有时候一个任务同时开三个窗口对着看。这种感觉挺上头的，真的，就像同时有三个程序员在帮你干活，你只需要把需求一说，他们就开始咔咔写代码。
但问题也在这里。
前几天我做一个小项目，PRD写得清清楚楚，丢给AI让它写。
第一轮，嗯还行，逻辑基本对但有个地方缺了。
第二轮，把那处改了，旁边又崩了。
第三轮，越改越离谱，代码开始自己给自己加bug。
第四轮的时候我盯着那坨跟需求完全对不上号的东西，整个人都麻了。
我当时就愣住了。
不是？？？
我说得很清楚啊？为什么会越改越歪呢？
然后我想起了一件事。我一开始丢需求的时候，几乎没有做任何规划。就是把需求文档贴进去，说了一句「帮我做一下」。AI确实做了，但它理解的「做」跟我心里的「做」，根本不是一回事。
这个感受，我后来发现在宝玉的一条推特里被总结得明明白白。
🌈 用好 Coding Agent，重点是两头，尤其是开头。如果一开始就走偏了，后面怎么改都改不好。
我当时看到这句话，感觉被人从屏幕里伸出一只手，啪地扇了我一下。
说得太对了。我之前所有的痛苦，所有那些「明明我都说了啊怎么就不理解呢」的时刻，根源全在第一步。我让AI在没有真正搞清楚我要什么的情况下，就开始写代码了。
而且我后来仔细想了一下，这好像不只是我一个人犯的错。
你去看GitHub上各种AI编程项目的PR记录，去看X上那些吐槽AI写代码的帖子，十有八九都是同样的问题。给了一个模糊的需求，AI给了一个看似合理但其实方向偏了的方案，然后就开始在错误的方向上越走越远，最后返工的代价比从头写还大。
说真的，这不就跟带新人一样吗？
你给一个新来的程序员分配任务，如果只是说「你去把这个功能做了」，他大概率做出来的东西跟你想象的不一样。但如果你花十分钟把需求掰开揉碎了讲清楚，甚至画个简单的流程图，他就能独立把活干好。
AI编程工具说到底就是一个能力超强但极其容易被带偏的「新同事」。
但你如果去看最近AI编程圈的风向，大家都在卷什么呢？
Claude Code刚刚推出了「动态工作流」功能，可以让Claude在一个会话里并行启动几十到几百个子智能体同时干活。听着牛逼吧？是的。
英伟达也开源了一个叫Polar的框架，能让Codex在SWE-Bench上的跑分从3.8%暴涨到26.4%，涨了将近600%。
Codex终于支持Windows了，以后在Windows电脑上也能直接让AI操控桌面。
Opus 4.8也发了，编码能力又全面升级。
坦率的讲，这些新东西都挺让人兴奋的。作为工具，它们确实在一个月比一个月强。
但有时候吧，我觉得我们是不是忽略了一件事。
工具在变强，但大多数人使用工具的方式，其实没有任何变化。
还是把需求一丢，等结果。结果歪了就重来，再歪再重来，反正AI跑得快。这不叫用AI，这叫跟AI玩轮盘赌。
这也是为什么我看到宝玉那条推文的时候，会觉得被戳中了。
他给了一套具体的方法论，我试了之后发现，确实好用。今天就跟你们聊聊这个。
第一步：三份方案，自己拍板
在你真正开始写代码之前，先把需求整理清楚。不是写在脑子里的清楚，是写在纸上的清楚。然后，把这同一个需求，丢给三个不同的AI编程工具，让它们各自出一版设计方案。
Codex出一版，Claude Code出一版，Cursor的Plan模式也来一版。
关键的地方来了。你要用的是三个工具里最强的那个Plan模式。不是让它们直接写代码，是让它们出方案。用GPT-5.5也好，用Opus 4.7也好，用你能拿到的最强的模型。
三个方案拿到手之后，你做的事情不是让它们投票，是你自己来判断。
哪个方案的思路最对？哪个方案考虑到了你没说出来的边界情况？哪个方案在你看来最简洁、最好维护？
选最优的那个方案作为主方案，但不要扔掉另外两个。另外两个方案里可能有更好的局部设计，可能有更巧妙的架构选择，把这些借鉴过来，揉进主方案里。
第二步：拆成 Phase，步步验证
对于特别复杂的项目，不是一口气出一个大方案。是把它拆成几个Phase，每个Phase有明确的完成标准和验证方法。写完一个Phase，验证通过了，再进入下一个。
这个Phase拆得越细，后面的返工就越少。 真的，这是我花了很多冤枉时间才学到的。
第三步：执行时盯关键节点
每个Phase开始执行的时候，AI按着你的方案去写代码。写完之后你先别急着说OK，人工过一遍。这个「过一遍」不是逐行review，那个太累了，是看整体逻辑对不对，关键节点有没有跑偏。
如果AI自己发现不了问题，你可以给它一个具体的纠偏指令。精确的纠偏比笼统的「这个不对，重新写」有效一百倍。
第四步：CR 一个就够了
用GPT-5.5来做CR。把代码丢进去，让它审核代码质量和设计符合度。跟你的原始方案做对照，看有没有遗漏或者绕路的地方。
这里有一个宝玉特别提到的点，我觉得非常重要。
🌈 不要用多个AI交叉Review。
什么意思呢？就是不要让Codex写的代码给Claude Code去Review，Claude Code返回的修改意见再丢给Cursor去改。这样搞的结果，大概率是代码越改越多，越改越乱。
为什么？因为不同的AI有不同的「审美偏好」。A觉得这里应该这么写，B觉得那里不应该那么写，C又觉得前面的全都不对。
三个医生给一个病人开三张方子。= =
病人不死也得掉层皮。
CR就用一个工具，一个模型，就够了。关键是你要有一个清晰的设计方案作为「标准答案」来对照。没有这个对照，AI的CR就是盲人摸象。
聊到这儿，你可能觉得这套方法论听起来挺费劲的。
说实话，一开始是很费劲。
我自己第一次尝试这么做的时候，光设计方案阶段就花了我小半天。用三个工具分别出方案，对比，融合，拆Phase，每个Phase写清楚验证标准。当时我的内心是，我要是自己写这玩意，可能已经写完一半了。
但后来我慢慢发现一个规律。
🌈 你花在设计上的时间，会在执行阶段十倍地省回来。
尤其是当项目规模超过「一个脚本搞定」的时候，这个规律就更明显。小需求可能看不出差别，三四百行代码的东西，让AI直接写也问题不大。但一旦上到几千行、几万行、跨多个文件的量级，前期规划的时间就变得极其划算。
我后来跟一个做工程的朋友聊这个事儿，他说了一句让我印象很深的话。
他说，这在传统软件工程里早就是常识了。需求分析、系统设计、详细设计、编码、测试，这个流程都跑了五六十年了。只不过以前是人对人，文档很正式。现在换成人对AI，大家就觉得可以省掉中间步骤了。
但步骤可以简化，逻辑不能跳过。
你跳过需求分析，AI就猜你的需求。你跳过方案设计，AI就给你一个它觉得最快但不是最好的实现。你跳过code review，小bug就变成大bug。
AI让我们跳过了很多「看起来费时间」的环节，但不代表这些环节没有价值。
顺着这个思路想下去，我突然觉得，这不仅仅是一个AI编程的问题。
你跟AI的所有协作，是不是都有这个规律？
让AI帮你写个PPT，如果你直接说「帮我做一个关于市场分析的PPT」，得到的一定是个空洞的模板。但如果你先花十分钟把大纲想清楚，每一页的核心信息定下来，甚至把数据的来源和口径列明白，AI做出来的PPT是能直接用的。
让AI帮你写一篇文章，如果你直接说「帮我写一篇关于AI编程的文章」，得到的是一篇套话满天飞的东西。但如果你已经想好了核心观点、每一段的走向、开头和结尾要说什么，AI就是在你搭好的骨架上填血肉。
说到写文章这事儿，我自己太有感触了。每次偷懒不想搭框架，直接让AI生成，出来的东西我都不想再看第二遍。但如果我已经把观点想透了，只是需要AI帮我把话说完，那种感觉就不一样了。AI从「造房子的人」变成了「铺地板的人」，岗位变了，产出也完全不一样。
所以问题不是AI有没有变强，它确实在变强。
问题是我们有没有学会跟它协作。
我记得Simon Willison前阵子写过一篇文章，说Anthropic和OpenAI已经找到了产品市场契合点。这个契合点是什么？不是聊天机器人，是编程智能体。企业用户在用Claude Code和Codex写代码这件事上的投入，已经大到让两家公司的企业套餐定价都从「高额折扣」变成了「按API用量计费」。
你想想看，AI编程已经不是「尝鲜」了，是正经的生产力工具。
但成为一个好工具，跟用得好这个工具，是两回事。
给你一把最好的锤子，不代表你就能造出漂亮的椅子。你还得知道怎么设计那把椅子，知道木头的纹理往哪个方向走，知道什么时候该用力，什么时候该收手。
AI编程工具也是一样的。它可以帮你省掉80%的体力活，但剩下20%的判断，你省不了。
而且坦白说，我是真的觉得，这20%才是真正值钱的地方。
写代码这件事，将来一定会变得越来越不重要。不是不重要，是门槛越来越低，低到任何人都能让AI帮你写。但「设计一个软件应该怎么做」，这件事的门槛反而会越来越高。
因为以前你有一个过滤机制。不会写代码的人，根本进不了这场游戏。现在这个机制没了，任何人都可以说「帮我做一个xxx」，能得到一个看起来能用的东西。但能不能用、好不好用、会不会在某天突然崩掉，区别全在设计阶段你是怎么想的。
宝玉的方法论，说到底就是在教你「怎么想」。用三个工具的Plan模式同时出方案，不是为了省时间，是为了逼你多看几个角度。拆成多个Phase写清楚验收标准，不是为了形式主义，是为了让你自己把需求真正想透。
这才是跟AI协作的正确姿势。
不是你把AI当打工者，往那一丢让它自己琢磨。是你做大脑，AI做手脚。 所有关键的判断你来下，所有重复的执行它来做。
我最近开始养成一个习惯。每次要给AI分配一个任务之前，先在脑子里过一遍这个流程，我要的是什么、为什么是这个方案、成功标准是什么。就这三件事，想清楚，写下来，再丢给AI。花的时间可能就五分钟十分钟，但后面的效率完全不一样。
试着想想看，如果你今天正好有个项目要用AI写，不妨试试宝玉这套方法。先别急着让AI写代码，先让它出方案。出三个方案，你选一个最好的。拆成Phase，定好验收标准。然后你就会发现一个很神奇的事。
AI写的代码变好了。
不是AI变好了，是你变好了。
是你学会了怎么当一个好用的甲方。
关注「科技热点Daily」，不只是看热点，更是学会怎么用好 AI。
