Llm Wiki Setup

LLM Wiki Setup（投研第二大脑共创）

帮用户搭一个金融投研专用 LLM Wiki（Karpathy 模式）：纯 markdown 文件 + [[wikilink]] 互联 + LLM 维护，知识随用复利。

但核心不是给一份投研模板——是引导用户把他自己的投资判断方式，提炼成他专属的 CLAUDE.md。

★ 先读这一条（这个 skill 的灵魂）

每个人用自己的语言、自己的投资偏好，建自己的 CLAUDE.md。

两个投资者看同一家公司，关注点可能完全不同——一个看「下季度订单能否超市场预期」，另一个看「管理层电话会上的语气和信心」。给他们同一份模板，就抹掉了让 wiki 有用的那个东西。

• ✅ 你的工作 = 访谈用户 → 提炼他的关注维度 → 用他的话写进 CLAUDE.md
• ❌ 你的失败 = 套一份「标准投研 schema」让他填空，或让他照抄 examples/

examples/investment-research-CLAUDE.md 是一个人长成的样子，给用户看可能性，禁止照抄。它像模板一样被搬走，这个 skill 就失败了。

不碰的红线（Karpathy 原意，别 over-engineer）

纯 markdown + wikilink + grep。不加 RAG / 向量库 / embedding。 知识靠预编译进结构化页「复利」，不是每次 query 重新检索原始文档——这是本模式相对 RAG 的根本区别，也是 Karpathy 的核心 idea。别加回任何检索层，别加 knowledge graph / 自动 health-check 之类机制（社区有些版本加了，那是 over-engineer）。

机制层 vs 规则层（贯穿全程的区分）

机制层照抄没问题（它是 Karpathy 模式的工程卫生，跟「你怎么投资」无关）。规则层照抄 = 背叛方法论。

工作流

Phase 0 — 判断意图

• 新建 vault → Phase 1
• 已有 vault，ingest 一份源 → 直接读 references/ingest_sop.md
• 已有 vault，财报后复盘某标的 → references/fulfillment_sop.md
• query → 读 vault 的 index.md + 相关页，带 citation 综合答；好答案回填 synthesis

Phase 1 — scaffold 机制层

python scripts/init_vault.py <目标目录>

建空骨架（三层目录 + lint + hook 占位 + 空 index/log + CLAUDE 骨架）。这一步只装机制层，不写任何 schema。

Phase 2 — 访谈共创 CLAUDE.md ★核心步骤

读 `references/interview.md`，按它的 8 个维度一条条访谈用户，把回答用他自己的话写进 <vault>/CLAUDE.md 规则层的占位。

• 一次问一个维度，别一口气灌
• 用户不在乎的维度直接砍（极简 > 全面）
• 卡住才翻 examples/ 给灵感，明说「别抄，挑你戳中的」
• 自检：写好的 CLAUDE.md 像不像「这个人」？像通用模板就重来

Phase 3 — 启用防腐

cd <vault> && git init
git config core.hooksPath .githooks   # local 配置，换机/重 clone 要重设
PYTHONUTF8=1 uv run --no-project --with pyyaml python3 scripts/lint-vault.py wiki  # 确认绿灯

Phase 4 — 首次 ingest 演示

拿用户一份真实的源（研报 / 电话会 / 纪要），按 references/ingest_sop.md 走一遍 HITL 5 卡点，让他亲眼看到 wiki 怎么从源长出来。用用户自己的素材，不要用 examples。

后续运营（按需读 references）

为什么这个 skill 是 inline（不设 context: fork）

它要调 analyst-track-record skill（复盘回测）、跑 Bash（scaffold / lint）、可能并行 Task 取财报数据——subagent 不能调 skill 或 spawn subagent，所以必须 inline。

Next Step

vault 搭好、用户开始 ingest 卖方研报后，如果他想回测某分析师过去准不准 → 建议接 analyst-track-record skill（双维度命中率，有 validated 脚本）。

<!-- ⚠️ 这是一份【参考样例】，不是模板，禁止照抄。 这是「一个看卖方研报的机构投资者」把他的投资大脑写成 CLAUDE.md 后长成的样子， 给你看「一份投研 wiki 可以长成什么样」——它的层级、维度、规则都是【那个人的】偏好。 你的 CLAUDE.md 应该用【你自己的语言、你自己的关注点】写（见 templates/CLAUDE-skeleton.md）： · 你不看卖方研报？删掉「分析师归属」整层。 · 你只关心高管语气？加一条这里没有的「管理层 sentiment」维度。 · 你要三行结论不要长报告？规则就该这么写。 挑你真在乎的，能砍就砍。照抄 = 又变成「别人的模板」，背叛了「每个人建自己的」。 -->

CLAUDE.md — 投研 LLM Wiki（参考样例 · 某机构投资者版）

这是一个 金融投研 LLM Wiki，instantiate 自 Karpathy 的 gist （<https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f>）。 纯 markdown + [[wikilink]] + grep，无 RAG/向量库/embedding——Karpathy 原意，别加检索层。

下面 H1-H11 是【这位机构投资者】选择的规则。它们不是 LLM Wiki 的「标准」，

是「看卖方研报、追踪分析师、按季报节奏复盘」这套工作方式的显性化。

你的工作方式不同，规则就该不同——用 templates/CLAUDE-skeleton.md 写你自己的。

• 覆盖领域：AI 算力价值链（GPU/ASIC/光通信/存储 + hyperscaler 买方）
• 数据来源：卖方深度研报 / 财报电话会 / SEC filing / 行业数据库

---

H1 — 三级骨架 hard rule

每一篇 wiki 页必须明确归属到下列且仅下列三个层级之一：

• wiki/macro/ — 宏观（货币政策、利率、流动性、汇率、地缘、政策）
• wiki/industries/ — 中观（行业、赛道、产业链、供需）
• wiki/companies/ — 微观（个股、上市公司、私人公司）

辅助层（不是骨架，是横切关注点）：

• wiki/analysts/ — 分析师档案 + 历史预测准确度
• wiki/themes/ — 跨行业主题（如「AI 算力」「国产替代」）
• wiki/synthesis/ — 跨源对比、跨时点对比、矛盾归档

禁止把 macro 内容写进 companies/，反之亦然。 一篇研报涉及多个层级时，必须分别更新对应页，并通过 [[wikilink]] 互联。

H2 — 分析师归属（analyst attribution）是一等公民

每一条观点 / 预测 / 评级必须挂在分析师名下。frontmatter 必须包含 analysts: 字段，且每个分析师在 wiki/analysts/ 下必须有对应页面记录其历史预测准确度。

任意 entity 页（macro / industries / companies）的「观点」段落必须使用以下格式：

- **[[analysts/<分析师姓名>]] (<券商>, <YYYY-MM-DD>)**: 上调评级至「买入」，目标价 <币种><价>（当前 <币种><价>，上行空间 +<N>%）。理由：Q1 营收 +<N>% YoY，超预期 <N>pp。 [来源：[[raw/<source-file>#p3]]]

禁止匿名观点（「市场认为」「机构普遍预期」）。如果源文档没说是谁说的，标 [[analysts/_anonymous]] 并在 lint 时降权。

这是本 skill 相对通用 LLM Wiki 的核心差异：通用版只有一个 sources 字段，记不下「谁说的 + 他过去准不准」。投研的 alpha 恰恰在分析师的判断力和历史命中率上。

H3 — 时点快照（point-in-time snapshot）

研报世界的核心时间结构是 半年报 / 年报 / 季频 / 临时事件。Karpathy 默认的 created/updated 不够。每篇 entity 页必须维护一个 ## 时点视图历史 section，结构如下：

## 时点视图历史

### <YYYY-MM-DD>（Q1 财报后）
- 共识评级：买入（<N> 家覆盖）
- 共识目标价：<币种><价> ± <币种><价>
- 关键变化 vs 上期：上调 EPS 预测 +<N>%，主因 <驱动>
- 关键风险：<风险，如客户集中度（前 3 大客户占 <N>%）>

### <YYYY-MM-DD>（Q1 业绩快报前）
- 共识评级：增持（<N> 家覆盖）
- 共识目标价：<币种><价> ± <币种><价>
- 关键变化 vs 上期：行业 beta 上调

所有 wiki 页都必须有这个 section，即使只有 1 个时点。 这让「今天 vs 一个月前对比」成为零成本 query。

H4 — 文档类型分流（ingest branching）

raw 目录的源文档必须打上 doc_type 标签。不同 doc_type 触发不同 ingest 分支：

禁止用同一套模板处理所有文档。 如果 doc_type 不在上表，停下来问用户。

H5 — 数字必须保留原文 + 单位 + 时点

任何数字（营收、目标价、EPS、市占率）必须以下列格式落地：

营收：<币种><值>（<YYYYQN>，YoY +<N>%，源：[[raw/<source>#p3]]）

禁止把数字孤立写（「营收 12.3 亿」）。lint 会把孤立数字标 STALE_NUMBER。

H6 — 观点冲突必须显式归档

当两个分析师 / 两份研报对同一 entity 给出冲突观点时（评级冲突、目标价 ±20% 以上、行业判断相反），必须在 wiki/synthesis/ 下创建专门的对比页。禁止只在 entity 页悄悄并列——冲突是信号，必须 surface。

格式：

# Synthesis: [[companies/<TICKER>]] 评级分歧 <YYYY-QN>

## 多头视角
- [[analysts/<A>]] (<券商>): 买入，目标价 <币种><价>，理由 ...

## 空头视角
- [[analysts/<B>]] (<券商>): 减持，目标价 <币种><价>，理由 ...

## 关键分歧点
1. 对 <核心驱动> 可持续性的判断（A 认为 <N> 个月强周期，B 认为 <N> 个月透支）
2. ...

## 历史回放
- A 在 <上一类似情境> 的预测：✅ 准（命中目标价 +5% 内）
- B 在 <上一类似情境> 的预测：❌ 偏空 15%

H7 — Lint 规则（金融特化）

自动化：结构性检查——wiki 内部断链（[[X]] 指向不存在页）+ frontmatter YAML 合法 + CROSS_LEVEL_LINK——已脚本化为 scripts/lint-vault.py，挂进 git pre-commit hook：commit 涉及 vault 文件时自动跑，硬 fail 阻断 commit，不靠人记忆/自觉。其余语义类（STALE_NUMBER / MISSING_ANALYST / 派生值过时副本）lint 抓不到，仍需 LLM / counter-review。

每次 ingest 完后必须跑下列检查（结构类已 hook 自动化，语义类由 LLM 做）：

硬错（阻断 commit）： 1. BROKEN_WIKILINK：[[X]] 指向 vault 内不存在的页 2. INVALID_YAML：frontmatter 解析失败（如值含未转义冒号） 3. CROSS_LEVEL_LINK：companies 页没有链到任何 industries 或 macro/themes 页（孤立微观信息无价值）

软警告（提示不阻断）： 4. STALE_NUMBER：超过 90 天没更新的数字标记 ⚠️ STALE 5. MISSING_ANALYST：观点没有 [[analysts/...]] 链接 6. CONFLICT_UNARCHIVED：同一 entity 页出现冲突观点但没建 synthesis 页 7. ORPHAN_DOC：raw 文件没有任何 wiki 页引用 8. TIMELINE_GAP：entity 页时点视图历史超过 60 天没更新 9. OVERSIZED_PAGE：单页过长（>200 行）建议拆分

H8 — HITL 卡点（ingest 时必须停下来问的 5 个问题）

ingest 一份新源时，禁止一气呵成。必须在以下 5 个卡点跟用户确认：

1. doc_type 确认：这份是 depth_report / market_update / expert_call / earnings_call / regulatory？ 2. 核心 takeaways 确认：LLM 提 3-5 条，让用户选哪些进 wiki 3. 新建 vs 更新 entity 决策：这家公司在 wiki/companies/ 下没有，要新建吗？还是合并到 [[companies/<母公司>]]？

• 建页门槛（page threshold）：一个实体/概念出现在 2+ 个源，或对单个源是 central 时才建独立页；否则并进已有页的一节，避免页面爆炸。

4. 冲突 surface：如果发现和已有 wiki 冲突，必须停下来问 这个冲突要进 synthesis 吗？还是修订旧观点？ 5. 时点快照确认：这次 update 的时点 label 是「Q1 财报后」还是「管理层电话会后」还是别的？

H9 — 查询模式（query 时的分流）

用户来 query 时，先判断 query 类型：

最后一类是 synthesis 回填——探索的复利。

H10 — CLAUDE.md 是活文档

每次 ingest 后如果发现现有 schema 不够，主动提议修订本 CLAUDE.md。但修订必须经用户确认。禁止 LLM 自己改 H1-H10。 可以 append H11、H12……新规则。

H11 — 财报后兑现复盘 SOP

已 ingest pre-earnings 预判的标的，财报发布后做兑现复盘——这是 vault 复利的核心证据（预测 → 兑现 → 校准）。这是本 skill 相对通用 LLM Wiki 最大的差异：通用版的「复利」是知识累积，这里的「复利」是判断力校准。

触发：某标的在 synthesis/<TICKER>-<period>-pre-earnings 有预判，且该 period 财报已发。

步骤： 1. 取真实财报：多路 fan-out（核心财务 / 分部利润率 / 电话会 / 预期差 / 同行 / vault 基线），每数字带一手出处（官方 filing / transcript）+ ≥2 源交叉验证。禁凭训练记忆编财报后数字（财报常在知识截止后）。 2. 建复盘页：synthesis/<TICKER>-<period>-results.md（doc_type: earnings_call），不复用 pre-earnings 页。 3. 对账（核心）：逐条对照 pre-earnings 预判，按 方向 / 机制 / 阈值 分层，每条标 ✅验证 / ⚠️偏差 / ❌证伪。引用 pre-earnings 原文 必带行号（可现场点回，证明非事后诸葛亮）。 4. 回填：company 时点视图 append 财报后一条（H3）；相关 analyst track record append datapoint（标 Pending，不提前定中长期输赢）。

铁律：

• 押对方向 ≠ 精准命中：诚实承认阈值偏差 + 指认哪个判断框架被验证、哪个被证伪——比「精准命中」经得起 sophisticated 买方拷问。装「算命准」会被基金经理当场问倒。
• falsification 必标：写明「什么结果会让原判断被证伪」（押下行 → 大涨即错），否则是 unfalsifiable 的「怎样都对」。
• n=1 ≠ alpha 统计证明：单标的单次兑现是方法论闭环演示，标注清楚，别声称统计显著。
• 复盘页 register 是写给 sophisticated 买方的：让数据 / 对账表自己说话，禁「硬证据 / 精准命中 / X 是 A·Y 是 B 对仗」式灌结论。

---

投研偏好（按你的真实偏好填）

• 重视数字 > 形容词。「显著增长」没价值，「+32% YoY」才有价值
• 重视观点 > 信息汇总。研报的价值是分析师的判断，不是公开信息的堆砌
• 重视对比 > 单点描述。「今天比一个月前看多了」比「今天看多」信息密度高一个量级
• 分析师 vs 分析师：当两个分析师对同一公司分歧时，这是 alpha 的源头
• 今天 vs 一个月前：当机构集体观点漂移时，这是趋势的源头

---

不要做的事（铁律）

• ❌ 不要写「市场认为」「普遍预期」——必须挂分析师名
• ❌ 不要孤立数字——必须带单位 + 时点 + 出处
• ❌ 不要悄悄并列冲突观点——必须建 synthesis 页
• ❌ 不要跨层级写——macro 内容不进 companies 页
• ❌ 不要一次 ingest 一份长研报不停下来问 HITL 5 问
• ❌ 不要相信 doc 扩展名——file + 用户确认 doc_type
• ❌ 不要加 RAG / 向量库 / embedding —— 纯 markdown 是本模式的本质，不是限制

Counter-Review：对账页 / synthesis 的对抗审查

用于复盘页、冲突归档页这类「有判断」的内容——把「看着对」逼成「经得起买方拷问」。

agent findings 是假设，不是结论

用 sub-agent 做对抗审查，输出是「风险清单」不是「结论」。禁止原样搬给用户。 每条用三维过滤：

• 概率：真会发生吗？（虚构风险 / 边缘 case / 真问题）
• 成本：修 vs 不修各自代价？
• 现实：用户的真实场景会触发吗？

分级：真实 + 低成本 → 改；真实 + 高成本 → 告诉用户权衡；虚构 / 过度 → 明说「拒绝」。汇报标 ✅真问题 / ⚠️部分对 / ❌虚构 / 🚫有害，别全盘照抄。

诚实对账（复盘页专用）

• 押对方向 ≠ 精准命中：承认阈值偏差，指认哪个框架被验证 / 证伪——比「我们押中了」经得起买方拷问。
• 引用预判带行号，可现场点回。
• n=1 标清楚，不声称统计显著。

别用 sub-agent 检测「AI 味」

同 model 盲区——AI 味要靠用户的耳朵 calibrate，不是再派一个同源 agent 来闻。写给 sophisticated 买方的页，register 错了用户一眼能看出，agent 看不出。

财报后兑现复盘 SOP

仅当用户的 CLAUDE.md 启用了「复盘」维度时用（访谈第 7 问）。

这是 LLM Wiki 相对通用知识库最大的差异：通用版「复利」是知识累积，这里是判断力校准——

押注 → 兑现 → 校准，是 vault 最有说服力的复利证据。

触发

某标的之前在 wiki 里有 pre-earnings 预判，且该期财报已发。

步骤

1. 取真实财报（禁凭训练记忆编——财报常在知识截止后）：多路取核心财务 / 分部利润率 / 电话会 / 预期差 / 同行；每数字带一手出处（官方 filing / transcript）+ ≥2 源交叉验证。 2. 建复盘页：synthesis/<标的>-<期>-results.md，不复用 pre-earnings 页。 3. 对账（核心）：逐条对照预判，按 方向 / 机制 / 阈值 分层，每条标 ✅验证 / ⚠️偏差 / ❌证伪。引用预判原文必带行号（能现场点回 = 证明不是事后诸葛亮）。 4. 回填：标的时点视图 append 财报后一条；分析师 track record append 一个 datapoint（标 Pending，不提前定中长期输赢）。

分析师回测：用现成 skill，别重造

如果用户启用了 analysts/ 层，回测分析师历史准确度用 `analyst-track-record` skill（双维度：方向 alpha + 分析质量，有 validated 脚本）。别自己写命中率算法——它踩过你想不到的坑（same-day dedup、benchmark alpha vs 绝对收益、样本量警告）。

铁律

• 押对方向 ≠ 精准命中：诚实承认阈值偏差 + 指认哪个判断框架被验证、哪个被证伪——比「算命准」经得起 sophisticated 买方拷问。装「精准命中」会被基金经理当场问倒。
• falsification 必标：写明「什么结果会让原判断被证伪」（押下行 → 大涨即错），否则是 unfalsifiable 的「怎样都对」。
• n=1 ≠ alpha 统计证明：单标的单次兑现是方法论闭环演示，标注清楚，别声称统计显著。
• register：让数据 / 对账表自己说话，禁「精准命中 / 硬证据 / X 是 A·Y 是 B 对仗」式灌结论。

Ingest SOP：怎么把一份新源喂进 wiki

前提：用户已经在他的 CLAUDE.md 规则层定义了他自己的 doc_type 分类和关注维度。

这份 SOP 是通用流程骨架，「分哪些类、看哪些维度」以用户的 CLAUDE.md 为准，不要套标准分类。

0. 别信扩展名

file <path> 确认真实格式（.xls 可能是 xlsx，.txt 可能是 PDF 导出）。

HITL 5 卡点（禁止一气呵成）

ingest 一份长源时，必须在这 5 处停下来跟用户确认——一口气 ingest 完再问，等于替他做了判断：

1. doc_type 确认：这份属于你 CLAUDE.md 里的哪一类？（用户自己的分类）不同类触发不同处理深度。 2. 核心 takeaways：提 3-5 条，让用户选哪些进 wiki。不是全塞。 3. 新建 vs 更新 entity：

• 这个实体 wiki 里有吗？没有 → 新建还是并进已有页？
• 建页门槛：实体出现在 2+ 源，或对单个源 central，才建独立页；否则并进已有页一节（防页面爆炸）。

4. 冲突 surface：和已有 wiki 矛盾吗？矛盾 → 进 synthesis 还是修订旧观点？（冲突是信号，别埋） 5. 时点 label：这次 update 的时点叫什么？（「Q1 财报后」/「电话会后」/……，用户的语言）

ingest 后

• 数字落地带单位 + 时点 + 出处（不写孤立数字）
• 更新 index.md + append log.md
• 跑 scripts/lint-vault.py（hook 会自动跑，手动也可）

一条源可能触多页

一份深度研报可能同时更新多个层级——分别更新 + wikilink 互联，别全塞一页。具体触哪些层，看用户 CLAUDE.md 的分层。

访谈：把用户的投资大脑提炼成他自己的 CLAUDE.md

你的任务

帮用户长出他自己的 CLAUDE.md，不是给他一份模板。

最大的失败 = 套一份「标准投研 schema」让他填空或照抄。 那会杀死这个方法论的全部价值。

为什么：一份 LLM Wiki 的价值 = 它装的是这个人独一无二的判断方式。两个投资者看同一家公司，关注点可能完全不同：

• 一个看：下季度营收能否超市场预期、大客户订单的放量节奏、关键产品的兑现度
• 另一个看：管理层电话会上的语气和信心、对前景措辞的松紧、有没有回避问题

给他们同一份模板 = 抹掉了让 Wiki 有用的那个东西。

大部分人（哪怕是资深投资者）知道自己看什么，但不知道怎么把隐性框架写成 LLM 能执行的 CLAUDE.md。你的工作就是这个「提炼 + 结构化」——不是替他决定看什么。

---

三条访谈原则

1. 先问再写，用户的话优先。 每个维度先问，拿到用户自己的语言，再帮他结构化。绝不用你的术语替他命名。 用户说「我就看管理层说话有没有底气」→ 规则就用他这句话，别改写成「管理层指引一致性分析」（你的术语）。

2. 能砍就砍，极简 > 全面。 用户不关心的维度，他的 CLAUDE.md 里就不该有。宁可 3 条他真用的，不要 11 条标准的。每塞一条他不在乎的规则，都在稀释这份 wiki 的「他味」。

3. 样例只在卡住时给，且明确「别抄」。 用户说「我不知道还能看什么」→ 才翻 examples/ 给他看可能性，让他挑 / 改 / 弃。给的时候说：「这是某个人长成的样子，看看有没有戳中你的，没有就跳过。」

---

访谈维度（一次一个，别一口气灌）

对应 templates/CLAUDE-skeleton.md 规则层的 8 个占位。每个维度给：怎么问 / 怎么追问 / 怎么提炼 / 反模式。

1. 你看什么市场、什么标的

• 问：你是机构还是个人投资者？买方 / 卖方 / PB？看 A股 / 港股 / 美股？覆盖哪些标的或赛道？
• 提炼：决定 vault 的 scope 和骨架的具体切法。
• 反模式：默认所有人都要「宏观 / 行业 / 公司」三级——个人投资者可能只跟 10 只票，不需要宏观层。

2. 你做判断时，真正看的是哪几个点 ★最核心

• 问：拿一个你最近认真看过的标的，你当时到底在看什么？什么让你决定买 / 卖 / 不动？
• 追问（关键）：你说的「基本面好」，具体是哪几个数字 / 信号？——逼出具体维度，不要停在形容词。 形容词（「成长性好」）没法写成规则，具体信号（「下季度营收增速能否回正」「毛利率能否守住」）才行。
• 提炼：这是用户 CLAUDE.md 的灵魂——他的「关注维度清单」。用他的原话命名，写进规则层。
• 反模式：替他写「估值 / 成长 / 质量」这种教科书三因子——那不是他的脑子。

3. 你的知识怎么分层

• 问：你脑子里这些标的是怎么归类的？按行业？按主题？按持仓？
• 提炼：三级骨架（macro/industries/companies）只是一种切法，尊重用户的切法。
• 反模式：硬套三级——有人只想要「标的 + 主题」两层。

4. 你怎么记录观点 —— 要不要追踪「谁说的、准不准」

• 问：你看卖方研报吗？你在意某个分析师过去准不准吗？
• 提炼：在意 → 建 analysts/ 层 + 观点挂名 + 可配 analyst-track-record skill 做回测（见 fulfillment_sop.md）。不在意 → 整层删掉。
• 反模式：给只看财报的个人投资者强塞「分析师归属」。

5. 你怎么看时间 —— 要不要「今天 vs 上个月」对比

• 问：你关心机构观点随时间怎么变吗？关心季报 / 年报节奏吗？
• 提炼：关心 → 每页维护「时点视图历史」，让「今天 vs 一个月前」成零成本对比。不关心 → Karpathy 默认 created/updated 够了。

6. 你要什么样的输出

• 问：你要一份十万字报告，还是三行结论？要不要明确的「买什么 / 卖什么 / 为什么」？
• 提炼：决定 LLM 生成报告的粒度。用户看不完的长报告对他没价值。
• 反模式：默认输出「专业研报格式」——有人就要三行。

7. 你怎么复盘

• 问：财报出来后，你会回头看自己之前判断对不对吗？
• 提炼：会 → 启用「财报后兑现复盘 SOP」（fulfillment_sop.md）。不会 → 留空，别强加。

8. 你的源都有哪些类型

• 问：你平时的信息从哪来？研报 / 电话会 / 纪要 / 新闻 / 社区？
• 提炼：用户自己的 doc_type 分类，不是标准 5 类。不同类型他想怎么区别处理（哪些细读、哪些只抓增量）。

---

进阶手法：让用户挑错，而不是凭空答

前面的维度访谈是「问」。但当用户「知道但说不清」时（资深专家最常见的状态），直接问往往问不出真东西——他要么答不上来，要么给你一堆正确但泛泛的话。

换个思路：别让他凭空表达，给他一版故意泛泛的东西让他挑错。 你先用通用知识对他关心的标的生成一版平庸的分析，问他「这版差在哪」——他挑错时，隐性知识自己跳出来：「这没用，我看这家只看下季度大客户订单能不能放量，你连前三大客户占 65% 都没提」。那句「我只看 X」就是萃取物，用他的原话写进 CLAUDE.md。

为什么 work：人有个不对称——主动说清自己的判断方式很难，但一眼看出「这版不对」是本能。把前者偷换成后者，用户能说出的东西多 10 倍。错误是钩子。

至于怎么把挑错一路引导到他认领「这就是我」、怎么追到那些最值钱的边界条件——那是访谈当场的火候，比这个思路本身难得多，也不是一份清单能替代的。

---

访谈后

1. 把每条回答用用户的话写进 CLAUDE-skeleton.md 对应占位。 2. 用户没想清的维度留空（活文档，以后用着补）。 3. 自检一遍：这份 CLAUDE.md 读起来像不像「这个人」？如果它像任何一份通用投研模板，重来。

你成功的标志

用户看着写好的 CLAUDE.md 说「对，这就是我看东西的方式」——而不是「嗯，这个模板挺全」。

后者意味着你失败了：你给了他一个模板，而不是帮他照镜子。

---

关于这个公开版

>

上面是投研场景的访谈共创方法，照着做能搭出一个真正能用的、装着你自己判断的投研 wiki——不是残缺版，是真能跑的。

>

但把一个「说不清自己怎么判断」的专家，真萃取到他认领「这就是我」，靠的是访谈当场的火候：火候因专家、因行业、因那场对话的走向而变，标准化成一份 SOP 发给你反而容易让你用错。那一步我们是陪你一起做，不是发文档让你自学。

派生值 prune 纪律（vault 卫生）

机制层卫生，跟用户的投资偏好无关——所有 LLM Wiki 通用。

防的是「同一事实在多处复制后漂移」，让 vault 越用越可信而不是越用越自相矛盾。

派生值本就不该持久化

计数（「共 N 家覆盖」）、厚度、汇总状态、目录复述子标题、可由正文推导的「最后更新于」——不是去重问题，是不该写，需要时现算。写死它 = 埋一个将来会跟事实对不上的雷。

写前漂移测试（三选一命中即停）

1. 能由本页或别处明细算出 → 派生值，删，别写 2. 算不出但同一事实别处有权威定义 → 纯 [[wikilink]] 引用，别写值 3. 既非派生也非复制、是「某历史时刻发生了什么」 → 才写死当时事实

[[wikilink]] 只解第 2 种；对第 1 种用 wikilink 是错的（制造会过时的引用脚手架 + 「已对齐」的假象）。

改会变的事实前，先 grep 所有副本

改数字 / 置信标注 / 口径 / 状态 / 日期前，先 grep 它在全 vault 的所有出现处（表格单元格 / 摘要 / 结论 / index 描述列 / frontmatter 全算），一次改齐。一致性靠 grep 兜底，不靠记性。

lint 抓不到这些

派生值漂移是语义类，结构 lint 抓不到，靠这份纪律 + counter-review（见 counter_review.md）。

CLAUDE.md — <你的 vault 名>

这是我的 个人投研 LLM Wiki，instantiate 自 Karpathy 的 gist （<https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f>）。 纯 markdown + [[wikilink]] + grep，无 RAG / 向量库 / embedding——这是模式本身，别加检索层。

这份 CLAUDE.md 是「你的投资大脑」。 下面分两块：

- 机制层 = 所有 LLM Wiki 通用的工程结构，照着保留即可。

- 规则层 = 用你自己的语言、你自己的投资偏好写，不要照抄任何模板。

>

每个 [ ] 是一个待你想清楚的问题（skill 的访谈会带你过一遍）。没想清的先空着，

用着用着再补——这是活文档。卡住了去 examples/ 找灵感，但只挑你真在乎的，能砍就砍。

---

机制层（通用工程结构 · 保留即可）

三层文件结构（Karpathy）

• raw/ — 原始源材料，只读不改（研报 / 电话会 / 纪要 / 新闻原文）
• wiki/ — LLM 编译的知识页，按你的层级组织
• wiki/index.md — 全局目录（每页一行摘要）；wiki/log.md — append-only 操作日志

防腐（机械门，不靠自觉）

• scripts/lint-vault.py 挂 git pre-commit hook：commit 前自动查断链 / YAML / 孤立页，硬 fail 阻断
• 数字必须带单位 + 时点 + 出处，不写孤立数字
• 安装 hook：git config core.hooksPath .githooks（hooksPath 是 local 配置、不随仓库走，换机/重 clone 要重设）

---

规则层（你的投资大脑 · 用你自己的话写）

下面每条都是问题不是答案。访谈时一条条带你想；想清一条写一条。

我看什么市场、什么标的

[ 机构还是个人投资者？买方 / 卖方 / PB？A股 / 港股 / 美股？覆盖哪些标的或赛道？ ]

我做判断时，真正看的是哪几个点

[ 这是最核心的一条。 写你自己的关注维度，用你自己的话，别套术语模板。 例（别抄，只是示意不同人差异有多大）：

• 有人看：下季度营收能否超市场预期 / 大客户订单放量节奏 / 关键产品兑现度
• 有人看：管理层电话会语气和信心 / 对前景措辞的松紧 / 有没有回避问题

这几条决定 LLM 给你生成的报告长什么样。 ]

我的知识怎么分层

[ 要不要分 宏观 / 行业 / 公司 三级？还是别的切法（如只按主题、只按标的）？ 你关心的横切主题有哪些？ ]

我怎么记录观点 —— 要不要追踪「谁说的、准不准」

[ 你看卖方研报吗？在意分析师的历史命中率吗？ 在意 → 建 analysts/ 层、每个观点挂分析师名（可配 analyst-track-record 回测）。 不在意（如你只看财报原文）→ 删掉这整条，别让模板硬塞给你。 ]

我怎么看时间 —— 要不要「今天 vs 上个月」对比

[ 关心机构观点随时间漂移吗？关心季报 / 年报节奏吗？ 关心 → 每页维护「时点视图历史」，让「今天 vs 一个月前」成为零成本对比。 不关心 → 用 Karpathy 默认的 created/updated 就够。 ]

我要什么样的输出

[ 十万字报告，还是三行结论？要不要明确的「买什么 / 卖什么 / 为什么」？ 你看不完的长报告对你没价值——按你真能用的粒度写。 ]

我怎么复盘 —— 财报出来后回看判断对不对

[ 你会回头对账自己之前的预判吗？ 会 → 启用「财报后兑现复盘 SOP」（见 references/fulfillment_sop.md）：预测→兑现→校准，判断力复利。 不会 → 留空。 ]

我的源都有哪些类型，怎么区别处理

[ 研报PDF / 电话会 / 专家纪要 / 新闻……不同类型你想怎么区别 ingest？ 这是你自己的 doc_type 分类，不是别人给的标准 5 类。 ]

---

不要做的事（通用底线）

• ❌ 不加 RAG / 向量库 / embedding —— 纯 markdown 是本模式的本质，不是限制
• ❌ 数字不带出处
• ❌ 一次 ingest 一份长文不停下来跟自己确认要点（HITL）
• ❌ 照抄 examples/ —— 那是别人的大脑，不是你的