1. 使用 Spec Kit 和 Claude Code 重建应用 [0]

thumbnail
  1. 作者使用 Spec Kit 和 Claude Code 重建了整个应用程序 [0]。
  2. Spec Kit 就像是 “加强版的规划模式” [1]。
  3. 它强制 Claude 在编写任何代码之前，经历三个不同的规划阶段 [2]。
  4. 本教程将展示如何设置 Spec Kit，并查看输出是否有所改善 [3]。

1.1. Spec Kit 的安装和设置 [4]

  1. 首先，必须在 Claude Code 的项目中安装 Spec Kit [4]。
  2. 安装使用 uvx 命令，具体安装说明在视频描述中 [5]。
  3. 基本命令是 specify init，然后提供项目名称 [6]。
  4. 作者将项目命名为 Ré Rocket [7]。
  5. 选择 AI 助手时，作者选择了 Claude Code [9]。
    1. 其他选项包括 Gemini CLI、Cursor 或 GitHub Copilot [8]。
  6. 脚本类型选择了 sh，因为作者使用的是 Mac [11]。
  7. 该命令将 Spec Kit 中的所有模板复制到本地项目 [12]。
  8. 它还会安装在 Claude Code 内部使用的自定义命令 [13]。
  9. 安装完成后，其余操作都在 Claude Code 内部进行 [14]。

2. Spec Kit 的三阶段规划流程 [16]

thumbnail
  1. 作者进入了新创建的目录并打开了 Claude Code [16]。
  2. 现在出现了新的命令，首先是 specify 命令 [17]。

2.1. 阶段一：Specify (描述“是什么”和“为什么”) [20]

  1. Specify 阶段的目的是描述 “是什么” 和 “为什么”，而不是 “如何做” [20]。
  2. 不应涉及应用程序堆栈或技术等任何技术细节 [21]。
  3. 可以直接输入提示，但更好的方法是引用一个 Markdown 文件 [22]。
  4. 引用 Markdown 文件的好处是可以随时回顾，并作为迭代的起点 [24]。
  5. 在 Markdown 文件中，作者专注于用户旅程、体验、期望的结果和要解决的问题 [25]。
  6. 概述要求是：构建一个应用，帮助求职者创建针对特定职位描述优化的 定制简历 [27]。
  7. 描述了用户如何使用应用，例如首次简历创建、简历定制、迭代改进和个人资料管理 [29]。
  8. 这基本上是从 最终用户角度 描述需求，不涉及技术 [30]。
  9. 命令完成后，specs 文件夹下会添加一个名为 spec.md 的新文件 [32]。
  10. 该文件将初始提示映射到模板，并转换为 Spec Kit 识别的格式 [33]。
  11. 令人印象深刻的是，它将需求分解为 功能需求，并为每个需求编号 [34]。
  12. 有了这个全面的规范，就可以进入 plan 阶段 [35]。

2.2. 阶段二：Plan (添加技术细节) [36]

  1. Spec Kit 添加了 plan 命令 [36]。
  2. 现在可以开始提供关于 如何实现 的技术细节 [37]。
  3. 作者使用 plan 命令，指定使用 Next.js、shad CN 作为 UI，以及 Neon 作为数据库 [38]。
  4. Plan 步骤耗时约 半小时 才完成 [39]。
  5. 这个规划步骤是 “Token 吞噬者” (token hog) [40]。
  6. 它用完了作者的 Opus token 限制，导致作者不得不中途切换到 Sonnet 4 [41]。
  7. 这种规划方式相比 “随性编码” (vibe coding) 有一些优势 [42]。
  8. 优势包括：
    1. 它考虑了 架构 [43]。
    2. 它创建了五个库：Profile Manager、Resume Builder、AI Analyzer 和 Export Service [44]。
    3. 它实现了 测试驱动设计 (TDD)，考虑了所有需要构建的测试 [45]。
    4. 它采用了 “契约优先” (contract first) 方法 [48]。
      1. 这意味着它在编写任何代码之前，首先定义了 API [49]。
  9. 规划阶段的产物 (Artifacts)：
    1. 它创建了所有 API 的 OpenAPI 规范 [51]。
    2. 它提供了 数据模型 和一个清晰的 实体关系概览 (ERD) [52]。
    3. ERD 展示了所有不同的表及其相互关系，详细规划了数据库 [53]。
    4. 它包含 模式定义 (schema definitions) [55]。
    5. 它甚至考虑了用于性能的 索引策略 [56]。
  10. 作者认为这个规划非常全面，但可能 “有点过于全面” [57]。
  11. 命令的层叠关系：
    1. specify 提供了需求和用户视角 [60]。
    2. plan 深入技术细节，完成了详细的技术规范 [61]。

2.3. 阶段三：Task (分解为独立任务) [63]

  1. 下一个阶段是 tasks [62]。
  2. 此阶段将所有计划分解为 AI 稍后可以使用的 独立任务 [63]。
  3. task 命令运行相对较快，只用了几分钟 [64]。
  4. 它生成一个 tasks.md Markdown 文件 [65]。
  5. 该文件首先加载 plan.md（上一步创建的文件），以提供实现所需的所有细节 [66]。
  6. 然后，它将所有内容分解为不同的任务，例如 设置任务 和 数据库模式任务 [67]。
  7. 作者发现最有趣的是它坚持 测试驱动开发 (TDD) [68]。
  8. 它要求 必须先编写测试并使其失败，然后才能开始任何实现 [69]。
  9. 它计划先编写所有测试，让它们失败，然后才开始实现实际的应用程序 [70]。
  10. 接下来，作者尝试实现所有这些内容，看看是否能顺利运行 [72]。

3. 实现与结果评估 [73]

thumbnail
  1. 没有特殊的实现命令 [73]。
  2. 只需输入 implement，然后选择 task.md 文件 [74]。
  3. 该文件会引用 plan.md 和所有其他必要的参考资料 [75]。

3.1. 实现过程和挑战 [77]

  1. 实现过程耗时 超过一小时 [78]。
  2. 它多次填满上下文窗口，作者不得不 压缩 (compact) 它 [79]。
  3. 它也多次停止，作者不得不要求它 继续 [81]。
  4. 这个过程使用了 大量的 token，但确实编写了大量的代码 [83]。
  5. AI 声称应用现在 功能齐全 [84]。
  6. 它承诺具备完整的用户认证、授权、带有流式响应的简历定制和置信度评分 [85]。
  7. AI 做出了许多重大承诺 [86]。
  8. 作者输入了 Neon 和 Clerk 的所有 API 密钥和连接字符串 [87]。
  9. （插入作者的通讯订阅推广） [89]

3.2. 最终结果和失望之处 [93]

  1. 最终结果的 第一印象 看起来不错，界面干净 [93]。
  2. 应用能 立即运行，这一点非常好 [94]。
  3. Clerk 集成也 直接工作，使用 Gmail 账户登录并问候了作者的名字 [96]。
  4. 失望之处：
    1. UI 方面，个人资料和简历部分似乎可以工作，但点击 “模板” 时应用崩溃 [99]。
    2. 尽管进行了大量规划，但应用程序 并未完全完成 [100]。
    3. 它遗漏了一些关键部分 [101]。
    4. 例如，可以创建新个人资料，但只显示 专业摘要 [102]。
    5. 它没有提供工作经验、教育、技能等所有元数据 [102]。
    6. 甚至专业摘要也 无法保存 [104]。
    7. 弹窗提示 “保存功能尚未实现，只是一个 UI 演示” [105]。
    8. 这与 AI 完成项目时声称 “一切都已完成，可投入生产” 的说法正好相反 [105]。
    9. 这更像是一个项目的 “第一步”，而不是一个完整的项目 [108]。
    10. 它选择了 Next.js 14，作者认为这不是一个好的选择 [110]。
    11. 作者认为经过如此多的规划，AI 不应该选择一个 过时的版本 [111]。

3.3. 喜欢的部分：架构和契约管理 [112]

  1. 作者喜欢 一致的组件架构 [112]。
  2. 在 source 文件夹中，它构建了所有组件 [113]。
  3. 它将不同的服务分解为自己独特的服务组件 [114]。
  4. 例如，Profile Manager 与 Export Service 是分开的 [115]。
  5. 作者也喜欢 API 契约管理 和 状态管理 的实现 [117]。
  6. 在 /api 中，有针对个人资料、简历和模板的不同 API 端点 [118]。
  7. 甚至还有一个 健康检查 API (health API) [119]。
  8. 它在分离 API 和契约方面做得非常好 [121]。
  9. 在 specs 文件夹中，有很好的 API 文档，可以在添加新组件时参考 [122]。
  10. 相比 “随性编码”，这部分的组织结构要好得多 [123]。
  11. 由于采用了 TDD，它创建了 test 文件夹 [124]。
  12. 作者喜欢它将测试分为 契约测试、集成测试、库测试、性能测试 和 单元测试 [125]。
  13. 至少它为全面的测试套件奠定了基础 [126]。
  14. 尽管如此，测试套件的完成度不如作者基于规划阶段的工作所预期的那样完整 [127]。

4. 最终结论和未来策略 [128]

thumbnail
  1. 作者对 Spec Kit 的初步评价是：它是一个 好的框架 和 好的工具集 [128]。
  2. 但作者认为它 试图做太多事情 [129]。
  3. 作者计划尝试将 Spec Kit 的范围缩小，例如仅用于 新功能 而非整个应用程序 [130]。
  4. 作者不喜欢它长时间脱离用户交互进行规划 [132]。
  5. 作者更喜欢与 AI 编码时的 来回互动 [133]。
  6. 作者认为 AI 还没有足够好，不能独自规划一小时 [134]。
  7. 然而，Spec Kit 框架中包含各种优秀的 Markdown 文件 [135]。
  8. 用户可以只选取其中适合自己的部分，并根据自己的工作方式进行定制 [136]。
  9. 作者的策略是 取其精华，去其糟粕 [137]。
  10. （视频结束语） [138]