先说结论：这个项目确实交付了——我用 AI 端到端交付了整个内部工具，全程没写几行代码，上线后在内网跑了两个多月，用户没有骂娘。仓库里我亲手敲的部分，数下来大约一百行出头，剩下的全是一条条 AI 生成、我再逐段 review 改出来的。但如果你把"没写几行代码"理解成"躺着等交货"，那这篇文章就是来打破这个幻想的。

这个项目叫它"设备借用管理后台"吧，任务本身不复杂：给一个三四十人的内部团队做一套设备台账、借用归还登记、超期提醒和统计看板的小系统。放到一年前，我的第一反应是排期——按常规节奏，需求确认加联调加测试，怎么也得三周。这次我决定换一种打法：让 AI 承担从需求到代码、从测试到修复全链条的产出，我只做定义边界、做判断、验收和兜底。从立项到部署上线用了五个工作日，之后又稳定跑了两个多月。

这篇文章不聊什么高大上的架构，就讲讲这一趟完整的实操过程：我做了哪些准备、AI 在哪些环节干了什么、哪些地方翻车了、哪些代码最终我还是亲手写了。无论你是程序员、产品经理，还是正在犹豫"要不要让 AI 深度参与项目交付"的人，这篇应该都能给你一些能直接拿去用的经验。

1. 项目定调：什么样的活才敢交给 AI 端到端

先说需求是怎么来的。隔壁团队的 A 同事一直用共享文件夹里的表格管设备：几十台笔记本、测试手机、外设，谁借走了、什么时候该还、上个月谁用得最勤，全靠手工维护。表格越来越乱，超期了也没人记得提醒。A 找到我，原话是"搞个系统呗，能登记，能提醒就行"。

别小看这句"能登记，能提醒就行"，拆开来看其实是这么一组需求：设备台账要有增删改查和导入导出；借用和归还要有明确的状态流转，借出、归还、续借、挂失、报废；超期之后要自动提醒借用人和管理员；还要有一张统计看板，展示借用频次、闲置率和超期率。再加一层权限：普通成员只能看自己和本部门的记录，管理员能看全部。这些需求每一行都很普通，但组合起来就是典型的"小但麻烦"的内部管理系统。

1.1 需求长什么样：一个"小但麻烦"的内部工具

这类需求有一个关键特征：业务规则完全成熟。CRUD 加状态机加定时提醒，是软件工程里被写了无数遍的东西，模型训练数据里根本不缺同类代码。它不涉及复杂的并发交易，不涉及支付，也不涉及对外承诺，数据量撑死几千条记录。换句话说，即使 AI 在某些细节上犯了错，修复成本也完全可控。

这决定了我的第一个判断：选型不是看项目大不大，而是看它处于"经验密集区"还是"判断密集区"。设备管理后台属于典型的经验密集区，所有踩坑点在网上都有海量现成答案，模型大概率见过。而像老系统重构、核心交易链路、需要强合规审计这类项目，哪怕看起来只有几页需求，也不适合让 AI 全线代劳——因为那里面的坑不是"代码怎么写"，而是"业务到底怎么规定"，模型不知道你们公司的真实约束。

1.2 判断标准：这项目为什么适合 AI 端到端

我给自己列了三个判断标准，这次全部通过。

第一个是领域成熟度。设备管理、审批流、提醒任务、简单看板，每一块都有海量公开代码和文档，模型的输出质量有保障。反过来，如果现在让我用 AI 端到端做一个图像识别算法训练平台，再带一个模型调参界面，我大概会犹豫很久，因为领域里"对与错"的判断远超"代码能不能跑"。

第二个是集成复杂度。这个项目不需要对接公司现有的统一登录体系，不需要从老系统迁移历史数据，唯一的存量数据就是那张共享表格，导进来就行。没有外部依赖，意味着 AI 生成的东西不会因为"接口文档写错了""鉴权方式特殊"这类外部因素而连环翻车。

第三个是失败代价。最坏的情况就是数据丢失或者系统不可用，我手动恢复备份即可，不会造成资金损失，也不会影响外部用户。这个代价我愿意承担。如果是给客户做的交易系统，这个实验我是不敢做的。

1.3 三条底线：哪些判断我绝不外包给模型

决定用 AI 之后，我给自己划了三条底线，全程没有松动。

第一，数据模型和权限矩阵必须由我亲手确认。AI 可以设计表结构，但它不知道谁是我们部门的负责人，不知道哪些人应该看到哪些部门的记录，这类组织语义它永远猜不准。第二，所有删除操作必须有软删除兜底。我明确要求生成代码时用 is_deleted 字段，而不是物理删除，这样就算逻辑写错了也有后悔药。第三，验收标准前置。我开工第一天就跟 A 同事确认了验收口径：借出、归还、提醒、统计四条主流程必须走通；备份必须可恢复；权限绝不能串。模糊的验收意味着模糊的交付，这条对 AI 项目尤其致命。

一句话总结这部分：AI 可以当一支听话的编外团队，但不能当项目负责人。项目负责人始终是我。

底线划完了，接下来是真正干活的部分。

2. 从需求到代码：四天的 AI 协作主流程

从立项到上线一共五个工作日，前四天都在做一件事：把一句"搞个系统呗"变成一堆可运行的代码。整个过程可以拆成三个环节，每个环节的配合方式不一样。

2.1 第一轮对话：把一句话需求逼成需求文档

我没有直接让 AI"写一个设备管理系统"，而是先让它当需求分析师。第一轮 prompt 是这样的：

你是一位有经验的需求分析师。有一个三四十人规模团队的内部设备借用管理需求，初步描述如下：要管理笔记本、测试手机、外设等设备的库存，成员可以借用和归还，超期需要自动提醒，管理员要看统计报表。请先不要写代码，向我提出 10 个澄清问题，重点关注角色权限、设备状态流转、异常场景（遗失、损坏、超期）、通知方式。我会逐一回答。

这一问的作用比我想象中大得多。AI 提的 10 个问题里，有几个是我作为熟人平时根本不会问的：设备遗失后状态怎么处理、挂失和报废是不是两个独立状态、超期之后是否允许再借、归还时要不要填使用状况、提醒是站内通知还是也要发邮件、旧表格里的编号规则要不要保留。如果这些问题不提前定义清楚，后期每改一次状态机，都要连带改前端、改接口、改测试。

我逐条回答完之后，换了一个 prompt 让它产出需求文档：按用户故事和验收标准组织，附带模块清单和数据实体草稿。这一步产出的文档我拿给 A 同事看了一遍，确认无误后才进入下一环节。

我的经验是：你花在需求澄清上的每一分钟，都会在后面的代码阶段省回来。让 AI 问问题，看起来多了一轮对话，实际上是把未来十次返工提前到了需求阶段。

2.2 技术选型：我定方向、AI 补细节的配合方式

技术选型我给了非常强的约束，理由很朴素：内部小工具，越平凡越好维护。技术栈定为前端 Vue 3、后端 Node.js + Express、数据库 SQLite，单机部署。不用微服务，不用消息队列，不引入缓存，认证先做简单的账号密码加 JWT。这些约束是我在项目开始时一次性写进"全局约束清单"的，之后每一轮 AI 对话都带着这份清单。

AI 在这个环节做的事情是补细节：根据约束清单生成目录结构、接口列表、数据表定义。我给了它实体清单和业务规则，它返回了一整套建表语句和 REST API 端点设计。我不需要它在架构上有什么神来之笔，只需要它把常规方案可靠地铺开。

这一环节配合出来的结果大概是这样：

看到没有，每个设计项里我都先给"方向"，它再补"细节"。方向错了，细节再漂亮也没用；方向对了，AI 的细节产出质量就相当稳定。

2.3 分模块生成：一次只让它干一件事的 Prompt 策略

这是整个流程里最重要的一条操作纪律：绝不在一个对话里让 AI 生成整个项目。我把系统拆成了十来个模块，分轮生成，每轮只干一件事。后端分了初始化工程和表结构、用户认证与权限中间件、设备台账 CRUD、借用归还状态机、超期检测任务、统计看板接口六轮；前端分了登录页与布局、台账页、借用流程页、看板页四轮。每一轮都是新建对话，开头粘贴全局约束清单，然后给本模块的详细说明和上一轮产出的相关文件。

为什么这么拆？两个原因。第一是上下文窗口。一个对话里塞太多内容，模型中途就"忘了"前面的约束，生成到后面质量明显下降，这在后面的翻车实录里会提到。第二是隔离错误。如果一个模块生成得有问题，我只用重开一轮对话修那个模块，不会波及已经验证过的其他部分，排查成本低很多。

每个模块的 prompt 我都会带上三样东西：全局约束清单、本模块验收条件、接口签名或页面交互说明。比如生成"借用/归还状态机"那轮，我的 prompt 大致长这样：

请实现借用/归还模块。约束：状态流转只有 可借->已借出->已归还/已挂失/已报废；归还数量不能大于借用数量；同一设备未归还时不可再次借出；所有接口返回 { code, data, message }；时间统一存 UTC，展示时转东八区。验收条件：以上四条约束都有对应的代码校验和测试用例。

这种写法让 AI 的输出有明确的靶子，生成完我只需对着验收条件逐条核对，效率高得多。

3. "验收循环"才是真正的战场：AI 自审、测试补齐、报错反喂

很多跟 AI 协作的人有个误区，以为"生成完代码"就是完工。实际上生成只是开始，真正拉开交付质量差距的，是后面这套验收循环。我的流程很简单：每生成一个模块，立刻进入自审、补测、跑通三轮循环，不合格就重来。

3.1 AI 自审：让它用资深工程师视角挑自己的毛病

模块生成后，我不会马上去读每一行代码，而是先让 AI 自己审。prompt 是这样的：

请以资深后端工程师的身份，review 你刚才生成的这段代码。按以下顺序检查并输出修改后的完整代码：1. 是否有未处理的异常路径；2. 是否存在 SQL 注入或 XSS 风险；3. 事务边界是否合理；4. 是否在每个接口都做了角色权限校验；5. 边界条件是否覆盖（空列表、重复提交、并发）。对每个发现的问题，先说明原因再贴修改后的代码。

听起来有点反常识，但 AI 审自己生成的代码，确实能找出不少真问题。举一个印象最深的例子：一开始的"归还接口"没有校验归还数量不能超过借用数量，而且重复提交同一个归还请求会把库存扣成负数。第一次自审时它自己把这个 bug 揪出来了，给出的修改方案是给归还操作加上事务和数量校验。

我是这么看待这件事的：模型生成代码时是"写作模式"，让它 review 时是"审稿模式"，把它切换到审稿模式，能暴露很多写作模式下埋下的雷。与其我逐行肉眼看，不如先让它自查一遍，我再抽查重点。

3.2 场景测试清单：边界条件由人提，测试代码交给 AI

自审通过后，第二步是补测试。我负责列测试场景，AI 负责写测试代码。我给的场景里一定包含大量边界条件，因为模型自己往往想不到"用户会在 23:59 点击归还"这种刁钻时机。那次我列的场景包括：超期一天归还；归还数量大于借出数量；同一设备未归还时再次借出；一次性导入两千行记录；跨年跨时区的超期提醒；管理员删除已被借出的设备。

AI 根据这些场景生成了整套自动化测试用例。这些用例确实抓到了两个真 bug：一个是跨时区场景下，到期时间的计算没有考虑夜里 23 点到凌晨之间跨天的边界，导致部分设备被提前一天或延后一天判定超期；另一个是并发情况下两个请求同时归还会出现重复扣减。这两个 bug 如果靠手工点页面，还真不一定能试出来。

这里的配合原则是：AI 擅长把"场景描述"翻译成"测试代码"，但"该测什么场景"这件事必须人来定。让 AI 自己列场景，它列出来的往往都是理想路径，而项目翻车恰恰都发生在非理想路径上。

3.3 报错反喂：把完整报错信息丢回给模型

跑测试或者启动服务时一旦报错，我的处理方式非常简单：把完整报错信息原样复制，开一个新对话，附上相关代码文件和报错栈，让 AI 直接修。注意是"原样复制"，不是转述。我自己总结过，转述会丢失大量信息，比如某个变量在哪个作用域、第几行抛的异常、上游返回了什么样的数据结构。这些细节看着啰嗦，但恰恰是定位问题的关键线索。

有次前端列表页报错，页面整个白屏，控制台里是一个 undefined 的 map 调用。典型的"数据格式不一致"：列表接口在无数据时返回了 null，而前端代码直接当成数组去 map 了。我把完整堆栈和接口返回样例贴给模型，它马上就定位到是后端返回结构里 data 字段在空列表时变成了 null，而不是约定的空数组，顺手连后端和前端都修了。

这种"报错反喂"的循环，是我用 AI 干活时最顺手的调试方式。它省去了我手工打日志、翻源码的时间，但前提是报错信息必须完整、真实，不能是我根据记忆"复述"出来的版本。

4. 没写代码的时间里，我在盯这几件 AI 管不了的事

如果只看代码提交记录，这次项目确实符合"全程没写几行代码"的描述。但把视角拉到整个交付过程，你会发现有大量时间花在了"不写代码"的事情上。这些事恰恰是 AI 替代不了、也不该替代的。

4.1 权限模型：我把 AI 的第一版方案推翻了一半

AI 给出的第一版角色设计只有两个：普通成员和管理员。我一看就知道不行。实际需求里存在第三种角色"部门管理员"，要能查看本部门的全部登记记录，但看不到其他部门；而系统管理员要能配置设备分类、管理所有部门和人员。这个组织语义来自公司的实际架构，一个没见过组织架构的模型根本不可能猜对。

于是权限矩阵是我手工画的：

画完之后，我让 AI 按这个矩阵重写了权限中间件和所有接口的鉴权逻辑。最后手工改的部分其实不多，但"这个矩阵长什么样"这件事，只能由我来定。权限这类带组织语义的东西，是 AI 端到端交付里最不能外包的环节。

4.2 备份与迁移：AI 不操心的那些"脏活"

AI 生成的表结构一开始没有预留演化空间，开发到第二天我就发现要加一个字段，用来记录设备当前所在位置。我手工写的迁移其实就几行：新增一列、更新旧数据、调整索引。但这件事必须有人留意，因为 AI 在后续生成代码时不会知道你加了列，也不会自动去改它依赖的查询。

我做的另一件更基础的事是备份：上线前一天，我手工写了一个二十多行的备份脚本，每天凌晨用数据库自带的备份机制把数据文件复制到另一个目录，并保留最近 14 份。脚本内容大致是这样：

#!/bin/bash BACKUP_DIR=/data/device-backup DATE=$(date +%Y%m%d%H%M) sqlite3 /data/device.db ".backup '$BACKUP_DIR/device-$DATE.db'" find $BACKUP_DIR -name '*.db' -mtime +14 -delete

写完脚本我还干了一件更"笨"的事：手动删掉一个测试库，然后从备份恢复，确认恢复流程真的能跑通。备份如果不能恢复，等于没有备份。这类脏活 AI 不会主动替你操心，但它直接决定了项目出问题时的底线。

4.3 部署执行：AI 出文档、我跑命令

部署环节 AI 帮我把文档写好了，包括安装依赖、建目录、配置环境变量、用进程守护工具启动服务、用反向代理转发请求。但真正执行的时候，还是我一行行命令敲进去的。倒不是 AI 不能跑，而是部署涉及的机器环境、端口占用、防火墙策略、内部域名解析，这些实际环境的信息它完全没有，只能靠人实时处理。

印象最深的是环境变量。AI 文档里写了数据库路径、密钥、邮件服务配置这些变量，但没有告诉我"生产环境的敏感配置应该放在单独的配置文件里，不入库、不进提交历史"。我自己补了这个环节，把邮件服务密码这类敏感信息单独放到一个权限受限的文件里，应用启动时加载。这种东西你指望 AI 主动想到，不太现实。

4.4 用户反馈：让工具从"能跑"变成"愿意用"

内部工具的生死不在代码质量，而在用户愿不愿意填数据。上线前我约了 A 同事和另外两位使用者一起做了半小时演示，结果收到的反馈五花八门：列表页要加排序，借用表单里要默认选中"最近用过"的设备，两种相似状态的命名要把人绕晕。我统计了一下，这些改动里有七八成是文案和交互细节，真正的代码量很小，但每一处都直接影响用户意愿。

我把这些反馈整理成清单，分两批丢给 AI 改。改完后我自己逐个点了一遍，确认交互逻辑符合预期才发出去。这一下午没有写任何核心业务代码，但我觉得它是整个交付过程中价值最高的一段时间——让工具从"能跑"变成"大家愿意用"，这一步 AI 帮不了你。

5. 翻车现场：五个代表性坑与我的处理方式

跟 AI 端到端交付，不可能不翻车。把印象比较深的五个坑写出来，每一个都配了当时的处理方式，应该能帮你提前避掉大部分雷。

5.1 幻觉字段：AI 猜的字段和真实数据对不上

第一个坑出现在导入那一步。需求里要把旧表格的数据导进系统，我把表格的说明文字给了 AI，它理解成字段叫"设备编号、名称、分类、状态"。结果真拿到文件一看，列名叫"资产编号（内部用）"，里面带着横杠前缀，比如 "NB-2024-001"，和 AI 假设的纯数字编号完全是两码事。第一次导入直接失败，几百条数据全部校验不过。

处理方式：我把真实表头和几行样例数据直接发给 AI，让它重写导入映射逻辑，明确"保留原编号格式，不做转换"。教训很简单：涉及真实数据时，永远让 AI 看样例数据本身，而不是看你对数据的转述。模型会根据你给的信息做合理假设，但它猜的永远只是猜的。

5.2 上下文漂移：聊了二十轮，它忘了时间约束

第二个坑在同一个对话聊到二十轮以后出现。项目最初明确约束过"所有时间统一存 UTC，展示时转东八区"，这个约束我在前几轮都带着，但生成到后面某个功能时，模型直接用了本地时间的逻辑，导致超期提醒在夜里会出现八小时偏差。要不是之前写了跨时区测试用例，这个 bug 很可能就这么带上线了。

处理方式：从那天起我强制规定，每个新对话的第一段内容永远是全局约束清单，并且每完成一个模块，把关键决策追加进清单里。不再依赖"模型记住上文"，而是让"约束始终出现在最显眼的位置"。上下文漂移不是模型的道德问题，是你的信息架构问题。

5.3 看起来能跑，实际上全是隐患

第三个坑是"能跑但脆"。AI 生成的列表页代码，在数据为空时能正常显示；但一旦某条记录的关联用户被删掉，页面直接报错。原因是代码假定每条借用记录的用户都一定存在，没做关联查询的空值处理。这个 bug 在演示时没暴露，因为我测试的数据里用户都还健在；但它就在那里，像一颗定时炸弹。

处理方式：我用了比较笨但有效的策略——自审 prompt 里把"空值路径"单列为一条检查项，要求 AI 专门检查所有数据读取路径中可能出现的空值和异常。从那以后，AI 生成的代码里普遍多了空值判断和兜底提示，页面白屏这类问题明显减少。

5.4 过度信任：它也会写出拼接查询语句

第四个坑是最让我警觉的。在搜索筛选功能里，AI 为了"方便"，用了字符串拼接的方式来构造带条件的查询。虽然内部工具暴露面小，但这种写法本身就是坏味道。它出现在一次自审环节，被我从修改建议里发现的——如果我只信任第一版输出，不去读自审结果，这个隐患就会留在代码里。

处理方式：在全局约束清单里加了一条硬性规定——所有数据库操作必须用参数化查询，禁止字符串拼接动态语句。同时后续每个模块的验收条件里都带上这条。AI 不会因为"你不允许"就自动遵守，它只会遵循你写在约束里的内容。

5.5 重复造轮子：AI 不知道公司已有的组件

最后一个坑比较隐性。AI 写的"人员选择器"是从零实现的下拉多选框，而公司内部其实早就有一个公用的成员选择组件，支持搜索、部门筛选、批量选择。我在验收时才意识到，如果直接用了 AI 造的轮子，后面同事维护时要多扛一个跟全公司不一致的组件。

处理方式：我把现有公用组件的文档和用法摘要放进了全局约束清单，并明确要求"涉及成员选择的地方直接引用公用组件，不要自行实现"。如果你不告诉 AI 公司已有的资产，它只会从数据集里找最接近的方案，而那个方案往往不是你的方案。

这五个坑放在一起，其实指向同一个结论：AI 交付的代码不是"不用审"，而是"必须审"，而且要用结构化、有检查项的方式去审。我用一张表简单总结一下：

6. 交付后的复盘：手写代码清单与下次调整

项目上线两周后，我做了一次完整的复盘。先把账算清楚，再说说如果再来一次，我会在哪里调整。

6.1 代码盘点：我手写的部分到底有多少

我翻了提交记录，最终代码总量大约三千多行，其中后端占了大头。我亲手敲的代码大概在一百行上下，而且里面还有一半是脚本和配置文件。具体分布大概是：权限中间件里三个部门级判断，约三十行；导入映射函数，约十五行；备份脚本约二十多行；数据库迁移的语句和脚本约三十行；其余零星修复十几行。剩下接近三千行是 AI 生成的，但每一行都经过了至少一轮自审和测试。

这个数字其实挺能说明问题："没写几行代码"是真的，但"没干活"是假的。我真正的产出不在键盘上，而在验收标准、约束清单、权限矩阵和测试场景里。恰恰是这部分产出，决定了项目能不能交付。

6.2 交接与维护：跟接手同事说了三句实话

项目稳定运行后，我把它交接给了另一位同事负责后续维护。交接时我没有吹"AI 写的代码很完美"，而是说了三句实话。

第一句：主流程的代码我逐行审过，边缘文件比如导出、统计部分我只做了抽查，后续如果修改，建议先跑一遍回归测试。第二句：依赖版本要锁死，AI 生成的依赖清单里很多用了浮动版本范围，直接升级有风险，升级前先在测试环境跑一遍。第三句：我把每个模块当初的 prompt、全局约束清单和关键决策记录都存在仓库的文档目录里，后续你想要小改动，可以照着相同的方式让 AI 改，改完必须跑测试。

这三点不是客套，而是我踩完坑之后觉得"如果有人接手，最需要知道的就是这些"。

6.3 下一次接同样的活，我会怎么调整

复盘到最后，我给自己列出了四条调整项。

第一，测试骨架第一天就搭好，而不是在功能做得差不多以后才补。先写测试再写实现，AI 生成的代码会天然朝着满足测试的方向走。第二，约束清单从第一天就建文件，并且按"架构约束、数据约束、安全约束、界面约束"分类，每完成一个模块强制更新一次，避免漂移。第三，每完成一个模块就部署到测试环境手动点一遍，尽早暴露真实运行环境的问题，而不是攒到最后一起调。第四，权限模型和用户角色这类"组织语义"相关的内容，项目启动当天就定死，绝不等到生成阶段再返工。

这四条如果当时就做到，我估计交付时间能从五个工作日压缩到三个半工作日，而且翻车的坑至少能少踩两个。

最后再聊一点个人体会。做完这个项目，我对"用 AI 端到端交付"这件事的理解变成了：它不是在"减少你需要做的事情"，而是在"置换你做的事情"。你从写代码的人，变成了定义边界、设计验收、看住坑的人。省下来的不是时间，是体力；多出来的是判断。

如果你也想试一次，我的建议是从一个内部小工具入手，先划好底线，再把约束清单建起来。还有一个特别管用的小技巧：每次开始新一轮 AI 对话前，把上一轮的结果和你的修改意见粘回对话开头，花三十秒，能让你少踩一半的坑。