Menú
从非结构化对话数据中提取可预测的认知画像与公理
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
LLM Wiki vault 操作手册。 触发条件： - /ingest <path> — 当用户说「ingest」「把这篇文章加入 wiki」「编译到 wiki」「摄取」时触发 - /query <question> — 当用户说「搜索 wiki」「wiki 中有没有」「查一下 wiki」时触发 - /lint — 当用户说「检查 wiki」「wiki 健康度」「lint」「有没有断链」时触发 - /research <topic> — 当用户说「研究一下」「深度调研」「research」时触发
Use when the user wants to brainstorm an idea or design a feature/spec. Explores intent and requirements through dialogue, then writes a spec document to contexts/thought_review/ and STOPS. Does not auto-chain to implementation planning or any other skill.
结构稳定性分析器。不判断观点对错，只判断一件事：这个结构能不能活下去。 对任意观点、系统、模型、制度、人物言论进行五维结构稳定性分析， 输出存活概率和失效路径。当用户说「分析这个结构」「这个观点稳不稳」 「帮我拆一下」「结构分析」时触发。
AI 辅助开发中遇到“代码改不好”时的诊断思路与决策树
AI 产品设计、交互设计与系统架构中的关键原则与常见陷阱
AI 辅助编程与 Agent 系统设计的核心方法论和判断原则
| name | workflow-cognitive-profile-extraction |
| description | 从非结构化对话数据中提取可预测的认知画像与公理 |
执行前检查：确认当前模型 ID 是否包含 opus。
是 Opus → 继续。你的 context window 极其宝贵，你的核心能力是设计、质量把关和写作。所有调研、数据处理、代码编写一律 delegate 给 sub-agent，且默认并行。写作——包括公理文本、索引、最终报告——必须由你亲自完成，不得外包。
不是 Opus → 暂停，问用户：
"这个工作流设计为由 Opus 执行——Opus 的 context window 和写作能力是流程核心假设。你当前使用的模型不是 Opus，是否确认要继续？如果是误选模型，建议切换到 Opus 再开始。"
Opus 的 context window 是稀缺资源，不应被扫描和检索消耗。工作流分工：
| 角色 | 谁做 | 说明 |
|---|---|---|
| Plan（设计） | Opus 主 agent | 每轮迭代的调研计划、维度划分、任务边界 |
| Execute（调研） | Sub-agent（并行） | 数据扫描、关键词检索、反例狩猎、统计分析 |
| Write（写作） | Opus 主 agent | 公理文本、索引、报告——概念一致性和文风统一只能由一个 agent 保证 |
| QA（质量把关） | Opus 主 agent | 交叉验证 sub-agent 结果、发现矛盾、判断收敛 |
Sub-agent 调度遵循 并行 Subagent 工作流 的规则：并行度 ≤5，调研 overlap 30-50%，run_in_background=true。
所有面向最终产出的文本——公理定义、索引、方法论报告——必须由 Opus 亲自撰写。理由：
Sub-agent 产出的是原始调研材料，不是终稿的任何一部分。
最低下限：3 轮（广泛扫描 + 深度验证 + 至少一轮压力测试/定稿）。
上限不设，但每轮开始前必须评估是否继续（见"收敛判断标准"）。实测经验：3-4 轮是常见收敛点，超过 5 轮边际递减明显，且有过拟合风险。
每条公理都应有反例和边界条件。一条没有反例的公理要么太泛（"他关注 AI"），要么证据不足（看起来完美只是因为没认真找反例）。
目标：把原始数据转化为可检索的目标人物消息集合。
输入要求：
预处理步骤（delegate 给 sub-agent）：
规模评估 → 决定验证档位：
| 数据规模 | 推荐公理数 | 验证档位 | 说明 |
|---|---|---|---|
| < 500 条 | 3-5 条 | 轻量版 | 数据稀疏，跳过压力测试 |
| 500-2000 条 | 5-8 条 | 标准版 | 简化压力测试（互斥性 + 反例，跳过预测回测） |
| 2000-5000 条 | 8-12 条 | 标准版+ | 可做简化预测回测（3 个话题） |
| 5000+ 条 | 10-15 条 | 完整版 | 全部三层验证，含预测力回测（5+ 个话题） |
语义搜索准备（推荐）：如果数据量 ≥ 1000 条，建议在此阶段构建 embedding cache（见 语义搜索技能）。将消息按条拆成独立文本文件或 chunk，运行一次 embedding 建缓存。后续 Phase 1/2 的 sub-agent 可以用语义搜索替代纯关键词 grep——语义搜索能找到"关键词不同但意思相近"的消息，对发现隐含观点和边界案例尤其有价值。
Phase 0 产出：数据概况报告、验证档位决定、初步的维度假设、embedding cache（如适用）。
目标：从五个正交维度并行扫描，产出候选公理池。
Opus 做的事（Plan）：
| 维度 | 关注点 | 典型关键词 |
|---|---|---|
| 专业领域观点 | 目标人物的专业领域（技术、商业、学术等）核心判断 | 因领域而异 |
| 方法论偏好 | 如何做事、如何决策、如何评估 | 流程、标准、方法、原则 |
| 价值观与立场 | 社会议题、伦理判断、制度偏好 | 公平、效率、应该、不应该 |
| 论辩风格 | 怎么反驳、怎么说服、怎么让步 | 反驳标记词、让步标记词 |
| 语言与表达模式 | 句式偏好、类比习惯、情绪标记 | 高频短语、标点用法 |
run_in_background=true）Sub-agent 做的事（Execute）：
Opus 做的事（Consolidate）：
目标：验证候选公理的稳定性、独特性和边界条件。
Opus 做的事（Plan）：
| 任务 | 目标 | 方法 |
|---|---|---|
| 核心验证 | 可信度最高的 3-5 条候选，深挖证据链 | 穷举式搜索相关消息 |
| 跨源对比 | 同一观点在不同来源的表现差异 | 按来源分组对比 |
| 遗漏补充 | R0 可能遗漏的话题或模式 | 开放式扫描 R0 未覆盖的关键词 |
| 风格验证 | 论辩风格和语言模式的一致性 | 标记词频率统计 + 模式匹配 |
| 时间序列 | 观点的时间稳定性和演化轨迹 | 按月/季度分组，标注转折点 |
Sub-agent 做的事（Execute）：
Opus 做的事（Consolidate）：
适用条件：标准版及以上（数据 ≥ 500 条）。
目标：主动攻击公理的弱点，测试整体框架的预测力。
Opus 做的事（Plan）：设计 3-5 个压力测试任务。核心三件事：
检查公理之间是否存在逻辑矛盾。
操作：把公理按相关性分组（每组 3-4 条），让 sub-agent 检查组内是否有互斥关系。互斥不一定要消除——可以用"描述性 vs 规范性"、"默认模式 vs 边界模式"等分层解释来吸收。但需要标注冲突等级（1-10）。
明确要求 sub-agent 主动寻找反驳公理的消息。
操作：每条公理至少找 2 条反例，给每条反例打破坏力分数（1-10）。反例不是公理失败的信号——能被边界条件吸收的反例反而让公理更精确。
测试公理组合作为预测器的效果。
操作（严格顺序）：
改进版回测协议（可选，更可信但更贵）：
已知局限（必须在报告中披露）：
Opus 做的事（Consolidate）：
目标：Opus 亲自撰写全部公理文本。
硬约束：这个 Phase 不 delegate。所有公理文本由 Opus 一个人写。
公理文件模板：
# 编号 标题
## 核心表述
一句话，可独立引用。
## 展开
2-3 段落。解释逻辑链，说明与其他公理的关系。
## 边界条件
什么场景下弱化或不适用。包括 R2 发现的反例和张力。
## 代表性证据
带时间戳和来源的原始发言（3-5 条）。
## 跨源表现
同一观点在不同来源的表达差异。
## 可信度
1-10 评分，附简要理由。
风格类公理额外字段：
索引文件：
如果压力测试反馈需要大幅修订（不只是边界条件微调），则增加一轮 R3→R4：修订后再跑一轮简化压力测试验证修订效果，然后定稿。
不要主动发布。 定稿即完成。只有用户明确说"发布"、"上线"、"给我链接"时才进入此阶段。
基础转换流程见 分享报告到 Web，以下是多页公理站点的额外经验：
结构：索引页（index.html）+ 每条公理一个子页面。索引页用表格列出全部公理（编号、标题、核心表述、可信度），每行标题是指向子页面的超链接。每个子页面顶部加"← 返回索引"导航链接。
实操要点：
[V01](V01_xxx.html)），pandoc 转换时链接自动保留--embed-resources 内嵌），不依赖外部样式表——这样单独打开任何子页面都能正常显示delegate 规则：HTML 转换和上传可以 delegate 给 sub-agent，但索引页的 Markdown 源文件（公理间关系图、摘要文字）由 Opus 亲自写——这是写作，不是机械转换。
每轮结束后，评估以下四个信号：
| 信号 | 含义 |
|---|---|
| 修改指令可直接执行 | 不需要更多数据就能修订 → 可以收敛 |
| 预测力达到可用水平 | 连续口径 ≥ 80% → 框架已捕捉核心结构 |
| 反例类型开始重复 | 新一轮找到的反例跟之前类型相同 → 边际递减 |
| 公理间关系已稳定 | 不再需要新增、合并或大幅重组 → 结构收敛 |
四个信号中满足 3 个即可收敛。 满足 2 个时，建议再做一轮轻量验证确认。
过度迭代的风险：超过 4-5 轮后，每轮修订容易把公理从"可泛化的认知模式"磨成"训练数据的精确拟合"。宁可保留一些粗糙度，也不要过拟合。
一条好的公理应满足：
公理类型：建议分两类——
合并 vs 拆分的判断：底层判断相同 → 合并（即使表述不同）；底层逻辑正交 → 保留为独立公理（即使领域接近）。
以下经验从示例项目提炼，适用于所有认知画像提取任务：
证据数量和可信度评分是中间指标。最终判断公理是否成立的标准是能不能用它预测新话题上的反应。
主动寻找反例、量化破坏力、用边界条件吸收反例——这个过程比堆积正面证据有用得多。没有经过反例压力测试的公理只是观察，经过了才是公理。
当目标人物自己开始质疑某个具体方法但坚持上位概念时，公理应锚定在上位概念。例如：锚定"验证是控制面"而非"TDD 是控制面"——前者能吸收方法论漂移，后者会被新数据击穿。
同一个人在不同场景的表达差异揭示了哪些是底层信念、哪些是受众适配。如果一个观点只在一个来源出现，它可能是场景产物；如果跨源方向一致但表达不同，更可能是真实立场。
没有时间维度就无法区分稳定观点和一时兴起。观点的时间演化本身就是公理的一部分——记录转折点和演化轨迹。
当发现目标人物在某些场景会偏离公理预测时，量化偏离率（如"严格口径 2%，综合破坏 6.5/10"），而非模糊地说"有时候会偏离"。
告知 sub-agent"前一轮已引用的证据不要重复"——这一条简单约束能显著减少冗余，迫使 agent 去找新证据。
目标人物通常具有受众自适应能力。风格公理描述的是默认高频模式，不代表唯一模式。公理文本需要明确标注激活条件和模式切换场景。
不要预设"做 N 轮"，而是监控收敛信号。过度迭代有两个成本：context window 消耗，和过拟合。
| 陷阱 | 对策 |
|---|---|
| 公理太泛（"他关注 AI"） | 追问：这条能预测什么具体行为？不能 → 不是公理 |
| 公理太窄（"他反对 TDD"） | 提升到上位概念层级 |
| 证据选择偏差（只找支持的） | R2 反例狩猎强制对冲 |
| 跨公理概念不一致 | 写作不 delegate，一个人通稿 |
| 把转发内容当作本人观点 | 区分"转发行为"和"对转发内容的立场表达" |
| 把社交场景表态当稳定信念 | 跨源对比 + 时间序列验证 |
| 预测回测虚高 | 同时报告连续量表和二值量表，披露评判者局限 |
| 过度迭代导致过拟合 | 监控收敛信号，≥3 个信号满足即停 |
| Sub-agent 调研深度不够 | Prompt 中明确要求原文摘录 + 时间戳，不接受纯总结 |
| Context window 被调研消耗 | 严守 Plan/Write 自己做、Execute 全 delegate 的分工 |
| 数据规模 | Sub-agent 总调用数 | 预估轮次 |
|---|---|---|
| < 500 条 | 10-12 | 2-3 轮 |
| 500-2000 条 | 12-15 | 3 轮 |
| 2000-5000 条 | 15-20 | 3-4 轮 |
| 5000+ 条 | 18-25 | 3-5 轮 |
每轮 5 个并行 sub-agent 是默认配置。根据数据量和维度复杂度可调整为 3-7 个。
contexts/people/magong/| 日期 | 变更 |
|---|---|
| 2026-03-13 | 初始版本，从示例观察项目 methodology.md 抽象泛化 |