面向真实软件的智能体编程平台
返回
随着大语言模型技术的迭代升级，不断地促进 AI Coding 领域的快速发展。其应用的边界不断地拓宽，而 AI autonomous 的滑块快速地向右侧滑动。产品能力分别从代码辅助编写，对话式互动的工程修改和重构，再到委派 AI 自主编程的三个阶段进行演进。AI Coding 的解决问题边界也从知识问答，到 Feature 的端到端实现。
在社交平台上，每天充满着大量关于一句提示词，生成一个惊艳 demo 的 “Wow 项目”的故事。然而，当我们深入到真实的软件开发中时，依然还存在许多的困难，并未因 AI 的出现而凭空消失。这些困难，正如 Fred Brooks 在《人月神话》中所指出的，包括复杂性、一致性、易变性和不可见性。
我们一直在思考如何构建一款适用于真实软件开发工具，最大化地发挥出 AI 的潜能，以应对真实软件开发的挑战。
显性化的第一目标，就是知识可见性，完成知识对齐。 我们希望借助 AI 能力，帮助开发者快速了解项目的架构、设计思路，甚至是技术债务。这就像是为代码库配备了一个全知全能的导游，帮助新人和老手快速理解项目的来龙去脉。
这种可见性不仅降低了学习曲线，还促进了知识的传承。更重要的是，它为 AI 提供了准确的上下文，做好了人与 AI 的知识对齐，确保 AI 生成的代码与项目的整体结构和目标的一致性。
另一个目标是提升 AI 执行的透明度。 当 AI 在后台默默工作时，开发者可能会感到不安和失控。为此，我们引入了"To-dos"、"action flow" 的概念。 AI 在开始任务时就制定详细的执行计划，并在整个过程中实时更新进度。给开发者一个随时可以窥见 AI 的"思考"过程和工作状态。
在 AI Coding 的世界里，可见性不再是一个可有可无的特性，而是成功的关键。它消除了 AI 与人类开发者之间的沟通障碍，创造了一个更透明、更高效的协作环境。
我们认为，更好的上下文输入决定更好的代码生成结果。 关键是 Enhanced Context Engineering 。
它包括理解代码库，AI 不仅需要读懂代码，还要理解其结构和设计理念；记忆功能，这包括项目历史、用户或 AI 的操作记录，帮助 AI 建立长期的上下文理解。
通过 Enhanced Context Engineering，Qoder 能够基于深入的上下文理解提供更准确的建议，并且，可以基于丰富的上下文为架构和设计决策提供洞见。
Enhanced Context Engineering 不仅仅是一种技术，它代表了一种新的开发哲学。通过为 AI 提供丰富的上下文，我们正在创造一个更智能、更高效的开发环境。
在智能体时代，人类大部分的工作是表达意图和确认意图。 在对话模式下，作为开发者，你的角色是引导，并监督 AI 的执行过程，审查生成的代码，最终决定是否采纳。这种编程方式，整个过程由人通过对话进行主导，这最大程度地保持了开发的灵活性，还确保了 AI 始终与你的目标保持一致。
然而，随着 AI 能力的飞速提升，特别是在执行长期任务方面，我们将整个任务委托给 Agents。在这种模式下，你首先详细描述任务说明（Specs），然后将其委托给 AI 执行。AI 会自主完成工作，只有在遇到问题时才会"举手"寻求帮助。
Specification 对于个人是一种思考的工具（Tool of thought），在 write down 的过程中，将思考重新整理。Specification 对于人与人或人与 AI 的协作，是一种结构化沟通的介质。Specification 在软件开发中起着"指南针"和"地图"的作用，同时可以成为团队知识的一部分。
因此，我们为此专门设计了"Quest Mode"。在这个模式中，开发者的主要工作是明确任务意图和确认结果，而不是充当 AI 的"监工"。这种方式特别适合那些定义明确、可以批量处理的任务。
两种模式定义两种 人类与 AI 不同的协作边界。其应用场景：
未来的工作方式可能是这样的：白天，开发者与业务方澄清需求，利用 AI 辅助编写详细的任务说明书。下班前，他们将这些任务委托给 AI 执行。第二天早上，开发者查看结果，进行必要的修改和重构，然后继续与业务方讨论新的需求。Write Specs - Check & Refactor.
从实时伴随模式，再到委托模式，这些模式代表了人类开发者与 AI 助手协作的进化，各有其独特的优势和应用场景。而这恰好是真实软件开发中所必需的。
当模型的选择列表越来越长，我们问了自己一个问题：这个选择什么模型的工作应该由用户来做么？我们得到答案是否定的。对于用户来说，他需要一个能够高质量解决他们问题的模型，而不是自己每天决定去选择什么样的模型。
因此，我们把选择什么样的模型这个问题留给我们，永远给用户最佳的模型组合。用户不需要去理解各种评测数据，决定选用哪个模型合适。
Qoder 没有任何的上手成本。只要你能够完整地输入自然语言，就可以开始你的工作。做为一个新的项目，工程里可能什么东西也没有，这个时候，只要在对话框输入你的要求，如“基于 Spring-boot，实现一个照片上传、预览、下载的应用程序”，这个时候，Qoder 将会根据你的要求，生成整个工程脚手架，并且生成基础的业务逻辑代码。
另一种做法是，切换到 Quest Mode 下，先通过提示词，生成好相应的 Specification 文件。因为是一个全新的项目，我们建议第一个 Specification 主要描述好需要采用的开发语言等技术栈要求。同时，有一个 Version 0 的初始版本。一个明智的建议是，版本 0 最好是能够运行起来的工程。
大部分的开发工作都是基于已有的代码工程，开发者在开始他的工作之前，总是希望能够快速理解这个工程是用来做什么的，具体的技术架构是什么。
通过 Repo Wiki，可以让开发者快速了解这些信息。同时，我们也希望 Qoder 也能了解这些信息，Qoder 会在后台构建代码库的索引，并将工程引入到记忆中。
这样，开发者在开始一个任务的时候，大部分知识都已经准备就绪，开发者不用手工选择太多的上下文信息，Qoder 也可以准确地帮助开发者来完成。
基于已有的代码进行编辑是常态。Qoder 通过代码补全、NES 及 Inline Edit 的功能，来满足开发者日常代码编辑的诉求。
我们的愿景是解决真实软件开发的挑战。通过提升软件研发的可见性，加强人与人，人与 AI 的知识对齐，消除技术债务和协作摩擦。同时，最大化发掘 AI 的最大潜力，将人类从重复繁杂的工作中释放出来，投入到创意和创新工作中。
我们非常期待你使用它来进行真实软件的开发，并且分享你的想法。
AI Coding 的发展趋势
随着大语言模型技术的迭代升级，不断地促进 AI Coding 领域的快速发展。其应用的边界不断地拓宽，而 AI autonomous 的滑块快速地向右侧滑动。产品能力分别从代码辅助编写，对话式互动的工程修改和重构，再到委派 AI 自主编程的三个阶段进行演进。AI Coding 的解决问题边界也从知识问答，到 Feature 的端到端实现。
软件发展趋势
在社交平台上，每天充满着大量关于一句提示词，生成一个惊艳 demo 的 “Wow 项目”的故事。然而，当我们深入到真实的软件开发中时，依然还存在许多的困难，并未因 AI 的出现而凭空消失。这些困难，正如 Fred Brooks 在《人月神话》中所指出的，包括复杂性、一致性、易变性和不可见性。
- 软件的抽象本质使得它难以显性化。这导致组织间的知识对齐困难、知识传承困难、技术债务积累，影响协作。更值得注意的是，在 AI 时代，这种影响还延伸到了人与 AI 之间。
- 尽管 AI 可以帮助处理重复性的编码工作，但开发者可能在软件设计和需求澄清上投入不足，AI 生成更多难于维护的代码。
- 软件需要适应不断变化的需求，人们对于效率的追求是无止境的。目前，人与 AI 的协作主要采用同步对话的方式。在这种模式下 AI 的工作效率受限于人类的参与时间，并且需要不断进行校准和调整。这种协作方式，并未最大化地发挥 AI 的潜力。
我们的思考
我们一直在思考如何构建一款适用于真实软件开发工具，最大化地发挥出 AI 的潜能，以应对真实软件开发的挑战。
显性化
显性化的第一目标，就是知识可见性，完成知识对齐。 我们希望借助 AI 能力，帮助开发者快速了解项目的架构、设计思路，甚至是技术债务。这就像是为代码库配备了一个全知全能的导游，帮助新人和老手快速理解项目的来龙去脉。
这种可见性不仅降低了学习曲线，还促进了知识的传承。更重要的是，它为 AI 提供了准确的上下文，做好了人与 AI 的知识对齐，确保 AI 生成的代码与项目的整体结构和目标的一致性。
增强上下文工程
我们认为，更好的上下文输入决定更好的代码生成结果。 关键是 Enhanced Context Engineering 。它包括理解代码库，AI 不仅需要读懂代码，还要理解其结构和设计理念；记忆功能，这包括项目历史、用户或 AI 的操作记录，帮助 AI 建立长期的上下文理解。
通过 Enhanced Context Engineering，Qoder 能够基于深入的上下文理解提供更准确的建议，并且，可以基于丰富的上下文为架构和设计决策提供洞见。
Spec 驱动和任务委派
在智能体时代，人类大部分的工作是表达意图和确认意图。 在对话模式下，作为开发者，你的角色是引导，并监督 AI 的执行过程，审查生成的代码，最终决定是否采纳。这种编程方式，整个过程由人通过对话进行主导，这最大程度地保持了开发的灵活性，还确保了 AI 始终与你的目标保持一致。
然而，随着 AI 能力的飞速提升，特别是在执行长期任务方面，我们将整个任务委托给 Agents。在这种模式下，你首先详细描述任务说明（Specs），然后将其委托给 AI 执行。AI 会自主完成工作，只有在遇到问题时才会"举手"寻求帮助。
Specification 对于个人是一种思考的工具（Tool of thought），在 write down 的过程中，将思考重新整理。Specification 对于人与人或人与 AI 的协作，是一种结构化沟通的介质。Specification 在软件开发中起着"指南针"和"地图"的作用，同时可以成为团队知识的一部分。| Chat Agent Mode | Quest Mode |
|---|---|
| Chat Iteration | Spec First |
| Coding Through Conversation | Delegate Tasks to AI Agent |
| For Short Task | For Long Task |
| Supervise the workflow | Accurate describe the purpose |
提供最恰当的模型
当模型的选择列表越来越长，我们问了自己一个问题：这个选择什么模型的工作应该由用户来做么？我们得到答案是否定的。对于用户来说，他需要一个能够高质量解决他们问题的模型，而不是自己每天决定去选择什么样的模型。
因此，我们把选择什么样的模型这个问题留给我们，永远给用户最佳的模型组合。用户不需要去理解各种评测数据，决定选用哪个模型合适。
如何使用 Qoder 完成你的工作
从一个新项目开始
Qoder 没有任何的上手成本。只要你能够完整地输入自然语言，就可以开始你的工作。做为一个新的项目，工程里可能什么东西也没有，这个时候，只要在对话框输入你的要求，如“基于 Spring-boot，实现一个照片上传、预览、下载的应用程序”，这个时候，Qoder 将会根据你的要求，生成整个工程脚手架，并且生成基础的业务逻辑代码。
另一种做法是，切换到 Quest Mode 下，先通过提示词，生成好相应的 Specification 文件。因为是一个全新的项目，我们建议第一个 Specification 主要描述好需要采用的开发语言等技术栈要求。同时，有一个 Version 0 的初始版本。一个明智的建议是，版本 0 最好是能够运行起来的工程。
在一个已有工程上新增一个 feature
大部分的开发工作都是基于已有的代码工程，开发者在开始他的工作之前，总是希望能够快速理解这个工程是用来做什么的，具体的技术架构是什么。通过 Repo Wiki，可以让开发者快速了解这些信息。同时，我们也希望 Qoder 也能了解这些信息，Qoder 会在后台构建代码库的索引，并将工程引入到记忆中。
这样，开发者在开始一个任务的时候，大部分知识都已经准备就绪，开发者不用手工选择太多的上下文信息，Qoder 也可以准确地帮助开发者来完成。
熟悉的代码补全
基于已有的代码进行编辑是常态。Qoder 通过代码补全、NES 及 Inline Edit 的功能，来满足开发者日常代码编辑的诉求。