company-brain

/company-brain — 团队共享的 AI 就绪知识库

Company Brain （名词）：团队共享的 AI 就绪知识库，包含人员、公司、会议、SOP 和决策，并经过结构化整理，让 Claude 能够代表团队回答问题。

它是 second-brain（个人范围）的团队范围对应版本。核心的编译 → wiki → 输出模式相同；原始数据的架构不同，针对多人协作、销售密集型和运营密集型团队进行了优化。

它也是产品化服务 Company Brain Setup 的运营支柱（此前名为“Second Brain as a Service”，现已更名以匹配此技能）。

心智模型

三个层次，与 second-brain 相同，但 raw/ 层是结构化的，而非扁平的：

raw/          →  wiki/         →  outputs/
(structured      (compiled        (generated
 by category)     interlinked)     artifacts)

结构化的 raw/ 目录（每个目录都是知识库中的顶层文件夹）：

目录	内容
people/	包含上下文信息的联系人，相当于轻量级 CRM。每人一个 Markdown 文件。
companies/	组织资料，包括最近一次接触、商机规模和状态。每家公司一个文件。
meetings/	电话／会议记录和笔记。命名格式：YYYY-MM-DD-<company-or-topic>-<slug>.md。自动同步来源。
sops/	标准操作流程。命名格式：<team>-<process>.md（例如 sales-outbound-cadence.md）。
decisions/	决策记录（叙述式；与 decide 技能的结构化格式不同）。
customer-language/	来自潜在客户／客户／用户的原话。用于撰写文案、标题和异议回应。
recurring-questions/	在通话中被问到 3 次以上的问题。每个问题都会整理为已有答案的 SOP／FAQ／话术。
sales-objections/	异议及最佳回应库。汇编为销售话术。
raw/	旧有／未分类的记录（兜底目录，应尽量少用）。

wiki/、outputs/ 和 INDEX.md 的工作方式与 second-brain 相同。

保留目录（company-brain 不会修改）：Projects/、Team/、Templates/、Drafts/。

多作者规范

每条记录都会标注：

source: <URL / call / email / manual entry>
author: <who added this — email or handle>
captured: YYYY-MM-DD
trust: unreviewed

Wiki 页面会在 ## Sources 部分跟踪累计贡献（按来源文件和作者分别记录）。不覆盖内容——始终追加并注明来源。

敏感度标记（可选，但建议使用）：

sensitivity: internal        # any team member can read
sensitivity: leadership      # exec team only
sensitivity: confidential    # named list only (list access in the file)

默认值：internal。查询模式会遵守敏感度设置——除非调用者在访问名单中，否则不会纳入 confidential 内容。

信任级别

多作者规范的另一部分是：并非所有记录都应获得同等的上下文权重。每个结构化原始文件都包含一个 trust: 字段。

（字段名为 trust，而非 status，因为 companies/ 和 decisions/ 已使用 status: 表示生命周期状态——潜在客户／客户、已决定／已撤销——两者不能冲突。）

信任级别	含义	查询时的处理方式
unreviewed	已记录，但尚未经过人工确认（每条新记录的默认值）	可以使用，但会标记出来——依赖此类内容的回答会注明置信度较低
verified	已由人工审核并确认无误	完整权重
deprecated	错误或已过时——仅为保留历史而留存	绝不作为上下文使用
superseded	已被更新内容取代——添加 superseded_by: [[target]]	绝不作为上下文使用；查询会指向替代内容

特意采用枚举而非数值权重——团队只需维护一个包含四种值的字段，无需维护 0–1 的浮点数。

弃用取代删除。“绝不删除原始文件”的规则依然有效：当信息被证实有误或过时时，应将其标记为 deprecated（或标记为 superseded 并添加指向替代内容的指针），而不是删除。保留历史，同时保护上下文。

信任级别与敏感度相互独立——文件可以是 verified + confidential，也可以是 unreviewed + internal。

现有知识库：早于信任级别规范的文件可能没有 trust: 字段——应视为 unreviewed。如果知识库的架构文档（CLAUDE.md / AGENTS.md）早于信任级别规范，那么首次运行 /cb review 时，请提议将信任规范添加到该文档中（知识库的 CLAUDE.md 仍具有权威性——应扩展它，而非覆盖它）。

步骤 1 — 加载知识库配置 + 架构

1. 阅读 references/vault-config.md，获取知识库路径（默认：${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/）
2. 阅读知识库的架构文档——<vault>/CLAUDE.md 或 <vault>/AGENTS.md，以实际存在的文件为准（如果两者都存在，则都阅读）——以获取权威的团队架构。如果存在此类文档，请优先遵循，而不是 references/schema.md——团队的知识库才是事实来源。
3. 如果两者都不存在，则使用 references/schema.md 作为后备方案——团队架构入门套件。

步骤 2 — 解析模式

调用方式	模式
/cb capture / /company-brain capture /“将此内容记录到团队知识库”	capture
/cb compile /“编译公司 Wiki”	compile
/cb query <q> /“团队对 X 有什么了解”	query
/cb review /“审查公司知识库” /“清理团队知识库”	review
/cb lint /“检查公司知识库”	lint
/cb connect /“查找跨团队关联”	connect
/cb search <term> /“搜索公司知识库”	search

步骤 3 — 运行模式

capture

与 second-brain 的摄取方式相同，但路由方式不同——根据内容类型选择结构化目录。

1. 识别内容类型并路由到相应目录：

   • 通话 / 会议记录 → meetings/YYYY-MM-DD-<company-or-topic>-<slug>.md
   • 个人的 LinkedIn / 简介 / 联系人背景信息 → people/<name-slug>.md
   • 公司简介 / 潜在客户 / 客户 → companies/<company-slug>.md
   • 已记录的流程 / 如何完成某项工作 → sops/<team>-<process>.md
   • 领导层 / 团队作出的决定 → decisions/YYYY-MM-DD-<decision-slug>.md
   • 客户原话引述 → customer-language/<theme-slug>.md（如果已有相关主题文件，则追加到该文件）
   • 通话中提出的问题 → recurring-questions/<question-slug>.md（重复时追加计数）
   • 听到的销售异议 → sales-objections/<objection-slug>.md（重复时追加变体）
   • 如果无法确定，请提问。
   • 如果目标目录尚不存在，则随本次记录一并创建。新知识库最初只包含一个试点工作流所需的目录（参见 references/vault-config.md →“从小处着手”）。

2. 添加多作者元数据（文件顶部）：

   source: <URL / call with X on YYYY-MM-DD / email from Y / etc.>
   author: <who captured this>
   captured: YYYY-MM-DD
   trust: unreviewed      # every capture starts unreviewed — review mode promotes it
   sensitivity: internal  # or leadership / confidential
   

3. 保存并报告文件路径 + 一句话摘要。

此处不要编译到 Wiki 中——capture 是快速摄取。

compile

与 second-brain 的 compile 模式采用相同的核心流程——处理尚未处理的结构化原始文件，生成 Wiki 页面、更新 INDEX.md，并添加 Sources 部分。

与 second-brain 的不同之处：

• 多作者归属：Sources 部分包含作者，而不只是文件名

  ## Sources
  - `people/jane-doe.md` (added by @alex, 2026-06-30) — CTO of Acme, evaluated us Q2
  

• 跨类别编译：关于“Acme Corp 交易”的 Wiki 页面可能会整合 companies/acme.md、meetings/2026-06-15-acme-discovery.md、sales-objections/acme-pricing.md 和 people/jane-doe.md 的内容——全部汇入同一个 Wiki 页面。
• 敏感级别继承：Wiki 页面继承所有来源中最高的敏感级别。如果任何来源标记为 confidential，Wiki 页面也标记为 confidential。
• 信任过滤：deprecated 和 superseded 来源不会纳入 Wiki 页面。如果已经用于 Wiki 页面的来源后来被标记为 deprecated，重新编译时会标记受影响的页面以供重新审核，并移除该来源；同时在 Sources 中注明，使用文件的 reviewed + reviewed_by 标记：- meetings/2026-06-15-x.md (deprecated 2026-07-01 by @alex)。主要由 unreviewed 来源构建的页面，顶部会添加 > ⚠ Mostly unreviewed sources 提示。
• 团队的 INDEX.md 类别：Sales、Customers、Ops、Product、Team & People、Decisions、Playbooks。可按需扩展。

其他所有内容（每个概念单独成页、[[wikilinks]]、必须包含 Connections、重质量而非数量）均保持不变。

query

与 second-brain query 相同，另外：

• 先进行敏感级别检查：识别调用者；拒绝纳入超出其敏感级别的内容。
• 信任规则：优先使用 verified 内容，而不是 unreviewed 内容；优先使用近期内容，而不是旧内容。绝不将 deprecated 或 superseded 内容用作上下文——最多只能将其作为指引引用：“（已弃用 — 请参阅 [[replacement]]）”。 两个来源相互冲突时，优先选择较新且状态较高的来源，并在回答中指出分歧。
• 置信度标记：如果回答主要依据 unreviewed 来源，请在开头说明：“置信度较低 — 4 个来源中有 3 个未经审核。运行 /cb review 来确认这些内容。”
• 考虑作者的回答：引用时，注明信息贡献者：“根据 [[Acme Deal]]（来源：meetings/2026-06-15-acme-discovery.md，作者 @alex）……”
• 将外部信息缺口交由 deep-research 处理，与 second-brain 相同。

将回答、查阅的 wiki 页面以及输出的敏感级别保存到 outputs/<YYYY-MM-DD>-<question-slug>.md。

review

人工筛选环节。 团队借此避免垃圾输入变成垃圾上下文：所有内容都可以自由捕获（不会丢失任何内容），但只有经过审核的信息才能获得完整权重。

0. 先进行敏感级别检查——规则与 query 模式相同：识别调用者，并从队列中排除超出其敏感级别的文件。报告排除数量：“有 3 项内容超出你的敏感级别，已跳过 — 领导名单中的某人需要审核这些内容。”

1. 建立分流队列：

   • 结构化原始数据目录中所有 trust: unreviewed 文件（包括完全没有 trust: 字段的文件），按从新到旧排序
   • lint 标记的所有内容（检查 1–12；检查 13 与审核本身有关）
   • 审核日期已过期的文件（如果存在这些字段）：decisions/ 中 review_by 已过期的文件，sops/ 中 last_reviewed + review_cadence 已过期的文件

2. 逐项处理队列。 对于每个文件，显示：单行摘要、来源、作者、捕获日期，以及引用该文件的 wiki 页面。提供四种处理方式——除 skip 外，每种处理方式都会添加 reviewed: YYYY-MM-DD + reviewed_by: <handle>：

   • verify → trust: verified
   • deprecate → trust: deprecated（内容有误或已过时；保留以供追溯）
   • supersede → trust: superseded + superseded_by: [[target]]（询问替代内容）
   • skip → 保持原样，在下次审核时再次出现

3. 批量应用 frontmatter 更新——不要重写文件正文，只修改元数据块。

4. 标记下游影响：如果已弃用或已取代的文件被现有 wiki 页面引用，列出这些页面，并询问是否现在重新编译。

5. 以摘要收尾：“已审核 12 项：8 项已验证、3 项已弃用、1 项已取代。已重新编译 2 个 wiki 页面。建议下次审核日期：。” 将摘要保存到 outputs/<YYYY-MM-DD>-review.md，以便保留筛选过程的审计记录。

频率：活跃知识库每周一次；配合 loopify 安排任务，确保实际执行筛选，而不是依赖某人记得去做。审核逾期超过 1 个月的知识库会出现在 lint 中（检查 13）。

lint

与 second-brain 相同的七项检查，另外包括：

8. 人员/公司信息过时 — 活跃客户的 people/ 或 companies/ 文件超过 6 个月未更新
9. 重复问题超过阈值 — 某个问题被问及 5 次或以上，但没有对应的 wiki 页面或 SOP
10. 异议没有回应 — sales-objections/ 文件未关联 sops/ 或 wiki/ 中的回应
11. SOP 时效性 — SOP 超过 12 个月未更新（随着业务发展，内容可能会过时）
12. 作者工作量失衡 — 一位贡献者完成了超过 80% 的内容捕获（通常意味着知识库依赖个人，这不利于团队持续运作）
13. 审核积压 — 超过 20 个文件处于 trust: unreviewed 状态，或超过 1 个月未进行审核（没有 outputs/*-review.md）。提示运行 /cb review。

connect

与 second-brain 相同，另加跨类别链接建议——例如，如果 sales-objections/pricing-too-high.md、customer-language/willingness-to-pay.md 和 sops/discovery-call-cadence.md 存在，应在它们之间建立链接。

search

与 second-brain 相同。搜索所有 structured-raw 目录和 wiki/。

可选：自动同步来源

团队知识库可以从自动采集中受益。有关设置模式，请参阅 references/auto-sync-sources.md：

来源	采集内容	设置方式
Fathom / Gong / Granola	通话／会议转录	Webhook → 追加到 meetings/
Slack export	值得保留的团队讨论	手动或定时导出 → raw/slack-<channel>-<date>.md
Email (Front / Missive / Superhuman)	值得保留的客户沟通邮件	转发到指定地址 → 追加到 people/ 或 companies/
CRM (HubSpot / Attio / Pipedrive)	交易状态、联系人信息	定期同步 → companies/ + people/

自动同步是可选的——大多数团队会先手动采集，等知识库逐渐成熟后再添加自动化。可配合 loopify 安排定期同步任务。

多写入者 git 同步（团队成员 + 远程 Agent）

团队知识库本质上由多个写入者共同维护，git 是协作层。将知识库托管在远程服务（GitHub/GitLab）上；远程服务也可充当无法访问文件系统的 Agent 的采集 API——云端 Agent、定时同步任务、队友的机器。任何能够访问 git 托管平台 API 的主体（直接访问，或通过 Executor 这样的 MCP 集成层），都可以读取 wiki，并将采集内容提交到结构化原始目录中。

为避免写入者各自为政，需要遵守以下规范：

1. 每次本地会话都要先拉取再写入：开始处理知识库前运行 git pull --rebase --autostash，提交后推送。多人和 Agent 同时提交时，本地副本很快就会过时。
2. Obsidian 用户：安装社区 Git 插件，启用定时自动拉取（约 10 分钟）和启动时拉取，关闭自动提交——提交应体现语义（每次采集／整理一次），而不是产生“知识库备份”噪声。每位团队成员的机器都需要配置，而不只是某一台。
3. 远程 Agent 和自动同步任务应以追加为主进行提交：在结构化目录中新建文件，使用描述性提交信息，并在采集文件的 frontmatter 中标注作者（多作者信任模型依赖此信息）。追加到不同文件很少会产生冲突；其余冲突可通过 rebase 解决。

每台机器在接入时都要验证一次完整流程：通过 API 进行远程提交 → 本地拉取 → 文件出现。

可组合使用

• second-brain——同类工具。个人 wiki 使用 second-brain；团队 wiki 使用 company-brain。个人可以通过不同的知识库路径同时维护两者。
• skillify——用于编写可从公司知识库读取内容的新技能（例如，每周一查询 company-brain 的 weekly-team-brief 技能）。
• loopify——安排自动同步任务（每日拉取 Fathom、每周导出 Slack、每周进行审查、每月检查 INDEX）。
• toolify——接入为公司知识库提供内容的集成（Fathom Webhook 接收器、Attio API 等）。
• deep-research——如果 query 发现信息缺口，则转向外部研究。将深度研究结果保存到 raw/，以便日后整理。
• decide——decisions/ 文件夹可补充 decide 的结构化归档。decide 记录评估过程；decisions/ 记录叙述 + 结果 + 复盘笔记。
• pm——团队任务管理位于 Projects/（该目录由 company-brain 保留）。pm 负责管理 Projects/；company-brain 会读取其中内容作为上下文，但不会修改。
• jab-hook——customer-language/ 为社交媒体文案提供素材，使其贴合潜在客户的真实用语。
• 博客起草技能（自建或配套插件）——从 customer-language/、recurring-questions/ 和 sops/ 获取内容，起草权威的博客文章。

同源实现（参考）

与 second-brain 同源：

• Gbrain — Garry Tan 团队规模的知识库（146K 个页面、24K 个个人实体）。基于 Postgres/PGLite，支持图遍历和定期维护。当团队的公司知识库超出纯 Markdown 的承载范围时，Gbrain 就是升级之选。
• Hermes 的 llm-wiki — 三文件夹模式的参考实现。
• Notion AI / Glean / Mem — 商业化的“公司操作系统”工具。Company-brain 是原生支持 Claude、以 Markdown 为先的替代方案——成本更低、可移植性更好，也更适合已经使用 Obsidian / Git 管理文档的团队。

质量说明

• 团队规模下，结构化原始数据优于扁平原始数据。 Second-brain 的类型前缀适用于个人；团队需要为人员、公司、会议等设置专用目录，以确保多人协作时搜索依然快速。
• 多人署名归属不可妥协。 每个文件都标注 author: 和 captured:。Wiki 页面按来源和作者注明引用。
• 端到端遵循敏感度要求。 查询模式拒绝包含高于调用者级别的内容。Wiki 页面继承所有来源中最高的敏感度。
• 绝不删除原始文件。 这与 second-brain 的规则相同——结构化目录才是事实来源。信息有误或过时后，应弃用而非删除——trust: deprecated 会将其从上下文中移除，同时保留历史记录。
• 自由捕获，审慎赋权。 信任枚举意味着录入信息是安全的——未经审核的内容不会以最高权重污染答案，而 /cb review 会定期清理并提升或退役相关内容。
• 从小范围开始，逐步争取扩展的条件。 先为一个与营收相关的工作流填充目录，由一两个人试点，只有在查询得到解答且审核机制运作良好后才扩大范围。参见 references/rollout.md。
• 公司知识库操作期间，绝不修改 Projects/、Team/、Templates/、Drafts/。
• 自动同步并非必需。 先手动操作；等知识库成熟后再自动化。在团队还没有养成定期手动记录会议的习惯前，不要把精力耗在 Fathom Webhook 上。
• 不要让一个人独自承担整个知识库。 如果 lint 标记的作者负载不均衡度超过 80%，团队就离失去整个知识库只差一个关键人员。应扩大贡献者范围。