⚡ 常用 Workflow 指南
效率工具 Workflow把重复的操作固化成工作流，收益不在「少打几个字」，而在把判断从每次现想变成一次想清楚。本文讲三件事：哪些任务值得固化、固化到哪种载体、以及本仓库正在跑的一套实例。
一、什么任务值得固化
不是所有重复操作都该写成工作流。判断标准是三条同时成立：
| 条件 | 含义 | 反例 |
|---|---|---|
| 重复发生 | 至少每周一次，或每次都在项目关键路径上 | 一年一次的年度归档 |
| 步骤稳定 | 流程形状固定，变的只是输入 | 每次都要临场决定下一步的探索性任务 |
| 有判断成本 | 步骤里含容易忘、容易做错的决定 | 一条命令就能完成的事 |
第三条最关键。只是「省敲键盘」的话，shell 别名就够了；值得写成工作流的是那些你会忘、会做错、或者需要按情况分支的部分。
⚠️ 固化过早是常见错误
流程还在变的时候写工作流，会把临时决定固化成规则，之后每次都要绕开它。先手工做三五次，等步骤稳定了再固化——这时你也才真正知道哪一步容易出错。
二、三种载体与各自的边界
同一个流程可以固化成三种形态，选错载体会让它难用或失效。
| 载体 | 触发方式 | 适合 | 不适合 |
|---|---|---|---|
| 斜杠命令 | 用户显式输入 /xxx | 用户主动发起、边界清晰的单一任务 | 需要根据上下文自动判断是否适用的 |
| Skill | 模型按描述自行判断加载 | 有分支、需按任务类型路由的复杂流程 | 简单到不值得读一份文档的 |
| 文档约定 | 写在 AGENTS.md / CLAUDE.md | 全局纪律、跨任务一致的规范 | 只在特定任务下才成立的规则 |
💡 判断口诀
「用户知道自己要什么」→ 斜杠命令；「模型需要先判断该做什么」→ Skill；「任何时候都成立」→ 文档约定。
三者可以叠加：文档约定管全局纪律，Skill 管任务路由，斜杠命令做显式入口。
2.1 Skill 的结构分层
流程一旦有分支，就需要分层，否则会变成一份没人读完的长文档。本仓库采用的四层结构：
skills/<name>/
├── SKILL.md # 入口：全局纪律 + 强制加载顺序 + 路由表
├── workflows/ # 步骤：每类任务一个，含该任务需加载的 references
├── references/ # 领域规范：格式、结构、边界，被 workflows 引用
└── assets/ # 可复用模板关键设计是「按需加载」：SKILL.md 只放路由表和纪律，具体步骤和规范按当前任务加载。这样单个任务读到的内容量是可控的，而不是每次都吞下全部规范。
三、本仓库的实例
这套 Skill 目前管着九个工作流，可作为分层设计的完整参考。
3.1 强制加载顺序
SKILL.md 的第一段就规定了顺序，避免跳过路由直接动手：
1. 阅读 workflows/routing.md
2. 为当前任务选择一个主工作流
3. 完整阅读该工作流及其列出的 references
4. 混合任务以主要交付物为主路由，确有需要时再加载一个辅助工作流「只选一个主工作流」是防止规范打架的核心约束——同时套用两套规范，冲突时无从裁决。
3.2 按交付物路由，不按动词
路由表的判断依据是目标路径而非操作类型：
| 目标位置 | 主工作流 |
|---|---|
docs/study-notes/ | 学习笔记 |
docs/research/ | 深度研究 |
docs/references/ | 政策与参考资料 |
docs/public/pages/ | HTML 页面 |
docs/.vitepress/、主题、侧边栏 | 站点维护 |
「新增」和「编辑」用同一个工作流——决定规范的是内容落在哪里，不是你要做什么操作。这条看似简单，却避免了「新建走一套、修改走另一套」的规范分裂。
3.3 校验编进构建，而非依赖自觉
"docs:build": "npm run docs:build:content && npm run docs:build:vitepress",
"docs:build:content": "npm run docs:check && npm run stats:update && npm run pages:css"四项校验（元数据、内容架构、坏链、格式结构）是 docs:build 的前置依赖——校验不过，构建不进行，部署不会发布。
配合 Git hook 让导航永不过期：
# .husky/pre-commit
npm run sidebar:generate
git add docs/.vitepress/sidebar.generated.js💡 这是整套设计里收益最高的一条
「记得跑一下检查」在个人项目里必然失效。 把校验变成构建的前置依赖、把生成变成提交的副作用，才是可靠的。详见 VitePress 知识库工程实践。
四、通用工作流模式
以下几条不依赖特定项目，可直接迁移。
4.1 Smart Commit：生成但不执行
带 RAG 的智能提交，根据文件变更和历史风格生成提交信息。
smart-commit —— 带 RAG 的智能提交
# 工作流程
1. 运行 `git status` 获取当前状态
2. 运行 `git diff` 查看更改
3. 运行 `git log -5 --oneline` 分析历史风格
4. 生成 3 个推荐的提交信息并展示给用户
5. **不要** 执行 `git add` 或 `git commit`，等待用户手动操作第 5 步是这个工作流的灵魂。读取历史风格（第 3 步）让生成的信息与仓库既有风格一致；而把执行权留给用户，则确保不会有意料之外的提交。
「AI 生成、人类执行」适用于一切不可逆操作——提交、推送、删除、部署。生成的成本低、纠错容易；执行的代价高、回滚麻烦。
4.2 时效性核查：不凭记忆写易变事实
涉及型号、价格、版本号、API 参数时，模型的训练数据必然滞后，凭记忆写出的内容看起来合理但可能已经作废。
# 工作流程
1. 识别请求中的易变事实（模型名、定价、版本、退役日期）
2. 对每一类，先查权威来源——官方文档 > 官方仓库 > 检索
3. 写入时标注快照日期与来源链接
4. 把易腐的硬数字转为不会过期的结构（比例关系、判断方法）第 4 步是最容易被忽略的。与其写「输入 $5/M」，不如同时写「输出通常是输入的 5 倍左右，缓存读取约 10%，批处理 5 折」——单价会变，比例关系不会。
4.3 结论验证：先量化再下判断
处理「我觉得 X 有问题」这类模糊反馈时，直接照做容易改错方向。
# 工作流程
1. 把主观描述转成可测量的指标
2. 跑一遍实际数据，看问题是否成立、规模多大
3. 若与初始判断不符，说明差异并给出修正后的方案
4. 改动后用同一指标复测举例：「字号不统一」→ 统计出 44 处声明用了 31 个取值、其中 13 档挤在 0.72–0.96rem 区间且相邻仅差 0.16px。有了数字，才知道该建阶梯而不是逐个微调。
4.4 外部项目精读：分离方法论与实现细节
把开源项目或课程转成笔记时，最大的陷阱是照抄结构——源项目的章节顺序服务于教学，不服务于日后检索。
# 工作流程
1. 先确认时效性：仓库最后提交时间、依赖的版本是否已退役
2. 通读后按「问题 → 机制 → 权衡」重组，而非按原章节顺序
3. 分出两类内容：方法论内核（长期有效）与实现细节（会过期）
4. 对已失效的部分，给出当前替代方案而非保留对照
5. 标注证据边界：哪些是原文事实、哪些是自己的推断第 3 步是核心——方法论和 API 细节的保鲜期差一个数量级，混在一起会导致整篇笔记被一起判定为过时。
五、反模式
| 反模式 | 后果 | 改法 |
|---|---|---|
| 把探索性任务写成固定步骤 | 每次都要绕开不适用的步骤 | 只固化稳定部分，其余留给判断 |
| 一个工作流覆盖所有情况 | 分支爆炸，没人读得完 | 拆成多个，用路由表分发 |
| 规范写在多处 | 冲突时无从裁决 | 单一入口，其余只做指针 |
| 工作流里塞满代码片段 | 与实现耦合，代码一改就失效 | 只写判断依据，实现交给现场 |
| 建好就不再回顾 | 流程早已变化，工作流仍在误导 | 每次发现绕开某一步，就是修订信号 |
📚 外部 Workflow 库
需要更多通用或特定工作流时，可参考：
| 资源 | 说明 |
|---|---|
| Anthropic Agent Skills | 官方 Skills 仓库，含文档操作、搜索等能力扩展 |
| Superpowers Skills | 大量可直接使用的 Agent Skills 与流程编排 |
| Fission AI OpenSpec | 规范化的 AI 交互与 Workflow 定义参考 |
| OpenAI Agents SDK | 轻量级多智能体编排框架 |
| Awesome LLM Apps | 各类实战导向的 AI Agent 集合 |
| Agno | Agent 框架，提供开箱即用的模版与 Toolkit |
站内相关：AI Agent 完全指南 · AI Skills 与 Function Calling · learn-claude-code 精读 · VitePress 知识库工程实践