Jira 中人工智能支持人员的人在环内模式
人在环内能够让您在支持人员承担更多开发工作时始终掌握控制权；在 Jira 中，该机制内嵌于工作流，而非一款独立工具。取得实效的团队会将人工判断保留给关键决策，其余工作交由支持人员处理。
这类判断有着天然的承载载体。Jira 历来就是团队管理工作、审批任务推进的平台，如今它同样可为支持人员承担此项职能。本指南介绍人类应当在哪些环节、以何种方式保持对人工智能支持人员的管控权，厘清权责归属，以及如何设计可规模化的监督机制。简而言之，落地完善的人在环内管控将带给您三项优势：
审批环节：管控那些无法干净撤销的操作
审查环节：在交付前拦截质量低下或方向偏离的输出内容
上报环节：将支持人员无法确定的判断自动分派给人员处理
什么是面向人工智能支持人员的人在环内管控？
人在环内是一种系统设计：人工智能支持人员会在预设检查节点暂停执行，由人员在高风险流程开始前完成审批、修正或是调整工作方向。支持人员负责执行常规工作，而人类掌控会产生实质后果的决策。
它是一套保障可靠性的架构，并非人工智能能力不足的表现，也不是模型足够强大后就可以撤除的临时拐杖。最出色的支持人员系统，会把人工判断精准设置在能够左右最终结果的关键位置。
在实践中，人在环内通常表现为三种模式：
审批：在执行高风险或不可逆操作之前进行签字审批。
审查：在支持人员的输出内容交付前核验。
上报：当支持人员判断存疑、缺少上下文信息或超出工作范围时，将任务转交人工处理。
人在环内、人在环上与人在环外对比
这三个术语说明了支持人员启动工作之后，人类能够保留多大程度的控制权。二者的区别归根结底在于谁执行操作、谁作出决策。
监督模式 | 工作原理 | 使用时机 |
人在环内 | 支持人员提出方案后暂停执行，由人员审批或修正，而后再执行操作。 | 高风险或不可逆工作，一旦出错，撤销代价高昂。 |
人在环上 | 支持人员自主执行，人员实时监督，可随时介入停止或修正。 | 追求效率且错误能够恢复的中等风险、可重复执行的工作。 |
人在环外 | 支持人员完全自主运行，无实时监控。监督为事后开展：审核、日志核查、抽查。 | 低风险、可逆且范围明确的工作，此类工作付出的成本高于它所能规避的损失。 |
目标并非对所有任务都实施最高强度监督，或是完全放弃监管，而是在风险真实存在的环节匹配适宜的管控模式，并且随着信任度提升，给予工作更高的自主执行权限。
人类应当在哪些环节保持对人工智能支持人员的管控？
先厘清权责归属
权责划分要早于检查节点的设置。在确定人员于何处开展审查或审批之前，首先就要明确支持人员一开始就有权负责的工作范围。检查节点只是用来执行这项决策，而不能替代决策本身。
一种简便的工作划分方式，是按照出错之后所要付出的代价来判定：
由支持人员负责。工作要求清晰明确，支持人员可以独立完成并办结，无需转交人工。
支持人员提出方案，人员负责处置。由支持人员起草工作，再由人员完成定稿、审批通过或者退回。
由人员负责。从一开始就由人类做出决策，支持人员仅提供辅助，不参与决策。
权责归属决定了工作由谁发起；而前面提到的监督模式，则决定了工作启动之后由谁开展监督。在 Jira 中，支持人员的每一项操作都会绑定明确身份信息，并且记录在工作项历史记录内，因此权责追溯有据可查，无需依靠人工记忆。
1. 审批：高影响工作开展前签字审批
当某项操作难以撤销时，就应当启用审批环节。生产环境变更、删除操作以及会产生费用的调用，都必须经过签字审批之后才可执行，因为一旦操作失误，将会付出高昂代价。在 Jira 中，审批是工作流内的一个审批步骤。它会暂停任务流转，直至指定人员完成签字审批，因此该管控关卡属于流程本身的一环，而非一条需要人工牢记的提醒事项。如需了解此类管控关卡背后完整的工作流规则机制，包括条件与验证器，请参阅 Jira 中的智能体化工程护栏与安全保障。
在 Jira 中：支持人员准备一项高影响变更，例如生产环境配置更新或者版本发布。在指定审批人完成审批之前，该工作项无法离开审批状态。原生审批步骤将流转绑定为两种结果：批准或驳回，并且会在工作项上记录决策者以及时间。
2. 审查：在交付前验证输出结果
在您已有的检查流程完成验证之前，请将支持人员生成的输出视作不可信内容。对于编码支持人员而言，审查即为拉取请求，它将执行您常规的审查与合并流程。
做好审查意味着能够查看工作内容，而不仅仅是结果。Jira 为您推荐页面上的支持人员会话视图，可集中展示支持人员执行了哪些操作及其背后原因，帮助审查人员直接获取上下文，无需重新梳理。
在 Jira 中：将工作项分配给编码支持人员，例如 Jira 编码支持人员。它会读取工作项以及关联的上下文信息，随后创建一份草稿拉取请求，并将其链接回该工作项，供您进行审查。您可以通过常规合并流程审查这份拉取请求，而 Jira 为您推荐页面中的支持人员会话视图，会按照待办事项对所有会话进行分组，并展示每一个支持人员执行过的操作，这样您在审查时就能够直接获取上下文，无需重新梳理。
将任意一条 Jira 事务分配给编码支持人员，即可看到它在安全的云沙盒环境内检索您的代码库、编写修复程序或新功能代码，并提起拉取请求。
3. 上报：当支持人员不确定或超出权限范围时移交
上报代表支持人员能够认知自身能力边界。当置信度较低、上下文信息缺失，或是触及策略边界时，支持人员应当暂停工作并发起问询，或将事务分派给人员处理，而不是自行猜测。关键在于让该移交流程形成系统化机制：设计触发器，使上报成为系统主动发起的异常流程，而非事后由人工发现的失误。不要依赖支持人员自行可靠判断它的置信水平。您需要自行定义触发器：缺少必需上下文、已产生低置信信号、变更规模超过设定阈值，或是任何触及策略边界的操作。
在 Jira 中，自动化规则可以添加评论、将工作项打上“待优化”标签，或是在上下文缺失时将事务分派给人工处理。无论支持人员来自 Atlassian 还是第三方产品，该机制均适用。支持人员在任务执行中途何时应当暂停并发起问询，可在支持人员自身的指令中进行设置（如果是 Rovo 或 Jira 支持人员，则在 Jira 内设置）；若是第三方支持人员（例如 Claude、Cursor、Copilot），则在对应工具的设置项中完成设置。
在 Jira 中：一条自动化规则每天早上扫描所有处于打开状态的安全工作项，并按照严重性进行分派。低风险、可逆修复任务交由编码支持人员处理，由其创建拉取请求。任何高严重性或涉及关键基础架构的事项，在执行任何变更之前都会先生成摘要并分派给对应的工程师，从而确保高风险决策交由人工处理时，所需上下文信息已整理完备。
您只需在 Jira 中一次性设置好自动化，后续工作便可交由支持人员完成。
什么时候人在环内会成为瓶颈，而非保障？
监督会在两个极端方向失效。管控不足，就会交付偏离目标或不可逆的工作成果：随着人工智能编码工具使用率的攀升，开发人员的生产力提升幅度停滞在大约 10%-15%，因为软件交付过程中的难点并不是编写代码，而是确定开发内容、理解待改动的系统，以及了解输出内容是否可安全交付。过度监督则会走向另一个极端，产生负面效果。
一旦审核关卡与风险等级不再匹配，人在环内机制就会转变为瓶颈。常见的三类失效模式如下：
关卡过多。如果对每一项操作都执行审查，就会产生审查疲劳、支持人员因等待人工处理而闲置，而您引入支持人员原本想要获得的效率优势也会悄然消失。
走过场式审批。当一项本无需审查的工作却触发关卡时，工作人员往往不经审阅就直接批准。此时检查节点沦为形式，一旦真正存在问题出现，就会失效。
只衡量介入行为，却忽视监督。统计审批数量，只能证明有人参与过流程，却无法证明他们查出了任何问题。数量不等于判断质量。
当您无法在不造成吞吐量受阻的情况下对每一项操作都设置关卡时，可以改用抽样审查。不必审查支持人员交付的全部内容，只需抽查其中一部分。在 Jira 中，自动化规则可以标记一定比例由支持人员完成的工作项，交由人员审核；也可以分派所有高风险事务，这样您既能对质量实施有效检查，又不会阻断整条工作流水线。
Jira 作为审查与审批平台
在 Jira 中，人在环内并非一款独立工具，而是您团队开展工作的平台，因此所有检查节点都位于工作所在的平台。这就是可规模化监督与无人维护的并行管控平台之间的区别。
三种模式位于同一平台：
通过工作流审批步骤进行审批，该步骤将暂停流转直至指定人员签字审批。
审查与工作项关联的拉取请求，借助 Jira 为您推荐页面上的支持人员会话视图，查看各个支持人员执行过的操作以及待您处理的事项。
通过支持人员指令与自动化规则完成上报，移交过程以及对应的负责人直接记录在工作项内。
Jira 可让您便捷地审查支持人员的输出内容并决定上线交付的内容
人员与支持人员基于同一套记录系统开展工作。无论由哪一个支持人员执行工作，您团队信赖的工作流、数据权限以及历史记录均保持生效，因此监督可复用您现有的管控机制，无需另行搭建一套专门面向人工智能的第二套系统。您可实现核查，同时避免无需蔓延。
人在环内与人工支持人员结合的最佳实践
最佳的人在环内系统会将人力投入集中于能够改变结果的环节，其余场景交由支持人员自主运行。
力求更少、更高价值的干预。每一道关卡都意味着成本，需移除所有已沦为走过场式审批的关卡。
根据风险与可逆性匹配监督力度。将常规工作自动化，仅对代价高昂或难以撤销的事项保留审批环节。
区分审批与审查。高影响操作执行前进行审批；对所有交付成果开展审查。
实现系统化上报。预先定义触发其：置信度低、上下文缺失或触及策略边界。
先小范围试点，再逐步扩大。为新支持人员划定严格的工作范围，待其逐步取得信任后再给予更多任务。
如何在 Jira 中设置您的首个人在环内工作流
您无需重新设计即可开始。选择一个工作流，添加一个检查节点，再由此逐步拓展。
选择一项常规任务。从失误代价低、易于撤销的工作入手，例如依赖项版本升级、不稳定测试修复或是文档更新。高风险工作留待您信任这套配置之后再开展。
将该任务分配给支持人员，并限定其仅可执行此项任务。您可通过经办人字段、面板列或工作流流转添加该支持人员。支持人员代表背后对应的人员执行操作，因此在 Jira 内部，它仅可访问该人员有权限查看的内容。Jira 管控您工作内容的访问权限；第三方支持人员借助自身工具所能执行的操作，则需在 Jira 之外另行设置。分配支持人员即可启动任务运行。该操作尚未启用人在环内机制，您需要后续增设检查节点来实现。
在影响发生的位置设置检查节点。在流转至高影响状态时添加审批步骤，以确保工作推进前经过人员签字确认。对于无原生审批功能的计划，可通过流转条件限制可推进工作的人员。
将输出内容送交审查。对于代码，让支持人员起草一份与工作项关联的拉取请求，确保变更在合并前接受正式审查。任何内容都不得仅凭支持人员的决定就交付。
确认操作留痕，再逐步扩大范围。检查支持人员的所有操作都已记录在工作项上，再进行拓展：优先从可逆工作着手，新增下一流转环节、下一种任务类型或是更大的工作范围。随着支持人员逐步赢得信任，再扩大其自主权限。
在 Jira 中查看支持人员执行过的操作及其作出过的决策。
最终目标并非部署一个无人值守运行的支持人员，而是搭建一套工作流：人员仅介入关键决策环节，其余环节无需干预，并且所有步骤均留存记录。
准备好将人员置于恰当的环节了吗？启动 Jira，体验原生人工智能开发
人在环内人工智能支持人员常见问题解答
如何在使用人工智能编码支持人员实现人在环内管控？
保证支持人员的工作可审查、受管控。将其输出内容分派给拉取请求，高影响变更必须经过审批才可执行，同时设计触发器，使支持人员在存疑或超出权限范围时上报人工处理。
Jira 中的人工智能支持人员是否可以要求人工审批？
是的。您可在产生影响的流转上添加一个工作流审批步骤，此时工作项将会暂停，直至指定人员批准或驳回。原生审批功能仅在 Premium 与 Enterprise 计划中提供。
谁对人工智能支持人员的行为承担责任？
始终由人员承担责任。支持人员执行相关工作，但由人类对最终结果负责。在 Jira 中，支持人员的每一项操作都会绑定明确的身份，并且保存在工作项的历史记录中。
什么是面向人工智能支持人员的循环工程？
循环工程指设计各类触发器，以此决定支持人员何时自行持续迭代工作、何时转交人工处理。合理的触发器能够让任务上报流程系统化，使监督落在存在风险的环节，而非覆盖全部流程。
仅靠人工介入是否就能满足人工智能治理要求？
人工监督是《欧盟人工智能法案》、美国国家标准与技术研究院人工智能风险管理框架 (NIST AI RMF) 等治理框架的核心，但是仅有监督并不等同于完成人工智能治理。您还需要实施强制访问管控、审批流程以及审核追踪。请参阅 Jira 中智能体工程的护栏与安全相关内容。