专场出品人：
......
......
AI驱动的软件工程（AI4SE）
专场定位：AI Coding进入深水区，从辅助编码到自主工程的全链路演进。
内容覆盖维度：
▪ Agentic Coding深度实践
▪ Loop Engineering新范式：AI编程从"辅助写代码"到"自演进循环"
▪ 自主代码审查Agent：代码质量门禁、安全扫描、自动化重构
▪ AI-native开发者工作流：IDE→Agent工作台→多Agent并行开发的范式迁移
▪ AI4SE的效率度量：从代码行数到交付质量的评估体系革新
谢明辉
从“会写代码”到“可规模化交付”的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 平台的图工程
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 拥有独立身份、独立凭证、独立发版，每一步可归因到具体数字员工，而非共用平台账号。
敬请期待
敬请期待
......
......
......
SECon组委会是由业界多位资深技术专家发起，负责组织技术指导委员会，并和委员会的专家一起挖掘全球软件工程领域的创新技术，同时依托智盟创课国内领先的人才能力提升服务供应商，组织专业的会务服务团队，全面推进会议的顺利落地，保证参会者体验。
服务总线：400-183-9980
商务合作：151-2264-3988 木子
票务联系：185-1306-7287 静秋老师
E-mail：speaker@qecon.com.cn
关注SECon公众号
添加SECon小助手，获取
会议最新资讯
