Path Simulation — verify your skill / workflow / tutorial by walking real user paths, not just checking structure.
写完/改完 skill、workflow、教程后，选一条真实用户指令模拟执行一遍，找出会卡住的地方。静态检查信文档，路径模拟信执行。
一个自检方法论，解决一个具体问题：
你用 AI 写完一套流程（skill / workflow / 教程步骤 / 提示词规范），怎么知道它真的能用？
常规做法是"检查格式、检查结构"——段落完整、步骤齐全、没写错字，就觉得没问题。
但结构完整 ≠ 走得通。
路径模拟的方法是：选一条用户可能说的真实指令，沿着你的流程一步一步假装走一遍，走到哪一步会发现——
- 卡住：这一步没有输入，或输入和上一步输出对不上
- 歧义：需要读者自己猜，规范没说清
- 缺失：某个分支没覆盖
这些问题只在"真的走"时暴露。走完发现问题 → 改 → 换一条路径再走 → 直到再走一条新路径不再发现新问题为止。
过去写文档，读者是人类——他们会自己脑补缺漏，能看懂大概意思。
现在写流程（尤其给 AI 用的 skill、提示词、workflow），执行者是逐字执行的 agent：你写"第 2 步检查文件"，但第 2 步需要的输入在第 3 步才产生——人类读者会绕过去，agent 会卡死在原地。
这套方法就是在实战中摔出来的：写完一个 skill，静态检查全过，一执行就卡。后来发现所有问题都有一个共同点——没走一遍。
| 静态检查 | 路径模拟 | |
|---|---|---|
| 相信什么 | 文档写清楚了 | 真的走一遍才信 |
| 查什么 | 结构、格式、单点 | 流程、触发条件、输入输出、断链 |
| 怎么查 | 读 | 走 |
| 成本 | 低 | 更低（零成本，脑子里走） |
| 发现率 | 结构问题 | 流程问题（大部分坑在这） |
诚实定位：路径模拟是廉价广覆盖的 flow 走查启发式（heuristic），不是完备的验证学。它能发现大部分流程问题，剩下的交给真实测试。「再走一条新路径不再发现问题」是合理的停止点（satisficing），不保证「覆盖完整」。
至少走 3 条不同路径，且必须覆盖：标准路径 + 至少 1 条风险路径（异常 #6 / 跨文件 #7 优先）。
跳过/中断/反悔/分批本质都是「用户不按线性走」的同类扰动，只走它们会漏掉正交的高风险轴。异常（输入缺失/环境不满足）和跨文件（文件间矛盾）才是真正容易爆的两条轴。
| # | 路径 | 典型用户话术 |
|---|---|---|
| 1 | 标准路径 | 「帮我做 X」 |
| 2 | 跳过路径 | 「直接给我结果，不用检查」 |
| 3 | 分批路径 | 「先做 A」「顺便记一下 B」「继续 A」 |
| 4 | 中断路径 | 「等一下，先处理这个」 |
| 5 | 反悔路径 | 「那条别删」「恢复刚才改的」 |
| 6 | 异常路径 | 「文件不存在」「没装依赖」 |
| 7 | 跨文件路径 | 检查参考文件之间是否矛盾 |
- 选一条用户指令作为入口——从实际用户会说的话里选，不自己编；入口无效（文件/路径不存在）→ 提示重选，不进入走查
- 循环走至少 3 条路径（标准 + 至少 1 条风险路径）——每步问：「这一步的输入从哪来？第一次用的用户能看懂吗？」
- 记录每个问题——哪步卡、为什么卡、建议怎么修
- 汇总报告给使用者——全部路径走完，统一展示问题清单（含严重度：阻断 > 一般 > 建议），不直接动手修
- 询问后执行修复——「修」/「只修 X」/「都不修」，确认后才动手；「问题」可能是作者故意设计，直接修 = 替作者做设计决定
- 修完换路径重走——验证已修条目 + 找新路径的新问题
- 沉淀新坑（可选）——回写进被测试 skill 的陷阱表/常见坑表（必须先询问使用者；第三方/共享 skill 默认只报告不写入；一律进 references/，不写进 SKILL.md 正文——坑表是给修改者看的，不是给使用者看的）
- 停下来的标准——直到再走一条新路径不再发现新问题；含多个参考文件时，停止前必须至少走一次跨文件路径
对 AI 助手说：
「用路径模拟自检一下这个 skill，至少走标准 + 异常/跨文件三条路径，输出问题清单和修复建议」
「我刚改完 workflow，帮我走一遍路径模拟，输出问题清单和修复建议」
报告按模板输出，含严重度排序和走查轨迹：
- 严重度：阻断（主干路径卡死 / 必出错）> 一般（分支歧义 / 偶发卡顿）> 建议（优化项）。按爆炸半径排序，先报阻断
- 走查轨迹：每条路径必填「走到第 X 步，第 Y 步判断无卡点」——无问题的路径也要留痕，防漏走、可复盘
完整模板见 references/report-template.md；一次完整走查长啥样（含闭环：发现→确认→修复→重走→停止）见 references/walkthrough.md。
| 坑 | 表现 | 修法 |
|---|---|---|
| 时序错位 | 检查/确认类步骤排在写入/分发之后，等于没查 | 检查步骤必须排在对应写入之前。写完再查的「检查」是装饰 |
| 跨文件矛盾 | 每条路径都走通，但相关文件之间互相矛盾 | 走完路径后专门做一次跨文件一致性检查 |
| 异常表误导 | 异常处理表声称「A 正常」，但真实路径下 A 也出错 | 异常表描述必须来自实测；重走时专门验证异常表里的"正常"声明 |
| 主体可移除 | 去掉某个角色/步骤，流程依然成立 | 说明它是装饰——移除，或让它承担真功能 |
| 方法论误移 | 问题不是"实现错误"，是整套方法论不匹配内容域 | 修的不是步骤，是 workflow 本身的设计前提（见「方法论审查三问」） |
| 坑 | 表现 | 修法 |
|---|---|---|
| 静态审查通过就信了 | 结构完整就认为没问题 | 必须走一遍，至少 3 条路径（含标准 + 至少 1 条风险路径） |
| 只走一条路径 | 标准路径通关就收工 | 换入口再走 |
| 走一遍没问题就停 | 第一次走通就完成 | "没发现问题"不是终点，再换路径 |
| 自检清单代替路径模拟 | 以为逐项打勾就够了 | 清单查单点，模拟查流程，两者缺一不可 |
| 测试域污染 | 模拟时用了领域外例子 | 所有测试案例必须来自被测试的同一领域 |
| 未报告就修复 | 发现问题没先汇总就自动修 | 先出问题清单，使用者确认后才修 |
| 擅自回写陷阱表 | 发现坑后没问使用者就写进被测试 skill | 回写有副作用，必须先问；第三方/共享 skill 默认只报告 |
| 回写进 SKILL.md 正文 | 坑表写进主文件，使用 skill 时加载维护向内容 | 一律回写进 references/，主文件只留引用 |
| 只修当下不沉淀 | 修完就停，新坑没进陷阱表 | 修完询问是否回写；已有表先查重 |
| 部分修复后重复询问 | 只修了部分，重走时未修的坑又冒出来被再问 | 标「使用者选择不修（原问题 #N）」，不重复询问 |
| 拆分后引用断链 | 章节拆到 references/ 后主文件仍引用已不存在的章节 | 拆分/重构后必走跨文件路径，检查「第 X 步」类编号引用 |
路径模拟抓「实现错误」；但当多条路径反复卡在同一处（即使修复后重走仍卡）、或问题清单混入「这个流程该不该存在」的疑问时——停下走查，切换设计层审查：
- 这东西该做成 workflow/skill 吗？——有没有更轻的载体？（FAQ / 参考文档 / 自检清单可能更合适）
- 目标用户真的是「走步骤」的人吗？——如果用户只会「直接给我结果」，步骤式设计本身就是错位
- 有没有更合适的现有方案？——重复造轮子 = 方法论误移
三问后仍要 workflow → 继续路径模拟；不要 → 记录「方法论不匹配」为独立审查项，回到定位重新设计。
适合：
- ✅ 写了 skill / workflow / 教程 / 操作手册，想确认真的能用
- ✅ 用 AI 写自动化流程、提示词规范的人
- ✅ 被"静态检查全过、一执行就卡"坑过的人
不适合：
- ❌ 纯知识类内容（百科条目、观点文章——没有执行步骤，静态检查够了）
- ❌ 只给别人读、不给人执行的文档
判定示例（边界靠例子才具体）：
| 被测对象 | 判定 |
|---|---|
| skill：用户提供 epub → 得到拆解文档 | ✅ 走路径模拟（有 A→B 流程 + 多入口） |
| 观点文章（纯知识） | ❌ 静态检查够 |
| API 参考文档（只查不操作） | ❌ 静态检查够 |
| 自动化脚本：输入 → 清理 → 输出 | ✅ 走路径模拟（异常路径需验证） |
| 提示词模板：填字段 → 生成 | ✅ 走路径模拟（跳过字段/空值都是路径） |
| Obsidian 工作流：新建 → 命名 → 归档 | ✅ 走路径模拟（有中间状态：改名/反悔/覆盖） |
references/path-types.md— 7 条标准路径清单（选入口时查）references/report-template.md— 产出物报告模板（含严重度 + 走查轨迹）references/faq.md— 常见问题（脑走查盲点、satisficing 停止点、人类 vs agent 怎么走）references/walkthrough.md— 真实走查范例（主案例完整闭环 + 附加案例 user-owned 报告态）
彬少 —— 一个什么都折腾一下的人：装系统 · 玩AI · 搭知识库 · 做设计。这套 Skill 是我自己在用的，用来检查自己写的 skill / workflow 是不是真能跑通。
微信公众号 「宝藏彬少」：折腾，是为了更好用。欢迎关注交流。