一个老问题
今天看了陈随易的文章，想到一件事：关于 AI Coding 的讨论，很久以来大家都分得不够清。
你一定见过这样的场景：有人说「AI 写代码太强了，效率翻倍」，另一个人马上反驳「AI 写的代码全是 bug，根本不能用」。然后讨论就演变成「AI 能不能取代人」这种大而无当的争论。
问题出在哪？双方说的根本不是同一件事。前者可能在说用 AI 快速搭个 Demo，后者可能在说让 AI 重构一个有十年历史的遗留系统。这两件事的难度差了十倍不止，放在一起比较毫无意义。
所以，我觉得在继续任何讨论之前，我们需要一个分类框架，把任务场景分清楚。
三个维度
我试着从三个维度来拆解 AI Coding 的任务场景。
第一个维度：用途
- Vibe Coding 与快速原型：MVP、Demo、一次性的小工具、验证想法的原型。这种场景下代码质量不是核心诉求，速度才是。AI 能帮你在几分钟内把脑子里的想法变成可以演示的东西。
- AI 辅助编程：写单元测试、格式转换、样板代码生成、文档补全。这些事情人也能做，但做起来无聊且耗时。AI 在这里的价值是释放人的时间，让人去做更有创造性的工作。
- 架构设计与重构：系统架构的调整、遗留代码的重构、复杂业务逻辑的设计。这里需要深度的上下文理解和长链条的推理，AI 目前在这个场景下的表现参差不齐。
第二个维度：知识密度
通用知识指的是模型训练时见过大量相关内容、Pattern 非常明确的东西：CRUD 操作、常见设计模式、标准库的使用、主流框架的基本用法。这类任务 AI 基本能直接搞定，因为它「见过太多遍了」。
领域知识则是另一回事。物流系统的调度逻辑、金融产品的合规要求、医疗系统的数据标准、特定行业的业务流程——这些光靠模型的通用能力不够，需要通过 prompt、文档、甚至针对性的 RL 来补充。
第三个维度：交互模式
- One-time 模式：类似 VS Code 里的 Copilot Quick Edit，你给一个指令，AI 返回一个结果，交互结束。适合简单、边界清晰的小任务。
- Agent 模式：通过持续对话来迭代内容。AI 不是一次给出最终答案，而是在多轮交互中逐步完善。适合需要探索和调整的任务。
- Human-in-the-loop 模式：在关键节点引入人工确认。AI 做出决策前会暂停，等待人类批准后再继续。适合风险较高、需要人类把关的任务。
这个框架有什么用？
把这三个维度组合起来，我们就能更精确地定位一个具体任务。
当有人说「AI 写代码很强」时，你可以追问：是什么用途？涉及多少领域知识？用的是什么交互模式？当有人说「AI 写代码不行」时，同样可以用这个框架来定位：是不是用了 One-time 模式去做架构重构这种复杂任务？
「AI Coding 行不行」这个问题太大了，没有标准答案。但如果我们问的是「用 Agent 模式加 Human-in-the-loop 来做一个物流系统的重构，AI 能帮到什么程度」——这就是一个可以认真讨论的具体问题了。
接下来的问题：该用什么架构？
分类只是第一步。对于一个具体任务，我该用什么架构？单 Agent 够不够用？需要多 Agent 吗？要不要引入 Human-in-the-loop？
我觉得这主要取决于两件事：模型本身的能力和任务本身的复杂性。
模型能力
一方面是泛化能力：模型能不能把在其他场景学到的知识迁移过来？面对没见过的问题，它能不能基于已有知识做出合理推断？泛化能力强的模型遇到新问题不会完全抓瞎；泛化能力弱的模型一旦偏离训练分布就容易犯低级错误。
另一方面是领域知识。这里有个微妙的地方：大部分面向 Coding 的 Agent 都针对通用编程场景做过 RL 优化，但如果你的任务涉及特定领域——比如医学、法律、金融——模型可能缺乏相关的领域知识。同一个模型在写 CRUD 代码和写医疗信息系统代码时的表现可能差距很大。
任务复杂性
这里我想聚焦在一个关键问题上：任务是否需要在中途被人类接手？被接手多少次？以什么形式接手？
人类介入 Agent 工作流程这件事，其实有本质区别。
确认型接手仅仅需要人类进行 confirm。典型例子是 Claude Code 里的 Plan Agent——在执行复杂任务前，Agent 会先生成一个计划，然后暂停下来等用户确认。用户看完觉得没问题，点一下 confirm，Agent 继续执行。这种介入是预期内的、流程化的，不意味着 Agent 遇到了困难，只是在关键决策点设置了一个检查站。它可预期、低认知负担、不阻塞思路。
阻塞型接手则是 Agent 遇到了确切的工程问题，无法继续。这又分两种情况：
一是遇到很难的 Coding 相关 bug。如果不停止，Agent 就会进入无限循环——反复尝试修复，每次都失败，直到耗尽 context 或者被用户强制终止。这时候人类需要介入分析问题根源，可能要调整策略甚至换个思路。
二是遇到很 tricky 的边界情况。比如 Agent 无法处理 Terminal 中的大量输出，信息过载导致它不知道该关注哪部分；执行过程中遇到一个等待用户输入的 App，Agent 不知道该输入什么；遇到需要认证的流程，Agent 没有权限继续。这与其说是 Agent 设计的失误，不如说是真实环境的复杂度总是超出预期。
阻塞型接手的特点是：不可预期、高认知负担、可能需要人类做创造性的决策。
单 Agent 还是多 Agent？
理解了上面的评估维度，我们就可以来看架构选择了。
单 Agent 适用于简单任务——任务边界清晰、不需要复杂的任务分解、模型的通用能力足以应对、即使出错影响也有限。比如写一个工具函数、生成单元测试、格式转换。
多 Agent 扁平架构是多个 Agent 并行工作，没有明确的层级关系。说实话，我暂时想不到这种架构的典型应用场景，可能只有在 Explore 代码库或者一些极其简单的并行任务下可以勉强用一用。扁平架构的问题在于缺乏协调机制，Agent 之间容易产生冲突或重复工作。
多 Agent 层级架构更实用。核心是引入一个 Meta Agent 来统筹多个 Sub-Agent。顶层 Agent 负责理解任务、分解子任务、分配给下级 Agent、整合结果；下级 Agent 各自专注于自己的子任务。这种架构适合：任务可以被自然分解为相对独立的子任务、子任务之间有依赖关系需要协调、整体复杂度超出单 Agent 处理能力。
一个粗略的决策路径
把上面的内容整合起来，可以得到一个粗略的决策路径：
- 评估任务复杂度：简单任务（边界清晰、风险低）用单 Agent；复杂任务继续往下评估。
- 评估是否需要人类介入：只需要确认型接手，单 Agent 加 Human-in-the-loop 就行；可能需要阻塞型接手，考虑多 Agent。
- 评估任务可分解性：可以分解为独立子任务，用层级化多 Agent；难以分解，用单 Agent 加频繁的人类介入。
- 评估模型能力与任务匹配度：通用知识足够，使用通用模型；需要领域知识，考虑领域特化模型或加强 prompt/context。
这个路径不是绝对的，但可以作为思考的起点。
最后的话
所以下次再有人跟你说「AI 写代码不行」，你可以掏出这套框架，花十分钟跟他解释清楚什么是任务复杂度、什么是知识密度、什么是交互模式。等你说完，他多半已经不想跟你吵了——问题解决。