企业官网建设流程全解析

做内容这行，收集案例是个特别容易让人产生错觉的动作。我见过很多人的“爆款案例库”，其实就是一条收藏夹链接加一张截图。当时看着很有启发的爆款，过两周再打开，除了标题之外完全想不起它为什么火。我也帮人做过一次案例库整理，几百条素材，最后能直接拿来用的不到三十条。问题不在内容不够多，而在于这些内容从进库的第一天起，就没有被结构化成可以被检索、被分析、被调用的资产。

用 AI 搭建 Obsidian 案例库，并不是让你把收藏动作变得更自动化，而是要把“收集”升级成一条生产线：采集、分析、结构化、复盘、调用。AI 负责把一坨内容变成一张带框架的案例卡，Obsidian 负责把一张张案例卡连成网络，人只负责判断这个案例值不值得入库、结论可不可信。

1. 先想清楚：案例库解决的不是“收集”，而是“调用”

1.1 为什么大多数案例库越建越没用

收集案例的原始冲动来自一个很合理的判断：能火的东西一定有可复制的结构。但大多数人的工作流在这里就停了。看到一篇爆款，收藏、截图、丢进文件夹，完事。

到真正需要的时候，比如下周要做一篇选题，你打开文件夹，面对几百个“当时觉得好”的链接，反而更焦虑。你记不住每条内容为什么火，也不知道应该从哪条开始拆。于是收藏得越多，决策成本越高，最后案例库变成一座只进不出的仓库。

这里有个容易被忽略的点：案例库的价值不在“有”，而在“随时能调出有用结论”。如果没有一个统一的分析结构，哪怕存了一千条爆款，也很难回答“这条案例的钩子是什么”“它用了什么叙述结构”“我能不能把它迁移到我的领域”这类具体问题。

1.2 AI 在这里补的是哪一环

很多人一听“用 AI 搭案例库”，第一反应是让 AI 帮你找爆款、帮你收藏。但这不是关键。

真正关键的工序，是把一条原始素材加工成一张结构化的案例卡。这个工作过去靠人肉，很耗时，所以大家懒得做；现在 AI 可以做初稿，把分析成本压到几乎可以忽略。

比如你看到一篇高赞回答，原来的处理方式是收藏链接，结束。现在可以这样做：把正文、评论区重点和公开数据交给 AI，让它按固定模板输出——选题切口、开头钩子、论证结构、情绪触发点、可迁移场景、一句话总结。AI 第一次给的草稿可能只有六成准确，但你只需要花两三分钟复核修正，这比从零开始分析快太多了。

1.3 这套方案的主判断

我想讲清楚的主判断是：用 AI 搭 Obsidian 案例库，本质上不是“用 AI 帮你存收藏”，而是把案例处理从“收藏—吃灰”变成“采集—分析—沉淀—调用”的完整流水线。Obsidian 负责组织笔记之间的关系，AI 负责降低分析成本，人负责判断和决策。

三者缺一不可。只靠 AI 不靠 Obsidian，分析结果散落在聊天记录里，无法沉淀；只靠 Obsidian 不靠 AI，入库成本太高，坚持不下去；两个都有但没有人的判断，案例库很快就会混入大量 AI 想象出来的结论。

2. 搭前准备：Obsidian 的目录、标签和模板设计

先解决一个基础问题：如果还没装 Obsidian，到官网下载安装包即可，Windows、macOS、Linux 都有对应版本。国内某些网络环境下下载可能偏慢，可以先检查网络，错峰重试，不要因为下载这一关就放弃。装好后新建一个 vault（仓库文件夹），后续所有目录都建在这个 vault 里。

新手很容易上来就追求插件全家桶，其实案例库的骨架不是插件，而是目录和模板。先想清楚结构，插件只是辅助。

2.1 目录结构：按场景分，不按平台分

我见过很多案例库按“抖音爆款、小红书爆款、公众号爆款”建目录，这样建很容易，但使用效率很低。因为同一套钩子和结构会在不同平台反复出现，按平台切分会让相似的思考散落在好几个地方。

我更建议按使用场景或处理流程来组织，例如：

• 00_Inbox：所有新采集的素材先落地到这里
• 10_案例卡：AI 分析完成、人工复核通过的正式案例
• 20_方法沉淀：从案例中提炼出的可复用框架、开头套路、结构模板
• 30_选题输出：已经转化为选题或脚本的待产内容
• 90_附件：图片、PDF、音频等非 Markdown 素材
• _模板：案例卡模板、复盘模板

这套结构的核心是“流动”：素材先进入 Inbox，加工成案例卡，再提炼成方法，最后输出成选题。目录反映的是流程，而不是平台，这样你在做内容时，只需要顺着流程找东西，不需要猜当时收藏时是怎么分类的。

2.2 标签体系：少而稳定的流程标签

标签用多了，最后一定失控。我的经验是，内容属性尽量靠目录和文件名表达，不要什么都打标签。标签只放两类。

一类是状态标签，标记案例目前走到哪一步：

• #待处理：刚进 Inbox，还没用 AI 分析
• #待复核：AI 初稿完成，等人确认
• #已入库：已经是合格的案例卡

另一类是少量内容标签，用来做横向筛选，比如：

• #钩子/数据、#钩子/冲突、#钩子/悬念
• #平台/短视频、#平台/图文
• #状态/已验证、#状态/待验证

原则是：标签总数控制在二十个以内，每个标签都有明确含义和边界，宁可少打，不要乱打。后期标签膨胀是案例库最常翻车的位置，后面排查里会专门讲。

2.3 案例卡模板：给 AI 一个统一的输出结构

模板是整个流程中最重要的一环，既决定了 AI 的分析质量，也决定了以后检索的效率。你给 AI 的模板越稳定，AI 的产出越稳定。

一个基础案例卡模板可以包含这些字段：

--- type: case title: "【案例标题】" platform: "" author: "" url: "" date: "YYYY-MM-DD" tags: - 待复核 status: draft --- # 案例：标题 ## 基本信息 - 平台/作者 - 链接 - 数据表现（阅读、点赞、收藏、转发等） ## 破题方式 - 它切入的是什么问题？ - 切入点有什么反常识或者让人好奇的地方？ ## 结构拆解 - 开头钩子： - 正文推进方式： - 结尾处理： - 数据/故事/案例的分布： ## 情绪与触发点 - 它调动了读者的什么情绪？ - 哪个细节最容易被记住？ ## 可迁移场景 - 这个方法可以迁移到哪些领域？ - 迁移时需要替换掉哪些部分？ ## 一句话总结 - 用一句话讲清楚这条案例的核心方法论。 ## 待跟进 - [ ] 人工复核分析 - [ ] 提炼通用方法

这个模板不用每个字段都写满，但一定要保持字段顺序固定。因为 Obsidian 的优势之一是后续批量处理和统一检索，结构一致才能用 Dataview 或表格视图做汇总。如果每张卡都长一个样，几百条案例放在一起时，你才能扫一眼就知道每条的核心在哪。

3. 核心工作流：用 AI 把案例素材变成案例资产

模板定好之后，才进入真正的工作流。我建议按照“采集—分析—复核—入库”四步走，不要跳步，尤其不要跳过复核。

3.1 采集：让素材先统一落进 Inbox

采集方式的底线是：所有素材必须有一个统一入口。不管是网页文章、公众号内容、短视频页面，还是 PDF 文档，都可以用 Obsidian Web Clipper 这类浏览器扩展一键抓取到00_Inbox，同时把标题、链接、作者等基础信息写进文件开头。

如果在手机端看到素材，也可以手动新建笔记贴进去，但有个原则：先落 Inbox，不要直接写进最终分类目录。理由很简单，你看到素材那一刻的判断，往往不等于你分析完素材之后得出的判断。先统一放进入口，再做加工，能避免大量时间花在“边收集边分类”上，那其实是决策负担。

另外，图片素材的存放建议在库内建一个附件目录统一管理，不要在 Markdown 里贴外链。外链图片一旦失效，整张案例卡就相当于废了一半，重新找素材的成本比一开始就把图存进来高得多。

3.2 定义 AI 的输入和分析要求

拿到原始内容后，AI 的分析质量取决于两件事：输入是否完整，输出格式是否严格。

很多人的做法是只把链接丢给 AI，说“帮我分析一下这篇为什么火”。如果这个 AI 工具没有联网能力，它根本看不到内容，只能给你一堆放之四海皆准的套路。因此，要么选择支持联网检索的对话工具，要么把正文粘贴进提示词里，二选一。

比较稳妥的提示词结构是这样：

你是一名内容策略分析师。下面我会给出一篇案例的完整内容，请你按照模板逐一分析。 模板字段： 1. 破题方式：它切入的问题是什么？ 2. 结构拆解：开头、正文、结尾分别怎么处理？ 3. 情绪触发点：它调动了什么情绪，用了什么细节？ 4. 可迁移场景：这个方法能迁移到哪些领域？ 5. 一句话总结：用一句不超过 30 字的话概括核心方法论。 要求： - 每个字段都必须输出，如果没有足够信息，写“资料不足，需人工补充”。 - 不要添加模板之外的新字段。 - 输出使用 Markdown 格式。 以下是案例内容： [把正文粘贴到这里]

这里有一个容易忽略的点：一定要让 AI 在没有足够信息时明确标注“资料不足”，而不是脑补。不然你得到一份看着完整、实则全是猜测的分析，复核成本比你自己写还高，那就失去用 AI 的意义了。

3.3 批量处理：先小批量验证，再放开

当你积累了一批素材，可能会想一次性把所有内容丢给 AI 批量分析。我的建议是：先拿三五条测试，别上来就跑全量。

原因有三个：

1. AI 工具的上下文长度有限，一次塞太多正文，后面的内容可能被截断，导致分析质量明显下降。
2. 批量模式下，模板不一致的概率更高，可能这一条输出三行，下一条输出八行，后期整理很痛苦。
3. 如果你用的是 API 调用，批量跑前最好先估算 token 成本。内容特别长的视频转写或长文，成本会快速上升。

更合理的做法是按天、按周批量处理：每次攒 5 到 10 条，跑一轮 AI，然后统一复核入库。这样既保留了批量的效率，又不会让复核堆积成山。

在实际接入方式上，常见做法有三种：复制粘贴到对话式 AI 工具里人工发起分析；通过 Obsidian 里的 AI 插件读取当前笔记并调用模型生成；或者自己写脚本批量调用 API，把结果写回 Markdown 文件。第一种成本最低，适合刚开始用；第三种效率最高，但需要一点编程基础。我建议从第一种开始，流程跑通了再考虑自动化，不要一开始就折腾脚本。

3.4 人工复核：只做判断，不重写

AI 生成的分析草稿，即使格式工整，也要经过你的复核。复核时不需要逐字改，重点检查三个位置：

• 事实性信息：平台、作者、链接、数据表现是否准确？
• 关键结论：它说“开头用了冲突式钩子”，你同意吗？如果不同意，为什么？
• 可迁移性：它提出的迁移场景是否真的成立？会不会太泛？

复核完之后，把标签从#待复核改成#已入库，再顺手把文件从 Inbox 移到10_案例卡目录。

这一步不能省。AI 的分析能力是在进步的，但“这条案例适不适合我所在领域”这件事，AI 永远不如你了解。你可以让 AI 分担工作量，但决策权必须留给自己。

4. 让案例库真正“用起来”：双链、检索和选题转化

很多人的案例库死在建好之后。真正让案例库活起来的，不是入库数量，而是调用频率。

4.1 用双链把案例连成网

Obsidian 和普通文件夹工具的本质区别是双链。案例之间如果只是各自独立的文件，价值仍然有限；一旦你能在一张新案例卡里看到“和这篇案例相关”的旧笔记，就会触发很多之前想不到的思路。

双链不建议主动大量加。我的做法是：入库时只加两种链接。一种是“相似案例”，把同类型、同平台的案例链在一起；另一种是“方法来源”，把案例链接到它在20_方法沉淀目录下对应的方法笔记。

更好的做法是，在方法笔记里反向维护一个清单。比如你写了“冲突式开头五要素”的方法笔记，把每一条符合这个方法的案例都列在里面。这样当你需要做选题时，看到方法笔记，就等于看到了所有可参考的案例。

4.2 检索方式：至少掌握三种

案例库一旦超过两百条，靠“回忆文件名”来找案例就不可靠了。至少要掌握三种检索方式：

1. 搜索：Obsidian 内置搜索，支持关键词、路径、标签。快捷键建议先记住，这会显著提升日常使用效率。
2. 标签筛选：用#钩子/冲突这类标签横向筛选，适合已经知道自己要什么类型的能力点。
3. Dataview 表格视图：如果你愿意写一点查询语法，可以把案例卡按平台、状态、日期生成动态表格，每次打开就是一张最新索引。

Dataview 不是必须的。如果你的索引需求不复杂，用搜索和标签就能覆盖大部分场景；但如果案例库要长期维护，Dataview 会在后期省下大量手工整理时间。有一点要注意：Dataview 依赖模板里 YAML 字段的稳定，所以前面说的“结构统一”会直接决定这个功能能不能用。

4.3 从案例库到选题清单

案例库最终要产出的是行动，不是自我感动。我通常会给每个案例卡补一个“如果我要模仿它”的字段，这不是模板里的固定字段，而是一句自由写的判断。

比如某条案例卡里，AI 已经分析出“用具体数字制造反差”这个结构，我会在下面补一句：“可尝试迁移到本行业，用成本数据制造认知冲突。”

然后每个月底把一个月入网的案例卡过一遍，挑出三到五条真正可迁移的，转成30_选题输出目录下的选题笔记，再在里面写标题候选、结构大纲、预期目标。这样案例库与内容生产之间就连成了一条完整的循环：案例在库，选题在写，写完再入库，持续迭代。

5. 最容易翻车的环节与排查链路

维护一个案例库，真正考验人的不是搭建，而是持续运行。下面这些是我自己踩过、也看别人踩过的坑，按排查顺序来讲。

5.1 结构不统一，后面全是病

现象：有的案例卡是完整表格，有的是几句话带过，有的连 URL 都没有。

排查链路：

1. 先看模板是否被改动过。如果模板已经变了，先统一模板版本。
2. 再看是不是 AI 输出格式漂移。批量处理时最容易出现，让 AI 严格按模板输出，必要时在提示词里给一个完整样例。
3. 再看是不是人工入库时偷懒。如果全流程都规范但仍有例外，那就是执行纪律问题，不是工具问题。

结构不统一的危害不在当下，而在三个月后：当你用 Dataview 统计案例类型时，会因为字段缺失得到一堆空值，等于整个索引失效。

5.2 AI 输出不等于事实

现象：AI 把“可能”说成“一定”，把用户评论中的一句吐槽理解成沉默多数，甚至给一个不存在的阅读量。

排查链路：

1. 数据类信息，必须回原文核对。阅读量、点赞、转发这些数字最好在采集时就记录下来，不要依赖 AI 回忆。
2. 因果判断类信息，回看原文论证。AI 说“这里用了稀缺感”，你自己判断是不是真的。
3. 在提示词里加“不确定就写资料不足”，能显著减少 AI 的脑补，但不能完全消除。

如果你发现某个 AI 工具在某个专业领域的分析经常跑偏，最好换一个工具，或者在提示词里多提供该领域的背景信息。不要指望一个模型通吃所有领域。

5.3 标签和链接膨胀

现象：标签越加越多，最后连“钩子/微恐怖”这种只有一条案例使用的标签都出来了；双链乱连，案例间失去了筛选价值。

排查链路：

1. 定期做标签审计：每季度导出标签列表，凡是只有一两条笔记的标签，合并或删除。
2. 给链接定规则：入库时只加“相似案例”和“方法来源”两类链接，其余诉求用搜索解决。
3. 如果已经膨胀，从标签数量最多的那批笔记开始清理，不要指望一次性搞完。

标签这东西，少的时候是导航，多的时候是噪音。判断标准很简单：如果打标签比检索还费时间，这标签就不该存在。

5.4 长期不更新，根因通常是成本太高

现象：案例库建了一个月，里面只有十几条，后来彻底不动了。

排查链路：

1. 先看采集成本：如果每次采集都要手动整理很多内容，说明入口太繁琐，优先优化 Inbox 流程，比如用 Web Clipper 一键抓取。
2. 再看加工成本：如果每次 AI 分析要复制粘贴、切换多个工具，说明可以把分析做成固定工作流，或者用 Obsidian 的 AI 插件在笔记内直接生成。
3. 最后看使用收益：如果你从来没从案例库返查过任何内容，说明你还没想清楚“我到底要用它解决什么问题”。

很多人以为不更新是因为懒，其实是因为流程没有正反馈。反过来说，只要你能从案例库里调出一次对实际内容创作有影响的结论，后续维护的积极性会完全不一样。

6. 适用边界：这套方案适合谁、不适合谁

任何工作流都有边界。这套“AI + Obsidian 案例库”的方法并不适合所有人，下面拆开讲。

6.1 建议直接尝试的人群

• 内容创作者、运营、编辑，需要持续产出选题和内容的人。
• 刚开始做知识管理、希望把零散收藏整理成可复用资产的人。
• 对 AI 工具有一定耐心，愿意先跑通流程再追求效率的人。
• 已经用过 Obsidian 基础功能，但还没有形成自己整理方式的人。

这类人的共同点，是正处于“素材很多但用不上”的瓶颈期，这套流水线能直接解决调用问题。

6.2 不建议硬套的场景

• 只是想快速找几个爆款链接，不需要深度分析的，这种情况用收藏夹就够了，搭一套体系反而是负担。
• 不愿意做人工复核，想全自动入库的。没有判断的案例库，只是一堆 AI 幻觉的集合。
• 已经有一整套成熟内容生产系统，只是在找新工具的人。Obsidian 的优势在于学习、思考、积累型场景，重协作的生产团队不一定需要迁移。

如果属于这些情况，建议先不要急着搭库。先明确自己的需求是“存”还是“用”，再决定要不要投入时间。

6.3 别忘了 Obsidian 本身的边界

Obsidian 是本地 Markdown 文件，天然适合个人知识库。但它不是协同内容管理系统，也不是数据报表平台。如果你的案例库需要多人同时维护、审批、发布，可能要结合其他系统来完成，不要指望 Obsidian 一个工具解决所有问题。

另外，Obsidian 的底层是本地文件，所以备份非常重要。至少保证 vault 目录在云端同步一份，或者定期手动备份。本地文件一旦磁盘损坏，几千条案例卡可能一夜之间归零，这个风险不值得冒。

案例库这种东西，建起来很容易，跑起来很难。很多人的失败不是因为不知道工具，而是把“收藏”当成了“积累”。

AI 能帮你在几分钟内把一条素材变成一张有框架、有判断、能调用的案例卡，Obsidian 能帮你把这些卡片组织成一张越来越密的网，但真正决定这套系统能不能持续运转的，还是你自己会不会在每次入库前问一句：这条案例，值得我花三分钟复核吗？值得，就留下；不值得，就删掉。

把标准定高一点，案例库最终会回报你。不是因为它装了多少爆款，而是因为它积累的是你反复确认过的判断。