有句话憋了很久：AI 辅助开发真正费神的，从来不是怎么让 AI 写出代码，而是怎么在一堆“能跑”的代码里，把需求、边界和验收标准一针一针地缝清楚。最近我用 AI 端到端交付了一个项目，从需求访谈、数据表设计、接口生成、页面组装，到测试、部署、文档，全程写下来的业务代码不到一百行。这句话说出去，身边多数同事是不信的。拆开看其实也没那么玄：需要交付一个给业务部门用的台账管理工具，界面要能看、数据要能改、权限要能分清、导出要能直接发出去。真正的难点不在“能不能写出来”，而在“写完的东西到底是不是对方要的，以及敢不敢直接交给对方用”。
这个项目让我对 AI 开发这件事彻底改观。以前我做 AI 生成代码，都是把它当“高级补全工具”，先自己搭好框架，再让 AI 填函数。这次我换了一个路子：把自己当成业务分析员和架构审核人，把 AI 当成施工队，每个环节的产出物都先用文档和清单定下来，再让 AI 去生成实现。整体做下来，我最大的体会是：AI 开发项目，拼的已经不是手速，而是对需求的控制力、对边界的敏感度，以及愿不愿意在“让 AI 干活”之前先把脑子动完。
1. 项目到底要交付什么：先花了两天抠需求
这个项目的甲方是公司内部的一个业务小组，他们以前维护着一张巨大的 Excel 表，记录每个项目从立项到结项的过程信息。信息一多，表格就开始失控：版本覆盖、字段缺失、权限靠“文件只读”、每次汇总都要靠手工整理。所以他们想做一个简单的台账系统，二十几个人一起填，负责人在后台看汇总，最后能把数据导出成表格和图表。作为技术方，乍一听很简单。但真要动手，第一件事不是打开代码编辑器，而是把“帮我们搞个系统”这句话，翻译成“到底有哪些角色、哪些状态、哪些字段、哪些按钮”。
我用了整整两天做需求确认。第一步是把已知的信息整理成一个“功能轮廓”，第二步是把不确定的地方列成清单，逐个找业务方确认。这里就有一个 AI 很有用的地方：让它根据你已掌握的零散信息，反推一份“需求澄清问题清单”。我自己准备时容易漏，比如“删除的数据要不要留底”“导出文件是 Excel 还是 CSV”“不同角色的可见范围一样吗”，这些问不细，后面开发全是在打补丁。
1.1 需求访谈靠的是一张 AI 生成的清单
我当时的做法是：先把业务小组描述的场景原封不动扔给 AI，包括他们现在的表格有哪些列、谁在填、谁在看、每月要出什么汇总。然后让它输出一个问题清单，把“还不确定的地方”全部问出来。这份清单对我的帮助不是替我做了判断，而是把容易忽略的细节铺开放在桌面上。我拿着清单去跟业务方开会的时候，对方都很惊讶，说你怎么连“项目结束后能不能改状态”“离职的人账号要不要保留”这种问题都想到了。
老实说，这些问题不是 AI 聪明，而是它见的足够多，知道一个普通台账系统在落地时会遇到的公共坑。我问完一轮之后，再把答案整理成“角色与权限说明”“字段与状态清单”“导出与搜索要求”三份东西。这一步看起来跟写代码无关，但直接决定了后面 AI 生成的东西会不会被推翻。等到真正进入开发的时候，我发现自己对项目心里有底得多，已经不再是“先做出来看看”的状态。
1.2 把“大概意思”转成“可验收的边界”
需求阶段最大的成果，是把一堆模糊说法变成了可验收的边界。比如对方说“要能看到项目进度”，其实是“列表页要按项目状态筛选，要有完成百分比，还要能在详情页看到最近更新的任务记录”。对方说“要能导出”，其实是“按筛选后的结果导出 Excel，并且文件名要带当前日期”。这些细节变成文字之后，AI 生成起来就非常顺。因为在它眼里，越是具体的描述，“可执行的指令”含量越高，生成出来的代码越接近目标，返工越少。
这个阶段我还做了一个现在觉得非常值的事：让 AI 依据需求清单生成一版“验收用例合集”。没写系统之前先有验收用例，听起来像多此一举，但后来测试时省了非常多时间。因为验收用例里包含的数据场景，比如“新建项目时没有填负责人”“同一天更新了多次进度”“筛选条件和导出条件不一致”，全都变成了真实执行时的测试样本。所以对于想复现这种玩法的人，我的建议很直接：不要一上来就让 AI 写页面，先让它帮你把需求问透，把它当成需求顾问，而不是代码生成器。
2. 技术组合为什么选这套“最没惊喜”的方案
聊完需求，紧接着就要选技术方案。这个环节我特别想强调一个反直觉的经验：AI 辅助交付时，选技术栈的第一原则不是“最新最热”，而是“让 AI 的预测能力处在最舒服的位置”。所谓最舒服，就是你用的技术组合在开源世界里非常常见，资料多、示例多、历史代码多，AI 训练时见过的样本就多，生成出来的内容踩坑概率就低很多。
我给这个项目定的组合并不惊艳：前端用主流脚手架生成默认模板，加一个通用组件库，后端用轻量级 Web 框架加关系型数据库，部署直接放在一台内部服务器上。听起来很普通，但正是因为普通，AI 生成接口、表单、列表、登录校验这些模块时，几乎不需要额外喂示例，它自己就能补齐常用写法。我见过一些同行做 AI 开发时特意选冷门框架，理由是“让 AI 学会新技术栈”，结果生成出来的代码经常带着旧架构的写法，反而要花大量时间纠错，这跟自己写也没区别了。
2.1 让模型在“主流路径”里发挥最长板
这里牵扯到一个很核心的原理：AI 生成代码，本质是在做概率预测。它给出的内容，来自对海量真实代码的学习，越主流的路径，被预测的概率越高，正确率就越高。如果你选一个发布才半年的框架，AI 能参考的样本就少，它就只能靠迁移别的框架的经验来猜，出来的东西就像刚学开车的新手走山路，方向大体对，但细节处可能频繁压线。
所以我专门把“技术约束”写进了给 AI 的提示词里，比如“使用默认模板生成项目结构，不要引入额外的全局状态库”“接口一律返回 JSON，日期字段只传字符串”“前端不许出现自定义组件库里没有的控件”。这些约束表面上是在限制功能，实际上是在给 AI 划定它擅长的舒适圈。让它在一条已经被验证过无数次的路径上去发挥，剩下来的异常情况才值得我用真代码去处理。
2.2 项目骨架与第一版约定
真正启动项目时，我并没有让 AI 一把生成整个系统的全部文件，而是先让它生成“最小可运行骨架”：一个空页面、一个健康检查接口、一张数据库连接表。这一步跑通的意义非常大，它确认了环境、依赖、启动方式这些最底层的东西都没问题。我们平时写代码也不会一上来就写完整业务，都是先能跑通 hello world 再往下堆。如果连骨架都没起稳就冲业务代码，后面一旦报错，你会很难分辨是业务逻辑的锅，还是基础设施的锅。
骨架确定后，我又做了一件事：把目录结构固定下来。不是那种大而全的规范，而是明确到“页面文件放哪、接口文件放哪、公共组件放哪、数据库脚本放哪”。目录一旦定清楚，后续每个模块的 AI 生成就有了位置感。AI 生成的代码经常有一个毛病，就是它喜欢自创组织方式，上次把按钮放在页面里，这次又想抽成公共组件。这时候如果没有目录约束，整个项目很快就会变成一间杂物房，看起来什么都有，找起来什么都乱。
3. 生成链路：从数据模型到页面全靠提示词推进
这次项目里跟 AI 交互最多的阶段，就是从数据模型到页面的生成。我自己的提示词习惯可以概括成三件套：先给字段清单，再给页面行为，最后给验收约束。每次生成一个模块，都按照这个顺序来。比如说要做项目列表页，我给出的不是“帮我做一个项目列表”，而是把需求阶段确认好的字段一个一个列出来，项目编号、项目名称、负责人、开始日期、结束日期、当前状态、进度占比，再补充一句“默认按开始日期倒序，状态筛选项要支持多选”。这样描述下来，AI 输出的页面几乎不用大改，剩下的都是边边角角的视觉调整。
这个过程中，名词统一比什么都重要。同一个字段，我如果有的时候叫“项目名称”，有的时候叫“项目名”，AI 就会产生困惑，可能在列表里用“项目名称”，在新建表单里用“项目名”，最后导出的表头又是另一种写法。所以我在一开始就把字段清单做成了一张对照表，每次提示词里都复制同一份字段名。这个习惯前期会显得啰嗦，但到后期，所有模块之间自动保持了一致性，几乎没有出现字段对不上、关联查不到的情况。
3.1 数据模型怎么“喂”给 AI
数据模型是整个系统的地基，这块我是完全让 AI 先生成，再人工修正的。我把业务方确认好的字段清单和关系描述打包发给它，让它先画出一个数据库表结构方案。比如“一个项目下有多个任务，一个任务只能属于一个项目”“项目负责人来自用户表”“项目状态分为筹备中、进行中、已结项、已中止”。AI 生成的建表语句配合关系型数据库的基础能力，能直接把外键关系和索引写出来。
我在这里只添加了一个必须遵守的约束：所有删除操作都走软删除，也就是加一个删除标记字段，而不是物理删除。这可能是台账系统最重要的设计决策，因为业务方明确说，有些数据填错了可以改，但不能平白消失，后续要对账。这个约束如果是在传统开发里，可能是程序员自己拍脑袋定的，但在 AI 开发模式下，它是通过提示词注入给 AI 的。效果就是，所有相关的列表查询、详情查询、统计数据，AI 都天然地带上了“过滤删除标记”的条件，不用我逐个页面去提醒。
3.2 一轮一轮交付，别让 AI 憋大活
我踩过最大的一个坑，就是试图让 AI 一次生成一大片复杂功能。如果你直接把“我要做一个完整的台账系统，包含项目管理、任务管理、用户权限、导出报表、图表统计”整个扔给它，大概率会得到一个结构混乱、功能残缺的初稿。整个项目里很多文件之间的关系是隐式的，AI 一发话就会迷失方向。正确做法是按模块拆开，一个一个生成，并且每生成一个模块，就把生成结果和运行情况喂回给 AI，让它保持对当前项目状态的记忆。
我在这个项目里的节奏是：数据模型→列表页→新建编辑表单→详情页→登录权限→导入导出→图表页。每一步都自带验收按钮：跑起来、点一遍、看看数据对不对。这种节奏看起来慢，实际上是最稳的，因为每一步的偏差都被限制在可控范围内。如果让 AI 一口气把所有页面都生成完，再集中排查，找 bug 的成本会指数级上升。宁可高频确认，不要攒着一堆不确定拖到最后。
4. 我还写的那几十行代码，都是逼到墙角才写的
必须诚实地说，这个项目并不是零代码。我手写了一些东西，但数量确实很少，而且写出来的部分都集中在“AI 靠猜容易出错，但代价很高”的场景里。整理下来，主要分成五类：环境初始化、鉴权过滤、敏感数据遮蔽、导出文件名的中文编码处理，以及一个对账用的审计日志。这些都不是业务逻辑本身，而是把 AI 生成的业务模块“粘”到真实运行环境里的胶水。真实项目和 Demo 的区别，往往就在这些地方。
比如鉴权那块，AI 能生成一个像模像样的登录页，也能生成一个拦截器，但“哪些接口允许匿名访问、哪些接口必须要登录、登录过期之后怎么跳转”，这些策略是强业务相关的。简单的 API 列表可以通过提示词让 AI 自己推，但真正的边界情况需要人来定。我写这部分代码时没有追求优雅，只遵循一个原则：尽量短小、尽量独立，方便以后有人接替维护时一眼能看懂。
4.1 哪些“小代码”必须人工干预
我给自己定了一个判断标准：如果 AI 生成的代码改起来需要反复试错超过三次，那就说明这个场景它不稳定，我更愿意手写一个固定实现。这个标准筛选出来的基本都是安全类问题。比如用户密码的加密方式、登录态的有效期、导出文件时对特殊字符的处理，这些和外部系统打交道的地方，最怕的是“看起来正常，但边界情况出错”。因为这些错误的代价可能不是程序报错，而是数据泄露或者文件打不开。
另外，我把软删除之外的另一条硬规则也放在了人工代码里：所有的数据变更操作，都要附带写入审计日志。谁在什么时候改了什么字段，改之前的值是什么，改之后的值是什么。这个逻辑非常简单，但 AI 在生成“增删改查”时往往不会主动考虑到。因为它做的是基于过去的平均代码分布来预测，而大多数内部系统的示例代码是不会操心审计的。业务方没有提这个需求，但作为一个有交付经验的人，我知道这类系统上线后一旦数据对不上，第一要找的就是审计记录。这块代码我不会让 AI 发挥，自己写更放心。
4.2 手动写的代码怎么确保未来维护不吃亏
人工代码虽然少，但反而最需要维护纪律。我给自己定的规矩是：每写一段手写代码，一定在旁边留下一段注释，说明为什么不能交给 AI 直接生成。立这个规矩是因为，下次自己或者别人接手时，可能又会觉得“这部分逻辑挺简单的，让 AI 重写一遍算了”，结果把安全策略越改越松。把这些注释当成一种“现场警告”，能有效拦住这种冲动。
还有一个实用的技巧：我把所有手动代码统一放在独立的目录里，不让它们散落在各个业务模块中。这样审查代码时，只要盯着这一个目录，就能看到整个项目的自定义边界。AI 生成的代码可能后期还会被重新生成、覆盖，而这部分人工代码就像是钉子一样钉在原地。后来证明这个做法确实好用，项目转交运维时，对方只需要看几个很短的文件，就知道哪些是系统自动生成的部分、哪些是需要人肉负责任的部分。
5. “没怎么写码”但测试和评审给足了
很多刚接触 AI 开发的人都会产生一种错觉：代码生成很快，测试也可以全速跳过。这是我最不赞同的心态，AI 生成的代码恰恰更需要测试，因为它很容易出现“语法完美但逻辑有偏差”的情况。比如它可能把“进度占比”算成“已用天数除以总天数”，而业务上要求的是“完成任务数量除以总任务数量”。这种错误不管从代码规范还是语法层面都挑不出毛病，只有数据结果不对时会露馅。
所以这个项目的测试策略是两层：一层是让 AI 生成单元测试，覆盖关键计算逻辑和状态流转；另一层是我自己手动过一遍核心场景的回归测试。单元测试方面，我会明确告诉 AI“针对这段函数写五个用例，必须包含正常值、空值、边界值、极端值和异常输入”。这样生成出来的测试通常比较有价值，而不是拿几个正面样例糊弄人。
5.1 AI 写单测，人测边界和权限
AI 写单测有个天然优势：它不用真的启动系统，纯粹根据逻辑推导，就能覆盖大量分支。我对它产出的单测只做两件事：第一，检查每个测试用例有没有明确的断言，而不是走一遍流程就完事；第二，检查它有没有偷懒，比如只测了正常路径、只测了一个值，或者把断言写得特别宽泛。这两关过了，单测代码本身是生成还是手写，对我来说没那么重要。
但边界和权限这些场景，我会保留给真人去测。理由很简单，每次真实业务里最容易出问题的，不是“登录后能做什么”，而是“未登录能不能直接访问那个接口”“A 用户能不能看到 B 用户的私有数据”“删除之后刷新列表会不会报错”。这些场景 AI 不会自己想到要测，因为它生成页面时的默认假设是“使用者都是正常操作的用户”，而真实世界里用户的下一步操作永远是“不可预测的”。
5.2 让另一路 AI 当“对抗式”评审
这个做法是项目到中后期我新增的，效果出乎意料地好。我用另一个独立的 AI 会话，把已经生成的模块源码贴过去，让它以“严格的安全审计员”身份找问题，而且不满足于它说“看起来没问题”。我会专门加一句“请基于以下约束找出五个潜在风险，并说明每个风险的触发条件和修复建议”。这种“对抗式评审”能补上我自己长时间看代码造成的视觉盲区。
为什么要用另一个会话，而不是同一个对话继续问？因为同一个对话里，上下文都是自己喂给它的，它很容易顺着之前的思路走，出错意见也往往是附和性的。换一个完全独立的会话，相当于换了一个“没被影响过的初级工程师”来提意见，往往能指出一些我从没注意到的问题。这次项目里被它抓出来的一个主要问题，就是日期过滤的边界：同一天内创建的数据在按“当天范围”筛选时，直接排除掉了，原因是时间戳没有做零点的归一化处理。这类问题让我很庆幸做了这层额外校验。
6. 文档、部署与演示，才算真正关上项目
如果只看“代码写完、页面能动”，这个项目其实进行到一半都不到。真正让它能“关掉”的，是文档、部署和演示这些收尾工作。这部分同样可以借助 AI，但更需要你心里有个框架。我的习惯是：让 AI 生成文档草稿，然后我再把草稿当成成品去补。你如果直接把 AI 生成的 README 丢给业务方，效果会特别假，因为里面既没有上下文，也没有这部业务方真正的关心事项。
我的做法是这样：先列一个文档大纲，包括项目背景、环境依赖、启动方式、目录说明、常见问题排查、上线检查清单。然后让 AI 根据代码和实际运行情况填草稿，我再补上每次部署踩过的具体坑。这份文档的最大价值不是给外人看的，而是给未来的自己看的，尤其是当系统运行两个月后出了奇怪问题时，查看“常见问题排查”往往比直接读代码更快。
6.1 文档生成不是敷衍，是维护成本分流
给 AI 喂文档任务时，我发现一个重点：它生成的内容需要配上“具体命令”才有实际意义。比如“启动服务”不能只说“运行项目根目录的启动脚本”，要写清楚用什么命令、在哪个目录下、需要哪些环境变量、连接数据库需要做什么准备。这些信息 AI 无法凭空生成，必须由我提供运行环境的事实。所以我通常先把实际的启动命令和环境变量贴给它，再让它整理成结构化的手册。
另外，我还让 AI 生成了一版“验收记录”，把我在测试阶段跑过的场景和结论汇总起来。这里面每一项都对应之前做好的验收用例，比如“新建项目时只填写必填项，保存能不能成功”“修改负责人之后，历史任务会不会跟着变”“导出筛选结果后 Excel 打开是否正常”。这份验收记录后来在转交演示时起了很大作用，因为它让看的人能快速理解系统已经覆盖了哪些场景，而不是听我临时现场演示碰运气。
6.2 部署选择要的是“可保全”，不是“最新”
关于部署，我没去折腾复杂的容器编排和自动化发布，而是选择了一个相对传统的方案：一台内部服务器，一个数据库服务，一个进程托管工具，开机自启。这个方案在很多人眼里不够“现代化”，但对这个项目来说非常合适。原因有两点：第一，系统使用者是二十几个人，并发量很低，性能压力可以忽略；第二，项目后续最长久的维护状态，大概率是一个不太懂代码的运维同事在按手册操作，传统方案对他最友好。
整个部署过程中，我给 AI 分配的任务是“给出一份从零部署到可用的操作清单”，并且限定它只能基于当前服务器的既有环境，不能引入需要额外装一大堆依赖的“高级方案”。AI 生成的清单帮我把步骤规范化了，但服务器上真正需要执行那些命令、哪个目录有权限、进程卡住了怎么重启，这些还是靠我已有的运维常识来补全。项目转交之后，运维同事按着这份清单操作过一次，基本没有回头找我问问题。
7. 实操里那些反直觉的坑和经验
整个项目做下来，最大的收获不是代码，是积攒了一堆不会写在官方教程里的经验。首先要说的就是上下文污染问题。AI 对话窗口能承载的信息是有限的，至少在现在的实际体验里，长会话聊到后面，模型会越来越“健忘”。我前后对话超过几十轮之后，发现它偶尔会把之前的命名搞混，或者把两个模块的约定混在一起。所以我养成了一个习惯：聊新模块时开新会话，把公共约定重新贴进去，而不是一直堆在旧会话里续聊。
具体做法是，给每个模块都准备一份“模块信息卡”：包括数据表字段名、接口命名规则、组件放置规则、验收点。每次新对话一开始，先把这份信息卡丢过去，再让它干活。这样既避免了上下文污染，又保证它每轮生成的风格是统一的。现在回想起来，很多 AI 开发翻车，不是 AI 能力不行，是用户让它怀着混乱的记忆去干活，它只能给你混乱的结果。
7.1 上下文污染比系统报错更磨人
我遇到过最典型的情况：在同一个会话里让它接着生成下一个列表页，它却把上一个列表页的搜索条件带了过来，新页面凭空多出一个跟当前业务无关的筛选框。更隐蔽的是，有时候它会把字段命名规则从“下划线风格”悄悄改成“驼峰风格”，而前端参数还没跟着变。这种问题不会立刻报错，等运行到某个角落才会暴露，排查时非常费时。后来我把“信息卡”改成每次必须重贴，才彻底治好了这个毛病。
除了上下文，另一个大坑是让 AI 对着“不明确的目标”做修改。比如你说“这个列表看着不舒服”，它根本不知道该往哪个方向改。我学到的提问方式是给出具体指向：“把状态改成标签形式，已完成用绿色，进行中用蓝色，已中止用灰色”。只有当你把目标具体化到“颜色、形状、位置”这个粒度，AI 的输出才可能一步到位。项目后期，我几乎不再说“我觉得不对”，而是直接说“把某处改成某种样子”。
7.2 提示词的三件套：范围、样例、否决项
现在回头看，我的提示词本质上都在套一个三件套结构：范围、样例、否决项。范围告诉它做什么、在哪个文件里做；样例告诉它期望的输出长什么样；否决项告诉它什么是不允许做的。比如我要它做一个新建项目的表单，范围是“页面文件里新增一个弹窗”，样例是“参考现有任务表单的布局，保留必填校验”，否决项是“不要修改列表接口，不要引入新的 UI 组件”。这三个条件一列，AI 生成的代码基本不会跑偏。
我强烈建议其他尝试 AI 开发的人，建立一个自己的“提示词模板”。因为每次重新组织语言，都会花不少时间，而且容易漏信息。把这个三件套固化下来之后，无论是开发新页面、修 bug 还是补测试，你都能快速进入状态。我甚至发现，当提示词模板稳定之后，项目的代码风格也稳定了，这比什么规范文档都管用。
8. 如果再来一次，我会怎么把这个流程用得更凶
项目结束后，我复盘了一下整个流程里 AI 最有价值、也最被我低估的环节，最后得出的结论是：需求阶段让 AI 反推验收用例，收益比让它多写两千行代码高得多。很多人把 AI 当成“写代码加速器”，但它其实更像“思考外脑”。你给它一个粗糙的想法，它能帮你扩展出边界条件和风险点，这些恰恰是普通开发里最吃经验的环节。下次如果再接手类似项目，我会在需求阶段就投入更多时间，把验收用例做得更细，让后面所有生成代码的提示词都带上“可被验收”的烙印。
这次项目还让我重新定义了一个词：交付。不是把系统跑起来叫交付，而是“对方能自己用、出问题能自己排查、甚至后续有改动需求时能借助同样的 AI 玩法继续迭代”，才算交付。以前我总担心代码写得少会显得项目“轻”，这次之后我完全放下了这个包袱，你把范围理得多清楚、把边界保护得多严谨、把后续运作铺得多顺畅，才是真正的水平。
8.1 需求阶段利用 AI 反推验收用例
具体来说，下次我拿到任何需求，第一件事不是画页面原型，而是用 AI 生成三层内容：业务场景清单、异常场景清单、验收用例清单。业务场景用来确认正常流程，异常场景用来确认边界处理，验收用例用来当作最后的测试标准。这三层内容确定之后，再决定技术方案，整个开发过程会变得非常“笃定”，因为每一步都知道走到哪里叫“完成”。
而且这些 AI 生成的内容，是能直接沉淀为项目文档的，不只是聊天记录。我会把它们整理到项目目录里，作为所有人共识的工作文件。这样一来，如果中途换人接手，或者一个月后要追加功能，都能凭借这份资料快速回到上下文里，而不是靠聊天记录考古。
8.2 这个玩法真正适合什么人
最后想说一下，标题里说“全程没写几行代码”，听着很轻松，但并不是人人上手都能做到。适合这种玩法的人，最好已经有过至少一两个完整项目的交付经验，能看懂 AI 生成代码的大致结构，能判断接口是否安全、边界是否覆盖、部署流程是否合理。如果完全没有任何编码基础，让 AI 帮你写项目，一旦遇到问题，你会连怎么提问都找不到方向。
换句话说，这个模式不是把程序员变成多余的人，而是把程序员的精力从“敲代码”挪到“定方向、审结果、保边界”。我建议想尝试的人，第一件事不是去研究用什么 AI 工具，而是先找一个很小的内部工具项目，专门练习“怎样把需求描述清楚、怎样验收 AI 的产出、怎样补上它够不到的地方”。把这个练习做扎实了，再谈大规模 AI 交付。
个人经验方面，我最后再分享一个验证过的小技巧：每次让 AI 大改之前，一定先手动备份当前能跑的版本。生成代码再快，回退也是需要成本的，保留一个随时能倒退的状态，你会大胆很多。这次项目能顺利收尾，很大程度上靠的就是“随时可控”的安全感，而不是 AI 有多聪明。
