AI写代码实操全记录：工具选型、提示词技巧与多AI协作踩坑

我一直觉得程序员这行有个有趣的现象：越是老手，越容易被"AI写代码"这个话题搞得既兴奋又焦虑。兴奋是因为有些活确实能甩给AI干，焦虑是因为朋友圈里那些"AI十分钟做出一个完整应用"的截图，怎么看都像是P的。到我自己真正动手尝试之后才明白，那些截图大概率是真的，但过程里没写出来的坑也一堆。

这篇东西就是我的第一次完整尝试记录：从选工具、写提示词，到让AI从零生成一个能跑起来的小工具，再到多AI协作这种进阶玩法。我尽量把每一步怎么想的、为什么这么做、踩了哪些坑都写清楚，给正在观望或者刚入坑的朋友做个参考。

1. 先搞清楚一件事：AI写代码到底解决了什么问题

在动手之前，我给自己列了个需求清单。不是随便找个题目让AI写，而是先想清楚：我希望AI帮我省哪部分时间，它哪些方面确实比我强，哪些方面只是听起来很强。

1.1 它擅长的和我该警惕的

用了一阵子之后，我发现AI在写代码这件事上，优势是实打实的：

• 样板代码和重复性结构生成速度极快。写个文件处理脚本、模板页面、配置类代码，基本是秒出。
• 冷门语法和API用法检索比查文档快。忘了Python的pathlib怎么拼接路径，问一句就出来了，不用再翻半天文档。
• 解释和翻译代码能力强。给一段别人写的、加了各种骚操作的代码，它能把逻辑一行行说清楚。
• 写单元测试、生成注释、做代码审查这些"低创造性高工作量"的事情，效率确实比我高。

但它的短板同样明显。最容易翻车的是逻辑比较绕的需求——比如"批量处理多个文件，每个文件结构不同，遇到异常要单独记录"这种，它第一版生成的代码大概率只覆盖了最简单的情况，边界条件全靠你提醒。还有那种涉及全局架构、模块间依赖关系的代码，它经常给出局部最优但整体混乱的方案。另外，它对代码库里的存量代码缺乏感知，经常生成一段风格完全不兼容的东西。

所以我给自己定了个原则：把它当实习生，不当大神。实习生能快速出活，但你必须告诉它背景、约束条件、验收标准，而且要检查它的产出。

1.2 选哪个工具：国内外主流编程助手横向对比

现在市面上的AI编程工具很多，我试了一圈，把印象比较深的几个列了个表：

这里多说一句Fitten Code，热搜里有人问"pycharm好用的ai插件fitten"，它确实是PyCharm里比较省心的选择，装好以后不需要额外配置，选中代码直接问就行。但如果你要用VS Code写C语言，那属于另一个坑，我后面专门讲。

1.3 我的实际选型结论

我最后的选择是混合打法：

• 日常在PyCharm里装Fitten Code，处理Python小脚本。
• 遇到需要"整体思路推演"的问题，去Claude里聊方案。
• 需要从零憋出一个完整小项目的时候，用Cursor开一个新项目来写。
• Codex偶尔用来做快速原型验证，看看一个想法能不能落地。

这个组合不是一步到位的，中间换了好几次。最开始我只用Copilot，后来发现它更像"快进键"，而不是"对话对象"——它擅长帮你把正在写的代码补完，但不擅长你问它"我这个程序整体架构应该怎么搭"。真正常用的反而是对话式的工具。

2. 第一次完整实操：让AI写一个批量重命名工具

光说不练没意思。我的第一次完整尝试，是让AI写一个"批量重命名文件"的Python工具。这需求说难不难，说简单也不简单——有GUI界面、支持正则表达式、能预览再执行、还能撤销。我特意选这个，是因为它足够典型：需要处理用户输入、操作文件系统、有状态管理，能充分暴露AI生成代码的各种问题。

2.1 我写的原始提示词

我见过很多人让AI写代码失败，问题多半出在提示词上。不是"帮我写个程序"这种太笼统的，就是自己的需求描述繁琐冗长。我第一次写的提示词如下：

我需要一个Python程序，实现批量重命名文件的功能。具体要求：

1. 使用tkinter做图形界面，不要用命令行。
2. 用户选择一个文件夹后，列出所有文件的文件名。
3. 支持两种重命名模式：简单替换（把A替换成B）和使用正则表达式匹配。
4. 重命名之前要能看到预览列表（旧名→新名），确认后再执行。
5. 执行后要支持撤销，撤销要把名字改回去。
6. 界面布局简单清晰，不要花里胡哨。
7. 给出完整代码，并告诉我如何运行。

这个提示词写得不复杂，但覆盖了需求边界：（a）技术栈明确；（b）交互方式明确；（c）功能点明确；（d）有预览确认流程；（e）有可逆操作。这都是从实际使用体验倒推出来的——没有预览直接改文件名，万一改错了用户会崩溃。

2.2 第一版代码的问题

几分钟后，AI生成了一份大约300行的代码。初次看，结构清楚，还有注释，我当时还挺满意的。但真正运行起来，问题一个接一个冒出来。

第一个问题：中文文件名乱码。Windows下tkinter处理中文文件名，如果文本框编码处理不当，列表和重命名结果会显示乱码。AI第一版只用了简单的os.listdir()，没有显式处理编码问题。

第二个问题：正则表达式模式没给错误提示。用户如果输入了非法的正则（比如[a-），程序直接崩溃。

第三个问题：撤销功能只保存在内存里。也就是说，软件重启后撤销记录全没了，而且如果重命名过程中途遇到权限错误，撤销列表可能不完整。

第四个问题：预览列表没有按文件类型筛选。文件夹里如果有子目录，子目录也会被当成文件列出来，这显然不合适。

这些都是非常典型的"AI盲区"——它在生成代码时，只会顺着你的需求写主流程，不会主动考虑异常路径和边界情况。你让它列文件名，它就老老实实列，哪怕列出来的是个文件夹它也照列不误。

2.3 我是怎么把它磨到能用的

接下来的过程很有代表性——不是让AI重新写一次，而是对着问题一个个追问。

我先把运行报错直接贴给它，它很快定位到编码问题，在读取文件列表时做了适配。

然后我逐条补需求："如果用户输入的正则不合法，弹窗提示，不要崩溃。""文件夹内容过滤掉子目录，只显示文件。""撤销记录写到JSON文件，下次启动可以恢复上一次的撤销历史。"AI每次都能针对性地修改代码。

这一段往返修改，才是AI写代码正确的使用姿势。它不是一次性把活干完，而是你提要求、它改、你再提、它再改的循环。而且每一次修改，它对上下文的理解都在提升，你会发现第二轮、第三轮的修改质量明显比第一轮好。

最后工具能正常用了。但我统计了一下，整个过程中AI第一版代码只完成了大约60%的需求，剩下的40%全部是靠我提问题逼出来的。这不是说AI不行，而是说明——需求没有说出来的部分，AI默认替你做了决定，而这些决定往往过于理想化。

3. 踩坑实录：VS Code写C没有代码提示、AI幻觉与上下文丢失

老实说，真正让我对AI写代码有更深认识的，不是那个重命名工具本身，而是过程中踩到的一系列坑。集中聊三个我印象最深的，第一个就是从热搜里看大家问得最多的"vscode写c没有代码提示"。

3.1 VS Code写C没有代码提示：根因排查全过程

这个坑我先是在自己电脑上遇到的。当时想用AI帮我写一段C语言的小程序，结果AI给的是对的，但我往VS Code里一贴，发现代码提示几乎等于没有，连标准库函数都不提示。

排查过程我一步步走下来：

第一步，确认有没有装C/C++扩展。VS Code本身不带C语言智能提示，必须装Microsoft官方的C/C++扩展。我检查了一下，装是装了。

第二步，确认有没有配置includePath。这一步是大多数人忽略的。VS Code的C/C++插件默认会范围搜索系统头文件，但如果路径配置不对，stdio.h这种基础头文件都找不到，自然就没有提示。问题就在它默认搜索范围有限，尤其在国内的安装环境下，头文件路径可能有差异。我在c_cpp_properties.json里加了：

{ "config": { "name": "Win64", "includePath": [ "C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Tools/MSVC/14.29.30133/include", "${workspaceFolder}/**" ], "intelliSenseMode": "windows-msvc-x64" } }

第三步，确认选择了正确的编译器。如果电脑上装了多个编译器（MinGW和MSVC都装了），VS Code可能选错，导致头文件解析失败。我手动指定了编译器路径，问题解决。

这个坑给我最大的教训是：AI写出来的C代码本身没错，但代码补全和AI是两套完全独立的机制。AI负责"生成"，代码提示负责"理解"，后者需要你自己搭好环境。我之前天真地以为有了AI，环境问题就消失了，事实证明该配的还得配。

3.2 AI幻觉：它一本正经地生成了一个不存在的API

这是我有一次遇到的最让人哭笑不得的情况。我让AI生成一段操作某第三方库的代码，它生成了类似这样的调用：

from some_library import Client client = Client() result = client.query_data(max_results=10, use_cache=False)

表面上看没有任何问题，合法、规范、有参数说明。但一运行，报错说max_results不是这个API的参数。我去查文档，发现这个库的query_data方法根本不接受这个参数。

这就是经典的AI幻觉——它读过大量类似代码，知道"查询方法通常会有这样一个限制条数的参数"，于是生成了一段表面合理、实际不存在的API调用。

应对这种问题，我的办法是：涉及第三方库的具体API时，明确要求AI附上参考文档的链接，或者要求它只写"文档中明确存在"的方法。有时候直接把它生成的代码里面的函数签名部分标出来，单独问"这个函数在官方文档里的完整签名是什么"，它就会回去重新查。

3.3 上下文丢失：多轮对话后AI"失忆"了

另一个非常常见的问题是上下文丢失。一条对话聊得久了，AI会渐渐忘记项目的初始需求。最典型的一次是：我一开始让它写"批量重命名工具"，明确说了不要命令行界面、要用GUI。结果聊到第30轮，我让它加一个功能，它居然给我生成了一段argparse命令行参数解析的代码——它已经完全忘了最初的设计约束。

这不是它傻，而是模型对过长对话的注意力分布有问题。越多中间讨论挤占早期信息，最初的核心约束就越容易被忽略。为了解决这个问题，我后来会在每一条消息里把最关键的需求重新贴一遍：

每轮提问时都提醒："记住我们的项目是tkinter GUI程序，不是命令行。"或者在聊了很多轮之后，直接开一个新对话，把需求文档重新粘贴进去重新开始。后者效果更好，新对话就像给AI一次"重新做人"的机会。

4. 进阶尝试：多AI协作与AI Agent的实际体验

重命名工具跑通之后，我开始琢磨更进阶的玩法。热搜里"多ai协作""ai agent"这俩词出现频率很高，我也实际试了。真用下来才发现，这些概念听着高大上，落到实际操作上其实是另一回事。

4.1 "多AI协作"到底怎么配合才有效

所谓多AI协作，最朴素的理解就是：别在一棵树上吊死。同一个问题，我让不同的AI工具给出方案，然后互相验证。

具体我这么做的：

第一步，让Claude设计方案。我会描述需求，让它给出完整的架构思路和数据流。它擅长从全局角度规划。

第二步，把Claude的方案丢给Cursor，让它实现代码。Cursor在生成代码的完整性和臆想的平衡上做得更好，但它的设计方案有时不如Claude严谨。

第三步，用Fitten Code在IDE里做快速检查和补全。速度最快，适合逐行级别的review。

第四步，甚至可以让两个AI互相审对方的代码。把Cursor生成的代码发给Claude："请你审查这段代码，指出潜在的bug和边界问题"，往往能发现单靠一个AI时注意不到的问题。

这个流程走一遍，质量和直接用单个工具生成相比，绝对不是一个量级。但代价也很明显——慢，而且你需要比任何单个AI都更懂这个项目。所以这个模式更适合复杂点的项目，简单脚本完全没必要。

4.2 AI Agent：让AI从"写代码的人"变成"项目负责人"

真正的Agent玩法更有意思。不是让AI只是生成代码片段，而是给它一个大目标，让它自己拆解任务、自己决定步骤、自己调用工具去完成。

我用一个开源的Agent框架试过让AI完成一个数据分析任务。任务描述是："读取data.csv，做数据清洗，统计其中A列和B列的相关性，画一张散点图保存为png。"

Agent的做法是这样的：

第一步：检查data.csv是否存在，读取前5行了解数据结构 第二步：检测缺失值和异常值，决定清洗策略 第三步：使用pandas进行统计计算 第四步：生成散点图脚本并执行 第五步：检查png文件是否生成成功，反馈结果

它会自己调用Python环境，写代码、执行代码、看报错、改代码，循环往复直到任务完成。整体执行过程中我不需要干预，跟传统"我出需求、它出代码、我测试"的模式差别很明显。

但Agent的局限也极其明显。最突出的问题是它对任务的理解可能一开始就跑偏。比如"数据清洗"在我脑子里是去掉异常值、统一格式，它可能理解成填充缺失值。一旦方向错了，后面所有步骤都会建在一堆流沙上，而且它会很自信地一路错到底。

另一个问题是执行成本。Agent每调用一次工具、每执行一次代码都是真实开销，一个简单任务可能触发几十次调用。做复杂项目时，我盯着它跑的耐心消耗很大。

4.3 Agent踩坑后的修正思路

用过Agent几次之后，我的体会是：Agent在自动化程度高的任务上很强，在模糊任务上很弱。你给它一个十分清晰、验收标准明确的任务，它表现惊艳；你只给一句"帮我看看这批数据处理一下"，它会给你搞出一堆意想不到的幺蛾子。

我的修正思路是，把模糊任务提前细化。不要直接说"分析这份数据"，而是拆成几个明确的子任务，让Agent逐个完成，每完成一步让我确认一次再进入下一步。这等于把监控点提前埋进去，避免它在错误道路上越奔越远。

4.4 付费工具值不值：Codex的一周体验

热搜里提到"codex付费ai编程软件"，我也专门花钱试了一周。我的体验总结下来一句话：理念领先，完成度还有提高空间。

Codex最惊艳的是它的"自动动手"能力。你给它一个需求，它能在云端直接把代码写好、跑起来、把界面截图给你看，整个流程像是一个远程实习生。尤其是做Web类小应用，从零到可运行可能只要几分钟。

但让我决定不续费的原因也很实在。第一，价格偏高，对我这种不是天天大量写原型代码的人不划算。第二，它生成的代码在复杂架构、团队协作场景里反而不好用——它倾向于把所有逻辑塞进几个大文件，不利于维护。对比下来，Copilot这类IDE内嵌式工具在日常开发里其实更顺手。

5. 提示词工程：我总结的几个"高杠杆"技巧

聊了这么多，我想把最核心的东西单独拿出来说：提示词。我见过太多人说AI写代码没用，结果一看原始提示词，就写了一句"帮我写个程序"。给一个毫无上下文的需求，AI能写出来就怪了。下面是我这几次尝试下来觉得最值得分享的几条经验。

5.1 给AI一个"角色"和"项目背景"

不要上来就"帮我写代码"，先给它一个项目和角色的设定。

我实际用的开头是：

"你现在是一个有5年Python开发经验的工程师。我们正在做一个用于个人照片整理的桌面小工具。技术栈是Python 3.10 + tkinter。请帮我完成以下功能..."

这样做的原因是：AI生成的代码风格和架构决策，会严重受它"猜测的你"影响。你说它是资深工程师，它就更倾向写健壮的代码、加错误处理、写类型注解；你不说，它默认按最简模式来。

5.2 把需求写成"验收标准"而不是"愿望清单"

"我想让这个程序更快"和"要求：数据处理耗时不超过3秒"是完全不同的两种描述。前者是愿望，后者是验收标准。AI更擅长满足后者，因为它能据此调整方案。

我在写需求时，会明确列出：

• 输入是什么格式（文件、数据库、接口调用？）
• 输出是什么格式
• 有哪些边界情况必须处理（空文件、超长文件、非法字符？）
• 性能有没有具体要求
• 代码需要兼容到什么环境（Windows？Python版本？）

每多写一条约束，AI生成的代码质量都会明显上一个台阶。这和跟人沟通需求其实没什么两样——你说得越具体，对方越不容易跑偏。

5.3 让AI先出方案，再写代码

还有一个容易被忽视的技巧：先让AI给方案，确认了再让它写代码。

我现在的标准流程是：

第一轮对话先让它描述实现思路、涉及的文件结构、核心函数的伪代码，我不让它写具体代码。

我看完思路后，可以在这一轮提出调整："这个流程我觉得太复杂了，能不能去掉中间状态缓存？"它修改思路后，再进入生成代码的阶段。

这样做的最大好处是，避免方向错了浪费大量生成时间。如果一上来就让它写代码，写得越长，后面想改方向越难——你看着一大坨代码，舍不得删，硬着头皮修，结果越修越乱。

5.4 让AI自己提问题

我发现一个特别有效的做法：结尾让它主动提问。

每次我提完需求，都会加一句："在没有把握的地方，你可以先问我几个澄清问题。"

这个操作听起来简单，效果却出奇好。AI会主动问"这个文件夹下有没有子目录需要递归处理？""重命名发生冲突时怎么办？"——这些问题恰恰是我第一次没考虑到的边界情况。相当于它帮我把需求清单给完善了，比我闷头一条条列要省力得多。

6. 什么项目适合交给AI，什么项目最好不要

试了这么多，我想给还没上手的朋友一个"适合度清单"。不是所有项目都适合AI写代码，盲目到处用只会让你失望。

6.1 适合交给AI的三类项目

第一类是原型验证型。你想验证一个想法可不可行，比如"用Python连某个API，拉数据做简单展示"，这种项目AI非常合适。它可能写得不够健壮，但能把流程跑通，让你快速验证可行性。

第二类是工具脚本型。像我的批量重命名工具，单机运行、逻辑清晰、不需要高并发，AI完全能胜任。这类"内部小工具"即使代码质量一般，你自己也能很快修修补补。

第三类是学习辅助型。让AI解释代码、帮你改装案例、出练习题、做代码审查，都是很好的场景。它相当于一个随时在线的私人导师。

6.2 暂时别交给AI的项目

第一类是核心业务系统。涉及权限、支付、数据一致性、高并发，这些领域要求代码极高的可靠性和可维护性。AI生成的代码在最坏的边界条件下往往经不起推敲。

第二类是修改一个你不熟悉的已有大型代码库。AI没有全局视野，它改动一个函数时，不会意识到另一个模块正在依赖这个函数的行为细节。你只能靠自己的全局熟悉来兜底。

第三类是涉及安全敏感逻辑的代码。加密、鉴权、防注入等等，除非你自己完全验证过，否则不要让AI独立生成。

我的判断标准很简单：AI适合做"边界清晰、失败代价低"的项目。写成什么样都能改，改坏了也不影响线上，那随意用；反之，谨慎再谨慎。

6.3 我的最终建议组合

如果你现在问我"国内哪个AI写代码最强"，我很难给一个绝对答案，因为不同场景好用程度完全不同。但如果只能选一个"综合体验最好"，我个人会选通义灵码——国内网络稳定、国产模型对中文理解好、主流IDE全覆盖、免费额度够用，日常开发足够了。想要更强的对话式项目生成体验，再配一个Cursor或者直接用网页版Claude。

工具不是越多越好。我现在常用的就两三个，每个工具在固定场景里发挥作用。这也算是我试了一整圈之后的最大感受——AI写代码这件事，工具只占三成，剩下七成是你会不会用。

我自己现在的工作流已经固定下来了：每天在PyCharm里用Fitten Code处理零碎代码补全和快速问答，真遇到完整的小工具需求，开Cursor新项目从头聊，方案层面交给Claude去推演。这套流程走下来，我明显感觉重复性劳动时间少了一大半。但要说以后都不用自己写了，那还早得很——AI写代码不是替代我，是把我的精力从"手写冒烟"里解放出来，放到更该花心思的架构设计和需求推演上。这可能才是它真正的价值。