那天我在盘点草稿能力时，原本想确认的是一个很直接的问题：如果不打开界面，能不能创建、修改、覆盖和验收一份草稿？看了一圈之后，答案其实比想象中清楚。创建可以走文件和结构化规格，只读验收也已经有了判断草稿能不能打开的能力，修改和覆盖则分别有各自的入口。
真正卡住我的，是“注册”这一步。文件已经写进某个目录，不等于草稿库已经安全地接收了它。尤其当以后会有很多程序同时交付文件时，注册动作如果只负责搬运，就可能把半成品、坏稿或互相覆盖的版本直接放进可见的草稿库。草稿交付的完成，不是文件出现在目录里，而是它通过验收后，以可追踪、可恢复的方式进入目标位置。
文件存在，不等于草稿交付成功
我一开始也差点把问题理解成“把注册器接出来就行”。只要调用方能把准备好的文件交给注册器，注册器再把文件放到目标目录，流程看起来就闭环了。但这个闭环只是运输闭环，不是交付闭环。
草稿至少有 3 个不同状态：内容被创建出来，内容能够被验收，内容被注册到草稿库。创建解决的是“有没有产物”，验收解决的是“产物是不是可用”，注册解决的是“可用产物如何进入另一个系统”。这 3 件事可以由不同程序完成，却不能因为都围绕文件，就把它们压缩成一个“写入成功”。
如果不区分这些状态，后面会出现很具体的问题。一个程序写完目录结构就返回成功，另一个程序马上去注册；注册器只看到文件齐全，却没有确认内容能否打开。结果可能是草稿库里多了一份无法打开的稿子，后续人工只能在界面里猜它是生成失败、复制不完整，还是注册时撞上了并发写入。
这件事让我重新意识到，自动化交付最需要保护的不是某一次文件操作，而是状态之间的边界。只有把“准备好”和“已接收”分开，系统才有机会知道自己到底完成了哪一步。
先把已有能力分清楚
盘点时，我没有把“非界面化”当成一个总开关。创建可以完全不依赖界面，不代表验收、修改、覆盖和注册自然都具备同样的路径。它们面对的风险不同，验证方式也不同。
创建关注的是能不能按照结构化规格生成一份草稿；修改和覆盖关注的是旧版本如何被替换，是否会误伤其他内容；只读验收关注的是不改变原文件的前提下，能否判断它是否可开、结构是否满足最低要求；注册则要处理从准备区到草稿库的交付边界。
这里最容易误判的错误捷径，是看到几个入口都已经存在，就认为“所有草稿能力已经暴露”。实际上，一个能力能被某个底层程序调用，和它已经被统一门面安全地提供给其他程序，是两回事。前者说明能力存在，后者还要说明入口稳定、参数边界一致、失败语义可理解。
我选择先画清这几层，是因为只有这样才能判断缺口到底在哪里。如果把非界面化和只读混为一谈，就会漏掉修改时的覆盖风险；如果把底层存在和门面暴露混为一谈，就会让每个调用方自己拼装注册流程；如果把注册成功等同于文件复制成功，就会把验收责任推给最后一个使用者。
缺口不是没有注册器，而是没有接上正门
继续往下看，真正的发现并不是“系统没有注册能力”。相反，注册器本身已经包含了比较完整的保护语义：写入是原子的，更新会做并发版本判断，重复请求可以幂等处理，失败时能够回滚，注册后还能触发必要的热重载。
但它没有接入统一门面。门面已经暴露了主要的草稿能力，验收器也已经在那里，唯独注册器仍然像一间有设备却没有门牌的房间。熟悉内部结构的人可以找到它，其他调用方却只能自己猜路径、猜参数、猜什么时候算成功。
一个底层能力即使已经足够完整，只要没有进入稳定的统一入口，它就还不能算是安全的公共能力。
这个判断很重要，因为直接让每个程序调用注册器，看上去能更快满足“很多程序都要注册”的需求，实际上会制造很多份不一致的约定。有的调用方先复制再检查，有的先检查但检查的规则不同，有的遇到冲突就覆盖，有的则静默失败。最后，问题不在注册器本身，而在大家都绕开了同一扇门。
注册前复用同一个验收器
接下来最关键的取舍，是注册前的验收怎么做。最省事的表面方案，是在注册流程里重新启动一个验收命令，等它输出“通过”后再继续。这样当然能工作，但它会把一个已经存在的判断能力重新包一层进程通信，增加启动、输出解析和异常归因的机会。
我判断更稳妥的方式，是直接复用验收器已经提供的可调用判定。它有一个不会因为普通不通过就抛出异常的结果判断，也有一个可以作为门槛使用的检查入口。注册流程拿到准备好的草稿后，先在当前流程里调用同一套验收逻辑；只有 verdict 通过，才进入真正的注册；如果不通过，就保留失败原因，不触碰目标草稿库。
这样做的理由不只是少起一个子进程。更重要的是，创建、单独验收和注册前验收使用的是同一套判断标准。否则，单独验收说“可开”，注册前的另一套简化规则却说“文件齐全”，两者之间就会出现一条危险的缝。
当时还确认了一个容易被忽略的兼容性问题：创建流程原本是通过子进程调用注册器，而不是直接把注册器导入进来。因此给注册器增加注册前的验收门，不会静默改变已有函数调用方的内部行为；那条调用路径也会自然获得同样的保护。这是一个很小的结构事实，却决定了修复可以落在共享入口，而不是到每个调用方逐个补丁。
原子、幂等和回滚分别守住什么
验收通过之后，注册本身还不能只靠“复制完成”。原子写入解决的是半成品可见问题：先在临时位置完成准备，确认成功后再一次性替换目标状态。这样，其他程序看到的要么是旧的完整版本，要么是新的完整版本，不会看到只写了一半的目录。
并发版本判断，也就是 CAS 这类保护，解决的是“我以为目标还是刚才那个版本”的问题。两个程序同时准备覆盖同一份草稿时，后提交者不能假设目标没有变化。它必须带着自己看到的版本来提交；如果期间已经被别人更新，就拒绝这次覆盖，而不是凭最后一次写入的时间决定谁赢。
幂等解决的是重复交付。网络重试、上层超时或调用方没有及时收到回执，都可能让同一份草稿再次提交。若每次重试都产生一个新版本，重复请求就会污染草稿库；幂等语义让同一个交付标识重复到达时，不会重复制造副作用。
回滚解决的是注册中途失败。目标状态发生变化后，如果后续热重载或索引更新失败，系统不能只留下“文件似乎已经进去”的半成功状态。它需要回到上一个可确认的版本，或者明确把失败留在隔离区，等待后续处理。热重载也不是装饰，它决定了注册成功后，使用者看到的是否真的是刚刚交付的内容。
这些保护不是同一件事的不同说法。原子性挡住半成品，并发判断挡住互相覆盖，幂等挡住重复副作用，回滚挡住中途失败，热重载保证交付结果能被后续消费者看见。可靠注册不是加一道“写入成功”的提示，而是让每一种失败都停在一个可以解释、可以恢复的状态。
把创建、验收、注册排成一条事务
从这次盘点里，我最后抽出的是一条有顺序的交付流程。第一步生成草稿，生成阶段只负责产出准备区里的内容，不急着宣布它已经进入草稿库。第二步做只读验收，确认文件结构、必要信息和可开性满足要求。第三步进入注册门，注册前再次复用同一验收器，避免准备区和正式交付之间发生变化后仍然照常提交。
通过之后，注册器在隔离位置完成写入，并用原子替换提交；提交时带上目标版本判断，冲突就拒绝；重复请求按幂等规则处理；中途失败则回滚或留在明确的隔离状态；最后完成热重载，并返回可以追踪的交付结果。
这里的“事务”不一定意味着把所有步骤塞进一个巨大函数。它更像一份必须遵守的顺序契约：前一步没有得到可验证的结果，后一步就不能把它当成成功。每个阶段可以有不同实现，但必须有明确的输入、输出和失败边界。
这个方法以后也能复用到其他批量交付场景。只要一个系统要接收外部生成的文件，就应该先问：什么条件证明它是可用的？什么动作算正式接收？并发时谁有权覆盖？重复请求会不会产生重复结果？失败后回到哪里？如果这些问题只能由每个调用方临时回答，系统就还没有真正形成交付门。
下次我会怎么做
下次再遇到“能不能让外部程序批量注册草稿”的需求，我会先把创建、只读验收、修改覆盖和正式注册分开盘点，不用“都能不打开界面”这句话替代能力清单。然后确认每项能力是否已经进入统一门面，以及底层实现是否被所有调用方共同使用。
对注册流程，我会坚持把验收放在提交之前，并优先复用已经验证过的判定函数，不再让注册器自己发明一套更宽松的规则。正式写入时，继续保留原子、版本冲突、幂等、回滚和热重载这些语义，并分别记录它们解决的风险。
最后，我会把“文件存在”“验收通过”“注册完成”“消费者已看到”作为 4 个不同的结果来报告。这样即使批量交付中有一份失败，也能知道它停在哪一层，不会把坏稿写进正式草稿库，更不会因为一次超时就重复制造结果。
这件事让我重新意识到，系统真正的安全感不是来自“大家都知道怎么写文件”，而是来自“任何人都必须经过同一套可验证的门”。一个流程成熟的标志，不是它允许更多程序直接操作，而是它让更多程序在共同边界内安全地操作。