用 github/spec-kit 把 AI 编码从“氛围编程”变成可落地流程，前端团队也能用

用 github/spec-kit 把 AI 编码从“氛围编程”变成可落地流程，前端团队也能用

导语

现在前端团队用 AI 写代码已经不算新鲜事了，但大多数人还在“氛围编程”阶段：给一段需求描述，AI 就输出一长串代码，看着对，跑起来却不一定对。最近 GitHub 开源的 github/spec-kit 把“规范驱动开发”这套思路接上了 AI，前端项目一样能用，而且可落地。

正文

问题：前端项目里，AI 写代码为什么越写越乱

过去一年多，前端团队普遍遇到这几件事：

• 同一个功能，AI 每跑一次代码风格都不一样；
• 需求在 Prompt 里写清楚了，落地到组件还是缺边界判断；
• 团队里不同人用的 AI 工具不一样，Cusor、Claude Code、Copilot 各写各的，结果无法对齐。

说白了，问题不是“AI 不够聪明”，而是缺一个所有人都遵守的“上层规范”。没有规范，AI 生成的代码本质上还是发散式的。

方案：Spec-Kit 的三层结构，不是新框架，是流程规范

github/spec-kit 的核心思路很直接：不是让 AI 直接写代码，而是让 AI 先读规范，再写代码。

它把流程拆成四层：

• constitution：项目宪法，定义代码质量、测试标准、UI 一致性等底线；
• specify：规格说明，只写“做什么”和“为什么”，不写技术栈；
• plan：技术方案，再落到框架、目录、依赖；
• tasks：任务拆解，把大方案拆成可执行的实现任务。

这四层文件一旦写好，后面不管是 Claude Code、GitHub Copilot、Gemini CLI 都能按同一套规范执行。对团队来说，相当于把“个人经验”变成了“团队资产”。

代码/截图：前端项目里怎么接上 Spec-Kit

Spec-Kit 本身不是前端框架，但可以嵌入任意前端项目。一个最朴素的接入方式是这样：

# 1. 安装 CLI
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# 2. 初始化项目
specify init my-frontend-project --integration claude

# 3. 生成项目宪法
specify constitution
# 输出：.specify/memory/constitution.md

# 4. 写规格说明
specify specify
# 输出：specs/xxx.md、checklists/requirements.md

# 5. 生成实施计划
specify plan
# 输出：specs/xxx-plan.md

# 6. 拆任务并执行
specify tasks
specify implement

对前端项目最实用的，是前两步先把 constitution.md 和 spec.md 定好，比如：

• 组件必须写测试；
• 状态优先用 Zustand，复杂场景才用 Redux；
• UI 必须支持暗色模式；
• API 错误码必须做统一兜底。

这些规则写进 constitution 以后，AI 后面生成组件、页面、接口层时，都会优先遵守，而不是每次重新“发挥”。

结论：Spec-Kit 解决的不是“AI 能不能写代码”，而是“怎么写才可控”

对前端团队来说，Spec-Kit 的价值不在于某个具体功能，而在于把“AI 编码”从个人行为升级成工程行为。规范一旦沉淀成文档，新人上手、跨项目复用、甚至换模型都不受影响。

下一步你可以先做一件小事：在下一个前端需求里，不要直接丢需求给 AI，先写一版 10 行的 constitution.md，再让 AI 按规范生成组件，感受一下差别。