16.8 万字需求、50 张表：一个数百万企业项目是怎么用 AI Coding 交付的？

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

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

所以我拿手上的项目试了一把。

结果嘛……踩到三个坑，摸索出三种解法，收获一个出乎意料的结局。都是真事，都是干货。

先说说我是谁

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

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

我不是那种追风口的人。一个新技术出来，我通常先看半年，看看先行者是怎么用的，再决定要不要上。

但去年，AI Coding 这一波，确实让我坐不住了。

朋友圈天天刷，技术群天天聊。Cursor、CodeX、Claude，一个比一个猛。讨论的已经不是"要不要用"，而是"你怎么还没用"。

正好，今年手上接了一个新项目。几百万预算，甲方催得紧，工期本来就吃力。我想，行，那就在这个项目上试。

不试不知道。一试，我才真正明白一件事：

AI Coding 的瓶颈，根本不在 AI。

这是个什么项目

一套担保业务的全流程管理系统。

什么意思呢？就是一家担保公司，从客户进门、审资质、给额度、放担保、盯风险，到最后解保收保费，整条业务线，全要在系统里跑完。

我接到需求文档那天，打开一看。

16.8 万字。

我当时还以为文件传错了。这是 PRD 还是长篇小说？

翻了一遍才确认，没传错。是真的写了这么多。你平时见到的需求文档，一两万字算厚的了。这份，快顶十本了。

你感受一下这几个数字：

15 个模块 / 11 类角色 / 10 条审批流 / 50 张数据表 / 43 个页面 / 5 个外部系统集成。

单拎出来，每一个都还好。但组合在一起，复杂度是相乘的，不是相加的。让我掰开说几个关键难点。

第一，流程长。

一笔业务要走 10 条审批流。普通企业级系统，3 到 5 条就已经算复杂了。这个项目，直接翻了一倍。

最长那条，要走：业务线 → 风控初审 → 风控复审 →业审会委员匿名盲投→ 秘书汇总 → 风险官独立评判 → 总经理审定。

注意"匿名盲投"四个字。多位评审委员，同时投票，但彼此看不到对方投了什么。光这一个功能的前端交互和后端并发控制，就够折腾很久了。

第二，角色多，权限交叉。

一共 11 类角色，但难点不在人多。在同一个人，换一条审批流，权限就不一样了

比如风险官。他在统一授信、单笔启用、保后检查、解保、五级分类这 5 条流程里，都有审核权。但在一般预警和特别预警里？对不起，没有。

这就像你公司里的财务总监，在报销审批流里能签字，在招聘审批流里就只能旁观。你得精确到"谁、在哪条流程的哪个节点、能干什么"。

第三，50 张表，依赖链是硬的。

一环扣一环。没有客户不能建授信。授信没批不能启用业务。业务没登记不能做保后检查。业务没结清不能解保。

这就是一条铁链，断了哪个环，后面全趴窝。不像有些系统，各模块是松散拼在一起的，你改了 A 模块，B 模块不受影响。这个项目里，你动一张表的一个字段，下游三个模块可能全要跟着调。

第四，业务规则细。第五，还要对接 5 个外部系统。

担保金额怎么算、保费怎么收、五级分类怎么认定、什么情况触发一般预警还是特别预警、解保后保费退不退？每一条，都是甲方写死的规则。

另外还得对接 OA 单点登录、外部文件存储、病毒扫描、消息通知、第三方数据监控。

以上，就是这个项目的情况。

甲方问我：能不能快点？

我说：能。我用 AI。

现在回头看，当时的我，就像一个拿着导航就敢跑川藏线的新手。导航是最新的，但实际路况完全不是那么回事。

坑一：上下文炸了

我们一开始的想法，特别朴素。

把 PRD 喂给 AI，让它一个模块一个模块地写代码。

现在的旗舰模型，上下文窗口都标称 1M 了。我这份 PRD 塞进去，理论上绰绰有余。对吧？

错。

这里有一个技术概念，叫“上下文窗口”。

简单说，就是 AI 一次性能"看到"多少内容。你可以把它想象成 AI 的工作台。工作台就这么大，你堆的资料越多，它能专心看的就越少。

旗舰模型说自己窗口有 1M。但实际上，受成本、提示词、工具等占用限制，编辑器可用的普遍也就 200k 上下。

而且还有一个更坑的问题，也就是“lost in the middle”。翻译一下：塞进去的内容越多，中间的部分越容易被忽略。就像你看一本 500 页的书，头 50 页记得，尾 50 页记得，中间 400 页？一片模糊。

AI 也一样。它能"看见"中间的内容，但注意力已经不够了。

所以，当我们把 PRD 塞进去，再加上已生成的代码、前面几十轮对话的历史，窗口很快撑满。

然后，三种症状，准时报到。

第一种：前后矛盾，丢三落四。

上午告诉它，“授信审批要支持退回到任意节点”。下午它写的代码里，退回逻辑变成了"只能退回上一级"。

让它改回支持退回任意节点，结果退回时要清空后续节点审批意见的逻辑，又悄悄被它删了。修一个，丢一个。跟打地鼠似的。

第二种：功能被悄悄漏掉。

16.8 万字的 PRD，它接不住。主流程做了，边界条件漏了，异常分支没了，权限校验忘了。你不主动问，它绝对不会告诉你"这块我没做"。

就像你让一个实习生对照清单采购 50 样东西。他跑了一趟超市回来，袋子看着挺满。你一对账，发现少了 8 样。问他咋回事。他说，啊，那几样我没注意。这显然交不了差。

第三种：越改越乱。

这个最坑。

开发同学让它改授信审批的退回逻辑。它改了。但我没注意到，它顺手把保后检查的流程代码也"优化"了。

因为在它眼里，这两块代码"长得差不多"，不如一起改了吧。结果呢？授信审批好了，保后检查炸了。功能看着是对的，跑起来全是暗雷。

就像你让装修师傅修厨房的水龙头，修完你发现，卫生间的水管也被他"顺便"拆了重接。他觉得自己是在帮忙，但你的马桶不出水了。

这就是上下文炸了之后的样子。

这已经是结构性的失控了。

坑二：代码快了，项目反而慢了

踩完第一个坑之后，有天站会上，一个开发同学说了句话：“我感觉我现在不是在用 AI 写代码，而是在给 AI 擦屁股。”

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

一个功能从"甲方说要做"到"上线能用"，要经过 6 个阶段：需求理解 → 需求澄清 → 方案设计 → 编码实现 → 测试验证 → 部署发布。

AI Coding 提效的，是哪一段？

只有编码。就中间那一段。

前面的需求理解、需求澄清、方案设计，是我自己干。后面的测试验证、部署发布，也是我自己干。

这两件事放在一起看，就很有意思了。AI 编码确实快了。但项目反而更慢了。

这不矛盾吗？

其实不矛盾。

因为 AI 生成的代码里有各种暗雷。团队在测试和排雷上花的时间，反而比以前更多了。以前开发写代码，虽然没那么快，但心里有数。哪里写了什么逻辑，哪里可能有坑，自己非常清楚。

现在呢？AI 一口气吐出几百行代码。看起来没问题。跑一遍，也没报错。但我们心里就是没底。因为不知道，它有没有悄悄改了什么没让它改的东西。

所以测试环节，我们从"抽查"退化成了"全量人肉回归"。AI 每改一次，整条审批流要从头跑一遍。这个成本，比我自己写代码高多了。

代码是快了。但我花了更多时间在对需求、改 bug、人肉回归上。

说白了，AI Coding IDE 给的是一把更快的锤子。但一把更快的锤子，并不等于一栋更好的房子。

如果你都不知道房子该盖成什么样，锤子挥舞地越快，你拆的墙可能越多。

如果你的团队正在用 AI Coding，但发现"写代码确实快了，加班却没少"。那多半也是卡在这个坑里了。问题不在锤子，在图纸。

坑三：AI 不跟你辩论

第三个坑，是最深的。也是我后来想通之后，觉得价值最大的一个。

你有没有遇到过这种情况，你跟 AI 说：“帮我做一个用户管理模块。”

它刷刷刷就开始写了。增删改查，页面有了，接口也有了。你打开一看，嗯，像那么回事。

但是，"用户管理"是什么意思？

只是增删改查？还是要带角色权限、组织架构、审批流的完整体系？

你说"支持导出"。导什么格式？Excel 还是 PDF？全量还是当前筛选条件？要不要按权限脱敏？

你说"列表要快一点"。怎么叫快？分页？虚拟滚动？加缓存？多大数据量下要多快？

你说"和现有系统打通"。打通哪个系统？实时同步还是定时批量？走 API 还是直连数据库？

AI 不会问你到底要哪种。它直接挑一种就开写。

别怪 AI。这是自然语言的天然缺陷。同一句话，十个人能理解出十种意思。人尚且如此，何况 AI。

但人和 AI 有一个关键区别。

人会追问。“你说的导出，是导什么格式？” AI 不会。它默默地挑一种理解，然后埋头生成。

你可能会说：那我让 AI 先问清楚再动手，不就行了？

能。但问题来了。

这个"问清楚"的过程，有没有被标准化进流程里？有没有被强制发生？有没有被记录下来？有没有被下游的设计和编码环节消费

如果你和 AI 只是在聊天窗口里随意"聊了聊"。那这些澄清，既没有存档，也没有结构。下次你换个模块让它做，同样的歧义，又会重新出现一遍。

零散的对话式澄清，做不到标准化。

一个多月后，决定先停下来

到这里，已经过去一个多月，我们决定先停下来。

那天晚上改第三轮 bug，同一个模块，第三轮。我自己上手，开始看 AI 生成的代码。

看着看着，突然意识到一件事。这些 bug，没有一个是 AI "写错"了。

退回逻辑出问题，是因为 PRD 里写的是"支持退回"，没说退到哪里、退回后其他节点怎么处理。AI 猜了一种。猜错了。

权限校验漏了，是因为 PRD 里压根没有明确写"风险官在预警流程里无权限"。AI 按默认逻辑，给所有角色都开了审核权。

数据依赖断了，是因为开发同学在对话里只提了当前模块的需求，没告诉它上下游的数据关系。它不知道"授信没批不能启业务"这条规则。

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

第二天站会上我把这个想法跟团队说了。大家的反应出奇一致，“每次返工的本质是需求没说清。”

不是 AI 不行。是我们喂给 AI 的东西，不行。

三个坑，看起来各不相同。上下文炸了、只管编码、语言模糊。但它们的共同根因，只有一个：

需求工程，没做好。

想明白这件事之后，团队换了一种方式来用 AI，从头再来。接下来这三个解法，单靠提示词技巧是做不到的，得有工程能力兜底。

解法一：化整为零

第一个改变。不再把整本 PRD 一次性塞给 AI。

就像你去自助餐厅，你不会把所有菜一次性全堆在一个盘子里。那样什么都拿到了，但什么都吃不好。你会先拿冷菜吃完，再拿热菜，最后来甜品。每次只拿你当前要吃的。

AI 也一样。

第一步，需求结构化解析。

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

成原子任务。

按依赖关系，把整个需求拆成一个个小于 4 小时的原子任务。每个任务边界清晰，互不干扰。

产品同学在拆第一个模块的时候，光"统一授信方案审批"这一条流程，就拆出了 14 个原子任务。拆完之后我们都愣了。原来一条审批流里面，藏着这么多以前根本没注意到的分支逻辑。

以前写代码的时候，这些东西全混在一起，出了 bug 才发现少了哪个。现在提前拆清楚了，写之前就知道有多少活，每个活的边界在哪

第三步，按需准备上下文。

这一步最关键。每个环节起一个 SubAgent，这个 Agent 不会把所有需求、所有上下文一股脑塞进去，而是按模块按需注入。做授信提交，就只给它授信相关的 Spec、组件、接口定义。不给它保后检查的东西。不给它解保流程的东西。

也就是渐进式知识披露，需要什么，再注入什么。

你不会上课第一天就把整本课本从头到尾念一遍。你会按章节来，第一章讲完、考完，再翻到第二章。AI 也是。

第四步，断点续跑。

Session 持久化，多个 Agent 各带独立的上下文窗口。长程任务可以中断、恢复。不受单次窗口大小的限制。

这四步做完之后，效果立竿见影。

上下文撑爆的问题，基本消失了。前后矛盾和功能遗漏，大幅减少。化整为零，按需喂料。窗口再有限，也接得住大规模复杂需求。

解法二：从一把锤子，到一条流水线

第二个改变，不再只用 AI 写代码。

之前的问题是什么？

AI 编码确实快。但编码只是六个环节中的一个。上游的需求理解和方案设计，没人管。下游的测试验证和部署发布，也没人管。

中间快了，两头慢了。总时间没省多少。

也就是说，我之前用 AI 的方式，是点状提效。而我真正需要的，是全链路提效

想明白这一点之后，我们不再把 AI 当成"写代码的工具"，而是当成"跑流水线的工人"。它不只写代码，它还参与需求解析、方案设计、自动化测试和部署。每一个环节，都在同一个平台上闭环运转。

其中变化最大的，是测试这一环。

前面说过，我们一度退化成"全量人肉回归"。改成流水线之后，测试用例不再是人写的，而是 AI 生成的 E2E 测试用例。例如 Spec 里写了"风险官在一般预警流程中无审核权"，就会自动生成一条对应的权限校验用例。而这两种模式的差别，看一眼就明白了：

一个，是让你某个动作快了。

一个，是让你从起点到终点的总时间短了。

在一个 16.8 万字、15 模块、50 张表的项目里，我需要的，显然是后者。

解法三：让 AI 先学会提问

第三个改变，是最根本的。

也是整个项目真正的转折点。

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

这里有一个概念，叫EARS

什么意思呢？它是一套需求书写规范。核心原则特别简单：把模糊的自然语言，写成“当……发生时，系统应……”的结构化规格。

给你看个对比就明白了：

常见写法：管理员可以删除用户帖子，但普通用户不行。

EARS 写法：当用户尝试删除帖子时，系统应检查角色是否为管理员；若非管理员，系统应显示"权限不足"提示并阻止删除操作。

看到区别了吗？将一句话的理解收敛到只剩一种。这就是 EARS 的价值。

我们在实际操作的时候，光是把"双人办理"这一个功能模块的需求，从 PRD 原文翻译成 EARS 格式的 Spec，就发现了多处歧义。有些甚至是 PRD 作者自己都没意识到的，比如“提交人范围如何限定”，“初审驳回后是返回上一环节，还是重置为草稿”。

以前这种歧义，要等代码写完、测试提 bug、开发去问产品才暴露出来。现在在 Spec 阶段就被拎出来了。AI 会主动逐条追问，而不是自己猜着往下写。

问清楚了，再动手。

然后，所有的澄清记录，都会结构化地存下来，成为标准化资产。下游的设计和编码，自动消费这些澄清结果。不再是一段随时丢失的对话。而是一份可追溯、可审查的需求契约。

需求澄清，是杠杆率最高的投入。

你在需求阶段多花一小时，能在开发阶段省十小时。但如果在需求阶段埋一个模糊点，就会在测试阶段炸出十个 bug。

结果怎么样？

好了，坑和解法都讲完了。

你最想知道的肯定是，最后这个项目，到底做成什么样了？直接用数据说话。

前期的结构化解析和任务拆分，我带着一位开发同学，扎扎实实干了近一周，把 16.8 万字的 PRD，一条一条地拆模块、拆任务、写 Spec、标歧义。

然后呢？

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

再说交付质量。

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

（测试数据）

甲方验收的时候说了句话，我印象很深：

“这是我们合作过的项目里，来回调整最少的一次。”

我心里说不上什么感觉。因为我知道，这个"调整少"，功劳在需求工程。就是我们在前面花了 2-3 倍的时间把需求理清了、掰碎了、标准化了，AI 才能在后面精准地还原出来。

AI 是好枪。但好枪也得有人瞄准。

这篇文章很长。能看到这里的你，我猜大概率也是一个在项目一线摸爬滚打过的人。

所以，说句实在话。AI Coding，确实有用。但它有用的前提，是你喂给它的东西够“好”。

需求越清晰，AI 越强大。需求越模糊，AI 越危险。

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

编者注：作者所在的网易智企，已将文中这套方法标准化沉淀为 CodeWave SDD（Spec-Driven Development，规格驱动开发），目前已有数百家企业采用该方法交付 AI 软件项目。近期，网易智企将进行一场 CodeWave SDD 项目的全流程演示直播，完整展示从企业项目 PRD 解析到系统交付上线的全过程。