那天我在处理一套人物视频的发布流程。原来的流程主要依赖桌面方式运行，现在要把它接到浏览器里。表面上看，任务很简单：打开页面，上传视频，补上标题和正文，再选择声明原创，最后按日期安排发布。
但真正动手以后，我很快发现，问题并不是“能不能上传”这么单一。浏览器已经打开，却不代表它就是正确的登录实例；一个平台能跑通，也不代表另外几个平台可以照搬；干跑时按钮被点亮，也不代表真实发送时已经具备授权。更麻烦的是，如果几个身份和平台都挤在同一个窗口里，后续任何一次登录、切换或验证，都可能污染前面的状态。
多平台自动化首先要解决的不是发布动作，而是每个动作究竟发生在哪个身份和哪个浏览器实例里。
第一次卡住：打开了浏览器，却还没有入口
一开始我以为，既然浏览器已经打开，就可以直接沿着页面往下做。后来才意识到，“页面打开”只是视觉状态，不是流程状态。当前窗口可能没有登录，也可能登录的是另一个人物；即使登录了，站点的入口、上传方式和发布表单也不一定相同。
这次最先暴露出来的是，原有视频流程已经能够处理素材，却没有把标题和正文完整带到浏览器流程里。也就是说，上传动作存在，内容上下文却没有跟上。用户要的不是单独把文件放上去，而是让原来的工作能力在新入口中保持一致。
如果不处理这个问题，后面会导致一种很难排查的假成功：视频显示上传完成，发布页面却缺少标题、正文或原创声明。页面可能没有立刻报错，但内容已经不完整，人工只能在最后一步重新补，自动化节省下来的时间又被找回来了。
所以我先把“浏览器入口”拆开来看：它至少包含实例、身份、站点、素材、文案和状态回读。只有这些东西能对应起来，打开的页面才算真正可用的入口。
统一命名，是为了让身份可以被判断
接下来出现了一个看似琐碎、实际上很关键的决定：以后如果还有其他人物，也统一使用“浏览器加人物名称”的方式命名实例。这个命名不是为了好看，而是为了让人和流程都能快速回答一个问题：当前使用的到底是谁的登录态？
最容易误判的地方，是把窗口当成身份。窗口只是外壳，身份保存在浏览器实例和它的登录状态里。今天某个窗口打开的是人物甲，明天重新使用同一个窗口，可能已经切到了人物乙；如果流程只记住“浏览器已经打开”，就会把错误身份当成正常状态继续执行。
我选择按人物建立独立浏览器实例，是因为人物是最稳定的隔离边界。平台会增加，入口会变化，发布方式会调整，但同一个人物的内容和登录态仍然需要保持一致。这样做也让排查有了起点：标题不对，先看内容；平台跳错，先看站点；身份不对，先看实例，而不是在一堆窗口里猜。
命名规则的价值，不是让目录更整齐，而是让登录态变成可识别、可隔离、可回读的对象。
这件事让我重新意识到，自动化流程中的很多错误并不发生在点击按钮时，而发生在点击之前。只要入口没有被准确命名，后面所有动作都可能建立在错误前提上。
先盘点平台，再决定接入顺序
当用户提出要把多个发布站点都接入浏览器时，我没有直接把所有平台一起改完。先要盘点每个平台是否有浏览器入口，哪些已经具备基础能力，哪些需要补上传、封面、正文或定时发布，哪些仍然要保留原来的方式。
这一步看起来像准备工作，实际是在缩小风险面。不同平台的表单结构不同，有的平台上传后会进入编辑页，有的平台会把封面和视频分成不同步骤，有的平台在真实发布时还会触发额外验证。它们共享的是“发布”这个目标，不是同一套页面行为。
如果一开始就把所有站点一起接入，失败时很难知道问题来自哪一层：是浏览器实例错了，素材没有找到，选择器失效，还是平台本身没有完成授权。更糟的是，某个平台的临时修复可能顺手改变另一个平台的登录态，让一个局部问题扩散成整条链路的问题。
因此这次先选了4个平台做干跑，先验证浏览器入口、素材选择、正文填写和状态读回。这里的“先做”不是把其他平台永久排除，而是把一次大改拆成几次有边界的小验证。一个入口只有在能说明自己支持什么、暂时不支持什么时，才适合被接进统一流程。
干跑不是走过场，而是检查选择器和边界
干跑阶段不真实发布，只让流程走到能够观察结果的位置。它要验证的不是“脚本有没有报错”，而是每一步有没有落到正确的页面元素上：上传的是目标视频，封面选的是对应版本，标题和正文没有串到别的人物，定时日期读取的是正确内容，最后还能把页面状态读回来。
视频号的预览动作就是在这个阶段被补出来的。上传之后页面会自动播放，流程还需要点击视频区域让它暂停，再读回当前状态。这个动作看似与发布无关，却很有价值，因为自动播放会遮挡或改变页面状态，人工验收时也容易误以为页面仍在处理。把暂停纳入上传后的固定动作，实际上是在给预览阶段增加一个稳定的检查点。
这里最容易走的错误捷径，是把“干跑通过”当成“真实发布已经具备条件”。干跑只能证明入口、素材、文案和页面交互基本能走通，它不能替用户完成授权，也不能替平台取消二次验证。后续真实发布时，平台仍然可能要求短信验证，或者因为风险控制拦住发送。
干跑证明的是流程可达，不是发布权限已经存在；这两种结论必须分开记录。
我更愿意把干跑看成一次边界检查：它回答“流程会走到哪里”，真实发布则另外回答“平台是否允许这次动作发生”。如果把这两个问题混在一起，成功时会过度自信，失败时又不知道应该查代码、查登录态还是查授权。
平台隔离，避免登录态互相污染
在这次接入里，平台和人物都需要隔离。一个人物可以有多个平台，但不能因为它们都在浏览器里，就默认共用一个窗口；同一个平台也可能存在不同人物的身份，更不能用“最近打开的页面”代替明确实例。
我判断按人物和平台建立独立车道是更稳妥的做法，因为发布动作本身会改变页面状态。上传文件、选择封面、填正文、设置时间，都会让当前页面进入下一阶段。如果中途切换站点或身份，流程可能还在继续，但它继续的已经不是原来的任务。
这种污染最难发现的地方，在于结果有时看起来仍然合理。标题可能是完整的，视频也可能上传成功，只是发布到了错误身份，或者把另一个平台的封面带了过去。等到发现问题时，通常已经进入不可逆的真实发布阶段。
所以我把每条车道都看成一份小合同：它有明确的人物、平台、浏览器实例和素材范围；流程开始前先确认合同，流程结束后再读回结果。合同越清楚，自动化越不需要依赖临场记忆。
授权门槛，要和技术能力分开
这次还有一个容易被忽略的结论：并不是所有平台都要马上登录。后续暂时没有内容要发的平台，可以先不登录，等到有实际内容时再进入对应车道。这样做不是少做一步，而是减少无意义的登录和状态维护。
但到了真实发送环节，干跑通过仍可能被二次验证拦住。这说明技术能力和平台授权是两条线。前者包括能否打开入口、找到控件、上传素材和回读状态；后者包括登录是否有效、是否需要短信确认、平台是否允许当前设备执行定时发布。
我选择把授权、二次验证和真实发布单独列为门槛，是因为它们都需要外部条件，不能靠继续点击来“碰运气”。自动化可以把验证码入口、等待状态和失败信息整理清楚，但不能把用户没有提供的授权凭空变出来。
表面上我是在接多个发布网站，其实我是在设计一套不会把“能操作”误写成“能负责”的流程。这个区别很重要：只有完成状态回读、授权确认和真实结果核验，才可以说发布完成。
下次我会怎么做
下次遇到类似的多平台发布需求，我会先建立一张最小车道表：人物是谁，平台是什么，浏览器实例叫什么，素材和文案从哪里来，当前只允许干跑还是允许真实发布。表不需要复杂，但每一项都要能改变下一步动作。
然后我会按这个顺序推进：先确认实例和登录态，再盘点平台入口；先选少量平台做干跑，再补齐上传、封面、正文、定时和状态读回；确认页面交互稳定后，才单独处理授权和真实发送。任何一个平台出现问题，都先留在自己的车道里定位，不把临时修复扩散到其他平台。
我还会把“上传后暂停预览”这类小动作保留下来。它提醒我，流程的完成标准不只是文件被提交，还包括页面进入可验收状态。真正可靠的自动化，不是把每一次点击压缩到最少，而是让每个关键状态都能被看见、被判断、被记录。
一个成熟的发布流程，不是一次把所有平台都跑通，而是下次接入新平台时仍然知道先隔离什么、先验证什么、什么结果还不能宣称完成。
这也是统一浏览器车道真正带来的价值。它没有消灭平台差异，却把差异放进了清楚的边界里；没有替代人的授权判断，却让人知道什么时候必须介入。工具真正改变的不是速度，而是我们愿不愿意把身份、入口、状态和失败原因留下来，让下一次不用从混乱的窗口开始。