从零到部署，看起来是一句话，背后是一整条链条。7 个环节，每个环节都可以自动化。

你有一个新项目想法。你打开 AI 工具，开始描述需求。AI 问了你 20 个问题，你回答了 20 次。然后 AI 开始写代码——但你需要一直在旁边看着，每做完一个步骤就问你"下一步做什么"。你感觉自己在"监工"而不是在"开发"。

你心想：能不能有一种方式，我只需要说一次"我要做一个 XXX"，然后就去喝杯咖啡，回来的时候项目已经搭建好了、蓝图已经设计好了、功能已经在开发了？

这不是偷懒，这是效率的极致追求。当你的项目模式成熟、技术栈固定、需求清晰时，从零到部署的每一个步骤都是可预测的——可预测就意味着可自动化。

7.1 全自动构建的定位

在整个技能体系中，全自动构建（Job）处于最顶层。它的存在意义是：把"从零到部署"这条 7 个环节的链条，封装成一个自动化流程。

从零到部署的完整链条是：

脚手架搭建 → 需求分析 → 架构设计 → 前端设计 → 功能开发 → 集成验收 → 部署配置生成

在没有 Job 的情况下，你需要手动启动每一个环节。你在终端里运行脚手架生成命令，你在编辑器里写需求文档，你在 AI 对话中手动调用 Architect 技能，你再手动启动 Orchestrator……这个过程重复 7 次，每次切换都需要你"重新进入状态"——从"脚手架思维"切换到"需求分析思维"再到"架构设计思维"。

Job 的思路很简单：把这 7 个环节封装成一个自动化流程。你只需要一个入口（"我要做一个 XXX"），Job 自动按顺序执行每个环节。每个环节的输出自动成为下一个环节的输入。

这个思路能成立的前提是：每个环节的流程是固定的、可预测的。脚手架有模板，需求分析有方法论，架构设计有原则，功能开发有 Workflow，验收有 Inspector，部署有配置模板。当每个环节都有"标准操作程序"时，把它们串起来就是一个自然的选择。

7.2 八阶段流程中的分工边界

每个阶段中，AI 做什么、人做什么、边界在哪里，这是 Job 设计中最重要的部分。

阶段 1：脚手架搭建 — AI 根据技术栈模板生成目录结构、配置文件、README。人的职责是确认模板选择（如果有多个选项）。脚手架是"骨架"，不包含任何业务逻辑。

阶段 2：需求分析 — 调用 Requirements 技能，引导用户说出需求，产出 REQUIREMENTS.md。人的职责是回答关键问题，确认需求文档。人不负责写文档，只负责做决策。

阶段 3：架构设计 — 调用 Architect 技能，基于需求文档产出 CONTEXT.md。人的职责是确认技术选型、数据模型、API 设计。AI 提议，人决策。

阶段 4：前端设计 — 如果项目有前端界面，调用 Frontend Architect 技能，产出前端设计文档。人的职责是确认 UI 风格、组件划分。不涉及具体编码。

阶段 5：高保真原型（POC） — 可选阶段。先出纯前端原型，确认效果后再开发。

阶段 6：功能开发 — 调用 Orchestrator 技能，按依赖顺序逐个实现功能。每个功能由 Workflow 自动完成，由 Inspector 验收。人的职责是在关键节点确认。

阶段 7：集成验收 — 检查跨功能集成的正确性。AI 提供数据，人做最终判断。

阶段 8：部署配置生成 — 根据项目结构生成 Dockerfile、CI/CD 配置。人的职责是确认部署目标环境。配置是模板化的，但需要人确认目标平台。

7.3 Job 模式选择

Job 支持三种运行模式：

• normal 模式：每个阶段展示计划后等待确认，验收发现问题时等待决策。适合新项目、技术栈不熟悉、需求不明确的情况。
• auto 模式：里程碑计划确认后直接执行，验收自动做分支判断。适合技术栈成熟、需求清晰、有经验的开发者。
• silent 模式：全部自动，静默执行，仅记录日志。适合完全信任的自动化管道或 CI/CD 集成场景。

如何选择？这是一个简单的决策树：

• 这是你第一次做这个类型的项目？→ normal
• 你做过 3 次以上类似项目？→ auto
• 你有一个经过验证的自动化管道？→ silent

7.4 状态驱动架构

Job 的核心设计是"状态驱动"——所有进度信息写入文件系统，每个阶段的状态决定下一步做什么。

状态文件

.agents/
├── job.state.json      # 当前阶段、里程碑进度
├── job.progress.md     # 追加式进度账本（人类可读）
├── REQUIREMENTS.md     # 需求文档（阶段 2 产出）
├── CONTEXT.md          # 项目蓝图（阶段 3 产出）
└── FRONTEND-DESIGN.md  # 前端设计（阶段 4 产出）

状态流转

Phase 0: INIT
  │
  ▼
Phase 1: SCAFFOLD → 完成 → 状态更新
  │
  ▼
Phase 2: REQUIREMENTS → 完成 → 产出 REQUIREMENTS.md
  │
  ▼
Phase 3: ARCHITECT → 完成 → 产出 CONTEXT.md
  │
  ▼
Phase 4: FRONTEND → 完成 → 产出 FRONTEND-DESIGN.md
  │
  ▼
Phase 5: POC（可选）→ 完成或跳过
  │
  ▼
Phase 6: DEVELOP → 逐个功能完成 → 每个功能验收
  │
  ▼
Phase 7: RUN_GATE → 通过 → 进入部署
  │
  ▼
Phase 8: DEPLOY → 完成 → 产出部署配置

对话中断后恢复： 读取 job.state.json，找到当前阶段，从该阶段继续执行。

7.5 降级策略

Job 的设计哲学是"降级优于阻塞"。遇到无法自动解决的失败时，默认行为是降级后继续，而不是停下来等人。

降级选项

三降级原则

1. 功能降级：如果一个功能无法在合理次数内完成，标记为"降级"，记录原因，继续其他功能
2. 质量降级：如果验收标准过高导致无法通过，可降低到"最低可接受标准"，但记录降级决定
3. 范围降级：如果某个功能超出了当前版本的范围，推迟到下一个版本

7.6 使用场景

场景一：个人项目

"帮我从零做一个个人博客系统。"

Job 会自动完成所有阶段，最终产出可部署的博客系统。你可以在任意阶段介入调整。

场景二：企业项目原型

"快速做一个设备管理系统的原型，前端用 Vue 3，后端用 Spring Boot。"

Job 会搭建脚手架、设计架构、完成核心功能、生成部署配置。你可以在原型通过后，再基于生成的代码深入开发。

场景三：学习项目

"帮我做一个简单的记账应用，帮我理解项目结构。"

Job 会产出完整的项目结构，你可以通过查看生成的代码学习一个完整项目的组织方式。

7.7 边界：什么时候不该用 Job

全自动构建不是万能的。以下场景不适合使用 Job：

1. 需求极度模糊：连你自己都不知道要做什么，就别说"全自动"了——先做需求分析
2. 技术栈不成熟：需要尝试新技术、做 POC 验证，不适合一键全自动
3. 需要深度定制：项目有特殊的安全要求、性能要求、合规要求，需要人工介入的环节多
4. 已有大量代码的项目：Job 是为"从零"设计的，已有项目应该用 Orchestrator 或 Next 技能

在这些场景中，建议使用 Orchestrator + Workflow 的灵活组合，而不是全自动的 Job。

本章小结

Job 站在 AI 编码体系的最顶层，把"从零到部署"的 7 个环节封装成一个自动化流程。它的核心价值不是"自动编码"，而是"自动化的项目管理"——从脚手架搭建到需求分析、架构设计、功能开发、集成验收、部署配置生成，全流程自动衔接。三种模式（normal / auto / silent）适应不同场景，降级策略确保流程不会因为局部问题而卡住。但 Job 不是万能的——需求模糊、技术栈不成熟、需要深度定制的项目，更适合用 Orchestrator + Workflow 的灵活组合。下一章，我们将深入解析 14 个技能的进阶用法。