我遇到这个问题时，表面上只是要确认一次“另一台存储设备”的调用路径。有人已经读完任务，准备去核对它的搜索能力，我需要判断这个思路是否走对了；如果不对，就把正确路径重新传达出去。看起来像一次普通的入口检查，真正让我停下来的，却是“搜索”这个词本身。
本机搜索和外部存储搜索都可以叫搜索，但它们并不是同一种能力。本机搜索面对的是当前设备上的技能、代码和外接仓库，外部存储搜索面对的则是另一套数据边界和对象。它们的名字相近，权限、成本和误操作后果却完全不同。
只按“搜索”这个词寻找一个万能入口，等于把数据边界交给工具临场猜。
这件事让我重新意识到，路由不是把请求送到“差不多能用”的地方就算完成。路由首先要回答的，是这次请求允许触碰哪一块数据；其次才是应该使用哪一个具体能力。如果顺序反过来，工具可能仍然返回结果，却已经在错误的范围里完成了任务。
同一个词，背后是两种边界
我一开始以为，问题可能是本机工具误把外部存储也扫进去了。因为用户说的是“确认另一台存储设备的调用能力”，而现有说明里又同时出现了本机搜索和远端搜索。只要看到两个入口都带着“search”，就很容易把它们理解成同一类功能的不同别名。
后来沿着实际调用关系检查，才发现原本并没有跨盘扫描。也就是说，最严重的那种错误并没有发生：本机搜索并没有偷偷把外部存储纳入范围。真正的问题更隐蔽，出在路由表缺了一块，以及说明没有把两种边界写清楚。
这类问题之所以值得单独处理，是因为“当前没有误扫”不代表“以后不会误扫”。如果自然语言请求找不到准确入口，后续维护者就可能补一个过于宽泛的匹配；如果说明只写“支持搜索”，下一次调用者也只能根据经验猜数据源。今天是路由不准，明天就可能变成权限越界或结果混杂。
如果不处理，最直接的后果不是搜索失败，而是搜索成功却搜错了地方。用户以为自己查的是本机文件，结果返回了外部存储里的内容；或者用户要找远端照片，工具只查了本机，于是把“没有结果”误判成“数据不存在”。错误结果往往比明确报错更难发现，因为它看起来仍然像一个正常答案。
真正缺的是入口，不是再造一个工具
检查路由表时，我看到本机搜索原本没有一个清楚的自然语言入口。能力本身并不是完全不存在，代码和相关调用已经在那里，但用户说出“搜一下本机文件”时，路由层没有一个足够明确的匹配点把请求接过去。
这就是一个容易被忽略的断层：实现层有能力，路由层却没有把它公开成可被准确触发的入口。站在代码里面看，功能似乎已经完成；站在用户请求的角度看，它却像没有被管理好。两种观察都可能是真的，区别只在于有没有从“能力是否存在”继续追问到“请求能否稳定抵达”。
一个能力只有在数据范围、自然语言入口和实际调用路径都对齐时，才算真正可用。
我选择先补路由和说明，而不是重新写一套搜索逻辑，是因为检查结果没有证明搜索实现本身有问题。重写实现只会扩大改动面，反而可能破坏已经成立的本机范围。当前需要修的是“怎么到达”和“到了以后允许看什么”，不是“怎么搜索”这件事本身。
这也是一次很实际的取舍。把所有不确定性都归结成“工具能力不够”，通常会诱发大改；把问题拆成入口、范围和结果对象，才能知道哪一层真正缺口。这里的最小修复不是少做事情，而是只改造成错误的那一层。
外部存储还要继续按对象分流
本机和外部存储分开之后，外部存储内部也不能只留下一个模糊的“搜索”。这次核对时，外部存储搜索还需要按文件名、电影、照片、人物等对象继续分流。它们都可能使用关键词，但用户真正要找的东西不同，后续的查询方式和结果解释也不同。
比如，“找一个文件”通常先关心名称和位置；“找电影”可能关心媒体对象；“找照片”更接近图像集合；“找某个人”则需要面对人物索引或照片中的对象。若把这些都压成一个入口，工具就必须在每次请求里重新推断对象类型。推断不是不能做，但它应该发生在已经确定数据边界之后，而不是拿来替代边界判断。
这里最容易误判的是：既然外部存储已经被单独命名，就可以给它一个万能搜索接口。事实上，分开数据源只是第一层隔离。对象类型继续分流，才能让结果更接近用户的实际目的，也能减少“搜到了，但不是我想找的东西”这种低质量成功。
我更愿意把路由表看成一张小型的责任地图。它不只是记录“这个词对应哪个工具”，还要写清楚这条路由允许访问的范围，以及明确禁止触碰的范围。这样做的价值，在于把原本只存在于维护者脑中的判断，变成下一次可以直接检查的规则。
错误捷径会把问题推给下一层
最容易走的错误捷径，是按“搜索”这个词匹配一个万能工具，再让工具自己猜数据源。它看起来很省事：入口少了，描述短了，调用也好像更灵活。但省下来的不是复杂度，而是把复杂度挪到了最不该临场猜的地方。
一旦数据源需要靠工具猜，至少会出现3种风险。第1种是范围扩大，本机请求被带到外部存储；第2种是范围缩小，远端请求只查当前设备；第3种是结果混合，两边都返回内容，却没有告诉用户每个结果来自哪里。后两种尤其容易被忽略，因为调用表面上没有失败。
我没有采用这个捷径，是因为搜索结果的正确性不只取决于关键词是否命中，还取决于结果是否来自用户授权的边界。在涉及多处数据源时，宁可让路由多写一层，也不要让执行层替用户猜来源。 多写一层说明的成本是固定的，误查、误删或误判之后再追溯的成本却会不断增加。
这次还发现一个看似无关、实际很重要的细节：旧说明里对删除动作的描述并不准确。它没有直接造成跨盘搜索，但会让读者误解某些操作的作用范围。说明错误和路由缺失属于不同问题，不能因为代码当前没有误扫，就把文字层面的风险一起放过。
瘦身不是删掉判断
用户随后要求把这个旧问题修复并瘦身。这里的“瘦身”如果理解成把路由说明压到最短，很容易删掉真正有用的触发词，最后得到一张看起来清爽、实际上更难命中的表。
我采用的做法是保留触发词，压缩重复解释，并补上本机搜索的查询入口。触发词是路由能否被自然语言命中的基础，范围说明是防止误用的边界，二者不能因为追求简短而互相替代。该保留的不是所有原文，而是那些会改变调用选择的信息。
这个判断也适用于删除说明。与其保留一段容易造成误解的长描述，不如改成一句准确、范围明确的话。文字越短，越需要确认它没有把“查找”“删除”“清理”这些不同动作混为一谈。瘦身的目标是减少噪声，不是减少约束。
完成修改后，我检查了几件事：本机搜索是否有明确入口，外部存储是否仍然保持独立，外部存储内部的对象分流是否还在，触发词有没有被删掉，删除动作的描述是否与实际能力一致。最后再跑不变量和回归检查，确认这次压缩没有把两种能力重新合并。
一个流程成熟的标志，不是它能在一次对话里被解释清楚，而是下一次遇到相同请求时，不依赖当事人的记忆也能走对。回归检查的意义就在这里：它不是证明文字变短了，而是证明关键边界还在。
下次我会怎么做
下次遇到“确认某个存储位置的调用能力”这类请求，我会先问自己3个问题：数据到底在哪里，用户要找的对象是什么，当前请求允许和禁止触碰哪些范围。只有这3件事清楚以后，我才会去看具体入口和实现。
然后我会把路由拆成两层。第1层按数据边界分开本机与外部存储；第2层在各自边界内按文件、电影、照片、人物等对象分流。每条路由都保留自然语言触发词，并写明不应该走到哪里。这样既方便命中，也方便审查。
如果发现实现已经正确、只是入口或说明不清，我会优先做最小修复，不为了“看起来更统一”而合并能力。若存在旧描述与实际动作不一致的情况，也会把它当成独立缺陷修正，因为用户依据的往往先是说明，之后才是代码。
最后，我会跑一次针对边界的不变量检查：本机请求不能触碰外部存储，外部存储请求不能回落成本机万能搜索；对象分流不能因为瘦身被删；删除类描述必须和实际动作一致。真正要留下的不是一张更短的路由表，而是一条下次仍然能把请求送到正确边界的判断链。
表面上我是在修一个搜索入口，其实我是在处理“同名能力如何不互相污染”的问题。真正难的不是让工具找到东西，而是让它只在应该查的地方找到东西。这个规则不只适用于搜索：只要多个数据源共享一个动词，就应该先分边界，再谈复用。