Outcomes
学完这一阶段，你应该能做到什么
不要求一次到位，但你至少应该把这几个判断和动作练熟。
- 会把复杂需求拆成清晰的阶段、模块和并行子任务。
- 知道什么时候适合开多个子代理，什么时候必须集中决策。
- 能围绕架构边界、发布风险和回归测试组织整个开发过程。
Lessons
核心课时
每节课都为一个工程动作服务，而不是只堆定义。
Course Content
正式课程内容
下面这部分才是这个阶段真正要读、要练、要做的正文。建议先顺序读，再回头做 mission 和 quiz。
大型项目最难的部分通常不是实现某个函数，而是能不能稳定拆分、并发推进、统一收口。项目越大，越不是“谁写得快谁赢”，而是谁能组织清楚边界、验证和发布节奏。
这一阶段的正式内容，会把你从‘会用 AI 写功能’带到‘会组织 AI 和人一起推进复杂交付’。这是一种产品级、工程级的能力。
需求拆解与阶段目标
大项目要从交付结果拆，而不是从代码目录拆。
这一课要掌握什么
- 理解为什么需求拆解应该从用户价值出发。
- 学会把需求拆成阶段目标和可验证产物。
- 避免把目录结构误当成项目结构。
正式讲解
很多人拆任务时，第一反应是按前端、后端、数据库、运维这些技术目录切开。技术视角当然重要，但如果没有交付目标，这种拆法很容易变成一堆彼此脱节的工作包。
更好的做法是先定义用户价值和里程碑：第一阶段要让用户完成什么动作，第二阶段要打通哪条主路径，第三阶段要补哪些非功能能力。然后再往下映射到技术模块。
这样做的好处是，你拆出来的任务更容易被验证，因为每个阶段都对应一个明确可见的结果。
Practice
练习：把一个大项目拆成 3 个里程碑
- 选一个你熟悉的产品想法。
- 先写 3 个用户可见的阶段目标。
- 再把每个阶段目标映射到技术任务。
Homework
课后作业：需求拆解与阶段目标
- 把这节课的方法应用到一个中大型项目或毕业项目规划中。
- 写出你会如何拆任务、分工和验证的完整方案。
- 记录你会如何把这一课沉淀成团队可复用资产。
交付一份项目级方案或复盘文档，而不是零散笔记。
Test
面对更复杂的项目时，你能否仍然把这节课的方法说清楚并执行出来？
你应该能回答
- 请描述这节课最重要的组织原则。
- 请举出一个常见失控场景，并说明如何避免。
- 请说明主代理、人类决策者或负责人在这个场景中的职责。
通过标准
- 能从系统层而不是局部实现层解释问题。
- 知道复杂项目的主要风险来自哪里。
- 能把分工、验证和发布节奏讲成一条完整链路。
Evaluation
优秀
你已经能从项目级视角组织任务、控制风险并稳定推进交付。
达标
你能在复杂场景中保持边界清晰，并完成最小闭环。
还需加强
你仍然容易把复杂问题退化成局部实现，没有真正掌握组织能力。
学完自检
- 我先写用户结果，再写技术任务。
- 我知道里程碑和目录结构不是一回事。
- 每个阶段我都能定义可验证产物。
多子代理任务编排
并发的前提是边界清晰、职责分离，而不是代理数量多。
这一课要掌握什么
- 理解多子代理协作的价值和前提。
- 学会为不同代理划定文件与职责边界。
- 知道主代理为什么不能放弃收口。
正式讲解
多子代理真正提升效率的地方，在于它把研究、实现、验证、文案等不同类型工作并行化，而不是让多个代理挤在同一段逻辑上互相踩脚。
高质量编排通常包含三层：主代理负责目标收敛和集成，执行代理负责各自模块落地，验证代理负责构建、测试和风险检查。只要这三层边界清楚，复杂任务就能跑得很顺。
相反，如果你没有明确文件边界和责任归属，并发会迅速变成返工。
Practice
练习：为 3 个代理分工
- 选一个需要 UI、数据、测试三类工作的任务。
- 为每个代理写下文件范围和目标。
- 再写主代理最终要做的 3 件收口动作。
Homework
课后作业：多子代理任务编排
- 把这节课的方法应用到一个中大型项目或毕业项目规划中。
- 写出你会如何拆任务、分工和验证的完整方案。
- 记录你会如何把这一课沉淀成团队可复用资产。
交付一份项目级方案或复盘文档，而不是零散笔记。
Test
面对更复杂的项目时，你能否仍然把这节课的方法说清楚并执行出来？
你应该能回答
- 请描述这节课最重要的组织原则。
- 请举出一个常见失控场景，并说明如何避免。
- 请说明主代理、人类决策者或负责人在这个场景中的职责。
通过标准
- 能从系统层而不是局部实现层解释问题。
- 知道复杂项目的主要风险来自哪里。
- 能把分工、验证和发布节奏讲成一条完整链路。
Evaluation
优秀
你已经能从项目级视角组织任务、控制风险并稳定推进交付。
达标
你能在复杂场景中保持边界清晰，并完成最小闭环。
还需加强
你仍然容易把复杂问题退化成局部实现，没有真正掌握组织能力。
学完自检
- 我知道并发收益来自边界清晰。
- 我会给代理划写清文件范围。
- 我保留主代理统一收口。
架构边界与回归面
系统越大，边界和回归面越决定你的速度上限。
这一课要掌握什么
- 理解架构边界为什么决定并发质量。
- 知道回归面是如何产生的。
- 学会在任务定义阶段就考虑风险扩散。
正式讲解
架构边界的价值，不只是让代码更优雅，而是让系统能独立演进。一个模块如果输入输出清楚、职责清楚，它就更适合被单独开发和测试。
回归面则来自改动的扩散。你改了一层状态逻辑，可能影响很多页面；你改了一个共享组件，可能影响所有表单。系统越大，这种影响越要提前看。
所以成熟团队会同时维护两张地图：模块边界图和回归风险图。前者告诉你怎么拆，后者告诉你怎么验。
Practice
练习：画一张回归风险图
- 选一个跨多个页面的共享模块。
- 列出它会影响的页面或接口。
- 写下本次改动必须回归的 3 个点。
Homework
课后作业：架构边界与回归面
- 把这节课的方法应用到一个中大型项目或毕业项目规划中。
- 写出你会如何拆任务、分工和验证的完整方案。
- 记录你会如何把这一课沉淀成团队可复用资产。
交付一份项目级方案或复盘文档，而不是零散笔记。
Test
面对更复杂的项目时，你能否仍然把这节课的方法说清楚并执行出来？
你应该能回答
- 请描述这节课最重要的组织原则。
- 请举出一个常见失控场景，并说明如何避免。
- 请说明主代理、人类决策者或负责人在这个场景中的职责。
通过标准
- 能从系统层而不是局部实现层解释问题。
- 知道复杂项目的主要风险来自哪里。
- 能把分工、验证和发布节奏讲成一条完整链路。
Evaluation
优秀
你已经能从项目级视角组织任务、控制风险并稳定推进交付。
达标
你能在复杂场景中保持边界清晰，并完成最小闭环。
还需加强
你仍然容易把复杂问题退化成局部实现，没有真正掌握组织能力。
学完自检
- 我知道边界清晰会提升并发质量。
- 我会主动识别回归面。
- 我不把验证留到最后随缘处理。
技术债、发布节奏与持续演进
高手不是没有技术债，而是知道怎么控制它、记录它、安排它。
这一课要掌握什么
- 理解技术债与项目节奏的关系。
- 知道什么时候该修，什么时候该记录后补。
- 建立风险显式化的习惯。
正式讲解
大型项目永远不可能每一步都做到完美，所以真正重要的是风险是否可见。技术债本身不是罪过，隐藏的技术债才危险。
当你在速度和质量之间做取舍时，应该明确记录：这次为什么先不修、它会影响什么、什么时候回补。这样团队不会因为短期提速而彻底失去长期控制力。
发布节奏也是同理。稳定的项目不是每次都发得快，而是每次都知道为什么能发、为什么暂时不发。
Practice
练习：写一份已知风险清单
- 选一个你准备交付的功能。
- 列出 3 个你知道但本轮不处理的风险。
- 写下它们的影响和回补时机。
Homework
课后作业：技术债、发布节奏与持续演进
- 把这节课的方法应用到一个中大型项目或毕业项目规划中。
- 写出你会如何拆任务、分工和验证的完整方案。
- 记录你会如何把这一课沉淀成团队可复用资产。
交付一份项目级方案或复盘文档，而不是零散笔记。
Test
面对更复杂的项目时，你能否仍然把这节课的方法说清楚并执行出来？
你应该能回答
- 请描述这节课最重要的组织原则。
- 请举出一个常见失控场景，并说明如何避免。
- 请说明主代理、人类决策者或负责人在这个场景中的职责。
通过标准
- 能从系统层而不是局部实现层解释问题。
- 知道复杂项目的主要风险来自哪里。
- 能把分工、验证和发布节奏讲成一条完整链路。
Evaluation
优秀
你已经能从项目级视角组织任务、控制风险并稳定推进交付。
达标
你能在复杂场景中保持边界清晰，并完成最小闭环。
还需加强
你仍然容易把复杂问题退化成局部实现，没有真正掌握组织能力。
学完自检
- 我会记录风险而不是假装不存在。
- 我知道技术债需要显式管理。
- 我不会把节奏建立在侥幸上。
Deep Dive
这一阶段真正要建立的工程习惯
读完下面这些部分，再去做练习和复盘，学习效率会高很多。
大型项目的核心能力不是写代码
当项目变大时，单个函数实现的难度往往不是最大问题。真正难的是你是否能把需求拆成可独立推进的块，并且保证块与块之间能重新拼起来。
这也是子代理真正发挥价值的地方：它们不是为了炫技，而是为了更快地处理边界清晰的独立工作。
并发要建立在模块边界上
如果多个代理都去碰同一套状态逻辑、同一批组件或同一个数据库迁移，冲突会迅速吞掉并发收益。
高质量并发依赖清晰分工，例如一个代理做内容数据，一个代理做交互组件，一个代理做部署配置，最后由主代理集成。
为什么必须保留统一的收口者
无论开多少子代理，主代理或技术负责人都必须负责整体验收、冲突处理、最终验证和发布判断。
没有统一收口者的并发，很容易变成多个局部最优拼不成一个整体。
Mission
为一个大型全栈应用设计并发开发计划
选择一个“在线教程平台”或“团队协作工具”类产品，把需求拆成研究、设计、实现、测试、部署五条子线，并定义主代理的职责。
- 列出每条子线的输入、输出、文件边界和验证动作。
- 标记哪些动作需要人工审批或高层决策。
- 把最终集成、冒烟测试和上线准备写成主代理清单。