有句话憋了很久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 有多聪明。