划定AI使用责任边界，核心是把“谁在什么环节、对什么产出、承担什么确认义务”写成可执行的规则。本文按场景分级、角色分工、流程步骤、示例和检查五个部分展开，适用于研发团队建立或修订AI使用规则；全平台权限体系和模型训练治理不在本文范围内。
要点总览（TL;DR）
- 先按产出影响面和可逆性把AI使用分为低、中、高三级，级别越高，默认确认要求越强，分级口径写入规则文档。
- 设置提出人、使用人、复核人、批准人四类角色：复核人看质量，批准人担后果，高等级产出上使用人与批准人应当分离。
- 流程按提出与登记、使用与标注、复核与批准、归档与留痕四步执行，每步都有输入、动作、输出和完成标志。
- 留痕记录至少包含任务描述、AI参与环节、使用工具、复核意见、批准人、时间与版本，争议时按记录逐环节定位责任断点。
- 每季度检查一次：高等级场景全量核对，中低等级场景抽样，检查不通过时整改指向具体环节，并在下一轮抽查中验证。
责任边界先按使用场景分级
笼统的“AI使用”无法直接分配责任。同一份AI产出，用于个人参考和进入正式交付，出错后的影响范围与修正成本差别很大。分级的作用，是让团队在事前就知道这类使用需要走到哪一级确认，而不是每次临时判断。
建议用两个维度交叉定级：产出影响面，指AI产出被谁使用、影响多少下游环节；可逆性，指出错后能否低成本撤回或修正。两个维度交叉后形成低、中、高三级，级别越高，默认责任强度越高。
| 等级 | 典型场景 | 默认责任要求 |
|---|---|---|
| 低 | 个人查阅资料、生成草稿供自己参考、代码补全后由本人逐行确认并仅提交到个人分支 | 使用人自行判断并对最终产出负责，记录AI参与环节即可，无需额外批准 |
| 中 | AI生成的测试用例、需求初稿、技术方案片段进入团队评审；AI辅助生成的代码合入共享分支 | 使用人标注AI参与，由复核人核对事实与质量，复核通过后进入正常评审流程 |
| 高 | AI产出直接影响对外交付、生产环境变更、客户可见文档、安全相关配置 | 在复核基础上增加批准人放行，留痕记录完整，纳入定期抽查范围 |
分级结果要写入规则文档，至少包含三部分：等级定义与判断口径、每级对应的确认要求、等级调整的触发条件。判断口径尽量用可观察的特征描述，例如“是否进入生产环境”“是否对外可见”“是否可在一个工作日内撤回”，避免使用“重要”“关键”这类需要再解释的词。当一次使用同时符合多个等级特征时，按最高等级执行。
分级不是一次定完就固定不变。团队可以在复盘中调整典型场景的归级，但调整要记录原因和生效时间，避免同一类使用在不同时期适用不同规则却无从对照。
四类角色的职责与交付物
分级解决“要确认到什么程度”，角色解决“由谁确认”。建议设置提出人、使用人、复核人、批准人四类角色。小团队中一人可以兼任多个角色，但同一份高等级产出上，使用人与批准人应当分离。
| 角色 | 输入 | 核心动作 | 交付物 |
|---|---|---|---|
| 提出人 | 业务需求、使用场景说明 | 定义任务目标、验收口径、产出用途与影响范围，初判使用等级 | 任务登记记录，含目标、验收标准、初判等级 |
| 使用人 | 登记记录、可用工具与数据范围 | 执行AI辅助操作，标注AI参与环节，自查产出 | 产出物及AI参与标注、自查说明 |
| 复核人 | 产出物、标注、验收口径 | 核对事实准确性、完整性、是否符合验收标准，提出修改意见 | 复核意见，明确通过、退回修改或升级批准 |
| 批准人 | 复核意见、留痕记录 | 对高等级产出做最终放行，对放行后果负责 | 批准记录，含批准人、时间、放行范围 |
复核人与批准人的区别在于关注点不同：复核人看质量，判断产出是否准确、完整、符合口径；批准人担后果，判断这份产出是否可以进入它将要影响的范围。把两者合并，容易出现“质量检查过了就默认可以放行”的漏洞，尤其在对外交付和生产变更场景。
角色缺位时要有替代安排，并写进规则。常见做法是：复核人临时不可用时，由同领域另一名具备复核能力的人替代，替代关系在记录中注明；批准人缺位时，高等级产出暂缓放行，或由上一级管理者书面授权代行，授权记录随产出归档。替代安排的原则是责任有承接人，而不是让流程卡住或默认跳过。
把边界写进流程：从提出到归档的操作步骤
角色和分级只有落到动作顺序上才会被真正执行。下面四步构成一个完整闭环，每一步都给出输入、动作、输出和完成标志，团队可以据此改写为自己的流程文档。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提出与登记 | 使用需求、场景说明 | 提出人填写任务目标、验收口径、产出用途，按分级表初判等级并指定使用人 | 任务登记记录 | 登记记录中等级、使用人、验收口径三项齐全 |
| 使用与标注 | 登记记录、数据与工具使用范围 | 使用人在授权范围内执行，标注哪些环节由AI参与、使用了什么工具，完成自查 | 产出物与AI参与标注 | 标注可让复核人识别AI参与部分，自查说明已附 |
| 复核与批准 | 产出物、标注、验收口径 | 复核人按口径核对并给出意见；高等级产出提交批准人放行 | 复核意见、批准记录 | 复核意见明确结论，高等级产出有批准人签署 |
| 归档与留痕 | 登记记录、产出物、复核与批准记录 | 将全过程记录归入统一位置，与产出物版本对应 | 完整留痕记录 | 按任务可一次调出从登记到批准的全部记录 |
留痕记录至少包含：任务描述、AI参与环节、使用的模型或工具、复核意见、批准人、时间与版本。记录的价值在于争议发生时能逐环节回看，定位责任断点，而不是事后补一份说明。
这些登记、复核与归档动作需要有承载位置。ONES 的 AI 研发管理方案围绕真实项目、真实知识和真实权限运行，基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 能将自然语言指令转化为 ONES 中可追踪的工作，并把结果保存为工作项、Wiki 页面等内容。团队可以把任务登记做成工作项、把复核意见和批准记录写入对应文档状态，使责任流转与日常研发协作在同一处完成。AI生成内容是否带有可识别的来源标注与审计字段，建议在选型或配置时向工具方确认，并作为留痕要求的核验点。
示例：一次AI生成代码变更的责任流转
以下为演示情景，用于说明边界如何走一遍，不代表任何真实项目记录。
场景与分级判断。某研发小组需要为一个支付回调模块补充异常处理逻辑，使用人借助AI生成初版代码。该变更将合入共享分支并随版本发布，影响下游对账环节，出错后需要发版修正，判断为高等级。
各角色动作与交接。提出人（模块负责人）登记任务：目标为补齐回调超时与重复通知的处理，验收口径为覆盖三类异常且通过既有回归用例，初判等级为高，指定使用人与复核人。使用人在授权代码库范围内生成初版，标注“异常分支判断与日志语句由AI生成，接口签名与事务边界由本人编写”，完成本地自查后提交复核。复核人逐段核对异常分支是否覆盖验收口径、日志是否泄露敏感字段，给出“两处分支条件需调整”的退回意见。使用人修改后再次提交，复核人确认通过并注明“质量符合口径，建议放行”。批准人（技术负责人）查看复核意见与留痕记录后签署放行，限定合入范围为本迭代共享分支。
留痕记录内容。该任务的记录包含：任务描述与验收口径、初判等级与判断依据、AI参与环节标注、使用的工具、两轮复核意见、批准人与批准时间、产出物版本号。记录与代码变更关联，可按任务调出。
争议时的追溯路径。若上线后出现漏处理某类异常，按记录回看：先确认验收口径是否覆盖该类异常，再核对复核意见是否识别到该分支，最后查看批准范围是否包含该场景。责任断点落在哪一环，就针对该环修订规则，例如补充验收口径模板或调整复核检查项，而不是笼统追责。
完成检查：边界是否真的生效
规则写完不等于边界生效。以下清单用于定期核对，建议每季度执行一次，高等级场景全量检查，中低等级场景抽样检查。
| 检查项 | 核验方式 | 通过标准 |
|---|---|---|
| 规则文档与角色名单齐全 | 查阅规则文档，核对各等级场景与四类角色的指定名单 | 等级定义、确认要求、角色名单均有明确版本和生效时间 |
| 留痕记录完整可追溯 | 随机抽取任务，尝试从登记记录调出复核意见、批准记录与产出物版本 | 抽取样本均能完整调出，字段无缺失 |
| 分级执行一致 | 对照分级表检查实际任务的定级与确认动作是否匹配 | 高等级任务均有批准记录，未出现降级执行且无说明的情况 |
| 抽查与复盘机制运转 | 查看历次抽查记录与复盘结论 | 抽查按计划执行，复盘结论有对应的规则或流程修订 |
| 替代安排有记录 | 检查角色缺位时的替代与授权记录 | 替代关系或授权均有书面记录并随产出归档 |
检查不通过时，整改动作要指向具体环节：记录缺失，补的是登记与归档的承载位置和填写要求；分级执行不一致，修的是分级口径或确认动作的触发条件；复核流于形式，调整的是复核检查项与复核人指定方式。整改完成后在下一轮抽查中验证同一问题是否消失，验证结果纳入复盘记录。
当团队的使用场景发生变化，例如引入新的AI工具或扩大AI参与范围，应同步复核分级表与角色名单，确认原有边界仍覆盖新场景，再进入常规检查循环。
常见问题
团队规模很小，四类角色分不开怎么办？
小团队可以一人兼任多个角色，但高等级产出上使用人与批准人应当分离，这条底线建议保留。提出人与使用人合并、复核人与批准人合并，在低等级场景通常可行；进入对外交付或生产变更时，至少让另一名具备判断能力的人承担批准动作。兼任关系要写进角色名单，注明谁在什么情况下代行哪个角色，避免事后说不清当时由谁放行。
AI参与环节标注到什么程度才算够用？
标注的目标是让复核人能识别哪些部分由AI生成、哪些由人编写，从而把核对精力放在正确的位置。实践中可以按段落、函数或章节标注，并说明使用的工具。标注过粗（例如整份文档只写一句“AI辅助”）会让复核失去着力点；标注过细又会增加执行负担。建议以复核人能否据此定位核对范围为判断标准，并在复盘中根据退回意见调整标注粒度。
留痕记录应该放在哪里，用文档还是工作项？
两种承载方式都可以，关键是能按任务一次调出从登记到批准的全部记录，并与产出物版本对应。工作项适合承载任务登记、状态流转和复核结论，文档适合承载较长的复核意见和规则说明。ONES 的 AI 研发管理方案围绕真实项目、真实知识和真实权限运行，基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 能把自然语言指令转化为 ONES 中可追踪的工作，并把结果保存为工作项、Wiki 页面等内容。团队可以据此把登记、复核与归档放在同一处完成。AI生成内容是否带有可识别的来源标注与审计字段，建议在选型或配置时向工具方确认。
使用人自己判断等级，会不会普遍往低里定？
这是分级执行中最常见的偏差。可以用三种方式约束：分级口径用可观察特征描述，例如是否进入生产环境、是否对外可见、是否可在一个工作日内撤回，减少解释空间；同时符合多个等级特征时按最高等级执行；抽查时专门对照定级与实际确认动作是否匹配，发现降级执行且无说明的，作为整改项处理。定级偏差反复出现在同一类场景时，考虑把该场景直接写进分级表的典型示例。
引入新的AI工具后，原有责任边界需要整体重写吗？
通常不需要整体重写，先做一次覆盖性复核：新工具的使用场景能否归入现有等级，原有角色名单是否仍然适用，留痕记录能否覆盖新工具产生的产出。复核结论可能是补充典型场景、调整某级确认要求，或新增一条标注要求。复核结果记录原因和生效时间，再进入常规检查循环，这样规则演进有据可查，也不会因为工具变化而频繁推翻整套机制。
