导读
会提问只是入门。AI 擅长「当下接龙」，却不擅长自己记住最佳路径。本文把个人 / 小团队可用的 AI 工作流拆成 Rules、Skills、知识库 三层，说明如何沉淀 Skill、如何协作，以及本周就能落地的第一步。

---

会提问、会写 Prompt，只是入门。

真正拉开差距的，是你能不能把「已经验证过的最佳做法」沉淀下来，让 AI 下次按同一条路稳定完成，而不是每次从零开始聊。

每个认真用 AI 的人，都应该会搭建并持续完善适合自己的工作流。

核心观点：AI 擅长「当下接龙」，不擅长「自己记笔记、自己定规矩」。所以要把规矩写成 Rules，把最佳路径写成 Skills，把资料放进知识库。

---

一、为什么「会聊天」还不够

1.1 AI 不是人，它的工作方式决定了坑在哪里

先建立一个正确、够用的认知，AI不会思考，没有记忆和反思机制：

1. 没有跨会话的稳定记忆
   换一个对话窗口，上次对齐过的背景、口味、边界，它往往不知道。

2. 不会主动反思、复盘、迭代流程
   人做完一件事会想：「下次别再踩这个坑。」AI 不会自动把这次经验写进下一次标准动作——除非你主动外挂机制去记录。

3. 本质是概率生成
   它根据上下文，计算下一个最可能、最通顺的词或片段；同时还带有随机性（常说的温度系数）。于是：

   • 同一件事，不同会话结果会漂
   • 同一句话，问两次也可能不一样
   • 你以为「它懂了」，其实只是「这一轮上下文里接得顺」

直接后果： 如果你只靠对话，就会反复教、反复改、反复对齐。不是你不够会问，而是「对话」本身不是为「可复用」设计的。

1.2 重复沟通，才是最贵的隐性成本

很多人以为用 AI 省时间，实际却卡在这里：

• 每次写周报，都要重新交代项目背景、读者是谁、语气要求
• 每次做竞品分析，都要重新说明维度、输出格式、禁止臆造数据
• 每次改需求文档，都要重新强调「先澄清再写方案」

这些不是创造性工作，而是已经验证过的协作成本。真正该被工作流吃掉的，正是这部分。

1.3 上下文有限：不能靠「把历史全贴进去」

就算每次把资料、规则、范例全塞进对话，也有两个问题：

1. 上下文窗口有限
   越塞越多，重要信息更容易被淹没，模型也更容易「丢注意力」。

2. Token 又贵又吵
   每次重复传输同一套流程说明，既浪费，也干扰当前任务真正该聚焦的输入。

Skill 的价值不只是省事： 它把最佳流程压缩成可复用的说明书，释放上下文，让 AI 专注处理「这一次的输入」，而不是反复回忆「这件事该怎么做」。

1.4 结论：需要外挂工作流

既然 AI 不会稳定地「自己记住最佳路径」，那就主动外挂：

• 用 Rules 固化边界与标准
• 用 Skills 固化做事步骤
• 用 知识库 提供可检索的事实与资料

工作流的本质，不是让 AI 更聪明，而是让「聪明」变得可重复、可路由、可协作。

---

二、Agent 工作流三件套：Rules、Skills、知识库

一个完整、够用的个人或小团队 AI 工作流，通常由三层组成：

层级	是什么	负责什么	一句话
Rules（约束层）	AI 的人格、边界、输出契约	少犯错	始终生效的「标准」
Skills（流程层）	AI 的 SOP 手册	提效率	按需调用的「路径」
知识库 / RAG（资料层）	AI 的参考资料	找依据	需要时检索的「事实」

记住这句就够用：

Rules 定边界，Skills 定路径，知识库定依据。

Rules 像刹车和方向盘，Skills 像导航地图：没有 Rules，AI 容易跑偏；没有 Skills，AI 容易绕远路；没有知识库，AI 容易凭感觉编。

2.1 Rules：始终生效的标准，不只是禁止项

Rules 是贯穿会话的长期约束。它不只是「否定逻辑」，常见至少有三类：

1. 边界：不能做什么
   例如：不要编造数据；不确定时先问我。

2. 人格 / 偏好：以什么身份、什么风格协作
   例如：偏严谨；先给结论再展开；默认简洁中文。

3. 输出契约：结果必须长什么样
   例如：默认给可执行清单；对外文案必须标注假设。

Rules 解决的问题是： 无论做什么事，底线与质量门槛是什么。

2.2 Skills：按需加载的做事路径

Skills 回答的不是「你是谁」，而是：

这件事分几步？每一步要什么输入？产出什么？哪里必须停下来让人确认？

例如：

• 写活动文案的 5 步法
• 从会议录音到待办清单的 3 段流程
• Bug 复现 → 定位假设 → 最小修复方案

它的职责很明确：把你验证过的最佳路径固化下来，让 AI 识别到意图后按流程完成，而不是重新即兴发挥。

2.3 知识库：需要时检索的事实

知识库提供的是资料与依据，而不是流程本身：产品 PRD、历史决策、品牌话术、竞品资料、接口文档、过往复盘……

三者分工可以这样理解：

• Rules 告诉 AI：按什么标准做
• Skills 告诉 AI：按什么步骤做
• 知识库告诉 AI：依据什么材料做

2.4 补一句，避免概念混淆

如果你已经在用 Cursor、Claude 或各类 Agent 平台，还可以把「工具层」分开看：

概念	解决的问题
Skill	怎么做（流程 / SOP）
工具 / MCP	能碰什么（系统、文档、数据库、浏览器）
知识库	该参考什么（资料与事实）

完整一点的工作流常常是：

Rules 约束 + Skill 编排 + 工具取数 + 知识库查证。

本文仍以 Rules / Skills / 知识库为主；希望AI能力更强可在腾讯MCP广场 搜索下载各类MCP使用。

---

三、Skills 从哪里来

Skills 不是灵感创作，更像是经验压缩。常见有三条路。

3.1 从开源或社区「拿来再改造」

优先从现成库里找接近需求的 Skill，再改成自己的版本。

推荐入口：SkillHub（腾讯） —— 可浏览、搜索各类开源 Skill，挑接近场景的拿来改。

改造步骤：

1. 先跑一遍，看默认假设是否符合你的场景
2. 改触发描述、步骤、输出格式、人工确认点
3. 变成「适合你」的版本，而不是原样照搬

原则： 别人的 Skill 是半成品原料，不是成品答案。

3.2 从历史会话里沉淀

这是最贴近真实业务的方式。观察最近 2～4 周的高频对话：

• 哪类事你反复开新会话？
• 哪类事你总在纠正同一类错误？
• 哪类事你已经形成了「先问 A，再做 B，最后输出 C」？

这些就是 Skill 的雏形。沉淀步骤：

1. 复盘一次「终于做对了」的对话
2. 抽出：触发场景、必要输入、步骤、产出、禁止项、人工确认点
3. 写成 Skill
4. 下次故意只用它再跑一遍，修到稳定

3.3 用元能力批量生产：skill-creator 或 /create-skill

当你开始认真建库，「写 Skill」本身也会变成重复劳动。这时应先启用一个元技能：

• 按开放标准（如 Anthropic 的 Skills 规范）与业界原则，先做一个 skill-creator
• 或直接用工具自带的 /create-skill

之后流程变成：

描述需求 → 用 skill-creator 生成初稿 → 试用反馈 → 再迭代。

另外补充一点，避免和「路由」搞混：

• skill-creator：用来创建 / 修改 Skill 的元技能，需要时你可以自己建或用工具命令
• 意图路由（通常内置）：Cursor、Claude 等工具会根据用户意图，自动匹配并加载合适的 Skill——一般不需要你再单独创建一个 Router Skill

你要做的，是把每个 Skill 的触发条件写清楚；路由这件事，工具大多已经帮你做了。

---

四、什么是好的 Skill

一个好的 Skill，目标只有一句话：

只做一件事；能被 Agent 自动识别并正确调用；能稳定地把这件事做完。

这一章分两层看：

1. 基础四条标准：先把 Skill「做对」——几乎所有岗位都适用
2. 进阶写法原则：再把 Skill「写稳」——从工程实践里提炼的通用技巧

---

基础标准：先把 Skill 做对

4.1 标准一：单一职责

坏例子：

• 「写一整本书」
• 「从 0 到 1 做完整运营方案并直接发布」

好例子：

• 「根据材料生成大纲」
• 「根据已选定大纲写单章初稿」
• 「检查章节逻辑并给出修改建议」

Skill 越大，失败点越多，质量越不可控。正确姿势是可组装的小模块，不是万能巨兽。

4.2 标准二：可被自动识别

Skill 不只是给自己看的备忘录，更是给 Agent 看的路由说明书。好的描述通常包括：

• 它解决什么问题
• 用户怎样表达意图时应触发
• 它不处理什么

对比：

• 好： 当用户要「把会议录音 / 纪要整理成待办」，使用本 Skill……
• 差： 一个叫 helper 的 Skill，描述写「什么都能干」

如果 Agent 不知道何时调用你，这个 Skill 等于不存在。

4.3 标准三：输入 / 输出清晰

至少写清：

• 输入：必须提供什么？缺了先问还是用默认？
• 输出：最终交付物是什么格式？
• 质量标准：怎样算完成？

没有 I/O 的 Skill，最后会变回另一场自由发挥对话。

4.4 标准四：必须有人工确认节点

这是办公室场景里最容易被忽略、却最重要的一点。

AI 工作流不是无人流水线，更像副驾驶：

为什么必须这样？

1. 关键选择依赖业务判断、风险偏好、品牌口径——这是人的优势
2. 全自动看起来爽，错一次成本可能高于全程手做
3. 「可停、可确认、可改道」，才是能上真工作的工作流

结论： 好的 AI 工作流，不是消灭人，而是把人放到少数高杠杆判断点上。

4.5 两个反面教材

• 过度耦合： 把很多阶段塞进一个 Skill，看起来一键完成，实际是把所有不确定性捆在一起。应拆小，再串联。
• 过度死板： 没有确认点、没有例外分支、不允许追问缺失信息。结果是输入一偏，输出自信地错。

---

进阶原则：再把 Skill 写稳

Skill 里只写「你团队才知道、Agent 猜不到」的东西；再按风险管住它，按步骤带着它，交活前再验一次。

4.6 只写 Agent 不知道的事

Agent 已经很强：通用写作、常见代码、常规分析，它大多会。你不必在 Skill 里再教一遍「什么是周报」「什么是 React」。

真正值得写的，是那些只存在于你和团队脑子里的私有约定：

• 开发：接口必须走统一封装，禁止裸用 fetch；状态管理用哪套、日期库用哪个
• 产品：需求先澄清再写方案；验收标准必须可测试；不确定项标「待确认」
• 运营：对外数据必须可追溯；品牌禁用词列表；先选题确认再写正文
• 设计：默认设计系统组件优先；某类页面必须给无障碍说明

判断标准很简单： 这段话如果要对一个「刚入职的资深同事」交代，就值得写进 Skill；如果是行业常识，删掉。

• 浪费： 「写 HTTP 请求可以用 fetch……」（Agent 本来就会）
• 有价值： 「所有接口请求必须走项目封装的 request，禁止直接用 fetch / axios。」（私有约定）

4.7 按风险等级调「管控力度」

写 Skill 像设计道路：高速路要护栏，公园小路可以放开。

力度	怎么写	适用场景
松	只给方向与原则	方案 brainstorm、代码 Review、选题发散
中	给模板 + 规范，细节可调整	按团队规范写组件、写周报、写需求初稿
严	精确步骤，几乎不留发挥空间	发版、改配置、数据变更、对外正式发布

记住： 越危险的操作越要收紧；越创造性的任务越要放手。

4.8 画好三条线：能做、要问、别碰

Agent 没有职场常识。每个 Skill 建议都写 Boundaries，把标准四里的「人工确认」落成明确清单：

类型	含义	示例
放手做	任务范围内直接执行	新建当前需求相关文件；生成周报初稿
先问我	高影响变更先确认	改公共模块 / 全局配置；新加依赖
绝对不要	红线，禁止越界	删测试、提交密钥、编造数据、擅自对外发布

4.9 用示例说话，并尽量参数化

在「输入 / 输出清晰」之上，再进一步：

• 少写三段抽象解释，多给一个可照抄的示例（范文、代码模板、输出样例）
• 参数化复用：把可变部分抽成参数（名称、风格、是否生成附带物），一个 Skill 覆盖一类相似任务

Agent 理解示例的能力，通常强过理解自然语言空话。

4.10 内容分层 + 多步锁顺序 + 工具优先

三件省心的写法：

1. 内容分层：主文件只放核心规则；详细规范放到 references/，按需加载；引用尽量只做一层
2. 多步锁顺序：发版、上线、迁移等流程用编号清单，写明「按顺序执行，不要跳步」
3. 工具 / 脚本优先：确定性操作能跑脚本就别手写；项目已有工具要在 Skill 里列出来，Agent 默认不知道

4.11 交付前设一道「质检门」

在 Skill 末尾加 Pre-Delivery Checklist，要求「全部通过后才能说已完成」。关键是写得具体：

• 虚： 「保证质量」「写得专业一点」
• 实： 「跑 tsc 无报错」「周报必须含进展 / 风险 / 求助三栏」「对外文案无未确认数据」

4.12 写之前再过一遍避坑清单

1. description 太模糊 → Agent 不会自动调用
2. 正文太啰嗦 → 只写团队私有约定，不写行业常识
3. 给太多并列选择 → 先给一个默认方案，必要时再给备选
4. 忘记设边界 → 没有「别碰」，就容易越界
5. 名称太泛 → helper 不如 weekly-report

---

五、Skills 如何协作：工作流真正开始成形

单个 Skill 解决单点效率；多个 Skill 协作，才叫工作流。

5.1 形态一：线性调用

上一个的输出，是下一个的输入。这是最常见、也最稳的形态：

产品侧也可以同样拆：

需求澄清 → 人工确认范围 → 用户故事拆解 → 评审问题清单

线性调用的优点是可理解、可调试：哪一步坏了，就修哪一步。

5.2 形态二：自动路由（通常不用自己建）

当 Skill 变多，你也不必每次记住「该喊哪个」。在 Cursor、Claude 这类工具里，意图识别和 Skill 分派一般是 Agent 自带能力：它会读每个 Skill 的 description，自动决定加载哪一个。

于是会出现这种体验：

• 「帮我分析这周数据」→ 自动命中数据分析 Skill
• 「写一封对客户的致歉邮件」→ 自动命中商务邮件 Skill
• 「把评审纪要沉淀成行动项」→ 自动命中会议待办 Skill

所以日常工作流里，通常不需要再创建一个 Router / 管家 Skill。
你真正该投入的，是把每个 Skill 写到「能被正确匹配」：触发场景清楚、职责单一、边界不严重重叠。

只有这些情况，才值得额外做编排层（可以是一个编排型 Skill，或自建 Agent 流程）：

1. 一次请求要串很多 Skill，且顺序 / 分支很固定
2. 多个 Skill 容易抢同一意图，需要明确优先级或决策树
3. 你在自建 Agent 平台，没有成熟的自动 Skill 路由

多数人先把 Skills 写好，比先造一个管家更划算。

5.3 协作时的三条纪律

1. 接口稳定：上游输出格式尽量固定，下游才好接
2. 失败可回退：某步不确定时停下来问人，而不是硬往下传错
3. 职责不重叠：Rules 管全局标准，Skill 管局部流程，别让每个 Skill 都重复写一整套宪法

---

六、什么时候还不该上 Skill

不是所有事都值得立刻做成 Skill。否则你会从「重复教 AI」变成「重复维护烂 Skill」。

暂缓固化的信号：

1. 一次性探索：你还在找方向，流程每天都在变
2. 创意发散期：需要的是多样性，不是稳定性
3. 你讲不清步骤：说明业务本身还没想清楚——先梳理业务，再写 Skill

Skill 是流程的压缩，不是流程的替代。先有清晰流程，再有好 Skill。

实用判断： 如果同一类事你已经认真做过 3 次以上，且纠正点高度重复——就可以开始沉淀 Skill 了。

---

七、人的角色变了：从「会提问」到「会定义流程」

很多人仍把竞争力理解成「谁 Prompt 写得花」。更准确的说法是：

未来差的不是谁更会问，而是谁更会把工作拆成可执行流程。

角色	负责
人	定义问题、拆解流程、设定边界、选择关键节点、验收结果
AI	按既定路径执行、检索资料、生成草稿、做机械性整理与转换

动手干活前，不妨先和 AI 讨论：怎样减少人工重复参与？
只要你开始追问「如何少做重复劳动」，正确的工作流往往会自己长出来。

再往上看一层：搭建工作流的过程，其实是你对自己业务逻辑的一次 CT 扫描。如果你拆不清步骤，你既管不好人，也指挥不好 AI。

---

八、你现在在哪一层：工作流成熟度

可以用下面这张表做自我定位，也方便团队对齐语言：

层级	状态	典型表现
L1	会提问	遇到问题就开聊，结果看运气
L2	有常用 Prompt	会复制粘贴模板，但仍靠人记
L3	有 Rules + 若干 Skills	常见任务开始稳定，少重复教学
L4	Skills 可串联，关键节点人工确认；必要时接工具 / 知识库	形成真正可复用的个人或小团队工作流

不必立刻到 L4。更务实的目标是：

把 L3 当成「会用 AI」的现代门槛；把 L4 当成下一阶段效率飞轮。

---

九、岗位最小可用示例

不必一次建很多。每个岗位先有一个「最小闭环」就够。下面以产品经理为例画一张图，其余岗位用文字列出。

产品经理

Rules 示例： 先澄清再方案；不确定标成待确认；不编造用户原话。

其他岗位最小闭环

• 开发：Bug 复现补全 → 根因假设与影响面 → 最小修复方案 → Code Review 自检
  Rules： 先给风险与回滚；不擅自扩大改动范围。
• 测试：改动点提取 → 测试点设计 → 人工确认优先级 → 用例与回归范围
• 设计：需求解读 → 方案方向发散 → 人工选定方向 → 设计说明 / 标注说明
• 运营 / 业务：选题生成 → 人工选定 → 正文创作 → 渠道适配
  Rules： 涉及数据必须可追溯；对外口径不确定先停。

这些例子不是让你照抄，而是说明一件事：

任何岗位，只要存在重复路径，就能工作流化。

---

十、体感对比：没有工作流 vs 有工作流

以「写周报」为例。

没有工作流时

1. 开新对话，重新说明读者是谁
2. 粘贴一堆零散进展
3. AI 写得太虚，你改
4. 你补充风险与阻塞，AI 再改
5. 你强调结论前置，再改
6. 终于能用——下周重来

有工作流时

• Rules：结论先行；必须含进展 / 风险 / 求助；不夸张成果
• Skill：收集素材 → 结构化周报 →（你确认重点）→ 精简版 / 同步版
• 知识库：本周文档、迭代备注、数据看板摘要

体感差距就在这里： 你从「教 AI 写周报」变成「喂素材，验收结果」。

---

十一、落地：本周只做一件事

别一上来规划宏大的「个人 AI 操作系统」。从最小动作开始。

步骤 1：选一个最高频任务

近一个月至少认真做过 3 次，且每次都在重复解释同类要求。

步骤 2：写 3 条 Rules

1. 一条边界：不能怎样
2. 一条风格 / 角色：希望它怎样协作
3. 一条输出契约：结果必须怎样

步骤 3：沉淀 1 个 Skill

先按基础四条标准写齐：

• 单一职责
• 可被自动识别（description 写清触发场景）
• 输入 / 输出清晰
• 至少 1 个人工确认点

有余力再补进阶项：团队私有约定、能做/要问/别碰、标准示例、交付前检查清单。

可先去 SkillHub 找接近的 Skill 改造；找不到再从历史会话里自己沉淀。

步骤 4：跑两次真任务

第一次找漏洞，第二次验证是否真的减少了沟通轮次。

步骤 5：只有稳定了，再考虑串联第二个 Skill

本周不要学更多概念。把你最重复的 1 个任务，沉淀成 1 个 Skill + 3 条 Rules。

---

写在最后

你可以只带走这几条：

1. 会用 AI，下一步是会搭自己的 AI 工作流。
2. AI 擅长当下接龙，不擅长自己记最佳路径。
3. Rules 定边界，Skills 定路径，知识库定依据。
4. 好 Skill 只写 Agent 不知道的事；只做一件事，且能被自动识别。
5. 按风险调管控：危险操作收紧，创造性任务放手。
6. 画好能做 / 要问 / 别碰；交活前过质检门。
7. 人负责定义，AI 负责执行。
8. 只要你开始追问「如何减少重复劳动」，工作流就会长出来。

只要想把重复劳动交出去，总会找到适合自己的 AI 工作流。动手之前，先问自己一句：

这件事，怎样才能少让我反复参与？

---

附录：术语速查

• Rules：长期生效的约束与标准（边界、人格、格式）
• Skills：按需调用的 SOP / 流程说明
• 知识库 / RAG：可检索的参考资料层
• MCP / 工具：让 AI 连接外部系统的能力插件
• 意图路由（通常内置）：Agent 根据用户意图自动匹配并加载 Skill 的能力；一般不必单独创建 Router Skill，把各 Skill 的触发条件写清楚即可
• skill-creator：用于创建与修改 Skill 的元技能
• Human-in-the-loop：流程中的人工确认节点
• Context Window：单次对话可有效利用的上下文容量
• SkillHub：https://skillhub.cn/skills