那天要做的事情听起来很简单：把一个语写 Agent 免费放到技能平台上。目标已经说得足够清楚，方式也像是自动化最擅长的那种任务——准备好目录，打一个包，跑发布流程，然后等它完成。
但流程真正跑起来以后，我没有立刻把“自动上架”理解成“一条命令跑到底”。本地包已经准备好，最佳实践预检没有错误和告警，dry-run 也通过了。看起来最难的部分已经结束，偏偏状态信息提醒我，团队账号还没有登录，需要真人在网页上扫码。
我在这里停了一下。免费发布并不等于没有边界。打包是本地动作，登录是身份动作，提交是对平台发起请求，审核通过是平台状态变化，公开发布更是面向外部用户的结果。它们都可以被一条自动化链路串起来，但不能因此被当成同一件事。
一个流程能自动连续执行，不代表它在授权上就可以连续通过。
表面上是上架，实际上是几种状态
如果只看用户目标，整个任务只有一个动词：上架。可是系统不会只产生一个“成功”或“失败”。它至少要回答几组不同的问题：包是否构建完成？包里的内容是否通过预检？当前登录的是不是正确的账号？提交有没有被平台接收？审核是否结束？技能现在是否已经对外可见？
这些问题的答案可能同时不同。一个包可以已经生成，但预检仍有问题；预检可以通过，但登录状态缺失；提交可以成功，但审核还在排队；审核可以通过，但公开发布还没有发生。把它们压扁成一个状态，短期看起来省事，后面却很难判断到底卡在哪里。
这件事让我重新意识到，自动化的第一责任不是把动作做得更快，而是把状态说得更准确。只要状态准确，下一步才有依据；如果状态含糊，所谓自动化只是把猜测执行得更快。
最容易误判的是“能打包”
最容易走的错误捷径，是把“本地能打包”当成“已经可以上架”。这次暂存包里有需要发布的文件，也有本地离线运行用的目录。后者不能顺手塞进发布包，否则平台拿到的内容就和预期不同。打包成功只能证明文件被收集、压缩或整理完成，不能证明内容符合平台规则。
所以我先做最佳实践预检，再做 dry-run。预检回答的是“这个包有没有明显违反要求的地方”，dry-run 回答的是“如果真的提交，系统准备提交什么”。两个动作都没有改变平台上的外部状态，却能提前暴露很多问题。一个检查内容，一个检查动作，两者缺一不可。
如果不处理这一层，后面会出现的问题不只是发布失败。更麻烦的是，包可能已经被提交，平台记录了一个不完整版本，之后再排查时还要区分是内容错误、参数错误，还是账号权限错误。预检和 dry-run 的价值，是把可以在本地发现的问题，留在本地解决。
登录不是一个可以代填的参数
这次还有一个容易被自动化掩盖的细节：个人版和团队版的登录状态不是一回事。本机已有团队侧的信息，但个人侧没有登录状态，而团队技能只能走网页发布流程。即使某个账号显示“已登录”，也不能推断另一个账号同样可用。
这里最容易误判的是，把登录理解成命令行里的一个选项。实际上，登录代表“谁在授权这次操作”。尤其在需要真人扫码的场景里，自动化可以打开页面、填写已知字段、等待结果，却不能把扫码这一步伪装成系统已经完成。它需要把控制权交还给真正有权限的人。
我没有让流程绕过扫码，也没有把缺失的个人登录状态当成无关紧要的小问题，是因为账号类型会改变发布对象和权限边界。用错账号，哪怕最后出现了一个成功页面，也可能是把技能放到了错误的空间里。真人介入不是自动化失败，而是身份边界被正确保留下来的表现。
这也解释了为什么一个好的流程会在这里暂停，并明确告诉人下一步该做什么：在哪个登录入口操作，需要扫码，完成后系统会继续检查什么。暂停点应该是可理解、可恢复的，而不是一句模糊的“等待中”。
提交、审核和公开发布不能混为一谈
登录完成以后，流程仍然没有结束。提交只是把材料交给平台；审核通过说明平台接受了这份材料；公开发布则意味着外部用户可以看到或使用它。这3个动作的影响范围逐步扩大，授权强度也应该逐步提高。
如果把提交、管理员批准和公开发布写成一个不可回滚的黑盒命令，最危险的地方不是它偶尔失败，而是它可能在用户没有意识到的情况下继续往下走。用户说“免费上架”，通常是在表达目标，不一定是在表达“请无条件执行所有外部状态变更”。免费只说明价格模式，不等于可以跳过确认。
我选择把这些门分开，是因为每一步都能留下一个可核对的结果：提交后有提交编号或受理状态，审核阶段有轮询结果，公开发布后有对外可见状态。遇到失败时，也能判断应该重试当前步骤，还是需要真人重新授权，而不是从头再来一遍。
这里还有一个实际的边缘情况：提交成功不代表审核已经完成，轮询中断也不代表审核失败。如果把“没有及时读到最终状态”直接写成“发布失败”，就可能重复提交；如果把“提交成功”写成“已经公开”，又会对外传递错误信息。只有读回与当前阶段对应的结果，才能宣布这一阶段完成。
把每一道门写成输入和输出
后来我更愿意把这类流程看成一串有边界的门，而不是一条线。每道门至少要写清3件事：它接收什么输入，完成后产生什么输出，允许谁推动它通过。
第一道门是打包。输入是待发布的技能目录和版本信息，输出是一个可以被检查的暂存包，权限范围仍然在本地。第二道门是预检和 dry-run。输入是暂存包和发布参数，输出是检查结果与待提交元数据，不应产生平台上的真实变更。第三道门是登录。输入是目标账号和真人授权，输出是明确的登录状态，不能用另一个账号的状态替代。
第四道门是提交。输入是经过核对的包、展示信息和免费模式，输出是平台已接收的记录。第五道门是审核。输入是提交记录，输出是审核中的、通过的或拒绝的状态。第六道门才是公开发布，输入是已经通过审核的版本，输出是外部可见的页面或可用状态。
这样的拆分看起来比“一键发布”麻烦，却让流程具备了回读能力。每一步都能回答“现在在哪里”“下一步是什么”“如果不继续，已经改变了什么”。一个流程成熟的标志，不是它能跑通一次，而是它在下次少依赖临场记忆。
我更愿意把这看成一种工作习惯，而不是一个技巧。凡是涉及账号、审核、对外可见性或不可逆变化的自动化，都应该先把状态拆开，再决定哪些步骤可以自动推进，哪些步骤必须停下来交给人。
下次我会怎么做
下次再遇到免费技能上架，我会先把“上架”改写成一张小的状态表，而不是直接寻找一条最长的命令。先确认发布对象、版本和价格模式，再在本地完成打包、预检与 dry-run；随后单独检查个人或团队登录状态，确认账号和目标空间一致。
在提交前，我会把待提交的元数据重新读一遍，确保展示名、版本、摘要和包内容都是这次要发布的东西。提交动作单独记录结果，审核状态单独轮询，公开发布再作为最后一道授权门。任何一步没有得到对应的明确结果，就停在当前门，不向后猜。
如果需要真人扫码或确认协议，我会把它标记为人工节点，说明操作位置、成功标志和系统会继续做什么。这样人的介入不是一个突然出现的阻塞，而是流程设计的一部分。若审核仍在处理中，我会报告“已提交、等待审核”，而不会为了让结果看起来完整，提前写成“已上架”。
这次最值得留下的，不是某个技能最终有没有出现在平台上，而是我终于把“免费发布”从一句目标，拆成了几组可以核对的承诺。真正可复用的发布方法，不是把所有动作塞进一键，而是让每一道门都只承担它能够证明的那件事。