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

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 删减。

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 真正完成的效果和需求吞吐是否真的变化。