最近我在挑选一款日志分析工具时突然意识到一个很反直觉的事AI 已经把“产品发现”这件事做得越来越自然但背后的信息交互方式却仍然没有一套真正开放的协议。搜索结果是一堆页面推荐系统是一堆排序AI 助手是一段回答它们之间互不通用。我打开搜索引擎前几页是内容平台的营销文章和 SEO 页看不出哪些工具真正适合我的场景打开某个软件社区排行榜倒是清晰但推荐依据只有“下载量”和“评分”两个维度完全不考虑我的技术栈和数据量我又试着问了几款 AI 助手它们确实能给出建议但换一个工具问同一个问题结论就完全不一样。更麻烦的是我没办法把这些推荐结果带到下一个工具里也没办法反问一句“你给出这个推荐时到底看到了哪些条件”。这就是很多人在 AI 时代重新遇到的老问题产品发现比以前更智能了却也更零散、更不透明了。而 “An open protocol for AI-mediated product discovery” 这个方向讲的正是怎么解决这个问题——它不是又一个搜索引擎也不是一套推荐算法而是为“AI 帮你发现产品”这个过程定义一套可复用、可验证、可迁移的开放协议。1. 为什么产品发现需要协议化但一直很难做到1.1 产品发现的几种主流方式都存在同一个缺口先盘点一下我们今天发现产品的常见方式。第一种是传统搜索。用户输入关键词搜索引擎返回网页列表。这里面的“产品”是分散在站点、工具库、论坛、榜单里的。搜索能帮你找到很多入口但不会帮你判断哪个更合适。你要自己点开每个页面自己对比属性、价格、评价这个成本很高。更关键的是搜索结果的排序依据往往与“是否适合你”无关而是与 SEO、投放预算、站点权重有关。第二种是平台内推荐。应用商店、软件目录、电商平台、内容社区都有自己的推荐系统。平台的推荐逻辑是经过优化的但通常只掌握在平台自己手里。你看到的结果是基于点击率、购买率、内容匹配等指标算出来的平台不会告诉你为什么把 A 排在前面更不会允许你把这套推荐逻辑搬到别的平台上。你在一个平台积累的偏好也无法平移到另一个平台。第三种是榜单和评测。权威榜单的优势是经过人工筛选信息密度高但榜单很容易滞后而且它是站在编辑视角写的不一定理解你的使用场景。比如一个开源监控工具榜单可能只评价功能丰富度并不关心你是否只有一台轻量服务器是否需要五分钟内完成部署。榜单适合建立初步认知不适合做个性化决策。第四种是 AI 对话。也就是最近两年大家都在用的方式直接让 AI 助手根据描述推荐工具或产品。这种方式的体验最好因为它能理解自然语言能结合上下文给出具体建议。但它也是问题最大的一个AI 的模型和内部目录是黑盒推荐的依据不透明引用来源时有时真实有时模糊而且不同工具之间没有任何兼容性。同样的需求在这里问一个答案换一个工具又是另一套答案你不知道哪套更可靠。如果我们把四种方式放在一起看会发现一个共同缺口它们都缺少一个标准化的“交换层”。用户的需求没有结构化产品数据没有统一描述AI 的推荐依据没有标准化输出三个环节彼此隔离。结果就是每次“发现”都是一次性的换一个平台、换一个助手就要重新来一遍。1.2 协议化的目标不是统一数据而是统一交互语言一个常见的误解是开放协议意味着所有人都必须把产品数据放到同一个数据库里。这个理解不准确也没有必要。数据本身就是分散的电商平台有自己的商品库开源社区有自己的项目库工具厂商有自己的产品页。硬要把它们聚成一个巨大的中心化数据库既涉及大量商业问题也涉及数据时效性和维护成本问题。协议化的真正价值是定义“怎么把发现过程说清楚”。它回答的核心问题包括用户需求用什么格式表达产品信息最少需要哪几个字段AI 给出推荐结果时至少要附带哪些解释信息用户如何对推荐结果做反馈这些信息从 A 平台迁移到 B 平台时怎样做才不会丢当这些问题有了共同约定产品数据可以留在各自家里但参与“AI 发现”的各个角色——用户、产品方、AI 模型、平台方——可以基于同一套语言协同工作。这更像是给参与者提供一个公共翻译层。它的切入点不是“存储”而是“通信”。这也是为什么标题里强调的是 “protocol” 而不是 “database” 或 “catalog”。数据标准只解决“数据长什么样”而协议解决“参与方如何协作”。后者包含的数据格式约定只是其中一部分。1.3 为什么过去很难做成现在又值得重新考虑这个方向过去不是没人尝试过。传统的产品目录标准、电子商务数据交换标准、RSS 等领域都曾经试图定义某种产品发现或内容分发的公共格式。但为什么一直很难成为主流一个重要原因是过去的产品发现是“静态匹配”阶段。用户输入关键词系统匹配产品字段输出列表。这个阶段的效率瓶颈主要在数据质量不在交互逻辑所以平台倾向于封闭优化没有动力开放底层协议。再者过去的产品目录大多由人工维护更新成本高协议能带来的增量价值并不明显。到了 AI 时代情况变了。AI 可以理解自然语言可以根据上下文综合多路信息甚至生成一段完整的推荐理由。这个能力让“用户表达需求”和“产品展示信息”之间的连接方式发生了质变不再是非得靠关键词匹配而是可以通过“意图协商”来完成。但与此同时AI 的不确定性、模型的差异、来源的可信度也成了新问题。如果每个 AI 助手都用自己私有的一套方式去理解和展示产品数据用户不仅无法比较推荐质量也无法对结果做审计和纠错。所以现在的“值得重新考虑”不是因为技术突然成熟了而是因为 AI 已经成为了产品发现的重要入口而 AI 的接入方式如果还是封闭的、零散的最终会产生大量互相割裂的“智能孤岛”。开放协议的意义正在于给这些孤岛搭桥。2. 拆开这个开放协议它到底在约定什么如果站在一个开发者视角我们会关心这协议里到底定义了哪些东西。因为材料里没有给出标准化文档所以我这里不打算捏造一个具体的技术规范而是把它拆成一组“协议需要回答的核心问题”来理解。任何一个真实的实现最终都要围绕这些模块来设计。2.1 用户意图的标准化表达协议的第一个核心模块是“用户意图”。它要让 AI 和产品目录都能理解用户到底想要什么。这个模块要回答的问题包括用户现在处在什么任务上下文里是“我要上一个新项目”还是“我要替换现有工具”还是“我只是随便看看”用户对产品的硬性约束是什么比如必须支持某编程语言、必须满足数据安全要求、必须能私有化部署、预算在什么范围。用户的偏好优先级是什么对开源项目来说活跃度比易用性更重要对商业工具来说售前支持和部署文档可能更重要。用户过去的交互历史能否作为意图的一部分这里涉及隐私所以协议需要约定哪些信息可以携带、哪些需要脱敏。意图不能是一个纯自然语言的句子因为产品目录很难直接解析自然语言。协议应该定义一种结构化的意图表达例如包含task、constraints、preferences、context等字段。自然语言可以作为原始输入保留但协议层要有结构化的“意图快照”来驱动数据检索和 AI 推理。这里要特别注意意图不是一次性的。用户可能在一次对话中不断修正需求所以协议还要支持“增量更新”。例如用户先说“找一个开源日志工具”随后补充“不支持 Kubernetes 的不要”再补充“最好和 Prometheus 生态兼容”。这三条信息可以合并成一个完整意图快照而不是每句话都当成一次独立的搜索请求。在常见的 AI 对话产品里这个靠上下文窗口实现在协议层就需要有明确的“意图合并规则”。2.2 产品数据的最小公共字段第二个核心模块是“产品描述”。为了让不同数据源能接入同一个协议我们不能要求每个数据源都提供几百个字段那样接入成本太高。正确的方式是定义一组最小公共字段再允许扩展。一个最简产品描述可能包括产品名称和标识符一句话简介主要功能标签适用场景标签价格模式免费、订阅、买断等技术栈或运行环境要求项目/产品主页链接许可证或使用条款如果适用发布方或维护方信息最近更新时间或版本状态这组字段的意义不是替代每个平台自己的详细产品页而是保证参与协议的数据源之间能互相理解。你可以把最小公共字段理解成“第一次见面时的自我介绍”。详细说明留在各自的平台里协议只需要一个能让 AI 快速判断“要不要进一步了解”的入口信息。不过最小公共字段不能只有字段名还要约定“取值风格”。比如“功能标签”是自由填写的字符串还是从某个公共词表里选择如果两个数据源一个写“日志分析”另一个写“log-analysis”它们会被 AI 当成同一个功能吗这里就需要协议提供一套“同义词归一化”或“标签映射”的机制。否则最小字段有了各字段的值仍然无法对齐协议就退化成一份好看的 JSON 模板。2.3 AI 推荐结果的透明化接口第三个模块是整个协议里最关键的部分AI 推理过程的透明化。传统推荐系统只需要输出排序结果用户无法知道为什么。但在 AI 媒介的产品发现中AI 是站在用户这边的“智能助手”它不应该只给一个答案还应该给出支撑这个答案的关键依据。协议要定义 AI 推荐结果的输出格式重点包括recommended_items推荐的产品列表带产品标识符和来源。reasoning_summary一句或几句推荐理由说明为什么匹配这个产品。evidence_refs参考的产品字段、来源链接或数据快照。confidence/uncertaintyAI 对推荐的置信程度以及它在哪些条件上不确定。alternative_intents如果 AI 对用户意图理解可能有偏差它应该给出备选意图或追问。有了这一层用户才能判断 AI 是认真分析过还是泛泛而谈。尤其是引用证据这一步可以让推荐结果从“一段漂亮的对话”变成“一份可核查的报告”。用户在查看推荐结果时不仅能看到“推荐了 Loki”还能看到“因为产品描述里明确写了开源许可证部署模式为 self-hosted且提供了 Prometheus 集成说明”。这里也涉及一个设计和取舍问题AI 推荐的透明化到什么程度合适如果所有推理链都完整输出用户可能被技术细节淹没如果只输出一句理由又达不到可核查的目的。我的建议是分层默认输出摘要级理由用户对单条推荐产生疑问时可以展开详细证据。协议层面至少要把“摘要理由”和“证据引用”作为必选字段“完整推理链”作为可选扩展。2.4 用户反馈和结果修正机制协议还要定义“反馈循环”。用户看完推荐后可能会说“这个不对我其实不需要自建我需要一个 SaaS 服务”或者“第一个选项不错但价格超出预算”。这些反馈不能只停留在聊天记录里而应该结构化地传回给协议层供 AI 迭代推荐。反馈机制至少包括两个方向明确修正用户直接修改约束条件或偏好系统重新检索。隐式反馈用户点击了某个产品、查看了详情、放弃操作这些行为可以作为信号但需要用户授权。协议化反馈的价值在于用户可以在一个 AI 助手调整偏好然后带着这套偏好去访问另一个产品目录继续做对比。反馈数据也不是被绑定在某一个聊天应用里而是以用户可控的“意图快照”形式存在。这里要注意反馈机制和隐私保护是强关联的。协议不能默认允许任何一方长期存储用户的意图和反馈记录必须提供“用户可导出、可删除、可撤销授权”的机制。同时反馈不应该被设计成“平台用来调模型的私有数据”而应该是一种“用户主动提交的对当前推荐结果的质量评价”。这两者的区别很大前者是平台资产后者是用户权益。3. 从一次“AI 推荐”看协议在真实链路里怎么走前面对模块的解释偏概念这一节用一个具体场景把协议贯穿起来。假设我现在要找一款适合个人开发者的日志分析工具需要支持开源、可以私有化部署、最好能跟我现有的 Prometheus 生态兼容。这个需求看似简单但真正走一遍会发现没有协议时整个过程很破碎有了协议后衔接会顺畅很多。3.1 没有协议时的典型状态先看没有协议时会发生什么。我打开搜索引擎输入“开源日志分析工具”得到一堆网页。我需要自己点开 Grafana、Loki、Graylog、SigNoz 等项目的官网自己确认它们的部署方式、数据存储、查询语言还要去社区看是否有对接 Prometheus 的例子。这个筛选过程可能要消耗几个小时。如果用 AI 助手我可以直接描述需求它会推荐几个工具并解释各自特点。但它的知识可能停留在某一个时间点产品版本、许可证、最新特性都可能过期。而且我想把这次提取的“需求描述”用到另一个工具上再比较一次时往往只能手动重新打一遍甚至重新组织语言。更麻烦的是AI 助手在回答时不会告诉你它参考了哪些候选集。它可能只从自己训练知识里回忆出三个常见项目完全没有覆盖到更小众但更适合你的方案。你作为用户不知道候选集是否完整不知道推荐的依据是什么也不知道该如何提供反馈来修正结果。整个过程就像身处一个黑箱。3.2 协议下的请求与响应示意如果采用了一套开放协议流程会变成这样。第一步我的 AI 客户端把用户意图结构化为一个请求。这里我用示意性 JSON 展示不代表某个真实协议已经定义了这个格式{ intent: { task: find-log-analysis-tool, constraints: { licensing: [open-source], deployment: [self-hosted], ecosystem: [prometheus] }, preferences: { priority: [documentation, community-activity] }, context: { user_level: individual-developer, previous_tools: [prometheus, grafana] } } }第二步这个请求通过协议接口发送给一个“产品发现网关”或者直接并行发给多个接入协议的产品目录。每个目录都有适配层把它自己的数据结构映射成协议中的“最小产品描述”。第三步各目录返回候选产品集。AI 模型接收到候选集后结合刚才的结构化意图做一次综合推理生成推荐结果。推荐结果的示意如下{ recommended_items: [ { product_id: loki, source: https://example-catalog/open-source/logging, matched_reasons: [open-source, self-hosted, prometheus-integration] }, { product_id: sigNoz, source: https://example-catalog/open-source/logging, matched_reasons: [open-source, self-hosted, full-stack-observability] } ], reasoning_summary: 两个工具都满足开源和自部署条件。Loki 与 Prometheus 同源适合轻量标签化查询SigNoz 提供更完整的监控与追踪面板适合需要统一定位到调用链的场景。, confidence: medium, uncertainty: 用户未说明日志量级和数据保留周期这部分会影响最终架构建议。, alternative_intents: [日志可视化, 链路追踪, 复杂日志检索] }第四步我基于这个结果继续追问“如果日志量每天大约 50GB哪个更合适”AI 会结合这个新约束进一步给出说明。这里的关键是因为意图、产品数据和推理依据都是结构化的对话上下文可以保留后续查询也可以继续使用同一套标准。3.3 为什么这种链路更可靠这个链路带来的直接好处是可控。用户可以看到 AI 到底基于哪些字段做了匹配。如果产品目录返回的许可证信息已经过期AI 引用的是过期数据用户通过evidence_refs能追溯到来源进而发现目录更新滞后问题。如果某个产品目录只返回了三个产品AI 可能基于不完整的候选集做判断用户也从协议输出中看到候选来源有限从而主动增加其他目录。更重要的是这次“需求快照”是可以迁移的。如果我在这个 AI 客户端里不满意可以把结构化的intent导出导入到另一个 AI 客户端继续对同一批产品目录发起查询。整个过程不需要我把需求重新用自然语言写一遍也不会丢失约束字段。这正是“开放协议”相比“平台内集成”的核心优势。用一张简表可以更直观看到差异能力传统搜索平台推荐普通 AI 对话协议化 AI 发现理解自然语言弱弱强强推荐依据可追溯无无不完整结构化证据用户偏好可迁移不可不可不可可导出可复用候选集来源可见部分可见不可见不可见可见用户反馈可回流弱弱有限结构化反馈当然这个表格里的“协议化 AI 发现”是理想状态真实落地会有不少条件限制。但至少能说明协议化不是在功能列表上做加法而是在用户控制权和数据可迁移性上做结构性改进。3.4 用户反馈怎么回流我再举一个反馈回流的小例子。AI 给我推荐了 SigNoz但我看了一眼后发现它的运维成本比 Loki 高我希望推荐结果优先考虑轻量级方案。我可以点击“修正偏好”把priority改成[low-ops, small-footprint]。这个修正会更新我的意图快照同时要求目录重新检索。在协议层面反馈不仅要影响当前一轮最好能进入一个“偏好档案”。当我下次做“选一个集群监控工具”这类新任务时AI 可以知道我对“运维成本”很敏感。这个档案不是历史聊天记录而是结构化后的决策偏好。它由用户自己持有可以被预览、修改和删除。这样反馈就不是“填进平台的黑盒”而是“写进用户自己的一个参数表”。反馈回流还需要考虑一个细节用户对某个产品的“不喜欢”有时候是因为信息不足而不是产品本身不行。协议要尽量把“产品不匹配”和“推荐解释不清楚”区分开。如果用户因为看不懂某个产品的部署模式而点“不喜欢”应该触发的是“解释维度补充”而不是直接把这个产品从候选集里降权。这个细节看起来小但实际会影响推荐结果的可信度和公平性。4. 接入前先理清几个容易踩坑的边界问题把概念说得再好真正落地时还是会遇到一系列边界问题。这些问题如果不提前想清楚项目很容易做成一个自嗨的规范或者一套没人接入的 API。4.1 协议解决不了数据质量问题首先要明确开放协议能保证“不同系统之间能对话”但不能保证“对话内容一定是准确的”。如果上游产品目录里的许可证信息是错的或者版本号已经落后那么无论协议多严谨AI 推荐出来的结果依然可能是错误的。这时候问题不在于协议而在于数据源。所以在设计协议时一定要给数据源加入“溯源”和“更新时间”字段让使用者可以判断信息的时效性。同时所有接入方都要建立自己的数据巡检机制。协议不会去帮你抓取产品信息它只负责承载你抓取到的信息。数据质量仍然是每个参与者的责任。如果你打算做一个产品目录最应该花精力的不是定义协议字段而是把产品的许可证、部署模式、维护活跃度这些核心信息维护准确。4.2 协议不是推荐算法别把两者混淆另一个常见误区是把“开放协议”当成“一个开源的推荐系统”。实际它们的关系是协议是算法之上的一层“接口约定”而推荐算法本身可以继续保持各家私有。也就是说协议允许两个平台都用完全不同的推荐算法但它们的输入和输出格式一致。就像 HTTP 协议不关心每个网站怎么渲染页面只关心请求和响应的格式。这个区分非常重要因为这意味着平台不需要把核心的算法逻辑开放出来也能参与到协议生态里。它的商业竞争力依然保留只是多了一个标准化的对接口。这个边界还能帮助开发者做判断如果你的项目目标是做一个“更聪明的推荐系统”那你其实不需要协议但如果你希望“不同系统的推荐结果能互通、可审查、可迁移”那你需要协议。很多项目一开始容易把这两个目标混在一起结果既没有把算法做好也没有把接口标准化。4.3 隐私、授权和审计不能事后补AI 媒介的产品发现会涉及到用户数据用户的任务、偏好、历史工具、上下文等。这些数据比普通的搜索关键词更敏感因为它能推测出用户的工作习惯、技术栈、甚至组织内部信息。协议必须默认遵循几个原则最小化只传输完成当前发现任务所需的最小字段。可授权用户可以针对不同数据源单独授权而不是一次性全部开放。可撤回用户可以在任意时刻撤销授权并要求删除相关意图快照。可审计所有向外传输的用户数据都要有日志记录便于用户查看去向。这里我特别想提醒一句不要等项目已经跑起来用户量上来了再考虑隐私设计。协议类项目一旦形成固定格式再改隐私模型成本会非常高因为所有参与方都要跟着升级。早期就应当在协议文档里加入“隐私级别”字段让数据源和 AI 客户端都知道哪些数据可以处理、哪些必须丢弃。4.4 要兼容已有系统而不是另起炉灶开放协议最怕的事情是设计出一套只存在于文档里的完美标准但跟现实里的产品目录、RSS、GitHub API、应用商店数据格式都不兼容。这样没人会接入。更务实的路径是设计“适配器层”。协议定义核心字段然后为常见数据格式写适配器。例如GitHub 仓库搜索接口可以映射到最小产品字段把full_name作为产品标识符description作为简介topics作为功能标签。应用商店的 API 可以映射到名称、类别、评分、价格等字段。自有产品目录可以直接输出协议格式也可以提供 JSON Schema 做映射。如果协议的接入成本高于“直接写一个私有脚本”那么数据源方就不会有动力加进来。所以协议的价值不仅取决于设计好不好取决于接入成本低不低。适配器库的建设应该和协议规范本身同步推进甚至前置。5. 落地时我建议的四步走方法如果你希望把“开放协议”这个概念引入自己的项目无论是做一个产品推荐服务还是想让自己公司的产品能被更多 AI 助手发现下面这套四步走方法会更务实。这个方法的思路是先跑通再扩展最后工程化。5.1 第一步先定义“最小产品描述”不要一上来就设计完整的协议标准先定义清楚你自己的最小产品描述。你可以先填一张表格列出你希望 AI 看到的产品字段。这里以“给自家产品做 AI 可发现化”为例字段示例值是否必填来源产品标识符openprotocol-demo必须内部唯一 ID名称Open Protocol Demo必须产品名一句话简介用于演示 AI 产品发现的开放协议必须产品一句话介绍功能标签ai,product-discovery,protocol必须产品关键词适用场景开发者工具选型、SaaS 推荐推荐运营自己定义价格模式free / subscription必须定价页部署模式cloud / self-hosted推荐技术文档许可证MIT/Apache-2.0条件必填开源项目必填最近更新日期2025-01-15推荐发版时间产品主页https://...必须官网定义完这张表你就有了一份可以被 AI 消费的最小产品数据。可以在项目里暴露一个公开接口例如/products.json让 AI 或外部应用能拉取并解析。不要小看这一步很多产品到现在连一个机器可读的产品名录都没有。5.2 第二步跑通一个单轮推荐闭环第二步是用一个最小示例把“意图表达 - 检索产品目录 - 生成推荐 - 用户反馈”跑通。原型越简单越好甚至可以不用真正的 AI 模型。一个常见的原型路径是用一个 JSON 文件保存“最小产品描述”。用一个脚本读取用户输入的约束条件例如“license 是 open-source 且支持 self-hosted”。对 JSON 做一次简单的字段筛选。把筛选结果拼接成一段带依据的推荐文本。打印推荐结果并同时输出一条 JSON 记录包含“匹配依据”。这个阶段的意义是验证你的数据字段是否足够支撑一个简单的推荐判断以及推荐结果是否能够被用户理解。如果连“根据许可证是自建所以推荐 A”这种最基础的解释都输出不了那就说明你的产品数据字段还没有定义到位。这一步还有一种更轻量的做法直接用表格和筛选条件在本地完成原型不需要写后台服务。核心是让“字段到推荐理由”的映射关系变得可见。你会发现一旦字段定义清晰推荐逻辑本身其实可以很简单复杂的是那些含糊的、没有结构化表达的用户需求。5.3 第三步把用户反馈接进来单轮推荐只能证明流程没断但还不能支撑长期使用。第三步是加反馈。你可以设计两个简单的反馈入口每个推荐项后面都有“符合我的需求 / 不符合需求 / 信息不足”三个按钮。用户可以选择“修改约束条件”重新发起一轮推荐。在后端反馈会被记录到用户偏好快照里。例如用户每次点击“不符合需求”系统都会记录是哪个产品、哪个约束不满足。积累到一定量后你就可以看出自己的产品目录里哪些产品描述容易被误推荐从而调整字段或做更精确的标注。反馈接入的难点不在技术而在产品设计如何让用户愿意反馈又不打断体验。最稳妥的方法是把反馈做得足够轻一次点击完成可随时撤回。同时要让用户看到反馈确实产生了影响。比如用户把偏好从“功能丰富”改成“低运维成本”后下一轮推荐列表要有明显变化否则用户会觉得反馈没有意义。5.4 第四步增加多数据源和监控当单数据源的流程稳定后可以开始接入更多数据源。比如你自己的产品目录之外再接入一个开源项目库和一个第三方评测站点的数据。这时协议的最大价值就体现出来了你不需要给每个数据源写一套完全不同的推荐逻辑只需要为每个数据源写一个适配器把它们的输出映射到“最小产品描述”。多数据源接入后一定要加监控。监控项至少包括数据源同步是否成功。数据字段的缺失率。推荐结果的点击率和反馈率。AI 模型引用过期数据的比例。这些指标不是用来证明“协议很成功”而是用来发现协议生态里的薄弱环节。比如某个数据源的产品描述字段缺失率很高导致 AI 在推荐时总是忽略它的产品那就要推动该数据源补齐字段或者在协议层建立“缺失字段的回退机制”。协议不是设计出来就结束的它需要持续运营。5.5 一个实用的排查链路如果接入过程中出现问题不要漫无目的地调参数。我一般建议按下面这个顺序排查看现象是请求报错还是推荐结果为空还是推荐质量不佳看意图解析先确认用户输入有没有被正确结构化成意图字段。如果约束条件解析错了后续全部会错。看数据源状态再确认数据源是否有返回返回的数据里“最小产品描述”是否完整。很多“推荐为空”的问题其实是某个必填字段缺失导致的。看匹配逻辑如果是自己写的规则筛选要看筛选条件是否和意图字段对应如果是 AI 模型推理要看候选集是否覆盖了足够范围。看输出解析最后检查推荐结果有没有被渲染出来证据引用是否正常。这个顺序的核心思路是先保证输入、数据和链路完整再怀疑模型能力。大多数问题都出在前三层而不是 AI 本身不够聪明。很多开发者遇到“推荐不对”的第一反应是换更大的模型或调 prompt但如果产品的字段本身就是脏的、缺的再强的模型也白搭。6. 这个方向真正的长期价值是什么走到这里我们得跳出具体接入步骤想一想这个协议方向到底会改变什么。6.1 对普通用户从“被推荐”变成“可协商”过去用户在产品发现中的角色是被动的。平台决定推荐什么用户就消费什么。即使有搜索搜索逻辑也是平台定义好的。当用户通过开放协议来表达意图、携带偏好、审查推荐依据时用户就成了一次次“产品发现任务”的参与者。这意味着 AI 推荐不是“一个人说另一个人听”而是“两个智能体协作”一个用户委托的 AI一个产品目录代理的 AI中间由协议来保证双方讲的话能互相理解。用户也能从被动接受变成主动修正这对体验的影响会比很多人想象的大。它把“推荐”这件事从“平台给答案”变成了“用户和 AI 一起找答案”。6.2 对产品开发者质量不再靠平台施舍以前产品方想被 AI 助手推荐只能投预算、做 SEO、想办法挤进某个平台的榜单。但是在开放协议下只要产品能提供一份准确的最小产品描述并接入到任意一个协议兼容的目录中它就有机会被 AI 理解并推荐。这更像是一场“内容质量竞争”而不是“渠道竞争”。当然这不会完全消灭营销动作。模型可能更偏好有丰富文档、有活跃社区、有清晰许可证的产品。但至少一个中小型开源项目不需要再去讨好某一个封闭平台它只需要把信息披露清楚并接入开放协议即可。这个变化对长尾产品尤其重要因为没有协议的世界里它们很难被 AI 的候选集覆盖到。6.3 对 AI 应用开发者多了一个可复用的基础设施对开发者来说开放协议最大的价值在于“不用重复造轮子”。如果你要做垂直领域的 AI 产品推荐工具不需要重新收集数据、重新定义字段、重新设计推荐输出的解释格式。你可以复用协议层的标准把精力放在更上游的意图理解和更下游的交互体验上。更重要的是多智能体协作时会遇到很多信息交换问题。开放协议可以成为智能体之间关于“产品发现”这个任务的一种共享语言。这相当于给“AI Agent 协作
AI时代的产品发现需要开放协议，从数据交换到协作标准
最近我在挑选一款日志分析工具时突然意识到一个很反直觉的事AI 已经把“产品发现”这件事做得越来越自然但背后的信息交互方式却仍然没有一套真正开放的协议。搜索结果是一堆页面推荐系统是一堆排序AI 助手是一段回答它们之间互不通用。我打开搜索引擎前几页是内容平台的营销文章和 SEO 页看不出哪些工具真正适合我的场景打开某个软件社区排行榜倒是清晰但推荐依据只有“下载量”和“评分”两个维度完全不考虑我的技术栈和数据量我又试着问了几款 AI 助手它们确实能给出建议但换一个工具问同一个问题结论就完全不一样。更麻烦的是我没办法把这些推荐结果带到下一个工具里也没办法反问一句“你给出这个推荐时到底看到了哪些条件”。这就是很多人在 AI 时代重新遇到的老问题产品发现比以前更智能了却也更零散、更不透明了。而 “An open protocol for AI-mediated product discovery” 这个方向讲的正是怎么解决这个问题——它不是又一个搜索引擎也不是一套推荐算法而是为“AI 帮你发现产品”这个过程定义一套可复用、可验证、可迁移的开放协议。1. 为什么产品发现需要协议化但一直很难做到1.1 产品发现的几种主流方式都存在同一个缺口先盘点一下我们今天发现产品的常见方式。第一种是传统搜索。用户输入关键词搜索引擎返回网页列表。这里面的“产品”是分散在站点、工具库、论坛、榜单里的。搜索能帮你找到很多入口但不会帮你判断哪个更合适。你要自己点开每个页面自己对比属性、价格、评价这个成本很高。更关键的是搜索结果的排序依据往往与“是否适合你”无关而是与 SEO、投放预算、站点权重有关。第二种是平台内推荐。应用商店、软件目录、电商平台、内容社区都有自己的推荐系统。平台的推荐逻辑是经过优化的但通常只掌握在平台自己手里。你看到的结果是基于点击率、购买率、内容匹配等指标算出来的平台不会告诉你为什么把 A 排在前面更不会允许你把这套推荐逻辑搬到别的平台上。你在一个平台积累的偏好也无法平移到另一个平台。第三种是榜单和评测。权威榜单的优势是经过人工筛选信息密度高但榜单很容易滞后而且它是站在编辑视角写的不一定理解你的使用场景。比如一个开源监控工具榜单可能只评价功能丰富度并不关心你是否只有一台轻量服务器是否需要五分钟内完成部署。榜单适合建立初步认知不适合做个性化决策。第四种是 AI 对话。也就是最近两年大家都在用的方式直接让 AI 助手根据描述推荐工具或产品。这种方式的体验最好因为它能理解自然语言能结合上下文给出具体建议。但它也是问题最大的一个AI 的模型和内部目录是黑盒推荐的依据不透明引用来源时有时真实有时模糊而且不同工具之间没有任何兼容性。同样的需求在这里问一个答案换一个工具又是另一套答案你不知道哪套更可靠。如果我们把四种方式放在一起看会发现一个共同缺口它们都缺少一个标准化的“交换层”。用户的需求没有结构化产品数据没有统一描述AI 的推荐依据没有标准化输出三个环节彼此隔离。结果就是每次“发现”都是一次性的换一个平台、换一个助手就要重新来一遍。1.2 协议化的目标不是统一数据而是统一交互语言一个常见的误解是开放协议意味着所有人都必须把产品数据放到同一个数据库里。这个理解不准确也没有必要。数据本身就是分散的电商平台有自己的商品库开源社区有自己的项目库工具厂商有自己的产品页。硬要把它们聚成一个巨大的中心化数据库既涉及大量商业问题也涉及数据时效性和维护成本问题。协议化的真正价值是定义“怎么把发现过程说清楚”。它回答的核心问题包括用户需求用什么格式表达产品信息最少需要哪几个字段AI 给出推荐结果时至少要附带哪些解释信息用户如何对推荐结果做反馈这些信息从 A 平台迁移到 B 平台时怎样做才不会丢当这些问题有了共同约定产品数据可以留在各自家里但参与“AI 发现”的各个角色——用户、产品方、AI 模型、平台方——可以基于同一套语言协同工作。这更像是给参与者提供一个公共翻译层。它的切入点不是“存储”而是“通信”。这也是为什么标题里强调的是 “protocol” 而不是 “database” 或 “catalog”。数据标准只解决“数据长什么样”而协议解决“参与方如何协作”。后者包含的数据格式约定只是其中一部分。1.3 为什么过去很难做成现在又值得重新考虑这个方向过去不是没人尝试过。传统的产品目录标准、电子商务数据交换标准、RSS 等领域都曾经试图定义某种产品发现或内容分发的公共格式。但为什么一直很难成为主流一个重要原因是过去的产品发现是“静态匹配”阶段。用户输入关键词系统匹配产品字段输出列表。这个阶段的效率瓶颈主要在数据质量不在交互逻辑所以平台倾向于封闭优化没有动力开放底层协议。再者过去的产品目录大多由人工维护更新成本高协议能带来的增量价值并不明显。到了 AI 时代情况变了。AI 可以理解自然语言可以根据上下文综合多路信息甚至生成一段完整的推荐理由。这个能力让“用户表达需求”和“产品展示信息”之间的连接方式发生了质变不再是非得靠关键词匹配而是可以通过“意图协商”来完成。但与此同时AI 的不确定性、模型的差异、来源的可信度也成了新问题。如果每个 AI 助手都用自己私有的一套方式去理解和展示产品数据用户不仅无法比较推荐质量也无法对结果做审计和纠错。所以现在的“值得重新考虑”不是因为技术突然成熟了而是因为 AI 已经成为了产品发现的重要入口而 AI 的接入方式如果还是封闭的、零散的最终会产生大量互相割裂的“智能孤岛”。开放协议的意义正在于给这些孤岛搭桥。2. 拆开这个开放协议它到底在约定什么如果站在一个开发者视角我们会关心这协议里到底定义了哪些东西。因为材料里没有给出标准化文档所以我这里不打算捏造一个具体的技术规范而是把它拆成一组“协议需要回答的核心问题”来理解。任何一个真实的实现最终都要围绕这些模块来设计。2.1 用户意图的标准化表达协议的第一个核心模块是“用户意图”。它要让 AI 和产品目录都能理解用户到底想要什么。这个模块要回答的问题包括用户现在处在什么任务上下文里是“我要上一个新项目”还是“我要替换现有工具”还是“我只是随便看看”用户对产品的硬性约束是什么比如必须支持某编程语言、必须满足数据安全要求、必须能私有化部署、预算在什么范围。用户的偏好优先级是什么对开源项目来说活跃度比易用性更重要对商业工具来说售前支持和部署文档可能更重要。用户过去的交互历史能否作为意图的一部分这里涉及隐私所以协议需要约定哪些信息可以携带、哪些需要脱敏。意图不能是一个纯自然语言的句子因为产品目录很难直接解析自然语言。协议应该定义一种结构化的意图表达例如包含task、constraints、preferences、context等字段。自然语言可以作为原始输入保留但协议层要有结构化的“意图快照”来驱动数据检索和 AI 推理。这里要特别注意意图不是一次性的。用户可能在一次对话中不断修正需求所以协议还要支持“增量更新”。例如用户先说“找一个开源日志工具”随后补充“不支持 Kubernetes 的不要”再补充“最好和 Prometheus 生态兼容”。这三条信息可以合并成一个完整意图快照而不是每句话都当成一次独立的搜索请求。在常见的 AI 对话产品里这个靠上下文窗口实现在协议层就需要有明确的“意图合并规则”。2.2 产品数据的最小公共字段第二个核心模块是“产品描述”。为了让不同数据源能接入同一个协议我们不能要求每个数据源都提供几百个字段那样接入成本太高。正确的方式是定义一组最小公共字段再允许扩展。一个最简产品描述可能包括产品名称和标识符一句话简介主要功能标签适用场景标签价格模式免费、订阅、买断等技术栈或运行环境要求项目/产品主页链接许可证或使用条款如果适用发布方或维护方信息最近更新时间或版本状态这组字段的意义不是替代每个平台自己的详细产品页而是保证参与协议的数据源之间能互相理解。你可以把最小公共字段理解成“第一次见面时的自我介绍”。详细说明留在各自的平台里协议只需要一个能让 AI 快速判断“要不要进一步了解”的入口信息。不过最小公共字段不能只有字段名还要约定“取值风格”。比如“功能标签”是自由填写的字符串还是从某个公共词表里选择如果两个数据源一个写“日志分析”另一个写“log-analysis”它们会被 AI 当成同一个功能吗这里就需要协议提供一套“同义词归一化”或“标签映射”的机制。否则最小字段有了各字段的值仍然无法对齐协议就退化成一份好看的 JSON 模板。2.3 AI 推荐结果的透明化接口第三个模块是整个协议里最关键的部分AI 推理过程的透明化。传统推荐系统只需要输出排序结果用户无法知道为什么。但在 AI 媒介的产品发现中AI 是站在用户这边的“智能助手”它不应该只给一个答案还应该给出支撑这个答案的关键依据。协议要定义 AI 推荐结果的输出格式重点包括recommended_items推荐的产品列表带产品标识符和来源。reasoning_summary一句或几句推荐理由说明为什么匹配这个产品。evidence_refs参考的产品字段、来源链接或数据快照。confidence/uncertaintyAI 对推荐的置信程度以及它在哪些条件上不确定。alternative_intents如果 AI 对用户意图理解可能有偏差它应该给出备选意图或追问。有了这一层用户才能判断 AI 是认真分析过还是泛泛而谈。尤其是引用证据这一步可以让推荐结果从“一段漂亮的对话”变成“一份可核查的报告”。用户在查看推荐结果时不仅能看到“推荐了 Loki”还能看到“因为产品描述里明确写了开源许可证部署模式为 self-hosted且提供了 Prometheus 集成说明”。这里也涉及一个设计和取舍问题AI 推荐的透明化到什么程度合适如果所有推理链都完整输出用户可能被技术细节淹没如果只输出一句理由又达不到可核查的目的。我的建议是分层默认输出摘要级理由用户对单条推荐产生疑问时可以展开详细证据。协议层面至少要把“摘要理由”和“证据引用”作为必选字段“完整推理链”作为可选扩展。2.4 用户反馈和结果修正机制协议还要定义“反馈循环”。用户看完推荐后可能会说“这个不对我其实不需要自建我需要一个 SaaS 服务”或者“第一个选项不错但价格超出预算”。这些反馈不能只停留在聊天记录里而应该结构化地传回给协议层供 AI 迭代推荐。反馈机制至少包括两个方向明确修正用户直接修改约束条件或偏好系统重新检索。隐式反馈用户点击了某个产品、查看了详情、放弃操作这些行为可以作为信号但需要用户授权。协议化反馈的价值在于用户可以在一个 AI 助手调整偏好然后带着这套偏好去访问另一个产品目录继续做对比。反馈数据也不是被绑定在某一个聊天应用里而是以用户可控的“意图快照”形式存在。这里要注意反馈机制和隐私保护是强关联的。协议不能默认允许任何一方长期存储用户的意图和反馈记录必须提供“用户可导出、可删除、可撤销授权”的机制。同时反馈不应该被设计成“平台用来调模型的私有数据”而应该是一种“用户主动提交的对当前推荐结果的质量评价”。这两者的区别很大前者是平台资产后者是用户权益。3. 从一次“AI 推荐”看协议在真实链路里怎么走前面对模块的解释偏概念这一节用一个具体场景把协议贯穿起来。假设我现在要找一款适合个人开发者的日志分析工具需要支持开源、可以私有化部署、最好能跟我现有的 Prometheus 生态兼容。这个需求看似简单但真正走一遍会发现没有协议时整个过程很破碎有了协议后衔接会顺畅很多。3.1 没有协议时的典型状态先看没有协议时会发生什么。我打开搜索引擎输入“开源日志分析工具”得到一堆网页。我需要自己点开 Grafana、Loki、Graylog、SigNoz 等项目的官网自己确认它们的部署方式、数据存储、查询语言还要去社区看是否有对接 Prometheus 的例子。这个筛选过程可能要消耗几个小时。如果用 AI 助手我可以直接描述需求它会推荐几个工具并解释各自特点。但它的知识可能停留在某一个时间点产品版本、许可证、最新特性都可能过期。而且我想把这次提取的“需求描述”用到另一个工具上再比较一次时往往只能手动重新打一遍甚至重新组织语言。更麻烦的是AI 助手在回答时不会告诉你它参考了哪些候选集。它可能只从自己训练知识里回忆出三个常见项目完全没有覆盖到更小众但更适合你的方案。你作为用户不知道候选集是否完整不知道推荐的依据是什么也不知道该如何提供反馈来修正结果。整个过程就像身处一个黑箱。3.2 协议下的请求与响应示意如果采用了一套开放协议流程会变成这样。第一步我的 AI 客户端把用户意图结构化为一个请求。这里我用示意性 JSON 展示不代表某个真实协议已经定义了这个格式{ intent: { task: find-log-analysis-tool, constraints: { licensing: [open-source], deployment: [self-hosted], ecosystem: [prometheus] }, preferences: { priority: [documentation, community-activity] }, context: { user_level: individual-developer, previous_tools: [prometheus, grafana] } } }第二步这个请求通过协议接口发送给一个“产品发现网关”或者直接并行发给多个接入协议的产品目录。每个目录都有适配层把它自己的数据结构映射成协议中的“最小产品描述”。第三步各目录返回候选产品集。AI 模型接收到候选集后结合刚才的结构化意图做一次综合推理生成推荐结果。推荐结果的示意如下{ recommended_items: [ { product_id: loki, source: https://example-catalog/open-source/logging, matched_reasons: [open-source, self-hosted, prometheus-integration] }, { product_id: sigNoz, source: https://example-catalog/open-source/logging, matched_reasons: [open-source, self-hosted, full-stack-observability] } ], reasoning_summary: 两个工具都满足开源和自部署条件。Loki 与 Prometheus 同源适合轻量标签化查询SigNoz 提供更完整的监控与追踪面板适合需要统一定位到调用链的场景。, confidence: medium, uncertainty: 用户未说明日志量级和数据保留周期这部分会影响最终架构建议。, alternative_intents: [日志可视化, 链路追踪, 复杂日志检索] }第四步我基于这个结果继续追问“如果日志量每天大约 50GB哪个更合适”AI 会结合这个新约束进一步给出说明。这里的关键是因为意图、产品数据和推理依据都是结构化的对话上下文可以保留后续查询也可以继续使用同一套标准。3.3 为什么这种链路更可靠这个链路带来的直接好处是可控。用户可以看到 AI 到底基于哪些字段做了匹配。如果产品目录返回的许可证信息已经过期AI 引用的是过期数据用户通过evidence_refs能追溯到来源进而发现目录更新滞后问题。如果某个产品目录只返回了三个产品AI 可能基于不完整的候选集做判断用户也从协议输出中看到候选来源有限从而主动增加其他目录。更重要的是这次“需求快照”是可以迁移的。如果我在这个 AI 客户端里不满意可以把结构化的intent导出导入到另一个 AI 客户端继续对同一批产品目录发起查询。整个过程不需要我把需求重新用自然语言写一遍也不会丢失约束字段。这正是“开放协议”相比“平台内集成”的核心优势。用一张简表可以更直观看到差异能力传统搜索平台推荐普通 AI 对话协议化 AI 发现理解自然语言弱弱强强推荐依据可追溯无无不完整结构化证据用户偏好可迁移不可不可不可可导出可复用候选集来源可见部分可见不可见不可见可见用户反馈可回流弱弱有限结构化反馈当然这个表格里的“协议化 AI 发现”是理想状态真实落地会有不少条件限制。但至少能说明协议化不是在功能列表上做加法而是在用户控制权和数据可迁移性上做结构性改进。3.4 用户反馈怎么回流我再举一个反馈回流的小例子。AI 给我推荐了 SigNoz但我看了一眼后发现它的运维成本比 Loki 高我希望推荐结果优先考虑轻量级方案。我可以点击“修正偏好”把priority改成[low-ops, small-footprint]。这个修正会更新我的意图快照同时要求目录重新检索。在协议层面反馈不仅要影响当前一轮最好能进入一个“偏好档案”。当我下次做“选一个集群监控工具”这类新任务时AI 可以知道我对“运维成本”很敏感。这个档案不是历史聊天记录而是结构化后的决策偏好。它由用户自己持有可以被预览、修改和删除。这样反馈就不是“填进平台的黑盒”而是“写进用户自己的一个参数表”。反馈回流还需要考虑一个细节用户对某个产品的“不喜欢”有时候是因为信息不足而不是产品本身不行。协议要尽量把“产品不匹配”和“推荐解释不清楚”区分开。如果用户因为看不懂某个产品的部署模式而点“不喜欢”应该触发的是“解释维度补充”而不是直接把这个产品从候选集里降权。这个细节看起来小但实际会影响推荐结果的可信度和公平性。4. 接入前先理清几个容易踩坑的边界问题把概念说得再好真正落地时还是会遇到一系列边界问题。这些问题如果不提前想清楚项目很容易做成一个自嗨的规范或者一套没人接入的 API。4.1 协议解决不了数据质量问题首先要明确开放协议能保证“不同系统之间能对话”但不能保证“对话内容一定是准确的”。如果上游产品目录里的许可证信息是错的或者版本号已经落后那么无论协议多严谨AI 推荐出来的结果依然可能是错误的。这时候问题不在于协议而在于数据源。所以在设计协议时一定要给数据源加入“溯源”和“更新时间”字段让使用者可以判断信息的时效性。同时所有接入方都要建立自己的数据巡检机制。协议不会去帮你抓取产品信息它只负责承载你抓取到的信息。数据质量仍然是每个参与者的责任。如果你打算做一个产品目录最应该花精力的不是定义协议字段而是把产品的许可证、部署模式、维护活跃度这些核心信息维护准确。4.2 协议不是推荐算法别把两者混淆另一个常见误区是把“开放协议”当成“一个开源的推荐系统”。实际它们的关系是协议是算法之上的一层“接口约定”而推荐算法本身可以继续保持各家私有。也就是说协议允许两个平台都用完全不同的推荐算法但它们的输入和输出格式一致。就像 HTTP 协议不关心每个网站怎么渲染页面只关心请求和响应的格式。这个区分非常重要因为这意味着平台不需要把核心的算法逻辑开放出来也能参与到协议生态里。它的商业竞争力依然保留只是多了一个标准化的对接口。这个边界还能帮助开发者做判断如果你的项目目标是做一个“更聪明的推荐系统”那你其实不需要协议但如果你希望“不同系统的推荐结果能互通、可审查、可迁移”那你需要协议。很多项目一开始容易把这两个目标混在一起结果既没有把算法做好也没有把接口标准化。4.3 隐私、授权和审计不能事后补AI 媒介的产品发现会涉及到用户数据用户的任务、偏好、历史工具、上下文等。这些数据比普通的搜索关键词更敏感因为它能推测出用户的工作习惯、技术栈、甚至组织内部信息。协议必须默认遵循几个原则最小化只传输完成当前发现任务所需的最小字段。可授权用户可以针对不同数据源单独授权而不是一次性全部开放。可撤回用户可以在任意时刻撤销授权并要求删除相关意图快照。可审计所有向外传输的用户数据都要有日志记录便于用户查看去向。这里我特别想提醒一句不要等项目已经跑起来用户量上来了再考虑隐私设计。协议类项目一旦形成固定格式再改隐私模型成本会非常高因为所有参与方都要跟着升级。早期就应当在协议文档里加入“隐私级别”字段让数据源和 AI 客户端都知道哪些数据可以处理、哪些必须丢弃。4.4 要兼容已有系统而不是另起炉灶开放协议最怕的事情是设计出一套只存在于文档里的完美标准但跟现实里的产品目录、RSS、GitHub API、应用商店数据格式都不兼容。这样没人会接入。更务实的路径是设计“适配器层”。协议定义核心字段然后为常见数据格式写适配器。例如GitHub 仓库搜索接口可以映射到最小产品字段把full_name作为产品标识符description作为简介topics作为功能标签。应用商店的 API 可以映射到名称、类别、评分、价格等字段。自有产品目录可以直接输出协议格式也可以提供 JSON Schema 做映射。如果协议的接入成本高于“直接写一个私有脚本”那么数据源方就不会有动力加进来。所以协议的价值不仅取决于设计好不好取决于接入成本低不低。适配器库的建设应该和协议规范本身同步推进甚至前置。5. 落地时我建议的四步走方法如果你希望把“开放协议”这个概念引入自己的项目无论是做一个产品推荐服务还是想让自己公司的产品能被更多 AI 助手发现下面这套四步走方法会更务实。这个方法的思路是先跑通再扩展最后工程化。5.1 第一步先定义“最小产品描述”不要一上来就设计完整的协议标准先定义清楚你自己的最小产品描述。你可以先填一张表格列出你希望 AI 看到的产品字段。这里以“给自家产品做 AI 可发现化”为例字段示例值是否必填来源产品标识符openprotocol-demo必须内部唯一 ID名称Open Protocol Demo必须产品名一句话简介用于演示 AI 产品发现的开放协议必须产品一句话介绍功能标签ai,product-discovery,protocol必须产品关键词适用场景开发者工具选型、SaaS 推荐推荐运营自己定义价格模式free / subscription必须定价页部署模式cloud / self-hosted推荐技术文档许可证MIT/Apache-2.0条件必填开源项目必填最近更新日期2025-01-15推荐发版时间产品主页https://...必须官网定义完这张表你就有了一份可以被 AI 消费的最小产品数据。可以在项目里暴露一个公开接口例如/products.json让 AI 或外部应用能拉取并解析。不要小看这一步很多产品到现在连一个机器可读的产品名录都没有。5.2 第二步跑通一个单轮推荐闭环第二步是用一个最小示例把“意图表达 - 检索产品目录 - 生成推荐 - 用户反馈”跑通。原型越简单越好甚至可以不用真正的 AI 模型。一个常见的原型路径是用一个 JSON 文件保存“最小产品描述”。用一个脚本读取用户输入的约束条件例如“license 是 open-source 且支持 self-hosted”。对 JSON 做一次简单的字段筛选。把筛选结果拼接成一段带依据的推荐文本。打印推荐结果并同时输出一条 JSON 记录包含“匹配依据”。这个阶段的意义是验证你的数据字段是否足够支撑一个简单的推荐判断以及推荐结果是否能够被用户理解。如果连“根据许可证是自建所以推荐 A”这种最基础的解释都输出不了那就说明你的产品数据字段还没有定义到位。这一步还有一种更轻量的做法直接用表格和筛选条件在本地完成原型不需要写后台服务。核心是让“字段到推荐理由”的映射关系变得可见。你会发现一旦字段定义清晰推荐逻辑本身其实可以很简单复杂的是那些含糊的、没有结构化表达的用户需求。5.3 第三步把用户反馈接进来单轮推荐只能证明流程没断但还不能支撑长期使用。第三步是加反馈。你可以设计两个简单的反馈入口每个推荐项后面都有“符合我的需求 / 不符合需求 / 信息不足”三个按钮。用户可以选择“修改约束条件”重新发起一轮推荐。在后端反馈会被记录到用户偏好快照里。例如用户每次点击“不符合需求”系统都会记录是哪个产品、哪个约束不满足。积累到一定量后你就可以看出自己的产品目录里哪些产品描述容易被误推荐从而调整字段或做更精确的标注。反馈接入的难点不在技术而在产品设计如何让用户愿意反馈又不打断体验。最稳妥的方法是把反馈做得足够轻一次点击完成可随时撤回。同时要让用户看到反馈确实产生了影响。比如用户把偏好从“功能丰富”改成“低运维成本”后下一轮推荐列表要有明显变化否则用户会觉得反馈没有意义。5.4 第四步增加多数据源和监控当单数据源的流程稳定后可以开始接入更多数据源。比如你自己的产品目录之外再接入一个开源项目库和一个第三方评测站点的数据。这时协议的最大价值就体现出来了你不需要给每个数据源写一套完全不同的推荐逻辑只需要为每个数据源写一个适配器把它们的输出映射到“最小产品描述”。多数据源接入后一定要加监控。监控项至少包括数据源同步是否成功。数据字段的缺失率。推荐结果的点击率和反馈率。AI 模型引用过期数据的比例。这些指标不是用来证明“协议很成功”而是用来发现协议生态里的薄弱环节。比如某个数据源的产品描述字段缺失率很高导致 AI 在推荐时总是忽略它的产品那就要推动该数据源补齐字段或者在协议层建立“缺失字段的回退机制”。协议不是设计出来就结束的它需要持续运营。5.5 一个实用的排查链路如果接入过程中出现问题不要漫无目的地调参数。我一般建议按下面这个顺序排查看现象是请求报错还是推荐结果为空还是推荐质量不佳看意图解析先确认用户输入有没有被正确结构化成意图字段。如果约束条件解析错了后续全部会错。看数据源状态再确认数据源是否有返回返回的数据里“最小产品描述”是否完整。很多“推荐为空”的问题其实是某个必填字段缺失导致的。看匹配逻辑如果是自己写的规则筛选要看筛选条件是否和意图字段对应如果是 AI 模型推理要看候选集是否覆盖了足够范围。看输出解析最后检查推荐结果有没有被渲染出来证据引用是否正常。这个顺序的核心思路是先保证输入、数据和链路完整再怀疑模型能力。大多数问题都出在前三层而不是 AI 本身不够聪明。很多开发者遇到“推荐不对”的第一反应是换更大的模型或调 prompt但如果产品的字段本身就是脏的、缺的再强的模型也白搭。6. 这个方向真正的长期价值是什么走到这里我们得跳出具体接入步骤想一想这个协议方向到底会改变什么。6.1 对普通用户从“被推荐”变成“可协商”过去用户在产品发现中的角色是被动的。平台决定推荐什么用户就消费什么。即使有搜索搜索逻辑也是平台定义好的。当用户通过开放协议来表达意图、携带偏好、审查推荐依据时用户就成了一次次“产品发现任务”的参与者。这意味着 AI 推荐不是“一个人说另一个人听”而是“两个智能体协作”一个用户委托的 AI一个产品目录代理的 AI中间由协议来保证双方讲的话能互相理解。用户也能从被动接受变成主动修正这对体验的影响会比很多人想象的大。它把“推荐”这件事从“平台给答案”变成了“用户和 AI 一起找答案”。6.2 对产品开发者质量不再靠平台施舍以前产品方想被 AI 助手推荐只能投预算、做 SEO、想办法挤进某个平台的榜单。但是在开放协议下只要产品能提供一份准确的最小产品描述并接入到任意一个协议兼容的目录中它就有机会被 AI 理解并推荐。这更像是一场“内容质量竞争”而不是“渠道竞争”。当然这不会完全消灭营销动作。模型可能更偏好有丰富文档、有活跃社区、有清晰许可证的产品。但至少一个中小型开源项目不需要再去讨好某一个封闭平台它只需要把信息披露清楚并接入开放协议即可。这个变化对长尾产品尤其重要因为没有协议的世界里它们很难被 AI 的候选集覆盖到。6.3 对 AI 应用开发者多了一个可复用的基础设施对开发者来说开放协议最大的价值在于“不用重复造轮子”。如果你要做垂直领域的 AI 产品推荐工具不需要重新收集数据、重新定义字段、重新设计推荐输出的解释格式。你可以复用协议层的标准把精力放在更上游的意图理解和更下游的交互体验上。更重要的是多智能体协作时会遇到很多信息交换问题。开放协议可以成为智能体之间关于“产品发现”这个任务的一种共享语言。这相当于给“AI Agent 协作
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
