money-panel

/money-panel — 多评审者协调器

标准启动流程：生成输出前，按照 /money § 标准技能启动流程，执行 5 步启动序列（解析 slug → 写入遥测数据 → 自动加载所有学习类别 → 展示项目本地技能（如果有）→ 加载所有原子类别；如果某个原子直接影响子评审者的结论，则每位子评审者都必须通过 A-{id} 引用它）。

你的任务是针对用户的商业计划，依次进行四人评审，然后综合评审结果。每位评审者都是拥有独立结论的完整角色。你要运行全部四位评审者，收集他们的输出，找出共识与分歧，并且只呈现确实需要人工决策的事项。

评审技能不可省略，也不能走捷径。 你必须实际调用每项技能并阅读其输出。不调用技能就进行综合评审，只是在演戏。

---

为什么要这样做

独立创始人可以为任何计划寻找理由，让它看起来可行。多角度评审能迫使人们正视各自独立的失败模式。但连续进行四轮评审会让人筋疲力尽——到第 3 位评审者时，用户已经疲惫不堪，不再参与。协调器正是为解决这个问题而设计：自动运行全部评审，找出共识，只呈现尚未明确的判断。

输出：一份最终结论，明确指出分歧，并附上后续行动清单。

---

触发方式

命令	行为
/money-panel	对最近讨论的计划运行评审会
/money-panel <path-to-plan.md>	对指定计划文件进行评审
/money-panel --slug <project>	从 ~/.smtm/sessions/<project>/ 提取最新快照并进行评审
/money-panel --skip <reviewer>	跳过指定评审者（例如 --skip skeptic）。谨慎使用——四角度评审正是整个流程的核心
/money-panel --add <persona>	为评审流程添加自定义评审角色（见下文“自定义角色”）
/money-panel --only <persona>[,<persona>...]	只运行指定的评审者。适用于修复某个维度的问题后重新评审

自然语言等效说法：

• “评审会”、“运行所有评审”、“评审流程”、“对这个计划进行压力测试”
• “审议会”、“四方评审”、“全角度评审”

---

要加载的内容

1. 最新快照，位于 ~/.smtm/sessions/{slug}/
2. 项目经验，位于 ~/.smtm/projects/{slug}/learnings.jsonl
3. 先前的评审会记录——检查项目会话目录中是否有近期的 /money-panel 运行记录；如果有，则提示：“上次评审会是在 {N} 天前，结论是 {V}。此后有什么变化吗？”

计划至少必须包含：ICP、价格、价值主张、市场推广渠道和预计收入所需时间。缺少其中任何一项，都不要继续；应拒绝并建议先运行 /money-strategy。

---

工作流

步骤 1 — 准备检查

打印一段话，总结即将评审的内容：

Panel about to review: {plan title}
ICP: {icp}
Price: {price}
Wedge: {wedge}
Time to first $1k MRR estimate: {weeks}

Reviewers in this run: investor, customer, operator, skeptic

请用户确认这些输入正确无误后再继续。评审质量取决于收到的输入质量。

步骤 2 — 运行评审者 1：投资者

使用相同的计划输入调用 /money-review-investor。记录其结论（以下之一：适合种子轮融资／仅适合后续融资轮次／仅适合自举创业／无法融资）和逐题评分表。暂时不要向用户展示；只需记录。

步骤 3 — 运行评审者 2：客户

调用 /money-review-customer。记录其结论（现在就会付费／有阻力但会付费／定位错误／ICP 错误）以及客户实际提出的异议。

步骤 4 — 运行评审者 3：运营者

调用 /money-review-operator。记录其结论（现在即可交付／缩减范围后即可交付／需要招聘／技术栈错误）以及切实可行的 8 周路线图。

步骤 5 — 运行评审者 4：怀疑者

调用 /money-review-skeptic。记录其结论（致命风险／可解决的风险／低风险／问题问错了）、最主要的 3 项风险，以及被回避的问题。

步骤 6 — 综合评估

将四位评审者的所有评定映射为 0-3 分：

评审者	3（绿色）	2（黄色）	1（橙色）	0（红色）
投资者	种子轮可行	仅适合后续轮次	仅适合自力更生	无法融资
客户	现在就付费	有阻力，但愿意付费	定位错误	ICP 错误
运营者	现在即可发布	缩减范围后即可发布	需要招聘	技术栈错误
怀疑者	风险低	风险可解决	问题问错了	生存性风险

将分数相加（最高 12 分）。根据以下标准给出评审团结论：

• 10-12 → 🟢 立即发布：从四个角度看，计划都切实可行。开始构建。
• 7-9 → 🟡 修改后发布：计划仍可挽救。下方列出了做出承诺前需要进行的具体修改。
• 4-6 → 🟠 返工：至少两个角度指出计划存在重大问题。不要发布；修改计划结构。
• 0-3 → 🔴 放弃或转向：至少存在一个生存性问题，且整体表现薄弱。要么寻找不同的切入点，要么运行 /money-diagnose，找出基本面薄弱的计划为何总是出现。

步骤 7 — 找出分歧

对于每位评审者，记录他们分别认为用户应该改进什么。如果有 3 位或更多评审者提出相同的改进项，那就是“自动确定的行动”（照做）。

如果评审者意见不一（例如，投资者认为可以融资，而运营者认为无法由一人独自发布），那就是“取舍决策”——明确呈现给用户。这些时刻最能体现评审团的价值：用户只需思考那些难以取舍的判断。

步骤 8 — 输出

使用以下固定结构：

# Panel Review — {plan title}

## Final Verdict: {🟢 SHIP IT / 🟡 REVISE THEN SHIP / 🟠 REWORK / 🔴 KILL OR PIVOT}

**Score: {N}/12**

{One paragraph synthesizing the four angles into a single take.}

---

## The four reviewers

| Reviewer | Verdict | Score |
|---|---|---|
| Investor | {verdict} | {0-3} |
| Customer | {verdict} | {0-3} |
| Operator | {verdict} | {0-3} |
| Skeptic | {verdict} | {0-3} |
| **Total** | | **{N}/12** |

---

## Where they agreed (auto-decided actions)

For each item, this means 3+ reviewers independently flagged the same fix.

- [ ] {action 1}
- [ ] {action 2}
- ...

These are the highest-confidence next actions.

---

## Where they disagreed (your call)

Each disagreement is a place where the panel can't auto-decide because it's a taste call only the user can make. Format each as:

### Disagreement 1: {topic}
- {Reviewer A} said: {position}
- {Reviewer B} said: {opposing position}
- **Why this matters**: {1 sentence}
- **Your call**: {prompt for user to choose}

### Disagreement 2: ...

---

## The avoided question (from Skeptic)

{The single most-avoided question from the skeptic review. Restate it here at the panel level — it's typically the highest-leverage question to actually answer before any execution.}

---

## Three things to do this week

Concrete actions, sequenced. Format: "[ ] {action} — by {day}"

- [ ] {action 1, ideally something testable in <72 hours}
- [ ] {action 2}
- [ ] {action 3}

---

## Suggested next skill

Based on the verdict:
- 🟢 SHIP IT → suggest `/money-save` then `/money-product`
- 🟡 REVISE THEN SHIP → suggest `/money-strategy` to revise, then re-run `/money-panel`
- 🟠 REWORK → suggest `/money-strategy` from a deeper rework, possibly returning to `/money-discover` first
- 🔴 KILL OR PIVOT → suggest `/money-diagnose` to surface why this plan keeps surfacing, or `/money-discover` for a new wedge

---

原则

• 即使能预测结论，也要运行全部四位评审者——价值在于意外的发现，而非预期的结论。
• 分歧才是精华——评审者意见一致的地方，用户已经知道。意见不一的地方，才是用户真正需要思考的。
• 不要淡化负面结论——🔴 就是 🔴。不要为了照顾情绪而把它平均成委婉的 🟠。关键在于承诺之前得到真实的评估。
• 最重要的输出是那个被回避的问题——把它醒目地呈现出来，不要埋在某个章节里。
• 三个行动，不是十个——以 15 个待办事项收尾的评审团不会促成行动。三个高杠杆行动才会。

---

自定义角色设定（--add 标志）

四位内置评审者涵盖了业务可行性。有些计划还需要其他视角——企业采购买家、硬件供应专家、隐私律师、社区经理、开源维护者。使用 --add 可将领域专家加入评审流程，同时保留四位核心评审者。

语法

/money-panel --add "<role>: <one-sentence brief>"

示例：

/money-panel --add "Enterprise IT buyer: I need SOC2, SSO, and DPA before signing"
/money-panel --add "Open-source maintainer: I'm wary of vendoring this dependency"

如何运行自定义角色评审

对于每个 --add 角色，按照以下结构进行小型评审：

1. 角色背景：将角色重述为一段自我介绍。包括激励因素——他们因什么受到奖励、因什么受到惩罚，以及日常工作实际是什么样的。
2. 三个问题：只生成该角色会针对这个计划提出的三个问题。不要泛泛而谈——问题必须只有从该角色的视角出发才有意义。
3. 用他们的语言给出结论：使用该角色自己的表述方式给出结论（企业买家不会说“能否发布”，而会说“我能通过采购流程报销这笔费用吗”）。
4. 用户遗漏的一件事：用一句话指出计划未涉及、但该角色认为会阻碍计划推进的唯一事项。

自定义角色的结论会加入评审矩阵，但不计入 12 分总分。它会单独出现在“其他视角”部分。用它来进行压力测试，而不是作为关卡。

值得添加的常见自定义角色

计划类型	值得添加的自定义角色
企业 SaaS	“企业 IT 买家”、“合规官”、“采购负责人”
消费者应用	“毫无耐心的普通用户”、“注重隐私的用户”、“喜欢自定义一切的高级用户”
开发者工具	“评估依赖项的资深工程师”、“开源维护者”、“50 人公司的平台团队负责人”
市场平台	“双边市场专家”、“流动性优先的投资者”
硬件 / 供应链	“运营 / 履约负责人”、“制造合作伙伴”
受监管行业	“领域专属律师（医疗保健 / 金融 / 教育）”

对于每种计划类型，默认的 --add 集大约会增加两个角色。超过两个会引入干扰；只加一个通常不足以发现足够多的问题。

评审小组结束后

如果结果为 🟢 或 🟡：强烈建议使用 /money-save 锁定评审结论。后续技能应遵循“我们进行了评审小组讨论，得出了 X 结论”，而不是重新争论。

如果结果为 🟠 或 🔴：同样建议使用 /money-save——保存评审小组的结果本身就很有用，之后可供 /money-restore 和 /money-report 使用。即使记录的是“这个计划被否决了”，也属于宝贵的机构记忆。

---

价值量化（必须在输出末尾列出）

• ⏱ 节省的时间——约省下 2-4 周：原本需要全神贯注地依次运行四项评审技能；此外，还能避免花数月执行有缺陷的计划
• ⚠️ 规避的风险——(1) 通过选择性阅读评审结果，为计划自我辩护，直到获得绿灯；(2) 评审疲劳——到第 3 次评审时，大多数创始人都会不假思索地赞同；(3) 在客套的总结中掩盖本应提出的问题；(4) 行动过多——最后列出 12 项待办，却无人理会
• ✅ 你获得的内容——一个 🟢/🟡/🟠/🔴 总结论、四项评审的子结论、自动决定的行动、需要你自行判断的明确分歧、揭示出的回避问题，以及本周的 3 项具体行动
• 🚧 没有这项技能时——你会进行一两次评审，接受最乐观的结论，然后发布产品；到了第 4 个月才发现，没进行的那项评审本来能立即指出结构性问题