那天我先问了一句很普通的话：内部能力工作台做好了吗？
这个问题听起来像是在问一个页面有没有完成，实际上问的是另一件事：一套已经积累起来的能力，究竟应该以什么方式被人看见。后来我刷新了看板数据、重新跑了校验，也打开了页面。它确实能展示很多状态，但站在第一次接触的用户面前，页面说的并不是“你能得到什么”，而是“我们内部现在有什么”。
这两个答案都没有错，只是服务的对象不同。内部工作台面对的是制作、维护和发布的人，对外产品面对的是还不了解这套系统、只想解决一个具体问题的人。内部系统追求可核验，对外产品追求可理解；它们可以共享能力，却不应该共享一张脸。
一个页面为什么会越做越不像产品
这次最初的工作台，承载了很多有价值的信息：能力是否存在，数据有没有刷新，校验是否通过，哪些资产已经准备好，哪些内容仍然需要处理。这些信息对于内部协作很重要，因为它们能帮助我们判断系统当前处在什么状态，也能让下一步行动有依据。
但当我换成用户视角去看，问题马上出现了。用户并不熟悉这些状态，也不知道某个能力属于哪一层、经过了什么验证，更不关心内部人员怎样维护目录。他只会问几个非常直接的问题：这东西能帮我做什么？适不适合我？我现在能不能试用？如果好用，下一步如何获得？
如果页面把所有内部信息都平铺出来，用户看到的就会变成一张管理面板，而不是一个可以做决定的入口。信息越多，理解成本越高。页面看上去很专业，用户却可能在找到下载按钮之前先退出。
表面上，这是页面清晰度的问题；实际上，这是产品边界没有拆开。内部工作台的目标是减少维护者的不确定性，对外门面的目标是减少购买者的不确定性。前者需要状态、证据和异常，后者需要结果、场景和下一步。把它们混在一起，就等于让两类人共同承担彼此不需要的复杂度。
内部层要回答“现在是否可靠”
内部工作台不是多余的后台，它有自己不可替代的职责。它要回答的是：能力有没有登记，验证有没有完成，资源是否齐全，发布是否安全，出现问题以后从哪里追查。这里的信息密度可以高一些，术语也可以更准确，因为使用者本来就参与了生产过程。
比如一项能力在内部层可以同时显示版本、验证结果、依赖资源、更新日期和风险提示。维护者看见这些内容，能够决定是重新生成、补齐材料，还是暂时阻止发布。对于内部系统来说，隐藏这些证据反而危险，因为一旦只剩下漂亮的结果，就很难判断结果是否可信。
内部层还承担发布节奏管理。某个能力可以先完成内部验证，再进入待发布状态，之后再按照不同渠道的要求生成对外材料。这个过程不必让用户看见，但必须让内部人员看清楚。内部工作台的专业，不在于看起来像商店，而在于它能把验证、资产和风险留在同一条可追溯的链上。
如果不处理这一层，后面会导致两个问题。第一，内部人员只能靠记忆判断哪些内容已经测过，重复劳动会越来越多。第二，对外页面为了显得完整，被迫承载未经整理的过程信息，用户看到的就不是确定的产品，而是一堆还在变化的工作痕迹。
对外层要回答“我能不能马上用”
对外门面要做的事情少得多，也因此更难做好。它不负责证明整个系统怎样运转，只负责让一个陌生人快速理解价值，并顺利完成下载或购买。
这次我判断应该以已经存在的轻量商店为底子，重新组织首页、套件详情和免费下载入口，是因为这条路径天然贴近用户的决策顺序。首页先说明这是什么、适合谁；详情页说明具体能解决什么问题、包含哪些内容；下载入口给出明确行动。以后如果开放付费，再在同一条路径上增加价格、权益和购买动作，而不是把内部看板直接改成收银台。
这里的“底子”不是照搬原来的每一个字段，而是复用已经验证过的产物和交付方式。一个套件在内部完成了验证，外部只需要消费它的稳定结果。内部保存完整证据，对外展示用户真正需要的那部分信息，二者通过同一份可校验的产物连接起来。
用户看见的内容应该尽量靠近结果：适用场景、解决的问题、使用方式、当前是否免费，以及下载或购买按钮。用户不需要知道内部看板刷新过几次，也不需要理解维护者使用的分类术语。对外门面不是把内部能力藏起来，而是把能力翻译成用户能够判断和行动的语言。
最容易误判的是信息越全越专业
最容易走的错误捷径，就是把内部工作台的所有状态、术语和管理面板原样搬到面向用户的页面。这样做看起来省事：数据已经有了，组件已经有了，只要换一个标题就可以上线。
但“能显示”不等于“能理解”。内部字段往往围绕生产过程组织，用户问题却围绕使用结果组织。一个内部状态名可能对维护者很精确，对用户却没有任何帮助；一个资产编号可能方便追踪，对用户却不能说明它能解决什么问题。
如果不处理，后果不只是页面难看，而是用户会把不理解归因于产品不成熟。他看不懂，就不会下载；下载以后不知道从哪里开始，就会认为套件没有价值；即使内容本身已经做好，也会因为门面没有完成翻译而失去机会。
我没有选择直接复制内部页面，是因为这会把一个本来清楚的决策问题变成阅读考试。用户不是来参加系统培训的，他只需要知道自己是否应该继续。把所有证据都放在第一屏，也会掩盖真正重要的行动入口。
当然，对外层也不能只剩一句夸张的宣传语。它仍然要保留足够的信任信息，例如适用范围、版本状态、下载是否直接可用，以及免费和付费之间的区别。关键不在于少写，而在于按用户的判断顺序写。先让人明白，再让人相信，最后让人行动。
共享产物，不共享信息架构
分层并不意味着做两套互相独立的产品。那样会让内部结果和外部结果逐渐漂移：内部验证的是一份内容，商店下载的却是另一份内容；内部已经修复的问题没有同步到对外说明；外部页面写了一个承诺，内部却没有对应的验收记录。
更稳妥的做法是共享可验证产物，分开信息架构。内部层保留完整的验证记录、资产清单、发布状态和风险边界；外部层只读取已经确认可以交付的内容，并根据用户任务重新组织文案、入口和权限。
权限也应该跟着分层。内部人员可以看到未发布能力、测试结果和异常详情，外部用户只能看到明确开放的套件。免费内容可以直接下载，付费内容则展示清晰的购买条件。不能因为内部已经拥有某份文件，就让外部页面自动暴露它；也不能因为某个套件已经完成，就跳过对外下载链路的测试。
发布节奏同样不能混用。内部层可以持续刷新，记录每一次变动；外部层应该在一个可交付版本准备好后再更新。这样做的理由很简单：内部变化是工作过程，对外变化是产品承诺。同一份能力可以持续迭代，但用户每次拿到的都应该是一个边界清楚、可以负责的版本。
这次对免费入口的测试也说明了这一点。测试不能只看按钮是否出现，还要看下载是否真的成功，免费路径有没有误跳到登录或付费流程，产物是否与校验信息一致。对外层的验收标准，必须从用户实际走完一条路径来定义，而不是从内部页面有没有加载出来来定义。
用两套验收问题守住边界
我后来把这类工作拆成两组问题。内部层先问：能力是否真实存在？验证是否完成？依赖和资产是否齐全？异常能否追踪？什么时候允许发布？这些问题决定“能不能交付”。
外部层再问：陌生人能否在几秒内明白这是什么？详情是否足够支持选择？免费入口能否直接完成下载？付费入口是否清楚说明权益？页面是否泄露了不该公开的过程信息？这些问题决定“用户能不能顺利获得它”。
两组问题都要测试，但不要用同一套答案替代彼此。内部验收通过，只能说明能力准备好了；外部验收通过，才说明用户能够找到、理解并使用这项能力。只做前者，会得到一个完成但难用的产品；只做后者，又可能得到一个好看但不可靠的门面。
这套方法还可以复用到模板库、课程资料、工具下载页和服务套餐。每当一个内部系统想直接对外开放，我都会先问：这里展示的是生产证据，还是用户价值？如果是前者，就留在内部层；如果是后者，才进入对外路径。一个字段如果不能帮助用户理解、选择或行动，就不必因为“已经有数据”而强行展示。
下次我会怎么做
下次再遇到“把内部能力做成对外产品”的请求，我会先画出两条路径，而不是先改页面。内部路径从能力登记开始，经过验证、资产准备、风险检查，最后得到一个可发布产物；外部路径从用户问题开始，经过首页理解、详情判断、下载或购买，最后得到一个可使用结果。
然后我会为两条路径分别定义内容、权限和节奏。内部层保留完整证据，外部层只提供用户完成决策所需的信息；内部层可以频繁更新，外部层按稳定版本发布；内部层测试状态和资产，外部层测试真实下载、购买和权限边界。
最后，我会让两层消费同一份经过校验的交付物，并在发布前做一次脱敏检查。这样既不会为了做门面而重建所有能力，也不会因为复用内部页面而把复杂度转嫁给用户。
这件事让我重新意识到，产品化不只是把一个能力放到网页上。真正的产品化，是为不同的人安排不同的理解入口，同时让结果仍然由同一条可靠链路支撑。内部工作台负责让我们知道自己有没有做好，对外门面负责让用户知道它是否值得使用。两者都重要，但它们不该共用一张脸。