定义问题，远远比解决问题重要

管理里面有一句话，你如果无法度量，也就无法管理。

先说结论

能力	1、提高AI
意愿	1、消除偏见 2、提供最佳实践

1. 增加开发人员使用AI的意愿问题

1. 提高开发人员需求拆分为AI友好的粒度

1. 提高开发人员对任务判定的能力：AI工具自动评估任务是否可以解决：当前ai工具不具备，需要开发人员来判断

1. 提高开发人员使用AI生成代码能力：AI能解决功能点，生成准确的代码

背景

随着AI技术的快速发展，AI编程助手如GitHub Copilot等工具已成为现代软件开发的重要组成部分。AI的发展对编程的范式改变是必然的，你不拥抱，别人就会拥抱，你的成本就会比别人高，此时，你就会在商业成本上更高，进而降低竞争力。

然而，许多团队在引入这些工具后，面临着使用率低、接受度不高等问题。本文将从多个角度探讨如何让团队真正接受AI编程助手，并充分发挥其潜力。

适用范围

软件研发成本占比较高(>30%)的公司或团队

有些企业的竞争力不包含研发成本或者研发成本的降低对成本影响很低，此时，AI辅助提效就不是必须的。

前情提要

企业降本的几种场景

1. 业务收缩（ROI低），裁人

副作用：降低收入，提高了ROI

1. 业务不变，裁人（降低成本）

副作用：可能出现质量事件，交付延迟等，面临客户投诉

1. 扩充业务，不增加人（控制成本）

副作用：可能出现质量事件，交付延迟等，面临客户投诉

注：实际上还有降低福利等措施，不在本文考虑范围

为了避免副作用的其中一个方法就是提高人效。

研发效率影响因素

文化

组织

流程

人

工程能力

AI 辅助提效从哪里入手（Where)

根据二八法则，核心是找到研发的高能耗点，且AI能比较好得解决

从人数占比分析

大部分团队，开发人员占比最高，最简单的方式看一个研发团队的各个岗位占比。一个 10 人团队，占比大概为，团队管理者:架构师:开发:测试 = 1:1:6:2，虽然，各个角色薪资不是1:1，毫无疑问，开发人员占比最高

从研发流程分析业界AI提效的投入

当前业界主要关注的就是代码生成，为什么业界要关注代码生成而不是其他，原因是，在一个软件团队中编码人员最多，成本占比最大，而且软件团队最后交付的就是代码，因此，AI在开发领域最成熟，提效带来的收益最大

阶段	可公开训练数据	自动/客观评价	错误回滚成本	上下文长度需求	商业付费意愿	当前技术成熟度	综合 ROI	资源投入热度
需求分析	★ 企业内部文档，几乎无开源	★ 主观评审，无统一指标	★★ 需求返工=项目最大浪费	★★★★★ 会议记录+原型+脑图>1 M token	★ 无明确预算科目	☆ 学术空白	极低	几乎无
系统设计	★ UML/架构图散落，格式不统一	★★ 靠架构师拍脑袋	★★ 设计失误导致后期重写	★★★★ 跨多模态图+文	★★ 预算挂在“咨询费”	★ 探索性论文	低	零星
代码生成	★★★★★ GitHub 1.2 TB 公开+CI 反馈	★★★★★ 编译器/单元测试秒级 Pass/Fail	★★★★ 函数级回滚秒级零损失	★★ 32k–200k token 刚好覆盖函数	★★★★★ 开发者月付 10–20 美元已成习惯	★★★★★ 已有千亿级模型+IDE 插件规模落地	最高	主力赛道
单元/接口测试	★★ 测试用例散见，无统一语法	★★★ 覆盖率可量化，但需搭环境	★★ 漏测带来线上故障	★★★ 需读代码+日志+配置	★★ 测试工具预算受限	★★ 自动生成用例刚起步	中	次热点
持续集成	★★ CI 脚本公开，但量小	★★★ 构建成功/失败可自动判	★★ 构建失败阻塞交付	★★★★ 多仓库+多流水线	★ 企业不愿额外付费	★★ 研究阶段	中偏低	少量
部署&运维	★ 日志/监控高度敏感，难开源	★ MTTR/SLA 指标滞后且噪声大	★ 线上故障=直接赔钱+P0 值班	★★★★★ 跨云、多 K8s 集群，上下文巨大	★ 预算投给平台，不买单脚本	★ 实验性产品	极低	几乎无

星级说明：★越多代表该项越有利于 AI 大规模投入（数据多、评价易、成本低、付费意愿强等）。

通过以上分析，开发的编码部分在整个研发成本中占比最高，AI的成熟度也最高

如何通过AI提升开发效率

在开始how之前我们先要问自己几个问题

视角一：从开发的活动进行分析

一个开发人员在需求端到端

活动	角色	占比	现状	AI 参与程度及GAP
需求分析	架构师		人工	无
方案设计	架构师		人工	多模态的能力：具备根据视频流和文字进行业务理解的能力不足
需求评审	架构师		人工
版本计划	项目管理		人工
需求串讲	项目管理、架构师、开发、测试		人工	无
测试策略			人工
软件实现设计	开发		人工+AI
测试用例设计	测试		人工+AI
软件实现设计反串讲	项目管理、架构师、开发、测试		人工	无
测试用例设计反串讲			人工
需求开发	开发		人工+AI	根据方案生成代码
测试用例开发	测试		人工+AI	根据代码生成测试
本地自验证	开发		人工
单元测试	开发		人工+AI
开发环境部署			人工
开发环境联调			人工	对测试环境数据的理解不足
代码提交（门禁、流水线修复）	开发		人工
代码检视	开发、架构师		人工+AI
测试环境部署	开发		人工	对测试环境数据的理解不足
需求相关资料刷新	开发		人工
需求转测	开发		人工
测试环境验证（多轮）	测试		人工
问题单修改（功能、安全、开源软件）	开发		人工
开源软件治理	开发		人工
漏洞清零	开发		人工
告警清零截图	开发		人工	无（）
服务包归档	开发		自动化	无（自动化）
测试报告	测试		人工	无
版本发布	项目管理、QA		人工	无
部署上线	运维		人工	无

对于开发人员来说，端到端交付一个需求的影响因素

维度	因素	AI能力匹配度
需求本身	需求的规模	规模越小，AI能力越匹配
需求本身	需求的清晰度	需求越清晰，AI能力越匹配
需求本身	需求的复杂度	需求越简单，AI能力越匹配
需求本身	需求的优先级	与AI无关
个人能力	技术能力：复杂任务的能力	可以提升
个人能力	业务理解：业务熟悉程度	可以提升
个人能力	技术储备：复用的组件，框架	与AI无关
个人能力	学习能力	与AI无关
个人能力6	个体效率	与AI关系不大
团队协作	协作效率：文档完备度，沟通顺畅程度	与AI关系不大
团队协作	流程效率	与AI关系不大
团队协作	工程化能力：工具支持，自动化能力，如流水线	与AI关系不大
团队协作	设施基础：环境	与AI关系不大
外部环境	第三方服务	与AI关系不大

经过以上分析，回答了前面两个问题

1、AI 能提升开发效率么？ 能

2、哪些能？哪些不能？ 参考如上表格

如何提升AI的使用率

AI编程助手的使用率模型

AI编程助手类似自动化编程工具，能自动完成开发人员指定的任务。人机交互领域有很多关于自动化工具的研究，《Trust, self-confidence, and operators' adaptation to automation》中的模型特别适合用来解释AI编程助手的使用率：

                                    

我们将使用率（Usage Rate）定义为开发人员使用AI编程助手的时间占总开发时间的比例。根据模型，影响使用率的因素包括以下四个：

1、信任（Trust）：开发人员对AI编程助手的信任程度，可通过主观评分（1-10分）衡量。

2、自信（Self Confidence）：开发人员对自己能力的信任程度，同样以1-10分的主观评分衡量。

3、偏见（b）：开发人员对AI编程助手的负面倾向，主要受历史经验和环境的影响。 b值越大，使用意愿越低。

4、惯性系数（s）：开发人员维持现有工作习惯的倾向强度。s值越大，越难改变当前开发习惯。

需要注意的是，AI编程助手是通用工具，而非单一功能工具，其模型参数（Trust、Self Confidence、b、 s）会因任务类型而异。例如：

1、开发人员相信AI编程助手可以高效的生成代码块，但未必相信它能高效的修复线上Bug。

2、开发人员对自己实现新功能有信心，但不代表他对架构重构有同样的自信。

3、开发人员在个人项目中敢于大胆尝试 AI 编程助手，但在商业项目中会因为风险而更加保守。

4、随着信任程度的提升，代码块生成的使用率增长会快于简单重构(可以用快捷键完成的重构)。

如何提高AI编程助手的使用率？

根据模型，我们可以采取以下措施来提高使用率：

1、提高信任(Trust)

2、提高自信(Self Confidence )

3、消除偏见( b )

4、降低惯性（s）

AI编程助手的信任模型

什么是信任？

这里我使用的是论文《Trust in Automation: Designing for Appropriate Reliance》[2]对信任的定义：信任是个体在不确定或易受伤害的情境下，认为代理(比如AI编程助手)能帮助自己实现目标的一种态度。

信任模型

关于信任，有各种各样的模型来描述它的组成部分。有的将其描述为能力、诚信、一致性、忠诚和开放性。有的将其描述为可信度、可靠度、亲密度和自我导向[4]。还有的将其描述为能力、仁慈和诚信[5]。

这里我采用的是对自动化工具更加友好的，论文《Trust in Automation: Designing for Appropriate Reliance》[6]中的模型，其将信任的组成部分描述成任务表现(Performance)、任务过程(Process)和设计意图(Purpose)。

其中：

• 任务表现()：AI编程助手当前和历史的表现情况，包括稳定性、可预测性和能力等特征。它主要在具体的任务和使用场景中进行体现。例如

  • 是否熟悉开发人员所在的领域

  • 是否熟悉开发人员的任务上下文

  • 是否可以理解开发人员指定的任务

  • 是否可以在预期的时间内完成任务

  • 是否可以保证任务完成的质量

  • 是否可以多次使用时稳定的完成任务

• 任务过程()：AI编程助手如何完成任务，包括可靠性、开放性，一致性和可理解性等特征。它主要在行为方式中进行体现。例如

  • 是否会针对开发人员的任务提出好问题

  • 是否可以在实现之前给出详细计划

  • 是否可以保证实现和计划描述的一样

  • 是否可以按照开发人员的最佳实践来完成任务

  • 是否遵守开发人员的指令

  • 是否尊重开发人员的反馈

  • 是否允许开发人员随时打断

  • 是否有完善的权限控制机制

  • 是否可以方便的退出和恢复环境

• 设计意图()：AI编程助手的设计意图和开发人员目标的一致程度。例如

  • 是否存在幻觉

  • 是否可以保证数据安全

  • 是否可以保证合法合规

  • 是否存在恶意操作

  • 是否存在故意欺骗

  • 是否尊重开发人员的目标

如何提升我们对AI编程助手的信任程度？

1、提供最新的高级模型

2、分享成功的使用案例：降低学习曲线

3、内部运作原理：了解AI编程助手的设计意图，既可以让开发人员更好的使用，也可以增加信任程度

4、解决过程可视化：方便及时调整

5、BadCase分析：避免踩坑

如何提升

关注和衡量

发现关键行为

把自己作为用户，去亲自体验 AI 是否可以提效，找了一个日常的需求，经过描述之后，发现 AI 无法直接给出满意的回答，同一个简单的需求，试了 3-4 轮始终无法达到自己的期望。经过和 IT 装备的开发人员求助之后，对提示词进行调整之后，效果有显著的提升，因此，我意识到，关键是要针对实际的业务场景，输出最佳实践，这样其他开发人员根据场景，基于最佳实践，第一次就能得到一个比较好的效果。

利用六种影响力来源

自我动力

1、让用户主动做出选择：对种子用户进行访谈，了解对 AI 的态度

2、创造直接的体验：针对种子用户，亲自结对使用 AI，了解用户的痛点

3、用故事打动人心：通过展示其他人的优秀案例，了解 AI 带来的效率提升

4、把苦差事变成打榜：比如，比拼谁的优秀案例多，案例多的及时奖励

自我能力

1、提供提示词的赋能

2、给出需求的拆分指导

3、

社会动力

1、意见领袖：部长亲自发言，软件教练、CMC 主任亲自使用 CodeMate 并给出指导

社会能力

1、成立专项的试点组织：

系统动力

1、在办公区增加相关的横幅宣传：比如让 AI 给我打工，未来只有两种人，能用好 AI 的和用不好 AI的 

系统能力

1、每个 PL 团队进行 AI 相关的赋能：CodeMate 使用、提示词使用指导、AI 优秀实践学习

1、AI 优秀实践发布会，PDU部长亲自讲话，软件教练现身指导，AI 优秀实践月度榜单瓜xx 礼物，秘书每日宣传、CMC 对榜单中实践有效性进行评审。

4、能提升多少？ 不知道

不知道的原因是，对于其中任一项都可以进一步拆分，例如

对于需求开发，可以进一步拆分为前端、APP、后端（各种语言、算法等）。

对于后端进一步可以拆分为应用开发、中间件开发、内核开发、算法开发。对每一层的开发场景来说都是不一样的。

那么，是不是没法回答呢？或者说如何回答？

要回答这个问题，就需要针对每个团队、进一步细分场景，评估每个场景AI的胜任能力。这个时候，才能比较客观的评估AI对研发的提效情况。

AI 工具的能力

1、结果的稳定性

2、在特定成绩能力成熟度

3、在AI的边界

AI工具是和软件开发人员一起协作的，目前度量上的影响因素，根据对AI工具在各个阶段进行评估

1. 开发任务的难度：纯文本，多模态，代名仓规格，技术复杂度，业务复杂度

1. 开发人员使用AI工具的意愿

1. 开发人员使用ai工具的能力：prompt描述准确度

1. ai工具的能力边界：解决任务的难度，由上下文长度，生成速度，输出结果稳定性(版本之间结果的稳定性)，代码质量(意图理解能力)，可扩展性(方便定制)，可观测性，用户体验

各个因素直接的关系

1. 软件开发人员的能力和ai工具的能力的关系：ai如果只具备初级开发能力，那么，你让一个高级开发工程师去让他干活，显然是降低效率的。

1. 使用ai熟练程度：哪些任务可以使用ai，哪些任务不能使用ai，需要软件开发人员对ai工具有一个清晰的认识，才能在合适的场景下合适使用ai。开发任务的场景是确定的，

1. 开发任务的难度和ai工具能力：如果让一个初级能力的ai去开发一个超出ai工具能力的任务，显然是降低效率的

1. 开发人员使用ai工具的意愿

不知道能提升多少，不代表不能提升

理想的情况是，如果一个软件开发人员

1. 愿意使用AI，越使用AI，效果越好

1. 对一个需求进行功能分析，拆分为不同的功能点

1. 准确评估开发场景AI是否能胜任，评估越准确，AI胜任的部分使用AI越多，提升效率越高；AI不胜任的部分人工开发，降低试错的成本

1. 使用AI的能力越熟练，提升效果越明显

那么，一定能提升开发效率，此时，使用得越多，提升的效率越明显。但是具体能提升多少，无法准确度量。

问题转换为

1. 增加开发人员使用AI的意愿问题

1. 提高开发人员需求拆分为AI友好的粒度

1. 提高开发人员对任务判定的能力：AI工具自动评估任务是否可以解决：当前ai工具不具备，需要开发人员来判断

1. 提高开发人员使用AI生成代码能力：AI能解决功能点，生成准确的代码

难点

如何定义任务的粒度：任务显然是不是一个需求，而是一个个功能点，而功能点的粒度的大小由实际验证后才能确定。可能是一个crud的'中的一个接口，也可能是一组接口接口，

1、不同AI的能力不同，功能点的粒度也不一样，

2、模型是迭代的，因此，即使是同一模型，也会发生变化

以上做到了，开发人员适应AI工具的意愿自然就高了，剩余思维惯性的用户，强推即可

开发人员对AI工具的意愿由两个因素影响

1. 惯性：习惯了已有的工具，不愿意切换

1. 偏见：对ai的能力不清楚，自认为无法解决自己的问题

评估开发场景AI是否能胜任由两个因素影响

1. 对ai能力和使用的熟悉程度

1. 对任务的评估准确度

如何提升开发人员使用ai的能力

AI的能力影响因素

1. ai工具能力随着版本的更新在软件开发任务的能力总体上是提升，但是在具体的任务上可能存在反复

1. 当前与ai交互的唯一难度是如何准确描述需求让ai一次生成期望的代码

措施

AI提升开发效率是一个系统工程，对各方的诉求如下

维度	维度
组织	1、领导公开鼓励开发人员在开发过程中使用AI 2、认知到AI前期探索需要一定工作量，并预留工作量用于AI能力的探索 3、对探索最佳实践的开发人员给予激励 4、每个团队设立AI知识工程角色
AI能力构建者	1、重视用户体验的提升 2、清晰的发布范围：版本发布明确支持的场景，根据评测集输出评测报告，优秀实践，指导开发人员快速判断AI边界 3、开放的架构：让开发人员能快速根据具体场景定制。比如，工具注册机制、Hook机制、上下文定制等等
AI工具运营者	1、梳理领域的技术场景，并针对典型任务进行探索和评测，输出AI能力的评估报告和优秀实践 2、持续分析AI工具的使用情况，对于使用不积极的开发人员进行访谈
开发团队	1、AI友好的开发规范：需求和功能描述要使用markdown，mermid进行流程图等 2、AI友好的需求：需求的拆分的粒度与AI支持的能力匹配 3、熟悉AI的工具：学习AI边界，AI擅长的部分依据最佳实践进行需求开发；AI不支持部分尽量自动化 4、积极探索：探索AI在新场景的能力匹配度，并贡献案例，注：AI无法胜任某种场景也是最佳实践

场景的来源：以团队为粒度，梳理团队典型开发场景，以其中一个团队探索的场景作为基线，其他团队参考后不断完善

任务的粒度问题：任务的力度会随着ai的能力变化而变化，刚开始可以小一些(函数级，或类级)，逐步扩大。

常见问题

1、AI在同一场景存在不稳定：这是存在的，而且是比如会出现的，比如，我自己在探索中就发现，在某场景的任务中，A任务在第一次在X地方表现不太理想，在第二次又在Y地方表现不太理想。

AI本身存在幻觉，使用得当，整体是能提效的。

2、场景如何分类？

场景是否能穷尽？场景应该基于业务还是基于技术？场景基于技术，技术点相较于任务来说，更容易穷尽而事实上，经过验证，同一技术点的能力，在不同业务下都表现相对很稳定。

未来畅想

1. AI自动对需求进行拆分，AI支持的场景自动生成AI不支持的场景，留给开发人员

当ai提效降低的成本-投入ai的成本>0，此时，才能说，ai辅助效率提升了

自主权的重要性

处理这类不确定性问题的最佳方式是赋予开发人员自主权，让他们自行决定何时、在何种场景下使用AI编程助手。

AI编程助手的使用率模型

影响因素分析

AI编程助手的使用率(μ)受四个主要因素影响：

1. 信任(t)：开发人员对AI编程助手的信任程度（1-10分）

1. 自信(s)：开发人员对自己能力的信任程度（1-10分）

1. 偏见(b)：开发人员对AI编程助手的固有负面倾向

1. 惯性系数(i)：开发人员维持现有工作习惯的倾向强度

常见现象解释

1. 初级开发人员比高级开发人员使用更多：初级开发人员自信程度较低(s值较大)，导致使用率更高
2. 陌生领域比熟悉领域使用更多：面对陌生领域时，开发人员自信程度较低(s值较大)

如何提高AI编程助手的使用率？

消除偏见(b)

1. 认可使用成本：承认使用AI编程助手需要时间和精力投入

1. 加强信息共享：收集成功和失败案例，归纳有效实践

提升信任程度(t)

信任的三个组成部分：

1. 任务表现(Performance)：稳定性、可预测性、能力等

1. 任务过程(Process)：可靠性、开放性、一致性、可理解性等

1. 设计意图(Purpose)：与开发人员目标的一致程度

AI编程助手的信任提升模型

SRK行为模型

将人的行为按认知负荷分为三个层级：

1. 基于技能(Skill-based)：认知负荷最小，依靠潜意识完成

1. 基于规则(Rule-based)：认知负荷中等，依靠规则决策

1. 基于知识(Knowledge-based)：认知负荷最大，需要大量学习和分析

错误分类

AI编程助手的错误可分为三类：

1. 失误(Skill-based Slips)：执行时出错

1. 规则错误(Rule-based Mistakes)：依据的规则错误

1. 知识错误(Knowledge-based Mistakes)：缺乏相关规则或知识

信任提升模型

团队协作

1. 由AI负责人维护模板，确保符合团队最佳实践

1. 模板上传到代码库，团队成员开发时采用

1. 开发人员分析失败原因，补充缺失内容

1. AI负责人识别广泛使用的知识、规则或技能，添加到模板

团队知识库

1. 文档和代码仓是分离的→文档和代码仓都被ai解析

参考

《Trust, self-confidence, and operators' adaptation to automation》: https://www.sciencedirect.com/science/article/abs/pii/S107158198471007X

《Trust in Automation: Designing for Appropriate Reliance》: https://journals.sagepub.com/doi/10.1518/hfes.46.1.50_30392

如何让团队真正接受AI编程助手？