用 GitHub Issues 驱动 Spec 全流程开发：从一句话需求到原生 macOS 应用（Relationship Compass 实战）-平芜编程栈

用 GitHub Issues 驱动 Spec 全流程开发：从一句话需求到原生 macOS 应用（Relationship Compass 实战）

【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding，项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe

本篇技术指南以 Datawhale easy-vibe 项目 Stage 3「核心技能」中的实战章节为主体，完整还原一条 Spec 驱动开发链路：从一句模糊的产品想法出发，借助grill-with-docs、to-spec、to-tickets、implement、code-review五个 Skill，把需求逐步收敛为规范文档、带依赖关系的 GitHub Issues、逐张实现并测试的提交，最终产出一个可构建、可验证的原生 macOS 应用Relationship Compass。读完本文，你将掌握一套可迁移到网站、后台系统或移动应用项目的"需求先确认、任务有记录、完成可检查"的 AI 迭代开发工作法，并理解 GitHub 在其中的三种角色。

1. 先理解：什么是 Spec 驱动开发

很多人第一次用 AI 写代码时，会采用下面这种方式：

告诉 AI 想做什么 → AI 写代码 → 发现不对 → 再补一句要求 → 继续修改

做一个小页面时，这种方式通常够用。但项目变大后，很容易遇到三个问题：

前面讨论过的要求，过几轮对话后被忘掉了；
AI 一次改很多文件，你无法判断当前到底完成了多少；
功能看起来能运行，却没人逐条检查它是否真的符合最初需求。

Matt Pocock 的 Skills 就是为了解决这些问题而设计的。这里的Skill可以简单理解为"写给 AI 的标准工作流程"：它不只告诉 AI 写哪一段代码，而是规定 AI 在每个阶段应该先做什么、产出什么工件（Artifact）、什么时候停下来等你确认。

1.1 与"直接从聊天开始写"的差异

普通 AI 辅助开发，常常把聊天记录当成唯一的需求来源。Spec 驱动开发则会在写代码前，先把已经确认的要求保存成仓库中的正式文档，后续每一步都回到这份文档检查。

直接从聊天开始写	Spec 驱动开发
AI 主要依赖当前聊天内容	AI 以仓库中版本化的 Spec 为主要依据
想到一个要求就直接补一句	需求变化时，先更新 Spec 和任务，再继续实现
进度只存在于 AI 的总结里	进度保存在 GitHub Issues 和提交中
完成后主要看"能不能运行"	完成后逐条对照验收标准检查

因此，Spec 驱动开发的重点并不是"多写一份文档"，而是把需求从聊天中的一句话，变成整个开发过程都能引用、更新和验证的共同标准。

1.2 GitHub 在这条流程中的三种角色

一次聊天只能保存"我们刚才说了什么"，GitHub 则可以长期保存"项目已经决定了什么、接下来要做什么、哪些事情已经完成"。在本教程里，GitHub 不只是存放源代码的网盘，它同时承担三种角色：

项目档案室：保存 Spec、项目用词（术语表）和重要技术决定；
任务看板：用 Issues、优先级和依赖关系表示工作顺序；
完成记录：用提交、测试结果和关闭状态证明每张任务是怎样完成的。

GitHub 中的内容	用大白话解释	本例中的实际文件或记录
需求文档（Spec）	这个软件最后要做到什么	`specs/relationship-compass-mvp.md`
Issue	一张可以独立完成的任务卡	`#2 Browse sample Contacts`
任务依赖	哪张任务卡必须先完成	`#3`要等待`#2`
Commit	这一轮具体改了什么	`feat: browse sample contacts`
Tests	已实现功能有没有被后续修改弄坏	`swift test`
架构决策记录（ADR）	为什么选择这种技术而非另一种	`docs/adr/0002-native-swiftui-macos.md`

下面这张流程图更直观地展示了整个工作流：

所以 GitHub 在这里更像一块"有记忆的开发工作台"：AI 每次开始工作前都可以先读取当前状态，人也可以随时打开仓库看到需求、进度、代码和验证结果，而不必翻完整段聊天记录。

1.3 整条路线总览

本次实践依次使用五个 Skill，对应的主流程是：

grill-with-docs → to-spec → to-tickets → implement → code-review

grill-with-docs：先和 AI 讨论，把"我大概想做什么"变成双方都理解的明确范围，并厘清技术边界；
to-spec：把已确认的讨论整理成一份正式的需求规格文档；
to-tickets：把大需求拆成若干张带优先级和依赖关系的 GitHub Issues；
implement：让 AI 从第一张可开始的任务卡出发，逐张测试并实现；
code-review：实现完成后检查两遍——一遍看代码质量，一遍对照 Spec 检查需求覆盖度。

相比最初流传的"四步流程"，这条主流程多出了最后的code-review。原因很简单：软件"能运行"不等于"已经按要求做好"。完成实现后再单独检查一次，往往能发现测试和第一次开发都没有注意到的问题。

2. 开始之前要准备什么

如果你想自己跟着做一遍，需要提前准备：

一个 GitHub 账号；
已经在终端登录的 GitHub CLI（gh命令）；
Node.js 18 或更高版本（用于安装 Skills）；
一个能够读取项目 Skills 的编程 AI 工具；
如果要运行本文的 macOS 示例，还需要一台 Mac 和 Xcode。

关于 Skill 的基础概念（SKILL.md结构、全局 Skill 与项目 Skill 的区别、安装与管理方式），可参考同章教程 Skills 完整指南。

2.1 安装 Matt Pocock 的 Skills

先在你准备开发的项目目录中打开终端，然后运行：

npx skills@latest add mattpocock/skills

安装过程可能会询问你要把 Skills 安装到哪里。如果希望直接安装全部内容、不逐项确认，可以使用：

npx skills@latest add mattpocock/skills -y

安装完成后，Skills 会出现在项目的.agents/skills/目录中。如果项目规模很大，连"应该先讨论哪些问题"都还不清楚，可以先使用wayfinder列出尚未做出的关键决定，再回到本文这条主流程；第一次练习时不需要它。

2.2 创建 GitHub 示例仓库

先确认终端已经登录 GitHub：

gh auth status

如果还没有登录，再运行gh auth login -h github.com。接着创建一个名为relationship-compass-macos的公开仓库，并把当前项目推送上去：

gh repo create relationship-compass-macos \ --public \ --source . \ --remote origin \ --push

这几个参数分别表示：仓库公开、使用当前文件夹、把 GitHub 地址保存为origin，并立即推送当前代码。

警告：真实联系人数据不要放进公开仓库本教程为了方便读者查看完整案例，使用的是公开仓库和固定假数据。如果你要开发自己的联系人管理工具，请改用--private，并在推送前检查样例文件、日志和 Git 历史中是否包含真实姓名、邮箱或关系备注。

2.3 准备任务标签

GitHub 标签能告诉 AI 一张 Issue 是否可以开始，以及它有多重要。本例实际使用了以下几类标签：

标签	表示什么
`ready-for-agent`	需求已经写清楚，AI 可以开始做
`priority:P0`	最先完成的基础工作，否则后面的功能无法继续
`priority:P1`	核心功能，但需要等待前置任务
`priority:P2`	收尾、文档和完整验证
`completed-by-agent`	已经由 AI 实现并验证完成

3. 这次要做一个什么软件：MVP 边界

本教程的示例Relationship Compass是一个 macOS 联系人关系管理工具。它不是用来追踪销售业绩，而是帮助个人记住：我认识谁、我们是什么关系、上次聊了什么、什么时候适合再次联系。

第一版（MVP）只做下面这些事情：

内置 6 个固定的假联系人，打开应用就能看到效果；
支持按姓名、组织、角色、邮箱和圈子搜索联系人；
支持按关系强度和圈子组合筛选；
可以编辑组织、角色、邮箱、备注和跟进周期；
可以从 UTF-8 CSV 文件安全导入联系人（带校验和去重）；
可以记录一次互动，并自动计算下一次跟进日期；
数据保存为本地 JSON 文件，下次启动时可以恢复。

第一版明确不做：云同步、AI 人脉评分、账号体系、后端服务，以及读取 macOS 系统通讯录。这样既能把最重要的使用闭环做完整，又避免在一开始就申请敏感权限。

这个例子的价值在于：它足够小，可以在一篇教程里走完全程；同时又包含真实软件常见的多个环节——界面、数据导入、本地持久化、搜索筛选、日期计算和自动化测试。

4. 第一步：用`grill-with-docs`把需求聊清楚

grill-with-docs可以理解为"先把需求问透"。它不会在收到第一句话后马上写代码，而是像一位有经验的产品和技术伙伴一样，继续问几个真正会影响实现结果的问题。进入新仓库后，像平时说话一样描述目标即可，不需要提前写正式的产品文档：

/grill-with-docs 我想实现一个 macOS 上的 CRM，可以管理我导入的联系人关系，帮助我梳理人脉。可以先使用假数据。

Agent 的回应是：

好，我们先不急着写代码。我会和你一起把"第一版做什么、不做什么、数据放在哪里"讨论清楚。遇到需要选择的地方，我会先解释区别，再给出推荐。

这一步看起来像"多聊了一会儿"，其实是在提前避免返工。比如：要不要读取系统通讯录，会影响隐私权限；要不要云同步，会影响是否需要账号和服务器。这些问题如果等代码写到一半才决定，改动成本会大得多。

4.1 对话如何逐步收敛

用户不需要懂 SwiftUI、数据库或测试框架，只需要说清楚自己想要的使用体验。本例最关键的几轮对话收敛出了以下决定：

决策	选择	原因
产品形态	macOS 14+ 原生 SwiftUI	原生文件选择、键盘操作和辅助功能
首版数据	6 个确定性的假联系人	不要求用户一开始就交出敏感数据
导入格式	UTF-8 CSV	容易准备、检查和修复
数据保存	本地 JSON	简单、透明、不需要后端
关系强度	Close / Active / Dormant	避免把私人关系变成销售评分
核心行为	搜索筛选、资料维护、互动记录、待跟进列表	构成可验证的最小闭环
隐私边界	不读取系统通讯录、不联网	首版不申请敏感权限
测试入口	`RelationshipStore`对外提供的功能	测试用户能看到的结果，不依赖内部写法

4.2 同步建立项目语言（CONTEXT.md）

讨论过程中，一些词很容易产生歧义。比如Contact既可以翻译成"联系人"，也可能被 AI 理解成"销售线索"；Follow-up可能被理解成任务、提醒或通知。因此，把已确认的项目用词写进CONTEXT.md：

**Interaction**: A dated note that records a meaningful exchange with a Contact. _Avoid_: Activity, event, touchpoint **Follow-up**: A suggested next connection date derived from the latest Interaction and the Relationship Profile's rhythm. _Avoid_: Task, reminder, notification

这不是为了把文档写得更正式，而是为了让后面的代码、测试和 Issue 始终使用同一套说法，避免 AI 一会儿写Contact，一会儿又改成Lead或Customer。

4.3 只记录真正重要的 ADR

ADR（Architecture Decision Record，架构决策记录）是一张很短的说明卡：记录一个重要选择，以及当时为什么这样选。本例只记录了两条真正重要的决定：

0001-local-first-private-data.md：关系信息留在本地，不申请通讯录权限；
0002-native-swiftui-macos.md：使用原生 SwiftUI，而不是 Electron 或 Web 壳。

ADR 不需要很长，也不用为每个小选择都写一份。只有那些以后很难改、而且存在明显取舍的决定，才值得单独记录。

4.4 确认共享理解

讨论结束时，AI 会问你是否已经达成共识，只有你明确确认后流程才进入下一步。这个暂停很重要：此时改一句需求只需要几秒；如果等 20 个文件都写完才发现方向错了，就要花更多时间返工。

完成这一步后，你应该得到：一份明确的第一版功能范围、一份"不做什么"的清单、统一的项目用词、少量真正重要的技术决定，以及你对最终方向的一次明确确认。此时还没有开始实现功能，是正常的。
GitHub 在这一步负责"保存已经确认的上下文"：把统一用词写进CONTEXT.md，把两项重要技术选择写进docs/adr/，然后提交。这样下一次会话重新打开仓库时，AI 可以直接读取这些决定。

5. 第二步：用`to-spec`写成需求文档

需求已经聊清楚，下一步是把聊天内容整理成一份以后可以反复查看的正式文档。这里的Spec（需求规格）应该讲清楚：软件解决什么问题、用户可以完成哪些操作、哪些内容不在第一版范围内，以及最后怎样判断功能已经做好。

/to-spec 根据刚才的讨论生成完整规格，保存到仓库，并发布到 GitHub Issues，标签使用 ready-for-agent。

to-spec会综合刚才的对话、项目用词和架构决定，生成一份结构化文档。本例最终得到的规格包括：

要解决的问题 第一版解决方案 24 条用户故事 已经确认的技术选择 验证（测试）方式 第一版明确不做的内容 其他补充说明

完整规格保存在仓库的specs/relationship-compass-mvp.md，同时发布为 GitHub 总 Issue #1，作为项目的可见入口。同一份需求以两种方式存在：仓库中的 Markdown 文件便于版本管理和代码审查；Issue #1 则作为项目入口，方便跟踪状态和关联后续任务。

需求变化时：应该先修改 Spec 文件并留下提交，而不是只在新的聊天里补充一句。这样 GitHub 会保留"需求为什么变了、什么时候变了"的历史。

5.1 好 Spec 要描述行为，而不是文件名

一份好规格应该描述"用户最后能做到什么"，而不是过早指定"必须创建哪个文件"。例如，本例有一条用户故事是：

作为用户，我希望从未记录过互动的联系人也出现在待跟进列表中，这样刚导入的人不会被悄悄忘掉。

这句话包含三个信息：谁需要它、希望发生什么、为什么有价值。它没有规定 Swift 文件叫什么，所以以后即使重构代码，这条需求仍然成立。

5.2 提前说明怎样验证

规格还要提前说明"做完后怎样证明它是对的"。本项目把RelationshipStore对外提供的功能当作主要测试入口，自动检查：

样例数据初始化；
搜索与组合筛选；
CSV 导入、校验与去重；
JSON 保存和恢复；
关系档案编辑；
互动记录的时间顺序；
指定日期下的下一次跟进计算。

这些测试只关心用户最终能观察到的结果，不关心内部某个小函数被调用了几次，因此重构内部实现时测试不会轻易失效。

6. 第三步：用`to-tickets`拆成有顺序的任务

一份 Spec 可能包含几十条要求，直接让 AI"一次全部实现"仍然很冒险。to-tickets的作用，就是把大目标拆成若干张能够单独完成、单独检查的 GitHub 任务卡。

/to-tickets 根据 Relationship Compass 的第一版需求文档拆分 GitHub Issues。每张任务都要交付一个可以独立演示的小功能，并写清楚优先级、完成标准和前置任务。先把任务清单和依赖图展示给我，确认后再发布。

本例拆成 5 张实现票：

Issue	优先级	完成后可以看到什么	前置任务
#2 Browse sample Contacts	P0	可启动的应用、样例联系人、搜索和详情	无
#3 Import and persist	P0	CSV 导入去重、JSON 持久化	#2
#4 Organize Profiles	P1	编辑资料、关系强度、圈子与筛选	#2
#5 Interactions and Follow-ups	P1	互动历史与待跟进列表	#4
#6 Polish and verify	P2	文档、错误状态、打包和完整验证	#3、#5

6.1 纵向切片 vs 横向拆分

拆任务时最容易犯的错误是按技术类别分工：一张票只建数据模型，另一张票只写界面，最后一张票才补测试。这样前几张票做完时，用户仍然看不到任何可以使用的功能。

更合适的方法是纵向切片——可以把它想象成切蛋糕：每一块都同时包含蛋糕胚、奶油和水果。对应到软件里，就是每张 Issue 都尽量同时包含必要的数据、界面和测试，关闭一张就能多演示一个完整的小功能。模型、Store、UI 和测试不会横向分离。

6.2 优先级与依赖是两回事

表格里的Blocked by表示"必须等待谁先完成"。流程刚开始时只有 #2 可以动手；#2 完成后，#3 和 #4 都具备了前置条件；#5 必须等 #4；最后的 #6 则要等导入保存和互动跟进两条功能线都完成。Skills 把"所有前置任务已完成、现在可以开始"的那几张票称为任务前沿（task frontier），也就是"当前没有被卡住的任务"。

优先级和依赖是两回事：P0 表示很重要，依赖关系则表示现在能不能做。一张很重要的任务，如果依赖的基础功能还没完成，也需要先等待。

这一步之后，GitHub 从"需求档案室"变成了真正的任务看板：Issues 带上priority:P0/P1/P2，并使用了 GitHub 原生的Blocked by依赖关系，而不是只在正文里写一句"以后再做"。

7. 第四步：用`implement`逐张任务实现

任务拆好后，才正式进入写代码阶段。implement会读取 GitHub Issues，找到当前没有被前置任务卡住、同时优先级最高的那一张，然后只围绕这张票工作。

/implement 根据优先级和依赖关系逐个实现所有 ready-for-agent Issues，从第一个未被阻塞的 Issue 开始。每张票使用 TDD，在完成后运行类型检查和对应测试并提交。

本例中，每张任务完成后都会留下一个独立的主要提交，这样如果某一轮出现问题，可以准确知道是哪张任务带来的修改。

7.1 每张任务都先证明"现在还不行"（TDD）

以 CSV 导入这张任务为例，Agent 实际按照下面的顺序工作：

先写一个测试：同一份 CSV 导入两次，联系人数量不能翻倍；
运行测试，确认当前版本确实还做不到；
实现 CSV 读取和去重，让这个测试通过；
再补一个测试：CSV 表头错误时，原来的联系人不能被破坏；
修正实现，重新运行这一组测试和完整构建；
提交代码，关闭当前 Issue，再领取下一张没有被阻塞的任务。

本项目使用 Swift Testing 验证：

swift test --filter RelationshipStoreTests swift build swift test

swift build负责确认整个项目可以编译，swift test负责运行全部自动化测试。最终共有 13 项行为测试，完整构建和全部测试都通过。

真实提交到仓库的RelationshipStore.importCSV做了四件事：读取 UTF-8 CSV、检查表头、寻找重复联系人、准备导入结果。它会先在一份候选数据上完成全部处理，只有所有行都合法时才替换当前联系人列表——因此文件中途出错也不会让应用留下"只导入一半"的状态。对应的RelationshipStoreTests会把同一份 CSV 连续导入两次，确认第二次只更新已有联系人而不是再新增一份，同时还覆盖了重复表头和带 UTF-8 BOM 的文件等边界情况。

7.2 Issue 状态就是项目真实进度

Agent 不会随便挑一项功能开始写。它先读取ready-for-agent、优先级和Blocked by，找到当前可以执行的 Issue；完成后，把提交哈希和测试结果写回对应 Issue，移除ready-for-agent，添加completed-by-agent，再关闭这张任务。因此，GitHub 上的 Issue 状态就是项目的真实进度，而不是一份需要手动维护、很快就会过期的旁观清单。

8. 第五步：用`code-review`检查有没有遗漏

所有 Issues 都关闭，并不代表工作已经结束。第一次实现时，AI 的注意力主要放在"把当前任务做通"，仍可能出现两类问题：代码越来越难维护，或者有些需求表面上做了、实际还有缺口。因此，实现完成后还会运行code-review，它分成两次独立检查。

8.1 第一遍：检查代码是否健康

第一遍只看代码本身，不重新讨论产品需求，重点检查：

文件和类型的名字是否容易理解；
同一段逻辑是否在多个地方重复；
一个界面文件是否承担了太多职责；
修改一个小功能是否需要同时改很多无关位置；
代码是否遵守仓库AGENTS.md中的约定。

本例第一次检查时，就发现 SwiftUI 主界面过大，而且"跟进天数"只是一个普通整数，很容易绕过"最小一天"的校验。随后拆分界面职责，并把跟进周期变成一个会主动校验取值的数据类型。

8.2 第二遍：逐条检查需求是否真的完成

第二遍不评价代码写得好不好看，而是重新打开 Spec 和所有 Issues，逐条核对：有没有遗漏的要求、有没有只做了一半的功能、界面看起来存在但实际行为是否正确、有没有擅自增加不在第一版范围内的功能。

这次审查找出了第一轮测试没有覆盖的真实问题：

CSV 中出现两个同名表头时，应用会报运行时错误，而不是给出安全提示；
没有邮箱的联系人，无法通过"姓名＋组织"识别为同一个人；
普通联系人列表已经筛选了，但"待跟进"列表没有使用同样的筛选条件；
数据虽然能保存，却不会在下次启动时自动恢复；
详情页没有明确显示计算出来的下一次跟进日期。

处理顺序是：先为这些问题补上测试，再修正代码，然后重新执行两遍检查，直到两项检查都通过。

这里最值得记住的是：测试全部通过，只能证明"已经写进测试的行为"没有出错，不能自动证明最初需求一条都没有漏。所以最后仍然需要重新对照 Spec。
GitHub 在这一步：审查发现的问题继续以独立提交保留在仓库中；确认全部修复后，#2–#6 的完成评论写明主要提交和验证结果，最后再关闭总需求 Issue #1，这样从 Issues 页面就能从任务一直追溯到代码和测试。

9. 最终得到的软件

经过需求讨论、文档整理、任务拆分、逐张实现和两轮审查后，最终得到的是Relationship Compass——不是界面效果图，而是一个可以编译、测试、打包并双击打开的原生 macOS 应用。

交付项	最终结果
GitHub 项目管理	1 张总需求 Issue 和 5 张实现 Issues，全部关闭
实现过程	9 个小步提交，按照任务依赖逐个完成
自动化验证	13/13 项行为测试通过，完整项目可以编译
最终审查	代码质量与需求完成度两项检查均通过
可运行产物	打包脚本可以生成`Relationship Compass.app`
数据边界	数据只保存在本地，不读取系统通讯录，不上传联系人关系

9.1 搜索与组合筛选

在搜索框输入Founder后，列表会从 6 位样例联系人缩小到 Maya Chen；左上角还可以继续按关系强度和圈子组合筛选。普通联系人列表与待跟进列表使用同一套筛选规则，不会出现"一边筛选了、另一边仍显示全部联系人"的情况。

9.2 编辑关系档案

选择联系人后，可以修改组织、角色、邮箱、关系强度、圈子、跟进周期和备注。应用会自动清理重复圈子，并校验跟进周期至少为一天。保存后的内容会立即反映到搜索和筛选结果中。

9.3 记录互动并计算下次跟进

为 Maya 记录一次 2026 年 8 月 9 日的互动后，应用根据 30 天的跟进周期，把下一次联系日期自动更新为 2026 年 9 月 8 日。互动内容会出现在历史记录中；日期到期后，这位联系人会自动进入"待跟进"区域。

这些界面背后的关键行为都有对应测试：同一份 CSV 重复导入不会产生重复联系人；错误表头不会破坏原有数据；保存并重新打开后所有字段仍然一致；保存文件损坏时应用会安全回到样例数据；搜索和筛选条件可以组合使用。

如果你使用 Mac，可以按照下面的顺序构建、测试和打包这个示例项目：

git clone https://github.com/sanbuphy/relationship-compass-macos.git cd relationship-compass-macos swift build swift test ./scripts/package-app.sh open "dist/Relationship Compass.app"

前两条命令下载代码并进入项目目录；swift build和swift test分别检查编译与测试；打包脚本会在dist目录生成应用；最后一条命令负责打开它。

注意：示例不是生产版通讯录。它有意不读取 macOS 系统通讯录、不上传关系数据，也不提供 AI 人脉评分。真实产品如果增加云同步、联系人权限、加密或 AI 分析，需要重新讨论隐私边界，并记录新的架构决定。

10. 可直接复制的完整流程

如果你想在自己的项目里复现这套流程，可以从下面四段输入开始。不必原样照抄产品名称，但建议保留"先确认、再写文档、按依赖实现、最后审查"这些约束。

10.1 需求讨论

/grill-with-docs 我想实现一个 macOS 上的 CRM，可以管理我导入的联系人关系，帮助我梳理人脉。可以先使用假数据。 请和我继续讨论第一版要做什么、不做什么、数据放在哪里、采用什么技术，以及最后怎样验证。每次只问当前最关键的问题；遇到选择时先解释区别并给出推荐。在我明确确认之前，不要开始写代码。

10.2 生成 Spec

/to-spec 把刚才已经确认的讨论整理成一份完整需求文档，保存到仓库，并发布为一张 GitHub 总 Issue，添加 ready-for-agent 标签。 不要重新问已经确认的问题。文档要写清楚用户能完成哪些操作、怎样验收、第一版明确不做什么；技术部分记录稳定决定，不要堆容易过期的文件路径。

10.3 拆分 Issues

/to-tickets 根据刚才的需求文档拆分 GitHub Issues。不要把数据、界面和测试完全分开；每张任务都要尽量交付一个可以独立演示的小功能。 每张 Issue 写清楚优先级、完成标准和前置任务。先把任务清单与依赖图展示给我，确认后再发布到 GitHub。

10.4 自动实现

/implement 根据优先级和前置任务，实现所有 ready-for-agent Issues。每次只处理一张当前可以开始的任务；先写描述正确结果的测试，再完成实现，并经常运行测试和完整构建。每张任务完成后单独提交。 所有 Issues 完成后，分别检查代码质量和需求完成度。修复发现的问题，重新运行全部测试，直到两项检查都通过。

11. 什么时候适合"连续自动实现"

这条流程比较适合：范围可以通过讨论收敛的 MVP；有明确用户行为和验收标准的 App、网站或后端；可以通过测试或构建命令验证的仓库；希望 Agent 跨多个会话持续工作的项目。

它不太适合那些需求每小时都在变化、结果无法通过测试或构建验证，或者会直接操作生产数据的任务。

即使让 AI 连续实现，下面几个节点仍然应该由你亲自确认：

需求讨论结束时，确认第一版范围没有理解错；
创建 Issues 前，确认任务没有漏项、先后顺序合理；
涉及付费、生产部署、删除数据、账号权限和隐私时，确认具体的外部操作；
完成后亲自打开真实界面，检查构建产物和审查结果。

真正可靠的自动开发，不是把所有决定都交出去，而是你负责目标、边界和最终验收，AI 负责把已经确认的事情稳定地执行下去。

总结

到这里，我们已经从一句模糊想法出发，完成了需求讨论、正式文档、GitHub 任务拆分、逐张实现、测试、审查和应用打包。这套方法最重要的不是记住几个斜杠命令，而是把开发过程变成一条随时可以查看、暂停和继续的路线：

模糊想法 ↓ grill-with-docs 明确范围 + 统一用词 + 重要技术决定 ↓ to-spec 可以逐条验收的需求文档 ↓ to-tickets 有优先级和先后顺序的 GitHub 任务 ↓ implement 逐张任务实现、测试和提交 ↓ code-review 检查代码质量 + 检查需求完成度 ↓ 可构建、可验证的软件

当一段聊天结束后，需求文档、Issues、依赖关系、提交和测试仍然留在 GitHub 中。下一次继续开发时，AI 不需要从头猜测你想做什么，而是可以沿着这些记录继续往前走。这套流程可以迁移到网站、后台系统、移动应用或你自己的工具项目中——先选一个范围不大的真实需求，完整走通一次，再逐渐应用到更复杂的项目里。

如需进一步了解这套方法与纯 Vibe Coding 的理论差异，可继续阅读同章前篇《从 Vibe Coding 到 Spec Coding》，其中解释了"Code is a lossy projection of intent"的核心理念，以及 Spec 如何成为 AI 时代的"新代码"。

【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding，项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考