我花 3 天逆向 gstack to dbs，发现方法论比代码更值钱

80 行代码，为什么比 8000 行更强大？

当我打开 dbs 的核心文件时，只看到 80 行。

没有复杂的 bash 脚本，没有外部依赖，没有状态管理。只有一个清晰的路由表和几句简洁的指令。

但这 80 行背后，是作者对 gstack（23 个 skills、数千行代码、完整的工程化体系）的深度理解和大胆简化。

这不是"抄袭"，这是"方法论跨领域迁移"的教科书案例。## 省流版：5 步迁移框架

如果你想把一个领域的方法论迁移到另一个领域，这是完整路径：

Step 1: 识别源领域的"角色-流程"结构
       （gstack: CEO → 工程师 → QA → 发布）

Step 2: 映射到目标领域的"专家-诊断"体系
       （dbs: 诊断师 → 对标 → 内容 → 执行力）

Step 3: 发现目标领域的独特需求（源领域没有的）
       （dbs 的心理诊断层、微工具矩阵）

Step 4: 简化技术实现（只保留必要的）
       （dbs 去掉了 bash、状态管理、外部依赖）

Step 5: 设计边界和路由（防止跑偏）
       （dbs 的"这不是商业问题，是情绪问题"）

核心洞察：好的方法论是跨领域的。关键是理解本质，而非照搬形式。下面是完整的推演过程。

适用说明

这篇文章适合你，如果你：- 看到一个好工具，想提取背后的方法论

• 想把某个领域的方法论应用到自己的领域
• 想理解"复用"和"抄袭"的本质区别

这篇文章不适合你，如果你：- 只想要现成的工具，不关心背后的思考

• 认为方法论是不可迁移的

第一幕：作者@dontbesilent看到了什么？

想象你是 dbs 作者，某天你打开 gstack 的 README.md，看到这段话：

"gstack is how I do it. It turns Claude Code into a virtual engineering team — a CEO who rethinks the product, an eng manager who locks architecture, a designer who catches AI slop..."

翻译：
我正是通过 gstack 来实现这一点的。
它能将 Claude Code 转化为一支虚拟工程团队——
一位负责重新构思产品的 CEO，
一位负责敲定架构的工程经理，
以及一位负责捕捉 AI 粗制滥造之处的设计师……

这句话里藏着一个革命性的洞察：工作可以被"角色化"。传统思维：

• 我要写代码 → 我打开编辑器 → 我写
• 我要做设计 → 我打开 Figma → 我画

gstack 的思维：

• 我要写代码 → 我召唤"工程经理"角色 → 他帮我设计架构
• 我要做设计 → 我召唤"设计师"角色 → 他帮我审查质量

这不是工具，这是"召唤术"。

第二幕：第一个关键问题

看完 gstack 后，作者脑子里冒出的第一个问题不是"这个工具好用吗"，而是：

"为什么只有软件开发可以这样？"思考实验：软件开发 vs 商业诊断

软件开发的流程：1. 产品经理：这个功能要不要做？ 2. 架构师：怎么设计？ 3. 工程师：怎么实现？ 4. QA：有没有 bug？ 5. 运维：能不能上线？

商业诊断的流程：1. ？：这个生意要不要做？ 2. ？：商业模式对不对？ 3. ？：定价合不合理？ 4. ？：内容怎么做？ 5. ？：执行力够不够？

发现：结构是一样的。都是"多个专家，按顺序检查不同维度"。

第三幕：入口 skill 的选择

"如果我要做商业版的 gstack，第一个 skill 应该是什么？"gstack 的第一个 skill：

/office-hours - YC Office Hours
Start here. Six forcing questions that reframe your product before you write code.

翻译：
/office-hours —— YC 办公时间
从这里开始。在编写代码之前，先用这六个“强制性问题”重新审视并重构你的产品。

关键词：Start here（从这里开始）

这告诉我们：入口 skill 是整个系统的灵魂。

作者的选择：/dbs-diagnosis

为什么不是 /dbs-benchmark（对标分析）？

为什么不是 /dbs-content（内容诊断）？

因为 /dbs-diagnosis 对应的是 gstack 的 /office-hours：

第四幕：融合两种风格

gstack 的 /office-hours 是苏格拉底式提问：

You: I want to build a daily briefing app for my calendar.
Claude: [asks about the pain — specific examples, not hypotheticals]
You: Multiple Google calendars, events with stale info...
Claude: I'm going to push back on the framing. You said "daily briefing app."But what you actually described is a personal chief of staff AI.

翻译：
你：我想为我的日历开发一个每日简报应用。
克劳德：[询问痛点——具体例子，而不是假设]
你：多个谷歌日历，事件信息过时……
克劳德：我要指出你的措辞问题。你说的是“每日简报应用”，但你实际上描述的是一个私人幕僚人工智能。

但 dontbesilent 的方法论是直接下诊断：

"你这个不是产品，是你的大脑活动。"
"播客怎么赚钱是个错误的问题，因为播客不是产品，是产品形式。"

作者的困境：

如何把"苏格拉底式提问"和"直接下诊断"结合起来？作者的解决方案：消解漏斗

第一层：语言陷阱检测
→ "你说的'适合'是什么意思？"（苏格拉底式）
→ "这个词没有定义，问题不成立。"（直接判断）

第二层：假设错误检测
→ "你的问题假设了'创业需要钱'。"（指出假设）
→ "但这个假设本身可能是错的。"（直接判断）

这是融合：先问，再判断，再等用户回应。

第五幕：发现关键差异

gstack 的假设：

"用户知道自己要做什么（比如'我要做日历应用'），只是不知道怎么做。"

所以 gstack 的流程是线性的、确定性的：

1. 确认方向（/office-hours）
2. 设计架构（/plan-eng-review）
3. 实现（写代码）
4. 验证（/qa）
5. 发布（/ship）

dbs 的发现：

"用户不知道自己要做什么，甚至不知道自己的问题是什么。"

所以 dbs 的流程是树状的、探索性的：

1. 消解问题（/dbs-diagnosis）
2. 如果问题成立 → 路由到专业诊断
3. 如果问题不成立 → 告诉用户为什么

这导致了什么？

• gstack 需要"深度流程"（一个功能从头到尾）
• dbs 需要"广度工具"（不同类型的问题需要不同的诊断）

所以：

• gstack 有 /qa（深度测试一个功能）
• dbs 有 /dbs-content、/dbs-hook、/dbs-xhs-title（针对不同内容类型的诊断）

第六幕：技术实现的大胆简化

gstack 的技术栈（重量级）：

150+ 行的 preamble

_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || ...)
mkdir -p ~/.gstack/sessions
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l)
_PROACTIVE=$(~/.claude/skills/gstack/bin/gstack-config get proactive 2>/dev/null)
...

这是一个完整的工程化系统：

• 自动更新检查
• 会话管理
• 配置系统
• 学习记忆
• 遥测数据

dbs 的技术栈（极简主义）：

---
name: dbs
description: dontbesilent 商业工具箱主入口
---

你是 dontbesilent 商业工具箱的入口。
你的唯一任务是：搞清楚用户需要什么，然后把他路由到正确的 skill。

**你不做诊断，不做分析，不给建议。你只做路由。**```

80 行。没有 bash。没有依赖。没有状态。

作者的洞察：

<strong>商业诊断不需要操作代码/浏览器/Git，可以把技术栈简化到极致。</strong>这不是"偷懒"，这是"理解本质"。

## 第七幕：创新 — 多专家并行讨论

gstack 的 /design-shotgun：

1. 生成 4-6 个 AI 设计方案
2. 在浏览器里并排展示
3. 用户选择喜欢的
4. 迭代

这需要浏览器、图片生成、前端展示。

但 dbs 是纯对话式的，怎么做"多方案对比"？

作者的解决方案：/dbs-chatroom

1. 用 Agent tool 并行调用多个专家（芒格、卡尼曼、达里奥）
2. 每个专家独立思考
3. 把所有回复并排展示（用 markdown）
4. Claude 作为判官总结

这是用"多 Agent 并行"替代"多设计方案并行"。

更深的洞察：

- gstack 的 /design-shotgun 是"生成多个方案，让用户选"（选择题）
- dbs 的 /dbs-chatroom 是"生成多个观点，让用户综合"（思考题）

为什么？

因为：

- 设计方案可以"选一个最好的"
- 商业观点不能"选一个最对的"，需要"综合多个视角"

## 第八幕：自我迭代能力

更有意思的是，dbs 后来不只是拿来诊断商业问题。

作者还把这套方法用回了自己的 Agent 工作台。

这就像一个编辑部先发明了一套"选题方法"，后来发现自己的选题库越来越乱，于是又用这套方法反过来整理选题库：

- 先盘点现有选题
- 再确认哪个版本是主稿
- 再把不同平台的版本同步起来
- 最后检查有没有遗漏和冲突

这就是 /dbs-agent-migration 的意义。

它表面上是在整理 skill、规则文件和 Agent 目录。

但更深一层看，它说明作者已经不是在"照着 gstack 做 dbs"。

他已经把 gstack 的方法论内化成了自己的默认工作方式：

遇到混乱，不是马上写脚本搬文件，而是先审计、确认真源、建立同步关系、再验证。

这就是"自我迭代能力"。

一个工具系统真正成熟的标志，不是它能解决外部问题，而是它能反过来帮助作者维护、整理、升级自己。

## 核心洞察：三个层次的复用

层次 1：表面复用（结构）

gstack 的结构：

- 入口 skill（/office-hours）
- 核心流程（plan → build → review → ship）
- 专业流程（design）
- 工具类（browse, careful, freeze）

↓ 复用到 ↓

dbs 的结构：

- 入口 skill（/dbs）
- 核心流程（/dbs-diagnosis）
- 专业诊断（benchmark, content, hook, ...）
- 工具类（ai-check, agent-migration）

<strong>这是最容易看到的，但也是最浅的。</strong>层次 2：方法论复用（原则）

gstack 的原则：

1. Boil the Lake（做完整的事）
2. Search Before Building（三层知识）
3. User Sovereignty（人决策）
4. 分阶段确认（不要一次性跑完）

↓ 复用到 ↓

dbs 的原则：

1. 消解优先于解答（99.1% 被消解）
2. 公理驱动（六大公理）
3. 用户判断（每一步都对话）
4. 分层检验（七项检验，每项都停下来）

<strong>这是更深的，需要理解"为什么这样做"。</strong>层次 3：思维模式复用（范式）

gstack 的范式：  
**"工作 = 召唤不同角色的专家"**↓ 复用到 ↓

dbs 的范式：  
**"诊断 = 召唤不同领域的专家"**↓ 再复用到 ↓

任意领域的范式：  
**"X = 召唤不同角色的专家"这是最深的，是"元方法论"。**## 为什么 dbs 作者能成功复用？

不是每个人看到 gstack 都能做出 dbs。为什么 dbs 作者能？

原因 1：他有"领域知识"

dbs 作者深度理解 dontbesilent 的方法论，他就是他说的本身：

- 六大公理
- 消解漏斗
- 七项检验
- 说话风格

<strong>没有这个，就只能复制结构，做不出灵魂。</strong>原因 2：他有"抽象能力"

他能看到：

- /office-hours 的本质不是"产品诊断"，而是"挑战假设"
- /design-shotgun 的本质不是"生成设计"，而是"并行方案对比"
- /investigate 的本质不是"技术调试"，而是"系统性根因分析"

<strong>没有这个，就只能照搬，做不出创新。</strong>原因 3：他有"实践需求"

他自己就是 dontbesilent 方法论的使用者，他知道：

- 哪些问题最常见（所以做了 /dbs-diagnosis）
- 哪些环节最痛（所以做了 /dbs-xhs-title、/dbs-hook）
- 哪些工具缺失（所以做了 /dbs-agent-migration）

**没有这个，就只能纸上谈兵，做不出实用工具。**## 你的复用路径：可操作的检查清单

现在轮到你了。你想复用这套方法到什么领域？

第一步：你有"领域知识"吗？

- 你深度理解这个领域的方法论吗？
- 你能列出这个领域的"公理"吗？
- 你知道这个领域的"说话风格"吗？

第二步：你有"抽象能力"吗？

- 你能看到 gstack/dbs 的"本质"而不是"表面"吗？
- 你能把"软件开发的原则"翻译成"你的领域的原则"吗？
- 你能识别"哪些可以复用，哪些需要创新"吗？

第三步：你有"实践需求"吗？

- 你自己就是这个领域的从业者吗？
- 你知道这个领域最痛的点是什么吗？
- 你能列出"如果有这个工具，我会怎么用"的场景吗？

## 通用的"领域迁移框架"（再次强调）

```markdown
Step 1: 识别源领域的"角色-流程"结构
       （gstack: CEO → 工程师 → QA → 发布）

Step 2: 映射到目标领域的"专家-诊断"体系
       （dbs: 诊断师 → 对标 → 内容 → 执行力）

Step 3: 发现目标领域的独特需求（源领域没有的）
       （dbs 的心理诊断层、微工具矩阵）

Step 4: 简化技术实现（只保留必要的）
       （dbs 去掉了 bash、状态管理、外部依赖）

Step 5: 设计边界和路由（防止跑偏）
       （dbs 的"这不是商业问题，是情绪问题"）

结语：方法论的力量

从 gstack 到 dbs，我们看到的不是"抄袭"，而是"方法论的跨领域迁移"。

这个过程揭示了三个深刻的真理：

1. 好的方法论是跨领域的- "召唤不同角色的专家"适用于软件开发、商业诊断、个人成长、团队管理...

2. 复用不是照搬，是理解本质后的重新创造- dbs 作者没有复制 gstack 的 150 行 bash，而是用 80 行纯对话实现了同样的范式

3. 最好的工具来自于"自己吃自己的粮食"- /dbs-agent-migration 是作者用 gstack 方法论解决自己问题的产物

现在，问问你自己：

你手里有什么"gstack"？你想解决什么领域的问题？你能不能提取出"本质"，然后在新领域重新创造？如果答案是"能"，那么你已经掌握了这个时代最重要的能力之一：

方法论的跨领域迁移。## 附录：领域差异对照表

参考资料：

栋哥主页：x.com/dontbesilent
dbs github 官网：github.com/dontbesilent2025/dbskill
Garry Tan 主页：x.com/garrytan
GStack github 主页：github.com/garrytan/gstack

方法论的力量，在于它可以被复用。