查找替换应让用户先看到命中了哪里，再决定改多少。明确当前选区或整篇正文的范围，区分当前命中与其他命中，分别提供替换当前项和全部替换；批量修改前展示数量及关键上下文，完成后可恢复这次操作。没有找到内容、部分内容只读和结果正在更新，要用不同反馈。
知识库管理员想把一段项目说明中的“成员”改成“项目成员”，但全文还含有“成员管理”“非项目成员”和引用代码。先用Pixso的原型预览演示查找、跳过和替换，比仅画两个输入框更能暴露误改范围。
打开面板时，先解释当前作用范围
用户选中一段文字再打开查找，通常会期待只处理该段；从菜单直接打开，则可能期待搜索整篇。产品可以采用不同默认值，但当前范围必须在面板中持续可见，例如“在当前选区查找”或“整篇正文”。不能只用一个没有文字提示的小图标表示作用范围。
本例选区只有“项目介绍”小节，正文其他小节暂不参与。面板打开后仍以浅色边界标出选区，用户切到全文时清楚看到范围变化。关闭查找面板不应丢失原编辑光标；点击其他位置继续写作后，再打开面板要重新判断是否仍有有效选区，不能沿用一块已经不在当前视野中的旧范围。
查找对象也有边界：正文、标题、表格单元格、图片说明、链接目标、评论和代码块不是同一种内容。本例查找可见正文与表格文字，不直接替换链接地址和代码。界面可简洁标为“正文内容”，具体包含项在需要时展开；不把一项看似普通的术语修改扩大成内部URL修改。
VS Code的基础编辑文档将查找范围、匹配选项以及替换区分为独立能力。自己的编辑器同样需要明确这些条件，而不是复制图标后假定用户能够推断作用范围。
命中数量要和可见高亮对应
在查找框输入“成员”后，正文中的每个匹配都可以高亮，当前正在处理的一项则使用更明显的轮廓。面板显示“第2项，共6项”，上下一个命中负责跳转，不负责执行替换。到最后一项再次点击下一项时，若回到第一项，用简短提示说明已经回到开头。
“成员管理”里的成员属于字串匹配，“非项目成员”里的成员同样会被命中。是否替换它们是语义判断，不能靠高亮颜色替用户决定。本例管理员要处理特定段落中的独立称呼，因此应先缩小范围，再逐项查看上下文；直接全文替换可能产生“非项目项目成员”这样的错误。
对于中文，不要把英文的“整词匹配”图标当作无需解释的万能规则。中文词边界如何识别取决于实现；支持什么就准确命名，必要时提供例子。如果业务只做普通字串查找，就不画一个看似支持语义分词的选项。正则表达式也属于进阶能力，只有真正支持并有错误提示时才开放。
找到内容后可滚动定位，但不要把输入焦点从查找框抢走。用户仍可能继续输入词语。匹配很多时可以延迟高亮更新以保持响应，但需避免旧数量冒充新查询的结果；查找框已经是“项目成员”，正文却仍高亮“成员”时，应明确处于更新中。
逐项替换与全部替换，用不同反馈承担风险
替换当前项适合逐条判断语境。按钮可以直接写“替换此处”，执行后移动到下一处原始匹配，并让刚修改位置短暂可辨。若替换词本身仍含查找词，不能立刻重新命中刚改出的内容而陷入循环。本例“成员”改为“项目成员”后，继续查找应按约定跳过刚完成的匹配。
全部替换适合范围明确且表达一致的内容。先给出“当前选区内6处将替换”的说明；重要文档或跨度较大时，提供上下文预览。预览不是再显示一遍搜索词，而是让用户看出原句和改后句，发现词组被误伤。只读片段与可替换内容分别计数，不能显示6处却实际只改4处而无说明。
在Pixso画布上放两个大画板：左边是带查找面板的知识库原文，右边是替换预览。两边只使用“成员加入项目”“成员管理”“非项目成员”三个短句，逐条展示对应结果，并把不准备修改的项保留为未选。这样一眼就能讨论哪些命中应该跳过，而不必在密集的假文档里找差别。
批量处理结束后，反馈准确说明“已替换4处，2处未修改”，并给出未修改的原因或位置。用户手动排除的命中不叫失败；只读限制与内容在操作前被他人修改，则分别说明。结果文案应沿用前面同一统计口径。
撤销恢复的是这一批改动，不是整个文档
管理员执行全部替换后，发现选区仍然太大。一次撤销应恢复本次替换涉及的内容，同时保留此前已经写好的其他段落。不要为了实现简单，重新加载一份较早的完整文档，顺带丢掉用户此前的修改。
如果执行替换后又打了几个字，编辑器的撤销顺序需要与普通编辑一致。常规撤销可以先撤销后来输入，再撤销批量替换；专门的“恢复本次替换”若允许跨过后续编辑，则必须有真实的冲突处理，不能无声覆盖后续内容。本例只采用常规编辑历史，不额外承诺越过新修改的独立回滚。
多人同时编辑时，预览与执行之间的内容可能变化。执行前应基于仍有效的命中位置重新确认，不能按旧字符下标替换另一段文字。遇到变化可列出未执行的项目，让管理员刷新预览；“替换完成”只描述真正改动的范围，不把冲突项藏在统一成功状态里。
替换成空文字等同于删除匹配内容，面板要容许这个合法目标，但清楚表达结果。查找内容为空时则不发起全文匹配，也不让全部替换成为一个危险的可点击动作。两边输入框看似对称，语义约束并不相同。
查找面板不应挡住正在修改的那句话
桌面可以采用侧栏或紧凑浮层，正文滚动时留出当前命中的可见空间。若浮层总盖住右上角第一处命中，用户只能不断关闭面板确认结果，工作流就被破坏。手机可用底部面板，但键盘弹出后仍需要保留一句上下文和下一项按钮。
关闭面板后恢复到合理的编辑位置：只查找未修改时，可留在最后查看的位置；执行替换后，光标与选区按约定回到修改处。保存文档与替换内容是不同动作，编辑器原有的保存状态仍需持续可见，不能用“替换完成”暗示内容已成功同步到服务器。
最终交付最值得保留的是一组原句与预期结果：哪处替换、哪处跳过、哪处只读、撤销后应恢复什么。它比单列“支持查找替换”更能约束实现。用户看到的数量、正文变化和恢复结果使用同一组样例，才有可能放心使用全部替换。
