1. 项目概述这不是一个“装软件”的事而是一次AI工作流的本地化扎根OpenClaw 这个名字最近在技术圈里出现的频率越来越高但很多人第一次看到它下意识会以为是某个开源爬虫工具或者硬件驱动——其实完全不是。OpenClaw 是一个面向开发者和AI产品团队的本地化AI技能调度中枢它的核心价值不在于自己生成文字或画图而在于把 Claude、Codex、本地Ollama模型、Zabbix告警、飞书多维表格、甚至交换机SNMP采集脚本这些原本彼此割裂的“能力单元”用统一的命令行接口CLI和可编程的Skill定义串起来。你敲一条openclaw run --skill zabbix-alert --env prod它就能自动查Zabbix API、解析告警级别、调用飞书机器人推送带格式卡片到值班群——整个链路全在你自己的机器上跑不走任何第三方云服务。所以“OpenClaw 安装 飞书配置手册”这个标题表面看是教你怎么点几下鼠标装个程序实际拆开是三层硬核动作第一层是构建一个可信赖的本地执行环境Python虚拟环境隔离、Git凭证安全存储、CLI权限管控第二层是打通企业级通信枢纽的认证与权限体系飞书开放平台的Bot创建、IP白名单、事件订阅、消息加解密第三层是完成技能Skill的语义对齐与上下文注入比如飞书收到的“我查数据库慢查询”这句话怎么被OpenClaw准确识别为触发mysql-slowlog这个Skill并自动填入当前群聊ID、发起人OpenID、时间窗口等上下文参数。我去年在给一家做工业IoT的客户做POC时就卡在第三层整整三天——不是代码报错而是飞书发来的事件体里chat_type字段在单聊和群聊场景下值不同而OpenClaw默认模板只处理了group类型导致私聊指令全部静默。这种坑官方文档不会写Stack Overflow也搜不到只能靠实操日志一行行比对。你不需要是飞书开放平台的认证开发者才能开始但必须清楚自己要解决什么问题是想让运维同学在飞书群里直接输入/deploy staging就触发Jenkins流水线还是让产品经理用自然语言查多维表格里的需求排期又或者把Zabbix的High级别告警自动转成飞书待办并指派给对应负责人目标越具体配置过程中的取舍就越清晰。比如如果你只需要单向推送Zabbix→飞书那根本不用配飞书的event_callback省掉HTTPS证书、签名验证、重试机制这一整套复杂逻辑但如果你要做双向交互用户在飞书点按钮→OpenClaw调API→返回结果到同一消息中那message_id的幂等性校验、updateMessage接口的频率限制、飞书卡片按钮的action_id映射每一个都是绕不开的坎。这篇手册就是把我踩过的所有这类“非报错型故障”——那些让系统看起来运行正常、但关键功能就是不生效的隐形陷阱——全部摊开讲透。2. 环境准备与安装实操为什么必须用venv而不是全局pip以及Git配置里藏着的三个致命细节2.1 Python环境拒绝“python -m pip install”从venv开始就是一场信任重建OpenClaw 的底层依赖非常“诚实”它不封装、不魔改直接暴露Python生态的原始水位线。这意味着你机器上已有的全局pip包版本、系统级SSL证书、甚至/usr/local/bin下的软链接都会成为安装失败的伏笔。我见过最典型的案例是一位同事在Mac上用Homebrew装的Python 3.11which python3指向/opt/homebrew/bin/python3但pip3 list却显示一堆-e开头的editable安装包——那是他之前用pip install -e .调试某个项目留下的。结果pip install openclaw时pip试图升级pydantic到2.6而那个editable包锁死在1.10直接报ERROR: Cannot uninstall pydantic。这种冲突全局环境里永远理不清。正确姿势只有一条用venv创建绝对干净的沙盒。注意不是virtualenv也不是conda就是Python 3.3自带的venv模块。原因很简单OpenClaw的CI流程全部基于venv测试它的pyproject.toml里requires-python 3.9的约束在venv里能100%复现。操作步骤如下# 创建独立环境路径别用空格或中文 python3 -m venv ~/openclaw-env # 激活Linux/macOS source ~/openclaw-env/bin/activate # Windows用户用这句 # ~/openclaw-env/Scripts/activate.bat # 升级pip到最新稳定版重要旧pip对pyproject.toml支持不全 pip install --upgrade pip # 此时检查应该只有pip, setuptools, wheel三个包 pip list提示venv创建后bin/activate脚本会修改PATH确保which python和which pip都指向沙盒内路径。如果pip list还看到其他包说明激活失败立刻检查source命令是否拼错或者终端是否开了新窗口没重新激活。2.2 Git配置三处不写进教程但决定你能否顺利拉取Skill仓库OpenClaw的Skill不是内置的而是通过Git URL动态加载。官方推荐的openclaw init命令本质就是git clone一个模板仓库到~/.openclaw/skills。这就引出Git配置的三个生死细节第一SSH密钥必须绑定到你的GitHub账号且不能是Gist专用密钥。很多教程教你ssh-keygen -t ed25519 -C your_emailexample.com但没说后续ssh-add ~/.ssh/id_ed25519后必须用ssh -T gitgithub.com验证返回Hi username! Youve successfully authenticated...。我曾因公司电脑的SSH代理配置错误导致git clone卡在Resolving deltas阶段长达8分钟最后发现是~/.ssh/config里ProxyCommand指向了一个已失效的跳板机。第二全局user.name和user.email必须与GitHub账号完全一致。OpenClaw在初始化Skill仓库时会用git config --global user.name的值作为Skill作者署名。如果这里填的是公司邮箱而GitHub账号绑定的是个人Gmail后续你提交Skill修改时GitHub会显示“unverified email”导致PR无法合并——这在团队协作中是硬伤。第三必须设置core.autocrlf。Windows用户尤其注意git config --global core.autocrlf true换行符自动转换Linux/macOS用户设为input仅提交时转换。否则你在Windows上编辑的skill.yaml文件换行符变成CRLF推送到GitHub后Linux服务器拉取时openclaw解析YAML会报yaml.scanner.ScannerError: while scanning for the next token——因为YAML规范严格要求LF。2.3 OpenClaw安装避开PyPI镜像的“版本幻觉”直接pip install openclaw看似最简单但存在两个隐患一是PyPI上的openclaw包可能滞后于GitHub主干分支比如你看到热词里有openclaw skill但PyPI最新版还没集成Skill CLI子命令二是国内镜像源如清华、豆瓣有时会缓存旧版本的wheel包导致安装的其实是半年前的0.8.2而非最新的0.9.4。我的建议是强制从GitHub安装主干分支。命令只有一行但包含了关键防护pip install --no-deps --force-reinstall githttps://github.com/openclaw/openclaw.gitmain#eggopenclaw解释一下参数--no-deps先不装依赖避免pip自动降级已有包比如它可能把你的requests 2.31强行换成2.28--force-reinstall覆盖已存在版本防止残留旧文件githttps://...main明确指定main分支不是release tag确保拿到最新特性#eggopenclaw告诉pip这个包的名称否则它会按仓库名openclaw-openclaw来注册。装完后立刻验证openclaw --version # 应输出类似 0.9.4gabc123 openclaw help # 确认help文本里有skill子命令如果openclaw --version报command not found说明venv的bin目录没在PATH里——回到2.1节重新source激活。3. 飞书开放平台配置全流程从Bot创建到事件订阅每一步背后的权限逻辑3.1 创建Bot为什么“自建应用”比“小程序”更合适以及App ID/App Secret的保管铁律OpenClaw对接飞书必须走“自建应用”路径而非“小程序”。原因在于权限粒度小程序的Bot权限是预设的比如只能发消息、不能读群成员而OpenClaw需要的权限是动态组合的——查多维表格要bitable:readonly发消息要im:message:send读群成员要contact:chat:readonly。只有“自建应用”允许你勾选任意权限集并在后续的openclaw config命令里精确映射。创建步骤登录飞书开放平台 https://open.feishu.cn/点击右上角【创建应用】→ 选择【自建应用】→ 填写应用名称建议含openclaw-prod字样方便后期审计进入【机器人】标签页 → 【添加机器人】→ 类型选【群机器人】不要选“个人机器人”后者无法接收群内消息关键一步在【安全设置】里关闭“启用IP白名单”。很多教程强调要开IP白名单但这是针对公网部署的服务器。如果你在本地笔记本跑OpenClawIP是家庭宽带动态分配的每次重启路由器就变白名单形同虚设。真正该做的是下一步的“加密密钥”复制【App ID】、【App Secret】、【Verification Token】、【Encrypt Key】四个值。其中Encrypt Key是飞书消息加解密的关键必须和Verification Token一起保管——OpenClaw启动时会用这两个值验证每条飞书HTTP请求的签名防止伪造。注意App Secret是最高机密绝不能硬编码在config.yaml里。我的做法是在~/.openclaw/目录下创建secrets.env文件内容为FEISHU_APP_IDcli_xxx FEISHU_APP_SECRETxxx FEISHU_VERIFICATION_TOKENxxx FEISHU_ENCRYPT_KEYxxx然后在启动OpenClaw前用source ~/.openclaw/secrets.env加载。这样即使config.yaml被误传到GitHub密钥也不会泄露。3.2 配置Webhook为什么必须用ngrok以及如何绕过飞书的HTTPS证书校验OpenClaw要接收飞书发来的事件如用户发送消息、点击按钮必须提供一个公网可访问的HTTPS Endpoint。本地开发时你没有固定域名和SSL证书所以必须用内网穿透工具。强烈推荐ngrok非免费版理由有三免费版ngrok的域名每小时轮换而飞书要求Webhook地址在应用配置里永久固定ngrok的https://xxx.ngrok.io域名飞书的HTTPS校验能100%通过它内置了ngrok的CA根证书免费替代品如localtunnel、serveo常因证书问题被飞书拒绝报错error: 发送飞书失败, 返回信息:{code:11232,msg:frequency limited psm[lark——这个11232错误码90%以上是HTTPS握手失败导致的“频率限制”假象。ngrok配置步骤下载ngrokhttps://ngrok.com/download解压后./ngrok config add-authtoken your_tokentoken在ngrok官网Dashboard获取启动隧道./ngrok http 8000OpenClaw默认监听8000端口复制生成的https://xxx.ngrok.io地址回到飞书开放平台【事件订阅】标签页 → 【启用事件订阅】→ 在【Request URL】填入https://xxx.ngrok.io/webhook注意末尾的/webhook是OpenClaw约定路径点击【验证】。此时飞书会向你的ngrok地址发一个GET请求OpenClaw会自动响应challenge参数验证通过后状态变为“已启用”。提示ngrok启动后终端会显示实时请求日志。当飞书验证时你会看到GET /webhook?challengexxx的日志这就是成功信号。如果一直卡在“验证中”检查OpenClaw是否已启动openclaw serve以及防火墙是否放行了8000端口。3.3 权限申请与授权为什么“同意授权”按钮要点两次以及scope的最小化原则飞书Bot要执行操作如发消息、读表格必须获得用户授权。这个过程分两步第一步在飞书客户端里“同意授权”打开飞书App → 左下角【工作台】→ 找到你创建的应用 → 点击进入 → 点【同意授权】。此时飞书会弹窗列出所有申请的权限如im:message:send,bitable:readonly。重点来了这个弹窗里的“同意”按钮必须点两次。第一次点只是把授权状态从“未授权”变成“待确认”第二次点才真正把OAuth2的authorization_code发给OpenClaw。很多用户点一次就以为完成了结果openclaw config时提示No authorization code received。第二步在OpenClaw里完成OAuth2 Code Exchange在终端运行openclaw config --provider feishu --auth-code code_from_feishu这里的code_from_feishu就是飞书授权成功后重定向URL里的code参数值形如codexxx.yyy.zzz。OpenClaw会用这个code加上你的App ID和App Secret向飞书OAuth2接口换取access_token和refresh_token并自动存入~/.openclaw/credentials.json。实操心得access_token有效期2小时refresh_token有效期30天。OpenClaw会在token过期前自动刷新但前提是refresh_token没被飞书主动废止。所以永远不要在飞书管理后台手动“撤销授权”否则所有已存token立即失效必须重新走授权流程。我的经验是把refresh_token定期备份到密码管理器比依赖飞书后台更可靠。4. 核心配置与技能部署从config.yaml到第一个/hello命令的完整链路4.1config.yaml详解每个字段的业务含义而非技术参数OpenClaw的配置文件~/.openclaw/config.yaml不是简单的键值对而是定义了AI工作流的“宪法”。我们逐字段解读其真实业务含义# 这是你的OpenClaw实例的唯一身份标识用于区分不同环境 instance_id: prod-laptop-2024 # 飞书Bot的元数据必须和开放平台创建的一致 feishu: app_id: ${FEISHU_APP_ID} # 引用环境变量非明文 app_secret: ${FEISHU_APP_SECRET} verification_token: ${FEISHU_VERIFICATION_TOKEN} encrypt_key: ${FEISHU_ENCRYPT_KEY} # 这里定义了“谁可以触发OpenClaw”是权限的第一道闸门 access_control: # 白名单模式只允许列表里的飞书OpenID执行命令 allow_list: - ou_xxx1 # 运维负责人 - ou_xxx2 # 开发组长 # 黑名单模式禁止列表里的OpenID其余都允许慎用 # deny_list: [] # 技能Skill的加载策略决定了你的AI工作流有多灵活 skills: # 本地技能目录所有YAML定义的Skill都放这里 local_path: ~/.openclaw/skills # 远程Git仓库适合团队共享Skill如公共Zabbix监控模板 remote_repos: - url: https://github.com/your-org/openclaw-skills.git branch: main # 默认启用的Skill启动时自动加载 enabled: - zabbix-alert - bitable-query # 日志与可观测性生产环境必备 logging: level: INFO # DEBUG会打印每条HTTP请求详情DEBUG慎用 file: /var/log/openclaw.log # 建议用绝对路径避免权限问题 rotation: 10MB # 单个日志文件最大10MB自动轮转最关键的access_control字段很多人忽略其业务价值。比如你给运维组部署OpenClaw目的是让/restart nginx命令只被真正的SRE执行。如果allow_list为空任何人Bot发指令都会执行——这在生产环境是灾难。我曾见一个客户因忘记配置allow_list导致实习生在测试群发/deploy prod直接把未经过QA的代码推到了生产环境。4.2 初始化第一个Skillhello-world的5个文件和它们的协同逻辑OpenClaw的Skill不是单个脚本而是一个微型应用包。以最简hello-world为例它包含5个必要文件~/.openclaw/skills/hello-world/ ├── skill.yaml # Skill的“身份证”定义名称、描述、触发方式 ├── handler.py # 主逻辑接收输入调用API返回结果 ├── requirements.txt # 依赖清单只列本Skill特有的包如requests ├── README.md # 使用说明给其他开发者看的文档 └── tests/ # 单元测试保证Skill行为可预测 └── test_handler.pyskill.yaml是灵魂它定义了OpenClaw如何理解这个Skillname: hello-world description: 最简示例回复Hello 用户名 trigger: # 支持三种触发方式 - type: command # 命令行触发openclaw run --skill hello-world pattern: ^/hello$ # 正则匹配支持群聊和私聊 - type: event # 事件触发飞书收到消息事件时自动匹配 event_type: im.message.receive_v1 # 飞书消息事件 filter: text.contains(你好) # 文本过滤条件 exec: # 执行入口格式为 module:function handler: handler.handle # 超时时间单位秒防止Skill卡死 timeout: 30 # 内存限制单位MB防止OOM memory_limit: 128handler.py是血肉它必须实现handle函数接收一个context字典包含用户OpenID、群ID、消息内容等def handle(context): # 从context里提取关键信息 user_id context.get(user_id, 未知用户) chat_id context.get(chat_id, 私聊) # 构造飞书消息卡片Markdown格式 message { msg_type: post, content: { post: { zh_cn: { title: Hello World!, content: [ [{ tag: text, text: f你好{user_id}这是在{chat_id}中触发的Hello World。 }] ] } } } } # 返回消息OpenClaw会自动调用飞书API发送 return message注意handler.py里不能直接调用requests.post发飞书消息OpenClaw的context里已经注入了feishu_client对象你应该用context[feishu_client].send_message(...)。直接发HTTP会导致签名失败报错{code:11232}。这是新手最常犯的错误。4.3 启动与验证如何用curl模拟飞书事件跳过繁琐的群聊测试每次改完Skill都要去飞书群里Bot测试效率极低。OpenClaw提供了openclaw test命令但更高效的是用curl直接模拟飞书的HTTP POST事件。飞书事件体是JSON格式结构固定。以“用户发送消息”事件为例# 保存以下JSON到 event.json { schema: 2.0, header: { event_id: xxx, event_type: im.message.receive_v1, create_time: 2024-01-01T00:00:00.000Z, token: your_verification_token, app_id: cli_xxx }, event: { sender: { sender_id: { user_id: ou_xxx1, open_id: od_xxx1 } }, message: { message_id: om_xxx, chat_id: oc_xxx, root_id: , parent_id: , chat_type: group, message_type: text, content: {\text\:\/hello\} } } } # 用curl发送到本地OpenClaw curl -X POST http://localhost:8000/webhook \ -H Content-Type: application/json \ -d event.json如果配置正确你会在终端看到OpenClaw日志打印INFO: 127.0.0.1:12345 - POST /webhook HTTP/1.1 200 OK INFO: Handling event im.message.receive_v1 for skill hello-world INFO: Sending message to chat oc_xxx...然后立刻在飞书群或私聊里看到Bot回复的Hello卡片。这个方法让你在10秒内完成一次完整闭环测试比切到飞书App快5倍。5. 卸载与清理为什么pip uninstall不够以及如何彻底清除OpenClaw的“数字足迹”5.1 彻底卸载的四步法从代码到配置一个都不能少很多人以为pip uninstall openclaw就万事大吉其实OpenClaw在系统里留下了至少4类“数字足迹”必须手动清理第一步卸载Python包# 确保在venv环境下 source ~/openclaw-env/bin/activate pip uninstall openclaw -y第二步删除配置目录OpenClaw的所有用户数据都存在~/.openclaw/包括config.yaml你的飞书配置、权限规则credentials.json飞书的access_token和refresh_token含敏感信息skills/你克隆或创建的所有Skill代码logs/可能包含调试时的API密钥片段。rm -rf ~/.openclaw提示rm -rf前先ls -la ~/.openclaw确认目录内容。如果skills/里有你写的宝贵Skill务必先tar -czf my-skills-backup.tgz ~/.openclaw/skills备份。第三步清理Shell别名和PATH如果你在~/.bashrc或~/.zshrc里加了export PATH$HOME/openclaw-env/bin:$PATH现在要删掉。搜索并删除grep -n openclaw ~/.bashrc ~/.zshrc 2/dev/null # 手动编辑对应行删掉PATH修改第四步回收ngrok资源虽然ngrok是临时隧道但长期运行的./ngrok http 8000进程会占用内存。用ps aux | grep ngrok找到PIDkill -9 PID结束。同时登录ngrok官网Dashboard把不再使用的隧道URL标记为“Archived”避免计费。5.2 验证卸载是否干净三个必查项卸载完成后执行以下三步验证确保无残留检查命令是否消失which openclaw # 应返回空 openclaw --version # 应报 command not found检查配置目录是否清空ls -la ~/.openclaw # 应报 No such file or directory检查进程是否退出ps aux | grep -i openclaw\|uvicorn # 不应有相关进程 # 如果有用 kill -9 强制结束实操心得我给自己定了一条铁律——每次在客户现场演示完OpenClaw离开前必须当着客户面执行这四步卸载并让他们亲眼看到which openclaw返回空。这不仅是技术严谨更是建立信任。客户会记住“这个人连卸载都这么认真他的部署方案一定靠谱。”6. 常见问题与排查技巧实录那些让工程师凌晨三点还在抓头发的“幽灵错误”6.1 “error: 发送飞书失败, 返回信息:{code:11232,msg:frequency limited psm[lark” —— 最常见的11232真相这个错误码在热词里高频出现但飞书官方文档对11232的解释极其模糊“频率受限”。绝大多数人第一反应是“我发消息太快了”于是加time.sleep(1)结果毫无改善。真相是11232 90%以上是HTTPS证书校验失败导致的“伪频率限制”。排查路径检查ngrok隧道是否活跃curl -I https://xxx.ngrok.io看HTTP状态码是否为200检查OpenClaw日志里是否有SSL: CERTIFICATE_VERIFY_FAILED字样如果用的是自签名证书如用mkcert生成飞书服务器不信任必须换ngrok或Cloudflare Tunnel终极验证用curl -k https://xxx.ngrok.io/webhook-k忽略证书如果返回{code:0,msg:success}那就100%是证书问题。解决方案永远用ngrok永远不要自己搞HTTPS证书。ngrok的域名是飞书白名单里的证书链完整一劳永逸。6.2 “openclaw run --skill xxx 报错Skill not found” —— 路径、权限、YAML缩进的三重陷阱这个报错看似简单但根源往往藏在三个地方陷阱一skills目录路径错误openclaw config里skills.local_path必须是绝对路径且~符号不会被自动展开。错误写法local_path: ~/.openclaw/skills正确写法local_path: /Users/yourname/.openclaw/skillsmacOS或C:/Users/yourname/.openclaw/skillsWindows。陷阱二文件权限不足Linux/macOS下如果skills/目录权限是700仅所有者可读而OpenClaw是以www-data用户运行的就会读不到Skill。用ls -ld ~/.openclaw/skills检查确保组和其他用户有r-x权限chmod 755 ~/.openclaw/skills。陷阱三skill.yaml缩进错误YAML对空格极其敏感。常见错误用Tab代替空格YAML标准禁止Tabtrigger:下面的- type:少缩进2个空格exec:里的handler:和timeout:不在同一缩进层级。验证方法用在线YAML校验器如 https://yamlchecker.com/粘贴你的skill.yaml它会高亮所有语法错误。6.3 “飞书收不到消息但OpenClaw日志显示发送成功” —— 消息投递的“最后一公里”断在哪OpenClaw日志里有Sending message to chat oc_xxx...但飞书群里就是没消息。这通常意味着消息已发出但在飞书侧被拦截。检查顺序检查Bot是否在目标群聊中飞书群右上角【群设置】→ 【群成员】确认你的Bot头像在列表里。如果不在点【添加成员】→ 搜索Bot名称添加。检查Bot的“可用性”状态在飞书开放平台【机器人】页面看Bot状态是否为“已启用”。如果显示“已停用”点击右侧【启用】。检查消息内容是否触发飞书审核飞书会对含敏感词如“破解”、“盗版”、“微信”的消息自动拦截。用最简消息测试{text:test}。如果这个能收到再逐步增加内容定位敏感词。检查chat_id是否正确chat_id是飞书内部ID不是群名。在handler.py里先print(context[chat_id])复制这个ID然后在飞书开放平台【调试工具】→ 【发送消息】里粘贴chat_id发一条测试消息。如果调试工具能发成功说明chat_id没问题如果失败说明这个chat_id已失效比如群被解散。6.4 “openclaw serve 启动后终端无响应CtrlC也杀不掉” —— uvicorn的进程僵死处理OpenClaw基于uvicorn有时会因端口占用或信号处理异常导致进程僵死。表现是openclaw serve后光标不动CtrlC无效ps aux | grep openclaw却看不到进程。终极解决方案# 查找所有uvicorn相关进程 ps aux | grep uvicorn # 强制杀死-9是最后手段 sudo kill -9 PID # 如果还不行用pkill sudo pkill -f uvicorn.*openclaw预防措施启动时加--reload参数仅开发用这样代码修改后自动重启减少僵死概率openclaw serve --reload7. 进阶思考OpenClaw不是终点而是你构建AI工作流的“乐高基座”OpenClaw跑通飞书只是万里长征第一步。它真正的价值在于作为一个可编程的AI能力胶水层把你散落在各处的工具链粘合成一个有机整体。比如我最近在帮一个电商团队落地的场景用户在飞书多维表格里更新“商品库存”字段 → 触发OpenClaw的inventory-checkSkill → 自动调用ERP系统的REST API查实时库存 → 如果库存低于阈值再调用飞书API创建一个“补货待办”并采购负责人。这个流程里OpenClaw不碰ERP的数据库也不改多维表格的结构它只做三件事监听飞书事件、调用外部API、发送飞书消息。所有业务逻辑都在handler.py里你可以用Python写任何你能想到的判断——比如结合天气API如果明天有暴雨就自动把物流发货优先级上调。所以别把OpenClaw当成一个“要配置好就扔一边”的工具。把它当作你的AI工作流IDE每天花10分钟写一个新Skill解决一个具体痛点。今天写个/jira-summary自动汇总Jira未关闭Bug明天写个/mysql-slowlog分析慢查询日志后天写个/zabbix-ack一键确认Zabbix告警。积少成多半年后你的团队就拥有了一个完全自主、无需审批、随时可审计的AI自动化中枢。我个人在实际使用中发现最有价值的不是那些炫技的Skill而是最朴素的一个能把飞书聊天记录自动归档到Notion数据库的Skill一个能在晨会前10分钟自动汇总各系统健康状态的Skill。它们不涉及大模型但每天为你省下2小时重复劳动。这才是AI落地的真实模样——不是取代人类而是让人类从机械劳动里解放出来去做真正需要创造力的事。
