Corey Rosamond · 2026/10/4 · 约 6 分钟阅读
本文为英文原文的简体中文译文。资料和事件日期保留原文发表时的语境；代码示例保持原样。 Read in English
如果我聘请一位资深开发者，我希望他能劝我放弃一部分开发工作。一份接受所有功能要求、遇到每个问题都增加一项服务的方案，看起来可能很周全，却也可能让企业背上昂贵的运维负担。
所以，Laravel 最近的一篇工程文章引起了我的注意。它介绍了一项实用的技术决定：删掉团队刚刚做出来的东西。这种决定，通常没有发布新功能那么引人注目。
他们删掉了什么
在 9 月 3 日介绍 Laravel Boost 项目规则的文章中，Pushpak Chhajed 讲述了自己构建语义搜索层、五天后又将其移除的经历。对于一小批项目约定，普通 Markdown 文件、自动生成的索引和文本搜索更合适。作者表示，在探索性测试中，规则查找变得更稳定，同时明确指出，仍然需要受控对比来验证。
这只是针对其中一个功能的决定。Boost 独立的文档搜索仍然使用向量嵌入。同一款产品，完全可以在一个地方使用复杂的搜索系统，在另一个地方使用普通文件。
我欣赏的是这种判断力。团队要完成一项明确的工作，而最初的设计要求他们维护的技术设施，超过了这项工作的实际需要。
架构图上的每一层，都附带维护工作
假设一家企业有一个小型内部工具和四十份流程文档。员工需要找到正确的退货政策或安装检查清单。收到的方案却包括独立搜索服务、向量生成流程、同步任务、另一个管理后台，以及 AI 聊天界面。
这些组件都可能有价值。但在购买整套方案之前，我想先看看，现有系统究竟回答不了哪些问题。
也许文档命名混乱，没有明确负责人。也许搜索框无法处理员工实际使用的编号。也许旧版说明和现行版本并排出现，却没有日期。换一个模型，并不能决定谁负责审批退货政策。
每增加一项服务，工作都不止于首次开发。有人需要管理凭据、监控故障、处理升级，并知道如何恢复服务。原始文档变化时，另一份副本或搜索索引也可能需要更新。这样就会出现一段时间：系统的两个部分给出不同的信息。
托管服务可以替你承担大量运维工作。但在你的应用中，仍然需要有人负责它：理解配置和账单，也知道依赖服务不可用时，用户会遇到什么情况。
让简单方案也用结果说话
如果要做这个搜索项目，我会先整理一小组员工真实提出的问题，以及应该回答这些问题的文档。其中应包括准确的产品编号、旧政策名称、用员工自己的话描述的问题，以及该员工无权阅读的文档。
用这组问题对比现有工具、改进后的常规搜索和拟议中的 AI 辅助版本。记录是否找到了正确资料、内容是否为最新版、完成任务花了多久，以及受限内容是否仍然受到保护。小规模试验有助于选择方向，但不能替代完整的访问控制审查，也不能替代预期负载下的测试。
你正在使用的数据库，可能已经具备实用的搜索能力。例如，PostgreSQL 全文搜索支持索引、词形规范化和结果排序，能力远不止检查一段文字是否包含某个精确字符串。因此，它值得纳入评估，但不能假定它适合所有语言或资料集合。
如果员工的表述与文档用词差异很大，按语义检索可能有帮助。如果系统需要综合多个来源的信息，设计也可能需要进一步扩展。这些都是采用相同问题和约束、测试更强方案的理由。
即使如此，选择向量搜索，也不一定意味着再买一个数据库服务。pgvector 为 PostgreSQL 增加了向量相似度搜索。其文档也明确说明了一项取舍：近似索引可以用部分召回率换取速度。最终是否适合，仍取决于托管环境支持、工作负载、隔离要求和运维需求。
目标是找出能够满足要求、而企业又有能力运营的设计。数一数架构图上有多少方框，回答不了这个问题。
问清楚：什么情况下才需要下一层
一份有用的方案，应当说明简单设计在什么情况下会不够用。可能是实测响应时间超过了上限，搜索质量无法达到目标，也可能是隔离要求，或需要独立扩容的工作负载。
请对方说明这个边界的依据。“等业务发展起来就需要”留下了太多空白。文档数量、并发用户数和可接受响应时间的预估，才能让团队据此设计和测试。如果这些数字还不清楚，就明确说明，并为测量留出空间。
如果以后迁移会严重影响业务，现在多投入一些可能值得。对于每月只用两次的工具，保留一个简单的人工步骤，也可能合理。决定取决于实际工作、故障后果，以及可投入的运维人员。
谨慎移除组件承担的职责
简化现有应用，需要先调查。在移除某个组件之前，弄清谁在使用它、它管理哪些数据，以及哪些报表或后台任务依赖它。保留用户需要的行为，验证替代方案，并在切换流量之前准备回退计划。
身份验证、数据校验、备份和必要的审计记录，仍然各有作用。把所有内容塞进一个没有结构的文件，可以让架构图变小，却会让维护更困难。在应用内部划清职责边界很有价值，而不必把每个边界都变成独立部署的服务。
对于正在评审方案的企业负责人，我建议请开发者解释：他决定不加入哪个组件，以及什么变化会让他改变这个决定。清晰的回答，能让你看出他如何考虑你的预算和未来的维护工作。
如果你的应用已经积累了许多没人能解释用途的服务，Rosecraft 提供技术评估与规划。我们可以检查现有工作流程，识别真正服务于它的依赖，并建议范围明确的下一步。告诉我们系统负责什么，以及哪些部分越来越难维护。