本文是「AI 效能」系列的第三篇，讨论自动开发的边界从哪里划。流程骨架见 AI 效能流程总设计，初始化加速见 all-repos 本地镜像。
先给出答案
AI 自动开发不是「能不能全自动」的问题，而是「把自动开发限定在什么范围内才靠得住」的问题。结论是：简单、上下文封闭的任务可以全自动，跨模块、需要业务判断的任务必须人机协同，而更大的需求先由人拆成可协同的单元。
关键要点
- 架构是被现实约束出来的，先承认前提，再谈自动化。
- AI 仍不具备稳定的全局规划与长程自省能力。
- 多数真实环境的知识库建设不足，AI 拿不到干净输入。
- 自动化只在简单任务上兜底，跨模块任务交给协同。
- 协同工具保留标准流程，把人之间的拉扯换成 AI 对交接条件的裁判。
两个现实前提
架构不是拍脑袋定的，而是被现实约束出来的。谈自动开发之前，先承认两个必须面对的前提。
第一，AI 能力仍在发展中，尚未到达强人工智能。它能理解局部、能完成封闭任务，但不具备稳定的全局规划和长程自省能力。让它在没有人为边界的情况下独立扛起一个复杂需求，失败是必然的。
第二，绝大部分真实环境的知识库建设严重不足。业务规则散落在代码、口头和少数人的记忆里，缺少结构化、可检索、可复用的资料。AI 拿不到足够干净的输入，就不可能产出足够可靠的输出。
这两个前提决定了：问题不在于「能不能让 AI 自动开发」，而在于「把自动开发限定在什么范围内，它才真正靠得住」。
能力边界：自动化天花板在哪一级
基于上述前提，可以给自动开发能力划一条明确的线。
| 等级 | 范围 | 开发方式 |
|---|---|---|
| XS | 改字段、改文本这类极小需求 | 全自动 |
| S | 不跨业务模块的功能，如单页面内的变更（含前后端） | 全自动 |
| M | 跨模块、需要业务判断的功能 | 人工 + AI 协同 |
| L | 需要架构级拆解的大需求 | 人工拆成多个 M，再逐一协同 |
关键结论有两条。
一是自动开发的上限止于 XS 和 S。XS 是一眼见底的小需求；S 是不跨业务模块的功能，允许同时涉及前后端，但边界清晰、上下文可控。
二是 S 以上定义为 M 和 L，自动化不再兜底。L 级需求必须先由人工拆解成多个 M；每个 M 任务都需要人工与 AI 一起协同开发。这里没有「全自动」的位置，因为跨模块意味着跨上下文，而当前 AI 和知识库都还支撑不起这种跨度。
两套工具
边界划清之后，工程上自然分成两套工具，分别服务两个区间。
全自动开发工具
面向 XS 和 S，目标是把整条链路跑成无人值守的闭环。抽象来看，流程是：产品分析需求，任务分级后进入自动链，由编排层驱动 AI 完成开发与自动测试，直至发布。只有 XS 和 S 被允许进入自动链；人的角色被前移到需求分析和分级这一道关口，之后的执行不再需要人工介入。
这条链路的可靠性，不来自 AI 本身有多强，而来自边界的收窄：需求足够小、任务上下文足够封闭，失败面才可控。相关的状态推进与恢复策略，在 AI 效能流程总设计 里已经展开。
人工 AI 协同工具
面向 M 任务，保留产品、开发、测试三个标准流程。它没有改变流程本身，改变的是流程之间的衔接方式。
过去，产品、开发、测试之间的交接靠人来拉扯：产品说需求讲清楚了，开发说得先对齐方案，测试说标准没定义，信息在不同角色之间反复传递、反复失真。现在，衔接点交给 AI 来判断流程是否可以交接：上一环节的产出是否满足进入下一环节的条件，由 AI 依据约定做判断，而不是靠角色之间反复沟通确认。人依然是各个环节的执行主体，但流程「能不能往下走」由 AI 守住。
| 维度 | 全自动工具 | 人工协同工具 |
|---|---|---|
| 面向等级 | XS、S | M（L 拆成 M 后） |
| 人的介入点 | 需求分析与分级 | 每个环节的执行 |
| AI 的职责 | 开发、测试、发布 | 交接条件裁判与协同执行 |
| 关键约束 | 边界收窄、上下文封闭 | 标准流程不变、衔接交给 AI |
分工与衔接
两套工具的关系不是替代，而是按任务等级分流。
- XS、S 走全自动链，人工只负责需求分析和分级；
- M 走协同链，人工深度参与，AI 负责衔接裁判和协同执行；
- L 在进入协同链之前，先由人工拆解为多个 M。
这样一来，自动化的野心被严格控制在其能力范围之内，而超出能力的部分交给人机协同去承接，既不冒进，也不浪费 AI 已经具备的生产力。
设计原则
- 先承认能力边界，再谈自动化：自动化范围由 AI 能力上限和知识库现状共同决定，不反过来假设 AI 无所不能。
- 按等级分流：XS、S 全自动，M 人工协同，L 先拆成 M。
- 人工前移：在自动链里，人的价值集中在需求分析和分级这道关口。
- 衔接 AI 化：协同链保留产品、开发、测试标准流程，把角色间的拉扯换成 AI 对交接条件的裁判。
常见问题
为什么不让 AI 直接承接 M 级需求？
因为 M 级意味着跨模块，也就是跨上下文。当前 AI 缺乏稳定的全局规划能力，知识库又常常不足，强行自动承接会把失败面放大到不可控。
全自动链是否完全不需要人？
仍然需要。人负责需求分析和分级这道关口，决定哪些任务允许进入自动链。人的价值只是被前移，而不是被取消。
协同工具会改变原有流程吗？
不会。产品、开发、测试三个标准流程保持不变，改变的只是环节之间的衔接判定从人工拉扯变成 AI 裁判。
知识库不足时应该先补什么？
优先把反复使用的规则、背景和验收标准沉淀下来。知识库是自动开发可靠性的输入前提，输入不干净，再强的编排也只是把错误做得更快。