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

核心理念：工作流重构

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

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

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

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

重构三步法

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

校准 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和外部资源网络，放大个体能力边界，形成商业价值闭环的创业形态。

Step 0：判定

0A 阶段判定

0B 三轴判定

执行轴：6维能力调用

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

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

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

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

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

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

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

方法层

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

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

领域层：四大商业模式

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

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

创新轴：一人突破路径

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

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

OPC实现途径

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

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

关于实现技能

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

skill基本规范的优点：

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

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

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

三层价值属性：

职责分工：

价值链：

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

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

先重构再生成的效果：

四层架构优势：

• 一次构建，多领域复用：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执行参数：

生成工作流

用户输入："帮我做一个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生成的所有产物必须通过以下校验：

三条路径对比

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

OPC领域负载物

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

领域清单与依赖拓扑

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

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

领域要求清单

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

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

领域范本库

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

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

使用规则

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

OPC专属IPO基元链模式

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

OPC领域校准

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

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

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

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

OPC工具栈

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

OPC数据速览

呈现规则

事实纪律

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