【论术】模糊搜索实现-提示词

人们总是低估心智在白日梦和无目的的闲逛之际所获得的成长空间。 ---爱德华·威尔逊-

ai是一把刀，厨子把它当作美食工具，凶手把它当成凶器。

为了实现一个模糊查询的功能，所以尝试使了下提示词来实现，之前花很久才实现的功能，不到五分钟就实现，这就是ai的实力。由此可见，大概理解业务需求本身才是保存开发者的桎梏，而功能实现则可以交给ai了。
想要让ai实现称心如意，抛却所有高大上的东西，本质上就是三步：资源，目标，边界

1. 资源
   可以理解成你想做成一件事时当时的条件，不要直接上来说，实现xxx的功能，ai初始化时是惰性的，也不要指望它有多贴心，有时候的贴心反而是误导，对于软件工程来说，不确定性就是最大的问题，为了使其可控的知道它要做的事，根本原则就是给它可用的资源，想要实现某个功能，要先让它分析当前的现状，这一步必不可少，防止它为了实现而不管不顾，提前让它预知现状是当下ai能力下的最优解，总而就是一句话，想让它实现一件事，先让它深刻了解现状

2. 目标
   目标越详细，ai实现的越精细，如果写的越少，ai对prompt是敏感的，词句写的越少，不确定性概率越大，生成的代码质量就越差，与心中预想的目的就越远，为了实现目标，其实越繁琐越好，最好分步骤，其实可以在这一步将其作为一个新手，分步骤，每一步的目的是什么，它应该展示什么或者实现什么，最后在结束时再简述一下，如果不放心，还可以让它再输出一下刚刚对话的关键实现点【注意：这是杀手锏】，这一步是为了让它知道它接下来要基于现状实现什么，越啰嗦，越有可能实现的更完善。

3.边界
人最大的自由不是想做什么就做什么，而是不想做什么就可以不做什么。
ai不行，我们不允许ai想做什么就做什么，也不允许ai不想做什么就不做什么
这一步其实比目标更重要，目标实现不了，可以分批次多步骤，甚至可以换个新对话甚至换个模型乃至换个新的,工具实现，但是边界不行，目标的最坏结果是做不出来，无用功，但是边界不够清晰，则会导致ai乱写，如果是一个刚入项目的新手，在不了解项目现状的情况下贸贸然使用ai改动，则易导致出现不可控的意外情况，所以这一步相比较其它步骤，反而更重要，除非对项目熟悉度高且心中有数，否则在开发时一定要注意给ai提约束，这一步是为了告诉它，你不可以做什么，跟目标一样，也是步骤越多越好，提的越多，最后实现的就越健壮，就越不容易出问题。

以下是例子：

由于这一块比较熟悉，就没有添加边界，但是资源给了，目标设定了，同时也让ai反馈了它要做的事，所以依然发了出来

目标：实现公共页签的模糊查询
q： 三个页签的左侧容器是怎么布局的？ [这一步是为了让ai了解目标所在的容器的环境以及内容]
·a·: balabalabala...
q： 这个公共组件的业务维度之下，全部之上添加一个搜索框，
目的：用于模糊搜索模板列表
数据来源：不走后端，纯粹前端搜索

1. 实时匹配搜索词，如果有搜索词符合，则将匹配项的匹配搜索词标红展示
   不管是叶子节点还是一级节点都要展示二级节点以及对应的叶子节点
   如果清空搜索词后则选中全部并请求全部数据
   如果选中了某一项，执行搜索逻辑

先不要写代码，描述下基于上述逻辑需要实现的东西 [注意，这是目标]

a: 基于你这套现有公共组件（+ 联动），要实现的东西可以拆成下面几块：

要新增的能力
在左侧 业务维度 标题下、全部 行上，新增一个前端搜索输入框。
搜索范围是左侧当前已拉取到的本地数据（/），不走后端接口。
输入时实时过滤（建议防抖可选，逻辑上可实时）。
命中关键词的文本要高亮（标红）展示。
搜索后的展示规则
无搜索词时：展示完整树（全部 + 所有一级分类 + 所有叶子）。
有搜索词时：
如果命中叶子：展示该叶子所属的一级分类，并展示对应叶子（通常只展示命中的叶子即可）。
如果命中一级分类：该一级分类要展示，同时它下面的叶子也要展示（你要求的“一级命中也要展示二级及对应叶子”）。
关键词在一级名、叶子名都要支持模糊匹配（建议统一忽略大小写）。
全部 行始终保留在最上方，方便用户一键回到全量。
选择与联动规则
清空搜索词后：
左侧选中态重置为 全部；
触发右侧“全部数据”请求（即现有 ({ source: "all", ... }) 流程）。
搜索结果中点击任意项（一级/叶子）：
仍走现有“选中 -> 触发筛选 -> 右侧列表刷新”的链路；
只是候选列表来自“搜索结果子集”。
如果当前已选中某项，再输入搜索词：
执行搜索过滤；
若当前选中项仍在结果中，保持选中；
若不在结果中，建议视觉上取消该选中（或回落到 全部，这个可定规则）。
需要改动的核心点（实现层面）
内新增状态：

基于 的
新增文本高亮渲染函数：
把命中片段包裹红色样式节点（仅渲染层处理，不改原始数据）。
调整当前分组展开逻辑：
搜索模式下，命中的分组默认展开（否则用户看不到匹配叶子）。
保持与外部的既有协议不变：
继续通过 向 Txxx 传 /。
你这条需求里建议先确认的细节
一级分类命中时，是否显示该分类下全部叶子，还是仅显示“叶子也命中”的子集。
叶子命中时，是否允许只显示命中的叶子，还是也要带出同组全部叶子。
搜索词清空时是否一定强制触发一次“全部查询”（你描述里是要触发，建议按这个执行）。
如果你认可这个拆分，我下一步就可以按这个逻辑给你落到组件改造方案（再开始写代码）。

q: 1. 一级分类命中时，展示全部叶子
2. 二级分类命中时，所属一级分类的叶子展开时只展示命中的二级分类
3. 搜索词清空时要强制触发一次“全部查询”
4. 注意ui逻辑的善后 【注意，这是对目标的二次完善】

a:收到，这 4 点可以落成一套明确的交互规则。下面我按“最终行为”给你收敛一下，并把你提到的 UI 善后 也补全。

最终搜索行为（按你确认）
一级分类命中
显示该一级分类，展开后展示该分类下全部叶子。

二级叶子命中
显示其所属一级分类，展开后只展示该分类下命中的叶子子集（非命中叶子隐藏）。

搜索词清空
强制回到“全部”选中态，并强制触发一次 source=all 的右侧查询（不能仅改 UI，不触发请求）。

命中文案高亮
一级标题、二级叶子名里命中片段都要标红；未命中部分保持原样。

建议的数据与渲染逻辑
维护 （输入框值）与 。
基于原始 计算 （仅用于渲染）：
分组命中：group.title 命中 -> items = group.items（全量）
分组未命中但叶子有命中：items = matchedItems（子集）
都不命中：过滤掉该分组
全部（总数） 建议在搜索态显示搜索结果总数（更符合预期）；非搜索态显示原总数。
选中与请求联动（重点）
点击“全部”：沿用现有逻辑，触发Change。
点击叶子：沿用现有逻辑，触发 ' 查询。
清空输入时：
重置 activeTab=all / activeLeafId=null / activeGroupKey=null
立即触发一次“全部查询”（避免只重置左侧高亮）。
UI 善后（你提到的重点）
搜索态下分组建议默认展开（否则用户看不到命中叶子）。
若当前选中叶子在新搜索结果中被过滤掉：
仅清理左侧选中高亮，不自动触发查询（避免频繁请求抖动）；
直到用户点击结果项或清空搜索再触发查询。
（如果你希望“过滤掉时立刻回全部并查询”，也可以改成强制回退策略）
无结果时显示空态（例如“未匹配到模板”），但“全部”行仍保留可点。
输入框应有 clear 按钮，清空后行为与手动删空一致（必须触发“全部查询”）。
保持滚动与回到顶部按钮逻辑：
搜索词变化时可回滚到顶部，减少“筛完仍停在底部”的割裂感。
高亮渲染只做展示层处理，不污染原始数据结构。
如果你认可这版规则，我下一步就按这个方案改

q: 执行

上面就是整个流程，希望能给读者一点启发。

以上。