企业官网建设流程全解析

1. 项目缘起：为什么要在 Slack 里塞一个“会主动干活”的 AI

团队协作工具用久了，你会发现一个很尴尬的现象：信息全在 Slack 里，但 Slack 本身不会帮你处理信息。有人问“上周那个接口文档谁写的”，你得翻半天聊天记录；有人问“这个报错之前谁遇到过”，你得靠记忆去猜；新同事入职，问“咱们项目的部署流程是啥”，你得从头讲一遍，讲完发现三个月前已经在某个频道里详细说过一次了。

company-brain这个项目，瞄准的就是这个痛点。它的核心思路很直接：把团队在 Slack 里沉淀的所有对话、文档、决策记录，变成一个可以被自然语言查询的知识库，并且让 AI 不只是“你问我答”，而是能主动发现值得关注的信息、主动推送提醒、主动帮团队把散落的知识串起来。

我第一眼看到这个标题的时候，脑子里冒出来的关键词是Slack、AI、Cloudflare Workers、MCP。这几个词组合在一起，其实已经勾勒出了这个项目的技术骨架：Slack 作为交互入口，AI 作为处理引擎，Cloudflare Workers 作为部署载体，MCP 作为连接外部工具和数据的协议层。这套组合拳打下来，一个轻量、低成本、可扩展的团队知识助手就成型了。

适合谁来参考这篇内容？三类人。第一类是小团队的技术负责人，想用最低成本给团队加一个“记忆外挂”；第二类是对 AI Agent 和 MCP 协议感兴趣的开发者，想看看这些概念在真实项目里怎么落地；第三类是用 Slack 做主要协作工具的产品或运营同学，想理解背后的机制，方便提出更合理的使用需求。

下面我会从整体设计思路开始拆，然后逐层深入到核心实现细节、实操部署流程、常见问题排查，最后分享一些我在类似项目里踩过的坑和总结出来的经验。

2. 整体架构设计：为什么选 Cloudflare Workers + MCP 这套组合

2.1 从“被动问答”到“主动干活”的设计转变

大部分团队知识库机器人的做法是：用户提问，机器人检索，返回答案。这个模式的问题在于，它仍然是“人驱动”的——你得先知道要问什么，才能得到答案。但团队协作里真正有价值的信息，往往是你不知道自己不知道的那些。

company-brain的设计思路做了一个关键转变：它把 AI 从“应答者”变成了“观察者+参与者”。具体来说，它会在后台持续监听 Slack 频道里的消息流，识别出值得关注的内容——比如某个技术决策的讨论、某个问题的解决方案、某个重要文档的链接——然后自动把这些信息归档到知识库里。同时，它还能根据预设规则或 AI 判断，主动在频道里发出提醒，比如“这个问题的解决方案上周在另一个频道讨论过，链接在这里”。

这个转变的技术含义是：系统需要具备事件驱动的能力，而不是简单的请求-响应。Slack 的事件订阅机制天然支持这一点，每当频道里有新消息，Slack 会推送一个事件到你的服务端点。你的服务需要快速响应这个事件，做初步处理，然后决定是立即回复还是异步处理。

2.2 Cloudflare Workers 作为部署载体的优势与取舍

为什么选 Cloudflare Workers 而不是传统的服务器或者容器化部署？这个问题我在实际项目里反复权衡过，结论是：对于 Slack 机器人这类场景，Workers 的优势非常明显。

第一，冷启动几乎为零。Slack 的事件推送是突发的，可能几分钟没有消息，然后突然来一波。传统服务器要么一直开着浪费资源，要么冷启动慢导致响应超时。Workers 的冷启动在毫秒级，完全不会因为冷启动导致 Slack 的 3 秒响应超时。

第二，成本模型友好。Workers 的免费额度对于小团队来说完全够用：每天 10 万次请求，每次请求 10 毫秒 CPU 时间。一个几十人的团队，每天的消息事件可能就几百到几千条，远远用不完。即使付费，价格也比开一台最小规格的云服务器便宜。

第三，边缘部署。Slack 的服务器在全球都有，Workers 会自动在离用户最近的边缘节点执行，响应延迟更低。

但 Workers 也有明显的限制，这些限制直接影响了架构设计：

• CPU 时间限制：免费版每次请求只有 10 毫秒 CPU 时间，付费版 30 秒。这意味着你不能在 Workers 里做太重的计算，比如直接调用大模型做推理。解决方案是把重活外包给外部 API，Workers 只做轻量的路由和转发。
• 无持久化存储：Workers 本身是无状态的，不能直接存数据。你需要搭配 KV、D1、R2 或者外部数据库。company-brain这类项目通常需要存向量嵌入和元数据，所以外部数据库是必须的。
• 运行时限制：Workers 支持 JavaScript/TypeScript 和 Python（通过 Pyodide），但 Python 的支持有限。如果你要用 Python 生态的 AI 库，可能需要考虑其他方案。

注意：如果你打算用 Workers 做 MCP 服务端，需要确认你的 MCP 实现是否依赖 Node.js 特有的 API。Workers 的运行时是基于 V8 的，和 Node.js 有差异，某些 npm 包可能无法直接使用。

2.3 MCP 协议在项目中的角色定位

MCP（Model Context Protocol）是这两年 AI 工具链里一个很重要的概念。简单来说，它定义了一套标准协议，让 AI 模型能够以统一的方式调用外部工具、访问外部数据源。你可以把它理解成“AI 世界的 USB 接口”——不管你是数据库、文件系统、API 还是其他什么，只要实现了 MCP 协议，AI 就能通过统一的方式和你交互。

在company-brain里，MCP 主要承担两个角色：

角色一：让 AI 能够访问团队知识库。知识库可能存储在多种后端里——Slack 的消息历史、Notion 的文档、GitHub 的 README、本地的 Markdown 文件。每个后端都有自己的 API 和数据结构。通过 MCP，你可以为每种数据源实现一个 MCP Server，AI 只需要知道“我要查知识库”，具体查哪个后端、怎么查，由 MCP 层来路由。

角色二：让 AI 能够执行操作。比如 AI 判断某条消息值得归档，它需要通过 MCP 调用“写入知识库”的工具；AI 想主动发提醒，需要通过 MCP 调用“发送 Slack 消息”的工具。MCP 把这些操作标准化，AI 不需要关心底层是 Slack API 还是别的什么。

这种设计的妙处在于解耦。你的 AI 逻辑不需要硬编码任何具体的数据源或操作，它只和 MCP 协议打交道。以后想换数据库、想加新的数据源、想支持新的操作，只需要实现新的 MCP Server，AI 侧几乎不用改。

2.4 数据流全景：一条消息从产生到被“消化”的完整旅程

为了让你对整体架构有个直观感受，我描述一条消息的完整处理流程：

1. 用户在 Slack 频道发了一条消息，比如“我们把用户认证从 Session 改成了 JWT，原因是移动端需要无状态”。
2. Slack 的事件订阅机制把这条消息推送到你的 Cloudflare Worker 端点。
3. Worker 收到事件后，先做签名验证（确保请求真的来自 Slack），然后快速返回 200 响应（Slack 要求 3 秒内响应，否则会重试）。
4. Worker 把消息内容、频道 ID、发送者、时间戳等信息写入一个队列（可以用 Cloudflare Queues 或者直接调用外部 API）。
5. 后台处理服务从队列里取出消息，调用 AI 模型做内容分析：这条消息是否包含值得归档的知识？是否涉及某个技术决策？是否和已有知识库里的内容相关？
6. 如果判断值得归档，处理服务通过 MCP 调用“写入知识库”工具，把消息内容、向量嵌入、元数据存入数据库。
7. 如果 AI 判断这条消息和某个已有问题相关，或者检测到某个关键词触发了提醒规则，处理服务通过 MCP 调用“发送 Slack 消息”工具，在相关频道发出提醒。
8. 用户下次提问时，AI 通过 MCP 查询知识库，检索相关片段，生成回答。

这个流程里，Cloudflare Workers 承担的是“前台接待”的角色——快速响应、轻量处理、转发任务。真正的重活（AI 分析、向量检索）由外部服务完成。MCP 则是贯穿始终的“连接器”，让各个组件能够以标准化的方式协作。

3. 核心细节解析：Slack 事件处理、AI 分析与 MCP 工具链

3.1 Slack 事件订阅的配置与签名验证

Slack 的事件订阅配置本身不复杂，但有几个细节容易踩坑。首先你需要在 Slack API 后台创建一个 App，然后开启 Event Subscriptions，填入你的 Worker URL。Slack 会先发一个 challenge 请求验证 URL 的有效性，你的 Worker 需要正确响应这个 challenge。

签名验证是安全的关键。Slack 会在每个请求的 header 里带上X-Slack-Signature和X-Slack-Request-Timestamp。验证逻辑是：把版本号、时间戳、请求体拼接成一个字符串，用你的 Signing Secret 做 HMAC-SHA256 签名，然后和 header 里的签名对比。如果签名不匹配，说明请求不是来自 Slack，应该直接拒绝。

// Cloudflare Worker 里的签名验证示例 async function verifySlackSignature(request, signingSecret) { const timestamp = request.headers.get('X-Slack-Request-Timestamp'); const signature = request.headers.get('X-Slack-Signature'); const body = await request.text(); // 防止重放攻击，时间戳超过 5 分钟直接拒绝 if (Math.abs(Date.now() / 1000 - timestamp) > 300) { return false; } const sigBasestring = `v0:${timestamp}:${body}`; const encoder = new TextEncoder(); const key = await crypto.subtle.importKey( 'raw', encoder.encode(signingSecret), { name: 'HMAC', hash: 'SHA-256' }, false, ['sign'] ); const signatureBuffer = await crypto.subtle.sign( 'HMAC', key, encoder.encode(sigBasestring) ); const mySignature = 'v0=' + Array.from(new Uint8Array(signatureBuffer)) .map(b => b.toString(16).padStart(2, '0')) .join(''); return mySignature === signature; }

提示：Workers 里读取 request body 只能用一次。如果你先await request.text()做了签名验证，后面就不能再读 body 了。解决方案是在验证前先 clone 一份 request，或者把 body 存下来传给后续逻辑。

另一个容易忽略的点是Slack 的重试机制。如果你的 Worker 响应超过 3 秒，Slack 会认为失败并重试，最多重试 3 次。这会导致同一条消息被处理多次。解决方案是在 Worker 里尽快返回 200，把实际处理逻辑放到异步任务里。Workers 支持waitUntil方法，可以在返回响应后继续执行异步操作。

3.2 消息内容的 AI 分析与知识提取策略

消息进来之后，怎么判断它值不值得归档？这是整个系统里最需要“调参”的部分。我的经验是，不要指望一个通用的 AI 模型能完美判断，而是要用“规则+AI”的混合策略。

规则层负责快速过滤：消息长度太短（比如“好的”“收到”）直接跳过；纯表情或纯链接的消息跳过；机器人自己发的消息跳过。这些规则能过滤掉 60% 以上的噪音。

AI 层负责精细判断：对于通过规则过滤的消息，调用 AI 模型做分类。Prompt 的设计很关键，我一般会这样写：

你是一个团队知识管理助手。请判断以下 Slack 消息是否包含值得归档的团队知识。 值得归档的内容包括：技术决策及原因、问题解决方案、重要文档链接、流程说明、经验总结。 不值得归档的内容包括：日常寒暄、简单确认、临时性通知、纯表情回复。 消息内容：{message} 请返回 JSON 格式：{"worthy": true/false, "reason": "判断理由", "category": "分类", "summary": "一句话摘要"}

这个 Prompt 的关键在于给出明确的判断标准和反例。只告诉 AI“判断是否值得归档”，它会很迷茫；给出具体的正例和反例，准确率会高很多。

分类和摘要也是重要的元数据。分类可以帮助后续检索时做过滤，摘要则可以在展示时提供快速预览。我通常会把分类限定在几个固定选项里：技术决策、问题解决、文档资料、流程规范、经验分享。这样后续做统计和分析也方便。

3.3 向量嵌入与知识库检索的实现细节

知识库检索的核心是向量嵌入。简单来说，就是把每段文本转换成一个高维向量，语义相近的文本在向量空间里的距离也相近。用户提问时，把问题也转成向量，然后在知识库里找最接近的向量对应的文本。

嵌入模型的选择上，我一般用 OpenAI 的text-embedding-3-small，性价比高，1536 维的向量对于团队知识库这个量级完全够用。如果对成本更敏感，可以用开源的嵌入模型自己部署，但维护成本会高一些。

向量存储方面，小团队用 PostgreSQL + pgvector 就够了。pgvector 是 PostgreSQL 的扩展，支持向量类型和近似最近邻搜索。建表语句大概是这样：

CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE knowledge_items ( id SERIAL PRIMARY KEY, content TEXT NOT NULL, summary TEXT, category VARCHAR(50), embedding vector(1536), source_channel VARCHAR(100), source_user VARCHAR(100), source_timestamp TIMESTAMPTZ, created_at TIMESTAMPTZ DEFAULT NOW() ); CREATE INDEX ON knowledge_items USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);

检索的时候，用余弦相似度找最接近的几条：

SELECT content, summary, category, 1 - (embedding <=> $1) AS similarity FROM knowledge_items ORDER BY embedding <=> $1 LIMIT 5;

注意：ivfflat索引的lists参数需要根据数据量调整。数据量在 1 万条以下时，lists = 100是合理的；数据量到 10 万条时，可以调到 1000。这个参数影响检索速度和召回率的平衡，需要根据实际情况调优。

3.4 MCP 工具的定义与调用流程

MCP 的核心概念是“工具”（Tool）。每个工具定义了一个可以被 AI 调用的能力，包括名称、描述、参数 schema。AI 根据用户请求和工具描述，决定调用哪个工具、传什么参数。

在company-brain里，我通常会定义这几个核心工具：

每个工具的实现就是一个函数，接收参数、执行操作、返回结果。MCP 协议规定了工具描述和调用的格式，AI 模型通过这个格式来发现和调用工具。

// MCP 工具定义示例 const tools = [ { name: 'search_knowledge', description: '在团队知识库中搜索相关信息。当用户询问团队历史决策、问题解决方案、文档位置时使用此工具。', inputSchema: { type: 'object', properties: { query: { type: 'string', description: '搜索查询文本' }, category: { type: 'string', enum: ['技术决策', '问题解决', '文档资料', '流程规范', '经验分享'] }, limit: { type: 'number', default: 5 } }, required: ['query'] } } ];

工具描述的质量直接影响 AI 调用的准确性。描述要写清楚“什么时候用这个工具”，而不只是“这个工具做什么”。比如search_knowledge的描述里明确写了“当用户询问团队历史决策、问题解决方案、文档位置时使用”，这样 AI 在遇到这类问题时才会想到调用它。

3.5 主动推送机制的触发条件与实现

“主动干活”是这个项目的亮点，也是最难做好的部分。主动推送做得好，用户觉得贴心；做得不好，用户觉得骚扰。我的经验是，主动推送必须满足三个条件：高置信度、高价值、低频率。

高置信度意味着 AI 对“这条信息值得推送”的判断必须很确定。我一般会设置一个置信度阈值，只有 AI 返回的置信度超过阈值时才推送。阈值设多少？我的经验是 0.85 以上，低于这个值宁可不错推。

高价值意味着推送的内容必须对接收者有用。比如有人在频道里问“这个报错怎么解决”，而知识库里有相关的解决方案，这个推送就是高价值的。但如果只是检测到某个关键词就推送，往往价值不高。

低频率意味着不能频繁推送。我一般会设置每个频道每天最多推送 3 条，每个用户每天最多收到 5 条。超过限额的推送会被静默丢弃，或者汇总成一条日报。

实现上，主动推送通常有两种触发方式：

方式一：事件触发。当新消息进来时，除了判断是否归档，还判断是否和已有知识相关。如果相关，就推送。这种方式实时性好，但计算量大，每条消息都要做一次检索。

方式二：定时扫描。每隔一段时间（比如每小时），扫描最近的消息，批量判断是否有值得推送的内容。这种方式计算量小，但实时性差。

我一般会结合两种方式：对高优先级的频道用事件触发，对普通频道用定时扫描。这样既保证了重要频道的实时性，又控制了整体成本。

4. 实操部署：从零搭建一个可运行的 company-brain

4.1 环境准备与依赖清单

开始之前，你需要准备这些东西：

• Slack 工作区：需要管理员权限来创建 App 和配置事件订阅。
• Cloudflare 账号：免费版即可，用于部署 Worker。
• AI 模型 API：OpenAI、Anthropic 或者兼容 OpenAI 接口的其他服务。需要 chat 模型和 embedding 模型。
• PostgreSQL 数据库：本地或云端均可，需要安装 pgvector 扩展。Supabase、Neon 等托管服务都支持。
• Node.js 环境：用于本地开发和部署 Worker，建议 18 以上版本。
• Wrangler CLI：Cloudflare 的官方部署工具，npm install -g wrangler。

依赖清单里，我特别想强调pgvector 的安装。如果你用 Docker 跑 PostgreSQL，直接用pgvector/pgvector:pg16这个镜像就行。如果用自己的 PostgreSQL，需要编译安装扩展，步骤稍微麻烦一些。托管服务里，Supabase 和 Neon 都默认支持 pgvector，省去安装步骤。

4.2 Slack App 的创建与权限配置

在 Slack API 后台创建 App 的步骤：

1. 访问 Slack API 网站，点击“Create New App”，选择“From scratch”。
2. 填写 App 名称（比如company-brain），选择要安装的工作区。
3. 在左侧菜单找到“OAuth & Permissions”，配置 Bot Token Scopes。需要的权限包括：
   • channels:history：读取公开频道消息
   • channels:read：获取频道列表
   • chat:write：发送消息
   • groups:history：读取私有频道消息（如果需要）
   • im:history：读取私信（如果需要）
   • users:read：获取用户信息
4. 在“Event Subscriptions”里开启事件订阅，填入你的 Worker URL（部署后再填），订阅这些事件：
   • message.channels：公开频道消息
   • message.groups：私有频道消息
   • app_mention：被 @ 时触发
5. 在“Basic Information”里记下Signing Secret，后面验证签名要用。
6. 在“OAuth & Permissions”里点击“Install to Workspace”，安装后拿到Bot User OAuth Token。

注意：channels:history只能读取机器人已经加入的频道。你需要把机器人邀请到相关频道里，用/invite @company-brain命令。这一步很容易忘，忘了的话机器人收不到任何消息。

4.3 Worker 项目的初始化与核心代码结构

用 Wrangler 初始化项目：

npm create cloudflare@latest company-brain cd company-brain npm install

项目结构大概是这样：

company-brain/ ├── src/ │ ├── index.js # Worker 入口 │ ├── slack.js # Slack 相关逻辑 │ ├── ai.js # AI 调用逻辑 │ ├── mcp.js # MCP 工具定义 │ └── db.js # 数据库操作 ├── wrangler.toml # Worker 配置 └── package.json

wrangler.toml里需要配置环境变量和 KV 绑定：

name = "company-brain" main = "src/index.js" compatibility_date = "2024-01-01" [vars] SLACK_SIGNING_SECRET = "your-signing-secret" [[kv_namespaces]] binding = "RATE_LIMIT" id = "your-kv-namespace-id"

敏感信息比如 Slack Token、AI API Key，不要写在wrangler.toml里，用wrangler secret put命令设置：

wrangler secret put SLACK_BOT_TOKEN wrangler secret put OPENAI_API_KEY wrangler secret put DATABASE_URL

Worker 入口的核心逻辑：

import { verifySlackSignature } from './slack'; import { processMessage } from './ai'; export default { async fetch(request, env, ctx) { if (request.method !== 'POST') { return new Response('Method not allowed', { status: 405 }); } const clonedRequest = request.clone(); const isValid = await verifySlackSignature(clonedRequest, env.SLACK_SIGNING_SECRET); if (!isValid) { return new Response('Invalid signature', { status: 401 }); } const body = await request.json(); // URL 验证 challenge if (body.type === 'url_verification') { return new Response(body.challenge, { status: 200 }); } // 异步处理消息，立即返回 200 ctx.waitUntil(processMessage(body, env)); return new Response('OK', { status: 200 }); } };

这里的关键是ctx.waitUntil。它让 Worker 在返回响应后继续执行异步任务，避免 Slack 因为等待超时而重试。

4.4 数据库表设计与向量索引创建

数据库表的设计前面已经给了一部分，这里补充完整的 schema：

-- 知识条目表 CREATE TABLE knowledge_items ( id SERIAL PRIMARY KEY, content TEXT NOT NULL, summary TEXT, category VARCHAR(50), embedding vector(1536), source_channel VARCHAR(100), source_user VARCHAR(100), source_timestamp TIMESTAMPTZ, created_at TIMESTAMPTZ DEFAULT NOW() ); -- 推送记录表，用于控制频率 CREATE TABLE push_history ( id SERIAL PRIMARY KEY, channel VARCHAR(100), user_id VARCHAR(100), pushed_at TIMESTAMPTZ DEFAULT NOW(), content_summary TEXT ); -- 索引 CREATE INDEX idx_knowledge_category ON knowledge_items(category); CREATE INDEX idx_knowledge_channel ON knowledge_items(source_channel); CREATE INDEX idx_push_channel_time ON push_history(channel, pushed_at); CREATE INDEX ON knowledge_items USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);

push_history表是用来控制推送频率的。每次推送前，先查这个频道今天已经推了几条，超过限额就不推。

4.5 部署上线与 Slack URL 验证

部署 Worker：

wrangler deploy

部署成功后会得到一个 URL，类似https://company-brain.your-subdomain.workers.dev。把这个 URL 填到 Slack App 的 Event Subscriptions 里，Slack 会立即发一个 challenge 请求验证。如果 Worker 正确响应了 challenge，URL 旁边会显示“Verified”。

验证通过后，把机器人邀请到测试频道，发一条消息，看看 Worker 的日志里有没有收到事件。可以用wrangler tail实时查看日志：

wrangler tail

如果日志里能看到消息事件，说明链路通了。接下来就是调 AI 分析逻辑，让知识库慢慢积累起来。

5. 常见问题与排查技巧实录

5.1 Slack 事件收不到或响应超时

这是最常见的问题，排查思路按顺序来：

签名验证失败还有一个隐蔽的原因：请求体被读取了两次。Workers 里request.text()或request.json()只能调用一次，第二次会返回空。解决方案是在验证前request.clone()一份。

5.2 AI 分析结果不稳定或分类错误

AI 分析的不稳定性主要来自 Prompt 设计和模型选择。我的经验是：

• Prompt 要具体：不要只说“判断是否值得归档”，要给出明确的判断标准和例子。
• 输出格式要固定：要求 AI 返回 JSON，并在 Prompt 里给出 JSON schema。这样解析起来不会出错。
• 温度参数调低：分类任务用temperature=0或0.1，让输出更确定。
• 加 few-shot 示例：在 Prompt 里给 2-3 个正例和反例，准确率会明显提升。

如果分类错误率还是高，可以考虑用更小的模型做初筛，把不确定的交给大模型做精细判断。这样既控制了成本，又保证了准确率。

5.3 向量检索结果不相关

向量检索不相关，通常是这几个原因：

嵌入模型不合适。不同嵌入模型对中文的支持差异很大。text-embedding-3-small对中英文混合内容支持不错，但如果你的团队主要用中文，可以考虑专门的中文嵌入模型。

文本切分太粗或太细。一条 Slack 消息可能很长，直接整条嵌入效果不好。我一般会把长消息按语义切分成 200-500 字的片段，每个片段单独嵌入。切分的时候尽量按段落或语义边界切，不要硬切。

相似度阈值没设好。余弦相似度的范围是 -1 到 1，但实际相关的文本相似度通常在 0.7 以上。如果检索结果里有很多不相关的，可以把阈值调到 0.75 或 0.8。

索引参数没调优。ivfflat的lists参数和查询时的probes参数都会影响召回率。probes设得越大，召回率越高但速度越慢。一般设probes = sqrt(lists)是个不错的起点。

5.4 主动推送变成“骚扰”

主动推送做不好，用户会很快把机器人静音。我的避坑经验：

• 设置每日限额：每个频道每天最多 3 条，每个用户每天最多 5 条。
• 设置置信度阈值：AI 判断的置信度低于 0.85 不推送。
• 提供反馈机制：推送消息里加“有用”和“没用”按钮，收集反馈来优化推送策略。
• 支持频道级配置：允许频道管理员关闭主动推送，或者调整推送频率。
• 汇总而非逐条推送：如果有多条值得推送的内容，汇总成一条消息，而不是逐条发。

提示：主动推送的第一周特别关键。如果第一周推送的内容质量不高，用户会形成“这个机器人很烦”的印象，后面很难扭转。建议第一周只对高置信度的内容推送，宁可少推，不要错推。

5.5 成本控制与性能优化

Cloudflare Workers 本身成本很低，主要成本在 AI API 调用和数据库。控制成本的几个手段：

缓存嵌入结果。同样的文本不要重复调用嵌入 API。可以用 KV 或者数据库缓存文本的哈希和对应的嵌入向量。

批量处理。嵌入 API 通常支持批量调用，一次传多条文本比逐条调用便宜且快。

分级处理。不是所有消息都需要大模型分析。先用规则过滤，再用小模型初筛，最后才用大模型精细判断。

控制检索范围。检索时先按分类或时间范围过滤，再做向量检索，减少计算量。

定期清理。过期的推送记录、低质量的知识条目定期清理，保持数据库精简。

性能方面，Workers 的冷启动不是问题，但数据库查询可能是瓶颈。确保向量索引正确创建，查询时用EXPLAIN ANALYZE检查执行计划，避免全表扫描。

6. 一些实操心得与扩展思路

我在类似项目里踩过的最大的坑，是一开始就追求“全自动”。想着让 AI 自动判断、自动归档、自动推送，结果发现 AI 的判断准确率远没有达到可以完全放手的程度。后来调整了策略：AI 做初筛和推荐，但关键操作（比如归档重要决策）需要人工确认。这样既减轻了人工负担，又保证了知识库的质量。

另一个心得是知识库的价值在于“用”，而不在于“存”。如果团队只是把消息归档进去，但从来不去查，那这个知识库就是死的。所以我在项目里会特别注重“主动推送”和“提问引导”——让 AI 在合适的时机主动把知识推给需要的人，或者在用户提问时引导他们使用知识库。用起来的知识库才有生命力。

扩展思路上，这个项目可以往几个方向走：

多平台支持。现在只支持 Slack，可以扩展到飞书、钉钉、Teams 等。MCP 的标准化设计让这种扩展变得容易——只需要实现对应平台的 MCP Server。

知识图谱。现在只是向量检索，可以进一步构建知识图谱，把知识条目之间的关系也建模进去。这样检索时不仅能找到相关条目，还能找到关联的决策链、影响范围等。

工作流集成。把知识库和 CI/CD、项目管理工具集成。比如代码合并时自动关联相关的技术决策记录，或者新任务创建时自动推荐相关的历史经验。

个性化推荐。根据每个用户的角色、参与的项目、历史查询记录，个性化推荐知识内容。新同事入职时自动推送项目背景和流程文档，比人工讲解效率高得多。

最后分享一个小技巧：给知识条目加“时效性”标记。技术决策和流程规范可能过一段时间就失效了，在归档时让 AI 判断这条知识的“保质期”，过期后自动标记为“可能过时”，检索时降低权重或者提示用户。这个细节能显著提升知识库的可靠性，避免用户被过时信息误导。