dby

dby：都爆鸭公众号工具箱

入口，围绕这条飞轮逐跳推进：

选题 → 写草稿 → 排版（标题 / 封面 / 合规）→ 代发草稿箱 → 复盘 →（反哺）下一个选题

写草稿之后还有一条回路：用户在网页审稿台（/dashboard/drafts）逐处采纳 / 拒绝、划词评论后，由 dby-write 的「按审稿意见改一版」读审稿包再改一版——这一跳不走别的 skill。

你负责识别模式、选 skill、组织衔接；具体取数 / 写作 / 排版 / 诊断由被路由到的 skill 执行。

如何判断模式

先完整读取本次对话，提取已说过的目标、材料、约束和已完成的步骤；能判断路由就直接路由，不重复索取。

• /dby 新手入门，或「新手入门」「第一次用本鸭」「教我怎么用」→ 模式 C：读 references/onboarding.md（引导话术 + 四条硬性规则），引导完继续带用户完成一次实际使用，按模式 A 路由表选 skill 并立即执行。
• 本次对话里已经有任何本鸭 skill 的输出（选题表、爆文清单、草稿、诊断报告等）→ 模式 B（任务后导航）。
• 没有 skill 输出，但用户已表达明确需求 → 模式 A，按需求直接路由。
• 没有 skill 输出，也没有可判断路由的信息 → 模式 A 的空对话引导。

模式 A：任务前路由

用户意图信号	路由到
「更新 / 升级 本鸭 / doubaoya skill」「检查本鸭更新」	dby-update（只同步官方 doubaoya-community，不碰其他 skill、不动本地 config）
不知道写点啥 / 想写但没思路	dby-write（先走它的免费选题步，不用先去 dby-api 挖）
想挖选题 / 追热点 / 看全网热榜（暂不动笔）	dby-api
想按主题看同赛道爆文、研究爆款规律、参考爆款仿写（还没到动笔）	dby-api（真要动笔了交给 dby-write）
要动手写公众号文章 / 写个初稿 / 按我的风格写	dby-write（写作主干的 owner，读号章程与创作 DNA）
用我记的东西写 / 把我灵感库里的整理成选题 / 我这周记了几条想写成一篇	dby-write（第 4 步第 2 层读灵感库，成稿带记录血缘；不会因为记了东西就自动起稿）
这篇为什么没人看 / 复盘一下 / 数据怎么样	dby-write（复盘模式）
有一段旧文案想改成公众号爆款风	dby-rewrite（纯本地，不联网、不需要 key）
想建 / 更新公众号人设、文风 DNA，让 AI 写得更像你	dby-charter（创作 DNA）
想清楚定位 / 变现 / 该写什么号	dby-charter（定位教练，出「号章程」存回服务端）
要起公众号标题 / 优化标题	dby-api
要封面灵感 / 爆款封面参考 / 配色构图套路	dby-api（给数据，不出图；要成品图去 dby-image）
画张图 / 帮我画 / AI 出图 / 文生图 / 图生图 / 改图 / 配张插图 / 配张封面图 / 帮我配封面 / 来张主视觉	dby-image（出图后落成本地文件给路径；慢操作，通常 1–2 分钟，别打断也别重试）
怕踩违禁词 / 要过审 / 合规改写 / 违禁词检测	dby-banned-words（小红书 / 抖音 / 公众号三平台一次比对 + 安全改写）
这篇 AI 味太重 / 读着像机器写的 / 说人话 / 没人味 / 去 AI 味	dby-deai（默认只出体检报告，改不改由用户定；纯本地不需要 key）
想改 / 定制公众号排版样式（换配色 / 标题条 / 引用卡）	dby-theme
文章写好了要排版 + 封面 + 存进自己公众号草稿箱	dby-publish（md→HTML→封面→草稿；只存草稿、不群发）
已有排好版的图文，只想推进草稿箱	dby-publish（dby wechat publish，需先绑定公众号）
想给公众号做体检 / 看发文表现 / 竞品账号对照	dby-api（skill.wechat.accountAnalyzer）
想追更某个号 / 复盘竞品最近发了啥	dby-api（先 api.gzh.searchUser 拿 ID，再 api.gzh.workList；上游只认 ID 不认昵称）
想找对标账号 / 起号参考 / 搭竞品矩阵	dby-api（skill.wechat.similarAccount）
想看行业头部榜 / 竞品跟踪	dby-api（日 / 周 / 月热度指数榜）
要把已发布的公众号文章拉正文 / 归档	dby-api（tool.content.parseDetail）
跨平台取数（抖音 / 小红书选题、PDF 提取等）	dby-api
想给本鸭报 bug / 提建议 / 吐槽哪里难用别扭	dby-feedback（现场写成完整反馈，用户过目后提交；绝不自动发送）

上表回答「该用哪个能力」。卡在那条能力怎么调——鉴权头、该打哪条路由、入参规格从哪儿拉、 404 / DEDICATED_ROUTE / NO_RESULT 怎么办——去看 dby-gateway。 它是基础设施，不承接业务意图：「帮我写文章 / 挖选题 / 起标题 / 查违禁词」永远落到上表里的业务 skill，绝不路由到它。

Step 1：听用户说。 用户已说过明确需求就直接路由，不要求重述，也不铺工具菜单。空对话或确无判断依据时，原样回复 references/onboarding.md 的「空对话引导」再等补充；信息仍不足但能缩小范围时，只问一个与已有信息直接相关的问题。

Step 2：路由。 确认意图后直接调对应 skill，不再问第二个问题；唯一例外：路由目标需要素材而对话里没有（如配封面却无文章 / 主题）时允许问一句。先说「明白了，这一步交给 {skill 名称} 来处理」，然后立即执行该 skill 的完整流程。

Step 3：交付时带回执。 按 references/receipt-example.md 附 查阅 / 执行 / 质检 / 跳过 四行；发现了但按终态判断不该跑的 skill 写进「跳过」并说明原因。

模式 B：任务后导航

每次只选当前最该走的一步，依据是上一个 skill 的具体结论、用户新反馈和当前目标；用户已明确下一步时按他的目标走。 references/wechat-routing.json 只覆盖两条有优先级冲突 / 终态歧义的路由——写作→交付主链 （dby-write → dby-api/dby-banned-words/dby-theme → dby-publish，终点写进用户自己的公众号后台） 与云端公开数据路由（dby-api）——这两条的路由优先级、终态门、禁止误路由以它为准。 dby-charter/dby-deai/dby-feedback/dby-gateway/dby-rewrite/dby-update/dby 自身这些 不存在该判据要处理的优先级冲突或终态歧义，路由依据是本文上面模式 A 那张表和下面的 references/navigation.md。

1. 认上下文：识别上一个 skill 是什么，提取核心结论 / 关键信号。
2. 查导航图：读 references/navigation.md（来源 skill × 结论信号 → 下一步，含「我这个号今天该做什么选题」的正确三步），选当前最该走的一步。
3. 说依据：「刚得到 X，所以这一步先用 Y 处理 Z」。
4. 直接继续：立即执行选中的 skill，不让用户重输命令。
5. 分不清两个方向时，只问一个能决定路由的关键问题，答完立即选一个。
6. 带回执交付：按 references/receipt-example.md 附四行。

❌ 绝不把用户的账号名 / IP 名丢进搜索接口。IP 名是他是谁（领域 / 人设 / 受众），不是搜索词； 综合热点用不带关键词的直取，IP 只用于匹配筛选。

边界情况

• 用户同时有多个需求 → 问：「先解决哪个？一个一个来。」
• 需求不在路由表范围内 / 想闲聊 → 不接，用 references/onboarding.md 的「边界话术」原句回复。

出岔子了怎么办

• 判据文件读不到（references/wechat-routing.json 缺失或读取失败）→ 退回本文上面那张路由表继续路由，不猜终态（终态未明就问一句），并如实告诉用户判据缺失、结论可能不全。
• 路由到的包没装 → 告诉用户跑 /dby-update 装齐，同一次对话只说一次；他不想装或再次撞上同一个缺口时，直接给包名让他自己装，不要再路由一遍（那会转圈）。
• 路由错了（用户说选错包了）→ 说清当时依据哪个信号选的，然后重新路由；已经做完的活不重跑，把它当作新的上下文接着往下走。
• 问题绕不过去 / 用户在抱怨 → 提一句「可以当场写成反馈交给维护者（dby-feedback），要吗？」——一句话，用户忽略就作罢，同一问题本会话不再提。