ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

AI写代码实操全记录:工具选型、提示词技巧与多AI协作踩坑 我一直觉得程序员这行有个有趣的现象越是老手越容易被AI写代码这个话题搞得既兴奋又焦虑。兴奋是因为有些活确实能甩给AI干焦虑是因为朋友圈里那些AI十分钟做出一个完整应用的截图怎么看都像是P的。到我自己真正动手尝试之后才明白那些截图大概率是真的但过程里没写出来的坑也一堆。这篇东西就是我的第一次完整尝试记录从选工具、写提示词到让AI从零生成一个能跑起来的小工具再到多AI协作这种进阶玩法。我尽量把每一步怎么想的、为什么这么做、踩了哪些坑都写清楚给正在观望或者刚入坑的朋友做个参考。1. 先搞清楚一件事AI写代码到底解决了什么问题在动手之前我给自己列了个需求清单。不是随便找个题目让AI写而是先想清楚我希望AI帮我省哪部分时间它哪些方面确实比我强哪些方面只是听起来很强。1.1 它擅长的和我该警惕的用了一阵子之后我发现AI在写代码这件事上优势是实打实的样板代码和重复性结构生成速度极快。写个文件处理脚本、模板页面、配置类代码基本是秒出。冷门语法和API用法检索比查文档快。忘了Python的pathlib怎么拼接路径问一句就出来了不用再翻半天文档。解释和翻译代码能力强。给一段别人写的、加了各种骚操作的代码它能把逻辑一行行说清楚。写单元测试、生成注释、做代码审查这些低创造性高工作量的事情效率确实比我高。但它的短板同样明显。最容易翻车的是逻辑比较绕的需求——比如批量处理多个文件每个文件结构不同遇到异常要单独记录这种它第一版生成的代码大概率只覆盖了最简单的情况边界条件全靠你提醒。还有那种涉及全局架构、模块间依赖关系的代码它经常给出局部最优但整体混乱的方案。另外它对代码库里的存量代码缺乏感知经常生成一段风格完全不兼容的东西。所以我给自己定了个原则把它当实习生不当大神。实习生能快速出活但你必须告诉它背景、约束条件、验收标准而且要检查它的产出。1.2 选哪个工具国内外主流编程助手横向对比现在市面上的AI编程工具很多我试了一圈把印象比较深的几个列了个表工具类型适合场景我的实际体验GitHub CopilotIDE插件写代码过程中的行级/块级补全补全质量高对上下文理解好但国内访问有时候慢CursorAI优先的编辑器对话式生成、改bug、跨文件改动对话体验最好适合从零写小项目但用久了需要适应它的交互方式通义灵码IDE插件中文场景、主流IDE全覆盖国内网络下很稳中文理解好免费版够用Fitten CodeIDE插件PyCharm/VS Code用户轻量、免费补全速度很快但生成长代码块的逻辑性弱一些Claude / ChatGPT对话网页需求讨论、方案设计、代码审查聊思路最好用直接生成完整大项目反而容易漏细节Codex云端编程环境自然语言直接生成应用理念很强但我用下来还是定位在原型验证阶段这里多说一句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程序实现批量重命名文件的功能。具体要求使用tkinter做图形界面不要用命令行。用户选择一个文件夹后列出所有文件的文件名。支持两种重命名模式简单替换把A替换成B和使用正则表达式匹配。重命名之前要能看到预览列表旧名→新名确认后再执行。执行后要支持撤销撤销要把名字改回去。界面布局简单清晰不要花里胡哨。给出完整代码并告诉我如何运行。这个提示词写得不复杂但覆盖了需求边界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_results10, use_cacheFalse)表面上看没有任何问题合法、规范、有参数说明。但一运行报错说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更擅长满足后者因为它能据此调整方案。我在写需求时会明确列出输入是什么格式文件、数据库、接口调用输出是什么格式有哪些边界情况必须处理空文件、超长文件、非法字符性能有没有具体要求代码需要兼容到什么环境WindowsPython版本每多写一条约束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写代码不是替代我是把我的精力从手写冒烟里解放出来放到更该花心思的架构设计和需求推演上。这可能才是它真正的价值。
返回列表