【未来虫教育】对并行智能体的合理预期

使用并行智能体需要完全区别于传统编程或氛围编程的思维模式。这一转变的重要性，不亚于最初从传统编程转向 AI 辅助开发。

4.1 思维模式转变

控制方式从精确操控转向全局调度。你不再需要掌控每一行代码，而是同时管理多个任务。要以系统工程师管理 Kubernetes Pod 的思维来运作 —— 每个任务都是可替代、可重启的单元，而非需要精心呵护的独立服务器。

所有操作转为异步模式。与需要实时等待反馈的氛围编程不同，并行智能体默认是异步工作的。此刻输入的上下文将决定半小时后的产出结果，你无法像过去那样随意给出模糊指令再中途修正 —— 因为每次调整都要等待一小时才能收到反馈。

不必从待办清单内精挑细选某一个 “完美任务”，而应找出一天内能协同推进的多个问题。推荐采用 “2+5” 模式：集中精力攻克 2 项关键任务的同时，并行处理 5-10 个后台小任务 —— 诸如文案调整、界面优化、解决次要 Bugs 这类可以在你专注核心工作时自动处理的事项。

4.2 实际成功率

别指望 100% 的成功率。根据我使用并行智能体进行编码时的个人观察，成功率分布如下：

10%：一次生成完美方案，可直接交付。

20%：接近完成，仅需约 10 分钟的本地微调。

40%：需要人工介入修正。

20%：完全偏离方向，需关闭 issue 并记录经验教训。

10%：产品方案本身存在缺陷。

即便只有 10% 的任务被智能体完美解决，这个过程依然极具价值。智能体可靠地承担了基础工作 —— 定位文件、编写样板代码、添加测试用例。当你进行审查时，大量基础工作已完成，使你能专注于排查和修复特定问题。

当工程师对编码智能体应有何种表现没有合理预期时，挫败感便会油然而生。有些工程师若得不到完美的解决方案便会直接放弃。我认为应该突破这种思维局限，学会提取智能体的有效产出，并在需要时运用工程知识介入修正。

4.3 优势与短板

并行智能体擅长处理：

Bugs 的修复与竞态条件问题的处理

后端逻辑、控制器模块（译者注：负责接收前端请求、协调不同服务组件并返回响应的代码模块。）与验证逻辑

数据库变更与迁移脚本

依赖包版本升级与代码结构转换

目标明确的小型任务

它们处理以下情况则比较困难：

全新的 UI 开发（通常需要实时视觉内容反馈）

需实时视觉内容反馈的任务

为已存在的 PR 补充未明确写入文档的需求或隐含逻辑

需要综合考量超出 issue 范围的上下文内容才能完成的复杂架构决策

4.4 在新的编程范式下，重要性提升的技能

在并行智能体环境中，这些传统技能价值倍增：

全栈理解能力非常重要。若你仅精通前端或后端，将会很快遇到瓶颈。智能体通常需要跨越整个技术栈的指导 —— 从数据库迁移到 UI 更新，贯通前后端才能确保协作顺畅与产出质量。

问题拆解能力成为一项核心技能。庞大复杂的问题难以被智能体有效处理。将大问题分解为定义清晰的小任务，可使智能体独立并行工作，从而提升整体产出效率，同时也让代码审查与集成工作变得更轻松顺畅。

书面表达能力变得很重要。智能体依赖你清晰详细的 issue 描述来产出准确的结果。请避免使用模糊的语言、不必要的术语或模棱两可的需求。指令越具体有条理，智能体的输出质量越高。

质量保证和代码审查技能在此工作流中占据核心地位。由于审查周期是主要瓶颈，快速评估代码质量、发现缺陷及验证需求是否实现的能力变得尤为关键。高效的测试与验证能确保并行开发不会堆积未审查或存在故障的代码。

使用并行智能体工作时，必须优化审查速度。你可以同时启动 50 个任务，但仍需逐一审查、理解与验证。让审查周期变得快速（理想情况下能在 10 秒内完成检出、重构与测试）已成为整个工作流的关键所在。