Solopreneur OS

SKILL.md

---
name: solopreneur-os
author: 王教成 Wang Jiaocheng (波动几何)
description: 一人公司操作系统。核心能力：工作流重构——将任何领域的复杂工作流重构为AI辅助一人简易完成的方法（拆解人的局限补偿层→消除→基于AI能力模型重整）。执行轴为6维能力调用而非角色分工，管线为IPO基元链而非流水线传递。内容轴提供清单法与样本法的OPC适配规则，创新轴适配一人公司独特约束的突破路径。领域负载物覆盖7域31种任务类型、每种任务的组件清单与18个实战范本（含5个合规检查范本+1个工作流重构范本）。覆盖从0到1启动、商业模式设计、AI工具栈搭建、合规风控、现金流管理的全周期。触发词：一人公司、OPC、单人创业、solopreneur、超级个体、独立开发者、个人商业、微创业、一人商业闭环。
---

# One Person Company OS — 一人公司操作系统

## 核心理念：工作流重构

OPC的真正核心不是"在传统工作流中用AI替代人工"，而是**基于AI能力模型重构工作流**。

传统工作流的复杂性 = 事情本身的复杂度 + 人的局限补偿层。人脑容量有限所以拆环节，人之间要文档传递所以有中间产物，人之间协作有损耗所以需要管理协调——这些复杂性只与人的局限有关，与事情本身无关。AI拥有广域知识+生成能力+上下文窗口，可以端到端完成复杂任务，不需要这些补偿机制。

因此OPC的执行方式是**能力调用**而非角色分工——遇到什么事就调用什么能力，不需要先贴角色标签。流程应该回归事情本身的复杂度，而大多数事情本身没那么复杂。

**适用范围不止于流程。** 任何产物（文档、方案、设计、代码）都可以拆解为组成部分，其组装过程就是一种"工作流"。本方法同样适用于：把一份复杂产物拆解为组件→识别哪些组件是人的局限补偿→消除→重整为AI可端到端产出的组装链。产物重构和流程重构是同构的。

### 重构三步法

| 步骤 | 操作 | 要点 |
|------|------|------|
| **拆解** | 识别每个环节的存在理由 | 追问：这个环节存在是因为事情本身需要，还是人的局限需要？ |
| **消除** | 去掉人的局限补偿层 | 传递/协调/格式环节直接消除，校验环节精简为关键节点；**校准环节保留**——中间产出物若起纠偏作用则不合并 |
| **重整** | 基于AI能力模型重新编排 | 保留的✅核心环节+🔶校准环节（作为基元内分步校准点）+⚡关键校验节点→端到端IPO基元链 |

**环节分类**：✅核心（保留） | 🔶校准（保留为基元内分步校准点） | ❌传递（消除） | ❌协调（消除） | ⚡校验（精简） | ❌格式（消除）

**校准 vs 校验**：校验是事后检查对错，校准是过程中锁定方向。校准环节的中间产出物（如功能描述、方法调用结构）不只是传递文档，更是在过程中提供纠偏锚点——省掉校准看似简化，实则把纠偏压力推到最终产出，返工成本更高。

**合并判断准则**：AI技术上能一步完成 ≠ 一步完成最好。消除环节前，除了问"这是人的局限还是事情本身的需要"，还要问"这个中间产出物是否在过程中起校准作用"。如果起校准作用，即使技术上能合并，也不应合并——应保留为基元内分步校准点。

**重构判断标准**（满足任一即需重构，详见 `references/sv-pipeline.md` §零）：3+角色接力 | 3+份中间文档流转 | 30%+时间在协调沟通 | 返工率≥30%

**重构验证清单**：⬜事情完整性 ⬜补偿层已消除 ⬜校准不丢失 ⬜端到端可执行 ⬜复杂度回归 ⬜质量守恒 ⬜合规不跳过

**重构后典型形态**：单步IPO（标准化任务） | 简短基元链2-5个（中等复杂度） | IPO+人工决策（涉及合规/客户/品牌）

**选择原则**：能单步IPO的不用基元链，能基元链的不加人工决策。

> 重构方法的完整执行逻辑、触发条件、前后对比模板、实例化演示详见 `references/sv-pipeline.md` §零。

---

## OPC定义

**一人公司（OPC, One Person Company）**：在AI工具赋能下，由单一创始人主导决策，借助AI Agent和外部资源网络，放大个体能力边界，形成商业价值闭环的创业形态。

| 特征 | 传统公司 | 个体户 | OPC |
|------|---------|--------|-----|
| 决策者 | 多人协商 | 一人 | 一人主导 |
| 执行力 | 团队分工 | 个人人力 | AI Agent+外部资源 |
| 规模化 | 招人扩编 | 受限于24小时 | 系统复制+产品化 |
| 成本结构 | 高固定成本 | 低但天花板低 | 极低启动成本+弹性 |
| 退出方式 | 融资/上市 | 关停 | 产品化/SaaS化/出售 |

---

## Step 0：判定

### 0A 阶段判定

| 阶段 | 特征 | 核心任务 | 推荐基元链 |
|------|------|---------|-----------|
| **0→1 探索期** | 无客户/产品/收入 | 验证需求、选定赛道 | OP-P1需求验证 |
| **1→10 验证期** | 首批客户、不稳定收入 | 跑通交付、积累案例 | OP-P2快速交付 |
| **10→100 增长期** | 稳定客源、需规模化 | 产品化、自动化 | OP-P5服务产品化 |
| **100→1000 扩张期** | 收入可观、需系统化 | SaaS化、品牌化 | OP-P3内容获客飞轮 |

### 0B 三轴判定

| 判定维度 | 简单 | 中等 | 复杂 |
|---------|------|------|------|
| **复杂度** | 单一问答→直接回答+陷阱检查 | 单模块任务→单步IPO | 跨模块任务→IPO基元链 |
| **内容类型** | 非结构化→不激活 | — | 结构化成品→激活内容轴 |
| **创新需求** | 常规执行→不激活 | — | 需要突破→激活创新轴 |

---

## 执行轴：6维能力调用

OPC最核心的约束是一个人承担所有事，但"承担所有事"不等于"扮演所有角色"。执行逻辑：识别任务需要什么能力→调用对应能力→产出结果。

| 能力 | 代号 | 本质 | 核心挑战 |
|------|------|------|---------|
| **调研** | S | 从环境中获取信息 | 信息过载，判断噪声vs信号 |
| **设计** | C | 对信息加工处理和决策 | 选择困难，判断自建vs外包vsSaaS |
| **执行** | A | 产生可观测的产出 | 执行疲劳，判断手动vsAI自动化 |
| **财务** | O | 结构化管理和维护资源 | 现金流生死线 |
| **获客** | I | 与外部主体建立关系 | 最难外包，AI不擅长 |
| **合规** | G | 确保安全、合规、质量 | 小组织承担完整责任 |

**调用逻辑**：不是"我是产品人所以做调研"，而是"这个任务需要调研能力所以调用"。能力之间无边界，同一刻可叠加多种能力。

**调用序列**：调研→设计→执行→财务自然推进，获客贯穿前三个，合规贯穿全部。

**关键原则**：一个人不是同时做六件事，而是一个人决定什么事该做什么不做、什么调用AI、什么外包。6维能力是能力框架，不是岗位清单。

> 6维能力的详细映射（操作类型/自治度/陷阱/决策矩阵）、领域校准推导、IPO基元链模式详解与实例化演示、执行规则、工具调用策略详见 `references/sv-pipeline.md`。

---

## 内容轴：OPC内容方法与商业模式

内容轴分两层：**方法层**（怎么组织内容）和**领域层**（OPC的商业模式数据）。

### 方法层

| 范式 | OPC适配 | 典型场景 |
|------|---------|---------|
| **清单法** | 按`references/sv-requirements.md`的槽位逐项填充 | 首次创建，确保不遗漏 |
| **样本法** | 按`references/sv-exemplars.md`的结构参考模仿产出 | 有高质量同类样本 |
| **结合** | 范本定框架+清单填内容 | 复杂成品 |

**方法选择**：首次创建按范本参考，已有经验按清单产出，复杂任务两者结合。用户决定，AI不得自动选择。

> 完整的清单法与样本法工作流详见 `references/sv-compose.md`。

### 领域层：四大商业模式

| 模式 | 毛利率 | 启动难度 | 月收入潜力 |
|------|--------|---------|-----------|
| **AI原生机构** | 70% | 低-中 | ¥2万-35万 |
| **AI顾问服务** | 80% | 低 | ¥2万-14万 |
| **AI数字产品** | 90% | 中 | ¥3.5万-21万 |
| **AI软件服务** | 95% | 高 | ¥7万-70万+ |

**Dan Martell升级路径**：AI服务/顾问（70-80%）→ 积累客户信任与业务洞察 → 可重复流程产品化打包成SaaS → 毛利升至95%。

> 四大商业模式的组件清单与定价参考详见 `references/sv-requirements.md` P2-01节。

---

## 创新轴：一人突破路径

OPC的创新约束独特——不是缺创意，而是缺资源、缺时间、缺人手。

| 模式 | 核心逻辑 | 典型场景 |
|------|---------|---------|
| **模式零：工作流重构**（前置） | 先重构流程本身，不在旧流程上优化 | 任何领域进入前的元能力 |
| **模式一：垂直利基定位** | 反转「做大市场」假设，极小市场极深服务 | 定位差异化 |
| **模式二：约束驱动** | 资源极限就是创新源泉 | 低成本获客、极限约束下的方案 |
| **模式三：技能→系统迁移** | 个人技能→商业系统的结构迁移 | 从时间换钱到系统换钱 |
| **模式四：一人×AI矩阵** | 个人能力维度×AI工具维度→新商业模式 | 跨领域能力组合发现 |

> 四种模式的详细执行方式、维度矩阵预设、评估侧重点、场景适配指引、创新工作流详见 `references/sv-innovation.md`。

---

## OPC实现途径

OPC的元能力是工作流重构——掌握了重构方法，任何领域都能简化为AI辅助一人简易完成。

| 途径 | 一个人能完成什么 | 传统工作流→重构后 | 实现技能 | OPC模式适配 |
|------|---------------|-------------------|---------|------------|
| **软件开发OPC** | 软件产品设计→开发→交付全流程 | 6+角色N份文档→需求→架构→代码三步 | AI Dev Workflow | AI软件服务(95%) / AI原生机构(70%) |
| **风格设计OPC** | 风格设计→生成→衍生→应用全流程 | 4+角色多轮迭代→6槽位×100实例一站式生成 | Style Design Generator | AI数字产品(90%) / AI顾问服务(80%) |
| **学术产出OPC** | 学术论文选题→论证→生成全流程 | 导师-学生-审稿人三角→选题四模式+论文四步流 | Thesis Topic Selector + Academic Thesis Workflow | AI数字产品(90%) / AI顾问服务(80%) |
| **网文创作OPC** | 网络小说世界观→大纲→正文→运营全流程 | 编辑-作者-运营三人→三轴运行时+领域负载物 | UTOS + Web Novel Writing Reference | AI数字产品(90%) / AI原生机构(70%) |
| **任意领域OPC** | 任意领域知识→任务体系→产出全流程 | N角色M环节→运行时+重构器+编译器+应用程序四层 | UTOS + Workflow Refactor + Domain Payload Generator + 目标领域负载物 | 按领域适配 |

**实现途径分两类**：独立工作流型（自含执行逻辑，标准工作流可覆盖）和生态组合型（运行时+重构器+编译器+应用程序四层寄生部署，需要高度定制领域知识）。

### 关于实现技能

实现途径中的每个技能（skill）都是你自己全面可控的工作系统，不是别人或公司做的黑箱工具。

**skill基本规范的优点**：
- **全面可定制**：执行逻辑、内容要求、质量标准、输出格式——所有需求按你的实际场景精确设计，没有任何环节是别人替你决定的
- **完全可修改**：拥有完整的定义权和修改权，不满意就改，不需要等别人更新版本或开放配置项
- **平台无关迁移**：skill是标准规范的自包含文件，任何支持skill规范的AI工具平台都能直接使用，不绑定任何特定产品或服务商
- **渐进式构建**：从最简单的SKILL.md单文件开始，按需扩展references/scripts/assets，复杂度随需求自然增长，不需要一开始就设计完整架构
- **版本可控**：纯文本文件，用Git管理演进历史，回滚/对比/协作与代码工作流一致
- **可组合复用**：skill之间可以引用和组合，已有skill的能力可以直接被新skill调用，不需要从零开始

**UTOS+WF+DPG+Payload四层架构**：

当skill复杂度超出基本规范的处理能力时，四层架构提供了超越单skill的能力——它不是更大的skill，而是不同层级的架构：

| 层级 | 角色 | 类比 | 说明 |
|------|------|------|------|
| **UTOS**（运行时） | 通用执行引擎 | 操作系统内核 | 三轴判定、能力调度、基元链编排 |
| **WF**（重构器） | 工作流重构引擎 | 编译器前端——源码解析与优化 | 拆解传统工作流→消除人的局限补偿层→重整为AI能力模型的IPO基元链 |
| **DPG**（编译器） | 领域知识编译引擎 | 编译器后端——代码生成 | 将重构后的领域知识结构编译为可执行的领域负载物 |
| **Payload**（应用程序） | 领域专属任务体系 | 应用程序 | 领域专属的任务体系、清单、范本——可独立使用也可寄生部署 |

**三层价值属性**：

| 技能 | 价值类型 | 使用频率 |
|------|---------|---------|
| **WF** | 转化价值——解决"从旧到新"的转化问题 | 低频、脉冲式 |
| **DPG** | 创建价值——解决"从无到有"的创建问题 | 中频、按需 |
| **UTOS** | 运行时价值——解决"执行任务"的运行问题 | 高频、持续 |

**职责分工**：

| 技能 | 管什么 | 不管什么 |
|------|--------|---------|
| **WF** | 流程结构——哪些环节保留、消除、校准 | 领域知识内容（清单/样本） |
| **DPG** | 领域知识内容——catalog(清单)、requirements(要求)、exemplars(范本) | 流程结构 |
| **UTOS** | 三轴执行框架——执行轴编排、内容轴消费清单/样本、创新轴突破 | 具体领域内容 |

**价值链**：

```
传统工作流 ──[WF]──→ 重构后IPO基元链 ──[DPG]──→ 领域负载物 ──[UTOS]──→ 持续执行
```

**四层协作逻辑**：WF不是UTOS的外部附加工具，而是四层架构中不可省略的层级——它确保DPG编译的源材料本身已消除人的局限补偿层，而非将传统流程直接编译为结构化但冗余的Payload。没有重构器的架构，等于编译器前端的源码未经解析优化就直接生成代码——产出物可能结构完整但包含大量不必要的补偿层残留。

**先重构再生成的效果**：

| 场景 | catalog任务数 | requirements复杂度 | exemplars数量 |
|------|-------------|-------------------|---------------|
| 未重构直接生成 | 包含传递/协调/格式环节对应的任务类型 | 大量"人的局限补偿"相关要求 | 范本里嵌套冗余中间产物 |
| 先重构再生成 | 只保留✅核心+🔶校准+⚡关键校验对应的类型 | 要求聚焦事情本身 | 范本干净，无冗余传递物 |

**四层架构优势**：
- **一次构建，多领域复用**：UTOS运行时只需部署一次，换一个Payload就切换一个全新领域
- **重构器前置保证**：WF在DPG编译之前运行，确保进入编译器的领域知识已基于AI能力模型重整
- **领域知识工程化**：WF产出重构后的IPO基元链→DPG将其编译为结构化Payload→领域经验可积累、可迭代、可交付
- **寄生部署**：Payload可寄生在UTOS运行时上获得完整执行能力，也可独立作为基本skill使用
- **无限扩展**：任何新领域只需要WF重构→DPG编译→生成新的Payload
- **重构器后置优化**：已产出的Payload也可再经WF重构三步法优化为更精简的IPO基元链

### 领域负载物生成（DPG）

DPG是元技能——产出不是领域知识本身，而是**领域负载物技能**。当需要为新领域创建知识参考库时，DPG负责从零生成完整技能。

#### 三层结构

DPG生成的领域负载物技能遵循固定三层结构：

```
第一层：任务清单 + 依赖拓扑       →  references/catalog.md
第二层：任务要求（槽位定义）       →  references/requirements.md
第三层：优秀范本                  →  references/exemplars.md + references/exemplars/子目录
```

- **第一层 catalog**：每个任务含5字段（ID/名称/说明/依赖/UTOS映射提示），附域间逻辑流和依赖拓扑摘要
- **第二层 requirements**：每个任务含必选组件、可选组件、组装顺序、约束、格式——定义"产出物由什么组成"
- **第三层 exemplars**：清单主文件做索引 + 子文件存具体范本，供UTOS内容轴样本法消费

#### 领域分析框架（R1-R5）

DPG使用五维度定位新领域，推导UTOS执行参数：

| 维度 | 低 | 高 | 影响什么 |
|------|----------|----------|---------|
| **R1 信息密度** | 操作类/手工类 → S轻 | 数据类/研究类 → S重C深 | 感知和认知单元占比 |
| **R2 创造性** | 流程类/合规类 → A标准 | 艺术类/研发类 → A极高 | 内容轴创新轴激活频率 |
| **R3 交互性** | 独立产出类 → I少 | 服务类/协作类 → I多 | 交互单元数量 |
| **R4 规范性** | 创作类/设计类 → G偏松 | 法规类/工程类 → G偏严 | 守护单元密度、合规约束数量 |
| **R5 迭代性** | 一次性交付→循环少 | 持续运营/连载→循环多 | 管线中↻模式的使用 |

#### 生成工作流

```
用户输入："帮我做一个XX领域的知识参考库"
        ↓
  Step 1: 领域分析（30-40%时间）
    ├─ 1A: 领域定义 + R1-R5分类定位
    ├─ 1B: 域划分（价值链拆解 / 职能分工）
    └─ 1C: 任务枚举 + 依赖推导 + UTOS映射提示
        ↓
  Step 2: 文件生成（40-50%时间）
    ├─ 2A: SKILL.md（三层结构+依赖声明+UTOS接口）
    ├─ 2B: catalog.md（任务清单+拓扑）
    ├─ 2C: requirements.md（槽位定义）
    └─ 2D: exemplars.md（范本框架）
        ↓
  Step 3: UTOS校验（10-15%时间）
    └─ 20项逐条检查 → 修正FAIL项 → 输出完整技能
```

#### UTOS兼容性契约

DPG生成的所有产物必须通过以下校验：

| 维度 | 要求 |
|------|------|
| 三层结构一致 | 必须为：catalog + requirements + exemplars |
| 依赖声明格式 | 必须含强依赖UTOS声明 + 加载检查流程 + 降级模式 |
| 元操作映射 | 每个任务必须标注S/C/A/O/I/G映射提示 |
| 五字段Schema | 每个任务组件必选：ID/名称/说明/依赖/UTOS映射 |
| 域间逻辑流 | 域间必须有明确的价值链逻辑顺序 |
| 依赖拓扑摘要 | 必须有至少3条跨域管线链路 |
| Step 0-4接口 | SKILL.md必须含"与UTOS的接口"章节 |

#### 三条路径对比

| 路径 | 清单/样本来源 | 优势 | 劣势 |
|------|-------------|------|------|
| **WF单独用** | 无，用户临时提供 | 流程极简 | 内容质量靠用户自身积累 |
| **WF + DPG + UTOS** | 领域负载物结构化提供 | 流程+内容双保险，系统化 | 首次生成有成本 |
| **WF + UTOS（无DPG）** | 用户手动输入到IPO的I | 灵活 | 每次都要手动准备，覆盖度不稳定 |

> DPG的完整领域分析框架、三层结构模板、UTOS接口校验清单、生成工作流详见 `domain-payload-generator` 技能的references目录。

---

## OPC领域负载物

执行轴管"怎么做"，领域负载物管"做什么"——7域31种任务类型、每种任务的零件清单、18个实战范本。

### 领域清单与依赖拓扑

| 域 | 任务数 | 核心任务 | 核心能力需求 |
|----|--------|---------|------------|
| **P0 工作流重构** | 6 | 传统工作流识别→环节分析→消除→重整→验证→形态选择 | 调研→设计→执行 |
| **P1 商业定位** | 4 | 垂直利基定位、市场扫描、差异化价值主张、能力盘点 | 调研→设计 |
| **P2 商业模式** | 4 | 模式选择、服务包定义、定价策略、收入结构 | 设计→财务 |
| **P3 产品与交付** | 4 | MVP设计、流程标准化、产品化路径、AI辅助交付 | 设计→执行 |
| **P4 获客与品牌** | 4 | 内容获客体系、冷启动、个人IP、转化留存 | 获客→执行 |
| **P5 运营与自动化** | 4 | AI工具栈、Agent工作流、日常SOP、系统迭代 | 执行→财务 |
| **P6 财务与合规** | 5 | 主体选择、现金流、税务、合同法律、数据安全 | 合规→财务 |

**关键依赖链路**：（详见 `references/sv-catalog.md` 依赖拓扑摘要）

> 完整清单与依赖拓扑详见 `references/sv-catalog.md`。

### 领域要求清单

每种任务类型的"零件清单"——必选/可选组件、组装顺序、领域约束。按清单逐项产出。

> 完整槽位详见 `references/sv-requirements.md`。

### 领域范本库

18个OPC实战范本（含1个工作流重构范本+5个合规检查范本），按范本参考产出。

| 范本ID | 范本名称 | 对应任务 |
|--------|---------|---------|
| EX-01 | 工作流重构范本 | P0 |
| EX-02 | 垂直利基定位一页纸 | P1-01 |
| EX-03 | 个人能力维度矩阵 | P1-04 |
| EX-04 | AI原生机构商业计划框架 | P2-02, P2-03 |
| EX-05 | AI数字产品商业计划框架 | P2-02, P2-03 |
| EX-06 | MVP一页纸 | P3-01 |
| EX-07 | 服务产品化路线图 | P3-03 |
| EX-08 | 内容获客飞轮设计 | P4-01 |
| EX-09 | 冷启动获客行动计划 | P4-02 |
| EX-10 | AI工具栈配置清单 | P5-01 |
| EX-11 | 日常运营SOP | P5-03 |
| EX-12 | 现金流管理表 | P6-02 |
| EX-13 | 服务合同审查清单 | P6-04 |
| EX-14~18 | 五大致命陷阱检查 | 全局 |

> 完整范本详见 `references/sv-exemplars.md`。

### 使用规则

1. **任务识别**：确认用户需要哪种OPC任务（参考catalog）
2. **方法选择**：首次创建按范本参考，已有经验按清单产出，复杂任务两者结合
3. **按需读取**：确认任务后读取对应requirements槽位和exemplars范本
4. **产出交付**：按清单逐项填充，或按范本结构替换实际内容
5. **用户主权**：AI按技能框架产出的内容是起点，不是终稿。用户对任何环节有独特的校准点、质量标准或业务约束，都可以也应当要求修改——尤其是校准点的取舍，只有用户知道哪些中间产出物对他的场景真正起纠偏作用。用户还可以主动提供清单和样本作为校准参考

---

## OPC专属IPO基元链模式

| 模式 | 流程 | 适用 |
|------|------|------|
| **OP-P1** 需求验证链 | I:想法→[S市场扫描]→[C需求判断]→[I潜在客户确认]→[G可行性验证]→O:验证结论 | 0→1阶段 |
| **OP-P2** MVP快速交付链 | I:已验证需求→[C最小方案设计]→[A AI辅助快速实现]→[I客户反馈]→↻→O:交付归档 | 1→10阶段 |
| **OP-P3** 内容获客飞轮链 | [A AI内容生产]⇉[I分发渠道1/2/3]→[S数据监测]→[C效果分析]→↻ | 任何阶段 |
| **OP-P4** 合规风控检查链 | [G主体合规]→[G税务合规]→[G合同合规]→[G数据安全]→O:合规档案 | 法律/财务/数据操作前 |
| **OP-P5** 服务产品化链 | I:已验证服务流程→[C产品化拆解]→[C自动化点位识别]→[A AI自动化搭建]→[G质量验证]→O:产品归档 | 10→100阶段 |

> 5种模式的详解、关键规则、实例化演示详见 `references/sv-pipeline.md` §三、§四。

---

## OPC领域校准

OPC领域校准不查表，按5条推导规则自动适配：

| 规则 | 校准结果 |
|------|---------|
| 资源极限原则 | 调研和设计能力优先调用，执行偏精准 |
| 现金流敏感原则 | 财务能力必须调用，合规不可省 |
| AI杠杆原则 | 执行优先评估AI自动化，获客AI辅助但人主导 |
| 垂直利基原则 | 设计决策时强制收敛到垂直领域 |
| 合规底线原则 | 合规能力贯穿全程，不可跳过 |

**校准维度默认值**：能力优先级 S:C:A:O:I:G ≈ 2:3:2:1.5:1.5:2 | 自治度 🟨半自动为主 | 创新评估 可行性+非平凡性 | 产出格式 一页纸/清单/可执行步骤

> 校准推导逻辑与阶段校准矩阵详见 `references/sv-pipeline.md` §二。

---

## OPC五大致命陷阱（内嵌合规检查）

| 陷阱 | 触发条件 | 检查动作 |
|------|---------|---------|
| **「AI能搞定一切」幻觉** | 纯AI执行决策 | 强制标注AI不擅长项+要求人工介入 |
| **合规与法律风险** | 注册/合同/财务决策 | 强制触发合规检查+法人独立原则 |
| **无客源就注册公司** | 提出注册公司意图 | 先验证3+付费客户？建议先个体工商户 |
| **卖AI技术而非商业成果** | 定位/获客决策 | 检查是否在说「我能帮你导入AI」→改说商业成果 |
| **定位太广无垂直利基** | 商业模式/定位决策 | 强制收敛：能否一句话说清服务谁解决什么 |

---

## OPC工具栈

| 能力需求 | 工具类型 | 月费参考 |
|---------|---------|---------|
| 调研 | 市场调研与信息检索工具 | 免费-¥200 |
| 设计 | 编码与架构辅助工具 | ¥100-300 |
| 执行 | 自动化流程与内容生产工具 | 免费-¥300 |
| 财务 | 协作表格与项目管理工具 | 免费-¥100 |
| 获客 | 获客辅助与客户沟通工具 | 按用量 |
| 合规 | 法律合规辅助工具 | 按用量 |

**选型原则**：优先国内可用/免费低成本；核心工具有备选；月费合计控制在¥200-500。

---

## OPC数据速览

| 指标 | 数据 |
|------|------|
| 全国OPC数量 | 超1600万家，占企业总数27.4% |
| 2025上半年新增 | 286万户，同比增47% |
| 高盈利OPC深度使用AI | 92% |
| 启动资金低于$500 | 90% |
| 稳定盈利比例 | 仅20%（SoloNest 2000+样本，待验证） |
| 单人创始人占比(2025) | 36.3%（6年增长53%） |

---

## 呈现规则

| 场景 | 默认呈现 | 可展开 |
|------|----------|--------|
| OPC快速问答 | 直接回答+陷阱检查 | 基元链详情、能力分析 |
| 商业模式设计 | 一页纸方案+四维评估 | 完整清单/样本、财务模型 |
| 合规风控 | 风险清单+建议 | 法律依据、操作步骤 |
| 现金流分析 | 关键指标+runway | 完整现金流表、情景分析 |
| 获客方案 | 渠道+成本+预期ROI | 内容策略、自动化流程 |

---

## 事实纪律

1. OPC政策数据必须基于可验证的最新政策，不确定的标注「待验证」
2. AI工具能力描述必须基于实际能力，不得夸大
3. 收入预期必须标注为「参考范围」，不得承诺具体数字
4. 合规建议必须标注「不构成法律意见」，关键决策建议咨询专业律师/会计师
5. 成功案例引用必须确知真实存在，不得编造
6. 对OPC的乐观预期必须同时呈现现实困难（仅20%稳定盈利）