Coroid 的适用场景

“AI 编程工具”涵盖多种截然不同的产品。它们并非竞争同一类任务，选错类别所造成的损失，要比在同一类别内选错产品更大。

四大类别#

前两类工具是将模型置于开发者身旁。智能体会话会将工作从开发者本地机器转移出去，但仍需人工指定每个任务、引导执行过程、测试输出结果并确认任务完成。原型设计工具能快速构建新成果。Coroid 并不属于上述任何一类：它针对你已运行的代码库的每一次变更，按照你一次性设定的流程自动执行，无论由谁发起请求。

会话与工厂解决的是不同类型的问题#

智能体会话是最接近的类比，因为它们最终也会生成拉取请求。二者的区别在于流程的承载方式不同。

会话的运行依赖于操控它的人。有人决定要处理什么任务，编写提示词，打开预览界面，找出存在的问题，撰写后续指令，并判定任务是否完成。最终结果的好坏取决于此人当天的专注程度，且只有具备全部这些能力的人才能操作：实践中通常是工程师。

工厂的运行依赖于你一次性设定的流程。Coroid 将相关步骤保留在系统中——规格说明、依据验收标准进行的 QA 检测、审核、质量策略以及审批规则——并将其应用于每一次代码变更。由于该流程并非请求人的职责，因此任何人都能发起请求。

会话适合探索性工作：与智能体共同攻克陌生难题，或按需灵活调整变更。对于必须每次都符合标准的任务，应交由 Coroid 处理。二者在 pull request 处交汇：借助 GitHub App，Coroid 可对开发者使用自有智能体开启的拉取请求执行相同的检查和审核。查看审核拉取请求。

原型设计与生产环境是不同类型的问题#

这一点值得明确区分，因为原型设计工具性能优异，人们很容易误以为同样的方法能适用于生产环境工作。

原型设计注重快速产出可视成果。你从零开始，无需遵循现有架构、无需保证测试套件通过、无需匹配既定规范，且尚无其他人依赖该成果。约束条件只会拖慢进度——这些工具也确实很少设置此类约束。

生产环境工作几乎完全受约束条件的限制。代码已然存在且包含既定决策，其他组件也依赖于它。还有必须通过的测试、需遵守的规范、安全与合规要求，以及发布前必须通过的审核流程。

Coroid 正是围绕这些约束条件而非规避它们而构建的：

它们能够良好配合#

并非非此即彼，二者以自然的方式协同工作：

先制作原型以确定要构建什么。验证一个想法、探索用户界面，本周内就能呈现给相关方——原型工具在这些方面都优于 Coroid，您应当选用此类工具。

随后在您将长期维护的代码库中构建它。一旦想法确定，相关工作就会转入您实际运行的代码库，遵循您的规范、测试和审核流程。这正是 Coroid 的职责。

原型可以回答我们是否要构建它。Coroid 则回答在我们已有的系统中妥善构建它。

何时不应使用 Coroid#

直接说明这点比罗列功能列表更有用：

• 您只是在验证一个想法，而非正式发布。应选用原型工具。Coroid 会生成针对真实代码库的已审核变更，对于明天可能就会被丢弃的内容而言，这属于不必要的额外开销。
• 您希望在几分钟内看到可视化效果。Coroid 生成的是拉取请求，而非实时演示。
• 您需要结对编程伙伴。如果您想待在编辑器中，与模型逐行协作，那便是 IDE 助手。Coroid 会在您处理其他事务时，针对完整的工作单元开展工作。
• 您希望边推进边探索问题。如果变更在您工作时逐步成型，可引导智能体会话。Coroid 依据规格开展工作，并确保结果符合规格要求。
• 您尚未创建代码库。Coroid 需要工作空间——请参阅 连接您的代码。

生产导向带来的后续影响#

在 Coroid 中，有几项功能看似多余，直到您将其视为生产需求：

• 工作在执行前就已明确指定以便有可验证的依据，任何人无需了解其构建方式就能提出相关要求。
• 验证由未编写该代码的智能体执行。
• 没有 pull request 的参与，任何内容都无法进入您的默认分支。
• 策略和门控在执行路径中强制实施，而非仅作为建议。
• 每次执行过程都会被记录——包括成本、模型、步骤和相关证据。

对于一次性原型而言，上述功能不值得为此付费；但对于企业实际运行的系统而言，这一切都物有所值。

相关内容#

• 什么是 Coroid
• Coroid 框架
• 任务如何转化为 pull request