用 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.mdIssue一张可以独立完成的任务卡#2 Browse sample Contacts任务依赖哪张任务卡必须先完成#3要等待#2Commit这一轮具体改了什么feat: browse sample contactsTests已实现功能有没有被后续修改弄坏swift test架构决策记录ADR为什么选择这种技术而非另一种docs/adr/0002-native-swiftui-macos.md下面这张流程图更直观地展示了整个工作流所以 GitHub 在这里更像一块有记忆的开发工作台AI 每次开始工作前都可以先读取当前状态人也可以随时打开仓库看到需求、进度、代码和验证结果而不必翻完整段聊天记录。1.3 整条路线总览本次实践依次使用五个 Skill对应的主流程是grill-with-docs → to-spec → to-tickets → implement → code-reviewgrill-with-docs先和 AI 讨论把我大概想做什么变成双方都理解的明确范围并厘清技术边界to-spec把已确认的讨论整理成一份正式的需求规格文档to-tickets把大需求拆成若干张带优先级和依赖关系的 GitHub Issuesimplement让 AI 从第一张可开始的任务卡出发逐张测试并实现code-review实现完成后检查两遍——一遍看代码质量一遍对照 Spec 检查需求覆盖度。相比最初流传的四步流程这条主流程多出了最后的code-review。原因很简单软件能运行不等于已经按要求做好。完成实现后再单独检查一次往往能发现测试和第一次开发都没有注意到的问题。2. 开始之前要准备什么如果你想自己跟着做一遍需要提前准备一个 GitHub 账号已经在终端登录的 GitHub CLIgh命令Node.js 18 或更高版本用于安装 Skills一个能够读取项目 Skills 的编程 AI 工具如果要运行本文的 macOS 示例还需要一台 Mac 和 Xcode。关于 Skill 的基础概念SKILL.md结构、全局 Skill 与项目 Skill 的区别、安装与管理方式可参考同章教程 Skills 完整指南。2.1 安装 Matt Pocock 的 Skills先在你准备开发的项目目录中打开终端然后运行npx skillslatest add mattpocock/skills安装过程可能会询问你要把 Skills 安装到哪里。如果希望直接安装全部内容、不逐项确认可以使用npx skillslatest add mattpocock/skills -y安装完成后Skills 会出现在项目的.agents/skills/目录中。如果项目规模很大连应该先讨论哪些问题都还不清楚可以先使用wayfinder列出尚未做出的关键决定再回到本文这条主流程第一次练习时不需要它。2.2 创建 GitHub 示例仓库先确认终端已经登录 GitHubgh 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 Profiles rhythm. _Avoid_: Task, reminder, notification这不是为了把文档写得更正式而是为了让后面的代码、测试和 Issue 始终使用同一套说法避免 AI 一会儿写Contact一会儿又改成Lead或Customer。4.3 只记录真正重要的 ADRADRArchitecture 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 ContactsP0可启动的应用、样例联系人、搜索和详情无#3 Import and persistP0CSV 导入去重、JSON 持久化#2#4 Organize ProfilesP1编辑资料、关系强度、圈子与筛选#2#5 Interactions and Follow-upsP1互动历史与待跟进列表#4#6 Polish and verifyP2文档、错误状态、打包和完整验证#3、#56.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 testswift 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），仅供参考
