上周末我干了一件一直想干的事：系统性用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和Continue，PyCharm里试了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。思路没问题，但第一版代码存在一个实实在在的bug：pandas读取GBK编码的CSV时会直接报UnicodeDecodeError，AI只在读取时用了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目录。配置完记得Ctrl+Shift+P执行"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界面的小项目，到时候再换个题目聊聊经验。
