我是于飞，上海企通数字科技的CEO。1995年入行，第一行代码是用汇编写的。
从汇编到C，从C到C++，从Delphi到.NET，从JEECG到ClickPaaS，再到今天的CodeWave——回头看这30年，我其实只在做一件事：寻找一种更高效、更高质量、可复用、利润更高的软件交付方式。
这不是技术洁癖，而是生存本能。
作为一家ISV(独立软件开发商)的CEO，摸爬滚打数十年，我太清楚这个行业的残酷了。客户预算在压缩，交付周期在缩短，团队成本在上涨，但代码质量不能打折，功能不能缺斤少两，交付不能掉链子。每一个项目，都是一场利润和质量之间的拉锯战。
所以当有人问我："AI Coding是不是风口?"我的回答是——对ISV来说，这不是风口，是刚需。而且，才刚刚开始。
为什么这么说?因为过去30年里我试过的所有方案，没有一个真正解决ISV的核心痛点。直到最近一年，我才看到了真正的破局可能。
ISV的真实处境：我们到底被什么困住了?
在讲AI Coding之前，我想先说说ISV真实的生存状态。不是行业报告里的数据，是我自己带团队、做项目、算账本的切身体会。
第一个困局：效率。一个中型企业管理系统项目，从需求确认到上线交付，45到60天是常态。客户等不了，竞争对手报价比你低、周期比你短。你要么压缩工期牺牲质量，要么坚持质量丢掉订单。这个选择题，我做了无数次。
第二个困局：返工。这是利润最大的杀手。我们统计过，中途承接的项目返工率长期在40%以上。你以为开发完了，其实只完成了60%。上线之后，要修半年到一年才能真正稳定。客户不满意，团队很疲惫，利润被一点点吃掉。
第三个困局：资产浪费。做了这么多年项目，按理说应该积累了大量可复用的模块、组件、业务模板，但实际复用率不到20%。每个项目都在重复造轮子，因为技术栈在变，客户需求在变，无法沉淀可复用的资产。
坦白说，很多ISV不是死于市场，不是死于技术路线选错，而是死于交付。交付效率上不去，交付质量稳不住，就永远在"接单—亏钱—接单—再亏钱"的循环里打转。
我踩过的坑：各类开发平台教会了我什么
正因为痛，所以我一直在找解药。
1998年我就用过清华圆方基于FoxPro的开发框架。当年觉得眼前一亮——原来可以不用一行行敲代码，拖拖拽拽就能出界面。后来这些年，我陆续尝试过各类开发平台，有的是个人试用，有的是带团队正式投入做项目。每一次都带着期待进去，每一次都带着不同程度的失望出来。
这些平台并非没有价值，在特定场景下确实提效明显。但当你试图用它们做真正的企业级项目，那种有复杂业务逻辑、有多角色权限、有跨模块数据流转、有定制化报表的项目，问题就来了。
我总结了四条共性教训：
第一，"表单+流程"的天花板太低。做个审批系统、做个简单的数据管理没问题，但凡涉及复杂的业务计算、条件判断、跨实体关联，平台就力不从心了。
第二，平台耦合严重，业务被锁死。离了这个平台就是一堆废数据。客户要私有化部署?要二次开发?要换供应商?抱歉，全部推倒重来。
第三，最后10%的工作占掉90%的时间。前面80%的功能唰唰唰很快出来了，结果剩下的定制需求你得写代码、写扩展、甚至绕过平台限制去开发。最终算下来，工期没省多少，反而多了一层学习成本。
第四，一旦超出平台能力，又回到传统开发。你花了时间学平台、搭基础，到关键环节发现搞不定，只能用纯代码写，两套体系并行，维护成本反而更高。
这些经历教会了我一个关键认知：过去的开发平台，解决了"画界面"的问题，但没有解决"写逻辑"的问题，更没有解决"交付质量"的问题。
所以当AI Coding出现的时候，我比任何人都想拥抱它。但第一波AI工具，又给我泼了一盆冷水。
AI Coding的第一波浪潮：快，但"飘"
2023年开始，AI编程工具井喷。Cursor、GitHub Copilot、Windsurf……我们团队也第一时间跟进了。
说实话，第一次用Cursor写代码的时候，我是震撼的。自然语言描述需求，AI直接生成代码，效率提升肉眼可见。我们甚至用Cursor配合RuoYi框架做了几个实际项目，体验确实不错。
但做了几个项目之后，我开始冷静下来。
因为对ISV来说，"快"不是唯一指标，"稳"才是命门。有人说："一句话生成CRM，一句话生成ERP。"我认为这完全是扯淡，生成快是快，但生成完了不可用，流程跑不通，逻辑对不上。
什么叫"稳"？就是生成的代码可预期、可维护、可交付。客户验收的时候能过关，上线之后不会三天两头出Bug，后续迭代的时候新同事能接手。
而当下通用的AI Coding工具在这几个维度上，坦率说，还有明显的短板：
代码质量不可控。它生成的代码可能风格不统一、命名不规范、分层不合理。一个人用还好，团队协作就乱了。
上下文丢失。项目一大，文件一多，AI就开始"忘事"。前面聊好的数据结构，后面生成的接口就对不上了。
确定性问题。同样的Prompt，今天生成一个版本，明天生成另一个版本。你无法确保输出的稳定性和一致性。对于企业级项目，这是不可接受的。
这种"没有约束的快速生成"本质上是在高速积累技术债。所以我当时的判断是：这一波AI Coding是"副驾驶"，有用，能辅助，但ISV需要的是"主驾驶"。一个能真正接管核心开发工作、输出可交付成果的"主驾驶"。
CodeWave 为什么让我觉得"这次不一样"
我和网易智企·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真正需要的东西。
实战验证：BIMS项目全记录
理论再好，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实践直播中的演讲整理。
