简单学习了一下 https://github.com/github/spec-kit，确实是一个很有趣的项目。
作为一个资深的开发者，在我看来，spec-kit 就是试图在扮演我每天都在做的事情，试图以标准化的方式完成从需求到产品的过程：
1. 模拟场景，撰写 user story。
2. 根据 user story，编写需求文档（相当于
3. 根据需求，撰写技术文档，进行可行性分析和系统设计（相当于
4. 根据技术文档，拆分开发任务。如果选择 TDD 的开发模式，则可以同步编写测试用例（相当于
5. 各个开发人员和测试人员，认领任务，进行开发和测试（相当于
在我的实际上和 AI 协作 coding 的经验看来，实际上还少了一个很关键的步骤，应该可以视为
我之前使用 Augment Code 时，发现它对每一个项目，都会维护一个全局的 memory，从而让 Agents 能够在一个统一的上下文中工作。这个 memory 里面，包含了项目的概要，需要关注的重要功能点，相关规范等等，类似于一个专注于当前项目的
我可以理解，对于那些对标准开发流程比较陌生的初级开发者而言，或者对于那些纯粹 vibe coding 的人而言，spec-kit 无疑是一个巨大的进步，显著提高了开发结果的确定性。不过，有一个地方让我觉得有点奇怪，spec-kit 居然需要开发者手动来逐步执行
从我个人来说，我不会考虑实际使用 spec-kit，有如下原因：
1. 作为一名资深开发者，我已经熟悉了标准的产品研发流程，不需要 spec-kit 用如此笨拙的方式来引导我，它的工作流在我看来过于粗糙。
2. 正如官方的视频介绍中所说，“spec-kit 让你只需要关心 What 和 Why，而不需要关心 How”。但是我认为，目前的模型能力还不足以让我完全不关心 How。
3. 为了降低成本，我倾向于尽可能减少和 AI 对话的次数，而 spec-kit 显然会大幅增加我和 AI 交互的频次。
综上，我认为 spec-kit 是一个很好的试图对 vibe coding 标准化的尝试。它就像一幅重型铠甲，如果你武艺平平，那么它会显著提高你的战斗力。但是对于那些武艺高强的武士而言，它反而会拖累你的身手，让你无法发挥出真正的实力。所以是否要采用它，取决于当前项目对于开发流程的 vibe 程度有多高。
我认为，spec-kit 的价值体现在：
1. 对于 vibe coder，作为一种提高标准化和确定性的工具，提高产品质量。
2. 对于和 AI 协作的开发者，提供了一个参考，可以用来优化开发流程和 prompt 设计。
3. 对于 agents 的设计者，提供了一个完整的和用户交互的流程，可以用来设计能够完成用户需求的 agents。
Ps. 我更倾向于认为，spec-kit 所提供的辅助，很快（或者已经）被强化学习或 fine-tuning 内化为模型本身的能力，而不需要外部的工具来辅助。
最后，我个人对开发模式的看法是，短期内 AI 编程 Agents 仍然和资深开发者存在一些本质上的差距，但是这并不影响它能够极大的提高开发效率，并且独立完成大量的产品。我认为，短期内两种不同类型的人类开发者角色将会并存：
1. 一种是白盒开发，人类开发者掌控核心的细节，AI 扮演辅助角色，帮助人类开发者提高效率。
2. 另一种是黑盒开发，也就是所谓的 vibe coding，AI 扮演主导角色，人类开发者主要负责提出需求和验收结果。
这两种模式都有其适合的场景和生存空间，具体选用什么工具和开发流程，还是要取决于具体的项目需求。
作为一个资深的开发者，在我看来，spec-kit 就是试图在扮演我每天都在做的事情，试图以标准化的方式完成从需求到产品的过程：
1. 模拟场景，撰写 user story。
2. 根据 user story，编写需求文档（相当于
/speckit.specify）。3. 根据需求，撰写技术文档，进行可行性分析和系统设计（相当于
/speckit.plan）。4. 根据技术文档，拆分开发任务。如果选择 TDD 的开发模式，则可以同步编写测试用例（相当于
/speckit.tasks 和 /speckit.checklist）。5. 各个开发人员和测试人员，认领任务，进行开发和测试（相当于
/speckit.implement）。在我的实际上和 AI 协作 coding 的经验看来，实际上还少了一个很关键的步骤，应该可以视为
/speckit.clarify 的补充，就是收集相关 工具、SDK、API 的详细使用文档，以便于 AI 能够理解和正确地使用这些工具。我之前使用 Augment Code 时，发现它对每一个项目，都会维护一个全局的 memory，从而让 Agents 能够在一个统一的上下文中工作。这个 memory 里面，包含了项目的概要，需要关注的重要功能点，相关规范等等，类似于一个专注于当前项目的
Agents.md 文件。这个文件，在 spec-kit 中被称为 constitution。我可以理解，对于那些对标准开发流程比较陌生的初级开发者而言，或者对于那些纯粹 vibe coding 的人而言，spec-kit 无疑是一个巨大的进步，显著提高了开发结果的确定性。不过，有一个地方让我觉得有点奇怪，spec-kit 居然需要开发者手动来逐步执行
specify、plan、tasks、checklist、implement 这些步骤，而不是直接让 AI 来直接完成这些步骤，对于 vibe coder 而言可能过于繁琐。从我个人来说，我不会考虑实际使用 spec-kit，有如下原因：
1. 作为一名资深开发者，我已经熟悉了标准的产品研发流程，不需要 spec-kit 用如此笨拙的方式来引导我，它的工作流在我看来过于粗糙。
2. 正如官方的视频介绍中所说，“spec-kit 让你只需要关心 What 和 Why，而不需要关心 How”。但是我认为，目前的模型能力还不足以让我完全不关心 How。
3. 为了降低成本，我倾向于尽可能减少和 AI 对话的次数，而 spec-kit 显然会大幅增加我和 AI 交互的频次。
综上，我认为 spec-kit 是一个很好的试图对 vibe coding 标准化的尝试。它就像一幅重型铠甲，如果你武艺平平，那么它会显著提高你的战斗力。但是对于那些武艺高强的武士而言，它反而会拖累你的身手，让你无法发挥出真正的实力。所以是否要采用它，取决于当前项目对于开发流程的 vibe 程度有多高。
我认为，spec-kit 的价值体现在：
1. 对于 vibe coder，作为一种提高标准化和确定性的工具，提高产品质量。
2. 对于和 AI 协作的开发者，提供了一个参考，可以用来优化开发流程和 prompt 设计。
3. 对于 agents 的设计者，提供了一个完整的和用户交互的流程，可以用来设计能够完成用户需求的 agents。
Ps. 我更倾向于认为，spec-kit 所提供的辅助，很快（或者已经）被强化学习或 fine-tuning 内化为模型本身的能力，而不需要外部的工具来辅助。
最后，我个人对开发模式的看法是，短期内 AI 编程 Agents 仍然和资深开发者存在一些本质上的差距，但是这并不影响它能够极大的提高开发效率，并且独立完成大量的产品。我认为，短期内两种不同类型的人类开发者角色将会并存：
1. 一种是白盒开发，人类开发者掌控核心的细节，AI 扮演辅助角色，帮助人类开发者提高效率。
2. 另一种是黑盒开发，也就是所谓的 vibe coding，AI 扮演主导角色，人类开发者主要负责提出需求和验收结果。
这两种模式都有其适合的场景和生存空间，具体选用什么工具和开发流程，还是要取决于具体的项目需求。
GitHub
GitHub - github/spec-kit: 💫 Toolkit to help you get started with Spec-Driven Development
💫 Toolkit to help you get started with Spec-Driven Development - github/spec-kit
