---
name: opc-equity-cooperation
description: OPC分布式协作中台解决方案，解决临时团队动态合作、能力出资合规、多方利益分配
license: MIT
compatibility:
  - claude-code
  - copilot
  - cursor
  - openclaw
  - coze
author: 胡田
version: 1.0.0
---

# 胡田-OPC导师-股权合作机制 Skill

## 技能描述

一套完整的OPC分布式协作中台解决方案，解决临时团队动态合作、能力出资合规性、多方协议签署、国企孵化审计合规等核心痛点，彻底摆脱对工位的依赖。

> **一句话定位**：用「合同约定+贡献记录」代替「工商注册+股权绑定」，把平台的角色限定在工具和服务，彻底隔离资金风险。

> 📌 **姊妹篇提示**：本Skill专注SPV层面的合作与分钱机制。如需了解从项目孵化到SPAC上市的完整资本化路径，请参考姊妹Skill「胡田-SPAC资本路径规划」。

## 核心适用场景

| 场景 | 适用模式 | 说明 |
|------|---------|------|
| 临时OPC团队组建项目合作 | 项目型SPV | 几个人临时组队做项目，按里程碑分账 |
| 本地化生意联盟合作 | 联盟型SPV | 做家门口生意，不需要工位，平台按单抽成 |
| 国企孵化器OPC项目孵化 | 母SPV+子SPV | 国企出服务包不出钱，简化审计流程 |
| 任何需要动态股权分配的轻量级合作 | 通用框架 | 三层架构适配各类场景 |

## 三大核心创新

### 1. 三层递进合作机制
```
联盟层（轻量）→ SPV层（项目）→ 实体公司层（成熟）
   90%场景           9%场景           1%场景
```

### 2. 双层法律架构
- **第一阶段（项目期）**：贡献权重 + 牵头方代持，**不涉及工商变更**
- **第二阶段（成熟期）**：历史贡献折算工商股权，**才启用股权概念**

### 3. 制度+信用双重约束体系
- **三长老治理**：盟主（执行）+ 合规长老（合规）+ 监事长老（监督）
- **5级信用评级**：S/A/B/C/D级，信用分实时影响分配系数

## 核心概念速查

| 概念 | 定义 | 适用范围 |
|------|------|---------|
| **OPC** | Operation Partnership Connection，运营合伙人连接 | 所有场景 |
| **SPV** | Special Purpose Vehicle，特殊目的载体 | 本Skill专指"软SPV"（非工商注册） |
| **软SPV** | 虚拟合作共同体，靠合同+区块链存证，不注册公司 | 99%的OPC项目 |
| **硬SPV** | 正式注册的法律实体，有工商股权 | 仅成熟稳定项目 |
| **贡献权重** | 事先约定的收益分配比例，代表角色分工 | 软SPV阶段 |
| **股权** | 工商注册的股东权益 | 仅硬SPV阶段 |
| **牵头方** | 联盟对外签约的主体，代持SPV法律关系 | 所有项目 |

## 使用方法

### 第一步：选择SPV模式

根据场景选择对应的SPV类型：

| 模式 | 适用场景 | 典型参与者 | 典型收益 |
|------|---------|-----------|---------|
| **轻量联盟SPV** | 兼职/副业/家门口生意 | 小老板、社区团长、兼职者 | 按单抽5%服务费 |
| **项目型SPV** | 几个人组队做项目 | 自媒体团队、设计工作室、外包团队 | 项目服务费+按需工位费 |
| **国企孵化型** | 母SPV+子SPV双层架构 | 国企+OPC孵化项目 | 服务费+股权增值 |

### 第二步：组建治理团队

```
三长老角色设计：
┌────────────────────────────────────────────────────┐
│              联盟盟主（发起人/运营导师）             │
│  • 日常运营决策、争议协调、对外代表                 │
│  • 任期1年，可连任                                 │
├────────────────────────────────────────────────────┤
│              合规长老（律师/会计师/国企代表）        │
│  • 法律合规审查、税务方案审核、敏感词监控          │
│  • 发现违规可立即暂停执行                          │
│  • 任期半年轮换                                    │
├────────────────────────────────────────────────────┤
│              监事长老（民主选举的核心成员）          │
│  • 监督盟主行为、审计账务、保护中小成员利益         │
│  • 发起弹劾的权力                                  │
│  • 任期半年轮换，不得连任超过2届                   │
└────────────────────────────────────────────────────┘
```

### 第三步：跑通六大系统

按以下顺序启动系统，确保数据流转闭环：

```
1. 合同系统 → 生成贡献权重初始值
        ↓
2. 设计规划系统 → 任务执行与里程碑验收
        ↓
3. 账务台账系统（含共管账户+分账+发票）→ 记录贡献
        ↓
4. 信用台账 → 履约情况更新信用分
        ↓
5. 审计系统 → 全流程审计生成报告
        ↓
6. 风控系统 → 实时监控预警/拦截
        ↓
7. 区块链存证 → 所有节点全上链
```

### 第四步：分账与清算

严格按以下顺序执行分账流程：

```
1. 【回款到账】客户付款给牵头方
        ↓
2. 【开票给客户】牵头方开全额发票
        ↓
3. 【成本确认与开票】各方向牵头方开成本发票
        ↓
4. 【税费核算】牵头方核算应缴税费
        ↓
5. 【分账执行】
   ├── 扣除税费预留
   ├── 扣除平台服务费（5%）
   ├── 报销实际成本（已开票部分）
   └── 按贡献权重分配税后净收益
        ↓
6. 【打款】牵头方分别打款给各方
        ↓
7. 【完税凭证】全员可查
```

**分账优先级（严格顺序）**：
1. 税费预留（按比例计提）
2. 平台服务费（5%）
3. 实际成本报销
4. 按贡献权重分配收益

## 关键文件索引

| 文件 | 内容 | 优先级 |
|------|------|--------|
| `references/01-核心概念.md` | 三层架构、SPV模式、法律框架 | ⭐⭐⭐ 必读 |
| `references/02-治理机制.md` | 三长老权责、议事规则、争议解决 | ⭐⭐⭐ 必读 |
| `references/03-六大系统.md` | 业务系统完整设计 | ⭐⭐ 重要 |
| `references/04-财务税务.md` | 共管账户、分账流程、发票方案 | ⭐⭐⭐ 必读 |
| `references/05-信用评级.md` | 5级信用体系、升降级规则 | ⭐⭐ 重要 |
| `references/06-国企孵化.md` | 母SPV+子SPV双层架构 | ⭐ 特定场景 |
| `references/07-合规红线.md` | 非法集资防范、敏感词对照表 | ⭐⭐⭐ 必读 |
| `references/08-落地路径.md` | MVP→完善版→平台版 | ⭐⭐ 重要 |
| `references/09-合同模板.md` | 合作协议、服务采购协议模板 | ⭐⭐ 重要 |
| `references/10-流程图.drawio` | 完整泳道流程图（可用diagrams.net打开） | ⭐⭐⭐ 必读 |

## 快速检查清单

启动一个OPC项目前，确认以下事项：

```
□ SPV模式已选定（联盟型/项目型/国企孵化型）
□ 三长老角色已确认（盟主+合规长老+监事长老）
□ 贡献权重已约定并上链存证
□ 牵头方已确定（对外签约主体）
□ 共管账户已开设（双人U盾）
□ 分账优先级已约定
□ 税务方案已确认（各参与方开票给牵头方）
□ 合规长老已完成合规审查
□ 所有合同已签约上链
□ 六大系统已初始化
```

## 合规底线（绝对不能碰）

| 红线 | 正确做法 |
|------|---------|
| ❌ 向不特定对象公开募集资金 | ✅ 只对接特定的已有合作基础的人 |
| ❌ 承诺固定收益或保本 | ✅ 只说按实际项目收益分配，风险自担 |
| ❌ 平台归集资金形成资金池 | ✅ 资金走第三方托管或共管账户 |
| ❌ 层级裂变、拉人头返利 | ✅ 每个项目独立核算，不搞层级 |
| ❌ 发行代币、积分分红 | ✅ 不用任何代币化，只做合同约定 |
| ❌ 服务包没有定价依据 | ✅ 每个服务项都有市场价格参考和验收标准 |

## 常见问题

**Q: SPV不是法律实体，怎么签合同？**
A: 由牵头方代持，所有法律行为通过牵头方签署。合作方与牵头方签《服务采购协议》。

**Q: 贡献权重和股权有什么区别？**
A: 贡献权重只在软SPV阶段使用，代表收益分配权，不代表任何股权，不涉及工商变更。股权只在项目成熟后注册硬SPV时才启用。

**Q: 国企怎么参与？**
A: 国企出"服务包"（场地、政策、品牌等）不出真金白银，用服务包折算成母SPV的小比例股权（10-20%）。只需签一次母SPV协议，所有子SPV由母SPV统一管理。

**Q: 发票问题怎么解决？**
A: SPV本身不开票，由各参与方各自开票给牵头方，牵头方开票给客户。这解决了SPV不是法律实体无法开票的问题。

**Q: 项目做大了想上市怎么办？**
A: 本Skill聚焦SPV层面的分钱与治理，项目做大后的资本化路径（SPV→实体公司→SPAC上市）请参考姊妹Skill「胡田-SPAC资本路径规划」。

**Q: SPV和实体公司是什么关系？**
A: SPV是虚拟合作共同体，用贡献权重分账；实体公司是工商注册实体，用股权分账。当SPV项目成熟后（连续盈利+年营收>500万），可以选择折算成实体公司股权，这时资本化规划请参考姊妹Skill。

---

## Agent Harness（执行保障体系）

### Harness标签
| 标签 | 值 |
|------|-----|
| harness:enabled | yes |
| harness:pre-check | 6 |
| harness:checkpoints | 5 |
| harness:post-check | 12 |
| harness:files | 10 |
| harness:dependencies | 无 |
| harness:self-heal | yes |

### Pre-Check（执行前检查）
| 序号 | 检查项 | 检查方法 | 失败处理 |
|------|--------|---------|---------|
| PC1 | references目录存在 | 检查 `./胡田-OPC导师-股权合作机制/references/` 目录是否存在 | 创建目录并提示缺失文件 |
| PC2 | 核心参考文件完整性 | 检查10个references文件是否全部存在 | 提示缺失文件，阻塞严重项 |
| PC3 | 输出目录可写 | 检查工作目录是否可创建文件 | 切换到可写目录 |
| PC4 | SPV模式已选定 | 验证用户输入包含SPV类型（联盟型/项目型/国企孵化型） | 提示选择SPV模式 |
| PC5 | 三长老角色已确认 | 验证输入包含盟主、合规长老、监事长老信息 | 提示填写三长老信息 |
| PC6 | 牵头方已确定 | 验证输入包含牵头方法人信息 | 提示指定牵头方 |

### Checkpoints（关键步骤检查点）
| 序号 | 检查点 | 触发时机 | 验证内容 | 失败处理 |
|------|--------|---------|---------|---------|
| CP1 | 合同系统初始化 | 生成贡献权重初始值后 | 权重文件存在且包含所有参与方 | 重新生成或补充 |
| CP2 | 三长老治理机制 | 完成三长老角色分配后 | 三个角色职责清晰、无冲突 | 提示冲突并重新分配 |
| CP3 | 共管账户设置 | 完成账户配置后 | 账户信息完整（双人U盾机制） | 提示完善账户配置 |
| CP4 | 分账优先级确认 | 完成分账规则设定后 | 税费→平台费→成本→收益的顺序正确 | 强制执行标准顺序 |
| CP5 | 合规审查通过 | 合规长老完成审查后 | 无违规项或违规项已修复 | 阻塞直到合规 |

### Post-Check（执行后验证）
| 序号 | 验证项 | 验证方法 | 最低标准 | 失败处理 |
|------|--------|---------|---------|---------|
| PV1 | 核心概念.md存在 | 文件存在性检查 | 文件>1KB | 重新生成 |
| PV2 | 治理机制.md存在 | 文件存在性检查 | 文件>1KB | 重新生成 |
| PV3 | 六大系统.md存在 | 文件存在性检查 | 文件>1KB | 重新生成 |
| PV4 | 财务税务.md存在 | 文件存在性检查 | 文件>1KB | 重新生成 |
| PV5 | 信用评级.md存在 | 文件存在性检查 | 文件>1KB | 重新生成 |
| PV6 | 合规红线.md存在 | 文件存在性检查 | 文件>1KB | 重新生成 |
| PV7 | SPV合作协议包含甲方乙方 | 内容检查 | 包含"甲方"、"乙方"、"股权比例" | 补充缺失章节 |
| PV8 | 分账流程包含7个步骤 | 内容检查 | 包含税费/平台费/成本/收益关键字 | 补充缺失步骤 |
| PV9 | 三长老职责不冲突 | 逻辑检查 | 三者职责无重叠或冲突 | 重新设计职责边界 |
| PV10 | 共管账户机制完整 | 内容检查 | 包含双人U盾/审批机制 | 补充账户安全机制 |
| PV11 | 区块链存证方案存在 | 文件/内容检查 | 包含存证方案描述 | 补充存证机制 |
| PV12 | 执行报告生成 | 自动生成 | 包含检查点结果和交付物清单 | 触发自修复 |

### Self-Heal（自修复策略）
| 故障场景 | 修复策略 | 重试上限 |
|---------|---------|---------|
| references文件缺失 | 根据业务逻辑重新生成标准内容 | 3次 |
| 协议文件缺少关键章节 | 自动补充标准章节模板 | 2次 |
| 分账顺序不符合规范 | 强制重排为标准顺序（税费→平台费→成本→收益） | 1次 |
| 三长老职责冲突 | 调用三长老角色模板重新分配 | 2次 |
| 网络超时（区块链存证） | 跳过存证步骤，标记待补充 | 3次 |

### Handoff（Skill间交接）
| 方向 | Skill名称 | 接口类型 | 数据格式 |
|------|----------|---------|---------|
| 被调用方 | 社区成果年鉴 | 输入：提供信用评级台账 | credit_ledger.json |
| 被调用方 | 获客分包平台 | 输入：提供SPV协议模板、三长老机制 | spv_protocol.md + governance.md |
| 被调用方 | SPAC资本路径规划 | 输入：提供SPV贡献权重数据 | contribution_weights.json |
| 输出方 | 全部下游Skill | 输出：合作协议、信用台账、治理机制 | 结构化JSON + Markdown |

---

*本Skill由胡田OPC导师体系提供，版本1.0*
*姊妹篇：「胡田-SPAC资本路径规划」— 专注项目孵化到资本化的完整路径*
*本Skill已完成Agent Harness嵌入，版本1.0+Harness v1.0*