大多数 AI 分享聚焦于全新项目里的“惊艳演示”——用 Vibe Coding 快速做出 PoC。但真实的企业级工程完全不同：庞大的遗留代码库、数百万高质量期望的企业客户、每两周一次的稳定交付。在这样的场景里，AI 带来的往往不只是速度，还有被忽视的隐性成本：代码产出激增，而人的评审带宽有限，评审变浅、技术债悄然累积，最终质量下滑、客户受损、团队疲惫。

本次分享来自一线真实工程实践，讲述我们如何面对并“偿还”这笔隐性成本：为携带大量历史债务的项目设定正确预期，用反馈闭环守住质量，用持续重构控制技术债，再用确定性的自动化关卡真正释放研发速度。我们还会分享数据驱动决策、"模式思维"这一最被需要的能力，以及多个 AI 融入日常工作的真实案例。

演讲提纲

1. 概览：规模、包袱与质量约束

2. AI 提速的隐性成本：为什么"更快"会变成"更贵"

• 核心框架：守质量 → 控债务 → 提速度
• 守住质量：建立反馈闭环

3. 与 AI 一起做数据驱动决策：观察—分析—决策—行动

• 控制技术债：一致性、显式性与持续重构
• 释放速度：把确定性关卡尽可能前置到流水线

4. 案例：AI 如何融入工程师与管理者的日常

实践痛点

• AI 的瓶颈不是算力，而是人。 智能体工作流必须尊重“人在环路”中有限的评审带宽，否则质量崩塌
• 携带历史包袱的项目需要正确的预期。 隐性成本必须先被承认、再被偿还，才能谈提速
• 质量要靠闭环守住，不能靠人海。 测试覆盖、Dogfooding、遥测与客户反馈共同构成安全网
• 技术债要持续偿还。 当问题形成模式，就该重构甚至重写，并把范例前置给 AI 复用
• 速度靠自动化关卡释放，而非施压于人。 把确定性检查前置到流水线，把人从重复劳动中解放出来

前沿亮点

• 真实的大项目，而非全新项目： 企业级代码仓库、百万高标准企业客户——不是 Vibe Coding 的 PoC
• 质量是硬约束： 在高标准场景下，失控的 AI 往往制造的问题多于价值——这正是最少被谈及、却最真实的一面
• 可复用的方法论： "守质量—控债务—提速度"三段式框架，以及可落地的数据驱动决策闭环
• 全部源自一线实践： 每条经验都来自持续交付的真实产品，而非演示

听众收益

• 一套在历史包袱、高质量约束场景下引入 AI 的可复用框架，而不仅是演示技巧
• 如何识别并偿还 AI 提速带来的隐性成本，为团队设定正确预期
• 守住质量的具体工程实践：反馈闭环、数据驱动决策、持续重构、确定性自动化关卡
• "模式思维" 这一关键能力，帮助从看似无关的问题中提炼共性并系统性解决

2026 年，AI 落地竞争焦点从单点试点转向规模化编排与组织重塑。平安集团探索“工程筑基 + 组织重塑”双线路径：工程上通过系统 AI Ready 与先进生成工具，锻造团队级数字工程师；组织上将传统岗位分工转变为精益团队，落地 OPC（一人公司）模式。先行团队交付周期从月缩短到周，端到端交付效率提升 50 %。本次分享完整呈现双线演进、真实 trade off 与可复制经验。

演讲提纲

1. 背景：AI 落地进入深水区

• 单点提效在大型金融集团走不远——系统高熵、能力零散、协同低效。从“工具接入”走向“组织级编排”是必答题。

2. 工程线：锻造团队级数字工程师

• 系统 AI Ready
  • 知识蒸馏 + 测试补全，将高熵遗留系统转化为低熵、可验证、可驱动的团队级 AI 底座
• 先进生成工具
  • 团队级数字工程师底座
  • 目标驱动架构（MOA + Graph）：明确业务目标状态，让数字工程师从“执行任务”转向“达成目标”  
  • 金融级治理：全链路数据闭环、模型与资产中心，保障规模化可控

3. 组织线：精益化与 OPC 落地

• 团队形态重塑
  • 原有大量跨前后端 + 质量的岗位分工，转变为“少量人 + 数字工程师”的精益混合团队
• OPC 落地
  • 精益团队以一人公司模式运行，通过原型驱动、敏捷迭代，直接对可衡量业务结果负责

4. 效果

• 先行团队交付周期从月缩短到周，端到端交付效率提升 50%

5. 反思：规模化的真实代价与应对

• 知识蒸馏前期投入、多 Agent 协调成本、人机信任张力、组织变革阻力——踩过的坑与应对策略

实践痛点

• 高熵系统改造的前期投入巨大：知识蒸馏与测试补全需要大量业务专家与技术专家深度介入，才能把碎片化、隐性知识结构化。短期可能拖慢交付节奏，长期才真正释放价值。这是大型金融集团遗留系统多、知识分散的必然代价
• 多 Agent 协同带来的协调成本与错误放大风险：MOA + Graph + Loop 虽然能实现目标驱动，但 Agent 之间的通信、状态同步和反馈循环会显著增加 Token 消耗与延迟。业界已有研究指出，无结构的多 Agent 容易出现错误放大（甚至达到 10 倍以上）。简单任务如果强行上复杂 Graph，反而得不偿失
• 人机信任与治理的持续张力：即使有理想态约束和数据闭环，金融场景下仍需强人机审核环节。数字工程师的输出质量再高，也难以完全替代人类对合规、风控的最终判断。同时，团队级数字工程师大规模落地后，容易出现“ Agent Sprawl ”（代理泛滥），带来治理、审计与成本不可控的风险
• 组织与流程重塑的阻力：真正发挥团队级数字工程师价值，几乎需要重塑现有研发流程与角色分工（人从执行者升级为“数字军团指挥官”）。文化惯性、考核机制、跨部门协同都会成为落地阻力

演讲亮点

• 团队级 + 目标驱动的深度工程化：不同于个人 IDE 助手（如 Cursor 等）或通用多 Agent 框架，我们把团队级数字工程师与 MOA + Graph + Loop 架构深度结合，从“帮你执行任务”明确升级为“帮你达成目标”。Graph 提供结构化流程与状态管理，Loop 实现持续自我修正，MOA 汇聚多专家能力，三者协同解决了业界常见的“上下文碎片化（80% 问题）”和“目标漂移”问题，并完全适配集团内部研发流程
• 系统 AI Ready 的可落地路径（降低高熵系统）：我们把“系统 AI Ready ”明确定义为通过知识蒸馏 + 测试补全降低系统熵，而不是简单接入工具。这一工程化路径直接解决了大型金融集团知识碎片化、可验证性差、跨系统依赖不可见等核心痛点，同时内置金融级安全管控（网络隔离、外发代码管控、容器围栏等），在保证安全合规的前提下实现团队级 AI 能力下沉

听众收益

• 系统 AI Ready + 先进生成工具的工程化路径  
• 从岗位精益化到 OPC 的组织转型方法  
• 大型金融集团规模化落地的真实经验与避坑要点

进入 2026 年，企业在 AI Token 和工具上的投入持续增长。对于大型研发组织，问题已经不是“有没有使用 AI”，而是这些投入能否缩短交付周期、改善质量，并转化为组织效能。传音拥有大量历史业务信息、复杂存量系统和技术债务，无法推倒重来，只能在保障交付和质量稳定的同时逐步改造。本次分享聚焦 AI 从 L2 流程嵌入走向 L3 Agent 驱动的关键阶段，介绍传音如何自上而下规划精品 Agent、自下而上培养超级个体和涌现领域 Agent，如何用知识与 Harness 支撑业务交付流和质量改进流，以及如何通过任务吞吐量、质量结果和人效判断 AI 提效是否真正有效。

演讲提纲

1. 为什么单点变快了，整体交付没有同步变快

• AI 已经在文档、设计、编码和故障分析等环节产生局部效果，但当任务跨越产品、设计、开发和测试等多个职能后，瓶颈往往转移到信息解释、评审等待、任务交接和质量返工上
• 对千人级研发组织来说，从 L2 走向 L3，组织和协作方式的影响大于技术本身。整体思路可以概括为：组织提效 = 超级个体 × AI 杠杆 ÷ 协作摩擦

2. 组织层面：怎样让一千多人真正开始改变

• 一方面，自上而下从业务交付流和质量改进流中选择高价值任务，明确 Agent 的输入、输出和验收标准，由平台团队建设通用能力
• 另一方面，从一线选择种子选手，通过真实项目培养能够拆解任务、调动知识和多个 Agent、判断输出质量的超级个体。再由超级个体、领域专家和平台人员组成内部 FDE 小队，从现场沉淀领域 Agent、Skill 和规则
• 自上而下规划的 Agent 与一线涌现的 Agent，通过统一的知识边界、工具权限、验收方式和人工接管标准进行对齐。组织机制上，既让沉淀可复用能力、主动分享并带动他人的成员获得更多发展机会，也通过任务周期、质量结果和上下游效率变化传递转型压力

3. 技术层面：Agent 怎样进入研发流程

• Agent 需要两部分信息：一部分是需求、项目、代码、测试、缺陷和版本等业务数据，由现有 SaaS 系统持续更新；另一部分是产品规范、Review 规则、测试策略、故障案例和专家经验，在知识平台、结构化研发产物、Harness 和 Agent/Skill 之间不断修正
• 业务交付流从洞察、PRD、SDD/Spec、设计、Demo 延伸到编码和交付，重点减少上下游重复理解和人工转译。特性树用于组织业务范围和价值点，并检查需求及产物覆盖情况
• 质量改进流从编码、Code Review、Test、故障分析、根因分析回到修复。Issue 覆盖稳定性、性能、功耗、通信、三方应用和业务应用等类型，通过故障树分类分层；再用 Harness 约束 Review，收敛测试范围，持续调整测试 Case，并通过视觉、功能和日志结果验收

4. 度量与规模化：最后回到任务结果

• 目前部分场景已经出现明确变化：PRD 辅助生成由约1周缩短到1天；某前后端 MVP 的研发投入由80人日降至25人日，整体周期缩短63.6%；三方应用六类场景的根因分析准确率达到80.7%，样本为150单
• 这些数据只能证明局部场景有效。进一步需要以真实任务为单位，观察任务吞吐量、交付周期、一次通过率、Issue 覆盖、根因准确率、测试投入和人均任务承接量。目前正在通过 Multica 等平台补齐任务过程观测
• 同时，将能够参与端到端 AI 任务的超级个体占比作为组织能力指标，H2 目标是在重点业务线的目标人群中逐步提升到 30% 以上。只有稳定改善任务结果的 Agent、Skill 和工作方式，才向其他业务线复制

实践痛点

• 任务划分和拆解的口径
• 统计维度和能力建设投入不足
• 内部 FDE 组织建设和实施难度

演讲亮点

• 在存量大型研发组织中牵引AI提效落地，我们多数在单点/单场景提效，对于商业企业而言这是远远不够的，我们需要让 AI 提效的成果显性化和体系化

听众收益

• 了解千人级研发组织如何启动和运行 AI2D 提效实践
• 掌握自上而下规划 Agent、自下而上涌现 Agent，以及培养超级个体和组建 FDE 小队的方法
• 理解业务数据、研发经验、特性树、故障树和 Harness 如何进入真实研发流程
• 了解如何通过任务吞吐量、交付周期和质量结果，判断 AI 提效的实际价值

当 AI 让一个人能够完成过去需要多个角色协同的工作时，组织设计的前提也开始变化。我认为，AI Native 组织的原则是“非必要不协作”：优先让个人和小团队完成业务闭环，再引入必要的协作。本次分享将结合大模型公司的实践，讨论这一原则如何落地：业务与组织如何微服务化，Builder 与 Operator 如何分工，以及管理者如何从协调执行转向管理 Context 与 Outcome。

演讲提纲

1. 为什么 AI 改变的是组织，而不仅仅是工具

• AI 扩大了个人的能力边界
• 岗位、流程和组织边界需要随之调整

2. 第一原则：非必要不协作

• 优先独立闭环，减少交接、等待和反复对齐
• 根据业务需要判断协作的必要性

3. 边界怎么划：业务与组织的微服务化

• 围绕完整业务结果划分单元
• 明确输入、输出和责任，支持自主执行

4. 责任怎么分：Builder 与 Operator

• Builder 构建能力，Operator 运行业务、负责结果
• 同一个人或小团队可以兼具两类责任，形成闭环

5. 管理怎么做：Context 与 Outcome

• Context：共享目标、背景和约束，让人能够自主判断
• Outcome：明确结果、标准和反馈，让自主执行保持方向一致

实践痛点

• 协作成为默认动作，交接与沟通挤压交付时间
• 个人能力边界扩大，岗位、权限和考核没有跟上
• 管理仍依赖过程协调，缺少支持自主执行的机制

演讲亮点

• 新原则：从优化协作效率，进一步追问协作是否必要
• 新分工：用 Builder 与 Operator 连接能力建设和业务结果
• 新管理：用 Context 与 Outcome 支撑个人和小团队自主闭环