作为一个资深的开发者，在我看来，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 扮演主导角色，人类开发者主要负责提出需求和验收结果。
这两种模式都有其适合的场景和生存空间，具体选用什么工具和开发流程，还是要取决于具体的项目需求。
