创始人智能路由

问题：23 个命令的认知税

当 gstack 提供了 23 个斜杠命令时，创始人需要记住每个命令的用途并判断该用哪一个。这本身就是一种认知负担——你手头有一个具体问题，却先要花时间回忆该敲哪个命令。更糟的是，如果选错了，路由就会偏离，后续的上下文加载和决策记录也跟着走偏。

工作原理：关键词 + 意图路由

/cs:founder-mode 把这个负担从人脑转移到了系统。它由 cs-chief-of-staff 代理执行，核心逻辑是关键词 + 意图匹配。路由器会扫描问题中的信号词，然后按预定义规则映射到对应的 C 级顾问：

• 出现 burn、runway、fundraise、dilution 等财务信号 → cs-cfo-advisor
• 出现 pipeline、win rate、forecast 等销售信号 → cs-cro-advisor
• 出现 positioning、ICP、message、brand 等市场信号 → cs-cmo-advisor
• 出现 roadmap、PMF、JTBD、North Star 等产品信号 → cs-cpo-advisor
• 出现 cadence、OKR、scorecard 等运营信号 → cs-coo-advisor
• 出现 hiring、comp、ladder、equity 等人事信号 → cs-chro-advisor
• 出现 security、threat、compliance、SOC 2 等安全信号 → cs-ciso-advisor
• 出现 architecture、tech debt、SLO、latency 等技术信号 → cs-cto-advisor
• 出现 contract、IP、term sheet 等法务信号 → cs-general-counsel-advisor
• 出现 retention、NRR、churn、CSM 等客户成功信号 → cs-cco-advisor
• 出现 training data、consent、data mesh 等数据信号 → cs-cdo-advisor
• 出现 model selection、eval、hallucination、EU AI Act 等 AI 信号 → cs-caio-advisor
• 出现 DORA、cycle time、deploy frequency 等工程效能信号 → cs-vpe-advisor
• 出现 strategy、vision、board、M&A 等战略信号 → cs-ceo-advisor

如果问题里出现来自两个或更多角色的信号，路由器会先通过 /cs:brief 生成摘要，再触发 /cs:boardroom 进入多角色会商。如果问题模糊或无信号匹配，它会先调用 /cs:office-hours 强制创始人把问题说清，而不是硬猜。

工作流固定为五步：解析问题中的角色信号；若恰好一个角色，直接调用对应的 cs-* agent；若两个或更多，先建 brief 再进 boardroom；若模糊，先进 office hours；无论哪条路径，都会通过 decision-logger 记录本次路由决策。

边界与注意事项

这套路由本质上是关键词驱动的确定性匹配，不是语义理解模型。它不会自己判断「这其实是个财务问题」，而是找有没有 burn、runway 之类的词。所以如果你的问题用了领域内的同义词或隐喻，很可能被判为 ambiguous，然后被打回 office hours 让你重新描述。这不是 bug，是设计——它宁可让你多说两句，也不愿路由错。

另外，它依赖 company-context.md 和 decision-logger 的持久记忆来避免重复讨论已经决策的事项。如果上下文文件缺失或决策日志没写，路由器不会知道之前的选择，可能重新走一遍老路。还有一点：路由表覆盖了 14 个 C 级角色，但如果你的公司结构或问题域不在这张表里，也需要自己补充映射规则，否则照样落进 ambiguous。