Spec Kit 把 Tasks 放在 Plan 和 Implement 之间，但这并不表示任何模型都必须经过这一层。这一节区分 Spec Kit 的标准流程和强模型的动态规划，然后确定胶囊系统在 Plan 完成以后怎样进入实现。
7.1 Tasks 是标准流程，不是模型必需的能力
Spec Kit 的标准流程是 SPEC → Plan → Tasks → Implement。$speckit-tasks 会读取 SPEC 和 Plan 的全部产物，再生成一份按用户故事和依赖关系排列的 tasks.md。标准的 $speckit-implement 就是读取这份任务清单，逐项编写代码、执行测试并标记完成状态。
这套设计很适合能力一般的模型、多人协作的项目，以及需要跨多个会话逐步完成的长任务。任务清单把实现顺序和方案保存在会话之外，后来接手的人或模型可以直接看到哪些事已经完成，哪些需求还没有实现。
但是，如果大模型本身已经能够自己理解并自行设计，过早把每一步固定成文件路径和执行顺序，有时候反而会限制大模型的能力。
7.2 高级模型可以在实现中动态规划
能力较强的编码模型拿到 SPEC 和完整的 Plan 产物以后，可以先自己检查代码库，形成当前的执行计划，然后边实现、边测试、边调整。它并没有省略“任务拆分”这个思考过程，只是不再把拆分结果提前固定成 tasks.md。
这种方式要求稳定的上层约束已经存在。SPEC 仍然规定系统必须做什么，Plan 仍然保存技术决定、对象关系和契约，测试和验收场景仍然需要。交给模型的也不只是一份 plan.md，而是当前功能目录中的 SPEC、Plan、调研结果、数据模型、契约和验证指南。
现在的强模型就像一个逐渐扩大的黑洞，不断把原来放在外部 Skill 和流程里的能力吸收进模型自己的执行过程。最先被吸收的，往往就是任务拆分、执行顺序和中间进度管理。这并不意味着 Spec Kit 会突然失去价值，而是它和强模型的分工会有改变：外部文档保留用户意图、技术边界和验收依据，模型自己决定当下怎样完成。
我个人认为，强模型建议是 GPT-5.6-Sol 或同等水平的模型。最差也应该试试 Kimi-K3（不保证效果，K3 我实际只测试了前端，后端能力存疑）。我的公众号有测试效果。 https://mp.weixin.qq.com/s/mOTSGj3ZThrZN8xIH7On9Q
7.3 用高级模型规划，用低成本模型执行
并不是每个项目都会让高级模型全程执行开发。如果实际执行编码工作的模型比较弱但 Token 价格更低，例如选择某个低成本的 DeepSeek 模型，Tasks 这一步仍然极具价值。
这时我强烈建议，先让高级模型生成并审查 Plan 和 Tasks，把需求转成明确的文件、代码和测试任务；然后再把 tasks.md 交给低成本模型，让它按照既定顺序完成实现。这就是“高级模型做规划，低成本模型做执行”。
这种折中方案节省的主要是高级模型的 Token 和调用费用。编写代码、读取工具输出和反复运行测试通常会消耗大量 Token，把这部分交给价格更低的模型，可以降低整体费用。
不过，项目的总 Token 数不一定会减少，因为低成本模型可能需要更详细的任务说明，也可能产生更多返工。它真正优化的是高价 Token 的使用方式。
7.4 胶囊系统直接从 Plan 进入实现
本教材的胶囊系统使用高级模型开发（GPT-5.6-Sol，思考档位为 High）。
因此，Plan 经过人工审查并确认以后，不再单独生成 tasks.md，而是把当前功能目录和项目实际代码直接交给高级模型。模型需要自行制定执行计划，完成代码和测试，最后再逐项核对 SPEC 中的需求和验收场景。
教材里没有继续走 Tasks 有两个原因。1. 教材使用的是高级模型，本身应该给与它一定的空间，让他自由发挥。2. 以后模型的能力会越来越强，模型之外的能力会被模型自身“同化”，比如今天需要外置的 tasks，过段时间几乎所有的模型都能很好的自己规划了，那就没必要单独在外置 task了。这是趋势。
关于测试
Vibe-Coding 的代码测试非常关键。那么，在 SDD 的流程中，测试（主要是单元测试）是在哪里生成和执行的？
如果项目还没有开始实现，此时根本没有可以运行的测试代码。Plan 不会生成测试代码，Tasks 即使存在，也只会列出“编写某项测试”这样的任务，不会生成实际测试代码。真正的测试文件，始终由执行 Agent（Codex）在实现阶段创建。
这几层产物对测试相关承担的职责并不相同：
| 产物 | 与测试的关系 |
|---|---|
| SPEC | 提供功能需求、边界情况、验收场景和期望结果 |
| Plan | 确定测试框架、测试分层、目录结构和外部依赖的隔离方式 |
| Tasks | 可选地把“编写哪些测试”列成执行清单，但不包含真正的测试代码 |
| 执行 Agent | 创建或更新测试文件，编写产品代码，然后运行测试并核对结果 |
胶囊系统的 Plan 已经选定 pytest，并规划了 tests/unit、tests/contract、tests/integration、tests/acceptance 和 tests/fixtures。这些目录表达的是将来要保存哪些测试，不代表测试文件已经存在。执行 Agent 需要从 SPEC 提取可验证的行为，再按照 Plan 的分层把它们写成单元测试、契约测试、集成测试和端到端验收测试。
所以，跳过 Tasks 以后，实现指令不能只要求 Agent “运行全部测试”。还要明确要求它根据 SPEC 和 Plan 创建或更新测试代码，并在最后说明每项需求由哪个测试文件验证。这样才能避免 Agent 只写产品代码，然后对着一个空的测试目录报告“全部通过”。
直接实施的指令
这时不再使用标准的 $speckit-implement，因为该命令要求功能目录中必须存在 tasks.md。我们直接给高级模型一条实现指令：
请读取当前项目目录中的 SPEC 和全部 Plan 产物，
完成 P1、P2 的全部实现。
开始编码前请自行制定执行计划。根据 SPEC 的功能需求、
边界情况和验收场景，以及 Plan 中的测试策略，确定需要的
单元测试、契约测试、集成测试和端到端验收测试。
实现过程中必须创建或更新相应的测试代码，不能只运行已有测试。
可以根据代码和测试结果调整执行计划。完成后运行全部测试，
再逐项核对 SPEC 的功能需求、边界情况、验收场景和成功标准。
最后读取
`specs/001-capsule-main-flow/implementation-report-template.md`，
根据实际实现和测试结果填写报告，并保存为
`specs/001-capsule-main-flow/implementation-report.md`。
报告必须列出每项 SPEC 要求对应的实现文件、测试文件或其他
验证方式及其结果；没有运行、没有通过或尚未完成的项目必须如实说明，
不能以“全部通过”代替逐项核对，也不能在报告中保留未填写的模板内容。
跳过 Tasks 省掉的只是一份提前固定的执行清单，不是省掉规划和测试。高级模型仍然要先规划再动手，只是这份计划可以随实现结果继续变化。测试则是它调整计划和判断完成的依据，不能跟着 Tasks 一起被省略。