为什么说 AI Coding 对软件开发商才刚刚开始?

我是于飞，上海企通数字科技的CEO。1995年入行，第一行代码是用汇编写的。

从汇编到C，从C到C++，从Delphi到.NET，从JEECG到ClickPaaS，再到今天的CodeWave——回头看这30年，我其实只在做一件事：寻找一种更高效、更高质量、可复用、利润更高的软件交付方式。

这不是技术洁癖，而是生存本能。

作为一家ISV（独立软件开发商）的CEO，摸爬滚打数十年，我太清楚这个行业的残酷了。客户预算在压缩，交付周期在缩短，团队成本在上涨，但代码质量不能打折，功能不能缺斤少两，交付不能掉链子。每一个项目，都是一场利润和质量之间的拉锯战。

所以当有人问我：“AI Coding是不是风口？“我的回答是——对ISV来说，这不是风口，是刚需。而且，才刚刚开始。

为什么这么说？因为过去30年里我试过的所有方案，没有一个真正解决ISV的核心痛点。直到最近一年，我才看到了真正的破局可能。

在讲AI Coding之前，我想先说说ISV真实的生存状态。不是行业报告里的数据，是我自己带团队、做项目、算账本的切身体会。

• 第一个困局：效率。一个中型企业管理系统项目，从需求确认到上线交付，45到60天是常态。客户等不了，竞争对手报价比你低、周期比你短。你要么压缩工期牺牲质量，要么坚持质量丢掉订单。这个选择题，我做了无数次。

• 第二个困局：返工。这是利润最大的杀手。我们统计过，中途承接的项目返工率长期在40%以上。你以为开发完了，其实只完成了60%。上线之后，要修半年到一年才能真正稳定。客户不满意，团队很疲惫，利润被一点点吃掉。

• 第三个困局：资产浪费。做了这么多年项目，按理说应该积累了大量可复用的模块、组件、业务模板，但实际复用率不到20%。每个项目都在重复造轮子，因为技术栈在变，客户需求在变，无法沉淀可复用的资产。

坦白说，很多ISV不是死于市场，不是死于技术路线选错，而是死于交付。交付效率上不去，交付质量稳不住，就永远在“接单—亏钱—接单—再亏钱“的循环里打转。

正因为痛，所以我一直在找解药。

1998年我就用过清华圆方基于FoxPro的开发框架。当年觉得眼前一亮——原来可以不用一行行敲代码，拖拖拽拽就能出界面。后来这些年，我陆续尝试过各类开发平台，有的是个人试用，有的是带团队正式投入做项目。每一次都带着期待进去，每一次都带着不同程度的失望出来。

这些平台并非没有价值，在特定场景下确实提效明显。但当你试图用它们做真正的企业级项目，那种有复杂业务逻辑、有多角色权限、有跨模块数据流转、有定制化报表的项目，问题就来了。

我总结了四条共性教训：

• 第一，“表单+流程“的天花板太低。做个审批系统、做个简单的数据管理没问题，但凡涉及复杂的业务计算、条件判断、跨实体关联，平台就力不从心了。

• 第二，平台耦合严重，业务被锁死。离了这个平台就是一堆废数据。客户要私有化部署？要二次开发？要换供应商？抱歉，全部推倒重来。

• 第三，最后10%的工作占掉90%的时间。前面80%的功能唰唰唰很快出来了，结果剩下的定制需求你得写代码、写扩展、甚至绕过平台限制去开发。最终算下来，工期没省多少，反而多了一层学习成本。

• 第四，一旦超出平台能力，又回到传统开发。你花了时间学平台、搭基础，到关键环节发现搞不定，只能用纯代码写，两套体系并行，维护成本反而更高。

这些经历教会了我一个关键认知：过去的开发平台，解决了“画界面“的问题，但没有解决“写逻辑“的问题，更没有解决“交付质量“的问题。

所以当AI Coding出现的时候，我比任何人都想拥抱它。但第一波AI工具，又给我泼了一盆冷水。

2023年开始，AI编程工具井喷。Cursor、GitHub Copilot、Windsurf……我们团队也第一时间跟进了。

说实话，第一次用Cursor写代码的时候，我是震撼的。自然语言描述需求，AI直接生成代码，效率提升肉眼可见。我们甚至用Cursor配合RuoYi框架做了几个实际项目，体验确实不错。

但做了几个项目之后，我开始冷静下来。

因为对ISV来说，“快“不是唯一指标，“稳“才是命门。有人说：“一句话生成CRM，一句话生成ERP。“我认为这完全是扯淡，生成快是快，但生成完了不可用，流程跑不通，逻辑对不上。

什么叫“稳“？就是生成的代码可预期、可维护、可交付。客户验收的时候能过关，上线之后不会三天两头出Bug，后续迭代的时候新同事能接手。

而当下通用的AI Coding工具在这几个维度上，坦率说，还有明显的短板：

• 代码质量不可控。它生成的代码可能风格不统一、命名不规范、分层不合理。一个人用还好，团队协作就乱了。

• 上下文丢失。项目一大，文件一多，AI就开始“忘事“。前面聊好的数据结构，后面生成的接口就对不上了。

• 确定性问题。同样的Prompt，今天生成一个版本，明天生成另一个版本。你无法确保输出的稳定性和一致性。对于企业级项目，这是不可接受的。

这种“没有约束的快速生成“本质上是在高速积累技术债。所以我当时的判断是：这一波AI Coding是“副驾驶“，有用，能辅助，但ISV需要的是“主驾驶“。一个能真正接管核心开发工作、输出可交付成果的“主驾驶“。

我和网易智企·CodeWave的缘分，最早是从可视化能力开始的。当时我在找一个能真正支撑企业级项目的可视化平台。试用CodeWave之后，第一个感觉是：这个IDE的体验很像当年的Delphi。

熟悉Delphi的人应该懂我的意思，那是上一个时代最接近“所见即所得“的开发体验：拖拽组件搭界面，双击就能写逻辑，所有操作都在一个窗口里完成。CodeWave给我的感觉，就是Delphi在AI时代的重生。

但真正让我觉得“这次不一样“的，是2024年到2025年CodeWave在AI方向上的连续进化——从D2C，到Vibe Coding，再到Spec-Driven。

Spec-Driven的核心逻辑是什么？三个关键词：固定范式、需求驱动、确定性输出。

你把PRD（产品需求文档）按照规范整理好，输入给CodeWave。系统不是“自由发挥“地生成代码，而是按照一套固定的规约范式，将需求映射为标准化的技术实现。中间通过NASL（网易自研的DSL中间语言层）做解耦，生成的不是直接绑定某个运行时的代码，而是可以多目标编译的中间表达。

打个比方：通用AI编程像freestyle即兴说唱，每次表演都不一样，精彩但不可控；Spec-Driven像轨道列车，方向确定、路径可预期、到站时间可信赖。

对ISV来说，这意味着什么？

意味着我不再需要一个团队里全是高级开发。一个懂业务的人把Spec写好，一个会Review的人做质量把关，AI负责中间所有的代码生成。中等人才加上CodeWave，就能产出过去只有高级团队才能交付的成果。

这才是ISV真正需要的东西。

理论再好，ISV最终看的是实战。所以我们拿了一个真实的BIMS系统开发项目来做验证。

• 项目规模：3个核心业务模块 / 26个页面 / 147个功能点 / 84页PRD文档

• 团队配置：2人——1人负责编写Spec文件，1人负责Review和调整。

没错，就是2个人。我们同时用两种方案做了对比：一套是Cursor + RuoYi框架的AI Coding方案，一套是CodeWave Spec-Driven方案。同样的需求，同样的功能点，看哪套交付得又快又稳。

结果出来的时候，我心里是有底的，但数据还是超出了预期：

• 提效 2.5 倍。CodeWave整体交付效率是Cursor + RuoYi方案的2.5倍。这不是跟纯手写代码比，是跟“已经用了AI辅助“的方案比。

• 首次可用率 78.63%。AI生成的功能，接近八成不需要任何人工修改，直接可用。而Cursor + RuoYi方案的产出则需要大量人工调整和逻辑修正才能达到可交付状态。

让我最心动的不是“2.5倍提效“这个数字，而是“可交付“。

CodeWave生成的结果，不是Demo，不是原型，是可以直接给客户看、可以直接部署、可以直接进入验收流程的交付物。对ISV来说，“可交付“等于“可收款“，等于“有利润“。

坦诚说，CodeWave 目前还在快速迭代中。我们在实践过程中遇到了一些需要打磨的地方，我想如实说出来。

举个最直观的例子：CodeWave生成一个完整模块需要一定的等待时间，对习惯了Cursor秒级响应的开发者来说，这个体感是明显的。但换个角度想——Cursor秒级生成的代码你可能要花半小时去调，而CodeWave等几分钟出来的结果八成直接能用。算总账，还是后者划算。

但关键在于，这些是“90分产品到95分“过程中的优化项，不是“能不能用“的根基性问题。CodeWave的底层逻辑规约驱动、确定性输出、企业级可交付。这个底座是扎实的。

而且网易智企团队的响应速度让我有信心：我们的反馈当天就能看到回应，很多改进几乎是即时跟进的。这种迭代节奏，意味着今天的“90分“很快会变成明天的“95分“。

对ISV来说，选择工具从来不是选“当前最完美的“，而是选“方向对、进化快、底座稳“的。

数据摆在这里了，但这只是一个项目的验证。让我兴奋的，不仅是当下的成绩，更是我看到的趋势。

回到分享主题：为什么说AI Coding对ISV来说才刚刚开始？这不是一个修辞手法，而是基于我的真实观察和判断。

第一个判断：工具成熟度刚刚越过临界点。

什么叫“临界点“？就是从“能用“到“敢用到客户项目里“的那条线。

过去两年，AI Coding工具从“惊艳的玩具“进化成了“初步可用的工具“。但对ISV来说，“初步可用“不够，必须是“企业级可用“——可交付、可维护、可审计、可迭代。

CodeWave是我个人目前看到的第一个真正越过这条线的方案。78.63%的首次可用率、2.5倍的提效——这些数据证明，AI不再只是写写Demo的副驾驶，而是可以承担核心交付工作的主力。

但请注意，这后面还有巨大的提升空间：可用率从78%到90%再到95%，提效从2.5倍到5倍到10倍，每一个百分点的提升都意味着ISV利润结构的根本改变。

第二个判断：行业认知存在巨大的时差。

我接触到的一部分海外团队，已经把AI深度嵌入了交付全流程。他们不再讨论“要不要用AI”，而是在优化“怎么用AI用得更好“。而我在国内接触的大量ISV同行，很多还在用纯手写代码的方式交付项目，有些试过低零代码但踩了坑退回来了，有些知道AI Coding但觉得“不靠谱、不敢用“。

这个认知时差，既是挑战，也是机会。

挑战在于：如果你是ISV的决策者，你需要在信息不充分的情况下做出判断——要不要投入时间和精力去学习、验证、切换到AI驱动的开发模式？

机会在于：正是因为大多数人还没动，先动的人才有窗口。

第三个判断：真正的红利窗口刚刚打开。

我说的不是“用AI写几行代码“的红利，而是“用AI重构整个交付链路“的红利。

从需求分析，到架构设计，到代码生成，到测试验证，到部署上线，当这个链路中的每一个环节都能被AI加速和优化的时候，ISV的商业模型会发生根本性变化：

• 同样的团队规模，可以同时服务更多客户

• 同样的项目报价，利润率可以从15%提升到40%以上

• 同样的交付周期，质量可以从“凑合能用“提升到“客户主动转介绍“

这个红利窗口有多大？我估计就是未来2到3年。谁先跑通“AI原生的交付流程“，谁就能在这个窗口期建立结构性优势。等到所有人都会用的时候，就不再是优势，而是门槛了。

1995年，我23岁，第一次在电脑上写出一段跑通的汇编程序，激动得一夜没睡。

2026年，我54岁，坐在电脑前看CodeWave根据我的PRD文档生成出一个完整的业务系统，那种激动，和31年前一模一样。

技术换了无数代。汇编、C、C++、Delphi、.NET、Java、低代码、AI编程……但ISV的本质从未改变——用技术为客户创造价值，用效率为自己赢得利润，用质量为行业赢得尊重。

AI Coding不是终点，而是新的起点。

它不会让软件开发变得“不需要人“，但会让“会用AI的人“价值倍增。它不会让ISV的生意变得轻松，但会让“率先转型的ISV”获得前所未有的竞争优势。

如果你也是ISV同行，我的建议很简单：不要等完美方案出现再行动。现在就开始尝试，哪怕从一个20到30个页面的中小型项目开始验证。我们当初就是这么做的，先用一个真实项目跑通流程，再决定要不要全面切换。你需要积累的不只是工具使用经验，而是“如何用AI重构团队协作与交付方式“的认知——这才是真正的壁垒。

我在这个行业干了30年，踩过无数坑，走过无数弯路。但我从来没有像今天这样确信：ISV最好的时代，才刚刚开始。

前提是，你愿意拥抱变化。与所有同行共勉：永远年轻，永远在路上！

本文基于上海企通数字科技CEO于飞在网易智企·CodeWave《ISV利润从100万到300万》AI Coding实践直播中的演讲整理。

网易智企·CodeWave 可控的企业级 AI Coding 平台，全国六城巡演正式启动！首站广州，5 月 11 日见。

这一场你将获得：

✅ 可落地的 Spec-Driven 开发工具：告别”AI 生成完还要反复返工”的死循环✅ 6 个软件开发配套 Skill：不是听完就忘的概念分享，回去就能在项目上跑起来✅ 本地已跑通模式的 ISV 同行：案例交流、资源对接，就在现场发生

📍 南京、深圳、上海、杭州、北京站已同步开放报名，扫码后可选择你所在的城市。

👇 扫码选择你所在的城市，即刻报名

AI 正在从「能用」走向「好用」，但技术落地从来不是单点突破，而是一场产业协同的远征。 如果你也在寻找 AI 与业务深度融合的真实路径，期待与千位企业决策者面对面碰撞，5月29日杭州，网易创新企业大会诚邀你现场见证、共创答案。

👇 扫码立即报名，锁定席位

点击“阅读原文”，免费试用CodeWave！