business-operations-skills

业务运营 — 领域协调器

BizOps 层面是内部的：也就是公司实际运作的方式。此协调器会分叉对话上下文，将你的询问路由到六个子技能之一，然后向父线程返回简明摘要。繁重的资料导入工作（供应商目录、流程访谈、多文档 SOP 收集）会留在分叉的上下文中。

何时调用

症状	路由到的子技能
“工作大部分时间都在什么地方等待？”	process-mapper
“这个供应商的交付是否符合 SLA？”	vendor-management
“我们有足够的人手在第三季度交付吗？”	capacity-planner
“我需要向公司介绍一次组织架构调整”	internal-comms
“为我编写一份事件响应流程的运行手册”	knowledge-ops
“为什么我们的软件支出同比增长了 40%？”	procurement-optimizer

路由逻辑（确定性）

协调器会根据提示词中检测到的信号对询问进行分类。达到两个信号即可自信路由；仅检测到一个信号时则会提出澄清问题。

信号表

信号类别	关键词	子技能
PROCESS	瓶颈、周期时间、等待、交接、BPMN、流程图、工作流	process-mapper
VENDOR	供应商、SLA、合同、第三方、MSA、SaaS 订阅、续约	vendor-management
CAPACITY	人数、产能、利用率、规划、招聘顺序、FTE	capacity-planner
COMMS	全员大会、内部简报、公告、变更管理、FAQ、员工大会	internal-comms
KNOWLEDGE	SOP、运行手册、知识库、wiki、操作指南、文档、入职文档	knowledge-ops
PROCUREMENT	支出、采购、供应商合理化、软件审计、SaaS 蔓延	procurement-optimizer

如果信号混杂（例如，“供应商 SLA + 支出审计”），先运行置信度最高的子技能，然后在后续分叉轮次中衔接第二个子技能。

回退

如果没有任何信号类别的得分 ≥ 2，则提出一个澄清问题，指出两个最可能的候选项。切勿默默猜测。

工作流（Matt Pocock 式深挖规范）

此规范源自 Matt Pocock 的 grill-with-docs 模式：先探索再提问，每轮只问一个问题并给出建议答案，沿决策树深度优先推进，追踪依赖关系，并确保每个质疑都有文档依据（references/）。

第 1 步 — 提问前先探索

提出任何澄清问题之前，先检查：

• 用户的工作目录中是否已有可供我们搜索的流程图、供应商目录、SOP 或组织架构图？
• 询问是否已经明确了所属领域（例如，“供应商 SLA 审查”就是 vendor-management，无需提问）？
• 文件名是否能明确所属领域（procurement-Q3.csv → 采购）？

如果代码库能确定所属领域，直接路由。不要提问。

第 2 步 — 若仍有歧义，只提一个有引导性的强制选择问题，并给出建议答案

Matt 的规则：绝不捆绑提问。绝不要默认问“你怎么看？”。始终给出你的建议。

模式：

Q1/1: [precise question naming the two candidate lanes]
Recommended: [Lane X, because <one-sentence rationale from the signal table>]

(Confirm, or override?)

等待用户回复。然后再进行路由。提问后，绝不能在用户回复前默默猜测。

第 3 步 — 分叉式决策树推进（仅当询问跨越多个领域时）

如果用户的询问确实跨越两个领域（例如，“供应商 SLA + 支出审计” = VENDOR + PROCUREMENT），则按深度优先方式沿决策树推进：

1. 先确定置信度较高的领域 → 在分叉上下文中运行该子技能 → 返回摘要
2. 提问：“现在要运行[第二个领域]吗？我的建议是：要，因为[依赖原因]。”
3. 只有在用户明确确认后，才运行第二个子技能

切勿默默串联。每个分叉步骤都必须经过用户明确确认。

第 4 步 — 在分叉上下文中调用子技能

每个子技能都会收到原始提示词，以及结构化输入（文件路径、JSON 输入）的摘要。分叉上下文会将大量摄取内容（供应商目录、流程记录、SOP 源文档）留在父上下文之外。

第 5 步 — 返回摘要并附上引用依据的挑战

子技能完成后，向父线程返回一份不超过 200 词的摘要：

• 分析了什么
• 3 项主要发现（每项都须注明参考文档引用，例如：“Goldratt 的约束理论：优化瓶颈，而非非约束因素”）
• 3 项后续行动（尽可能注明负责人）
• 产出物的路径
• 一个刨根问底的挑战问题，并注明引用：“你的增值率为 12%。精益经典著作（Womack & Jones，1996）将低于 15% 归类为浪费严重。是什么阻碍了流程重设计——政治、技术，还是预算？”

随后，父 Agent 可以提出后续问题（每个问题都会触发新的分叉调用）。

逼问问题库（基于文档的刨根问底模式）

当用户提供了足够的上下文，可以进入某条路径时，编排器可以在调用子技能前，先就该路径中的决策向用户提问。每轮只问一个问题，并附上建议答案和经典依据引用。示例：

• PROCESS 路径：“开始绘制流程图前：你有各阶段的实测周期时间，还是只有估算值？建议：坚持获取最长的 3 个阶段的实测数据。反模式（Goldratt，1984）：根据估算绘图，会优化错误的约束。”
• VENDOR 路径：“开始评分前：你的一级关键性门槛是什么——按支出（每年 $X），还是按运营依赖性（供应商故障会导致收入受阻）？建议：按运营依赖性划分。反模式（Gartner TPRM）：仅按支出分级会漏掉支出低但关键的供应商，例如 Target 数据泄露事件中的 HVAC 供应商。”
• CAPACITY 路径：“开始建模前：你是按利用率还是吞吐量进行规划？建议：按吞吐量（Little 定律）。反模式（DORA）：利用率规划超过 80% 会因排队而损害吞吐量。”

在确定该路径的定义性决策之前，绝不要运行子技能。

假设

1. 用户代表一家员工人数 ≥ 10 人的组织行事（规模更小的组织不需要此功能）。
2. 用户能够访问子技能所需的数据（流程文档、供应商列表、支出导出等），或接受技能提供的模板虚拟数据。
3. 用户需要的是确定性、可重复的分析，而不是带有 LLM 风格的文字。每个子技能都附带仅依赖 Python 标准库的工具。

非目标

• 不能替代 ERP、供应商管理平台（Vendr、Tropic）或容量规划 SaaS（Float、Runn）。
• 不会跨会话存储状态——每次调用都是独立的。
• Python 工具不会调用外部 API（设计上仅使用标准库）。

与以下内容的区别

• business-growth/* — 这是外部销售流程（CSM、销售工程、RevOps）。BizOps 面向内部。
• c-level-advisor/coo-advisor — 这是战略层面的 COO 判断（“我们应该重组吗？”）。BizOps 侧重战术层面（“这是带有瓶颈的流程图”）。
• engineering/slo-architect — 这是使用 SLO/SLI/错误预算的系统可靠性。process-mapper 关注的是业务流程可靠性，而非系统可靠性。
• engineering/llm-wiki — 这是个人 PKM（Karpathy 的模式）。knowledge-ops 负责全公司范围的 SOP 编写。

输出产物

每个子技能至少会生成一个产物（Markdown、CSV 或 JSON），并保存到用户的工作目录中。编排器会在摘要中提供文件路径。

反模式（请勿）

• ❌ 为了“面面俱到”而运行全部 6 个子技能——根据迹象选择一个，返回摘要，再由用户决定是否继续调用其他技能
• ❌ 自动批准供应商或流程变更——呈现发现，由人工决定
• ❌ 未经询问就编辑生产流程文档——写入新文件，并提出差异
• ❌ 跳过摘要步骤——父上下文需要的是不超过 200 词的摘要，而不是完整的子技能输出

参考资料

• 有关 COO 的战略定位，请参阅 c-level-advisor/coo-advisor
• Path-B 构建模式：documentation/implementation/bizops-commercial-expansion-plan.md