大多数团队的共享 Project 第一周看着体面，三个月就烂了。有人上传了二十个文件，三个人各传了一版品牌指南，去年的策略文档没人归档，到了 Q2 团队就悄悄不再用它。本文就是那套能撑到半年后还在被人问问题的结构。
一句话总结
- 一个共享 Project 需要：一个指定的 owner、第一天 5-8 份带日期的 Knowledge 文件、以及写明”拒答什么”的 Instructions。剩下的都是维护。
- 想跨同事共享 Project，必须用 Team 套餐（截至 2026 年 6 月，每席位 $25/月，按年付为 $20/席位/月）或 Enterprise。Pro 和 Max 都是单人版。
- 把 Project 设为 Private，默认给同事 “Can view” 权限，“Can edit” 只留给 owner。“人人可改”和当年搞垮你们 wiki 的失败一模一样。
- 杠杆最高的一个习惯：owner 维护一份
decisions.md、追加后重新上传，再配一个每月 30 分钟的剪枝。Project 不是被烂文件搞死的，是没人剪枝搞死的。
本文涵盖
怎么定义、填充、维护一个共享 Project，让下个季度才入职的第三号新人能去问它、并且得到团队认可的答案。包括 owner 机制、文件卫生、指令纪律、权限模型，以及防止漂移的季度复盘。
这篇适合谁
团队负责人、运营、过了 5 人门槛的创始人，以及那些被告知”知识管理你来负责”却没人给一套方法的同学。如果你们团队已经付了 Claude Team 或 Enterprise，而共享 Project 功能几乎没人用，这套就是为你写的。
你需要哪个套餐：先把账算清
跨同事共享 Project 是 Team 或 Enterprise 才有的能力。个人版（Pro、Max）的 Project 只属于单个账号。下表数字截至 2026 年 6 月。
| 套餐 | 价格 | 团队规模 | 能否共享 Project | 适合 |
|---|---|---|---|---|
| Pro | $20/月（年付 $17） | 1 人 | 不能（单人） | 个人知识库 |
| Max | $100（5 倍）/ $200（20 倍） | 1 人 | 不能（单人） | 重度个人使用 |
| Team（标准席位） | $25/席位/月，年付 $20 | 5-150 席位 | 能 | 大多数小团队 |
| Team（高级席位） | $125/席位/月，年付 $100 | 5-150 席位 | 能，用量 6.25 倍 | 团队里的重度用户 |
| Enterprise | 定制 | 通常 70+ | 能，含 SSO/审计 | 合规要求高的组织 |
下单前还有几个细节值得知道：
- 最少 5 个席位。 Team 不是给单人用的，起步就要付至少 5 个席位。
- 标准席位是 Pro 用量的 1.25 倍，高级席位是 6.25 倍。 把席位类型混搭：owner 和最重度的人用高级席位，其余用标准席位。
- 所有席位都能用 Claude Opus 4.7 和 Sonnet 4.6，上下文窗口 100 万 token（截至 2026 年 6 月）。知识库问答用 Sonnet 4.6 当主力就完全够。
什么时候上
当至少 3 位同事每月不止两次问同一个”需要大段背景”的问题、入职流程里频繁出现”去问 Sarah”、或者你自己一直在把同一份品牌/产品资料粘进各种私聊时，就该上。团队不到三人就别折腾，直接发消息更快。
Project 知识到底怎么工作
搞清楚检索机制，会改变你装文件的方式：
- 小知识库会整体进上下文。 只要文件能塞进 100 万 token 的窗口，Claude 每条消息都会把它们全部读一遍。
- 超过之后，Claude 切换到检索（RAG）。 Anthropic 官方说明 RAG 能把有效容量扩大最多 10 倍，且仅对付费套餐（Pro、Max、Team、Enterprise）开放。代价是：Claude 此时只抓最相关的片段，而不是通读全部，所以埋在第 19 份文件里的一条事实可能被漏掉。
- 单文件上限 30MB。 文件数量没有硬上限，但堆得越多，检索质量越糙。这才是要把文件集控紧的真实原因，而不是配额。
实际启示：每多一份低价值文件，都会让高价值答案稍微变差一点。哪怕窗口很大，也要当它很小那样去精选。
开始之前
- 指定一个唯一 owner。 没有 owner 的共享知识就是共享腐烂。owner 不必什么都写，但必须决定什么留下来。
- 列出团队成员每月反复问的 5-10 个高价值问题。 这些问题决定你需要哪些 Knowledge 文件，而不是反过来。
- 先划清范围： 品牌、产品、决策、客户 FAQ。其他东西另开 Project。一个大杂烩 Project 是最常见的失败形态。
- 把要导入的文档原作者拉进来打招呼。 突袭式合并会破坏信任。
步骤拆解
- 用”产出导向”的名字建 Project。 “Q3 对客回答”比”客服知识库”好得多。产出导向的名字逼 owner 必须定义”完成”的样子。
- 把可见性设为 Private，再把同事加成”Can view”。 在 Claude 里，Project 分 Public（全组织）和 Private（受邀成员）；私有项目的成员要么是”Can view”（可读可聊），要么是”Can edit”（可改指令、知识和成员权限）。把”Can edit”只留给 owner。注意：归档 Project 会把所有共享权限重置为 Private，之后若取消归档要重新授权。
- 第一天 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。 责任分散等于没人剪枝，四个月就死。
- 给所有人都开”Can edit”。 和 Confluence 上”人人可改”的失败模式一样。所有变更走 owner 集中收口。
- 第一天把整个 Notion 都倒进去。 文件一旦超过上下文窗口，Claude 切到检索，埋在底下的事实就会被漏。
- Project 取了个不带产出的名字（比如”市场”），范围立刻失控。
- 没写拒答指令。 同事第一次问价格时，Project 就会自信地编一个。
- 让 Knowledge 文件没有日期， 等于无法剪枝。
- 在本地改文件却忘了重新上传。 对话用的还是旧版本，跟新政策直接打架。
- 把聊天记录当成团队记忆。 共享 Project 不会共享聊天，每位同事的聊天都是私有的。文件集才是耐久的记录。
FAQ
- 共享 Project 需要哪个套餐？: Team（截至 2026 年 6 月，每席位 $25/月，按年付为 $20/席位/月）或 Enterprise。Pro 和 Max 的 Project 只属于单个账号。
- 文件多少算多？: 单文件上限 30MB，数量没有硬上限；但当知识总量超过上下文窗口，Claude 会切到检索，埋在底下的事实命中率下降。每个 Project 的活跃文件控制在约 5-15 份，再多就按产出导向拆开。
- 同事能不能改 Knowledge？: 只有被授予”Can edit”的成员能改。默认所有人给”Can view”，变更走 owner。
- 共享 Project 的聊天记录互通吗？: 不互通。共享的是 Knowledge 和 Instructions，不是聊天。每位同事在共享 Project 里有自己的私有聊天。重要决定要写进
decisions.md。 - Team Project 里是哪个模型在回答？: Claude Opus 4.7 和 Sonnet 4.6，截至 2026 年 6 月二者都是 100 万 token 上下文窗口。知识库问答用 Sonnet 4.6 当主力。
相关阅读
官方规则可参考 Anthropic 帮助中心的 Team 套餐说明 和 Project 可见性与共享管理。