AI辅助开发实战：从结对编程到代码审查的落地经验

AI 辅助开发这件事，我从最初把它当"高级自动补全"用，到现在把它当成日常开发流程里绕不开的一环，中间踩过的坑、交过的学费，比看过的教程多得多。网上关于 AI 编程的文章，要么是清一色的"效率提升十倍"式吹捧，要么是"AI 写的代码全是 bug"式全盘否定，真正把"什么场景该用、什么场景别碰、怎么用才不给自己挖坑"讲透的，少。这篇就聊聊我自己在真实项目里用 AI 辅助开发的一些体会，不吹不黑，只讲能落地的经验。不管你是刚接触 AI 编程的新手，还是已经用了一段时间但总觉得"差点意思"的老手，应该都能从里面找到点有用的东西。

1. 先想清楚 AI 在开发流程里到底站在哪个位置

1.1 它不是"替你写代码的人"，而是"随时在线的结对伙伴"

很多人对 AI 辅助开发的第一印象就是"我描述需求，它给我代码"。这个理解不能说错，但太窄了。我用了大半年之后最大的感受是：AI 真正的价值不在于替你敲键盘，而在于它永远在线、永远不会不耐烦、永远愿意陪你把一个问题从不同角度捋一遍。

你想想真实的结对编程是什么样：你旁边坐一个经验不错的同事，你写代码的时候他偶尔瞄一眼说"这里边界没处理"，你卡住的时候他跟你一起画图理思路，你写完他帮你 review 一遍。AI 现在能做的，恰恰是这些"辅助性"的工作，而不是"替代性"的工作。把它当成结对伙伴，你的用法会完全不一样——你会开始让它解释代码、让它挑毛病、让它给多个方案对比，而不是只让它吐代码。

这个定位一旦摆正，很多纠结就没了。你不会再纠结"它写的代码能不能直接用"，因为结对伙伴写的代码你本来也要 review；你也不会再抱怨"它不懂我的业务"，因为新来的同事本来也需要你讲背景。

1.2 三个最容易被高估和低估的能力

我观察下来，大家对 AI 的能力判断普遍存在偏差。被高估的通常是这三样：

• 复杂业务逻辑的准确实现。你描述一个涉及多状态流转、多角色权限、历史数据兼容的需求，它给你的代码往往"看起来对，跑起来错"。因为它没有你系统的完整上下文，只能靠猜。
• 对老代码库的理解。你扔给它一个几千行的祖传模块让它改，它大概率会改出新 bug，因为它看不到这个模块和其他模块之间那些没写在代码里的约定。
• 性能敏感场景的优化。它给的优化建议经常是教科书式的，但你的瓶颈可能根本不在它以为的地方。

被低估的反而是一些"脏活累活"：

• 样板代码和胶水代码的生成。DTO 转换、配置文件、单元测试骨架、正则表达式，这些它又快又准。
• 陌生技术栈的上手。你第一次用某个库，让它给个最小可运行示例，比翻文档快得多。
• 代码解释和文档生成。接手别人的代码，让它逐段解释，效率提升非常明显。

把这两组能力记在心里，你就知道什么时候该找它、什么时候该自己上。

1.3 一个反直觉的结论：越简单的任务，AI 的收益反而越不稳定

这点可能和直觉相反。很多人以为简单任务 AI 肯定做得好，复杂任务才容易翻车。但实际用下来，复杂任务因为你会格外谨慎地 review，反而出不了大问题；简单任务因为你觉得"这还用看？"，直接复制粘贴，结果它给你埋了个隐蔽的坑，你半天才发现。

举个例子，让 AI 写一个"判断字符串是否为合法邮箱"的正则，它给你的正则可能漏掉某些边界情况，比如连续的点、开头结尾的点。这种小函数你根本不会细看，直接用了，等到线上出问题才回头查。所以我的原则是：越是简单到你觉得不用看的代码，越要扫一眼。这不是不信任 AI，而是不信任"自己会偷懒"这件事。

2. 提示词写得好不好，直接决定你是在提效还是在返工

2.1 把 AI 当新人：背景、约束、期望，一个都不能少

我见过太多人这样用 AI：打开对话框，敲一句"帮我写个登录功能"，然后对着返回的代码发愁——因为返回的东西跟他的项目结构、技术栈、鉴权方案完全不搭。

正确的做法是把它当成一个刚入职、技术不错但完全不了解你项目的新人。你会怎么给新人派活？你肯定会说清楚：我们用什么框架、这个功能在哪个模块、有什么现成的工具类可以复用、有什么坑要避开。对 AI 也一样。

一个我常用的提示词结构是这样的：

背景：这是一个基于 XX 框架的 XX 系统，用户认证用的是 XX 方案。 任务：实现 XX 功能。 约束： - 复用现有的 XX 工具类，不要重复造轮子 - 错误处理遵循项目现有的 XX 规范 - 不要引入新的第三方依赖 期望输出：完整的函数实现 + 关键逻辑的注释 + 边界情况说明

这个结构看起来啰嗦，但它能帮你省掉后面反复来回改的时间。我实测下来，把背景和约束写清楚，一次就能用的概率能从三成提到七成以上。

2.2 让它先给方案再写代码，能挡掉一半的返工

这是我最想推荐的一个习惯：不要让它直接写代码，先让它给方案。

比如你要做一个数据导出功能，别上来就说"写个导出 Excel 的代码"。先说"我要做一个数据导出功能，数据量大概十万条，用户可能同时导出，你给几个技术方案，说明各自的优缺点"。它会给你流式导出、分批查询、异步任务等几个方向，你挑一个，再让它基于选定的方案写代码。

这样做的好处是，方案层面的错误在写代码之前就被拦住了。如果它直接写代码，你可能要等到代码写完、跑起来发现内存爆了，才意识到方案本身就有问题。先聊方案，等于把"返工"的成本从"重写代码"降到"重新讨论"。

2.3 迭代式对话比一次性长提示词更靠谱

有些人喜欢憋一个超长的提示词，把所有要求一次性塞进去。我试过，效果不稳定——提示词太长，AI 反而会顾此失彼，抓住后面忘了前面。

更靠谱的方式是迭代式对话。先给核心需求，拿到初版，然后针对性地提修改意见："这里错误处理太简单了，加上重试逻辑""这个函数太长了，拆成两个""性能上有没有优化空间"。每一轮只聚焦一两个点，AI 的响应质量明显更高。

这就像 code review，你不会一次性给同事提二十条意见，而是一条一条来。对话式迭代的本质，就是把 review 融进了生成过程。

2.4 几个我踩过坑才总结出来的提示词禁忌

• 别用"优化一下"这种模糊指令。你说"优化"，它可能改可读性，可能改性能，可能改结构，方向完全不可控。要说清楚优化什么："减少数据库查询次数""降低这个函数的时间复杂度"。
• 别让它猜你的意图。你觉得"这个很明显啊"，它不觉得。宁可多打几个字说清楚，也别让它猜。
• 别在同一个对话里聊太多不相关的事。上下文会互相干扰，聊到后面它可能把前面任务的设定带进来。一个任务一个对话，或者及时开新对话。

3. 代码 review 这一关，AI 时代反而更重要了

3.1 AI 生成的代码有它自己的"味道"，你得学会识别

用久了你会发现，AI 写的代码有一些共性特征，识别这些特征能帮你快速定位潜在问题：

• 过度防御。它特别喜欢加各种 null 检查、try-catch，有时候防御到冗余的程度。这些防御本身没错，但可能掩盖了真正的问题——比如一个不该为 null 的地方它给你包了层判断，结果真正的 bug 被吞掉了。
• 边界处理想当然。空数组、负数、超长字符串、并发，这些边界它经常处理得不完整，或者处理方式和你的业务预期不一致。
• 命名和风格不统一。它可能这个函数用驼峰，那个用下划线，和你的项目规范对不上。
• 注释比代码还多，但注释说的是"做了什么"而不是"为什么"。真正有价值的注释是解释"为什么这么写"，它给的注释往往是废话式的复述。

知道这些特征，你 review 的时候就有重点了：先看边界，再看防御逻辑有没有吞异常，最后统一风格。

3.2 把 AI 也拉进来做 review，形成"双人复核"

有意思的是，AI 不仅能写代码，还能 review 代码。我现在的习惯是：AI 写完的代码，我让另一个对话（或者同一个对话换个角度）来 review 一遍，专门找问题。

提示词可以这样写："以下代码是我刚写的，请你以严格的 code reviewer 身份，找出其中的 bug、边界问题、性能隐患和可读性问题，不要客气。"它经常能挑出一些我自己没注意到的东西。

当然，它 review 出来的问题也要你自己判断，有些是误报。但"AI 写 + AI 审 + 人终审"这个三层结构，比"AI 写 + 人审"要稳得多。相当于你多了个不知疲倦的复核员。

3.3 测试用例是 AI 辅助开发里性价比最高的产出

如果要我选一个 AI 辅助开发中"投入产出比最高"的环节，我会选写测试。

原因很简单：测试代码逻辑相对独立、模式化强、对业务上下文依赖低，正好是 AI 的强项。而且测试代码写错了，跑一下就知道，反馈极快。

我的做法是：功能代码写完后，让 AI 基于这个函数生成单元测试，覆盖正常路径、边界情况、异常情况。然后我跑一遍，看哪些测试挂了——挂掉的要么是测试写错了，要么是功能代码有 bug，两种情况都值得深挖。

这里有个小技巧：让 AI 生成测试的时候，明确告诉它"要覆盖哪些边界"，比如"请覆盖空输入、超长输入、特殊字符、并发调用这几种情况"。不然它默认只测正常路径，覆盖度不够。

4. 不同开发场景下，AI 的用法完全不一样

4.1 新项目从零搭建：让 AI 当"脚手架 + 顾问"

新项目是 AI 最能发挥的场景之一，因为没有历史包袱，上下文干净。

我的流程通常是：先跟 AI 聊技术选型，把需求、团队技术栈、预期规模告诉它，让它给几个方案对比；选定后让它生成项目骨架、目录结构、基础配置；然后一个模块一个模块地实现。

这个阶段有个坑要注意：别让 AI 一次性生成整个项目。它生成的代码量一大，质量就断崖式下降，而且你根本 review 不过来。正确做法是按模块推进，每个模块跑通、测过、review 过，再进下一个。

另外，新项目阶段让 AI 帮你写 README、接口文档、部署脚本，效率也很高。这些文档类产出，AI 的质量普遍不错。

4.2 老项目维护：AI 是"翻译官"和"局部手术刀"

老项目是另一个极端。你面对的是几千上万行祖传代码，AI 看不到全貌，直接让它改风险很大。

这个场景下我主要用 AI 做两件事：

一是当翻译官。接手一个陌生模块，让 AI 逐段解释这段代码在干什么、可能有什么副作用、和哪些地方有耦合。它解释得不一定全对，但能帮你快速建立初步认知，比你自己一行行啃快得多。

二是当局部手术刀。改一个小函数、加一个字段、修一个明确的 bug，这种范围可控的任务，AI 做得很好。关键是把改动范围框死，明确告诉它"只改这个函数，不要动其他任何地方"。

老项目里最忌讳的是让 AI"重构一下这个模块"。它不知道你项目里那些隐式约定，重构出来的东西大概率跑不起来。

4.3 调试排错：让 AI 帮你缩小范围，而不是直接给答案

遇到 bug 的时候，很多人直接把报错信息扔给 AI 问"怎么解决"。这样用不是不行，但效率不高，因为它给的答案经常是泛泛的、网上抄来的。

更好的用法是让 AI 帮你缩小排查范围。比如："这段代码在 XX 情况下报 XX 错误，我怀疑是 A 或 B 导致的，你帮我分析一下哪种可能性更大，以及怎么验证。"它会给你一个排查思路，你按着思路去验证，比直接要答案靠谱得多。

还有一个我常用的技巧：把相关的代码、日志、报错一起贴给它，让它"扮演一个经验丰富的调试者，列出所有可能的原因，按可能性排序"。这个"按可能性排序"很关键，能帮你优先排查最可能的方向。

4.4 学习新技术：AI 是最好的"陪练"

学一个新框架、新语言的时候，AI 的价值特别大。你可以让它给你出练习题、陪你一步步实现、在你卡住的时候给提示而不是直接给答案。

我学一个新东西的套路是：先让 AI 用一段话讲清楚这个技术的核心概念和适用场景；然后让它给一个最小可运行示例，我跑一遍；然后让它基于这个示例出几个循序渐进的练习题，我自己做，做完让它批改。

这个"讲解 + 示例 + 练习 + 批改"的循环，比看视频教程效率高，因为节奏完全由你控制，卡在哪就多练哪。

5. 那些没人告诉你、但一定会遇到的坑

5.1 幻觉：它会一本正经地编造不存在的 API

这是 AI 辅助开发里最危险的坑。它会用非常自信的语气告诉你"调用 XXX 方法即可"，而那个方法根本不存在，或者参数完全不对。

我踩过最惨的一次，是它给我编了一个第三方库的方法，我照着写了，编译直接报错，查了半天文档才发现那个方法压根没有。

防这个坑的办法只有一个：凡是涉及具体 API、库函数、配置项的，一律去官方文档核对。别嫌麻烦，这一步省不得。尤其是版本相关的 API，AI 的训练数据可能滞后，它给的是老版本的用法。

5.2 上下文丢失：聊到后面它忘了前面说过什么

长对话里，AI 会"忘记"前面的设定。你前面说了"用 Python 3.10 的语法"，聊到后面它可能给你整出个 3.6 的写法。

应对办法是：关键约束在每轮对话里重复强调，或者把核心设定整理成一段"项目背景"，每次开新对话都带上。别指望它记住所有东西，它的记忆是有限的。

5.3 安全与合规：生成的代码可能带隐患

AI 生成的代码，在安全方面经常有疏漏。比如 SQL 拼接没做参数化、用户输入没做校验、敏感信息硬编码、依赖了有已知漏洞的库版本。

这些在功能测试阶段往往发现不了，因为功能是正常的。但上线之后就是定时炸弹。所以涉及安全相关的代码——认证、授权、数据访问、加密——AI 生成的版本一定要人工重点审查，或者干脆自己写。

5.4 依赖膨胀：它喜欢引入新库

AI 特别爱用第三方库来解决问题，一个简单的功能它能给你引入三四个依赖。这在个人项目里无所谓，在团队项目里就是灾难——依赖越多，维护成本越高，安全面越大。

我的做法是在提示词里明确写"不要引入新的第三方依赖，用标准库或项目现有依赖实现"。这一句话能挡掉很多麻烦。

5.5 版权与合规：生成代码的来源要心里有数

AI 生成的代码，可能和某些开源项目高度相似。在商业项目里用，理论上存在合规风险。我的建议是：核心业务逻辑、有商业价值的算法，尽量自己写或者深度改写；AI 生成的通用代码，用之前心里有个数，必要时做一下相似度检查。这不是危言耸听，是给自己留条后路。

6. 把 AI 用出"团队感"：多工具协作的实践

6.1 不同工具擅长不同的事，别指望一个工具包打天下

现在 AI 编程工具很多，各有侧重。有的擅长代码补全，有的擅长对话式开发，有的擅长处理大代码库。我的经验是别死磕一个工具，根据任务类型切换。

比如写新功能的时候，我用对话式工具聊方案、写代码；改 bug 的时候，用能读取整个项目上下文的工具；写测试和文档的时候，用哪个顺手用哪个。工具是为人服务的，不是反过来。

6.2 让 AI 之间互相"打架"，能逼出更好的方案

这是个进阶技巧：同一个问题，问两个不同的 AI，把它们的答案放一起对比。你会发现它们给的方案经常不一样，各有各的道理。对比的过程，本身就是一次深度思考。

我做过一次技术选型，把同一个需求分别问了两个 AI，一个推荐方案 A，一个推荐方案 B。我把 A 的方案拿给 B 挑毛病，把 B 的方案拿给 A 挑毛病，来回几轮，最后综合出来的方案比我一开始想的周全得多。

6.3 建立自己的"提示词库"，把好用的沉淀下来

用久了你会发现，有些提示词特别好用，反复用。把这些沉淀下来，形成自己的提示词库，是提升效率的关键。

我的提示词库大概分几类：代码生成类（带背景约束的模板）、代码 review 类、测试生成类、文档生成类、调试分析类。每类存几个经过验证的模板，用的时候改改细节就行，不用每次从零想。

这个库是越用越值钱的资产。别人还在纠结怎么问的时候，你已经把活干完了。

7. 心态：别神化，也别妖魔化

聊了这么多具体的东西，最后说点心态层面的。AI 辅助开发这件事，最大的障碍往往不是技术，是心态。

一种极端是神化：觉得 AI 什么都能干，自己不用学了，什么都交给它。这种心态的人，用不了多久就会发现自己在原地踏步——因为你不理解它生成的代码，出了问题你修不了，需求变了你也改不动。AI 是放大器，放大的是你已有的能力，你本身能力不行，它放大出来的也是不行。

另一种极端是妖魔化：觉得 AI 写的代码都是垃圾，坚决不用。这种心态的人，会眼睁睁看着别人效率翻倍，自己还在手敲样板代码。工具本身没有对错，关键是怎么用。

我的心态是：把 AI 当成一个能力不错但需要管理的协作者。它帮我处理重复劳动，我负责判断方向、把控质量、承担最终责任。代码是我提交的，出了问题是我负责，这个责任 AI 背不了。想清楚这一点，你就知道该怎么用它了。

用到现在，我最大的体会是：AI 没有让我变懒，反而让我对代码质量的要求更高了。因为生成代码的成本降低了，review 和判断的价值就凸显出来了。以前我可能花八成时间写代码、两成时间 review，现在反过来了，写代码的时间大幅压缩，省下来的时间全花在思考方案、审查质量、打磨细节上。这其实是件好事——它逼着开发者从"码农"往"工程师"的方向走。

如果你现在还在纠结要不要用 AI 辅助开发，我的建议是：先用起来，从最简单的场景开始，比如让它写个工具函数、生成个测试。用着用着，你自然会找到适合自己的节奏。别人的经验只能参考，真正的用法得自己在项目里磨出来。