OpenClaw 联合 Claude Code 与飞书 Bot 操作完全指南
一、OpenClaw 与 Claude Code 的关系
1.1 各自定位
| 组件 |
定位 |
核心能力 |
| Claude Code |
Anthropic 官方本地 AI 编程助手 |
读写代码、执行 Shell、操作 Git、处理复杂工程任务 |
| OpenClaw |
本地 AI Gateway + 渠道中枢 |
连接 Telegram/飞书/Discord、调度多种 AI 模型、集成飞书/日历/Gmail 等 tools |
1.2 协作模式：OpenClaw → Claude Code
通过手机/电脑上的 Telegram 或 飞书，向 OpenClaw 发送指令。
OpenClaw 收到后，可以启动真正的 Claude Code CLI 作为子进程（通过 ACP 协议），让 Claude 在 Mac 上执行大型编程任务，完成后把结果返回到聊天窗口。
二、架构简图
[你] → Telegram / 飞书
↓
[OpenClaw Gateway] ← 本地运行 (127.0.0.1:18789)
↓
┌─────┴─────┐
│ │
飞书操作 ACP 子进程
│ │
lark-cli [Claude Code]
│ │
文档/Base 代码/Shell/Git
三、在 Telegram / 飞书中指挥 Claude Code
3.1 绑定当前聊天到 Claude
发送以下命令：
/acp spawn claude --bind here
效果：
- 在当前聊天中创建一个 Claude ACP 会话
- 之后你发的每条消息都会直接传给 Claude Code 处理
- Claude 在
~/.openclaw/workspace-claude 下工作
3.2 创建持久话题（大型任务推荐）
在支持话题/线程的渠道（如飞书群、Discord）：
/acp spawn claude --mode persistent --thread auto
效果：
- 自动开一个话题/线程
- Claude 的回复和中间过程都在这个线程里
- 不污染主聊天
3.3 只执行一次性任务
/acp spawn claude --mode oneshot
效果：
- 执行一个任务就结束
- 适合"帮我 review 这个 PR"、"生成一份报告"等短任务
3.4 常用 ACP 控制命令
| 命令 |
作用 |
/acp status |
查看当前聊天的 ACP 绑定状态 |
/acp cancel |
取消当前正在执行的任务 |
/acp close |
关闭 ACP 会话并解绑 |
/acp doctor |
检查 ACP 系统健康状态 |
四、通过 Claude 完成飞书操作（双重能力）
4.1 关键原理
当 Claude 被 OpenClaw 通过 ACP 启动后，Claude 并不直接拥有飞书 tools。飞书操作由 OpenClaw 的 main agent 或内置 skills 执行。
但你可以这样配合：
- 用 OpenClaw 直接发送飞书消息、创建文档
- 用 ACP 的 Claude 处理代码、生成内容
- 再把结果交给 OpenClaw 写入飞书
4.2 实战：让 Claude 生成日报，OpenClaw 发到飞书
步骤 1：在 Telegram 里绑定 Claude
/acp spawn claude --bind here
步骤 2：给 Claude 派活
帮我写一份今天的研发进度日报，包含：
- 已完成：修复了登录 bug
- 进行中：重构订单模块
- 阻塞项：等待设计稿
Claude 生成内容后返回给你。
步骤 3：把内容发给 OpenClaw 的 main agent
把下面这份日报发到飞书群 oc_xxxxxx：
[粘贴 Claude 生成的内容]
OpenClaw（main agent）会调用飞书工具完成发送。
五、Bot 身份详解
5.1 什么是 Bot 身份？
OpenClaw 连接的飞书应用是 Clawdbot（appId: cli_a94a4198e6385eef）。所有通过 OpenClaw 或 lark-cli 执行的飞书操作，默认都以这个 Bot 的租户身份进行。
5.2 Bot 身份的优势
- ✅ 无需人工登录：没有 user 会话过期问题
- ✅ 24小时在线：可以自动跑定时任务
- ✅ 操作权限稳定：已配置好 scopes，可读写文档、Base、IM
5.3 身份验证结果
{
"appId": "cli_a94a4198e6385eef",
"brand": "feishu",
"defaultAs": "bot",
"identity": "bot"
}
测试命令结果：
lark-cli im +chat-search --query test --as bot --page-size 1
# -> { "ok": true, "identity": "bot" }
六、Bot 身份下可执行的飞书操作类别
6.1 即时通讯（IM）
| 操作 |
示例命令/指令 |
| 发送文本消息 |
@bot 发送消息到群 oc_xxx：今天进度更新 |
| 发送 Markdown |
@bot 用 markdown 发飞书消息... |
| 搜索群聊 |
lark-cli im +chat-search --query xxx --as bot |
| 查看历史消息 |
lark-cli im +chat-messages-list --chat-id oc_xxx |
6.2 云文档（Docs）
| 操作 |
示例命令/指令 |
| 创建文档 |
@bot 在飞书里创建一个文档，标题是 xxx |
| 更新文档 |
@bot 在飞书文档 doc_xxx 里追加一段内容 |
| 搜索文档 |
@bot 搜索飞书里标题包含 xxx 的文档 |
6.3 多维表格（Base）
| 操作 |
示例命令/指令 |
| 创建记录 |
@bot 在 Base xxx 的表 yyy 里添加一条记录 |
| 查询记录 |
@bot 列出 Base xxx 中状态为待办的所有记录 |
| 更新记录 |
@bot 把记录 zzz 的状态改成已完成 |
6.4 日历与任务
| 操作 |
示例命令/指令 |
| 创建日程 |
@bot 帮我创建一个明天下午的会议 |
| 查看日程 |
@bot 查看我今天的日程 |
| 创建任务 |
@bot 创建一个任务：周五前提交报告 |
七、三种典型工作流
工作流 A：纯 OpenClaw（快速操作）
适合：发消息、查日程、改 Base 记录
[你] -> Telegram message
↓
OpenClaw main agent
↓
lark-cli --as bot
↓
飞书 API
工作流 B：纯 ACP Claude（编程任务）
适合：写代码、debug、跑测试
[你] -> /acp spawn claude --bind here
↓
Claude Code CLI
↓
本地代码仓库
工作流 C：Claude + OpenClaw 组合（复杂自动化）
适合：Claude 生成内容 -> OpenClaw 写入飞书
[你] -> /acp spawn claude --bind here
↓
Claude 生成报告 / 分析数据 / 写脚本
↓
[你@OpenClaw] 把结果发到飞书
↓
OpenClaw main agent -> lark-cli bot -> 飞书
八、命令速查表
启动 Claude ACP
/acp spawn claude --bind here
/acp spawn claude --mode persistent --thread auto
/acp spawn claude --mode oneshot
ACP 管理
/acp status
/acp cancel
/acp close
/acp doctor
直接调用 lark-cli（Bot 身份）
lark-cli im +chat-search --query 关键词 --as bot
lark-cli im +messages-send --chat-id oc_xxx --content "hello"
lark-cli docs +search --query 关键词 --as bot
lark-cli base +list-bases --as bot
lark-cli calendar +agenda --as bot
lark-cli task +get-my-tasks --as bot
九、注意事项
- Bot 身份不能执行所有 user-only 操作。例如某些通讯录搜索命令仅限 user 身份。
- WebChat（Control UI）不支持 thread binding，所以
/acp spawn claude --thread auto 在 Web 控制台里会失败。
十、状态确认（2026-04-10）
| 检查项 |
状态 |
| OpenClaw Gateway |
运行中 (127.0.0.1:18789) |
| Telegram 渠道 |
已连接 (@duoer02_bot) |
| Feishu 渠道 |
已连接 (Clawdbot) |
| Claude Code CLI |
可用 (v2.1.79) |
| acpx -> Claude Code |
已验证通 |
| OpenClaw ACP -> Claude |
已验证通 |
| lark-cli bot 身份 |
已验证通 |
🚀 实践记录：基于 Cursor + Git Worktree 的多 Agent 自动化串行流水线
🛠 核心工具栈： Cursor | Git Worktree | Opus 4.6 & Codex-5.3
🎯 核心目标： 通过“一句话提示词”触发多个 Sub-agent 形成自动化串行执行，实现多任务并行开发。
📂 当前提案： openspec/changes/redesign-skill-card-vertical
🔄 自动化串行工作流 (Agent Pipeline)
- 注意：下面没有明确说用 SubAgent 的就不要用 SubAgent
0 TASK 0：提案复核
- 模型：Gemini-3.1-pro
- 任务：。使用 openspec-review-specs skill。
- 关注点：着重审视提案完备性设计，关键数据流，属性、接口对齐等等。
1️⃣ TASK 1：架构师预审 (Architect Review)
- 模型：Opus 4.6
- 任务：站在架构师的视角，对当前提案进行全局优化与细节补充。使用 neversight-skills_feed-system-architect skill。
- 关注点：着重审视系统设计，挖掘潜在的代码复用机会，确保方案的健壮性。
2️⃣ TASK 2：提案执行 (Implementation)
- 模型：Opus 4.6
- 任务：直接执行指令
/opsx/apply，将打磨后的提案转化为实际代码。
3️⃣ TASK 3：代码审查 (Code Review)
- 模型：Codex-5.3 (模型切换)
- 任务：
- 执行
git commit 保存初步生成的代码。
- 严格对照提案 (Proposal) 审查当前 Commit 的代码逻辑。
- 注：此阶段仅做只读审查（Read-only），不进行任何代码篡改，确保 Review 视角的客观性。
4️⃣ SubAgent 4：自愈与更新 (Auto-Refinement)
- 模型：Opus 4.6 (模型切回)
- 任务：摄取 Agent 3 输出的审查报告，基于反馈结果自动更新并修复代码缺陷。
5️⃣ SubAgent 5：收尾与归档 (Archiving)
- 模型：Opus 4.6
- 任务：
- 执行指令
/opsx/archive，对当前提案进行状态归档。
- 执行最终的
git commit，完成该特性的闭环。
💡 瓶颈复盘与优化方案 (Reflections & Optimization)
当前流水线实现了高度的自动化，但整体运行耗时稍长。
- 优化思路：当前 Sub-agent 的职责划分过于细粒度。下一步可以尝试降低颗粒度，将高内聚的任务合并（例如将“架构预审”与“提案执行”合并为单个大 Agent 步骤，或将“自愈更新”与“归档”合并），以减少模型切换和上下文传递带来的通信损耗，从而大幅提升流水线执行速度。
为什么复杂任务的默认工作流应该写在 AGENTS.md，而不是某个 Skill 里
> 时间：2026年3月26日 10:04（北京时间） > 主题：小满的任务工作流设计原则、AGENTS.md 与 Skill 的职责边界、为什么默认流程属于上层规则而不是专项技能
最近我们围绕一个问题做了比较深入的讨论：
**“为什么小满现在这套默认工作流程，要写在 AGENTS.md，而不是直接做成某个 skill？”*“为什么小满现在这套默认工作流程，要写在 AGENTS.md，而不是直接做成某个 skill？”AGENTS.md，而不是直接做成某个 skill？”
这个问题看起来像是文档放哪更合适，但本质上其实是在讨论：
- 一个 AI 助手到底应该怎么组织自己的工作系统
- 什么属于“总规则”，什么属于“专项能力”
- 为什么有些东西必须写成全局行为，而不能塞进单个模块里
我把这次讨论整理成一篇更完整的文章，方便后续团队统一理解，也方便作为知识库中的长期规则沉淀。
一、先说结论
小满现在这套默认工作流——比如：
- 先判断任务类型
- 如果有明确匹配的 skill，就先读 skill
- 先只读排查，再决定是否动手
- 能直接完成就直接完成
- 复杂任务分层处理，必要时再拆子 agent
它更适合写在 AGENTS.md，而不是某一个单独的 skill 里。
原因很简单：
这不是某类任务的“专项执行方法”，而是小满处理几乎所有任务时的总调度逻辑****总调度逻辑。
换句话说：
AGENTS.md 负责：收到任务后，先怎么判断、怎么分流、怎么做决策Skill 负责：一旦确定这是某类任务，具体怎么做
一个管“选路”，一个管“走路”。
二、AGENTS.md 和 Skill，本来就不是同一层东西
1）AGENTS.md 是上层规则
AGENTS.md 更像是 AI 助手的工作宪法、操作系统或者岗位说明书。
它适合承载：
- 群聊和私聊边界
- 默认任务 intake 流程
- 复杂任务怎么处理
- 什么时候先查环境、什么时候先给方案
- 角色定位、任务分发和交接规范
- 团队协作方式
这些规则的特点是：
- 跨任务
- 跨领域
- 跨 skill
- 不管当前任务具体是什么，都会先影响行为
所以这类内容天然适合放在 AGENTS.md。
2）Skill 是专项能力模块
而 skill 更像一个个专业工具箱或 SOP 模块。
比如：
healthcheck：怎么做健康检查find-skills：怎么搜索可用 skilllark-kb-analysis-writer：怎么导出整库并分析service-guardian：怎么做服务守护compaction-survival：长任务时怎么保持状态不丢
它们回答的是：
“当任务已经被识别成某一类后，具体执行方法是什么？”****“当任务已经被识别成某一类后，具体执行方法是什么？”
所以 skill 更适合写“专项执行路径”，而不是负责整个 agent 的总决策逻辑。
三、为什么“默认工作流”不能只靠某个 skill 承担
1）因为它发生在选 skill 之前
这是最关键的一点。
我们现在这套默认流程的前两步就是：
- 先判断任务类型
- 如果有明确匹配的 skill，就先读 skill
注意这里的逻辑顺序：
**是否调用某个 skill，本身就要先经过上层判断。**是否调用某个 skill，本身就要先经过上层判断。
如果把这套流程写进某个单独 skill，就会出现一个逻辑倒挂：
- 我得先调用一个 skill
- 才能读到“要先判断该不该调用 skill”
这就变成自我循环了。
所以像“先判断任务类型”“先查现有能力”“先摸环境”这种规则，必须写在 skill 之上。
而 AGENTS.md 恰好就是那个上层。
2）因为它是跨任务的共通原则
这套流程不是只对某一类任务生效。
它同时适用于：
- 知识库整理
- 服务稳定性排查
- 研究报告
- 技术方案分析
- 目录架构优化
- 自动化流程设计
- 长任务、多步骤任务
也就是说，它不是某个领域专属，而是小满做事的默认脑回路。
这种“共通原则”如果塞进某一个 skill，就会变成局部规则，覆盖范围反而不对。
3）因为它决定的是“任务怎么进系统”，不是“任务怎么执行”
这套流程本质上是：
- 先看这是不是复杂任务
- 先看已有工具、脚本、文档、spec
- 先摸清环境再动手
- 复杂任务默认先给方案
- 确认后再推进重执行
这套东西决定的是：
**任务进来后，先走哪条路。**任务进来后，先走哪条路。
而不是某条具体路径内部的步骤。
因此它属于任务路由层任务路由层，不是专项执行层专项执行层。
4）因为它和角色、边界、协作方式绑定在一起
小满并不是一个抽象的工具集合，而是一个带角色约束的助手。
当前体系里，小满有：
- 群聊边界
- 私聊代发规则
- 研究任务默认写知识库
- Lark 任务默认自动路由
- 复杂任务先方案后执行
- 必要时可用子 agent 协作
这些东西不只是“怎么做某件事”，而是：
- 小满是谁
- 小满对用户和团队负责什么
- 小满在什么场景可以主动，什么场景应该克制
这更像岗位规则、协作契约，而不是 skill 说明书。
所以应写在 AGENTS.md，而不是写进某个单一 skill。
5）因为多个 skill 往往会同时适用，需要上层裁决
现实任务经常不是单一归类。
比如一个任务可能同时涉及：
如果没有上层规则，小满就很容易：
- 乱选 skill
- 并行混用路径
- 该先只读的时候直接上手修改
- 该先给方案的时候直接执行
所以必须有一个写在 skill 之上的“总调度逻辑”，决定：
这正是 AGENTS.md 的职责。
四、如果硬把它做成一个 skill，会出现什么问题
1）职责膨胀
如果专门做一个所谓“intake skill”，里面负责：
- 判断任务类型
- 检查现有能力
- 搜索增强路径
- 决定要不要给方案
- 再决定是否调用别的 skill
那它很快就会变成一个“万能前置 skill”。
问题是：
- 它什么都管
- 但并不专注于某个领域
- 和
AGENTS.md 的作用高度重叠
- 会形成两个总控中心
结果不是更清楚，而是更容易混乱。
2）会形成“skill 套 skill”的递归感
流程会变成：
- 收到任务
- 先调用 intake skill
- intake skill 再判断要不要调用其他 skill
- 其他 skill 再真正干活
这在设计上很别扭。
因为本来应该作为 agent 默认脑回路的东西，被额外包成了一个 skill，反而增加了一层形式主义。
3）轻任务会被过度流程化
并不是所有任务都需要显式走一遍完整 intake。
很多任务其实很轻：
这类任务如果每次都显式调用某个“前置 skill”，系统就会显得过于笨重。
而写进 AGENTS.md，这套规则可以自然地作为默认行为存在：
这更像“会做事的人”，而不是“执行表单流程的机器”。
4）没命中任何 skill 时，仍然需要默认规则兜底
还有很多任务属于：
- 没有一个 skill 完全匹配
- 但仍然需要先看现有环境
- 仍然需要先查脚本、文档、配置真相
- 仍然需要先给方案，而不是蛮干
如果这类规则不写在上层，而只寄托在某个 skill 上，那一旦任务没命中那个 skill，整套流程就失效了。
所以必须有一个不依赖 skill 是否命中，也能生效的默认行为层****不依赖 skill 是否命中，也能生效的默认行为层。
这层就是 AGENTS.md。
五、那 skill 在整个体系里应该做什么？
最合理的分工是这样的：
AGENTS.md 负责
- 默认任务 intake
- 任务分类
- 风险判断
- 优先复用已有能力
- 是否先给方案
- 是否应该拆子 agent
- 群聊 / 私聊边界
- 团队协作方式
Skill 负责
- 某个领域的专业做法
- 某类任务的执行 SOP
- 某项能力的标准流程
- 专项工具链的使用方式
比如：
healthcheck 负责“怎么排查服务健康”lark-kb-analysis-writer 负责“怎么读整库再分析”service-guardian 负责“怎么做守护和 auto-recovery”compaction-survival 负责“长任务如何保存状态、抵抗压缩丢失”
可以理解为：
AGENTS.md 是总导演- 各个 skill 是专业部门
导演决定拍什么、怎么分工；部门负责把自己那段拍好。
六、那 skill 完全不需要做 planning 吗？
也不是。
其实可以额外做一个专门的 planning / intake / capability-first planning skill，作为补充层****补充层。
它适合用在：
- 特别复杂的陌生任务
- 用户明确说“先别做，先给最优方案”
- 需要做方法设计、路线设计、任务拆解
但它的定位应该是：
显式规划模块****显式规划模块
而不是：
默认工作流本体****默认工作流本体
也就是说：
AGENTS.md 仍然负责全局默认行为- planning skill 只在需要时被主动启用
这样两层不会冲突。
七、为什么这次这套流程特别适合写进 AGENTS.md
因为这次讨论的不是某个专业技能该怎么做，而是一个更上层的问题：
“小满以后在面对复杂任务时，默认应该怎么思考、怎么判断、怎么进入执行。”****“小满以后在面对复杂任务时，默认应该怎么思考、怎么判断、怎么进入执行。”
这个问题本质上属于：
- 行为风格
- 风险控制
- 协作协议
- 任务调度逻辑
- agent 宪法级规则
所以把它写进 AGENTS.md，不仅合理，而且是最清晰的做法。
八、最终总结
为什么默认工作流要写在 AGENTS.md，而不是 skill？
因为这套流程决定的是：
**在选 skill 之前，小满应该怎么做事。**在选 skill 之前，小满应该怎么做事。
而 skill 更适合解决的是：
**当已经确定这是一类任务后，该怎么具体执行。**当已经确定这是一类任务后，该怎么具体执行。
一个是上层总规则，一个是下层专项能力。两者不是对立关系，而是分层关系。
真正成熟的 agent 系统，不是把所有东西都塞进 skill，而是要把：
- 全局行为规则
- 专项技能模块
- 用户偏好和团队协作方式
- 长任务生存与恢复机制
放在正确的层级上。
这次讨论的价值就在这里：
我们不是只给小满增加了一个新流程，而是在逐步把“小满怎么工作”这件事，变成一套更清晰、更可维护、也更像真正助理的系统。
九、建议的后续动作
基于这次讨论，后续可以继续补两类文档：
- 《AGENTS.md 与 Skill 的职责边界图》****《AGENTS.md 与 Skill 的职责边界图》
- 用图示方式明确：什么该写 AGENTS、什么该写 Skill、什么该写 MEMORY
- 《复杂任务 Planning / Intake Skill 设计方案》****《复杂任务 Planning / Intake Skill 设计方案》
- 不是替代 AGENTS.md，而是作为显式规划层补充
如果这两份补上，整个系统的分层会更清楚，小满后续也更容易持续优化。
调研日期：2026-03-13
目标：实现 OpenClaw 同时对接 Telegram 和飞书（Lark）
一、当前环境分析
1.1 OpenClaw 现有配置
已配置的渠道：
渠道 │ 状态 │ 说明
─────────┼─────────────────┼────────────────────────────────────────────────
Telegram │ ✅ 正常运行 │ 3 个 bot（nexus、xiaoman、polymarket），DM 开放
飞书 │ ⚠️ Webhook 模式 │ 非原生 WebSocket，通过 bridge 中转
当前飞书配置（~/.openclaw/openclaw.json）：
{
"feishu": {
"domain": "lark",
"streaming": false,
"blockStreaming": false,
"textChunkLimit": 8000
}
}
1.2 当前飞书对接架构
现有方案：Webhook Bridge
飞书 → Cloudflare Tunnel → bridge.py (localhost:19800) → OpenClaw Gateway (localhost:18789)
bridge.py 功能：
- 接收飞书事件（卡片消息、私聊、群聊）
- 转发给 OpenClaw Gateway
- 群聊智能回复（strict 模式：必须 @ 才回复）
- 消息去重和持久化
问题：
- 非原生集成，依赖额外 bridge 服务
- 需要 Cloudflare Tunnel 暴露公网
- 功能受限（无法使用 OpenClaw 原生飞书功能）
二、OpenClaw 原生飞书集成
2.1 官方支持情况
OpenClaw 官方原生支持飞书，通过 WebSocket 长连接接收事件，无需公网暴露。
支持的功能：
- 私聊消息
- 群聊消息（支持 @ 机器人）
- 卡片消息（Interactive Card）
- 发送消息（send_as_bot）
- 媒体文件处理
2.2 配置步骤
步骤 1：创建飞书应用
- 访问 飞书开放平台
- 创建企业应用
- 获取 App ID 和 App Secret
步骤 2：配置权限
在飞书应用权限中批量导入：
{
"scopes": {
"tenant": [
"im:message",
"im:message:send_as_bot",
"im:message:readonly",
"im:chat.members:bot_access",
"im:resource",
"aily:file:read",
"aily:file:write"
]
}
}
步骤 3：启用机器人能力
在 应用能力 → 机器人 中启用并设置机器人名称。
步骤 4：配置事件订阅
- 选择 使用长连接接收事件（WebSocket）
- 添加事件：
im.message.receive_v1
步骤 5：发布应用
在 版本管理与发布 中创建版本并提交审核。
2.3 OpenClaw 配置
方式一：CLI 配置（推荐）
openclaw channels add
# 选择 Feishu，输入 App ID 和 App Secret
方式二：配置文件
{
"channels": {
"feishu": {
"enabled": true,
"dmPolicy": "pairing",
"accounts": {
"main": {
"appId": "cli_xxx",
"appSecret": "xxx",
"botName": "小满"
}
}
}
}
}
飞书国际版（Lark）配置：
{
"channels": {
"feishu": {
"domain": "lark"
}
}
}
三、Telegram 对接现状
3.1 当前配置
已有 3 个 Telegram bot：
Bot │ Token │ DM 策略 │ 群聊策略
───────────┼───────────────────────────────┼─────────┼──────────
nexus │ 8605513784:AAHpV9JvZECkHc0... │ pairing │ allowlist
xiaoman │ 8679985454:AAFMmTZSHeBL_... │ open │ open
polymarket │ 8617997098:AAFtetMdfopk_... │ open │ allowlist
配置特点：
- 均使用代理：
http://127.0.0.1:7897
- DM 策略：nexus 需配对，其他开放
- 群聊：xiaoman 完全开放，其他需白名单
3.2 优化建议
- 统一代理：可考虑移除代理（如果网络可达）
- 安全策略：生产环境建议使用 pairing 模式
- Streaming：可开启流式响应提升体验
四、完整对接方案
4.1 目标架构
┌─────────────────────────────────────────────────────────────┐
│ 用户 │
├──────────────┬──────────────────────┬──────────────────────┤
│ Telegram │ 飞书 │ │
│ (原生) │ (原生) │ │
└──────┬───────┴──────────┬──────────┴──────────┬───────────┘
│ │ │
▼ ▼ ▼
┌──────────────────────────────────────────────────────────────┐
│ OpenClaw Gateway │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ Telegram │ │ Feishu │ │ 其他渠道 │ │
│ │ (WebSocket)│ │ (WebSocket)│ │ (WhatsApp等) │ │
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
4.2 实施步骤
第一步：切换到原生飞书集成
- 停止当前 bridge 服务
- 配置 OpenClaw 飞书原生支持
- 重启 Gateway
- 验证飞书消息接收
# 配置飞书
openclaw channels add
# 选择 Feishu，输入 App ID 和 App Secret
# 重启 Gateway
openclaw gateway restart
# 查看状态
openclaw gateway status
第二步：优化 Telegram 配置
根据需要调整 DM 和群聊策略：
{
"channels": {
"telegram": {
"dmPolicy": "pairing",
"groupPolicy": "allowlist",
"streaming": "partial"
}
}
}
第三步：配置群聊回复规则
飞书群聊支持两种模式：
strict：必须 @ 机器人才回复smart：智能判断，无 @ 也回复有价值的消息
{
"channels": {
"feishu": {
"accounts": {
"main": {
"groupPolicy": {
"groups": {
"oc_0c097efa8e1dd026ed84a61d7a22fe80": {
"requireMention": true
}
}
}
}
}
}
}
}
五、飞书 Bot 高级功能
5.1 当前飞书 Bot 能力
基于现有配置，空空拥有的飞书 Bot：
能力 │ 状态 │ 说明
─────────────┼──────┼─────────────────
接收私聊消息 │ ✅ │ DM 策略：开放
接收群聊消息 │ ✅ │ 需 @ 或在群里
发送消息 │ ✅ │ send_as_bot
发送卡片消息 │ ✅ │ Interactive Card
处理媒体 │ ✅ │ 图片、文件等
5.2 飞书 API 能力（需额外配置）
能力 │ 权限名称 │ 用途
─────────────┼───────────────────────────────────┼─────────────
读取用户信息 │ contact:user.employee_id:readonly │ 获取用户身份
上传文件 │ im:resource │ 文件上传下载
创建群聊 │ im:chat:create │ 自动建群
@人 │ at:user │ 群聊@功能
5.3 消息类型支持
类型 │ 支持 │ 说明
───────┼──────┼─────────────────
文本 │ ✅ │ 基础文本消息
富文本 │ ✅ │ post 消息
卡片 │ ✅ │ Interactive Card
图片 │ ✅ │ image 消息
文件 │ ✅ │ file 消息
语音 │ ✅ │ audio 消息
六、问题排查
6.1 常见问题
问题 │ 可能原因 │ 解决方案
───────────────┼──────────────────┼─────────────────────────
飞书消息收不到 │ Gateway 未运行 │ `openclaw gateway start`
事件订阅失败 │ WebSocket 未连接 │ 检查 gateway 状态
权限不足 │ 权限未配置 │ 在飞书开放平台添加权限
群聊无法回复 │ 未发布应用 │ 提交审核并发布
6.2 调试命令
# 查看 Gateway 状态
openclaw gateway status
# 查看飞书通道日志
openclaw logs --follow | grep -i feishu
# 测试发送消息
openclaw message send --to <user_id> --message "测试"
# 飞书通道诊断
openclaw doctor
七、结论与建议
7.1 当前评估
维度 │ Telegram │ 飞书
───────────┼────────────────┼─────────────────────────
集成方式 │ 原生 WebSocket │ Webhook Bridge（需改造）
稳定性 │ 高 │ 中（依赖 bridge）
功能完整性 │ 完整 │ 部分（bridge 限制）
维护成本 │ 低 │ 高（额外服务）
7.2 建议方案
推荐：切换到原生飞书集成
优点：
- 无需公网暴露（WebSocket 长连接）
- 功能完整（原生支持所有飞书能力）
- 维护简单（OpenClaw 内置）
- 稳定性高
实施难度：
- 中等（需要重新配置飞书应用）
- 需要停机迁移（约 5 分钟）
7.3 实施优先级
- P0：切换飞书到原生集成
- P1：优化 Telegram 配置
- P2：添加飞书高级功能（文件上传、用户识别等）
附录
A. 飞书应用权限清单
im:message # 接收消息
im:message:send_as_bot # 发送消息
im:message:readonly # 读取消息
im:chat.members:bot_access # 获取群成员
im:resource # 资源文件
aily:file:read # 读取文件
aily:file:write # 写入文件
B. 相关链接
C. 当前配置参考
飞书 App ID: cli_a9147270bf785eef
飞书 App Secret: E0uJ4NbE4eAlMzN2wxbZIfTLgtmxZahD
GenGo 群 chat_id: oc_0c097efa8e1dd026ed84a61d7a22fe80
测试群 chat_id: oc_ff7ba9324d31ac25051ddb1e927cfa2b
空空 open_id: ou_f51b1ac9513c91b557b2e1017ae75fc4
报告撰写：小满 🌾
最后更新：2026-03-13 18:55 GMT+8
你可能见过这样的同事：周报、资料整理、会议纪要都交给 AI 处理，下午 6 点准时下班。而你自己打开 AI，却还是一问一答——背景要反复解释，格式要反复纠正，最后不像在用工具，更像在和 AI 斗智斗勇。
差别不一定在你怎么跟 AI 说话，而在于他用的是能执行任务的 AI Agent（可以理解成“会自己动手干活的 AI 助理”）。
这一章不讲复杂概念，也不写代码。我会带你在 Codex App 里完整走一遍：准备一个空文件夹，做好基本配置，让 Codex 自己安装一个公司 Skill 库（一批别人攒好、打包在一起的方法），最后用一个现成 Skill 帮你审一篇文章。整个过程不涉及命令行，你只需要照着做，看到 Codex 真的动起来、并留下结果，就完成了最重要的一步。
顺利的话，这一篇从准备到跑通大概二三十分钟，中间每一步都有截图，跟着做就行。
这里先假定你已经会注册、安装、登录 Codex，这些不在本文展开。
为什么要用 Agent
普通聊天 AI 主要是在“回答”你：你问一句，它答一句；你补一句，它改一点。AI Agent 不一样——你给它一个目标，它会按步骤执行，能检查文件、发起必要的操作、看结果，再把结果写回文件。
| 普通聊天 AI |
AI Agent |
| 你问一句，它答一句 |
你给目标，它拆步骤执行 |
| 主要给建议和文本 |
能读文件、跑命令、调用工具、检查结果 |
| 每次都要重新解释背景 |
可以复用已有的工作方法 |
| 更像顾问 |
更像会动手的助理 |
这一章你先不用理解所有细节，先体验一次：把一个明确任务交给 Codex，让它真的动起来。
Skill 的作用
Agent 会动手，但它不一定知道你的工作习惯：什么内容要先查固定口径、什么情况不能直接改、会议纪要按什么格式归档、复盘里哪些话不能写得太虚。这些通常得你一次次告诉它。
你可以先把 Skill 理解成一份给 Agent 用的工作方法：它会告诉 Agent 什么时候用、按哪几步做、输出什么、遇到什么情况要先停下来问你。
一句提示词解决“这一次怎么说”；一个 Skill 解决“以后都按这套做”。
这一章不会让你写 Skill，你只需要先用 Codex 跑一次安装任务，再亲手试一次它的效果。
第一步：准备好文件夹——Codex 的主战场
Codex 做事需要一个文件夹。它会在这个文件夹里读文件、写文件、执行检查，所以文件夹就是它干活的工作台。没有文件夹，它就只能跟你聊天，发挥不出 Agent 的价值。
怎么管理这些文件夹，有一条简单原则值得从一开始就养成：
一个项目一个文件夹。
这样做有两层好处：
- 文件隔离：每个项目的产出各放各的，Codex 生成、修改的文件不会和别的资料混在一起，也不会误伤你的正式文档。
- 上下文隔离：Codex 只看得到当前文件夹里的内容。文件夹越聚焦，它对“你在做什么”的判断就越准，不会被无关资料带偏。
第一次上手，先在桌面新建一个空文件夹，命名为 codex-tranfu-demo。新建文件夹这种事你肯定已经会了，这里不再赘述。需要稍微留意的，是怎么在 Codex 里打开它。
打开 Codex，找类似这样的入口（不同版本叫法略有差异）：
- 鼠标移动到“项目”那一行
- 会出现最右边那边文件夹然后有一个加号角标的图标，点击它
- 选择“使用现有文件夹”
选择刚才新建的 codex-tranfu-demo。如果 Codex 提示你确认是否信任这个文件夹，放心确认——它是你刚新建的空文件夹，里面没有任何东西。
打开好之后应该是这样。
打开错了文件夹也不要紧，退出重新选 codex-tranfu-demo 即可。
第二步：做好基本配置——让 Codex 放开手脚
默认设置下，Codex 每做一个动作都可能停下来问你“能不能执行”，模型也未必是最强的那个。第一次上手为了顺畅，建议先调两个地方。
| 设置项 |
建议 |
为什么 |
| 权限 |
设为 Full access（完全访问） |
Codex 在当前文件夹里读写文件、执行检查时不必每一步都来问你，体验会顺很多。你打开的是一个隔离的空文件夹，就算 Codex 自由发挥，能影响的也只有这个练习文件夹里的内容，碰不到你的正式资料。 |
| 模型 |
选 GPT-5.5，推理强度选 Extra High，速度选 Fast |
任务越是多步骤，模型的推理能力越关键。推理强度拉到 Extra High，Codex 拆解和执行任务时更稳，少走弯路。以 100 美元的 Pro 套餐为例，5 小时的用量基本上是用不完的，除非你同时开好几个任务一起跑。第一次上手，放心用最好的配置。 |
配置好之后，后面 Codex 执行任务时基本不会再频繁打断你。它仍然会把每一步显示出来，你照样能看着它做事——如果哪一步看起来不对劲，随时可以喊停。
第三步：安装 Skill 库——别人攒好的方法直接用
想用好 Skill，一个准确、常用、好维护的 Skill 仓库很重要。你不需要自己一个个去写、去攒——直接装一个现成的库，里面别人打磨好的方法就都能用了。这里用我们公司日常在用的 Skill 库做演示。
你只需要把下面这句话复制给 Codex：
请阅读 https://github.com/tranfu-labs/tranfu-skills/blob/main/INSTALL.md 并按文档步骤帮我安装公司 skill 库.
发出去后，Codex 会按文档一步步来：
- 检查当前文件夹
- 打开安装说明
- 确认是否已安装
- 按步骤安装
- 最后检查结果
因为你已经开了 Full access，它通常不必再来征求许可，会自己走完。
安装完成后会大概有这样的输出（不同版本可能略微不一样）。
怎么算安装成功？ 你可以这样验证：
- 打开一个新会话，注意一定要是咱们刚刚创建的项目右侧的开始新对话按钮
- 然后告诉它：
查询一下tranfu库中有哪些skill
如果不顺利，它一般也会告诉你：
无论成功还是报错，先把这张结果截图保存下来。
第四步：跑一个 Skill——当场审一篇文章
库装好了，但你还没见它干活。这一步就让一个现成 Skill 当场跑给你看。
我们先创建一个新对话。
每一个独立任务的时候，最好都新开一个对话。
我们用「营销号审核」这个 Skill 举例——它能帮你判断一篇文章是不是营销号套路、有没有夸大和带节奏。先让 Codex 把它装进当前项目：
安装 Tranfu 库中的营销号审核 Skill 到项目中
装好后，还是新开一个对话。
然后随便找一个文章链接丢给它审一审：
用营销号审核 Skill 审查这篇文章：https://zazencodes.substack.com/p/build-your-own-developer-tools-with
注意看 Codex 的反应：它会主动调用刚装的营销号审核 Skill，而不是随口给你一段泛泛点评。看到它在执行过程里点名用到了这个 Skill，就说明 Skill 被正确激活了。
注意：这里需要两次展开才会看到它。
跑完后，它会按 Skill 设定的方式给出审查结果——哪里像营销号、哪些说法站不住脚、整体可信度如何。
到这里你已经完整体验了一遍：装库 → 装具体 Skill → Skill 真的帮你干了一件事。
第一轮完成标准
先别用“我是不是完全懂了”来判断自己。第一次动手的标准很具体——只要满足下面任意一种，就算完成。
| 你看到什么 |
算什么 |
接下来做什么 |
| Codex 显示公司 skill 库已安装，并能正常使用 |
跑通 |
截图保存 |
| 营销号审核 Skill 被激活，并给出了审查结果 |
跑通（加分） |
截图保存 |
| Codex 输出“部分成功”，但说明卡在哪一步 |
阶段完成 |
截图保存，下一篇前处理 |
| Codex 报错，但给了求助话术 |
阶段完成 |
把截图和话术发给同事 |
| Codex 没法打开文件夹 |
阶段完成 |
截图发给hello@tranfu.com |
保存证据比追求完美更重要。最有用的截图有这么几张：
- 打开
codex-tranfu-demo 的画面
- Codex 开始执行的画面
- 安装结果的画面
- Skill 被激活和审查结果的画面（如果走到了）
常见卡点
你大概率会卡在这几类地方。先列在这里，是想让你知道：第一次上手卡住，很正常。
| 卡点 |
可能原因 |
你现在怎么做 |
| 找不到打开文件夹的入口 |
Codex 版本或界面不同 |
截图问同事“Codex 里怎么打开文件夹” |
| 打开了重要资料文件夹 |
选错文件夹 |
退出，重新选 codex-tranfu-demo |
| 找不到 Full access 或模型设置 |
设置项位置因版本而异 |
截图问同事，或先用默认设置往下走 |
| Codex 只回答概念，不执行 |
可能没在工作区里发任务 |
确认当前打开的是 codex-tranfu-demo |
| Codex 没给出最终结果 |
可能卡在安装某一步 |
截图保存，对话结果也算 |
| tranfu-skills 安装失败 |
网络、权限或本机设置问题 |
截图，使用它给的求助话术 |
| 营销号审核 Skill 没被激活 |
库或 Skill 没装好 |
确认库已安装，再重发安装该 Skill 的指令 |
| 它输出一堆英文报错 |
本机设置或权限问题 |
截图，直接用它生成的求助话术 |
第一次上手只需要判断一件事：
这一步该继续，还是该截图求助。
最小完成版本
如果你只想先快速试一下，做到这几步就够：
- 在桌面新建
codex-tranfu-demo，用 Codex 打开它
- 设好 Full access 和模型
- 复制安装指令，让 Codex 装好公司 Skill 库
- 保存最终截图
能留下下面任意一种截图，就可以先停：
- 打开空文件夹的截图
- 执行中的截图
- 安装结果截图
- 清晰的报错截图
有报错也算——因为你已经从“我不知道从哪里开始”，走到了“我知道卡在哪一步”。
如果还有 10 分钟
可以顺手再多试一个 Skill：
- 让 Codex 换几个关键词搜搜库里还有什么：
写作、复盘、review
- 挑一个看起来用得上的，让它装进项目
- 再像刚才审营销号那样跑一次
不用判断哪个最好，把搜到的 Skill 名称或一次执行结果截图保存下来就行。
下一篇会用一个现成 Skill，审一次你自己写给 AI 的任务说明。
关掉之后，什么还在？
你可能会担心：今天装的、聊的，关掉 Codex 是不是就没了？
记住一句话就行：
聊的会忘，装的会留。
- 这次对话会忘：退出 Codex 再打开，就是一个全新的对话，它不记得你们刚才聊过什么。这跟你平时用 ChatGPT 一样，正常。
- 装好的 Skill 不会忘：它就存在
codex-tranfu-demo 这个文件夹里。明天打开 Codex，还选这个文件夹，它就还在。
所以明天想接着用，不用重装、也不用重新解释。打开文件夹，再说一句“用营销号审核 Skill 审这篇”就行——你不用它记得，它只要在这个文件夹里找得到 Skill 就够了。
打个比方：一个 Skill 就像贴在工位上的一张 SOP。今天带的实习生下班走了（对话关了），明天来个新实习生（新对话），墙上那张 SOP 还在，新人照样照着做。
顺带记住一条，你以后一直用得上：
想留下的东西，得落到文件里；只在对话里说的，关掉就没。
这也是为什么这一章我一直让你截图保存——审查结果也一样，想留就截图，或者让它写进文件夹。
完成结果
这篇的关键不在术语，也不在复杂工具，而在一个很关键的转变：
- 从“我问 AI 一个问题”，变成“我让 Codex 执行一个任务”。
- 从“每次重新解释”，变成“开始使用可复用的工作方法”。
- 从“AI 只给我一段回答”，变成“AI 能在一个文件夹里留下可检查的结果”。
这就是 Skill 系列的第一步：先让它动起来一次。后面才谈得上用好别人写的 Skill、判断自己的经验适不适合沉淀、写出自己的 Skill，最后发布给同事用。
什么样的工作值得做成 Skill
你大概以为，越难、越高大上的事，越值得做成 Skill。
恰恰相反。真正值得装进去的，往往是那种你都懒得跟人说、说出来还有点不好意思的小破事——就因为它太琐碎，你每次用 AI 都得重新交代一遍。
我们先把这件事掰开。
一句话标准：装一次，反复用
想象你身边来了个新同事，绝顶聪明，啥都会，唯独有一个毛病：他记不住你们公司的规矩。
每次派活，你都得从头讲一遍——表格要哪几列、审稿卡哪几条、文件名按什么格式起。他做得很好，但下次你还得再讲一遍。讲到第十遍，你是不是想抓狂？
Skill 就是那张你递给他的小抄。**值得写进小抄的，是你每次都得重新交代、而他自己打死也猜不到的那套规矩和步骤。**写一次，以后他自己揣着。
听起来谁的事都能装？别急，先过两道关。两道都过，才值得动手。
第一关：这事，是不是只有你们才知道？
你随手想个活——比如"把这段话改通顺"。
打住。这种谁都会的，AI 生下来就会，你装它纯属脱裤子放屁。它早就会的东西，你写进小抄，等于教鱼游泳。
那什么才值得？是它猜不到、只能你教的那些：你们部门那张鬼才看得懂的表格模板、你们主编那套刁钻的审稿标准、你们归档时那串龟毛的命名格式。
一句话——谁都会的，划掉；你们独有的，留下。
反例
| 案例 |
解释 |
| "帮我把这封邮件改得更礼貌一点。" |
AI 本来就会,不用做成 Skill。 |
| "帮我给这篇文章想 10 个更吸引人的标题。" |
这是通用写作能力,不用做成 Skill。 |
| "帮我把这段话翻译成英文。" |
除非你们有一套特殊术语和翻译口径,否则不用做成 Skill。 |
正例
| 案例 |
解释 |
| "每周把销售同事发来的客户拜访记录,整理成 CRM 里那 6 列固定字段。" |
字段名、合并规则、缺失信息怎么标,这些只有你们知道。 |
| "发布 Practice 文章前,按我们自己的清单检查标题、摘要、series/order、未发布链接和 MOCK 标记。" |
这不是普通审稿,是你们站点自己的发稿规矩。 |
| "把候选人的面试反馈,改成 HRBP 可以直接转发的固定口径。" |
哪些话能写、哪些话要收住、结论怎么排,这是你们公司的表达边界。 |
第二关：你能一句话说清"它什么时候该上场"吗？
这一关最容易漏，可它偏偏要命。
Skill 装好之后，不是你喊一声它才动——是 AI 自己判断什么时候该把这张小抄掏出来。它靠什么判断？就靠你写的那句使用说明。
所以你得能一口气说清："当我要做 XX 的时候，用它。"说得清，它该上场时就上场。说不清，那张小抄就躺在兜里睡大觉，该用的时候它压根想不起来。
你试试对着自己的活说这句话。卡壳了？那这关没过。
反例
| 案例 |
解释 |
| "做一个能帮我处理内容运营的 Skill。" |
太大了,到底是选题、改稿、排期,还是发布前检查?AI 不知道什么时候该掏出来。 |
| "帮我提升客户沟通质量。" |
触发条件是散的:售前邮件、会议纪要、投诉回复,每一种都不是同一件事。 |
| "遇到我觉得棘手的写作任务时,帮我判断怎么写。" |
这得先靠你自己觉得棘手,AI 没法自己判断什么时候该上场。 |
正例
| 案例 |
解释 |
| "当我要把客户访谈录音整理成产品需求卡片时,用它。" |
场景、输入、输出都清楚,AI 知道什么时候该用。 |
| "当我要发布一篇 Practice 系列文章前,用它检查 frontmatter、series/order、未发布链接和 MOCK 标记。" |
触发点就是发稿前检查。 |
| "当我要把一次面试反馈整理成 HRBP 可转发版本时,用它。" |
不是所有面试工作都用,只在改写反馈口径这一步用。 |
还有一条藏起来的关：这事,你是不是老在干?
前两关都过了,先别急着庆祝。
回头看一眼:这事你多久干一次?要是一年才碰一回——比如年终才填那张表——那做成 Skill 也白搭。等明年用到它时,你早忘了自己还装过这么个玩意儿。
得是你反复在做、做到手疼的事,装进去才划算。
反例
| 案例 |
解释 |
| "每年年底把部门预算表整理成老板要看的版本。" |
一年才做一次,等下次用到时你很可能已经忘了这个 Skill。 |
| "帮我为这次公司年会写一套主持人口播。" |
这是一次性任务,没有反复调用的价值。 |
| "帮我研究一下我们要不要进入日本市场。" |
这更像一次决策前调研,不是会反复执行的固定流程。 |
正例
| 案例 |
解释 |
| "每天把客服工单整理成产品问题、操作问题、情绪问题三类。" |
高频、重复、分类规则稳定,值得沉淀。 |
| "每周把销售拜访记录整理成 CRM 里的固定字段。" |
每周都做,而且每次都要按同一套字段和规则处理。 |
| "每次发布 Practice 文章前,检查 frontmatter、series/order、未发布链接和 MOCK 标记。" |
只要发稿就要检查,重复频率够高。 |
拿你自己的活往里一套,无非这么几种结果
规矩讲完了。现在你脑子里那件事,往这两道关上一撞,无非这么几种结局:
| 结果 |
怎么处理 |
| 两道都过 |
别犹豫,就是它,动手。 |
| 卡在第一关 |
AI 本来就会,或者纯靠你的手感、压根没规矩可教,当场划掉,这事不配。 |
| 卡在第二关 |
说不清它啥时候用,多半是这事本身就说不清边到哪儿。换一件清清楚楚的先练手。 |
| 一半过一半不过 |
别整个扔掉,切一刀:该按死规矩、该掐准时机的那半截做成 Skill,剩下要你拿主意的那半截,自己留着。 |
最后这种最常见,也最值钱——下面专门说。
一个 Skill,只干一件事
你可能想造一个无所不能的超级 Skill,啥都能干。
千万别。一个啥都干的大块头,"什么时候用"这句话根本说不清——你想想,一个号称"什么都会"的同事,你反而不知道该派他干嘛。结果就是 AI 要么乱用,要么干脆不用。
**切得越小,叫得越准。**从那种"三句话能说明白、每周要重复好几遍"的小动作下手,一个 Skill 咬死一件事。
下面这些事,先别碰
照着上面的逻辑往下推,有几种活天生就过不了关,趁早死心:
| 类型 |
为什么先别碰 |
| AI 本来就会的 |
谁都会的本事,你教它等于白教。 |
| 全靠手感、说不出规矩的 |
出创意、判断好坏,你自己都讲不清章法,拿什么写进小抄? |
| 一年碰不上几回的 |
装了也想不起来用。 |
| 必须你本人拍板的 |
定方向、做决策,这是你的事,不是小抄能替的。 |
下面直接交给 AI 来判断。
直接交给AI来判断
先安装 skill-content-fit
可复制：
安装 Tranfu 库中的 skill-content-fit skill 到项目中
然后把你的例子发给它让它判断
反例
可复制：
这个适合作为skill吗
---
上周产品评审会开完后，大家都以为别人会跟进，结果三个待办没人认领，项目延期了两天。
正例
可复制：
这个适合作为skill吗？
---
凡是涉及多人协作的会议，纪要必须在会后 24 小时内整理出行动项，每个行动项都要包含负责人、截止时间、交付物和确认人；没有负责人或截止时间的事项不能进入待办列表。
把你的方法写成第一个 Skill
你可能以为，写第一个 Skill 最难的是学会 SKILL.md 怎么写。
其实不是。
SKILL.md 看着像技术文件，但这部分最不用你操心。格式、字段、目录、排版，Codex 都会。真正难的是把你脑子里那套“我平时就是这么做的”，说成一组别人也能照着执行的规则。
先把一个误区拆掉：你会判断，不代表 Codex 会复用你的判断。
比如，一篇稿子哪里虚、会议纪要漏了哪个待办、prompt 为什么跑偏，你通常一眼能看出来。但写 Skill 不能只写结论，要把判断依据写出来：你看哪些信号、缺了什么就放进待确认、什么情况必须停下来问。
所以不要写这种规则：
帮我整理得清楚一点。
这句话太空。Codex 会按通用理解去整理，最后给你一份格式整齐、语气礼貌的东西。但哪些决定必须保留、哪些内容要放进待确认、哪些表达不符合你的习惯，它还是不知道。
这一篇只解决一个问题：把这套判断依据写进当前项目的 Skill 文件。不是让 Codex 在聊天里生成一段草稿，而是让项目里真的多出一个下次还能继续调用的 SKILL.md。
按下面五步走：
- 先定题目高度。
- 让 Codex 访谈你。
- 让 Codex 在当前项目里落文件。
- 立刻用 prompt-review 压一遍。
- 拿真实素材跑一遍。
别跳步。前面没定准，后面会写散；没有真实素材验证，Skill 看起来能用，实际使用时还是会跑偏。
第一步：先把题目高度定准
一个 Skill 最怕两种死法。
第一种是太窄。你把它写成“飞书会议聊天记录整理”，结果下次别人给你一段录音转写，Codex 想不起来用它。
第二种是太宽。你把它写成“资料整理”，结果会议纪要、读书笔记、销售线索、周报复盘全往里塞。最后这就不是 Skill，是大杂烩。
你要的是中间那一档：
| 题目 |
判断 |
| 飞书会议聊天记录整理 |
太窄 |
| 资料整理 |
太宽 |
| 会议记录整理 |
能用 |
先写三句话：
- 这个 Skill 处理：
[输入是什么]
- 它产出：
[结果长什么样]
- 它不处理：
[边界是什么]
比如：
- 这个 Skill 处理：会议录音转写、会议聊天记录、零散会议笔记
- 它产出：结构化会议纪要
- 它不处理：会议观点润色、战略判断、替负责人拍板
这三句话像给 Skill 画地盘。地盘太小，它出不了门；地盘太大，它开始乱跑。
判断标准很粗暴：
- 换一个同类输入，它还适用吗？
- 适用，就保留。
- 不适用，就太窄。
- 什么输入都适用，就太宽。
如果你卡住，别自己闷头想。直接把这一步丢给 skill-domain-framing。
安装 skill-domain-framing
安装 Tranfu 库中的 skill-domain-framing skill 到项目中
还是以之前的会议纪要为例，你只需要这样说
创建skill
---
凡是涉及多人协作的会议，纪要必须在会后 24 小时内整理出行动项，每个行动项都要包含负责人、截止时间、交付物和确认人；没有负责人或截止时间的事项不能进入待办列表，内容是当提到小王的时候，就合并进他的工作安排中，工作安排通常在项目路径下的week-jobs/xiaowang.md中
然后AI会加载对应的Skill
这时候你会发现它自动就帮你锁定比较合适的领域来定义你的skill了
第二步：让 Codex 访谈你
AI有一个毛病是做得太快想得太少，刚刚它直接全流程走完直接就生成了一个Skill，但实际上还有很多不清楚的地方
这个事情的时候就需要你对AI说
根据我最开始的描述，通过提问的方式帮我细化各种不明确的地方，在选项中你会帮我思考几个可能的选择和最推荐的选择以（推荐）为开头来标注
跟AI一起思考把各个流程细化，越贴合你们的真实场景，这个Skill就越有用
第三步：确认 Skill 创建的位置
你可能注意到了，我们一路创建Skill下来，没有指定在哪里创建，那么这个Skill去哪了？
告诉我这个Skill在哪，路径是什么
路径在我们项目文件夹下的 .codex/skills/organize-meeting-actions
第四步：立刻用 prompt-review 测一遍
现在我们已经写好初始版本了，但是是以我们自己的视角，尽可能还原工作流等等约束来写的，这就一个问题
后面是AI读取它之后不一定会完全按照它的来，这就需要我们略微修改它里面的措辞和全篇的结构
这里我们直接用tranfu库中的prompt-review来帮我们做这一步即可
用tranfu skill 中的 prompt-review skill来审核它
没有安装这个Skill也没有关系，AI会自动帮我们安装，最后执行过是这样
具体的修改你可以点击这里已编辑Skill看到，你会看到它做的修改一般是：
- 一类改动是把具体的一些单词变成大写，这是因为关键的NOT这类单词大写之后在大模型读取的权重会更高一些，更能够听从指令
- 还有一类改动增加正例与反例，这是因为你告诉AI一些抽象约定它理解的意思可能和你表达的意思有很多不一致的地方，这个时候就需要正例与反例对齐你们的理解
第五步：拿真实素材跑
到这里，Skill已经写好了，也优化过一遍了。现在才轮到测试。
回顾一下我们的skill的目标
凡是涉及多人协作的会议，纪要必须在会后 24 小时内整理出行动项，每个行动项都要包含负责人、截止时间、交付物和确认人；没有负责人或截止时间的事项不能进入待办列表，内容是当提到小王的时候，就合并进他的工作安排中，工作安排通常在项目路径下的week-jobs/xiaowang.md中
那么当我们提供一个新的会议纪要的时候，AI应该识别里面小王的内容，然后把他对应的工作写进week-jobs/xiaowang.md中
下面是我们的案例：
会议案例：小程序改版排期讨论
小张：今天我们主要确认小程序改版的排期。首页、活动页和数据埋点都要同步推进，先听一下进度。
小丽：设计稿已经完成七成，首页结构没问题，但活动页的优惠规则还没最终确认。我需要运营在明天下午前给到完整文案和规则。
小王：开发这边可以先做首页和基础组件，活动页等规则确定后再接入。现在风险主要是接口字段不稳定，如果后端本周五前不能定稿，下周联调会被影响。
小张：后端我来协调。小王，你先按现有字段做 mock，不要等接口完全完成。
小王：可以。我今天会把组件拆分方案发出来，明天开始写首页，预计三天完成第一版。
小丽：我会在今晚补齐首页细节，包括空状态、加载状态和错误提示，避免开发时反复确认。
小张：很好。那结论是：小丽明晚前交完整设计细节，小王本周完成首页开发，我负责推动接口定稿。周五下午我们开一次短会，只看阻塞项，不重新讨论方案。
你会看到AI已经加载了我们的Skill，并正确修改了xiaowang.md，具体内容点击之后可以查看得到，
这一篇你真正完成了什么
你不是学会了写一个文件。
你是把一段每次都要重新解释的工作方法，搬进了当前项目。
以前你每次都要说：
- 这个会议纪要按我们那个格式来。
- 没有负责人别乱写。
- 没拍板的别写成结论。
- 不确定先问我。
现在这些话进了 SKILL.md。下次在同一个项目里，Codex 不需要你从头讲一遍。
这就是 Skill 和普通 prompt 最大的区别。
prompt 像一句临时吩咐，说完就散。
Skill 像贴在项目墙上的规矩。对话换了，任务换了，只要项目还在，那张规矩还在。
最后只记这条路径：
skill-domain-framing 定高度- Codex 访谈你
- Codex 在当前项目落文件
prompt-review 立刻优化- 真实素材跑两轮
写 Skill 不是把话说得更漂亮。
是把话说到下次不用再说。
发布你的第一个 Skill：tranfu-publish 流程
你可能以为，发布一个 Skill，就是打开终端，敲一串看起来很专业的命令。
但在这里，真正的玩法刚好反过来：你不自己搬箱子，你让 Codex 把箱子搬到公司库门口，再让它给你拿回一张 GitHub PR 小票。拿到它，才算这个 Skill 真正走上了“可以被别人看到、检查、合并”的发布流程。
开始之前，先确认三件事：
- 已经读完第 1、2、3 章。
- 已经有一个本地 Skill。
- 当前正在用 Codex 操作。
本章的目标很简单：
让 Codex 把本地 Skill 提交到公司库，拿到 GitHub PR 链接。
全程只和 Codex 对话。
不要自己敲命令。
这句话很重要。发布流程里最怕的不是慢，而是你手一快，绕过了检查点。就像寄快递，地址、收件人、包裹内容都还没核对，你已经把箱子扔上车了。车是开了，至于开到哪里，就不好说了。
1. 先检查钥匙：GitHub 登录
发布到公司库，第一道门是 GitHub 登录。
你可以把 GitHub 理解成公司库大门上的电子锁。Codex 再能干，也得先确认这台机器有没有开门权限。不然它最多只能站在门口，礼貌地告诉你：我进不去。
复制下面这段话给 Codex：
检查当前机器是否具备发布 Skill 到公司库的 GitHub 登录状态。
要求：
1. 全程你来检查
2. 告诉我当前 GitHub 用户名
3. 如果已登录，输出：GitHub 登录已就绪
4. 如果未登录，引导我完成授权
5. 如果缺少发布所需工具，输出一段给环境负责人的求助话术
你要看到的成功标准是：
GitHub 登录已就绪GitHub 用户名：[你的账号]
2. 检查货物：本地 Skill 能不能发布
发布前先确认两件事：
- 请确保你的 Skill 已经走完了上一章的创建 Skill 的流程，保证 Skill 是一个基础合格的 Skill。
- 确保 AI 可以读取到你的 Skill，如果你不确定，可以问一下 AI。
示例话术可以这样判断：
| 类型 |
示例话术 |
判断 |
| 反例 |
我打算发布一个 meeting-saver skill，你可以访问得到它吗？ |
访问不到时，要检查名字是否打错，或者之前的 Skill 是否不在这个文件夹。 |
| 正例 |
我打算发布一个 organize-meeting-actions skill，你可以访问得到它吗？ |
organize-meeting-actions 是我们上一篇创建的，它可以正确访问得到。 |
反例截图：
正例截图：
3. 开始发布：
这里不需要执行什么终端命令，只需要告诉Codex一句话，它就会帮我们做：
把 organize-meeting-actions skill 分享到 Tranfu 库
为什么这里会有一个临时文件？
| 项 |
说明 |
默认 SKILL.md |
只有 name 和 description 两个属性。 |
| Tranfu 库补充字段 |
version、author、updated_at、origin。 |
| 临时文件作用 |
先把这些准备好，然后放到 Tranfu 库中。 |
接下来你需要干什么
跟它说一句发布即可。
4. 拿到 PR 链接：发布成功长什么样
跟AI说发布了之后，你会发现它返回了一个链接，
如果你是我们Tranfu公司的员工，还会收到一条通知
这里我解释一下里面最核心的概念：
等待审批完成之后，你会看到这样一条消息在Lark群中
5. 发布成功
到这里，你已经完成了第一次 Skill 发布。
用会议后事项跟进 Skill 讲透新手最常见的 8 个坑
这一章不再泛泛讲“Skill 要不要装很多”。
我们只盯着一个真实场景：
凡是涉及多人协作的会议，纪要必须在会后 24 小时内整理出行动项，每个行动项都要包含负责人、截止时间、交付物和确认人；没有负责人或截止时间的事项不能进入待办列表，内容是当提到小王的时候，就合并进他的工作安排中，工作安排通常在项目路径下的 week-jobs/xiaowang.md 中。
这不是一个“会议纪要润色”需求。
它真正要做的是会议后事项跟进：
- 从会议材料里识别行动项。
- 过滤掉缺少负责人或截止时间的事项。
- 保留负责人、截止时间、交付物、确认人。
- 遇到小王相关事项时，合并进
week-jobs/xiaowang.md。
这类 Skill 特别适合拿来讲新手坑。
因为它看起来很小，实际边界很容易滑坡。你一不小心，就会把它写成“所有会议都管、所有待办都管、所有人的工作安排都管、所有项目管理都管”的超级 Skill。到最后，它既容易误触发，又容易改错文件，还会在每次触发时吃掉一大块上下文。
先把结论放前面：
会议后事项跟进 Skill 应该是项目级、强触发、轻正文、窄边界、可回归的工作单元。
为什么？
因为 Skill 不是常驻大脑增强包。Codex 通常先看到 Skill 的名字和 description，等任务相关时才加载完整 SKILL.md。一旦加载，正文就会进入上下文，和用户请求、对话历史、系统提示一起竞争空间。12
所以这一章用同一个会议后事项跟进 Skill，讲 8 个新手最常踩的坑。
1. 把项目规则装到用户级
会议后事项跟进 Skill 的第一件事不是写正文，而是先判断它应该装在哪里。
这个案例里有一条非常关键的线索：
工作安排通常在项目路径下的 week-jobs/xiaowang.md 中
只要规则写到了项目路径、项目文件、项目成员，就优先放项目级 Skill。
比如你的项目是 /Users/wing/Develop/codex-tranfu-demo，那么这个 Skill 更适合放在 /Users/wing/Develop/codex-tranfu-demo/.codex/skills/organize-meeting-actions/SKILL.md。
它不适合直接装到用户级。
原因很简单：week-jobs/xiaowang.md 不是你所有项目都有的文件。小王也不是你所有项目里都有的人。把这条规则装到用户级，Codex 在别的项目里也可能误以为应该找这个文件，甚至创建一个不该出现的 week-jobs/xiaowang.md。
用户级更适合放通用方法，例如：
- 如何判断 Skill 是否值得创建。
- 如何审查 Skill 的
description。
- 如何发布或安装 Skill。
- 如何用提问澄清不明确需求。
项目级才适合放这类规则：
- 多人协作会议会后 24 小时内整理行动项。
- 行动项必须包含负责人、截止时间、交付物、确认人。
- 没有负责人或截止时间不能进入待办列表。
- 小王相关事项要合并到
week-jobs/xiaowang.md。
判断方法很直接：
| 规则内容 |
推荐位置 |
| 所有项目都适用的 Skill 写作方法 |
用户级 |
| 所有会议都适用的行动项基本格式 |
可能用户级 |
| 绑定某个项目路径的工作安排规则 |
项目级 |
| 绑定某个成员文件的小王跟进规则 |
项目级 |
新手常犯的错，是把“我常用”误认为“所有项目都该用”。
会议后事项跟进 Skill 要反过来想：
只要它会读写当前项目里的具体文件，就先按项目级处理。
2. 不先判断主 Skill，就让相邻 Skill 抢边界
更准确地说，问题通常不在“你会不会拆出很多微 Skill”。
真实工作里，很少有人按程序步骤拆零件，把每个字段检查都做成独立 Skill。
更真实的问题是：你的工作台里已经有几个“看起来都能处理一点”的 Skill。
比如：
| Skill |
看起来能处理的部分 |
meeting-notes-summary |
把会议记录整理成正式纪要 |
project-todo-triage |
从项目材料里提取待办和风险 |
weekly-worklog-sync |
把成员事项合并进 week-jobs/ |
lark-meeting-cleanup |
清理飞书会议转写和聊天记录 |
follow-up-message-draft |
根据待办起草会后提醒话术 |
这些名字都合理，也都不是瞎拆。
问题是，用户只说一句：
把这次会议里小王的后续事项整理一下。
到底该用哪个？
Skill 不是越多越强。它更像按需调用的操作卡片。装很多 Skill，不代表它们每次都会一起帮忙；Skills 会按任务相关性自动使用，不需要你每次手动点名。3
这里要先判断“主 Skill”。
主 Skill 不看输入长什么样，而看最后不可省的结果是什么。
如果用户只是要：
把这段会议记录整理成纪要。
那主 Skill 可以是 meeting-notes-summary，甚至普通 prompt 就够。
如果用户要：
把会议里小王的后续事项整理出来，并合并进他的工作安排。
那主 Skill 就应该是项目级的：
organize-meeting-actions
因为这个任务的成败，不取决于纪要写得漂不漂亮，而取决于：
- 有没有提取可跟进的行动项。
- 有没有过滤掉缺负责人或截止时间的事项。
- 有没有把小王相关事项合并进
week-jobs/xiaowang.md。
- 有没有保护旧任务不被覆盖。
其它 Skill 可以作为辅助，但不应该抢主导。
比如飞书转写很乱，可以先让 lark-meeting-cleanup 清理材料；但真正决定行动项是否进入待办、是否写入 week-jobs/xiaowang.md 的，仍然应该是 organize-meeting-actions。
装之前先问这 5 个问题：
| 问题 |
通过才装 |
| 下周还会处理同类会议吗？ |
会 |
| 是否每次都要检查行动项字段？ |
是 |
| 是否每次都要更新小王工作安排？ |
是 |
| 是否比临时 prompt 更稳定？ |
是 |
| 是否能和已有会议、待办、周报 Skill 分清主次？ |
能 |
这些就先别装：
- 只是把会议内容总结得更好听。
- 只偶尔给小王整理一次任务。
description 写成“资料整理、待办管理、项目推进”。- 和已有会议纪要 Skill 只有名字差异，没有不同失败标准。
- 需要读写文件，但你没确认它会改哪些路径。
你可以让 Codex 先帮你清理 Skill 工具台：
帮我审查当前可用的 Skills。
只围绕“会议后事项跟进”判断：
1. 哪个 Skill 应该做主 Skill
2. 哪些 Skill 只能作为前置清理或辅助输出
3. 哪些 description 太泛，可能抢错任务
4. 哪些应该合并、改名、收窄或暂时不用
输出判断理由和建议动作，不要解释概念。
一个好 Skill 不靠名字多，而靠主任务判断稳定。
会议后事项跟进就是这种任务：重复、规则明确、出错成本不低。
3. description 写成了“会议纪要整理”
会议后事项跟进 Skill 最容易死在 description 上。
坏例子通常长这样：
description: 整理会议纪要、提取待办事项、优化会议内容。
这句话看起来没错，但太宽。
它会带来三个问题。
- 普通会议摘要也可能触发它。用户只是想要一段纪要摘要，Codex 却可能开始检查负责人和截止时间。
- 普通待办整理也可能触发它。用户只是整理个人 todo，Codex 却可能去找
week-jobs/xiaowang.md。
- 文章或周报润色也可能误触发。因为“优化会议内容”这几个字太像内容处理 Skill。
description 是 Skill 的门牌。Codex 通常先看门牌，再决定要不要把完整 SKILL.md 读进来。门牌写宽了，路过也会进；门牌写窄了，该进的时候不进。4
这个案例的 description 要把四件事写清楚：
| 维度 |
要写清楚的内容 |
| 输入 |
多人协作会议的录音转写、聊天记录、零散会议笔记 |
| 输出 |
可跟进的行动项，以及小王工作安排文件的合并更新 |
| 触发 |
用户要求整理会议后事项、会后待办、小王相关会议任务 |
| 排除 |
普通摘要、文章润色、个人备忘、替负责人拍板 |
可以这样写：
description: 整理多人协作会议的录音转写、聊天记录和零散笔记，提取会后行动项，并检查每个行动项是否包含负责人、截止时间、交付物和确认人；没有负责人或截止时间的事项不得进入待办列表。当会议内容提到小王，或用户要求同步小王的会议后事项时，把属于小王的行动项合并进项目内 week-jobs/xiaowang.md。用于会议后事项跟进、会后待办整理和小王工作安排同步。不要用于普通会议摘要、文章润色、个人备忘、战略判断、绩效评价，或替负责人确认未拍板事项。
写完以后不要凭感觉说“应该可以”。直接做触发测试。
应该触发：
- 把这次会议里的行动项整理出来，提到小王的同步到他的工作安排。
- 这段飞书会议记录按会后待办处理，负责人和截止时间不全的不要进列表。
- 小王在会上认领的任务帮我合并进
week-jobs/xiaowang.md。
不应该触发：
- 把这次会议摘要写得更正式一点。
- 帮我润色这篇周报。
- 整理一下我今天的个人 todo。
- 评价一下小王这周表现怎么样。
可复制：
请帮我优化这个会议后事项跟进 Skill 的 description。
要求：
1. 保留“多人协作会议 -> 行动项 -> 小王工作安排文件”的边界
2. 明确负责人、截止时间、交付物、确认人四个字段
3. 明确没有负责人或截止时间不能进入待办列表
4. 补上 8 条应该触发的真实用户说法
5. 补上 8 条不应该触发的相邻场景
6. 只改 description，不改正文
Skill 路径：
[粘贴 SKILL.md 路径]
如果会议后事项 Skill 经常误触发，先别急着怪模型。多数时候，是 description 把“会议摘要”“待办管理”“项目管理”这些相邻任务也写进来了。
4. 把所有会议规则都塞进 SKILL.md
会议后事项跟进 Skill 一旦触发，完整 SKILL.md 会进入上下文。
这就是为什么它不能写成一份“会议管理百科”。
上下文窗口是公共资源。Skill 会和系统提示、对话历史、其他 Skill 元数据、用户请求一起竞争上下文。即使 SKILL.md 写得有道理，只要它太长，一旦加载，每个 token 都会和其它信息抢位置。1
这个案例的主文件应该很短。
应该放进 SKILL.md 的，是执行时必须马上知道的规则：
- 只处理多人协作会议后的事项跟进。
- 行动项必须包含负责人、截止时间、交付物、确认人。
- 没有负责人或截止时间，不得进入待办列表。
- 提到小王时，合并进
week-jobs/xiaowang.md。
- 更新文件前先读取现有内容，避免覆盖旧任务。
- 无法判断负责人、截止时间或确认人时，放入待确认，不要编造。
不应该放进主文件的，是低频背景：
- 公司会议文化说明。
- 所有团队成员的职责介绍。
- 会议纪要写作教程。
- 项目管理理论。
- 历史会议完整样例。
如果确实需要长资料，拆到 references/：
| Reference |
放什么 |
references/action-item-format.md |
行动项字段和示例 |
references/team-members.md |
团队成员角色说明 |
references/follow-up-examples.md |
历史会议样例 |
但只拆出去还不够。你还要写清楚什么时候读。
这样写才有用：
- 当用户要求解释行动项字段格式时，读取
references/action-item-format.md。
- 当会议里出现不熟悉的成员简称时，读取
references/team-members.md。
- 当用户要求对齐历史写法时，读取
references/follow-up-examples.md。
- 默认不要读取
references/ 下的长样例。
别只写：
更多资料见 references/。
这句话对 Codex 没什么帮助。它知道有仓库，但不知道该翻哪一箱。
固定检查可以脚本化。
比如这个 Skill 的稳定校验可以放到 scripts/：
- 检查输出行动项是否都有负责人。
- 检查输出行动项是否都有截止时间。
- 检查是否意外删除
week-jobs/xiaowang.md 里的旧任务。
- 检查是否把待确认事项写进正式待办列表。
还有一类内容既不是 references/，也不是 scripts/。
它是关键任务流程里的显式动作。
比如会议后事项跟进 Skill 如果只写：
这不够。
这些话太软，Codex 很可能直接往下做。关键流程缺失时，要把 Codex 里更接近的动作写明白。Codex 官方建议复杂或模糊任务先 plan，也可以让 Codex 先 interview 你；subagents 也不会自动触发，必须明确要求 spawn / delegate。56
在这个 Skill 里可以这样写：
| 缺的不是规则，而是流程动作 |
在 Codex 里应该写成 |
| 会议目标、确认人、目标文件不清楚 |
先进入 Plan mode，或先 interview 用户，问清缺失字段再执行 |
| 步骤多，容易漏读旧文件或漏验证 |
维护执行计划，逐步更新 update_plan：提取、过滤、读旧文件、合并、验证7 |
| 会议材料很长，提取行动项会污染主上下文 |
显式 spawn 一个 subagent，只负责从材料里提取候选行动项并返回摘要 |
| 需要实际落地到项目文件 |
明确读 week-jobs/xiaowang.md、合并编辑、再检查 diff |
注意，这里不是把 Claude Code 的 AskUserQuestion、TaskCreate 这些名字照搬进 Codex Skill。
更稳的写法是写 Codex 能直接执行或理解的动作：
- 如果关键字段缺失，先进入 Plan mode 或 interview 用户，不要继续写文件。
- 如果会议材料超过一屏或包含多场会议，spawn 一个 subagent 只做候选行动项提取；主 agent 负责判断哪些能进入正式待办。
- 执行过程中维护
update_plan，至少包含：提取行动项、过滤缺字段事项、读取小王旧工作安排、合并新事项、检查 diff。
可复制：
请压缩这个会议后事项跟进 Skill。
目标：
1. 删除会议管理科普和 Agent 已经知道的通用解释
2. 保留触发边界、行动项字段、待确认规则、文件更新规则
3. 把低频样例拆到 references/
4. 把可机械检查的字段完整性规则放到 scripts/
5. 在 SKILL.md 里写清每个 reference 和 script 什么时候使用
6. 补上关键流程动作：什么时候 Plan/interview，什么时候 update_plan，什么时候 spawn subagent，什么时候读写文件
7. 不改变“多人协作会议 -> 行动项 -> 小王工作安排”的任务边界
Skill 路径：
[粘贴 SKILL.md 路径]
会议后事项跟进 Skill 费不费 token，不只看它有没有用，还看它有没有把低频资料全带上桌。
5. 把会议后事项跟进扩大成项目管理
这个 Skill 应该写大一点，还是拆小一点？
不要按字数判断。
按工作单元判断。
更稳的方法是问三件事：
- 输入是不是同一类？
- 产出是不是同一种？
- 失败标准是不是同一个？
对会议后事项跟进来说：
| 维度 |
会议后事项跟进的判断 |
| 输入 |
多人协作会议材料 |
| 产出 |
结构化行动项，以及小王工作安排文件更新 |
| 失败标准 |
漏掉行动项、编造负责人、缺少截止时间、覆盖旧任务、误改无关文件 |
这些可以放在同一个 Skill 里：
| 候选范围 |
判断 |
| 会议录音、会议聊天记录、零散会议笔记 -> 行动项 |
可以合 |
| 行动项字段完整性检查 |
可以合 |
小王相关行动项 -> week-jobs/xiaowang.md |
可以合 |
| 读取旧工作安排并合并新任务 |
可以合 |
这些不要顺手塞进去。不是因为它们不重要，而是它们更像另一个主任务：
| 候选范围 |
判断 |
把所有成员的事项统一归档到 week-jobs/ |
可能是 weekly-worklog-sync |
| 从会议结论更新项目排期表 |
可能是项目排期维护 Skill |
| 给参会人起草会后提醒消息 |
可能是会后沟通 Skill |
| 把会议记录改写成正式纪要 |
可能是会议纪要 Skill |
| 根据会议内容生成周报 |
可能是周报 Skill |
为什么“写入小王文件”可以合？
因为它不是另一个任务，而是这个会议后事项跟进流程的落地动作。会议里提到小王，如果不更新他的工作安排，这个 Skill 的目标就没完成。
为什么“所有成员事项归档”不要直接合？
因为输入、输出、失败标准都变了。它不再是处理一场会议里的小王事项，而是在维护一套成员工作台账。那可以是另一个 Skill，也可以是后续工作流，但不该悄悄塞进当前 Skill。
可复制：
帮我判断这个会议后事项跟进 Skill 应该拆还是合。
候选范围：
1. 整理多人协作会议行动项
2. 检查负责人、截止时间、交付物、确认人
3. 小王相关事项写入 week-jobs/xiaowang.md
4. 把所有成员事项统一归档到 week-jobs/
5. 根据会议内容起草会后提醒消息
只按这 3 个标准判断：
1. 输入是不是同一类
2. 产出是不是同一种
3. 失败标准是不是同一个
最后输出：
1. 保留一个 / 拆成几个 / 合并到已有 Skill
2. 推荐 Skill 名称
3. 推荐 description 边界
4. 不要覆盖的相邻场景
判断拆还是合，不要问“它能不能顺手也做”。会议后事项跟进 Skill 的边界，通常就是被“顺手把所有人的安排也同步一下”撑爆的。
6. 把每次 prompt 都复制成 Skill 正文
prompt 管这一次。
Skill 管以后每一次。
会议后事项跟进特别适合说明这个区别。
如果你只是在某一次会议后说：
- 这次纪要写得口语一点。
- 这次只保留技术相关事项。
- 这次不要更新小王文件，先给我看草稿。
这些是 prompt。
它们只影响这一次，不应该写进 Skill。
但下面这些是每次都要遵守的规则：
- 多人协作会议会后 24 小时内整理行动项。
- 每个行动项必须包含负责人、截止时间、交付物、确认人。
- 没有负责人或截止时间，不能进入待办列表。
- 提到小王时，要合并进
week-jobs/xiaowang.md。
- 更新前读取旧文件，合并而不是覆盖。
- 不确定时放入待确认，不编造。
这些应该写进 Skill。
资料里对这个区别说得很清楚：prompt 是对话级的一次性指令；Skill 是按需加载的可复用专业能力。Skills 适合团队流程、品牌规范、会议纪要格式、数据分析流程这类可重复工作。Custom instructions 更广泛地应用，Skills 只在相关任务加载。82
简单判断：
| 内容 |
放哪里 |
| 这次纪要语气轻松一点 |
prompt |
| 这次只看技术事项 |
prompt |
| 先输出草稿，不写文件 |
prompt |
| 行动项必须有负责人和截止时间 |
Skill |
小王事项合并进 week-jobs/xiaowang.md |
Skill |
| 旧任务不能被覆盖 |
Skill |
| 长样例和历史写法 |
references/ |
| 字段完整性和文件差异检查 |
scripts/ |
千万别把 Skill 写成“我每次都可能想说的话合集”。
会议后事项跟进 Skill 只应该固定这几件事：
- 遇到哪类会议材料。
- 按什么步骤提取行动项。
- 输出什么字段。
- 哪些事项不能进入待办。
- 什么时候更新小王文件。
- 不确定时怎么处理。
- 怎么验证没有漏字段、没覆盖旧任务。
可复制：
请判断下面这些要求应该放进会议后事项跟进 Skill，还是留在本次 prompt。
规则列表：
1. [规则 1]
2. [规则 2]
3. [规则 3]
判断标准：
1. 只对这次会议有效 -> prompt
2. 每次会议后都要遵守 -> Skill
3. 很长但低频 -> references/
4. 可自动校验 -> scripts/
输出表格，不要展开解释。
一句话：你只是今天想这么做，用 prompt；你不想以后每次都重新解释，就写进 Skill。
7. 发布后跑歪了就整份重写
会议后事项跟进 Skill 发布后，第一次跑歪很正常。
但不要整份重写。
要先分类。
同样是跑歪，原因可能完全不同：
| 现象 |
先改哪里 |
| 用户说“整理小王会后事项”但 Skill 没触发 |
description 太窄 |
| 用户只是要会议摘要，Skill 却触发 |
description 太宽 |
| 输出了没有截止时间的待办 |
workflow 或 gotchas 缺规则 |
| 把“待确认”写进正式待办 |
输出模板不清 |
覆盖了 week-jobs/xiaowang.md 旧内容 |
文件更新步骤缺读旧文件 |
| 把小张的事项写给小王 |
负责人归属规则不清 |
| 每次都手动检查字段 |
应该补 scripts/ |
| 关键字段缺失时还继续写文件 |
应该显式要求 Plan mode 或 interview 用户 |
| 经常漏掉读取旧文件、合并、验证这几个步骤 |
应该显式要求维护 update_plan |
| 会议材料太长，主线程里塞满转写细节 |
应该明确 spawn subagent 做候选行动项提取 |
第一版 Skill 本来就常常要靠真实任务继续修改。更重要的是，你要看执行轨迹，不只看最终结果。如果 Agent 浪费步骤，常见原因是规则太泛、不适用，或者给了太多同级选项。触发问题还要用 should-trigger / should-not-trigger 查询集反复测。94
修改时记住三条：
- 一次只改一个问题。
- 每次改完用同一条会议材料回归。
- 不要为了一个失败案例，把
description 改到过拟合。
再加一条更关键的：
- 如果缺的是任务流程，不要只补一句“注意检查”；要补显式动作。
- 如果缺的是长子任务，不要让主 agent 硬扛；要明确交给 subagent，并规定返回摘要。
比如失败现象是：
会议里说“小王先按现有字段做 mock”，但没有明确截止时间。Codex 把它写进了正式待办。
这时候不要重写整个 Skill。
只补一条 gotcha：
如果行动项缺少负责人或截止时间，必须放入“待确认”，不得写入正式待办，也不得写入 week-jobs/xiaowang.md。
再用同一条会议材料回归。
如果失败现象是：
会议材料很长，Codex 在主线程里贴了大量转写细节，最后漏掉了小王的两条任务。
也不要只补一句“仔细阅读会议材料”。
要补成可执行的子 Agent 规则：
当会议材料很长、包含多段转写或多场会议时，spawn 一个 subagent。该 subagent 只做候选行动项提取，返回负责人、截止时间、交付物、确认人和原文依据。主 agent 不接收原始长转写，只接收摘要后再判断哪些事项能进入正式待办和 week-jobs/xiaowang.md。
如果失败现象是：
Codex 提取了行动项，但忘了先读取 week-jobs/xiaowang.md，直接覆盖了旧内容。
要补成计划规则：
执行时必须维护 update_plan，且不能跳过这 5 步：提取候选行动项、过滤缺负责人或截止时间的事项、读取 week-jobs/xiaowang.md 旧内容、合并新事项、检查 diff 确认旧事项未被删除。
可复制：
这个会议后事项跟进 Skill 发布后跑歪了。
失败现象：
[写清楚哪里错]
真实会议材料：
[粘贴触发请求和会议内容]
请先分类：
1. 触发问题
2. 执行步骤问题
3. 输出格式问题
4. 缺少 gotcha
5. 应该脚本化
6. 是否缺少 Plan/interview/update_plan/文件读写这类显式流程动作
7. 是否应该把过长子任务交给 subagent
然后只做最小修改。
不要重写整份 SKILL.md。
改完后，用同一条会议材料再跑一次。
会议后事项跟进 Skill 的迭代，不靠豪华重构。它靠一次抓住一个偏差。
8. 从公司库安装前不看权限和脚本
公司库里的 Skill 也不能闭眼装。
会议后事项跟进 Skill 尤其要小心，因为它通常会读写项目文件：
- 读取会议材料。
- 读取
week-jobs/xiaowang.md。
- 修改
week-jobs/xiaowang.md。
- 可能读取
references/ 里的团队成员说明。
- 可能运行
scripts/ 做字段检查。
资料里说得很直接：只从可信来源安装 Skill；安装不太可信的 Skill 前，要检查其中的文件、依赖、资源和外部网络访问。Skill 的主要风险包括 prompt injection 和 data exfiltration。3
翻译成人话就是：
它可能诱导 Agent 做不该做的事，也可能把不该出去的数据带出去。
安装这个 Skill 前，至少看 6 件事：
SKILL.md 的任务边界是不是只处理会议后事项跟进。description 有没有泛化到资料整理、项目管理、绩效评价。allowed-tools / disallowed-tools 有没有给过大权限。scripts/ 是否会读写 week-jobs/ 之外的路径。- 是否要求安装第三方包。
- 是否会访问外部网络或上传会议内容。
优先安装这些：
- 团队验证过。
- 边界只覆盖会议后事项跟进。
- 明确写了读写文件路径。
- 更新文件前会读取旧内容。
- 没有负责人或截止时间不会写入正式待办。
- 脚本只做本地字段检查。
先别安装这些：
description 写成“整理会议、同步待办、推进项目、跟踪成员”。- 脚本默认扫描整个项目目录，而不是限定
week-jobs/ 和会议材料。
- 需要联网但没说明原因。
- 会把会议内容发到外部服务。
- 会根据会议内容自动评价成员表现。
可复制：
帮我审查这个公司库里的会议后事项跟进 Skill 是否适合安装到真实项目。
检查：
1. SKILL.md 是否只覆盖多人协作会议后的行动项跟进
2. description 是否太泛，是否会误触发普通摘要、周报、项目管理
3. allowed-tools / disallowed-tools 是否合理
4. scripts/ 是否只做本地字段检查，是否读写敏感文件
5. 是否会访问外部网络或上传会议内容
6. 是否明确保护 week-jobs/xiaowang.md 的旧内容
7. 是否和我已有会议纪要或待办 Skill 重叠
输出：
1. 建议安装 / 先不安装 / 只在练习项目试用
2. 风险点
3. 安装前要问维护者的问题
公司库不是自动可信区。会议内容和成员工作安排都可能敏感，越是会读写项目文件的 Skill，越要先看清楚它能碰哪里。
会议后事项跟进 Skill 避坑清单
把这张表贴到每次审查前面。
| 问题 |
判断标准 |
| 1. 装到哪里？ |
写到项目路径和小王文件，就放项目级 |
| 2. 怎么判断主 Skill？ |
看最后不可省的结果，不看输入材料像什么 |
| 3. 为什么误触发？ |
多半是 description 把会议摘要、待办管理、项目管理都写进来了 |
| 4. 为什么更费 Token？ |
SKILL.md 太重，触发后抢上下文 |
| 5. 写大还是拆小？ |
输入、产出、失败标准一致就合，否则拆 |
| 6. Skill 和 prompt 怎么分工？ |
一次性偏好放 prompt，重复流程放 Skill |
| 7. 发布后不好用怎么办？ |
分类问题；流程缺失补显式动作，长子任务指定 subagent |
| 8. 公司库能不能直接装？ |
先审来源、权限、脚本、联网和文件读写范围 |
最后给 Codex 的总检查 prompt：
请按“会议后事项跟进 Skill 避坑清单”审查这个 Skill。
检查 8 件事：
1. 是否应该装到项目级
2. 是否值得创建或安装
3. description 是否容易误触发
4. SKILL.md 是否太重
5. 范围应该拆还是合
6. 哪些内容应该留在 prompt
7. 是否缺少 Plan/interview/update_plan/文件读写/subagent 这些显式流程动作
8. 是否适合从公司库安装到真实项目
要求：
1. 先给结论：保留 / 修改 / 不建议安装
2. 每条只写问题和最小修改建议
3. 不要重写整份 Skill
Skill 路径：
[粘贴 SKILL.md 路径]
会议后事项跟进 Skill 真正厉害的地方，不是把“会议纪要”四个字写进一个新文件。
它厉害在：把会后跟进里最容易漏、最容易编、最容易改错文件的规则固定下来。
下次你再丢一段会议记录，Codex 不应该只是写一段漂亮摘要。
它应该知道：
- 哪些是行动项。
- 哪些缺字段不能进待办。
- 哪些属于小王。
- 应该合并到哪个项目文件。
- 哪些不确定必须问。
这才是 Skill 和普通 prompt 的区别。
prompt 解决这一次。
Skill 固定以后每一次。
参考资料
这篇只用了能落到操作上的一手资料：