至于冲突，superpowers 里的 Skills 设计上是互补的，但如果你同时安装了来自不同来源的多个 Skills，偶尔会出现"两个 Skills 都想处理同一类任务"的情况。坦白讲，没有这个 Skill 之前，我让 Claude 写代码，它会先写实现，然后我问"帮我补测试"，它补的测试几乎都是在测它自己的实现，而不是在验证业务行为。我打了个勾，推上去了。触发后 Claude 会输出一个结构

上下文膨胀的成本是随轮次线性增长的，即使用 Haiku，一个 20 轮的对话的 input cost 仍然是 1 轮的 20 倍。一个典型的 10 轮对话，不加处理的 context 可能是 50,000 tokens，用分层裁剪压缩后通常可以控制在 15,000-20,000 tokens 以内，同时保留所有关键信息。一个需要 10 步推理的代码调试 agent，和一个需要 3 轮的客服 age

场景：重构一个有 15 个文件的 Spring Boot 服务，Claude Code 自动启动了 4 个子 Agent（2 个 Explore，1 个 General-purpose，1 个 Plan），主 Agent 负责协调和最终修改。配置完之后，我跑同样的多 Agent 任务，账单从。指向 DeepSeek，但没有明确指定子 Agent 用哪个模型，Claude Code 在内部路由时可能

你在请求里告诉模型「有这几个函数，参数格式如下」，模型决定要不要调用，返回一个结构化调用指令，你的代码去执行，再把结果塞回 Prompt。你的服务独立部署成一个 MCP Server，任何支持 MCP 协议的客户端——Claude Desktop、Cursor、自己写的 Agent——都能发现和调用你的工具，不依赖具体模型，一次开发到处复用。说到底，MCP 解决的核心问题是「工具定义和模型解耦」—

差距主要出现在需要深度理解业务背景做权衡决策的场景，Claude Sonnet 4.6 在这里会更主动地给出有见解的建议，V4-Pro 有时更"执行型"。我把 Claude Code 的后端切换到 DeepSeek V4 跑了一遍，用了同样量级的 tokens，账单是 $2.3。如果工作流里有大量截图、视觉内容，或者对最新模型能力有依赖，继续付 Claude 官方的价格是合理的。不是"碾压"，是"

它的价值不依赖团队规模，依赖的是"高风险特性 + 独立视角验证"这个组合——哪怕你是一个人开发，dispatch 一个不带设计文档的 reviewer agent 都比你自己再看一遍有效。文档里说"这里保证了幂等性"，reviewer 就会在看到对应代码时默认"嗯，这里处理过了"——然后真正的漏洞就在这个默认里溜走了。排查了四个小时，找到了原因：在某个特定的并发窗口下，幂等键虽然写进去了，但写入和

这两个心态完全不一样——Phase 6 发生在你最自信的时候，而"最危险的时刻就是你感觉最自信的时候"。我把这个 skill 的完整源码、这次踩坑的所有设计文档和修复 plan 都整理好了，下一篇打算写「冷上下文 reviewer 找出的 10 个 Critical Bug 的详细复盘，每个 bug 附上原始 prompt 和修复 commit」，关注一下，发了第一时间推送。熟悉设计的 revie

这和 Kubernetes Reconcile Loop 的设计逻辑是一样的——你告诉 K8s「我要 3 个 Pod」，K8s 自己想办法凑够 3 个，而不是你指定「先启动第一个，再启动第二个，再启动第三个」。你可以同时 dispatch 多个独立任务，自己去做真正需要动脑子的工作，偶尔扫一眼 agent view，哪个会话需要你输入了就 peek 一下回复，哪个完成了就看看 PR 链接。用 wo

它解决一个很具体的问题：Claude Code 每个会话是独立的，你在昨天的会话里和 Claude 讨论了某个模块的设计决策、踩了一个坑、确认了一个命名规范——今天新开一个会话，这些全没了。坦白说，我踩过这个坑。这个官方工具在这里是有意义的：它帮你构建自己的 skill，并且能做 A/B 测试，测量你的 skill description 激活率（经过优化后，激活率可以从 20% 提升到 90%）

这些经历让我比较清楚一件事：工具和框架会变，模型会迭代，但「把复杂任务拆清楚、把上下文给准确、把风险拦住、把经验沉淀下来」这套思维方式不会过时。会用工具的人很多，会把工具改造成自己工作流的人很少。我在 InfoQ 和公众号写文章的这几年，以及在腾讯云架构师同盟社区里接触的工程师，用 AI 工具用得比较系统的那批人，现在交付速度和质量都跟两年前不一样了。重构遗留代码、补单测、系统化 Debug、Co