LLM Wiki

LLM Wiki 是个人站点背后的知识编译层。 它不替代 RAG，不替代个人站点，而是把原始资料、个人思考、外部信息持续整理成一个由 LLM 维护、由人校准的结构化 wiki。这层 wiki 不直接对外发布，但它让写文章、做决策、回答高价值问题都有现成的素材和索引。

核心思路

传统 RAG 是在提问时临时检索资料：

资料 → 切 chunk → 向量索引 → 提问 → 检索片段 → LLM 拼答案

LLM Wiki 是在平时就把资料整理成可复用的知识单元：

资料 → LLM 阅读 → 提炼概念、实体、主题、关系 → 写成 wiki 页面 → 页面互链
      → 新资料持续更新旧页面 → 查询时基于 wiki 综合回答 → 高价值答案再沉淀回 wiki

区别不在检索技术，而在谁负责把知识组织好。RAG 把组织工作推给检索时刻的临时拼接，LLM Wiki 把组织工作前移到平时的结构化沉淀。两者可以叠加：wiki 自身的索引也可以走 RAG。

三层结构

LLM Wiki 由三个独立层组成，每层解决不同问题。

第一层：原始资料（raw）。这一层保存事实来源，包括文章、论文、网页、会议纪要、PDF、读书笔记、碎片思考。原则是只存不改，任何整理动作都在上层完成，原始层永远可回溯。

第二层：Wiki 页面（wiki）。这一层是 LLM 维护的结构化 Markdown 页面，按页面类型组织：

index.md 总索引
log.md 更新日志
sources/xxx.md 单篇资料摘要
concepts/xxx.md 概念页（定义、背景、典型应用、关联概念）
entities/xxx.md 实体页（公司、人物、产品）
synthesis/xxx.md 综合分析页（跨资料结论）
comparisons/xxx.md 对比页
questions/xxx.md 高价值问题沉淀

这一层要把资料拆成可长期复用的最小知识单元，而不只是读完后写一段摘要。一个概念只出现一次，后续内容通过引用复用它。

第三层：Schema 规则（schema）。这一层定义 LLM 如何维护 wiki：什么类型的内容生成什么页面，概念页包含哪些字段，新资料进来时执行哪些动作，引用怎么标，矛盾怎么处理，重复如何合并。没有 schema，LLM 只是随手写笔记；有了 schema，LLM 才像知识库维护员。 具体例子见下文「8 类行业目录」——它是 schema 层在行业研究主题上的实例化。

知识栈闭环

LLM Wiki 不应该只是“笔记软件 + AI 对话”。笔记、模型和 Agent 分开使用时，常见结果是：笔记写完没人维护，AI 聊天每次从零开始，真正复杂的工作上下文在人的脑子和模型上下文里反复掉线。知识栈要解决的，是把三者合成一个闭环。

一个可运行的知识栈至少包含三层：

本地 Markdown 图谱：保存原始资料、长期笔记、索引、概念页和综合页，是知识系统的事实来源。
Agent 编排层：读取文件、调用工具、维护任务状态、执行 lint、把有价值的结果写回知识库。
长上下文推理模型：一次读取足够大的相关图谱，在多个文件、标签、概念和历史记录之间保持结构一致。

这三层的分工要清楚。Markdown 图谱负责长期主权：资料以普通文件存在，可以搜索、diff、版本管理和迁移；Agent 负责把静态文件变成可操作系统：它能读目录、跟链接、改文件、写报告、安排定时任务；模型负责跨文件理解、重组和生成。三层混在一起时，系统会变成一个难以追溯的聊天记录；三层分开协作时，知识才会持续复利。

这套闭环的最小运行方式是：

人捕获原始资料 → raw 保存来源 → Agent 读取相关文件 → 模型整理、打标签、加链接
→ Agent 写回 Markdown → lint 检查结构问题 → 人审核重要变更 → 新知识进入下一轮上下文

关键点在“写回”。一次聊天回答再精彩，如果没有进入文件系统，很快就会消失。一个 wiki 页面再粗糙，只要被写回、被链接、被 lint、被后续任务读取，就会成为下一次推理的上下文。知识系统的复利来自这个循环，单次回答质量只是局部收益。

Agent 要生活在图里。它不能只把知识库当作查询材料，读完后在聊天框里给结论；它应该知道哪些目录可读、哪些目录可写、哪些页面是原始资料、哪些页面是综合观点、哪些链接是确认过的、哪些链接只是待处理线索。这样它才像知识库维护员，而不只是偶尔来访的摘要工具。

后台班次

第二大脑长期失败的原因，通常不在方法论，而在维护劳动。卡片盒、PARA、双链、每日笔记和图谱视图都默认有人持续归档、拆分、链接、核查和复盘。这个人往往就是自己。忙碌一段时间后，系统里会出现未整理文件夹、孤立摘录、过期标签和没有来源的结论，知识库逐渐从思考工具退化成积压库。

LLM Wiki 要把这部分劳动设计成后台班次。白天，人只负责低摩擦捕获：看到材料、产生想法、遇到问题、发现矛盾时，把原文、链接、截图、语音转写或半成型念头放进 raw / Inbox。晚上，Agent 按固定流程处理这些材料，把它们拆成 source、concept、idea、synthesis 和待处理问题。早上，人看到的应该是一份可判断的简报：新增了什么、改动了什么、发现了哪些冲突、哪些地方需要人拍板，而不是一堆等待再次整理的新文件。

这个模型的关键是分工，而不是智能体数量。可以把后台班次拆成几个角色：

采集员：读取阅读清单、链接、PDF、网页快照和转发内容，补齐来源、时间、作者、原始链接、内容类型和隐私级别。
归档员：把长材料拆成可复用的 source note 和 atomic idea，避免把整篇文章直接塞进知识库。
制图员：维护页面之间的链接，给新条目找到相关 concept、entity、synthesis 和 question。
评论员：检查新材料是否挑战旧判断，标出来源不足、概念重复、证据薄弱、适用条件变化和互相矛盾的地方。
编辑员：把一组相关原子笔记编织成 synthesis 草稿，生成晨间简报和待决事项。
审计员：定期检查无来源笔记、断链、孤立页面、标签漂移、过长页面、过碎页面和长期无人处理的冲突。

后台班次应该按阶段交接，而不是把所有任务塞进一个大 prompt。一个可执行节奏是：

晚间采集 → 深夜精炼 → 清晨简报 → 每周审计

晚间采集只做低风险动作：拉取来源、保存原文、补元信息。深夜精炼才做拆分、链接、冲突检测和 synthesis 草稿。清晨简报把系统需要人的地方列出来，不要求人翻遍所有新文件。每周审计处理长期健康问题：哪些页面没有来源，哪些链接只是前向引用，哪些观点已经被新资料削弱，哪些目录边界正在被 Agent 写乱。

这套班次要有几条硬护栏。

原始资料不可改写。 raw 和 sources 是事实来源，只能新增、补元信息和引用，不能被 Agent 重写。所有摘要、概念、综合和评论都在上层生成。只要原文不动，后续任何误解都可以回溯和修正。

无来源，不成笔记。 AI 知识库最危险的腐坏，是衍生笔记继续引用衍生笔记，最后系统把自己编出的内容当成事实。每条 source note 必须指向原始材料；每条长期观点必须能回到 source、idea 或人工判断。无法确认来源的内容可以留在 Inbox 或 raw，不进入长期结论层。

人只处理判断，不重新承担苦工。 如果晨间简报只是提醒“昨晚新增了很多文件”，系统仍然把整理劳动甩回给人。好的简报应该把问题压缩成可判断事项：保留哪条观点、合并哪两个概念、是否接受某个反例、是否把某个 synthesis 升级为公开文章素材。人负责价值判断和边界确认，Agent 负责准备材料、列出证据和执行低风险改动。

版本控制先于自动化。 只要 Agent 获得写权限，知识库就应该纳入 git。每次后台班次结束后形成可查看的 diff，必要时一键回退。版本控制是自动化系统的刹车和记忆：它让人知道机器改了什么，也让错误不会在几轮自动改写后失去痕迹。

权限从窄到宽。 早期让 Agent 只写 Inbox、Reviews 和临时草稿；稳定后再允许它更新 concepts、synthesis 和 index；raw 层始终不可改写原文。越靠近长期观点和公开文章素材，越需要人工确认。自动化的目标是持续产生候选知识，而不是绕过人的判断。

当后台班次稳定运行后，知识库会出现几种健康信号：每天都有可追溯的新 source，旧 concept 会被新资料微调，synthesis 会逐渐变厚，Reviews 里有未处理冲突和审计报告，简报会持续把“需要人想一想”的问题推到面前。知识库真正复利的地方，是它在你不主动整理时仍然会维护结构、提出反例、生成候选判断；页面数量增加只是副产物。

关键流程

Ingest（导入） 是 wiki 的主入口。新增一篇资料时，LLM 不只生成摘要，而是按 schema 执行一组维护动作：

读取资料 → 生成 source 页面 → 提取关键概念 → 判断已有概念页是否需要更新
→ 创建新概念页 → 更新 synthesis 页建议 → 更新 index → 记录 log → 标记冲突

一篇关于 Agent 安全的文章可能同时更新多个概念页和综合分析页，产出一组结构化变更，而不只是一份摘要。

Query（查询） 先查 index 找到相关概念页和综合页，再综合回答；全文检索只是辅助入口：

理解问题 → 查 index → 找相关 concept / synthesis / source 页面 → 综合回答
→ 如果答案有长期价值，再沉淀成新 wiki 页面

Lint（体检） 决定知识库能不能长期复利。定期检查孤立页面、重复概念、过期观点、互相矛盾、index 覆盖度、过长/过碎的页面。这一步比前两步更关键。没有 lint，再多积累也只是垃圾堆。

Lint 还要处理前向引用。LLM 在整理资料时，可能发现一个值得建立的概念，但对应页面还不存在。此时直接跳过会丢失关系，凭空写成完整页面又容易制造假知识。更稳的做法是允许前向引用：先写出 [[待建概念]]，标记为未确认或未建页，在定期 lint 时统一处理。前向引用让知识图谱保留生长方向，lint 负责把灰色链接变成真实页面、合并到已有概念，或删除误判。

一次有效的 lint 要输出结构报告，而不只是“找错字”：

孤立页面：没有被任何 index、concept 或 synthesis 引用的页面。
重复概念：不同文件表达同一概念，需要合并或建立主页面。
灰色链接：前向引用、断链、命名不一致的 wiki link。
标签漂移：同类内容使用了不同标签体系，或者新标签没有进入 schema。
过期观点：旧 synthesis 与新资料冲突，需要更新或标记历史观点。
过碎页面：只有一句话、没有复用价值的概念页。
过长页面：堆积多个主题，应该拆分成概念页和综合页。

从储存到碰撞

知识库如果只优化储存，很容易变成整齐的积压库。文件夹、标签、搜索、双链和图谱视图可以让资料更容易找到，但它们不会自动产生新判断。真正有价值的知识系统，要让想法系统性地发生碰撞：不同时间、不同主题、不同项目里的观察被放到一起，产生任何单条笔记里都不存在的新结论。

储存型知识库的典型问题是：资料很多，思考很少；摘录很多，立场很少；链接很多，非显而易见的连接很少。它能回答“我之前存过什么”，却很难回答“这些东西合起来暗示了什么”。LLM Wiki 的目标，是把知识库从资料仓库变成思考反应堆。

想法碰撞需要三个条件。

第一，知识库里要有自己的立场。 只有摘录没有反应，系统只能整理别人的观点。每条重要 source note 都应该有一段反应：它确认了什么，挑战了什么，补充了哪个维度，会不会改变已有判断。弱反应只是“这篇很有启发”；强反应会点出冲突、影响和下一步归属。比如一篇关于注意力稀缺的文章，不应该只被摘要为“平台流量越来越贵”，还要写清楚它是否挑战了某个增长假设、是否改变某个行业判断、是否应该进入某个 synthesis。

第二，系统要主动寻找非显而易见的连接。 手工链接通常记录的是你已经意识到的关系。它有价值，但不会带来太多新东西。综合任务应该明确要求：找出来自不同主题、不同时间、不同项目的笔记之间的联系；表面相似不算；只复述已有链接不算；必须说明两条或多条父笔记共同推出了什么新判断。真正值得保留的连接，通常会让人停顿一下，因为它不是自己原本会顺手想到的关系。

第三，矛盾要被主动挑出来。 知识系统不能只服务于确认偏误。新的 source note 应该定期和旧的 idea / synthesis 对照：哪些证据正在削弱旧判断，哪些旧观点需要增加适用条件，哪些表述已经过期。一个论点和反向证据碰撞后，如果还能站住，通常会变得更具体；如果站不住，就应该被改写、降级或归档为历史观点。

可以把 wiki 页面分成两类：

Source：资料、摘录、外部观点、原始事实。
Idea：自己的立场、判断、假设、问题、反应。

Source 进入知识库只是开始。没有 Idea 层，LLM 只能在资料之间做表面聚合；有了 Idea 层，它才能把外部资料和你的既有判断放在一起，产生“这会改变我什么”的结果。一个好系统不是只问“这篇资料说了什么”，还要问“这篇资料会让哪条已有判断变强、变弱、变窄或变得更可执行”。

一个可执行的日常综合任务可以这样设计：

读取最近新增的 source 和最近活跃的 idea
→ 找出 2-3 个非显而易见连接，必须指明父笔记
→ 找出 1-2 个与旧观点冲突或需要修正的地方
→ 生成候选子想法，说明它不是已有内容的摘要
→ 标记应该更新的 concept / synthesis / question 页面

更强的月度任务，可以直接问：

读取过去一个月新增和修改的笔记。
只回答一个问题：基于这些已有想法，知识库本来可以产生哪条目前还不存在的新判断？
列出父笔记，描述子想法，说明推理链，并指出它应该进入哪个 wiki 页面。
不要总结已有内容，产出还不存在的判断。

这类任务的价值在于，它把“写下一篇文章”“开启一条研究线”“修正一个旧观点”从灵感依赖，变成知识库周期性产生的候选输出。人仍然负责判断这些输出是否成立，但系统负责把可能的连接推到人面前。

当知识库没有产生新想法时，通常有几个原因：

只有摘录，没有反应。 解决方式是暂停继续捕获，先给已有 source 写立场反应。
连接过于显而易见。 说明综合提示太宽松，或者不同领域的 idea 太少。
矛盾检查长期为空。 可能是旧判断已经很稳，也可能是输入源一直在确认既有信念，需要检查阅读和捕获是否过窄。
资料质量太低。 低质量捕获会稀释信号，lint 应该能把长期没有复用价值的页面标出来。
系统只会输出摘要。 说明 schema 没有要求“父笔记、子想法、推理链、应更新页面”这些结构字段。

一个成熟的 LLM Wiki 打开时，应该有一种“系统在你不看时仍然工作”的感觉：有待确认的前向引用，有需要处理的矛盾，有新的 synthesis 候选，有被合并或降级的旧页面。知识库的生命力不在页面数量，而在这些页面是否持续互相改写。

资料捕获层

很多知识系统首先失效在输入端。资料没有进入 raw 层，再好的 schema、wiki 和 lint 都无从发挥作用。尤其在个人知识管理里，高价值信息经常不在正式文章里，而在微信群聊、私聊、文件、语音、公众号文章、临时链接、截图和移动端看到的网页里。这些内容带着场景、语气、人物关系和当下问题，比公开网页更接近真实工作流。

收藏夹解决的是"以后可能有用"，没有解决"以后还能找到、理解、复用"。一条群聊观点被收藏后，通常会失去上下文：谁说的、针对什么问题、当时有什么反驳、后续是否被验证。等到真正需要时，它只是一段沉在列表里的碎片。LLM Wiki 需要在收藏动作之后再多走一步：把资料保存到 raw 层，并补齐最小元信息。

更合理的捕获入口应该贴近日常动作。比如把一个固定联系人或机器人当作知识入口：看到有价值的聊天记录、文件、链接、语音、文章时，直接转发给它。后续由 AI 完成标题、来源、时间、内容类型、标签、摘要、待确认问题的初步整理，再进入 raw 层。这样做的价值是把捕获动作压缩成一次明确的用户意图，而不是追求"自动同步一切"。

私域资料尤其适合这种方式。封闭平台里的内容很难稳定抓取，强行绕过平台边界会带来账号、安全和合规风险。用户主动转发是一条更稳的桥：系统不需要监听全部聊天，不需要批量抓取所有内容，只处理用户明确选择送进知识库的资料。这个边界很重要，因为个人知识库往往会混入家庭、工作、客户、朋友和隐私信息，入口越强，越需要克制。

捕获层只应该完成三件事：

保存原文：聊天记录、文件、语音转写、网页正文、链接快照先进入 raw 层，保留可回溯来源。
补齐元信息：记录来源平台、转发时间、原始链接、发送者或场景备注、内容类型、隐私级别。
生成待处理线索：提取可能进入 wiki 的概念、实体、问题和行动项，但不直接覆盖已有 wiki 页面。

后续 ingest 才负责结构化。捕获层不能越权把碎片直接变成结论，否则会把临时观点、未经确认的传闻、上下文不完整的聊天内容沉淀成长期知识。更稳的路径是：

转发/保存 → raw 原文与元信息 → AI 初步清洗 → 人确认敏感边界
→ ingest 进入 source / concept / synthesis → lint 定期检查

对微信这类高频入口，实践上可以设置几条硬规则：默认不自动同步全部聊天；涉及他人隐私、公司机密、客户材料时先标记为私有；语音和图片 OCR 保留原始文件；AI 生成的标题、标签和摘要可以改写，原文不可改写；无法判断来源和授权边界的资料，只进 raw，不进公开文章素材池。

资料捕获层越顺手，LLM Wiki 才越有机会长期运行。一个需要打开多个工具、复制粘贴、手工改标题的流程，很快会在忙碌中断掉。入口足够低摩擦，raw 层才会持续增长；边界足够清晰，wiki 层才不会被隐私、噪音和未经验证的信息污染。

主动情报层

资料捕获层解决的是“我看到有价值内容时怎么低摩擦保存”。主动情报层解决的是另一类问题：有些重要变化不会主动走到眼前，需要系统定期去看。行业新闻、监管政策、安全事件、GitHub repo、竞品官网、招聘页面、融资动态、技术博客、漏洞公告、CVE、供应链风险和长期关键词，都适合进入主动监控。

主动情报层的目标，是让系统持续发现“值得判断的变化”。它应该像一个低噪声雷达：按固定节奏扫描明确对象，识别增量，过滤噪音，把真正需要人判断的内容送进 raw / source / review。没有这层能力，知识库只能依赖偶然看到的材料；有了这层能力，个人站点才会对外部世界保持在场感。

一个主动情报系统至少包含四类 watchlist。

第一类：主题 watchlist。 围绕长期关注方向设置关键词和问题，例如 AI 安全、支付安全、大模型越狱、Agent 安全、供应链攻击、数据合规、浏览器安全、个人 AI 系统。关键词不能只写宽泛词，还要写清意图：是找监管变化、技术突破、攻击案例、产品机会，还是投资风险。宽泛关键词负责发现，窄关键词负责降低噪音。

第二类：对象 watchlist。 跟踪具体 GitHub repo、公司、竞品、开源项目、研究团队、监管机构、媒体栏目和个人作者。对象型监控比关键词更稳定，因为它知道“谁重要”。GitHub 可以看 release、issue、pull request、commit 活跃度、star 变化和安全公告；竞品可以看官网文案、价格页、招聘岗位、技术博客、融资新闻和产品更新。

第三类：风险 watchlist。 专门监控会触发行动的变化，例如漏洞公告、CVE、依赖库安全问题、供应链攻击、监管处罚、数据泄漏、云服务故障、关键基础设施事故。这类信息的价值不在写文章，而在提醒是否需要检查系统、调整策略或更新风险认知。

第四类：趋势 watchlist。 定期看行业新闻、政策文件、研究报告、社交平台高频讨论和开发者社区热点。趋势监控要避免追热点，重点看一个主题是否反复出现、是否跨平台扩散、是否从讨论进入产品和预算、是否开始影响监管和组织行为。

主动情报层可以按这条管线运行：

watchlist → 定时抓取 → 变化检测 → 去重与分级
→ source note → 与已有 idea / synthesis 对照
→ 生成 review 简报 / GitHub Issue / 待更新页面

其中最关键的是变化检测。系统不应该每次把整篇网页、整组 release、整堆搜索结果都重新塞进知识库，而要回答：和上一次相比，新增了什么、删除了什么、语气变了什么、价格变了什么、重点功能变了什么、风险状态变了什么。主动监控的价值来自 delta，而不是重复抓取。

去重与分级同样重要。主动抓取一旦没有分级，很快会制造大量待处理材料。可以把结果分成四级：

静默归档：保存到 raw，不打扰人，供未来检索。
普通更新：进入 source note，等待后台班次整理。
需要判断：进入 review 简报，说明为什么值得看。
需要行动：生成明确任务，例如检查依赖、更新文章、调整 watchlist、创建 issue。

沉淀时要区分“事实变化”和“判断变化”。一个 repo 发布新版本，是事实变化；这个版本是否代表技术路线转向，是判断变化。一个竞品招聘安全工程师，是事实变化；它是否意味着该公司开始重视安全合规，是判断变化。source note 保存事实，idea / synthesis 承载判断，不能让抓取层直接把线索写成结论。

主动情报层还需要定期审计 watchlist。长期没有产出有效内容的关键词要删除；噪音太高的源要降频；反复产出高价值材料的源要升权；已经过期的竞品、项目、政策专题要归档。watchlist 本身也是知识资产，应该被版本管理，能看到什么时候加入、为什么加入、什么时候调整。

不同类型的信息适合不同频率：

安全漏洞、CVE、供应链风险：高频监控，必要时当天提醒。
GitHub release、issue、技术博客：每日或每周整理。
竞品官网、价格页、招聘页：每周或每月做变化检测。
监管政策、行业报告、宏观趋势：每周或每月综合。
长期关键词：低频但持续，观察主题是否跨源反复出现。

主动情报层的边界要清楚。公开网页、RSS、官方 API、GitHub、监管公告和用户主动提供的材料，适合自动处理；登录态内容、私域聊天、付费内容、平台限制抓取的页面和涉及他人隐私的信息，需要更谨慎的授权边界。系统能抓到，不代表应该抓；系统能总结，不代表可以公开发布。

这层能力和 GitHub Issue 可以配合。高价值变化可以自动创建 issue，但 issue 应该带上来源、抓取时间、摘要、为什么值得处理、建议归属和不确定点。这样后续沉淀时，LLM 不需要只看一个链接猜意图。低价值变化不要创建 issue，否则收件箱会变成噪音池。

主动情报层最终要服务于三类输出：更新已有判断、产生新研究问题、触发具体行动。没有进入这三类输出的监控，只是在制造信息消费。一个成熟的系统应该能定期回答：本周哪些外部变化改变了我的判断？哪些主题开始值得深入？哪些风险需要立即处理？

和当前个人站点的关系

当前个人站点的沉淀路径是：

输入 → 人工理解 → 写成文章 → 发布

LLM Wiki 引入后的路径是：

输入 → LLM 结构化 → wiki 持续演化 → 人工判断 → 精选成文章 / 方法论 / 决策依据

二者是上下游分工，不存在替代关系：

层级	作用	公开性	维护方式
原始资料	事实来源	私有	人工收集
LLM Wiki	结构化知识资产	半公开/私有	LLM 维护，人审核
个人站点	长期作品与方法论	公开	人主导，LLM 辅助

关键原则：

不要让 LLM 决定什么可以公开。
不要把 wiki 页面直接当文章发布。
不追求一开始全自动。
一个主题跑通闭环，再扩展到其他主题。
wiki 服务于长期写作、研究和决策，不是终点。

LLM Wiki 真正解决的问题是个人知识系统能否长期复利。单次写作节省的时间不重要；持续累积下来，wiki 让旧资料能反向更新旧观点、让新思考能基于已有结构、让高价值问题不再从零回答，才是有价值的部分。

落地步骤

不要一开始改造所有知识库。

第一步：选一个高价值主题试点。 适合的主题特征是资料更新快、概念多、和当前工作强相关、能产出公开文章。AI 安全、Agent 框架、特定行业研究都是典型候选。

第二步：建立最小 wiki 骨架。 创建 index.md / log.md / schema.md 三个核心文件，加 sources/ / concepts/ / synthesis/ 三个子目录。schema.md 先只定义 source、concept、synthesis 三种页面类型的最小字段；comparisons、questions 等类型等需求出现时再扩展。

第三步：用半自动方式跑通一次闭环。 选 10 篇资料手工或半自动地走一遍 ingest 流程，重点观察 schema 是否真的能约束 LLM 输出、概念页是否能被复用、index 是否方便查找。不要先写程序，先把人和 LLM 的协作节奏跑顺。

第四步：从 wiki 提炼第一篇公开文章。 这次提炼才是真正验证 wiki 价值的时刻——如果 wiki 里的概念页、综合页无法支撑一篇有深度的文章，说明结构还需要调整；如果可以，wiki 才真正成为个人站点的素材库。

第五步：把 lint 排上日程。 没有 lint 就没有长期复利。固定周期（每周或每月）跑一次检查：孤立页面、重复概念、过期观点、index 覆盖度。

第六步：给目录设置权限边界。 人可以自由写 Inbox/、Daily/、Reading/；Agent 可以把内容整理到 Projects/、Reviews/、concepts/、synthesis/；raw 层只能新增和补元信息，不能被改写；公开文章素材池必须经过人工判断。目录权限不一定一开始就写成复杂配置，但心智边界要清楚。

第七步：把重复维护变成轻量任务。 每天整理昨日记录，每周生成 review，每月检查孤立页面和重复概念，新资料进入后自动生成 source 页面，这些都是低风险、高复利的后台任务。知识库最容易失败的地方，是维护永远依赖人的临时兴致。让低风险维护按固定节奏发生，系统才会越用越稳。

落地之后，wiki 是个人站点的预编译层，不只是"另一个文档系统"。个人站点从此可以专注于精选和表达，不必再从零组装结构化思考。

可扩展的文件夹布局

LLM Wiki 的目录不需要一开始就复杂，但每个目录要有清楚职责。一个实用布局可以是：

目录	作用	人和 Agent 的边界
`raw/`	原始资料和来源快照	只新增，不改写原文
`Inbox/`	临时想法、粗糙记录、快速转发	人自由写，Agent 只做初步整理
`Daily/`	日志、当天想法、工作片段	人自由写，Agent 可生成日/周摘要
`Reading/`	阅读摘录、source note、资料卡片	人捕获来源，Agent 生成 source 页面
`concepts/`	稳定概念页	Agent 可建议创建，人审核关键概念
`synthesis/`	跨资料综合判断	Agent 起草，人决定是否成为长期观点
`Projects/`	当前项目相关知识	Agent 可整理项目状态和未决问题
`Reviews/`	周/月复盘和 lint 报告	Agent 定期生成，人确认方向

这个结构的意义是给 Agent 明确操作边界，而不只是“分类好看”。混乱知识库会把大量模型能力消耗在理解混乱上；职责明确的目录会把模型能力用于重组、对比、链接和更新。目录越稳定，Agent 越容易形成可复用的工作流。

一个具体应用：8 类行业目录

承接第一步「特定行业研究」的提示——LLM Wiki 的一个典型应用是快速进入一个新行业：评估一个赛道、调研一个潜在客户、规划一次转型。这一场景对应 schema 层的一个具体实例化：8 类核心目录，每个目录对应一种 wiki 页面类型：

目录	作用	关键产出	对应 wiki 页面
品牌	谁是头部玩家	头部品牌 + 创始人 + 销售渠道 + 估计规模	entity 页
产品	行业提供什么	产品类型（按市场规模排序）+ 拆解到成分 / 评价 / 价格	concept / entity 页
痛点	用户的钱藏在哪	高频抱怨 + 高频需求 + 用户目标	synthesis 页
内容	流量在哪里	头部账号 + 爆款话题分析	synthesis 页
关键词	用户怎么搜	跨平台关键词按意图分类	index / concept 页
竞品	同行怎么赚钱	头部竞品 + 拆解收入模式 + 拆解流量来源	entity / synthesis 页
商业模式	钱怎么流转	收入结构 + 利润环节 + 关键资源	concept 页
行业地图	全景视角	上下游关系 + 监管 + 趋势 + 机会点	synthesis 页

让 LLM 一次建立完整目录结构（每个目录一个 markdown 文件），然后逐步填充。

痛点是被低估的目录。 大多数研究者先看产品，但用户的钱藏在痛点里。让 LLM 整理用户讨论（Reddit、知乎、垂直论坛）的高频抱怨、高频需求、高频问题——这些会直接指向产品机会。现有产品说明市场已被验证，但用户痛点暴露的是未被满足的需求——这是新进入者的最佳入口。同样的精力花在痛点上，回报是花在产品上的数倍。

流量与内容是被忽视的目录。 真正决定一个行业起飞的，往往是内容传播。头部账号的内容分析会告诉你什么话题反复在爆、什么观点反复有人讲、什么内容天然容易传播。这些是经过同行验证过的"流量地图"——新进入者按图索骥，能跳过大部分试错。理解一个行业的流量结构，比理解它的产品结构更重要。

反向拆解赚钱逻辑。 最快进入新行业的方法，是先从同行开始。直接让 LLM 拆解头部竞品：他们卖什么、靠什么流量、收入结构如何、关键资源是什么。一个被市场验证过的模式，比任何理论分析都更接近真相。

把数据库接入工作流。 数据库的价值不在收集，而在持续调用：决策时直接调出，启动新项目时复用上一轮目录结构套用到新行业，行业知识按时间快照累积供未来对比。

核心思路​

三层结构​

知识栈闭环​

后台班次​

关键流程​

从储存到碰撞​

资料捕获层​

主动情报层​

和当前个人站点的关系​

落地步骤​

可扩展的文件夹布局​

一个具体应用：8 类行业目录​

相关​