给公司请一位 AI 同事:我用 Claude Code 造了一个 claude-claw

产品经理在飞书群里丢了一段话——「@claude-claw 给『用户中心』加个需求，登录页接入 Google OAuth，优先级 P1，指派给小王。」几秒后机器人回了一张卡片：禅道需求单 #1287 已创建，标题、优先级、负责人全部到位，点一下直接跳转工单页。这就是 claude-claw——一只每天在公司群里值班的 AI 员工。

🧑‍💼真实习生：会请假、会摸鱼、记性时好时坏、权限靠 HR 手动约束、同时只能服务一个老板。

🤖claude-claw：7×24 在线，对话上下文天然延续，只能碰你允许的东西，同时为整个团队服务，每个人一份独立会话。

网关做三件事——接入飞书（用 WSClient 长连接，不走 webhook，公司内网无公网域名也能跑）、身份校验（whitelist.json 热加载，30 秒内生效）、容器调度（每个飞书用户按 user_id 哈希到固定容器，对话上下文自然连贯，空闲 30 分钟自动回收）。

容器里跑着一个 Node HTTP 服务，收到 prompt 就喂给 Claude Agent SDK 的query()，把流式事件以 SSE 推回 Gateway。用node:22-slim起，rootfs 只读，唯一可写的目录是/work——用户上传的图片、生成的截图、临时文件全落这里，出这一格就动不了。

这是 claude-claw 的"手"。我写了四个 MCP Server：mcp-lark（回消息/建飞书文档/授权）、mcp-zentao（建需求/任务/Bug）、mcp-history（查历史聊天归档）、mcp-web（常驻 Playwright 浏览器读带登录态的内网站点）。另外还装了lark-cli，封装 200+ 飞书 API，Claude 直接通过 Bash 调用。

PM 讨论到一半说"这个录到禅道里，指派给我"，claude-claw 就会抽出关键信息、调用mcp__zentao__create_story，建完回复带工单号和链接的交互卡片。整个过程没有任何表单填写。

评审结束，一句"把刚才结论整理成文档放在这个群"，claude-claw 回溯前 20 条消息，生成带标题、分段、待办的飞书 Doc，并自动给群成员授予编辑权限——这一步是个暗坑，等会儿单独讲。

"上周有人提到 OAuth 的问题吗？"一句话，mcp-history扫 SQLite 里的聊天归档，返回相关消息片段。时间维度、关键词维度都能查。

设计师把内部 CoDesign 链接丢进群："帮我看看这个稿子"，claude-claw 通过常驻 Playwright 浏览器（复用真实登录态）打开页面、截图、读文字，然后基于内容回答。

用户可直接在消息里带图片、PDF、视频。Gateway 把附件下载到/work/sessions/xxx/，在 prompt 里以绝对路径传进去。视频则由 ffmpeg 预抽 N 张关键帧，当成一条时间线来理解。

沙箱容器--read-only根文件系统，cap-drop=ALL，没有 host 网络，没有挂载 docker.sock。就算 AI 被骗着写rm -rf /，它也只能在 /work 里自己玩自己。

settings.json 默认deny 一切，只 allow 白名单：Read 限定 /work，Bash 限定 ls/cat/grep/git log 这类只读命令，Write 同样只许写 /work。这层是 Claude Code 原生机制，不需要额外开发。

pre_tool_use钩子在每次工具调用前做二次校验：路径前缀合法吗？命令是否命中黑名单（curl/wget/nc/ssh/...）？MCP 参数有没有拼接执行风险？这一层是兜底，防止权限配置自身出现疏漏。

lark-cli 支持bot和user两种身份。不加约束时 Claude 会为了"办成事"自动 fallback 到 user——结果就是A 问一句话，机器人拿着 B 的账号去读 B 的私人日历。我在 system prompt 和 hook 里双重约束"永远不要用 --as user"。

⚠️ 这个坑是我上线前两天才意识到的。真实项目里，AI 会为了完成任务而"聪明"地找捷径，而这些捷径往往就是权限漏洞。多想一步，不让它"自由发挥"。

如果你也在考虑给团队做类似的事，送你三句话：

1️⃣从一个高频且痛的场景开始——不要一上来就想"做一个能做所有事的助手"。我选禅道，是因为每天都在用，填表单又烦。

2️⃣权限设计先于功能设计——想清楚 AI 能碰什么、不能碰什么，再想它能做什么。反过来做会爆炸。

3️⃣让 Claude Code 自己决定怎么做——你负责画边界，它负责做决定。别把它当函数调。