你的团队开通AI编程助手了么？你有没有被天天催着提高使用率？你有没有发现很多时候团队成员都不会使用AI编程助手来写代码？除了常规的知识分享和案例分享，还有没有其他有效的方法可以提高使用率？
自从我所在的团队开通GitHub Copilot以来，上述问题一直在困扰着我，这篇文章就是我尝试解决这些困扰的答案。
为什么要提高AI编程助手的使用率？
在讨论“如何提高”之前，我们得先想清楚“为什么要提高”。
我个人认为这是基于一个核心假设：使用AI编程助手可以提高开发效率，用的越多，效率提高就越多。让我们暂且相信这个假设是成立的，并通过实践来验证它。
那么，我们能强制要求团队成员在所有开发工作中都用AI编程助手生成代码吗？在假设未被充分证明之前，这样做风险极大：万一它不能提高开发效率怎么办？万一它并不是“用的越多，效率提高就越多”又怎么办？我在《如何处理未知问题？》中讨论过，处理这类情况的关键在于减少潜在损失，最好的方式是赋予开发人员自主权——让他们自行决定何时、在何种场景下使用AI编程助手。
在开发人员可以自由决定是否使用AI编程助手的情况下，使用率会自然提升吗？从我所在的团队使用GitHub Copilot三个月后的情况看，开发人员只会在以下场景频繁使用：
- 代码理解
- 方案分析
- 函数级代码重构
- 函数级算法实现
- 单元测试生成
而在这些场景下则很少用：
- 行级代码修改
- 能用IDE快捷键完成的修改
- Bug修复
- 复杂任务的实现（特别是跨文件或跨模块的）
如果没有外部干预，团队的使用模式会基本稳定在这种状态。
那么，我们要采取哪些行动才能提高使用率呢？这就是我们下面要讨论的内容。
AI编程助手的使用率模型
这里我想打个比方：AI编程助手就像一个自动化编程工具，能自动完成开发人员指定的任务。人机交互领域有很多关于自动化工具的研究，我发现《Trust, self-confidence, and operators' adaptation to automation》中的模型特别适合用来解释AI编程助手的使用率：
这里我们将使用率(Usage\text{ }Rate)定义为开发人员使用AI编程助手的时间占总开发时间的比例，从模型中可以看到，影响使用率的因素有四个
-
信任(Trust)：开发人员对AI编程助手的信任程度，可以根据主观感受打1-10分。
-
自信(Self\text{ }Confidence)：开发人员对自己能力的信任程度，可以根据主观感受打1-10分。
-
偏见(b)：开发人员对AI编程助手的固有负面倾向，主要取决于开发人员的历史经验和所处环境。b的值越大，开发人员使用AI编程助手的意愿就越低。
-
惯性系数(s)：开发人员维持现有工作习惯的倾向强度。s的值越大，开发人员越难以改变当前的开发习惯。
需要注意的是，AI编程助手不是一个像重命名快捷键那样的单一功能的自动化编程工具，而是一个通用的自动化编程工具，它可以完成任何编程任务。所以，对于同一个AI编程助手来说，模型参数（Trust, Self\text{ }Confidence, b, s）会随任务类型变化而变化。例如：
- 虽然开发人员相信AI编程助手可以高效的生成代码块，但是这不代表他们同样相信AI编程助手可以高效的修复线上Bug。
- 虽然开发人员对自己在现有架构上高效实现新功能充满信心，但这并不意味着他们也相信自己能高效完成架构重构。
- 虽然开发人员在个人项目中敢于大胆尝试AI编程助手的各种用法，但是这不代表他们在高风险的商业项目中也敢于冒着浪费时间和承担损失的风险去大胆尝试AI编程助手的各种用法。
- 随着开发人员对AI编程助手信任程度的增加和偏见的减少，AI编程助手在代码块生成中的使用率提升和在代码简单重构(可以用快捷键完成的重构)中的使用率提升显然是不同的。
既然每个任务的模型参数都不一样，而且我们很难穷举出所有的任务，那这个模型对我们有什么用呢？我觉得至少有三个作用：
首先，它可以帮助我们分解目标。我们一直将提高AI编程助手的使用率作为目标，这个模型告诉我们这个目标可以被进一步分解成无数个子目标，即提高AI编程助手在各个任务场景下的使用率。如果我们只着眼于最终目标，那必然只会采取一些通用措施，这样势必会出现停滞不前的情况。只有先将最终目标分解为子目标，然后在采取通用措施的基础上，针对不同的子目标采取不同的措施才能推动子目标的达成，从而继续推动最终目标的达成。
其次，它可以告诉我们应该怎么做。这个模型告诉了我们有哪些因素会影响AI编程助手的使用率，而我们要做的就是采取措施来改变这些因素。
最后，它可以帮助我们解释一些现象，让我们清晰的知道导致这些现象的原因是什么，从而避免采取错误的行动。
下面让我们试着用这个模型来解释一些常见的现象。
用模型解释常见现象
初级开发人员比高级开发人员用的多？
在同一个团队内，对于相同类型的任务，大家对AI编程助手的信任程度应该是相差不大的。也许大家对AI编程助手的偏见不同，但应该不会有大的差距。
可能存在的差异是，初级开发人员的自信程度往往要比高级开发人员低，表现在模型中就是Trust - Self\text{ }Confidence值更大，这就导致了初级开发人员的使用率更高。
陌生领域比熟悉领域用的多？
对于同一个开发人员，在面对相同类型的任务时，其对AI编程助手的偏见和信任程度短时间内不会有太大波动。但在面对陌生领域时，其自信程度往往要比熟悉领域低，表现在模型中就是Trust - Self\text{ }Confidence值更大，这就导致了其在陌生领域的使用率更高。
个人项目比商业项目用的多？
对于同一个开发人员，在面对同一领域内相同类型的任务时，其对AI编程助手的偏见和自信程度短时间内不会有太大波动。但在面对商业项目时，其对AI编程助手的信任程度往往要比个人项目低，因为商业项目往往有更高的要求，而更高的要求会降低我们对AI编程助手的信任程度，我们需要更多的信任才能放心将任务交给AI编程助手来完成。表现在模型中就是个人项目中Trust - Self\text{ }Confidence的值更大，这就导致了其在个人项目中使用率更高。
知识和案例分享为啥有效？
当开发人员没有意识到可以在某个任务场景下使用AI编程助手时，他们对其是没有信任可言的。而知识和案例分享可以拉齐大家对AI编程助手的认知，形成最佳实践，减少偏见，并且建立起基础信任，从而提高使用率。
如何提高AI编程助手的使用率？
现在让我们看看依据模型我们可以采取哪些措施来提高使用率。
消除偏见(b)
每个开发人员对AI编程助手的偏见是不一样的，有些人非常乐观，愿意在各种类型的任务中尝试使用，即便失败也不会影响其对AI编程助手的态度。而有的人则非常谨慎，只有当AI编程助手能够在某个类型的任务中证明其效果后，才愿意尝试使用，而且一旦出现失败就会快速放弃。
要消除偏见，我们首先要增强大家使用AI编程助手的动机。例如，我们可以考虑将使用AI编程助手的能力纳入开发人员的能力评估中，鼓励大家在日常工作中尝试不同的使用方法，分享成功案例，总结最佳实践，解决团队痛点，发展他人相关能力等。
然后，我们需要认可使用AI编程助手所产生的成本。AI编程助手的使用是有成本的，开发人员需要时间和精力去编写提示词，审查代码，纠正错误，尝试不同方案。而这些成本有可能是没有回报的，例如在多次尝试之后，开发人员发现AI编程助手无法完成该任务，只能自己手动完成。如果我们不认可这种成本，就意味着开发人员需要自己为该成本买单，那么他们在使用AI编程助手之前就会考率值不值得用，就会变得谨慎起来。
最后，我们要增强团队内部的信息共享。和IDE不同的是，AI编程助手没有固定的使用方法，每个人都可能摸索出成功率高或失败率高的方法，只有加强信息共享，不断的收集成功或失败的使用方法，归纳总结出有效的实践并推而广之，才有可能最大限度消除大家的偏见。
提供更多信息，校准主观感受(Trust, Self\text{ }Confidence)
从模型中我们可以看出，开发人员对AI编程助手的信任程度和他们的自信程度是影响使用率的主要因素，而这两个因素都是开发人员的主观感受，我们需要提供足够的信息来展示AI编程助手的开发效率和他们自己的开发效率，以此来校准他们的主观感受。
例如，我们可以通过标签来识别出哪些故事卡和代码提交使用了AI编程助手，然后对这类故事卡和代码提交的指标进行单独分析，以得到AI编程助手的开发效率。
提升信任程度(Trust)
虽然信任往往指的是人与人之间的信任，但在人机交互领域，信任已经被拓展到了人对自动化工具的信任。
那么，要如何做才能提升信任程度呢？我们将在下一节详细讨论。
AI编程助手的信任模型
什么是信任？
这里我使用的是论文《Trust in Automation: Designing for Appropriate Reliance》对信任的定义：信任是个体在不确定或易受伤害的情境下，认为代理(比如AI编程助手)能帮助自己实现目标的一种态度。
信任模型
关于信任，有各种各样的模型来描述它的组成部分。有的将其描述为能力、诚信、一致性、忠诚和开放性。有的将其描述为可信度、可靠度、亲密度和自我导向。还有的将其描述为能力、仁慈和诚信。
这里我采用的是对自动化工具更加友好的，论文《Trust in Automation: Designing for Appropriate Reliance》中的模型，其将信任的组成部分描述成任务表现(Performance)、任务过程(Process)和设计意图(Purpose)。
其中：
- 任务表现(Performance)：AI编程助手当前和历史的表现情况，包括稳定性、可预测性和能力等特征。它主要在具体的任务和使用场景中进行体现。例如
- 是否熟悉开发人员所在的领域
- 是否熟悉开发人员的任务上下文
- 是否可以理解开发人员指定的任务
- 是否可以在预期的时间内完成任务
- 是否可以保证任务完成的质量
- 是否可以多次使用时稳定的完成任务
- 任务过程(Process)：AI编程助手如何完成任务，包括可靠性、开放性，一致性和可理解性等特征。它主要在行为方式中进行体现。例如
- 是否会针对开发人员的任务提出好问题
- 是否可以在实现之前给出详细计划
- 是否可以保证实现和计划描述的一样
- 是否可以按照开发人员的最佳实践来完成任务
- 是否遵守开发人员的指令
- 是否尊重开发人员的反馈
- 是否允许开发人员随时打断
- 是否有完善的权限控制机制
- 是否可以方便的退出和恢复环境
- 设计意图(Purpose)：AI编程助手的设计意图和开发人员目标的一致程度。例如
- 是否存在幻觉
- 是否可以保证数据安全
- 是否可以保证合法合规
- 是否存在恶意操作
- 是否存在故意欺骗
- 是否尊重开发人员的目标
如何提升我们对AI编程助手的信任程度？
首先，我们需要向开发人员提供最新的高级模型。最新的高级模型有较低的幻觉率，更容易服从开发人员的指令，拥有的知识也更加丰富。
其次，我们需要持续的向开发人员分享成功的使用案例。成功案例的分享有助于让开发人员对AI编程助手能做的事情有一个基础概念，可以建立起基础信任。
之后，我们需要向开发人员讲解AI编程助手的内部运作原理。通过了解内部运作原理，开发人员可以更加了解AI编程助手的设计意图，既可以让开发人员更好的使用，也可以增加信任程度。
然后，我们需要让AI编程助手解决问题的过程变得更加透明化、易于理解和易于交互。如果我们能确定AI编程助手在使用正确的方式解决问题，那么结果也不会太差。
最后，我们要持续的收集开发人员失败的使用案例。失败的案例可以让我们知道AI编程助手在哪种场景下表现的不好，从而可以分析失败原因，找到措施来提升其在该场景下的表现。
那在实际项目中我们该如何落地呢？我们将在下一节详细讨论。
AI编程助手的信任提升模型
在讨论信任提升模型之前，我需要先介绍一下SRK行为模型(Skill-Rule-Knowledge Behavioral Model)。
SRK行为模型(Skill-Rule-Knowledge Behavioral Model)
SRK行为模型将人的行为按认知负荷的大小分为三个层级：
- 基于技能(Skill-based)的行为：认知负荷最小，我们依靠潜意识就能完成该行为。例如使用快捷键修改变量名、运行单元测试、启动本地开发环境等。
- 基于规则(Rule-based)的行为：认知负荷中等，我们依靠规则做出决策并完成相应的行为。例如修改代码时根据开闭原则新建类、重构时根据坏味道去除重复代码、实现时根据YAGNI原则避免过度设计。
- 基于知识(Knowledge-based)的行为：认知负荷最大，通常在我们面对从未遇到过的问题时出现，这时我们没有任何现成的规则可以参考，需要学习大量的知识和进行大量的分析才能进行决策并完成相应的行为。例如Bug的修复、架构设计、老旧系统迁移等。
行为错误分类
根据SRK行为模型，我们可以将AI编程助手的错误归为以下三类：
- 失误(Skill-based Slips)：行为本身是正确的，但在执行的时候出错了。例如AI编程助手表示要安装某个依赖，但生成的安装命令却是错的；AI编程助手想要读取命令行输出，但读取失败。
- 规则错误(Rule-based Mistakes)：行为本身是错误的，原因是产生该行为所依据的规则是错误的。例如，AI编程助手在完成任务时先写代码再写测试，没有按照TDD先写测试再写代码；AI编程助手在已有模块里添加大量逻辑，没有拆分到新的模块。
- 知识错误(Knowledge-based Mistakes)：行为本身是错误的，原因是缺乏可依据的规则或相关知识来做出正确的决策。例如，AI编程助手没有将最新的语言特性纳入训练集，导致生成过时的代码；AI编程助手不理解项目的专业术语，导致生成错误的代码。
信任提升模型
我们要提升对AI编程助手的信任，首先需要建立赋能团队来推动整个过程。其次，我们需要将AI编程助手和开发人员的表现可视化，以便校准我们对AI编程助手的信任程度以及我们的自信程度。最后，我们需要建立一个完善的知识分享平台，让每个人都能及时了解公司的AI战略、成功或失败的使用案例、AI编程助手的使用方法和内部运行原理等信息。
基于以上措施，我们需要采取试验-错误-改进(Trial-and-Error)的方式来改善AI编程助手的行为。在这个过程中，我们要持续的进行试验并收集失败的使用案例，从中识别出导致低信任度的行为，并进行相应的改进。
对于识别出的行为，我们需要根据信任模型对其进行分析，找到造成低信任度的原因。例如，模型幻觉度高是AI编程助手的设计意图(Purpose)出现了问题；没有按TDD实现需求是AI编程助手的任务过程(Process)出现了问题；读取不到命令行的输出内容是AI编程助手的能力(Performance)出现了问题。
设计意图(Purpose)的问题需要公司去分析，因为它会涉及到AI编程助手的采购。例如，幻觉度高可能是因为合同中没有启用高级模型，数据泄露是因为AI编程助手没有完善的数据保护机制等。公司需要根据分析结果决定是要更新合同还是选择其他的AI编程助手，以确保AI编程助手的设计意图与我们的目标一致。这类问题的改进对我们增加对AI编程助手的信任程度影响力最高。
任务过程(Process)的问题需要团队去分析，因为每个团队的实践不同，任务过程也不同。例如，没有按TDD实现需求可能是AI编程助手选择了传统的实现方式；直接生成代码却没有任何解释可能是AI编程助手选择代码优先以更快完成任务；实现之前看不到任何计划可能是AI编程助手选择先做再想的模式完成任务。团队需要根据分析结果为AI编程助手补充缺失的技能、规则或知识以优化任务过程。这类问题的改进对我们增加对AI编程助手的信任程度影响力中等。
任务表现(Performance)的问题需要开发人员去分析，因为每个开发人员面对的任务是不一样的。例如，使用错误的框架可能是AI编程助手不了解当前项目的技术栈；无法读取命令行的输出内容可能是AI编程助手命令行集成出现了问题；生成巨大类可能是AI编程助手没有遵守开闭原则。开发人员需要根据分析结果为AI编程助手补充缺失的技能、规则或知识以得到更好的任务表现。这类问题的改进对我们增加对AI编程助手的信任程度影响力最低。
信任提升模型在GitHub Copilot中的应用
系统指令模板
根据上节的信任提升模型，我们需要从知识、规则和技能三个层面改善GitHub Copilot的行为，所以我们设计一个系统指令模板，它包含了三部分内容：
Knowledge用于解决知识错误。在发现GitHub Copilot出现知识错误时，我们可以将缺失的知识加入该部分。例如，系统架构、代码规范、技术栈等信息。
Rules用于解决规则错误。在发现GitHub Copilot出现规则错误时，我们可以将该场景下适用的规则加入该部分。例如，收到问题先进行问题界定、实现之前先制定方案、实现时使用TDD等规则。
Skills用于解决失误。在发现GitHub Copilot出现失误时，我们可以将缺失的技能加入该部分。例如，问题界定、方案制定、TDD等技能。
团队协作
上述模板主要由团队中的AI负责人进行维护，他需要保证GitHub Copilot的开发过程符合团队的最佳实践。在上述模板中，我们加入了问题界定、问题规划、TDD、大声思考、运行测试、运行命令等开发过程中的最佳实践。
上述模板会被上传到代码库中，这样每个团队成员在使用GitHub Copilot进行开发时就会采用上述最佳实践。但这并不能保证GitHub Copilot可以成功完成所有任务，只能说它可以提高任务的成功概率。对于失败的任务，开发人员需要分析失败的原因，将GitHub Copilot缺失的知识、规则或技能添加到系统指令模板中，这样系统指令模板就慢慢变成了这个代码库独有的系统指令。
AI负责人需要了解每个代码库的系统指令，识别出被广泛使用的知识、规则或技能并将其添加到系统指令模板中。
通过这种方式，团队对GitHub Copilot的信任程度会越来越高，使用率也会越来越高。
总结
AI编程助手就像是一个新员工，尽管它可能具备强大的能力，但我们仍需要对其进行重新培训，使其符合我们的价值观，遵守我们的最佳实践，并掌握我们所需要的技能。只有在我们充分信任它时，才有可能将重要的任务交给它完成。
我们不能单纯的追求AI编程助手的使用率或代码生成率的提升。从代码提示的角度来看，其使用率可能已经达到100%，因为许多AI编程助手的这个功能是默认开启的，每位开发人员在编写代码时都会用到。然而，尽管行级别的代码提示功能比普通插件强大，但对开发人员的帮助仍然有限，无法降低他们的认知负荷，从而无法提高开发效率。我们期望开发人员在高认知负荷的复杂任务中更多地使用AI编程助手，以提高开发效率。我们希望的是AI编程助手能够减轻开发人员的工作量，在复杂任务中给予更多的帮助，这就需要提升开发人员对其的信任程度。
与IDE这样的即插即用工具不同，AI编程助手需要不断的改进来增加我们对它的信任程度。这种改进可以由设计者通过版本更新来完成，也可以通过开发人员的定制化配置来实现。如果只能由设计者更新版本来完成，这意味着开发人员需要被迫接受设计者的意图，在高度不确定的开发场景中，信任程度是很难被提升的，也就很难被推广。若设计者既能提供通用默认配置，又允许开发人员通过定制化的知识、规则和技能影响AI编程助手的行为，则可在高度不确定的开发场景中提升对其信任度。
回到最初的问题，我们之所以使用AI编程助手，并非因为它已经被证明可以提高开发效率甚至替代开发人员，而是因为我们不想错失这种可能性。因此，即使尚未被证明，我们也要在可控的风险下边使用边对其进行验证和改进。其中的关键就是要验证我们对AI编程助手的信任可以达到什么程度，以及我们能把信任提升到什么程度。我们可能在某些场景下十分信任AI编程助手，也有可能在所有场景都十分信任AI编程助手甚至将所有任务都交给它完成。前者是我所在的团队目前的情况，而后者还有待进一步提升我们对AI编程助手的信任程度。
