DevOps|AGI : 智能时代研发效能平台新引擎(上)

devops,agi,智能,时代,研发,效能,平台,引擎 · 浏览次数 : 186

小编点评

## AGI 如何改变研发效能平台? **1. 代码自动生成和编写** - AGI 可以根据用户描述的代码逻辑,自动生成代码框架或大部分完整代码。 - 节省手动编码的时间,特别适用于比较规则和结构化的业务逻辑。 **2. AI 代码补全** - 分析程序上下文和开发者的意图,智能推荐可以补充的API、模块、变量名等,辅助开发者编码。 **3. 代码纠错和重构** - 实时分析开发者代码,自动发现代码错误并进行修正。 - 可以帮助提高代码的质量和稳定性。 **4. API 测试** - 根据swagger 文档,或者 postman 自动扫描扫描所有 API,生成测试用例,然后每个API接口都调用一遍生成报告。 **5. 性能测试** - 由于AGI了解系统架构,可以生成有效的性能测试用例和流量数据。 **6. 功能测试** - 因为AGI可以通过文档知道我们要验收的功能,所以可以让其比照产品需求文档进行功能验收测试。 **7. UI 自动化测试和验收** - AGI可以自动生成测试脚本来进行自动化测试,同时如果产品需求文档中含有设计师的设计稿,甚至可以让 AGI 把功能页面和设计稿进行比对,降低设计师走查的工作量,提高工作效率。 **8. 安全测试** - AGI可以帮助发现系统中的安全漏洞和隐私风险。 **9. 可访问测试** - AGI可以帮助发现系统中的可访问问题。 **10. 混淆测试** - AGI可以帮助发现系统中的混淆问题,例如代码逻辑错误或数据库表结构错误。 **11. 其他测试** - AGI还可以帮助进行其他测试,例如安全测试、可访问测试、混沌测试等。 **总结** AGI是研发效能平台的新突破,其在代码生成、AI 代码补全、代码纠错、API 测试、性能测试、功能测试、UI 自动化测试、安全测试、可访问测试、混淆测试等方面都具有巨大的帮助力。 **未来展望** - 随着AGI技术的不断发展,我们将看到其在研发效能平台中的更广泛应用场景。 - AI 将成为研发效能平台的重要工具,帮助我们释放大脑的想象力,解放我们的双手。

正文

AGI 的出现,给了我们一个新视角去审视我们做过的系统,尤其是研发效能平台。研发效能平台作为一个工具平台,本质就是提高公司整体产研的效率。AGI 的快速进步大家已经有目共睹,本文就是在项目协同,代码管理、测试、AIOps等方面来探讨 AGI 可以给研发效能平台带来的巨大变化效率提升。拥抱 AGI,吸纳 AGI 来改善和升级我们的研发效能平台。使用人工智能提高研发产能和效率是当下的重要趋势,AGI技术作为人工智能的前沿,必将成为推动研发效能新一轮飞跃的关键技术。

研发效能是一个组织高效交付产品的能力,以及围绕提高这一能力所建立起来的由规范、流程、工具、度量体系、实践等组成的系统工程体系。目标是优化开发者体验,夯实产品研发运营基础设施和赋能组织持续高质高效地交付产品价值。

laofo@scmroad

ChatGPT主要功能

我(ChatGPT)是一个基于OpenAI的大语言模型,可以用于生成文本、回答问题、完成任务和提供建议等方面,主要功能包括:

  1. 文本生成:可以根据用户提供的主题或关键词生成文章、段落、句子等内容。

  2. 问答系统:可以回答用户提出的问题,并尝试提供相关信息和解释。

  3. 语言翻译:可以将一种语言翻译成另一种语言,并尝试推荐最合适的翻译。

  4. 情感分析:可以分析给定文本的情感色彩,并提供相关建议和反馈。

  5. 任务完成:可以基于用户的任务需求,尝试提供解决方案和建议。

总的来说,我能够处理各种类型的文本数据,并尝试提供最适合用户需求的回答、建议和解决方案等。

上面是ChatGPT 给出它自己能做哪些事情。ChatGPT不是 AGI 的全部,但是至少我们可以通过ChatGPT发现一些情况。下面我就会把ChatGPT的主要能力和研发效能平台核心功能结合起来,谈谈到底有哪些改变。

AGI+项目协同

  • 自动创建文档结构和框架:比如我要写一份产品需求文档,我直接在某个目录下点击 AGI 机器人,通过语音或者文字告诉它,帮我生成一份产品需求文档,AGI 就可以自动帮我生成一个模版式的文档和部分内容。如果 AGI 经过一些训练,这个文档的内容会更充实和正确。

  • 润色、审查、辅助编写文档:比如我已经有一份已经写好的文档,这时可以把文档地址发给 AGI,让它看下文档内容是否有逻辑上的问题,描述得是否准确,同时还期望它能自动帮我修复有问题的部分。

  • 语音/视频输入生成文档、方便检索和查看:比如我们在聊天或者开会的时候可以打开 AGI。当会话结束时,AGI可以自动帮我们把聊的内容生成一份会议纪要,由时间线构成的文档,有总结,有待办,甚至还有聊天或者会议的音视频。现在有一些产品已经支持部分功能了。

  • 自动根据文档内容生成静态、动图、视频等内容:现在已经midjourney 已经可以根据描述信息自动生成图片了。如果我们的文档写得不够详细,AGI 可以通过对效能平台的学习,补充文档,甚至可以添加动图或者视频来辅助理解文档内容。

  • 任务的高效管理和处理:当效能平台把自己能力通过API 给 AGI 后,我们就可以通过语音或者以文字沟通的模式高效管理我们那的任务。比如对着 AGI 机器人说:“列出我现在进行中的任务有哪些,请关闭任务2,备注已完成,给小明发个通知。” 这样AGI就成了我们的个人工作助理。 

AGI+代码编写、调试、审查

  • 自动代码生成:AGI可以根据用户通过语音或文本描述的程序逻辑,自动生成代码框架或大部分完整代码。节省手动编码的时间,特别适用于比较规则和结构化的业务逻辑。

  • 智能代码补全:AGI可以分析程序上下文和开发者的意图,智能推荐可以补充的API、模块、变量名等,辅助开发者编码。

  • 代码纠错和重构:AGI可以实时分析开发者编写的代码,检测潜在的错误、不规范之处以及可以优化的地方,并提出修改建议。早期发现并修复问题,降低后期调试的难度。AGI也可以根据最佳实践,自动优化和重构已有代码。

  • 自动生成文档和注释:AGI可以根据程序逻辑自动生成代码注释和文档,节省手动编写文档的工作量,并保证文档的准确性和实时性。

  • 单元测试用例的生成和补充:对现有代码,补足单元测试用例;对新代码,自动生成单元测试用例。

  • 人工评审代码准入:对于需要做CodeReview 的代码(比如架构上的考虑),可以通过 AGI 二次扫描解决问题后,再进行人工CR。 

AGI+Testing

除了文档协同和代码编写智能辅助,我觉得测试方向会是AGI的另外一个用武之地,且大有可为。

单元测试:补充单元测试用例已经不是什么新鲜事了,我们还可以让AGI自动执行代码,根据代码测试覆盖率的结果补充单元测试。这就更近一步了。

API测试:根据swagger 文档,或者 postman 自动扫描扫描所有 API,生成测试用例,然后每个API接口都调用一遍生成报告。

性能测试:之前我们的很多性能测试都是通过制造高负载测试其系统的性能,有了AGI之后,因为它了解我们系统的整体架构,数据库表结构,调用链条,可以有助于我们构造出有效的性能测试用例和流量数据。

功能测试:因为AGI可以通过文档知道我们要验收的功能,所以可以让其比照产品需求文档进行功能验收测试。

UI 自动化测试和验收:之前互联网行业UI 的自动化测试不太流行,主要原因是互联网行业页面变化快和UI自动化测试成本高。而有了 AGI之后,AGI就可以自动生成测试脚本来进行自动化测试。同时如果产品需求文档中含有设计师的设计稿,甚至可以让 AGI 把功能页面和设计稿进行比对,降低了设计师走查的工作量,提高了工作效率。

除了上面,还有安全测试、可访问测试、混沌测试等非功能性测试,AGI都可以帮助我们。之前测试条件比较复杂、人力执行测试成本高的工作都可以通通交给 AGI,让它来帮我们执行。

AGI+可观测性

可观测性(monitor+logging+alarm+tracing)和AIOps

我们可以先通过可观测性系统的建设,收集系统的各种数据,然后通过 AGI 加持的 AIOps 分析和处理这些大量的运营数据。如果 AGI 能通过运营数据反推服务、代码、需求中存在的问题和纰漏,将会大大缩短 idea-code-data-feedback 这个反馈的链路,提高产研交付效率,bug修复效率,提高系统的稳定性和运维效率。

 

AGI+内部问答知识库和客户服务

目前的企业智能客服还是比较初级的,一般流程是员工发起聊天询问问题,智能客服会根据关键字给出一个或多个备选解决方法,有的还会给出相关文档链接,如果依然不能解决问题,员工可以通过智能客服转人工服务。

有了 AGI 以后,我们就可以利用公司内部数据和知识库的信息训练一个专门服务企业内部员工的 AGI,这样员工就不再需要复杂检索,只需像与真人对话一样提出问题就可以了。

因为 AGI 还具有语言翻译的功能,你可以用英文询问问题,我可以通过中文回答,AGI从中自动翻译,这样可以提高跨语言的交流效率,减少多语言客服支持人员的数量,降低企业运营成本。

 

AGI 改变效能平台入口

在 ChatGPT 之前,效能平台可能有多个入口,包括一个独立的网站,一个IM 中的应用,一个 API 开放服务,还有知识库等,有了AGI 以后,很多功能都会通过 API 或者文档接入到 AGI 中,通过 AGI 来提供服务。ChatGPT的用户体验已经深入人心,我觉得在公司内部 AGI 会以一个 企业 IM 中的个人助理的形式出现,一个入口提供各种服务,极大提高个人的工作效率。

 

本文总结

AGI代表了人工智能技术的最高水平,其在研发管理和研发效能方面的应用将引发革命性变化,这也是研发领域不可逆转的发展趋势。同时AGI 的出现挑战着我们对企业服务,对研发效能平台的认知,我们要把 AGI和研发效能平台结合到一起,看看 AGI 能催化出一个什么形态。AGI 目前在国内还是起步的阶段,各个大佬纷纷下场,百舸争流,希望不久能有更先进的工具出现,帮助我们释放大脑的想象力,解放我们的双手。

 

我的其它文章

devops|中小公司效率为王,没必要度量
devops|中小公司不要做研发效能度量
infra | devops工具链基建建设评价标准

DevOps | 互联网、软件公司基础设施建设(基建)哪家强?

DevOps | 研发效能价值如何衡量

与DevOps|AGI : 智能时代研发效能平台新引擎(上)相似的内容:

DevOps|AGI : 智能时代研发效能平台新引擎(上)

AGI 的出现,给了我们一个新视角去审视我们做过的系统,尤其是研发效能平台。研发效能平台作为一个工具平台,本质就是提高公司整体产研的效率。AGI 的快速进步大家已经有目共睹,本文就是在项目协同,代码管理、测试、AIOps等方面来探讨 AGI 可以给研发效能平台带来的巨大变化效率提升。拥抱 AGI,吸

DevOps|从腾讯TEG CDC解散聊技术中台价值和建设

近日一则腾讯TEG CDC整个部门解散的消息在很多群里炸了锅,有的唱衰互联网行业,有的唉声叹气,还有的甩锅到 AGI 的发展。总体上来说,这个事情的确已经发生了,我想从组织架构和整体效能这两方面来分析下这次组织变化。 腾讯TEG CDC解散 6月28日,网传腾讯TEG CDC整体解散,人员涉及设计师

DevOps|1024程序员节怎么做?介绍下我的思路

1024,祝每个程序员小哥哥小姐姐节日快乐。 因为在研发效能部门,我支持过几次 1024 程序员节的活动,所以经常有朋友问我1024 程序员节怎么做,本篇就是简单介绍下我的思路,希望对你有用。 1024程序员节的由来 俄罗斯把每年第256(=2^8)天,即平年9月13日或闰年9月12日定为国际程序员

DevOps | 如何快速提升团队软件开发成熟度,快速提升研发效能?

今天一个小伙伴问我,如何「快速提升」一个团队的软件开发成熟度?我犯难了。我个人理解一个团队的软件开发成熟度涉及的东西很多,但最简单最直接的方法就是发钱涨工资,可是估计很多公司不愿意,那就只有扣了。 快速提升的目标 短期制度解决 如果想短期快速提升,那就直接梳理好最关键点,制定规章制度,然后通过奖惩制

DevOps|乱谈开源社区、开源项目与企业内部开源

之前的一篇文章《从特拉斯辞职风波到研发效能中的荒唐事》中关于企业内源的内容在研发效能群内引起了大家的热烈讨论。有的小伙伴不同意,有的小伙伴非常不同意,我觉得这都是非常正常的反馈,话不说不透,理不辩不明,我还是特别希望能和大家一起把这个问题弄明白。这篇文章就是那篇文章的后续,本文主要讨论开源社区、开源

DevOps | 企业内源(内部开源)适合什么样的公司

框架类是否适合企业内源? 框架类都由公司早期来的一些大佬们负责(相当于技术委员会),更新频率非常低。给框架类提MR的人,多数本身就在技术委员会。 如果公司的人员众多,类似BAT级别,几万人使用的框架,大家一起添砖加瓦也许是合适的,尤其适合那些公司本来已经开源到开源社区的框架。但做之前肯定有大量的学习

DevOps|研发效能不是老板工程,是开发者服务

有人说研发效能是老板工程。不是的,研发效能不是老板工程,它不直接服务于老板(虽然老板可能看一些报表),反而是服务于广大产研运(产品+研发+质量+运维)的同学,所以有的公司也把研发效能叫做基础中台,平台工程,开发者服务团队,或者叫开发者服务平台。做好研发效能,做好开发者中台,就容易把公司的各种中后台能

DevOps|研发效能价值如何衡量

现在很多公司都在做或者计划做研发效能,也知道研发效能工作很重要,能提高产研运同学的协同效率,提高员工的工作效率和质量,提高业务交付效率和交付质量,但是价值有多大?效率又有多高呢?因为不容易说清楚,所以经常碰到一些质疑和灵魂拷问。 如何衡量研发效能的效果? 如何衡量研发效能的作用? 如何说清楚研发效能

devops|中小公司不要做研发效能度量

我特别反感那些不顾公司现状一上来就想要做研发效能度量的人,尤其是想把研发效能度量当成锤子四处去敲打螺丝钉的人。 没几个人的小公司上来就做研发效能度量,就如同普通人一上来直接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下,公司想要做好研发效能度量也有标准的三步:长时间对研发效能

devops|中小公司效率为王,没必要度量

之前写过一篇文章《devops|中小公司不要做研发效能度量》,主要是从基础设施方向考虑,因为很多条件都不具备,贸然高投入去做研发效能度量可能达不到我们的预期效果,给出的建议是先做好当下打好基础。今天想到一个好例子,可以类比下。 两个人小家庭 1)人少 2)收入清晰 3)支出清晰,买了什么东西,花了多