在过去的一年里，越来越多的生成式 AI 应用来到了我们的日常，Copilot 似的 AI 大大改善了我们的工作和生活体验。而作为工程师，仅仅使用 AI 工具是不合时宜的，在恰当的时候，加入 AI 原生应用的开发大军，才是更适合被誉为 “夕阳产业” 从业人员的一种选择。
而从我们构建 ClickPrompt、AutoDev及其它 AI 应用的过程来看，要设计好这一类 AIGC 的体验不是一件容易的事情。我们试图从过去的一些经验里做总结，并在此文中融入了我们的思考。从现有主流的 AI Copilot 型应用、生成式 AI 的特点，两个比较好的例子就是写作与编程。前者有非常成熟的 Notion AI 作为示例，后者有不断涌现的 GitHub Copilot、Cursor、JetBrains AI Assistant 等工具。
写作是一个复杂还是繁杂问题？
也因此，对于这个问题来说，人们的答案是不一样的。对于不经常写作的人来说，这必然是一个复杂问题；他们可能不知道从何处开始，如何组织思路，如何表达自己的观点。他们可能感到困惑和无助。而对于经常写作的来说，多数情况下都是一个繁杂问题。
人们看待问题的方式不一样，思考过程不一样，也就导致了会产生不同的结果。同样是 AI 辅助写作工具的设计，可能会出多种不同的结果，从简单的 zero-shot 的一键式生成，到根据不同写作模板写成，再到 Notion 结合不同的意图生成。
所以，你问一个经常写文章的人，他可能就会这样说写作的步骤是这样的：
确定主题：首先，他们会选择一个明确的主题或者话题来进行写作。这个主题可能是他们感兴趣的领域，或者是与他们当前工作、学习相关的话题。
进行调研：在开始写作之前，经常写文章的人会进行一些调研工作，以获取更多关于所选主题的信息和背景知识。这可以通过阅读相关文献、文章、报告或者采访专家等方式进行。
制定大纲：在收集足够信息后，他们会制定一个大纲来组织自己的思路和结构。这个大纲通常包括引言、正文和结论等部分，并且可能包含一些子标题或者章节标题。
写作草稿：接下来，经常写文章的人会根据大纲开始撰写草稿。在这个阶段，他们不必担心语法错误或者完美表达，在思路流畅地展开为主。
……
但是，故事并非只到这里，你在写作的时候，还涉及到文章的前言、总结等的内容。如下是一个使用 AutoDev + ChatGPT 3.5 生成的前言：
随着用户体验的重要性不断提升，开发团队将更加关注用户需求和期望，通过用户故事来指导开发过程。这种方法将帮助开发团队更好地理解用户需求，提高产品质量，并增强用户满意度。同时，随着人工智能和机器学习的发展，软件开发也将越来越注重个性化和智能化的用户故事，以满足不断变化的用户需求。
写作从一个复杂问题变成繁杂问题是因为：模式化。经验丰富的人脑子里有大量的模式，这些模式是随着大量的练习自然而然形成的。要将这些模式从大脑中提炼出来，并非是一件容易的事，也因此师傅厉害，学生不一定能学到东西。
GitHub Copilot 辅助的是编程的什么？
我们在内部进行了一系列的 GitHub Copilot 培训，主要目的不是训练 IDE 插件如何使用，而是如何将 GitHub Copilot 与我们的工作流结合。诸如于，在经典的 Thoughtworks 毕业生培训里，在培训某个语言语法之前，还有大量的练习是关于如何思考的，诸如于 Tasking。
Tasking 简单来说，就是任务拆分。你所要面对的问题，类似于把大象放进冰箱要几步？在你关下冰箱之前，你需要一个哆啦A梦的缩小枪，才能把大象真正放进去。但是，很遗憾的是 GitHub Copilot 并非是你的缩小枪 —— 你不能打开 IDE，把你的任务变成注释和函数签名，然后用 Copilot 直接完成你的代码。
在编写 CRUD 时，我们的过程是这样的：
代码修改点一。分析你的需求、任务，根据任务定位出修改点；然后，才是编写你的第一部分代码。
代码修改点二。而由于，我们的代码是模块化的、类文件化的，所以你还需要定位下一个修改点，然后继续你的第二部分代码。
往复循环，直至你编写代码
测试并修复你的 bug。
这也是我们设计 AutoDev 的 AutoCRUD 的最初想法，结合 ChatGPT 分析改动点，找到改动点后由 AI 完成改动。
而如果我们结合上面的过程会，发现 GitHub Copilot 更多的只是在帮我们：解决人类健忘的语法、不流畅的结构化翻译问题。也因此，它就更像一个和你结对的编程员。
IDE 如何结合好 AI 辅助编程？
既然，我们将 GitHub Copilot 视为一个高级一点的代码补全工具，那么对比于 Notion AI 这一类的写作工具，就会发现存在大量的机会能改善编程上的体验。
尽管，我们是在 JetBrains AI Assistant 项目之前，构建了 AutoDev 应用，但是由于 JetBrains 在这方面拥有更多的思考、丰富的 API 经验，所以我们可以从他们的 AI 助手看到对于体验设计：
围绕日常活动设计。开发者日常需要写文档、代码检视、编写提交信息等等，都结合 AI 来实现对应的功能。
针对不同场景设计。诸如于早先的 CI/CD、代码解释、语义化搜索等等。
当然了，与 JetBrains 这一类通用型的工具相比，AutoDev 也在思考更符合于企业应用开发的场景：
编码规范化。即让 AIGC 生成的代码更符合企业需要。
团队协作 AI。即让团队可以自定义自己的 AI，以辅助团队更好的进行开发活动。
而如果我们再进一步分析这些需求会发现，其实这些需求的本身是围绕于个人、组织在日常活动中所出现的模式。再模式固化到工具中，以提升个人的体验与效率。
增强人类而应用模式，还是取代模式？
最后，回到我们的问题上，问题的答案就变得非常有趣。人们对于 AIGC/GenAI 到底是否是 AGI 并没有达到一致意见。
如果我们的工具定位的是取代现有的流程，那么必然我们应该站在新的模式来考虑这个问题。诸如于，开发人员不应该对 AI 生成的代码进行代码检视，而是应该由另外一个 AI 去 review AI 生成的代码。只是，我们并不敢笃定 AI 生成的代码是准确的，所以还需要人工介入。而 AI 也不代替我们去坐牢，所以我们走的模式还是增强模式。
那么，既然我们的应用意图是：增强人类，那么理想的方式还是围绕人类的习惯来构建。我们需要去寻找这个行业的专家，将它们的日常活动与 AIGC 紧密结合，并将专家的思维模式提炼出来，融入工具中。再辅助配合一些自定义的能力，以此来构建 AIGC 时代的 AI 原生应用。
总结总而言之，在 AI 领域，我们需要在设计 AIGC 应用时，更加关注个人习惯和思维模式，并结合专家知识和行业经验来构建更适合用户需求的 AI 原生应用。
PS：事实上，在写完一篇文章的时候，我们应该花点时间去校对与润色，但是我一直忽略了这一步，这大概就是我的问题了。
