AI 能写代码已经不是新闻但ISV敢不敢把 AI 写的代码交付给客户、上线到生产环境这才是真问题。本期对谈网易智企邀请深耕交付行业 18 年的 ISV 掌舵者周勇与网易智企·CodeWave 解决方案专家赵志鹏从真实业务压力出发聊透一个核心命题AI Coding 从能用到敢交付中间到底差什么过去一年AI Coding 火遍整个技术圈。Copilot、Claude、Cursor()、Codex……各类代码生成工具轮番登场大家第一次看到 AI 写代码时无不感到震撼。似乎只要把需求告诉工具AI 就能直接生成前端页面、后端逻辑甚至底层接口。 但如果把视角从个人开发者转向企业交付场景问题就没那么简单了。对于一家真正要做交付的ISV来说关键问题不是 AI 能不能写代码而是 AI 写出来的代码企业到底敢不敢用、敢不敢上线、敢不敢交付。如果出了问题怎么追溯责任怎么算带着这个问题网易智企邀请到南京盛世安链云计算有限公司总经理周勇进行了一场关于AI Coding 在真实企业交付中到底能不能用的深度对谈。 周勇在软件交付行业深耕了十八年先后服务过华为、阿里等头部客户如今带领一家约百人规模的 ISV 企业深耕政企与金融赛道。他不是技术理论家而是每天在投标、交付、带团队、扛利润的一线经营者。 在接下来的对谈中双方坦率地聊了四个话题ISV 当前的真实压力、AI Coding 在企业场景中的认知转变、什么样的 AI Coding 工具 ISV 才敢真正拿来交付以及将如何改写 ISV 的生意模式。01客户要求越来越高利润却越来越薄核心洞察ISV 的天花板不是技术能力而是人天×单价的结构性枷锁。志鹏这几年软件交付行业的变化非常明显。外部客户的预算越来越谨慎但对交付速度、系统体验和智能化能力的要求反而越来越高。您在近几年投标、签单的时候感受到的最明显变化是什么 周勇比较明显的变化就是卷。 客户对交付速度的要求很高而且这不是单纯的压价格。以前我们投标靠拼方案、拼工期、拼人天大家坐下来还能聊。现在客户会把一些非常难的问题直接抛出来。别人把周期压一半你能不能你现在的方案里面有没有智能模块能不能跟我现有系统打通客户不太关注你有多少人不再关注你为这个项目付出了多少只看交付结果。我有一次一个长期合作的客户跟我说预算往下砍两成交付范围基本不变上线时间还要提前一个月。这种压力不是单向的某一个点而是很普遍的现象。说到底你效率提不上去连上桌的资格都没有。 志鹏从公司管理者的角度您在人力成本上最头疼的是什么 周勇感觉就是两头都够不着。 一边是高端人才。能做架构、能总负责交付的高级开发他们薪资高、养起来贵大厂开出的薪水可能是我们的数倍。不是说我给不起但从个人发展来说我们有时候也不应该去强留。 另一边是初中级人员。能招到量也大但面对复杂的交付场景他们很难独当一面。能写功能但遇到复杂的业务规则、性能瓶颈或者系统集成就容易出问题。 所以我们在想AI Coding 能不能把高级人员的规范和经验沉淀下来让初中级的同学借助工具写出靠谱的代码整个人力结构就可能被优化。但前提是AI 不能自由发挥它得遵循我们的交付标准否则初中级用了 AI反而可能把不规范放大那就更可怕了。志鹏有没有感觉到团队在扩张订单在增长但利润却没有同步上升 周勇坦白讲以前我们的利润能做到25-30 个点。现在随着整个行业透明度越来越高、竞争越来越卷能保住 15 个点就不错了。 ISV 的交付归根结底还是算人天你的上限就是投入的人数乘以天数乘以单价这是结构性的天花板。再加上客户的需求变更改流程、调权限。你投入的人天越来越多隐性的返工成本也在持续叠加。 今年我们营收增长了 40%但全年算下来利润非常薄。如果这种交付模式不调整、不突破光靠堆人这条路肯定很难走下去。人在某种程度上并不完全是正向资产也可能成为负资产。志鹏ISV 当前面临的压力可以概括为客户要求越来越高、人力成本越来越重、利润越来越薄而同行已经开始用 AI 挤压效率差。AI Coding 对 ISV 已经不是可选项而是一个必须认真看待的变量。在问到同行状态时周勇将 ISV 分为三类这是一个非常犀利的观察。周勇我觉得现在不是个例应该说是群体性焦虑。但真正落地实施的还是少数。第一类焦虑但观望。怕用不好、怕出问题、体量小、对产品和现金流有蛮高要求投入后看不到回报就继续观望。这是当前绝大多数。第二类试了但没跑通。团队装了 Copilot、Cursor 等工具个人开发确实快了但放到客户的项目群交付里没有看到实质性的提效。你说提升 50%其实还是有一些差异的。第三类真正用 AI 去重构了交付体系把效率跑通了的。这类很少但它会强势拿走绝大部分 ISV 供应商的订单。 以前同行聊的是今年收入多少、利润怎么样现在都在聊你们最近有没有用 AI。对话背后的焦虑完全不同。因为第三类一旦跑通前两类的生存空间会被直接挤掉。02从能不能写到敢不敢交认知的跃迁核心洞察从AI 能不能写代码到AI 写的代码敢不敢交付是企业 AI Coding 认知的真正分水岭。志鹏您第一次看到 AI 写代码的时候是兴奋多还是怀疑多 周勇第一次用极度兴奋。几分钟就生成了完整的接口和前端页面。这些代码正常情况下我们团队要写大半天。第一反应肯定是觉得产能要翻倍了交付周期也能大幅压缩。 但等拿真实的业务需求做了测试后问题就暴露出来了。AI 不太能理解行业的业务规则生成的代码逻辑会有漏洞、权限有缺失、代码风格混乱。你做交付的时候能写一段代码很厉害但你能不能交付一个完整的、可维护的系统上线之后会不会出问题客户验收的时候能不能通过这是两个完全不同的问题。所以对 AI Coding 的态度不是说能不能用而是我们敢不敢用于交付。 志鹏个人开发者更关注能不能再快一点但企业交付关注的是业务规则准不准、系统架构是不是一致、安全和权限符不符合规范、代码质量能不能可控。AI Coding 从 Demo 到交付中间隔着一个很深的鸿沟。那站在 ISV 老板的角度AI Coding 到底要满足哪些条件您才敢把它放到真实交付项目里 周勇第一可控。AI 不能自由发挥你得按我的架构、我的规范来做事情。第二可追溯。出了问题你得能查到是哪个代码、哪条业务规则导致的不能是个黑盒。第三兜底。出了事不能甩锅给 AI得有人或者平台把最后一道关。第四不绑定。代码是我的交付物我要能拿走能二次开发。说到底是一个核心问题出了事我能找谁这个问题不解决AI 再厉害我也不敢用。客户不会因为代码是 AI 写的就免除我们的责任交付方永远要承担最终责任。 志鹏企业级 AI Coding 的信任门槛可以概括成四句话看得见生成过程、管得住生成边界、查得到问题来源、说得清责任归属。只有做到这四点AI Coding 才能真正走入企业项目。03真正的分水岭提示驱动 vs 规格驱动核心洞察Prompt 驱动像口头吩咐装修师傅Spec 驱动像交付一整套施工图纸。志鹏市面上的 AI Coding 工具很多网易智企·CodeWave SDD 跟它们本质的区别是什么我认为最大的区别在于绝大多数 AI Coding 工具本质上是提示驱动Prompt-driven()而 CodeWave SDD 强调的是规格驱动Spec-driven。提示驱动的方式很灵活开发者通过自然语言告诉 AI 要写什么。但问题在于它高度依赖人对提示词的提炼能力和表达水平。不同的人写不同的提示词AI 生成的结果可能完全不一致。这在个人场景里可以接受但在企业交付场景里是巨大的风险因为企业要的是一致性、规范性和可追溯性。 规格驱动的思路完全不同。我们不是让 AI 自由发挥而是先把业务需求页面逻辑、数据模型、流程规则、权限规则、接口定义全部变成Spec再基于Spec进行系统的架构设计、研发任务拆解通过NASL语言可以生成数据建模、前端页面、后端服务等最终通过NASL硬约束生成规范的企业级源码。 打个比方提示驱动更像你跟装修师傅说我要一个高级一点的客厅最后装成什么样完全取决于师傅的个人实力和经验规格驱动更像你给了师傅一整套施工图纸里面有明确的材料标准、电路位置甚至验收要求都写好了。 周勇那 Spec 谁来写门槛比写代码高还是低如果比写代码还难对我们来说就是另一种负担。 志鹏这是很多客户都会问的。首先Spec 不是让业务人员或开发人员从零去写一大堆复杂文档。它更像是把原本散落在需求文档、会议纪要、产品原型里的所有内容变成一份人能理解、AI 也能执行的规格。 CodeWave SDD 有一个很重要的能力叫EARS 需求标准化它会帮助团队把尽量快一点界面再简洁一点这种模糊描述转化成当什么条件发生时系统应该做什么事情如果出现异常应该怎么处理等规范表述。Spec 的价值不是增加文档负担而是在编码之前先把需求边界、触发条件、业务规则讲清楚。未来的核心能力会从谁写代码更快升级为谁能把需求拆解得更清楚、规则定义得更明确、交付边界讲得更清楚。周勇那需求变更怎么办客户经常会调整如果改一个需求就要重新来一遍AI带来的效率提升可能全被吃掉了。 志鹏传统开发中需求变更的痛苦很大程度来源于需求跟代码之间是割裂的。客户改了一条业务规则团队要先回忆当初怎么设计的、代码在哪、影响范围多大大家都不愿意改。CodeWave的思路是让 Spec、领域语言和代码资源之间保持清晰的对应关系。需求变更时不是钻进代码里大海捞针而是先回 Spec 里调整规则再由平台识别影响范围、驱动后续应用调整。同时CodeWave 本身就具备全生命周期管控能力从需求、开发、验证、发布到运维。变更不再是代码层面的局部修补而是规格层面的有序演进。企业软件真正的成本往往不在第一次开发而在后续长期的维护和变化。 周勇出了问题怎么追溯 志鹏这恰恰是 Spec-driven 体系的核心优势。NASL 是一套面向 Web 应用的领域特定语言()涵盖数据定义、页面、流程和权限等子语言。它的价值不是替代 TypeScript而是把 Spec 层面的业务约束进一步转化成平台可控、可校验、可维护的开发约束。 这样一来生成结果就不再是黑盒每一段逻辑、每个页面行为、每个数据关系都可以找到对应的规则模型和平台约束。出了问题可以沿着一条清晰的链路往回追溯问题发生在哪个页面、哪个业务流程、调用了哪个组件而不再依赖开发人员的个人经验逐行排查。 企业级AI Coding不只负责把代码写出来还要负责说清楚代码为什么要这样设计、为什么这样写。只有能说清楚企业才真正敢负责。04初中级开发者的放大镜效应核心洞察工具会放大使用者的能力——强者更强弱者的问题也会被放大。志鹏初中级开发用 AI Coding会不会很容易把不合规的代码带到真实项目里 周勇这就是我比较担心的。我们发现一个规律。工具会放大使用者的能力。强的人用 AI更快更准弱的人用 AI更可能把不好的结果直接合并进去。正如我们内部常说的AI 生成的代码有时候看起来非常对但就像一本正经地胡说八道。初中级开发者很容易放弃警惕。 所以企业级的 AI Coding不能只靠开发者个人去把关还是要有平台级的兜底标准。 志鹏这正是 CodeWave 里Harness工程马具工程的设计出发点。我们不假设 AI 永远正确而是用事前约束、事后可验证、工具化检测来减少胡说八道的现象。整个过程中需求不会一次性丢给 AI而是拆成一系列可检查、可确认、可回退的任务节点再结合可视化开发的模型约束。这些事情不能完全靠初中级开发者自己判断而应该由平台统一提供约束。 打个比方这相当于给初中级开发者配了一位永远不会疲劳的高级代码审核员。它不是替代所有人的判断而是把基础规范、工程约束、质量检查前置让团队的整体交付质量变得更稳定。AI 帮你写代码和AI 帮你过规范是两件完全不同的事。前者是生产力工具后者是质量体系。05ISV 的商业模式会被重写核心洞察从卖人天走向卖确定性是 ISV 商业模式升级的关键一跃。志鹏如果 AI Coding 真的能变成可控、可追溯、可维护、可交付的能力您觉得 ISV 的生意模式会发生什么变化 周勇我觉得首先不是效率的提升。它应该是一个产能结构的释放。高级人员还是有限的有时并行三个以上的项目就会出现全线延期。如果平台工具能让高级人员专注于行业方案和架构设计把标准化开发交给初中级人员协同 AI 工具完成同规模团队能承载的项目数量应该能提升 50% 以上。同时人才结构也可以优化。不需要大量高薪去招聘执行型开发人力成本就可控了项目毛利空间自然就提升了。 招人层面也会发生变化。单纯写代码的价值会持续降低而能听懂客户业务、能拆解需求、能搭建标准化方案和行业模型的复合型人才会成为企业的核心资产。招聘时会降低底层编码的权重重点考察行业理解力和业务建模能力。从定价模式来看最关键的转变是从卖人天走向卖确定性。过去按人天报价客户不断压价、行业不断内卷这是恶性循环。但如果我们依托标准化的 AI 平台能给出确定的周期、确定的质量指标和确定的售后维护标准就可以把整套解决方案打包定价不再按人头算。客户愿意为确定性付出溢价。而不是因为你加了多少班。 志鹏总结一下AI Coding 对 ISV 的改变是四个层面的。团队效率提升同等人数承接更多项目人才结构升级从写代码转向懂业务、会建模、定规格定价模式升级从卖人天转向卖确定性交付资产持续沉淀从项目制走向产品化和行业方案化。06结语ISV 的核心竞争力会被重新定义志鹏周总最后请您用几句话总结一下站在 ISV 企业经营者的角度怎么看待 AI Coding 对交付行业的影响 周勇第一AI Coding 不是会不会来的问题而是怎么落地的问题。这一波不会绕过 ISV反而会让 ISV 的竞争格局被重塑。先用起来的组织会反过来挤压还在观望的组织。第二AI 本身不是壁垒。谁能把 AI 融入可控的交付体系并真正落地谁才能赢。第三ISV 的真正护城河不会消失但会被重新定义。未来能够存活且有竞争力的 ISV一定是依托标准化的 AI 工具沉淀行业资产能够向客户提供稳定、确定性的数字化方案服务商。 从代码生成工具走向可控的交付体系这条路如果能走通ISV 的整个商业模式都会升级。 志鹏今天聊下来有一个核心观点特别清晰。AI 写代码不难难的是让企业敢用、敢交付、敢负责。未来真正有竞争力的 ISV一定不是单纯拼人力、拼工时、拼低价而是拼三件事行业认知的厚度你是否比 AI 更懂客户场景、交付的确定性你是否能让客户放心把项目按时按质交付、快速的迭代能力你能否跟得上客户变化的节奏。当 AI 把编码效率不断拉高ISV 真正要沉淀的是行业理解、交付体系和客户资产。以上内容源于客户对谈直播内容整理直播回放请关注视频号“网易智企-CodeWave”于直播回放中观看。
