AI Search 新 Binding：把多知识库检索做成命名空间

这篇解决什么

RAG 项目常把产品文档、客户文档和内部 SOP 分散成多个索引，应用侧越写越乱，跨库检索难治理。

适合谁

适合做文档问答、客户知识库、内部 SOP 搜索、AI 客服和开发者门户的团队。

操作步骤

1. 把知识库按产品、客户、权限和更新频率分组
2. 为每组创建 AI Search instance 并记录 instance id
3. 使用 namespace binding 管理实例创建和查询
4. 为跨库问题显式传入允许检索的 instance_ids
5. 记录每次回答命中的文档和更新时间
6. 把无命中文档整理成补充素材队列

可复制模板

命名空间：
Instance ID：
数据范围：
权限等级：
更新频率：
跨库规则：
命中记录：

验收清单

• 实例分组清楚
• 权限范围明确
• 跨库查询受控
• 命中文档可追溯
• 补充队列存在

常见错误

• 只收藏产品更新，没有把它改成当天能执行的工作卡。
• 只看发布标题，没有确认账号权限、适用版本、成本和数据边界。
• 把 AI 自动化结果直接当结论，没有保留人工复核和失败恢复动作。
• 外部链接散落在聊天记录里，后续复查时找不到来源和日期。

30 分钟小样本

先选一个真实但低风险的任务。前 5 分钟写清输入材料和目标产物；中间 15 分钟按本文步骤执行一次；最后 10 分钟记录输出、人工修改量、失败点和下一次复用条件。小样本通过后，再扩展到团队模板或固定 SOP。

复用方式

第一次执行时，把它当成个人操作卡；第二次执行时，把成功步骤整理成团队模板；第三次执行时，再判断是否值得升级成固定 SOP、工具页或培训材料。每次复查都要看官方页面是否改版、权限或价格是否变化、原来的示例是否还能跑通。

资料依据

• Cloudflare AI Changelog / AI Search instances built-in storage and namespace Workers Bindings / 2026-04-16

标签