这次遇到一个很容易把人带偏的问题：一个刚推出不久的桌面版应用出现了。它看起来像是一个新产品，也确实多了桌面窗口、菜单、登录态和后台运行这些体验。于是最先冒出来的念头是，要不要给它单独做一套能力，还是把它并入已有的网页版流程？
我一开始也差点沿着“桌面版是不是新入口”去组织工作。后来把它的实际形态、能做什么、数据存在哪里，以及以后会不会变化放在一起看，才发现问题不在入口。真正要决定的是：哪些能力应该只有一份真源，哪些差异必须单独适配，未来升级时怎样只补变化而不推倒重来。
我先被入口问题带偏
当时的场景很具体。桌面版刚出现，用户希望先熟悉它，再判断应该新建一套能力，还是让已有网页版能力继续统一调配。桌面版和网页版在很多地方看起来一样，都能进入同一个创作页面，完成相近的生成和取数动作；但桌面版又多了一层本地壳，似乎值得单独研究。
如果只看表面，最容易得出两个结论。第一个是“既然是新应用，就复制一套技能”，这样入口清楚，短期也容易开工。第二个是“既然页面一样，就完全当作网页版”，这样代码少，却可能漏掉桌面窗口、登录分区、更新机制和后台控制这些真实差异。
这两个结论都有一半正确，也都有一半危险。**桌面版和网页版的区别，不能决定能力应该复制几份；它只能决定入口适配要承担什么。**如果这里判断错了，后面每一次流程修改都要同时改两套，改了一边忘了另一边，最后看起来有两个“专家员工”，实际上没有一个真正知道哪份规则才是最新的。
真正要拆的是能力层、入口层和状态层
我后来把问题拆成了3层。第一层是原厂能力，也就是提示词、模型、生成规则、任务结构、结果取数和业务限制。这些东西描述的是“能做什么”，与它从浏览器打开还是从桌面窗口打开没有直接关系。第二层是入口适配，负责页面驱动、桌面壳控制、调试通道、窗口可见性以及登录状态的接入。第三层是本地状态，包括缓存、配置、登录分区和可能存在的数据库落盘。
这3层如果混在一起，桌面版每增加一个按钮，就会被误认为增加了一项业务能力；网页版每改一个取数流程，也会被误认为必须把桌面版完整重做。拆开之后，归属就清楚了：共用能力只保留一份，入口差异放进适配层，本地状态单独记录并设置边界。
我选择这个拆法，是因为它同时解决了现在和未来的问题。现在，桌面版可以作为一个新的执行入口，复用已经成熟的网页版能力；未来，桌面版即使新增原生功能，也只需要在入口层或状态层增加接线，不必把共享的能力真源复制一遍。
这件事让我重新意识到，所谓“统一”，不是让所有东西看起来一样，而是知道哪些东西必须统一，哪些东西必须保留差异。统一错了，会抹掉真实边界；分开错了，会制造重复劳动。
后台运行和落盘状态不能混为一谈
用户随后把问题问得更深：如果拿到了调试通道，能不能尽量后台运行？桌面版有没有自己的数据库或其他本地落盘？这两个问题看似都属于桌面端，实际指向不同风险。
后台运行关心的是“怎么操作”。桌面应用是否能在不抢前台的情况下被驱动，取决于调试通道、窗口控制和页面上下文；它不应该改变生成能力的归属。落盘状态关心的是“数据在哪里”。桌面版可能保存登录分区、缓存、项目索引或更新信息，但这些本地文件不能自动被当成业务真源，更不能因为看到了数据库就把它直接接进主流程。
我会先区分可观察事实和推测：确认有没有本地状态目录，确认它保存的是配置、缓存还是业务记录，再判断能否安全读取。对于登录态和敏感数据，只验证边界，不把凭据导出成新的依赖。对于业务数据，优先使用页面自身已经发出的、可验证的只读通道，避免为了省一次页面操作而绕过安全校验。
**后台能力解决的是执行时机，落盘状态解决的是数据边界；两者都属于入口适配，却不能替代能力真源。**如果不处理这个区分，后台脚本可能误把缓存当成完整数据，数据库分析也可能变成一条脆弱的旁路。表面上操作变快了，实际却更难判断结果是否可靠。
新入口不等于新能力
这次还有一个容易混淆的地方：桌面版看上去拥有自己的窗口和操作面板，似乎应该把每个页面动作都重新定义一遍。可如果这些动作最终仍然落在同一套网页能力上，那么所谓“桌面版能力”很多时候只是同一能力换了一个进入方式。
如果把每个入口都当成一个独立产品，最容易走的错误捷径就是复制入口、复制取数逻辑、复制一套状态管理。这样做看似支持了更多场景，实际上只是把同一个问题复制了很多遍。今天网页版流程改了，明天桌面版流程漏改；两边都能运行，却很难保证它们理解的是同一个任务。
所以我会把任务、对话和结果这些业务概念先放在能力层说清楚，再让不同入口去承接。网页版的页面操作经验不能因为桌面版出现就丢掉，桌面版新增的后台通道也不能未经验证就取代原有流程。未来即使出现多个窗口、多个工作区或更多客户端，变化也应该发生在适配层，而不是把业务定义复制到每一个入口。
真正有价值的验证，不是证明“桌面版也能点通”，而是确认同一项能力在不同入口下仍然遵循相同的边界、命名和结果判断。**自动化的可靠性，不在于入口能不能点通，而在于换了入口以后，它仍然知道自己在完成什么。**这也是能力层比入口层更重要的原因。
升级要留一根增量接线位
用户还提醒了一件非常现实的事：桌面版刚推出，后面一定会反复升级。今天看到的窗口、调试接口、数据位置和页面桥接方式，不能被写成永远不变的前提。否则第一次分析很漂亮，下一次版本升级就只能从头猜。
我更愿意把升级处理成一个小型的版本哨兵。每次先记录当前版本、关键资源指纹、入口地址、可观察的桥接能力和本地状态布局；升级后再做差异清单。没有变化的部分继续复用，发生变化的部分标出影响范围，只对受影响的适配和回归验证做增量修改。
最容易误判的是，把“版本号变了”理解成“整套能力都要重做”，或者把“页面还能打开”理解成“所有旧结论仍然成立”。前者会让维护成本随版本累积，后者会让错误悄悄进入生产流程。我不会直接这么做，是因为桌面壳的变化和网页能力的变化并不同步，必须分别判断。
如果不留下这根接线位，下一次升级时会出现两个后果：一是重复建设，团队重新盘点已经确认过的能力；二是遗漏变化，旧的取数或后台假设继续运行，却没有人知道它已经不适用。增量更新不是为了少写几行代码，而是为了让每次变化都留下可追踪的范围。
下次我会怎么做
下次再遇到一个新的桌面入口，我会先问4个问题。它复用了哪些原有能力？它新增了哪些入口差异？它有哪些独立状态需要观察？下一次升级时，哪些事实可以被自动比较？这4个问题比“要不要新建一套技能”更早，也更接近真正的架构判断。
具体流程会先确认能力真源，再建立入口适配，最后盘点本地状态和版本基线。涉及后台运行时，先验证能否不抢前台；涉及数据库或缓存时，先确认数据性质和隐私边界；涉及多任务、多轮对话时，先用稳定标识、分页和完整性检查验证取数，不用屏幕上当前可见的几张卡片代表全部历史。
我最终想保留的规则很简单：桌面版可以是新的门，但不能因为门不同，就把房间复制一遍。**一个成熟的自动化系统，应该让入口可以变化，让能力保持连续，也让升级只需要接上新增的那一段。**这样以后再出现新的客户端、新的页面或新的后台通道，我们面对的就不是一次从零开始的熟悉，而是一套能够继续生长的能力系统。