从 GStack 到 DBS：复用的入口

来源：X @iamzhihui

GStack 是 YC 总裁 Garry Tan 开源的个人 Claude Code 技能包，仓库自述包含 23 个有主见的工具，分别承担 CEO、设计师、工程经理、发布经理、文档工程师和 QA 的角色 ^[4,14]；发布数周后获得 6.6 万 star ^[14,29]，媒体普遍将其解读为把 Claude Code 变成“虚拟工程团队” ^[26,29]。dbskill（DBS）是博主 dontbesilent 开源的中文商业诊断技能集，从 16,152 条公开推文中提炼出 4,176 个知识原子，整理为 29 个 Skills，支持豆包、WorkBuddy、Claude Code、Codex 等宿主 ^[1,2]。素材将两者描述为“80 行代码 vs 数千行代码”的极简主义对比 ^[0]，但可核验的事实显示，两个系统的关键差异不在代码规模，而在入口对用户的不同假设：一个是假定用户已带着想法前来，另一个则假定用户尚未明确自己的问题。

同一范式，两种问题空间

GStack 的 23 个 skill 按产品生命周期排列：/office-hours 负责确认方向，plan-* 系列执行 CEO、工程与设计评审，design-shotgun 产出设计方案，/review、/qa、/ship 处理验证和发布 ^[13,29]；此外还有 /pair-agent 用于多智能体协作，/retro 做每周复盘，/learn 管理跨会话记忆 ^[42]。这一流程覆盖“把一个功能从想法做到上线”的完整闭环 ^[29,42]。

DBS 的 29 个 skill 按问题类型分类：/dbs-diagnosis 用于商业诊断，/dbs-benchmark 用于对标分析，/dbs-content、/dbs-hook、/dbs-xhs-title 用于内容创作，/dbs-resonate、/dbs-script-flow、/dbs-spread 用于文稿检查，/dbs-deconstruct、/dbs-goal、/dbs-good-question 用于澄清概念与目标，/dbs-action、/dbs-slowisfast 用于处理拖延 ^[34,35]。其能力清单中没有 ship、deploy 这类交付环节 ^[34]，因为诊断类任务无需上线 ^[0]。

两者共享相同的范式：将工作分解为“召唤不同角色的专家” ^[0]。GStack 的 README 将整个系统定义为虚拟工程团队，CEO、设计师、工程经理、QA 各司其职 ^[4,7,29]；DBS 的每个 skill 也对应一位专家，例如用维特根斯坦语言哲学审计目标的 /dbs-goal，用阿德勒心理学诊断拖延的 /dbs-action ^[35]。

入口：两种对用户的假设

GStack 的入口 /office-hours 在仓库中名为“YC Office Hours（两个模式）”，触发词包括 brainstorm this、is this worth building、help me think through ^[25]。YC 官方演示将其描述为“仿照真实 YC 合伙人会议、在你写代码之前压力测试你的想法” ^[26]。它的工作方式是 push back：有使用者输入 /office-hours 后，AI 会指出“你描述的其实不是日历应用，而是个人 AI 幕僚长”，给出三条实现路径，并推荐最窄的一条 ^[28]。

DBS 的入口 /dbs 不同。其公开描述只有一句：“你是 dontbesilent 商业工具箱的入口。你的唯一任务是：搞清楚用户需要什么，然后把他路由到正确的 skill。” ^[38] 作者在推文中说明，/dbs 会自动路由到 diagnosis 等 skill，用户无需关心自己正在使用哪个 ^[37]。

素材将差异解释为：GStack 假设“用户知道自己要做什么，只是不知道怎么做”，因此采用线性流程；DBS 假设“用户不知道自己的问题是什么”，因此先处理问题再决定是否路由 ^[0]。这一解释在 skill 设计中得到印证：DBS 专设了“澄清”类工具，例如 /dbs-goal 将模糊目标审计为可检查的交付物，/dbs-deconstruct 澄清概念，/dbs-good-question 提出好问题 ^[34,35]。而 GStack 用户带来的是一份“值不值得做”的想法（is this worth building ^[25]），需要推敲的是方向，而非问题本身。

流程形态：线性交接链与树状路由

GStack 可验证的核心是“结构化交接”：/office-hours 产出的设计文档由 /plan-eng-review 读取，后者写下的测试计划再由 /qa 接手 ^[29]。完整链路为 /office-hours 写设计文档 → /autoplan 串联 CEO、设计、工程评审 → /review 修复 lint、标记竞态条件 → /qa 打开真实浏览器进行 UI 测试并提交回归测试 → /ship 同步 main、运行测试、开启 PR ^[29]。每个 skill 的输出作为下一个 skill 的输入，流程固定 ^[0]。

DBS 没有这样的链路。它的主入口只负责判断“该路由到哪里”：问题成立则转专业诊断，不成立则告诉用户原因 ^[0,38]。因此 GStack 需要深度（一个功能从想法到上线的完整工序），DBS 需要广度（为每种问题类型准备一个诊断器）^[0]，这也是 DBS 同时存在 /dbs-content、/dbs-hook、/dbs-xhs-title 三个不同切面的内容类 skill 的原因 ^[34,35]。

工程重量：跟随业务需求伸缩

GStack 的工程实现较重。每个 skill 的 SKILL.md 中嵌有大量 bash 前置脚本：/office-hours、plan-ceo-review 等会读取 gstack-config 配置、写入 gstack-telemetry-log 遥测、运行 gstack-update-check 更新检查、维护 learnings.jsonl 跨会话记忆 ^[6,10,11,25]。底层基于完整的浏览器服务架构：CLI 客户端（Bun 编译的二进制）通过 HTTP 与常驻 server 通信，server 用 CDP 驱动 Playwright Chromium，将控制台日志与网络请求写入环形缓冲区并异步落盘，内置 30 分钟空闲回收 ^[40,43]。该设计源于实际约束：浏览器冷启动需等待 3-5 秒，进程终止会导致 Cookie 和登录态丢失 ^[40,43]。

素材称 DBS 将这一切压缩到“80 行、没有 bash、没有依赖、没有状态” ^[0]，但该观点在公开仓库中找不到依据：dbskill 仓库实际包含 scripts、tools、docs、site、知识库等目录和 92 次提交 ^[2]，README 记录了 v2.18.16 将 30 个 skill 的描述从 10,635 字符压缩至 1,907 字符的操作 ^[2]。素材提到的“80 行核心文件”“99.1% 被消解”“六大公理”“七项检验”等说法，在 DBS 公开仓库与 dontbesilent 公开内容中均无出处 ^[1,2]。可验证的极简之处仅在于 /dbs 入口本身，即一段纯对话式的路由指令 ^[38]，这恰好印证了素材判断：商业诊断不操作代码、浏览器和 Git，技术栈可以只剩对话 ^[0]。技术复杂度随业务需求复杂度变化 ^[0]。

光环之外

GStack 伴随热度也存在争议。InfoQ 报道称，Garry Tan 声称过去 60 天在经营 YC 的同时上线了 3 个生产级服务和 40 多个功能模块，按“逻辑代码变更量”计算，效率是 2013 年的 810 倍 ^[9]；但“每天 1-2 万行代码”的说法被普遍视为“行数作秀”，批评还包括 AI 审查自己刚写的代码、与个人工作流过度耦合、供应链安全风险，以及“本质上只是一系列组织良好的文本文件”——报道结论是，对有严肃需求的团队，最好按自身需求构建定制版本 ^[9]。另需澄清，GStack 是 Garry Tan 的个人开源项目，并非 YC 或 Anthropic 的官方产品 ^[31]。

将两套系统放在一起观察，真正被迁移的并不是代码行，而是“先弄清问题是什么、再召唤对的专家”这一顺序 ^[0,29,38]：GStack 通过 /office-hours 在写代码前推敲想法 ^[26]，DBS 通过 /dbs 在诊断前明确诉求 ^[38]。素材强调的“复用本质是理解底层逻辑而非复制代码” ^[0]，在可核验层面即指此点。

原文更正：素材宣称 DBS 核心文件仅 80 行，且存在“99.1% 被消解”“六大公理”“七项检验”等说法，但在 DBS 公开仓库与 dontbesilent 公开内容中均查无出处。^[2]