AI 代码生成率冲到 50%以上，研发周期却没变短；非研发人员开始用 Vibe Coding 写软件，但信任感在下降。AI Coding 都这么强了，在企业级开发中的应用到底卡在哪？
近日，InfoQ《极客有约》X AICon 直播栏目特别邀请贰贰壹咨询合伙人 &蜂量科技 CEO 张子天担任主持人，和小红书 AI Coding 总架构师郑鑫祺、快手 AI Coding 负责人李京一起，在 AICon全球人工智能开发与应用大会2026 上海站 即将召开之际，共同探讨 AI Coding 在企业落地中的真实难题。
部分精彩观点如下：
会用 AI 工具不等于个人提效，个人提效也不等于组织提效。
工具始终是手段，真正能达到整体吞吐量提升、人均效率提升、代码产量提升的，协作才是终点。协作系统不只是多个 Agent 并行，还包含人和 AI 之间协作关系的重构。
现在有一种说法：Code is Cheap。以前是“Talk is Cheap, Show Me the Code”，但现在 Talk 也没那么 Cheap 了，你的想法表达、输入可能更重要。
组织形态肯定会变化，而且已经在发生，更闭环、更具创造力的组织，迭代空间更大。
当 Token 费用单价足够便宜时，ToC 应用反而会更爆发出来。
在 6 月 26-27 日将于上海举办的 AICon全球人工智能开发与应用大会2026 上海站 上，我们特别设置了【Agent企业级研发体系的重构】专题。该专题将系统探讨如何将 AI 深度嵌入需求、架构、开发、测试与运维全流程，打造人机协同的新型研发范式。
查看大会日程解锁更多精彩内容：https://aicon.infoq.cn/2026/shanghai/schedule
以下内容基于直播速记整理，经 InfoQ 删减。
完整直播回放可查看：
行业现状与认知冲突
张子天：过去一年，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，要用更低成本把事做成。
企业级 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 生态跟企业内部打通，构建成本不一定高但收益高；二是配套基础设施如知识工程；三是数据安全等红线，甚至需要模型层自部署。分场景、分阶段来看。
郑鑫祺：核心还是看你当下要解决什么问题。尤其针对非以研发产品为核心的企业，能自己做的部分越少越好，更多还是用好这个能力，提高企业产业效能。
未来判断
张子天：如果站在 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 应用反而会更爆发出来。
会议推荐
6 月 26-27 日，AICon上海站即将开幕！60 + 顶尖专家携一线实战案例齐聚，聚焦构建可信赖、可规模化、可商业化的 Agentic 工程实践，一站式打通 AI 工程化卡点、从源头避坑！欢迎报名咨询👇
