点击此处，立即下载通义灵码！https://tongyi.aliyun.com/lingma/

编码使用实践

通义灵码最佳使用实践参考

通义灵码是JetBrains或VSCode集成开发环境（IDE）中嵌入的一款智能开发助手工具，旨在通过人工智能技术简化软件开发过程，提升开发效率。本文将介绍在开发过程中如何深度体验多种辅助功能。其主要功能包括：通用大模型问答、生成单元测试、提供场景优化、编写说明文档，以及根据您的代码生成高质量AI驱动的代码等。这些功能为开发者提供了显著的便利与效率提升。

快捷键的运用

默认快捷键

通义灵码的多个操作均配备了开箱即用的快捷键，以下列出了几项常用的快捷键。

此外，在通义灵码的问答面板中，用户可以通过使用 Cmd+Enter（适用于 MacOS/Linux）或 Ctrl+Enter（适用于 Windows）来实现换行功能。请注意，直接按下 Enter 回车键将立即将当前提问内容发送给模型。

说明：使用更换生成结果快捷键会提高生成的多样性参数（temperature），有时能生成更长或更发散的内容。

自定义快捷键

JetBrains IDE

首先打开菜单栏中的设置页面。
在面板左侧选择“快捷键”（Keymap），随后找到“插件”（Plugins）中的“TONGYI Lingma”子项，展开后即可查看和编辑相关快捷键。

VSCode

请单击 IDE 左下角的设置图标，随后选择键盘快捷方式菜单。

在页面中搜索“TONGYI Lingma”，即可查看和编辑所有快捷键。

说明：为了便于识别，VSCode 的大部分通义灵码快捷键都是以 TONGYI Lingma 命名的，但触发内联建议、显示上一个/下一个内联建议快捷键复用了已经存在系统级功能项，因此命名风格上稍有差异。

配置的运用

配置面板

JetBrains IDE

JetBrains IDE 的配置面板位于设置页面的顶级菜单“TONGYI Lingma”板块。可以通过单击状态栏中的通义灵码小图标，迅速选择“高级设置”项进行访问。

VSCode

VSCode 的配置面板同样可以从状态栏右下角的通义灵码图标点击“高级设置”进入。

常用配置项

按文件类型禁用自动补全功能。

如果某些类型的文件在使用自动补全时产生干扰，可将该文件的后缀类型添加至列表中。多种后缀之间应使用英文逗号分隔（例如：txt,md）。

说明：禁用特定文件类型的自动补全功能主要是指禁用自动补全触发。然而，在文件内通过快捷键手动触发补全（默认快捷键为 Alt+P）时，仍然可以使用大模型的内容自动续写生成的功能。

下拉提示时保留补全结果。

默认情况下，当 IDE 有基于语法的下拉补全提示时，通义灵码会自动停止展示大模型补全内容，避免视觉上的冲突。image

若希望通义灵码总是生成大模型补全，可以勾选该配置项，效果如下图所示，此时按下 Tab 键将会采纳大模型的生成结果。image

生成长度控制。

通义灵码支持将自动触发和手工触发的代码续写能力分别设置生成长度参数。通常建议将手工触发（默认快捷键 Alt+P）设置得比自动触发稍长。

说明：这个配置项只是设置模型允许生成的最大长度，若模型某次补全生成的内容长度原本就较短，通过修改此配置并不能让模型生成的内容变长。

代码注释的运用

通过注释引导补全生成

在缺乏额外注释引导的情况下，模型只能基于当前代码的上下文，以及项目中引用和找到的相似代码来推测接下来可能要编写的内容。当模型的推测不准确时，可以通过增加代码的方式来引导模型实现所需的代码。

例如，在以下这段代码中，模型首先推测了一个 CHAT_CONTEXT 字段，然而并不是我们所期望的内容。

接下来，我们添加一行注释，以指示模型下一个字段为历史记录。随后，模型生成了符合预期的字段及其相应的数据填充代码。

使用描述生成方法

通过“编辑区的代码注释引导补全”或“使用通义灵码问答面板”，均可实现基于注释生成整个方法的目标。由于通义灵码的智能问答场景所使用的模型参数量通常大于代码补全模型的参数量，因此，对于这类场景，通常建议在问答面板中直接提出所需生成的问题描述。

如果对期望生成的语言或方法签名（包括方法名、参数类型、返回值类型）有特殊要求，请在提问时详细描述该方法签名。

跨文件索引的运用

及时保存文件并更新索引

通义灵码的跨文件索引是抑制代码幻觉的重要机制。通过自动识别当前上下文中所涉及的类型和方法定义，模型能够感知项目中其他文件的类型所包含的成员以及方法所具有的参数。在首次打开新项目时，通义灵码将自动创建项目的文件索引。此后，每次保存文件时，将触发单个文件的增量索引更新。然而，由于集成开发环境（IDE）中的文件通常存在内存缓存，在刚刚编写完一个文件后切换到另一个文件时，可能因本地索引尚未更新而无法识别新增加或修改过的内容，仍然按照原有的类型结构进行推理。例如在某代码项目中，我们为 Pet 对象新增了一个 saleable 属性。

随后切换至另一个文件，尝试让大模型进行补全，但模型推理出的逻辑使用的是另一个不太相关的字段。

若要消除这种信息差异，建议在编辑完前一个文件后，主动按下文件保存键快捷键Ctrl+S，然后再继续编辑其他文件。这样生成的内容将能够正确引用到修改过的对象结构。

针对MyBatis场景的优化方案

除了 Java、Python、JavaScript 等主流编程语言项目的跨文件引用功能，通义灵码还支持在编写 MyBatis 的 XML 文件时自动识别 Mapper 对象所引用的表结构类型。例如，在编写如下的 insert 语句时，插件会利用当前项目中的 TexiOrder 类型信息，确保生成的每个字段都为正确的。

及时清理上下文信息

适时清空上下文

在同一次会话中，前文的对话内容会在每次向大模型提问时，自动作为上下文提供给模型。当实际提问的是一个与前文无关的问题时，这些额外信息可能会对模型的回答产生干扰。

此时，用户可以单击问答面板顶部的新建会话按钮，以在新的会话中进行提问，或使用/clear context命令清空上下文，以减少前文对后续问答的干扰。

查看历史对话记录

在创建新的会话后，如需查找之前提问的内容，可利用历史记录功能返回至先前的话题，并继续进行追问。

基于代码提问

通用问答

若需要基于特定代码段的内容进行提问，除了可以直接将代码内容粘贴到问答区外，还可以先在代码编辑器中选择一段代码，然后在问答区针对该段代码进行提问，例如。

内置代码任务

通义灵码插件内置了四项代码任务：解释代码、生成单元测试、生成代码注释和生成优化建议。通义灵码大语言模型针对这些任务进行了专项训练。例如，在生成单元测试的情况下，使用内置任务的效果优于先框选代码后再输入生成单元测试的方式。
代码任务有三种使用方式。其中最常用的方式是在方法定义的开头，点击通义灵码的小图标，并在下拉选项中直接选择所需执行的任务。

a. 第一种方式，是使用IDE下拉菜单的方法。

b. 第二种方式，选择代码后右键单击鼠标，并从上下文菜单中选择“通义灵码”选项。整屏示例@1x

c. 第三种方式，选择代码后在问答面板输入斜线（/）以激活内置任务菜单，接着选择相应的任务。整屏示例@1x

提示词的使用技巧

在提问中引用所选代码

在提问时，如果同时在代码编辑区选择了文本或代码段，所选择的内容将自动以 Markdown 引用格式附加到提问内容的末尾。因此，若在提示词中提及所选择的代码，应使用“如下代码”或“以下内容”，例如。

正确的说法：请检查以下代码是否存在下标越界风险。
错误的说法：请检查选中的代码是否存在下标越界风险。（模型并不知道选中的代码是什么）

在使用命令时，请附加相关信息。

通过在命令后追加更多的辅助信息，可以为问答提供更为丰富的上下文，从而获得更符合预期的回复。

通过多轮对话生成有效代码

在与大语言模型进行对话时，提供的上下文越丰富，生成的结果越能符合用户的预期。因此，用户可以在上一轮对话的基础上继续进行问答，从而增加后续提问的上下文信息，这样生成的结果能够更好地反映整个历史上下文。然而，上一轮的历史信息有时可能会造成干扰，此时用户需要适时清空上下文。

在上一轮的基础上，进一步进行深入追问。

为模型提供参考示例

当需要模型按照指定格式输出或遵循特定前置规则时，提供一个参考实例往往能取得更好的效果，而非仅用文字描述。例如，某一程序的运行结果文件可以使通义灵码整理成特定的 JSON 结构文档。首先，打开文件并全选问题内容，然后在问答区域进行提问。对比下述两种提示词，后者能够更稳定地输出预期的数据格式。

提示词1：将测试报告整理为JSON格式，每个测试结果为一个JSON结构。用例名称应放置于name字段，成功与否应记录于success字段，运行耗时需在duration字段中体现（单位为毫秒），测试覆盖率则应放置在coverage字段。detail字段的值为一个JSON，包含每次用例的输入和输出，分别存放于input和output字段中。
提示词2：将测试报告整理为JSON格式，具体格式参照输入报告。

```
…报告内容略…


应输出的数据如下。请根据此示例生成测试报告。

[
{
“name”: “超出有效页码范围时，应返回空列表并提示无更多数据”,
“duration”: 3434,
“coverage”: 80,
“detail”: [
{
“input”: “…”,
“output”: “…”
}
]
}
]


#### 为模型设定身份

与单纯的提问相比，预先向模型提供身份信息能够有效提升生成结果的稳定性和准确性。以生成测试用例为例，首先打开接口文档文件，全面选取文件内容，然后在问答区域进行提问。对比下述两种提示词，后者能够生成质量更高且覆盖率更好的用例。

- 提示词1：请根据以下接口文档生成相应的测试用例。
- 提示词2：您是一位经验丰富的测试工程师，具备对细节的高度敏感性，并能够高效识别潜在问题及边界情况。请根据以下接口文档生成详尽的测试用例，以确保所有预期功能行为均得到验证。

> **说明**：由于优质的提示词通常需要输入较多内容，因此这一部分的技巧与通义灵码即将推出的自定义提示词功能结合使用较为合适。在当前阶段，用户可以选择手动输入或将提问模板复制粘贴到问题中进行编辑。

# 单元测试

## 通义灵码加持的单元测试实践

本文首先讲述了什么是单元测试、单元测试的价值、一个好的单元测试所具备的原则，进而引入如何去编写一个好的单元测试，通义灵码是如何快速生成单元测试的。

### 什么是单元测试？

单元测试是一种软件测试方法，通过编写代码来验证应用程序中最小的可测试单元（如单个函数、方法或类）的正确性。通常，单元测试由开发人员在功能实现过程中或完成后编写，其目的是确保每个最小可测试单元都能按照设计预期正常工作。

### 单元测试的价值

单元测试的价值主要体现在提高软件质量和可靠性，‌确保代码在修改或重构后仍然能够正常运行。‌单元测试的优势包括：

- **提高代码质量**：‌通过发现代码中的错误和漏洞，‌从而提高代码的质量和可靠性。‌
- **提高开发效率**：‌在开发过程中及时发现问题，‌减少开发周期和成本。‌
- **便于重构和维护**：‌确保代码在重构和维护过程中不会出现新的错误和漏洞。‌
- **有助于团队协作**：‌作为团队成员之间的沟通和协作工具，‌提高团队的协作效率和质量。‌

此外，‌单元测试还可以让软件故障尽早被发现，‌避免故障遗留到后期由于定位修复难度带来的更大损失。‌它的可回归性为软件提供了一层安全防护网，‌为软件后续的重构和修改提供了安全保障。‌单元测试还为软件单元如何被使用提供了天然的代码样例使用手册。

### 遵循的原则

好的单元测试就像空气（AIR）一样感觉不到，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化（A）、独立性（I）、可重复执行（R）的特点。

- **A: Automatic（自动化）**：单元测试应能被自动化执行，以便在代码更改时快速确认新加入的代码没有破坏已有功能，通常情况下会将单测接入到持续集成中，每当代码有变更时都会通过持续集成自动触发单元测试。
- **I: Independent（独立性）**：每个单元测试应当是独立的，不能依赖于其他测试的执行顺序或结果。这也要求单测的测试颗粒度必须足够小，只有这样才能满足独立性。
- **R: Repeatable（可重复执行）**：好的单元测试在同样的条件下，每次运行应当给出相同的结果。它不应依赖于外部因素（如网络、数据库或文件系统），需要对这些外部的依赖进行正确的mock 。

除此之外，好的单测还必须要满足有**明确的断言，执行速度快，边界测试充分，覆盖率高**等特点。只有满足这些条件的单测才是好的单测，好的单元测试是对代码质量保障至关重要的一环。

### 如何编写单元测试？

下面以Java语言为例来介绍如何编写单元测试，总体遵循以下几个步骤：

#### 拆分详细的测试用例

##### 考虑分支条件

在编写单元测试时，需要考虑代码中的所有分支。分支包括if、else、switch语句等，每个分支都需要单独测试。例如：

public String classifyNumber(int number) {
if (number < 0) {
return "negative";
} else if (number == 0) {
return "zero";
} else {
return "positive";
}
}


在上述代码中，有三个分支需要测试：

- number<0。
- number==0。
- number>0。

针对每个分支，都需要编写一个测试用例。

##### 寻找边界条件

除了分支，还需要考虑边界条件。例如，对于上述分类函数，边界值是-1、0和1。边界条件测试可以找出可能潜在的问题，确保代码在极限条件下也能正常工作。

#### 制定统一的单测规范

##### 命名规范

单元测试类通常采用 类名Test的形式。例如，如果要测试一个Calculator类，则单元测试类可以命名为CalculatorTest。单元测试方法的命名应当描述具体要测试的内容。例如：

public class CalculatorTest {
@Test
public void testAddition() {
// 测试内容
}
@Test
public void testSubtraction() {
// 测试内容
}
}


##### 存放路径

一般情况下，单元测试类存放的位置在与被测试类相同包名的下面，但在不同的目录中。在标准的 Maven 项目结构中，源代码放在src/main/java，单元测试代码放在src/test/java。

src/main/java/com/example/Calculator.java
src/test/java/com/example/CalculatorTest.java


#### 选择合适的单测框架

Java 常用的单元测试框架有JUnit和Mockito，下面将围绕如何使用这两种框架编写基本的单元测试：

##### JUnit 测试框架

JUnit是Java语言中最著名的单元测试框架。它简洁易用，提供了丰富的注解和断言。

1. 添加JUnit依赖（以Maven为例）：

junit junit 4.13.2 test ```

编写单元测试：

import org.junit.Test;
import static org.junit.Assert.*;

public class CalculatorTest {
    @Test
    public void testAddition() {
        Calculator calculator = new Calculator();
        assertEquals(5, calculator.add(2, 3));
    }
}

Mockito 测试框架

Mockito是一个强大的模拟框架，用于创建虚拟对象，简化单元测试，特别是在测试不易创建的依赖对象时非常有用。

添加Mockito依赖：

<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-core</artifactId>
  <version>3.11.2</version>
  <scope>test</scope>
</dependency>

编写单元测试：

import static org.mockito.Mockito.*;
import org.junit.Test;

public class UserServiceTest {
    @Test
    public void testGetUser() {
        UserService userService = new UserService();
        UserRepository mockRepo = mock(UserRepository.class);

        when(mockRepo.findUserById(1)).thenReturn(new User(1, "John Doe"));
        userService.setUserRepository(mockRepo);

        User user = userService.getUserById(1);
        assertNotNull(user);
        assertEquals("John Doe", user.getName());
    }
}

如何使用通义灵码快速生成单测

在大多数开发者的编程习惯中，通常采用Test Later的方法进行单元测试，即首先编写好代码，然后再为代码编写相应的单元测试。在此背景下，利用通义灵码生成单元测试显得尤为便捷。以下列举几种使用通义灵码生成单元测试的方式。

手工选中代码方式生成

在 IDE 编辑区中，通过通义灵码选中某段代码来生成单测，选中代码后，在灵码的问答框内，通过 /generate unit test来生成与选中的代码对应的单元测试。

说明：使用/generate unit test这个命令时，可以在输入框追加更多的信息，来生成更符合开发者需要的测试用例，如需要支持JUnit5或采用Mockito进行Mock，就可以采用 /generate unit testJUnit5Mockito这样的方式，后面两个关键词被当作前面命令的参数，这样的使用方式，同样适用于其他命令。

使用快捷按钮方式生成

通义灵码插件在每个方法签名的上面都会有一个小图标，单击图标后会弹出相应的命令菜单，选择生成单元测试。

也可以选择要生成的代码块，然后单击右键来选择生成单元测试功能。

采纳单元测试

单测代码生成完毕后，在问答区的代码块右上角，会有三个选项，分别是插入代码，复制和新建文件：

插入代码：会将当前生成的单测代码插入到当前打开的文件中。
复制：即复制代码块的代码，由用户自行选择将代码复制到哪个文件中。
新建文件：会按照Java单测的规范，新生成一个单测类文件，放到指定的目录中（对应单测方法文件所在的test目录下），如果已经存在同名的单测文件，需要用户自主确认是否覆盖原文件。

单测生成追问

如果您对当前生成的单测代码不满意（需要使用特定的单测框架或者生成更多的单测方法），只需在问答区中的输入框输入相应的文本进行追问即可，或者也可以单击预置的单测追问Tag，如示例中追问的Tag ：Retry、Use Mockito、Use Spring Test和Explain code，进行追问，直到生成您满意的单测代码为止。

说明：一般根据代码生成的单元测试，会枚举常用的测试用例，并不会遍历所有的用例。如果您觉得生成的用例不足，建议先采纳当前生成的几个用例，放到测试文件当中。然后，切换到测试文件中，采用代码续写的方式，通义灵码会帮助您续写新的测试用例。

结语

单元测试是重要的编程实践，为编码过程搭建质量围栏。同时，采用测试驱动开发实践中的Test First ，能够显著推动代码设计的演变。通义灵码，可以极大降低单元测试框架的搭建和测试用例编写的工作量。同时，使用通义灵码对单元测试用例保鲜，可以显著提升编码质量。

用通义灵码维护遗留代码的正确姿势

本文首先介绍了遗留代码的概念，并对遗留代码进行了分类。针对不同类型的遗留代码，提供了相应的处理策略。此外，本文重点介绍了通义灵码在维护遗留代码过程中能提供哪些支持。

什么是遗留代码

与过时技术相关的代码：
- 与不再受支持的操作系统或软件库相关的代码。
- 依赖于已淘汰的技术栈或编程语言的代码。
为兼容老旧功能而保留的代码：
- 在现代软件中为了兼容旧版本功能而保留的代码片段。
- 为了确保向后兼容性而不得不保留的代码。
缺乏文档和维护的代码：
- 没有良好文档支持的旧代码。
- 缺乏现代开发实践（如单元测试、代码审查等）的代码。

解决遗留代码的方法

解决遗留代码有以下三种常见的处理方法：

根据上述描述，补充单元测试是一种有效解决遗留代码问题的方法。然而，这种方法仍然存在一些问题：

大量遗留代码缺少单元测试，并且由于代码间的复杂依赖关系，进行测试的成本非常高。
具体的衡量标准却不够清晰，无法定义好的单元测试。
哪些代码需要添加单元测试？

单元测试常见的误区

缺乏断言的假单元测试：开发者可能会采取仅调用函数而不进行断言的方式，以提高覆盖率指标，导致了许多无效的单元测试。
把单元测试当成白盒测试：一些观点将单元测试归类为白盒测试，但实际上应将其视为针对函数签名的黑盒测试。
依赖真实环境的单元测试：阻碍单元测试的主要因素包括惰性和依赖环境配置。若不使用Stub或Mock解除对外部环境（如网络IP、数据库）的依赖，单元测试将难以达到FIRST原则（快速、独立、可重复、自我验证、及时性）。

选择性的进行单元测试

单元测试除了带来收益外，本身也会产生一定的成本。如果从收益与成本的角度分析遗留代码，将有助于明确为遗留代码补充单元测试的策略，此策略被称为选择性单元测试。那么，如何界定成本与收益呢？

遗留代码单元测试的成本收益象限分类

针对遗留代码的单元测试，可以根据其成本和收益进行象限分类。根据下图，对分类标准和各象限进行详细说明：

分类标准

X轴（成本）：代码依赖程度越高，测试成本越大。
Y轴（收益）：代码复杂度越高，质量收益越大。

四个象限

圈复杂度与依赖的概念理解

圈复杂度（Cyclomatic Complexity）：衡量代码中逻辑分支的数量。
扇入（Fan-In）：直接调用该模块的上级模块的个数，扇入大表示模块的复用程度高。
扇出（Fan-out）：一个模块直接调用的其他模块的数量，扇出大表示该模块依赖其他模块越多。

不同类型代码的处理策略

根据上述的分析，遗留代码的处理策略就变得十分明确：

算法类代码（Algorithms Code）：生成单元测试。
协调类代码（Coordinators Code）：进行接口测试。
复杂代码（Overcomplicated Code）：寻找合适的机会进行重构。
琐碎代码（Trivial Code）：不做处理。

使用通义灵码处理遗留代码

1. 了解项目工程

在维护一个工程的遗留代码，首先可通过 @workspace 功能了解整个工程的目的及其涉及的各个模块。

2. 对不同类型代码进行处理

针对算法类（Algorithms）代码生成单元测试

选中需要基于生产代码进行代码生成的部分。在生成时，请注意所需的框架及Mock等依赖信息，可以通过生成单元测试命令后追加相关信息进行补充。如 /generate unit testingCppUTest。

一般而言，基于现有代码生成的单元测试用例数量通常较为有限。如果对单元测试的测试场景及用例数量有具体要求，可以在新生成的单元测试文件中，通过测试函数的续写方式生成更多的单元测试。在续写过程中，通义灵码将尽可能遵循已有用例，以此作为上下文进行参考。

针对协调类代码（Coordinators）进行接口测试

对于协调类代码而言，单元测试并不是一种理想的解决方案，由于存在过多的依赖，测试成本显著提高。针对此类代码，应该采用接口测试或功能测试的方式进行覆盖，然而在编写自动化测试用例时，开发者常常会遇到相关问题。因此，可以通过通义灵码，快速掌握并理解测试框架。

针对用例的编写，可以选择相应的被测函数，并在问答区中直接提问：基于Robot Framework生成以下代码的测试用例。沿着这一思路，同样可以实现相应的Keywords等内容。

超复杂的代码（Overcomplicated Code）找机会进行重构

针对超复杂的代码，可以使用通义灵码的 /generate optimization 命令，以获得针对所选代码的优化建议。代码审查与优化将从语法问题、异常改进、代码整洁度、安全性及风险等多个维度给出相应的优化建议。

针对复杂遗留代码的优化，并不建议开发者们盲目进行全面的优化和重构。遗留代码的变更可能会带来巨大的风险。因此，开发者应根据具体情况，在合适的机会，遵守童子军法则，进行重构和优化。在这一过程中，通义灵码也将为您提供有力支持。

结语

以上便是在处理遗留代码时可参考的实践。处理遗留代码需要深入代码的复杂结构，细致地追踪每一个可能的分支节点。在这一过程中，除了识别并修复潜在的缺陷外，还必须在有限的时间内完成所有任务。为了避免这一局面的发生，最佳的策略是预防代码的腐化，善用工具，并在编写初期遵循良好的编程原则。

企业级能力使用实践

企业代码补全增强使用实践

通义灵码提供了企业代码补全增强的能力，在开发者使用通义灵码 IDE 插件的行间代码生成时，可以结合企业上传的代码库作为上下文进行行间代码补全，使代码补全更加贴合企业代码规范、业务特点。本文将分享如何构建高质量的企业代码库，以及开发者在前端和后端开发场景的使用实践。

适用版本与支持语言

管理员如何准备高质量企业代码库

为确保代码数据的有效处理，我们建议您遵循以下指导原则来准备代码库。这将有助于提升检索的效率与准确性。

准备指南

上传限制仅适用于源代码文件，代码库中应仅上传实际编写的源代码文件。例如，对于Java应上传.java文件，对于C#应上传.cs文件，对于JavaScript应上传.js或.jsx文件等。
请避免上传以下内容。

测试数据与代码：请勿上传测试脚本、测试用例或任何不包含业务逻辑的测试相关代码。
Mock方法：排除所有由模拟方法和工具生成的代码，除非这些代码包含对业务逻辑的具体实现。
构建产物：
- 前端：排除通过构建工具（如Webpack、Gulp等）生成的文件，这些文件通常位于dist或build目录下。
- 后端：排除编译生成的DLL文件及其他所有编译输出。

注释要求如下。

对希望被检索到的函数，在函数头部应添加详尽的注释。
注释应提供充分的信息以区分不同的函数，建议参考注释模板或根据企业规范进行相应调整。

/**
 * 更新指定订单状态。
 *
 * @param orderId 订单的唯一标识符。
 * @param newStatus 新的订单状态。
 * @return boolean 表示更新是否成功。
 */

函数名称规范要求。

如果函数注释较为简单，则函数名称必须能够准确描述其功能。
使用清晰且具描述性的命名方式，例如：exportOrdersToPDF、updateOrderStatus而不是 func1。

上传指南

打包压缩文件：将代码文件打包为.zip、.gz或.tar.gz格式。
代码包大小限制：每个代码包的大小不得超过100 MB。

开发者如何使用企业代码生成增强

插件版本要求

仅适用于 VS Code 1.3.9 及以上版本，以及 JetBrains IDEs 1.3.10 及以上版本。

后端场景使用实践

通过自然语言注释生成代码。

a. 企业代码库代码上传：上传包含所需功能代码的压缩包至企业代码库，例如雪花算法的代码，并确保目标函数遵循注释规范，注释位于函数头部。更详细代码库准备指南请参见上述管理员如何准备高质量企业代码库。

/**
 * 使用雪花算法生成唯一序列号
 * @param workerId
 * @return
*/
public synchronized Long getSnowFlowerId(long workerId){
 long id = -1L;

 if (workerId < 0 || workerId > snowFlowerProperties.getMaxWorkerId()) {
    throw new IllegalArgumentException(
      String.valueOf("workerID must gte 0 and lte " + snowFlowerProperties.getMaxWorkerId()));
 }

 // ... 算法实现代码 ...
 
return id;
}

b. 输入注释：在集成开发环境（IDE）中定位到某Java类内，输入与期望召回的函数相匹配的注释。注释格式可以灵活，但应确保含义的准确性和一致性。

第一种方式

//请通过雪花算法生成唯一编号的代码，返回生成的id

第二种方式

/**
 * 使用雪花算法生成唯一序列号
 * @param wId
 * @return
*/

注释说明。

注释长度要求：在编写代码时，注释应尽量避免过于简短，建议长度至少15个字符，过短的注释将无法触发召回。
注释语义要求：确保注释的语义准确且有意义，最好包含关键词与返回值说明，以便通义灵码准确地理解和匹配相应的代码。
多语言支持：支持中英文注释，代码库中的注释和实际编码时的注释可以使用不同的语言。
参数名称灵活性：参数名称可以灵活处理，通义灵码会根据提供的参数自动调整以匹配召回的代码。如下反例。
- //雪花算法问题：没有提供足够的信息，注释长度过短。
- //生成唯一序列号问题：没有使用具体关键词，可能会影响理解和匹配效果。

c. 代码生成：首次回车后，灵码将提供基于注释生成补全建议；再次回车后，灵码将根据企业代码库中的代码进行补全。

说明：

如果您的注释中包含参数，灵码将自动调整生成代码中的参数，确保命名一致性。

如果需要刷新缓存获取新的补全建议，macOS可以使用⌥(option) P 手动触发行间补全，Windows可以使用Alt P手动触发。

通过函数签名生成代码。

a. 代码库代码上传：上传包含所需功能代码的压缩包至企业代码库，并确保这些函数具有清晰且独特的标识，以便于检索和识别。更详细代码库准备指南请参见上述管理员如何准备高质量企业代码库。

b. 输入函数签名：在集成开发环境（IDE）中定位到某Java类内，键入目标函数的签名部分。参数名称可以灵活处理，通义灵码会根据提供的参数自动调整以匹配召回的代码。

public List<Object> nextList(String name, int size)

函数签名说明。

函数名称：使用较为清晰的函数名称，需要具备一定语义作为相似性依据。
参数和返回值：类型和顺序需要与目标函数保持一致，但参数名称可以灵活处理，通义灵码会根据提供的参数自动调整以匹配召回的代码。如下反例。
- public List
- public List nextList(int orderId)// 问题：参数类型和返回值类型，与目标函数不匹配

c. 代码补全：首次回车后，灵码将提供代码补全建议；再次回车后，灵码将根据企业代码库中的代码进行自动补全。

说明：

灵码将根据您提供的参数名，自动调整生成代码中的参数名，确保命名一致性。

如果需要刷新缓存获取新的补全建议，macOS可以使用⌥(option) P 手动触发行间补全，Windows可以使用Alt P手动触发。

前端场景使用实践

通过标签补全前端自研组件代码。

a. 代码库代码上传：在开始之前，您需要确保所有必要的前端组件代码已经上传到企业代码库中。如下是React框架示例。

<LTable
      isReady={isReady}
      formInitialValues={formInitialValues}
      rowKey="key"
      tableRef={tableRef}
      toolbarLeft={
          <Button type="primary">新增</Button>
      }
      formItems={formItems}
      formRef={formRef}
      columns={columns}
      request={async (params, requestType) => {
        const res: Record<string, any> = await apiGetUserList(params);
        return {
          data: res.data,
          total: res.total,
        };
      }}
/>

b. 编写组件代码：在您的IDE中打开相应的.jsx文件，并开始编写代码。输入基础HTML标签或自定义组件标签，例如。

c. 代码自动补全：当您输入的代码达到一定长度，并且能够与企业组件库中的代码匹配时，IDE将自动触发代码补全功能，为您生成完整的组件代码。您也可以通过回车，主动触发代码补全。

重要：请在完整的组件标签内触发您的补全。

通过自然语言注释生成代码。

a. 代码库代码上传：上传包含所需功能代码的压缩包至企业代码库，并确保每个函数都遵循注释规范，注释位于函数头部。更详细代码库准备指南见管理员如何准备高质量企业代码库章节。如下是JavaScript示例。

/**
 * 根据报错信息生成，以id为键值的对象
 * @param {Array<validator,Result>} results
 * @return {Record<string,string>}
*/
function getErrObj(results) {
  // ... 函数实现代码 ...
}

b. 输入注释：在IDE中，在JavaScript文件内输入特定的注释内容，如下示例。

//根据报错信息生成以 id 为键值的对象

注释说明。

注释长度要求：在编写代码时，注释应尽量避免过于简短，建议长度至少15个字符，过短的注释将无法触发召回。
注释语义要求：确保注释的语义准确且有意义，最好包含关键词与返回值说明，以便通义灵码准确地理解和匹配相应的代码。
多语言支持：支持中英文注释，代码库中的注释和实际编码时的注释可以使用不同的语言。
参数名称灵活性：参数名称可以灵活处理，通义灵码会根据提供的参数自动调整以匹配召回的代码。

c. 代码生成：首次回车后，灵码将提供基于注释生成补全建议；再次回车后，灵码将根据企业代码库中的代码进行补全。

说明：

如果您的注释中包含参数，灵码将自动调整生成代码中的参数名，确保命名一致性。

如果需要刷新缓存获取新的补全建议，macOS可以使用⌥(option) P 手动触发行间补全，Windows可以使用Alt P手动触发。

常见问题：在重新安装插件后，即便重启IDE或重新登录，仍无法成功召回知识库中的代码。

解决方案：

在macOS系统中，请执行以下命令以重启进程并清除缓存。

ps -ef|grep lingma|grep start|awk '{print $2}'|xargs -I {} kill -9 {}

如果是Windows系统，请在进程管理器中结束Lingma进程。

企业知识库问答使用实践

知识库问答增强：知识库构建与管理指南

通义灵码能够结合企业知识库的私域数据，生成贴合企业特点的回答。充分发挥检索增强技术的优势，构建高质量的企业知识数据以及合理的知识库权限管理是必不可少的。本文将为您详细介绍如何构造与管理一个高质量的企业知识库。

前提条件

适用版本：通义灵码企业标准版、通义灵码企业专属版。
适用人员：通义灵码管理员、组织内全局管理员（专属版）。

场景介绍

通义灵码虽然具备广泛的通用知识，但缺乏企业独有的专业知识和数据。通过引入企业知识库，可以帮助模型更精准地理解私域知识，以便生成更加贴合企业特色的个性化回答。通义灵码能够基于知识库进行自由问答，代码优化与生成，广泛应用于企业规范检查、技术支持等多个场景。

例如：

智能自由问答场景：企业技术新人入职问答、企业安全合规规范问答、产品运维故障排查咨询、企业内部平台、API使用问答等。
代码优化与生成场景：根据企业编码规范，确保代码风格的一致性与规范性；根据安全规范文档检查代码漏洞，并提出修复建议等。

为了最大程度发挥生成的效果，需要从两个方面进行实践。一方面是构建高质量的知识库，确保知识数据的质量；另一方面是清晰的知识库权限分配，确保知识库的可见范围符合预期。为此知识库管理员需要：

提供 AI 友好的、高质量的知识数据，如文档或代码等，陈旧或不准确的信息不仅无法带来增益，反而可能会误导模型，影响回答的准确性；
构建一个结构合理、权限隔离的知识库。这不仅保障了数据的隐私和隔离，还保障了知识库的易管理性和可维护性。权限管理混乱的知识库可能会引发数据安全等问题。

构建高质量知识库

通义灵码的企业知识库问答功能，目前已支持通过文档上传的形式，将其转化为检索增强的知识数据，本章节将重点介绍文档类知识数据的准备原则和方法。如需了解代码类请参见。

文档格式要求

格式：支持PDF、CSV、DOCX、TXT、Markdown格式，优先推荐使用Markdown格式。
大小：每次最多上传10个文件，单文件大小不超过 10MB。

单个文档规范

单个文档需要从名称、标题、格式、内容方面检查是否符合文档规范矮的

详细说明与示例如下：

文档类型与命名

类型：推荐使用Markdown格式。相较于Word和PDF，我们推荐使用Markdown格式以获得更佳的文档处理效果。
编码：推荐使用UTF-8编码，以确保字符兼容性最佳。
文档命名：文档名用词简洁明了，不同命名之间应有明显差异，便于模型理解。避免使用含义不明的英文缩写、数字或符号。

文档结构

层级结构：需采用多级标题来组织文档内容，避免将信息堆砌在单一段落。特别是对于专有名词的释义，每个专有名词建议单独成行。
各级标题：各层级标题含义清晰用词简洁明了，不同标题之间有明显差异。避免使用含义不明的英文缩写、数字或符号。避免罗列文章关键词，会对模型造成干扰。

####### 反例

《AK安全使用规范》
【目录】
关键词：AK、安全规范、Access Key
一、定义
Access Key（简称AK），是用于身份验证的一种密钥对，由Access Key ID 和 Access Key Secret 组成。它允许用户通过API调用安全地访问系统服务。本规范旨在明确AK的使用规则，确保系统的安全性与稳定性。Access Key ID是代表用于标识用户的身份。Access Key Secret是代表用于加密签名，保证请求的唯一性和不可抵赖性。
二、使用原则
确保Access Key Secret的保密性，不得泄露给任何未经授权的第三方。遵循最小权限原则授予API调用权限，仅授予完成任务所必需的权限。定期每90天更换Access Key Secret。记录AK的使用情况，并定期审查使用日志，确保没有异常行为，以及在不需要时及时撤销其权限。
三、安全实践
为确保访问密钥（AK）的安全，我们实施了以下简化的安全实践：在生产环境中，我们优先使用环境变量存储AK，避免硬编码；通过配置管理系统统一管理AK，防止其在代码中的直接暴露。同时，我们对日志进行过滤，确保AK的Secret信息不会被记录。我们还定期进行权限审查，确保AK仅拥有执行必要操作所需的最低权限。此外，建立了异常检测机制，以便快速识别并响应任何可疑的AK使用活动。这些措施共同保障了AK的安全和合理使用。
四、 API调用示例
● 示例1
Node.js中使用AK/SK进行API调用：在Node.js中，可以使用axios库来发送API请求，并在请求头中包含AK和SK。例如，使用AK和SK进行签名认证的API请求可能如下所示：
【示例代码块】
● 示例2
Python中使用AK/SK调用API：在Python中，可以使用requests库来发送带有AK和SK的API请求。以下是一个示例代码，展示了如何构建请求并添加签名：
【示例代码块】

####### 正例（注释为优化说明）

《AK安全使用规范》
/*
去除干扰元素：文章开头的目录、关键词等无需召回的内容可以删除，以减少干扰。
专业名词解释：专业名词及其解释应以条目形式列出，以便于模型更好地查找和理解。
/
一、定义
● Access Key（简称AK）：是用于身份验证的一种密钥对，由Access Key ID 和 Access Key Secret 组成，它允许用户通过API调用安全地访问系统服务。
● Access Key ID：用于标识用户的身份。
● Access Key Secret：用于加密签名，保证请求的唯一性和不可抵赖性。
/
避免使用大段落陈述，建议采用分点陈述的方式，以便模型更容易理解
/
二、使用原则
● 保密性：Access Key Secret 必须严格保密，不得泄露给任何未经授权的第三方。
● 最小权限：授予API调用的权限应遵循最小权限原则，仅授予完成任务所必需的权限。
● 定期轮换：定期更换Access Key Secret，推荐每90天更换一次。
● 监控与审计：记录AK的使用情况，并定期审查使用日志，确保没有异常行为。
● 及时撤销：当不再需要使用某个AK时，应及时撤销其权限。
三、安全实践
● 环境变量：在生产环境中，使用环境变量而非硬编码的方式存储AK。
● 配置管理：使用配置管理系统来管理AK，避免直接在代码中出现。
● 日志过滤：确保日志记录中不会出现Access Key Secret。
● 权限审查：定期检查AK的权限设置，确保符合最小权限原则。
● 异常检测：建立异常检测机制，及时发现并处理可疑活动。
/
关于API调用示例部分，示例层级的名字不清晰，其中“示例1”和“示例2”，需要修改为某个示例的具体名字
*/
四、API调用示例
● Node.js中使用AK/SK进行API调用示例
在Node.js中，可以使用axios库来发送API请求，并在请求头中包含AK和SK。例如，使用AK和SK进行签名认证的API请求可能如下所示：
【示例代码块】
● Python中使用AK/SK调用API示例
在Python中，可以使用requests库来发送带有AK和SK的API请求。以下是一个示例代码，展示了如何构建请求并添加签名：
【示例代码块】

文档章节和段落

将相关性强的内容尽量聚集在同一段落或章节内，以确保数据处理文档切片的准确性和相关内容的连续性。
避免指代或缩略关键信息。如果遇到内容相同，避免“同上”或“与某个模块相同”这样的表述，应该具体写明内容。
避免无意义的空行。
建议利用项目符号（如Markdown中的“-”或“*”）和有意义的缩进来分点阐述，可以在一定程度上辅助模型更准确地理解。

特殊内容与媒体处理

当文档段落中出现图片、表格时，应该对应注意以下几点：

文档中关于表格的处理：
- 表格格式要求：表格的第一行应为表头，不要将表格名称作为表格的第一行内容。
- 表格结构说明：对于表格结构没有特别的要求。可以根据内容的需要自由设计列和行。
- 保持样式简洁：建议去除所有不必要的格式，如背景色、字体样式等。表格线条应保持清晰，使用默认的线条样式。
- 补充说明：
  - 企业标准版，由于表格处理能力仍在持续优化，建议在文档中尽量减少表格，或考虑比如文本列表等替代方式来展示表格数据。
  - 企业专属版与私有化版本，通义灵码已经具备了更高级的表格处理能力，可确保表格数据的准确性。
文档中关于图片的处理：
- 优先使用文字：尽可能地使用文字表达信息，如果图像中的文字比较少且包含重要信息，建议将信息转录成文字的形式。
- 添加图示说明：确保所有核心图都有图示说明（即图解或说明），图示说明应清晰地解释图中的主题。
其他通用注意事项：
- 特殊字符：避免包含表情包的特殊字符，以免造成解析问题。
- 页眉页脚、水印、批注：避免包含批注、页眉、页脚或水印，以免造成不必要的干扰。
- 文档背景：文档每页尽可能无背景，复杂背景容易造成干扰。
- 统一文字方向：确保文档中所有文字的方向一致。
- 音视频：避免包含音视频等多媒体内容。

不同类型文档的处理准则

Markdown：建议优先使用Markdown格式。
Word：
- 使用更新格式：优先采用2007版或之后的Word格式。
- 使用全局样式：统一使用全局标题和段落样式。
- 避免字符样式：不要使用字符样式，如特殊字体格式、边框和底纹。
- 使用段落样式：应使用段落样式来保持文档格式的一致性。
PDF：
避免使用图片：不要直接将图像转换成PDF文件。应该将图像中的重要信息转录成文本，并按照本文中的文档规范要求进行组织。
不包含嵌入压缩文件：请确保文件中不包含嵌入的压缩文件。
保持文档单栏布局：避免双栏并排形式，以确保内容被正确解析。
CSV：
- 避免使用图片：不插入图片，以确保文档的文本可搜索性。
- 不嵌入压缩文件：不要在文档中嵌入压缩文件。
- 表头作为第一行：在表格中，将表头放在第一行，不要将表格名称作为表格的第一行内容。
  特别说明：
- 推荐用法：保存FAQ（常见问题解答）中的问答对。FAQ的问题表述清晰明确，答案简洁易懂，使用用户熟悉的术语，突出关键词，以提高检索召回准确度。例如：矮的 (1)

不推荐：在CSV中上传复杂的关系型数据表。可能会导致数据处理时间超长，导致数据处理失败。

多文档规范

在编写文档时，确保多个文档之间做到知识独立、知识聚合、规范统一以及覆盖全面，这样做能够显著提高知识的召回准确度，从而提升整体效果。你可以参考以下准则来进行多文档组织与整理：

知识独立：每个文档应包含独特且非冗余的信息。

在撰写文档内容时，如介绍特性或功能时，检查是否存在与其他文档重叠的内容，并尽量减少重复。
尽量保证每个文档都是自成一体的知识单元，能够独立提供完整而准确的信息。

知识聚合：尽量将与同一主题相关的所有信息整合到一起。

尽量将同一主题的相关知识聚类在一起，避免相关知识过于分散，尽量实现文档内高内聚。

规范统一：确保同类信息在不同文档间保持一致性和标准化。

确保所有文档遵循一致的风格和术语标准。
制定详细的风格指南和术语表，并对文档编写者进行培训，确保他们能够正确应用这些规则。

覆盖全面：确保文档的完整性、及时性、准确性。

确保知识库覆盖问答所需的高频知识。针对需要高精确度回答的问题，知识无遗漏，如对于某个API的咨询，需确保包含了所有相关的接口、参数。
定期对知识库进行审核和更新，补充缺失的知识点，淘汰过时的内容。

遵循上述原则，不仅能帮助企业知识库管理员创建高质量的产品文档，还能提升用户的满意度和体验。通过系统化的方法来组织和维护文档，确保了信息的准确性、易用性和完整性，为用户提供了一个更加可靠的知识资源库。

知识库权限管理

知识库的划分，通常是根据内容主题和可见成员对象来确定。

一方面，可以创建企业内所有已授权开发者可见的通用型知识库，用于共享企业内的规范性文档和指南，如企业代码规范、安全标准等；另一方面，也可以为特定团队或部门创建垂直型知识库，如具体业务的开发文档、培训材料和运维指南，或面向企业新人的技术指南等。

新建知识库

在通义灵码的企业管理台，选择知识管理模块，单击新建知识库，选择智能问答场景，可见范围选择私有-仅知识库成员。

说明：可见范围选择公开则企业内所有已授权使用通义灵码的开发者均对知识库可见，选择私有则可以自定义可见成员的范围，推荐选择私有。

管理知识库可见成员

在通义灵码的企业管理台，选择知识管理模块，选择需要操作的知识库，在知识库的可见成员管理列表中选择添加开发者或移除。如需了解知识库更多操作请参见。

说明：在管理知识库的可见成员时，需确保每位成员仅访问与其职责和工作相关的知识内容。这不仅保护了数据隔离和隐私安全，还减少了不必要的信息干扰，提升了用户的专注度和知识检索的效率。

效能实践

应该如何衡量AI辅助编程带来的收益

本文主要介绍了如何度量研发效能，以及AI辅助编程是如何影响效能的，进而阐述如何衡量AI辅助编程带来的收益。

理解度量：有效区分度量指标

为了帮助研发团队更好地理解和度量研发效能，可以将指标分为三类：能力和行为指标、交付效能指标和业务结果指标。该分类有助于从不同维度评估和改进研发工作。

能力和行为指标：反映团队的实际工作方式和能力，影响交付效率，可以被改进。例如，单元测试覆盖率、代码扫描问题数、持续集成频次、圈复杂度、解耦度（Decoupling Level）等因素。
交付效能指标：反映技术团队的效率，与业务结果有一定相关性，但不直接影响业务结果。例如，速度、吞吐量和质量等因素。
业务结果指标：反映真实的经营情况，直接与公司的收入、规模和成本等相关，可以直接用于绩效考核。例如，营收GAAP、毛利、净利、成本及月活跃用户等数据均可作为业务结果指标。

什么是研发效能，如何度量？

研发效能是指软件研发团队持续、快速、高质量交付有效价值的能力。具体来说，包括以下几个方面：

做正确事情的能力：即交付有效价值。
正确地做事的能力：即持续性、速度和质量三个方面，其中质量是对速度的约束条件，持续性是对速度和质量的一贯性要求。

研发效率的度量

有效的度量能够引导正确的改进行为，决定后续的改进行动。团队的职责范围决定了采用什么样的指标。通常对于技术团队会从以下几个方面进行衡量：

效率：速度（流动效率，单个工作项的流速）和吞吐量（资源效率，单位时间内完成的工作项数量）。
质量：交付质量，即交付物离开团队之后的质量。
员工幸福感：员工幸福感是一个主观性调研指标，与持续性有正相关。

AI辅助编程是如何影响研发效能的？

AI辅助编程以AI为技术手段，提升编程效率，反映的编码的能力和行为。具体可以从以下几个方面衡量：

编码效率：开发者的编码时间占比 × AI生成代码占比 = 节省的开发时间比例。例如，员工有30%的时间花在编码上，AI生成了40%的代码，则可以理解为节省了12%的开发时间。
代码的缺陷密度：代码的缺陷密度是一个滞后指标，反映代码质量，如千行代码缺陷量。
员工编程体验的满意度：员工编程体验的满意度是一个主观指标，反映工具对于员工编程工作的帮助，如工具的易用性和实际工具的使用效果。

编码效率提升

在软件研发过程中，编码效率是影响研发效率的重要因素。除编码效率外，还有许多其他因素对整体研发效率产生影响，主要包括需求质量、协作流程、测试自动化及持续集成/持续交付（CI/CD）的工程能力等。这些因素可归纳为两个方面：个体效率（单点改进）和协作效率（流程改进）。从问题改进的角度来看，可以总结为四个方面：阻塞、返工、负债和失能。

编码时间占比与AI生成代码占比

开发者的编码时间占比 × AI生成代码占比 = 节省的开发时间比例。例如，员工有30%的时间花在编码上，AI生成了40%的代码，则节省了12%的开发时间。

数据来源显示，受访者花费不到三分之一的时间编写新代码或改进现有代码（32%），35% 的时间用于管理代码（包括代码维护 19%、测试 12% 和响应安全问题 4%），另有 23% 的时间用于会议和管理运营任务

综合开发行为的提升

程序员在开发阶段不仅写代码，还包括调试、测试、信息检索等工作。因此，在每项工作中是否有提升点，以及提升了多少，可以形成如下的计算公式：

这里设定一个假设基线，即在没有 AI 工具的情况下，单位工作量的成本是多少。该基线一般在企业内有相关统计数据，如果没有，则可以参考行业统计数据。此外，还需考虑在每个开发行为中，AI提升效率的同时是否会产生额外成本，例如接受代码后仍需进行修改，这可能会影响手工基线的准确性。

无论选择选项一还是选项二，其背后的方法均为：行为 × 效果 = 效率。一般而言，不必过于追求数据的精确性，因为过于精确的统计可能会引导错误的行为或增加额外的管理成本。统计意义上的准确性就够了，其关键在于能够有效回答一个本质问题，并指导相应的改进。

开发效率提升对整体研发效能的影响

根据利特尔法则（Little's Law），速度 = 在制品数量（WIP） / 吞吐量，换算过来就是吞吐量 = 在制品数量（WIP） / 速度。通过AI方式，可以改变以下几点：

交付的速度：单个工作项的速度提升了，吞吐量会增加，在途任务（任务的WIP）也会显著下降。对于待排期需求会是一个很好的消耗，从而减少待排期需求的数量。待排期需求的数量下降，对于整个产品研发的在途需求数（需求WIP）也会下降，进而提升了整体研发速度。
交付的确定性：速度提升，对于软件研发在时间上的确定性会有着与之相应的提升。

员工的编码体验的满意度

为了评估智能编码助手对员工编码体验的满意度，可以通过用户调研的方式获取反馈，并发现可以改进的地方。问卷设计需要考虑三个因素：用户画像、用户满意度、用户使用效率。以下是具体的问卷设计示例：

用户画像

你有多少年的编程经验？
- 不足 1 年。
- 1-3 年。
- 3-5 年。
- 5-10 年。
- 10 年以上。
你在工作中的主要角色？
- 初级开发者。
- 中级开发者。
- 高级开发者。
- 架构师。
- 技术经理。
- 其他（请说明）。
你常用的编程语言有哪些？（多选）
- Java。
- Python。
- C++。
- JavaScript。
- Go。
- Ruby。
- PHP。
- SQL。
- XML。
- 其他（请说明）。
你使用智能编码助手的频率如何？
- 每天多次。
- 每天一次。
- 每周几次。
- 每月几次。
- 很少使用。

用户满意度

你对智能编码助手的总体满意度如何？（打分 1-5 分，5 分最高）
关于使用智能编码助手的一些描述，你的看法是？
- 视觉舒适、操作符合习惯。
- 没有被打扰的感觉。
- 上手成本低、操作流畅。
- 愿意采纳生成的建议代码。
- 编码问题能够得到有效回答。
- 代码和问答生成速度快。
- 较少遇到报错。

用户使用效率

通过使用智能编码助手，你觉得对你的编码工作效率有多大的提升？（单选）
- 显著提升。
- 有所提升。
- 没有变化。
- 有所下降。
- 显著下降。
回想一下，你使用智能编码助手的场景，下方的描述，你的观点是什么？
- 工作更加有成就感。
- 编码时更加自信。
- 使用熟悉的语言时，效率更高。
- 使用不熟悉的语言时，进度更快。
- 减少编写重复性代码。
- 可以保持编码心流。
- 减少搜索引擎使用。

最后，您可能会得到如下方所示的结论：

AI辅助编程的效果如何衡量？

针对“到底使用采纳率合适，还是AI代码生成占比合适”的问题，首先需要明确两者的定义及其计算逻辑：

同时，可能还会有这样的疑问，为什么不使用AI代码生成的入库占比来计算呢？主要原因如下：

版本管理工具无法识别：版本管理工具无法区分代码是由AI生成的还是人工编写的。代码提交的作者是提交人本身，而非AI。
引入复杂度：追求入库率会导致度量变得异常复杂。追求构建并发到生产环境的数量，引入了更多变量。

因此，建议采用最直观的 AI 生成占比来统计编码行为的效果是一个比较推荐的方式。如果无法获得 AI 生成占比，采用采纳率也是一种可取的方式，但过分追求统计精确性的意义不大。

衡量AI编码工具收益的具体方式

为了更好地衡量AI编码工具对效率的影响，可以从以下几个方面进行观测和分析：

工具使用量：
开发者数量：统计使用AI编码工具的开发者数量。
活跃度：统计活跃用户的数量和活跃频率。
行为：某些能力使用的频次，统计特定功能（如代码补全、单元测试生成、代码注释生成等）的使用频次。
效果：采纳或有效生成占比，统计采纳的AI生成代码行数占总变更代码行数的比例。

开发效率提升：通过观测开发者在使用 AI 编码工具前后的编码效率变化，建立相关性。同时，通过“工具使用的行为 x 效果 ≈ 效率”这个简单公式，来获得对于个人开发效率提升的统计。

研发效率的贡献：研发效率涉及多个方面，包括需求质量、协作流程、测试自动化、CI/CD工程能力等，但开发阶段的效率提升对整体研发效率有显著贡献。

从系统思考的方式建立因果关系：从整体系统的角度出发，分析各个行为、效率和结果之间的因果关系。找到关键的杠杆点，即能够带来最大效益的改进点。

度量原则：度量指标需要回答一个本质的问题，即AI编码工具是否真正提升了开发效率。度量指标应引导正确的改进行动，而非误导。

标签：教程,通义,代码,单元测试,生成,使用,灵码
From： https://www.cnblogs.com/tongyilingma/p/18474536

通义灵码实践教程

编码使用实践

通义灵码最佳使用实践参考

快捷键的运用

默认快捷键

自定义快捷键

JetBrains IDE

VSCode

配置的运用

配置面板

JetBrains IDE

VSCode

常用配置项

代码注释的运用

通过注释引导补全生成

使用描述生成方法

跨文件索引的运用

及时保存文件并更新索引

针对MyBatis场景的优化方案

及时清理上下文信息

适时清空上下文

查看历史对话记录

基于代码提问

通用问答

内置代码任务

提示词的使用技巧

在提问中引用所选代码

在使用命令时，请附加相关信息。

通过多轮对话生成有效代码

为模型提供参考示例

Mockito 测试框架

如何使用通义灵码快速生成单测

手工选中代码方式生成

使用快捷按钮方式生成

采纳单元测试

单测生成追问

结语

用通义灵码维护遗留代码的正确姿势

什么是遗留代码

解决遗留代码的方法

单元测试常见的误区

选择性的进行单元测试

遗留代码单元测试的成本收益象限分类

分类标准

四个象限

圈复杂度与依赖的概念理解

不同类型代码的处理策略

使用通义灵码处理遗留代码

1. 了解项目工程

2. 对不同类型代码进行处理

针对算法类（Algorithms）代码生成单元测试

针对协调类代码（Coordinators）进行接口测试

超复杂的代码（Overcomplicated Code）找机会进行重构

结语

企业级能力使用实践

企业代码补全增强使用实践

适用版本与支持语言

管理员如何准备高质量企业代码库

准备指南

上传指南

开发者如何使用企业代码生成增强

插件版本要求

后端场景使用实践

第一种方式

第二种方式

前端场景使用实践

企业知识库问答使用实践

知识库问答增强：知识库构建与管理指南

前提条件

场景介绍

构建高质量知识库

文档格式要求

单个文档规范

文档类型与命名

文档结构

文档章节和段落

特殊内容与媒体处理

不同类型文档的处理准则

多文档规范

知识库权限管理