القائمة
从非结构化对话数据中提取可预测的认知画像与公理
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 抽象泛化 |