AI编程实战经验：从工具选型到代码质量把控的完整指南

先把话放前头这篇文章不对任何具体的AI代码工具做神化宣传也不劝你从一个工具全家桶跳进另一个全家桶。我就是一个业余时间写代码、靠AI工具把想法落地成实际项目的人。过去一年多我用AI完成了几个web应用、一套小红书选题抓取脚本、一个给家里用的能耗统计小站甚至一个基于OpenCV的简易图像识别demo。很多项目从有个模糊想法到跑起来能用AI帮我省掉了大量翻阅文档和样板代码的时间。但我也踩了不少坑比如让AI生成的代码在某个边界条件下直接死循环、让AI改了五次SQL查询结果越改越慢、在嵌入式环境里让AI写的寄存器配置直接烧坏了开发板的IO口。这篇文章就是我整理的一份AI代码业余开发经验主要写给三类人想用AI辅助自己开发但不知道怎么开始的编程爱好者、在技术选型和工具选择上摇摆不定的中小团队兼职开发者以及正在尝试用AI写代码但又担心代码质量失控的自由职业者。我会把工具选型、实操流程、分场景用法、质量把控这些事一件件说透也会把翻车现场和排查思路记录在案。1. 别急着写代码先搞清楚AI写代码这件事的本质1.1 AI生成的每一行代码本质上都是概率补全不是逻辑验证很多人第一次用AI写代码时都容易有个错觉以为AI真的理解了业务逻辑是个坐在旁边的资深工程师。实际上当前主流的AI代码生成模型核心仍然是基于上下文的下一个token预测——说白了它是在根据你给它的输入推断最可能接在这个位置上的文本应该是什么。这就像手机输入法的联想功能只不过联想粒度从词语变成了函数、类和整个文件。这个本质决定了三件很重要的事。第一AI生成的代码看起来往往非常流畅、结构完整变量命名规范、缩进统一单看局部会觉得这个人水平可以但它不会真正执行一遍来验证自己的输出。第二AI对语义正确性的判断是统计层面的它知道获取用户信息应该调用getUserInfo比调用getUesrInfo更常见但它并不知道你的数据库里到底有没有这张表、表里字段名是否匹配。第三AI的自信程度和正确概率并没有强相关性它会用同样笃定的语气给你一个完全过时的API调用方式。理解了这一点你就知道为什么很多人在实际开发中会觉得AI时灵时不灵。灵的时候因为你的问题正好落在它训练数据里大量出现过的模式上比如写一个Spring Boot的登录接口不灵的时候因为你问的是需要精确推理和验证的内容比如这个生产者-消费者模型在消费速度大于生产速度时会不会出现死锁。所以正确的使用姿势不是把AI当成能思考的结对程序员而是把它当成一个反应极快、知识面极广、但偶尔会一本正经胡说八道的实习生。你必须自己充当那个最终负责代码正确性的人。1.2 搞清楚AI的边界比学会用哪个工具重要得多我给每个刚接触AI编程的朋友都会做一个简单的分类什么是AI擅长写的代码什么是AI不擅长写的代码。这个分类不是按语言来分的而是按任务的确定性程度来分的。AI非常擅长的是那些模式固定、重复度高、有大量语料可以参考的代码。比如增删改查接口、基于现有组件库搭页面、配置文件编写、写单元测试用例、数据清洗脚本、各种胶水代码和样板代码。这类代码的特点是什么它的正确答案在开源仓库和技术博客里已经出现了几万次AI只需要从这些样本里找出最一般的那个形态给你。AI不太擅长的是需要精密逻辑、强时效性数据和全局约束的代码。比如电商系统的库存扣减逻辑涉及并发、事务、幂等比如嵌入式里直接操作寄存器配置涉及具体芯片手册的时序参数和勘误比如一个需要精确控制内存分配的底层模块再比如那些需要结合实时业务规则做判断的算法逻辑。这些任务不是AI不会写而是它的输出很容易在细节上出现偏差而这类偏差的排查成本往往远超省下的编码时间。还有一类是灰色地带AI可以写但你需要投入大量时间去验证。典型的就是把一段老代码从Java 8迁移到Java 17把一个单体架构的模块改造成微服务调用这类跨边界的大动作。AI可以帮你完成80%的机械性调整但剩下的20%依赖团队内部约定和历史包袱它完全看不见。对于业余开发来说我一般建议凡是跑起来崩了会浪费半小时以上的代码都要慎重让AI直接出稿。2. 业余开发者的AI代码工具正经选型2.1 按开发场景挑工具不按名气挑工具现在市面上的AI代码工具多到眼花缭乱我听到最多的问题是到底哪个AI写代码最厉害。我的回答往往是先别问谁最厉害先想清楚你在什么场景下写代码。不同工具的设计哲学差别很大适合的用法也完全不同。第一类是编辑器内置的AI助手代表是GitHub Copilot、通义灵码、CodeGeeX、文心快码这类它们的主要形态是你写注释或函数名它预判并补全接下来的代码。这类工具最适合的场景是你手上有明确的思路只是不想敲那些冗长的样板代码它像一个非常快的键盘延伸能帮你快速把脑子里已有的逻辑翻译成代码。这类工具最大的优点是侵入性低、不改变你的编码习惯缺点是你很难让它独立完成一个复杂模块的设计——它更擅长接着你的思路往下写。第二类是AI编程IDE或者Agent式工具代表是Cursor、Trae、Windsurf、Claude Code这类它们的核心能力是你给它一个任务描述它自己读取项目结构、分析依赖、生成代码、甚至帮你跑命令和修错误。这类工具适合的场景是你脑子里有一个完整的功能需求但还没想好具体怎么实现。它跟第一类的区别在于它面对的是整个项目上下文而不是你光标位置的那一行。我个人的感觉是这类工具能显著拉高上限但也很容易拉低下限——如果你自己都不清楚功能边界和验收标准它会很热心地帮你生成一个看似完整但到处是坑的实现。第三类是零代码/低代码平台和API接口直接调用式比如各种AI构建应用平台以及直接调用大模型API自己写Agent流程的方式。这类工具如果你处于完全不懂代码的业余状态可以用前者快速搭个原型但想深入定制就很受限。这里我给一个我自己实测后的建议选项表你可以根据自己的情况对号入座场景推荐工具类型理由日常在IDE里写Java/Go/Python思路清晰编辑器内置AI助手如Copilot、通义灵码补全上下文敏感少打断手写流从零做一个前后端项目需要搭骨架Agent式IDE如Trae、Cursor能从项目结构层面帮你设计前端页面和交互开发需要快速调样式Agent式工具AI对话如Claude/Gemini对话视觉和交互细节可以用对话直接改嵌入式/单片机开发编辑器内置AI助手手动review关键寄存器代码必须人工验证内网开发、离线环境私有化部署的代码模型数据合规要求不能连外网写脚本、做数据分析、爬虫等一次性任务各类对话式AI即可不依赖项目级上下文单任务完成度高2.2 几个主流的免费与低门槛方案说到具体的工具我不能不提几个业余开发者最常问的选择。GitHub Copilot在国内同步率略低、付费门槛高而且对于纯业余用户来说很多功能其实过剩。如果你想零成本起步我建议先去试试以下三条路线第一条路线是通义灵码。它对JetBrains全家桶和VS Code都有比较好的支持个人用户免费额度足够日常使用而且它有一个很大的优势——对中文注释和中文需求的识别能力比较强毕竟训练语料里有大量的中文技术内容。你用中文写获取当前登录用户的信息并返回给前端它的生成质量通常比一些纯英文语料为主的工具更自然。第二条路线是Trae。这个是目前我见过对国内用户最友好的AI IDE之一它内置了AI对话、智能体、项目生成等能力而且是原生免配置的。跟Cursor不同Trae在联网和服务稳定性上对国内用户友好很多。我给一个完全零基础的朋友推荐过Trae他愣是靠着聊天在里面生成了一个完整的管理后台页面虽然代码质量一般但至少界面出来了。第三条路线是CodeGeeX和CodeGeeX4这类插件。它们主要优势是免费、对中文支持好、支持私有化部署。如果你在公司内网环境开发数据不能出内网这类可以本地部署的模型就很有价值。我见过一些做嵌入式或军工相关项目的朋友因为数据合规原因只能用CodeGeeX本地部署版或者在内网自建一个代码模型服务效果虽然比不上大厂的超大规模模型但在能跑这个层面上足够用了。3. 我实测下来最好用的AI写代码三步法3.1 第一步先把需求拆到一句话能说清的粒度我踩过最大的坑就是拿着一个含混笼统的需求去问AI。比如说帮我做一个阅读协议页面的开发这个需求如果你是直接丢给AI它会给你生成一个看起来什么都有、实际上完全没法用的页面。为什么因为阅读协议页面这个需求本身包含了很多隐藏决策协议内容是从哪里获取的静态写死还是后端接口返回未同意状态下用户能不能继续操作已同意过的用户再次进入还需要弹窗吗不同版本协议是否需要记录用户同意的是哪个版本正确的做法是先把需求拆成AI能理解的最小原子任务。我一般按功能点输入输出异常处理四个维度来拆。以阅读协议页面为例拆完之后大概是这种颗粒度任务1进入需要阅读协议的页面时弹出协议弹窗弹窗内容从config/agreement.json读取任务2弹窗底部固定两个按钮同意和不同意不同意则关闭弹窗并退出当前功能任务3用户点击同意后把协议版本号姓名时间写入本地存储字段localStorage并关闭弹窗任务4下次再进入该页面时读取本地存储的协议版本号如果与当前版本号一致则跳过弹窗不一致则重新弹出这样拆完你再把任务1单独丢给AI它生成的代码基本就能用了。整个过程就像你带一个实习生干活——你不能说帮我做一个模块你得说帮我把这个接口对接一下、字段映射表在docs目录下、错误码处理按表来。AI的上下限很大程度上取决于你把需求拆得够不够细。3.2 第二步给AI足够的上下文而不是让它凭空猜很多人的第二个大坑是以为AI能读懂项目。实际上除了少数能自动索引整个代码库的Agent式工具外大多数AI工具的核心上下文仍然是你在对话里提供给它的那部分内容。你给的信息越少它就越会使用通用方案去凑答案而通用方案往往跟你项目的现有代码风格、依赖版本、业务约束是脱节的。我给AI提代码需求时基本会采用这样一个上下文模板项目技术栈Vue 3 TypeScript ViteUI组件库为Element Plus 现有相关代码src/api/user.ts里已有getUserInfo接口返回结构为{ code, data: { id, name, avatar } } 需求描述在个人中心页面右上角添加一个头像下拉菜单点击头像展示个人资料和退出登录两个选项数据从getUserInfo取 约束条件头像加载失败时显示默认占位图菜单在点击空白区域时需要自动关闭这个模板看着啰嗦但它把AI最需要的三块信息全给了技术栈、现有代码结构、需求约束。我曾经做过对比实验同样的需求给足上下文和不给上下文AI生成的代码可以直接使用率大概是从三成提升到了八成以上。在实际操作中如果你用的是对话式AI还有个技巧是把相关代码文件直接复制粘贴进对话里让它分析。如果你用的是Agent式工具比如Trae、Cursor就尽量让工具先覆盖相关目录再在对话里明确指定请参考src/api/user.ts这个文件里的函数定义来生成。让AI看到真实代码比让它凭着对你的想象生成代码结果天差地别。3.3 第三步拿到代码不急着跑先做三查一问每次AI生成代码之后我都建议你先做三个检查再动手运行查依赖、查边界、查异常然后让AI自己解释一遍。很多人拿到代码直接一跑遇到报错就丢回给AI去修这样虽然最终也能跑通但你会失去对代码逻辑的掌控力而且会让AI修出一堆打过补丁的烂代码。第一个检查是依赖检查。AI生成的代码经常会引用了它觉得应该存在的依赖库比如生成前端代码时用了lodash的某个函数但你的package.json里根本就没装。先检查一下代码顶部和关键逻辑里的import/require是否都对应了真实的依赖和版本。第二个检查是边界条件检查。重点看三处数据为空时会不会崩比如列表接口返回null、数字为0或负数时会不会出问题、并发访问时有没有竞态可能。这三个地方是AI代码翻车最频繁的点因为它生成代码时脑子里默认的都是理想输入。第三个检查是异常处理检查。AI默认生成的代码里有很高比例是完全不写错误处理的——接口失败呢文件不存在呢用户输入非法呢这些都让它自动跳过。所以拿到代码后建议手动补上try-catch或者错误回调。最后一个动作是让AI解释一遍这段代码。这一步很多人都省了但它其实是你检查逻辑漏洞最好的办法。你就直接问针对你刚才生成的这个函数请逐行解释它的逻辑并指出你认为最可能出错的两个边界情况。如果AI的解释很含糊、跟你预期的业务逻辑不一致那这段代码大概率是有问题的要么重写要么再补充约束条件让它优化。4. 不同开发场景下的AI用法和注意事项4.1 前端开发和App开发AI用得最舒服也最容易失控的区域前端开发是我认为AI带来效率提升最明显的领域而且没有之一。因为前端的产出是看得见的AI生成页面结构、样式布局、组件交互你只需要刷新浏览器就能判断效果验证成本极低。这让对话-生成-验证-修改的循环变得非常顺畅。举几个实际场景。如果你在做uniapp开发微信小程序AI能帮你把页面模板、样式、生命周期函数快速写完但你要特别注意的是各种平台的差异——微信小程序里很多DOM API不可用需要改用uni.xxx系列的APIAI生成的代码如果用的是纯Web思维很容易写出在微信里跑不通的代码。如果你在开发谷歌浏览器插件AI能帮你快速生成manifest.json配置、background脚本、content脚本的框架但插件的权限声明、跨域策略、消息通信这些安全相关的部分一定要自己确认一遍。如果你做一个阅读协议页面这类简单需求AI不仅能生成页面还能顺便帮你把上面说到的那几种状态都覆盖到前提是你把状态分支描述清楚。前端最容易失控的地方在哪里在组件诅咒和视觉还原这两件事上。AI生成代码时很热衷于封装一切它会把三行能写完的逻辑封装成一个抽象组件美其名曰复用实际上让简单页面变得晦涩难懂。我的建议是对于业余开发者的个人项目保持代码尽可能平铺、组件只封装真正重复的部分的原则遇到AI过度封装时直接让它不要抽象直接写具体实现。视觉还原方面AI生成的样式在细节上往往和设计稿有差异它更擅长的是根据你的文字描述生成一个视觉上合理的布局而不是严格复刻设计稿的间距、字号和色彩。如果你是拿设计稿来开发建议直接把截图丢给AI让它描述再让它按描述中提到的设计规范生成代码这个效果比你单纯说照着这个设计稿做好得多。4.2 Java后端和API开发接口模板福音但权限和事务必须人工把关Java后端开发是目前AI代码助手应用最成熟的领域之一因为Java的生态规范性强、各种框架的模式高度一致。我认识的不少Java开发者的日常已经变成了用AI生成Controller、Service、Mapper的骨架代码然后自己往里面填核心逻辑。这个过程确实能省掉大量写样板代码的时间尤其是Spring Boot这种框架一个CRUD接口的Controller层代码AI生成的质量甚至比不少刚工作一两年的初级开发写得还好。但有两块地方是AI生成的重灾区你一定要自己把关。第一块是权限校验。AI生成的接口默认是没有权限控制的它不会主动在你的接口前面加PreAuthorize不会检查当前用户有没有操作该数据的权限。如果你直接把AI生成的接口丢上去很有可能出现任何人只要知道接口地址就能修改他人数据这种漏洞。我的做法是在让AI生成之前把权限需求写进约束条件里比如该接口仅允许管理员调用请在方法上补充对应的权限注解并在方法内校验当前用户是否有权限操作该订单。第二块是事务处理。AI默认不会考虑这个操作需要原子性比如一个下单并扣库存的操作它可能给你分成两个独立的数据库操作中间如果出现异常库存扣了但订单没创建成功。这时候如果你不自己加Transactional数据就彻底乱了。至少在所有涉及多步写操作的接口我都建议你检查一下AI生成的代码是否加了事务控制。另外Java生态里的checked exception处理、日志规范、参数校验注解这些约定俗成的东西AI也容易漏需要你在review时补上。4.3 嵌入式与硬件开发能用但你必须把它当外行来审嵌入式开发是我这几年见过AI翻车最多、但也是大家用得最多的方向之一这是个有点矛盾的现象。说用得最多是因为嵌入式开发过程中的样板代码实在太多了——芯片初始化、外设驱动、寄存器结构体定义、各类状态机的switch-case骨架这些东西占据了开发者大量时间。说翻车最多是因为嵌入式代码的验证成本极高它不是运行在你电脑上、报错就能看到的而是一旦写错轻则功能异常重则烧坏硬件。我用AI辅助过STM32的开发也见过有人用Trae配合Keil来做嵌入式开发。AI在这方面能做的事情包括根据芯片型号生成初始化代码当然你需要核实它给出的寄存器地址是否对应你的芯片手册、写外设驱动的框架比如I2C、SPI、UART的收发函数骨架、生成状态机逻辑、把数据手册里的时序描述转换成代码等。这些工作确实能省不少时间。但嵌入式有个铁律所有涉及硬件寄存器、时钟配置、中断优先级的代码必须逐行核对芯片手册。AI生成的代码里非常容易混入看起来很像但实际不存在的寄存器名或者给另外一款芯片用的配置值因为它训练数据里可能同时包含了多家芯片的代码混淆是大概率事件。另外嵌入式开发里时间是一个非常关键的维度AI生成的代码很少会考虑执行时序比如某个外设从使能到可读之间需要软件延时等待AI不会自动帮你加最后表现出来就是这个设备时而工作正常时而不正常。所以自从我第一次让AI写的寄存器初始化代码直接让开发板部分IO口异常之后我就养成了一个习惯AI生成的嵌入式代码先人工逐行走查一遍再烧进板子。4.4 Agent开发AI自己写AI但先把架构定好用AI写AI正在成为最近最热门的玩法。现在市面上大量AI员工智能体项目本质上是基于LangChain、LangGraph这类框架开发的一套多步骤调用大模型的流程。有意思的是这类开发任务里AI代码工具是最顺手的使用场景——因为Agent开发的逻辑本身就是给模型定义任务、定义工具、定义流程你让AI来写这类代码它非常容易理解你的意图。但Agent开发有一个和传统开发截然不同的坑你的程序运行结果高度不可控。传统代码是确定性的你给同样的输入得到的输出基本一致但Agent每次调用大模型得到的结果可能都不一样。这意味着AI生成的Agent代码问题不会出现在代码本身错了而是出现在代码没有错但编排出来的行为不符合业务预期。我建议做Agent开发时架构设计必须你自己先想清楚别依赖AI。你要明确Agent是单轮对话还是多轮迭代哪些步骤需要调用外部工具、哪些步骤直接让模型推理是否需要引入反思或验证的中间步骤状态管理放在哪里、上下文窗口怎么维护这些问题AI给不了你答案因为它不知道你的业务目标。架构定清楚之后再让AI去实现某一个具体的节点比如写一个从数据库读取用户信息并格式化成上下文的功能写一个调用外部搜索API的函数写一个把模型输出解析成JSON的parser。这样既享受了AI的效率又保证了Agent的整体可靠性。我见过很多人做Agent开发时把一个完整需求甩给AI生成了几百行代码看起来什么功能都有但其实有一半的流程调用是无效的——因为模型输出格式稍有变化整个流程就断了。所以Agent开发的学习路径里我在实践中有个强烈建议不要先学Prompt工程先学如何设计一个可靠的流程。你可以在架构上多花时间把每个节点的输入输出明确定义好让AI去做节点内的实现这个模式是我目前测试下来最稳定的。5. AI写的代码到底会不会让代码质量下降说实话看人5.1 质量下降的三种典型翻车姿势网上一直有个争论AI coding的到来会不会让代码质量下降作为一个在业余开发里重度使用AI的人我的观点是工具确实会放大人的习惯如果你本来就习惯糊弄AI会帮你更高效地生产糟糕代码。具体到实践中有三种翻车姿势最有代表性。第一种是无脑接受生成结果。AI返回什么代码看都不看就直接贴进项目。这种人往往不是懒而是觉得AI比我懂。但正如前面说的AI只做概率预测不做逻辑验证它给出代码的时候根本不知道你的业务场景长什么样。无脑接受的结果就是代码里混入了大量似是而非的逻辑平时不触发一旦触发就是事故现场。第二种是让AI在错误的代码上反复打补丁。很多人遇到AI生成的代码报错第一反应就是把错误信息丢回给AI让它修。这个动作本身没错错的是如果基础设计就是错的——比如函数结构不合理、数据结构不匹配、接口约定冲突——你让AI修一百遍也只是在歪墙上刷漆。我的经验是如果同一个问题的修修补补超过三轮果断推翻重写而不是继续让AI打补丁。第三种是把AI当成背锅侠。代码出问题了第一反应是这是AI写的。但实际上责任在你因为是你决定把这段代码放进项目的是你决定不对边界条件做检查的是你决定省掉测试的。AI不会对任何一行代码负责这叫能力的转移而不是责任的转移。5.2 建立你自己的AI代码质检流程为了不让代码质量滑坡我在持续使用AI辅助开发后给自己制定了一套质检流程。这套流程不复杂但每个项目我都会强制执行你可以直接抄作业。第一步是写代码前定标准。在让AI生成代码之前先想清楚这三件事这个功能需要覆盖哪些输入场景数据结构和接口契约是什么代码层面有哪些硬性约束把标准写在对话里让AI按这个标准来写。第二步是生成后走查清单。我给自己订了一个检查表每次AI生成的代码都要过一遍下面这个表是核心几项检查项具体内容遗漏后果举例空值处理数据源为空时逻辑是否正常空列表导致NPE或页面白屏并发安全多线程/多用户场景下是否有竞态库存扣成负数、订单重复权限验证接口/功能是否校验了操作者身份越权访问他人数据资源释放文件流、数据库连接、网络请求是否关闭内存泄漏、句柄耗尽异常分支网络超时、接口报错时的降级方案用户操作失败时无任何提示硬编码检查是否有魔法数字、写死的URL和秘钥换环境就崩、秘钥泄露第三步是让自动化测试兜底。业余项目很容易忽略测试但越是用AI生成代码越需要测试来兜底。你不需要写很复杂的测试只要把主流程和几个边界条件用单元测试覆盖起来就行。比如你让AI写了一个根据用户等级计算折扣的函数你就写一个测试用例普通用户0.9折、VIP用户0.8折、黑名单用户不参与折扣。测试一旦跑不过说明AI生成的逻辑有问题至少比上线后用户帮你测要好。5.3 对抗代码腐烂AI帮你抢时间技术债却要你自己还AI生成代码还有一个隐性的长期影响就是让项目里的技术债快速累积。什么叫技术债就是写代码时为了追求速度和能跑而牺牲的设计、规范和架构未来你需要花额外时间去偿还。比如AI生成代码时经常绕过了抽象和分层——它把一个业务逻辑直接写在Controller里没有Service层、没有DTO短时间看很爽但当你的项目从3个接口增长到30个接口时这种代码就会变成一座随时会塌的积木塔。我的经验是用AI开发的项目要在两个时间点主动做技术债清理。第一个时间点是功能打通并稳定运行一周后这个时候你已经确定核心流程没问题了赶紧腾出半天时间梳理一下哪些代码是AI生成的临时方案哪些可以合并、抽象、复用。第二个时间点是准备加新功能之前先花十分钟看一下现有代码能不能支撑新需求如果不能先重构再扩展别让新功能堆在旧烂代码上。我们总说AI开发抢的是时间但架构和工程质量要自己付。这句话如果你只是在字面上认同那你大概率还是会慢慢陷入代码腐烂的困境。真正的行动是给每个AI辅助开发的项目设定一个重构节点就像给汽车设定保养里程一样。6. 业余开发里最常见的AI代码问题与排查实录6.1 常见问题速查表建议直接收藏我在业余开发中反复遇到过一些共性问题这里整理成一个速查表每条都附上了排查思路方便你在踩坑的时候快速对照。问题表现可能原因排查与解决思路生成的代码依赖了不存在的库AI按通用模式引用了库检查包管理文件安装对应依赖或让AI换成项目已有库跑起来报错但看代码逻辑没问题AI使用了过时API或环境差异把完整报错栈给AI追问这个API在当前版本中是否已被废弃同一段逻辑生成多次每次都不一样没有给AI稳定上下文锁定技术栈和已有代码在提示词中要求保持风格一致AI生成的SQL在数据量大时性能极差AI没考虑索引和查询体量单独让AI做SQL优化加执行计划分析后人工确认Agent流程偶尔断没有固定原因模型输出格式不稳定用结构化的输出解析器并在解析失败时增加重试逻辑嵌入式代码烧进去后行为异常寄存器配置或时序有问题对比芯片手册逐行检查必要时用示波器确认波形让AI修bug越修越乱基础设计有问题三次内无法解决就推倒重写不要执着于打补丁除了表里这些我还想多说一句关于开发一个App并上架大概要多少钱这件事。很多业余开发者用AI工具之后觉得开发成本大幅降低了于是萌生了自己做一个App上架赚钱的想法。但我要提醒一句扎心的实话AI确实能帮你把App的开发成本从十几万降到几千甚至几百但真正的成本大头从来不在开发上而在后续的运营、合规审核、兼容性适配、内容维护上。一个App上架需要解决的签名、隐私政策、软著、服务器、域名备案等问题AI帮不了你太多。所以我的建议是如果你真的想上架先用AI做个MVP验证需求别在第一版就投入大量精力。6.2 几个我用得最顺手的独家技巧最后分享几个我在实践里验证过、但很少在教程里看到的技巧。这些不算什么高深的东西但确实帮我省了很多时间和精力。第一个技巧是让AI先写测试再写实现。这个思路颠覆了大多数人的习惯。我们在让AI生成功能代码之前先让它根据需求描述写出测试用例然后你review一下这些测试用例。为什么好用因为测试用例本质上是把需求翻译成了可验证的输入输出对它比自然语言描述更精确。如果AI连测试都想不清楚它生成的实现大概率也有问题。而且这一步还能让你同时拿到测试代码后面直接跑通就是双重保障。第二个技巧是用代码评审模式而不是直接问答模式。普通对话式AI的默认行为是有求必应——你让它写它就给你写。但很多工具支持你指定角色我一般会让它切换到资深代码评审者角色先对我贴进来的代码做Review指出潜在问题再给出修改建议。有时候我甚至不让它改只让它找问题。这个模式下的AI判断更谨慎也更符合实习生写代码、师傅把关的协作方式。第三个技巧是善用AI生成Commit信息、PR描述和文档。AI写代码的范畴不只是在编辑器里生成代码它还能承担大量辅助性的脏活累活。比如写完一个功能模块后让AI根据你修改过的文件生成规范的commit message、生成PR描述、甚至是生成这个模块怎么使用的README文档。这些工作之前很多人懒得做但恰恰是最影响项目可持续性的。用AI做这些负担几乎为零却能让你的项目条理性高一个档次。第四个技巧是关于保持代码库小规模的执念。我见过很多业余项目代码越写越多最后自己都不想打开了。为什么会这样其中一个原因是AI的生成成本太低导致功能膨胀很快。我给自己定的规矩是每个业余项目的核心代码量控制在2000行以内超过这个量就必须做模块拆分否则就砍功能。保持代码库小AI的上下文管理才会简单你手动的review负担才会可控项目也更容易长期维护下去。写在最后的一点个人体会说实话我写这篇经验整理最重要的目的不是安利某个工具也不是教大家一套什么高级Prompt心法。AI写代码这件事我个人的体会是——它真的把从想法到能跑的程序之间那条漫长的路缩短到了一个周末的长度让业余开发者可以更频繁地试错、更随心地验证自己的想象力。但这条路并不会因为变短而省略掉思考本身你想不清楚需求AI给你的是精致的误解你不校验代码AI给你的是华丽的隐患你不控制风险AI只能放大你的试错成本。我自己现在开发项目的流程已经固定成了我自己想清楚架构和边界让AI去填肉再由我用测试和Review来把关。这套流程不完美也会遇到AI能力不够边界的情况但它在一个人做一个项目的场景里给了我最大的掌控感和安全感。如果你也正在用AI写代码的路上摸索希望这篇整理能让你少踩几个我踩过的坑也欢迎你去看看我后面会陆续分享的分场景实操细节——那是另一段更长也更具体的故事了。