专场出品人：茹炳晟
腾讯研究院 高级技术顾问
中国计算机学会TF多智能体系统SIG副主席，中国计算机学会TF数据科学与知识工程SIG执委，“软件研发效能度量规范“标准核心编写专家，中国商业联合会互联网应用技术委员会智库专家，中国通信标准化协会TC608云计算标准和开源推进委员会云上软件工程工作组副组长，腾讯云架构师技术同盟入会主席，年度IT图书最具影响力作者，多本技术畅销书作者，著作有《软件研发效能提升之美》《现代软件测试技术之美》《测试工程师全栈技术进阶与实践》《多模态大模型技术原理与实战》《高效自动化测试平台:设计与开发实战》《软件研发效能提升实践》《软件研发效能权威指南》《现代软件测试技术权威指南》《高质效交付》《代码之外：软件工程师成长手记》等，译作有《软件设计的哲学》《整洁架构之道》《持续架构实践》《构建Agentic AI系统》《大模型驱动的软件测试：从理论到实践》《平台工程》《企业架构决策：战略框架与实施指南》《AI领导力》《现代软件工程》《计算机科学通识：计算思维培养与多学科问题解决实践》《DevOps实践指南（第2版）》《精益DevOps》《基础设施即代码-模型驱动的DevOps》等，国内外各大技术峰会的联席主席，出品人和Keynote演讲嘉宾。公众号“茹炳晟聊软件研发”主理人。
AI驱动的软件工程（AI4SE）
专场定位：AI Coding进入深水区，从辅助编码到自主工程的全链路演进。
内容覆盖维度：
▪ Agentic Coding深度实践
▪ Loop Engineering新范式：AI编程从"辅助写代码"到"自演进循环"
▪ 自主代码审查Agent：代码质量门禁、安全扫描、自动化重构
▪ AI-native开发者工作流：IDE→Agent工作台→多Agent并行开发的范式迁移
▪ AI4SE的效率度量：从代码行数到交付质量的评估体系革新
罗茂毅
AI Coding 的可靠交付与持续迭代
腾讯 高级工程师
腾讯高级工程师，2020 年加入腾讯，主要从事前端工程化与研发效能建设。主导无极低代码平台及 AI Coding 平台的开发，围绕腾讯内部管理台等业务场景，持续完善应用开发与交付体系。目前专注于 AI 驱动的软件工程，探索从 AI Coding 到端到端研发流程的落地实践。
议题背景：
AI 编码进入日常研发后，如何控制变更风险、验证运行结果并持续改进？本次分享结合腾讯内部管理台实践，介绍业务代码与基础能力的边界设计、多环境验证及发布恢复机制，讨论如何利用页面定位、运行反馈和 AI 测试完成排障与复验，并分享团队基于反馈与日志开展问题发现、修复和评审的循环工程实践，为业务应用的可靠交付提供可复用的方法。
内容大纲：
1. 工程约束：AI 编码的安全边界与可靠交付
1.1 能力边界：业务代码生成与底层数据、接口能力封装
1.2 环境隔离：多环境隔离与发布前的分级验证
1.3 权限与配置：访问控制、敏感配置管理与操作审计
1.4 发布与恢复：版本管理、部署状态追踪与异常恢复
1.2 环境隔离：多环境隔离与发布前的分级验证
1.3 权限与配置：访问控制、敏感配置管理与操作审计
1.4 发布与恢复：版本管理、部署状态追踪与异常恢复
2. 运行反馈：上下文驱动的问题定位与修复验证
2.1 可视化定位：页面元素与源码位置的关联
2.2 诊断上下文：网络请求、运行日志与编译错误的反馈
2.3 业务流程验证：基于业务目标的零手写用例 AI 自动化测试
2.4 协同迭代：共享工作区、状态同步与代码热更新
2.2 诊断上下文：网络请求、运行日志与编译错误的反馈
2.3 业务流程验证：基于业务目标的零手写用例 AI 自动化测试
2.4 协同迭代：共享工作区、状态同步与代码热更新
3. 循环工程：研发团队自身的 AI4SE 实践
3.1 问题发现：开发反馈与运行日志驱动的异常分析
3.2 定位与修复：结合会话上下文和代码仓库的 AI 辅助排障
3.3 质量验证：自动化测试与人工代码评审的协同
3.4 经验复用：问题案例沉淀与研发流程持续改进
3.2 定位与修复：结合会话上下文和代码仓库的 AI 辅助排障
3.3 质量验证：自动化测试与人工代码评审的协同
3.4 经验复用：问题案例沉淀与研发流程持续改进
听众受益：
1. 明确 AI 代码生成与基础工程能力的职责边界，获得控制应用交付风险的设计参考。
2. 了解如何组织页面、请求和构建信息，形成 AI 定位、修复与验证的迭代流程。
3. 借鉴反馈驱动的循环工程方法，将实际问题转化为修复任务、验证依据和可复用经验。
1. 明确 AI 代码生成与基础工程能力的职责边界，获得控制应用交付风险的设计参考。
2. 了解如何组织页面、请求和构建信息，形成 AI 定位、修复与验证的迭代流程。
3. 借鉴反馈驱动的循环工程方法，将实际问题转化为修复任务、验证依据和可复用经验。
谢明辉
从“会写代码”到“可规模化交付”的Coding Agent落地建设
腾讯音乐 技术专家
现就职于腾讯音乐娱乐集团，长期从事研发效能、AI Coding 与智能体工程化实践，关注大模型在真实软件研发流程中的规模化落地。主导和深度参与企业级研发智能体 Modus 的建设，将代码知识图谱、规格驱动开发、工程方法论、需求澄清、质量门禁及多平台 Agent 能力整合为可审计的研发闭环；同时推动业务知识库、代码知识库、反馈更新机制与 Benchmark 评测体系在真实业务需求中试点。实践重点不是单点代码生成，而是通过知识、流程、测试与评测协同，持续提升交付完成度、稳定性和组织可复制性，并积累了跨产品、开发、测试协同推进 AI 研效落地的实践经验。
议题背景：
AI 编程工具已经具备较强的代码生成能力，但在真实企业研发中，制约规模化提效的往往不是模型本身，而是项目知识缺失、需求上下文断裂、交付流程不可控以及效果无法度量。本次分享结合企业内部 Coding Agent 实践，介绍如何构建面向人的业务知识库与面向 Agent 的代码知识库，如何以需求单串联澄清、设计、开发、测试和评审，并通过反馈回刷、Benchmark 与研效指标建立可持续优化闭环。
AI 编程工具已经具备较强的代码生成能力，但在真实企业研发中，制约规模化提效的往往不是模型本身，而是项目知识缺失、需求上下文断裂、交付流程不可控以及效果无法度量。本次分享结合企业内部 Coding Agent 实践，介绍如何构建面向人的业务知识库与面向 Agent 的代码知识库，如何以需求单串联澄清、设计、开发、测试和评审，并通过反馈回刷、Benchmark 与研效指标建立可持续优化闭环。
内容大纲：
1. AI Coding 从个人提效走向工程提效的关键断点
1.1 代码生成能力不等于真实需求交付能力
1.2 知识、上下文、流程与评测的四类断点
1.3 简单需求直通与复杂需求治理的边界
1.2 知识、上下文、流程与评测的四类断点
1.3 简单需求直通与复杂需求治理的边界
2. 双知识库：同时服务人和 Agent
2.1 面向产品与开发的业务知识库
2.2 面向机器推理的 Domain、Module 与代码证据
2.3 业务规则、代码事实与目标需求的权威边界
2.2 面向机器推理的 Domain、Module 与代码证据
2.3 业务规则、代码事实与目标需求的权威边界
3. 以需求为基石的 Agent 研发闭环
3.1 从需求澄清、设计和计划到开发、测试与 CR
3.2 产物流转、质量门禁与可恢复执行
3.3 多平台 Agent 的统一能力与上下文组织
3.2 产物流转、质量门禁与可恢复执行
3.3 多平台 Agent 的统一能力与上下文组织
4. 知识反馈与持续更新机制
4.1 从 Agent/Web 对话采集带证据的反馈事件
4.2 业务知识、代码事实、提示词与代码缺陷的分流
4.3 去重幂等、版本发布与回归验证
4.2 业务知识、代码事实、提示词与代码缺陷的分流
4.3 去重幂等、版本发布与回归验证
5. 如何评测 AI 研发提效
5.1 四组对照 Benchmark：模型、方法、流程与知识增益
5.2 完成度、质量、时间、Token、人工介入与稳定性
5.3 连接 AI 单测、AICR 与静态质量扫描的长期研效度量
5.2 完成度、质量、时间、Token、人工介入与稳定性
5.3 连接 AI 单测、AICR 与静态质量扫描的长期研效度量
听众受益：
1. 获得一套从个人 AI Coding 走向团队级工程提效的判断框架；
2. 理解业务知识库与代码知识库的分工、交集及更新方式；
3. 掌握以需求为基石串联澄清、设计、开发、测试和评审的落地方法；
4. 学会设计控制变量的 Coding Agent Benchmark，量化知识库和工程流程的独立增益；
5. 了解企业试点中产品、开发、测试协作的真实问题与推进策略。
孟繁茂
Agent 驱动的产研新流程：需求 Agent 的工程化落地实践
去哪儿 机票辅营搜索负责人 资深技术架构师
负责辅营搜索与商品策略相关业务，长期参与机票业务中的 AI 应用探索，实践方向包括 AI 客服、导购与搜索。围绕业务落地，探索不同 Agent 架构、测试与运营方式，积累工程实现和业务知识组织经验。近期聚焦 Agent 驱动的软件交付流程，推进需求编写、技术方案、工单处理及巡查排障等场景的智能体实践，并探索 Harness 平台、Skill 与企业知识库的协作方式，关注 Agent 如何融入产研团队、形成可审核的交付结果，以及如何通过知识回流持续改进。
议题背景：
本次分享以需求 Agent 作为产研新流水线的第一站，介绍“新员工、新模式、新分工”的协作方式，并展开从模糊 Idea 到可评审 PRD 的工程实践。内容覆盖企业业务知识提取与召回、团队需求模板与记忆管理、Harness 与 Skill 协作、飞书与 Web 混合交互，以及人工审核和交付后的知识回流，帮助听众理解需求 Agent 如何进入真实工作流程，并获得从单一场景启动实践的方法。
本次分享以需求 Agent 作为产研新流水线的第一站，介绍“新员工、新模式、新分工”的协作方式，并展开从模糊 Idea 到可评审 PRD 的工程实践。内容覆盖企业业务知识提取与召回、团队需求模板与记忆管理、Harness 与 Skill 协作、飞书与 Web 混合交互，以及人工审核和交付后的知识回流，帮助听众理解需求 Agent 如何进入真实工作流程，并获得从单一场景启动实践的方法。
内容大纲：
1. Agent 进入产研团队：新员工、新模式与新分工
1.1 新员工：从需求到测试，Agent 开始承担具体工作
1.2 新模式：从人工串联到 Agent 参与的任务流水线
1.3 新分工：产研共同审核与 Agent 领航员
1.2 新模式：从人工串联到 Agent 参与的任务流水线
1.3 新分工：产研共同审核与 Agent 领航员
2. Agent理解业务：业务知识提取、召回与需求澄清
2.1 明确任务：从模糊想法中识别目标、约束与待确认问题
2.2 准备知识：从代码与历史需求中提取业务概念、规则和流程
2.3 使用知识：通过 CLI 查询与召回，为需求判断提供上下文
2.2 准备知识：从代码与历史需求中提取业务概念、规则和流程
2.3 使用知识：通过 CLI 查询与召回，为需求判断提供上下文
3. 形成需求：需求 Agent 的执行架构与产研协作
3.1 确立标准：按产品团队和需求类型管理模板、案例与记忆
3.2 完成协作：用飞书与 Web 对话澄清、初稿生成需求
3.3 支撑执行：Harness、Skill 与 CLI 如何协同完成任务
3.4 判断质量：通过质量评分+产研审核确认需求完整性与可交付性
3.2 完成协作：用飞书与 Web 对话澄清、初稿生成需求
3.3 支撑执行：Harness、Skill 与 CLI 如何协同完成任务
3.4 判断质量：通过质量评分+产研审核确认需求完整性与可交付性
4. 连接交付：任务交接、知识回流与效果复盘
4.1 交接任务：将确认后的 PRD 作为后续 Agent 的工作输入
4.2 回流知识：关联需求文档、设计文档与交付代码
4.3 复盘实践：效果、失败案例与下一步演进
结语 AI 项目实践思想手册
4.2 回流知识：关联需求文档、设计文档与交付代码
4.3 复盘实践：效果、失败案例与下一步演进
结语 AI 项目实践思想手册
听众受益：
1. Agent Skill架构：看懂 Harness、Skill 与 CLI 的协作方式，获得需求 Agent 工程化落地经验。
2. 企业知识库技术设计：掌握多维度知识库的提取建立、活用agent记忆、Skill提取、CLI召回知识库。
3. 产品提效与协作：了解产品经理学会借助 Agent 澄清想法、生成和修改 PRD，推进需求评审。如何明确人与 Agent 的分工及审核节点，让需求衔接后续设计与开发
1. Agent Skill架构：看懂 Harness、Skill 与 CLI 的协作方式，获得需求 Agent 工程化落地经验。
2. 企业知识库技术设计：掌握多维度知识库的提取建立、活用agent记忆、Skill提取、CLI召回知识库。
3. 产品提效与协作：了解产品经理学会借助 Agent 澄清想法、生成和修改 PRD，推进需求评审。如何明确人与 Agent 的分工及审核节点，让需求衔接后续设计与开发
王胜志
从个人提效到组织提效——
APEX：可观测、可验收的 Agent 工程体系
APEX：可观测、可验收的 Agent 工程体系
bilibili 资深开发工程师
从事大规模在线推理与性能优化方向的工程与平台建设，当前在哔哩哔哩负责推理性能平台相关工作。过去一段时间主要在做的，是把"性能优化"这件高度依赖专家经验、反复试错的事，变成一套可被 agent 规模化执行的工程流程。为此主导建设了 APEX 平台——一套面向性能探索的 Agentic 平台生态，把问题拆成四层：目标层"要什么"，底座层"怎么调度一个 turn"，场景层 "怎么被优化"，执行层"谁去执行"。目前已承载推理参数寻优、特征图自动优化、CPU/GPU 迁移等 7 个真实线上场景。
议题背景：
哔哩哔哩 APEX 平台的核心是图工程：把员工的工作流、知识库和工具沉淀成一个个场景 loop，再把场景组合成图，让复杂工作有一套可端到端交付的解法。难处不在让 agent 聪明一次，而在经得起长跑：版本、状态、断点、账目样样要稳；性能场景还多一道门槛，环境、负载、观测口径任何一样漂移，数字就作废。撑住它的是自研分层解耦：底座只承诺"执行一次"，编排层管多轮，沙盒把"可比"变成默认，执行交给数字员工。
哔哩哔哩 APEX 平台的核心是图工程：把员工的工作流、知识库和工具沉淀成一个个场景 loop，再把场景组合成图，让复杂工作有一套可端到端交付的解法。难处不在让 agent 聪明一次，而在经得起长跑：版本、状态、断点、账目样样要稳；性能场景还多一道门槛，环境、负载、观测口径任何一样漂移，数字就作废。撑住它的是自研分层解耦：底座只承诺"执行一次"，编排层管多轮，沙盒把"可比"变成默认，执行交给数字员工。
内容大纲：
1. 问题：当任务从"执行一次"变成"持续数日"
1.1 反直觉的起点：短任务考验模型，长任务考验平台
1.2 长任务逼出的四个问题：版本、状态、断点、审计
1.3 我们的选择：分层解耦的平台，而非端到端黑盒
1.4 "长"只是表象：出路不在更强的 agent，而在图工程
1.2 长任务逼出的四个问题：版本、状态、断点、审计
1.3 我们的选择：分层解耦的平台，而非端到端黑盒
1.4 "长"只是表象：出路不在更强的 agent，而在图工程
2. APEX 的核心：图工程
2.1 原子：工作流、知识库与工具，封装为一个场景
2.2 场景本身即有规模：简单者一条 loop，复杂者已是一张图
2.3 组合：图可嵌套——场景可作为更大图中的一个节点
2.4 交付：具备完整能力的场景即可独立交付，无需等待组合
2.5 落到工程：目标 / 底座 / 编排 / 执行四层
2.6 谁保证"跑到终态"，谁保证"执行到位"：两层的分界
2.2 场景本身即有规模：简单者一条 loop，复杂者已是一张图
2.3 组合：图可嵌套——场景可作为更大图中的一个节点
2.4 交付：具备完整能力的场景即可独立交付，无需等待组合
2.5 落到工程：目标 / 底座 / 编排 / 执行四层
2.6 谁保证"跑到终态"，谁保证"执行到位"：两层的分界
3. 底座层：只承诺"执行一次"
3.1 对外只有一组动作，无一与"第几轮"相关
3.2 状态机中最反直觉的一格：idle 是一等状态
3.3 地基决策：版本是会话的属性，而非机器的属性
3.4 这条决策换来了什么，代价又是什么
3.5 队列与并发：租约领取、心跳续租、同质执行机池
3.2 状态机中最反直觉的一格：idle 是一等状态
3.3 地基决策：版本是会话的属性，而非机器的属性
3.4 这条决策换来了什么，代价又是什么
3.5 队列与并发：租约领取、心跳续租、同质执行机池
4. 编排层：把"多轮优化"跑起来
4.1 为何底座之上仍需一层：轮次与收敛属于业务判断
4.2 编排层是什么：自研 Pipeline 调度框架（S2）
4.3 一次 job 的链路：解释器只做派发，写库亦为任务
4.4 真正调用 LLM 的步骤极少：两个证据
4.5 断点续跑何以"天然"：结果入 KV，重跑直接读取
4.6 水平扩展：任务 ID 即路由键，新增集群只需加配置
4.7 场景玩法：7 个线上场景如何共用同一套执行
4.8 打分与硬约束：四维加权 + 一票否决
4.9 一个真实教训：分数达标而早停，吞吐仍在攀升
4.10 组合如何落地：pipeline 互相调用 + DAG 可视化
4.2 编排层是什么：自研 Pipeline 调度框架（S2）
4.3 一次 job 的链路：解释器只做派发，写库亦为任务
4.4 真正调用 LLM 的步骤极少：两个证据
4.5 断点续跑何以"天然"：结果入 KV，重跑直接读取
4.6 水平扩展：任务 ID 即路由键，新增集群只需加配置
4.7 场景玩法：7 个线上场景如何共用同一套执行
4.8 打分与硬约束：四维加权 + 一票否决
4.9 一个真实教训：分数达标而早停，吞吐仍在攀升
4.10 组合如何落地：pipeline 互相调用 + DAG 可视化
5. 场景沙盒：让"可比"成为默认
5.1 为何先解决可比性：在噪声上决策比不决策更危险
5.2 沙盒是什么：运行真实服务的隔离实验环境
5.3 让负载可比：线上真实流量抓取一次、反复回放
5.4 让环境可比：一个 tag 冻结一整套工作环境
5.5 环境装配线（代号 harness）：从 tag 到可运行环境
5.6 可信与可扩展：门禁前置，新增场景只增配置
5.2 沙盒是什么：运行真实服务的隔离实验环境
5.3 让负载可比：线上真实流量抓取一次、反复回放
5.4 让环境可比：一个 tag 冻结一整套工作环境
5.5 环境装配线（代号 harness）：从 tag 到可运行环境
5.6 可信与可扩展：门禁前置，新增场景只增配置
6. 数字员工：身份、凭证与可审计
6.1 为何 agent 不能借用平台账号
6.2 一场景一数字员工：提交记录即可追溯到具体场景
6.3 凭证现签、终态即失效，仅在内存与环境变量中流转
6.2 一场景一数字员工：提交记录即可追溯到具体场景
6.3 凭证现签、终态即失效，仅在内存与环境变量中流转
7. 人在环中：人只出现在两个环节
7.1 拍板：agent 反问，决策回喂后自动续跑
7.2 验收：结果是否可信、是否交付
7.3 其余环节自动化：人从流程驱动者回到判断者
7.2 验收：结果是否可信、是否交付
7.3 其余环节自动化：人从流程驱动者回到判断者
8. 落地见闻与工程取舍
8.1 "每次从零装配"的代价：环境版本只增不减
8.2 多场景共用同一批代码仓：改动共享文件前先对齐
8.3 可观测性：这一轮由谁执行、在何处、做了什么
8.4 成本上限须显式设定：框架不会替你截断失控的 loop
8.2 多场景共用同一批代码仓：改动共享文件前先对齐
8.3 可观测性：这一轮由谁执行、在何处、做了什么
8.4 成本上限须显式设定：框架不会替你截断失控的 loop
9. 收束：三条底线与一个终局
9.1 环境扰动最薄化：仅执行层触碰真实环境
9.2 下层不感知上层：loop 归编排层，底座只认 turn
9.3 事实来源是系统记录，而非人的口述
9.4 终局：场景本身即可成图，亦可再组成更大的图
9.2 下层不感知上层：loop 归编排层，底座只认 turn
9.3 事实来源是系统记录，而非人的口述
9.4 终局：场景本身即可成图，亦可再组成更大的图
听众受益：
1. 一套"图工程"的落地思路
如何将员工的日常工作流、知识库与工具封装为一个个场景：简单场景是一条loop，复杂场景本身即一张图、可独立端到端交付，亦可再组合成更大的图。这是 Agent 平台从"单点自动化"走向"可交付"的关键一跳。
2. 一套可直接对照的分层方法厘清"目标 / 底座 / 编排 / 执行"各自的职责边界——避免把 loop 与收敛判断硬塞进执行底座这类最常见的架构错位。
3. 企业级 Agent 平台的关键抉择
版本亲和、会话状态机、租约队列、可漂移 worker 池——哪些必须在地基阶段一次做对，哪些可以后补。
4. 数字员工的身份与审计落地路径
让 agent 拥有独立身份、独立凭证、独立发版，每一步可归因到具体数字员工，而非共用平台账号。
郑伟
OPPO 互联网 AI 研发效能演进之路
OPPO 互服工程团队 AI 提效负责人
17年研发和管理经验
oppo互服工程团队ai提效负责人
oppo互服工程团队ai提效负责人
开场
这是一次复盘分享：过去一年多，互服在 AI 研发上实际走过哪些阶段、每阶段做了什么
阶段 1：工具普及（人 + Cursor）
全面开通 Cursor，做基础培训
覆盖和活跃已经起来（覆盖约 5 千人，活跃率约 77%）
多数人停在对话式使用；Rules / Plan / Commands 用得少
问卷：多数觉得「有帮助」，显著提效的少；资深同学、复杂需求更不明显
这一阶段留下的问题： 会用工具了，但项目里不稳定、不敢大规模信 AI 出的代码。
阶段 2：上下文工程
把「AI 要干活所需的信息」补上，分三块一起做。
2.1 仓库建设（AI README）
仓内给 AI 的项目说明书：业务术语、架构、规范、怎么构建/测试
/ai-readme：AI 扫仓出骨架，人补业务判断；单仓 / 多仓 / 客户端模块各有一套
全局规则用 ai-readme-cli 按技术栈下发
2.2 知识库建设
仓外、跨项目的组织知识（变革里的必答题）
和 README 分工：仓内管「这个项目怎么写」，知识库管「公司/业务侧的规范、决策、领域知识」
同期做知识收集工具、网关、平台化
2.3 提示词 / 需求说清楚
提示词优化 MCP：需求先结构化；说不清就问人，不猜着改
可带一个例子： 女娲活动中台同一条需求，有/无 AI README 的对照（耗时大约少 1/4）。
阶段 3：智能化流程 · 研发数字人（欧小猿）
背景：周期要缩短；0.5H～48H 这类需求，人盯着 Cursor 敲，提效有限
做法：这类需求交给欧小猿做，人做评审
分级按自动驾驶思路 L0–L5（辅助编码 → 主导编码 → 简单场景自主 → …）
现在：L2，AI 主导编码（方案 / 写码 / CR / 解 bug 数字人做，人审方案和代码）
L2 已对过的能力：方案一次过 >90%，代码一次过 >80%，测试提的 bug 自修 >80%
推广：互服铺开 → 工时往 0.5H 收 → 再铺平台产品技术中心、视频中心等
同一时期还有测试数字人、运营/投放等 Agent，作为其它域的平行线
阶段 4：AI Native 分队
各组织、各团队成立若干 AI Native 分队，用小分队方式把 AI 研发跑起来
看的是组织结果，不是某套操作细节
核心指标：需求双人完成率——一条需求最多两人做完，就是产品 + 研发
分队对这个指标负责，用它衡量 AI Native 有没有真正把人减下来
阶段 5：可定制的团队协同（CoMind）
重点是 团队协同：人和数字人、产品和研发在同一套上下文里一起干活
统一上下文：仓库、知识、规范、任务进度对齐
协同方式可按团队来配（角色、分工、接力）
往上沉淀可复用能力：
公共流水线：跨团队共用的研发协同流水线
公共 Agent：可被各团队调用的共用智能体
研发 Skill：可下发、可复用的研发技能包
收尾
串一遍：普及工具 → 补上下文（仓库 + 知识库）→ 数字人进研发 → 成立 AI Native 分队、盯双人完成率 → CoMind 上的团队协同（统一上下文、公共流水线 / Agent / Skill）
现在停在：L2 能上岗；分队和双人完成率在跑；团队协同在 CoMind 上铺
接下来：简单场景往 L3 收；知识库进到日常取用；公共流水线、公共 Agent、研发 Skill 继续沉淀
这是一次复盘分享：过去一年多，互服在 AI 研发上实际走过哪些阶段、每阶段做了什么
阶段 1：工具普及（人 + Cursor）
全面开通 Cursor，做基础培训
覆盖和活跃已经起来（覆盖约 5 千人，活跃率约 77%）
多数人停在对话式使用；Rules / Plan / Commands 用得少
问卷：多数觉得「有帮助」，显著提效的少；资深同学、复杂需求更不明显
这一阶段留下的问题： 会用工具了，但项目里不稳定、不敢大规模信 AI 出的代码。
阶段 2：上下文工程
把「AI 要干活所需的信息」补上，分三块一起做。
2.1 仓库建设（AI README）
仓内给 AI 的项目说明书：业务术语、架构、规范、怎么构建/测试
/ai-readme：AI 扫仓出骨架，人补业务判断；单仓 / 多仓 / 客户端模块各有一套
全局规则用 ai-readme-cli 按技术栈下发
2.2 知识库建设
仓外、跨项目的组织知识（变革里的必答题）
和 README 分工：仓内管「这个项目怎么写」，知识库管「公司/业务侧的规范、决策、领域知识」
同期做知识收集工具、网关、平台化
2.3 提示词 / 需求说清楚
提示词优化 MCP：需求先结构化；说不清就问人，不猜着改
可带一个例子： 女娲活动中台同一条需求，有/无 AI README 的对照（耗时大约少 1/4）。
阶段 3：智能化流程 · 研发数字人（欧小猿）
背景：周期要缩短；0.5H～48H 这类需求，人盯着 Cursor 敲，提效有限
做法：这类需求交给欧小猿做，人做评审
分级按自动驾驶思路 L0–L5（辅助编码 → 主导编码 → 简单场景自主 → …）
现在：L2，AI 主导编码（方案 / 写码 / CR / 解 bug 数字人做，人审方案和代码）
L2 已对过的能力：方案一次过 >90%，代码一次过 >80%，测试提的 bug 自修 >80%
推广：互服铺开 → 工时往 0.5H 收 → 再铺平台产品技术中心、视频中心等
同一时期还有测试数字人、运营/投放等 Agent，作为其它域的平行线
阶段 4：AI Native 分队
各组织、各团队成立若干 AI Native 分队，用小分队方式把 AI 研发跑起来
看的是组织结果，不是某套操作细节
核心指标：需求双人完成率——一条需求最多两人做完，就是产品 + 研发
分队对这个指标负责，用它衡量 AI Native 有没有真正把人减下来
阶段 5：可定制的团队协同（CoMind）
重点是 团队协同：人和数字人、产品和研发在同一套上下文里一起干活
统一上下文：仓库、知识、规范、任务进度对齐
协同方式可按团队来配（角色、分工、接力）
往上沉淀可复用能力：
公共流水线：跨团队共用的研发协同流水线
公共 Agent：可被各团队调用的共用智能体
研发 Skill：可下发、可复用的研发技能包
收尾
串一遍：普及工具 → 补上下文（仓库 + 知识库）→ 数字人进研发 → 成立 AI Native 分队、盯双人完成率 → CoMind 上的团队协同（统一上下文、公共流水线 / Agent / Skill）
现在停在：L2 能上岗；分队和双人完成率在跑；团队协同在 CoMind 上铺
接下来：简单场景往 L3 收；知识库进到日常取用；公共流水线、公共 Agent、研发 Skill 继续沉淀
Agentic AICon 组委会是由业界多位资深技术专家发起，负责组织技术指导委员会，并和委员会的专家一起挖掘全球软件工程领域的创新技术，同时依托智盟创课国内领先的人才能力提升服务供应商，组织专业的会务服务团队，全面推进会议的顺利落地，保证参会者体验。
服务总线：400-183-9980
商务合作：151-2264-3988 木子
票务联系：185-1306-7287 静秋老师
E-mail：speaker@qecon.com.cn
关注SECon公众号
添加SECon小助手，获取
会议最新资讯
