摘要
本文介绍了一款面向全司研发人员的开发助手的设计与实现思路，普及了开发助手的功能和技巧，量化了落地后的效果数据。
首先，分析了市面上已有的AI产品Copilot和ChatGPT的局限性，然后提出了开发助手的设想，包括 集成在IDE、智能代码补全、问答能力、与代码的联动、公司内部知识等。
接着，详细介绍了开发助手解决的典型痛点和方案，包括自动/手动填充上下文、自定义Prompt模板、快速排查报错、对接公司内部系统和智能代码补全。
最后，分享了开发助手不同功能的效果测量思路及数据，并列出未来规划。
一、背景
AIGC是今年最热门的技术趋势之一，在此之前已经有几款出色的AI产品问世。
- 2021年6月，Github和OpenAI合作推出了Github Copilot预览版。Copilot主要提供了更智能的代码补全功能，与传统的基于语法规则的补全完全不同。根据官方实验数据，Copilot显著提高了开发效率：
- 2022年11月，OpenAI发布了ChatGPT，一款基于大语言模型的人工智能问答产品。ChatGPT具备学习和理解人类语言的能力，能够进行对话互动交流，完成撰写文案、方案、代码、翻译等多种任务。这款产品在两个月内迅速获得上亿用户，成为史上用户增长速度最快的消费级应用程序，也成为了全球范围内的热门话题。ChatGPT展现出了解放人类生产力的巨大潜力，从工业界到学术界，从个人到企业，引起广泛关注。与传统的聊天机器人不同，ChatGPT知识渊博，能够满足人类各种需求，并且表现出了一定创造力，这对软件工程领域提供了新机会。
今年，基础平台组做了一款面向公司内全体研发人员的开发助手，开发助手不同于编程工具，会对多种研发活动进行提效，目前已取得不错的用户反馈，覆盖超过 80% 的开发者。
本文有两个目的，对外 分享开发助手的设计与实现思路；对内 普及开发助手功能及技巧。
二、设计思路
一个开发助手应该具备哪些能力、以什么形式提供能力？可以从市面上已有产品进行调研，这里以背景中提到的 Copilot 和 ChatGPT 入手。
2.1 Copilot 的局限性
Copilot 的补全功能能够在用户编写代码时，自动分析已有代码、并在合适时机给出补全建议。开发者们只要开始写代码了，或者编写一段描述代码功能的注释，Copilot 就会开始工作。下图灰色部分即 Copilot 给出的代码提示：
上面的案例比较简单，其实Copilot的补全能力很强，理想情况下，开发者只需要写个开头，然后一路按 Tab 键，不断接受 Copilot 补出来的代码，最终可在短时间内完成整块代码。 理想很美好，现实却残酷，经过近一年实际使用，发现 Copilot 存在一定问题和局限性。
无法控制上下文
Copilot 底层使用 CodeX 模型，CodeX 是 OpenAI GPT-3 模型微调后的版本，一脉相承，用法相似，需要先传入代码上下文作为 Prompt，然后由大模型返回补全出的代码。
目前，Copilot 将组装 Prompt 的逻辑进行了屏蔽，对于用户来说是无感知的，用户无法手动指定上下文，这就有问题了，一旦组装的上下文信息不全，大概率补不出预期的代码，下图就是一个示例：
示例中，Copilot 没有把 Node 结构放到上下文里，因此大模型不知道 Node 里有哪些属性，只能自己猜，最终导致补出来的代码无法编译，不可用。
场景单一，只能输出代码
对于开发人员来说，单纯写代码的时间并不多。根据公司问卷调研数据，代码开发占整体研发活动比例约 23%，因此单纯的补全代码工具对于开发者的整体提效收益有限。
VSCode 插件生态中，Copilot 除了有一个代码补全的插件，还提供了一个类似 ChatGPT 的 Copilot Chat 插件：
该 Chat 插件仍然不支持指定上下文，在国内使用经常出现网络问题，不稳定、影响体验。公司内部主要使用 Java 语言，超八成开发的 IDE 是 IDEA，而 IDEA 生态在搭建开发助手时，还没有 Copilot Chat 插件。
就在最近 11 月 8 号 GitHub Universe 2023 上，Copilot 发布了 JetBrains IDEs 的 Copilot Chat 私有测试版，后续我们也会持续跟进 Copilot 更新。
安全隐私问题
不仅是 Copilot，生成式 AI 类产品的数据安全与隐私风险问题备受关注，争议不断。
大模型通过训练海量数据而生成，其中可能包含大量个人敏感信息。这些信息的泄露可能导致严重的隐私侵犯，给个人带来不可逆转的损失。
此外，大模型的数据安全也面临黑客攻击和恶意利用的风险，可能导致数据泄露、篡改或被用于其他恶意活动。这些问题对于企业来说更为敏感，需要慎重考虑。
2.2 ChatGPT 的局限性
缺少内部知识
ChatGPT 通过学习大量的公共文本数据来生成自然语言的回答，由于其预训练数据主要来自于互联网上的公共资源，ChatGPT 只具备公共知识，而不具备内部知识。内部知识通常指的是特定组织、企业或个人拥有的专有信息，例如公司的内部流程、机密数据或个人的私人信息等。
有使用门槛
ChatGPT 回答质量与提问质量相关，在使用 GPT 时，经常遇到这种情况：某个问题用类似的提问内容，问多次t都没有得到预期结果。然后换了种问法就有了。
如何写好 Prompt、让 GPT 输出更好的答案？这件事并不容易，有一个专门的技术研究这块：Prompt 工程。指针对于 Prompt 进行结构、内容等维度进行优化的AI技术，它把大模型的输入限定在了一个特定的范围之中，进而更好地控制模型的输出。
不难发现 Prompt 存在门槛，对用户来说是个使用负担。如果有现成的 Prompt 模板，用户能直接使用，或者能从模板中学到好的 Prompt 写法，门槛就会有所降低。
缺少与代码间的联动
开发同学的主要工作仍是编码，在编码过程中使用 ChatGPT，存在工具间来回切换（IDE 和 浏览器）、提问/回答内容频繁复制等问题，使用上不够顺畅，这里有很大的用户体验提升空间。
安全隐私问题
和 Copilot 一样，ChatGPT 也存在安全隐私问题，且有时候提问内容会错误命中其校验过滤器。
2.3 开发助手设想
分析完 Copilot 和 ChatGPT 的能力及局限性后，对开发助手有了这些想法：
- 开发者的核心是 coding，coding 就离不开 IDE，因此开发助手一定要长在 IDE 里
- 智能代码补全能力是必须的、核心功能
- 类似 ChatGPT 的问答能力必须有，但要降低用户的提问门槛
- 问答窗口需要和工程源码有双向、顺畅地联动
- 具备公司内部知识，能解答私域知识类问题
- 在问答窗口中，能以交互式完成对其他系统的操作，如：预定会议室
三、典型功能
本节是全文重点，将从实际工作场景入手，介绍开发助手解决的痛点、方案。
3.1 自动填充上下文
痛点分析
让 AIGC 工具生成函数时，开发者必须手动拷贝大量的上下文代码，这样工具才有可能得到准确回答，这个拷贝操作相当麻烦。
举个例子，让 GPT 生成一个 dfs 算法时，必须把函数入参的类结构也提交给 GPT，否则 GPT 会猜测入参对象有哪些属性，这种猜测大概率是错的，最终导致生成的代码没法编译，影响回答质量。
效果演示
开发助手提供了智能分析上下文并填充到提问框的能力，用户选中代码点击AI助手中的"将选中代码片段加入到Chat框"，或使用快捷键 Alt+i 时，除了会将选中的代码复制到提问框，还会将代码相关的上下文自动提交给助手。
如上图，当需要实现一个复制属性的函数，使用 Alt+i 快速将函数签名插入到提问框，并且将相关的类作为上下文传给助手，助手拿到类中的字段后，才有更高概率准确完成函数逻辑。
实现原理
利用 IDEA 框架能力，可直接拿到选中的代码片段及其所在文件。具体来说，利用 IDEA 的 SPI 机制能获取到如下代码片段：
-
（必传）选中函数入参、返回值的类文件：这类数据是显而易见的，必须放到上下文中
-
（必传）选中函数中，调用的其他函数信息（包含入参、返回值）：对于下图这种情况，让开发助手实现 updateOriginChecklist 函数，显然要将 DemandDoc 类结构也放到上下文里
- （可选）选中函数前面、后面的代码片段：当生成的函数实现中，需要调用函数附近的其他函数时，则要将附近函数也传给开发助手
- （可选）相似片段：当要填充的函数和代码库中已有函数，写法类似时，将相似片段传给开发助手，会有更大概率得到高质量结果
- （可选）当前类中 import 导入的类，源码文件
3.2 手动指定上下文
痛点分析
当自动组装的上下文不够用时，可以手动指定上下文。
效果演示
目前提供了三种手动提交上下文的方式，分别对应包、类、代码片段，选中后在右键菜单中可以看到相关功能。
下面是一个实际案例，通过添加 LogUtil 类作为上下文，让开发助手能按照要求打印日志：
3.3 自定义Prompt模板
痛点分析
- 有些问题需要多次使用，每次都重新输入一边，麻烦
- Prompt 工程有学习成本，容易劝退
效果演示
我们提供了多种渠道，帮助用户低成本学会 Prompt 常用技巧：
1、系统内置常用 Prompt 模板，并暴露出模板 Prompt 内容，帮助用户学习好的 Prompt 写法。
2、在公司内部多种渠道（如 大讲堂、wiki）输出 Prompt 工程的技巧，让大家快速上手 Prompt。
3、后续计划，将 Prompt 技巧放在开发助手中，当用户点击开发助手时，会出现不同的 Prompt Tips 和效果示例。
通过上面多种方式，大家逐步掌握了这项技能，就能写出好的 Prompt 了。开发助手支持让用户自定义 Prompt 模板，鼓励大家将好的模板公开出来。下面是新建自定义 Prompt 模板时的表单：
自定义模板时，可以选择创建零到多个参数，参数可在使用时替换成实际值，例如模板 "代码解释"：
| 你现在是一名编程专家，请对代码进行解释，要求：1、分步骤解释2、避免逐行翻译代码，不重要的细节可忽略，对代码按逻辑进行适当聚合3、针对代码中的特殊设计进行解释要解释的代码是： |
|---|
{code} 是用户填写的代码，模板中 ${} 的数量需要和参数列表的参数数量相同。
利用 Prompt 模板功能，可以顺畅地完成各种操作，下面演示两个具体案例，体验一下丝滑的感觉。
3.4 快速排查报错
通过选中报错信息，利用 Alt+i 快捷键，快速将异常堆栈及信息复制到了提问框，然后选择 Prompt 列表中的"排查异常"模板，就快速完成对异常的分析和可能的解决方案。
从动画中可以看出，分析异常的过程顺畅且高效。后续我们计划在异常分析时结合工程源码，让开发助手分析完异常后根据工程信息直接给出修改方式，并支持一键将修改方式应用在工程源码中。有了这个功能后，从异常提交->异常分析->异常修复就都通了。
3.5 对接公司内部系统
痛点分析
目前公司里的各种工具系统非常全面，但各系统的页面是独立的，这就导致开发者们在编码时经常要跳转到其他系统，如 配置中心、PMO 系统等，且有些系统的点击路径很长，导致编码流畅度和效率有降低。
为缓解这一问题，开发助手目前接入了 PMO 系统，可以通过开发助手的聊天框，以问答的交互形式获取到 PMO 信息。
效果演示
利用已提供的 Prompt 模板 "获取用户今天排期的PMO信息"，可以方便的获取到 PMO 信息，不再需要切换浏览器到 PMO 系统上查询。
实现原理 这一功能的实现稍微复杂，我将以问题形式逐步揭晓。
1、开发助手是如何知道提问者是谁的？
开发助手通过主机的环境变量、git 配置、代码仓库等渠道，可以拿到 IDEA 及运行主机的相关信息，其中就包含了工程的编程语言、AppCode、使用的 git 分支、用户 uid 等信息，因此就知道提问者是谁了。
2、如何利用 AI 完成获取 PMO 操作？
以 "请将我今天排期的 PMO 进行关闭" 为例，主流程如下图：
首先，对问题进行路由，交给特定的 PMO 域 AI Agent。AI Agent 可以简单理解为智能体，能像人一样处理专业领域的事情。
然后，PMO Agent 会对问题做规划，按需调用外部工具，拿到结果后，根据结果情况再继续规划后续步骤，这个流程可以执行多次，最终会输出自然语言的结果。
上面的描述可能有点抽象，具象一下，下图展示了 PMO Agent 的完整处理逻辑：
左上角是用户的提问，右下角是输出的回答；左侧一列表示三种动作，分别是 包装提示词、获取并解析 GPT 的输出、调用工具并拿到结果。
3、基于 AI 的实现，和传统软件实现操作 PMO，有什么区别？
表格对比了传统软件和 AI Agent 之间的差异：
| 区别点 | 传统软件 | Agent |
|---|---|---|
| 交互方式 | 基于界面 | 自然语言的交互式 |
| 能力范围 | 解决"点"问题，每个功能一个实现 | 解决"面"问题，实现原子操作后，可由 AI 自由组合 |
| 扩展性 | 一般 | 好 |
| 价值 | 低成本的自动化商品 + 高成本的个性化商品 | 低成本的个性化商品 |
| 角色 | 作为工具，辅助人类 | 可替代人类工作 |
3.6 智能代码补全
和 Copilot 的补全功能类似，开发助手也提供了智能代码补全能力。实现原理是，基于开源大模型的代码补全能力，配合自研的 IDEA 插件进行请求/响应的处理、及补全的渲染，实现了一套极低成本、较低延迟、接受率尚可的代码补全方案。
整体方案较复杂，做了很多工作，包括但不限于 建立效果测试集、部署/评估/优化多个开源大模型、补全功能工程化等，后续会写一篇关于代码补全的文章，详解代码补全在去哪儿的落地方案和实施路径。
四、效果数据
公司内部注重测量，工具的效果一定有数据支撑。本节分享一下，量化开发助手不同功能价值的思路，及落地后量化出的效果数据。
4.1 代码补全
开发助手对于代码补全的效果比较好度量，方案如下：
1、通过在 IDEA 插件里监听用户接受补全的代码事件，可以算出接受的代码总行数及具体代码，即开发助手生成的代码情况。
2、根据 git 提交记录可以分析出用户一段时间内编写的总代码行数，这样就可以计算出同一时间周期内（如 一个月），开发助手生成的总代码行 / 总提交代码行，即为开发助手在编码阶段带来的提效比例。
3、研发活动有很多种，包括 方案设计、编码、自测、解决问题等，编码只是其中一部分，因此计算总提效时，需要乘以编码活动时间占比，公式为：
研发提效比 = 编码占比 * (开发助手生成行 / 总提交行) 在公司内部，实际测量出来的数据为 20% * 10% = 2%，也就是研发提效 2%。
4.2 通用问答
量化开发助手的通用问答价值比较困难，不同的场景中回答所带来的价值差别很大。最终使用了问卷调查来量化提效数据，这种手段需要保证问卷的覆盖度，公式为：
节约总时间 = 单日回答总次数 * 回答有效率 * 有效回答节约时间
目前测量出来实际数据，回答有效率为 0.482，有效回答节约时间为 4.324min。
4.3 操作指令
开发助手支持操作指令，比如 "获取排期的 PMO"。这部分的提效可以细化到每个操作指令，还是以获取排期 PMO 为例：
1、计算如果是手工获取排期的 PMO 需要花费多少时间，现在通过开发助手完成同样的操作需要多少时间，两者之差就是单次节约的时间成本。
2、乘以该功能的使用总次数，得出该指令的总节约时间。
3、将所有指令的节约时间求和，得出总节约时间，公式为：
节约总时间 = ∑ (特定指令单次节约时间 * 使用次数)
五、未来规划
开发助手会持续更新，迭代周期是 1~2 周 1 个版本。最新版本的 IDEA 插件已经具备自动升级能力，大家无需手动升级插件了。
目前 AI 领域发展速度很快，临近完篇时，OpenAI 和微软发布了很多重磅功能，包含 更准确/支持更大 context 的 GPT-4 Turbo 大模型、自定义 ChatGPT 版本、Assistants API、Copilot Workspace，相关链接放在了文末。
未来，开发助手主要会在三个方向继续发展：
- 扩展开发助手知识边界，对接公司内部知识库平台，具备私有知识（开发中，待文章发布时大概率已经上线）
- 以代码为核心，提供特定场景的功能，如 代码可视化（提供业务流程图、链路图等）、代码导航（根据自然语言定位到代码片段，方便读代码）、代码智能优化、代码模板、异常修复
- 结合公司的研发流程，贯穿始终，提供顺畅的流程体验及交互式操作能力
相关链接：
-
OpenAI Prompt Engineering：
-
OpenAI DevDay, Opening Keynote：
-
GitHub Universe 2023：
以上就是本次分享的所有内容，最后为大家带来一个内推信息，欢迎优秀的你加入驼厂~