上周末我干了一件一直想干的事系统性用AI写代码把一个小工具从零到一完整实现出来。不是拿AI补个函数、修个报错那种零敲碎打而是把一个真实需求丢给大模型让它当主要生产力我只做需求定义、代码审查和测试验证。这次AI写代码尝试1的完整过程、提示词模板、翻车记录、排查思路全在这篇里。如果你是第一次认真尝试用AI做开发或者用了AI但总觉得生成的东西能用但不敢用这篇文章应该能帮你少走不少弯路。我先说结论AI写代码这件事真正难的从来不是让AI写出代码而是让你自己搞清楚你想要什么、以及怎么验证AI给你的东西是对的。1. 动手前的准备模型选型与工作流设计1.1 为什么这次要动真格之前我也用过AI写代码但基本都是碎片化场景报错信息丢给AI问一句、某个算法记不清了让AI写个Demo、正则表达式懒得自己拼。这些场景确实提升效率但说实话没有改变我的工作方式。这次我想玩大一点让AI从头到尾负责一个工具的编码我扮演产品经理测试工程师代码审查员的角色。选什么项目很关键。我特意挑了一个看起来简单但坑不少的需求写一个Python命令行工具批量处理多个CSV文件自动做数据清洗去重、补全缺失值、格式统一最后汇总成一个Excel报表。选这个需求有三个原因第一它的输入输出边界非常清晰适合用自然语言描述第二它涉及文件IO、数据帧操作、编码处理、异常捕获这些常见编程场景能看出AI的真实水平第三它是我实际工作中会用到的工具写出来不浪费。工具选型上我也做了对比。国内能直接用的几个大模型加上本地的开源模型、IDE里的AI插件我这次全都试了一圈。坦白讲不同模型在写代码这项任务上的差距比想象中大同一个需求有的模型能一次写出能直接跑通的脚本有的模型会给你一个充满低级语法错误的半成品。我的建议是别迷信最强选一个你手边能方便调用、上下文窗口够大、且支持多轮对话的模型然后把它用透。我用的是当前主流的几个商用模型轮换对比再加一个本地部署的开源模型做交叉验证。1.2 IDE插件与辅助工具怎么配工欲善其事必先利其器。除了网页版对话我还配置了几款AI编程插件。VS Code里装的是Cline和ContinuePyCharm里试了Fitten Code插件JetBrains全家桶自带的AI Assistant也体验了一下。这些插件的价值不只是选中代码问一句更重要的是它们能直接读取你当前的代码上下文帮你在工程内部做多文件修改。对我来说插件和网页版的分工是这样的局部修改、读代码、解释报错用插件整体需求的方案设计、代码生成、重构建议用网页版对话。刚开始用插件时容易犯一个错把插件当搜索引擎用。问这个函数怎么用其实浪费了AI的能力你要问的是根据我这个文件里的上下文和调用方式这个函数哪里写错了为什么。插件能感知你光标所在的文件、当前的报错列表和终端输出这个信息量是网页版没有的。另外提醒一句别装一堆AI插件同时开着。我试过在同一个IDE里同时启用三个AI插件结果是它们互相抢占快捷键、上下文互相污染生成质量反而下降。选一个主力的其他临时需要再开。2. 提示词工程规则设定比代码本身更重要2.1 一个能用的角色设定模板AI写代码这件事很多人第一反应是你给我写个Python脚本这样得到的答案往往泛泛而谈看起来像那么回事一跑就报错。问题不在AI在于你给的信息量太少。我花了很大力气研究提示词最后总结出一个比较通用的模板核心是四件事角色、任务、约束、输出格式。角色设定要具体到你是一个有十年Python开发经验的资深工程师擅长编写生产级代码。任务部分不能只说要干什么要说清楚输入是什么、输出是什么、运行环境是什么、数据长什么样。约束部分是最容易忽略的你要明确告诉AI不做什么比如不要使用第三方未授权库不要修改原始文件所有函数必须写docstring。输出格式部分要约定代码块语言、是否需要注释、是否需要说明文档。我这次实际用的第一版提示词是这样的角色是数据工程师任务是处理CSV文件约束是只允许用pandas和openpyxl、必须兼容UTF-8和GBK编码、遇到坏数据要跳过并记录日志输出是一个Python脚本加一段简短的代码逻辑说明。这个提示词花了大约10分钟打磨但后面节省的时间远超10分钟——第一版代码虽然有bug但大方向完全正确结构清晰几乎没有需要推翻重来的地方。2.2 任务拆解一次只让它做一件事第二个心得是把大任务拆成小任务。别让AI一口气写完一个带GUI的、支持多线程的、带数据库持久化的超级工具它写出来的一定是缝合怪。我这次把CSV处理工具拆成了三个步骤第一步让AI写出核心的数据清洗函数只处理单个CSV文件第二步让AI写出多文件的批量扫描与异常捕获逻辑第三步让AI写Excel报表生成。每一步单独对话拿到代码后我亲手拼装再回头让AI审查拼装后的整体代码。拆解还有一个好处便于定位问题。如果第N轮的生成结果跑不通你可以只针对那一小段代码做排查而不是在一个三百行的混乱脚本里大海捞针。而且每轮的上下文都保持干净AI不容易被前面的错误带偏。任务拆解的另一种形式是让AI自己拆。你可以在提示词里要求在开始写代码之前先列出你准备分几步实现这个需求、每步的输出是什么得到我确认后再写代码。这样能强制AI展现思路你也能提前发现它理解偏了的地方。我实测这个地方非常管用——它自己拆出来的步骤和我想的不一样我才发现我需求描述里有个关键歧义CSV列的命名到底是固定的还是动态读取的。如果不是让它先列步骤这个歧义会在代码跑完才暴露那就浪费一轮了。2.3 通用规则与安全边界提示词工程里有一条黄金法则把通用规则写在对话的最前面而不是挤在需求后面。我习惯在每段对话开头固定放一段规则前置内容大概是这样所有代码必须兼容Python 3.9及以上版本不要使用实验性语法涉及文件操作必须显式关闭资源或使用上下文管理器所有异常都要被捕获并记录不能让程序直接崩溃代码中禁止硬编码路径必须使用命令行参数或环境变量。这些规则每次对话都要写一遍虽然啰嗦但对生成质量的提升是决定性的。边界问题也要在提示词里讲清楚。比如不要修改输入文件不要自动联网下载依赖不要删除任何数据。AI在生成代码时有一种倾向就是过度设计它常常会自作主张加一些你不需要的功能比如自动发送邮件通知、定时任务、GUI界面。你必须在约束里告诉它这个工具是命令行工具不提供任何图形界面否则它会把简单问题复杂化。3. 实操全程实录从CSV工具到可运行脚本3.1 第一轮生成从设计到首版我第一次对话的完整提示词大概是这样的你是一个资深Python工程师请编写一个命令行工具功能是批量处理指定目录下所有CSV文件。处理规则包括删除完全重复的行对缺失的关键字段id、name、amount做标记而不是删除金额字段统一保留两位小数日期字段统一转为YYYY-MM-DD格式每个文件处理完毕输出处理前后的行数对比。输入目录和输出目录通过命令行参数指定支持--input和--output两个参数。只允许使用pandas、openpyxl和标准库。代码需要包含主函数入口ifname main并处理FileNotFoundError、UnicodeDecodeError等异常。请先简单说明你的实现思路然后给出完整代码。AI返回的实现思路是用os.walk扫描目录逐一读取CSV用pandas做去重用drop_duplicates缺失值用isna标记日期和金额用pd.to_datetime和round处理最后把多个DataFrame写入Excel的不同sheet。思路没问题但第一版代码存在一个实实在在的bugpandas读取GBK编码的CSV时会直接报UnicodeDecodeErrorAI只在读取时用了utf-8没有做编码回退。这是典型的AI写代码盲区——它知道GBK这回事但默认你不会遇到所以不处理。我没有直接把错误丢给AI而是把模拟的GBK文件报错信息复制给它让它先解释为什么会报错。这一步很重要因为如果你直接说修一下AI可能给你一个治标不治本的修改。让它先解释原因你会得到一个真正的修复增加一个自动尝试[utf-8, gbk, gb18030]编码列表的helper函数。这个修复后来帮了大忙因为实际场景里哪个文件是什么编码根本不确定。3.2 迭代修复引入代码审查环节第一版代码跑通之后我做了两件让代码从能跑变成能看的事。第一件是让AI做静态审查。我把完整代码粘贴回去输入提示词请以代码审查员的视角审查下面这段代码重点关注资源泄露、异常处理缺失、pandas的链式赋值警告、性能瓶颈。不要重写整个文件只列出你发现的具体问题每个问题指明行号和修改建议。这个操作强烈建议每个人都试一次AI会指出一些你自己根本不会注意的问题比如它发现我在循环里反复创建ExcelWriter的实例导致多个sheet写入覆盖还发现用df.iterrows()遍历大文件性能极差建议换成向量化操作。第二件是人肉审查。AI毕竟是AI它不会从你的业务角度思考。我仔细看了一遍发现它把金额字段统一保留两位小数实现成四舍五入但我的实际业务要求是金额过大时用千分位分隔符展示且不做四舍五入直接截断。这种需求偏差AI真的没办法自己发现只能靠人。我改了这部分然后打开一个对比版本管理工具记录了两版差异。这一轮下来代码从AI的代码变成了我的代码这个转变是关键。3.3 补齐测试让AI写pytest用例代码写完不等于完事。我一直有个习惯工具类脚本至少要覆盖核心路径的测试。这次想偷个懒让AI来补测试。提示词是为下面的代码编写pytest测试用例要求覆盖正常文件处理、空文件、重复行、缺失值、非法数据、文件不存在、编码错误七个场景。每个测试用例需要构造临时文件作为输入测试完成后清理。AI很快生成了一套基于pytest和tmp_path fixture的测试这比我手写快得多。但我发现AI测试有个常见毛病过度使用mock测试根本没走真实逻辑。比如它给编码错误场景写的测试直接mock了read_csv来抛异常这样根本没有验证到我的编码回退逻辑。我把这个问题反馈给它要求不要mock pandas读取行为实际创建一个GBK编码的临时CSV文件来测试。修改后的测试就扎实了很多。用AI写测试重要的是你在提示词里明确要真实数据、不要mock核心IO函数不然它就是自欺欺人。3.4 多AI协作让不同模型互相找茬这次尝试最有意思的部分是我引入了一个多AI协作的流程。具体做法是用模型A写主体代码用模型B来审查代码并挑刺再把B的意见发给A让它修正。B站在B的偏好上说话A反而能接受与自己生成惯性不同风格的建议。我用一个开源模型当B它不倾向于维护自己生成的代码所以指出的问题更不留情面。它发现了几个真实问题包括一个在windows上路径分隔符不兼容的问题这个连我都没注意。这不是什么高深的技术就是工程上的结对编程第二双眼睛逻辑。多AI协作的意义在于打破单模型生成风格的定势。模型生成代码会有自己的习惯深度求索的模型喜欢写非常紧凑的代码有的模型却习惯把每个逻辑拆成小函数。让另一个模型审一遍相当于自动获得一个不同风格的审查员。未来agent成熟之后这种多个智能体互相验证的方式会变成标配现在手动做其实成本也不高无非是多开一个对话窗口。4. 常见问题与排查技巧实录4.1 IDE环境类问题速查用AI写代码绕不开IDE环境配置。我这次同时踩了三个常见坑整理成表格先给大家一个速查。首先是VS Code里写C语言没代码提示。这个问题多半不是你代码的问题而是VS Code没有配置好C/C扩展的IntelliSense。我见过很多人直接开一个.c文件就开始写写了一半发现所有标准库函数都是波浪线。正确做法是先确认安装了C/C扩展然后在项目根目录建一个.vscode/c_cpp_properties.json把includePath指向你实际使用的编译器的头文件目录比如MinGW的include和vcruntime目录。配置完记得CtrlShiftP执行C/C: Rescan Workspace。另外如果你新建的是单文件而没有打开一个文件夹有些扩展功能会不生效。第二个坑是JetBrains IDE里写代码时出现大片黄色高亮占据好几行。这个黄色高亮通常是代码警告Warning或者语言级别提示。很多人以为是AI插件在报错其实是IDE自带的静态检查在提示你有潜在问题比如变量名不符合规范、表达式可以被括号简化、存在未使用的导入等。按快捷键就可以展开具体警告内容不用理会也可以只是别把它当成代码错了的信号。如果你确实不想要这些提示可以在设置里关闭Inspections但我建议留着这些警告很多是有效的比如未使用变量通常意味着逻辑没写完。第三个坑是PyCharm里AI插件装了但不生效。我在PyCharm里装Fitten Code插件后右侧面板一直提示登录失败。排查发现是代理设置问题PyCharm默认使用系统代理而系统代理没有正确配置导致插件无法请求后端API。解决方案是把Python环境的内置HTTP代理设置关掉或者检查系统代理的连通性。这种问题跟代码本身无关但卡住的时候真的很磨人。4.2 生成代码的典型翻车清单AI写代码的翻车方式其实高度一致。我这次总结了一个典型翻车清单以后每次用AI生成代码我都会拿这个清单去检查。第一是API版本幻觉。AI特别喜欢调用它训练数据里见过的函数而这些函数的版本和签名可能已经变了。比如某次它用了os.path.exists的旧式字符串拼接我用的Python 3.9虽然支持但已经被标记为deprecated。解决方法是给AI明确指定依赖库版本并在提示词里说禁止使用已经废弃的API。第二是边界条件缺失。AI生成的循环通常不会自己处理列表为空除数为零文件为空这些边界你需要额外要求请确保代码在所有边界条件下都不会抛出未捕获异常。第三是记忆偏差。多轮对话里AI经常忘记你前面说过的约束。比如第一轮你说了不要修改原始文件第三轮它又写出了原地覆盖的逻辑。应对方法是如果你发现AI开始飘就把关键约束重新粘贴一遍明确说重申一下之前的约束这次修改请不要破坏它。我实测还有一个很隐蔽的问题AI生成的正则表达式往往准确但很难懂而且常常在不该用正则的地方用正则。比如解析CSV行它偶尔会给你一个复杂的正则但其实csv模块就能干净地解决。我在审查时遇到这类过度聪明的实现一般都会要求AI改用标准库降低维护成本。判断一个AI实现对错标准从来不是能不能跑而是可读、可维护、够健壮。4.3 并发与工程化避坑心得热词里有个ai agent 怎么扛并发虽然我这次不是在做agent但AI生成的代码如果后面要被agent调用并发就是绕不开的问题。我遇到过AI生成的代码里有一个全局共享的文件句柄一旦多线程调用就会相互污染。这种问题靠AI自己很难发现你得在提示词里明确要求代码必须在多线程环境下安全禁止使用全局可变对象。关于AI测试开发这次我也深有体会。让AI写测试用例确实快但你要有一种测试审测试的意识。AI生成的测试往往会测出它自己代码的预期行为而不是正确行为。也就是说如果代码本身是个错误的实现AI生成的测试很可能把错误行为当成正确结果来断言。真正有效的做法是把一个独立编写的测试用例手动跑一遍或者让不通的模型来审测试。我这次踩过的一个具体问题AI生成的测试用了固定的临时目录路径导致多次运行测试时数据残留测试结果互相影响。修复方法是让AI改用pytest的tmp_path特性每次测试自动创建和清理临时目录。这种细节提示词里不写AI真的想不到。5. 收尾的个人体会经历这次完整尝试之后我越来越觉得AI写代码这件事本质上是把编程的乐趣做了重新分配。以前那些机械性的重复劳动——查文档、写模板代码、处理格式转换——现在AI全包了。但真正重要的判断需求有没有理解偏、逻辑有没有漏洞、要不要引入某个依赖、性能瓶颈在哪儿这些还是要人来扛。AI就像一把电钻能帮你省掉凿墙的力气但图纸得你自己定。最后分享一个小技巧也是我这次很受用的给AI开的需求工单尽可能包含一个验收标准。比如如果输入目录下没有CSV文件程序应该打印提示并以退出码0正常结束而不是抛出异常。这种验收标准写得越细AI生成的东西越接近你的预期。我最近已经养成了一个新的工作习惯先写验收标准再把验收标准连同需求发给AI这比单纯提需求要好用得多。下一次尝试我打算用AI写一个带Web界面的小项目到时候再换个题目聊聊经验。 
长河君 · 2026/10/28 16:39:53 · 阅读 1.2k AI写代码实战复盘：提示词工程、代码审查与pytest全记录
上周末我干了一件一直想干的事系统性用AI写代码把一个小工具从零到一完整实现出来。不是拿AI补个函数、修个报错那种零敲碎打而是把一个真实需求丢给大模型让它当主要生产力我只做需求定义、代码审查和测试验证。这次AI写代码尝试1的完整过程、提示词模板、翻车记录、排查思路全在这篇里。如果你是第一次认真尝试用AI做开发或者用了AI但总觉得生成的东西能用但不敢用这篇文章应该能帮你少走不少弯路。我先说结论AI写代码这件事真正难的从来不是让AI写出代码而是让你自己搞清楚你想要什么、以及怎么验证AI给你的东西是对的。1. 动手前的准备模型选型与工作流设计1.1 为什么这次要动真格之前我也用过AI写代码但基本都是碎片化场景报错信息丢给AI问一句、某个算法记不清了让AI写个Demo、正则表达式懒得自己拼。这些场景确实提升效率但说实话没有改变我的工作方式。这次我想玩大一点让AI从头到尾负责一个工具的编码我扮演产品经理测试工程师代码审查员的角色。选什么项目很关键。我特意挑了一个看起来简单但坑不少的需求写一个Python命令行工具批量处理多个CSV文件自动做数据清洗去重、补全缺失值、格式统一最后汇总成一个Excel报表。选这个需求有三个原因第一它的输入输出边界非常清晰适合用自然语言描述第二它涉及文件IO、数据帧操作、编码处理、异常捕获这些常见编程场景能看出AI的真实水平第三它是我实际工作中会用到的工具写出来不浪费。工具选型上我也做了对比。国内能直接用的几个大模型加上本地的开源模型、IDE里的AI插件我这次全都试了一圈。坦白讲不同模型在写代码这项任务上的差距比想象中大同一个需求有的模型能一次写出能直接跑通的脚本有的模型会给你一个充满低级语法错误的半成品。我的建议是别迷信最强选一个你手边能方便调用、上下文窗口够大、且支持多轮对话的模型然后把它用透。我用的是当前主流的几个商用模型轮换对比再加一个本地部署的开源模型做交叉验证。1.2 IDE插件与辅助工具怎么配工欲善其事必先利其器。除了网页版对话我还配置了几款AI编程插件。VS Code里装的是Cline和ContinuePyCharm里试了Fitten Code插件JetBrains全家桶自带的AI Assistant也体验了一下。这些插件的价值不只是选中代码问一句更重要的是它们能直接读取你当前的代码上下文帮你在工程内部做多文件修改。对我来说插件和网页版的分工是这样的局部修改、读代码、解释报错用插件整体需求的方案设计、代码生成、重构建议用网页版对话。刚开始用插件时容易犯一个错把插件当搜索引擎用。问这个函数怎么用其实浪费了AI的能力你要问的是根据我这个文件里的上下文和调用方式这个函数哪里写错了为什么。插件能感知你光标所在的文件、当前的报错列表和终端输出这个信息量是网页版没有的。另外提醒一句别装一堆AI插件同时开着。我试过在同一个IDE里同时启用三个AI插件结果是它们互相抢占快捷键、上下文互相污染生成质量反而下降。选一个主力的其他临时需要再开。2. 提示词工程规则设定比代码本身更重要2.1 一个能用的角色设定模板AI写代码这件事很多人第一反应是你给我写个Python脚本这样得到的答案往往泛泛而谈看起来像那么回事一跑就报错。问题不在AI在于你给的信息量太少。我花了很大力气研究提示词最后总结出一个比较通用的模板核心是四件事角色、任务、约束、输出格式。角色设定要具体到你是一个有十年Python开发经验的资深工程师擅长编写生产级代码。任务部分不能只说要干什么要说清楚输入是什么、输出是什么、运行环境是什么、数据长什么样。约束部分是最容易忽略的你要明确告诉AI不做什么比如不要使用第三方未授权库不要修改原始文件所有函数必须写docstring。输出格式部分要约定代码块语言、是否需要注释、是否需要说明文档。我这次实际用的第一版提示词是这样的角色是数据工程师任务是处理CSV文件约束是只允许用pandas和openpyxl、必须兼容UTF-8和GBK编码、遇到坏数据要跳过并记录日志输出是一个Python脚本加一段简短的代码逻辑说明。这个提示词花了大约10分钟打磨但后面节省的时间远超10分钟——第一版代码虽然有bug但大方向完全正确结构清晰几乎没有需要推翻重来的地方。2.2 任务拆解一次只让它做一件事第二个心得是把大任务拆成小任务。别让AI一口气写完一个带GUI的、支持多线程的、带数据库持久化的超级工具它写出来的一定是缝合怪。我这次把CSV处理工具拆成了三个步骤第一步让AI写出核心的数据清洗函数只处理单个CSV文件第二步让AI写出多文件的批量扫描与异常捕获逻辑第三步让AI写Excel报表生成。每一步单独对话拿到代码后我亲手拼装再回头让AI审查拼装后的整体代码。拆解还有一个好处便于定位问题。如果第N轮的生成结果跑不通你可以只针对那一小段代码做排查而不是在一个三百行的混乱脚本里大海捞针。而且每轮的上下文都保持干净AI不容易被前面的错误带偏。任务拆解的另一种形式是让AI自己拆。你可以在提示词里要求在开始写代码之前先列出你准备分几步实现这个需求、每步的输出是什么得到我确认后再写代码。这样能强制AI展现思路你也能提前发现它理解偏了的地方。我实测这个地方非常管用——它自己拆出来的步骤和我想的不一样我才发现我需求描述里有个关键歧义CSV列的命名到底是固定的还是动态读取的。如果不是让它先列步骤这个歧义会在代码跑完才暴露那就浪费一轮了。2.3 通用规则与安全边界提示词工程里有一条黄金法则把通用规则写在对话的最前面而不是挤在需求后面。我习惯在每段对话开头固定放一段规则前置内容大概是这样所有代码必须兼容Python 3.9及以上版本不要使用实验性语法涉及文件操作必须显式关闭资源或使用上下文管理器所有异常都要被捕获并记录不能让程序直接崩溃代码中禁止硬编码路径必须使用命令行参数或环境变量。这些规则每次对话都要写一遍虽然啰嗦但对生成质量的提升是决定性的。边界问题也要在提示词里讲清楚。比如不要修改输入文件不要自动联网下载依赖不要删除任何数据。AI在生成代码时有一种倾向就是过度设计它常常会自作主张加一些你不需要的功能比如自动发送邮件通知、定时任务、GUI界面。你必须在约束里告诉它这个工具是命令行工具不提供任何图形界面否则它会把简单问题复杂化。3. 实操全程实录从CSV工具到可运行脚本3.1 第一轮生成从设计到首版我第一次对话的完整提示词大概是这样的你是一个资深Python工程师请编写一个命令行工具功能是批量处理指定目录下所有CSV文件。处理规则包括删除完全重复的行对缺失的关键字段id、name、amount做标记而不是删除金额字段统一保留两位小数日期字段统一转为YYYY-MM-DD格式每个文件处理完毕输出处理前后的行数对比。输入目录和输出目录通过命令行参数指定支持--input和--output两个参数。只允许使用pandas、openpyxl和标准库。代码需要包含主函数入口ifname main并处理FileNotFoundError、UnicodeDecodeError等异常。请先简单说明你的实现思路然后给出完整代码。AI返回的实现思路是用os.walk扫描目录逐一读取CSV用pandas做去重用drop_duplicates缺失值用isna标记日期和金额用pd.to_datetime和round处理最后把多个DataFrame写入Excel的不同sheet。思路没问题但第一版代码存在一个实实在在的bugpandas读取GBK编码的CSV时会直接报UnicodeDecodeErrorAI只在读取时用了utf-8没有做编码回退。这是典型的AI写代码盲区——它知道GBK这回事但默认你不会遇到所以不处理。我没有直接把错误丢给AI而是把模拟的GBK文件报错信息复制给它让它先解释为什么会报错。这一步很重要因为如果你直接说修一下AI可能给你一个治标不治本的修改。让它先解释原因你会得到一个真正的修复增加一个自动尝试[utf-8, gbk, gb18030]编码列表的helper函数。这个修复后来帮了大忙因为实际场景里哪个文件是什么编码根本不确定。3.2 迭代修复引入代码审查环节第一版代码跑通之后我做了两件让代码从能跑变成能看的事。第一件是让AI做静态审查。我把完整代码粘贴回去输入提示词请以代码审查员的视角审查下面这段代码重点关注资源泄露、异常处理缺失、pandas的链式赋值警告、性能瓶颈。不要重写整个文件只列出你发现的具体问题每个问题指明行号和修改建议。这个操作强烈建议每个人都试一次AI会指出一些你自己根本不会注意的问题比如它发现我在循环里反复创建ExcelWriter的实例导致多个sheet写入覆盖还发现用df.iterrows()遍历大文件性能极差建议换成向量化操作。第二件是人肉审查。AI毕竟是AI它不会从你的业务角度思考。我仔细看了一遍发现它把金额字段统一保留两位小数实现成四舍五入但我的实际业务要求是金额过大时用千分位分隔符展示且不做四舍五入直接截断。这种需求偏差AI真的没办法自己发现只能靠人。我改了这部分然后打开一个对比版本管理工具记录了两版差异。这一轮下来代码从AI的代码变成了我的代码这个转变是关键。3.3 补齐测试让AI写pytest用例代码写完不等于完事。我一直有个习惯工具类脚本至少要覆盖核心路径的测试。这次想偷个懒让AI来补测试。提示词是为下面的代码编写pytest测试用例要求覆盖正常文件处理、空文件、重复行、缺失值、非法数据、文件不存在、编码错误七个场景。每个测试用例需要构造临时文件作为输入测试完成后清理。AI很快生成了一套基于pytest和tmp_path fixture的测试这比我手写快得多。但我发现AI测试有个常见毛病过度使用mock测试根本没走真实逻辑。比如它给编码错误场景写的测试直接mock了read_csv来抛异常这样根本没有验证到我的编码回退逻辑。我把这个问题反馈给它要求不要mock pandas读取行为实际创建一个GBK编码的临时CSV文件来测试。修改后的测试就扎实了很多。用AI写测试重要的是你在提示词里明确要真实数据、不要mock核心IO函数不然它就是自欺欺人。3.4 多AI协作让不同模型互相找茬这次尝试最有意思的部分是我引入了一个多AI协作的流程。具体做法是用模型A写主体代码用模型B来审查代码并挑刺再把B的意见发给A让它修正。B站在B的偏好上说话A反而能接受与自己生成惯性不同风格的建议。我用一个开源模型当B它不倾向于维护自己生成的代码所以指出的问题更不留情面。它发现了几个真实问题包括一个在windows上路径分隔符不兼容的问题这个连我都没注意。这不是什么高深的技术就是工程上的结对编程第二双眼睛逻辑。多AI协作的意义在于打破单模型生成风格的定势。模型生成代码会有自己的习惯深度求索的模型喜欢写非常紧凑的代码有的模型却习惯把每个逻辑拆成小函数。让另一个模型审一遍相当于自动获得一个不同风格的审查员。未来agent成熟之后这种多个智能体互相验证的方式会变成标配现在手动做其实成本也不高无非是多开一个对话窗口。4. 常见问题与排查技巧实录4.1 IDE环境类问题速查用AI写代码绕不开IDE环境配置。我这次同时踩了三个常见坑整理成表格先给大家一个速查。首先是VS Code里写C语言没代码提示。这个问题多半不是你代码的问题而是VS Code没有配置好C/C扩展的IntelliSense。我见过很多人直接开一个.c文件就开始写写了一半发现所有标准库函数都是波浪线。正确做法是先确认安装了C/C扩展然后在项目根目录建一个.vscode/c_cpp_properties.json把includePath指向你实际使用的编译器的头文件目录比如MinGW的include和vcruntime目录。配置完记得CtrlShiftP执行C/C: Rescan Workspace。另外如果你新建的是单文件而没有打开一个文件夹有些扩展功能会不生效。第二个坑是JetBrains IDE里写代码时出现大片黄色高亮占据好几行。这个黄色高亮通常是代码警告Warning或者语言级别提示。很多人以为是AI插件在报错其实是IDE自带的静态检查在提示你有潜在问题比如变量名不符合规范、表达式可以被括号简化、存在未使用的导入等。按快捷键就可以展开具体警告内容不用理会也可以只是别把它当成代码错了的信号。如果你确实不想要这些提示可以在设置里关闭Inspections但我建议留着这些警告很多是有效的比如未使用变量通常意味着逻辑没写完。第三个坑是PyCharm里AI插件装了但不生效。我在PyCharm里装Fitten Code插件后右侧面板一直提示登录失败。排查发现是代理设置问题PyCharm默认使用系统代理而系统代理没有正确配置导致插件无法请求后端API。解决方案是把Python环境的内置HTTP代理设置关掉或者检查系统代理的连通性。这种问题跟代码本身无关但卡住的时候真的很磨人。4.2 生成代码的典型翻车清单AI写代码的翻车方式其实高度一致。我这次总结了一个典型翻车清单以后每次用AI生成代码我都会拿这个清单去检查。第一是API版本幻觉。AI特别喜欢调用它训练数据里见过的函数而这些函数的版本和签名可能已经变了。比如某次它用了os.path.exists的旧式字符串拼接我用的Python 3.9虽然支持但已经被标记为deprecated。解决方法是给AI明确指定依赖库版本并在提示词里说禁止使用已经废弃的API。第二是边界条件缺失。AI生成的循环通常不会自己处理列表为空除数为零文件为空这些边界你需要额外要求请确保代码在所有边界条件下都不会抛出未捕获异常。第三是记忆偏差。多轮对话里AI经常忘记你前面说过的约束。比如第一轮你说了不要修改原始文件第三轮它又写出了原地覆盖的逻辑。应对方法是如果你发现AI开始飘就把关键约束重新粘贴一遍明确说重申一下之前的约束这次修改请不要破坏它。我实测还有一个很隐蔽的问题AI生成的正则表达式往往准确但很难懂而且常常在不该用正则的地方用正则。比如解析CSV行它偶尔会给你一个复杂的正则但其实csv模块就能干净地解决。我在审查时遇到这类过度聪明的实现一般都会要求AI改用标准库降低维护成本。判断一个AI实现对错标准从来不是能不能跑而是可读、可维护、够健壮。4.3 并发与工程化避坑心得热词里有个ai agent 怎么扛并发虽然我这次不是在做agent但AI生成的代码如果后面要被agent调用并发就是绕不开的问题。我遇到过AI生成的代码里有一个全局共享的文件句柄一旦多线程调用就会相互污染。这种问题靠AI自己很难发现你得在提示词里明确要求代码必须在多线程环境下安全禁止使用全局可变对象。关于AI测试开发这次我也深有体会。让AI写测试用例确实快但你要有一种测试审测试的意识。AI生成的测试往往会测出它自己代码的预期行为而不是正确行为。也就是说如果代码本身是个错误的实现AI生成的测试很可能把错误行为当成正确结果来断言。真正有效的做法是把一个独立编写的测试用例手动跑一遍或者让不通的模型来审测试。我这次踩过的一个具体问题AI生成的测试用了固定的临时目录路径导致多次运行测试时数据残留测试结果互相影响。修复方法是让AI改用pytest的tmp_path特性每次测试自动创建和清理临时目录。这种细节提示词里不写AI真的想不到。5. 收尾的个人体会经历这次完整尝试之后我越来越觉得AI写代码这件事本质上是把编程的乐趣做了重新分配。以前那些机械性的重复劳动——查文档、写模板代码、处理格式转换——现在AI全包了。但真正重要的判断需求有没有理解偏、逻辑有没有漏洞、要不要引入某个依赖、性能瓶颈在哪儿这些还是要人来扛。AI就像一把电钻能帮你省掉凿墙的力气但图纸得你自己定。最后分享一个小技巧也是我这次很受用的给AI开的需求工单尽可能包含一个验收标准。比如如果输入目录下没有CSV文件程序应该打印提示并以退出码0正常结束而不是抛出异常。这种验收标准写得越细AI生成的东西越接近你的预期。我最近已经养成了一个新的工作习惯先写验收标准再把验收标准连同需求发给AI这比单纯提需求要好用得多。下一次尝试我打算用AI写一个带Web界面的小项目到时候再换个题目聊聊经验。