AI 写代码已经老生常谈，但 AI 敢不敢动老系统、动了会不会出事，才是真问题。本期对谈，网易智企邀请广西云开信息技术有限公司 CIO 梁维忠，与网易智企·CodeWave 解决方案专家赵志鹏，把 AI 落地拆成新应用"从无到有"与老应用迭代"从有到变"两个场景，谈透两种开发方式的分工、边界与未来。
市面上有两种声音：一种说 AI 很快就会把开发全部接走，另一种说 AI 写的东西根本不能用；都不好用，因为它们都在笼统地谈"开发"。新应用开发没有历史包袱，是"从无到有"；老应用迭代要在真实用户和历史数据之上做改动，还不能弄坏现有的东西，是"从有到变"；两件事都叫"写代码"，难度结构却完全不一样。
梁维忠长期在企业数字化一线做决策，手上同时压着两条线：业务部门排队等着的新系统，和一堆必须改的老应用。他的数字很有代表性：工作量大致七成在老应用迭代和维护上，三成在做新应用。去年刚推 AI 时内部反馈两极分化，做新项目的兴奋，维护老系统的意见很大。复盘后他才意识到：不是人的问题，是场景的问题。
新应用开发：AI 占"量大但浅"，人守"量小但深"
核心洞察：AI 消灭的是"偶然复杂性"，本质复杂性仍要靠人判断；纠错便宜、错误立刻暴露的地方放开让 AI 跑，纠错昂贵、错误会潜伏的地方必须设关卡。
赵志鹏：新应用这条线上，AI 和传统开发怎么分工？
梁维忠：我们按环节切，不是按人切。
需求整理和原型是 AI 主导：业务把需求说一遍，AI 整理成结构化需求文档并直接搭出能点的原型，过去要一两周，现在两三天。
界面和标准功能是 AI 加平台主导：列表、表单、审批流、权限配置几乎不用人写，代码量占比五成以上但技术含量最低。
数据模型与核心业务逻辑是人主导、AI 辅助：模型一旦定错后面全是返工；怎么算、怎么判，必须人想清楚、写清楚规则。
集成和联调基本还是传统开发：问题通常不在代码，在对方行为不符合文档。架构和非功能性设计完全是人。总结一下：AI 占的是"量大但浅"的部分，人守的是"量小但深"的部分。
赵志鹏：这对应了软件工程里的经典区分。Brooks 所说的偶然复杂性与本质复杂性。前者是工具不够强而额外产生的工作，后者是事情本身固有的难。业务规则怎么定、异常怎么处理。AI 是迄今为止消灭偶然复杂性最强的武器，但还没触及本质复杂性：界面、表单、CRUD，AI 一上来就能吃掉一大块；数据模型、业务规则、架构，AI 给的是"看起来对"的答案，却没有做判断的依据。CodeWave SDD 的 EARS 需求标准化就是沿这条线走的。
赵志鹏：从 0 到 1 这件事上，您体感最大的价值点是什么？
梁维忠：只说一个：不是写得快，是能让需求早一点被证伪。传统流程里，验收时业务才说"这不是我想要的"，返工；我们的返工率历史上长期在三成以上。不是谁不专业，而是开发完成之前业务看到的都是文字和静态图，同一句需求在业务和我们脑子里的画面根本不是一个东西。现在业务说完需求，我们当天或隔天就给他一个能点的东西，"证伪"发生得越早，整个项目就越便宜。今年新项目验收返工率从三成以上降到一成左右，省下的人月比编码提效省的多得多。
赵志鹏：新应用里有哪些东西必须传统开发来做？
梁维忠：三条，写进规范，不靠自觉。第一，数据模型：整个系统里最贵的改动。我们有过教训，一个项目为了快直接用了 AI 的数据模型草稿，业务跑了三个月才发现一个维度设计成一对一、实际是一对多，返工代价超过全部节省。第二，涉及钱、权限和合规的逻辑：AI 可以写，但必须人逐行看懂、必须有完整测试，因为这类错误不一定马上报错，而是悄悄算错。第三，架构决策和技术选型：AI 给的是"教科书上最优"的答案，我们要的是"在我们约束下可行"的答案。
赵志鹏：这三条红线的共同特征是错误代价不对称：写错一个页面改掉几乎零成本，定错数据模型是指数级成本，算错一笔钱可能是信任和合规。所以标准很简单：纠错便宜、错误立刻暴露的地方放开让 AI 跑；纠错昂贵、错误会潜伏的地方必须设关卡。AI 生成的代码"看起来太对了"，真问题藏在边界条件和异常路径里。这正是"马具工程"要解决的：前提不是"AI 总有一天不犯错"，而是"AI 一定会犯错，所以每个环节都要有门禁"。
赵志鹏：用 AI 快速做出新应用之后，有没有留下后遗症？
梁维忠：有，而且被严重低估：做得太快，导致没人真正理解这个系统。传统开发有个好的副作用，写得慢，逼着人想清楚。现在 AI 三天做完一个模块，开发自己可能都没完整读过代码，半年后业务要改，谁都说不清楚。而且生成成本低，团队倾向于"再生成一个"而不是"复用现有的"。
我们曾三个月里出现十几个长得差不多、实现各不相同的表单，谁都不敢删。不管治理，AI 快速造出的新应用一年之后就会变成我们自己制造的"老应用"。我们后来补了两条规则，交付必须附一份"人写的"系统说明；优先复用。
赵志鹏：AI 让写代码变便宜，结果不是代码变少而是暴涨，每一行都是维护成本。AI 时代"生成"不再是瓶颈，"治理"才是。用结构化规格约束生成，让应用以人和机器都能解析的规格与模型形态存在，系统本身是自描述的。CodeWave SDD与 AI Coding 工具不是一类东西。
AI Coding 工具是副驾驶，解决"一个人写得更快"，人不能撒手；CodeWave SDD提供的是"AI 软件交付团队"：在 AI Coding 之上再叠一层，让需求、设计、架构、开发、测试等多角色 Agent 按工程规范协作，人只出现在需求与验收两端。一句话：AI Coding 让一个人变强，AI 软件交付团队让一个人拥有一支团队。
老应用迭代：两个月学费，AI 需要解决"考古加外科手术"问题
核心洞察：代码只告诉 AI"系统是怎么做的"，没告诉它"为什么这么做"；新应用是创作问题，老应用迭代是考古加外科手术问题，AI 的产出只能是人用的中间材料。
赵志鹏：现在切到占您七成工作量的老应用迭代，我们在客户现场听到的抱怨九成以上来自这里，请讲讲真实体感。
梁维忠：说实话，前期是失望的，甚至添乱。三个例子。其一，老系统加功能，开发照 AI 的方案改完主流程是通的，上生产后另一个功能坏了。那段逻辑在别处被一个历史遗留开关控制着，AI 看不到。
其二，AI"好心办坏事"：一个字段当年因对接方限制把日期存成字符串，AI 判定是明显设计缺陷，顺手"修正"成日期类型，改完一堆地方报错。
其三，文档和代码不一致：AI 读到的是一个并不存在的系统，方案看着靠谱其实完全不能用。我们交了两个月学费，结论是："让 AI 读懂老系统然后替我们改"这条路当前阶段风险收益比不划算。
赵志鹏：第二个例子暴露的是比技术更深的问题：AI 能识别哪里不符合最佳实践，却不知道偏离背后的历史原因。原因不在代码里，在人的记忆和会议记录里。这不是模型能力问题，是信息可得性问题：代码只告诉 AI"是怎么做的"，没告诉它"为什么这么做"。AI 在"没有历史"的地方很强，在"有历史"的地方很弱；而老应用的全部难度，就是历史。
赵志鹏：同样的工具、同样的团队，新老应用上表现有差别吗？
梁维忠：核心差别三个。
约束来源不一样：新应用的约束来自需求文档，是显式的；老应用的约束大部分来自现状。数据结构、接口契约、用户习惯，它们"长"在系统里，不可能全整理出来喂给 AI。
正确的定义不一样：新应用的"正确"是满足需求；老应用迭代的"正确"是满足新需求的同时不破坏原有的一切。
验证难度不一样：老应用改完，全量回归理论上要做、实际做不到，只能靠经验判断影响面，而这个经验需要对系统的全局认知和历史事故记忆，AI 很难。所以：新应用开发是"创作"问题，老应用迭代是"考古加外科手术"问题。
赵志鹏：这个比喻非常精准。Lehman 软件演化定律说：被真实使用的系统必须不断变更，且复杂度不断上升、除非专门投入去抑制。这解释了老应用为什么难：必须一直改，而每次改都让它更难改。老应用的问题根子上不是"代码旧"，而是"系统不可被理解、改动不可被验证"。
赵志鹏：那在老应用迭代里，AI 在哪些地方真有用？
梁维忠：我们后来想通了：老应用场景里 AI 不仅能做"生产者"，还能做"研究员"和"质检员"。
一是帮人理解系统：新人接手老模块，先让 AI 把调用关系、数据流向、关键分支梳理成一份说明，这个阶段过去要两周，现在三四天。
二是补测试，收益最大的用法：动老模块之前，先让 AI 基于现有代码"现在的行为"补测试用例，先固定再改，改完一跑哪里行为变了立刻知道；上线后存量改动引发的线上问题降了一半以上。
三是影响面分析：改一个字段、一个接口，让 AI 先把所有引用列清单，人工又慢又容易漏，AI 又快又全。共同点是：AI 的产出都是给人用的中间材料，不是直接上生产的东西；判断和决策还是人做。
赵志鹏：传统开发在老应用迭代里的价值，是被削弱了还是被放大了？
梁维忠：传统开发的能力被削弱了，但人的能力被放大了。我们团队现在最值钱的几个人，不是 AI 用得最溜的，是对老系统最了解的："这么改会不会出事"这个判断依赖很难言传的东西。
历史事故记忆、雷区模块、表面无关实际耦合的功能，都在人脑子里。而 AI 要在老系统上发挥作用，必须有人喂对的上下文、有人判断它的输出对不对，这两件事只有懂系统的人能做。AI 没有替代这类人，反而让他们成了瓶颈。
边界怎么移动：不要等模型变强，要让系统变清楚
核心洞察：模型能力是所有人共享的，系统的可理解程度是你独有的；"AI 让重写变便宜"是陷阱，未来的钥匙在企业自己手里。
赵志鹏：您觉得"AI 开发和传统开发"这条边界，未来一到三年会怎么移动？
梁维忠：会移动，但主要动力不是模型变强。我们的体会是：AI 在我们这里的瓶颈大部分时候不在模型能力，在信息供给，同一个模型，去年在新应用上效果好、老应用上效果差，差别在于上下文清楚不清楚、约束显式不显式。
边界移动的真实动力有两个：一是模型能力提升；二是更重要的，系统本身变得可被机器理解。每把一个模块的数据结构、业务规则、流程逻辑显式表达出来，AI 在那个模块上的能力边界就往前推一步。所以我跟团队讲：不要等模型变强，要让系统变清楚。前者你等不来，后者你今天就能做。
赵志鹏：这是今天最有价值的判断。未来企业在 AI 开发上的差距，不会体现在用了什么模型，会体现在自己的系统有多"可读"。CodeWave SDD 往长看就是在做这件事：把业务逻辑变成"人和机器都能读懂的规格资产"，模型每升级一次，这份资产的价值就被放大一次。
从经营视角看，这件事还有一层：用 SDD 之前，不用改组织模式；用完之后，组织模式会自己变。项目组人数变小、人均效率提升，同样人力拆出更多项目组、并行承接多条业务线，利润与收入整体增长。从"堆人做项目"变成"小团队并行跑多个项目"，这就是 SDD 带来的组织变化。一句话：小团队撬动更多项目、更高利润，这是 ISV 该算的产能账。
赵志鹏：AI 让新应用生产变快了，几年后老应用存量会不会暴增？
梁维忠：一定会，而且比预期更快。假设 AI 让新应用生产效率提升一倍，产出的系统数量就是以前的两倍，每个上线后都进入"持续迭代"状态。我们今天用 AI 加速生产的不只是新应用，同时也是未来的老应用存量，而且是加倍的。
更糟的是，AI 快速生成的系统往往没人完整测试过，按"没有测试的代码就是遗留代码"这个定义，它们从第一天起就是遗留代码。我们可能正在做一件危险的事：生产端提了一倍效率，同时在维护端埋下两倍甚至更多的负担，而后者是长期的、复利的。我们现在定了两条规则：新应用交付必须自带数据模型说明、核心路径测试等"可维护性交付物"；优先复用，严格控制资产重复。
赵志鹏：如果 AI 真的越来越强，老应用的出路是什么？继续迭代，还是干脆重写？
梁维忠："AI 让重写变便宜了，所以可以重写"是个陷阱。重写老系统最贵的从来不是写代码，而是三件事：搞清楚系统现在到底在干什么，包括那些没人记得为什么存在的分支；数据迁移，脏数据和当年遗留的特殊记录，工作量极大且不能出错；切换的业务风险，并行跑多久、怎么对账、怎么回滚，这是组织和流程问题。AI 只降低了"写代码"的成本，而它在整个重写成本里可能只占两三成。
我见过团队启动大重写，卡在数据迁移和并行对账上拖了一年多，最后两套系统都要维护，比原来更糟。所以我的策略是：不做整体重写，做渐进替换。挑改动最频繁、业务价值最高的模块一块一块重做，新老共存、逐步迁移；不怎么动的老部分就让它安静跑着。最好的老系统，是那种你可以放心忘掉它的老系统。
赵志鹏：这里要警惕一个普遍的认知偏差：估算成本时人们总是高估"看得见的工作"，而 AI 恰好加速的是看得见但占比不大的部分。我们总是高估一项技术的短期影响、低估它的长期影响。
梁维忠：我想反问一句：三年之后，老应用迭代这件事 AI 有可能真的接手吗？还是永远需要人来兜底？
赵志鹏：我的判断分三层。
第一，AI 一定会大幅进入迭代场景，但不是靠"模型变得更聪明"。卡住 AI 的不是推理能力而是信息，模型再强只要信息不在那里就只能猜。
第二，钥匙在企业自己手里：三年后会出现明显的两极分化，把系统变成结构化资产的企业，AI 在他们的迭代场景里会非常好用；系统没理顺的企业，哪怕用上最强的模型，体验也不会有本质区别。
人兜底的位置会往上移但不会消失：软件最终要对业务结果负责，AI 目前承担不了责任。
结语：技术负责人该押注什么能力
赵志鹏：最后请您总结，一个技术负责人最该押注的能力是什么？
梁维忠：三句话。第一句，押注"判断力"：AI 和传统开发是不同场景下的配比关系，而配比会变；什么场景放手让 AI 跑、什么地方必须设关卡、什么事情现在还不能交出去，这个判断力是穿越工具变化的。
第二句，押注"让系统变清楚"，这是唯一确定有回报的投入：数据模型抽清楚、业务规则写明白、测试补起来、原因记下来，无论 AI 怎么演进，清楚的系统一定比糊的系统更有价值。
第三句，押注"从写到定义和验证"的能力迁移：实现的门槛在快速下降，"想清楚要什么"和"判断做出来的对不对"这两头的价值在快速上升。AI 没有改变什么是对的，它只是把做对的回报和做错的代价，都放大了很多倍。
志鹏：最后用两句话收尾。关于现在，AI 和传统开发不是谁取代谁，而是在"从无到有"和"从有到变"两个场景里各自占着不同的位置；搞清楚自己面对的是哪个场景，比纠结怎么用 AI 更重要。关于未来：AI 能在你的系统上走多远，取决于你的系统有多清楚；这场竞争的胜负很大程度上不在模型那一侧，在你这一侧。
本文基于网易智企「AI 实战派」系列整理，内容经精编删减。
