Claude Code on 姚玉亮的网络日志

高低模型分工：用最少的 token 做最难的任务

Sun, 30 Aug 2026 18:00:00 +0800

我最初的做法：高模型出计划，低模型执行

在炼丹炉（Alchemy Furnace，我的开源项目）上开发大功能时，我的模型分工一开始是这样的：高模型出计划，低模型去试执行。逻辑听起来无懈可击：计划是最费脑子的活，给最强模型；执行是照着做，给便宜模型省 token。

跑了几轮之后我意识到，这不是最佳实践：省下的 token 在别的地方加倍还了回去。坑在哪、后来怎么分，一条条说。

三个坑：为什么"计划高、执行低"不够

坑一：计划里的任务难度不均。

一个实施计划拆出来的任务，难度天差地别。同一个计划里，既有"写一个纯函数渲染器"这种机械活，也有"设计 SSRF 校验 + 提供者熔断 + 证据等级判定"这种高难活。一刀切全丢给低模型，难任务在低模型手里反复试错，每次失败都是一轮"试错 + 看错误 + 再试"，token 没省多少，时间翻倍，最后往往还是得升级。

坑二：低模型失败没有出口。

低模型试了，失败了，然后呢？如果升级路径不存在，低模型只有两个选项：硬编一个成功（最危险，测试都可能一起编出来），或者卡死空转。我早期踩过前者，代价是返工整个文件。

坑三：验证被一起降级了。

执行降级了，自测也跟着降级：低模型自己测自己，绿灯也不能全信。判断性工作（“这样测算不算数”）和机械性工作（“跑一遍测试”）不是一回事，不能一起降级。

模型分级的问题不在"分级"本身，而在分级的依据：按角色分（计划/执行）是错的，按难度分（任务）才对。

正确框架：按难度分级 + 三个旋钮

Claude Code 的 Workflow 里每个子 Agent 可以独立指定模型档位和努力度，这就是三个旋钮：

旋钮一：模型档位。高（Opus）/ 中（Sonnet）/ 低（Haiku）。

旋钮二：努力度（effort）。从 low 到 max。很多任务根本不用换模型：同一个模型把 reasoning 预算拧低，就是廉价版本。换模型是换"能力上限"，调 effort 是调"用力程度"，两回事。

旋钮三：任务边界清晰度。这是最便宜的杠杆：spec 拆得越细、验收标准写得越死，任务越接近"机械执行"，能用的模型档位就越低。

我的任务分配表：

难度	模型	例子
判断型	高模型 + 高 effort	需求探索与脑暴、接口契约设计、代码评审、根因定位、安全核对
常规型	中模型 + 中 effort	常规功能实现、测试编写、中等重构、普通调试
机械型	低模型 + low effort	模板化改动、纯函数实现、i18n 文案、跑测试与验证

用最少的 token 做最难的任务

说白了就一条：把大部分任务变简单，让高模型 token 只花在"决定"上，不花在"执行"上。

几个真实管用的杠杆：

计划是高模型性价比最高的投资。计划阶段多花的高模型 token，换来的是执行阶段任务边界清晰、可降级给便宜模型。这是"1 单位的贵，换 100 单位的省"。不是精确数字，是量级感受。
低模型任务必须满足三个条件，缺一不可：

边界明确：任务描述到文件级，依赖关系写清
测试兜底：TDD 红→绿，失败能被测试抓住
终止条件：做不了就停，明确写"连续失败就停止报告，不许编成功"

第三条最重要。我在炼丹炉的 Workflow 脚本里给每个子 Agent 都注入了终止条件段（A3：文件不存在、依赖无法确认、连续 3 次修复失败，立即停止报告）。允许低模型说"我卡住了"，比让它硬编一个成功安全一个量级。

升级路径要显式。低模型失败不是终点：带着"红测试 + 尝试过程 + 卡点描述"升级给高模型。高模型拿到的是完整上下文，一次到位给解法或改计划，而不是重新摸底。
评审和验证分开降级。跑回归（机械）可以低模型；安全核对、代码评审（判断）留给高模型。炼丹炉的验收任务里，回归和"ZIP 解压检查有没有泄露 key"是两件事：前者低模型跑，后者高模型过。

炼丹炉实例：一个计划怎么分

以女娲蒸馏 + Skill 导出的开发为例（6 个任务、4 个波次）：

计划本身（文件级任务清单）：高模型出。这是唯一一个"必须先花"的成本。
Task3 Skill 渲染器：纯函数、格式明确（slug 规则、SKILL.md 结构、ZIP 命名全写死）、测试完备，典型的机械型任务，低模型 + low effort 就能扛。
Task2 Python 蒸馏链路：SSRF 校验、来源熔断、证据等级判定，属于判断与工程混合，配中模型 + 中高 effort，比低模型反复试错便宜得多。
Task6 端到端验收：回归跑测低模型，产物安全核对（解压查 sk-、token、内部日志）高模型。
A3 终止条件：给每个"低模型试"的任务一个明确出口，试不动就停，升级。

收尾

用下来我的感觉是：判断性的活给最贵的模型，机械的活给最便宜的；任务写得清就可以降档，失败超过两次就升级，别耗着。

模型分级省的不是高模型的钱，是浪费在错模型上的钱。最难的活依然要最贵的模型，但反过来也成立：大部分活之所以难，是因为你没把它写清楚。把任务写清楚，是高模型 token 花得最值的地方。

封面图：Krzysztof Golik / Wikimedia Commons · CC BY-SA 4.0

复杂任务的快速实现：我的 Claude Code 工作流

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

复杂任务为什么难

先说结论：复杂任务难的不是写代码，是下面四件事。

需求模糊：说需求的人自己都没想清楚。“文档核验要留痕”，留什么痕？按什么查？入口放哪？全要靠推。
代码陌生：改的不是自己写的代码库，路由注册在哪、DAO 怎么组织、有没有现成的组件，一无所知。
链路长：一个需求横跨后端服务、管理后台、上层服务三个仓库，联调对不上是常态。
步骤多：建表、写记录、加接口、做页面、上层同步，十几步里漏掉任何一步，都要返工。

过去我处理复杂任务靠"经验 + 加班"：经验让我少踩坑，加班补上流程损耗。现在我用 Claude Code 的 workflow 跑，发现上面四类复杂度可以分别拆掉。

一、需求模糊？先探索，再一次一个问题

需求模糊是复杂任务的第一个坑，也是最贵的坑：设计错了，后面全白做。

我的做法是两段式：先让 AI 探索代码，再让它一次只问一个问题。

拿最近一个"核验记录"需求举例。AI 先翻了两个仓库，带回几个关键事实：文档表上已经有"核验状态"字段，核验逻辑集中在文档服务的一个方法里，前端代码里已经有现成的下拉加载 hook。这些事实直接改变了设计：记录表和状态字段是两回事，但很多人第一版会把它们混在一起。

然后进入提问环节，一次一个问题：

我：核验记录存哪些字段？ AI：除了核验人和核验时间，要不要存版本号？这决定表结构。我：先只存核验人和核验时间。 AI：好。那列表按数据集 ID 过滤、分页返回，对吗？

每个答案都在修正下一个问题。一次抛十个问题，AI 只能靠猜排优先级，猜错一半就得返工。模糊需求最怕的不是问得少，而是问得乱。

二、代码陌生？子代理并行探索

复杂任务往往意味着大型代码库。让主会话把每个文件都读一遍，上下文直接爆炸；不让它读，问的问题全是空对空。

我用子代理解决：只读的探索型子代理，各自负责一个方向，跑完只把结论带回来。

还是那个需求。两个仓库，我开了两个子代理并行：

一个查后端：核验逻辑在哪个方法里？用什么 ORM？表结构长什么样？
一个查前端：数据管理页面结构？有没有现成的分页/下拉加载组件？

主会话的上下文只收到两条结论，干净利落。复杂任务拆给子代理，等于给主会话外挂了好几个只读大脑。

三、步骤多？用 spec 锚定，用计划兜底

十几步的任务，光靠"记住"一定会漏。我的流程里有两个强制环节：

第一步，设计获批后写 spec 文档。表结构、接口定义、前端改动点、上层同步点全部落盘。这份文档是后续所有工作的锚点：代码评审不再对着记忆逐条想，而是对着 spec 逐条核对。

第二步，用计划技能把设计翻译成有序任务。先改什么、后改什么、每个任务做完怎么验证，都拆成文件级清单。执行阶段照着走，不会顾此失彼。

复杂任务最怕的不是步子慢，而是做完了发现做的是另一个需求。spec 就是防这件事的。

四、链路长？add-dir 多项目，一个会话挂三个仓库

跨仓库任务的真正成本不在写代码，在于两边对不上：前端叫 page 后端叫 current，接口路径差一个斜杠，联调半天。

Claude Code 的 add-dir 可以把多个项目目录加进同一个会话，三个仓库的上下文同时可见。字段名、接口路径、分页参数在计划阶段就定死，代码照着写就行，联调成本趋近于零。

以前这种需求：拉群 → 各自开工 → 联调发现对不上 → 返工。现在：一个会话、一份 spec、三份代码同时改。

五、改错返工？hooks 门禁 + 验证闭环

复杂任务最容易在最后一步翻车：改完了、自测过了，忘了检查脱敏、忘了跑构建、忘了验证线上。

我的解法是 hooks：把检查前置到事件本身。比如写文件前必须声明事实（这个文件被谁引用、里面有没有敏感内容），执行破坏性命令前必须给出回滚方案。检查不是"记得就做"，而是流程的必经环节，不做就卡住。

收尾阶段再加一道验证：构建无错误、线上返回 200、关键内容比对通过，才算完成。质量不是最后检查出来的，是流程逼出来的。

我的工作流时间线

一个复杂任务在我这里是这样的节奏（示意）：

flowchart LR
 T1["探索 + 脑暴"] --> T2["方案 + spec"] --> T3["实施计划"] --> T4["执行三仓"] --> T5["评审 · 验证 · 部署"]

环节	干什么	用时
探索 + 脑暴	读代码、一次一个问题澄清需求	一个上午
方案 + spec	2-3 个方案对比，获批后落盘设计文档	半小时
实施计划	设计翻译成文件级任务清单	十分钟
执行	按清单改三个仓库	主工作量
评审 + 验证 + 部署	对着 spec 评审，构建、线上验证	收尾

对比以前的节奏：需求评审会一轮、文档两轮、联调两轮、返工一轮，光流程损耗就吃掉一半时间。

收尾

复杂任务的复杂度分布大概是这样：需求 > 链路 > 步骤 > 代码。Claude Code 的 workflow 没有任何魔法，它只是把"该问的、该查的、该记的、该验的"变成了流程的默认动作，让 AI 和人的精力都集中在真正难的地方。

真正快的不是写代码那一下，而是不返工。

封面图：jurvetson / Flickr · CC BY 2.0

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

AI Vibe Coding 工作流：用 Claude Code 全栈交付

Sun, 28 Dec 2025 10:30:00 +0800

一个人，三套技术栈

2026 年初我开源了 alchemy-furnace（炼丹炉），一个多人格融合 Agent 系统：Go(Gin+GORM) 做网关，Python(FastAPI) 做合成引擎，Next.js 做前端，三套技术栈一个人全栈交付。按传统写法，光是在语言和框架之间切上下文，就要吃掉大量业余时间。我拿 Claude Code 当主力开发助手，慢慢攒出了一套自己的 Vibe Coding 工作流。

先给 Agent 立规矩

第一步，先写 CLAUDE.md，把项目结构、技术栈、启动命令、代码规范和关键领域概念（金丹、丹炉、血统追溯）写清楚，作为 Agent 的长期记忆。

第二步，复杂功能（Promptbreeder 变异算子、合成提示词缓存、多供应商适配）先用 Plan 模式让它出实施计划，我审完再让它动手写代码。

第三步，小步提交，每个子任务一个 commit，方便 review，也方便回滚。

第四步，测试先行。让 Claude 按函数签名写 table-driven tests，我负责补边界 case。

第五步，用 Task 跟踪多步任务，让它自己跑 go build、go test，失败了读报错自己修。

两份配置

项目根的 CLAUDE.md 片段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# alchemy-furnace

## 架构
- gateway/ : Go 1.22, Gin + GORM, 负责 API Key 鉴权、路由、计费
- engine/ : Python 3.11, FastAPI, 多人格融合 + Promptbreeder 变异
- web/ : Next.js 14 App Router, Tailwind, shadcn/ui
- deploy/ : docker-compose, 单机部署

## 约定
- Go 代码通过 `make lint` 检查，禁止裸 ignore error
- Python 用 ruff + mypy，接口模型必须用 Pydantic
- 所有外部供应商调用走统一 provider 抽象
- API Key 入库前必须 AES-GCM 加密
- DEMO_MODE 下不调真实 LLM，返回内存 mock

settings.json 里放行高频命令，减少权限弹窗：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "permissions": {
 "allow": [
 "Bash(go build ./...)",
 "Bash(go test ./...)",
 "Bash(go vet ./...)",
 "Bash(ruff check *)",
 "Bash(pytest -q)",
 "Bash(docker compose config)"
 ]
 }
}

坑是真坑

第一，上下文是稀缺资源。我不会把整个仓库丢给 Claude，而是用子任务切给它：“只看 gateway/internal/provider 目录，给 OpenAI 兼容层加一个 DeepSeek 适配”。大范围重构先让它列影响文件清单，再逐个改。

第二，Vibe Coding 不等于不看代码。写完让它自己跑测试，但 API Key 加密、变异算子的血统追溯这类关键路径，我逐行 review。能跑通不代表逻辑对，尤其涉及金额、权限、加密的时候。

第三，幻觉 API 是真问题，它会编出不存在的 eino 函数签名。我的要求是先 go doc 或直接读 vendor 源码确认，不许凭印象写。

第四，多语言项目在同一会话里容易串味。我一般按服务分会话，或者明确说"接下来只写 Python，别把 Go 的错误处理风格带进来"。

第五，尽量用增量 Edit 而不是整体 Write。diff 清晰，跑偏了当场就能发现。

后来

Claude Code 让我这种以后端为主的人，敢一个人扛前端和算法服务。它最擅长样板代码、测试用例、跨文件重构和根据报错自修复；我负责架构、边界和验收。alchemy-furnace 能在业余时间快速做到 46 star，靠的就是这套工作流。

封面图：recursion_see_recursion / Flickr · CC BY 2.0