很多人跟我说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-stringAI却给我生成了一大段.format()的代码看起来也优雅但一过代码评审就被打回来了。解决方案是在提示词模板里加入“风格规范”这一项比如请遵循以下代码风格使用f-string、禁止使用全局变量、函数必须带docstring、常量使用大写命名。最好把团队已有的规范文档直接丢给它让它照着写。5.4 依赖与环境的坑AI不知道你本地有什么AI看不到你电脑里装了哪些包、用的什么版本、Python是3.8还是3.12、是Windows还是Linux。它经常会给你一个在它看来“天经地义”的依赖比如直接import OpenSSL但你本地根本没装装起来又是一串麻烦。更隐蔽的是版本差异问题。同一个API在某个库的老版本和新版本里用途完全不同AI默认输出的可能是新版本写法而你项目里锁的是老版本。对付这个坑的办法是在提问前主动说明环境信息。养成一个习惯提示词开头先写“Python 3.10Windows 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会从一个“抖机灵的文字接龙机器”变成你每天下班前最想感谢的同事。这个转变我自己只花了不到两周就完成了你也可以。
