评判和打造一人AI原创公司(OPC)的实战指南。双模式运行:先评判(OPC可行性评分0-100),后打造(四阶段行动框架)。当用户提到OPC、一人公司、solo founder、AI原生创业、个人创业、独立开发者创业、one-person company、solo startup等关键词时触发。尤其聚焦构思阶段验...
--- name: opc-playbook description: "评判和打造一人AI原创公司(OPC)的实战指南。双模式运行:先评判(OPC可行性评分0-100),后打造(四阶段行动框架)。当用户提到OPC、一人公司、solo founder、AI原生创业、个人创业、独立开发者创业、one-person company、solo startup等关键词时触发。尤其聚焦构思阶段验证,覆盖全生命周期,含心理支持模块。" metadata: source: "The Founder's Playbook: Building an AI-Native Startup (Claude/Anthropic, 2026-05)" agent_created: true version: "1.0.0" --- # 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. **六维度打分**:逐一评估并给出分数和理由 3. **生成诊断报告**: - 总分 + 等级判定 - 各维度分数 + 强弱项分析 - 最致命的 1-2 个短板及修复建议 - GO / 条件 GO / NO-GO 结论 4. **如果是 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 市场调研与竞品梳理 **必须回答的问题**: 1. TAM/SAM/SOM 多大?用公开数据建模型,对假设做压力测试 2. 竞品分四类:直接竞品、间接竞品、潜在收购方、跨界打劫者——每一类为什么对你构成威胁? 3. 竞品用户在骂什么?揪出 3 个被反复吐槽但没人解决的痛点 4. 未来 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 跑诊断,回答三个问题: 1. 数据里有没有特定群体的反应不同于其他人? 2. 设计价值 vs 体验价值的差距,是定位问题还是产品问题? 3. 当前产品要找到 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 最重要的资产): 1. **领域知识深度编码**:你的行业黑话、监管陷阱、极端边界情况 → 写入产品的测试用例和提示词优化 → 通用 AI 无法匹配 2. **用户行为数据复利**:用户接受/拒绝哪些输出 → 行为指纹 → 时间锁定的专有数据 → 抄袭者无法购买 3. **工作流锁定**:客户在产品上搭建自动化、培训团队、连接数据源 → 切换成本从换软件变成系统级手术 **行动**: - [ ] 找出 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 个核心问题) 1. 你想解决什么问题?为谁解决? 2. 你在这个领域有什么经验/资源? 3. 你知道有哪些竞品?你觉得他们做得怎么样? 4. 你的目标用户现在怎么凑合应对这个问题? 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. **推进最重要的 1 项任务**(不是最紧急的,是最重要的) 2. **检查关键指标**(用户数、留存、收入、AI 工具运行状态) 3. **记录 1 条决策/学习**(积累机构知识) ### 每周 1. **复盘本周进展** vs 上周计划 2. **5 客户/用户互动**(访谈、反馈收集、客服) 3. **1 次"魔鬼代言人"会议**(让 AI 挑战你的假设) 4. **心理自检**:1-10 分,你现在状态如何?<5 则本周减负 ### 每月 1. **阶段通关检查**:还在正确的阶段吗?是否该进下一阶段? 2. **重新跑一遍市场调研**(竞品格局变化、新进入者、用户需求漂移) 3. **OPC 可行性重新评分**:6 个维度有变化吗? 4. **倦怠信号检测**:连续 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](https://claude.com/blog/the-founders-playbook) — Anthropic/Claude, 2026-05 - **翻译**:[创始人手册:打造 AI 原生初创公司](https://baoyu.io/translations/2026-05-16/the-founders-playbook-building-an-ai-native-startup) — 宝玉翻译 - **OPC 概念延伸**:Paul Jarvis《Company of One》、Elad Gil《High Growth Handbook》
don't have the plugin yet? install it then click "run inline in claude" again.