很多人跟我说，AI写代码就是“人工智障”，让它写个排序算法都能跑出一堆莫名其妙的报错。我一开始也这么觉得，直到我花了两周时间认真研究了一下自己到底是怎么提问的，才反应过来：不是AI太蠢，是我根本没把它当副驾驶，而是当成了一个能读懂我心意的搜索引擎。你想想，你上了一辆车，副驾驶坐了个驾龄十年的老司机，结果你一句话不说就往路口冲，他能做的只有帮你拉手刹，甚至还会骂你几句——AI也是一样的道理。
这篇文章我打算写一份非常具体的用法指南，面向那些已经试过AI写代码但觉得“不好用”的人。我会把我在实际项目里总结出来的提问心法、提示词模板、工具选型、踩坑记录全部摊开来讲，争取让你看完之后，能把AI从“人工智障”调教成真正的“超级代码副驾驶”。
1. “人工智障”的真相：大多数人是把AI当搜索引擎用
先泼一盆冷水：市面上九成的“AI写代码翻车”案例，问题都不在模型本身，而在提问方式。
1.1 你问得越模糊，它答得越离谱
很多人第一次用AI写代码，开口就是“帮我写一个登录功能”。这句话拿到任何大模型面前，它都会陷入一种“你到底要什么”的迷茫状态——是网页登录还是App登录？用Session还是JWT？要不要验证码？需不需要第三方OAuth？数据库用MySQL还是PostgreSQL？密码加密用bcrypt还是argon2？
模型为了讨好你，只能挑一个它认为“最可能合理”的方案给你。于是你得到一段看起来像模像样、但和你项目结构完全不搭的代码。你贴进项目里，报错一片红，于是得出结论：AI是智障。
这就像你去餐厅只说了一句“给我来点吃的”，厨师端上来一碗牛肉面，你却说你要的是披萨——到底是谁的问题？
1.2 一次对话就要结果的“三句话定版”心态
还有一种心态更常见：觉得AI应该像搜索引擎一样，输入关键词就返回最终答案，而且一次就要对。一旦第一版不对，就立刻否定整个工具。
搜索引擎的工作模式是“你查词，我给链接”，责任在你自己去判断哪条链接靠谱。但AI编程工具的工作模式应该是“你提需求，我给方案”，方案是可以迭代的。第一版往往只是一个草稿，你需要像带实习生一样，指出这里不对、那里要改，它才能逐步接近你想要的成品。
换句话说，搜索引擎是“查一次，自己判”，AI是“聊一路，一起改”。带着“三句话就要定版”的预期去用AI，注定会失望。
1.3 忽略上下文上下文：AI没有记忆，只有窗口
另一个容易被忽略的点是：大多数AI对话窗口，每次对话其实是一次独立的上下文。你上午让它写了一个工具函数，下午问它“这个函数是不是有Bug”，它大概率会一脸茫然——因为你们之间的“记忆”已经在某个地方断了。
我见过一个典型的翻车场景：同事让AI写了一个Excel解析脚本，后来数据格式变了，他直接在同一个对话里问“为什么我这边又报错了”，AI却开始在完全不相关的方向上瞎猜。原因很简单，之前的解析逻辑、字段映射、异常信息通通没有体现在新的提问里，模型根本不知道你“又报错”的“又”是从哪来的。
所以，与其说是AI不聪明，不如说我们默认它“记得住”，但它的记忆就只存在于当前对话窗口。你需要主动把关键上下文喂回去。
2. 让AI听懂人话的核心心法：像指挥实习生一样下指令
搞清楚问题根源之后，解决方法其实就一句话：把AI当成一个聪明但没经验的实习生，你交代任务的态度，决定了它交付的质量。
2.1 角色设定：告诉AI它是谁、服务谁
实习生进组第一天，你得告诉他“你是这个项目的新成员，你的任务是帮我把支付模块重构掉”。AI也一样，指令里带角色设定，输出质量会完全不同。
我试过的对比例子很典型。直接问“写一个Python函数计算文件MD5”，它给你一个能用但毫无防御的版本；改成“你是一名Python后端工程师，请实现一个可用于生产环境的文件MD5计算函数，需要考虑超大文件读取、异常处理和返回格式统一”，输出立刻变严谨。
原理不难理解：当你给AI一个“资深工程师”的人设，它会在模型权重里寻找与这个角色匹配的表达习惯，输出自然更规范。这个技巧在所有主流AI编程工具里都适用。
2.2 任务拆解：一个函数一个函数地喂
实习生最怕你一口气丢给他“把登录模块做了”。他会手足无措。AI也一样，任务太大太笼统，它只能给你一个“看起来完整但处处是洞”的骨架。
更聪明的做法是把大任务拆成原子化的小任务：先写一个密码加密工具函数，再写一个用户查询接口，最后写一个登录路由。每个小任务都单独确认、单独验收，合在一起就是完整功能。
拆解的时候还有个小技巧：按文件的依赖顺序来。先写工具函数，再写业务逻辑，最后写接口层——这样AI每一步都有前一步的代码作为参考，生成的内容在逻辑上更难跑偏。
2.3 验收标准：说清楚“怎么样算好”
给实习生布置任务，光说“做完给我”不够，你得告诉他“做完的标准是什么”。代码任务也一样，你需要在提示词里明确验收维度。
最常见的验收维度有三个：
- 功能正确性：输入什么样、输出什么样，边界情况怎么处理
- 代码风格：遵循PEP8还是公司规范，是否需要类型注解
- 鲁棒性：是否需要try/except，是否要考虑超时、重试、并发
比如你让它写一个HTTP请求封装，如果不说“需要处理超时与重试”，它很可能给你一个裸的requests.get()，用不了多久就踩坑。验收标准写清楚，等于给AI装了导航，它才知道往哪儿开。
2.4 迭代修正：第一版不行就让它自己复盘
有一次我让AI写一个分页查询，它给出的SQL用了OFFSET，数据量一大就卡。我本来想直接重写，后来换了个方式：把报错信息和性能数据贴回去，补了一句“请先自己分析一下这个分页方式在深分页场景下的问题，再给出优化方案”。
它很快就提到了OFFSET深分页的性能缺陷，并主动改成了游标分页的思路。这个流程给我的启发是：不要只看结果，要让AI具备“自我纠错”的意识。你在提示词里加一句“先分析原因，再给代码”，它输出的质量会明显高一个档次。
3. 保姆级实操：一个万能提示词模板+四个高频场景演示
心法说完了，接下来是最直接的“抄作业”环节。我整理了一个万能提示词模板，再拆解四个高频场景的具体用法。
3.1 万能提示词模板
这个模板我在多个项目里反复调整过，最终版本长这样：
你是一名拥有5年经验的{语言/领域}工程师。现在需要你帮我完成一个任务： 【任务描述】 背景：{项目背景、代码仓库情况，以及和这个任务相关的上下文} 约束： - 技术栈：{语言、框架、数据库等} - 风格要求：{是否需要类型注解、遵循什么规范} - 边界条件：{需要考虑的异常、超时、并发等} 验收标准： - 输入X时，应该输出Y - 边界情况Z需要额外处理 请先给出实现思路，再提供完整代码，最后附上关键代码的说明。这个模板看起来有点长，但实际用熟了之后你不需要每次都完整写一遍——很多AI编程工具支持把类似的角色设定保存成定制指令或技能预设，直接复用就好。
3.2 场景一：生成一个带异常处理和参数校验的函数
假设我需要一个读取CSV文件并返回字典列表的函数。普通问法只会有两句：一句功能描述，加一句“请写Python代码”。高质量问法是这样的：
你是一名Python后端工程师。帮我写一个读取CSV文件的函数。 背景：数据量可能达到几十万行，文件可能包含脏数据，字段可能缺失。 约束： - 使用csv模块，不要引入pandas - 函数签名需要类型注解 - 对于缺失字段，用空字符串填充 - 文件不存在或编码错误时，抛出带上下文的异常 验收标准： 1. 正常场景：返回list[dict]，字段名与CSV表头一致 2. 异常场景：报错信息包含文件路径和具体原因 请先说明实现思路，再给代码。这样问出来的代码，和我自己在生产环境里写的几乎没什么差别。关键在于你把异常场景、数据体量、依赖约束都说清楚了，AI就不会踩那些“一看就是个玩具代码”的坑。
3.3 场景二：让AI修复一个报了堆栈错误的Bug
改Bug是最容易翻车的场景，因为大多数人只丢一句“帮我看看这个报错”，然后贴一堆堆栈信息。AI看不到堆栈之外的任何代码，只能盲猜。
正确的姿势是：把报错信息、相关代码、你本地的环境信息、你已经尝试过的方案，全部塞给它。比如：
你是一名Python开发工程师。我这段代码运行时报了KeyError，堆栈信息如下： {paste堆栈} 相关代码如下： {paste代码} 我已经确认过：配置文件中明明有这个键，但还是报错。我怀疑是在多线程环境下字典被其他地方修改了。 请帮我分析可能的原因，并给出修复方案和对应的代码。这里最关键的一句话是“我已经尝试过…”，它能快速帮AI排除掉一大批无效方向。实测下来，这种带“排查历史”的提问，比单纯甩报错信息要高效得多。
3.4 场景三：让AI解释一段看不懂的代码
看老项目代码常常是一种折磨。有一种高级用法是把AI当“代码讲解员”，让它不只告诉你这段代码在“做什么”，还要告诉你“为什么写成这样”。
我通常这么问：
你是一名擅长代码阅读的工程师。下面这段代码是从XXX老项目里摘出来的，我看不懂。 {paste代码} 请按以下方式解释： 1. 这段代码的核心功能是什么 2. 每一段关键逻辑的目的 3. 哪些地方是历史遗留写法，在现代版本中可以用什么替代 4. 如果我要把这段代码重构掉，需要注意什么风险这种提问方式特别适合接手老项目。AI给的回答往往能帮你节省至少半天时间，因为它会把一些看起来像“魔法”的写法翻译成正常人类能理解的语言，还会提醒你哪些地方动不得。
3.5 场景四：让AI补测试用例
写单测是大部分人最不爱干的活，但AI特别擅长，因为它不需要理解业务深意，只要按照“给定输入，验证输出”的模式来就行。
关键是要给它一个“测试基座”：
你是一名测试工程师。基于下面这个函数{paste代码}，帮我补充pytest测试用例。 要求： - 覆盖异常分支 - 对边界情况单独建用例 - 每个测试用例命名遵循test_xxx_场景_期望结果的风格 - 使用pytest.mark.parametrize进行参数化 - 不需要覆盖到网络请求，外部依赖全部mock掉加了“外部依赖全部mock掉”这个约束后，你得到的测试代码基本可以直接跑。如果没有这句，AI很可能会写出一堆真的去发HTTP请求的“假单测”，把CI跑挂。
4. 工具选型：选对副驾驶才能省心
方法对了，工具也得合适。现在市面上的AI编程工具五花八门，我按“代码副驾驶”的定位把它分成了几类，说说各自的适用场景。
4.1 主流AI编程工具的定位差异
- GitHub Copilot：代码补全与本地对话的代表。它在IDE里做实时补全非常顺滑，适合“写到一半让AI接下一行”的节奏，但让它做大规模重构对话，体验一般。
- Cursor：编辑器级的AI原生工具。它的聊天和分析能力更强，可以一次丢好几个文件进去，适合做跨文件改动、代码库分析、批量重构。
- 通义灵码/文心快码：国产工具里补全能力不错，对国内开发者的网络环境和中文提示词支持更好，而且是免费起步，适合个人开发者尝鲜。
- 各类插件型AI：比如PyCharm里的Fitten Code、Continue等，它们依附在IDE上，主打轻量、简单，不用换编辑器，非常适合“主力IDE不想动”的那群人。
4.2 轻量插件型工具的适用场景
我重点聊聊PyCharm里的Fitten Code这类轻量插件。它们的优点是零学习成本——你继续用原来的IDE，装个插件就能对话、补全、解释代码。
这种工具最适合两类人：一类是刚接触AI编程、不想把整个IDE换掉的人；另一类是有固定团队规范、编辑器已经统一为PyCharm/VSCode的人。它们通常也支持代码片段生成、选中代码解释、报错信息分析这些高频操作，日常写脚本、写函数够用了。
不过要注意的是，轻量插件在“跨文件上下文理解”上通常弱于Cursor这类原生AI编辑器。如果你的需求是让AI同时看多个文件然后做重构，轻量插件可能力不从心。
4.3 我的选择建议与组合方案
个人建议是组合使用，而不是押宝在单一工具上。
日常写代码的时候，我用补全型工具接管“写样板代码”的动作——比如写循环、写DTO、写常规CRUD，它能把你的击键量砍掉一大半。遇到需要深入讨论的问题，比如“这个模块怎么设计才合理”“定位这个线上Bug”，我会打开对话型工具，把相关代码贴进去做深度分析。
工具只是载体，真正决定产出的是你怎么提问。这句话值得再重复一遍，因为换再多工具，也救不了模糊的提问。
5. 实战中的坑与对策：哪些场景AI真不行
即使你已经熟练掌握了提问技巧，有些场景AI依然会掉链子。下面这几个坑我是真金白银踩过的，分享出来给大家避雷。
5.1 AI会一本正经地瞎编API
这是最危险的一个坑。AI在生成代码时，偶尔会“幻觉”出一个看起来很像样、但实际不存在的API或方法名。如果你不了解这个库，直接复制运行，报错的时候你可能还会怀疑是自己的参数写错了。
比如我让它写某个云服务SDK的上传逻辑，它给我编了个upload_file方法，但我翻了官方文档怎么找都找不到。后来发现那个版本SDK里的方法是put_object。
对策只有一条：重要API调用一定要对照官方文档复核。看到AI写的第三方SDK调用，先确认方法名、参数名和返回结构是否真实存在。这一点不能偷懒，也别指望AI自动修正。
5.2 多文件改动时AI容易“失忆”
跨多个文件修改代码，是当前AI最容易翻车的场景之一。它可能在A文件里给你加了一个新函数，却忘了在B文件里更新调用；或者它记得要改前端页面，却忘记了后端接口字段也要同步改。
我现在的做法是：在这种场景下，主动给AI列出“待改动文件清单”和“依赖关系说明”。我会在提示词里写清楚：
这个功能涉及三个文件： 1. api/user.py：负责新增接口 2. service/user_service.py：负责业务逻辑 3. dao/user_dao.py：负责数据访问 依赖关系是：接口层 -> 业务层 -> 数据访问层 请按这个顺序逐一生成改动方案，并说明每个文件的具体改动点。如果你用的工具支持多文件上下文（比如Cursor），直接把这些文件拖进对话；如果不支持，就让他们逐文件输出改动方案，自己再人工串起来。
5.3 AI生成的代码风格可能与项目不一致
AI训练数据里充斥着各种风格的代码——有人喜欢列表推导式，有人坚持用contains，有人习惯先定义常量再使用。它给你生成的代码，默认风格未必符合你项目的规范。
我经历过一个比较无语的场景：团队里约定所有字符串拼接用f-string，AI却给我生成了一大段.format()的代码，看起来也优雅，但一过代码评审就被打回来了。
解决方案是在提示词模板里加入“风格规范”这一项，比如：
请遵循以下代码风格：使用f-string、禁止使用全局变量、函数必须带docstring、常量使用大写命名。最好把团队已有的规范文档直接丢给它，让它照着写。
5.4 依赖与环境的坑：AI不知道你本地有什么
AI看不到你电脑里装了哪些包、用的什么版本、Python是3.8还是3.12、是Windows还是Linux。它经常会给你一个在它看来“天经地义”的依赖，比如直接import OpenSSL，但你本地根本没装，装起来又是一串麻烦。
更隐蔽的是版本差异问题。同一个API，在某个库的老版本和新版本里用途完全不同，AI默认输出的可能是新版本写法，而你项目里锁的是老版本。
对付这个坑的办法是：在提问前主动说明环境信息。养成一个习惯，提示词开头先写“Python 3.10，Windows 11，依赖包是……”——这比事后排查报错要省时间得多。
6. 进阶：把AI嵌入工作流，而不只是补代码
当你开始熟练地用AI生成、修错、解释代码之后，你会慢慢意识到，AI最大的价值不是帮你写代码，而是帮你压缩“从想法到实现”之间的时间。这部分的进阶用法我觉得非常值得展开聊聊。
6.1 让AI当代码审查员
我最近半年养成了一个习惯：每次写完一个大功能，先让AI做一轮“代码评审”，再提交给真实同事。
操作很简单，把代码贴给它，然后说：
你是一名经验丰富的代码审查员。请审查这段代码，重点关注： 1. 潜在的逻辑错误和边界条件遗漏 2. 性能问题，比如不必要的循环、重复查询 3. 安全风险，比如SQL注入、敏感信息泄露 4. 可读性和命名问题 请按“问题严重程度”分级输出，并给出修复建议。很多时候，AI能抓到一些人工复查容易忽略的细节——比如断言了不彻底的条件、一个未被释放的资源、一个遗漏的await。把它当成“第二双眼睛”，比单纯让它写代码更有长期价值。
6.2 沉淀自己的提示词库
大多数人的提示词用过就扔，每次重新组织语言，效率很低。我建议你给自己的高频任务做一个“提示词库”，放到一个专门的文件或笔记里，分类管理。
比如我自己的库里有：写函数、改Bug、解释代码、生成测试、代码评审、版本迁移、写提交信息、生成SQL，这么几个分类。每个分类下存着经过迭代打磨的模板。等到要用的时候，复制粘贴、替换具体描述，两三分钟就能发起一个高质量对话。
时间久了你会发现，你调教AI的水平其实已经被固化成了模板，不需要每次从零开始。
6.3 多AI协作的新玩法
现在还有一个新趋势：让多个AI协作。比如用AI-A生成整体设计方案，用AI-B去做具体实现，再用AI-C去做代码审查和挑刺。
我在一个中等规模的重构项目里试过这个玩法。先用一个更强的模型做系统设计，产出一个详细的重构方案文档；然后把方案文档喂给另一个模型，让它按步骤逐文件实现；最后用专门的“审查员”提示词去跑第三轮。整体效率比单人单向对话高出不少，尤其适合那种“方向太多、容易迷失”的大任务。
当然，多AI协作也意味着你要花更多时间去对齐上下文，不能指望它们之间自己默契配合。你需要当好那个“传话人”。
6.4 别让AI替你思考
最后说一条我的底线原则：AI可以提高写代码的速度，但它替代不了你做技术决策。什么架构合适、什么依赖该引入、什么功能该砍掉，这种问题必须由你来拍板。
我见过一些同行，长期用AI生成代码之后，代码评审能力明显退化——看到问题说不上来哪里不对，只知道“感觉怪怪的”。这种状态很危险。AI是好用的副驾驶，但方向盘始终要抓在自己手里。它给出的方案，你一定要自己理解以后再合入，否则某一天它给你编了一个假API，你可能连错在哪都看不出来。
关于我自己的使用体会，最后再补一句：那些说AI是“人工智障”的人，多半还在用语音输入“帮我把淘宝页面写出来”这种级别的提问。等你真正学会把一个任务拆到足够细、把上下文交代得足够清楚、把验收标准定得足够具体，AI会从一个“抖机灵的文字接龙机器”，变成你每天下班前最想感谢的同事。这个转变，我自己只花了不到两周就完成了，你也可以。
