夜雨聆风同样用AI写代码，有人提速5倍，有人反而更慢。差距不在工具，在方法。
● ● ●
开篇
上周三下午，我盯着屏幕上的报错信息发了整整20分钟的呆。
事情是这样的：我让Claude帮我写一个用户认证模块。给的提示词我觉得挺清楚的——"加一个Google OAuth登录"。结果它给我搞了400多行代码，引入了我项目里根本没用过的库，session管理方式跟我现有的完全不兼容。
我花了两个小时把它的代码拆了重写。
配图1
后来跟一个每天用AI写代码的朋友聊起这事，他说了一句让我挺受刺激的话："你这不是在用AI，你是在跟AI玩猜谜。"
他给我看了他的工作方式——同样是写一个认证模块，他先花10分钟写了一份简短的需求文档，然后让AI按文档执行。出来的代码一次过，几乎不用改。
差别在哪？他把"写代码"这件事的瓶颈，从"生成代码"挪到了"描述需求"。
这个转变，让他的产出效率翻了3倍。我后来照着做了一个月，确实管用。今天把这套方法拆开讲讲。
● ● ●
别急着让AI动手，先写一份"施工图"
很多人用AI写代码的习惯是：想到什么说什么。
"帮我写个登录页面"、"加一个日历组件"、"把这段代码优化一下"。这种提示词，AI拿到之后只能猜你想要什么。猜对了是运气，猜错了你就得花时间擦屁股。
配图2
Spec-first prompting——先写规格，再让AI执行。这个概念不是我发明的，Claude Code的官方文档里就有推荐，很多资深开发者也在用。但知道的人真不多。
具体怎么写？一份好的"施工图"只需要回答四个问题：
- 01要做什么？ 一句话说清楚，不写行业黑话
- 02输入和输出是什么？ 数据结构、API格式、页面状态变化
- 03边界情况有哪些？ 空数据怎么办、出错了怎么处理、权限不够会怎样
- 04什么东西不能碰？ 已有的功能、数据模型、认证流程
举个实际例子。我那个认证模块，如果一开始这样写：
为项目添加 Google OAuth 登录。 - 使用项目已有的 passport.js，不要引入新依赖 - 回调路由用 /auth/google/callback - 登录成功后跳转到 /dashboard，失败跳 /login?error=1 - session 存储用现有的 Redis 方案，不要改成 JWT - 写测试覆盖：正常登录、回调失败、session 过期三个场景
你看，这比"加一个Google OAuth登录"多了也就几分钟的功夫。但这几分钟省下来的，是后面几个小时的返工。
朋友跟我说他现在每接到一个需求，第一件事不是打开IDE，而是打开一个markdown文件。先花5到10分钟把上面四个问题答完，然后才开始跟AI对话。
"写施工图"这个习惯一旦养成，你会发现一个反直觉的事情：AI写代码最费时间的部分，从来不是生成代码，而是你反复纠正它搞错的部分。 Spec-first的价值就是把纠正的次数降到接近零。
● ● ●
让AI先想后做，别让它上来就改文件
Claude Code有个功能叫Plan Mode。Cursor的Composer也有类似的"先规划再执行"模式。
很多人不用这个功能。嫌多一步。嫌慢。
我之前也这样。觉得AI直接改文件多快啊，何必多此一举让它先"想"一遍？
配图3
直到有一次，我让它重构一个数据库查询模块。它二话不说就开始改，改了7个文件。我review的时候发现其中3个文件完全不需要动——它"顺手"帮我都优化了一遍，但那些优化引入了新的bug。
从那以后，只要改动涉及超过两个文件的任务，我必开Plan Mode。
流程很简单：
第一步，让AI先读代码、不碰文件。 告诉它："读一下/src/auth目录，理解我们怎么处理登录和会话的。同时看一下环境变量的配置方式。" 这一步的目的是让AI建立上下文。很多人的习惯是上来就扔需求，AI对项目一无所知就开始写——这就像你招了个新员工，第一天不给他看项目文档，直接让他改代码。
第二步，让它出方案。 "我想加Google OAuth。需要改哪些文件？会话流程是什么？给我一个实施计划。" 这时候AI会列出它打算动哪些文件、怎么改、预期的结果。你review这个计划的成本几乎为零——你只需要看一眼文件列表，判断"这几个该动"或"那个不该碰"。
第三步，确认之后再执行。 Plan通过了，再让它动手写代码。
这三步看起来多了两步，实际省下来的时间远超你想象。我统计过自己一个月的使用数据：不做Plan的时候，平均每个功能要纠正2到3次；做了Plan之后，降到0.5次以下。
有经验的开发者用AI编程工具后，实际生产效率可能反而慢19%——这是有研究数据支撑的。原因就是他们花了大量时间在审查和修复AI生成的代码上。Plan Mode的核心价值，就是把这个"审查-修复"循环的次数砍下来。
● ● ●
一个Agent不够，试试并行
这个技巧听起来有点"高级"，但实际操作比你想的简单。
配图4
核心思路：把一个大任务拆成几个互不依赖的小任务，每个小任务丢给一个独立的AI会话，让它们同时跑。
比如你要做一个新功能，可以这样拆：
- Agent A：实现核心业务逻辑
- Agent B：写测试用例
- Agent C：更新文档和API说明
三个同时跑，总耗时约等于最慢的那个。串行做的话，总耗时是三个加起来。
这里有个关键前提：用Git Worktree隔离每个Agent的工作目录。 如果三个Agent都在同一个目录里改文件，互相踩踏，那就是一团乱麻。Git Worktree让每个Agent在独立的分支和目录里工作，共享同一个代码仓库但互不干扰。
有个开发者分享过他的数据：跑10个并行Claude Code会话，配合CLAUDE.md项目规则文件，一个月能产出500+次commit。当然普通开发者用不着这么夸张，但从1个Agent变成2到3个并行，确实能把一个中等复杂度的功能从一整天缩短到三小时左右。
实操建议：从2个并行开始。 一个写代码，一个写测试。等你习惯了review多个diff、管理worktree之后，再往上加。瓶颈会从"写代码有多快"转移到"review代码有多快"——说实话这反而是个更好的位置。
还有个被很多人忽略的东西：上下文文件。Claude Code的CLAUDE.md、Cursor的.cursorrules——这些文件相当于给AI的"项目说明书"。你在里面写上项目的技术栈、命名规范、哪些文件不能随便动、已知的坑……AI每次启动会话都会读这个文件，不需要你每次都重复说一遍。
我自己写的一份CLAUDE.md大概20行，核心就几条：技术栈和版本号、数据库Schema概要、不能动的核心文件列表、测试命令。每次新会话启动，AI上来就知道项目的"规矩"，输出质量肉眼可见地提升。
这文件越短越好。官方建议的标准是：每条规则问自己"不写这条，AI会犯什么具体的错？"——答不上来就删掉。太长的CLAUDE.md反而会让AI忽略里面的重要规则。
● ● ●
予昕点评
说点我自己的感受。
用AI写代码这件事，市面上99%的教程都在教你怎么写"更好的提示词"。什么"请用TypeScript"、"请遵循SOLID原则"、"请写单元测试"——这些当然有用，但都是"术"的层面。
真正的杠杆在"道"的层面：你有没有一个结构化的工作流程。
Spec-first prompting解决的是"AI不知道你想要什么"的问题。Plan Mode解决的是"AI上来就乱改"的问题。并行Agent解决的是"一次只能做一件事"的问题。上下文文件解决的是"每次都要从头解释"的问题。
这四个加在一起，才是2026年AI编程效率的真正差距。
我最想说的一句话是：AI不会替代程序员，但会用AI的程序员会替代不会用的。 这句话已经被说烂了，但很少有人真正想过"会用"到底意味着什么。不是会写花哨的提示词，是有一套可复制的工作方法。
还有一个容易被忽略的点——你review AI代码的能力，比你写代码的能力更重要了。 以前review是可选的，现在是必须的。AI生成代码的安全漏洞概率大约是手写代码的2.74倍（有研究数据）。你不能信任它，但你可以验证它。建立验证习惯，比学会任何工具都重要。
● ● ●
行动清单
- 01今天就开始写"施工图"： 下次用AI写代码前，花5分钟回答那四个问题——做什么、输入输出、边界情况、不能碰什么。写在一个markdown文件里，喂给AI。
- 01给你的项目建一份CLAUDE.md： 20行以内，写上技术栈、命名规范、测试命令、不能动的文件。放在项目根目录。没有AI工具也无所谓，先写好，以后用到的时候你会感谢自己。
- 01试一次Plan Mode： 下一个涉及多文件改动的任务，强制自己先让AI出方案再动手。感受一下"先想后做"和"上来就改"的效率差距。
💬 你平时用AI写代码最多遇到什么问题？评论区聊聊，我帮你踩坑。
👆 觉得有用就点个「在看」👍，让更多人看到。
💬 回复「入群」加入AI交流群
💬 回复「咨询」获取一对一AI建议
💬 回复「清单」领取《2026 AI免费工具清单》
