制定AI助手使用规范，核心是把“随手用一下”变成有边界、有审核、有留痕的可管理动作。本文按范围分级、操作流程、角色分工、条款模板、落地检查五个部分展开，给出可直接填写的表格与清单。规范条款、使用记录和审核动作需要承载平台时，可考虑放进ONES这类研发管理工作项与文档体系中流转。
要点总览（TL;DR）
- 规范先划边界：按任务类型与数据敏感度交叉判断，把场景分为自助可用、需审批、禁用三类，并写明哪类数据能进哪类工具。
- 操作流程统一为提出、审核、采纳、留痕四步，每步写清输入、动作、输出与完成标志；自助场景可跳过审核，提出与留痕不能省。
- 角色设使用者、审核者、规范维护者、团队负责人四类，提出者与审核者分离，并写明争议与异常的上报对象、响应时限与最终决定人。
- 条款写成固定字段的表格：场景、允许动作、限制条件、审核要求、留痕方式，带版本号与生效日期，废止条款保留以便对照历史记录。
- 落地用三层检查验证：发布前准入检查、运行中抽查记录、定期复盘指标；条款均有责任人、记录可追溯、抽查无高风险未审批使用，即视为生效。
规范先定边界：哪些场景可用、哪些必须审批
规范的第一件事是划范围。范围不清，后面所有审核都会变成逐次争论。建议用两个维度交叉判断：任务类型决定“用来做什么”，数据敏感度决定“能喂什么进去”。两个维度都落在低风险区，才允许自助使用；任一维度进入高风险区，就转入审批。
按任务类型，可把场景分为三类：
- 可用（自助）：低敏感内部信息的整理、摘要、改写、会议纪要初稿、测试用例草稿、公开文档的措辞润色等。使用者自行判断，事后按约定留痕。
- 需审批：涉及客户数据、未公开代码、合同与报价信息、对外发布内容、影响交付承诺的估算与排期建议。使用前提交申请，由指定审核人确认输入范围和输出用途。
- 禁用：法律法规或合同明确禁止外传的数据、涉及个人隐私的原始记录、安全密钥与凭证、未经授权的第三方代码，以及需要承担法律责任的正式结论直接由AI生成后对外使用。
数据敏感度需要单独写明限制条件。低敏感指已在团队内部公开、可被全员查阅的信息；中敏感指限项目组可见的需求、设计、缺陷信息；高敏感指客户数据、财务数据、未发布版本代码与安全相关配置。中高敏感数据进入外部AI工具前必须审批，进入已部署在受控环境内的助手可按团队约定简化流程。这一条要写清楚“哪类数据进哪类工具”，避免只写“注意数据安全”。
规范还要写明适用对象与工具范围：覆盖哪些角色（研发、测试、产品、项目管理）、覆盖哪些工具（外部通用助手、内部部署助手、集成在研发平台中的助手）。工具清单建议附在规范末尾并标注版本，新增工具时走同一条准入流程。
场景分级表可直接填写：
| 场景 | 数据等级 | 是否需审批 | 责任人 |
|---|---|---|---|
| 会议纪要整理与摘要 | 低 | 否 | 使用者本人 |
| 需求文档初稿生成 | 中 | 是 | 需求负责人 |
| 测试用例草稿补全 | 中 | 是 | 测试负责人 |
| 客户反馈归类分析 | 高 | 是（含数据脱敏确认） | 项目负责人 |
| 对外发布文案生成 | 高 | 是 | 市场与法务指定审核人 |
| 生产环境配置与密钥处理 | 高 | 禁用 | — |
从提出到采纳：AI助手使用的四步操作流程
边界定好后，需要一条固定动作链，让每次使用都能被追溯。建议统一为提出、审核、采纳、留痕四步，每步都写清输入、动作、输出和完成标志。四步不必都走完整审批，自助场景可跳过第二步，但第一步和第四步不能省。
第一步：提出。使用者填写使用申请或在任务记录中登记，输入信息包括：使用目的、任务类型、拟使用的工具、输入数据范围与等级、预期产出形式、计划使用时间。动作是把这些字段填完整并关联到对应工作项或需求。输出是一条可查的使用记录。完成标志是记录已创建且数据等级判断明确。
第二步：审核。审核人核对三件事：输入数据是否超出该等级允许范围、产出用途是否与申请一致、是否涉及对外承诺或法律风险。审核动作是给出通过、附条件通过或退回，并写明理由。输出是审核结论与附加限制（如“输出需人工逐条核对后再使用”）。完成标志是审核结论已记录在案，附条件项已明确。
第三步：采纳。使用者对生成结果做事实核对与质量判断，判断依据包括：关键数据是否可溯源、结论是否有原文支撑、是否存在明显错误或遗漏、是否满足交付标准。采纳时注明“直接采纳”“修改后采纳”或“弃用”，弃用也要记录原因，便于后续复盘哪些场景不适合使用AI。输出是采纳结论与修改说明。完成标志是结果已进入正式交付物或明确弃用。
第四步：留痕。把使用记录、审核结论、采纳说明归档到统一位置，与对应工作项、文档或需求关联。留痕内容包括工具名称、使用时间、输入摘要（不存原始敏感数据）、输出摘要、审核人与采纳人。完成标志是记录可被检索，且能回答“这份产出用了什么AI、谁审的、谁采纳的”。
四步的输入输出清单可整理为一页流程说明，贴在团队文档首页。流程本身不复杂，难点在于让记录成为习惯，因此留痕动作应尽量嵌入现有工作流，而不是另开一套表格。
角色与交付物：谁提出、谁审核、谁负责
流程要落到人身上才有约束力。建议设置四类角色，并遵循提出者与审核者分离的原则：同一人不能既申请又批准高风险场景的使用。
| 角色 | 主要职责 | 对应交付物 | 交接节点 |
|---|---|---|---|
| 使用者 | 判断场景、填写申请、核对输出、完成留痕 | 使用记录、采纳说明 | 提交申请时、采纳结论形成时 |
| 审核者 | 核对数据范围与用途、给出审核结论与限制条件 | 审核结论、附加限制说明 | 审核完成时移交使用者 |
| 规范维护者 | 维护条款版本、更新工具清单、收集问题并修订 | 规范文档版本、变更记录 | 定期修订时、新增工具准入时 |
| 团队负责人 | 处理争议、协调资源、组织复盘、决定升级事项 | 争议处理结论、复盘纪要 | 异常上报时、复盘会议后 |
争议与异常的升级路径要写具体。常见情形有三类：使用者与审核者对数据等级判断不一致；审核人缺位或超时未处理；发现已采纳的产出存在错误或数据泄露风险。前两类由团队负责人裁定或指定临时审核人，第三类立即暂停相关产出使用，由负责人组织核查并记录处理结果。升级路径写明“向谁报、多久内响应、谁做最终决定”，避免出现问题时无人拍板。
角色分工还要与留痕对应：每条使用记录都应能指向具体的提出者、审核者和采纳者。这样复盘时才能区分是条款不清、审核失守还是使用不当。
条款怎么写：规范文档的字段与示例
规范文档建议写成条款表，一条条款对应一个场景或一类动作，字段固定，便于填写和检查。推荐字段为：场景、允许动作、限制条件、审核要求、留痕方式。每个字段都要写到可执行的程度，“合理使用”“注意安全”这类表述无法检查，应替换为具体动作或判断标准。
一条完整条款的填写示例：
| 字段 | 填写内容 |
|---|---|
| 场景 | 基于内部需求文档生成测试用例草稿 |
| 允许动作 | 将需求文档中已对项目组公开的部分输入助手，生成用例草稿；使用者逐条核对后补充边界条件 |
| 限制条件 | 不得输入客户名称、真实用户数据与未发布版本信息；单次输入不超过该需求文档范围 |
| 审核要求 | 测试负责人审核输入范围与用例覆盖度，输出需标注“AI草稿，已人工核对” |
| 留痕方式 | 在对应测试任务下记录工具名称、使用时间、审核人与采纳结论 |
条款的版本与更新维护同样要写进规范。建议每条条款带版本号和生效日期，规范维护者按季度或按触发事件（新增工具、发生违规、法规变化）修订，修订记录保留变更原因与影响范围。条款废止时不删除，标注失效日期，保证历史使用记录仍可对照当时的条款判断合规性。
条款数量不必求多，先覆盖高频场景和明确禁用场景，运行一段时间后按实际申请记录补充。新增条款走与初次制定相同的评审，避免规范越写越厚却无人执行。
落地与检查：准入、过程与复盘三层验证
规范发布不等于生效，需要用三层检查验证执行情况。三层检查各有侧重：准入检查看“能不能开始用”，过程检查看“用的时候守没守规矩”，复盘检查看“规范本身是否合理”。
发布前准入检查。核对项包括：场景分级表是否覆盖团队主要使用场景；每条禁用场景是否有明确判断标准；四步流程的输入输出是否完整；四类角色是否都已指定到人；条款模板是否可直接填写；工具清单是否标注版本。全部满足才发布，缺项列明补齐责任人与时间。
运行中抽查与记录核对。建议每月抽查一定比例的使用记录，核对三件事：记录字段是否完整、审核结论是否与实际使用一致、采纳说明是否包含核对动作。抽查发现记录缺失的，先补流程再追原因；发现高风险场景未审批的，按升级路径处理并纳入复盘。抽查比例和频次按团队使用量确定，使用量小的团队可按季度抽查。
定期复盘的指标与改进动作。可观察的指标包括：审批通过率与退回原因分布、弃用比例及弃用场景、抽查记录完整率、因AI产出导致的返工或纠错次数。复盘输出应是具体的条款修订或流程调整，例如某类场景退回率持续偏高，说明限制条件写得过严或审核标准不清，需要修订条款而非反复提醒。
判定规范生效的完成标志可以设为三条：所有条款都有明确责任人；抽查范围内的使用记录可追溯且字段完整；抽查未发现高风险场景未经审批的使用。三条同时满足，说明规范已进入运行状态，后续转入常规维护。
当团队希望把使用记录、审核结论和采纳动作放进同一套研发管理流程时，ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把结果保存为工作项或 Wiki 页面，减少页面切换和重复录入。基于 ONES 权限体系进行知识问答和任务执行时，输出过程可追踪、结果可审计，适合承载规范中的留痕与审核流转。具体权限配置与审批流设置需结合团队现有流程确定。落地前也可参考 ONES 的建议：先梳理研发流程、现有数据与高频协作问题，再确定AI能力的应用范围和推进路径，这与本文先定边界、再定流程的顺序一致。
常见问题
团队刚开始用AI助手，规范要不要一次写全所有场景？
不必。建议先覆盖两类内容：高频使用场景和明确禁用场景。高频场景决定日常执行效率，禁用场景守住底线。其余场景在运行一段时间后，按实际申请记录和退回原因逐步补充条款。
新增条款走与初次制定相同的评审，由规范维护者提出、团队负责人确认后生效。这样规范能保持可执行，避免一次写得很厚却无人对照使用。
自助场景跳过审核，出了问题责任怎么算？
自助场景的边界要在条款里写清楚：允许输入什么数据、产出用于什么范围、需要做哪些核对。使用者在范围内使用并完成留痕，责任按条款约定归属；超出范围使用，则按违规处理，走升级路径。
留痕是责任判断的依据。每条记录应能指向提出者、采纳者和使用时间，这样复盘时才能区分是条款不清、判断失误还是越界使用。
审核人经常缺位或超时，流程卡住怎么办？
在规范里为每类场景指定一名主审核人和一名备选审核人，并约定响应时限。超时未处理时，使用者可向团队负责人上报，由负责人指定临时审核人或直接裁定。
如果某类场景长期因审核积压影响交付，说明审批范围可能设得过宽，应在复盘中重新评估该场景的数据等级与审批要求，调整条款而不是靠催办维持。
使用记录放在哪里比较合适，需要单独建一套系统吗？
优先嵌入现有工作流。记录与对应的工作项、需求或文档关联，比另开一套表格更容易坚持。记录内容至少包括工具名称、使用时间、输入摘要、输出摘要、审核人与采纳结论，原始敏感数据不写入记录。
当团队希望把使用记录、审核结论与采纳动作放进同一套研发管理流程时，ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把结果保存为工作项或 Wiki 页面。基于 ONES 权限体系进行知识问答和任务执行时，输出过程可追踪、结果可审计。具体权限配置与审批流设置需结合团队现有流程确定。
怎么判断规范真的在起作用，而不只是发了一份文档？
看三个可观察的信号：抽查范围内的使用记录字段完整、可追溯；抽查未发现高风险场景未经审批的使用；复盘能拿出具体的条款修订或流程调整，而不是只重复提醒。
如果退回率集中在某一类场景，通常说明限制条件或审核标准需要修订；如果弃用比例偏高，说明该场景可能不适合用AI助手，应调整适用范围。指标用于改进条款，不用于考核个人使用量。
