findscripter 何时使用
面向处理排队工作（工单、案例、工作项）的运营团队定编：客服、CX、客户成功、BizOps、IT 运营、财务运营。基于 Erlang-C 排队论、Little 定律与运营管理经典（Fournier、Larson、Cleveland、Reinertsen）。纯确定性计算，仅用 Python 标准库，无 LLM 调用。
典型触发：
- 年度运营产能规划（次财年的 10-11 月）。
- 季度再定编：需求变化超 15% 或流失率骤升。
- 预算答辩：用算术而非"感觉"向 CFO 论证 headcount。
- 诊断：团队持续未达 SLA，需判断是定编、流程还是瓶颈问题。
- M&A / 新业务线：为新团队或合并组织定编。
- 适用门槛：团队持续利用率高于 80%，或12 个月内增长超 50%。在确定 headcount 预算前运行。
不该用边界：
- 工作不是排队制（项目型工作）→ 用错了技能。
- 工程产能 → 用 DORA 四项指标 / 周期时间 / WIP 那套（不同工作单元、不同数学）。
- 3-5 年战略人力规划（能力组合、人才供给、继任）→ 属战略 HR，本技能只做 0-12 个月的运营定编。
- 项目交付吞吐（Jira 速度、冲刺容量）→ 用项目管理工具。
- 先找瓶颈再定编：若不知道瓶颈在哪，先做流程映射（process-mapper），再用本技能围绕已知瓶颈定编——绕着错误约束招人等于浪费。
步骤
- 取需求分布。从工单系统（Zendesk、Intercom、JSM、ServiceNow、Salesforce）拉取每日工单/案例量的 P50/P90/P99。只有均值时立刻停下去拉分布——单点需求估计是运营中最昂贵的反模式。
- 建模吞吐。用你的需求、AHT（平均处理时长）、SLA 目标、当前 FTE、缩水率运行
capacity_modeler.py，按职能加--profile。读 80% 利用率那一行——那是你的定编点。 - 标利用率风险。对团队真实利用率数据运行
utilization_analyzer.py。任何人持续 >85% 即吞吐崩溃风险（Reinertsen）；团队内差距 >30 个百分点为 UNBALANCED（失衡）——招人前先修。 - 排招聘。用当前 FTE、年末目标、爬坡时长、流失率、增长率运行
hiring_sequencer.py。它会前置招聘（Q1 35%、Q4 15%）、套用爬坡曲线，并在管理跨度越过 7 IC/经理时触发管理岗招聘。 - 过逼问清单（见下）。一次一题，不许跳。提交计划前答案必须写下来。
指令
三个脚本均支持 --input <path>（JSON）、--output {markdown,json}、--sample（内置示例）、--help，纯标准库。
scripts/capacity_modeler.py—— Erlang-C 定编，含缩水率调整与 P50/P90/P99 违约概率；--profile取行业默认值。产出 70/80/90% 利用率下所需 FTE、各点 P(SLA 违约) 与 SAFE/WATCH/AT_RISK/CRITICAL 风险带。--profile可选support / cx / bizops / finance-ops / it-ops。scripts/utilization_analyzer.py—— 逐人红绿灯 + 团队级健康判定（HEALTHY/SQUEEZED/OVERLOADED/UNBALANCED），含方差检测。scripts/hiring_sequencer.py—— 12 个月季度计划，含爬坡、流失、增长、每季度最大招聘数约束与管理岗触发逻辑。
运行示例：
python scripts/capacity_modeler.py --profile support --sample
python scripts/capacity_modeler.py --input demand.json --profile cx --output json
python scripts/utilization_analyzer.py --input team_util.json
python scripts/hiring_sequencer.py --input hiring.json --output markdown
关键约束（建模假设）：
- 工作必须排队（工单/案例/工作项），非项目型。
- 一个季度内需求分布足够平稳；阶跃变化（新品发布、M&A、监管变动）需季中重跑。
- 至少 90 天历史需求数据才能算 P50/P90/P99；不足则先从销售/用户量预测生成分布。
- 队列内为单一服务等级；若有硬优先级分层（P1/P2/P3 各有 SLA），每层建一个独立队列再求和。
- 多渠道需连贯建模：用对应
--profile，内置缩水率溢价。
示例
capacity_modeler.py 的输入 JSON 骨架：
{
"team_name": "Tier-1 Support",
"demand": {
"tickets_per_day_p50": 320,
"tickets_per_day_p90": 480,
"tickets_per_day_p99": 720
},
"sla_target_minutes": 60,
"current_fte": 12,
"avg_handle_time_minutes": 18,
"shrinkage_pct": 30,
"working_hours_per_day": 8
}
行业 --profile 默认（缩水率% / SLA 目标分钟）：support 30/60、cx 32/30、bizops 25/240、finance-ops 22/480、it-ops 28/120。缩水率 = 不可用于产出工单的带薪时间占比（培训、休息、同步、PTO、临时打断）。
读结果时：先看 80% 利用率行定编；P(P90 违约)>10% 说明定编点欠员；P(P99 违约)>50% 说明没有峰值预案。
注意事项
反模式（Top 8，详见来源清单）：
- 按 100% 利用率规划（Reinertsen 原则 12）。
- 把爬坡当瞬时（Larson）。
- 12 个月计划忽略流失（Bersin）——30% 年流失下，20 人团队一年走约 6 人，"净增 5"实为"招 11"。
- 永远只招 IC、无管理岗触发（Fournier）——越过 7 IC/经理后 1:1 退化，越过 10 即覆盖危机，在跨 10 之前招经理。
- 只按 P50 需求定编（Cleveland）——会有一半时间错过 SLA；按 P99 又超配 30-50%，P90 才是正确运营定编点。
- 不做缩水率调整（Cleveland、SRE Workbook）。
- 多渠道工作用单渠道模型（Gartner、Kingman）。
- P99 事件无峰值预案（Hopp & Spearman、Reinertsen）——没有溢出层/外包/降级契约，P99 当天就是董事会可见的火情。
逼问清单（一次一题、按序、写下答案）：
- 你的瓶颈是什么，是否经验证实？（不是"感觉"，要带排队等待数据的具体阶段；Goldratt：系统同时只有一个绑定约束。）
- 你在接受何种服务权衡？（快 vs 共情 / 广 vs 深 / 低成本 vs 高质量——Frei：四者不可兼得。AHT/SLA/缩水率必须与该权衡一致。）
- 你的需求 P90 是多少，到 P99 差多大？（两个来自近 90 天的具体数字 + 日历背景。）
- 在计划利用率下，P90 与 P99 的 P(SLA 违约) 各是多少？（用 Erlang-C 算，不是猜。）
- 你为今年的流失预算了替补招聘吗？（具体数字。）
- 管理跨度何时触发管理岗招聘，候选人是谁？（来自
hiring_sequencer.py的具体季度 + 至少一名候选人。） - P99 当天的峰值预案是什么？（溢出层 / 外包合约 / on-call / 升级树，或书面降级契约。）
提交的计划，其可辩护程度只等于你对这七问的回答质量。
互见
- 工程产能：用 DORA 四项指标、周期时间、WIP 衡量工程吞吐——不同工作单元与数学，不在本技能范围。
- 战略人力规划：1-5 年能力组合、人才供给、继任——本技能只做运营 0-12 月定编（Lawler：混淆二者会被招进错的岗位）。
- 流程映射（process-mapper）：先找瓶颈，本技能再围绕已知瓶颈定编。顺序：process-mapper → capacity-planner。
- CS 覆盖（cs-coverage）：按 ARR/CSM 比与分层定编客户成功；本技能按排队工作量（工单、案例、升级）定编。同时承担关系工作与工单队列的 CS 团队，两者都跑。
采编自 alirezarezvani/claude-skills（MIT 许可）。