用AI写完第一个开发项目后，我发现姜还是老的辣

这个系列前两篇，一篇写的是AI十秒钟能生成一个页面，但企业真正要买的不是速度，是把AI碎片组织成可持续运行系统的“骨架”（03-1｜当AI能10秒生成一个页面，企业真正要买的是什么？）；另一篇写的是旧系统不必推倒重建，而是逐层蜕皮，在稳定能力上长出新的交互和智能协作（03-2｜旧系统如何长出第二生命体？）。

这两篇都是观察和判断。真正上手用AI开发的时候，起初是兴奋，后来是怀疑，然后是开悟。当AI把“实现”变得越来越容易，真正稀缺的反而是定义业务、划定边界、搭好骨架的能力。写完第一个AI开发项目，我才发现：姜还是老的辣，AI越强，人越要懂业务。

一、删繁就简

事情是这样的，在高手的指点下，我开始尝试用飞书妙搭的AI，快速搭了一版流程管理系统的页面——流程架构表、文件审批流、版本管理，能跑。拿给负责开发的同事看，他是一位有二三十年经验的IT开发专家。

他看了之后，没说好不好，先自己验证了一轮：这事AI到底能不能干？值不值得干？确认完，他接手了。

但他没从我的页面开始改，他把我那版AI生成的东西里多余的部分全剔掉，直接回到这件事的骨头上看。

我原本其实是在想这个业务对象是什么操作流程是什么，谁去操作？有哪些数据规则？是什么页面？长什么样实现了哪些价值？

我自信的以为基于开源的代码，我已经能够实现一个非常庞大的流程管理系统。只是他还没有办法跟我们的生产环境真实的数据联动起来。当我把这个方案给到他的时候，还按照用AI写了需求文档，他直接摇头拒绝我用AI写的文档。我刚开始以为他抵触新技术，后来觉得他不适应新的协作方式，再后来我觉得他可能只是把这件事情看得更简单，比我用AI开发还简单。

要砍掉50%的东西。先砍了我的功能范围，其次砍了我的页面字段，然后砍了角色。

最后眼看着他只关注三项（流程架构层级，适用范围，角色），说实在的，我是相信的，IT的同事总是能把我的世界变得极其简单。事实证明，后来开发出来的页面满足了最小可行性，功能点全部覆盖了，设计极其的精简高效，比我之前搭的简易审批流顺畅多了，也比我之前搭的系统逻辑清晰多了。

二、AI折叠了什么

三个点一定下来，系统很快就跑起来了。这让我开始想一个问题：以前做这种事，要经过多少环节？现在为什么变得这么简单？中间的复杂过程去哪儿了？哪些东西变成了基本功能？人到底应该关注的最重要的是什么？

标准的IT系统建设流水线是这样的：需求收集→业务分析→方案设计→规划排期→详细设计→开发编码→测试验证→上线部署→运维迭代。每一步都有专人负责，每两步之间都有文档传递和评审。一个流程管理系统，走完这条线，少则三个月，多则半年。

现在AI把中间大部分过程折叠了。需求收集和业务分析还是你的，但方案设计、详细设计、开发编码、测试验证，这些环节之间的边界模糊了——你跟AI说一句话，它直接出页面、出代码、出数据库结构。不需要写方案文档，不需要画详细设计图，不需要等开发排期。

好处是什么？

中间翻译层消失了。以前你把需求翻译成文档，开发把文档翻译成代码，每一层都有信息损耗——你说的，BA写的，开发理解的，三样东西。现在你直接跟AI说要什么，它直接做。损耗少了，速度快了，改起来也快——一句话的事。

中间产物不再需要单独维护。方案文档、详细设计文档、接口文档——这些以前要专门写、专门评审、专门更新的东西，现在嵌在了你跟AI的对话里。对话就是文档，文档就是代码。

但这个速度有个代价——翻译层消失的同时，缓冲也没了。以前你写得不清楚，BA会帮你补，开发会问你，评审会拦你——每一层都在纠错。现在AI不会问你，它直接给你一个看起来合理的东西。你定义错了，它就照着错的做，而且做得又快又好，快到你来不及发现错了。

你得自己想清楚，没有人在中间替你兜底了。

三、AI折叠之后

好处和问题都摆在这了。那我们每天到底在干什么？

写代码的时间，不到10%。

剩下90%，三件事：

第一件：定义业务实体

系统底层有哪些对象？流程有编号、名称、版本、Owner、状态、生效日期。流程节点有编号、名称、角色、输入、输出、KCP。角色有ID、名称、职责、数据权限。流程文件有版本号、审批记录、发布历史。

这些东西，AI不会替你定义。因为这是你对业务的理解深度。你定义的实体对不对、全不全、清不清楚，直接决定整个系统长什么样。

AI写代码快，但骨架必须你搭。

第二件：定义边界和规则

AI生成的东西，大部分是对的，但总有一部分错得很隐蔽。比如生成一个审批流程，AI默认每个节点都能“退回发起人”。但真实业务里，有些节点只能退上一步，有些不能退，有些退回去要走不同路径。

这些规则，AI不知道。只有你知道。你不定义，AI就给你一个看起来很合理、但实际上不能用的东西。

第三件：验收和校准

传统验收：你写需求文档，开发做完，你测，发现bug，提给开发，开发改，再测，反复几轮。

现在的验收：

我：“发布按钮放右上角，只有流程Owner能点。”

AI：“好的，已调整。”

我：“不对，流程管理员也能发，但要二次确认。”

AI：“好的，已加弹窗。”

我：“发布前校验必填字段，没填的标红，不能发。”

AI：“好的，已加校验。”

没有中间层替你纠错了。 以前你把需求翻译成文档，开发把文档翻译成代码，每一层都有信息损耗，但每一层也都在纠错。现在你直接跟AI说要什么，它直接改。速度极快，但前提是——你得知道自己要什么。

验收能力，本质上就是定义能力。

四、对我们的要求变成了什么

以前做数字化项目，近一半时间花在写文档、画流程图、做需求规格上，跟业务部门沟通和跟IT对齐解释需求各占一大块，当时对于我们理解这一系列的工具以及这一系列工具文件之间的一致性都要耗费很多时间。

但是现在写文件和检查文件间一致性大部分的工作都可以交给AI他甚至可以帮我们处理的更好。其实这也给我们更多时间深入业务现场理解真实痛点、思考架构数据组织怎么对齐，这一块时间从前到现在都省不了，甚至要求更高了，我们借助工具可以拓展原来我们完全看不懂的地方，他帮我们把真实的业务装进这些框架里面，我们需要的是理解并使用它。

时间越来越腾挪到了两端：一端是更底层的架构设计，一端是更上层的价值创造。

AI把写代码、画基础页面、搭环境这些“翻译和实现”的活全包了之后，人的价值就往两头走了——一头是感知价值，知道做什么；另一头是定义结构，知道怎么把规则和实体说清楚。中间那些翻译的、实现的、重复的活，正在被底座快速吃掉。

但这里有个问题：AI是个极其强大的“顺从者”。Garbage in garbage out；你给它清晰、严密的业务逻辑，它就能帮你瞬间落地一个完美的系统。工具越智能，对人的业务定义能力要求就越高。

怎么补上这个能力？三周下来，我看到四件事必须做。

第一件，别再上来就看竞品、拿别人模板了。先追问：这个业务场景最本质的输入是什么？输出是什么？不可妥协的底线是什么？把混沌的业务语言，翻译成结构化的实体与属性。这是从“拿来主义”转向“第一性原理拆解”。

第二件，建立红线思维。AI最容易犯的错是“过于听话而忽视现实约束”。什么能做、什么绝对不能做、异常状态怎么回滚——这些隐性的行业经验和合规要求，必须变成显性的逻辑规则。

第三件，把跟AI的沟通当成一种新型的架构评审。有个判断标准：如果跟AI对话三轮还没改到位，不是AI笨，是你脑子里的业务逻辑根本没想清楚。

第四件，定义能力得去业务现场，去听、去感受流程卡在哪里、痛在哪里。对真实痛点有极高感知力的人，才能定义出真正有生命力的系统结构。

五、从这件事中得到的反馈

这事做完之后，我得到三层反馈。

第一层，对自身工作的认知。 以前我以为流程管理的核心能力是“把业务需求翻译成IT语言”。现在这个翻译层被AI折叠了，真正的能力是定义——定义业务实体是什么、规则边界在哪里、数据结构怎么对齐。

第二层，对AI折叠的价值认知。 03-1写的是“AI碎片需要骨架来组织”，03-2写的是“旧系统可以长出第二生命体”。这一篇补上了第三块拼图：骨架不是AI给你的，是你站在大模型的肩膀上自己定义的，用它。

第三层，对AI给IT开发带来的改变。 业务和IT之间的墙，不是被拆了，是被穿透了。以前业务说需求，IT写代码，中间隔着BA、隔着文档、隔着评审。现在业务直接跟AI说一句话，系统就改了。但穿透的代价是：业务人员必须具备IT架构和AI思维，IT人员必须理解业务本质和场景价值。那堵墙不是消失了，是变成了每个人都必须同时多种视角。

你能用业务语言说清楚一个流程的每个节点为什么存在，同时能用数据结构语言说清楚这些节点怎么存、怎么关联——多种语言你都得会说。

底座替我们干的活越多，我们该拿回的是什么？

不是更多的活，是更多的时间。

拿回时间之后去做什么，这个问题比“AI会不会取代你”重要得多。

我的答案是跟身边的人多吃几顿火锅，多看几场电影，多逛几次公园。

观潮台 · AI新流水线 · AI与IT系列

把复杂趋势，翻译成一句能干活的话。

往期推荐：

03-1｜当AI能10秒生成一个页面，企业真正要买的是什么？

03-2｜旧系统如何长出第二生命体？

本文来自「AI新流水线」系列·AI与IT子系列，聚焦AI介入流程变革的真实现场与瓶颈迁移。