工作流
先让 AI 重现故障，再让它改代码
用失败样例把调查和修复接起来。
资料核验2026.11.12 · 编码助手 · 可用于现有软件仓库
读者说文章链接偶尔打不开，助手看到路由层就准备改 URL 拼接。也许症状只发生在带尾斜杠的地址，也许是旧的静态产物没清掉。先重现一次，能把两条路径区分开。
给 AI 的上下文与边界
给助手一条有尾斜杠和一条无尾斜杠的文章链接，要求先记录请求状态、构建输入和实际文件。对照本地开发服务和静态产物，找到一个能稳定区分两种结果的测试入口再改代码。
给调查一条可判定的起点
要求先列 URL、状态码、当前构建命令和预期。对照正常地址与异常地址，再查路由和实际构建目录。首次交接只需要给出复现步骤与最可能的改动位置。
能写回归用例时，让用例先在旧实现失败。修完后重跑同一路径，再用正常地址做一个对照。
如果始终无法重现，记录尝试过的版本和环境，再补缺失的用户线索。
可以直接照着做的演练
记录 /notes/demo 与 /notes/demo/ 各自的状态、最终地址及页面标题。先在开发服务运行，再在静态托管预览运行。差异应在明确的一层可重复出现，这份矩阵可直接作为修复后的对照。
检查生成结果
- 旧实现稳定失败，新实现用同一请求通过。
- 正常路径仍可访问。
- 回答说清是路由匹配、部署重定向还是旧构建导致。
复查时追问一层
无法复现时，让助手交回尝试过的环境和缺失信息，继续补线索。先做最小调查能减少大范围修改。如果只有线上失败，不要把本地成功当成复现已经解决。
给复现记录加一个正常反例，例如其他文章同样地址形式可读。若只有一个 slug 失败，再检查内容数据、输出文件和部署缓存，避免把个别输入问题修成全站 URL 规则变化。修复后要复跑这个正常反例。
