如何用AI Coding交付几百万真实企业项目｜干货复盘

这两个月，我带团队用 AI 交付了一个几百万的真实项目。

你肯定刷到过很多"AI 十分钟写个 App"的视频。但你有没有好奇过，这些东西放到真正的企业级项目里，到底能不能打？

所以我拿真实项目试了一把。

结果嘛……三个坑，三个解法，一个出乎意料的结局。都是真事，都是干货。

我在网易智企做企业应用交付，写了十年代码，带了五年团队。

这次的项目，我们组了一个 5 人小队：1 个产品、2 个开发，加上我和一个测试。

这次交付的是一套担保业务的全流程系统，从客户进门、审资质、放担保，到解保收保费，一整条业务线全在系统里跑。

PRD 足足 16.8 万字，相关功能如下：15 个模块、11 类角色、10 条审批流、50 张数据表、43 个页面，还要对接 5 个外部系统。单拎一个都不吓人，摞在一起，复杂度是相乘的。

这个系统的难点如下：

从业务场景来看，该系统一笔业务要过 10 条审批流，而对于普通系统而言三五条就算复杂了。该系统最长那条，从业务线走到风控初审、复审，再到业审会委员匿名盲投、秘书汇总、风险官评判、总经理审定。就“匿名盲投”四个字，多位委员同时投票、还要求互相看不见谁投了谁，光这一项功能就够折腾半个月。

再看权限这块，难的不是 11 类角色，是同一个人换条流程，权限就变了。比如风险官在授信、保后、解保里能审，到了预警流程，没有。

50 张表的依赖更硬：没客户不能建授信，授信没批不能启用业务，业务没结清不能解保。断哪一个环节，后面环节全部卡死。

按以上的功能需求这个项目放在以前，我们 5 个人全职得干 10 个月，但当时甲方催得急，想着可以用 AI 开发，我们答应 2 个月交付。

团队一开始的想法特别朴素：把 PRD 整个喂给 AI，让它一个模块一个模块写。旗舰模型上下文窗口都标到 1M 了，理论上够用吧？

错。

上下文窗口就是 AI 的工作台，堆得越多，它能专心看的越少。标称 1M，实际能用的也就 200k，中间的需求文档最容易忽略。

项目刚开始做，三种问题出现了：

一是前后矛盾。

上午说“退回任意节点”，下午写出来只能退上一级；让它改回来，清空后续意见的逻辑又被悄悄删掉。修一个丢一个。

二是漏功能。

16.8 万字的 PRD 它接不住，主流程做了，边界条件、异常分支、权限校验全漏，你不问 AI 它绝不吭声。

三是越改越乱。

让它改授信审批的退回逻辑，它顺手把保后检查的流程也“优化”了，因为在它眼里这两块代码长得差不多。授信审批好了，保后检查炸了。

用 AI 搞过软件项目开发的你是不是也遇到过类似的问题？

有天站会上，一个开发说了句：“我感觉我不是在用 AI 写代码，是在给 AI 收拾烂摊子。”

确实啊。会后，我们算了一笔账。

一个功能从“甲方说要做”到“上线能用”，要过 6 道：需求理解、澄清、方案设计、编码、测试、部署。AI 提效的只有编码这一段。

编码确实快了，项目反而慢了：代码里全是暗雷，排雷比过去还费时间。以前自己写，慢是慢，心里有数；现在它一口气吐几百行，跑一遍不报错，谁心里都没底。测试从“抽查”退化成“全量人肉回归”，它每改一次，整条审批流从头跑一遍。

说白了，AI Coding 给的是一把更快的锤子。可更快的锤子，不等于更好的房子。你连房子要盖成什么样都没想清楚，锤子抡得越快，拆掉的墙越多。

你跟 AI 说“帮我做个用户管理模块”，它刷刷刷就开写，增删改查、页面、接口全有了，打开一看，像那么回事。

可“用户管理”到底指什么？只是增删改查，还是要带角色权限、组织架构、审批流？你说“支持导出”，导什么格式、要不要脱敏？

AI 不会问你，它直接挑一种理解就开写。

别急着怪它。同一句话十个人能理解出十种意思，这是自然语言的毛病。

但人和 AI 有个关键区别：人会追问，AI 不会。

你可能会说，让它先问清楚再动手不就行了？能。可这个“问清楚”，有没有写进流程、被后面的设计接着用？要只是在聊天框里随口聊聊，这些澄清既没存档、也没结构，换个模块再做，同样的歧义又冒一遍。

遇到以上问题后，我们决定先停下来。

那天晚上改第三轮 bug，还是同一个模块。我自己上手看代码，突然想通了：这些 bug 没一个是 AI “写错”的。退回逻辑出问题，是 PRD 只写了“支持退回”，没说退到哪；权限校验漏了，是 PRD 压根没写“风险官在预警流程无权限”。

每一个 bug 的根因，都指向同一个地方：需求。

不是 AI 不行，是喂给它的东西不行。是我们自己的需求，一开始就没写清楚。

想明白之后，我们换个打法，从头再来。

先把需求结构化解析，把 16.8 万字“提纯”，提炼出大纲、标准词表、模块拆分。去掉冗余的描述、重复的废话、格式噪音。只留下 AI 真正需要的事实，最终形成一份带结构化大纲的标准需求。

再拆原子任务，按依赖关系拆成一个个小于 4 小时的活，边界清晰、互不干扰。产品同学拆第一个模块，光“统一授信方案审批”一条流程，就拆出 14 个原子任务。以前这些全混着，出了 bug 才发现少了哪个；现在动手前就知道有多少活、边界在哪。

然后按需喂上下文：每个环节起一个子代理，只注入这个模块需要的那部分。最后是断点续跑，会话持久化，长任务能中断、能恢复。

这几步做完，上下文撑爆基本消失，前后矛盾和功能遗漏少了很多。

第二个改变：不再只让 AI 写代码。

编码只是六个环节里的一个。上游的方案设计、下游的测试部署都没人管，中间快了，两头慢了。说白了，我们之前用 AI 是“点状提效”，想要的却是“全链路提效”。

所以我们不再把 AI 当“写代码的工具”，而是当“跑流水线的工人”，让它也参与需求解析、方案设计和自动化测试。

变化最大的是测试。改成流水线以后，用例不再靠人写，而是 AI 生成的端到端用例：规格里写了“风险官在预警流程无权限”，它就自动生成对应用例，跑一遍，不通就报。

让需求标准化，让“澄清”变成流程的一部分。

这里有个东西叫 EARS，一套需求书写规范，把模糊的自然语言写成“当……发生时，系统应……”的结构化规格。举个例子：管理员可以删除用户帖子，普通用户不行；写成 EARS 就是“当用户尝试删除帖子时，系统应检查其角色是否为管理员，若不是，系统应显示权限不足并阻止删除”。

一句话被收敛到只剩一种理解，这就是它的价值。

光是“双人办理”一个模块，把 PRD 原文翻成 EARS 规格，就揪出好几处歧义，有些连 PRD 作者自己都没意识到。以前这类歧义要等测试提 bug，现在写规格时就拎出来了。

所以从以上就不难看出，需求澄清是回报最高的那笔投入。需求阶段多花一小时，开发阶段能省十小时。

整体交付周期从预估的“5 人全职 10 个月”，压缩到了“我和 1 名开发，两个人 3 周”。虽然我们在需求阶段投入的时间，比以往同类项目长，但项目整体交付效率反而提升了 30 余倍。因为开发、交互、测试、返工等等的工作量，几乎消失了。

再说交付质量。

项目需求 43 个页面、10 条审批流、50 张表，100% 覆盖。以前最容易漏的边界条件、异常分支、权限校验，在结构化 Spec 阶段就被拎出来了。AI 不需要"记住"所有需求。它只需要每次做任务时，看到那个任务完整的上下文就够了。UAT 阶段，严重缺陷为 0。不是说一个 bug 都没有。样式细节、交互微调，当然有。但"功能做错了"这种事，没有发生。

项目界面，数据为测试数据

今天这篇文章，讲的是我们交付的一个真实项目。但支撑它的这套方法，不是某一个人的灵光一现，而需要完整的工程化能力去托底。

过去这段时间，我们网易智企已经用同样的方法，陪着几百家企业交付了真实的 AI 软件项目。这些实战经验沉淀下来，就是 CodeWave SDD（Spec-Driven Development，规格驱动开发）。

近期，网易智企将进行一场 CodeWave SDD 项目的全流程演示直播，完整展示从企业项目 PRD 解析到系统交付上线的全过程。该直播属于定向邀请，名额有限，公众号后台回复“直播”报名预约。名额有限，报完即止！

作为网易旗下一站式企业AI应用服务提供商，网易智企倾力打造企业AI实战栏目——「AI实战派」，聚焦AI在真实业务中的落地应用，通过实战教学、案例拆解、研讨交流等多元形式，将前沿的AI技术转化为真实的业务动能，为企业管理者、业务决策者和一线实践者提供可迁移、可复用的实战方法论与深度洞察。

关于我们