AI写代码60% 研发效率为何不升反降？

AI 代码生成比例已突破 50%，研发周期却未见明显缩短；非技术人员借助 Vibe Coding 编写软件，但信任度反而下滑。AI Coding 能力如此强大，为何在企业级开发中迟迟难以规模化落地？

近日，小红书 AI Coding 总架构师郑鑫祺与快手 AI Coding 负责人李京展开深度对话，聚焦这一核心痛点。以下是从对谈中提炼出的关键认知。

• 会调用 AI 工具并不等于个人效率提升，个人效率提升也不等于组织效率提升。
• 工具只是路径，真正实现全局吞吐增长、人均效能跃升、代码产出激增的，是协作体系的变革。协作系统不仅涉及多 Agent 并行，更关乎人与 AI 之间分工与交互关系的重新设计。
• 当前流行一种观点：Code is Cheap。过去讲“Talk is Cheap, Show Me the Code”，但现在 Talk 也不再廉价——想法表达与输入质量或许比代码本身更关键。
• 组织形态必然重塑，且已在发生。更闭环、更具创造力的组织，迭代空间显著更大。
• 当 Token 单价足够低廉时，ToC 应用将迎来真正的爆发期。

行业现状与认知冲突

张子天：过去一年，AI Coding 的热度已从“尝鲜”迈入“大规模落地”阶段。但许多企业面临相同困境：AI 代码生成率持续走高，需求交付效率却未能同步提升。企业 AI Coding 当前的瓶颈到底在哪里？

李京：快手从 Copilot 阶段开始探索智能化提效，经历了代码续写、Agent 多文件生成，再到 SDD 驱动复杂任务。续写时期，AI 代码贡献率仅为个位数；Agent 阶段跃升至 20%-30%；今年已达 50%-60%。但问题随之浮现：工程师体感效率提升 40%，研发周期却几乎没有压缩，个人承接需求数与组织吞吐量也无显著增长。核心洞察是：会用 AI 工具 ≠ 个人提效，个人提效 ≠ 组织提效。症结分三个层面：组织层面仍沿用传统产研团队模式；协同层面，上下文在传递中持续流失；知识层面，业务知识、领域知识、研发知识未能有效沉淀与打通。

郑鑫祺：AI 生成能力本身基本过关，主要卡点在验证环节和前期对齐。生产力被拉高，但交互链条的其他环节并未同步跟进。第二个问题是组织协同——个人因 AI 变快，但整体组织效率是否适配原有传递链条，需要重新审视。第三点，大型分布式系统在过去过度微服务化与中台化，导致研发环境分散，需要工程治理与模型能力相互配合才能解决。

李京：我们经历了几个阶段：AI First 阶段是人主动应用 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 中的知识与记忆体系。

郑鑫祺：目前每个人在单仓中已沉淀了大量知识，包括 Code Graph、PRD、各种总结。关键缺口在于如何提升 SDD 模式中 Spec 的质量，以及降低对话成本。花两小时对齐 Spec 再加一小时 CR，和熟练工程师直接上手相比，效率并无明显优势。Spec 质量方面，更核心的是记忆迭代与关键记忆的抽象。早期推动缺乏指标牵引，大家都在整理资料，最终指标才是最关键的东西。

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

张子天：二位讲的内容都是企业已在实践的，且建立在强大的已有 Knowledge 基础之上。对于中小团队，落地难度更大——他们很难找到既能深入业务、又能将不同模块与业务场景梳理到一起的架构人才。中小团队大多直接铺在业务上，针对某个需求、某个 Feature、某个单点系统开展工作。不知二位对中小团队有何建议？

郑鑫祺：中小团队反而有更成熟的方案可直接使用。大厂因历史技术债与过度设计的系统，需要花更多时间建设“航空母舰”。中小团队系统架构更贴近社区，Claude Code 加 Harness 体系本身就 Work，纳入速度更快。但核心要关注效果优先——做了很多 Knowledge，效果没有变化，那就陷入了“赛博精神病”状态。Spec 对焦轮数、采纳率等指标要持续追踪，以此反向推动知识沉淀。

李京：中小团队落地反而更快速。社区里有 Claude Code、OpenCode、各种 Agent 和 Harness，买几个 Token Plan 就能有效运行。即使在大企业，优秀实践也是将大组织拆成小团队，通过 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，或生成测试计划并执行验证。

第二阶段，人作为观察者，让 Agent 自主执行复杂任务。我们主要强化 Agent 的计划与研究能力，使其生成的计划基本能一次性通过，输出效果在前置阶段就能很好把控。

还有一个中间探索：上下文窗口有限，持续塞入内容会导致问题。因此我们引入 SubAgent，在前置、后置以及中间执行环节中，让更合适的模型或 Agent 做更合适的事，一定程度上减少上下文浪费，避免信息失真。

郑鑫祺：在小红书 Vibe Coding 场景中，面向非研发群体，很多时候追求 0 Code。0 Code 的背后，在 Human in the Loop 情况下，更多是 Shape Up 理念的应用：先给模糊概念，AI 提出精准问题，再给 Demo，逐步迭代。

实践完成后，进入产出质量阶段，非研发或产品人员很难自行纠偏，此时需要模型去执行。这里面有模型控制论与模型智能之间的平衡。模型智能持续增强，但受 Context Length 和 Transformer 架构上限影响，上下文问题始终需要精细化控制。这不是 OpenClaw 带来的 AgentOS 能解决的——它解决的是生态问题，即低成本融合 Skill。但在模型控制方面，仍需将专家经验精细融入 Workflow。

在我们的实践中，小红书自研了整套上下文框架与 Agentic 体系，确保每个关键决策与判断可被精细控制，通过各种 Hook 和纠正模型行为的手段，将质量稳定在 90 分甚至 100 分。但这必然牺牲部分泛化性。后续方向是：先精再泛，在泛化过程中利用泛化 Skill 与精致流程编排出更高效的路径。

对于 Human in the Loop，背后更多是 Shape Up 理念在产品中的运用，即何时该提问。Claude Code 有时过度打断用户，甚至持续沟通数小时，这不可接受。因此需要更好的设计哲学，定义流程让 AI 遵守，包括如何探索、何时保持沉默、何时触发询问。如果要做得精细，确实投入巨大。但模型在不断进步，这块始终是需要打磨的方向，让效果持续逼近 100%。

张子天：现在很多企业开始遇到一个新问题：AI 生成代码越来越多，但大家对代码的“信任感”反而下降。例如：AI 会自己造轮子、不遵守组件规范、安全边界模糊、代码不可维护、上线风险攀升。甚至不少团队担忧：“未来会不会产生大量 AI 技术债？”你们内部如何看待？

郑鑫祺：中小团队或 AI Native 型组织，可以给 AI 更多自主权，定期关注架构腐化趋势并重构。在大厂逻辑中，关键决策仍由人把控，比如 SDD 确认必须由人决策，不允许 AI 直接执行，因为很多操作不可逆或成本高昂，数据库混乱会带来巨大影响。长程任务需要更精细的 Verify 机制：前端 UI 比对、中间 TDD 驱动、各类自动化测试。最后的 CR 环节是信任核心——线上出 Bug 后如果无法修复，说明对 AI 的掌控力不足。传统只靠 Diff 的 CR 方式已不够，需要更完善的追溯链。但最终上线确认一定由人完成。

李京：现在流行一种说法：Code is Cheap。过去是“Talk is Cheap, Show Me the Code”，但现在 Talk 也不再廉价——你的想法表达与输入可能更关键。非严肃场景只看效果，代码可维护性可忽略。严肃生产系统需从三个角度应对：一是 AI 为何写出烂代码？可能是代码规范与架构设计未前置融入，提前告知 Agent 怎么写，烂代码概率就会降低；二是代码完成后让 Agent 交叉 CR，用智能化 Review 校验；三是让 AI 具备自我迭代能力，遇到 Bug 先自行修复一轮。归纳下来就是：架构设计提前告知 AI；交叉 Review；Agent 自我迭代、验证与自动修复。

郑鑫祺：要产出有品味的代码，仍然需要架构师来定调。你给它的 Knowledge、Trade Off、Spec 中的每个 Choice，未来都会被记忆。同样的工具，外包同学与架构师的使用效果差距显著。优秀的人依然至关重要。

张子天：AI 对人的能力放大效应非常明显，能力越强的人放大倍数越高。

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

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

郑鑫祺：指标需与阶段目标对齐。推广期看渗透率与 AI 代码占比，用 AI 就视为拥抱。全面使用后，关注速度与价值。速度即人均吞吐，相似复杂度的需求原来排期五六天，估时降低但人力不变，AI 贡献就更大。价值方面，看哪些 Demo 真正产出有价值的东西。无价值应用太多，会难以平衡 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 运行静态文件与服务，连接云数据库。运营可以用它做报名系统，财务可以做分析小系统，更多人能将想法以网页形式呈现。

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

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

观众：小红书目前如何确保系统安全？

郑鑫祺：最终上线与负责仍由人把控，AI 不会直接发布。如果有 AI 直接发布，那一定是 Demo，比如内部社区做内容，而非面向用户。整个过程中人的把控在小红书始终受重视，不会直接上线。

李京：如果将 Coding 能力开放给所有人，尤其是做偏生产级的系统，确实需要保障。数据安全方面，未受过专业训练的人，安全意识不够全面，危险操作（数据库、发布）、接入支付、API 对接都潜藏风险。面向非研发的系统需要特别关注。除安全外还有成本，非研发人员创建或产出的 ROI 也需要衡量。

郑鑫祺：核心是最终质量与安全仍由原有人把控。AI 可帮助非研发人员做自动化工具、报告、数据分析，大家构建自己的助理，做 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 生态与内部打通，构建成本未必高但收益显著；二是配套基础设施，如知识工程；三是数据安全等红线，甚至需要模型层自部署。需要分场景、分阶段来看。

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

未来判断

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

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

李京：这个变化是天翻地覆的。Anthropic 一直声称自己代码的 90% 以上由 AI 编写。组织形态必然会变化，而且已经在发生，更闭环、更具创造力的组织，迭代空间会更大。同理，即使在更远的未来，人的判断与品味也非常重要，能做出的作品依然不一样。

郑鑫祺：模型的上限尚未被完全触及，硅谷很多人认为预训练还有很大潜力。但上下文长度的问题尚未解决，未来两年仍会有大量上下文工程与场景工作要做，并非 AGI 马上到来。人的关注点可能不再是像以前那样深陷理性逻辑链，感性经济或那些长期被忽视的东西，可能会变得更加重要。

李京：目前高质量模型的成本依然较高。假如两年后基建与技术突破，模型成本降到极低，就像 SSD 从昂贵变为廉价基础设施，像用电一样，更多改变将发生。消耗 Token 不再心疼，这将大幅释放个人与组织的生产力和创造力。

郑鑫祺：如果是那种模式，企业形态可能又需要另论。但目前模型成本依然高昂，ToC AI 应用首先要解决价值与成本问题。软硬一体的公司可将推理成本融入硬件，在某个领域提供精致化服务，实现 ToC 扩张。否则，更多场景仍会落在 ToB，因为只有 ToB 才能算清 ROI。

张子天：这就像移动互联网时代早期，10 元只能买 30 兆流量，到现在 10 元可买几百个 G。当 Token 单价足够便宜时，ToC 应用反而会爆发得更猛烈。

企业级 Agent 落地，绕不开 4 个真实的工程问题。如何在 Agent 安全性与可用性之间找到平衡点？Agent 需要什么样的记忆系统才能真正理解上下文？如何通过算法压榨实现智力增量与成本控制的极致平衡？多 Agent 协作，如何做到可观测、可治理、可控制？国内的头部公司，已经在这些方向上给出了自己的实践答案。