Capability Pipeline OS（SkillHub）
Capability Pipeline OS（ClawHub）
Capability Pipeline OS - 通用能力管线操作系统
万物皆可单元化。任何领域的任何任务，都可以分解为可执行、可组合的能力单元，通过管线编排完成。6大元操作集群覆盖一切任务类型，领域差异通过推导规则自动适配。
触发词：能力单元、管线、Pipeline、任务分解、工作流、原子任务、单元化、编排、执行框架、能力管线、任务编排、流水线、自动编排、分解执行、元操作。
核心理念
万物皆可单元化。 任何任务------不论领域、不论复杂度------都可以分解为原子能力单元。单元是可独立执行、可自由组合的最小操作粒度。
单元即管线节点。 每个单元是管线中的一个节点，按依赖关系串联/并联/条件分支，形成完整的执行管线。
领域无关，方法通用。 6大元操作集群是领域无关的思维原语。领域差异不通过枚举覆盖，而通过推导规则自动适配。
负载物可替换。 产出 = 元操作 × 领域负载物。同一个"感知→认知→行动"管线，负载物是"市场数据"时产出商业洞察，负载物是"实验数据"时产出科学发现。
身份自适应叠加。 身份分两层：①元操作级身份（侦察者/分析师等），由元操作类型自动推导，服务于管线编排拓扑；②领域级身份（市场分析师/数据科学家等），附于名称字段括号中作为展示层视觉增强。两者正交不冲突------元操作管"做什么操作"，领域管"哪个领域"。身份本质是注意力偏置信号和人话翻译器，不是能力切换机制。
管线与IPO统一。 管线是IPO的P的具象化，IPO是管线的展开机制------两者是同一系统的两个视角。横向看是管线（6类型+6编排），纵向看是IPO递归（I→P→O），P递归展开时子级仍是管线结构，分形一致。
能力单元Schema
每个单元包含8个必选字段 + 2个可选字段：
必选字段
| 字段 | 说明 |
|---|---|
| 单元ID | {元操作代号}-{序号}，如 S-01、C-03、A-02 |
| 名称 | 单元功能的简明描述。格式：{功能描述}（{领域身份1}×{领域身份2}...），如 客户分级与定位（市场分析师×数据科学家）。括号内领域身份为展示层视觉增强，帮助人理解基元涉及的领域视角，对AI执行无实质影响（名称本身已足够锚定注意力） |
| 元操作 | S/C/A/O/I/G 之一，决定单元所属集群、管线拓扑位置和校准权重。同时推导元操作级身份（侦察者/分析师等）作为呈现层辅助 |
| 输入 | 启动所需的数据/上下文，标注必选/可选 |
| 输出 | 产物格式与颗粒度 |
| 依赖 | 前置必须完成的单元ID，无依赖=入口单元 |
| AI自治度 | ⬛全自动 / 🟨半自动(需人工确认) / ⬜辅助(人工主导) |
| 组合接口 | 输出可被哪些单元消费（→单元ID列表） |
可选字段
| 字段 | 说明 |
|---|---|
| 身份叠加 | 呈现层/叙事层字段。默认由元操作类型自动推导（主身份+辅助身份），特殊情况可手动指定。定位：注意力偏置信号+人话翻译器，不是能力切换机制。名称字段的领域身份括号已覆盖其呈现功能，本字段可视为元操作级身份（侦察者/分析师等）的备用呈现入口 |
| P实现 | LLM / 工具 / 技能 / 人机 / 组合，标注该单元P环节的实现方式 |
字段间逻辑关系：
单元ID ← 命名规范由元操作代号派生
元操作 → 决定管线拓扑位置 + 元操作级身份（呈现层辅助）
名称 → 携带领域级身份括号（展示层视觉增强，对执行无实质影响）
依赖 + 组合接口 → 构成管线的边（有向图）
P实现 → 单元内部P环节的执行方式，不改变I/O契约6大元操作集群
任何任务，无论领域，都可归入以下6大元操作之一或其组合。每个元操作是一个思维原语，不是固定功能------具体内容由领域负载物决定。
| 元操作 | 代号 | 本质 | 典型操作 |
|---|---|---|---|
| 感知 | S | 从环境中获取信息 | 采集、监测、扫描、检索、接收、观察 |
| 认知 | C | 对信息进行加工处理 | 分析、评估、推理、决策、规划、构思 |
| 行动 | A | 产生可观测的产出 | 生产、创造、执行、交付、实施、写作 |
| 组织 | O | 结构化管理和维护资源 | 存储、分类、索引、维护、更新、归档 |
| 交互 | I | 与外部主体建立关系 | 沟通、协调、谈判、协作、服务、汇报 |
| 守护 | G | 确保安全、合规、质量 | 验证、约束、保护、审计、纠偏、兜底 |
元操作间的流转关系
S(感知) → C(认知) → A(行动) → O(组织)
↑ |
+----------- 反馈环 -----------+
I(交互) 贯穿 S/C/A 全程 ------ 任何阶段都可能需要外部协作
G(守护) 贯穿 S/C/A/O 全程 ------ 任何阶段都可能需要约束和验证- 主链路：S → C → A → O 是任务的核心执行链
- 反馈环：O 的积累反哺 S 的感知质量
- 交互轴：I 横向贯穿，任何阶段都可能需要外部协作
- 守护轴：G 纵向贯穿，任何阶段都可能需要约束和验证
自适应身份叠加
身份分两层，正交不冲突：
① 元操作级身份（操作维度------做什么类型的操作）
由元操作类型自动推导，决定管线拓扑位置，同时作为呈现层辅助帮助人理解单元的操作类型：
| 元操作 | 执行身份 | 角色感 | 认知风格 |
|---|---|---|---|
| S 感知 | 侦察者 | 我去获取信息 | 开放、细致、穷举 |
| C 认知 | 分析师 | 我来解读判断 | 严谨、结构化、溯源 |
| A 行动 | 执行者 | 我来产出交付 | 务实、高效、闭环 |
| O 组织 | 管理者 | 我来维护归档 | 有序、一致、可检索 |
| I 交互 | 协调者 | 我来沟通对齐 | 共情、清晰、双向 |
| G 守护 | 守门人 | 我来验证兜底 | 严格、边界清晰、零容忍 |
② 领域级身份（领域维度------哪个领域的事）
附于名称字段括号中，格式如 客户分级与定位（市场分析师×数据科学家）。展示层视觉增强，给人"多智能体协作"的感觉。对AI执行无实质影响（名称本身已足够锚定注意力）。
两层关系矩阵：
感知(S) 认知(C) 行动(A) 组织(O)
市场 市场调研员 市场分析师 增长策略师 数据归档员
技术 技术侦察者 架构师 开发者 文档管理员
学术 文献采集员 研究综述者 论文撰写者 引用索引员- 横向（元操作级）：锚定动词/方法论层token（分析/推理/决策）
- 纵向（领域级）：锚定名词/对象层token（市场/定价/客户）
- 两层互补，零冲突
身份的真实定位：
- 身份不是能力切换机制，是注意力偏置信号 + 人话翻译器
- 名称字段（含领域身份括号）是最强的注意力锚点
- 元操作级身份在名称已精确描述任务时几乎冗余，保留用于呈现和管线编排辅助
多智能体协作层级（呈现层叙事）：
| 层级 | 结构 | 说明 |
|---|---|---|
| 单一身份 | 1个视角 | 最简单的原子操作 |
| 单元内多视角 | 2-4个身份并行 | 元操作主身份+领域身份+上下文辅助身份 |
| 管线级协作集群 | 4+身份流转 | 多个基元串联时，身份配置按拓扑动态呈现 |
身份叠加规则（呈现层面）：
- 元操作级主身份由元操作类型决定，领域级身份由任务领域推导写入名称括号
- 跨单元流转时，元操作级身份随元操作类型切换，领域级身份随任务内容变化
- 管线级别的身份呈现构成"多智能体协作"的视觉效果，实际执行由任务结构驱动
管线与IPO的统一结构
管线和IPO是同一系统的两个视角，不是两个独立机制：
横向视角（管线）：S-01 → C-01 → A-01 → G-01 → O-01 ← 单元间的编排
↓ ↓ ↓ ↓ ↓
纵向视角（IPO）：每个单元内部 = I → P → O ← 单元内的结构
↓
P递归展开 = 子管线（仍是6类型+6编排）
↓
子管线中每个单元 = I → P → O ← 继续递归统一本质：
- 管线是P的具象化------IPO说"P是处理过程"但没说P是什么结构。管线回答：P是一个由6种元操作按编排模式组合的子管线
- IPO是管线的展开机制------管线说"A-01是行动单元"但没说A-01内部怎么拆。IPO回答：A-01本身是I→P→O，P可以继续递归
- 分形一致性：每一层都是管线+IPO结构，横向有6类型+6编排，纵向有IPO递归，无限深度不换schema
递归规则：
- 简单单元：P是原子操作，不展开（递归终止）
- 复杂单元：P展开为子管线，子管线中的每个节点仍是S/C/A/O/I/G类型化单元
- 递归终止条件：P可直接执行，无需进一步分解
- 每一层的P展开都遵循相同的6类型+6编排规则
管线编排Schema
管线是单元按逻辑关系的有序组合。支持6种编排模式：
| 模式 | 符号 | 说明 | 示例 |
|---|---|---|---|
| 顺序 | → | A完成后执行B | S-01 → C-01 → A-01 |
| 并行 | ‖ | A和B同时执行 | S-01 ‖ S-02 → C-01 |
| 条件 | ? | 满足条件X执行A，否则B | C-01 ?(通过)→ A-01 : → C-02 |
| 循环 | ↻ | 重复执行A直到条件满足 | ↻(C-01 → A-01, 直到精度达标) |
| 扇出 | ⇉ | A的输出同时供给B/C/D | S-01 ⇉ [C-01, C-02, C-03] |
| 扇入 | ⇇ | B/C/D的输出汇总到E | [A-01, A-02, A-03] ⇇ O-01 |
任务分解方法
当用户提出任何任务时，按以下4步（Step 0判定 + Step 1-3分解编排）执行：
Step 0：复杂度判定
在分解之前，先判定任务复杂度，决定执行路径：
| 复杂度 | 判定标准 | 执行路径 |
|---|---|---|
| 简单 | 可直接完成，无需多步分解 | 单一IPO基元执行（I→P→O），不展开管线 |
| 中等 | 需要3-7个步骤协调 | 单层管线编排，无需递归展开 |
| 复杂 | 需要8+步骤或多层嵌套 | 多层管线+IPO递归展开 |
判定依据：任务涉及的元操作类型数、依赖关系复杂度、领域校准的深化方向。
简单任务快速通道：判定为简单的任务，直接以自适应身份叠加执行单一IPO基元，跳过Step 1-3。默认不展示IPO细节，用户可要求展示。
Step 1：领域识别与校准
识别任务所属领域，运用领域推导规则确定校准参数。
领域推导规则：
| 规则 | 领域特征 | 推导结果 |
|---|---|---|
| R1 信息密度 | 高信息密度领域（科研、金融、情报） | S和C权重高，G偏严格 |
| R2 创造性 | 高创造性领域（设计、写作、艺术） | A权重高，C偏发散，G偏宽松 |
| R3 交互性 | 高交互性领域（服务、教育、医疗） | I权重高，S偏人本，G偏伦理 |
| R4 规范性 | 高规范性领域（法律、认证、监管） | G权重高，O偏严格，自治度偏低 |
| R5 迭代性 | 高迭代性领域（软件、产品、实验） | 循环多，S→C→A链短而频 |
推导方法：给定领域，沿3个维度推导适配参数：
| 维度 | 推导内容 |
|---|---|
| 元操作侧重 | 该领域哪些元操作是核心驱动？权重如何分配？ |
| 评估侧重 | 该领域最看重什么？（准确性？创新性？安全性？效率？） |
| 深化方向 | 单元分解时在哪个元操作上需要更深粒度？ |
校准示例（非穷举，仅展示推导方法。遇到未列出的领域时，AI须根据推导规则自行适配，并向用户展示推导过程）：
| 领域 | 侧重元操作 | 评估侧重 | 深化方向 | 自治度偏好 |
|---|---|---|---|---|
| 商业运营 | S+C+A均衡 | 效率与ROI | C(分析决策) | 🟨半自动为主 |
| 学术研究 | S+C主导，A为写作 | 准确性与严谨 | S(文献)+C(论证) | 🟨半自动 |
| 软件开发 | C+A主导，循环多 | 正确性与可维护 | A(编码)+G(测试) | ⬛全自动+🟨审查 |
| 文学创作 | A主导，C为构思 | 创新性与感染力 | A(写作) | ⬜辅助 |
| 法律实务 | G+O主导 | 合规性与严谨 | G(合规)+O(文书) | 🟨半自动 |
| 医疗诊疗 | S(诊断)+C(判断)+G(安全) | 安全性与准确性 | S(问诊)+G(安全) | ⬜辅助 |
| 教育教学 | I+C为主 | 有效性与人本性 | I(教学互动) | 🟨半自动 |
| 个人生活 | 全均衡，简化 | 实用与便捷 | 简化为S→A短链 | ⬛全自动 |
| 工程项目 | A+O+G为主 | 安全与质量 | A(施工)+G(质检) | 🟨半自动 |
| 艺术创作 | A主导，S为灵感 | 创新性与表达力 | A(创作) | ⬜辅助 |
Step 2：任务→单元分解
将任务按元操作维度分解为原子单元：
- 识别任务边界：明确任务的起点（触发条件）和终点（交付标准）
- 沿主链路展开：从S→C→A→O逐层拆解，每层识别需要的原子操作
- 插入交互节点：在需要外部协作/确认处插入I类单元
- 插入守护节点：在需要验证/约束处插入G类单元
- 标注依赖和接口：明确单元间的数据流向和组合关系
单元命名规范 ：{元操作代号}-{序号}，如 S-01、C-03、A-02
分解粒度原则：
- 每个单元应是一个AI可独立执行的最小操作
- 如果一个单元需要多个不同类型的操作，继续拆分
- 如果一个单元的输出不被任何其他单元消费，考虑是否必要
- 目标粒度：3-15个单元/任务（少于3合并，多于15分层）
- 入口单元（无依赖）通常是S类或I类
- 终点单元通常是A类（交付）或O类（归档）
Step 3：管线编排
将分解后的单元按编排模式组装为管线：
- 主线顺序：沿S→C→A→O主链路建立顺序管线
- 并行优化：无依赖的单元标记为并行
- 条件分支：关键决策点设置条件分支
- 循环设计：需要迭代的环节设置循环
- 守护嵌入：在关键节点前嵌入G类验证单元
- 交互插入：在需要人工介入处插入I类确认单元
Step 4：执行与反馈
- 按管线顺序执行：遵循编排模式，依次或并行执行单元
- 依赖检查：每个单元执行前确认输入就绪，缺失则先执行依赖
- 输出传递：单元输出按组合接口传递给下游单元
- 偏差处理：执行结果偏离预期时，触发G类守护单元纠偏
- 管线优化：执行完成后复盘，优化单元粒度和管线编排
领域校准推导
本技能不预定义领域模板，而是通过推导规则自动适配任何领域。校准流程：
- 识别领域：从用户任务描述中提取领域关键词
- 应用推导规则：根据R1-R5判断领域特征
- 推导校准参数：元操作权重、评估侧重、深化方向、自治度偏好
- 展示推导过程：向用户展示推导逻辑，确认或修正
- 注入校准上下文：将推导结果注入后续所有单元执行
校准维度清单
| 维度 | 说明 | 示例 |
|---|---|---|
| 核心术语 | 该领域的10-15个关键概念 | 商业：GMV/ROI/ABP；学术：假设/变量/显著性 |
| 元操作权重 | S/C/A/O/I/G各占的比重 | 商业：S:C:A≈3:4:3；学术：S:C:A≈5:4:1 |
| 关键变量 | 该领域最核心的3-5个度量 | 商业：营收/利润/增长；学术：信度/效度/影响力 |
| 守护约束 | 该领域不可违反的底线规则 | 商业：合规/预算；学术：学术诚信/可重复性 |
| 产出格式 | 该领域标准的交付物格式 | 商业：方案/报告；学术：论文/综述 |
| 自治度偏好 | 整体偏全自动/半自动/辅助 | 商业：🟨半自动；创作：⬜辅助 |
通用管线模式库
以下为跨领域通用的管线模式。每个模式是一个可复用的编排骨架，负载物由领域决定。
P1 感知-决策-执行（基础闭环）
S-01(采集) → C-01(分析) → C-02(决策) → A-01(执行) → O-01(记录)适用：大多数标准任务的完整执行链。如商业市场分析、学术文献综述、软件需求分析。
P2 迭代精炼（螺旋上升）
↻(S-01 → C-01 → A-01 → G-01(质量检查), 直到达标) → O-01适用：需要多轮改进的任务。如写作精修、设计迭代、实验优化。
P3 并行感知-汇聚决策
[S-01 ‖ S-02 ‖ S-03] ⇇ C-01(综合分析) → C-02(决策) → A-01适用：需要多源信息汇聚的决策。如战略规划、投资决策、综合诊断。
P4 条件分支执行
S-01 → C-01(判断) ?(条件A)→ A-01 : ?(条件B)→ A-02 : → A-03适用：根据情况选择不同行动路径的任务。如故障处理、分诊分流、分类应对。
P5 交互驱动（人机协作）
S-01(采集) → I-01(确认需求) → C-01(规划) → I-02(方案确认) → A-01(执行) → I-03(反馈)适用：需要频繁人工确认的任务。如咨询服务、创意工作、教学设计。
P6 全守护（高安全）
G-01(前置验证) → S-01 → G-02(输入校验) → C-01 → G-03(逻辑审查) → A-01 → G-04(输出验证) → O-01适用：高安全性/合规性任务。如金融交易、医疗处置、法律文书、安全审计。
P7 创造发散-收敛
S-01(灵感采集) → C-01(发散构思) ⇉ [A-01, A-02, A-03](多方案) → C-02(收敛评估) → A-04(精炼交付)适用：需要创意产出的任务。如设计策划、广告创意、产品构思。
领域实例化演示
以下演示本技能在不同领域的实际分解过程。每个实例展示从任务描述到单元分解到管线编排的完整路径。
实例1：学术研究------撰写文献综述
领域校准：学术研究 → S:C:A权重≈5:4:1，评估侧重准确性，自治度🟨
| 单元ID | 名称 | 元操作 | 输入 | 输出 | 依赖 | 自治度 | 组合接口 |
|---|---|---|---|---|---|---|---|
| S-01 | 文献检索（文献研究员×数据库检索员） | S | 必选：研究主题；可选：数据库偏好 | 文献列表+摘要 | 无 | 🟨 | →S-02,→C-01 |
| S-02 | 文献筛选（文献筛选员×学术评审员） | S | 必选：S-01文献列表；可选：筛选标准 | 符合标准的文献集 | S-01 | 🟨 | →C-01 |
| C-01 | 主题归类与对比（主题分析师×比较研究专家） | C | 必选：S-02文献集 | 归类矩阵+对比表 | S-02 | ⬛ | →C-02 |
| C-02 | 研究脉络梳理（学术史学家×逻辑梳理员） | C | 必选：C-01归类结果 | 时间线+学派图 | C-01 | 🟨 | →A-01 |
| G-01 | 引用真实性核查（事实核查员×引用规范专家） | G | 必选：C-02梳理结果 | 核查报告 | C-02 | 🟨 | →A-01 |
| A-01 | 综述撰写（学术写作者×综述结构师） | A | 必选：C-02脉络+G-01核查 | 综述初稿 | C-02,G-01 | 🟨 | →G-02 |
| G-02 | 学术规范审查（学术编辑×格式规范员） | G | 必选：A-01综述稿 | 规范审查意见 | A-01 | ⬛ | →A-02 |
| A-02 | 修改定稿（学术编辑×精炼写作员） | A | 必选：A-01初稿+G-02意见 | 综述终稿 | A-01,G-02 | 🟨 | →O-01 |
| O-01 | 归档索引（档案管理员×引文索引员） | O | 必选：A-02终稿 | 归档记录+引用索引 | A-02 | ⬛ | --- |
管线：S-01 → S-02 → C-01 → C-02 ‖ G-01 → A-01 → G-02 → A-02 → O-01
实例2：软件开发------实现新功能
领域校准：软件开发 → C:A权重≈3:5，评估侧重正确性，循环多，自治度⬛+🟨
| 单元ID | 名称 | 元操作 | 输入 | 输出 | 依赖 | 自治度 | 组合接口 |
|---|---|---|---|---|---|---|---|
| S-01 | 需求理解（产品分析师×需求工程师） | S | 必选：需求描述 | 结构化需求文档 | 无 | 🟨 | →C-01 |
| C-01 | 技术方案设计（系统架构师×技术设计师） | C | 必选：S-01需求文档 | 技术方案 | S-01 | 🟨 | →I-01 |
| I-01 | 方案评审确认（技术评审员×项目经理） | I | 必选：C-01技术方案 | 评审结论 | C-01 | 🟨 | →A-01 |
| A-01 | 编码实现（软件工程师×全栈开发者） | A | 必选：C-01方案+I-01确认 | 代码文件 | I-01 | ⬛ | →G-01 |
| G-01 | 单元测试（测试工程师×QA专家） | G | 必选：A-01代码 | 测试报告 | A-01 | ⬛ | →A-02 |
| A-02 | Bug修复（调试工程师×代码维护员） | A | 必选：G-01测试报告 | 修复后代码 | G-01 | ⬛ | →G-02 |
| G-02 | 集成验证（集成测试工程师×CI/CD专家） | G | 必选：A-02修复后代码 | 集成测试报告 | A-02 | ⬛ | →O-01 |
| O-01 | 文档与归档（技术文档员×知识管理者） | O | 必选：A-02代码+G-02报告 | 完整交付包 | G-02 | 🟨 | --- |
管线：S-01 → C-01 → I-01 → ↻(A-01 → G-01 → A-02, 直到G-01通过) → G-02 → O-01
实例3：个人生活------规划旅行
领域校准：个人生活 → 全均衡简化，评估侧重实用，自治度⬛
| 单元ID | 名称 | 元操作 | 输入 | 输出 | 依赖 | 自治度 | 组合接口 |
|---|---|---|---|---|---|---|---|
| S-01 | 目的地信息采集（旅游研究员×目的地侦察员） | S | 必选：目的地；可选：偏好 | 目的地概览 | 无 | ⬛ | →C-01 |
| C-01 | 行程规划（行程规划师×路线设计师） | C | 必选：S-01信息；可选：预算/时间 | 行程草案 | S-01 | 🟨 | →I-01 |
| I-01 | 偏好确认（旅行顾问×用户体验员） | I | 必选：C-01行程草案 | 确认行程 | C-01 | 🟨 | →A-01 |
| A-01 | 预订执行（预订专员×在线操作员） | A | 必选：I-01确认行程 | 预订确认单 | I-01 | 🟨 | →O-01 |
| G-01 | 安全检查（风险评估员×安全顾问） | G | 必选：A-01预订结果 | 安全清单 | A-01 | ⬛ | →O-01 |
| O-01 | 行程归档（旅行记录员×档案整理员） | O | 必选：A-01确认单+G-01安全清单 | 旅行手册 | A-01,G-01 | ⬛ | --- |
管线：S-01 → C-01 → I-01 → A-01 → G-01 → O-01
实例4：商业运营------新品上市
领域校准：商业运营 → S:C:A均衡，评估侧重效率与ROI，自治度🟨
| 单元ID | 名称 | 元操作 | 输入 | 输出 | 依赖 | 自治度 | 组合接口 |
|---|---|---|---|---|---|---|---|
| S-01 | 市场数据收集（市场研究员×数据采集员） | S | 必选：行业/品类；可选：数据源 | 市场数据报告 | 无 | 🟨 | →C-01 |
| C-01 | 业务计划制定（商业策划师×战略规划员） | C | 必选：S-01市场数据；可选：业务目标 | ABP文档 | S-01 | 🟨 | →C-02 |
| C-02 | 客户分级与定位（市场分析师×数据科学家） | C | 必选：C-01业务计划 | 客户分级矩阵 | C-01 | 🟨 | →A-01 |
| A-01 | 核心信息架构（信息架构师×品牌策略师） | A | 必选：C-02客户分级 | Message House | C-02 | 🟨 | →A-02 |
| A-02 | 内容故事线设计（内容策略师×叙事设计师） | A | 必选：A-01信息架构 | 内容故事线文档 | A-01 | 🟨 | →A-03 |
| A-03 | 上市活动策划（活动策划师×营销创意人） | A | 必选：A-02故事线 | 活动方案 | A-02 | 🟨 | →G-01 |
| G-01 | 推广材料审核（合规审查员×品牌质检员） | G | 必选：A-03活动方案 | 审核意见 | A-03 | 🟨 | →A-04 |
| A-04 | 活动执行（活动执行经理×现场协调员） | A | 必选：A-03方案+G-01审核 | 执行记录 | G-01 | 🟨 | →C-03 |
| C-03 | 效果数据分析（数据分析师×效果度量员） | C | 必选：A-04执行记录 | 效果数据报告 | A-04 | ⬛ | →C-04 |
| C-04 | 效果评估（ROI分析师×业务评估员） | C | 必选：C-03效果数据 | 评估结论 | C-03 | 🟨 | →O-01 |
| O-01 | 项目归档（项目档案员×知识管理者） | O | 必选：C-04评估结论 | 项目档案 | C-04 | ⬛ | --- |
管线：S-01 → C-01 → C-02 → A-01 → A-02 → A-03 → G-01 → A-04 → C-03 → C-04 → O-01
执行规则
- 领域校准优先：首次使用时，识别用户所属领域，按推导规则完成校准，将领域特定知识注入后续所有单元执行
- 复杂度分叉：简单任务走IPO基元快速通道，中/复杂任务走管线编排路径
- 动态分解：根据任务实际结构分解单元，不强套模板
- 依赖检查：执行前确认依赖单元的输出已就绪，缺失则先执行依赖
- 自由组合：无依赖冲突的单元可并行；有依赖的按序执行
- 跨元操作流转：一个单元的输出可作为另一元操作集群单元的输入
- 管线复用：通用管线模式可直接使用或按需调整
- 反馈闭环：执行完成后O类单元的产出可反哺S类单元，形成持续优化循环
工具调用策略
单元执行时，P（处理）的实现方式按需选择：
| 实现方式 | 适用场景 | 示例 |
|---|---|---|
| LLM直接完成 | 文本生成、分析推理、方案设计 | 综述撰写、SWOT分析、创意构思 |
| 调用工具 | 需要外部数据或操作 | Web搜索获取信息、文件读写、代码执行 |
| 加载技能 | 领域专业工作流 | PDF处理、表格操作、浏览器自动化 |
| 人机协作 | 需要人工判断或确认 | 方案评审、创意定稿、风险决策 |
策略规则：
- 按需选用，不预设LLM-only或工具优先的立场
- 工具/技能在管线中作为P的实现方式纳入，不改变单元的I/O契约
- 加载技能时，技能成为当前单元的执行能力扩展
- 调用工具时，工具调用是P的内部实现细节，对外仍呈现为单元的标准输出
- 多种实现可组合：LLM生成草稿 → 工具格式化 → 人工确认 → 输出
呈现规则
| 场景 | 默认呈现 | 用户可请求展开 |
|---|---|---|
| 简单任务 | 直接展示结果 | IPO内部结构 |
| 中等任务 | 管线概览 + 各单元产出 | 单元内部IPO展开、依赖关系图 |
| 复杂任务 | 管线概览 + 关键节点产出 | 任意层级的IPO递归展开、完整依赖图 |
| 领域校准 | 校准结论 | 推导过程和依据 |
| 工具调用 | 调用结果 | 调用细节和中间状态 |
规则：默认展示最少必要信息让用户理解结果，用户说"展开""详细""怎么做的"时逐层揭示内部细节。
事实纪律
执行本技能时，AI必须遵守：
- 仅使用确知的事实和可验证的信息，不得编造数据或引用
- 领域校准推导须向用户展示推导过程和依据
- 单元分解须基于任务本身的结构，不得强行套用模板
- 管线编排须尊重任务的自然依赖关系，不得人为制造冗余节点
- 守护单元的约束条件须来自领域实际规则，不得凭空设定
- 单元输出格式须匹配下游单元的输入要求，确保组合接口可用