1. 金句：人留在产品里，知识跟过去
往后的总体趋势会是把最终用户留在你的产品里——无论是新功能的应用内提示，还是应用内文档本身，而不是设法把人推到你的文档站点去。
被绕开的，常常是「必须新开一个站、重新找目录、重新建立情境」这条路，不是知识本身。人还在办任务：开通、改权限、导出报表、对接单点登录。知识若跟不过去，人就会去搜群文件、问同事、问外面的助手——口径继续分叉，还多绕一圈。你们以为「文档站 PV 还不错」，现场却是用户宁可用企微里那条口述，也不愿意再开一个标签页。
趋势不是宣布文档站死刑。文档站仍可承接规格、深链、SEO 与需要安静阅读的长说明；变的是默认期望：用户希望少跳转。门牌可以在产品里——设置页旁的「？」、开通向导里的说明、功能空态上的「查看步骤」；事实源仍应在可治理的真源里。门牌跟着人走，货不应跟着门牌各养一份。
国内 SaaS 现场里，这句话几乎不用翻译。产品经理已经在争论「要不要做应用内引导」；客成功已经在抱怨「客户从不看帮助中心」；市场已经在问「为什么文档站流量和续约无关」。争论的焦点若停在「要不要文档站」，会偏题；更准的问法是：用户所在之处，能不能拿到现行事实，而不必先完成一次「离开产品再找目录」的仪式。
仪式成本很高：新开标签页、重新搜、重新判断「这篇是不是给我们这个版本的」。用户一旦学会绕开仪式——问同事、翻群文件、问外面的助手——你们的文档站再完整，也只是旁路。旁路多了，真源再正确也进不了任务现场。
2. 产品内帮助已经是主流渠道之一
公开观察里，产品内帮助已是重要到达渠道之一。访谈认为文档站形态会变，信息流仍关键——变的是形态与默认路径，不是「以后不需要可核对的说明」。国内现场同样：设置页旁的「？」、开通向导里的说明、工单里粘贴的帮助链接、空态上的短步骤，往往比「请访问我们的文档门户」更常被点。
「更常被点」不等于「更常是对的」。产品内入口若链到过期拷贝，错误会获得官方感。所以趋势金句要配一条纪律：入口可以留在产品里，事实必须仍能回到真源发版。
客户自助服务 的体验，越来越要求步骤出现在任务现场。人卡在「导出」按钮旁，最想看到的是这一步怎么做、谁有权限、失败会怎样——而不是先学会你们文档站的信息架构。全渠道体验 则要求：产品内提示、帮助中心、官网说明说法一致——渠道多，事实源一。渠道各养一份拷贝，用户留在产品里，读到的仍可能是过期契约；而且因为「就在产品里」，过期看起来更像官方。
不把 Baklib 写成已交付的「应用内文档 SDK」。能讲的是：真源可嵌、可链、可同源发布到多个入口；产品里怎么嵌控件、怎么做引导气泡，仍是你们的产品工程。平台侧把事实养清楚、发得出去；产品侧决定门牌开在哪一层。边界划清，才不会把「一处写、多处到达」听成「我们替你们做完应用内文档层」。
还有一种「留在产品里」的假象：客户端硬编码长文案，发版才改得动。人是留住了，知识却焊死在安装包里。真源跟不过去时，「应用内」反而成了过期说明书的高级包装。
另一种假象是「只留对话框」：产品里嵌了问答，却没有可点回的现行帮助页。人是留住了，核对路径断了。留人不是目的，留人且留对才是目的。对，来自真源；对话框只是门牌之一。
国内联合验收可以很短：产品经理点开设置页「？」，打开的是否仍是现行帮助；发版改了默认值之后，这条链是否还指向旧文。链断了或链旧了，「把用户留在产品里」就只剩半句趋势金句。
验收还可以加一条客成视角：客户成功是否仍在群里粘贴飞书旧步骤，而不是产品内 / 帮助中心的稳定链接。人留在产品里，知识却从群文件旁路进来，等于留人失败了一半。
3. 没有真源，每个入口各养一份过期拷贝
入口越多，没有真源时拷贝增生越快：产品内文案一份、帮助中心一份、官网一份、销售 PDF 一份、客服话术一份。人留在产品里，只是让错误发生得更近、更像「官方」。近，意味着更少人怀疑；像官方，意味着更难归因到「文档没更新」。
拷贝增生还有组织原因：每个入口背后常有不同主人——产品写引导、市场写官网、文档写帮助、销售改 PDF。主人多不是问题；没有共同真源才是问题。没有真源时，各自「更新自己那一份」会变成竞赛，竞赛的终点是口径战争。
内容复用 在这里是基础设施动作：一处维护任务说明，产品内链到现行页，帮助中心与官网同源出口。复用失败时，「把用户留在产品里」只会把过期步骤嵌得更深。复用成功时，改一处默认值，该亮的门口一起亮——产品内提示链到的仍是现行页，而不是上周焊死的句子。
国内最小闭环可以很克制：关键路径（开通、权限、导出）在帮助中心有现行页；产品内入口链到这些页，而不是在客户端硬编码长文。硬编码改不动时，帮助页还能发版——这才是「知识跟过去」，而不是「文案焊死在安装包里」。第二步再谈：空态与向导是否引用同一真源；客服话术是否转发稳定 URL；官网能力说明是否与帮助页同口径。闭环先小，再扩，比一上来做全站应用内文档中台更可验收。
再补一句容易混进邻近主题的边界：本篇不讲「知识只能活在对话框里」或「后端如何定义知识住所」——那些是另一篇文章的骨架。这里只钉到达策略：人在哪，现行事实就要能跟到哪；跟得过去的前提，是真源先立住、复用先跑通。
「跟过去」也可以很克制：先链后嵌。先保证产品内入口能打开现行帮助页；再谈要不要做更重的应用内阅读体验。克制的好处是可验收，且不把平台能力吹成应用内 SDK。
4. Baklib：一处写，多处到达
Baklib 更常交付的是「一处写，多处到达」的中台与叶子，而不是替你们完成应用内 SDK。SDK 是产品工程的选择题；中台是事实能不能同源发出去的基础设施题。题没分清，采购会上很容易买错期待。
帮助中心 承接任务说明，提供可嵌、可链的现行页；品牌官网 与其他叶子门脸不同、事实可同源——官网讲故事与能力边界，帮助讲此刻怎么做完；知识中台 立树干，让资源、知识、体验别各挖一口井。多站点 / 多入口同一真源；帮助可嵌、可链。不吹应用内 SDK 文档层——那是产品工程边界；平台边界是：真源住得下、找得到、发得出。
落地检查可以贴进产品与文档的联合清单：关键路径是否有现行帮助页？产品内入口是否链到这些页而非硬编码？官网与帮助是否同口径？发版改默认值时，是否有人负责回到真源再发出去？过这几问，「把用户留在产品里」才从趋势金句变成可运营的到达策略。
联合清单还建议写清边界：Baklib 负责真源与多入口发布；应用内控件、引导气泡、埋点与交互仍归产品工程。边界清楚，才不会在方案里把「可链可嵌」写成「已交付应用内文档 SDK」。
人留在产品里，知识跟过去。跟得过去的前提，是真源先立住。否则每个入口都在留人，也在留错——留得越近，错得越像官方。
