实用教程
用 Claude Opus 5.5 修复商品筛选页的后退恢复
给 Claude Opus 5.5 一组浏览器操作和预期状态，再让它修复筛选恢复。保存一个筛选值只完成了一半：后退、前进、刷新和打开分享链接后，地址栏、已选控件与结果列表必须一致。
给 Claude Opus 5.5 一组浏览器操作和预期状态，再让它修复筛选恢复。保存一个筛选值只完成了一半：后退、前进、刷新和打开分享链接后，地址栏、已选控件与结果列表必须一致。
先说清楚“后退一步”应该回到哪里
先写一份简短的历史行为约定。假设商品目录中，用户应用“蓝色”筛选、进入商品详情、再按后退。此时应回到蓝色商品列表，而不是无筛选的目录。搜索框输入三个字，也不应默认多出三次后退，除非产品明确选择这种行为。
一则 2020 年关于查询参数的开发者提问展示了相反的困扰：每次切换标签页都成了一步历史记录。它说明需要先做交互选择，不代表所有操作都该替换当前记录。
| 操作 | 本例的历史策略 | 预期结果 |
|---|---|---|
| 编辑尚未提交的搜索词 | 只保留本地草稿 | 后退不会逐字回放 |
| 应用一组有意义的筛选 | 新增一条记录 | 后退恢复上一组已应用筛选 |
| 修正默认 URL，不改变意图 | 替换当前记录 | 不产生重复步骤 |
| 打开商品详情 | 正常导航 | 后退回到已筛选列表 |
让 URL 能独立还原状态
使用分类、颜色、排序等公开且不敏感的值，不把客户信息或秘密写入地址。按允许值集合解析参数，提供默认值，并规定同名参数重复时如何处理。修改筛选参数时保留无关的广告参数，不要凭记忆重建整条查询串。
下面这个虚构地址中的颜色与排序足以描述可重现的列表状态：
/products?color=blue&sort=price-asc&utm_source=newsletter定向修改应将 color 改为 green，同时保留 sort 和 utm_source。用 URL 和 URLSearchParams 处理，不要手工拼接字符串。统一编码与解析规则，使刷新和新标签页都能重建状态，而不依赖之前页面的内存。
MDN 的 History API 指南区分了 pushState 新增记录与 replaceState 更新记录。调用它们不会替你完成界面渲染。历史遍历处理必须恢复视图，首条记录也要初始化，否则回到起点可能拿到空状态。已有路由框架时，应使用它支持的导航接口，不要再叠一套相互竞争的历史控制器。
让 Opus 按状态变化修复
修复提供的商品目录筛选恢复问题。输入包括路由版本、筛选组件、URL 解析器、请求逻辑和故障录屏。先梳理当前状态来源以及重复存储。
预期流程：无筛选目录 → 应用蓝色 → 打开商品 → 后退 → 蓝色列表 → 后退 → 无筛选列表 → 前进 → 蓝色列表。搜索草稿不能每输入一个字就新增历史。刷新和分享链接必须还原已应用状态。
保留无关查询参数。为颜色和排序设允许值，明确重复参数和非法值的处理。适用时使用现有路由接口。历史遍历时更新控件和结果，不得再新增历史记录。
处理慢请求，确保旧响应不能覆盖较新的筛选状态。提供清楚的加载和空结果状态，在正确结果出现后有意识地恢复滚动位置。
交付最小补丁和测试表，逐步记录 URL、控件、结果身份和历史位置。未执行浏览器测试不得声称通过；列明缺失的运行条件。这是拟议的 Opus 任务，不是模型实测。官方提示词指南可帮助组织任务，不能证明补丁有效。示例 URL 的解析往返可以本地验证，真实历史和请求行为仍需浏览器测试。
在慢请求下验收恢复
分别测试刚进入详情就后退，以及等待慢响应后再后退。再连续应用蓝色和绿色：即使蓝色请求最后才结束，也不能覆盖绿色结果。可以取消过期请求，或用当前请求标识拒绝旧响应；不要靠冻结全部导航掩盖问题。
**只用 local storage 够吗？** 它能记住偏好，却不能单独定义每条历史记录或分享视图。不要让保存的偏好悄悄覆盖 URL 中明确写出的状态。
**所有筛选都用 replaceState 吗？** 那会删除本例中有意义的中间步骤。先确定产品行为，再选接口。
**这和广告链接检查一样吗？** 不一样。广告链接审查检查目的地和参数，本文检查交互后的状态恢复。
可以在 Panelly Studio制作对应商品创意，再完整测试广告落地页的浏览与返回流程。这里不声称 Panelly 已集成 Opus，也不代表 Panelly 实现了上述虚构商品目录。
