那天我只是想把一个已经做好的技能发布出去，第一步却卡在了登录。网页已经登录，命令行工具也确认过是最新版，屏幕上的报错却一直说凭证无效。重新复制、重新粘贴、重新打开终端，都没有改变结果。
后来我才发现，自己拿到的并不是个人命令行发布凭证，而是企业侧用于商户绑定的令牌。它们都像一串可以拿来“登录”的字符，甚至都由同一个平台提供，但背后的账户体系、页面入口、用途和权限完全不同。发布失败的第一现场，往往不是某个字符输错了，而是我们把不同能力当成了同一种能力。
一次登录失败暴露了两套体系
最开始的直觉很简单：既然网页上能看到企业功能，手里的企业令牌应该也能拿去命令行登录；既然命令行支持发布，那就用它把技能发出去。这个推断听起来顺，却忽略了一个前提：平台上的“账户”并不只有一种。
个人版通常有个人中心、个人密钥页面和面向公开社区的命令行入口。企业版则有团队后台、商户管理页、企业源和团队发布页。网页上的登录态可能是浏览器会话，命令行需要的是个人凭证，企业源又可能只接受另一种企业密钥，商户绑定还要单独使用绑定令牌。它们的外形相似，不代表可以互换。
这次真正有用的线索，是终端回显的前缀和长度。它既不是我以为的个人凭证格式，也不是一把可以直接发布的钥匙。顺着来源往回查，才确认它属于商户绑定流程。它不是“坏了”，只是被放到了错误的门前。
如果不处理这个区别，后面会出现更麻烦的连锁问题：我们可能反复重试登录，误以为命令行工具没有更新；也可能为了绕过失败，把企业凭证写入个人配置；再往后，自动化脚本会把一次身份判断错误扩大成多账户串号、错误发布，甚至触发不该执行的写入动作。
表面是凭证错误，实际是能力分流
我后来把问题重新表述了一遍：不是“这串凭证为什么不能登录”，而是“我现在要做的动作，属于哪一种账户体系”。这样一换问法，很多混乱自然分开了。
个人账户负责个人命令行登录，也可以把内容发布到公开社区。企业账户负责团队内部的技能库、商户关系和团队审核。企业源密钥可能只用于搜索、安装或访问内部资源，商户号与绑定令牌用于支付侧的关系绑定，开发者密钥则参与付费能力的校验。它们都可能被称为“密钥”或“令牌”，但权限边界不同。
这里最容易误判的是，把“能访问”理解成“能发布”。一个企业账号可以打开后台，不代表它能拿同一份凭证运行个人命令行；一个浏览器会话可以进入发布表单，也不代表脚本可以跳过团队审核；一个商户绑定完成，也不代表付费技能已经满足对外服务条件。
能力分流要先于自动化，只有先确定账户、凭证和入口的对应关系，后面的动作才有意义。
我选择先停下，不继续猜凭证，而是把页面和用途逐项对照。原因很现实：发布是写入动作，猜错一次的成本通常高于多花几分钟核对。尤其在企业场景里，错误不一定立刻报错，可能表现为“登录成功但没有按钮”“页面能进但提交被拒”，这比直接失败更容易让人走偏。
先画矩阵，再决定走哪条入口
这次之后，我给这类任务留下了一张很小的账户与凭证矩阵。它不需要记录任何真实值，只要记录四列：账户体系、凭证类型、允许的动作、对应的入口。
个人账户对应个人密钥页面和命令行入口，适合个人发布；团队账户对应企业后台和团队发布页，适合上传、提交和审核；企业源凭证只进入企业源相关能力；商户绑定令牌只进入商户绑定流程；开发者密钥则作为付费发布前的前置条件。这样做的价值不在于表格本身，而在于每次动作前都能先回答“我到底在操作哪一层”。
网页发布的流程也因此被拆成了几段。先进入正确的团队后台，确认当前登录的是目标团队；再上传包并填写展示信息，区分免费和付费模式；接着只做本地与页面预检，确认包内容、字段和计费条件；之后才是提交、管理员审核和对外公开。每一步都对应不同权限，不再用一个模糊的“发布”覆盖全部行为。
团队网页发布还暴露出另一个容易被忽略的事实：填写表单和真正提交不是一回事。前者可以反复检查，后者会把内容写入服务端；审核又是另一种责任确认；公开则会改变外部可见状态。一个按钮看起来像一步，实际可能包含多个不可逆的决定。
因此，自动化的默认状态应该停在提交前。预检可以自动做，表单可以自动填，截图和结果可以自动保存，但提交、审核、公开必须分别使用显式开关。这样即使前面的识别有误，也还有机会在真正改变外部状态之前停下来。
自动化不能把提交和公开绑在一起
当时确实有一种很诱人的做法：既然都已经登录了，干脆让脚本一路点完，从上传、提交到审核，再直接公开。它看起来最省事，也最像“全自动”。但我没有这么设计，因为这几步的风险和责任并不相同。
提交意味着平台收到了一份新内容；审核意味着管理员确认它符合团队要求；公开意味着外部用户可以看见并使用。免费和付费还要再分一次：付费模式除了包本身，还要核对商户是否完成绑定、开发者密钥是否存在、支付预检是否通过。任何一项缺失，都不应该被“自动继续”掩盖。
如果不拆开这些闸门，自动化失败时很难判断到底发生了什么。是包没有上传，还是表单字段不完整？是服务端拒绝，还是审核没有通过？是已经审核但尚未公开，还是脚本误点了公开？状态一旦混在一起，恢复就只能依赖人工猜测。
我更愿意把这看成一种边界设计，而不是保守。自动化不是把人的判断删除，而是把判断放在更靠前、更清楚的位置。只读预检负责发现问题，提交开关负责确认写入，审核开关负责确认团队责任，公开开关负责确认对外影响。每道闸都留下自己的结果，下一次才知道应该从哪里继续。
失败会告诉你预检漏了什么
第一次真实提交时，表单内容和分类看上去都正确，服务端却拒绝了上传。页面只显示了一句很笼统的失败提示，继续看接口返回才发现，压缩包里带了一个点开头的隐藏文件，而服务端不接受这种文件类型。
这个失败很有价值，因为它说明“本地预检通过”并不等于“服务端一定接受”。之前的打包规则只跳过了少数环境文件，没有把所有点开头的文件和目录纳入排除范围。修复后重新打包，提交才真正成功。
这件事让我重新意识到，预检不能只检查我们以为重要的字段，还要覆盖服务端实际会拒绝的边界。包里有没有隐藏文件、环境配置、状态目录和不该上传的依赖，和展示名、版本号一样重要。尤其是付费包，任何密钥、环境文件或本地状态残留，都可能变成安全问题。
失败之后还要回读服务端状态，确认没有重复记录。不能因为页面报错，就默认“什么都没有发生”；也不能因为重新提交成功，就忽略第一次是否已经留下半条记录。可靠流程的标志不是一次跑通，而是失败后知道发生了什么、没有重复什么，以及下一步该从哪里接上。
这也是我把提交结果按阶段记录的原因：预检结果、服务端响应、审核状态和公开状态分别保存。结果越具体，恢复动作越小。没有这些信息，所谓自动化只是把人从点击按钮的位置，换到了排查混乱日志的位置。
下次我会怎么做
下次遇到个人版和企业版同时存在的发布任务，我会先问自己 4 个问题：当前要发布到哪里，使用的是哪种账户，手里的凭证允许什么动作，真正的写入入口是哪一个。只有这 4 个答案对得上，才开始准备包和自动化流程。
接着我会画一张最小矩阵，不记录真实凭证，只记录账户、用途、入口和权限。个人发布走个人路径，团队发布走企业网页；商户绑定和付费校验单独处理；任何不能确认来源的令牌，都先停在只读检查，不拿去试登录。
执行时，我会把流程固定成预检、提交、审核、公开 4 道闸。默认只做到提交前，免费和付费分别检查对应条件；提交后回读状态，确认没有重复；遇到服务端拒绝，就把错误翻译成打包规则或表单规则，而不是盲目重试。
我最终想留下的，不是一条“自动发布”的命令，而是一条能解释自己为什么停下、为什么继续的路径。真正可复用的方法，不是记住某个平台的一串凭证，而是先做能力分流，再让每个入口只承担它应该承担的动作。