前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >AutoDev 1.4 规模化 AI 研发辅助:团队 Prompts、自定义活文档、代码检视

AutoDev 1.4 规模化 AI 研发辅助:团队 Prompts、自定义活文档、代码检视

作者头像
Phodal
发布2023-10-25 19:37:37
3930
发布2023-10-25 19:37:37
举报
文章被收录于专栏:phodalphodal

在过去的两个月里,随着 Thoughtworks 内部的大规模 AI 辅助软件交付(AI4SoftwareDelivery)的展开 —— 在全球,有上千名的 Thoughtworker 这一个涉及不同角色、不同地区,以及几十场内部分享的活动。

我们也在 AutoDev 加入了更多的新特性,以持续探索如何在 IDE 里更好的协助团队进行提效。为此,作为目前国内最好的开源 AI 辅助编程工具,我们在 AutoDev 1.4.0 引入了几个比较有趣的特性,以探索规模化的 AI 研发提效。

AutoDev GitHub:https://github.com/unit-mesh/auto-dev

团队 Prompts:代码化 Prompt,以在团队扩散

为了响应我同事们对于 TDD (测试驱动开发)的热情,即 #49 issue 中对于《支持TDD开发模式,根据指定测试生成对应实现》,我们构建了 Team Prompts 的功能。现在,你可以在你的代码库里,直接编写 Prompt,AutoDev 将读取您编写的 Prompt,并成为 AI 辅助功能的一部分。

这意味着:

  • 您可以在团队里,共享你的 prompt,而不再是个性化的配置。
  • 您组织里的不同团队,可以在各自的团队里分享自己的 AI 经验。
  • 您不再需要定制更多的 IDE 需求,只需要提供接口能力即可。

Team Prompts 示例

让我们来看一个简单的示例,首先你需要在你的代码库里创建(或者配置) Prompt 文件夹,然后使用编写你的一系列 Prompt,诸如于 TDD 里可以是:

  • Tasking.vm,用于根据需求拆分出对应的测试用例。
  • TDD-Red.vm,根据生成的测试用例,编写第一个失败的测试。
  • TDD-Green.vm,根据生成的测试,编写、优化对应的实现代码。
  • TDD-Refactor.vm,重构实现的代码。

在这些 prompt 文件里,只需要根据 AutoDev 的配置文件引入对应的上下文变量(参考:https://ide.unitmesh.cc/variables ) 即可。诸如:

代码语言:javascript
复制
---
priority: 2023
interaction: ChatPanel
---
```user```

你是一个资深的软件开发工程师,你擅长使用 TDD 的方式来开发软件,你需要根据新的测试用例,来改进原有的代码实现。

原有的实现代码是:$context.underTestFileCode($methodName)

新的测试代码是:

${selection}

请根据新的测试,优化 class under test 部分的代码。请返回对应的方法的代码,使用 ``` 开始你的代码块:

Prompt 开头的部分是一个 Markdown 的 YAML FrontMatter,用于做一些简单的配置,在这里的 priority 用于配置菜单中的优先级,interaction 即是用于配置交互方式,如:

  • ChatPanel 用于直接输出在右侧的聊天窗口;
  • AppendCursorStream 则是用 Stream (打字机效果)的方式在当前文档输出。

Context 则是内置的一些系统函数,用于提供额外的能力支持。

Team Prompts vs Custom Prompt

在 AutoDev 1.1 中,我们提供了 Custom Prompt 的功能,它的主要意图是为个人提供一些个性化的配置,而 Team Prompts 则是针对于团队来提供团队统一的配置能力。

通过 Team Prompts 这样的方式,我们可以编写一系列适用于不同场景的 AI 指令,并快速分享给团队的所有人。

我们将持续演进 Team Prompts,以更方便地让大家使用。

自定义活文档:持续辅助遗留系统重构

与普通的文档生成、注释生成相对,我们觉得从底层支持对于代码的注释生成,进而辅助系统进行重构显得更有意义。

AutoDev 文档生成

在参考了 JetBrains AI Assistant 的文档生成思想之后,我们也在 AutoDev 中添加了文档生成这种聊胜于无的功能 —— 从个人角度而言,在有了 AIGC 之后,这种功能象征意义大于实际意义。直到我需要我为 Chocolate Factory 添加文档的时候,发现这个功能真好用。

没啥说的,选中一个类、方法、变量,右键一下,或者按一下 Alt + Enter 就可以生成了。如果原先的方法和类中已经有文档,那么将会根据现有的代码和文档重新生成(大概率,取决于 AI 的脾气了)。

如果您在实现的一个对外的 SDK,那么我更建议你采用我们在《开发者体验:探索与重塑》中定义的《文档工程》的方式。诸如于我们在 Chocolate Factory 中提供的,根据测试用例代码和注释来生成真正可靠的代码。

自定义活文档生成

作为曾经的遗留系统重构专家,写过几个流行的重构工具、电子书,以及我们公司同事在大型保险公司的经历来看,直接根据代码生成注解形式的文档,可以大大节省阅读大量的成本。并且在已有的代码 + 新的文档的注释基础上,我们可以更好地构建 RAG 能力,进而快速从代码中梳理出真正有用的知识。

为此在 AutoDev 里,只需要添加一些 examples,就可以让 LLM 来生成对应的文档。示例:

代码语言:javascript
复制
"documentations": [
  {
    "title": "Living Documentation",
    "prompt": "编写 Living Documentation。按如下的格式返回:",
    "start": "",
    "end": "",
    "type": "annotated",
    "example": {
      "question": "...",
      "answer": "..."
    }
  }

再根据不同的场景,生成对应的注解格式,所以你也可以用它来生成 Swagger 注解,这样就可以直接生成 API 文档了。

代码检视

如我们在先前的文档《AIGC 重塑软件工程 Code Review 篇》所介绍,我们是通过在 AutoDev 结合 DevOps 平台来共同完成代码检视的。

IDE 侧应该如何检视代码

在 IDE 侧,我们更推荐的方式是理解业务场景,结合部分的语法问题进行 review。其主要原则是,从我们日常的工作习惯来说,我们会选取多次提交(诸如一个需求的所有代码提交),再进行 Code Review。又或者是单个文件在历史周期上的变化,所以我们在设计上也是围绕于日常的使用习惯来配置的。

结合需求系统的 Code Review

对于考虑 AIGC 来进行研发提效的团队而言,大部分的团队已经具备了相当 DevOps 成熟度,诸如于在提交信息里结合需求 ID 来进行提交,诸如于 feat(devops): init first review command #8

在这种场景之下,AutoDev 会根据这里的 8 去获取对应的需求系统的信息,以此作为业务上下文,来补充我们所需要的业务上下文,进而作为 LLM 的补充信息。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2023-10-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 phodal 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 团队 Prompts:代码化 Prompt,以在团队扩散
    • Team Prompts 示例
      • Team Prompts vs Custom Prompt
      • 自定义活文档:持续辅助遗留系统重构
        • AutoDev 文档生成
          • 自定义活文档生成
          • 代码检视
            • IDE 侧应该如何检视代码
              • 结合需求系统的 Code Review
              相关产品与服务
              腾讯云服务器利旧
              云服务器(Cloud Virtual Machine,CVM)提供安全可靠的弹性计算服务。 您可以实时扩展或缩减计算资源,适应变化的业务需求,并只需按实际使用的资源计费。使用 CVM 可以极大降低您的软硬件采购成本,简化 IT 运维工作。
              领券
              问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档