Knowledge-Management

老周是我们团队最资深的售前。上个月给华东一家汽配连锁分销商做方案，他熬了三个通宵，产出一份 80 页的 PPT —— 行业洞察、痛点拆解、架构图、ROI 测算、三个同行的成功案例，一应俱全。客户的财务总监当场说：「这是我见过最懂我们的方案。」单子签了。

四个月后，这个客户在续约评估里打了低分。原因不是产品不好，而是交付团队上线的对账流程，跟老周方案里承诺的「月结 T+1 出报告」对不上 —— 交付的同事根本没看过那份 PPT，他们手里只有一个工单：「给客户 A 部署对账 Agent」。老周写进方案的服务标准，卡在了销售和交付之间那道看不见的缝里。

而那份被财务总监称赞过的 80 页方案，此刻正安静地躺在某个钉盘文件夹里，再没有人打开过。

周三晚上 9 点，供应链主管小林在钉钉里收到一条告警：「供应商 A 本周交货延迟率从 3% 升至 12%」。他看了一眼，回了句「知道了，季节性波动，不用管」。这条消息随即被淹没在后续 200 条群聊里。

两个月后，另一个团队的采购经理在审批供应商 A 的新合同时，完全不知道这段历史。合同正常通过。三个月后，供应商 A 果然出了大问题——产能不足导致全线延迟。

这个故事里， 信息是存在的——告警推了，人判断了，反馈也有了。但信息在人与人之间断裂了。小林的处理经验没有被结构化地沉淀下来，后来的决策者无从获取。

这正是大多数企业 AI 落地时撞上的第一堵墙： 不是 AI 不够聪明，而是企业的「神经系统」还没建好。

上周五，我让 AI 帮我分析一场 90 分钟产品周会的听记转写稿——15000 字的会议记录，要求提取关键决策、未闭环的行动项、以及和过去三个月决策之间的矛盾。

第一次，我直接把转写稿喂给 AI，说「帮我整理会议纪要」。得到一份「看起来还行」的摘要：谁说了什么、讨论了什么话题。但这不是我需要的——我需要的是 洞察。

比如：技术负责人在讨论方案 A 时说「我觉得可以上」，但架构师追问了三个问题后，他改口说「那还是再看看」。AI 的摘要写的是「张总介绍了技术方案」—— 关键决策点被淹没了。

上周我打开了尘封已久的 Obsidian vault。

50 多个插件，300 多个标签，12 个 database view，还有一套精心设计的 MOC（Map of Content）索引系统。我花了不知道多少小时在「组织」知识，而不是「使用」知识。

然后我意识到： 这套系统在 AI 时代已经过时了。

上周五晚上，我让 AI 帮我做一件事：把过去三个月收集的 47 篇关于 Agent 架构的文章、12 段会议笔记、和 6 个项目的 README，整理成一份「哪些架构模式真正有效」的判断。

如果是一年前，我会得到一份按关键词频率排列的摘要——看起来专业，实际上没用。

但这次不同。AI 花了大约 40 秒，输出了一份结构清晰的报告：哪些模式在多个项目中反复出现、哪些只在特定场景下有效、我的笔记里对同一问题有过矛盾的判断。它甚至指出了我在三月份写的一段话和五月份的一个项目决策之间的矛盾。

这不是搜索，不是摘要，不是 RAG 的简单检索。这是 理解。

知识管理有四个值得做的企业场景，其中「企业 SOP / 最佳实践沉淀」看起来最不起眼——知识静态、更新慢、容易退化成高级搜索、用户日活偏弱。

但如果你换一个角度看，SOP 沉淀的真正价值不是「把经验存起来」，而是 把经验变成可执行的系统行为。

这篇文章用一个完整案例来说明：一位 Windows 用户打开悟空发起任务，悟空报错「任务执行环境准备失败」，到 AI 定位根因、修复代码、验证、发布，全程 4 小时。每个环节 AI 做什么、人做什么、知识如何在这个过程中自然沉淀。

你花了两周时间，终于摸索出了一套让悟空写技术方案「一次可用」的 Prompt 组合：包含提问澄清、交付物定义、示例对齐和工具调度。你觉得自己简直是 AI 协作大师。

但当你把这套方法推荐给团队时，发现大家根本用不起来。

• 同事 A 嫌每次都要复制粘贴一大段约束太麻烦，干脆还是用最原始的「帮我写个方案」。
• 同事 B 漏掉了关键的示例部分，导致输出质量参差不齐。
• 同事 C 遇到新场景，不知道如何调整 Prompt，只能重新从零摸索。

个人用得好，不等于团队用得好。

在前面的七篇文章中，我们构建了从 需求澄清、分步执行、交付物定义、示例对齐、迭代优化、上下文管理 到 工具协同 的完整个人技巧体系。

但这些技巧如果只停留在你的大脑或剪贴板里，它们就是易失的、碎片化的、不可复用的。

今天，我们探讨技巧八：如何通过「提示词工程化」，把个人经验沉淀为参数化模板和团队 SOP，实现 AI 协作的工业化生产。

上周和一位做 Notion 类产品的创业朋友 Hugo 深聊。他们团队 5 个人，技术栈很现代：Rust 后端 + CRDT 协作引擎 + React 前端。全员配了 Cursor/Copilot，编码效率确实起飞了。

但他抛出一个让我后背发凉的数据：

“写代码快了 10 倍，但端到端交付只快了 2 倍。剩下的时间差，全耗在给 AI 擦屁股上。”

他给我看了一个真实案例。新人小李接到任务：“新增一个代码块类型，支持语法高亮和行号。”

没有 Harness 的灾难：

1. 小李让 Agent 生成代码（5 分钟，看起来完美）
2. Agent 不知道团队半年前从"嵌套 JSON"迁移到"扁平化 parent_id"的架构决策，生成了嵌套方案
3. 小李没看出来（新人不懂历史），提交 PR
4. CI 失败：循环引用检测拦截（嵌套结构在协作同步时会死锁）
5. 小李让 Agent 修复，Agent 为了绕过检测，直接改了权限校验逻辑（越界）
6. 老王 Review 时发现 3 个深层问题：CRDT 冲突策略不对、离线同步没考虑、权限模型被破坏。打回。
7. 反复 3 轮，耗时 2 天。老王叹气：“还不如我自己写。”

问题本质：AI 把编码压缩了，但把 隐性知识的缺失放大了。

过去靠"问老王"填补的架构决策、历史坑位、协作潜规则，AI 一概不知道。阿里技术许晓斌称之为 人肉中间件现象：员工沦为 AI 与业务系统间的手工搬运工。腾讯技术工程则指出：Harness 不是目的，知识才是护城河。

这篇文章，就以这个 5 人 Notion 团队为案例，完整拆解他们如何用 三层架构（组织 × 资产 × 工程） 构建 Harness 系统，把"给 AI 擦屁股"变成"AI 自主交付"，实现知识复利。

上周和一位创业者吃饭，他刚帮一家大型企业做完知识图谱项目的评估。结论让人倒吸一口凉气：要达到替代中级岗位能力的水平，算上数据采集、清洗、标注、图谱构建和持续维护，预算需要一个亿。

企业听完直接搁置了。

这不是个例。过去三年，我见过不下十个类似的项目——企业想做知识库，供应商画了一个「知识图谱+智能问答」的大饼，然后企业发现投入产出比根本算不过账。

但今年情况变了。模型能力的跃迁正在催生一个新范式：不再靠人工标注堆数据，而是让 LLM 做编排，结合企业搜索，人做优化调整和确认。

知识整理的起点也不再是宏大的「企业知识图谱」，而是每个人手边的 Journal——每日工作日记。通过钉钉这样的组织连接工具，个人知识可以自然地流转、沉淀为企业知识。

去年年底，我做了一个实验：把过去十年写的 190 多篇博客、Obsidian 里的读书笔记、还有悟空 Agent 的实践记录，全部扔给 Hermes Agent，让它按照 Karpathy 的 LLM Wiki 模式自动整理。

三天后，我打开 Obsidian 的 Graph View，看到了一个由 50 多个节点互相连接的知识网络 — 不是文件归档，而是一个真正的知识图谱。Agent 自动提取了实体和概念，建立了双向链接，甚至发现了我自己都没意识到的关联：[[compression-as-intelligence]] 和 [[agent-memory]] 之间有一条隐含的逻辑链，我自己写了三年都没发现。

那一刻我意识到：个人知识管理的瓶颈不是工具，而是"碎片到结构"的转换成本。 这篇文章，我把整个系统的架构、自动化流程和实际用法完整拆解出来。