认知画像提取工作流

术-内容 · 术层 skill 全文

本页是 <code>rules/skills/workflow_cognitive_profile_extraction.md</code> 的逐字投影（仅隐私清洗，零改写）。

认知画像提取工作流

元数据

• 类型: Workflow
• 适用场景: 从非结构化对话数据（群聊、Slack、Discord、邮件、播客转录等）中提取可预测的认知画像
• 产出: 一组"公理"——可用于预测目标人物在新话题上的反应方向、论辩姿态和修辞手段的条件触发规则
• 依赖: 并行 Subagent 工作流、深度调研工作流
• 创建日期: 2026-03-13
• 来源: 示例观察项目（8139 条微信消息 → 15 条公理，预测力回测 89%）

模型 Guardrail

执行前检查：确认当前模型 ID 是否包含 opus。

• 是 Opus → 继续。你的 context window 极其宝贵，你的核心能力是设计、质量把关和写作。所有调研、数据处理、代码编写一律 delegate 给 sub-agent，且默认并行。写作——包括公理文本、索引、最终报告——必须由你亲自完成，不得外包。
• 不是 Opus → 暂停，问用户：

核心原则

1. 并行 + Delegation 是第一原则

Opus 的 context window 是稀缺资源，不应被扫描和检索消耗。工作流分工：

Sub-agent 调度遵循 并行 Subagent 工作流 的规则：并行度 ≤5，调研 overlap 30-50%，run_in_background=true。

本表的 Plan / Execute / Write / QA 四角色分工的核心纪律是整合产物由 Opus 自己写，不 delegate 最终写作；本 skill 是该分工在"认知画像提取"场景下的具体实例化。

2. 写作不 delegate（硬约束）

所有面向最终产出的文本——公理定义、索引、方法论报告——必须由 Opus 亲自撰写。理由：

• 公理之间的概念一致性（同一现象在不同公理里的措辞不能互相矛盾）
• 交叉引用的精确性（V05 引用 V07 的张力描述必须两边对齐）
• 文风统一（15 条公理读起来像同一个人写的，不像 5 个 agent 拼的）

Sub-agent 产出的是原始调研材料，不是终稿的任何一部分。

3. 迭代轮次动态滚动

最低下限：3 轮（广泛扫描 + 深度验证 + 至少一轮压力测试/定稿）。

上限不设，但每轮开始前必须评估是否继续（见"收敛判断标准"）。实测经验：3-4 轮是常见收敛点，超过 5 轮边际递减明显，且有过拟合风险。

4. 公理是条件触发规则，不是绝对律条

每条公理都应有反例和边界条件。一条没有反例的公理要么太泛（"他关注 AI"），要么证据不足（看起来完美只是因为没认真找反例）。

工作流

Phase 0: 数据准备

目标：把原始数据转化为可检索的目标人物消息集合。

输入要求：

• 目标人物的文本消息集合
• 最好带时间戳（必要：用于时间演化分析）
• 最好带来源标签——群名/频道名/对话类型（必要：用于跨源对比）
• 可选：带上下文的版本（每条消息附前后 N 条他人发言，用于理解互动模式）

预处理步骤（delegate 给 sub-agent）：

1. 从原始格式提取目标人物消息（用 ID 而非显示名过滤——显示名可能跨群变化）
2. 产出统计摘要：总消息数、时间跨度、各来源的消息分布
3. 如果有多个对话源，产出带上下文的版本

规模评估 → 决定验证档位：

语义搜索准备（推荐）：如果数据量 ≥ 1000 条，建议在此阶段构建 embedding cache（见 语义搜索技能）。将消息按条拆成独立文本文件或 chunk，运行一次 embedding 建缓存。后续 Phase 1/2 的 sub-agent 可以用语义搜索替代纯关键词 grep——语义搜索能找到"关键词不同但意思相近"的消息，对发现隐含观点和边界案例尤其有价值。

Phase 0 产出：数据概况报告、验证档位决定、初步的维度假设、embedding cache（如适用）。

Phase 1: 广泛扫描（R0）

目标：从五个正交维度并行扫描，产出候选公理池。

Opus 做的事（Plan）：

1. 确定 5 个扫描维度——建议的默认维度：

1. 为每个 sub-agent 写 prompt，明确：搜索范围、输出格式（时间戳 + 来源 + 原文 + 候选公理）、允许的 overlap 范围
2. 并行派出 5 个 sub-agent（run_in_background=true）

Sub-agent 做的事（Execute）：

• 扫描全部数据，按分配维度提取模式
• 每个维度产出 3-5 个候选公理，每个附 3+ 条带时间戳的证据
• 标注跨维度发现（供交叉验证用）

Opus 做的事（Consolidate）：

1. 收集 5 个 sub-agent 的结果
2. 合并重叠的候选公理（合并标准：底层判断相同，而非表述相似）
3. 拆分过泛的候选公理
4. 产出候选公理清单（预计 12-20 个候选）和初步综合分析

Phase 2: 深度验证（R1）

目标：验证候选公理的稳定性、独特性和边界条件。

Opus 做的事（Plan）：

1. 设计 5 个验证任务——建议的默认配置：

1. 关键去重约束：告知每个 sub-agent"前一轮已引用的证据不要重复"——这一条对报告质量提升最大
2. 并行派出 5 个 sub-agent

Sub-agent 做的事（Execute）：

• 按分配任务做深度验证
• 每条候选公理给出可信度评分（1-10）、反例列表、边界条件建议

Opus 做的事（Consolidate）：

1. 交叉验证各 sub-agent 的发现
2. 为每条候选公理更新可信度、添加边界条件
3. 淘汰可信度过低的候选（建议阈值：< 6.0）
4. 判断收敛：是否需要继续到 Phase 3？

Phase 3: 压力测试（R2）

适用条件：标准版及以上（数据 ≥ 500 条）。

目标：主动攻击公理的弱点，测试整体框架的预测力。

Opus 做的事（Plan）：设计 3-5 个压力测试任务。核心三件事：

3a. 互斥性检验

检查公理之间是否存在逻辑矛盾。

操作：把公理按相关性分组（每组 3-4 条），让 sub-agent 检查组内是否有互斥关系。互斥不一定要消除——可以用"描述性 vs 规范性"、"默认模式 vs 边界模式"等分层解释来吸收。但需要标注冲突等级（1-10）。

3b. 反例狩猎

明确要求 sub-agent 主动寻找反驳公理的消息。

操作：每条公理至少找 2 条反例，给每条反例打破坏力分数（1-10）。反例不是公理失败的信号——能被边界条件吸收的反例反而让公理更精确。

3c. 预测力回测（完整版）

测试公理组合作为预测器的效果。

操作（严格顺序）：

1. 设计 5-10 个假设话题（覆盖不同公理组合）
2. 在不检索原始数据的前提下，用公理做先验预测：立场方向、论辩策略、可能的类比/短句
3. 检索原始数据，寻找语义相近的真实对话
4. 对比预测与实际的一致性，打分

改进版回测协议（可选，更可信但更贵）：

• 话题从真实数据中随机采样，而非 agent 自选
• 用一个没有参与公理制定的独立 agent 做一致性评判
• 预测信心和一致性分开评分

已知局限（必须在报告中披露）：

• 小样本（5-10 个话题）统计结论不稳健
• LLM 评判 LLM 预测存在系统性偏差
• 连续量表（如 89%）和二值量表（如 60%）差异大，建议同时报告两个数字

Opus 做的事（Consolidate）：

1. 根据压力测试结果修订每条公理的边界条件和可信度
2. 标注公理间的关系图（闭环、张力、正交关系）
3. 判断收敛：是否需要额外轮次？

Phase 4+: 定稿（R3+）

目标：Opus 亲自撰写全部公理文本。

硬约束：这个 Phase 不 delegate。所有公理文本由 Opus 一个人写。

公理文件模板：

# 编号 标题

## 核心表述
一句话，可独立引用。

## 展开
2-3 段落。解释逻辑链，说明与其他公理的关系。

## 边界条件
什么场景下弱化或不适用。包括 R2 发现的反例和张力。

## 代表性证据
带时间戳和来源的原始发言（3-5 条）。

## 跨源表现
同一观点在不同来源的表达差异。

## 可信度
1-10 评分，附简要理由。

风格类公理额外字段：

• 适用范围/默认模式：说明风格公理在什么语境下激活、什么语境下切换

索引文件：

• 所有公理的速查表（编号、标题、核心表述、可信度）
• 公理间关系图（闭环、张力、正交）
• 压力测试关键发现摘要

如果压力测试反馈需要大幅修订（不只是边界条件微调），则增加一轮 R3→R4：修订后再跑一轮简化压力测试验证修订效果，然后定稿。

Phase 5: 发布为 Web 站点（仅用户明确要求时执行）

不要主动发布。 定稿即完成。只有用户明确说"发布"、"上线"、"给我链接"时才进入此阶段。

基础转换流程见 分享报告到 Web，以下是多页公理站点的额外经验：

结构：索引页（index.html）+ 每条公理一个子页面。索引页用表格列出全部公理（编号、标题、核心表述、可信度），每行标题是指向子页面的超链接。每个子页面顶部加"← 返回索引"导航链接。

实操要点：

1. 先在 Markdown 源文件里加好页间链接（V01（V01_xxx.html）），pandoc 转换时链接自动保留
2. 每个 HTML 文件独立自包含（CSS 用 --embed-resources 内嵌），不依赖外部样式表——这样单独打开任何子页面都能正常显示
3. 用 rsync 整个文件夹上传，而非逐文件传——保证目录结构和链接一致
4. 上传后用 curl 验证索引页和至少 2 个子页面的 HTTP 200

delegate 规则：HTML 转换和上传可以 delegate 给 sub-agent，但索引页的 Markdown 源文件（公理间关系图、摘要文字）由 Opus 亲自写——这是写作，不是机械转换。

收敛判断标准

每轮结束后，评估以下四个信号：

四个信号中满足 3 个即可收敛。 满足 2 个时，建议再做一轮轻量验证确认。

过度迭代的风险：超过 4-5 轮后，每轮修订容易把公理从"可泛化的认知模式"磨成"训练数据的精确拟合"。宁可保留一些粗糙度，也不要过拟合。

公理设计标准

一条好的公理应满足：

1. 持久性：跨时间段、跨话题反复出现，不是一次性的表态
2. 独特性：是目标人物特有的，而非大多数人都会说的通识
3. 预测性：可以用来预测他在新话题上的立场和表达方式
4. 具体性：有多条原始发言作为证据，且证据来自多个独立时间点
5. 非冗余：公理之间不重叠，各自覆盖不同侧面
6. 有边界：标注在什么场景下弱化或不适用

公理类型：建议分两类——

• 观点类：定义"他会站什么立场"
• 风格类：定义"他会怎么表达"

合并 vs 拆分的判断：底层判断相同 → 合并（即使表述不同）；底层逻辑正交 → 保留为独立公理（即使领域接近）。

方法论心得

以下经验从示例项目提炼，适用于所有认知画像提取任务：

1. 预测力是终极验证标准

证据数量和可信度评分是中间指标。最终判断公理是否成立的标准是能不能用它预测新话题上的反应。

2. 反例比正例更有价值

主动寻找反例、量化破坏力、用边界条件吸收反例——这个过程比堆积正面证据有用得多。没有经过反例压力测试的公理只是观察，经过了才是公理。

3. 公理应锚定在稳定的判断层级上

当目标人物自己开始质疑某个具体方法但坚持上位概念时，公理应锚定在上位概念。例如：锚定"验证是控制面"而非"TDD 是控制面"——前者能吸收方法论漂移，后者会被新数据击穿。

4. 跨源对比区分"真实观点"和"社交表演"

同一个人在不同场景的表达差异揭示了哪些是底层信念、哪些是受众适配。如果一个观点只在一个来源出现，它可能是场景产物；如果跨源方向一致但表达不同，更可能是真实立场。

5. 时间序列区分"信念"和"表态"

没有时间维度就无法区分稳定观点和一时兴起。观点的时间演化本身就是公理的一部分——记录转折点和演化轨迹。

6. 情绪偏离需要量化

当发现目标人物在某些场景会偏离公理预测时，量化偏离率（如"严格口径 2%，综合破坏 6.5/10"），而非模糊地说"有时候会偏离"。

7. 去重约束对 sub-agent 质量提升最大

告知 sub-agent"前一轮已引用的证据不要重复"——这一条简单约束能显著减少冗余，迫使 agent 去找新证据。

8. 风格公理是默认策略簇

目标人物通常具有受众自适应能力。风格公理描述的是默认高频模式，不代表唯一模式。公理文本需要明确标注激活条件和模式切换场景。

9. 收敛信号 > 固定轮次

不要预设"做 N 轮"，而是监控收敛信号。过度迭代有两个成本：context window 消耗，和过拟合。

陷阱与对策

规模与成本参考

每轮 5 个并行 sub-agent 是默认配置。根据数据量和维度复杂度可调整为 3-7 个。

参见

• 语义搜索技能 — 超越关键词匹配，用 embedding 相似度发现语义相关的消息
• 并行 Subagent 工作流 — Sub-agent 调度的执行规则
• 深度调研工作流 — 多 agent 并行 + 交叉验证的基础架构
• 多 Agent 并行分析 — 50% overlap、交叉验证方法论
• 示例观察项目（本 skill 的原始来源）— contexts/people/magong/

变更日志