写操作应按出错后的可恢复程度分阶段放开：先选能撤回、影响范围小的动作，审批等代表人员判断的动作留在后面。执行结果以目标系统单据和页面回执核验。
本文中的筛选、回退和观察清单是实施建议；具体动作是否可撤回、异常怎样恢复及记录范围，应以目标系统和项目验收为准。
只读查询跑顺之后，业务侧通常会问一句：什么时候能开始写单据。这个问题跟只读跑了多久关系不大，跟「哪一类动作错一次还能收回来」关系很大。
新建一条记录、改一个字段、推进一步状态、点一次同意，四件事错一次留下的东西完全不同。混在一起讨论，结论只能是要么全开、要么全不开；拆开排个队，路径就出来了。
下面按放开的实际顺序写：四类动作怎么排、首轮选哪一类、确认点停在流程哪一步、每种失败配哪条退路、放开后两周看什么、什么情况下扩大或收回去。
一、四种写动作，错一次留下什么不一样
同一句「让 AI 帮我写单据」，落到系统里是四类动作。四类动作的实现难度接近，拉开差距的是错了以后能不能恢复原样。
| 动作类型 | 常见例子 | 错一次会留下什么 | 能不能自己撤回 | 首轮适合度 |
|---|---|---|---|---|
| 新建 | 新建采购申请、新建客户档案、新建报价单 | 多一条记录，一般不覆盖他人数据；但可能已触发通知、占用额度 | 可作废或删除，前提是没被下游引用 | 适合，优先带草稿态 |
| 修改 | 改交期、改数量、改收货地址 | 覆盖原值，原值往往没人留档 | 能改回，但得知道原来是什么 | 谨慎，只放字段白名单 |
| 状态推进 | 提交审批、确认发货、关闭工单 | 流程往前走一步，通知已发出 | 只能用反向动作，原状态回不去 | 后放 |
| 审批 | 同意、驳回、加签 | 一个人的判断落到单据上 | 撤销要走撤销流程，且别人已据此行动 | 最后放 |
表里容易被低估的是「修改」。它看起来比新建轻，麻烦却大：新建多一条记录，作废就行；修改是覆盖，改完之后原始值可能只在某个人的记忆里。真放开这一类，字段要挑，改动前后的值要留，否则一次批量修改过后，谁也说不清原来的交期是几号。
「审批」排在最后，是因为它代表一个人的判断，跟技术难度无关。AI 把依据找齐、把意见草拟出来，点同意的那一下仍应由有权限的人来做。这一下被代点了，责任归属就模糊，后面追责只能追到系统。
排序之后还有一件事要提前想：一个能力里塞的动作越多，出错的入口越多。既有新建又有审批的能力，两类风险落在同一个人手上，首轮不要这样配。
二、首轮选哪一类：五条筛选标准
排序只解决「谁先谁后」，具体放开哪一项能力，还要用五条标准过一遍。五条不必同时满分，但缺两条以上，这项能力就不适合做首轮。
- 错一次能撤回：能作废或改回，不必打电话请供应商把货退回来。
- 只影响一张单据、一个环节，不连带改库存、应收、供应商评价这些别人正在用的数据。
- 判断依据在系统里查得到，AI 填进去的每个值都能指回一条原始记录，员工核对时有地方看。
- 频率高、金额小，省下的人工看得见，错了损失也可控。
- 员工原本就在这个页面办事，沿用原有页面与原系统权限，不额外开一条新通道。
按这五条筛，采购申请、费用报销单、售后工单这类「新建 + 可作废」的动作通常排在前面；价格与账期字段的修改排在后面，一改就动钱，原值还常常没人留；审批同意放到最后，签的是人的名字。
有一种中间做法经常被提到：只放开「保存为草稿」。它确实把风险压得很低，但提交之后的那一段，它一点也测不到，目标系统认不认、校验规则卡在哪、同一条动作触发两次会不会出两张单，都要真提交才看得见。草稿可以当台阶用，替代不了首轮的放开。
三、确认点停在哪一步
讨论人工确认，容易停在「要不要」这一层，结论往往是一句「关键操作都要确认」。要定下来的是停在哪一步，三种停法效果不一样。
- 停在预填之后、提交之前：AI 在原业务页面里把字段填好，员工逐个核对，自己点提交。这一种最常用，员工看得见每个字段，责任清楚，也便于当场改。
- 停在草稿：AI 生成草稿落库但不提交，员工到单据列表里接着办。适合一次生成多条、需要集中复核的场景；代价是草稿会积压，得有人定期清。
- 停在业务动作之后、审批之前：只适合流程本来就分两段的业务，比如先确认收货、再走付款审批。它替不了前两种，尤其不能拿来给写操作补一道确认当免责。
无论停在哪一步，有一条边界不变：页面预填不等于提交成功。字段填满只说明准备做完，办成没办成，要看页面回执或目标系统里的单据状态。
还有一件容易混的事：员工点了确认，不等于数据范围被放开。连接器这一层判断的是这个人能不能调用这项能力，具体返回哪些客户、哪些金额，仍由 ERP、MES 这些目标系统按他的功能权限与数据权限再判一次。把人工确认当成权限校验的替代品，两类风险会混在一起，出了事两边都说不清。
四、每种失败配一条退路
放开之前，把可能出的错列一遍，每种配一条退路，谁执行写清楚。写完这一步，才算具备放开的条件。
| 失败情形 | 会看到什么 | 退回动作 | 谁执行 |
|---|---|---|---|
| 字段填错，员工没看出就提交 | 单据已生成，值不对 | 改回原值或作废重开，保留改动前后的对照 | 经办 + 主管 |
| 同一条动作被触发两次 | 两张内容相近的单据 | 作废后一张，回头查触发源 | 经办 + 平台管理员 |
| 目标系统拒绝 | 报错，未落单 | 不用退回，改输入重试 | 经办 |
| 单据已生效，下游已动起来 | 已通知供应商、已占用额度 | 开反向单据冲销，原单不能删 | 业务 + 财务 |
| 提交时授权已过期 | 提交失败 | 重新授权后再办 | 管理员 |
表里第四行最难处理，也最能说明「能不能放」。单据一旦生效、通知发出、额度占上，改几个字段解决不了，要走冲销、跟对方解释、在账上留两条记录。这类动作放开的时机应当往后排，等前几类跑稳了再说。
退路写不出来，说明现在还不该放。有些动作的退路天生很窄，比如已经对外发出的通知、已经同步给第三方的数据，它们更适合一直停在人工确认那一侧。
回退窗口和审计配置是连着的：记录保存多久由企业按行业要求配置，配置的长度要能盖住回退与对账需要的那段时间。窗口比退路短，事后就核对不出原值。
五、放开后的两周，看五类证据
放开之后容易犯的一个错，是拿「有没有人抱怨」当结论。抱怨少，可能只是没人认真看。更稳的做法是固定看五类东西。
| 证据 | 看什么 | 出现什么就先停下 |
|---|---|---|
| 预填被改动的比例 | 员工提交前改了哪些字段、改了多少 | 某个字段几乎每次都被改，取数口径错了 |
| 预填被放弃的比例 | 填好了没提交 | 占比偏高，说明依据不够，员工不放心 |
| 重复触发次数 | 同一动作出现两次以上 | 去重没生效 |
| 失败分布 | 报错集中在哪一类原因 | 权限、字段映射、系统限流，改法各不相同 |
| 人工回补次数 | 员工回原系统手工补做 | 这一段没省下工，价值没兑现 |
这些数不用精确到小数点，方向对就够用。两周只是能看到分布的窗口，没有谁规定必须两周；业务量小的场景，可能要更久才看得出趋势。
判断这些数据时，把它们跟只读阶段比。只读阶段的数据范围、字段口径、员工范围都已经验证过，写操作阶段如果同一个字段的取值方式突然变了，问题多半出在新加的判断逻辑上。
星云 PLUS AI 系统连接器连接现有系统，不换系统、沿用员工权限、关键操作人确认、调用审计。轮到写操作，这四件事正好就是放开的四个检查点：身份是不是真人、数据范围由谁说了算、哪一步停下来等人、出了事能不能对上记录。
六、什么时候扩大，什么时候收回去
扩大看三条，缺一条就再等等。
- 预填被改动的比例在下降，说明口径稳住了。
- 这段时间没有出现撤不回来的错误。
- 退路被真实用过一次，并且走通了。没被用过的退路，走不走得通还不知道。
收回也有三种情形：同类错误重复出现；退路走不通，比如下游已经动起来、冲销也补不回原状；责任说不清，谁确认的记不下来。
收回的动作要小。先把这项能力的写操作关掉，退回只读，把原因写在能力定义旁边，改完再开。整项能力不必一起下线，员工还能查，业务不至于整段断掉。
有一种情形要特别处理：错误由员工操作引起、能力本身没问题时，停能力等于让所有人陪着一个人受罚，收回到个人授权就够了。反过来，多个人在同一项能力上犯了同样的错，多半是能力定义或确认点设错了，该改的是配置。
结语
从只读到写入，落地时要备三张纸：一张四类动作的排序表，一张每种失败的退路，一张两周的证据清单。三张都写得出来，放开就只是执行；写不出来，说明还没到那一步。
想验证现在能不能走，挑一件员工今天还要回原系统补录的事，回答三个问题：错一次能不能撤回、确认停在哪一步、退路由谁执行。三个都答得出，就从这一件开始；有一个答不出，先把它补上再谈放开。
常见问题
只读已经跑了两个月，能不能直接开自动执行？
跑得久只说明查询稳，不代表写操作的判断依据齐了。先看四类动作里哪一类能撤回，从那一类起，自动执行放到后面再谈。
首轮要不要接审批类能力？
不建议。AI 可以把依据汇总、把审批意见草拟出来，同意或驳回仍由有权限的人点。审批被代点，责任归属就模糊了。
员工绕过界面直接调接口提交，怎么管？
这类动作同样在能力授权与调用记录的范围内：这项能力有没有授权给这个人、这次调用有没有记下来，都是可查的。决定范围的还是目标系统，它按员工的功能与数据权限再判一次，绕开界面不等于绕开权限。
预约系统连接评估：https://www.xingyunzuo.cn/
从一项写操作开始评估
确认目标系统、员工权限、人工确认点与异常回退方式，再确定适合的实施范围。
预约系统连接评估