Hi～大家好呀，我是清汤饺子。

之前写了不少 Cursor 和 Claude Code 的单独教程，但最近被问得最多的一个问题其实是： "你平时到底用哪个？两个都装了吗？"

我的答案是：都用。

不是因为我钱多烧得慌，而是这两工具真的互补。用了一段时间组合拳之后，我的开发效率又上了一个台阶。今天就来聊聊我的真实使用心得。

---

一、我踩过的坑：只用其中一个的局限

1. 只用 Cursor？热情过头容易翻车

刚开始我是 Cursor 重度用户，毕竟 IDE 里直接写代码的感觉很顺。但用久了发现一个问题：Cursor 太"积极"了。

有时候我只是想改个小样式，它能给你整出来一套组件抽象。我只是想加个简单的加载状态，它直接给你上了一整套状态管理方案。

不是说不好，而是有时候我真的就只想——快点搞定，别整那么多花活。

2. 只用 Claude Code？终端操作有局限

后来切到 Claude Code，发现上下文理解确实强，代码质量也更高。但问题是：它毕竟是 命令行工具 ，对 GUI 项目有点不太友好。

比如我想在浏览器里调试一个 CSS 动画，想在某个特定的光标位置试试某个交互——这种事在终端里做起来就没有那么直接。

3. 结论：没有银弹

所以我的结论是：两个工具各有各的擅长领域，硬要二选一反而是给自己找麻烦。组合使用才是最优解。

---

二、场景分工：什么时候用哪个

经过几个月的磨合，我是这么分工的：

1. Cursor 更适合这些场景

1. 快速原型搭建

当我要验证一个新想法或者快速搭一个 demo，Cursor 的多文件编辑能力很强，能一次性给你生成一整套页面。这种场景 Claude Code 也可以，但 Cursor 更"短平快"。

2. 批量文件修改

比如我要把项目里 20 个组件的样式从 less 迁移到 styled-components，或者批量替换某个 API 调用——这种事 Cursor 的批量编辑效率很高。

3. GUI 调试

在浏览器里点点改改，看看效果，这种事 Cursor 集成得更好。Claude Code 的话你得靠终端里的预览，体验稍差。

2. Claude Code 更适合这些场景

1. 代码审查

把一堆代码丢给 Claude Code，让它帮我 review 一下质量、看看有没有潜在的 Bug——这种事 Claude Code 做得很漂亮。上下文理解能力强，能发现一些我自己可能忽略的问题。

2. 复杂重构

当我要对一个大文件或者多个模块做重构的时候，我会用 Claude Code 出方案，然后让它一步步来。Cursor 虽然也能做，但复杂场景下 Claude Code 的规划能力更强。

3. 长对话需求

比如我要和 AI 讨论一个架构设计，或者让它帮我分析一段老代码的逻辑——这种需要多轮对话的场景，Claude Code 的体验明显更好。

---

三、工作流串联：1+1>2 的组合拳

光说场景可能还是有点虚，来说说我每天是怎么组合用这两个工具的。

1. 新功能开发流

1. 用 Cursor 快速搭架子：新功能的页面和基础组件，用 Cursor 快速生成第一版
2. 用 Claude Code 审查优化：把代码丢给 Claude Code，让它帮忙看看有没有改进空间
3. 回到 Cursor 执行：根据 Claude Code 的建议，在 Cursor 里做精细调整

2. Bug 修复流

1. 用 Cursor 定位问题：在代码里直接搜索定位，Cursor 的跳转和搜索功能比较好用
2. 用 Claude Code 分析根因：把相关代码丢给 Claude Code，让它帮忙分析可能的原因
3. 回到 Cursor 修复：确认方案后在 Cursor 里执行修复

3. 代码重构流

1. 用 Claude Code 出方案：让它先分析现有代码，设计重构方案
2. 用 Cursor 执行：根据方案在 Cursor 里一步步改，Cursor 的修改精度更高

4. 我的每日模板

早上开工：
→ 用 Claude Code 过一遍昨天的代码，快速 review
→ 用 Cursor 开始今天的功能开发

下午：
→ 遇到复杂问题切 Claude Code 对话
→ 批量修改切 Cursor 执行

收工前：
→ Claude Code 总结今天改动，生成 commit message

---

四、实战心得：三个月磨合出来的经验

1. Rules 和提示词怎么差异化配置

Cursor 和 Claude Code 我配的 Rules 不太一样：

Cursor侧重于项目的技术规范——用什么组件库、用什么命名方式、样式写在哪个文件里。这种偏"执行层"的东西 Cursor 更容易遵守。

Claude Code侧重于架构和设计原则——为什么要这样设计、有什么权衡、哪种方案更合理。这种偏"思考层"的东西 Claude Code 更擅长。

2. 两个工具的上下文如何互补

我有个小技巧：用 Claude Code 建立项目记忆。

每次项目有重大架构调整或者加了新模块，我会用 Claude Code 做一个详细的分析和总结，然后把这个结论记在项目文档里。下次 Cursor 接手这个项目的时候，就能通过读取文档快速了解上下文。

3. 避免"两个 AI 打起来"

有时候两个工具会给出一致的建议，那挺好；但有时候它们意见不一致，甚至互相否定对方的方案。

我的处理方式是：听更了解项目上下文那个的。

比如这个模块是我用 Cursor 写的，Cursor 更清楚细节，那就以 Cursor 为主。反之亦然。

---

五、最后

说了这么多，其实就想说一点：工具是手段，不是目的。

不管你用 Cursor 还是 Claude Code，还是两个组合用，最重要的还是解决实际问题。不要为了用工具而用工具，也不要因为某个工具火就跟风。

找到最适合你自己的工作流，让它为你服务——这才是正经事。

也欢迎关注我的公众号「清汤饺子」，获取更多技术干货！

Hi～大家好呀，我是清汤饺子。

先说个我踩过不止一次的坑。

我要加个功能，跟 AI 说"加个用户登录"。AI 热情开干，半小时后给我整了个完整的 Auth0 集成方案——OAuth 2.0、JWT、refresh token，应有尽有。

我只想要一个最简单的本地账号密码登录。

AI 很委屈：你不就说"加个用户登录"吗？我以为……

我：我也以为你能读懂我的心思。

问题出在哪？不是 AI 不够努力，是我们在起点就没有对齐"做什么"。

然后我发现了 Spec Kit——GitHub 官方的 Spec-Driven Development 工具包。

GitHub 说：为什么不反过来试试？让规格说明书变成可执行的，代码来服务规格，而不是规格服务代码。 听起来很简单对吧？但背后的思路很根本。

一、Spec-Driven Development：规格说明书才是老大

传统开发里，代码是老大，规格说明书是跟班。 我们写 PRD、设计文档、技术方案，这些是"脚手架"——搭完就扔。代码往前走，文档跟不上，最后代码就是规格，规格就是代码。 这句话听起来很熟悉对吧？每个团队都经历过"代码改了三版，文档还停在 v0.1"的痛苦。

我们写 PRD、设计文档、技术方案，这些是" scaffolding "——搭完就扔。代码往前走，文档跟不上，最后代码就是规格，规格就是代码。

这是 GitHub 想翻过来的。

Spec-Driven Development（ SDD ） 的核心主张是：规格说明书变成可执行的，代码是规格的输出，而不是规格的指导。

翻译成人话：以前是"我想清楚，然后写代码"；现在是"我想清楚，写规格，AI 从规格生成代码"。

这不是在改进写代码的方式，这是在重新定义谁来当老大。

二、Spec Kit 是什么

GitHub 官方出的，听起来就很靠谱对吧？ 实际上也确实靠谱——GitHub 的工程团队自己就在用这套方法论来开发产品，所以 Spec Kit 不是纸上谈兵，是从自己的真实工作里提炼出来的。

定位：让你聚焦在"产品场景和可预期结果"上，而不是从零开始 vibe coding 每一个细节。

它提供一套结构化的工作流，让 AI 从"你说什么我做什么"变成"你说什么——我来确保做对"。

支持 Claude Code、Codex、Cursor 等主流 AI 编程工具。

三、六步工作流（核心）

整个工作流的设计思路很清晰：先定规矩 → 说清楚做什么 → 给技术方案 → 拆成小任务 → 执行 → 随时检查。每一步都有 slash command 对应，不用记复杂参数，AI 帮你串联全程。

1. Constitution —— 定规矩

/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements

这一步创建项目的治理原则：代码质量标准、测试要求、UX 一致性规范、性能指标。

这些原则会指导后续所有的开发工作，相当于给 AI 定下了"宪法"。

2. Specify —— 写规格

这是最重要的一步，也是 Spec Kit 和普通 AI 编程最大的区别。你只管说"做什么"，技术细节完全不用操心。 你会发现——当你只说"做什么"的时候，AI 反而能更好地理解你的意图，不会自己脑补一堆"你可能想要"的功能。这大概就是传说中的少即是多吧。

/speckit.specify Build an application that can help me organize my photos in separate photo albums. Albums are grouped by date and can be re-organized by dragging and dropping on the main page. Albums are never in other nested albums. Within each album, photos are previewed in a tile-like interface.

这一步描述你要做什么。聚焦在"做什么"和"为什么"，不要管技术栈。

你会发现——当你只说"做什么"的时候，AI 反而能更好地理解你的意图，不会自己脑补一堆"你可能想要"的功能。

3. Plan —— 给方案

/speckit.plan The application uses Vite with minimal number of libraries. Use vanilla HTML, CSS, and JavaScript as much as possible. Images are not uploaded anywhere and metadata is stored in a local SQLite database.

规格确认后，这一步给出技术方案：选什么框架、用什么数据库、依赖怎么管理。

Plan 是规格和技术决策之间的桥梁——规格说"要一个照片应用"，Plan 说"用 Vite + SQLite + 原生 JS 来实现"。

4. Tasks —— 拆任务

/speckit.tasks

AI 根据 Plan 自动拆解成可执行的任务清单。每个任务精确到文件路径、验收标准，完成一个打一个勾。

5. Implement —— 执行

/speckit.implement

AI 按照任务清单一个个执行。和 OpenSpec 一样，严格按照 Plan 来，不会自己跑偏。

6. Review & Iterate —— 检查和迭代

实现过程中可以随时回到前面的步骤调整。规格改了，Plan 自动更新，Tasks 自动重新生成。

四、和 OpenSpec 的区别

这是大家最常问的问题。

	OpenSpec	Spec Kit
出品方	Fission-AI	GitHub 官方
工作流	propose → apply → archive	constitution → specify → plan → tasks → implement
风格	轻量、迭代友好	正式、有"宪法"概念
团队协作	支持	更好（支持 branch + merge 规格版本管理）
社区扩展	较少	丰富（Jira、Azure DevOps 等集成）

简单说：OpenSpec 更轻量，适合个人开发者快速上手；Spec Kit 更完整，适合团队协作和有正式流程要求的项目。

五、社区扩展生态（这是亮点）

这是我觉得 Spec Kit 最值得期待的地方——生态正在生长，而且很有意思。 截止目前社区已经贡献了十几种扩展，挑几个我，觉得特别有想法的说说：

集成类：

• Jira Integration：把 spec 规格自动同步到 Jira Epics 和 Stories
• Azure DevOps Integration：同步到 Azure DevOps Work Items

代码质量类：

• Checkpoint Extension：实现中途提交，不至于最后只有一个巨大的 commit
• Cleanup Extension：实现完成后自动 review 改动，修小问题，标记中等问题，生成大问题报告

流程类：

• Fleet Orchestrator：全生命周期编排，带 human-in-the-loop 关卡
• Cognitive Squad：多智能体认知系统，理解→内化→应用

文档类：

• Archive Extension：合并后归档到项目记忆
• DocGuard：Canonical-Driven Development 文档校验和评分

这些扩展开箱即用，按需安装。

六、怎么装

# 推荐：用 uv 持久安装（稳定版）
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

# 或者一次性运行（不需要安装）
uvx --from git+https://github.com/github/spec-kit.git@vX.Y.Z specify init <PROJECT_NAME>

⚠️ 前提：需要先安装 uv（一个极快的 Python 包管理器）。如果没装过，执行这一行就行：

curl -LsSf https://astral.sh/uv/install.sh | sh

装好后，在项目目录运行 specify init . --ai claude，AI 助手会自动识别并加载 Spec Kit。

七、技术原理

如果你对"它怎么做到的"感兴趣，这节简单说说。不感兴趣可以跳过，不影响你用它。

Spec Kit 的核心架构分四层，理解起来很简单：

• Specify CLI：命令行工具，负责初始化项目、管理扩展、调度 AI Agent。是整个工具的入口。

• Slash Commands（/speckit.*）：用户和 AI 交互的主要方式。每个 command 对应一个工作流阶段，AI 根据当前阶段决定下一步。

• Spec Artifacts：规格说明书的输出格式。包含：

  • SPEC.md——产品需求文档
  • PLAN.md——技术实现方案
  • TASKS.md——任务清单
  • CONSTITUTION.md——项目治理原则

• Extension System：社区扩展的插拔机制。扩展分为五类：

  • docs——读写/校验/生成规格文档
  • code——review/校验/修改代码
  • process——跨阶段工作流编排
  • integration——同步外部平台
  • visibility——项目健康度报告

八、和 Superpowers + ECC 的关系

这是 Claude skills 第四篇了，终于可以凑齐一桌麻将：

工具	出品	解决的问题
Spec Kit	GitHub 官方	规格说明书 → 可执行，需求对齐
OpenSpec	Fission-AI	轻量规格流程，迭代友好
Superpowers	@obra	工程纪律，TDD + task 分解
ECC	@affaan-m	AI 性能和记忆，Token 优化

Spec Kit 和 OpenSpec 解决的是同一类问题（需求对齐），但 Spec Kit 更适合团队、更正式；OpenSpec 更轻量、更迭代。

Superpowers 在下游执行层——规格确认后，怎么按工程规范来做。

ECC 在底层——让 AI 跑得更稳、更快、更聪明。

四者组合，才是完整的 AI 编程工作流。

---

写在最后

用了 Spec Kit 之后，我最大的感受是： Spec Kit 把"我以为 AI 能读懂我"变成了"我明明白白告诉 AI 我要什么"。

这种感觉就像是——以前是让 AI 猜你的心思，现在是跟一个聪明但需要你说清楚的同事合作。累吗？稍微累一点，但返工少多了，信心也多了。

Spec Kit 解决的就是这个问题——在 AI 动笔之前，先把"要什么"定义清楚。

GitHub 官方的背书也意味着它的长期维护有保障，扩展生态会更丰富。

如果你在团队里推动 AI 编程，用 GitHub 官方出品的工具，说服成本会低很多——不用解释这个工具靠不靠谱，直接说"这是 GitHub 官方做的"就够了。

当然，它也有学习成本。六个 command、constitution 怎么写、plan 怎么给，都需要摸索。但这个成本是一次性的，投入产出比很高。

你试过 Spec Kit 吗？或者你更偏向 OpenSpec 的轻量路线？欢迎评论区聊聊。

如果觉得有帮助，点个赞收藏一下，我会有更多动力继续写这个系列。

也欢迎关注我的公众号「清汤饺子」，获取更多技术干货！

Hi～大家好呀，我是清汤饺子。

我曾经让 AI 改个按钮颜色，它噼里啪啦一顿操作，把整个配色系统重构了。

你问我什么配色系统？我没说要重构配色系统啊。

AI：但重构之后更好看啊。

……行吧。

这个场景你经历过吗？需求说加个功能，AI 直接把项目翻了个底朝天。最后你花的时间比不用 AI 还多三倍。

问题出在哪？不是 AI 不够聪明，是你和 AI 之间没有"签字画押" 。

然后我发现了 OpenSpec。

一、解决什么问题

AI 编程最大的噩梦，不是它写得慢，是它完全按自己的理解来。

你脑子里想的是 A，AI 理解的可能是 B，它输出的变成了 C。你还得花时间把 C 改回接近 A 的样子。

这就是没有"需求对齐"的问题。

传统的软件开发里，有个东西叫Spec（需求规格说明书） ——在动手之前，产品、设计、开发三方签字确认"我们要做什么"。

OpenSpec 把这个机制引入了 AI 编程：先签字，再干活。

不是让 AI 写文档，是让 AI 和你在"做什么"这件事上真正对齐。

二、OpenSpec 是什么

作者是 Fission-AI，GitHub 上叫 OpenSpec。

定位是：The most loved spec framework。

核心价值主张：在写代码之前，AI 和人类对"要做什么"达成一致。

它解决的是 Superpowers 和 ECC 没覆盖到的那个环节——Superpowers 管"工程纪律"，ECC 管"性能和记忆"，OpenSpec 管**"需求对齐"**。

三个工具解决的问题正好互补。

三、核心理念

OpenSpec 的 Philosophy 里有几条我特别认同：

fluid not rigid — 流畅不僵硬

它不是要你写几十页的瀑布式文档。Spec 应该像对话一样自然，迭代式的。

iterative not waterfall — 迭代而非瀑布

以前的需求文档是一次性写完，然后"锁死"。OpenSpec 的 spec 是可以迭代的，每次改动都有记录。

easy not complex — 简单不复杂

不要搞得太重，简单到你可以随时改。

built for brownfield not just greenfield — 支持存量项目

不只是新项目可以用，存量项目也能用。真实开发场景大多是在别人写的代码上改，不是从零新建。

scalable from personal to enterprise — 从个人到企业级

一个人能用，团队也能用。

四、核心工作流

OpenSpec 的工作流就三步，非常简单：

1. propose —— 提案

你告诉 AI：/opsx:propose add-dark-mode

AI 自动生成一整套文档：

• proposal.md — 为什么要做这个改动
• specs/ — 具体需求和边界情况
• design.md — 技术方案
• tasks.md — 任务清单，每个任务精确到文件路径

这是最让我惊喜的地方——以前要人类自己写需求文档，现在 AI 帮你写。你只需要确认、修改，不需要从零憋字。

2. apply —— 执行

你确认 spec 之后：/opsx:apply

AI 按照 tasks.md 清单一个个执行。每完成一个任务打一个勾，你可以随时喊停。

最关键的是：AI 严格按照 spec 来执行，不会自己跑偏。

你改个按钮颜色，它就只改按钮颜色，不会顺手把配色系统重构了。

3. archive —— 归档

收尾：/opsx:archive

归档到 openspec/changes/archive/，保持项目干净，下次新需求不影响旧的。

五、Artifact-Guided Workflow（新功能）

这是 v2 的核心升级。

以前是你手工写 spec，AI 按 spec 执行。现在是 AI 根据你的 idea 自动生成完整 artifact。

你只管说想做什么，AI 把 proposal、specs、design、tasks 全套给你生成出来。你审核、修改、确认，然后 apply。

人类只需要在关键节点做决策，不需要从头参与到每一个细节。

六、我的真实感受

惊喜时刻：

• 终于有了一个"需求对齐"的机制。AI 不会自己跑偏，因为它要按 spec 执行
• propose 之后 AI 自动生成 spec，质量居然还不错
• 有了 spec 做依据，code review 也轻松多了

崩溃时刻：

• spec 写错了，apply 之后全错了。AI 是严格按照 spec 执行的，spec 对它就是对，spec 错它就错
• 需要花时间养成写 spec 的习惯，一开始会觉得"这么麻烦干嘛"

适合谁：

• 有一定复杂度的需求，不是"改个 typo"这种
• 团队协作场景，需要对齐多方预期
• 讨厌 AI 自己跑偏的人

不适合谁：

• 简单任务，直接让 AI 写反而更快
• 纯探索性开发，还没想清楚要做什么

七、和 Superpowers + ECC 的关系

这三个工具解决的问题正好互补：

工具	解决的问题
OpenSpec	需求对齐 — 先签字再动手
Superpowers	工程纪律 — TDD、task 分解、子 Agent 编排
ECC	性能和记忆 — Token 优化、memory 持久化、安全扫描

OpenSpec 在最上游——它管的是"做什么"。

Superpowers 在中游——它管的是"怎么做"。

ECC 在底层——它管的是"怎么跑得更好"。

三个一起用，才是完整的 AI 编程工作流。

八、技术原理

看完 GitHub 仓库，我发现 OpenSpec 的核心设计非常简洁——它不是给 AI 增加能力，而是给 AI 和人类之间增加一个"共同文档"作为契约。

1. 核心机制：Artifact + 人类确认

OpenSpec 的工作流核心是 Artifact 生成 + 人类确认：

1. 你 提出一个 high-level 的想法（"我想加个深色模式"）
2. AI 根据你的想法，自动生成一整套 Artifact（proposal.md、specs、design.md、tasks.md）
3. 你 审核、修改、确认这整套文档
4. AI 严格按照确认后的 Artifact 执行

关键是：在第三步你签字确认之前，AI 不会动手写代码。

2. OpenSpec Directory 结构

OpenSpec 在项目根目录创建的结构非常清晰：

openspec/
├── changes/
│   └── archive/         # 每次改动的归档
├── specs/               # 需求规格
├── design/              # 技术方案
├── tasks/               # 任务清单
└── .openspecrc          # 配置文件

这个结构让每一次改动都有据可查、可回滚。

3. propose 的内部逻辑

当 AI 执行 /opsx:propose 时，内部经历：

1. 理解需求：AI 解析你的自然语言输入
2. 生成 proposal.md：回答"为什么要做这个改动"
3. 生成 specs/ ：拆解需求成具体规格和边界情况
4. 生成 design.md：给出技术方案和备选方案
5. 生成 tasks.md：拆解为可执行的任务清单，每个任务精确到文件路径

这个过程本质上是 Socratic 式的 逆向工程——AI 不是在执行，而是在问你"你要做什么、做到什么程度"。

4. 人类在环（Human-in-the-Loop）

OpenSpec 每一层都有"人类确认"的节点：

想法 → proposal → 你确认 → specs → 你确认 → design → 你确认 → tasks → apply

这不是审批流程，这是 协作编辑。你在确认的过程中可以修改、补充、否定。AI 的 proposal 不是终点，是起点。

5. v2 Artifact-Guided Workflow 的升级

v2 最大的变化是：AI 不再只是执行者，还是提案者。

以前是"你写 spec，AI 执行"。现在变成"你说想法，AI 帮你写 spec，你确认，AI 执行"。

从"你主导"变成了"AI 主导生成，你主导确认"——这降低了使用门槛，让不擅长写 spec 的人也能用上这套方法论。

GitHub 仓库：github.com/Fission-AI/…

写在最后

OpenSpec 解决了一个根本问题：AI 编程最大的风险不是 AI 不够聪明，是人类和 AI 对"做什么"没有对齐。

你花 10 分钟写清楚 spec，AI 按 spec 执行，省掉的可能是一小时的返工。

当然，它不是万能的。spec 写对了才有效，写错了反而会误导 AI。

核心问题是：你愿不愿意在动手之前，先花时间想清楚"到底要做什么"？

这件事，AI 帮不了你。

---

你在 AI 编程时有没有过"AI 完全按自己理解来"的经历？最后是怎么解决的？欢迎评论区聊聊。

如果觉得有帮助，点个赞收藏一下，我会更有动力更新下一期。

也欢迎关注我的公众号「清汤饺子」，获取更多技术干货！