tob-poc-budget-justify — POC 预算论证助手
> 客户说"先做个 POC 看看"？帮你论证 POC 需要多少预算和资源。
当销售跟客户谈 POC，客户没明确预算/范围/时间/成功标准时，快速输出：
- POC 目标对齐与范围界定
- 资源/时间估算（人天 + 周期）
- 预算论证框架（为什么 POC 需要投入）
- 成功标准定义
- POC 72h 快速响应闭环（某大型文化集团实战，93% 通过率）
使用方式
交互模式（推荐）
tob-poc-budget-justify
快速模式
tob-poc-budget-justify --client "某零售集团" --industry "零售" \
--poc-goal "验证AI客服能否替代人工处理80%常见问题" \
--budget "10万以内" --decision-maker "IT总监"
精简模式
tob-poc-budget-justify --quick --client "某客户" --poc-goal "试试效果"
输出结构
POC 预算论证报告（Markdown），5 模块：
模块 1：POC 目标对齐
- 客户想验证什么（功能/效果/ROI/技术可行性）
- 客户的真实诉求 vs 表面诉求
- 风险提示：来自真实项目的教训
模块 2：POC 范围界定
| 范围 | 做什么 | 不做什么 | 原因 |
|---|---|---|---|
核心原则：POC 不是免费试用，是有边界的验证实验。
模块 3：资源/时间估算
| 阶段 | 人天 | 角色 | 交付物 |
|---|---|---|---|
注意：政务/金融行业含安全审计阶段，周期更长。
模块 4：成功标准定义
- 量化指标（准确率/响应时间/覆盖率）
- 验收方式（数据对比/客户打分/第三方评估）
- POC 72h 快速响应闭环（某大型文化集团实战）
- 超期警告：72h 无决策 → 标挂起 + 汇报
模块 5：预算论证
- 为什么 POC 需要预算（不是免费试用）
- 同行业 POC 投入参考（来自真实项目，去敏）
- POC 投入 vs 签单后收益对比
- 风险：无预算 POC 的隐性成本
规则来源
本 Skill 的规则萃取自 ToB 真实项目经验（去敏）：
- 零售行业：来自某零售 IT 服务商项目，"边界验证法"— 先列 3 个"不做什么"，客户才会认真谈预算。某项目 POC 预算 8 万，签单 50 万。
- 金融行业：来自某系统集成商项目，安全合规优先，低价竞品用"安全投入 = 合规保障"翻转。
- 政务行业：来自某政务集成项目，POC 最终是汇报给领导看的，必须有"领导能看懂的看板"。
- POC 72h 闭环：来自某大型文化集团实战，5 问题 48h 解决 4 个，93% POC 通过率。
不编造数据，不泄露客户信息。行业成本估算仅供参考，实际以项目具体情况为准。
实战原则
- POC = 有边界的验证 — 不是免费试用，不是功能演示
- 目标决定范围 — 客户说"试试效果" → 帮他翻译成具体验证指标
- 预算 ≠ 成本 — 是双方投入的诚意，无预算 POC = 客户不认真
- 成功标准先定义 — 签 POC 协议前先说好"什么算成功"
- 3 周是上限（零售） — POC 超过 3 周就变成项目，失去验证意义（政务/金融适当延长）
联用
- POC 前跑
tob-poc-budget-justify论证预算 → POC 中按 72h 闭环执行 → POC 成功后跑tob-sales-proposal生成提案 → POC 失败后跑tob-win-loss-review复盘
