本文是《VS Code Copilot 专家指南》的实战补充，回答一个问题：用 Copilot 从零开发并交付一款软件，标准流程是什么？
核心思想
不要一次性让 AI 写完整个软件，而是分阶段推进：每个阶段有明确的输入、产出和验收门槛；关键决策点必须由开发者确认后才进入下一阶段。
总体流程（7 个阶段）
1 需求立项 → 2 架构设计 → 3 项目初始化 → 4 功能开发 → 5 测试与质量 → 6 部署交付 → 7 维护迭代
（新需求 / 新 Bug → 回到阶段 4 的迭代循环）
| 阶段 | 目标 | 主要产出 |
|---|---|---|
| 1 需求立项 | 把模糊想法变成可验收的需求 | 需求文档、功能清单（REQ-XXX）、验收标准 |
| 2 架构设计 | 定技术栈、模块边界、数据模型 | 架构文档、目录结构、数据模型、接口契约 |
| 3 项目初始化 | 可运行骨架 + 固化约定 | 可运行骨架、copilot-instructions.md |
| 4 功能开发 | 按模块逐个实现并验证 | 业务代码、单元测试、提交记录 |
| 5 测试与质量 | 完整、可追踪、无回归 | 测试证据、风险清单、审查意见 |
| 6 部署交付 | 部署到目标环境 | Dockerfile、IaC、CI/CD、部署文档 |
| 7 维护迭代 | 沉淀经验、持续改进 | 更新的指令、记忆、Skill |
阶段 1：需求与立项
目标：把模糊想法变成可验收的需求清单。
| 项目 | 内容 |
|---|---|
| Copilot 角色 | 项目引导（默认 Agent 即可） |
| 输入 | 一句话目标 + 目标用户 + 业务背景 |
| 产出 | 需求文档、功能清单（REQ-XXX）、验收标准、范围外清单 |
提示词示例：
我要从零开发一款 [一句话描述]，目标用户是 [用户群]。
请先不要写代码，只做需求梳理：
1. 列出核心用户流程和关键功能
2. 为每个功能写验收标准（可测试）
3. 明确哪些功能不在第一版范围内
4. 指出哪些信息你还不确定，需要我确认
验收门槛：你能逐条确认"这就是我要做的"，且每个需求都有可验证的验收标准。确认后把结论写进 docs/requirements.md。
阶段 2：架构与技术选型
目标：确定技术栈、模块边界、数据模型和接口契约。
| 项目 | 内容 |
|---|---|
| Copilot 角色 | 架构分析（可配合 analyzing-architecture 类 Skill） |
| 输入 | 阶段 1 的需求清单 |
| 产出 | 架构文档、目录结构、数据模型、接口契约、技术决策记录 |
提示词示例：
基于 docs/requirements.md，帮我做架构设计：
1. 推荐技术栈并说明理由（前端/后端/数据库）
2. 画模块边界和依赖关系
3. 设计核心数据模型（ER 图）
4. 定义对外接口契约
5. 给出目录结构
每项决策请给出备选方案和取舍理由。
验收门槛：技术栈有明确理由、数据模型能覆盖所有需求、构建/运行/测试命令已明确。
阶段 3：项目初始化与约定固化
目标：创建可运行的最小骨架，并把团队约定写进配置文件。
| 项目 | 内容 |
|---|---|
| Copilot 角色 | 实现 + 项目配置 |
| 输入 | 架构文档、目录结构 |
| 产出 | 可运行骨架、copilot-instructions.md、构建/测试脚本 |
关键动作：
- 让 Agent 创建最小可运行骨架（不要提前实现业务功能）
- 创建项目级指令
.github/copilot-instructions.md，写入：目录规范、命名规范、构建命令、测试命令、安全要求 - 把构建/测试/启动命令写入仓库记忆
提示词示例：
按上面的架构设计创建最小可运行骨架，只包含：
- 项目配置文件（依赖、构建、测试）
- 一个 Hello World 级入口
- 一个最小测试用例
先不要写任何业务功能。完成后运行构建和测试确认能通过。
然后把构建命令、测试命令、代码规范写入 copilot-instructions.md。
验收门槛：构建 + 启动 + 测试 三条命令都能跑通。这是后续所有阶段的基线。
阶段 4：功能开发（核心迭代循环）
目标：按需求清单逐个实现功能，每完成一个就验证一个。
这是最核心的循环，不要一次性实现所有功能，按模块逐个推进：
选功能模块 → 制定实现计划 → 实现 + 单元测试 → 测试通过？
↘ 否 → 迭代修复 → 回到"实现 + 单测"
↘ 是 → 提交并记录进度 → 下一个模块
提示词示例：
@workspace 现在实现用户注册模块，按 docs/requirements.md 的 REQ-001。
要求：
1. 先列出实现计划（文件清单 + 步骤）
2. 实现功能并同时写单元测试
3. 运行测试，失败则修复
4. 遵循项目现有代码风格和 copilot-instructions.md
关键原则：
- 用 Todo 列表跟踪进度，让 Agent 逐个标记完成
- 每个功能完成后立即提交（小步提交，方便回滚）
- 遇到关键决策分歧时让 Agent 暂停询问，不要让它自由发挥
阶段 5：测试与质量门禁
目标：确保功能完整、可追踪、无回归。
| 检查项 | 方法 |
|---|---|
| 单元测试 | 让 Agent 检查测试覆盖率，补缺失用例 |
| 集成/端到端 | 启动应用，用浏览器工具走核心流程 |
| 需求覆盖 | 对照需求清单逐条核对（可用质量门禁类 Skill） |
| 代码审查 | 让 Agent 从安全性、可维护性、性能角度审查 |
| 依赖安全 | 扫描依赖漏洞（CVE） |
提示词示例：
@workspace 对当前实现做交付前检查：
1. 对照 docs/requirements.md 逐条确认是否实现
2. 审查安全性（注入、XSS、认证、敏感信息）
3. 审查可维护性（重复代码、命名、错误处理）
4. 运行全部测试并汇报结果
列出未完成项和风险清单。
验收门槛：所有需求有对应实现、全部测试通过、无高危安全/依赖问题。
阶段 6：部署交付
目标：把软件部署到目标环境，产出交付物。
| 项目 | 内容 |
|---|---|
| Copilot 角色 | 部署（可配合部署类 Agent/Skill） |
| 产出 | Dockerfile、IaC、CI/CD 流水线、环境变量、部署文档 |
提示词示例：
@workspace 为这个项目准备部署：
1. 生成 Dockerfile（多阶段构建）
2. 整理所有环境变量并给出 .env.example
3. 配置 CI/CD 流水线（构建 + 测试 + 部署）
4. 编写部署文档
验收门槛：能从干净环境一键部署，部署后核心流程验证通过。
阶段 7：维护与迭代
目标：把经验和约定沉淀，形成持续改进循环。
- 更新项目指令：把反复出现的约定写入
copilot-instructions.md - 更新记忆：把构建命令、坑点、架构事实写入仓库记忆
- 沉淀 Skill：把重复性流程固化成自定义 Skill 或自定义 Agent
- 每次 Bug 修复/新需求：重新走阶段 4 的迭代循环
一条可以直接用的"启动命令"
我要从零创建一个 [技术栈] 项目，目标是 [一句话描述]。
请严格按以下阶段推进，每个阶段先输出计划，等我确认后再进入下一阶段：
1. 需求梳理：用户流程、功能清单、验收标准
2. 架构设计：技术栈、目录结构、数据模型、接口
3. 创建最小可运行骨架，写入 copilot-instructions.md
4. 按模块逐个实现，每个模块带单元测试
5. 交付前做质量检查和安全审查
6. 准备部署配置和文档
遇到关键决策不明确时，先暂停并列出选项让我选择。
自动化机制：让 7 个阶段半自动运转
上面的「启动命令」是手动驱动版：每次都要你确认后才进下一阶段。更进一步，可以用一套机制让 AI 半自动推进整条流水线。
先给结论：完全无人值守一口气跑完 7 个阶段不现实，也不该追求。正确目标是「自动化执行 + 阶段门禁人工确认」——把执行和进度跟踪交给 AI，把方向决策和发布审批留给人。
机制分五层
编排层 协调 Agent（负责推进、决策、委派子代理）
↓ 读
计划层 plan.md + tasks.json（机器可读的单一事实来源）
↓ 更新
状态层 Todo 列表 + progress.md / 仓库记忆（进度持久化）
↓ 校验
门禁层 质量门禁（每个阶段结束前的验收检查）
↓ 依据
约定层 copilot-instructions.md（稳定规则）+ 钩子（自动触发动作）
1. 编排层：一个「交付协调者」Agent
用一个自定义 Agent（.agent.md）固定角色：它只负责读计划 → 判断当前阶段 → 执行 → 验收 → 更新状态 → 进入下一阶段。这就是把 7 个阶段串成循环的引擎。
# .agents/delivery-coordinator.agent.md
---
name: delivery-coordinator
description: 从零到一交付软件的流程协调者，按计划推进 7 个阶段并在门禁处暂停
---
你是软件交付协调者。按 .github/delivery/plan.md 推进工作：
1. 读取 plan.md 和 progress.md，确定当前阶段
2. 执行当前阶段，产出对应产物（写入 docs/ 或源码）
3. 对照该阶段的验收标准做自检
4. 更新 progress.md，把状态改为 done 或 blocked
5. 若验收自动通过 → 进入下一阶段；若需要人工决策 → 暂停并列出选项
6. 全程用 Todo 列表跟踪，每完成一项立即标记
2. 计划层：机器可读的计划文件
不要让 AI 凭记忆推进，要把 7 阶段写成结构化文件，作为「单一事实来源」：
# .github/delivery/plan.md
## 阶段状态：3/7（项目初始化完成）
- [x] 1 需求立项 → docs/requirements.md
- [x] 2 架构设计 → docs/architecture.md
- [x] 3 项目初始化 → 构建/测试跑通，copilot-instructions.md 已建
- [ ] 4 功能开发 → 按 REQ-XXX 逐个模块
- [ ] 5 测试与质量
- [ ] 6 部署交付
- [ ] 7 维护迭代
## 门禁规则
- 阶段 1、2：需人工确认
- 阶段 3、4：构建/测试自动通过即可
- 阶段 6：部署动作自动，发布/合并人工
3. 状态层：跨会话不丢进度
Copilot 单次对话有上下文上限，长流程必然跨多次会话，进度必须落在文件/记忆里：
progress.md记录当前阶段、已完成产物、阻塞项- 仓库记忆记录构建命令、架构事实、已确认决策
- 每次会话开头先让 Agent 读
progress.md恢复状态
4. 门禁层：阶段之间的验收检查
每个阶段结束前跑一次检查，通过才放行：
| 阶段 | 门禁 | 能否自动 |
|---|---|---|
| 1 需求立项 | 清单完整、每项可测 | 半自动（人工确认） |
| 2 架构设计 | 技术栈/模型/命令明确 | 半自动（人工确认） |
| 3 初始化 | 构建+启动+测试跑通 | 全自动 |
| 4 功能开发 | 每个模块单测通过 | 全自动 |
| 5 质量 | 需求覆盖+测试+安全 | 大部分自动，审查结论人工确认 |
| 6 部署 | 部署成功+核心流程通过 | 部署自动，密钥/合并人工 |
| 7 维护 | 文档/记忆已更新 | 全自动 |
5. 约定层 + 钩子层：稳定规则与自动动作
copilot-instructions.md固化不会变的东西（命名、构建、测试命令）- 钩子实现「完成 X 后自动做 Y」——就像本项目「docs 改完自动转 PDF 同步 iCloud」，可定义「阶段 3 完成后自动初始化 git 并首次提交」「阶段 5 完成后自动跑依赖漏洞扫描」
启动整个流水线的提示词
把上面五层串起来，每次新会话只需要一句：
你是交付协调者，按 .github/delivery/plan.md 推进从零到一交付。
先读 plan.md 和 progress.md 恢复进度，然后：
1. 执行当前阶段，产出对应文档/代码
2. 对照门禁规则自检并更新 progress.md
3. 门禁可自动通过的，直接进入下一阶段继续执行
4. 遇到需人工决策的（需求/架构/发布），暂停并列出选项让我选择
现在开始。
必须守住的边界
| 必须人工 | 原因 |
|---|---|
| 需求/架构签核 | 方向错了后面全错 |
| 发布、合并、密钥 | 不可逆且高风险 |
| 数据库生产变更 | 有副作用 |
| 关键选型（技术栈、第三方服务） | 影响长期维护 |
可放心全自动：写代码、写测试、跑测试、修编译错误、生成文档、更新进度文件、构建骨架——这些有客观验证标准、可回滚、无外部副作用。
与现有环境的关系
当前环境里已经内置了同类机制的成熟实现（偏 Java/Azure 迁移方向，但模式通用）：
- 编排：
execution-coordinator、modernize-rearchitecture（多代理协调者） - 计划：
creating-implementation-plan（产出 plan.md + 任务分解）、list-plans（发现计划） - 门禁：
quality-gates（四类质量门禁） - 分解：
project-decomposition、dag-generation（任务 DAG） - 钩子：
appmod-hooks（生命周期钩子）
对通用软件开发，不必搬这套重家伙，按上面的「五层」用自定义 Agent + plan.md + progress.md + 项目指令自建一套轻量版即可。
阶段 4 实战：功能开发的批处理模式
「自动化机制」是宏观框架；落到执行，最值得单独展开的是阶段 4——7 个阶段并非都适合「一口气」：需求/架构要你拍板，部署有密钥/合并卡点，只有阶段 4 任务多、重复、有客观验证信号（测试通过与否）。
三个前提
- 输入明确：REQ 清单带验收标准、架构已定、骨架能跑、
copilot-instructions.md已固化规范 - 任务可拆小块：每个任务 = 一个功能点 + 可测验收条件，依赖清晰
- 有客观验证信号：单测通过与否，AI 能自己判断对错
缺任何一个，「一口气」会变成「一口气跑偏」。
四个核心机制
- 批处理：把一批 REQ 一次交给 Agent，用 Todo 列表逐项推进，而不是「做一个 → 问你 → 做下一个」
- 自愈循环：每个任务固定闭环「实现 → 写测试 → 跑测试 → 失败修复 → 重跑」，测试结果就是它自己的反馈信号，无需你逐个看
- 上限与降级：设最大重试次数（每任务 3 次），连续失败就跳过并记入
progress.md，继续下一个，不卡死、不无限循环 - 小步提交：每完成一个任务就
git commit（消息带 REQ 编号），批次末尾统一跑全量测试
批处理提示词
@workspace 一次性完成以下功能（REQ-004 ~ REQ-008），每个任务带验收标准：
1. REQ-004 用户登录：...
2. REQ-005 资料编辑：...
3. ...
执行规则：
1. 用 Todo 列表跟踪，逐项推进，不要中途停下问我
2. 每个任务：先写测试 → 实现 → 跑测试 → 失败自动修复，最多重试 3 次
3. 每完成一个任务，git commit 一条（消息含 REQ 编号）
4. 某个任务连续失败或阻塞：跳过并在 progress.md 记录原因，继续下一个
5. 遵循 copilot-instructions.md 和既有代码模式
全部完成后：跑一次全量测试，按 REQ 编号汇报每个的完成/失败情况。
只有遇到架构级决策或公开 API 变更时才停下来问我。
两个必须守住的边界
| 控制点 | 做法 |
|---|---|
| 防死循环 | 每任务重试上限 3 次，超限跳过并记录 |
| 防跑偏 | 强制遵循 copilot-instructions.md + 参考既有代码模式，只有架构级决策才暂停 |
如何让任务一口气跑完：消除打断的完整配置
先给结论：「一口气」靠的是「消除打断 + 可续跑」，而不是"一个永不结束的回合"——VS Code Copilot 的 Agent 按回合工作，没有真正的无限循环开关。
为什么会被打断（4 个根因）
| # | 根因 | 现象 |
|---|---|---|
| 1 | 工具审批拦截（最常见） | 跑终端命令/删文件时弹「Continue / Cancel」等你点 |
| 2 | 上下文窗口耗尽 | 任务太大，Agent 做了一部分就结束回合，等你说"继续" |
| 3 | 交互式命令卡住 | npm init、git commit 打开编辑器、sudo 密码等，卡住等 stdin |
| 4 | Agent 主动提问 | 遇到歧义说"选 A 还是 B？""是否继续？" |
解法 1：开启工具自动批准（治根因 1）
打开设置（⌘,），搜索 autoApprove 或 tools，把 Agent 用到的工具设为自动批准；也可以直接写进 settings.json：
{
// 不同 VS Code 版本键名可能略有差异（chat.tools.* 或 github.copilot.chat.tools.*）
"github.copilot.chat.tools.terminal.autoApprove": true, // 终端命令自动批准
"github.copilot.chat.tools.fileEdit.autoApprove": true, // 文件编辑自动批准
"github.copilot.chat.tools.search.autoApprove": true // 搜索自动批准
}
解法 2：任务拆小 + 断点续跑（治根因 2）
单回合上下文有限是物理限制，没有魔法开关。对策是两招组合：
- 拆小：一次只给一个模块/一小批 REQ，保证单回合能做完
- 断点续跑：Agent 每次结束前把进度写进
progress.md，下回合开头先读它继续——「继续」的成本降为几乎为零
解法 3：强制非交互模式（治根因 3）
在提示词里写明命令规范，避免命令卡住等输入：
所有终端命令用非交互模式：
- npm/pnpm 加 --yes
- git 加 --no-pager，commit 用 GIT_EDITOR=true
- 禁止 sudo，禁止会打开交互编辑器的命令
解法 4：明确自主规则 + 停止条件（治根因 4）
把「什么时候可以自己做决定、什么时候才停下来」写死：
全程不要停下来问我；遇到选择先按最合理默认继续，最后在汇报里列出你做的假设。
只有遇到架构级决策或公开 API 变更时才暂停。
一条合体「全自动」提示词
@workspace 一次性完成以下功能（REQ-004 ~ REQ-008）：
[任务清单 + 每个的验收标准]
执行规则：
1. 全程不要停下来问我；遇到选择先按最合理默认继续，最后汇报里列出假设
2. 只有遇到架构级决策或公开 API 变更才暂停
3. 每个任务：写测试 → 实现 → 跑测试，失败自动修复，最多重试 3 次；超限跳过并记入 progress.md
4. 每完成一个任务就 git commit（GIT_EDITOR=true，消息含 REQ 编号）
5. 所有终端命令非交互：包管理器加 --yes，git 加 --no-pager，禁止 sudo
6. 若上下文不够：把当前进度写入 progress.md 后结束本回合
（下回合我只要说"继续"，你就先读 progress.md 接着做。）
⚠️ 安全提醒
开启终端自动批准后，Agent 可以不问你就执行 rm -rf、git push --force 这类命令。建议：
- 在开发目录/临时环境/容器里才开全自动
- 生产环境、有真实数据的目录保留人工审批
- 涉及删除/强推的操作，在提示词里明确「禁止 rm、禁止 push --force」
核心要点总结
| 原则 | 说明 |
|---|---|
| 分阶段推进 | 每个阶段有产出和验收门槛，不跳步 |
| 小步提交 | 每个功能完成就提交，便于回滚 |
| 约定先行 | 骨架阶段就固化 copilot-instructions.md |
| 测试伴随 | 写功能同时写测试，不事后补 |
| 机制驱动 | 用 plan.md + progress.md + 协调 Agent 半自动推进 |
| 消除打断 | 开自动批准 + 非交互命令 + 明确停止条件 |
| 人在环路 | 关键决策、部署、合并必须由你确认 |
| 安全边界 | 生产环境保留人工审批，禁危险命令 |
| 持续沉淀 | 经验写进 Memory / Instructions / Skill |
相关文档
- 《VS Code Copilot 专家指南》（
docs/copilot-agent-guide.md）——概念、Agent、Skill、指令、记忆的完整讲解 - 项目指令（
.github/copilot-instructions.md）——本项目约定的实际样例