先说结论这个项目确实交付了——我用 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 的输出数据表实体清单 业务规则建表语句、索引建议、软删除字段接口定义REST 风格 角色边界端点列表、参数、响应结构前端页面页面清单 交互说明路由结构、组件划分、表单校验看到没有每个设计项里我都先给方向它再补细节。方向错了细节再漂亮也没用方向对了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 对话前把上一轮的结果和你的修改意见粘回对话开头花三十秒能让你少踩一半的坑。