灵枢 · 学生社团智能知识中枢

这个项目是什么

灵枢是我给上海交大国学社做的一个 AI 知识平台。核心是三件事：把散落了 12 年的社团资料整理成结构化知识库，在这个知识库上搭一个能对话的 AI Agent，再做一套数据仪表盘来可视化社团的运营状态。

Agent 部分搭在 Coze 上，通过飞书文档知识库接入，提供三种能力：知识中枢（回答社团相关的知识性问题）、决策辅助（根据历史经验快速生成活动策划初稿）、宣传助手（为文宣部生成不同平台风格的文案）。

PPT 上写了三个人的名字，但说实话，产品设计、数据管线、Agent 搭建，基本都是我一个人做的。

为什么做这个

我自己当过社长，深知每年换届是什么感觉——新社干面对的不是能力不足，而是上下文丢失。国学社建社 12 年，积累了 5521 个文件、总共 22.22 GB 的资料，散落在 8 届社干、12 个人的电脑和云盘里，用了 4 种不同的存储介质。更离谱的是，有整整一个学年的资料几乎完全丢失了。

我做过一个用户旅程分析：文秘部策划一次大型摆摊活动，从理解母题到最终落地，人工检索和处理文档的时间占了活动总时长的 60% 以上。中间经历的情绪从兴奋、困惑到焦虑、烦躁，最后变成苦恼和担忧——不是活动本身难，而是「找到以前怎么做的」这件事太难了。

我想做的事情其实很朴素：让社团的知识像一个有经验的老社员一样，随时可以问。

我做了什么

项目大致分三块：

知识库建设是最重的一块。我用 Selenium 从公众号后台爬取了历届推送（扫码登录、获取 token、拼接 URL、拉取元数据和正文页面），然后用 BeautifulSoup 解析 HTML、python-docx 写入 Word 文档——因为飞书知识库可以直接上传 Word 转在线 Markdown。听起来简单，但公众号编辑器多次迭代过，加上秀米等第三方编辑器的 HTML 结构完全不一样，光是处理这些格式差异就花了很多时间。最终抓取了 876 篇推送，连同元数据一起灌进了飞书多维表格。

知识聚类与标签是我觉得最有意思的部分。876 篇推送里有 158 篇是读书会、专栏这类强知识内容。我先试了 LDA 主题模型——初始词典 9877 词，过滤后 1159 词，调了 8 个主题、25 passes、400 iterations，最终 Coherence Score 只有 0.415。结果能用但达不到业务层面的要求。后来我换了一个策略：从 LDA 提取的核心主题里抽象出 18 类标签，让 LLM 根据这些标签对文章分类，同时允许它提出新类别。效果好很多，分出了 28 个类别，后期只需少量人工微调。

Agent 搭建反而是最快的部分——Coze 上拖 workflow，接飞书文档知识库，做意图识别分流。技术含量不高，但确实让社干能用自然语言和社团知识交互了。

过程中的思考

做灵枢到后来做「开阳」（灵枢的迭代版本，基于 OpenClaw 框架），我一直在想一个问题：架构设计的「唯手熟尔」和模型能力的快速迭代之间，存在一种张力。

灵枢的时代，我需要非常小心地把任务拆分成 LLM 能处理的粒度——用 LDA 做粗分类、用 LLM 做精分类、用人工做兜底。这套 pipeline 设计得越精巧，每一步都越依赖我对任务边界的判断。但模型能力在几个月内可能就会跨过某个阈值，让整个精巧的拆分变得多余。

2026 年 4 月我开始做开阳的时候，很多灵枢时代需要复杂工作流才能完成的任务，用新一代模型直接就能做了。灵枢在 Coze 上本质是一个 workflow，火山引擎的额度和模型能力都有限，效果并不理想。而开阳基于 OpenClaw，可以直接接入飞书事件、操作文档、创建任务——从「知识检索」进化到了「行动执行」。

但灵枢沉淀的知识库极大地降低了开阳冷启动的难度。回过头来看，灵枢最大的产出不是那个 Agent，而是那个知识库。 Agent 会过时、会被替代，但整理好的知识本身是有复利的。

不过灵枢时代的知识库有一个致命问题：它是静态的。知识库一旦搭建完成，就没有自动更新的机制。「知识库维护」在 2025-2026 年间一直挂在 P0 名单上，但始终没人做——因为手动维护的成本太高，而 Coze 上的 Agent 根本没有写回知识库的能力。这也是促使我做开阳的直接原因之一：开阳可以直接写飞书文档、编辑知识库。虽然目前还没开放全量权限给它，但小范围测试已经可行了。从”只读知识”到”可读可写”，这一步看起来小，但意味着知识库终于有机会从一个需要人维护的静态资产，变成一个能自我生长的活系统。

这让我对做 AI 产品有了一个很底层的认知：不要太执着于 Agent 的架构有多精巧，而是要关注你沉淀了什么不会被模型迭代淘汰的资产——以及这些资产能不能自己长。

Q&A

Q: 876 篇公众号推送的爬取和治理，最坑的地方在哪？

公众号 HTML 结构不统一这件事，比我预想的严重得多。国学社公众号从 2017 年运营到现在，早期用微信自带编辑器，后来换了秀米，中间还有人直接从 Word 粘贴。三种编辑器产出的 HTML 嵌套方式完全不同。我不能写一个通用 parser 就了事——得针对不同时期的文章分别处理。最后大概写了五六套解析策略，用发布时间来启发式判断该用哪套。

Q: LDA 的 Coherence Score 0.415 意味着什么？为什么说达不到业务要求？

0.415 在学术论文里大概算是”还行”的水平，但放到实际业务场景里，分出来的主题对社干来说不够直觉。比如 LDA 会把「读书会」和「国学社」分到同一个主题里——从词共现的角度这没问题，但从社干的视角看，读书会和社团日常运营是两件事。最后我发现与其指望无监督方法给出业务可用的分类，不如先用 LDA 跑一遍看看数据的大致分布，然后从中提炼出人可以理解的标签体系，再让 LLM 按这个标签体系去分类。相当于 LDA 做数据探索，LLM + 人做最终决策。

Q: 灵枢已经被开阳替代了——如果现在回头看，灵枢最大的价值是什么？

知识库。毫无疑问是知识库。开阳冷启动的时候，灵枢沉淀的飞书知识库直接就能用，省去了至少两个月的数据整理时间。灵枢的 Coze Agent 本身已经没人用了，但知识库每天都在被查阅。这件事让我意识到，做 AI 产品的时候，最持久的价值往往不在 AI 那一层，而在你为了让 AI 能工作而做的数据治理。

Q: 你怎么看 Coze 这类低代码 Agent 平台？适合什么场景？

快速验证想法挺好的，尤其是当你一个人、时间有限的时候。但它的天花板很明显——本质上你在拖拽 workflow，能做的事被平台的抽象框住了。灵枢在 Coze 上最大的痛点是火山引擎模型的能力上限和 token 额度限制。当我需要更灵活的事件驱动和飞书深度集成时，Coze 就不够用了，所以才有了开阳。但如果只是做一个”读知识库、回答问题”的 MVP，Coze 的效率确实很高。

Q: 做这个项目期间最有成就感的瞬间？

是那个 LDA 不好使、换 LLM 辅助标签的时刻。本来花了好几天调 LDA 的参数，结果怎么调都不理想，一度觉得这条路走不通。后来想到”用 LDA 做探索、用 LLM 做决策”这个组合的时候，有一种”哦，这才对”的感觉。30 分钟就把 876 篇文章分好了类，而且质量比我手动分还准。这个时刻让我真正相信 AI 产品不是”AI 能力越强越好”，而是找到人和 AI 各自擅长的部分，然后组合起来。

Q: 「灵枢」和「开阳」这两个名字有什么讲究？

都是北斗七星的名字。灵枢是天枢的别名，北斗第一星，在斗口——它是整个斗的枢纽，所有指向都从它开始。给知识中枢取这个名字，是因为它的定位就是社团知识的枢纽：所有信息汇聚于此，所有查询从这里出发。开阳是北斗第六星，在斗柄靠近末端的位置——古人说”辅星傅乎开阳，所以佐斗成功”，开阳旁边有一颗小伴星叫「辅」，两者搭配才能发挥作用。开阳的定位也是如此：它不是独立工作的，而是辅助社干在飞书现场完成操作的。从天枢到开阳，从斗口到斗柄，从”知识汇聚”到”行动执行”，恰好对应了这两代产品的演进方向。