大多数团队的共享 Project 第一周看着体面，三个月就烂了。有人上传了二十个文件，三个人各传了一版品牌指南，去年的策略文档没人归档，到了 Q2 团队就悄悄不再用它。本文就是那套能撑到半年后还在被人问问题的结构。
本文涵盖
怎么定义、填充、维护一个共享 Project，让下个季度才入职的第三号新人能去问它、并且得到团队认可的答案。包括 owner 机制、文件卫生、指令纪律、以及防止漂移的季度复盘。
这篇适合谁
团队负责人、运营、过了 5 人门槛的创始人，以及那些被告知”知识管理你来负责”但没人给一套方法的同学。如果你们团队已经付了 Claude Team 或 Enterprise，而共享 Project 功能几乎没人在用，这套就是为你写的。
什么时候上
当至少 3 位同事每月不止两次问同一个”需要大段背景”的问题、入职流程里频繁出现”去问 Sarah”、或者你自己一直在把同一份品牌/产品资料粘进各种私聊时，就该上。团队不到三人就别折腾，直接发消息更快。
开始之前
- 指定一个唯一 owner。没有 owner 的共享知识就是共享腐烂。owner 不必什么都写，但必须决定什么留下来。
- 列出团队成员每月反复问的 5-10 个高价值问题。这些问题决定你需要哪些 Knowledge 文件，而不是反过来。
- 先划清范围：品牌、产品、决策、客户 FAQ。其他东西另开 Project。一个大杂烩 Project 是最常见的失败形态。
- 把要导入的文档原作者拉进来打招呼。突袭式合并会破坏信任。
步骤拆解
- 用”产出导向”的名字建 Project：“Q3 对客回答”比”客服知识库”好得多。产出导向的名字逼 owner 必须定义”完成”的样子。
- 第一天 Knowledge 最多放 5-8 份文件：品牌语气文档、当期定价表、Top-10 FAQ、电梯陈述、最新一页路线图。忍住一次性把整个 Notion 搬进来的冲动。
- Instructions 要写清楚这个 Project 是干什么的、不干什么的：“以我们客服团队的语气回答。永远不要编造价格。被问到未公开功能时拒绝回答并指向路线图文档。” 约束类指令的价值大于角色类指令。
- 跑一次校准会。让 3 位同事用他们真实在问的问题去问 Project，截图保存答案。哪条不对，就改 Knowledge 文件，而不是改 Prompt。Prompt 层的修补禁不住别人换种问法。
- 在 Knowledge 里加
decisions.md和changelog.md。团队每做一个决定（“功能 X 下线""Q4 起调价”），owner 写一条带日期的记录并重新上传。这是全流程里杠杆最高的一个习惯。 - 在 owner 日历上排一个每月 30 分钟的复盘。打开每一份 Knowledge 文件看日期，超出对应周期（定价按季度、品牌按年）的归档。大部分 Project 不是被烂文件搞死的，是没人剪枝搞死的。
第一次跑一遍
- 挑团队群里上周真实被问过的 3 个问题。不要美化，直接用原话。
- 把这三个问题原封不动丢进 Project，截图答案。
- 给每个答案打标签：“可直接发给客户""需要修改""错误”。新 Project 跑出 50% 直接可用、30% 需修改、20% 错误算正常水平。
- 对每个”错误”答案，判断该改的是 Knowledge（缺事实）还是 Instructions（语气不对）。一次只改一处，再跑一遍。同时动两处变量等于啥都没学到。
质量自检
- 新人能不能不问活人就拿到 Top-5 问题”够格发出去”的答案？拿不到就说明 Knowledge 不全。
- 同一个问题换三种问法，答案是否一致？答案大幅摇摆说明 Instructions 用得太重、Knowledge 用得太轻。
- 该拒答的真的拒答了吗？定价、未公开功能、法律意见，挨个测一遍。
- 每份 Knowledge 文件首行是不是都写了日期？没日期的文件迟早烂。
怎么把这套流程复用起来
- 把 Instructions 整段做成模板，10 分钟就能克隆一个姐妹 Project（销售、招聘、研发）。
- 维护一份”起步文件清单”：品牌语气、术语表、Top-10 FAQ、当前路线图、决策日志、变更日志。每个 Project 都从这同样的六个槽位开始。
- 把每次”错误”答案记进
lessons.md，写明日期和根因。攒到 20 条左右就会看出规律——大概率是时效问题，不是事实缺失。 - 每季度 30 分钟跨 Project 审一次。所有 owner 到场，让漂移被点名。
推荐链路
owner 用产出导向命名建 Project → 放 5-8 份首行带日期的 Knowledge 文件 → 写带明确拒答的 Instructions → 拉 3 位同事用真实问题校准 → 改到 50% 以上可直接发出 → 加 decisions.md 和 changelog.md → 日历上排好每月剪枝 → 季度跨 Project 审计。
容易踩的坑
- 没 owner。责任分散等于没人剪枝，四个月就死。
- 第一天把整个 Notion 都倒进去。文件超过十份后检索就开始变糙。
- Project 取了个不带产出的名字（比如”市场”），范围立刻失控。
- 没写拒答指令。同事第一次问价格时，Project 就会自信地编一个。
- 让 Knowledge 文件没有日期，等于无法剪枝。
- 在本地改文件却忘了重新上传。对话用的还是旧版本，跟新政策直接打架。
- 把聊天记录当成团队记忆。聊天是私有的、易丢的，文件集才是耐久的记录。
FAQ
- 需要哪个套餐？: Team 或 Enterprise。个人版没法跨同事共享 Project。
- 文件多少算多？: 活跃文件超过 15-20 份检索就明显变差。再多就按产出导向拆成多个 Project。
- 同事能不能改 Knowledge？: Team 版可以，但”人人可改”和 Confluence 的失败模式一样。所有变更走 owner 集中收口。
- 共享 Project 的聊天记录互通吗？: 不互通。每位同事在共享 Project 里有自己的私有聊天。重要决定要写进
decisions.md。