我第一次让 ChatGPT 写代码，是让它写个 Python 爬虫。它给了我一份看起来很完整的代码，我直接跑——报错。把报错贴回去，它道歉、改完、再报错。三个来回之后我悟了：不是 AI 不会写代码，是我不会跟 AI 聊代码。 下面这个复盘，是我交了几个月学费换来的。
坑一：需求描述太潦草#
早期我经常这样问：“写个用户登录功能。” 拿到的代码当然能跑，但和我的项目八竿子打不着——框架不对、数据库不对、鉴权方式不对。
正确姿势分四步：
- 先给上下文：项目用的什么语言、框架、数据库，一句话交代。比如"我在用 Python + FastAPI + PostgreSQL"。
- 说清输入输出：函数接收什么参数、返回什么，别让它猜。
- 限定边界：要不要异常处理、支不支持并发、性能有没有要求。
- 要解释不要只要代码：让它讲清思路，你 review 思路比 review 代码快得多。
坑二：拿它当搜索引擎用#
“FastAPI 怎么实现 JWT？"——这种问题直接问，拿到的往往是某个旧版本的写法。2025 年的库版本迭代快，AI 的知识有截止线，涉及具体 API 时，它的答案可能是"过期但自信"的。
我的做法是：让它给思路和伪代码，具体 API 去官方文档核对。或者反过来：我把文档链接和报错信息贴给它，让它基于最新信息帮我定位。调试类问题的标准流程：
- 贴完整报错信息（别只贴最后一行）。
- 贴出相关代码片段和环境版本。
- 让它先分析"可能的原因有哪几个”，而不是直接要答案。
- 按它给的排查顺序逐个验证，把结果反馈回去。
坑三：无脑接受重构建议#
让 AI 重构代码是真香，但有个前提：你得有测试兜底。我吃过最大的亏，就是让它重构了一个没测试的核心模块，重构完"看起来"更优雅了，上线后出了个边界 case 的 bug。
现在我的重构流程是固定的：先让 AI 写测试用例（针对现有代码的行为），跑通；再让它重构；重构完跑测试。测试全绿才算完。写注释也是同理——让它给函数写 docstring，写完我扫一遍，错的基本都是它"脑补"的业务逻辑。
三个立竿见影的提示词模板#
- 调试：“下面这段代码在 [环境版本] 下报错 [报错信息]，相关代码如下 [代码]。请先列出 3 个最可能的原因，再逐个给出验证方法。”
- 重构：“重构下面这段代码，要求：保持对外接口不变、补充异常处理、用 [项目规范] 的命名风格。重构后说明你改了哪几处、为什么。”
- 注释：“为下面每个函数写中文 docstring，说明参数、返回值和可能的异常。不确定的业务逻辑标出来，不要脑补。”
结对编程的正确姿势：让它当副驾驶，不是代驾#
用熟了之后，我的工作流固定成了"结对编程"模式：
- 我定方向：需求拆解、技术选型、架构设计，这些我来，AI 不参与决策。
- 它写初稿：具体的函数实现、样板代码、测试用例，丢给它写初稿。
- 我审查：重点看边界条件、异常处理、业务逻辑——这三处是它最容易翻车的地方。
- 它修，我验：有问题让它改，改完我跑测试验证，形成闭环。
这个模式下，它是个不知疲倦的副驾驶：打字快、不抱怨、随叫随到。但方向盘必须在你手里。什么时候你发现自己在"无脑复制它的代码"，就是该停下来 review 的时候了——那一刻你不是在提效，是在攒技术债。
AI 写代码的边界#
实测下来，AI 最擅长的是：样板代码、正则表达式、SQL 查询、单函数逻辑、报错解读；最不擅长的是：跨文件的架构设计、业务逻辑判断、最新版本的 API 细节。前者放心用，后者它只能打辅助。
另外，如果你写代码的主力场景在编辑器里，Cursor 这类 AI 原生编辑器比网页版 ChatGPT 顺得多，入门看Cursor 指南。提示词的基本功可以看提示词工程入门。注册账号遇到问题，参考Claude 注册教程里的网络环境部分（对 ChatGPT 同样适用）。
一句话复盘：AI 写代码的质量，取决于你"聊代码"的能力。上下文给得越全、验证越严格，它越像个靠谱的结对伙伴；反之，它就是个自信满满的实习生——代码能跑，但你得盯着。