活动特惠
论坛主席：马洪喜
拥有二十五年软件产品研发和管理经验，二十年云计算领域专业经验。曾在Oracle,Citrix,Rancher等公司担任技术领导职务。是信通院云原生成熟度模型、云上开发等相关技术标准制定的参与者，并连续十年获得微软最有价值专家MVP称号。目前研究的方向是企业场景全云化AI智能研发平台工程技术。
行云创新CEO
AI+研发效能10X提升
本论坛聚焦AI驱动的研发效能革命，致力于实现工程团队的生产力10倍跃升。论坛涵盖效能度量体系、AI辅助决策、自动化工作流、团队协作优化等核心技术。通过深入探讨从"生码率"到"价值率"的度量转型、AI赋能的敏捷实践、规模化效能提升等关键议题，我们将共同见证研发效能从"线性增长"向"指数级突破"的质变，打造AI时代的高效能工程组织。
AI 时代的智驾质量工程：从数据驱动到闭环验证
周小莉
某OEM高级经理
内容简介：
智能驾驶软件研发正从数据驱动迈向AI驱动，但需求到交付的流转仍依赖人工传文件、本地从零开发，经验随人走，质量难以闭环。本次分享将深入剖析如何以飞书项目AI工作流串联需求架构→开发→PR合入核心环节，通过多Agent协作实现“节点自动流转、拿到即初稿、结果自动回填”的闭环验证机制。内容将重点介绍三层架构设计、三个Agent角色定义与协作协议，并以remote模块为示例展示真实验证数据——端到端流转成功率100%、全流程耗时仅15.3分钟。通过实践复盘，揭示AI工作流如何将单点提效升级为组织级质量工程能力。
演讲提纲：
1.困境：智驾研发的“质量交付鸿沟”
1.1智驾软件复杂度的指数级攀升
1.1.1智驾算法历经规则驱动→数据驱动→模型驱动，软件规模与依赖关系呈指数增长
1.1.2需求→架构→开发→测试→合入，跨角色、跨阶段协同成本远超单一大模型的处理边界
1.1.3结合remote模块迭代中的实际情况：若干条需求涉及ipd1/ipd2双变更平台、多代码仓依赖，单环节切换即可产生数小时等待
1.2当前研发流程的三个断裂
1.2.1流转断裂：上下游全靠人工传文件、人工通知、人工确认——文件在需求→架构→开发→合入各环节间手动传递，占用大量精力，过程无存档、事后难追溯
1.2.2启动断裂：每个环节拿到上游产物后，要在本地重新打开Agent、配置文件、再跑一轮才能开始真正工作——每次从零开始，已有模板和经验无法复用
1.2.3经验断裂：流程高度依赖个人经验和习惯，判断依据散落在个人操作记录中，无法转化为团队可复用的流程资产——同类工作每次重推，团队能力随人员流动波动而非随运行次数积累
1.3为什么单点AI工具无法解决？
1.3.1代码生成Skill已覆盖部分环节，但仍依赖人工按需触发、碎片化调用，缺乏自动化闭环流转
1.3.2上下文无法跨任务持有：单次会话无法承载完整研发状态，需求意图→架构约束→代码实现之间的追溯链断裂
1.3.3知识无法持久沉淀：每次会话结束后，专业经验无法留存，无法实现跨任务的边际效应
2.重构：以AI工作流构建闭环质量工程
2.1核心理念：不是新造工具，是把现有能力串成流水线
2.1.1各角色日常已在使用的Skill和开发范式保持不变，通过飞书项目AI工作流将其接入节点
2.1.2飞书项目负责流程流转，AAMP负责任务投递，本地Agent负责执行，CLI负责结果回填
2.1.人从“流程的推动者”变为“结果的确认者”
2.2四层解耦架构设计
2.2.1触发层：飞书项目节点作为任务流转入口，状态变化触发对应AI节点
2.2.2调度层：AAMP接收节点任务，投递给指定Agent，回传状态回执
2.2.3执行层：本地Agent根据任务上下文执行具体工作（文档生成/代码提交/审核比对）
2.2.4回填层：Meego CLI + 飞书CLI读写工作项、回填字段、更新文档、推进节点
2.2.5事件驱动、异步执行：Webhook触发，各层通过标准协议通信，实现解耦集成
2.3三个Agent角色定义与协作协议
2.3.1需求架构Agent（V左构建）
2.3.2开发Agent（V左构建→V右验证桥接）
2.3.3PR合入Agent（V右验证）
2.4“五有”闭环设计原则
有输入：任务来源、字段、文档链接明确
有执行：Agent根据上下文完成具体工作
有回填：结果写回Meego字段或飞书文档
有反查：回填后确认结果已成功落库
有兜底：失败或信息不足时自动停止并通知负责人，支持回退普通流程
3.实战：remote模块端到端闭环验证
3.1验证策略：选择remote模块先行
3.1.1remote属于L4主线，相对独立、需求较简单，适合快速上线验证效果
3.1.2覆盖ipd1/ipd2双变更平台，若干条真实需求样本
3.2端到端流程全景
3.2.1SRS需求文档 → 需求架构Agent生成cc-read）→ 开发Agent生成代码提交test分支→ 人工审阅修改提交MR → PR合入Agent比对审核→ 通过后合入、字段回填、节点自动流转
3.2.2核心逻辑：每个节点的“完成”不仅指Agent执行结束，更要求结果已成功回填系统、完成文档沉淀和状态反查
3.3真实面对的不完美与改进方向
3.3.1部分场景失败报错不明晰→ 加强报错提示、Agent报错通知开发人
3.3.2开发Agent代码仓限定问题→ 完善仓库分支拉取逻辑
3.3.3需求臆造→ AI节点必须通过负责人校验才可流转，日志可追溯
4.迭代：从“串起来”到“跑得好”——质量闭环的持续进化
4.1两级循环结构
4.1.1Outer Loop（业务级） ：飞书项目流程/AAMP驱动——节点触发、任务投递、字段回填、反查确认、节点流转；失败进入failed/need_help人工兜底
4.1.2Inner Loop（Agent级） ：每个Agent内部的质量循环——需求架构Agent采用“生成→独立评审→修订→批准”；开发Agent采用“检查失败时定向修复”，不做全量重跑
4.2Harness工程：工具、知识、权限即配置
4.2.1工具与上下文即配置：每个Agent的可用工具（CTS/文档模板/代码仓/Skill/Git/CLI）与本地知识库（AGENT.MD/规则/历史经验）作为配置维护，随版本迭代
4.2.2权限即边界：Harness配置直接实现动作边界——只新建文档/只提交test分支/只读拉取；日志可追溯，无越权行为
4.2.3知识可追溯：使用时记录文档链接和时间信息，可追溯知识版本
4.2.4日志留痕：记录输入、输出、报错、回填结果，可拉取、可定位
4.3准出量化体系
4.3.1双维度准出标准：流程量化 × Agent配置量化
4.3.2指标看板：记录每次运行是否成功、人工接管率、响应时间、token消耗、命中Skill、bad case
4.3.3bad case回流机制：区分“流程可跑通问题”（针对节点AI配置修改）与“Agent配置问题”，记录→修复→版本迭代
4.3.4复盘节奏：初期每日复盘、后期每周复盘，由业务责任人与各Agent技术责任人跟进
5.洞见：从单点提效到组织质量工程
5.1成本节约的三层算账法
5.1.1第一层：人力流转成本节省
5.1.2第二层：错误率降低与返工减少——状态漏更新、PR漏合/错合、需求漏读、代码规范返工的系统性减少
5.1.3第三层：规模化复用价值
5.2落地挑战与应对
5.2.1Agent行为不确定性：需求臆造（7%）、判断可能无依据 → 关键动作边界定义为只读/仅建议/需审批，每动作责任归属明确，AI节点必须通过负责人校验才可流转
5.2.2任务运行中断：电脑息屏或切换页面导致进程暂停 → 梳理影响任务顺畅执行的核心因素（息屏/切后台/网络），推动飞书优化调整
5.2.3权限风险：lark cli存在权限风险 → 统一在组内L4知识库维护CTS/需求文档，通过目录及子目录权限继承机制实现自动化配置；新增“需求创建”节点需求文档md字段
5.2.4知识版本漂移：知识库随时间更新，产出难以对账 → 使用时记录文档链接和时间信息，可追溯知识版本
5.2.5失败不可感知：部分场景报错不明晰 → 加强报错提示，Agent报错通知开发人；bad case回流修复
5.3核心洞见：让能力随流程增长，而非随人流动
5.3.1传统模式：专家做得好→专家走了带走了→新来的人从头学→团队能力剧烈波动
5.3.2 AI工作流模式：每次运行沉淀一条经验→知识库越来越厚→新需求触发时自动复用→团队能力随运行次数持续增长
5.3.3智驾质量工程的本质正在从“管好人”转向“经营好流程” ——用流程承载知识，用AI放大人的判断力
6.展望
6.1从“好模型”走向“好系统”：通过工程化手段保障系统的稳定性、可扩展性与安全性
6.2Agent能力从单点工具演进为全流程协作智能体，覆盖需求→架构→开发→测试→交付全链路
6.3输出可推广的工程化最佳实践：为行业提供AI工作流重塑质量工程的可借鉴经验
1.困境：智驾研发的“质量交付鸿沟”
1.1智驾软件复杂度的指数级攀升
1.1.1智驾算法历经规则驱动→数据驱动→模型驱动，软件规模与依赖关系呈指数增长
1.1.2需求→架构→开发→测试→合入，跨角色、跨阶段协同成本远超单一大模型的处理边界
1.1.3结合remote模块迭代中的实际情况：若干条需求涉及ipd1/ipd2双变更平台、多代码仓依赖，单环节切换即可产生数小时等待
1.2当前研发流程的三个断裂
1.2.1流转断裂：上下游全靠人工传文件、人工通知、人工确认——文件在需求→架构→开发→合入各环节间手动传递，占用大量精力，过程无存档、事后难追溯
1.2.2启动断裂：每个环节拿到上游产物后，要在本地重新打开Agent、配置文件、再跑一轮才能开始真正工作——每次从零开始，已有模板和经验无法复用
1.2.3经验断裂：流程高度依赖个人经验和习惯，判断依据散落在个人操作记录中，无法转化为团队可复用的流程资产——同类工作每次重推，团队能力随人员流动波动而非随运行次数积累
1.3为什么单点AI工具无法解决？
1.3.1代码生成Skill已覆盖部分环节，但仍依赖人工按需触发、碎片化调用，缺乏自动化闭环流转
1.3.2上下文无法跨任务持有：单次会话无法承载完整研发状态，需求意图→架构约束→代码实现之间的追溯链断裂
1.3.3知识无法持久沉淀：每次会话结束后，专业经验无法留存，无法实现跨任务的边际效应
2.重构：以AI工作流构建闭环质量工程
2.1核心理念：不是新造工具，是把现有能力串成流水线
2.1.1各角色日常已在使用的Skill和开发范式保持不变，通过飞书项目AI工作流将其接入节点
2.1.2飞书项目负责流程流转，AAMP负责任务投递，本地Agent负责执行，CLI负责结果回填
2.1.人从“流程的推动者”变为“结果的确认者”
2.2四层解耦架构设计
2.2.1触发层：飞书项目节点作为任务流转入口，状态变化触发对应AI节点
2.2.2调度层：AAMP接收节点任务，投递给指定Agent，回传状态回执
2.2.3执行层：本地Agent根据任务上下文执行具体工作（文档生成/代码提交/审核比对）
2.2.4回填层：Meego CLI + 飞书CLI读写工作项、回填字段、更新文档、推进节点
2.2.5事件驱动、异步执行：Webhook触发，各层通过标准协议通信，实现解耦集成
2.3三个Agent角色定义与协作协议
2.3.1需求架构Agent（V左构建）
2.3.2开发Agent（V左构建→V右验证桥接）
2.3.3PR合入Agent（V右验证）
2.4“五有”闭环设计原则
有输入：任务来源、字段、文档链接明确
有执行：Agent根据上下文完成具体工作
有回填：结果写回Meego字段或飞书文档
有反查：回填后确认结果已成功落库
有兜底：失败或信息不足时自动停止并通知负责人，支持回退普通流程
3.实战：remote模块端到端闭环验证
3.1验证策略：选择remote模块先行
3.1.1remote属于L4主线，相对独立、需求较简单，适合快速上线验证效果
3.1.2覆盖ipd1/ipd2双变更平台，若干条真实需求样本
3.2端到端流程全景
3.2.1SRS需求文档 → 需求架构Agent生成cc-read）→ 开发Agent生成代码提交test分支→ 人工审阅修改提交MR → PR合入Agent比对审核→ 通过后合入、字段回填、节点自动流转
3.2.2核心逻辑：每个节点的“完成”不仅指Agent执行结束，更要求结果已成功回填系统、完成文档沉淀和状态反查
3.3真实面对的不完美与改进方向
3.3.1部分场景失败报错不明晰→ 加强报错提示、Agent报错通知开发人
3.3.2开发Agent代码仓限定问题→ 完善仓库分支拉取逻辑
3.3.3需求臆造→ AI节点必须通过负责人校验才可流转，日志可追溯
4.迭代：从“串起来”到“跑得好”——质量闭环的持续进化
4.1两级循环结构
4.1.1Outer Loop（业务级） ：飞书项目流程/AAMP驱动——节点触发、任务投递、字段回填、反查确认、节点流转；失败进入failed/need_help人工兜底
4.1.2Inner Loop（Agent级） ：每个Agent内部的质量循环——需求架构Agent采用“生成→独立评审→修订→批准”；开发Agent采用“检查失败时定向修复”，不做全量重跑
4.2Harness工程：工具、知识、权限即配置
4.2.1工具与上下文即配置：每个Agent的可用工具（CTS/文档模板/代码仓/Skill/Git/CLI）与本地知识库（AGENT.MD/规则/历史经验）作为配置维护，随版本迭代
4.2.2权限即边界：Harness配置直接实现动作边界——只新建文档/只提交test分支/只读拉取；日志可追溯，无越权行为
4.2.3知识可追溯：使用时记录文档链接和时间信息，可追溯知识版本
4.2.4日志留痕：记录输入、输出、报错、回填结果，可拉取、可定位
4.3准出量化体系
4.3.1双维度准出标准：流程量化 × Agent配置量化
4.3.2指标看板：记录每次运行是否成功、人工接管率、响应时间、token消耗、命中Skill、bad case
4.3.3bad case回流机制：区分“流程可跑通问题”（针对节点AI配置修改）与“Agent配置问题”，记录→修复→版本迭代
4.3.4复盘节奏：初期每日复盘、后期每周复盘，由业务责任人与各Agent技术责任人跟进
5.洞见：从单点提效到组织质量工程
5.1成本节约的三层算账法
5.1.1第一层：人力流转成本节省
5.1.2第二层：错误率降低与返工减少——状态漏更新、PR漏合/错合、需求漏读、代码规范返工的系统性减少
5.1.3第三层：规模化复用价值
5.2落地挑战与应对
5.2.1Agent行为不确定性：需求臆造（7%）、判断可能无依据 → 关键动作边界定义为只读/仅建议/需审批，每动作责任归属明确，AI节点必须通过负责人校验才可流转
5.2.2任务运行中断：电脑息屏或切换页面导致进程暂停 → 梳理影响任务顺畅执行的核心因素（息屏/切后台/网络），推动飞书优化调整
5.2.3权限风险：lark cli存在权限风险 → 统一在组内L4知识库维护CTS/需求文档，通过目录及子目录权限继承机制实现自动化配置；新增“需求创建”节点需求文档md字段
5.2.4知识版本漂移：知识库随时间更新，产出难以对账 → 使用时记录文档链接和时间信息，可追溯知识版本
5.2.5失败不可感知：部分场景报错不明晰 → 加强报错提示，Agent报错通知开发人；bad case回流修复
5.3核心洞见：让能力随流程增长，而非随人流动
5.3.1传统模式：专家做得好→专家走了带走了→新来的人从头学→团队能力剧烈波动
5.3.2 AI工作流模式：每次运行沉淀一条经验→知识库越来越厚→新需求触发时自动复用→团队能力随运行次数持续增长
5.3.3智驾质量工程的本质正在从“管好人”转向“经营好流程” ——用流程承载知识，用AI放大人的判断力
6.展望
6.1从“好模型”走向“好系统”：通过工程化手段保障系统的稳定性、可扩展性与安全性
6.2Agent能力从单点工具演进为全流程协作智能体，覆盖需求→架构→开发→测试→交付全链路
6.3输出可推广的工程化最佳实践：为行业提供AI工作流重塑质量工程的可借鉴经验
听众收益：
1.获取可落地的AI工作流架构方案：了解头部主机厂如何以飞书项目AI工作流串联多Agent协作，解决“人工传文件+从零开发”的质量交付难题，获得可借鉴的系统架构与分阶段落地路径。
2.掌握质量闭环的量化评估方法：学习如何建立“流程能力×Agent能力”双维度准出标准，通过若干条真实样本验证流转成功率、回填成功率、耗时、成本等关键指标，理解AI质量工程“算得清账”的度量框架。
3.启发从“管人”到“经营流程”的管理思路：为研发管理者提供将个人经验转化为组织流程资产的新视角——用流程承载知识、用AI放大判断力，让团队能力随运行次数持续积累而非随人员流动波动。
1.获取可落地的AI工作流架构方案：了解头部主机厂如何以飞书项目AI工作流串联多Agent协作，解决“人工传文件+从零开发”的质量交付难题，获得可借鉴的系统架构与分阶段落地路径。
2.掌握质量闭环的量化评估方法：学习如何建立“流程能力×Agent能力”双维度准出标准，通过若干条真实样本验证流转成功率、回填成功率、耗时、成本等关键指标，理解AI质量工程“算得清账”的度量框架。
3.启发从“管人”到“经营流程”的管理思路：为研发管理者提供将个人经验转化为组织流程资产的新视角——用流程承载知识、用AI放大判断力，让团队能力随运行次数持续积累而非随人员流动波动。
历任某新势力车企高级算法架构师，长期深耕于智能驾驶软件研发一线，主导了多个核心算法与系统工程化项目。专注智驾软件工程化体系建设，积极探索并实践将前沿大模型与多智能体（Multi-Agent）协作框架融入智驾软件的开发全流程。带领团队构建模型驱动的研发协作新范式，覆盖需求分析、算法仿真、代码生成与测试验证全链路，显著提升复杂智驾系统的迭代速度与质量。
AiDD峰会
K+峰会
联系我们
购票热线：4006-998-758
媒体合作：柚子
媒体合作：柚子
联系电话：15601343666 邮箱：fengsh@keylinking.com
赞助合作：一竹
联系电话：18515447737 邮箱：sunyz@keylinking.com
票务合作：Anny
联系电话：17778017751 邮箱：zhangp@keylinking.com
联系电话：18515447737 邮箱：sunyz@keylinking.com
票务合作：Anny
联系电话：17778017751 邮箱：zhangp@keylinking.com
关注主办方
