1. 在聊技术之前先说清楚——为什么要把Claude Code搬进Slack先别急着要代码我先说一个我自己的真实经历。我们团队前阵子做了一个内部工具平时大家都习惯在GitHub上面提交PR然后让Claude Code去做代码审查。结果每次审查结果都只停留在终端里要么是我截图发到群里要么是同事自己跑去命令行里跑一遍。有一次改动特别急PM在Slack里连环催开发同事就在旁边说我刚让Claude帮我查了那个报错结论是xxx但所有人都看不到这个过程最后信息全散了。这就是Claude Code和Slack结合的真正价值**不是让你在Slack聊天框里敲代码而是把Claude Code的执行过程、输出结果、审查结论直接暴露在团队每天都在的沟通场景里。**大家不用离开聊天界面就能发起代码任务、看到执行结果、参与讨论。尤其适合那种代码审查Bug排查技术方案咨询和日常开发辅助四类高频场景。这套方案适合谁首先是开发团队想把AI辅助开发变成可共享的团队能力而不是个人终端里的玩具其次是技术管理者想在不折腾团队工作流的前提下让AI审查、AI排错的结果自动沉淀到团队的沟通记录里最后是独立开发者想把Claude Code变成一个可通过Slack随时随地遥控的远程开发助手。我实测下来只要不是特别极端的情况下这套集成是完全可用的。下面我把从Slack App创建到桥接服务实现再到权限设计和实际踩坑的全过程完整展开。2. Slack App的创建权限和端点配置才是最容易翻车的地方很多教程一上来就甩代码但代码跑不起来的原因基本都出在Slack App配置上。我先把这一步拆透。2.1 创建Slack App时的归属选择进入api.slack.com/apps点 Create New App会先让你选From scratch或者从manifest文件。我的建议是直接选From manifest因为manifest可以把Bot Token、Scopes、Event Subscriptions全部声明在一个YAML文件里后续维护和迁移都方便。如果你直接选From scratch后面配置界面点得头晕不说少勾一个event都查半天。App创建好后第一件事是去Basic Information里记下你的App ID、Client ID、Client Secret后续桥接服务里要用到。这个页面也是整个Slack应用的心脏权限调整、Token管理、删除应用都在这里。2.2 必须勾选的OAuth Scopes清单Scopes决定了你的机器人能做什么。我团队踩过最蠢的坑是忘了加chat:write结果机器人能听到消息但没法回复看起来像信号黑洞。下面这个列表是我目前在实际项目中验证过的完整集合Scope作用是否必须chat:write往频道/会话发消息必选channels:history读取频道历史消息必选channels:read查看频道基本信息必选im:history读取私聊消息选配im:write私聊中回复消息选配reactions:write给消息加表情反应用作已收到反馈选配commands支持斜杠命令选配users:read获取用户基本信息推荐勾选这里有一个细节Slack的Bot Token是基于每个Workspace的不是全局的。也就是说同一个Slack App被安装到不同的Workspace里会生成不同的Bot Token。你在本地测试时安装到你的测试Workspace真正部署时还要给客户的Workspace再走一遍安装流程。不要想着一个Token走天下。2.3 Event Subscriptions和Socket Mode的选择Slack提供了两种接收事件的方式HTTP Request URL你需要一个公网可访问的HTTPS端点Slack把事件POST过来。适合部署在云服务器上的场景但本地开发调试很痛苦还得用内网穿透工具。Socket ModeSlack通过WebSocket长连接把事件推给你不需要公网端点。适合本地运行、内网部署。我推荐本地跑通用Socket Mode真的省去一大半环境配置的麻烦。开启Socket Mode之后你需要为它单独申请一个App-Level Token权限是connections:write。注意这个Token的开头是xapp-区别于Bot Token的xoxb-别搞混。事件订阅这里必须勾选你要监听的事件类型。常用的是message.channels监听公开频道消息message.im监听私聊消息app_mention当机器人被时触发不勾选对应事件无论你怎么发消息机器人都是盲的。2.4 把App安装到Workspace配置完Scopes和Events去Install App页面把App安装到你的Workspace安装完成后会拿到Bot Token。这里我强烈建议你保存到一个.env文件里后面桥接服务启动时读取别硬编码到代码里。至此Slack侧的基础设施已经就绪。你不需要去理解Slack的全部API光是这四件套——App创建、Scope配置、Socket Mode开启、Event订阅——就已经覆盖了接收消息并回复消息的核心链路。3. 桥接层的设计Slack消息是如何变成Claude Code任务的现在进入最核心的部分怎么把一条Slack消息转化成Claude Code能执行的编码或审查任务。3.1 为什么需要桥接层直接说破一点目前Claude Code没有一个官方发布的、开箱即用的Slack集成插件。我们能走通的方案是在Slack和Claude Code之间加一个轻量的桥接服务。这个桥接服务的本质很简单监听Slack事件 - 把消息组装成Claude Code CLI的输入 - 捕获输出 - 回发到Slack。我用一张图描述一下消息流转文字版用户在Slack频道发消息并机器人 | v 桥接服务监听Slack事件Socket Mode | v 桥接服务解析消息、检查权限、组装Prompt | v 调用Claude Code CLI以非交互模式或脚本模式执行 | v 捕获Claude Code的输出结果 | v 把结果格式化后通过chat.postMessage发回Slack频道这个设计的好处是Claude Code本身不需要任何改动。它就是一个跑在本地的、可以通过CLI调用的终端工具桥接层把Slack的聊天语言翻译成CLI指令再把CLI输出翻译回聊天语言。两边都只需要做好自己的一件事。3.2 核心代码骨架一个Python桥接服务我目前的生产方案使用Python slack-sdkslack-boltBolt框架自带Socket Mode支持代码量最少。下面给出一个精简但完整的实现框架# bot.py import os import subprocess import tempfile from slack_bolt import App from slack_bolt.adapter.socket_mode import SocketModeHandler # 环境变量读取不建议硬编码 BOT_TOKEN os.environ[SLACK_BOT_TOKEN] APP_TOKEN os.environ[SLACK_APP_TOKEN] app App(tokenBOT_TOKEN) def call_claude_code(prompt: str, cwd: str None) - str: 调用Claude Code CLI并以宽松超时方式捕获输出。 # 这里使用非交互调用把 prompt 作为输入传入 # 实际项目中要注意运行目录我后面会单独讲 with tempfile.TemporaryDirectory() as tmp_dir: target_dir cwd or tmp_dir result subprocess.run( [claude, -p, prompt], capture_outputTrue, textTrue, timeout600, cwdtarget_dir, ) if result.returncode ! 0: return f[Claude Code执行失败]\n{result.stderr[-2000:]} return result.stdout[-4000:] # 监听机器人消息 app.event(app_mention) def handle_mention(event, say): text event.get(text, ) # 去掉机器人的那段才是真正的指令 clean_text text.split(, 1)[-1].strip() say(收到正在调用 Claude Code请稍候...) result call_claude_code(clean_text) say(f\n{result}\n) # 监听私聊消息 app.event(message.im) def handle_dm(event, say): text event.get(text, ) if text.startswith(!): result call_claude_code(text[1:].strip()) say(f\n{result}\n) if __name__ __main__: handler SocketModeHandler(app, APP_TOKEN) handler.start()这段代码有三个细节值得展开第一是-p参数。Claude Code CLI的-p即--print模式会直接把模型输出打印到stdout后退出非常适合桥接场景。默认情况下它是带流式输出的我们加capture_outputTrue后一次性拿结果。第二是timeout600。Slack面对一个长期不回复的机器人不会报错但你的团队会因为等待而烦躁。根据任务复杂度设定超时时间很关键我们后来把超时策略改成了两档普通问答任务给3分钟代码审查任务给10分钟。第三是输出长度截断。Claude Code的输出可能很长超过Slack单条消息上限40000字符会导致发送失败。我做了[-2000:]或[-4000:]的截断处理经验是先整体发出去需要更多结果让用户输入继续。后面进阶方案里我会给一个分页输出的思路。3.3 会话管理不要让多个同事的任务互相串台上面的demo代码有个致命问题没有会话隔离。如果团队里有三个人同时机器人三个Claude Code进程会同时跑输出结果会互相混淆。解决办法是给每个用户或每个频道维护独立的会话上下文。我用的方案是一行一会话、一人一目录import os, uuid def get_session_dir(user_id: str) - str: 为每个用户创建独立工作目录避免同时运行多个任务时互相踩踏。 session_root os.path.expanduser(~/.claude-slack/sessions) user_session_dir os.path.join(session_root, user_id) os.makedirs(user_session_dir, exist_okTrue) return user_session_dir每个用户的任务都在自己的目录下运行Claude Code会在该目录里生成.claude相关的上下文文件历史记忆、配置文件这样A用户的项目历史和B用户的完全隔离。如果你更进一步想让同一个用户在多个频道有不同上下文可以在目录名里加上channel_id。这里必须注意一个坑多进程并发的Claude Code任务可能共享全局配置文件。如果你在~/.claude.json里加了自定义模型、API Key的配置多个进程同时启动时可能产生读写冲突。稳妥方案是给每个session目录单独放置一份配置文件或者把Claude Code跑在容器/子进程中并限制并发数。我们团队的做法是引入一个简单的信号量限制全局最大并发任务数为2其他请求排队等待实测稳定性高很多。3.4 临时任务目录 vs 持久项目目录桥接服务的另一个设计决策是Claude Code在哪个目录下运行两种选择各有用途临时目录模式每次任务都新开一个tempfile.TemporaryDirectory()适合不做深入编码、只做问答和方案咨询的场景。好处是干净不会留下任何历史文件坏处是无法读取你项目里的实际代码。持久项目目录模式桥接服务配置一个固定的项目根路径Claude Code在这个目录里运行可以直接读取代码仓库、修改文件、跑测试。适合代码审查、Bug定位、小型需求实现。我实际用的方案是混合模式桥接服务识别消息里的关键词比如带[review]标签的走持久目录的代码审查流程不带标签的走临时目录问答模式这样兼顾干净和效率。4. 实战场景演示在Slack里完成一次代码审查光说架构太抽象我直接以一个真实的代码审查场景走一遍完整流程你能看到每个步骤的输出形态和人工介入点。4.1 场景设定假设团队有一个仓库路径是/data/projects/order-service同事提交了一个PR改动是调整订单状态机的处理逻辑。在Slack频道里TA发了一条消息claude-bot [review] 请审查 /data/projects/order-service 里 order_state.py 的改动 重点看状态流转是否安全有没有并发问题以及异常处理是否到位。桥接服务收到消息后做三件事检查消息里是否有[review]标记当前用户是否有审查权限剥离claude-bot和[review]剩余内容作为prompt传给Claude Code指定运行目录为/data/projects/order-service追加一个系统提示词让Claude Code先读Git diff再审查。4.2 桥接层追加的审查提示词这一步很关键直接决定审查质量。我们在桥接层预先拼接了一段System Prompt你是一位资深代码审查者。请先执行 git diff 查看当前分支相对主分支的改动 然后从以下几个方面审查状态流转正确性、并发安全、边界条件、异常处理、 可维护性。输出格式按严重程度分级P0/P1/P2每条问题给出文件位置、 理由和修改建议。最后给出整体结论。把这段提示词和用户消息拼在一起作为最终Prompt传给Claude Code。4.3 实际运行效果和人工介入Claude Code执行后桥接层捕获输出格式化发回Slack。真实回复看起来像这样审查完成共发现 4 个问题 P1 - order_state.py:182 状态流转缺少 REJECTED - PENDING 的兜底分支 用户在退款驳回后无法重新提交导致流程卡死。 建议补充分支或明确拒绝策略。 P2 - order_state.py:120 update_state 方法中读-改-写不是原子操作 在高并发状态下可能丢失状态更新。 建议使用数据库行级锁或对比-交换Compare-And-Swap模式。 P2 - order_state.py:204 异常捕获过于宽泛Exception 兜底会把系统性故障当成可恢复错误 造成状态不一致。 建议区分业务异常和系统异常。 P3 - order_state.py:88 命名 state_active 和 state_finished 语义不够清晰 建议改为 ACTIVE / FINISHED 枚举。 整体结论建议修复 P1 后再合并P2 在下一迭代处理。当输出太长时我会在回复末尾追加提示输出过长如需查看完整审查结果请回复继续用户回复继续后桥接层把剩余截断部分发出来。这个分页拉取机制在审查大型代码块时几乎是必备的。4.4 长任务怎么切成增量任务Slack里的对话天然是短节奏的不适合把一个半小时的长任务一次性丢给Claude Code。我的经验是把任务粒度拆小普通问题排查直接一条消息问完3分钟超时代码审查限制为只看这个PR的diff不扩展到全仓库历史小型功能实现先让Claude Code生成实现方案人确认后再让它写代码最后让它补测试。每拆一步用户就多一次确认的机会也就少一次跑偏返工的机会。这一步是把AI当成团队实习生的正确打开方式而不是把AI当成无人值守的自动化流水线。5. 权限与安全设计不能让它变成公开的Shell把Claude Code暴露给整个团队本质上等于在Slack里开了一个能执行任意代码的入口。如果不做权限控制后果你懂的。下面是我在生产环境里验证过的一套围栏方案。5.1 频道白名单与用户黑名单桥接服务启动时读一个配置文件只有白名单内的频道才响应消息白名单外的消息一律忽略。同时在代码里加一层用户校验ALLOWED_CHANNELS set(os.environ.get(ALLOWED_CHANNELS, ).split(,)) ALLOWED_USERS set(os.environ.get(ALLOWED_USERS, ).split(,)) def is_allowed(channel_id: str, user_id: str) - bool: if channel_id not in ALLOWED_CHANNELS: return False if ALLOWED_USERS and user_id not in ALLOWED_USERS: return False return True白名单的好处是默认拒绝你不需要维护一份哪些人不许用的黑名单而是天然只对特定频道开放新同事进群也不会有权限。权限变化时只需要改环境变量并重启桥接服务。5.2 命令关键字白名单不是所有消息都值得转成Claude Code任务。我在桥接层加了一个简单的命令路由命令前缀目标行为示例[review]代码审查[review] 看下 payment.py 的改动[fix]定位并修复Bug[fix] 修复登录态过期后跳转死循环[explain]代码解释/教学[explain] 这个lambda表达式的闭包捕获机制[refactor]重构建议[refactor] 这个模块如何拆成两个类默认轻量问答解释一下Go的defer执行顺序没带前缀的消息不唤起Claude Code只做普通问答或忽略。这样做有两个好处减少误触发让Claude Code只在明确任务下工作同时增强安全意识——你可以在网关层拦截[shell]、[exec]这类高危命令从源头限死。5.3 敏感信息脱敏和操作审计这个我多说一句。Claude Code在处理私有代码仓库时有可能把代码片段、密钥、第三方服务凭证等敏感信息带进对话里。我的加固方案有三层前置脱敏在把消息发给Claude Code之前用正则把这些模式替换掉sk-[a-zA-Z0-9]{20,}、AKIA[0-9A-Z]{16}、数据库jdbc:mysql://...里的密码。替换成REDACTED再进模型输出过滤桥接服务在把Claude Code输出发回Slack之前二次扫描发现敏感模式就截断该段并用提示语替换。这个双层过滤实测能挡住绝大部分泄密场景审计日志每次调用都记录user_id channel_id prompt摘要 输出长度 耗时。不记录完整输出但留足排查线索。Slack侧可以设置消息保留策略不额外处理。注意脱敏只能作为预防不能作为绝对保证。如果你在代码仓库里存有线上环境的密钥文件别指望AI审查时能帮你严格保密。最稳的措施始终是把密钥通过环境变量注入不要在仓库文本里出现。5.4 高危操作需要二次确认Claude Code在-p模式下默认不会主动执行计划外的高危操作但即便它会你也应该在桥接层加一道兜底。我们做的方案是请求文本里如果包含rm、DROP TABLE、git push、git reset --hard等危险关键字桥接服务拒绝直接执行而是返回一个确认按钮。用户点击确认后带着确认标记再次调用Claude Code。这一步会牺牲一些全自动体验但换来的是人永远保留最终控制权。拿团队Copilot这种场景来说控制权比效率重要得多。6. 实测中踩过的坑Slack集成的六个高频事故现场下面这些坑全是我在生产环境里真实撞过的按翻车频率排序。6.1 Socket Mode连接掉线后静默失联Socket Mode听起来省事但长时间运行后偶发掉线。最恶心的不是掉线本身而是Bolt框架不会主动把错误抛给你表现为机器人死了但不报错。我的解决办法是加了一个健康检查线程每60秒给桥接服务的一个内部端点发一次ping如果连续三次无响应就自动拉起一个新的Socket连接。同时把Bolt的日志级别调到INFO把连接状态输出到标准输出接入日志平台后才能在第一时间感知掉线。6.2 Slack的3秒超时和任务执行时长的矛盾默认情况下Slack的Socket Mode事件要求在3秒内做ack否则会重试推送。如果你的桥接服务在3秒内没有响应可能造成消息重复处理。我的处理方式Bolt的say()方法会立即发送一条收到正在处理这属于异步发送不阻塞事件ack实际任务用子进程后台跑结果出来后通过client.chat_postMessage发送。如果要做得更规范可以把每条消息的处理状态记录在内存里重复消息进来时检查任务是否已在执行中是则忽略。6.3 并发调用Claude Code时的全局配置锁冲突我之前提过多个Claude Code进程同时跑时会抢全局配置文件。具体表现是任务A启动后干了一批活任务B启动时把配置改成了B需要的参数任务A后半程就莫名其妙切换了模型或上下文。稳定方案是给桥接层加一个并发控制用threading.Semaphore(2)限制最多两个任务同时执行。多出来的任务先进入队列并在Slack里告知排队等待时间。这个设计在公司内部用一个下午就没有再复现过配置错乱问题。6.4 上下文漂移同一个频道聊着聊着Claude忘了前面的任务如果不做上下文管理每次调用Claude Code都是独立的、无记忆的。你在Slack里发上次那个重构方案再细化一下第二点Claude Code完全不记得上次是哪次。我的处理是做一个简陋但有效的记忆拼接把每个用户在某个频道的最近5轮交互记录存到SQLite里每轮新请求自动把前几轮的prompt/输出摘要拼进Context里。这样至少能保证短期的对话连贯性。更进阶的用法是让Claude Code自己把有保留价值的结论写成项目里的笔记文件比如AI_NOTES.md后续查询时优先读取该文件既节约Token又能确保上下文不漂移。6.5 Markdown渲染和代码块适配问题Slack的Markdown支持有限跟GitHub的Markdown渲染差异很大。最典型的表现Claude Code输出的表格在Slack里直接乱掉列表的缩进层级也常常丢失。我的经验是对发送内容做一次轻量转换所有表格转换成文本对齐的无序列表代码块保留用 包裹长链接手动转换成带说明的文本链接。Claude Code输出的代码块标签适配Slack的代码样式提前做好映射否则发出去是看不懂的乱码字符。6.6 机器人不提示团队成员还有一个体验大坑机器人只回复已收到但没发起人团队成员很容易就漏掉关键反馈。Bolt的say()默认是在所在频道直接发消息不会主动任何人。要人方法是在消息文本里动态插入USER_ID前缀Slack会自动渲染成蓝色高亮的人名say(f{user_id} 审查完成结果如下\n{formatted_output})这样既让发起人第一时间收到提醒又让频道里的其他成员知道这条结果对应谁的任务。细节虽小但对团队的接受度影响很大——没人喜欢在一个嘈杂频道里找自己那份AI回复。7. 进阶方向从Slack命令接收器走向团队Copilot最后这一部分说说我接下来打算做、以及亲眼见过别人做得不错的延伸方向。当前版本实质上还是人在Slack里手动发指令等结果。下一阶段是两个方向一是把任务自动化。比如GitHub Webhook触发PR事件后自动让桥接服务调用Claude Code做review然后把结论贴回PR对应的频道或者Jira工单状态变更后让Claude Code自动生成一个初步处理方案。这个方向的核心不是技术而是业务规则设计——什么时候该自动介入什么时候该保持人工。二是把答案沉淀为团队知识库。现在每次Claude Code输出完结果只留在聊天记录里过三天就没人翻得到。我在桥接服务后面接了向量检索把每次请求的prompt output结构化存入本地知识库之后团队直接问上次那个状态机问题我们怎么解决的桥接服务先检索历史再决定是直接回答还是问Claude Code。实测能显著减少重复劳动。如果你想做多环境隔离也可以把Claude Code跑在GitHub Codespace或容器里让桥接服务通过SSH或Docker API远程调用这样开发机本地不需要装任何Claude相关依赖。这个方案在你需要给不同项目配置不同模型、不同上下文时尤其好用。我个人更关注的是如何让Slack里的人工确认环节变成标准的代码审查门禁。也就是Claude Code输出审查结论后必须有一到两个指定Reviewer按下通过桥接服务才继续下一步比如自动合并PR。这一步把AI的效率和人的判断结合起来也是我认为AI辅助开发里最有价值的产品形态之一。先把上面的基础跑通然后根据自己的团队流程往里面加权限、加记忆、加自动触发逻辑你就会发现Claude Code从终端里的魔法真正变成了团队里的基础设施。这个演化过程比一步到位做出一堆花哨功能稳定得多。