AI任务操作边界是一份按动作分级的授权约定：先明确AI可以读什么、建议什么、直接改什么，再为创建、拆解建议、分派建议、状态流转、执行跟进五类动作分别设定自动执行、需人工确认、禁止执行三档，并配套字段约束、留痕与复核机制。本文面向正在把AI引入任务工作项的研发团队，给出可执行的授权对照表、配置步骤、角色分工与检查清单，落地起点是从只读加建议开始，按动作逐项放开写权限。
要点总览（TL;DR）
- AI任务操作边界按动作分级：读取、拆解建议、创建、分派建议、状态变更、执行跟进六类动作，分别设定自动执行、人工确认后执行、禁止执行三档。
- 落地从只读加建议起步，按动作逐项放开写权限，用字段约束（必填项、状态机流转、分派范围）把档位变成可执行的规则。
- 定档位、配置、确认、抽检由不同角色承担，确保高风险动作不会因图省事被调成自动执行。
- 边界是否有效看四点：动作有档位和确认人、字段约束能拦截越权、AI写入可追溯、抽检问题有闭环。
- 误判率上升、工作项类型变化或流程调整时，回到授权矩阵重新评估，调整后先小范围观察再扩大自动范围。
先划清AI能碰哪些任务动作
边界划分的第一步是把“AI帮忙做任务”拆成具体动作，再对每个动作单独定档。按工具整体授权（例如“允许AI操作项目”）会让读、写、改状态混在一起，一处放开等于全量放开；按动作授权则可以在保留建议能力的同时，把写操作限制在少数低风险动作上。
任务工作项上常见的AI动作可以归为六类：读取任务与上下文、生成拆解建议、创建任务、给出分派建议、变更任务状态、执行跟进（提醒、催办、补充进展）。每类动作对应三档授权口径：
- 自动执行：AI直接完成，结果即时生效，事后可追溯、可回退。适用于影响小、易纠正的动作，如读取、生成建议草稿。
- 人工确认后执行：AI产出待确认结果，由指定确认人接受、修改或驳回后才写入系统。适用于会改变任务结构或责任归属的动作，如创建任务、分派。
- 禁止执行：AI不发起该动作，只能提示人工处理。适用于影响面大或难以回退的动作，如关闭迭代、批量删除、跨项目转移。
下表是一份可直接用于配置与评审的动作—授权档位对照表，档位为建议起点，团队可按自身风险偏好调整：
| 动作 | 建议档位 | 典型触发条件 | 回退方式 |
|---|---|---|---|
| 读取任务、迭代与文档上下文 | 自动执行 | 在已授权项目范围内 | 收回数据访问范围 |
| 生成拆解建议 | 自动执行（仅产出草稿） | 需求描述达到最小完整度 | 草稿不写入，直接丢弃 |
| 创建任务 | 人工确认后执行 | 拆解建议被确认人接受 | 删除或合并误建任务 |
| 给出分派建议 | 自动执行（仅建议） | 存在负责人候选与历史负载信息 | 负责人不采纳即可 |
| 变更任务状态 | 人工确认后执行，限定条件下自动 | 如“开发完成→待测试”且关联提交已合入 | 状态回退并记录原因 |
| 执行跟进（提醒、催办） | 自动执行，升级需确认 | 任务临近截止或阻塞超时 | 关闭提醒、调整规则 |
| 关闭迭代、批量删除、跨项目转移 | 禁止执行 | — | — |
需要区分两类相邻但不同的主题：资源容量与负载分析回答“人够不够、排得下排不下”，多步骤流程自动化回答“多个系统动作如何串成一条流水线”。本文的边界只约束AI在单个任务工作项上能发起哪些动作、以什么档位发起，容量判断与跨系统编排分别由相应机制处理，边界表里不混入这两类规则。
按动作设定授权档位的操作步骤
配置过程按“盘点—定档—加约束—设确认—试运行”推进，每一步都有明确输入和完成标志，避免边界停留在讨论层面。
第一步：盘点现有任务工作项类型与高频操作
输入是当前项目的工作项类型清单（需求、任务、缺陷、子任务等）和近一个迭代的操作记录。动作是统计每类工作项上发生频率最高的操作，标出哪些已由人工完成、哪些适合交给AI。输出是一份“工作项类型×高频操作”清单。完成标志是清单覆盖了团队八成以上的日常操作，且每项操作都能对应到S1中的六类动作之一。
第二步：为每类动作确定授权档位与触发条件
输入是上一步的清单和团队对风险的判断。动作是逐项填写档位，并为“自动执行”和“限定条件下自动”的动作写明触发条件，例如状态自动流转要求关联代码已合入、分派建议要求候选人在同一项目组内。输出是填满的授权矩阵。完成标志是每个动作都有唯一档位，没有“视情况而定”这类无法执行的表述。
第三步：配置字段约束
档位只说明“能不能做”，字段约束决定“做成什么样才算合规”。需要配置三类约束：必填项（如创建任务必须填写负责人、所属迭代、验收标准）、状态机允许的流转（如禁止从“待开发”直接跳到“已完成”）、分派对象范围（如只能分派给当前项目成员）。输入是授权矩阵，输出是配置后的工作项模板与状态流转规则。完成标志是用一条测试任务走完全流程，越权字段和非法流转均被拦截。
第四步：设置人工确认节点与确认人
对每个“人工确认后执行”的动作，指定确认人和确认时限。确认人应是该动作结果的责任人，例如创建任务由需求负责人确认，状态变更由任务负责人或测试负责人确认。输入是授权矩阵中的确认档动作，输出是确认人名单与超时处理规则（如超时未确认则退回草稿）。完成标志是每个确认档动作都能在系统中找到对应确认入口和确认人。
第五步：小范围试运行与观察期
选择一个迭代、一个项目组先行运行，观察期建议覆盖至少一个完整迭代。输入是配置完成的授权矩阵与试运行计划，动作是记录AI每次操作、确认结果和人工纠正，输出是试运行记录。完成标志是每个动作都有明确档位、确认人和回退方式，且试运行期间未出现越权写入。
角色分工与各环节交付物
边界能否维持，取决于每个环节是否有人负责、有物可查。下表给出角色—职责—交付物对照：
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 研发负责人或项目负责人 | 确定各动作档位与确认人，审批边界变更 | 授权矩阵、边界变更记录 |
| AI工具管理员 | 配置字段约束、状态流转与权限范围 | 配置清单、权限设置记录 |
| 任务执行人 | 处理需确认的建议，反馈误判与不合理建议 | 确认记录、误判反馈 |
| 质量或流程角色 | 定期抽检AI操作记录，跟踪问题闭环 | 抽检报告、问题闭环记录 |
分工上有两条实用原则：定档位的人与日常使用AI的人分开，避免为了省事把高风险动作调成自动执行；抽检角色独立于配置角色，抽检结果直接进入边界评审，而不是停留在个人观察。
在工具承载层面，ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并把自然语言指令转化为 ONES 中可追踪的工作，结果以工作项、Wiki 页面等形式留存。其AI能力基于ONES权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，这为“谁在什么范围内让AI做了什么”的复核提供了记录基础。字段必填、状态机流转与分派范围的具体配置方式，需在实施时按团队实际使用的工作项类型核验。
一个迭代内的边界运行示例
以下为演示情景，用于说明边界在连续任务流转中如何生效，不代表任何具体团队的真实数据。
迭代规划会上，产品负责人把一段需求描述交给AI，AI读取关联的Wiki页面与历史任务，生成拆解建议：三个子任务、建议验收标准、待澄清问题两条。拆解建议属于自动执行档，但只产出草稿，不写入系统。需求负责人逐条审阅，修改其中一条验收标准后确认，系统据此创建三个任务——创建动作走人工确认档，确认人即需求负责人。
任务创建后，AI根据历史同类任务给出分派建议，标注候选人与依据（如曾负责相似模块）。分派建议只作参考，最终分派由负责人在规划会上决定，AI不直接写入负责人字段。
开发过程中，某任务关联的代码提交合入，触发“开发完成→待测试”的状态变更。该流转在授权矩阵中属于“限定条件下自动”，条件满足即自动执行并记录触发依据；其余状态变更，如“待测试→已完成”，仍需测试负责人确认后执行。
执行跟进环节，AI对临近截止的任务发出提醒，属于自动执行；当任务阻塞超过约定时长，AI生成升级建议并推送给项目负责人，升级动作本身需人工确认后发出。若出现误判，例如AI把一条已澄清的问题仍标为待澄清，任务执行人在确认环节驳回并填写原因，该记录进入抽检样本，由流程角色在周度抽检中判断是否需要调整触发条件或档位。
完成检查：边界是否真的生效
边界落地后，用以下清单逐项核对，每项都给出通过标准：
- 动作覆盖完整：六类动作在授权矩阵中均有档位，每个“人工确认后执行”动作都有确认人和回退方式。通过标准：随机抽取一个动作，能在矩阵和系统中同时找到档位与确认入口。
- 字段约束生效：必填项、状态机流转、分派范围均已配置。通过标准：构造一条缺必填项或非法流转的测试任务，被系统拦截。
- 操作可追溯：AI发起的每次写入都有记录，包含动作、对象、时间与确认人。通过标准：任取一条AI创建的任务，能回溯到确认记录。
- 问题有闭环：抽检发现的问题有责任人、处理结果和关闭时间。通过标准：上一周期抽检问题关闭率达到团队约定水平，未关闭项有明确计划。
- 变更经评审：档位调整经过负责人审批并留档。通过标准：每次变更都能在变更记录中找到申请理由与审批人。
边界不是一次配置就长期有效。出现以下信号时应触发重新评估：确认环节的驳回率或误判率持续上升，说明触发条件过宽或建议质量下降；团队引入新的工作项类型或业务线，原有档位未覆盖新场景；研发流程调整，例如状态机增减状态或分派规则变化，使原有约束失效。重新评估时回到授权矩阵逐项复核，调整后重新进入小范围观察，再决定是否扩大自动执行范围。
常见问题
团队刚开始引入AI，第一版边界应该放到多宽？
建议第一版只开放读取和生成建议两类动作，创建、分派、状态变更全部设为人工确认后执行，关闭迭代、批量删除等动作直接列入禁止执行。这样AI能先参与需求澄清和拆解草稿，团队也能在确认环节观察建议质量。运行一个完整迭代后，再挑误判少、回退成本低的动作逐项放开自动执行，例如限定条件下的状态流转。
AI生成的任务拆解建议，确认人应该由谁担任？
确认人应是该动作结果的责任人，而不是最熟悉AI工具的人。拆解建议和创建任务通常由需求负责人确认，因为他要对任务范围和验收标准负责；状态变更由任务负责人或测试负责人确认；分派建议可以只作参考，最终分派由项目负责人在规划会上决定。确认人名单要写进授权矩阵，并约定超时未确认的处理方式，例如退回草稿。
哪些动作适合设为自动执行，判断依据是什么？
判断依据是影响面和回退成本。读取上下文、生成建议草稿、发出提醒这类动作影响小、纠正容易，适合自动执行；创建任务、变更状态会改变任务结构或流转记录，适合人工确认后执行；关闭迭代、批量删除、跨项目转移影响面大且难以回退，应列入禁止执行。对“限定条件下自动”的动作，触发条件要写成可核验的事实，例如关联代码已合入，避免用“视情况而定”这类无法执行的表述。
AI操作记录需要留到什么程度，抽检才有意义？
至少能回答四个问题：AI发起了什么动作、作用在哪个任务上、什么时间、由谁确认。有了这四项，抽检时才能回溯一条AI创建的任务是否经过确认、一次状态变更是否满足触发条件。抽检角色应独立于配置角色，抽检发现的问题要有责任人、处理结果和关闭时间，并进入边界评审，而不是停留在个人观察。ONES 的 AI 能力基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，可作为记录基础的参考；具体记录留存形式与查询范围需在实施时按团队配置核验。
边界定好之后，什么情况下需要重新调整？
三类信号值得触发重新评估：确认环节的驳回率或误判率持续上升，说明触发条件过宽或建议质量下降；团队引入新的工作项类型或业务线，原有档位没有覆盖新场景；研发流程调整，例如状态机增减状态或分派规则变化，使原有约束失效。调整时回到授权矩阵逐项复核，变更经过负责人审批并留档，调整后先小范围观察，再决定是否扩大自动执行范围。
