今天要问的是：有没有 Agent 在和这个产品交互？

访谈把清单写清楚：五年前你会问，我们怎么组织这些信息、搜索引擎怎么工作；今天你还要问，有没有 agent 在和这个产品交互？我们需要 llms.txt 吗？我们需要 MCP 服务器吗？

问题换代，不代表答案必须昨天就全上。先问对，再排期。把 MCP 写成「明天 Baklib 已是你们的 Agent 网关」，是把问句偷换成已交付——本篇明确分开。问句可超前，交付不能超卖。超卖的代价不是「听起来落后」，而是团队把预算与注意力花在空管线上，肚子里仍是过期 PDF。

企业与更小团队在 AI 发现上的投入差距不小。忽略这些问句，等于自愿把新渠道让出去；把问句听成「已经上线」，等于自愿把空管线当成绩。清单换代的真正含义，是发现策略的检查项变了：除了「搜索引擎怎么收」，还要问「助手侧有没有在碰我们的产品事实，碰得到的是不是现行结构」。

国内团队可以把这张清单翻译成周会语言：本周有没有客户用内部助手问过我们的产品？伙伴开发者有没有在 IDE 里搜过我们的对接说明？客服侧边栏问答有没有在答「权限 / 导出 / 开通」？有，就说明 Agent（或准 Agent）已经在交互——不管你们有没有正式项目名叫 MCP。没有看见，不等于没有发生；只等于你们还没把「交互」写进发现策略的观察面。

观察面一旦建立，下一步不是立刻上更深集成，而是问：交互碰到的事实，是现行页还是过期附件？很多团队在这里才第一次承认——Agent 早就在交互，交互的却是垃圾上下文。

传统搜索仍大；AI 搜索、编码助手、业界讨论中的 MCP 一类通道，已从几乎可忽略长到没法假装看不见。公开观察里，传统搜索发现与 AI 搜索都已是可观比例；企业与微型公司在 AI 发现上的差距明显。计划投入跳得快的，往往正是助手与 MCP 一类项——跳得快，更要分清「规划项」和「已交付」。

跳得快也容易跳错：把「计划评估 MCP」写成路线图没问题；把评估当成上线，会让发现策略停在概念层。数字提醒你们渠道已变；纪律要求你们别用概念图替代可检索真源。

用户问助手「哪家能导出、权限怎么隔离」，助手的参照系里若没有你们，候选名单里也就没有你们。发现失败可以发生在比价之前：不是输在功能表，是根本没入场。答案引擎优化与GEO提供发现侧自检语言——不是「进了参照系=已买广告」，是「事实与结构能不能被答案引擎与生成式入口稳定拿到」。投放可以把人送到官网；送到助手肚子里的，仍是可检索、已发布、带版本的页。

提示工程 改变不了「根本没被收录的现行页」。先有可检索真源，再谈提示怎么问。提示词团队可以把问题问得更漂亮；文档侧若只有网盘 PDF，漂亮问题也只会引出漂亮的空答案或漂亮的错答案。发现策略若只优化站内 SEO，而忽略助手通道，等于只修了一扇旧门，侧门已经在进客。

国内还有一种「数字幻觉」：文档站 PV 稳定，就以为发现策略健康。PV 不统计「有多少次助手在别处替用户决定了候选名单」。AI 发现不是零头时，健康指标要愿意多看一眼：高风险说明是否已发布且可深链；问答是否只读已发布库；销售是否还在转发不可检索的附件。

企业与更小团队的投入差距，也常表现为问句成熟度差距：大团队已经在排「要不要评估 MCP」，小团队还在争论「文档站要不要改版」。两边其实可以共用同一阶第一步——先让关键事实可被拿到。第一步不贵，贵的是跳过第一步直接画集成图。

发现侧自检时，把「助手有没有提到我们」和「提到的是否现行」分开看。提到旧版本，比完全没提到更麻烦：你们出现在参照系里，却以错误形态出现。GEO / AEO 类问法要盯的，不只是出现，还有出现得对不对。

「出现得对不对」还可以落成三块高风险说明：权限、导出、关键集成。这三块若过期，助手越会说，越像官方事故。发现策略若只庆祝「被提到了」，会把错误引用当成成功。

可执行的第一步通常是：分类与版本立住；关键能力写成已发布块；按需提供 llms.txt；问答只读已发布库。再评估是否需要更深的 Agent 集成或 MCP 一类通道。顺序反了，管线概念图很漂亮，肚子里仍是过期 PDF。llms.txt 可以是入场券之一，但单独不够——长页仍会被截断，根子仍是块好不好、能不能单独成立。

把「需要 MCP 吗」写进路线图没问题；把路线图条目写成「已开通」才有问题。问句清单换代，是为了让排期有新检查项，不是为了让发布会多一个已勾选的幻觉。

关于RAG：行业里常把「检索再生成」当作助手读企业知识的路径。Baklib 侧诚实边界是——检索已发布内容再总结，人能点回原文；不吹逐句高亮溯源，也不把公网常识冒充你们的产品事实。RAG 是能力边界说明，不是营销魔法词。边界说清楚，采购与实施才不会把「能问答」听成「每句都有法庭级出处」。

国内团队可以把本周问句缩成三句：有没有 Agent / 助手在碰我们的产品事实？三块高风险说明（权限、导出、关键集成）是否已发布且可深链？我们是否误把「需要 MCP 吗」听成「已经上了 MCP」？答完这三句，再排更深的集成。答「否 / 否 / 是」的组合很常见——常见不可怕，可怕的是用概念图掩盖这三句。

再补一条治理味的提醒：结构先立住，不等于永远不做更深集成。问句清单换代，正是为了让排期有顺序：先让事实可被拿到，再谈通道怎么铺。通道可以规划进路线图；已发布块可以本周验收。可验收的优先于可演示的管线动画。

关于诚实边界，再钉一次：检索再总结，解决的是「有料可吃、能点回原文」；它不自动等于「每一句都有高亮出处」。采购若把后者当成前者的捆绑承诺，上线后一定会失望。把边界写进方案书，比事后解释「RAG 不是魔法」便宜。

Baklib 能给的，是让这些新问句有可执行的第一步——而不是把行业问句包装成「已开通」。第一步通常长这样：开发文档与帮助类叶子有稳定结构；高风险说明已发布；对话只读已发布库；需要时补 llms.txt。做完这些，再讨论更深集成，才有讨论的底座。

开发文档 承接规格与接口表征：错误码、权限、集成限制写成可版本、可深链的页，供人与助手共同引用。AI 客服 只读已发布库，检索再总结，人能点回原文——这是 RAG 边界在到达层的落点，不是逐句溯源承诺。结构化发布与 llms.txt 可写；MCP 留在行业问句与规划里，SaaS 主路径不写成已开通网关。先结构、先真源、先可深链，再评估更深集成——顺序本身就是产品诚实。

落地时可以把「问题清单换代」写进发现策略一页纸：旧问句（搜索怎么收、目录怎么组织）保留；新问句（有没有 Agent 在交互、要不要 llms.txt、要不要评估 MCP）单列；每条问句旁写「本周可验收动作」与「尚未承诺的交付」。一页纸比十页战略更管用——因为它强迫你们把问句和交付拆开写。

一页纸上还可以加一列「诚实边界」：RAG = 检索已发布再总结，人能点回原文；不等于逐句高亮溯源；MCP = 行业问句与规划项，不等于 SaaS 主路径已开通网关。边界写在纸上，比写在事后解释里便宜。

今天要问的是：有没有 Agent 在和这个产品交互？问完，先给结构与可检索真源。有了第一步，后面的集成才不是空管线。没有第一步，问句越新，落空越快。