AI 写了60% 的代码，为什么企业研发效率还是没飞起来？

本文来自微信公众号： InfoQ ，编辑：宇琪，作者：AICon，原文标题：《AI 写了 60% 的代码，为什么企业研发效率还是没飞起来？》

1行业现状与认知冲突

张子天：过去一年，AI Coding的热度已经从"尝鲜"进入"大规模落地"阶段。但现在很多企业都遇到了一个共同问题：AI代码生成率越来越高，但需求交付效率并没有同步暴涨。企业AI Coding今天真正卡住的核心问题是什么？

李京：快手从Copilot时代开始做智能化提效探索，经历续写、Agentic多文件生成、到SDD推进复杂任务。续写时代AI代码贡献率个位数，Agentic时代跃升到百分之二三十，今年已到百分之五六十。但遇到了问题：工程师体感提效40%，研发周期却没怎么变化，个人承接需求数和组织吞吐都没有很大提升。我们洞察到：会用AI工具不等于个人提效，个人提效也不等于组织提效。问题有三方面：组织层面，还是传统产研团队模式；协同层面，上下文在传递中不断流失；知识层面，业务知识、领域知识、研发知识没有很好地沉淀打通。

郑鑫祺：AI生成能力基本没问题，核心问题在验证和前期对齐上。它把生产力拉上去了，但交互链条各环节没跟上。第二个问题是组织协同，AI让个人变快了，但整体组织效率是否还适合原来的传递链条要打问号。第三个点，企业大型分布式系统过去过度微服务化和中台设计，在AI环境中导致研发环境分散，需要工程治理和模型能力互相衔接来解决。

李京：我们经历了几个阶段：AI First阶段是人去应用AI，传统工具结合AI；现在叫AI Native，让整个东西是AI原生的——从为人设计工具，到结合AI，再到部分工具专门为AI设计。

郑鑫祺：背后还有人和AI的地位设计哲学。AI工具发展特别快，有的是助理型，有的在提独立个体。到底人扮演什么角色？在电商等复杂领域，人的决策判断依然关键；但也有很多确定的PMO流程，AI可以承担更多。这些会导致协作关系变化，对上层工具设计提出不同要求。

张子天：AI来了，大家总觉得是"金锄头"——皇帝种地也用金锄头，或把驴换成AI机械驴，显然不是最佳实践。过去大规模研发中形成的岗位分工和协作方式，在AI Coding时代可能已不适合。不只是研发层面的前后端合并，产品层面、需求业务方都需要重新整合，找到职能分工的新边界。但组织变革牵一发而动全身，大中企业比较谨慎，只能循序渐进。

张子天：今年大家明显能感受到，AI Coding正在从Copilot→Agent→Multi-Agent→Agent Team快速演进。同时，越来越多企业开始做面向非研发的Vibe Coding和NoCode Agent。你们怎么看这波变化？未来企业真正需要的，是"更强的AI编程工具"，还是"一个新的AI协作系统"？

郑鑫祺：从Copilot到Agent Team，一直在往前走的是工具。但工具始终是手段，真正能达到整体吞吐量提升、人均效率提升、代码产量提升的，协作才是终点。协作系统不只是多个Agent并行，还包含人和AI之间协作关系的重构。在我们Vibe Coding产品中，深度研究从需求到上线每个节点中人和AI的关系，哪些AI可以去决策和协作，哪些必须人来做关键判断。社区通用方案偏向单兵视角提效，在整个协作过程中是缺位的。推进也不能太激进，单兵阶段先达到一定指标，过程中用Claude加各种Harness体系丰富知识库和上下文采集，再慢慢往终点推进。

李京：过年前后OpenClaw发布带来了开源形态和新使用模式，让更多人认知到Agent AI能干什么，之后大量非研发人员开始使用。关于Agent协作系统，我们做了几方面：一是生态建设，CLI加Skill让非研发人员在内部生态里实现角色提效；二是知识打通，团队层面的互联互通；三是任务编排，业界有Web看板或以角色划分组建Agent Team等方式，还没有特别成熟的方案。

郑鑫：我想问李京老师一个问题。在知识整理这块，一个大的域有非常多的跨系统知识，一个需求涉及多个系统。怎么样在过程中让大家沉淀需求、沉淀知识、沉淀哪些知识？

李京：我们走了几个阶段。第一阶段做研发域和业务域知识构建，类似Project Wiki，跟业务侧联动做业务属性标注，也面向AI做业务角度的组织，把工具使用等信息做成知识放进去。第二阶段做流转平台，从需求分析、灌入任务，到PRD、单测、代码产生，整个链条串联。第三阶段是"自进化"——知识需要迭代起来不是死的，随着大家重点迭代方向和Skill使用情况，去迭代AgentOS里的知识和记忆体系。

郑鑫祺：现在每个人在单仓里已沉淀了很多Knowledge，不管是Code Graph还是PRD、各种总结。缺的是怎么提升SDD模式中Spec的质量和降低对话成本。花两小时对齐Spec再加一小时CR，和熟练工程师上手差不多。Spec质量上，更关键的是记忆的迭代和关键记忆的抽象。早期推动容易没指标牵引，大家都在整资料，指标最终最关键。

李京：在有限上下文下，不可能把所有知识全灌进去。除了上下文迭代策略，我们也在效果层面做把控，每个环节针对性沉淀评测和用例，保证Agent按效果优先的方式不断提升。

张子天：刚才二位老师讲的内容都是企业已经在实践的，这些内容都建立在一个非常强大的已有Knowledge基础之上。对于一些中小团队，落地其实更难，他们很难有专门的架构方向的人，既能深入业务，又能把不同模块、不同业务场景的东西真正梳理到一起。中小团队更多人就是铺在业务上，针对某一个需求、某一个Feature、某一个单点系统去做。不知道二位对中小团队的场景有没有比较好的建议？

郑鑫祺：中小团队反而有更成熟的方案可直接使用。大厂因为有大量历史技术债和过度设计系统，需要花更多时间建设"航空母舰"。中小团队系统架构接近社区，Claude Code加Harness体系本身是Work的，纳入更快。但核心要关注效果优先——做了很多Knowledge结果效果没变化，沉浸于"赛博精神病"里。Spec对焦轮数、采纳率等指标要非常关注，以此反推知识沉淀。

李京：中小团队落地更快速。社区里Claude Code、OpenCode、各种Agent和Harness，买几个Token Plan就能有效Run起来。即使大企业，优秀实践也是把大组织拆成小团队，通过Rules、AgentsMD、Spec等逐渐形成标准化。Agent基础设施、使用实践、研发流程，都有成型方案。

郑鑫祺：小团队核心要关注成本，很多测试烧了非常多Token，要用更低成本把事做成。

2企业级AI Coding的真实难点

张子天：现在很多AI Coding产品Demo都很强。但真正进入企业生产环境之后，很快会出现几个经典问题：长任务越来越偏、AI自己乱改架构、上下文失控、结果不可复现、用户一句话把任务带偏……这些问题本质上不是模型问题，而是系统问题。你们内部分别是怎么解决的？

李京：长任务是我们一个专门的研究方向，在"不计成本"的情况下，Agent能不能完成更复杂的任务。目标就是让Agent不间断地执行，一直到完成任务。

我们分两个阶段来看。第一阶段是Human in the Loop，人需要跟Agent交互。第二阶段是Human on the Loop，人抽离出来，作为观测者看Agent执行，怎么去纠偏。

在第一阶段，当人需要参与Agent循环时，复杂任务执行偏的成本越来越高，因为它改的代码非常多，回退时影响很大。我们做了几个方面的探索：

在前置环节，一是任务澄清，我们跟这个方向叫"主动性"，希望Agent在执行任务或做计划之前，先了解清楚自己是不是真的理解了问题。当时我们做了探索，让Agent主动问我问题，当它不清楚的时候要不断问。后来发现社区的Superpower也有这个过程。二是计划，也就是SDD，希望在前置把计划做得更明确。我访谈过一些同学，他们甚至已经不去看写代码的过程了，但一定要看写计划的过程。在前置确认计划OK，最终代码因为现在Agent或模型比较强，基本也就没有太大偏差。

在后置环节，Agent写的代码越来越多，让人Review也变复杂了。我们做了两个探索：一是让代码变更可视化，让人更快Review；二是让Agent交叉Review，或者做测试计划并把测试结果执行出来做Verify。

第二阶段，人作为观察者，让Agent自我执行复杂任务。我们主要在加强做计划和做Research的能力，让Agent做出来的计划基本能完全一把过，写出来的效果在前置就有很好的把控。

还有一个中间探索：上下文窗口有限，如果不断往里塞东西会出问题。所以我们做了SubAgent的探索，在前置、后置以及中间执行环节里，让更合适的模型、更合适的Agent去做更合适的事情，一定程度上保证上下文不被浪费过多，信息不会太失真。

郑鑫祺：在小红书Vibe Coding场景，面向非研发群体，很多时候追求的是0 Code。0 Code的背后，在Human in the Loop情况下，更多是Shape Up理念的应用：先给一些模糊的东西，AI来问精准的问题，再给一个Demo，再往下跑。

在实践完了之后，到了真正产出质量的阶段，对于非研发或产品人员来说很难去纠正，这时候就需要模型去执行，所以这里有非常多的模型控制论和模型智能之间的Balance。模型智能在不断增加，但因为Context Length和Transformer的上限，上下文问题始终需要精细化控制和解决。这不是OpenClaw带来的AgentOS能解决的问题，它更多解决的是生态问题：让更低成本地融合Skill。但在模型控制的角度，还是需要更精细地把专家经验融入进去，变成一个Workflow。

在我们的实践中，小红书自研了整套上下文框架和Agentic体系，来保障每个关键决策和判断能被精细控制，各种Hook、各种纠正模型行为的手段，来保证质量达到90分甚至100分。但它一定会牺牲一些泛化性。这也是后续要解决的：先精再泛，在泛的过程中再去看如何利用好泛的Skill和精致的东西来编排精的流程。

对于Human in the Loop，背后更多是Shape Up理念在产品中的运用，即什么时候该问。Claude Code有时候问得非常打断人，有时候沟通几个小时，这不可接受。所以需要一个更好的设计哲学，定义流程让AI遵守，包括怎么更好地探索、什么时候不让AI说话、什么时候命中。这块如果要做精细，确实有很大投入。但模型在增长，这块始终是一个需要打磨的方向，让效果一直冲到100%。

张子天：现在很多企业已经开始遇到一个新问题：AI生成代码越来越多，但大家对代码的"信任感"反而在下降。比如：AI会自己造轮子、不遵守组件规范、安全边界不清晰、代码不可维护、上线风险越来越大。甚至很多团队开始担心："未来会不会产生大量AI技术债？"你们内部怎么看这个问题？

郑鑫祺：中小团队或AI Native型组织，给AI更多自主权，定期关注腐化走势、定期重构。大厂逻辑下，关键决策依然靠人，比如SDD确认是人来做决策，不是让AI直接往下跑，因为很多东西不可逆或成本很高，数据库塞乱了影响面就很大。长程任务要做更多Verify的精细制作，前端有UI比对，中间有TDD驱动开发，还有各种自动化测试。最后的CR环节是核心信任度——线上出了Bug都修不来了，因为对AI掌控度不够了。原来只看Diff的CR方式不够，需要更有追溯链的CR方式。但最终上线的Confirm一定是人来确认。

李京：现在有一种说法：Code is Cheap。以前是“Talk is Cheap,Show Me the Code”，但现在Talk也没那么Cheap了，你的想法表达、输入可能更重要。非严肃场景就看效果，代码可维护性基本不用看。严肃生产系统分三个角度：一是AI为什么写出烂代码？可能是没把代码规范和架构设计适配到它的角度，更前置地告诉Agent怎么写代码，烂代码的可能性就降低；二是写完代码让Agent交叉CR，用智能化Review校验；三是AI具备自我迭代能力，遇到Bug可以先自己改一轮。归纳为：架构设计提前告知AI；交叉Review；Agent自我迭代、Verify和Auto Fix。

郑鑫祺：要产出有品味的代码，还是需要架构师来定。你给它的Knowledge、Trade Off、Spec中的每个Choice，未来会被记忆住。同样的工具，外包同学和架构师使用的效果差距很大。优秀的人依然非常重要。

张子天：AI对人的能力放大效果非常明显，能力越强的人放大越多。

观众：我们现在如何去追踪和量化AI Coding研发项目中的问题？

李京：最早建立浅层指标如代码生成率、智能CR生成率等，但最终看的是哪些被真实采纳、真正起到效果。度量体系很重要。

郑鑫祺：指标要和阶段目标相关。推广期以渗透率和AI代码占比来看，用AI就认为拥抱AI。都用AI之后就要看速度和价值。速度就是人均吞吐，类似复杂度的需求原来排期五六天，估时降低了人没变，AI贡献就更大。价值方面，哪些Demo真正产出了有价值的东西。Valueless应用太多就很难平衡Token价值。还提出Benchmark驱动方式，按阶段拆二三级指标跟进与行业SOTA比较。

李京：内部有专门的架构治理组，在AI时代建立了工程架构度量体系，对架构质量评分，一定程度上防止了架构和技术劣化。快手的另一个探索是需求分层（L1-L4）：L2是Agent辅助；L3是Agent更多协同；L4是Agent端到端交付。不同层级有不同观测——L4希望AI端到端交付，把控指标更多看AI真正完成的效果和需求吞吐是不是真的变化。

张子天：今年特别火的一个方向是："非研发开始写软件。"产品、运营、设计、数据团队都开始直接用AI生成应用。但这也有很多争议：有人觉得这是未来，也有人觉得这只是Demo幻觉。非研发真的会成为AI Coding下一波最大的用户群吗？

李京：会，这件事正在发生。AI Coding本来为研发群体做的，但研发群体在少数，今年越来越多非研发涌入。社区里判断：Coding本质是软件的表达形式，是创作，就像写文字，创作软件未来会平权到每个人。我们甚至做了基础设施：AI写完代码做成Skill，跟企业内部登录系统打通，用泛域名提供域名，把静态文件和服务用Serverless跑起来，接云DB。运营用它做报名系统，财务做分析小系统，更多人把想法以网页表达出来。

郑鑫祺：硅谷很多人眼中未来Office就是Claude Code。OpenClaw火了后越来越多同学因AI扶持Builder出很多有价值的项目。小红书给非研发做了很多工具，包括我负责的Muse，直接创意后部署上线，有数据库、有AI。核心还是看谁能发现需求、了解用户、有品味判断力。技术人员在专精领域还是主体，但纯写代码要求会更高。

张子天：过去研发像"雕版印刷"，只有少数人识字、会编程。现在有了AI Coding就像"活字印刷术"，让更多人掌握了编排和印刷技术。

观众：小红书目前是怎么确保系统安全的？

郑鑫祺：最终上线和负责还是有人把控，不是AI直接发布。如果今天有AI直接发布，那一定是Demo，类似内部社区做内容，不是直接面向用户的。整个过程人的把控在小红书一直非常关注，不会直接上线。

李京：如果把Coding能力开放给大家，尤其做偏生产级系统，确实需要保障。数据安全方面，非专业计算机训练的人Sense没那么全面，危险操作（数据库、发布）、接支付、API对接出去都有风险。面向非研发的系统需要特别关注。除了安全还有成本，非研发人员Create或产出，ROI也需要衡量。

郑鑫祺：核心还是最终质量和安全依然由原来的人把控。AI帮非研发做自动化工具、做报告、数据分析，大家Build自己的助理，做Demo也能很快跑通，这块比较成熟。但要做大型应用，依然需要安全、数据等专家把关。

观众：在AI贡献率层面上，有没有比较好的办法精准评估？对于初创或刚转型做AI Coding的团队，怎么评估落地效果？怎么针对性提升？

郑鑫祺：本质是顶层指标拆解的逐步演进过程。关注工具渗透就埋渗透数据，关注使用效果就统计需求吞吐情况，更精细的包括采纳率、知识命中率等。

李京：在不同阶段看不同指标，从渗透到AI代码贡献，再到ROI和需求吞吐。快手还做了需求分层（L1-L4）：L2是Agent辅助，L3是Agent更多协同，L4是Agent端到端交付。不同层级有不同观测。

郑鑫祺：不同的L之间的Bar有没有很明确的定义？会不会有难以划分的问题？跟原来低代码有点像。

李京：确实会有这个问题。我们在做需求分级时经过了比较多的讨论，而且是拿着真实需求去拆解的。

郑鑫祺：这确实是大家都面临的问题：工具很多，需求到底用什么样的方式去推？很多时候中台认的L4方向，但演进过程中业务又要发展，一定会有一个渐进式推进的过程。有时这个需求是L2，过段时间工具成熟了可能变成L3或L4。需要业务架构师动态判断。

观众：AI Coding如果不需要初级程序员了，只有高级工程师的概念，如何从头去培养这样的人群？是不是要断层了？

李京：不会断层。AI来了之后能力边界变得很扩充。首先，初级和高级的分层开始模糊——跟AI不断对话中AI会给人很多启发，之前需要经验积累的知识AI一定程度上能补齐，但需要经验把控的地方还是有的。具备好奇心、动手能力、创意和分享能力的同学成长更快。其次，职能边界也开始模糊——程序员跟AI共创时可以写出竞品调研方案和PRD，用AI工具画出高保真原型，能力边界被很大扩充了。

郑鑫祺：不管初级还是高级，定义没那么重要了，可能就是个符号。在不同领域，品味、判断和创造力的内涵不一样——做大模型是技术判断，想做调酒小程序是要更懂那些人和需求。但有一点是肯定的：要以Builder的心态去看问题，要有好奇心。Hackathon里那些同学比较有这种Taste，有小创意自己去Build，快速学习、自我迭代。

张子天：好比汽车工业早期，驾驶者是少数。当自动挡和新能源车出现后，人人都会开车了。评判标准可能都已经变化，不是能力强弱的问题，而是分领域了。

张子天：现在企业面对AI Coding，还有一个特别现实的问题：外部生态的发展速度，已经远远超过企业内部自研速度。从Cursor、Claude Code、Devin，到OpenClaw、Harness、各种Agent平台，新的能力几乎每个月都在变化。很多企业现在都在纠结：到底应该自研、采购、还是做混合架构？企业内部已有研发体系，又该怎么和外部AI Coding生态融合？企业级AI Coding最核心的壁垒，到底是模型、工具，还是组织与系统能力？

郑鑫祺：Cursor、Claude Code等热门产品大部分是单兵控制面，核心设计是一个开发者在屏幕面前，AI帮他把活干快。这是以模型视角出发、以超级个体效率最大化为目标的方向。小组织、AI Native完全采购用社区方案就好。但企业级复杂协同场景下，一个需求提出到上线跨越多个系统、多个仓库、多个团队、多个云环境，模型公司的单兵工具天然不会碰这一层。需要自建知识和工具，使用社区方案去运用，实现生产关系和生产模式的进化。

李京：一人公司懂代码的，社区方案拿来直接用。创业团队看当前阶段目标，如果目标就是更快完成业务、更快赚钱，ROI能打正的情况下直接采购更好。大型组织自研有几个方向：一是Skill生态跟企业内部打通，构建成本不一定高但收益高；二是配套基础设施如知识工程；三是数据安全等红线，甚至需要模型层自部署。分场景、分阶段来看。

郑鑫祺：核心还是看你当下要解决什么问题。尤其针对非以研发产品为核心的企业，能自己做的部分越少越好，更多还是用好这个能力，提高企业产业效能。

3未来判断

张子天：如果站在2028年回看今天，你们觉得：AI Coding最终改变的，只是"程序员写代码"这件事，还是整个软件公司的组织形态？到那个时候，一个真正的AI Native企业会长什么样？

郑鑫祺：改变的已经不是软件公司了。Anthropic预测2026年有一人独角兽，现在已经出现了，不是终点是起点。到2028年不存在纯粹的软件公司，所有公司都是AI公司，区别是谁先想明白。改变的不是程序员，而是整个交付链条上每个角色存在的理由。但我还是认为有品味、有判断的人依然非常重要。AI和人的关系最多到Peer，现在可能是助理，但不应该是奴役人的方式创造价值。核心竞争力是你能不能先发现别人没发现的需求，更快创造价值、得到收入。

李京：变化是天翻地覆的。Anthropic一直说自己的代码90%以上是AI写的。组织形态肯定会变化，而且已经在发生，更闭环、更具创造力的组织，迭代空间更大。同理，即使在更远的以后，人的判断和品味也非常重要，能做出的作品还是不一样的。

郑鑫祺：模型上限还没完全Touch到，硅谷很多人认为预训练还有很大空间。但上下文长度没解决，这两年还是有很多上下文工程和场景工作要做，并不是AGI就出来了。人的关注点可能不是像以前钻在知识理性的逻辑链中，感性经济或被忽视的东西可能更重要。

李京：现在好模型成本还挺高。假如两年后基建和技术突破，模型成本降到极低，像SSD硬盘从很贵变成廉价基础设施，就像用电一样，更多改变会发生。消耗Token没那么心疼了，会大幅释放个人和组织的生产力和创造力。

郑鑫祺：如果是那个模式，企业形态可能要另论了。但目前模型成本依然高昂，ToC AI应用首先要解决价值和成本问题。软硬一体公司可以把推理成本融到硬件里，解决一个领域的精致化服务达到ToC扩张。不然更多场景还在ToB，因为这样才能算清ROI。

张子天：好比移动互联网时代早期，10块钱30兆流量，到现在10块钱可以买好几百个G。当Token费用单价足够便宜时，ToC应用反而会更爆发出来。