基于wechaty的软件开发场景在AI加持下的构建

jekyll/_contributors/zhichunxiao.md

@@ -0,0 +1,12 @@
+---
+name: zhichunxiao
+site: https://github.com/zhichunxiao
+avatar: /assets/contributors/zhichunxiao/avatar.png
+bio: 一个狂热的 AI 玩家
+email: [email protected] 
+---
+
+## Contact me
+
+- Github: <https://github.com/zhichunxiao>
+- Email：<[email protected]>

jekyll/_posts/2024-05-23-construction-of-software-development-scenarios-based-on-wechaty-with-the-support-of-ai.md

@@ -0,0 +1,61 @@
+---
+title: "基于wechaty的软件开发场景在AI加持下的构建"
+author: David
+categories: article
+tags:
+  - ai
+  - gpt-4
+  - automation
+  - chatbot
+image: /assets/2024/05-construction-of-software-development-scenarios-based-on-wechaty-with-the-support-of-ai/article-picture.webp
+---
+
+> 作者: [David], A fanatical AI player.
+
+随着大模型的发展，在AI辅助编程的领域的关注热区已经从代码生成任务，扩展到很多其他开发任务，例如自动生成测试用例、bug 自动修复等。同时，作为上游的需求工程也成为热议的话题。然而，在把程序员从繁重的编码劳动中解放这个伟大的事情落地的过程中，对实际工作场景的重构至关重要，而当下的关注度却远不如AI研究工作本身。
+
+## 为什么软件开发中场景很重要？
+
+我们从一个简单问题说起。GPT-4出现至今，在辅助程序员编程任务上仍然强于代码大模型产品，为什么AI编程需要代码大模型产品，而不是直接用GPT-4？首先，代码大模型工具可以捕获代码上下文数据，可以支持多文件的数据输入，在代码理解能力的提升上具有可扩展性。其次，程序员在编码的时候特别需要连贯性，这种顺畅的编码是极好的用户体验，复制粘贴这种操作是他们不喜欢的。代码大模型产品是以插件的形式嵌入IDE中的，而直接使用GPT-4虽然能力很强，但是没在实际开发场景中，因此没能很好的发挥作用。最后，融入场景能更好的沉淀数据、计算指标、迭代优化。
+同样，在编码的上游是Plan阶段，也就是需求工程，目前已经有很多能力可以由大模型完成，但如果不把这样的能力以工具或产品的形态放到实际场景中，那也很难发力。在需求讨论的过程中，这个场景就是在即时聊天工具中的需求讨论。对于多数国内的C端开发者，微信作为最主流的及时聊天工具，如果能把需求讨论的场景梳理清楚，把大模型的能力嫁接进来，对于需求讨论的提效是不可估量的，而wechaty就是这样一个极好的辅助工具。
+在扩展人机协作方式中，场景下的用户需求指引AI研究方向，研究成果嫁接到工作场景，只有从场景的角度思考，才有可能打破现有功能边界，产生非线性的效能提升。
+
+## 如何基于wechaty打造AI赋能的软件开发场景
+
+### 软件开发工作流程是什么？
+
+Devops 模式是当下软件开发中典型的最佳实践，通常情况下包括从需求设计、编码、持续集成到持续交付，再通过反馈环路持续学习，回馈到初始的需求设计阶段，形成闭环并持续迭代。在整个环路中，不但需要各阶段的工程实践，还需要实时高效的沟通协作，才能保障业务目标落地。
+
+![devops.webp](/assets/2024/05-construction-of-software-development-scenarios-based-on-wechaty-with-the-support-of-ai/devops.webp)
+
+### 如何利用AI加持各个阶段的工程实践？
+
+在Plan阶段，需求获取、需求拆分、需求分类、需求排序等场景，是需求工程中可以通过大模型完成的任务，相关人员可以通过群聊天记录自动整理需求（例如：@wechaty/summarize，默认把群聊天中的信息自动梳理成需求条目），再把这些需求分类（例如：@wechaty/classify fun，按功能需求和非功能需求区分）。执行这些操作通过调用类似GPT-4接口实现。
+
+在Code阶段，代码生成、测试用例生成、bug自动修复、代码解释等场景是目前被众多代码大模型产品优先实现的任务，也是当前AI编码关注的热区。然而，从场景考虑需要把各个任务串联，上一级的输出作为下一级的输入。
+
+![plan-and-code.webp](/assets/2024/05-construction-of-software-development-scenarios-based-on-wechaty-with-the-support-of-ai/plan-and-code.webp)
+
+无论是Plan阶段还是Code阶段，如果结果不符合预期，需要调整后方再进入下一阶段，这一点非常必要，因为大模型是概率模型，几个概率相乘下来结果很可能偏离预期。可以发起多轮对话做调整，或直接手工修正，这恰好是wechaty依托微信群这个实时沟通场景中发挥价值的地方。
+
+另外，当前的代码大模型产品的Chat功能，从场景上看有其局限性，一是只能开发者和Chatbot点对点对话，无法形成多人协作；二是Chat功能的自然语言描述来自于上游需求讨论的结果，在IDE开发场景下无法自动导入，因此需要wechaty这样的外部工具去做从Plan到Code的打通。
+
+最后，更重要的是，当前学术界在需求工程讨论中，有一个痛点是需求数据隐匿性强，且获取成本高。如果从场景出发，基于wechaty和微信群生态很容易沉淀下来实际开发场景的数据，对学术界在需求工程的研究上可以给予很大支持。与此同时，学术界所需的数据信息可以反馈给wechaty社区，在真实开发场景中获取。
+
+### 如何利用AI助力实时高效的沟通协作？
+
+软件开发过程中会出现大量的沟通和协作，例如需求讨论、故障定位，社群运营等。这些成本评估下来往往比实际编码更高，因此如果AI能在具体场景中解决痛点问题，则带来的价值更大。可以基于wechaty构建的场景能力和解决的痛点，详见下表。
+
+|**基于wechaty打造场景能力**|**痛点**|
+|------|------|
+|自动拉群并添加干系人 |我是个“拉群工程师” |
+|自动生成群消息摘要 |我刚进群，你们讨论了啥？ |
+|自动得出结论 |开会没结果，事情不了了之 |
+|群聊天备份 |之前为那个事讨论那么久，聊啥来着？ |
+|群解散 |群太多 |
+
+需要注意的是，一个功能可以用在很多场景中，比如，自动拉群这个功能可以在需求讨论分解任务后，按各任务所指派的人批量建群；在故障定位时，把运行时错误代码做关联性分析，相关开发人员自动拉到一个群里。与此同时，一个场景可能需要多个功能支持，比如，一个问题解决后，群的运营周期结束，需要自动备份群聊天，作为数据和知识的沉淀，同时自动解散该群。
+
+## 基于wechaty的AI编程框架
+
+综上所述，这个项目考虑把AI大模型在软件开发全过程中已经被验证过的能力先用起来，利用wechaty和微信生态，在实际开发场景中让开发者感受到AI在效能提升上的价值，逐渐把各个场景连接，沉淀数据、不断优化，让价值更自动的流动。