不太懂 openspec ，最近了解了一下。自己在某个仓库使用 openspec 写了一次需求，也观察了一下 openspec 自身是怎么使用的，发现 openspec 的 spec 似乎就是在用自然语言描述代码逻辑行为的各种 case 。以 openspec 仓库自身的 spec 为例，发现 spec.md 文件本身是在描述代码的行为逻辑。比如 openspec 的某个 spec.md 对应行为就是这个文件： https://github.com/Fission-AI/OpenSpec/blob/8332a098118a6584a7104ccfe8e46669a1c24b7d/src/utils/change-utils.ts#L112 ，spec.md 本身贴在末尾

我的问题是:

1. 这样的 spec 存下来有什么意义？因为我理解存下来是为了后续有其他需求迭代时给 ai 看的，那为什么不直接让 ai 去读代码来理解现有的逻辑呢？我理解大型项目让 ai 工作是需要知识库的，但是 openspec 的 spec 更像一个细节说明书，而不是类似纲领的知识库。是不是说在 openspec 的工作流里面 spec 才是代码仓库的行为核心准则，理论上基于 spec.md 可以随时生成一套具体实现可能不一致，但行为一致的代码。
2. openspec 的工作流程是先让 AI 进行 plan ，然后迭代 plan ，直到 AI 给出 plan 满意了，然后 AI 开始进行 coding 。这个 plan 的流程现在 antigravity 等也能做到。感觉 plan 并不是 openspec 的重点，spec.md 才是重点是吗？如果说期望的流程是先和 ai 讨论出充满细节的 spec ，再让 ai 开始 coding ，有种变成了自然语言描述写代码的感觉，这个感觉非常怪。
3. 基于 1 的末尾提出的“spec 才是代码仓库的行为核心准则”的想法，假设需要落地到一个前端项目，那按照这个 spec 粒度，我感觉每个 tsx 文件都需要一个 spec 去描述它的规范行为。这个感觉就更怪了

有没有实践比较多的朋友能给一些输入，分享一些经验，或者思考？

附上的 spec.md

change-creation 规范

目的（ Purpose ）

提供用于以编程方式创建和校验 OpenSpec change 目录的工具函数。

需求（ Requirements ）

需求：Change 创建（ Change Creation ）

系统 必须（ SHALL ） 提供一个函数，用于以编程方式创建新的 change 目录。

场景：创建 change

• 当（ WHEN ） 调用 createChange(projectRoot, 'add-auth')
• 那么（ THEN ） 系统会创建 openspec/changes/add-auth/ 目录

场景：拒绝重复的 change

• 当（ WHEN ） 调用 createChange(projectRoot, 'add-auth')，且 openspec/changes/add-auth/ 已存在
• 那么（ THEN ） 系统抛出一个错误，表明该 change 已存在

场景：必要时创建父目录

• 当（ WHEN ） 调用 createChange(projectRoot, 'add-auth')，且 openspec/changes/ 不存在
• 那么（ THEN ） 系统创建完整路径，包括所有必要的父目录

场景：拒绝非法的 change 名称

• 当（ WHEN ） 使用非法名称调用 createChange(projectRoot, 'Add Auth')
• 那么（ THEN ） 系统抛出一个校验错误

需求：Change 名称校验（ Change Name Validation ）

系统 必须（ SHALL ） 校验 change 名称符合 kebab-case 规范。

场景：合法的 kebab-case 名称被接受

• 当（ WHEN ） 校验一个类似 add-user-auth 的名称
• 那么（ THEN ） 校验返回 { valid: true }

场景：允许数字后缀

• 当（ WHEN ） 校验一个类似 add-feature-2 的名称
• 那么（ THEN ） 校验返回 { valid: true }

场景：允许单个单词

• 当（ WHEN ） 校验一个类似 refactor 的名称
• 那么（ THEN ） 校验返回 { valid: true }

场景：拒绝大写字母

• 当（ WHEN ） 校验一个类似 Add-Auth 的名称
• 那么（ THEN ） 校验返回 { valid: false, error: "..." }

场景：拒绝空格

• 当（ WHEN ） 校验一个类似 add auth 的名称
• 那么（ THEN ） 校验返回 { valid: false, error: "..." }

场景：拒绝下划线

• 当（ WHEN ） 校验一个类似 add_auth 的名称
• 那么（ THEN ） 校验返回 { valid: false, error: "..." }

场景：拒绝特殊字符

• 当（ WHEN ） 校验一个类似 add-auth! 的名称
• 那么（ THEN ） 校验返回 { valid: false, error: "..." }

场景：拒绝以连字符开头

• 当（ WHEN ） 校验一个类似 -add-auth 的名称
• 那么（ THEN ） 校验返回 { valid: false, error: "..." }

场景：拒绝以连字符结尾

• 当（ WHEN ） 校验一个类似 add-auth- 的名称
• 那么（ THEN ） 校验返回 { valid: false, error: "..." }

场景：拒绝连续连字符

• 当（ WHEN ） 校验一个类似 add--auth 的名称
• 那么（ THEN ） 校验返回 { valid: false, error: "..." }