mcpField
C
challenge

challenge

github.com/alirezarezvani生产力28.9k1.4k 次安装2 天前更新
代码仓库

关于 challenge

面向计划评估团队的事前复盘技能，可在投入资源前检视方案。它按信心和影响评估假设、梳理依赖关系，并找出脆弱点及可逆性。

主要功能

  1. 01提取计划假设
  2. 02评估信心与影响
  3. 03定位高风险脆弱点
  4. 04梳理依赖链
  5. 05评估可逆性

适用场景

  1. 01审查产品路线图
  2. 02评估市场进入计划
  3. 03检视招聘或融资计划

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/alirezarezvani/claude-skills --skill challenge

安装后在 Claude Code 中输入/challenge确认已加载。

详细介绍

/em:challenge — 事前验尸式计划分析

命令: /em:challenge <plan>

在现实找上门之前,系统性地找出任何计划中的薄弱环节。目的不是否决计划,而是让它经得起现实的检验。

核心思路

大多数计划失败都有可预见的原因。不是运气不好,而是假设有问题:高估了需求,低估了复杂度,没有人质疑过的依赖关系,以及在电子表格里看起来合理、放到现实中却行不通的时间安排。

事前验尸技术:设想现在是 12 个月之后,这个计划已经彻底失败。然后倒推回去,找出原因。

这不是悲观主义,而是构建不易崩塌的东西的方法。

何时进行挑战

  • 在投入大量资源之前
  • 在向董事会或投资人汇报之前
  • 当你发现自己只听到关于该计划的正面反馈时
  • 当计划需要多个外部依赖同时到位时
  • 当有压力要快速推进,并想着“之后再想办法”时
  • 当你对该计划感到兴奋时(兴奋是需要更严格审视的信号)

挑战框架

第 1 步:提取核心假设

在检验计划之前,你需要先找出它所默认为真的所有事项。

针对计划的每个部分,问自己:

  • 要让这件事成功,必须满足哪些条件?
  • 我们对客户行为做了哪些假设?
  • 我们对竞争对手反应做了哪些假设?
  • 我们对自身执行能力做了哪些假设?
  • 这个计划依赖哪些外部因素?

常见假设类别:

  • 市场假设:规模、增长率、客户付费意愿、采购周期
  • 执行假设:团队产能、交付速度、无需大规模招聘
  • 客户假设:他们有这个问题,他们知道自己有这个问题,并且愿意付费解决
  • 竞争假设:现有企业不会反应,没有新进入者,护城河依然有效
  • 财务假设:燃烧率、收入时间点、CAC、LTV 比率
  • 依赖假设:合作伙伴会按时交付,API 不会变更,监管政策不会调整
第 2 步:为每个假设评级

对于提取出的每个假设,从两个维度进行评级:

置信度(你有多确定它是真的):

  • 高:已通过数据、客户访谈、市场调研验证
  • 中:方向大致正确,但尚未验证
  • 低:看似合理,但未经测试
  • 未知:我们根本不知道

假设错误时的影响(如果该假设不成立会怎样):

  • 严重:计划整体失败
  • 高:重大延期或成本超支
  • 中:需要大量返工
  • 低:可控的调整
第 3 步:绘制脆弱点

置信度为低/未知 × 影响为严重/高 的矩阵,就是你风险最高的假设。

脆弱点 = 低置信度 + 高影响

这些不是可以忽视的问题,而是你正在下的赌注。关键在于:你是否是在有意识地下这些赌注?

第 4 步:找出依赖链

很多计划失败,并不是因为某个单一假设错误,而是因为多个假设必须同时成立。

梳理依赖链:

  • 假设 B 是否依赖于假设 A 先成立?
  • 如果第一环出了问题,会有多少下游环节随之崩溃?
  • 关键路径是什么?哪里没有任何余量?
第 5 步:检验可逆性

对于每个关键脆弱点:如果该假设在第 3 个月被证明是错的,你会怎么办?

  • 能否转向?
  • 能否削减范围?
  • 资金是否已经花出去了?
  • 承诺是否已经做出了?

越不可逆,就越需要在做出承诺之前进行严格验证。

输出格式

挑战报告:[计划名称]

CORE ASSUMPTIONS (extracted)
1. [Assumption] — Confidence: [H/M/L/?] — Impact if wrong: [Critical/High/Medium/Low]
2. ...

VULNERABILITY MAP
Critical risks (act before proceeding):
• [#N] [Assumption] — WHY it might be wrong — WHAT breaks if it is

High risks (validate before scaling):
• ...

DEPENDENCY CHAIN
[Assumption A] → depends on → [Assumption B] → which enables → [Assumption C]
Weakest link: [X] — if this breaks, [Y] and [Z] also fail

REVERSIBILITY ASSESSMENT
• Reversible bets: [list]
• Irreversible commitments: [list — treat with extreme care]

KILL SWITCHES
What would have to be true at [30/60/90 days] to continue vs. kill/pivot?
• Continue if: ...
• Kill/pivot if: ...

HARDENING ACTIONS
1. [Specific validation to do before proceeding]
2. [Alternative approach to consider]
3. [Contingency to build into the plan]

按计划类型划分的挑战模式

产品路线图
  • 我们是在构建客户愿意付费的东西,还是他们说想要的东西?
  • 交付速度的估算是否考虑了真实的团队产能(而非理论产能)?
  • 如果核心功能的耗时是预估的 3 倍,会发生什么?
  • 当需求发生冲突时,由谁来做决定?
市场进入计划
  • 实际的 ICP 转化率是多少，而不是希望达到的那个？
  • 成交需要多少次触达？销售产能是否足以支撑？
  • 如果前 10 笔交易用了 3 个月而不是 1 个月，会发生什么？
  • “Land and expand”是真实可行的打法，还是一厢情愿？
招聘计划
  • 如果关键岗位的招聘用了 4 个月而不是 6 周，会发生什么？
  • 计划是否依赖于留住特定的人，而这些人可能会离开？
  • 计划是否考虑了爬坡期（通常需要 3–6 个月才能完全胜任）？
  • 如果招聘人员领先营收 6 个月，对烧钱速度会有什么影响？
融资计划
  • 如果领投方退出，你的备选方案是什么？
  • 你是否模拟过融资耗时 6 个月而不是 3 个月的时间线？
  • 如果融资在低端额度完成，按当前烧钱速度，你的跑道有多长？
  • 如果你只募集到目标金额的 50%，哪些假设会失效？

最难回答的问题

这些是人们常常回避的问题：

  • “最坏情况是什么，而不是基准情况？”
  • “如果这套计划由一个我们不信任的团队执行，它还能成功吗？”
  • “有哪些事情因为令人不适，我们一直没有直说？”
  • “谁有动机让这份计划听起来比实际更好？”
  • “如果要攻击这份计划，敌人会先攻击哪里？”

交付物

/em:challenge 的输出并不意味着可以停下来。它是一张漏洞地图。现在你可以做出有意识的决策：验证高风险假设、对关键假设进行对冲，或者明知而接受你正在承担的赌注。

未知的风险最危险，已知的风险则可以管理。

评论

支持 Markdown