直接结论
Cloudflare AI Search可以为每个向量保存最多10 KiB的共享元数据，但字符串字段只有前64个UTF-8字节进入可筛选范围；因此“值能被保存”不等于“完整值能被过滤命中”。多语言品牌应把市场、语言、内容类型、产品族和公开状态设计成短、稳定、枚举化的字段，把人类可读长描述留在正文或非筛选用途，并在修改字段Schema后安排全量重索引与查询回归。
事实与背景
Cloudflare AI Search在2026年8月25日的发布说明中更新了自定义元数据容量：每个向量可使用一个共享的10 KiB紧凑JSON UTF-8封装。这里的10 KiB不是每个字段各自拥有的额度，而是系统元数据、字段名、JSON语法和客户自定义元数据共同使用的总空间。官方文档同时明确，字符串可以保存得比可筛选前缀更长，但只有每个字符串的前64个UTF-8字节可被过滤条件匹配。
这两个边界解决的是不同问题。10 KiB决定一条向量记录能携带多少元数据；64字节决定字符串中有多少前缀进入筛选索引。一个长的产品系列名称可能完整或部分保存在元数据中，却因为关键市场代码、版本号或状态词出现在第64字节之后而无法按预期过滤。对中文、日文、韩文和含表情符号的内容尤其不能把“64字节”误读为“64个字符”，因为UTF-8字符占用的字节数并不固定。
先区分内置字段、自定义字段与正文
| 信息层 | Cloudflare当前处理方式 | 适合存放什么 | 不适合承担什么 |
|---|---|---|---|
| 内置元数据 | 自动提取filename、folder和timestamp | 文件身份、路径分组、更新时间范围 | 品牌自定义市场、语言或权限语义 |
| 自定义元数据 | 每个实例最多定义5个字段，支持text、number、boolean和datetime | 检索前必须执行的市场、语言、类型、产品族、公开状态等条件 | 长篇解释、证据正文或任意标签集合 |
| 页面或文档正文 | 抓取后转换、分块并建立检索索引 | 完整产品事实、限制条件、案例、证据与解释 | 需要在检索前严格排除的租户或权限边界 |
元数据筛选在检索之前执行，作用是先缩小候选文档集合，再进行向量、关键词或混合检索。它适合表达“只在英文东南亚公开知识中检索”这类硬条件，不等于改变正文的语义相关性。相关性阈值、重排、查询改写和生成提示仍是另一层配置；把所有信息塞进元数据不会自动提高答案质量。
为什么64字节要求短代码前置
筛选字段的首要目标不是可读性，而是稳定、唯一和可比较。与其把market写成一段“面向新加坡、马来西亚和印度尼西亚的东南亚英文市场内容”，更稳妥的做法是使用受控代码，例如sea-en；人类可读说明仍保留在页面标题、正文或内容管理系统中。这样可以减少翻译、大小写、空格、标点和超长前缀带来的不一致。
字段名大小写不敏感并会以小写保存，timestamp、folder和filename是保留名称，不能拿来定义自有字段。字符串筛选限制按UTF-8字节计算，因此验收时应直接计算编码后的字节长度，而不是在编辑器里数汉字。若业务必须保留较长字符串，应把用于过滤的稳定代码放在最前面，并另行保留显示名称；不能假设关键字出现在长值末尾也能命中。
多语言品牌的五字段最小方案
| 字段 | 类型 | 示例 | 决策用途 | 设计边界 |
|---|---|---|---|---|
market | text | sg、de、global | 限定目标市场 | 使用稳定市场代码，不写长地区说明 |
language | text | en、de、zh-cn | 限定回答语言 | 先确定统一大小写与连字符规范 |
content_type | text | product、evidence、faq | 区分事实页、证据页与问答页 | 不要把临时栏目名当永久类型 |
product_family | text | pump-a | 把检索限制到一个稳定产品族 | 代码与官网规范产品实体一一对应 |
is_public | boolean | true、false | 排除未公开内容 | 它不是身份认证或授权系统 |
这只是一个可执行的最小模型，不是所有企业的固定答案。若时间有效性比产品族更重要，可用datetime字段替换一个低价值文本字段；若产品版本是连续数值，可考虑number并用范围运算符筛选。内置timestamp已记录对象最后修改时间，企业应先判断它能否满足新鲜度需求，避免浪费有限的五个自定义字段重复表达同一件事。
对于多品牌、多租户或真正受限的数据，不应仅依靠is_public=false过滤。筛选配置错误、调用方漏传条件或后续Schema变化都可能扩大候选集合。敏感资料仍需使用独立实例、Cloudflare Access、服务端授权、最小权限和数据源隔离；元数据筛选适合检索治理，不是安全边界。
网站、R2与内置存储的元数据入口不同
网站数据源从页面<head>中的<meta>标签提取自定义字段，标签可使用name或property属性，但字段必须先在AI Search实例中定义Schema。抓取时，字段名按不区分大小写的方式与Schema匹配，content值再转换为配置的数据类型。布尔值当前接受true/1/yes与false/0/no；其他值会被视为无效并省略。
R2数据源通过S3兼容的x-amz-meta-*头写入，自带存储则在Items API上传时附加元数据。三种入口最终都要遵守实例Schema和向量元数据限制。把同一字段在不同来源中写成不同类型或不同枚举，会造成过滤结果不可比；多数据源项目应先冻结字段词典，再接入内容。
网站页面中的title、description和image有官方识别的meta来源，但仍需在Schema中定义后才会提取。标准meta与Open Graph同时存在时，标准meta优先。品牌应把“页面展示与摘要字段”和“必须检索前过滤的治理字段”分开排序，避免有限字段被重复、易变或无法形成决策的内容占满。
Schema修改不是无成本操作
Cloudflare明确说明，自定义元数据Schema发生变化会触发全部文档的完整重索引：新增字段进入索引，被删除字段从索引移除，既有向量更新为新的元数据结构。对大型、多语言或频繁更新的知识库，这意味着字段改名、类型调整和枚举重构不应直接在生产实例上试错。
发布前应先用代表性样本验证字段提取、类型转换、字节长度和过滤语句，再安排变更窗口。变更后不仅要看“同步完成”，还要抽查Items中的实际元数据，并对每个市场、语言、内容类型和公开状态运行正向与反向查询。若只验证能检索到目标内容，却不验证错误市场或非公开内容被排除，验收仍不完整。
过滤语法也有容易误读的边界
当前过滤支持$eq、$ne、$in、$nin以及大小范围运算符；直接给字段赋值等价于$eq。同一过滤对象中出现多个字段时，条件隐式按AND组合。$in的含义是把一个已存储的标量与候选标量列表比较，并不是在文档存储的数组中查找元素；Cloudflare说明Vectorize可以保存字符串数组，但当前不会索引或筛选这些数组。
因此，“一篇页面属于多个产品族”不宜用未经验证的字符串数组直接承担筛选。可把页面拆成更明确的知识单元、选择一个主产品族、使用多个规范页面，或调整实例与路径架构。无论采用哪种方案，都应以实际查询结果验证，不要把JSON看起来正确当作过滤已经生效。
一套可审计的上线验收矩阵
| 检查层 | 通过条件 | 失败表现 | 处置 |
|---|---|---|---|
| 字段词典 | 不超过5个字段；名称、类型、枚举、所有者和变更规则明确 | 同义字段并存、保留名称冲突、类型不一致 | 先统一Schema，不启动全量重索引 |
| 容量与前缀 | 过滤值的关键代码位于前64 UTF-8字节；总封装留有系统开销余量 | 长值后缀无法命中或字符串被截断 | 缩短并前置稳定代码，重新索引 |
| 来源提取 | 网站meta、R2头或Items API值按预期进入索引 | 布尔值无效、字段缺失、标准与OG值冲突 | 修正源值和Schema后重跑同步 |
| 过滤回归 | 正向样本命中，错误市场、语言、类型和状态样本均被排除 | 只验证命中，不验证排除 | 补齐负向与边界用例 |
| 安全与效果 | 受限数据由访问控制隔离；相关性和答案质量另行测量 | 把metadata当权限系统或排名优化 | 拆分安全、检索与GEO指标 |
验收记录至少应保留：字段Schema版本、数据源、示例URL或对象、原始元数据、UTF-8字节数、同步任务时间、查询过滤体、返回文档、应命中/应排除判断和复测日期。这样当网站改版、枚举变更或索引结果漂移时，团队可以定位是源数据、Schema、同步、过滤还是后续相关性环节出了问题。
测量要把过滤正确性与GEO效果分开
元数据过滤直接可验证的是候选文档集合是否符合条件。它不能证明页面被Google、Bing、ChatGPT或其他公开搜索系统抓取、索引或引用，因为Cloudflare AI Search是企业自己配置的数据与检索系统。即使品牌把公开官网接入AI Search并通过MCP或公共端点供Agent查询，也只能说明该入口的检索行为，不能代表全网平台行为。
正确的测量顺序是：先验证字段提取与过滤排除，再评估检索相关性、来源返回和答案准确性，最后才观察公开渠道中的品牌提及、引用、访问与转化。若过滤后答案改善，应保留相同问题集、同一实例配置和变更前后结果；若没有对照，不能把同期波动归因于64字节前缀或元数据调整。
对企业的影响
第一，多语言站点最容易踩中的不是10 KiB总量，而是把64 UTF-8字节误当成64个字符。中文、日文、韩文、重音字符和表情符号的字节占用不同，长的本地化描述不适合作为稳定过滤键。 第二，五个自定义字段是一项稀缺治理预算。品牌应优先保留会在检索前改变候选集合的维度，例如市场、语言、内容类型、产品族与公开状态，而不是重复正文、导航标题或已有内置字段。 第三，字段Schema会影响生产重索引成本。字段改名、类型变化或删增不是单页编辑，必须纳入版本、回滚、同步窗口和查询回归，尤其适用于大型产品库与多市场知识中心。 第四，元数据过滤不能替代权限控制，也不能代表公开AI搜索曝光。受限数据要在数据源与访问层隔离，GEO效果仍需用公开平台答案、来源链接、抓取/访问证据和站内分析独立验证。
智核增长的判断
Cloudflare本次容量更新让企业可以携带更丰富的元数据，但真正决定检索治理质量的仍是“少而稳定”的字段模型。对于品牌出海知识库，最优先的不是把10 KiB填满，而是把有限的五个字段设计成跨语言、跨系统、可版本化的控制面：短代码负责筛选，正文负责解释，内置字段负责文件和时间基础，访问控制负责安全。 实施时应先建立私有字段词典，明确每个字段的业务问题、类型、允许值、来源、负责人和弃用方式；随后用代表性页面做字节与过滤测试，最后再触发全量重索引。字段一旦进入多个站点、R2对象、上传流程和查询代码，后续修改成本会快速放大，因此第一次上线前的负向用例比增加更多描述字段更有价值。 本文能证明的是Cloudflare AI Search当前的元数据存储、字段数量、数据类型、筛选前缀和重索引行为；不能证明这些字段会被Google、Bing、OpenAI或其他公开搜索平台读取，也不能证明配置后会提高排名、引用率、品牌提及、流量或转化。
建议行动
- 盘点现有市场、语言、内容类型、产品族、版本、时间与公开状态字段，删除不能改变检索决策的候选项。
- 将自定义字段控制在5个以内，并为每个字段记录类型、允许值、来源、所有者、默认值和弃用规则。
- 避免使用`timestamp`、`folder`和`filename`作为自定义字段名，先复用可满足需求的内置元数据。
- 对所有文本过滤值计算UTF-8字节数，把稳定短代码放在前64字节内，不用本地化长描述作为唯一筛选键。
- 为市场、语言、内容类型和产品族建立统一的ASCII小写枚举，禁止同义词、自由文本与临时栏目名进入生产索引。
- 按数据源分别核对网站``、R2 `x-amz-meta-*`和Items API的字段注入方式与类型转换。
- 在修改Schema前保存字段版本、实例配置和基线查询，预留全量重索引窗口与回滚方案。
- 为每个字段组合建立正向、反向和边界查询，验证应命中文档与应排除文档，而不只检查是否返回结果。
- 对敏感、租户隔离或未公开数据使用独立实例、身份认证、授权和数据源隔离，不依赖metadata过滤保密。
- 将过滤正确率、检索相关性、答案准确性、公开AI引用和站内转化分开记录，避免跨层归因。
限制条件
本文基于Cloudflare AI Search截至2026年9月4日的官方文档。该产品仍标注为Beta，字段类型、限制、API语法、计费与重索引行为未来可能变化；实施前应重新核对官方发布说明、Metadata attributes、Filtering、Website与Limits页面。 10 KiB是每个向量的共享紧凑JSON UTF-8封装总量，包含系统元数据和JSON开销，不是客户可完全支配的净空间，也不是每个文档或每个字段的独立额度。Cloudflare会优先保留必要系统元数据，配置字段可在UTF-8字符边界被截断；因此不应把接近10 KiB的测试值当作稳定生产容量。 64字节规则适用于每个已索引字符串的可筛选前缀，不代表超过部分一定没有被保存，也不代表其他数据类型具有同样的字符串前缀语义。字符串数组当前可以存储但不会被索引或过滤。元数据筛选只约束Cloudflare AI Search的检索候选集合，不构成访问控制、法律合规结论、公开搜索收录或AI引用保证。