坦白讲我用AI写代码的时间不算特别长但架不住踩的坑多。从最开始拿ChatGPT生成一段排序算法都要改半天到现在能比较顺畅地让AI帮我搭一个小工具、修一个诡异报错、甚至梳理一个陌生项目的结构中间的弯路没少走。最近看到不少朋友开始尝试用AI做点小开发问的问题也特别集中所以干脆把这段折腾下来的经验整理成一份笔记主要面向那些不是专业程序员、但想借助AI实现点东西的业余开发爱好者。这篇文章不会教你什么高深理论全是实操中摸出来的土办法和血泪教训希望能让你少走点弯路。先说下这份经验整理到底覆盖了什么提示词到底该怎么写给AI才有效、模型怎么选才不浪费钱、拿到AI生成的代码之后怎么验证和调试、遇到报错怎么让它自己修、以及怎么把一个模糊的“我想做个XX”变成AI能执行的清晰需求。这些东西看着散但拼起来就是你用AI做开发的完整闭环。1. 先泼一盆冷水AI业余开发到底能做成什么样很多人对AI写代码的期待是“我说一句话它啪地交给我一个能上线的App”。这个期待不能说完全错但相信我真这么玩的人绝大部分都卡在了第一周。AI现在更像一个知识面极广、但没有任何项目经验的实习生它可以在你明确说出需求时写出非常漂亮的单段代码但一旦涉及多文件工程、状态管理、环境依赖、版本迭代这些东西它就会开始胡言乱语。1.1 你手里的AI是个“经验丰富的实习生”我用一个特别贴切的类比跟你讲跟AI协作开发本质上就是你带一个脑子很快但完全不懂你业务的新人干活。你跟他说“帮我写个脚本把文件夹里所有Excel的某几列数据合并成一个表格”他能一口气给你写出来甚至还会贴心地加上异常处理。但你要是跟他说“帮我把这个项目做成一个能卖的软件”他会满脸问号——卖什么卖给谁收多少钱数据存哪界面长什么样这些信息你全都没给他他当然什么也做不出来。很多业余开发者的第一反应是AI不行生成的东西根本没法用。但实际问题是需求没有说清楚。我把这个阶段总结为AI需要的是“需求说明书”不是“一句模糊的愿望”。1.2 我给自己定下的三条铁律踩了无数坑之后我给自己定了三条规矩现在基本每次开发都会遵守第一每次只让AI干一件具体的事。不是“帮我做个网站”而是“帮我写一个Python函数输入是一个日期范围输出是该范围内所有工作日的日期列表”。任务越小AI的准确率越高。第二AI生成代码之后必须自己跑一遍。我自己不懂编程的时候总幻想“AI写的肯定没错”但事实是它经常出错而且错得很有迷惑性。你让它写个快速排序它可能返回的结果是对的但边界条件处理完全错了数据量一大就崩。第三把AI当搜索引擎使是最大的浪费。它的真正价值不是告诉你“怎么实现”而是帮你在“实现的过程中”省掉重复劳动。写复杂逻辑、查API用法、写单元测试、解释报错这些才是它的主场。1.3 业余开发者的典型翻车路径我观察到的业余开发者翻车路径都大同小异先从“帮我写个XX”开始AI生成了一大段代码兴奋地复制粘贴运行报错把报错丢给AIAI改一遍再运行再报错循环几次之后彻底放弃。这个循环的破局点其实不在于AI而在于你自己必须建立最基础的程序运行认知——至少得知道代码在哪里跑、报错在哪里看、依赖怎么装。后面我会专门讲这一块怎么补。2. 写提示词不是说话是下需求单如果只能从这篇文章里带走一样东西那就是提示词的结构化方法。很多朋友用AI写代码的体验差八成问题出在提示词上。你跟AI说话跟给人下需求是完全不同的两回事人听了模糊指令会自己脑补AI只会老老实实或者胡说八道地按它理解的字面意思执行。2.1 我自己常用的五要素提示词模板后来我把提示词固定成了一个模板每次写代码需求都往里面填效果非常稳定。这个模板一共五个部分角色你是一名资深Python开发工程师 任务帮我写一个脚本读取指定文件夹下的所有CSV文件 输入文件夹路径作为命令行参数传入 输出合并所有CSV文件的公共列输出合并结果到新CSV文件 约束使用pandas库处理编码为utf-8内存占用要小你可能觉得这不就是把话说清楚吗对就是这么朴素。但绝大多数人做不到。你试试把上面的“任务”换成“帮我处理一下数据”AI给你的绝对是一坨无法直接落地的东西。角色设定很重要AI在“你是资深工程师”和“你是代码助手”两种设定下写出来的代码质量完全不同前者会考虑异常处理、代码规范和性能后者只会给出“能跑的最小实现”。2.2 示例驱动先给Input/Output再让AI干活有一类需求光靠语言描述是说不清的比如“帮我写一个正则表达式提取电话号码”。你描述半天格式、边界、特殊情况AI还是容易搞混。这时候最有效的方法是给示例这招我从实践中总结出来效果奇佳请写一个Python函数从文本中提取中国大陆的手机号码。 示例输入联系人张三电话13812345678备用号码010-87654321 示例输出[13812345678] 注意只提取11位数字开头的手机号码不提取座机号码。为什么示例这么管用因为AI本质上是在做模式匹配你给its的示例就是最精确的模式描述。人脑需要逻辑AI需要样例。这一点在写正则、写复杂的字符串处理逻辑、写数据清洗脚本时特别明显。2.3 让AI自己把任务拆成todo列表遇到稍微大点的开发任务我现在的习惯是第一步不让AI写代码而是让AI先拆任务我想做一个命令行工具功能是监控某个文件夹当有新文件出现时自动按扩展名移动到不同子文件夹。 先不要写代码先帮我把这个工具拆分成具体的功能模块列表每个模块说明它的职责和输入输出。这个操作有奇效。拆完任务之后你会有两个收获第一你发现自己原本脑子里模糊的需求其实包含了“文件监控、扩展名判断、文件移动、日志记录”至少四个子问题第二你会得到一个可以逐条喂给AI的任务清单。每完成一条你就让AI生成对应的代码模块然后拼接起来。大任务拆小了之后AI的出错率指数级下降。2.4 关于代码诊断插件的一点实际体验现在很多AI编程工具和IDE插件都内置了代码诊断功能例如在VSCode里搭配AI插件你写代码时它能实时标红报错。我的实际感受是诊断插件帮你省掉的不是“写代码”的时间而是“发现错误”的时间。以前我写完代码跑起来才发现错了现在很多低级错误在保存文件的那一刻就被插件标出来了。但注意诊断插件报的错不一定都对它也会误报。特别是当你在写一些比较新的库的代码时插件可能因为不认识某个API而标红这时候不用慌以实际运行结果为准。诊断插件的价值排序是语法错误 类型错误 潜在逻辑问题后面那种参考一下就行别太当真。3. 选模型、搭环境这些钱和功夫省不得代码写得好不好除了提示词模型本身也很关键。我身边有不少人图便宜或者图方便拿一些比较弱的开源模型跑代码生成结果被坑到怀疑人生。做AI开发这块我对模型的建议是代码生成场景要用推理能力强的模型对话场景可以随便但代码场景不能凑合。3.1 代码生成场景我推荐什么模型不同模型的代码能力差距是非常明显的。我自己试过好几款如果只让我推荐日常代码生成和调试优先用Claude系列和GPT系列的较新版本它们对复杂指令的理解能力和代码正确率确实高一个档次。特别是那些需要“理解上下文才能写对”的代码比如“在上一个函数的基础上把返回值从列表改成生成器”弱模型很容易给你重写一遍或者理解错。如果对成本敏感也有一些性价比很高的选择比如用国产模型跑一些模板化的代码任务比如生成增删改查接口、格式化代码、写单元测试完全够用。我的建议是模板化任务用便宜模型逻辑复杂任务用强模型别一刀切。3.2 本地部署大模型到底值不值我理解很多业余开发者的顾虑代码是隐私的不想传到云端想本地部署一个开源大模型来写代码。这个想法我支持但实操下来得泼点冷水。本地部署对人家的硬件要求确实不低——显存至少16G起步内存32G以上才跑得动7B级别模型而且7B级别的模型写代码能力只能说勉强能用14B勉强像样真要达到“好用”的程度得70B级别那硬件就已经是工作站了。我自己折腾过一阵子本地部署结论是如果只是为了写代码本地部署的性价比现阶段不高。你有那调模型、配环境的时间用云API早写完好几个功能了。但如果是为了学习、或者确实有隐私需求那本地部署是值得玩一玩的至少能让你搞懂“模型是怎么跑起来的”这件事对后续理解AI开发整体链路很有帮助。顺带一提本地部署的配置方法各大模型平台都有文档照着做就行没有太多黑魔法。3.3 前端开发领域特别值得投入说到用AI写代码我强烈建议业余开发者从前端下手。为什么因为前端有即时反馈。你写一个HTML页面双击打开浏览器就能看到效果不对马上改你写一个Python脚本还得配置环境、处理依赖、面对黑乎乎的命令行。对于初学者即时反馈就是最好的老师。前端开发的skills积累到一定程度之后你做任何小工具都会特别快。比如你想给家里人做一个“每周菜谱生成器”用AI生成一个网页再配合一个简单后端接口甚至直接用浏览器本地存储一晚上就能出成品。我自己很多朋友就是从这种小玩意开始慢慢建立起“我能做东西出来”的信心。这个信心比技术本身更重要。我还想多说一句前端框架的事。很多业余开发者一上来就纠结React、Vue、uniapp选哪个问各种技术选型。我的建议是如果你用AI开发框架选择基本取决于AI最熟悉哪个。AI对React和Vue的语料覆盖都很广哪个都行但如果你要跨平台做App那uniapp这种一套代码多端上架的方案对业余开发者就特别友好微信小程序、安卓、iOS都能出包AI对它的API也能准确生成。选框架不是选最好的是选AI生成错误率最低的。4. 一个完整实战从需求到交付的全流程演示前面讲的都是心法这一节走一个完整的实战流程。我拿一个特别适合业余开发者的项目举例用AI做一个批量图片压缩工具。这个项目麻雀虽小五脏俱全能覆盖掉需求拆解、代码生成、调试修复、打包交付的全流程。4.1 第一步需求描述但说人话我的第一版提示词绝对不可能是“帮我做个图片压缩工具”而是这样任务写一个Python脚本遍历指定文件夹下的所有jpg/png图片。 对每张图片做压缩处理将压缩后的图片保存到输出文件夹。 要求 1. 使用Pillow库处理图片 2. 压缩后图片画质不低于原图的80% 3. 输出文件体积要明显小于原文件 4. 命令行运行接受输入文件夹和输出文件夹两个参数 5. 处理完成后打印统计信息包括处理了多少张、总节省了多少空间你对比一下“帮我做个图片压缩工具”和上面这个需求。后者AI能直接给出基本可以运行的代码前者AI会反问你要用什么库、压缩到什么程度、要不要GUI界面。你写得越具体来回沟通的轮数就越少。4.2 第二步AI生成代码之后别急着复制拿到AI生成的代码我建议你花一分钟做一个动作把代码通读一遍。你不懂编程没关系就盯着看有没有以下特征——没有主函数入口、没有处理文件夹不存在的异常、写死了某个路径没有用参数接收。这三类问题即使不懂代码的人也能从字面上看出来。我看过太多人把AI生成的代码直接复制运行报错后开始跟AI来回拉扯。每次报错都比上一次更复杂因为AI基于报错信息反复修改很容易改出一堆补丁代码越补越乱。我的习惯是第一次生成的代码如果有明显的低质量问题直接重新生成而不是在烂代码上缝缝补补。实测重开的成功率远高于修补。4.3 第三步让AI解释错误而不是只报错误运行报错时我见过的最失败做法是把整段红色报错直接扔给AI说“这个怎么改”。正确姿势是告诉AI三件事你的代码文件内容或关键片段、完整的报错信息、以及你期望的行为。我惯用的提示词格式是运行下面代码时出现报错 [粘贴代码] 报错信息 [粘贴完整报错] 我的预期是脚本应打印处理结果但实际上在读取图片时中断了。 请分析可能的原因先不要修改代码先告诉我问题出在哪一行为什么。看到没我特意加了“先不要修改代码先告诉我问题出在哪一行”。为什么这么干因为AI有一种很强的不良倾向——你说“报错了”它直接甩给你一份重写的代码。新手一看代码变了也不知道改了哪下次报错还是不会处理。让AI先分析原因你才能慢慢建立对代码的掌控感。这招非常重要真的建议大家实操。4.4 第四步验证输出让AI补充测试代码终于跑通了输出结果看起来也正常。到这就能完事了吗远远不够。AI生成代码最大的隐患是边界情况没处理。你还可以让AI帮你验证代码运行正常了。现在帮我对这个脚本设计几个边界测试 1. 空文件夹的情况 2. 文件夹里有非图片文件的情况 3. 图片文件损坏的情况 4. 文件名包含中文和空格的情况 请逐个告诉我我现在的代码能否正确处理如果不行需要修改哪里。这一步能帮你把很多隐藏雷提前排掉。我做过太多项目AI生成的代码在主流程上一路畅通但碰到一个文件名带空格就崩了、一个空文件夹就报错了。这些坑如果等你自己一个个踩能踩到怀疑人生让AI提前过一遍它大多时候能自己发现并修复。4.5 第五步打包交付让AI帮你变成双击可用的东西对于业余开发者来说你写了一个脚本总不能每次运行时都打开命令行敲python指令吧特别是如果你想做个小工具给非技术的朋友或者家里人用。AI也可以帮你解决分发问题脚本已经测试完成。我想把它打包成一个Windows下双击就能运行的程序。 请告诉我用PyInstaller打包的具体步骤包括 1. 需要安装什么库 2. 打包命令是什么 3. 打包后如何验证exe文件是否完整运行你看这已经完全是一个“做产品”的思维了而AI在每一步都可以充当你的技术顾问。不光是打包成exe包括你想把这个脚本加上一个简单的图形界面AI完全可以帮你生成Tkinter的界面代码。这个技能树一旦点开你会发现做小工具的速度超乎想象。5. 常见问题与排查技巧实录跟AI协作开发这么久我自己总结了一些典型问题和排查思路整理出来供你参考。5.1 五种典型的AI代码翻车现场先聊聊我遇到的AI翻车场景这里面的规律性很强翻车类型典型表现高发原因应对策略幻觉函数调用了一个不存在的第三方API模型记忆错误让AI用pip搜索确认库的真实API古早版本语法生成了已经废弃的写法训练数据滞后提示“用最新稳定版语法并标注版本”环境不匹配写好了代码但你的电脑跑不了依赖冲突或缺失让AI生成requirements.txt并逐项安装验证自作主张改了你没让它改的代码逻辑多轮对话上下文污染明确说“只修改XX函数其他不要动”无限补丁修一个错引起三个新错在坏代码上反复修改放弃当前版本重新生成上面表格里每一条我都真实踩过。最典型的就是“幻觉函数”AI写了一个利用某库API的代码结果你一查这库压根没这个函数。怎么防让AI把关键函数的官方文档链接也一并给你或者让它先确认这个API的调用方式再写代码。5.2 报错排查的正确姿势关于报错排查我记得特别深的一次是帮一个朋友排查“由于找不到msvcp140.dll无法继续执行代码”的问题。他当时在某处下载了一个软件双击运行就报这个错第一反应是让AI修这个DLL文件。实际上这个问题的本质是电脑缺少微软Visual C运行库安装对应的VC_redist程序就能解决完全不需要什么边角操作。这个案例给我的启发是AI排查问题的能力上限取决于你描述问题的方式。你给AI的上下文越精确它的诊断越准确。如果只是丢一句“我的程序打不开了”AI也只能给你一句“请提供更多信息”。但如果你把完整的报错弹窗文字记录下来给它它基本能给出几百上千字里出现频率最高的那个正确答案。5.3 上下文管理的实战技巧跟AI协作开发有一个特别隐蔽但特别浪费时间的坑上下文污染。举个例子你一开始让AI写的是一个图片压缩脚本后来你问它“怎么遍历文件夹里的文件”它可能会参考前面的对话把回答限定在图片处理的场景里。或者你改需求说“改成批量重命名”AI可能在旧代码逻辑上打补丁而不是重新实现。我的做法是长对话及时分叉。一旦当前任务告一段落就把关键信息最终可用的代码版本、关键配置复制保存到自己的笔记里然后新开一个对话开始下一个任务。如果新任务的代码跟老代码相关就把老代码精简提炼后粘贴给新的对话。宁可麻烦一点记录也不要让AI在一堆旧上下文里“猜”你的新需求。5.4 关于“AI本地管理代码”的几条避坑速查表最后再给一份避坑速查表都是我实打实遇到的问题字虽短但每一条都值不少钱代码永远要有版本备份。AI改代码之前把当前可用的版本另存一份。别问我怎么知道的——跟AI协作改坏代码又改不回去的经历我敢说每个认真用过AI写代码的人都经历过。不要相信AI说“肯定没问题”。它的自信程度跟代码正确率基本无关。凡是AI说“肯定没问题”的我都会更加警惕。用AI写代码之前先想清楚失败成本。如果这个代码是你真正工作要用的请务必找懂行的人帮你review娱乐项目、学习项目随便造但生产环境不能把自己的职业生涯压给AI。环境问题学会自己排查。AI没法替你点击鼠标很多问题本质上是你自己的开发环境没配好。你花半小时搞懂什么是Python路径、什么是环境变量、什么是包管理会比让AI修一百遍代码都有用。别用一个AI生成的错误代码去问另一个AI怎么办。多模型交叉验证在某些场景有效但大多数情况下只会得到两个不同的错误答案。6. 关于“教别人用AI赚翻了”的一点个人看法最近网上关于“教别人用AI赚翻了”的热度很高我也看到不少朋友问我怎么看。我的态度很明确利用信息差做科普和培训本质上是在帮助别人节省学习成本这个价值是真实的。但作为业余开发者我觉得更重要的不是去“教别人用AI”而是自己先用AI做出点东西来。你亲手把一个想法变成了可用的工具这个过程中积累的解决问题能力、排除故障韧性、对逻辑的理解是任何培训费都换不来的。6.1 不要神化“AI代写代码成交”我见过不少人也想复制“帮别人做个小工具收点辛苦费”的模式。这个模式本身没问题但现实是你光靠“AI生成代码”是交付不了东西的。客户的电脑环境千奇百怪他们的需求描述天马行空你要做的绝不仅仅是生成代码还包括和环境搏斗、和客户沟通需求、反复修改调整。这些环节AI可以辅助但替代不了你。你真正的核心竞争力不是会使用AI工具而是会解决“代码离开你手之后发生的各种乱七八糟的问题”。6.2 业余开发者的真实边界我也得诚实地告诉你业余开发者的边界在哪里。用AI做小工具、自动化脚本、简单的网站和网页这是完全可行的但如果你想开发一个完整的App并上架应用商店成本不仅仅是你想象的那样只是写代码——还有开发者账号费用、隐私政策、UI设计、服务器费用等等。AI能帮你把代码这部分成本压到很低但代码从来不是产品的最低成本项。我见过太多业余开发者满怀热情地开始然后发现最后卡在了某一个非技术问题上。这不是坏事这正好帮你搞清楚自己喜欢什么。有些人对产品感兴趣有些人对技术实现感兴趣有些人就是想享受“做出来东西”的感觉——搞清楚自己属于哪类人比盲目跟风做开发重要得多。6.3 最后分享一个我自己坚持的习惯聊了这么多最后分享一个我坚持了很久的习惯也许对你也有用每完成一个小项目花半小时用AI帮你写一篇项目总结文档。不是那种技术文档而是记录这个项目解决了什么问题、用了什么方案、遇到了什么坑、怎么解决的。这相当于给自己的经验做一个增量存档。后面你技术慢慢变强、工具不断迭代回头看这些记录会发现自己走了好长一段路。AI代码开发这条路没有终点只有不断踩坑和填坑的循环。你愿意看到这里说明你对这件事是认真的。那么别光看找一个身边最无聊、最重复、最耗时间的小事试着用AI写个脚本解决它第一个作品完成时的成就感比刷一百条AI相关内容都实在。