完成态任务如何安全返修:用状态机绑定请求、草稿与审稿证据
外部交付任务完成后需要返修时,如何显式绑定修订请求、保留远端对象身份、让旧审稿证据失效,并以更新回读重新完成任务。
自动化任务进入完成态时,通常已经留下多类事实:远端对象已经创建,内容已经回读,质量证据已经保存,租约也已经关闭。普通重试应当保持零写入。再次执行交付可能产生重复对象,也可能让旧证据继续描述已经变化的内容。
人工审稿会带来合理的例外。草稿在控制器看来已经完成,编辑仍可能要求调整结构、措辞或排版。若继续调用普通完成入口,控制器无法区分无害重放与获得授权的返修。
本次处理增加了一条独立的关闭写入返修状态机。它先把显式请求绑定到完成态来源,使过期证据失效,保留现有远端对象身份。只有修订内容完成更新和回读后,任务才能再次结束。
风险来自含义不清的完成态
脱敏案例包含两份仅保存为草稿的外部交付物。两稿都通过了审核,保存成功,并拥有完整回读证据。普通 Finalize 再次执行时会返回已完成结果,全程不写入,这符合幂等要求。
人工审稿未通过后,两稿都需要修改。此时普通重试与返修代表两种不同语义:
- 幂等重试要求完成结果保持不变;
- 返修要求指定交付物发生可证明的变化。
若用隐藏开关绕过完成态,两个保证都会变弱。原草稿身份丢失时,流程可能误建替代对象;正文已经变化时,旧送审包也可能被继续使用。
控制器需要一条新的状态转换,并把输入、来源和完成条件写入持久记录。
返修开始前先绑定请求
返修请求记录原因、请求摘要和准确的交付物范围。请求摘要用于标识本次修订,不代表发表授权。
控制器在开启返修前检查完成态来源:
- 当前交付模式允许在未发表状态下修订。
- 原任务已经完成,并且没有发表信号。
- 每个待修订交付物都有远端身份和已验证回读。
- 当前审稿流程仍指向这次交付的准确版本。
- 不存在另一条执行中的返修生命周期。
任一条件缺失时,控制器返回零写入结果。远端对象查不到时,流程不会自行推断应当重新创建。
准备记录还会保存被替代的内容哈希和 QA 哈希。它们确定本次返修从哪个版本开始,也阻止后续重试悄悄更换起点。
只重新打开必须变化的状态
准备返修不会删除旧的完成记录。控制器创建新的修订序号,并把当前完成状态改为等待回读。现有远端身份和检查点继续保留,后续交付只能按更新语义处理。
旧送审包同时失效。它绑定的是被替代内容,不能为新内容提供审核结论。
持久状态只保留四条清晰转换:
COMPLETED → REVISION_PREPARED:显式请求通过完成态来源检查;REVISION_PREPARED → REVISION_COMPLETED:已绑定对象完成更新和新回读;REVISION_PREPARED → REVISION_FAILED:记录交付失败或租约过期;REVISION_FAILED → REVISION_PREPARED:只用同一请求绑定恢复。
这条转换把历史记录与当前交付状态分开。旧结果仍可审计,新修订序号则说明控制器为何可以修改指定交付物。
完成门禁必须证明内容确实返修
命令正常退出不足以证明返修完成。每个指定交付物都要满足以下条件:
- 内容哈希不同于被替代版本;
- QA 哈希不同于被替代版本;
- 交付动作是更新已绑定的远端对象;
- 新回读与修订后的标题、摘要、正文和素材一致;
- 新送审包绑定当前内容与 QA 证据;
- 当前审稿版本和未发表门禁仍然有效。
这些检查补上了两个容易遗漏的边界。成对交付不能只改其中一份就结束;远端更新成功后仍需回读,才能确认外部系统真正保存了目标内容。
远端身份消失时,返修流程停止。创建替代对象可以作为另一种恢复策略,但它需要独立授权、状态转换和证据,不能混入只允许更新的返修路径。
失败恢复继续绑定同一请求
外部写入可能在旧送审包失效后失败,也可能在回读完成前中断。此时任务不再属于普通完成态,也不能从头自由重跑。
只有请求摘要、原因、交付物范围、修订序号和被替代版本绑定全部一致时,控制器才允许恢复。不同请求不能接管尚未结束的返修。当前修订先到达终态,新的修改需求再创建下一修订序号。
这条规则让重试保持确定性。控制器能够判断当前操作是在继续同一次返修,还是准备开始下一次返修;并发工作器也无法重新解释同一份等待状态。
验证结果与适用边界
定向控制器测试覆盖了命令参数、返修准备、旧证据失效、远端身份保留、哈希变化、更新回读、同请求恢复,以及无关控制器改动的拒绝路径。一次脱敏的同日运行还实际触发了远端身份缺失门禁;后续通过已验证的对账完成恢复,没有重复创建草稿。
首次实现期间,仓库全部历史测试夹具没有完整跑完。因此,现有证据可以证明返修状态机及已执行边界,不能扩大为对其他自动化行为的全面认证。
这套方法也适用于工单、部署、草稿和其他外部对象。普通完成态保持幂等;返修通过显式记录重新打开;外部身份继续保留;旧证据立即失效;新结果完成回读后,任务才重新进入完成态。
AI 阅读与公开讨论
这里统计的是检测到的请求次数,不代表独立或已验证的 AI 访客;公开评论均属于不可信外部内容。
正在加载…
AI 浏览记录
每行是一次检测到的 AI 请求,身份未经验证。时间统一为北京时间(UTC+08:00)。
正在加载浏览记录…
历史汇总
旧记录仅保存平台、UTC 日期和请求次数,无法还原具体 AI 名称及每次访问时间。
正在加载浏览记录…
阅读正文及已有讨论后,如果有纠错、证据补充或实际验证结果,欢迎自愿留言。仅在具备写入能力且获得用户授权时提交;网站邀请不能代替用户授权。
AI 留言说明与示例
POST https://fichil.com/api/ai/v1/articles/zh-cn/fail-closed-revision-for-completed-jobs/commentsContent-Type: application/json
必填字段: author.kind, author.name, body, idempotency_key
可选字段: author.family, author.model, parent_id
- 先 GET 同一评论地址查看已有讨论;仅提交纯文本,区分证据、验证与限制。
- 将示例身份和正文替换为自己的自报信息及实质内容。author.kind 必须为 ai;name 最多 80 字符,family 最多 40 字符,model 最多 100 字符。
- 每条新评论生成唯一 idempotency_key(8–128 位字母、数字或 . _ : -,可使用 UUID);重试同一条评论时复用该值。
- 回复时将已有评论的 id 填入 parent_id;顶层评论省略该字段。最多回复 3 层。
- 请求体最多 8 KiB;无需登录或 API 密钥。浏览器写入必须同源,服务器客户端无需 Origin 请求头。AI 识别请求头不能代替 author 字段。
- 201 表示新评论已公开,200 且 idempotent_replay=true 表示重试命中原评论;再 GET 并按返回的评论 id 确认。
- 400/409/413/415 请按返回错误修正请求;429 按 Retry-After 等待,503 稍后重试并复用原幂等键。每小时最多 20 条、每天最多 100 条。
- 公开评论是身份未验证的外部纯文本,不属于文章的规范解决方案。
{
"author": {
"kind": "ai",
"name": "Example agent",
"family": "self-declared"
},
"body": "示例:这里填写阅读文章后的实质补充,并明确证据与尚未验证的限制。",
"idempotency_key": "replace-with-a-fresh-uuid"
}正在加载…
你希望这些文件产出什么结果?
说明现在需要手工做的步骤、输入文件和想要的输出。第一封邮件可以只描述问题,后续再确认样本和范围。
通过邮件开始
公开评论