1. 业余AI开发到底是什么：从"写代码"到"验收代码"
1.1 我理解的"业余AI开发"以及它和传统业余编程差异
我经常被朋友问到一个问题：现在AI这么强，我业余时间学点代码是不是直接让AI写就行了？说实话，这个想法对了一半。AI确实把代码生成的成本压到了几乎可以忽略的程度，但业余AI开发这件事本身，并不是"让AI写代码"这么简单，它更像是一种新的工作方式：你负责描述需求、拆解问题、验收结果，AI负责把想法快速变成可运行的初稿。
我给自己下的定义是：利用生成式AI辅助，以兴趣或个人生产力为目的，去完成原本需要较强编码能力才能搞定的软件开发活动。这句话里最关键的两个词是"个人生产力"和"辅助"。做出来的东西不一定要上架应用商店，也不一定要服务多少用户，很多时候就是解决自己工作或生活中的一个小痛点——比如批量整理文件、把excel数据变成图表、写一个自动巡检脚本、给某个开源项目补个小功能。
传统业余编程的瓶颈是"不会写、写不对、写得慢"；业余AI开发的瓶颈变成了"说不清、验不了、不敢改"。这个差异非常核心。以前你报错，是因为语法不对、逻辑写错，查一下文档改掉就行；现在AI写的代码第一次能跑的概率其实不低，但后续的问题往往出在"这个功能理解错了需求""这个API是它编出来的""这个方案在边界条件下会崩"，你需要有足够的判断力去识别这些坑。也就是说，业余开发者的核心能力正在从"写代码"迁移到"验收代码"，你得能看出来AI交付的东西到底对不对、好不好。
1.2 哪些项目适合业余者用AI做，哪些不该碰
我折腾了大半年，总结出来一个相对靠谱的边界。适合用AI做的项目，一般都有这几个特征：范围小、边界清楚、失败代价低、验收标准明确。比如单机运行的脚本工具、个人网页小应用、数据处理脚本、本地知识库问答demo、给学习项目写的单元测试、简单的智能体demo。这类项目你错了就错了，删掉重来成本很低，正好适合反复让AI迭代。
不适合的项目也有共性：涉及生产环境、涉及真实用户数据、对安全性和稳定性的要求高、需要从零设计一套复杂架构。比如一个要跑在服务器上给团队用的管理系统，或者一个涉及支付流程的app，AI可以帮你写其中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 10，Python 3.10，无外网访问限制"；约束是不能做什么，比如"不要依赖第三方登录、不要使用Selenium、每个请求间隔至少1秒"；验收是能直接跑的命令或结果，比如"用三个测试链接跑通，CSV内容正确且没有重复行"。
我举一个实际改写的例子。原来我说："帮我写个脚本批量下载图片。"改成五要素版本后是："帮我写一个Python脚本，读取images.txt中的图片URL（每行一个），下载到downloads目录，文件名使用URL中的原文件名，下载失败的重试一次，超时时间10秒，最后输出一份success_and_failed.txt列表。环境是Windows 10，Python 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约7GB，int4约4GB。这只是初始权重，实际运行时还要加一些上下文缓存（KV cache），所以显存或内存最好比权重大小多留出2-4GB。
我整理了一个自己常用的参考表，方便做配置选型：
| 模型规模 | 量化方式 | 权重占用 | 推荐运行环境 | 适合场景 |
|---|---|---|---|---|
| 7B/8B | int4 | 约4-5GB | 16GB内存或8GB显存 | 短代码解释、简单脚本生成、格式转换 |
| 7B/8B | int8 | 约7-9GB | 32GB内存或12GB显存 | 质量优先的短任务，速度略慢 |
| 14B | int4 | 约9-10GB | 32GB内存或16GB显存 | 复杂一点的函数编写、中等程度重构 |
| 32B | int4 | 约18-20GB | 64GB内存或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代码开发对业余者来说就不再是"玩票"，而是一种实实在在的生产力工具。
