业务流程、供应商与团队产能管理

它解决什么问题

公司内部的运营工作常常散落在各处：流程记录在访谈纪要里，供应商条款锁在合同 PDF 里，产能判断依赖某个负责人的直觉。当有人问「这批工作卡在哪里等待」「这个供应商是否达到 SLA」「Q3 能不能按时交付」，得到的通常是一次临时拼凑的回答，而不是可重复的依据。

这个技能面向的是内部运营（the BizOps surface is internal），不替代 ERP、供应商管理平台或产能规划 SaaS，也不负责对外销售动作。它把六类常见诉求拆成六个子技能：

• process-mapper — 识别瓶颈、等待时间与交接点
• vendor-management — 对照 SLA 与合同条款评估交付
• capacity-planner — 基于 headcount、FTE、utilization 做排期判断
• internal-comms — 变更通知、全员沟通、FAQ
• knowledge-ops — SOP、runbook、wiki 与入职文档
• procurement-optimizer — spend 审计、软件订阅梳理、供应商整合

它是怎么做的

核心是一个编排器（orchestrator）。它在分叉出的上下文（forked context）中接收原始请求和结构化输入（文件路径、JSON），子技能在其中做重活——读取供应商目录、整理流程访谈记录、吸收多份 SOP——父线程只拿到一份不超过 200 字的摘要。

分流逻辑是确定性的，基于提示词中的信号：

• 单类信号达到阈值即分流；混合信号时先跑置信度最高的子技能，再在后续轮次确认是否串联第二个。
• 若无信号达到阈值，会提出一个问题，点名两个最可能的候选方向，而不是静默猜测。
• 在提问之前先检查工作目录：是否已有 process map、vendor catalog、SOP 或组织图可供检索；若文件名已经指明方向（例如 procurement-Q3.csv），直接静默分流。

工作流遵循 explore-then-ask：先检索已有材料，再决定是否需要澄清；每次只问一个问题，并附上推荐答案，然后逐层深入决策树并跟踪依赖。每个子技能都会在用户工作目录生成至少一个产物（markdown、CSV 或 JSON），摘要中会给出文件路径。

适用边界

• 适合组织规模不少于 10 人的团队；更小的团队通常不需要这一层编排。
• 需要用户能提供相应数据（流程文档、供应商清单、支出导出等），或接受技能自带的模板化示例数据。
• 子技能的 Python 工具只使用标准库，设计上不调用外部 API；需要联网检索时会先说明目标与用途并取得明确同意。
• 不适合替代 COO 层级的战略判断（如「该不该重组」），也不同于工程侧的系统可靠性（SLO/SLI）或个人知识管理。
• 不会自动批准供应商变更或流程修改，也不会在未经询问的情况下编辑生产文档——它输出发现与建议，由人来决定；对现有文档的修改会写入新文件并提议差异。
• 不在会话之间保存状态，每次调用都是自包含的，因此分析结果需要依赖当前提供的数据。