Install
openclaw skills install opc-playbookOPC Playbook
评判和打造一人AI原创公司（OPC）的实战指南。双模式运行：先评判（OPC可行性评分0-100），后打造（四阶段行动框架）。当用户提到OPC、一人公司、solo founder、AI原生创业、个人创业、独立开发者创业、one-person company、solo startup等关键词时触发。尤其聚焦构思阶段验证，覆盖全生命周期，含心理支持模块。
OPC Playbook — 评判与打造一人AI原创公司
OPC = One-Person Company。一个人 + AI 基础设施 = 可盈利的完整商业体。 本 Skill 不是鸡汤，是诊断表和行动手册。先评后建，用数据说话。
运行模式
本 Skill 有两种模式，评判优先：
| 模式 | 触发条件 | 输出 |
|---|---|---|
| 评判模式 | 用户提出一个 OPC 想法/方向，或问"这个方向靠谱吗" | OPC 可行性评分（0-100）+ 分维度诊断 + GO/NO-GO 建议 |
| 打造模式 | 用户确认要动手，或已通过评判拿到 GO | 四阶段行动清单 + 里程碑检查点 + 心理支持 |
流程：评判 → GO → 打造。如果评判结果是 NO-GO，先解决短板再重新评判。
模式一：评判模式 — OPC 可行性评分
评分体系（百分制）
总分 = 六维度加权求和，满分 100 分。
| # | 维度 | 权重 | 评估什么 | 得分范围 |
|---|---|---|---|---|
| 1 | 痛点真实度 | 25% | 痛点是否具体、高频、有人愿意付费解决 | 0-25 |
| 2 | 市场可行性 | 20% | TAM/SAM/SOM 是否够吃、竞品格局是否可入 | 0-20 |
| 3 | AI杠杆率 | 20% | 该领域用 AI 能否把 1 个人的产出放大到 10 人级别 | 0-20 |
| 4 | 护城河潜力 | 15% | 领域知识深度、数据飞轮、工作流锁定能否形成壁垒 | 0-15 |
| 5 | 个人适配度 | 10% | 创始人的行业经验、人脉、兴趣是否匹配 | 0-10 |
| 6 | OPC可持续性 | 10% | 单人能否长期支撑（运营复杂度、心理负荷、风险集中度） | 0-10 |
评分标准与判定
| 总分 | 判定 | 建议 |
|---|---|---|
| 80-100 | 🟢 强 GO | 立即进入打造模式，聚焦构思验证 |
| 60-79 | 🟡 条件 GO | 补齐短板后可推进，重点攻克低分维度 |
| 40-59 | 🟠 弱 NO-GO | 重大缺陷，需重新思考方向或调整模式 |
| 0-39 | 🔴 强 NO-GO | 方向本身有问题，建议换赛道 |
各维度打分细则
1. 痛点真实度（25分）
| 分值 | 标准 |
|---|---|
| 21-25 | 痛点极其具体（可写成可测试假设）、高频（周级以上）、用户已在花钱/花时间凑合解决 |
| 16-20 | 痛点具体但频率中等，或用户痛点深但替代方案尚可 |
| 11-15 | 痛点存在但模糊（"大家觉得X很麻烦"级别），缺乏定量证据 |
| 6-10 | 仅为个人感受或小众需求，无市场验证 |
| 0-5 | 伪需求或已解决的问题 |
关键测试：能否把痛点写成一句话假设？例——❌"合同审查太慢"；✅"中型企业内部法务每个合同审查周期>3天，因邮件往复改红线而非版本控制"。
2. 市场可行性（20分）
| 分值 | 标准 |
|---|---|
| 17-20 | 市场规模够大（SOM 可支撑单人公司盈利），竞品少或竞品体验差，进入壁垒对 OPC 友好 |
| 13-16 | 市场存在但较分散或竞品已有先发优势，需要差异化切入 |
| 9-12 | 市场不明朗，需要大量教育成本，或竞品极强 |
| 5-8 | 市场过小或已红海化，OPC 难以突围 |
| 0-4 | 无有效市场或已被巨头垄断 |
3. AI杠杆率（20分）
| 分值 | 标准 |
|---|---|
| 17-20 | 该领域的调研、开发、运营全链路均可被 AI 大幅加速，1人≈10人产出 |
| 13-16 | 核心环节可被 AI 加速，部分环节仍需人工（如线下交付、监管审批） |
| 9-12 | AI 可辅助但非核心杠杆，人工仍是关键瓶颈 |
| 5-8 | 该领域 AI 杠杆有限，高度依赖人际交互或物理操作 |
| 0-4 | AI 几乎无杠杆，完全依赖人力和线下资源 |
关键问题：用 AI 能否把"验证→开发→交付→运营"四步中的至少两步压缩 5 倍以上？
4. 护城河潜力（15分）
| 分值 | 标准 |
|---|---|
| 13-15 | 领域知识极深（行业黑话、极端边界情况、监管陷阱）、数据飞轮可运转、工作流锁定天然存在 |
| 10-12 | 有一定的领域知识壁垒或数据积累潜力，但需时间建立 |
| 7-9 | 护城河主要靠先发优势和速度，容易被复制 |
| 4-6 | 产品差异化弱，通用 AI 即可替代 |
| 0-3 | 无护城河，纯功能型工具，随时被大模型更新碾压 |
核心逻辑：OPC 的护城河不在代码，在领域知识的深度编码 + 用户行为数据的复利积累 + 工作流绑定的切换成本。
5. 个人适配度（10分）
| 分值 | 标准 |
|---|---|
| 9-10 | 在该领域有 3 年以上深度经验、有目标用户人脉、对该问题有真实体感 |
| 7-8 | 有相关经验或强学习意愿，需要补充行业知识 |
| 5-6 | 有兴趣但无直接经验，需要从零积累 |
| 3-4 | 经验不匹配，需大量学习 |
| 0-2 | 完全没有相关背景和兴趣 |
6. OPC可持续性（10分）
| 分值 | 标准 |
|---|---|
| 9-10 | 运营极轻（自动化程度高）、心理韧性强的创始人、风险分散合理 |
| 7-8 | 大部分可自动化，少数环节需人工值守，心理负荷可控 |
| 5-6 | 运营复杂度中等，需要定期人工干预，存在单点故障风险 |
| 3-4 | 运营重、客户服务要求高、创始人容易倦怠 |
| 0-2 | 高依赖人工、高客户服务负荷、高合规风险、单人几乎不可能持续 |
评判模式执行流程
当用户提出 OPC 想法时：
- 收集信息：通过结构化提问，了解用户的想法、行业背景、目标用户、竞品认知
- 六维度打分：逐一评估并给出分数和理由
- 生成诊断报告：
- 总分 + 等级判定
- 各维度分数 + 强弱项分析
- 最致命的 1-2 个短板及修复建议
- GO / 条件 GO / NO-GO 结论
- 如果是 GO/条件 GO：自动过渡到打造模式的构思阶段
模式二：打造模式 — 四阶段行动框架
四阶段总览
| 阶段 | 核心目标 | 通关条件 | 聚焦度 |
|---|---|---|---|
| 1. 构思 | 基于研究的验证 | 问题-方案契合点（Problem-Solution Fit） | ⭐⭐⭐⭐⭐ |
| 2. MVP | 痛点→可用产品 | PMF 真实证据 | ⭐⭐⭐ |
| 3. 发布 | 势能→可持续增长引擎 | 可重复渠道驱动增长、生产级可靠、运营不卡人 | ⭐⭐ |
| 4. 扩展 | 系统性增长+护城河 | 公司可持续运转（盈利/IPO/被收购） | ⭐ |
本 Skill 尤其聚焦构思阶段——因为这是 OPC 最容易死掉的阶段，且是所有后续阶段的根基。
阶段一：构思（Ideation）⭐⭐⭐⭐⭐
最高法则：让你的脑子走在手的前面。 在没有确凿证据之前，绝不盲目动手开发。
1.1 把痛点打磨成可测试假设
坏假设 vs 好假设：
| ❌ 不可测试 | ✅ 可测试 |
|---|---|
| "报销很麻烦" | "中型企业财务经理每周花4h+核对报销单，因现有工具无法与财务软件打通" |
| "合同审查太慢" | "内部法务每个审查周期>3天，因邮件往复改红线而非版本控制" |
| "大家需要更好的工具" | "自由设计师每月因版本混乱丢失2+次修改成果，无版本控制习惯" |
行动：
- 写出你的痛点假设（一句话，包含：谁 + 多频繁 + 多痛 + 现在怎么凑合）
- 让 AI 扮演"魔鬼代言人"，反驳你的假设，找负面证据
- 找出假设中 3 个最致命的依赖前提，逐一追问"如果不成立会怎样"
1.2 市场调研与竞品梳理
必须回答的问题：
- TAM/SAM/SOM 多大？用公开数据建模型，对假设做压力测试
- 竞品分四类：直接竞品、间接竞品、潜在收购方、跨界打劫者——每一类为什么对你构成威胁？
- 竞品用户在骂什么？揪出 3 个被反复吐槽但没人解决的痛点
- 未来 2 年内，哪些政策/技术/人口趋势会深刻影响这个市场？是顺风还是逆风？
行动：
- 让 AI 帮你做竞品分类 + 威胁分析（让它站在竞品立场论证为什么他们会赢）
- 梳理主流渠道的竞品评价，揪出未满足需求
- 用公开数据建 TAM/SAM/SOM 模型，压力测试假设
- 识别 3 个关键外部趋势并评估影响
⚠️ 市场调研不是一次性的。 MVP 和发布阶段认知升级后，必须重新跑一遍。
1.3 客户调研
找谁聊：1 个精准目标画像 > 100 个泛泛的通讯录。包括具体职位、公司类型、团队架构、痛点最深的人群职级。
问什么：追问历史（"上次遇到这破事怎么处理的？"），而非假设未来（"你会用这种产品吗？"）。
常见错误：
- ❌ 面向未来的空泛问题 → ✅ 追问具体的历史行为
- ❌ 诱导性提问 → ✅ 开放式追问
- ❌ 同一套题给所有人 → ✅ 按角色定制问卷
行动：
- 定义目标用户画像（职位、公司类型、职级、痛点深度）
- 设计访谈问题，让 AI 审计：揪出诱导性、太宽泛、面向未来的问题
- 设计 3 个关键追问（应对敷衍或含糊回答）
- 每 5 次访谈做一次综合分析：支持假设的证据 vs 反对假设的证据
- 如果支持证据远多于反对证据，追问自己：这是数据真实反映，还是我选择性看到了想看到的？
1.4 设计解决方案概念
现实检查：你现在设计解决的，是调研出来的真实问题，还是你最初瞎猜的原始假设？
行动：
- 让 AI 找出支撑你设计的 3 个最致命依赖假设
- 追问：如果这些假设要成立，需满足什么条件？哪怕一个不成立会怎样？
- 用 AI 从各角度拷打方案：漏洞、替代品、规模化前提条件
1.5 轻量级原型
不是做产品，是做方案的"体验样本"，拿去给客户和投资人看。
行动：
- 明确产品最核心的 1 个交互依赖点
- 只做这 1 个核心功能
- 扔给目标画像里的 5 个人试用
- 5 次沟通获取的认知 → 决定继续还是推倒重来
构思阶段通关检查
| # | 问题 | 通过标准 |
|---|---|---|
| 1 | 痛点真实且具体吗？ | 能准确说出谁在经历、频率、程度、现有应对方式 |
| 2 | 方案能解决实际痛点吗？ | 解决的是调研发现的真实痛点，不一定是最初假设 |
| 3 | 有足够信号支持开发吗？ | 定性证据让"MVP"成为深思熟虑的决定而非豪赌 |
阶段二：MVP（Minimum Viable Product）
本质仍是"收集证据"的演习——只是从"痛点空间"转到了"解决方案空间"。
2.1 开发前先定架构
- 在写第一行代码前，定义架构决策：遵循什么模式、避开什么依赖、做了什么妥协、为什么
- 产出 项目上下文文档（类似 CLAUDE.md），成为所有后续会话的根基
- 每次 AI 编程会话前：重温范围说明 + 上下文文档
- 每次会话结束：更新决策日志
2.2 定义并严格执行 MVP 边界
零阻力范围蔓延是 AI 时代 MVP 最具代表性的失败模式。
- 白纸黑字写下：做什么、坚决不做什么、加功能的触发标准
- 新功能冒出来时，用 AI 做压力测试：这是用户的真实呐喊，还是创始人自嗨？
- 决策点从"要不要做这个功能？"变为"是否有足够多核心用户告诉我们，没有这个功能他们就得不到价值？"
2.3 安全审查
智能体编程工具生成的是"能跑"的代码，不是天生安全的代码。
- 部署前做安全审查：身份验证、会话处理、API 数据暴露、输入验证、注入风险、有漏洞的依赖
- 任何涉及验证、密钥、数据处理的部分 → 人类复核
2.4 上线前搭好数据指标框架
- 定义：对你的产品，哪些指标最重要？基准线在哪？
- 设定留存基准线、激活标准、第 7 天和第 30 天目标
- 定义"假阳性"长什么样：注册未激活、有收入无留存、热情高涨但不重复使用
- 让 AI 站在对立面给数据挑刺
2.5 向"证据"迭代，不是向"完整"迭代
PMF 试金石：
- 肖恩·埃利斯测试：问活跃用户"如果以后再也不能用这个产品了，你感觉如何？" → >40% 答"非常失望" = 有意义的 PMF 指标
- 费力程度测试：从你"推"变成市场"拉"的时候，是真实信号
转型决策：3+ 迭代周期无 PMF 进展 → 用 AI 跑诊断，回答三个问题：
- 数据里有没有特定群体的反应不同于其他人？
- 设计价值 vs 体验价值的差距，是定位问题还是产品问题？
- 当前产品要找到 PMF 需满足什么前提？结合现有现象，现实吗？
阶段三：发布（Launch）
证明你的企业配得上成长。
3.1 清剿技术债
- 系统性架构审计：结构弱点、测试覆盖缺口、重构候选
- 分类排序：下次发布前必须修 / 一个冲刺内 / 可接受的持续债务
- 将 MVP 阶段脑子里的架构决策文档化
3.2 解放创始人注意力
- 对当前运营负载做结构化审计：每个循环任务、每个决策、每个只有你记得才会发生的流程
- 分类：可完全自动化 / 需人工但不必须是你 / 真正需要创始人判断力
- 为自动化任务设计工作流逻辑
3.3 安全合规就绪
- 生产规模前的系统安全审查
- 目标市场要求的合规标准检查
- 把合规工作流构建到日常开发周期中（不是一次性项目）
发布阶段通关检查
| # | 条件 |
|---|---|
| 1 | 增长可重复且由渠道驱动，CAC/LTV/回收期清晰可辩护 |
| 2 | 产品可处理生产负载，安全合规就绪 |
| 3 | 运营不再卡在创始人，流程和自动化已到位 |
阶段四：扩展（Scale）
从构建者转变为面向公众的高管。
4.1 放权运营层
- 映射当前所有通过你路由的工作流/决策/审批节点
- 压力测试：如果你消失一周，哪些环节会停摆？→ 这些就是交接需强化的地方
- 将机构知识编码成可审计、可转移的系统
4.2 技术运营企业级化
- 产品文档、客户支持手册、SLAs
- 日志、监控、事件响应、可观测分层
- 工单路由、升级提醒、文档同步、续约跟踪自动化
4.3 建立真正的 GTM 职能
- 细分市场、话术架构、分析师关系、销售话术本
- 内容流水线、开发信序列、CRM 自动化
- 交互式演示环境、API 文档、技术核心一页纸
4.4 构建护城河
三大防御机制（OPC 最重要的资产）：
- 领域知识深度编码：你的行业黑话、监管陷阱、极端边界情况 → 写入产品的测试用例和提示词优化 → 通用 AI 无法匹配
- 用户行为数据复利：用户接受/拒绝哪些输出 → 行为指纹 → 时间锁定的专有数据 → 抄袭者无法购买
- 工作流锁定：客户在产品上搭建自动化、培训团队、连接数据源 → 切换成本从换软件变成系统级手术
行动：
- 找出 1 个通用竞品必踩雷的极端状况，和 AI 合作构建专门测试用例
- 设计用户行为反馈闭环，将使用行为转化为模型级提升
- 对 TOP 10 客户做"工作流集成深度审计"：自动化、系统接口、协作流程、切换成本
OPC 特有挑战与心理支持
传统创业指南不谈这些。但 OPC 创始人必须在心理层面和运营层面同时存活。
挑战 1：没有联创的决策真空
症状：所有决策自己做，无人拍板时反复纠结，关键决策拖延。
解药：
- AI 反方辩友：让 AI 扮演联合创始人的角色，但站在反对面。每一个重大决策，先让 AI 给出最强反对理由
- 决策日志：写下决策、依据、预期结果、复盘时间点。30 天后回头看，比在脑子里转悠强 100 倍
- 最低可行顾问圈：找 2-3 个你信任的人（不需要是合伙人），组成非正式顾问。每周 30 分钟同步即可
挑战 2：单点故障风险
症状：你病了公司就停了；你倦了产品就没人维护；你分心了客户就没人响应。
解药：
- 自动化一切关键路径：客服（AI 客服机器人）、部署（CI/CD）、监控（告警系统）、收款（自动续费）。每个环节都问"如果我不在场，这还能运转吗？"
- 文档化一切关键知识：不是给自己看的，是给"万一需要交接时"准备的。包括运营手册、灾备方案、供应商联系方式
- 设置健康冗余：至少 2 周的运营缓冲（内容排期、自动回复、预付款项）
挑战 3：规模天花板焦虑
症状："一个人怎么也做不过团队"、"是不是该招人了"、"不招人就是不上进"。
重新定义：
- OPC 的"规模"≠ 人数。OPC 的规模 = 影响力 × 自动化程度。一个人通过 AI 工具触达 10 万用户 = 比一个 10 人团队更"大"
- 不招人 ≠ 不增长。你可以：接入更多 AI Agent、构建自助式服务、开放 API 让用户自建集成、外包非核心环节
- 招人的信号：当你发现有些事情 AI + 你确实搞不定，且这件事直接影响收入，才考虑
挑战 4：孤独与倦怠
症状：长期独立工作导致动力下降、社交匮乏、自我怀疑周期性爆发。
解药：
- 社区归属：加入 indie hacker / solopreneur 社区（Indie Hackers、Twitter/X 创业圈、即刻"独立开发者"圈）。不需要深度社交，只需要知道有人跟你走同样的路
- 节奏感：设定工作节奏并遵守——每日核心时段、每周复盘、每月里程碑。节奏感是 OPC 创始人的"精神骨架"
- 庆祝小胜：每拿到一个付费用户、每完成一个功能、每收到一条正面反馈，都值得记录和庆祝。大脑需要正反馈
- 允许低谷：OPC 之路不可能一路高歌。低谷是正常的，不是你不行，是这个模式本身的节奏。低谷时做最基础的事情就好——维护客户、修小 bug、写一篇分享
挑战 5：身份焦虑
症状："我到底是个公司还是个自由职业者？"、"跟人说自己是一个人做的，会不会被看轻？"
重新定义：
- 你不是"一个人干所有活"的人。你是指挥 AI 团队的指挥官。你的价值不在手速，在判断力和领域知识
- OPC 是一种组织形态选择，不是"还没招人的早期阶段"。很多 OPC 是有意选择保持精益，不是因为做不到更大
- 你的产品能解决问题、用户愿意付费——这比你公司有几个人重要得多
评判→打造衔接流程
当用户提出 OPC 想法时，执行以下流程：
Step 1：信息收集（3-5 个核心问题）
- 你想解决什么问题？为谁解决？
- 你在这个领域有什么经验/资源？
- 你知道有哪些竞品？你觉得他们做得怎么样？
- 你的目标用户现在怎么凑合应对这个问题？
- 你打算一个人做多久？有没有考虑找合伙人？
Step 2：六维度评分
逐一打分，给出分数 + 理由 + 1 句改进建议。
Step 3：诊断报告
╔══════════════════════════════════════╗
║ OPC 可行性评分报告 ║
╠══════════════════════════════════════╣
║ 总分：XX/100 判定：🟢 强 GO ║
╠══════════════════════════════════════╣
║ 痛点真实度： XX/25 ████████░░ ║
║ 市场可行性： XX/20 ██████░░░░ ║
║ AI杠杆率： XX/20 ████████░░ ║
║ 护城河潜力： XX/15 ████░░░░░░ ║
║ 个人适配度： XX/10 ██████░░░░ ║
║ OPC可持续性： XX/10 ████░░░░░░ ║
╠══════════════════════════════════════╣
║ 最强项：XXX（理由） ║
║ 最短板：XXX（修复建议） ║
║ GO/NO-GO：XXX ║
╚══════════════════════════════════════╝
Step 4：如果 GO → 进入打造模式
从构思阶段第一步开始，逐项推进。每完成一个阶段，做一次通关检查。
OPC 创始人每日/每周/每月节奏
每日（核心 3 件事）
- 推进最重要的 1 项任务（不是最紧急的，是最重要的）
- 检查关键指标（用户数、留存、收入、AI 工具运行状态）
- 记录 1 条决策/学习（积累机构知识）
每周
- 复盘本周进展 vs 上周计划
- 5 客户/用户互动（访谈、反馈收集、客服）
- 1 次"魔鬼代言人"会议（让 AI 挑战你的假设）
- 心理自检：1-10 分，你现在状态如何？<5 则本周减负
每月
- 阶段通关检查：还在正确的阶段吗？是否该进下一阶段？
- 重新跑一遍市场调研（竞品格局变化、新进入者、用户需求漂移）
- OPC 可行性重新评分：6 个维度有变化吗？
- 倦怠信号检测：连续 2 周动力低于 5/10 → 启动心理支持模块
关键原则速查
| # | 原则 | 解释 |
|---|---|---|
| 1 | 脑子走在手前面 | 没确凿证据前不开发，AI 让开发太容易，容易跳过验证 |
| 2 | 对证据迭代，不对完整迭代 | MVP 做到 PMF 证据就够，不需要功能完整 |
| 3 | 让 AI 做魔鬼代言人 | 确认偏误是 OPC 第一杀手，AI 顺着你说比反驳你容易 |
| 4 | 领域知识 > 代码 | OPC 的护城河是你脑子里的行业深度，不是代码量 |
| 5 | 范围是铁律 | 写下做什么/不做什么，加功能需真实用户证据 |
| 6 | 技术债是复利的 | AI 生成的无架构代码库会加速腐化，上下文文档是保险 |
| 7 | 自动化关键路径 | 每个环节问"如果我不在场，这还能运转吗？" |
| 8 | 节奏感是精神骨架 | 每日/周/月的固定节奏比灵感爆发更重要 |
| 9 | 低谷是特性不是 bug | OPC 之路有周期，低谷时做最基础的事就好 |
| 10 | 你是指挥官不是苦力 | 你的价值在判断力和领域知识，不在手速 |
来源与延伸阅读
- 原文：The Founder's Playbook: Building an AI-Native Startup — Anthropic/Claude, 2026-05
- 翻译：创始人手册：打造 AI 原生初创公司 — 宝玉翻译
- OPC 概念延伸：Paul Jarvis《Company of One》、Elad Gil《High Growth Handbook》