AI只完成部分工作项操作时，处理顺序应当是先停住、再盘点、后补齐。中断可能发生在权限校验、上下文获取、依赖判断或人工确认环节，不同原因对应不同的接管方式。本文按“界定症状—验证原因—人工补齐—恢复验证”的顺序展开，适用于AI批量更新工作项、流转状态或生成子任务时中途停止的场景，并在处置步骤中说明ONES工作项与流转管理可以承接哪些动作。
要点总览（TL;DR）
- AI只完成部分工作项操作时，先冻结后续执行，再按“已改动、未改动、待确认”三类盘点受影响工作项，避免把AI建议当成既成事实。
- 中断原因按权限与字段校验、上下文缺失、跨工作项依赖、人工确认四类逐项验证，证据成立后再进入修复，防止补齐后再次中断。
- 人工接管由具备权限的人补齐字段、状态与关联关系；批量修改、状态回退、删除关联前先导出或备份，保留回退点。
- 恢复验证看三项证据：工作项历史完整、必填字段齐全、状态流转符合规则且下游依赖可继续，并与操作前基线逐项对比。
- 把本次中断原因写入AI操作规则、补充必填字段校验或增加人工确认节点，并定期抽查批量操作结果，观察中断频率变化。
中断发生在哪一步：先界定症状与影响范围
“只完成部分操作”是一个笼统描述，接管前要把它拆成可观察的事实。先确认AI原本要做什么、做到哪一步停下、哪些工作项被改动过。这一步的产出是一份中断症状与影响范围清单，后续原因排查和人工补齐都以它为底稿。
常见症状可以归为四类：状态未流转，工作项仍停留在原状态；字段只填了一部分，例如标题和描述已写入、负责人或截止日期为空；子任务或关联项未同步，父项已更新而拆出的子项没有建立关联；批量操作中途停止，前几条已生效、后续条目未处理。记录症状时尽量带上工作项编号和字段名，避免用“没做完”这类模糊表述。
影响范围盘点要回答三个问题：受影响的工作项有哪些，每个工作项哪些字段已改动、哪些未改动，以及哪些下游任务依赖这些工作项。下游依赖尤其容易被忽略，例如测试任务等待需求状态变为“已评审”，或发布计划引用某个缺陷的修复结论。上游工作项停在中间状态，下游就会卡住或按错误前提推进。
还要区分单次中断与批量中断。单次中断通常只涉及一个工作项，触发入口可能是对话式指令或单条操作；批量中断涉及一批工作项，需要记录发生时间、操作类型、触发入口和已处理条数。批量中断的影响面更大，盘点时应导出受影响工作项列表，作为后续核对和回退的依据。
| 症状类型 | 可观察表现 | 盘点重点 |
|---|---|---|
| 状态未流转 | 工作项停留在原状态，历史记录无状态变更 | 目标状态、流转条件、下游等待该状态的任务 |
| 字段部分填写 | 部分字段有值，必填字段为空或格式不符 | 已填字段清单、缺失字段、字段校验规则 |
| 子项或关联未同步 | 父项已更新，子任务或关联项未建立或未更新 | 关联关系清单、子项当前状态 |
| 批量操作中途停止 | 部分条目生效，其余条目无变化 | 已处理与未处理条目、操作时间与入口 |
原因假设与排除证据：权限、上下文、依赖还是确认环节
原因排查采用假设—证据的方式：先列出可能原因，再为每类原因找到可观察的验证证据，证据成立才进入修复。直接把“权限不够”或“AI不稳定”当结论，容易在补齐后再次中断。
权限与字段校验拦截。验证方法是查看操作账号对目标工作项是否具备编辑权限，检查必填字段是否为空、取值是否符合选项集，以及目标状态是否满足状态机允许的流转路径。证据通常出现在操作失败提示、字段校验标记或工作项历史中。若同一账号手动修改同一字段也失败，权限或校验原因基本可以确认。
上下文缺失。AI执行依赖工作项描述、关联项和历史记录。如果描述中缺少验收标准、关联需求未建立，或历史讨论中的关键约束没有被读取，AI可能在生成部分内容后无法继续。验证方法是核对AI操作所依据的输入是否完整：工作项描述是否有明确目标，关联项是否存在，相关Wiki页面是否可访问。上下文缺失的表现往往是产出内容方向正确但细节缺失，或对后续步骤给出含糊处理。
跨工作项依赖未满足。前置工作项未完成、关联缺陷未关闭、父项未进入可拆分状态，都会阻止后续流转。验证方法是沿依赖关系逐项检查前置条件，确认阻塞点具体是哪个工作项、哪个状态。这类原因在批量操作中更常见，因为一批工作项的前置条件往往不一致。
需要人工确认的环节。高风险操作可能被设计为等待人工审批，例如批量关闭工作项、修改优先级或删除关联。此时中断属于预期行为，验证方法是查看是否存在待确认提示或审批记录。若确认属于设计内的人工确认，接管动作就是完成确认，而非修复故障。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 权限或字段校验拦截 | 操作失败提示、必填字段为空、状态机不允许该流转 | 先查，成本最低且最常见 |
| 上下文缺失 | 描述不完整、关联项缺失、依据资料不可访问 | 其次查，核对AI输入是否齐全 |
| 跨工作项依赖未满足 | 前置工作项未完成、关联项状态不满足 | 再次查，沿依赖链逐项确认 |
| 等待人工确认 | 存在待确认提示或审批记录 | 同步查，区分预期中断与异常中断 |
排查顺序建议从权限与校验开始，因为这类原因验证快、证据明确；随后核对上下文完整性；再沿依赖链检查前置条件；最后确认是否存在设计内的人工确认环节。四类原因可能叠加，例如字段校验通过但依赖未满足，排查时逐项记录结论，避免只处理第一个发现的原因。
人工接管处置步骤：从盘点、补齐到交接
确认中断原因后进入人工接管。接管的核心原则是：先让AI停止继续改动同一批工作项，再由具备权限的人按盘点结果补齐，最后留下可追溯的交接记录。
第一步，冻结AI继续操作。暂停当前对话或批量任务，确认没有后续指令仍在执行。保留工作项当前状态和AI已产出的中间结果，包括已写入的字段、生成的草稿和未提交的建议。中间结果本身有参考价值，不要急于清空。
第二步，按三类盘点工作项。把受影响工作项分为已改动、未改动、待确认三组。已改动指字段或状态已经变化且需要复核的；未改动指AI尚未触及、需要人工补齐的；待确认指AI给出了建议但尚未提交、需要人判断是否采纳的。三类分开处理，避免把建议当成既成事实。
第三步，由具备权限的人补齐字段、状态与关联关系。补齐前先确认操作范围，批量修改、状态回退、删除关联等破坏性操作要先导出或备份当前数据，保留回退点。补齐时按工作项逐条处理，优先恢复阻塞下游的条目。若涉及状态回退，确认回退不会触发自动化规则或通知下游误判。
第四步，对AI产出内容做人工复核。已写入的描述、验收标准、子任务拆分需要逐项核对，确认与需求一致后再提交或流转。复核重点包括：内容是否引用了不存在的工作项、字段取值是否符合团队规范、拆分出的子任务是否覆盖原范围。复核通过后再执行状态流转。
第五步，记录接管信息。记录接管人、接管时间、补齐的字段与状态、遗留问题和待跟进事项。这份记录既是本次处置的交接凭证，也是后续复盘和补充规则的输入。
在ONES中，工作项的状态、字段和关联关系可以在同一工作项内维护，操作结果会留下历史记录，便于接管人核对已改动与未改动部分。ONES Assistant连接ONES Project、ONES Wiki与ONES TestCase，能够理解项目、工作项、迭代和Wiki页面等工作上下文并执行后续操作，结果保存为工作项或Wiki页面；其知识问答和任务执行基于ONES权限体系，输出过程可追踪、结果可审计。接管时可由具备权限的成员在工作项上补齐字段与状态，再对照历史记录确认AI已完成的动作，减少重复录入和页面切换。
恢复验证与复发预防：确认完成并补上规则
补齐完成后不能直接宣布恢复，要用证据确认工作项已回到可继续推进的状态。验证通过后，再把本次中断点转化为规则或复核节点，降低同类问题再次发生的概率。
恢复验证看三项证据。第一，工作项历史完整：状态变更、字段修改和关联建立都有记录，时间顺序合理，没有跳步或重复提交。第二，必填字段齐全：按团队字段规范逐项核对，确认没有空值或格式错误。第三，状态流转符合规则且下游依赖可继续：下游任务能够读取到预期状态，阻塞标记已解除。三项都满足，才视为恢复完成。
验证时与AI操作前的基线对比。基线可以取操作前导出的工作项列表或历史快照，逐项核对是否有遗漏未补的字段，以及是否有超出原范围的改动。对比能发现两类问题：该改的没改，以及不该改的被改了。后者在批量操作中更隐蔽，需要重点检查。
复发预防从三个方向入手。把本次中断原因写入AI操作规则，例如明确哪些字段必须由人工填写、哪些状态流转需要前置条件满足；补充必填字段校验，让缺失在提交前暴露；对高风险操作增加人工确认节点，把批量关闭、优先级调整等动作设计为等待确认后执行。规则补充后，用同类任务做一次小范围验证，确认中断不再出现。
日常还可以定期抽查AI批量操作结果，观察中断频率和原因分布的变化。抽查样本覆盖不同类型的操作入口，记录每次中断的原因分类，若某类原因反复出现，说明对应规则或校验仍需调整。接管记录和抽查结果放在一起复盘，能让AI操作边界逐步清晰，人工接管的范围也随之收窄。
常见问题
AI批量操作中途停止，已生效的条目还能继续用吗？
已生效的条目可以保留，但需要先复核再继续推进。批量中断后，先导出受影响工作项列表，把已生效条目与AI原本的目标逐条比对，确认字段取值、状态和关联关系符合预期。确认无误的条目可以保留，存在偏差的条目按人工接管步骤修正。未处理的条目在原因排除前不要直接重跑同一批指令，否则可能重复改动已生效部分。
中断原因一时查不清，能不能先人工补齐再排查？
可以，但要先冻结AI继续操作，并记录补齐前的状态。人工补齐能先解除下游阻塞，不过原因未查清时，同类中断很可能再次出现。建议补齐的同时保留证据：操作失败提示、字段校验标记、AI所依据的输入是否完整。补齐完成后按假设—证据的顺序补做排查，把确认的原因写入AI操作规则或复核节点，避免下次重复同样的接管动作。
哪些人工接管动作需要先备份或保留回退点？
批量修改字段、状态回退、删除或重建关联关系这三类动作风险较高，执行前应导出当前工作项数据或保留历史快照。状态回退还要确认不会触发自动化规则或让下游任务误判。单条工作项的字段补齐通常风险较低，但涉及负责人变更、优先级调整等影响下游排期的字段时，同样建议先记录原值。
接管后如何确认工作项真的恢复了，而不是看起来正常？
用三项证据交叉确认：工作项历史中状态变更、字段修改和关联建立都有记录且时间顺序合理；必填字段按团队规范逐项核对无空值；下游任务能读取到预期状态、阻塞标记已解除。再与AI操作前的基线对比，检查该改的有没有漏、不该改的有没有被改。三项证据和基线对比都通过，才视为恢复完成。
ONES Assistant在部分操作未完成时如何提示，能否直接续做？
现有官方资料说明ONES Assistant连接ONES Project、ONES Wiki与ONES TestCase，能理解项目、工作项、迭代和Wiki页面等工作上下文并执行后续操作，结果保存为工作项或Wiki页面，且基于ONES权限体系运行、输出过程可追踪、结果可审计（F1、F2、F3、F6）。资料未说明权限不足、字段缺失或状态机规则不满足时的具体中断提示形式与续做机制，这部分需要结合实际使用环境确认。接管时可由具备权限的成员在工作项上补齐字段与状态，再对照历史记录核对AI已完成的动作。
