夜雨聆风AI提效 · 方法论
用 AI 干活的时候，你有没有遇到过这种情况——明明上次已经教会 AI 怎么做了，这次换个场景又来一遍？
问题不在 AI。问题在于我们只教会了它「怎么做」，没教会它「什么才算做好了」。
01 AI 提效的两个前提，缺一不可
最近复盘自己的 AI 工作流，发现一个规律：AI 提效的前提其实只有两个——工具准备度和上下文准备度。
工具准备度，就是你的 AI 助手能不能「直接干活」而不是「先搭脚手架」。有现成的 Skill 封装，一条命令搞定，是最高等级。只能靠基础能力临时组装，是中等等级。连工具都要从头造，是最低等级。
上下文准备度，就是 AI 助手启动时「脑子里有多少东西」。最好的情况是它有精确的 API 端点和参数格式，最差的情况是连页面是什么结构都要当场摸索。
好工具 × 好上下文 = 分钟级交付差工具 × 差上下文 = 小时级摸索
02 工具的三个等级，差距是数量级的
以我最近两周的实战经验来看，工具准备度可以分三级：
L3 开箱即用
有现成 Skill，一条命令出结果。比如：用 xiewen-data 查订单数据，3 步完成。
L2 需要组装
有基础能力但需拼装流程。比如：用 CDP 控制浏览器 + 调 API 发公众号文章。
L1 从零搭建
没有工具支撑，先要造工具。比如：为新的 AI 平台创建 Skill、搭建开发环境。
L3 和 L1 之间的效率差距不是 2 倍 3 倍，是数量级差距。L1 任务中，80% 的时间花在「让工具能工作」上，只有 20% 花在完成业务目标上。L3 正好相反。
03 上下文有四层，越往上越值钱
上下文的准备度可以看成一个金字塔：
第四层 ⬆
踩坑经验 — 什么会失败、为什么如：OWL 不支持中文别名、公众号 UI 保存会被拦截
第三层
接口/参数 — API 端点、请求格式、认证方式如：operate_appmsg?sub=create 的 FormData 参数
第二层
业务规则/口径 — 数据口径、字段含义如：付费订单的口径是 status="paid"
第一层
项目结构/路径 — 仓库在哪、哪个脚本如：LobsterAI 在 /Users/.../Vincent/LobsterAI
绝大多数 AI 助手的基础配置在这一层就够用了。真正的效率瓶颈在上面两层——接口细节和踩坑经验。这两层的信息往往是一次性试错得来的，如果没记下来，下次还得重新试。
04 好了，那什么算「准备好了」？—— 三层验收框架
工具和上下文有没有准备好，不是靠感觉。我总结了一个三层验收框架，每次做完一个非重复性任务都可以对照检查。这是可以直接拿去用的：
第一层：功能验收 — 「能不能跑通」
不要只验「快乐路径」，要验「异常路径」。异常路径才是第一次做任务时消耗 80% 时间的地方。
快乐路径（必须通过）：正常输入 → 正常输出；输出格式符合预期。
异常路径（至少覆盖 3 个）：空输入不崩溃、认证失效能报错、网络超时有重试、输入过大能分片。
第二层：鲁棒性验收 — 「换个场景还能用吗」
功能过了不代表换个场景还能用。有一个简单检验标准：一个新同事拿着你的 Skill，只改输入参数、不读源码，能在 3 种不同场景下跑通吗？
输入变化：空输入、超大量输入、格式异常输入。
环境变化：首次运行、恢复运行、权限受限。
数据变化：NULL、零值、超长字符串等边界情况。
第三层：可演进验收 — 「下次能不能更快」
最容易跳过、但最拉开长期差距的一层。每次任务做完，问自己三个问题。
① 这次发现了什么新知识？→ 写入了哪个文件？
② 这次踩了什么新坑？→ 记入了哪个 pitfalls 文件？
③ 对应的 Skill 需要更新吗？→ 更新了什么？
三个都能回答，这次任务才算真正完成了——不只是产出交付了，能力也沉淀了。
AI 提效的本质不是让 AI 更聪明，而是让它在干活之前，手上的工具和脑子里的上下文都已经到位了。而「到位」这件事，不是靠感觉，是靠一层一层验出来的。
— AI启辰 · AI提效方法论