企业官网建设流程全解析

1. 先搞清楚 project 本身：company-brain 到底解决什么问题

看到这个项目名，第一反应是“又一个 Slack bot”，但把 README 和代码结构翻完，我的判断是：它不属于传统那种“你问一句它答一句”的被动式机器人，而是试图往主动型 AI 协作者方向走。换句话说，它想干的事不是“在 Slack 里等 @”，而是“自己盯着团队的工作流，发现问题、整理信息、主动推送给该看的人”。

这个定位很关键。Slack 里从来不缺 bot，缺的是能帮人省掉“打开多个频道翻记录”这种重复劳动的 AI。company-brain 的思路是把团队的公开对话、项目进展、文档链接、决策记录这些散落信息聚合成一个可检索、可归纳的“团队记忆”，再基于这套记忆去主动产出内容。如果再配上定时任务或者 Webhook 触发，它就可以像一个“有脑子的自动秘书”一样，在群里帮你同步项目状态、拆解任务、整理周报素材。

对于什么样的团队它最有用？我自己的判断是：10 到 50 人左右的研发或产品团队。人太少时靠口口相传就够了，人太多时这种工具会变成噪音源。而在中间这个规模，恰恰是信息碎片化最严重的阶段，每个人都在不同频道里说了一半的话，新成员进来根本不知道上下文在哪。company-brain 正好补上这个空档。

但这个项目还有一个更值得关注的点：它把GitHub 生态和Slack 生态串了起来。GitHub 里的 issue、PR、commit 记录是团队最硬核的工作痕迹，Slack 里则是这些痕迹周边的“软性讨论”。以往这两部分是割裂的——想回顾一个需求怎么从 idea 变成 commit，你得来回切换好几个页面。company-brain 这类工具尝试把这层关联做出来，让聊天记录和代码变更能够互相引用。

当然，标题里写的“会主动干活的 AI”是有一定夸张成分的。目前开源社区的多数同类项目还没到完全自主决策的程度，更准确的说法是“在规则允许的范围内主动执行一些低风险动作”。所以下面我聊的内容，都会基于“半自主辅助”这个现实定位来展开，不会把它吹成科幻片里的那种全自动管家。

2. 核心机制拆解：它凭什么能“主动干活”

2.1 从被动响应到主动触达，架构上发生了什么变化

传统 Slack bot 的处理模型是“事件驱动 + 即时响应”：用户发消息，平台推送 event 到 bot 的服务器，bot 调用一次大模型或规则引擎，然后把结果回帖到频道。整个过程是同步的，bot 没有“自己的时间线”。

而 company-brain 如果想“主动”，就必须在这条链路上多出两个核心组件：一个是定时任务的调度器，另一个是信息聚合与优先级判断模块。调度器负责按预设时间（比如每天早上 9 点、每周一上午）去扫描指定频道和 GitHub 仓库；聚合模块把扫描到的新消息、新 issue、新 PR 拉回来，做浓缩和去重，再交给大模型生成一段摘要或行动建议；最后由 bot 决定把内容发到哪个频道、@谁。

这个架构差异说起来就一句话，做起来牵扯不少细节。比如调度器得考虑时区、频道活跃度、Slack API 的速率限制；聚合模块得处理消息乱序、重复文本、跨频道引用；优先级判断更是棘手——哪些信息值得推？推给谁？一天推几次才不算骚扰？这些都是产品层面的取舍。

2.2 触发机制设计：定时、关键词、Webhook 如何搭配

从工程实现角度看，“主动干活”的触发源大致有三类：

第一类是定时触发。适合做日报、周报、CI 状态汇报这类周期性任务。比如每天早上扫描所有“开发中”的 PR，把 review 状态汇总发送到团队频道。这种场景不需要大模型做复杂推理，重点是信息的准确聚合，所以大模型产出前最好先做一轮硬性过滤。

第二类是关键词或语义触发。团队里经常出现“这个问题谁看下”“这个 bug 复现了吗”这类散落提问，bot 监听频道消息后做轻量语义判断，命中就自动去相关仓库或文档里查询上下文，把结果直接回复在提问线程下。这里的挑战是误触率控制——我对这类功能的容忍阈值很低，如果 bot 一周误触发三次以上，就会被整个团队静音。

第三类是外部 Webhook 触发。GitHub 的 issue 创建、PR 合并、CI 失败等事件通过 webhook 推送给 bot 服务，bot 拿到事件后结合历史上下文，主动向相关频道推送“格式化的、带建议的提醒”。这也是我认为最实用的一种触发方式，因为它的事件源是确定性的，不太会产生“AI 自己吓自己”的情况。

一个成熟部署下，这三类触发机制通常会组合使用。定时任务做宏观同步，关键词触发做即时问答，webhook 做关键节点提醒，各自负责不同的时间尺度和信息粒度。

2.3 “会主动干活”的安全边界与授权逻辑

凡是牵扯到主动行为的 AI，安全边界必须放在第一位。我见过不少翻车案例，说到底是权限模型没设计好，bot 能做的事超出了团队预期。

在 company-brain 这类体系里，我的建议是给 bot 划分三个安全等级：只读提醒、受限执行、完全授权。

• 只读提醒：bot 只能读取公开频道和指定 GitHub 仓库，产出的内容是“建议”“摘要”“提醒”，不能修改任何数据。初期部署建议先停留在这一档。
• 受限执行：允许 bot 在特定频道创建线程、在 GitHub 上给 issue 打标、触发 CI 重跑等低风险动作，且每个动作必须有日志和人工撤销通道。
• 完全授权：让 bot 能创建 PR、合并分支、修改项目设置。恕我直言，这套配置在大多数公司都不应该开，除非你们团队对 AI 的容错率高到离谱。

从工程角度，实现这个权限模型不需要很花哨的技术。核心是给 bot 的每次外部调用封装一层“动作受理层”，在发起 API 调用前强制检查环境变量或配置文件里定义的权限白名单。另外，所有主动动作必须保留完整的 prompt 输入、模型输出、API 调用记录，事后能回溯“它为什么做这个决定”。

3. 从零搭建一个可用版本：安装、配置与关键代码

3.1 环境准备与依赖清单

先把运行环境这块说清楚。这个项目本身对硬件要求不高，但如果你想让 bot 跑在 7x24 小时，建议不要用个人笔记本电脑，直接上云服务器或一台长期开机的 NAS/小主机都行。我的参考配置是 2 核 4G 内存，跑 Docker 容器就足够了，唯一需要注意的是 Slack API 和 GitHub API 对出口 IP 没有强制限制，但大规模调用前最好确认一下你自己的网络服务质量。

依赖清单上，核心是这几样：

• Node.js 18+ 或 Python 3.10+，取决于你拉到的代码分支对哪个运行时更友好。我实操时用的是 Node 20，主要是因为 Slack 官方 SDK 在 Node 下的生态更完整。
• Docker（可选但强烈建议），把应用和依赖打包在一起，升级回滚都干净。
• Slack App 的 Bot Token 和 App-Level Token，用来建立 WebSocket 长连接和调用 Bolt SDK。
• GitHub Personal Access Token（需要 repo 和 read:org 权限），用于拉取仓库信息和响应 Webhook 事件。

提示：Slack App 的权限范围里，最少要勾选channels:history、chat:write、commands、reactions:write。不要贪多，权限越宽，出风险的概率越大。

3.2 第一次配置 Slack App 的完整步骤

我踩过的坑比想象中多，这里梳理一条安全路径：

打开 Slack API 管理后台，点击 Create New App，选择 From an app manifest，粘贴一份 YAML 格式的配置。用 manifest 方式的好处是权限范围、事件订阅、slash command 可以一次性定义好，避免在网页上翻来覆去勾选。

manifest 里给我留下最深印象的坑是socket_mode的启用。如果不开启 Socket Mode，bot 需要一个公网 HTTPS 地址来接收 Slack 的事件回调。很多人在第一步就被内网穿透这件事卡住。推荐的做法是直接把socket_mode设为true，这样 Slack 会通过 WebSocket 主动推送事件到你本地运行的进程，不再需要公网回调地址。本地开发体验会轻松非常多。

配置完后，把 Bot Token 和 App-Level Token 复制出来，分别设置成环境变量：

export SLACK_BOT_TOKEN=xoxb-xxxxxx export SLACK_APP_TOKEN=xapp-xxxxxx export GITHUB_TOKEN=ghp_xxxxxx

启动项目时，入口文件通常会加载这些环境变量。如果你是第一次接触这类项目，直接在项目根目录创建一个.env文件也行，但注意千万别把它提交到 Git 仓库。

3.3 Git 仓库联动：代码层面怎么接

这个项目理论上应该提供一个处理 GitHub Webhook 的/github/events路由，但你把项目 clone 下来后，大概率需要根据自己的需求改改事件类型过滤逻辑。

后端核心逻辑大致是这样的：当 GitHub 推送pull_request或issues事件时，webhook 处理器把事件 payload 解析成结构化数据，提取关键字段如action、title、user、html_url，然后拼接成一条模板化消息，通过 Slack SDK 发到指定频道。

举一个简化版的思路，伪代码如下：

const payload = req.body; if (payload.action === 'opened' && payload.pull_request) { const pr = payload.pull_request; const message = { channel: 'dev-updates', text: `新 PR 来了：${pr.title}`, attachments: [{ color: '#36a64f', title: `#${pr.number} ${pr.title}`, title_link: pr.html_url, fields: [ { title: '作者', value: pr.user.login, short: true }, { title: '仓库', value: payload.repository.full_name, short: true } ] }] }; await slackClient.chat.postMessage(message); }

这段代码的价值不在实现，在于告诉你“人和 AI 的分工边界”可以怎么划：GitHub webhook 负责确定性事件，AI 负责生成动态摘要。我在实践时会把事件类型先分流，凡是模板能覆盖的直接发，凡是需要综合多来源信息（比如“这个 PR 改了哪些模块、和最近哪个 issue 相关”）的才交给大模型处理。

3.4 让 AI 真正“干活”的提示词设计

前文说的都还是“连接”层面的活，真正体现这个项目价值的地方是Prompt 工程。工程化提示词的思路跟聊天完全不同，它不是一句话，而是一整套“角色 + 上下文 + 输出约束”的组合。

以“每日项目同步”这个场景为例，我设计中会这么做：

系统提示词（System Prompt）： 你是团队的项目协作助理。你的任务是基于 Slck 和 GitHub 的数据，生成一份 简洁、可执行的项目同步报告。报告须包含：今日新增 issue/PR、待 review 列表、 可能被阻塞的任务、跨频道重复讨论提醒。 约束： - 只输出 Markdown 列表，不使用表格 - 每条信息不超过 80 字 - 如果信息不足，明确写“今日无异常”，绝不能编造 - 每一条建议必须附带信息来源的链接

关键的设计点在最后两条约束：“不能编造”和“必须带来源链接”。这两条配合起来，能过滤掉大模型最常见的幻觉问题。我见过太多 bot 翻车都是因为模型把历史信息里的仓库名、成员名张冠李戴，如果每条输出后头都挂着原始链接，阅读者一眼就能揪出错误，纠正成本大大降低。

另一个经验是：给模型的上下文要“按需裁剪”。不要一次把整周的消息全部塞给模型，既超 token 限制，又容易让模型抓不住重点。正确做法是先用关键词对消息做初步筛选，只把候选窗口内真正和项目有关的内容交给模型。我一般会把单次上下文字数控制在 3000 字以内，模型输出质量最为稳定。

4. 实操过程全记录：我用一周时间让它跑通

4.1 本地运行与服务部署细节

纸上谈兵讲了那么多，实操才能真正暴露问题。我的第一轮测试环境就是本地 Docker。把项目 clone 下来后，先构建镜像：

docker build -t company-brain . docker run -d --name company-brain \ -e SLACK_BOT_TOKEN=$SLACK_BOT_TOKEN \ -e SLACK_APP_TOKEN=$SLACK_APP_TOKEN \ -e GITHUB_TOKEN=$GITHUB_TOKEN \ company-brain

这里必须提醒一个坑：如果你只是简单跑npm start，进程会默认监听 3000 端口，但 Slack 的 Socket Mode 用的是 WebSocket，本质上服务不需要暴露任何 HTTP 端口。所以如果 Docker 启动后容器一直重启，大概率是因为进程本身和应用日志的交互有问题，而不是端口绑定不对。用docker logs看报错是最高效的排查手段。

跑通 Slack 连接之后，下一步就是接入 GitHub Webhook。这里建议先在本地用ngrok这类隧道工具做联调，把公网临时地址填到 GitHub 仓库的 Settings -> Webhooks 里。Webhook 地址指向你本地服务的/github/events。我在联调时遇到的典型问题是：Slack Bolt SDK 默认占用了/slack/events路由，而我希望/github/events也跑在同一个服务里，这需要你按框架的规则配置路由前缀，不要想当然。

4.2 一套可复现的“新闻摘要 + 定时日报”配置

第一次真正展示出效果，是做定时日报的那一刻。

在配置文件里，我把定时任务设置成每天早上 10 点执行一次扫描：从指定 GitHub 仓库拉取最近 24 小时的 issue、PR、commit 标题，再从 Slack 的general、dev、product三个频道拉取消息记录，合并之后用模型生成一份 200 字以内的摘要，发送到team-updates频道。

实际第一版跑出来的日报，说实话质量很一般：它在摘要里重复提到了同一个 PR 三次，还把两个不同 issue 的作者搞混了。追查原因，发现是“消息去重”这一步没做好——同一个仓库的事件在 GitHub webhook 里可能以多种形式重复推送，而 Slack 的历史消息里又引用了同一链接，两边没有做关联去重。

解决这个问题，我给扫描模块加了一个简单的缓存层：以关联 URL 为 key，记录每个信息源的最近推送时间，相同 URL 在 6 小时内只处理一次。这样效果立竿见影，日报的可读性一下就上来了。

4.3 多 AI 协作模式的早期实验

既然项目定位是“会主动干活的 AI”，那在实操中多模型协作这件事是绕不开的。我的实验方案是：把任务拆成“信息抽取 + 文案生成”两个环节，分别调用不同模型——抽取环节用速度快的模型跑关键词和实体识别，生成环节用质量高的模型来汇总结论。

举一个场景：从 GitHub issue 讨论串里抽取“决策”和“待办”，再把这两部分交给生成模型编排成一段面向团队的简报。这种分工有两个好处，第一是成本下降，简单任务不必每次都上大模型；第二是责任隔离，如果生成环节出幻觉，至少有抽取环节的结构化事实兜底。

不过我得泼一盆冷水：多 AI 协作在早期项目里最容易变成“多个模型互相干扰”。如果没有清晰的中间数据格式，A 模型的输出格式 B 模型解析不了，整个链路就会报废。建议先用 JSON Schema 把中间产物定死，比如“待办列表必须包含 owner, due_date, task_desc 三个字段”，再让下游模型消费这个结构。

5. 常见问题排查与避坑实录

5.1 Slack 连接不稳定怎么处理

症状是 bot 表现为“时灵时不灵”，有时候能回复，有时候完全没有反应。多数情况下问题出在 Socket Mode 的心跳机制或进程被系统回收。解决思路分三步：先看日志里有没有connection_updated或error关键字；如果连接闪断，给进程加一个守护进程（或者 Docker 的 restart policy 设为unless-stopped）；如果异常频率特别高，检查服务器是不是在 NAT 网络后，有些网络环境会限制长时间 WebSocket 连接。

5.2 GitHub API 限流导致数据抓不全

免费的个人 Token 速率限额是每小时 5000 次请求，听起来很多，但做一次“全仓库扫描 + 多频道消息聚合”很容易就撞到边缘。我的建议是给所有 GitHub API 调用加上本地缓存和条件请求头，只在数据确实变化时才发起完整请求。更直接的办法是把定时扫描的频率从每小时一次改成每 6 小时一次，反正团队里的关键信息没那么实时，省着点配额比频繁扫更安全。

5.3 内容重复推送与权限过宽的应对方案

前文提过的去重缓存是解决重复推送的第一道关卡。第二道关卡是给每条消息做语义指纹：把消息文本做规范化，用哈希算法生成短指纹，如果指纹出现在最近的消息记录里，直接丢弃。这种方式能兼容“同一事件的不同 URL 变体”这类复杂情况。

权限过宽的问题，我在正式部署时用了“最小白名单”原则：环境变量里列出 bot 可以操作的频道名和仓库名，不在名单内的资源一律拒绝。这个名单用逗号分隔，代码里维护一个 Set 即可，不必引入重型权限框架。

5.4 高频踩坑速查表

5.5 关于“无限制 AI”类内容的安全说明

在收集项目相关讨论时，我也注意到网上会有人把这些工具往“无限制”“无审核”方向上带。这个必须明确划清界限：所有内容生成都必须设置合规边界。我自己的做法是在系统提示词层就声明——模型不得生成包含违法、暴力、仇恨或歧视性内容；同时在应用层做关键词过滤和人工抽查，确保推送到团队频道的信息安全合规。

一个商业软件的底线，不在于它能做多少，而在于它知道什么不该做。AI 主动干活的前提，永远是它处在可控的规则框架内。

6. 后续可以怎么扩展

这个项目最吸引我的地方是它的扩展空间非常大。如果你们团队有自己的知识库系统，可以把 company-brain 的聚合模块外接到 Confluence 或 Notion 上，让 bot 不只盯着 Slack 和 GitHub，还能主动把文档变更同步到相关频道；如果你们对数据可视化有需求，也可以让 bot 每个周末汇总一次迭代数据，生成格式化的指标打卡，省去专人去数工具面板的时间。

另外，如果你对多 AI 协作方向有兴趣，可以在现有框架上增加一个“调度器”角色，让主模型先判断用户的问题属于哪一类，再分发给专门的小模型回答。整体架构不需要大改，只要把消息中间件做标准即可。

我个人认为，这类主动型 AI 工具在接下来一年里会越来越多，但真正能长期留住用户的，一定是那些“克制”的产品——知道什么时候该说话，更知道什么时候该安静。建议你在这个项目里先把检索、聚合、去重、权限这些基本功打磨扎实，再去追求更炫酷的主动能力。地基稳了，楼才能盖得高。