01 / 09 · 页头主张
AI-Augmented Software Engineering
把AI嵌入软件研发全流程，让智能开发从试点走向可复用的工程能力。
面向研发负责人与平台团队：从工具试点走向可度量的工程能力。
01
需求
需求澄清与拆解
02
设计
代码库感知的设计上下文
03
编码
仓库级上下文补全
04
评审
规则库驱动的评审
05
测试
用例生成与回归取舍
06
发布与运行
门禁与灰度发布
六个环节各有嵌入点；任何一段缺失，整体收益都会被下游瓶颈吃掉。
- 研发规模 50 人以上时收益最清晰
- 先把 DORA 与采纳率基线建起来
- 以平台与规范沉淀，不卖工具
- 结束标准：团队可独立运行例会
实践标签仅标注行业与落地状态，客户名脱敏。
02 / 09 · 适配与不适用
Fit & Non-fit
三档自查：规模、切入点、承接方都具备时再做。
适合我们 · 3 条
- 01
研发规模 50 人以上
- 02
已采购 AI 编码工具但停在个人提效
- 03
有平台或效能团队可承接
暂不适合 · 2 条
- 01
只想要工具清单与提示词模板
- 02
不做基线度量、不接受复盘
不满足承接条件时，我们先补齐组织与岗责，再进入流程或工具改造。
- 研发规模 50 人以上时收益最清晰
- 有平台或效能团队承接才可复制
- 愿意接受指标基线是进入前提
- 不做基线度量与复盘的团队不适合
判断口径来自能力全景图中的「组织与机制」层。
03 / 09 · 能力全景图
Capability Map
24 项工程能力来自实际项目交付沉淀，不是行业通用清单。
| 能力层 / 价值链 | 需求 | 设计 | 编码 | 评审 | 测试 | 发布与运行 |
|---|---|---|---|---|---|---|
| 组织与机制 | 研发–业务需求对齐机制 已验证 L3 需求澄清工作坊与验收口径 | 架构决策记录（ADR）机制 已验证 L3 决策留痕，避免反复推翻 | AI 编码规范与门禁 资产化 L5 AI 辅助编码的规则与准入要求 | 开发者采用度运营 规模化 L4 内部推广、答疑与激励节奏 | 试点到推广决策机制 规模化 L4 何时推广、何时止损的规则 | 效能例会与决策日志 规模化 L4 指标驱动的固定复盘节奏 |
| 工程方法 | 需求澄清与拆解 规模化 L4 把模糊需求拆到可验证粒度 | 遗留系统反向理解 试点中 L2 用 AI 还原既有代码与依赖 | 代码库感知的上下文工程 规模化 L4 按仓库上下文组织提示与规则 | 评审规则库 已验证 L3 面向 AI 产出的评审规则集合 | 测试用例生成与回归策略 规模化 L4 用例生成与回归范围取舍 | 灰度发布与回滚策略 已验证 L3 发布分批与快速回退方案 |
| 平台与工具链 | 需求与缺陷统一台账 规模化 L4 需求、缺陷与工单同源可追溯 | 设计资产与知识库 已验证 L3 设计资产可检索、可复用 | 代码库索引与检索 规模化 L4 为 AI 提供仓库级上下文检索 | 提示与规则资产库 已验证 L3 提示、规则按项目版本化管理 | 质量门禁集成 资产化 L5 门禁嵌入流水线，自动拦截 | 私有化模型与网关 已验证 L3 模型私有部署与调用统一入口 |
| 度量与治理 | 需求交付周期与吞吐基线 已验证 L3 交付周期与吞吐的基线口径 | 架构风险与技术债台账 试点中 L2 风险与技术债可量化可排序 | AI 采纳率与留存 规模化 L4 采纳率与持续使用率作为 KPI | AI 产出抽样审计 已验证 L3 按批次抽样复核 AI 产出 | 代码与数据合规策略 规模化 L4 代码、数据与提示的合规边界 | DORA 四指标基线 规模化 L4 交付与稳定性的四指标基线 |
组织与机制
- L3
需求 · 01
研发–业务需求对齐机制
需求澄清工作坊与验收口径
- L3
设计 · 02
架构决策记录（ADR）机制
决策留痕，避免反复推翻
- L5
编码 · 03
AI 编码规范与门禁
AI 辅助编码的规则与准入要求
- L4
评审 · 04
开发者采用度运营
内部推广、答疑与激励节奏
- L4
测试 · 05
试点到推广决策机制
何时推广、何时止损的规则
- L4
发布与运行 · 06
效能例会与决策日志
指标驱动的固定复盘节奏
工程方法
- L4
需求 · 01
需求澄清与拆解
把模糊需求拆到可验证粒度
- L2
设计 · 02
遗留系统反向理解
用 AI 还原既有代码与依赖
- L4
编码 · 03
代码库感知的上下文工程
按仓库上下文组织提示与规则
- L3
评审 · 04
评审规则库
面向 AI 产出的评审规则集合
- L4
测试 · 05
测试用例生成与回归策略
用例生成与回归范围取舍
- L3
发布与运行 · 06
灰度发布与回滚策略
发布分批与快速回退方案
平台与工具链
- L4
需求 · 01
需求与缺陷统一台账
需求、缺陷与工单同源可追溯
- L3
设计 · 02
设计资产与知识库
设计资产可检索、可复用
- L4
编码 · 03
代码库索引与检索
为 AI 提供仓库级上下文检索
- L3
评审 · 04
提示与规则资产库
提示、规则按项目版本化管理
- L5
测试 · 05
质量门禁集成
门禁嵌入流水线，自动拦截
- L3
发布与运行 · 06
私有化模型与网关
模型私有部署与调用统一入口
度量与治理
- L3
需求 · 01
需求交付周期与吞吐基线
交付周期与吞吐的基线口径
- L2
设计 · 02
架构风险与技术债台账
风险与技术债可量化可排序
- L4
编码 · 03
AI 采纳率与留存
采纳率与持续使用率作为 KPI
- L3
评审 · 04
AI 产出抽样审计
按批次抽样复核 AI 产出
- L4
测试 · 05
代码与数据合规策略
代码、数据与提示的合规边界
- L4
发布与运行 · 06
DORA 四指标基线
交付与稳定性的四指标基线
共 24 项能力：资产化 2／规模化 11／已验证 9／试点中 2／评估中 0
- 资产化 L5
已形成标准方法与模板，≥3 个项目复制 - 规模化 L4
已在 3 个以上项目落地 - 已验证 L3
在 1–2 个项目跑通并复盘 - 试点中 L2
正在项目内验证 - 评估中 L1
持续跟踪／内部预研，未在客户项目验证
以上能力项来自我们实际项目的交付沉淀，非行业通用清单。
- 横轴为研发全链路六段
- 纵轴为四类能力层，共 24 项
- 五档成熟度标注真实落地程度
- 可从任一切入点开始，不必全域铺开
成熟度档位与计数条按内部实际项目回填；矩阵可单独打印，作为交付物索引。
04 / 09 · 典型状况与根因
Symptoms & Root Causes
症状看起来在工具，根因多数在流程与治理。
个人提效明显，交付周期没变
根因测试、评审、发布成为下游瓶颈
新能源车企·已落地AI 生成代码审查标准不一
根因缺少面向 AI 产出的评审规则库与门禁
金融科技·已验证工具买了，用不起来
根因没有采用度运营与内部推广机制
通用制造·试点中试点团队效果好，其它团队复制不了
根因能力沉淀在个人与单团队，未平台化
新能源车企·已落地智能开发的效果说不清
根因没有 DORA 基线，也没有采纳率与质量抽样
金融科技·已验证
- 症状是现象，根因决定改造顺序
- 先定位下游瓶颈，再谈工具扩容
- 规则与门禁缺失会放大返工
- 没有基线，改进无法被验证
实践标签仅标注行业与落地状态，客户名脱敏。
05 / 09 · 可承诺的影响
Measurable Impact
先建基线再承诺：外部数据给量级，自有数据给结论。
- 技术从业者在工作中使用 AI90%
个体层面的采用已普遍发生
- 自评生产力提升>80%
自我感知与组织级指标并不同步
- 组织级软件交付指标改善基本持平
收益兑现取决于平台与治理，而非工具数量
适用条件：DORA 数据来自近 5000 名技术从业者的年度调研，反映行业整体分布，不构成对单一组织的收益承诺；实际改善幅度取决于平台成熟度、切入点范围与试点团队的投入。
自有实测区间
待回填：需 1–2 个客户项目的改造前后实测数据（须标注项目数与行业），回填后优先于外部数据呈现。
- 外部数据只作量级参考
- 自有实测区间优先呈现
- 没有基线就不下承诺
- 口径与取数清单在诊断阶段确定
自有实测区间为空缺状态，回填后替代外部数据作为主要证据。
06 / 09 · 工作框架
Engagement Framework
五个阶段，每个阶段都有交付物与退出标准。
01
场景评估
1–2 周
02
工程规范
2–4 周
03
试点验证
4–6 周
04
平台化推广
4–8 周
05
效能度量
持续
场景评估
1–2 周
- 关键活动
- 现状扫描与切入点排序
- 交付物
- 场景评估报告、切入点清单
- 退出标准
- 切入点与基线口径确认
工程规范
2–4 周
- 关键活动
- AI 辅助研发规范与门禁定义
- 交付物
- 研发规范文件、质量门禁规则
- 退出标准
- 规范在试点仓库生效
试点验证
4–6 周
- 关键活动
- 单团队试点与复盘
- 交付物
- 试点复盘、风险清单
- 退出标准
- 指标达成且风险可控
平台化推广
4–8 周
- 关键活动
- 能力与规则资产化
- 交付物
- 平台能力清单、规则资产库
- 退出标准
- 第二个团队可自助接入
效能度量
持续
- 关键活动
- 指标更新与月度复盘
- 交付物
- 效能度量看板、月度复盘机制
- 退出标准
- 团队可独立运行例会
- 交付物内嵌在阶段内，不另出清单
- 以可复制的平台能力为终点
- 每阶段都有明确的退出标准
- 试点不达标可止损，不做硬推
周期为典型节奏，实际受平台成熟度与试点团队投入影响。
07 / 09 · 为什么是我们
Why Us
我们做工程化落地，不卖工具订阅。
能力来源
常见做法行业通用能力清单
我们的做法24 项能力来自实际项目交付沉淀
角色定位
常见做法工具采购与部署
我们的做法只做工程化落地，不卖工具订阅
推进方式
常见做法一次性方案交付
我们的做法第一周建立基线，每周更新指标
成功标准
常见做法工具采购量与使用人数
我们的做法采纳率与留存作为 KPI
合规设计
常见做法上线前另行评估
我们的做法合规策略与产出抽样审计同步设计
- 能力项来自实际交付沉淀
- 方法与模板标准化，可事前核对
- 采纳率与留存作为 KPI
- 合规与抽样审计同步设计
顾问构成明细（平台工程／效能度量／质量与合规）待补充。
08 / 09 · 常见异议
Objections
四个最常被问到的问题，先说清答案。
- 01
「我们已经买了 Copilot，还需要你们？」
工具解决个体提效，工程化解决组织兑现，二者不冲突。
- 02
「能保证多少提效？」
先建基线再承诺；外部数据有其适用条件，不套用未经验证的数字。
- 03
「AI 生成的代码安全谁来兜？」
门禁与抽样审计随试点同步建立，不等到上线前才补。
- 04
「试点之后怎么推广？」
平台化与决策规则（何时推广／何时止损）是框架的固定阶段。
- 工具提效与组织兑现是两件事
- 提效承诺以基线为前提
- 安全门禁随试点同步建立
- 推广与止损规则写进框架
其他问题可在诊断沟通中直接提出。