1. 业余AI开发到底是什么从写代码到验收代码1.1 我理解的业余AI开发以及它和传统业余编程差异我经常被朋友问到一个问题现在AI这么强我业余时间学点代码是不是直接让AI写就行了说实话这个想法对了一半。AI确实把代码生成的成本压到了几乎可以忽略的程度但业余AI开发这件事本身并不是让AI写代码这么简单它更像是一种新的工作方式你负责描述需求、拆解问题、验收结果AI负责把想法快速变成可运行的初稿。我给自己下的定义是利用生成式AI辅助以兴趣或个人生产力为目的去完成原本需要较强编码能力才能搞定的软件开发活动。这句话里最关键的两个词是个人生产力和辅助。做出来的东西不一定要上架应用商店也不一定要服务多少用户很多时候就是解决自己工作或生活中的一个小痛点——比如批量整理文件、把excel数据变成图表、写一个自动巡检脚本、给某个开源项目补个小功能。传统业余编程的瓶颈是不会写、写不对、写得慢业余AI开发的瓶颈变成了说不清、验不了、不敢改。这个差异非常核心。以前你报错是因为语法不对、逻辑写错查一下文档改掉就行现在AI写的代码第一次能跑的概率其实不低但后续的问题往往出在这个功能理解错了需求这个API是它编出来的这个方案在边界条件下会崩你需要有足够的判断力去识别这些坑。也就是说业余开发者的核心能力正在从写代码迁移到验收代码你得能看出来AI交付的东西到底对不对、好不好。1.2 哪些项目适合业余者用AI做哪些不该碰我折腾了大半年总结出来一个相对靠谱的边界。适合用AI做的项目一般都有这几个特征范围小、边界清楚、失败代价低、验收标准明确。比如单机运行的脚本工具、个人网页小应用、数据处理脚本、本地知识库问答demo、给学习项目写的单元测试、简单的智能体demo。这类项目你错了就错了删掉重来成本很低正好适合反复让AI迭代。不适合的项目也有共性涉及生产环境、涉及真实用户数据、对安全性和稳定性的要求高、需要从零设计一套复杂架构。比如一个要跑在服务器上给团队用的管理系统或者一个涉及支付流程的appAI可以帮你写其中80%的代码但那20%的可靠性、安全性、异常处理恰恰是最重要的部分业余时间做容易翻车。我自己摔过的跟头是做了一个个人关键词监控工具本地跑得好好的一挂到云服务器就各种环境问题后来意识到问题不在代码而在我根本不该业余时间扛一个需要7x24小时运行的服务的运维成本。所以我的建议是业余AI开发先把自己定位成快速验证工具的人而不是软件服务提供商。做出来自己用、小范围分享、提升工作效率这些才是收益最高、挫败感最低的方向。等到你真的想把某个工具分享出去再花精力去考虑部署、安全、上架这些额外成本。2. 工具链怎么搭顺手模型、IDE插件与智能体分工2.1 模型选型在线通用模型、代码专用模型与本地小模型工具选型这件事我走了不少弯路。一开始听人说哪个模型强就切哪个结果发现大部分时间都耗在切换工具和重新描述需求上实际产出并不多。现在我的选择标准很简单先看任务类型再决定用哪类模型。我把模型分成三类来用。第一类是商用在线对话模型适合一次性回答和思路探讨。比如帮我解释这段代码在干嘛这个报错一般是什么原因给我一个正则表达式。这类模型通用能力强有免费额度用起来不需要想着显存、量化这些事是最省心的入口。它的弱点是很多对话产品不会自动读取你的项目上下文你需要手动贴代码、贴报错。第二类是代码专用模型包括开源的Qwen系列的Coder版本、DeepSeek的Coder系列等。这类模型在代码补全、仓库级理解、多文件改动的场景下表现更稳配合编辑器插件使用效果明显。我个人的体会是写独立函数、补全小模块、根据注释生成代码代码专用模型的命中率确实比通用对话模型高一截。而且开源模型可以本地跑代码不离开电脑对隐私敏感的业余项目特别友好。第三类是本地部署的小规模模型主要解决隐私、离线、长时间调试验证的需求。我后面会用一整章专门说本地部署这里只提醒一句不要一上来就追求70B的大模型先跑7B或者14B理解清楚量化、显存、推理速度这些概念比砸钱上硬件有用得多。选型还有个容易被忽略的点稳定性比热门度重要。很多新模型刚发布时评测分数好看但实际用起来文档少、社区方案少、别人踩坑的经验也不多对业余者来说反而是负担。我现在的策略是选一个主流模型持续用除非遇到明显的瓶颈否则不轻易换。2.2 IDE插件和代码诊断工具别把配置搞成第二个项目编辑器里的AI插件是业余AI开发最容易浪费时间的领域。市面上的插件五花八门什么补全的、对话的、自动写测试的、代码审查的你如果每个都装上、每个都研究一遍会发现一天时间就过去了代码一行没写。我踩过的坑就是某一段时间同时开了三四个AI相关插件互相抢快捷键、重复提示最后反而影响写代码的流畅度。我的经验是插件按补全、对话、诊断三件事来配就够用。补全类的负责在你写代码时给续写建议适合处理重复性样板代码。对话类的负责你选中一段代码后问帮我解释帮我重构这个函数的问题在哪它能看到当前文件内容比单独开网页对话要省事得多。诊断类的负责在运行时报错时自动抓取错误信息配合模型定位问题。配置上有个原则同类功能只留一个。比如补全已经有了就用补全不要再来一个对话类的也做补全运行时报错诊断留一个就好多了反而互相干扰。我目前最常用的组合就是一个编辑器内置对话插件加一个运行诊断工具补全直接用编辑器自带的也行轻量很多。另外别指望插件能完全替代人对架构的理解。插件能帮你快速改一个函数、修一个报错但这个模块该不该拆这个接口设计得合不合理这类问题插件给不出好答案因为它的上下文始终是有限的只能看到你当前打开的几个文件。2.3 用Agent开发还是开发Agent业余者的正确姿势最近Agent这个概念特别热我自己也花了不少时间研究。先澄清一个容易混淆的点用Agent开发和开发Agent是两件完全不同的事。用Agent开发指的是让具备自主执行能力的AI代理去完成一个相对完整的任务比如帮我在这个项目里新增一个用户登录功能包括前端页面、后端接口和数据库表。它能自己读代码、自己改文件、自己跑测试不完全依赖你逐行指挥。开发Agent则是你自己去写代码、编排工具做一个能完成特定任务的智能体比如做一个自动整理下载目录文件的小工具。对业余者来说我建议先学会用Agent开发把它当成一个会写代码但容易跑偏的实习生。给它任务时要写得像给实习生的任务说明书目标是什么、涉及哪些文件、完成的标准是什么、有哪些东西绝对不能改动。最重要的是分阶段检查不要让它一口气改完十个文件而是改完一个模块就停下来让你过目。这样即使它跑偏了你也能在早期发现不会整个项目被带歪。我实际用过一次Agent去生成批量重命名照片并按日期归档的脚本任务书里明确写了三条验收标准先输出一份将要执行的重命名清单、不实际改名、等确认后再执行。结果它在第二步就开始动手改名了因为我没有强调不准在确认前执行任何写操作。这个教训让我意识到给Agent写需求时边界条件比功能描述更重要。3. 和AI协作的工作流提示词如何写上下文如何管3.1 需求描述五要素输入、输出、环境、约束、验收很多人抱怨AI写的代码不对但仔细看需求描述往往只有一句话帮我写个爬虫或者写个自动整理文件的脚本。这种描述AI能发挥的空间太大出错的空间也大。我后来总结了一个需求描述五要素基本上每次都能把AI的生成质量往上提一大截。五要素分别是输入、输出、环境、约束、验收。输入是程序要接收什么比如程序从urls.txt读取链接列表一行一个输出是程序要生成什么比如输出一个result.csv包含链接、标题、价格三列环境是运行条件比如运行在Windows 10Python 3.10无外网访问限制约束是不能做什么比如不要依赖第三方登录、不要使用Selenium、每个请求间隔至少1秒验收是能直接跑的命令或结果比如用三个测试链接跑通CSV内容正确且没有重复行。我举一个实际改写的例子。原来我说帮我写个脚本批量下载图片。改成五要素版本后是帮我写一个Python脚本读取images.txt中的图片URL每行一个下载到downloads目录文件名使用URL中的原文件名下载失败的重试一次超时时间10秒最后输出一份success_and_failed.txt列表。环境是Windows 10Python 3.10不需要登录。验收方式用5个测试URL跑通目录中出现对应文件。AI根据后面这个描述写出来的脚本基本是直接能用的。这个现象背后有个简单的道理AI生成代码的时候是在拿你提供的约束做规划。约束越清晰搜索空间越小答案越准确。反过来你给的信息越空泛它就越倾向于写一个看起来差不多的通用方案而通用方案通常不会刚好符合你的实际情况。3.2 示例代码的正确打开方式让AI先讲解再复用网上找示例代码是业余开发者绕不开的事。但示例代码这东西坑特别多版本过期、依赖不全、为了展示效果省略了错误处理、用的库和你环境里已有的版本冲突各种情况都有。我以前的做法是直接把示例代码复制过来跑跑不通就问AI为什么报错经常一来一回折腾很久。后来我改变了一个习惯先把示例代码交给AI讲解再决定要不要复用。具体做法是把代码贴给AI让它按行解释这段代码的用途并特别标出哪些部分属于必须的核心逻辑哪些属于演示用的冗余代码哪些依赖需要额外安装哪些函数在当前版本里已经废弃。这一步看起来多花了三分钟实际上能省下后面半小时的排错时间。有一次我在网上找了一段Python操作Excel的示例代码直接跑报错提示某个方法不存在。如果是以前我会去查那个方法的新写法但那次我先让AI讲了一遍代码它很快就指出来这段代码是基于旧版本库写的其中某几个API在2.0版本里已经改名而且还默认了数据都是字符串没处理数字和日期。我按它给的新API改完一次就跑通了。这里有个细节要注意AI在解释代码时同样可能一本正经地胡说尤其是涉及具体版本号的时候。所以我会加一句如果对某个API的版本不肯定请明确说不肯定不要推测。让AI承认不确定性比让它硬编一个答案要靠谱得多。3.3 项目记忆文件跨会话不失忆的办法不管是免费版还是付费版对话模型都有上下文窗口的限制。一个会话聊得太长前面说过的重要内容会被截断AI就开始失忆反复问你已经回答过的问题或者把你之前定的技术方案悄悄改掉。这个问题在业余项目里特别明显因为我们的项目往往不是一口气写完的可能隔几天才继续做。我的解决办法是维护一个项目记忆文件习惯放在项目根目录命名成AI_CONTEXT.md。里面分四块写项目目标和技术栈、已经完成的功能清单、当前正在做的任务和卡点、下一步计划和你个人拍板过的关键决定。每次开始新的会话第一句话就把这个文件的内容贴给AI然后说我们继续这个项目先不要动代码告诉我你理解当前状态是什么。等它复述完再让它按任务清单往下做。这个习惯还有个额外的好处它逼着你每隔一段时间就梳理一遍项目进展。很多时候你会发现所谓卡住的问题写着写着就清晰了甚至不需要AI帮忙就已经知道怎么解决。对业余开发来说项目记忆文件既是给AI看的上下文也是给你自己看的工作日志。4. 本地部署大模型的一次完整记录配置、量化与边界4.1 为什么要本地部署隐私、离线、费用与学习价值业余AI开发到一定阶段自然会碰到一个需求有些代码和商业信息不适合发到在线服务里去问。比如你写了一个内部数据处理脚本里面包含同事名单或业务数据你不太可能把整段代码贴给在线模型看。这时候本地部署一个开源模型就是很自然的选项。本地部署的另一个价值是离线可用。有时候你在高铁上、在临时断网的现场想查一个函数写法、改一小段逻辑在线工具都用不了本地模型反而能顶上。除此之外还有费用上的考虑。在线模型用到一定量级是要付费的而本地模型只要硬件允许跑多少次都不额外花钱。对经常要反复调试的业余项目来说省下来的订阅费可能几个月就能抵消一部分硬件升级的开销。但我不建议业余者把本地部署当成一个必需项。它更像一个备用工具和进阶练习。我的建议是先用在线模型把项目做出来等确实遇到不方便外发代码和需要频繁离线调试的情况再来折腾本地部署。不要一上来就买显卡、下模型那是本末倒置。4.2 量化是怎么回事一个音质压缩的类比刚接触本地部署的人很容易被7B、14B、32B、FP16、int8、int4、量化这些词搞晕。我用一个类比解释模型权重文件就像一段无损音乐FP16是原始母带占空间大、质量高int8是压缩成高品级MP3占空间小一些听感基本无损int4是更激进的压缩格式文件更小但仔细听能感觉到一点点细节丢失。具体到显存占用有一个粗略的估算公式值得记住权重文件大小约等于参数数量乘以每个参数的字节数。FP16下每个参数占2字节int8大约占1字节int4大约占0.5字节。所以一个70亿参数的模型FP16需要约14GB存储空间int8约7GBint4约4GB。这只是初始权重实际运行时还要加一些上下文缓存KV cache所以显存或内存最好比权重大小多留出2-4GB。我整理了一个自己常用的参考表方便做配置选型模型规模量化方式权重占用推荐运行环境适合场景7B/8Bint4约4-5GB16GB内存或8GB显存短代码解释、简单脚本生成、格式转换7B/8Bint8约7-9GB32GB内存或12GB显存质量优先的短任务速度略慢14Bint4约9-10GB32GB内存或16GB显存复杂一点的函数编写、中等程度重构32Bint4约18-20GB64GB内存或24GB显存较大范围代码理解但速度仍然有限这张表给的是权重占用不是整机配置。如果你用CPU推理内存要足够大用GPU推理显存要足够大。没有独立显卡也能跑就是慢。4.3 配置参考与实测结论7B/14B/32B怎么选我自己先用一台只有16GB内存、没有独立显卡的旧笔记本试过7B模型。当时用的是常见推理运行时模型文件选int4量化纯CPU推理速度大概每秒3到8个token。这个速度拿去写长篇代码会让人崩溃但回答把这个函数改成返回字典这类短问题勉强能接受。那次体验给我的核心结论是本地小模型适合短查询类任务不适合长上下文项目重构。后来换了一台有12GB显存显卡的机器再跑7B和14B就顺畅多了。7B int8基本能在GPU上跑出每秒几十个token日常对话和短代码修改体感接近在线模型。14B int4在复杂函数生成上的质量明显好于7B但速度还是会比7B慢一些。32B我也试过效果好但对显存要求高我后来觉得业余项目很少需要用到这个级别尤其是不想在硬件上投入太多的话7B到14B的区间已经能覆盖大部分自己用的场景。关于工具选择我推荐从简单的运行时开始比如Ollama这类一键式工具装好之后拉取模型、启动本地服务然后在IDE插件或本地网页界面里接入。整个过程比从源码编译一个推理引擎省心太多。等真正需要深入调优了再去研究更底层的方案。还有一个细节本地部署跑通之后记得在项目记忆文件里记下模型名称、量化方式、启动命令别过两周不碰就全忘了。5. 排错实录当AI生成的代码报错时我做了什么5.1 典型报错拆解以msvcp140.dll这类环境问题为例AI生成代码报错大概分四类环境问题、依赖版本问题、API幻觉问题、逻辑边界问题。其中环境问题是最容易被忽视的因为它跟代码本身没关系。举个很典型的例子不少人在Windows上跑Python程序会遇到由于找不到msvcp140.dll无法继续执行代码这类报错。这个报错本质上不是你的代码逻辑有问题而是系统缺少了VC运行库。AI可以准确告诉你这是缺运行库但解决过程还是得你手动去下载安装对应版本装完可能需要重启终端甚至重启系统。这种过程AI帮不了忙因为它没法替你操作系统级别的交互。这个例子给我一个启发AI擅长解释错误类型但不擅长替你完成环境修复的交互流程。遇到环境类报错正确思路是先按报错关键词搜索如何安装/修复运行库把环境弄好了再说。不要反复追问AI为什么我的程序跑不起来那是在浪费它的能力。依赖版本问题也很常见。AI给你推荐一个库和一段代码你pip install之后发现跟环境里已有的包冲突或者新版本API跟AI写的代码对不上。我的习惯是每次让AI给出涉及第三方库的代码时加一句请同时说明你使用的库的版本范围以及安装命令这样至少在装包那一步就能发现版本差异。5.2 排查三步法复述、排序、先出计划再改代码AI生成代码报错之后很多人的第一反应是把报错贴回去让它重写。我试过效果很一般因为它会基于自己对代码的猜测重新生成一版可能修好了当前报错却改坏了另一个正常功能。我后来总结了一个排查三步法。第一步不让它直接改代码先让它复述对这段代码的理解包括这段代码的输入是什么、输出是什么、我最初的意图是什么。这一步能暴露一个关键问题AI到底有没有理解你的需求。很多时候它写出来的代码跟需求南辕北辙你却还在改一个从来就不对的东西。第二步让它列出代码中可能出问题的三处位置按概率从大到小排序并说明理由。这个排序过程比直接改代码有价值因为它逼着AI去做逻辑推理而不是拿报错信息盲猜。你还可以根据自己对代码的了解否决它排第一的猜测让它去查第二第三个位置往往真实问题就藏在后面。第三步让它先输出修改计划不要直接改。计划里应该写清楚要改哪个文件、哪个函数、改成什么样、影响范围是什么。你审核计划没问题了再让它动手。这一步能避免AI东改一处西改一处改到最后代码面目全非。我吃过亏之后现在凡是多文件项目全程坚持先出计划再动手翻车率明显下降了。5.3 最小复现脚本把500行问题缩成50行排查AI生成代码的另一个重要技巧是做最小复现。一个500行的项目报错你把全部代码都扔给AI上下文里塞满无关内容模型的注意力分散了反而不容易定位问题。正确做法是把报错的场景抽出来写一个尽量短的小脚本只保留触发错误的最小逻辑然后让AI对着这个小脚本排查。举个实际例子。我之前写一个数据处理脚本跑起来报一个索引越界错误。整个流程涉及读取文件、清洗数据、合并表格报错在最后一行但原因可能藏在前面哪一步数据格式变了。我一开始把全部代码发给AI它给了一堆可能的原因都模棱两可。后来我把合并表格并读取索引这一步单独抽出来造了两行假数据写了一个10行的小脚本复现报错AI一眼就看出是合并时索引没重置导致的修复方案非常明确。这个技巧的本质是把大问题拆小。AI对50行的最小复现脚本的判断准确度远高于对500行的完整项目。而且抽最小复现的过程本身就是在帮你理解代码的数据流和关键步骤很多时候你抽着抽着就自己发现问题了根本不用问AI。6. 从做到卖业余AI开发的成本认知与发布闭环6.1 一个app从开发到上架到底要花多少钱做到后面很多人会想把工具分享出去甚至上架应用商店。这时候首先要搞清楚一件事开发成本和生活里说的成本是两回事。如果用AI辅助纯代码开发这一环的成本低到你难以想象真正花钱的地方在后面的发布和运维环节。先说开发环节。主流在线模型普遍有免费额度IDE里的AI插件也有免费档或者低价订阅一个业余项目从零到跑通工具成本经常是0元。我自己做的那些小工具开发阶段一分钱没花。唯一的硬性成本是一台能跑代码的电脑二手旧笔记本也行毕竟AI帮你写了大部分代码编译和运行的压力并不大。花钱的大头在上架。各家平台的政策会调整我只说一个大概的认知框架主流手机应用商店的开发者账号通常有年费比如常见的是几十到上百美元一年部分PC游戏和软件平台也有一次性的上架费用。国内安卓应用市场还涉及软件著作权登记和平台审核这些都是要额外花时间和费用的。服务器成本这块看需求。纯本地的工具完全不需要服务器可以用免费或几块钱一个月的静态托管有账号系统、有后端数据存取的app轻量云服务器一个月大概几十块。我的建议是业余项目尽量设计成没有后端也能跑的形态因为你每引入一个后端就多了一个要维护、要花钱、要处理数据安全问题的东西。6.2 上架之外你还要补的功课隐私政策、测试、商店物料很多人没意识到做完功能只是上架的起点。商店审核团队不会关心你的功能多酷他们关心的是你的应用合规不违规、说明清不清楚、体验稳不稳定。无论做什么样的app隐私政策几乎是标配。哪怕你的app完全不收集用户数据也必须写清楚这个app不收集任何个人数据。这两句话看起来简单但它需要你认真梳理一遍自己的代码确认没有偷偷传数据到某个服务器。建议在项目里新增一个页面或文档专门说明数据处理方式版本更新时也要同步更新。测试环节比想象中花时间。AI写的代码在小规模测试集上表现不错但真实用户的使用场景千奇百怪空列表、网络超时、极端字符、旧版本操作系统。我现在的习惯是在有上架打算的项目里先拉三个不同类型的真人朋友试用几天专门让他们瞎点乱用收集到的崩溃和报错比我自己测试一周还多。商店物料也是一项不显眼但很耗时的活应用截图、功能描述、关键词、版本说明、甚至是图标。截图需要想清楚怎么把核心功能在几张图里讲明白功能描述要避开夸大宣传版本说明得跟着每次发布更新。这些事每件都不难但加在一起可能占据整个项目40%的时间。6.3 我建议业余者认真考虑的时间分配关于做一个app并上架大概要多少钱我现在更愿意把答案拆成两部分钱其实不多真正贵的是时间。AI把编码时间压缩了但验证正确性、补边角、走发布流程的时间不会因为AI而消失甚至因为代码不是自己一行行写的验证起来还要更小心。我给业余者的建议是给项目划分阶段只在阶段转换时需要增加投入。阶段一本地跑通核心功能这阶段用免费AI工具时间投入是几个晚上。阶段二小范围真人试用收集反馈这时候可能需要花几十块买个最便宜的云服务或者测试设备时间投入是两周左右。阶段三正式上架这时候才需要认真评估账号费用、隐私政策、商店物料这些事。如果前面两个阶段的反馈不好你完全可以停在这里不必为了我已经做到了而上架一个没人用的应用。我自己的体会是业余AI开发最舒服的状态是把AI当成一个随叫随到的结对编程搭子而不是一个替你完成所有工作的外包团队。你始终要保留对项目方向的判断力该不该做、做到什么程度、哪些地方必须人工把关。掌握了这个平衡AI代码开发对业余者来说就不再是玩票而是一种实实在在的生产力工具。