效率 on 姚玉亮的网络日志

一次聊需求，三仓同落地：我的 superpowers 全栈开发工作流

Thu, 27 Aug 2026 09:00:00 +0800

一个跨三个仓库的需求

我最近接到一个挺典型的需求：数据集管理里，“文档核验"这个动作要留痕：谁核验的、什么时候核验的；核验完还要能按数据集分页翻历史记录；管理后台加一个"核验记录"入口，点击弹列表，下拉就能一直加载；上层的知识库问答服务也要同步暴露这个列表接口。

这个需求横跨三个仓库：数据集管理服务、数据管理后台、知识库问答服务。

以前这种需求在我这儿是这么过的：拉群对齐需求 → 各写各的需求文档 → 前后端各自开工 → 联调时发现字段名对不上、分页参数叫法不一样 → 返工。现在我用 Claude Code 的 superpowers 工作流走了一遍完整流程，发现整个链条可以压缩成四步：brainstorming 聊需求 → 方案对比 → 写 spec → 生成实施计划。

flowchart LR
 A["brainstorming 聊需求"] --> B["方案对比"] --> C["写 spec 落盘"] --> D["生成实施计划"] --> E["add-dir 挂三仓并行落地"]

第一步：先探索代码，再开口问

superpowers 的 brainstorming 第一步不是问"你想要什么”，而是先看项目上下文：路由注册在哪、handler 怎么写的、DAO 用的什么 ORM、前端页面结构、有没有现成的分页组件。

我让 Claude 把两个仓库都翻了一遍，结论：

数据集管理服务是 Hertz + GORM 的架构，核验逻辑在文档服务的 revise 方法里，文档表上已经有一个"核验状态"字段，核验时会把它置为"已核验"
管理后台是 React + antd，代码里已经有现成的 useInfiniteScroll 下拉加载 hook，数据详情页结构也很清晰

这一步的价值在于：问题基于真实代码，而不是基于想象。我不用花十分钟给 Claude 讲架构，它自己读出来的上下文，比任何人的转述都准确。比如"核验状态字段已经存在"这个事实，直接影响了后面的设计：记录表和状态字段是两回事，但很多人第一版设计会混在一起。

第二步：一次只问一个问题

brainstorming 最反直觉的一条规则是：一次只问一个问题。

我一开始也觉得慢。但跑下来发现，需求是逐层展开的：先问"核验记录需要存哪些字段"，确定存核验人和核验时间；再问"列表按什么过滤"，确定按数据集 ID；再问"前端入口放在哪"，确定放数据详情页。每个答案都会修正下一个问题，一次抛十个问题，模型只能靠猜排优先级，猜错一半就得返工。

对话节奏大概是这样的（简化示意，实际要比这细致）：

我：核验记录需要展示哪些字段？ Claude：先确认一下，除了核验人和核验时间，要不要把核验前后的版本号也存下来？这会决定表结构。我：先只存核验人和核验时间，跑通第一版。 Claude：好。那列表接口按数据集 ID 过滤、支持分页返回，这个方向对吗？

一次一个问题看着慢，其实最快：每个问题都建立在之前答案的基础上，方向不会歪。

第三步：给 2-3 个方案，而不是直接开写

需求聊清楚之后，brainstorming 会要求给出 2-3 个实现方案对比。这个需求当时有两个主流方案：

方案 A：复用现有的行为记录表。那张表是 JSON 半结构化的流水表，加一种行为类型就能记录，不用建新表。
方案 B：新建独立的核验记录表。字段干净，查询直接，列表接口就是一条简单的 WHERE dataset_id = ? 分页查询。

我选了 B。核验记录是高频查询的业务动作，独立表让列表接口简单直接；方案 A 虽然少建一张表，但查列表要拆 JSON，而且行为流水表的数据量会持续膨胀，不适合做业务查询的底座。

选完方案，设计按块确认：表结构一块、接口定义一块、前端改动一块、上层同步一块，确认完再写进 spec 文档，落盘到 docs/superpowers/specs/ 目录下。这份文档是后续实施计划的输入，也是代码评审时对照的依据：评审不再靠记忆，而是对着 spec 逐条核对。

第四步：add-dir 多项目，前后端同时动

设计获批后进入实施阶段。Claude Code 的 add-dir 可以把多个项目目录加进同一个会话，这个需求一次挂了三个目录：

数据集管理服务：建表、在核验接口里写记录、新增分页列表接口
管理后台：数据详情页加入口、列表抽屉、下拉加载
知识库问答服务：同步暴露列表接口

多目录的意义不只是"能改多个仓库"，而是 AI 同时持有两边的上下文：字段名、接口路径、分页参数天然一致，联调成本趋近于零。以前前后端联调要查半天"到底叫 page 还是 current"，现在在计划阶段就把契约定死了，代码照着写就行。

几个真实的感受

一次一个问题反直觉，但确实是最快的提问方式。需求是逐层展开的，一次一个才能保证每个问题都有价值。
探索比提问重要。让 AI 先读代码，它问出来的问题才有质量；不探索就问，问的都是网上搜得到的通用问题。
设计文档不是走流程。跨仓库改动里，它是唯一让所有人（包括几周后的你自己）对齐的锚点。代码评审对着 spec 审，比对着记忆审靠谱一个量级。
YAGNI。AI 很容易过度设计，比如顺手提一句"要不要顺便做个操作审计"。不需要，砍掉。每个设计阶段都要主动问：这个功能现在真的需要吗？

建议

如果你也在用 AI 写代码，别只停留在"让它写函数"的层面。试试把流程也交给它：从一个小需求开始，完整走一遍 brainstorming → 方案对比 → spec → 计划 → 实现。第一次会不习惯"一次只问一个问题"，但跑完一个需求你就会发现，多花在澄清上的半小时，会在联调阶段加倍省回来。

Cursor 与 Claude Code 对比：我的 AI 编程实战配置

Mon, 12 Jan 2026 10:30:00 +0800

两个工具，两种脾气

过去一年我同时深度使用 Cursor 和 Claude Code。一个是 IDE，一个是 CLI 加 Agent，定位并不重叠。在某科技公司的统一认证中心、知识库问答服务后端，以及 alchemy-furnace 全栈项目里，我慢慢形成了「日常写代码用 Cursor，复杂重构和跨服务任务用 Claude Code」的组合，而不是二选一。

各干各的活

Cursor 的 Tab 补全和 Cmd+K 内联编辑最跟手。写熟悉的业务代码、前端 JSX、SQL 时效率极高，适合「我知道要写什么，只是想快一点」。Claude Code 的 Plan 模式、子任务和工具调用（Bash/Read/Edit）适合另一类活：「我知道目标，但需要它自己摸代码、跑测试、改一轮」，比如跨多个微服务加一个字段、批量修复 lint、写数据迁移脚本。

两份规则文件

Cursor 的 .cursorrules：

1
2
3
4
5
6


- You are an expert Go backend engineer.
- Prefer table-driven tests.
- Never ignore returned errors; wrap with fmt.Errorf("...: %w", err).
- Use zap for structured logging, no fmt.Println in business code.
- For GORM, always pass ctx and specify table name explicitly.
- Frontend: Next.js App Router, shadcn/ui, Tailwind. Keep components server by default.

Claude Code 的 CLAUDE.md 在上一篇已经展示过，重点是项目结构、命令和领域术语。两份文件内容不同，思路一致：把团队约定固化下来，而不是每次靠 prompt 提醒。

两个工具我都要求同一件事：改完代码自己跑测试。Cursor 用 Composer 执行 go test ./...，Claude Code 直接调 Bash 工具，看到失败再回头改。

踩过的坑

第一，上下文管理思路不同。Cursor 靠 @file、@git、@docs 手动引用，精确，但前提是你得知道该引用什么；Claude Code 会自己 grep 和 read，容易把上下文撑爆，得靠 Plan 模式和子任务控制范围。

第二，补全质量。Cursor 在短片段补全上更跟手，尤其前端 props；Claude Code 不做实时补全，但整段生成和跨文件重构更强。

第三，价格与合规。Cursor 可以切不同模型，但企业代码要考虑合规；Claude Code 走我自己的 API Key 或订阅，代码不外传到第三方索引，对公司项目更安心。我们在统一认证中心项目里明确禁止把含密钥或客户数据的文件贴到任何 SaaS 工具。

第四，终端场景。Claude Code 在服务器、容器、tmux 里能直接跑，改 KubeSphere 部署脚本、调试线上 Pod 时比 SSH 加本地 IDE 方便；Cursor 需要本地有仓库或 Remote-SSH。

第五，别迷信任何一个工具。我见过同事一路 Tab 出几百行没跑过的代码，也见过让 Agent 自主改一下午、最后全是幻觉 API 的。生成越顺手，检查越不能省。

第六，两者都需要一份清晰的项目规则文件。没有 .cursorrules 或 CLAUDE.md，它们都会按「通用最佳实践」写，和你项目的真实风格完全不搭。

我的组合

Cursor 当主力编辑器，处理日常 CRUD 和前端；Claude Code 当 Agent，处理跨文件、跨服务、需要自己跑命令的任务。两个工具都配好项目规则，都要求改完自跑测试，都不让它碰密钥。这三个「都」，比选哪个工具更重要。

封面图：MattsMacintosh / Flickr · CC BY 2.0

极客工具推荐

Thu, 01 Jun 2023 08:00:00 +0800

我的极客工具箱

终端

Alacritty — GPU 加速的终端模拟器
tmux — 终端复用神器
zsh + oh-my-zsh — 最强 Shell

编辑器

Neovim — Vim 的现代版
VS Code — 全能编辑器

开发工具

工具	用途
Docker	容器化
Git	版本控制
jq	JSON 处理
fzf	模糊搜索
ripgrep	极速搜索

工欲善其事，必先利其器。