AI 写代码,在 2026 年已经不是"要不要用"的问题,而是"用得好不好"的问题。我用 Claude Code、Cursor 这类工具高强度跑了一年多,一个越来越强烈的感受是:工具是同一个,但用得好和用得糟,产出的差距大到不像在用同一样东西 —— 有人靠它把效率翻几倍,有人靠它给自己埋了一堆迟早要还的债,甚至有人因为一次手滑把生产数据弄没了。
这篇不讲"AI 会不会取代程序员"这种宏大话题,只讲落地的东西:8 条我自己摔出来的实战习惯,加上"AI 到底擅长什么不擅长什么"的坦诚评估、一份 review AI 代码的检查清单、一个完整的工作流示例、主流工具的差异,以及五个最常见的误区。都是能直接抄进你日常的。文章有点长,但如果你每天都在和 AI 一起写代码,值得花二十分钟读完。
先想清楚:AI 编程到底改变了什么
很多人对 AI 编程的预期从一开始就是错的。他们以为瓶颈在"AI 够不够聪明",于是天天等着下一个更强的模型。但现实是:当前主流大模型的代码能力,早就过了"够用"的线 —— 它能写出语法正确、结构清晰、考虑了不少情况的代码。真正的瓶颈,从来不在模型那一侧,而在人怎么驾驭它。
换个角度想,AI 就像一个手速极快、知识面极广,但有三个致命特点的搭档:第一,它完全不了解你项目的历史 —— 不知道某个文件三年前为什么这么写、不知道哪个看起来没用的配置其实是线上在依赖的;第二,它不会替你负责 —— 代码出了线上事故,半夜爬起来的是你不是它;第三,它会非常自信地说出错误的话 —— 它的语气永远笃定,哪怕它在胡说。
一个会带这种搭档的资深开发者,产出会非常高;一个不会带的人,只会被它越带越乱。下面这 8 条习惯,本质上就是回答一个问题:面对这样一个搭档,你该怎么和它配合。
还要先破除一个心态:不要把"用了 AI"当成一种技能。真正的技能是"会用 AI"—— 这两者的差距,会在 2026 年之后越来越成为程序员之间的分水岭。
AI 擅长什么、不擅长什么:一份坦诚的评估
在讲习惯之前,先得对工具的能力边界有个清醒认识。盲目高估和盲目低估,都会让你用不好它。
AI 真正擅长的:
- 有明确模式的、重复性的代码:CRUD 接口、表单、数据转换、把一种格式改成另一种格式 —— 这些它又快又好。
- "我知道要做什么,但记不清具体 API"的场景:某个库的用法、某个正则的写法、某个命令的参数 —— 它是比文档更快的查询入口。
- 翻译和解释:把一段你看不懂的代码讲清楚、把报错信息翻译成人话、把伪代码变成真代码。
- "脚手架"工作:搭项目骨架、写配置文件、生成测试用例的框架。
- 第二意见:你写完一段代码,让它挑毛病、提替代方案 —— 它经常能看到你忽略的角度。
AI 不擅长、甚至会坑你的:
- 需要全局视野的决策:架构怎么分层、模块怎么拆、要不要引入某个技术 —— 这些它只能基于"通用最佳实践"给建议,给不了"针对你这个项目的最优解",因为它没有你项目的完整上下文。
- 边界情况和异常路径:它写的"正常流程"往往很漂亮,但空数组、null、并发、超长输入、网络中途断开 —— 这些它经常想不全。
- "看起来对其实错"的细节:差一错误(off-by-one)、条件写反、异步时序、浮点比较 —— 这类 bug 它写起来毫无心理负担。
- 新的、小众的、刚更新的东西:它的知识有截止时间,某个库上周刚发的破坏性更新,它不知道,还会很自信地用旧 API。
- 判断"什么时候该停":一个问题它解不了,它不会承认,只会继续猜、继续试,把代码越改越乱。
把这张能力清单记在心里,下面 8 条习惯就都有了出处 —— 它们本质上都是在放大 AI 的长处、对冲 AI 的短处。
习惯一:先让它读,再让它写
最高频、也最致命的错误,就是一上来直接"帮我实现某某功能"。AI 不是不会写,而是它会基于错误的假设写 —— 它没读你的代码,就开始脑补你的目录结构、命名风格、已有的工具函数、状态管理方式,然后写出一坨"语法没错、但和你项目处处格格不入"的东西。你拿到之后,要么大改,要么干脆推翻重来。
✗ 一上来就下命令(它会基于脑补的项目结构开写): "帮我把用户模块重构一下" ✓ 先对齐理解,再动手: "先读 src/modules/user/ 下的文件,说说这个模块现在是怎么组织的、 依赖关系是什么、你觉得哪里值得重构 —— 这一步先别改任何代码"
正确的顺序永远是:先让它读相关文件 → 让它复述一遍它的理解 → 你确认它没跑偏 → 再让它动手。这一步看着慢,实际上是整个流程里最省时间的。算一笔账:让它先花两分钟读一遍相关文件,成本是两分钟;它因为没读、基于错误假设写了一大段,你 review 出问题、解释、让它返工,成本是半小时起。这个账怎么算都划算。
更深一层的道理:AI 产出的质量,上限是由你给的上下文决定的,不是由模型能力决定的。同一个模型,你给够上下文,它能写出贴合项目的代码;你不给,它再聪明也只能猜。所以"让它读"不是一个礼貌性的步骤,而是直接决定结果好坏的关键动作。
实践中还有个小技巧:让它读完之后,不要只问"你读懂了吗",而要问"按你的理解,这个功能应该改动哪几个文件、大概怎么改"。它的回答会立刻暴露它有没有真的理解 —— 如果它说的文件和改法明显不对,你现在纠正的成本,远低于它写完之后。
习惯二:任务切小,一次只推进一步
"重构整个模块""把这个页面从 Vue 2 迁到 Vue 3""加一个完整的权限系统" —— 这种大任务直接整个丢给 AI,会出两个问题。
第一个是逻辑漂移:它写到一半,前半段按 A 思路写,后半段不知不觉换成了 B 思路,最后给你一个自相矛盾、还跑不起来的结果。模型在长输出里保持一致性的能力是有限的,任务越大、输出越长,漂移越严重。
第二个是你失去了把关能力:改动一旦很大,你根本没法逐行 review,只能"整体接受"或"整体拒绝"。而"整体接受"一段你没仔细看过的大改动,就是在赌运气。
把它拆开:"先把这个函数抽出来" → 验证 → "再给它加错误处理" → 验证 → "现在改调用方" → 验证。每一步都小到你能一眼看明白对错,翻车了也好回退 —— 大不了退回上一步。小步快跑、步步可验证,是和 AI 协作的核心节奏。
怎么判断"步子是不是切得够小"?一个简单的标准:如果这一步的改动,你没法在一两分钟内 review 完并确认它是对的,那这一步就还是太大了。把它再拆。
这条习惯还有个附带好处:小步推进时,如果某一步它做错了,问题被隔离在那一小步里,你很容易定位;而大改动里出了 bug,你得在一大片改动里大海捞针。
习惯三:让它解释,不只让它给代码
拿到一段代码,别急着粘进项目。先问它:"为什么这样写?""这里有什么取舍?""换一种实现会怎样?""这段代码在什么情况下会出问题?"
这么做有个隐藏的、价值巨大的好处:它解释不清楚的地方,往往就是它自己也没想透的地方。你会发现,它有时候会在解释的过程中自己说:"这里我用了 X,不过其实 Y 可能更合适,因为……" —— 恭喜,你刚刚提前拆掉了一颗它本来要埋给你的雷。
更深一层:让 AI 解释,本质是逼它把"模式匹配出来的代码"重新过一遍逻辑。大模型生成代码,很大程度上是基于训练数据里的模式;但"解释这段代码为什么对",需要它真的走一遍推理。这个二次推理的过程,能筛掉相当一部分"似是而非"的实现。
具体怎么问也有讲究。不要只问"解释一下这段代码"(它会逐行翻译,没用),要问带判断性的问题:"这段代码的时间复杂度是多少,有没有更优的""如果输入是空数组会怎样""这里为什么不用 X 而用了 Y""这段代码最可能在哪种情况下出 bug"。带判断的问题,才能逼出它的真实思考。
习惯四:把测试当成缰绳
AI 写的代码"看着对"绝不等于"真的对"。它极其擅长写出那种逻辑顺、命名好、注释全,但边界情况一碰就碎的代码 —— 前面那张能力清单里说过,异常路径是它的弱项。
测试就是套在它身上的缰绳。具体怎么用:
- 有测试的项目:让它先写测试,或者边写实现边补测试。让测试把它的实现框死 —— 测试通过,至少说明它没跑偏到离谱。更进一步,你可以自己先写好测试用例(尤其是边界用例),让它去写"能通过这些测试"的实现。
- 没有测试的项目:至少自己手动跑一遍关键路径,而且要专门测它容易错的地方 —— 空输入、超大输入、并发、网络异常。
最不该信的一句话,是它说的"这样应该就没问题了"。"应该"两个字是免责声明,不是结论。每次看到它说"应该没问题""理论上可以""一般情况下没事",你都要把它当成一个明确的信号:这里它没把握,需要你来验证。
有了测试这条缰绳,你才能放心让 AI 跑快 —— 因为你知道,它一旦跑偏,测试会立刻把它拽回来。没有缰绳的"快",是危险的快。
习惯五:不可逆的操作,自己来
删文件、删分支、改数据库 schema、git push、git reset --hard、rm -rf、改 CI/CD 配置、改线上配置 —— 这些不可逆或影响面大的操作,AI 可以建议,但执行那一下,必须自己来。
原因前面说过:AI 的视野只有你给它的上下文,而你的视野里有它看不见的东西。它不知道你三天前那个还没提交的改动有多重要,不知道那个"看起来没用"的文件其实是线上定时任务在调,不知道你那个分支上还有没合并的工作。
这里的成本是极不对称的:让 AI 自动执行这些操作,顺利的话帮你省几秒钟;一次手滑,代价可能是几小时甚至几天的工作量,甚至是线上事故。用几小时的潜在损失,去换几秒钟的便利,这笔账显然不划算。
具体做法:让 AI 把它建议的危险命令列出来、解释清楚每条在做什么,你看明白了,自己复制执行,或者明确地一条条批准。在不可逆操作这件事上,"慢"就是"快",多确认一步永远不亏。
顺带说一个相关的好习惯:动手做任何有风险的改动之前,先 git stash 或者 git commit 一下,给自己留个能回退的存档点。这样即使 AI(或你自己)把事情搞砸了,你也能一键回到安全状态。
习惯六:它写的代码,你必须能看懂
这是底线中的底线。如果 AI 给你的代码,你看不懂、又懒得搞懂,就直接合进去了 —— 你刚刚给自己开了一笔利息很高的技术债。
想象一下三个月后的场景:这段代码出了 bug,你打开它,面对的是一段"在自己项目里、但自己完全不认识"的代码。你不知道它为什么这么写,不知道改动它会牵连什么,不知道它的边界假设是什么。那种"我在维护一个陌生人的代码,而这个陌生人是三个月前的 AI"的绝望感,谁试谁知道。
处理办法只有两个,没有第三个:要么让它讲到你真的懂为止(回到习惯三),要么让它换一个你 hold 得住的方案。如果一段实现你怎么都理解不了,那它对你来说就不是"能用的代码",而是"定时炸弹"。
这条还有个反向的提醒:不要因为"AI 写的看起来很专业、很高级",就默认它是对的、是好的。"高级"不等于"适合你的项目"。有时候 AI 会用一些花哨的写法、引入一些重型的抽象,显得很厉害,但对你这个具体场景其实是过度设计。代码最终是你在维护,可读、可改、你 hold 得住,比"看起来高级"重要得多。
习惯七:上下文喂够,别让它猜
习惯一说的是"让它读现有代码",这一条更进一步:把项目里那些没写在代码里、但团队人人默认的约定,明确地告诉它。技术栈选型的理由、命名规范、目录约定、"我们这个项目坚决不做什么" —— 这些 AI 是猜不到的,代码里也读不出来,只能靠你喂。
最省事、也最有效的做法,是把这些约定写进一个固定的规则文件(Claude Code 里是 CLAUDE.md,放在仓库根目录),让 AI 每次会话都自动先读它:
# 项目约定 CLAUDE.md(放仓库根目录,AI 每次会话先读) ## 技术栈 - 前端 Vue 3 + TypeScript + Vite,统一用 <script setup>,不要用 Options API - 状态管理用 Pinia,不要引入 Vuex - 网络请求统一走 src/api/,不要在组件里直接 fetch / axios ## 代码规范 - 组件文件 PascalCase,工具函数 camelCase - 错误处理用项目已有的 useError(),不要自己 try/catch 弹 alert - 不写裸 CSS,用项目里的 UnoCSS ## 协作方式 - 改代码前先读相关文件;跨多文件的改动,先给方案再动手 - 一次只改一处,改完等我确认再继续 - 提交信息用中文,遵循 conventional commits ## 红线(绝对不要做) - 不要自作主张升级依赖版本 - 不要删除我没明确要求删的文件 - 不要为了"健壮"加一堆永远走不到的兜底分支
有了这么一份文件,你就不用每次对话都重复交代一遍,而且 AI 的产出会稳定地贴合你项目的风格。新人入职要读的那些"项目潜规则",AI 也一样需要 —— CLAUDE.md 就是写给 AI 的"入职文档"。
更重要的是,这份文件是一份会"增值"的资产。它不是写一次就完事的:每次 AI 踩了一个坑、或者你纠正了它一个习惯,就往里加一条。比如它又一次在组件里直接 fetch 了,你就加一条"不要在组件里直接发请求";它又自作主张升级了依赖,你就加一条红线。这样用下去,这份文件会越来越懂你的项目,AI 也会越用越顺手。维护好 CLAUDE.md,是投入产出比最高的一件事。
习惯八:学会判断什么时候该停手
有一种非常典型的翻车场景,几乎每个深度用 AI 的人都经历过:某个 bug,AI 改了一版没好,你说"还是不行",它再改一版,引入了新问题,你再说"不对",它又改…… 三五个来回之后,代码已经被它改得面目全非,而最初那个问题还在,甚至更严重了。
这时候必须果断踩刹车。要理解一个事实:AI 陷入"猜测—试错"循环时,它不会自己停下来,也不会承认"我搞不定" —— 它只会继续猜、继续打补丁,越改越乱。指望它自己跳出循环,是不现实的。
正确的做法是:识别到"它已经不在解决问题、只在打补丁"这个信号,立刻回退到最初的版本(这也是习惯五里"留存档点"的价值),然后自己花十分钟,把问题本身搞清楚 —— 到底是哪里错了、为什么错。搞清楚之后,你可以用习惯一、习惯二的方式重新带它一遍(给它你刚搞明白的上下文),或者干脆这一段自己写。
怎么识别"该停手了"的信号?几个典型特征:它的每一版改动都在"加东西"而不是"理解问题";它开始说"让我换个思路试试"(它其实没思路);同一个错误反复出现、只是换了个形式;你已经分不清现在的代码和最初的差在哪了。出现这些,就是刹车信号。知道什么时候不该用 AI,本身就是"会用 AI"的一部分。
怎么 review AI 写的代码
前面反复强调"把关",但"把关"具体看什么?Review 人写的代码和 review AI 写的代码,侧重点是不一样的。人写的代码,你大概知道这个人的水平和习惯;AI 写的代码,你要带着对它"能力清单"的认知去看 —— 重点盯它的弱项。
review AI 代码的一份检查清单: □ 它有没有"理解错需求"—— 做的是不是我真正要的那件事 □ 边界情况:空值 / 空数组 / null / 超长输入 / 并发,处理了吗 □ 有没有"看起来对、其实错"的逻辑(差一错误、条件取反、异步时序) □ 错误处理:是真的处理了,还是只是 catch 了之后吞掉 □ 有没有引入不必要的新依赖、新抽象、新文件 □ 命名、风格是否和项目现有代码一致 □ 它删改的地方,有没有顺手动了我没让它动的东西 □ 这段代码三个月后我自己还看得懂吗
这份清单里,最该花时间的是前三项:需求理解、边界情况、"看起来对其实错"的逻辑 —— 因为这正是 AI 最容易出问题、而表面又最不容易看出来的地方。AI 写的代码,"读起来通顺"几乎是必然的,所以"读起来通顺"不能成为你放行的理由。你要做的是主动去找它会错的地方,而不是被动地"看一遍没发现问题就过"。
一个实用的技巧:review 的时候,把它的代码当成一个你不信任的初级程序员写的来看。不是不尊重它,而是这种心态能让你保持该有的警惕 —— 你不会因为"它是 AI、应该挺厉害"就放松检查。
一个完整的工作流:从需求到合并
把上面的习惯串起来,一个真实需求的完整协作流程是这样的:
一个真实需求:"给订单详情页加一个'导出 PDF'按钮"
第 1 步【探索】"先读 src/views/order/OrderDetail.vue 和 src/api/order.ts,
说说这个页面现在的结构、数据是怎么来的 —— 先别改"
第 2 步【方案】"我想加一个导出 PDF 的功能。你给两个方案:前端直接生成、
和调后端接口生成,各自的优缺点,我来选"
第 3 步【实施】(选定方案后)"按方案 B,先在 src/api/order.ts 里加
exportOrderPdf(id) 方法,风格和现有接口保持一致 —— 只写这个函数"
第 4 步【测试】"给这个方法补单元测试,覆盖正常返回、接口 4xx、网络超时三种情况"
第 5 步【接 UI】"现在在 OrderDetail.vue 里加按钮,处理 loading 态和失败提示"
第 6 步【把关】我自己 review diff → 跑测试 → 手动点一遍 → 提交
注意这个流程的几个特征:每一步都小、都可验证;读和方案在写之前;测试紧跟实现;最后的 review、跑测试、手动验证、提交,这几个"把关"动作始终是我自己做。
在这个流程里,AI 承担了大部分"打字"和"查资料"的工作 —— 它写了接口、写了测试框架、写了 UI 代码。但所有的"判断" —— 选哪个方案、这一步对不对、能不能提交 —— 始终在我手上。这就是理想的人机分工:AI 负责"快",人负责"对"。
很多人觉得"这样一步步来,还不如我自己写快"。短期看,简单任务确实可能是。但这个流程的价值在复杂任务和长期:复杂任务里,AI 把你从大量机械劳动里解放出来,你能把精力集中在判断和设计上;长期看,因为每一步都把关了,你不会积累技术债,后期不会被反噬。
主流 AI 编程工具的取向差异
上面讲的习惯是通用的,但几个主流工具的取向确实不同,选对工具能让习惯落地得更顺:
- Claude Code(命令行):擅长跨多文件的任务,能自己跑命令、跑测试、读项目结构。它适合"派活"式的工作流 —— 你交给它一个相对完整的任务,它自己探索、实施、验证一阵,再回来汇报。它的上下文管理和工具调用是强项,
CLAUDE.md、子代理这些机制也是为这种工作流设计的。 - Cursor(编辑器):深度集成在编辑器里,实时补全(Tab)的体验是最好的。它适合"结对"式的工作流 —— 你在写,它在旁边帮,你写一半它补一半。喜欢手不离键盘、紧密协作的人会很喜欢它。
- GitHub Copilot:最成熟、最稳定的行内补全,生态最广。它在"补全"这件事上打磨得很好,但"agent 式"地把一整个任务交给它的能力,相对前两者弱一些。
没有哪个绝对最好,关键看你的工作方式:习惯"派活"就偏 Claude Code,习惯"结对"就偏 Cursor,只想要个稳定的补全就用 Copilot。但不管用哪个,上面 8 条习惯都适用 —— 工具决定下限,习惯决定上限。换工具能让你舒服一点,但不会让一个不会带 AI 的人突然变得会带。
团队里用 AI:协作方式也要跟着变
前面讲的是个人怎么用 AI。但当一个团队都开始用 AI,有些协作规则需要跟着调整,否则会出乱子。
Code Review 要更严,而不是更松。有人觉得"AI 写的代码质量不错,review 可以放松了" —— 恰恰相反。AI 让每个人的代码产出量暴涨,但产出量涨了不代表质量涨了,reviewer 面对的"待审代码"反而更多了。而且 AI 代码"读起来通顺"的特点,会让 reviewer 更容易松懈。团队要明确:AI 写的代码和人写的代码,适用同样的质量标准,review 不打折。
"谁提交谁负责"这条不能因为 AI 变。不能出现"这段是 AI 写的,出问题不怪我"的心态。提交者就是责任人,无论代码是谁(或什么)写的。这条立住了,大家才会认真把关。
项目的 CLAUDE.md 应该是团队共享、共同维护的。它沉淀的是团队的集体约定,不该是每个人各写一份。把它纳入版本管理,像维护文档一样维护它。
警惕"AI 同质化"。如果团队所有人都用 AI、都不加思考地接受它的默认方案,代码会慢慢变得"千篇一律地平庸" —— 都是 AI 眼里的"标准做法",缺少针对项目的巧思。保持"人的判断"在环路里,是对冲这种同质化的关键。
五个最常见的误区
误区一:把 AI 当成"全自动"。觉得只要把需求描述清楚,它就该给出能直接上线的代码。现实是它给的永远是"初稿",把关、补测试、验证边界永远是你的活。指望"描述完就能用",一定会被坑。
误区二:把 AI 当成"高级补全"。这是另一个极端 —— 只敢让它补几行代码,不敢把完整任务交给它。这严重低估了它能承担的工作量,等于买了跑车只用来在小区里代步。
误区三:不读它的代码就提交。前面反复说了,这是所有误区里代价最高的一个,不展开了。
误区四:让它一次做太大的事。对应习惯二。大任务不拆,既会逻辑漂移,又让你失去把关能力。
误区五:它说什么信什么。AI 的语气永远是笃定的,但笃定 ≠ 正确。它会非常自信地引用一个不存在的 API、非常自信地给一个有 bug 的实现。对它说的话,尤其是涉及具体 API、版本、配置的,要有"默认怀疑、动手验证"的习惯 —— 它说某个函数有某个参数,你去查一下;它说这么配能行,你跑一下试试。
常见疑问
用 AI 写代码,自己的能力会不会退化?取决于你怎么用。如果你"不读它的代码、不让它解释、出问题就让它瞎改",那确实会 —— 你只是在外包思考。但如果你坚持"让它解释、自己 review、自己做判断",AI 反而是个很好的学习工具:它能让你快速接触到大量不同的写法和思路,关键是你得带着脑子用。退化的不是"用 AI 的人",是"用 AI 来代替思考的人"。
什么任务不适合用 AI?需要深度理解业务背景的核心决策、涉及安全和钱的关键逻辑、需要大量项目历史上下文才能做对的改动 —— 这些可以让 AI 当参谋,但主导权要在你手里。还有就是"你自己都没想清楚要什么"的时候,别指望 AI 帮你想清楚,它只会顺着你的模糊需求给你一个模糊的实现。
AI 给的代码引入了我不认识的库,怎么办?停下来。要么让它解释为什么需要这个库、有没有不引入新依赖的办法,要么自己评估这个库值不值得引入。不要因为"AI 用了"就默认这个依赖是合理的 —— 多一个依赖就是多一份维护成本和供应链风险。
写在最后
AI 编程不会让程序员失业,但它会拉大程序员之间的差距。真正的分水岭不在于"用不用 AI",而在于"会不会带 AI" —— 能不能给够上下文、拆对任务、在该把关的地方把住关、在该停手的时候停手、对它说的话保持该有的怀疑。
上面这 8 条习惯、加上 review 清单和那些误区,说到底就一句话:把判断权牢牢留在自己手上,把重复劳动尽管交给它。
做到这一点,AI 是你职业生涯里见过最好的搭档 —— 它让你从机械劳动里解放出来,去做真正需要人来做的事。做不到,它就是你见过最快的麻烦制造机 —— 它会用前所未有的速度,帮你把项目推向失控。
工具已经摆在这里了。决定它是助力还是负担的,从来不是工具本身,是用它的人。
—— 别看了 · 2026