制定AI助手使用规范，先划定适用范围与禁用场景，再明确数据与输入边界、输出审核与责任、工具与账号准入、留痕与审计四条主线，最后落到可执行的条款、角色分工和检查表。规范宜从一页纸的最小版本起步，用真实任务试运行两到四周，按暴露的问题迭代。ONES可承载条款发布、审批记录与使用留痕等管理动作，本文按这一思路给出可直接起草的框架。
要点总览（TL;DR）
- 第一版规范控制在一到两页，先写适用范围和四条主线：数据与输入边界、输出审核与责任、工具与账号准入、留痕与审计，细则留给试运行补充。
- 按任务类型与数据敏感度两个维度交叉判断，形成直接使用、登记后使用、需审批、禁止四档动作，审批人指定到岗位而非个人。
- AI生成内容由使用人承担首要责任，按事实、引用、代码可运行性、合规表述四项复核；对外交付物增加二次审核并签字归档。
- 规范用两到四周真实任务试运行，按“条款不清、流程太长、工具不支持”归因修订，再正式发布并约定季度复审。
- 发布前逐项核对：无审批路径、无留痕方式、无责任人三类情况直接判定不通过。
规范先写哪几条：最小可用框架与条款结构
第一版规范的目标是让团队在两三天内能读懂、能执行、能被检查，篇幅控制在一到两页。写法上先定骨架，再填细则：骨架由适用范围和四条主线构成，细则留给后续试运行补充。
适用范围要写清三件事：生效对象（哪些团队、哪些岗位）、覆盖工具（自建助手、外部通用助手、嵌入研发平台的智能助手）、任务类型（文档、代码、测试、数据、对外沟通）。范围写得越具体，后面条款越容易判断。
四条主线各自回答一个问题：数据与输入边界回答“什么内容可以交给AI”；输出审核与责任回答“产出由谁复核、谁签字”；工具与账号准入回答“用哪个工具、用谁的账号”；留痕与审计回答“事后怎么查”。四条主线之外的内容，如培训、激励，可放到附录，不占正文。
条款建议采用固定句式：场景—允许或禁止—审批人—留痕要求。例如“向外部AI助手输入客户名称、合同金额等客户信息：禁止；如确有必要，须经数据负责人审批，并在使用登记表中记录输入摘要与审批单号”。固定句式让每条要求都能落到人、落到记录。
| 条款编号 | 适用场景 | 要求 | 责任人 | 留痕方式 |
|---|---|---|---|---|
| R-01 | 公开信息整理、通用文案润色 | 允许直接使用，输出须经使用人复核 | 使用人 | 无需单独登记 |
| R-02 | 内部需求文档、测试用例初稿 | 登记后使用，输出经同行复核 | 使用人、复核人 | 使用登记表 |
| R-03 | 含客户信息、个人信息的数据分析 | 需审批，输入前完成脱敏 | 数据负责人 | 审批单、脱敏记录 |
| R-04 | 核心源码、商业机密、未公开财务数据 | 禁止输入外部工具 | 团队负责人 | 违规记录与处置单 |
最小版本与后续扩展的关系要写进规范本身：明确本版覆盖哪些场景、哪些场景暂按“需审批”处理，并约定复审周期。这样团队知道边界在哪，也知道下一版会补什么，避免把未覆盖场景当成默许。
分场景定规则：哪些任务可以用AI助手，哪些要审批
笼统写“可以使用AI”无法执行。有效的做法是按任务类型和数据敏感度两个维度交叉判断，形成四档动作：直接使用、登记后使用、需审批、禁止。
任务类型可按研发团队的实际工作划分：文档撰写与润色、需求分析与测试用例生成、代码辅助（补全、解释、单测生成）、数据分析与报表、对外沟通材料。每类任务的风险点不同：文档类风险在事实错误与表述合规，代码类风险在许可证与可运行性，数据类风险在信息泄露，对外材料风险在口径不一致。
数据敏感度按四级划分：公开信息、内部信息、客户与个人信息、核心源码与商业机密。等级越高，动作越严。两个维度交叉后，同一任务类型在不同数据等级下可能对应不同动作，这正是规范需要写清的地方。
| 任务类型 | 公开信息 | 内部信息 | 客户与个人信息 | 核心源码与商业机密 |
|---|---|---|---|---|
| 文档撰写与润色 | 直接使用 | 登记后使用 | 需审批 | 禁止 |
| 需求与测试用例 | 直接使用 | 登记后使用 | 需审批 | 禁止 |
| 代码辅助 | 直接使用 | 登记后使用 | 禁止 | 禁止 |
| 数据分析 | 直接使用 | 需审批 | 需审批 | 禁止 |
| 对外沟通材料 | 登记后使用 | 需审批 | 需审批 | 禁止 |
审批人要按场景指定到岗位而非个人，避免人员变动导致流程中断：数据类由数据负责人审批，对外材料由市场或商务负责人审批，代码类由技术负责人审批。审批留痕用统一表单记录申请时间、场景、数据等级、审批结论，便于季度汇总。
“登记后使用”这一档容易被忽略，它适合内部信息场景：不设审批门槛，但要求在使用登记表中记录任务、工具和输出用途。登记的目的不是管控每一次使用，而是让团队掌握AI在哪些环节被使用，为后续评估和审计提供样本。
数据与输入边界：写清能输入什么、不能输入什么
数据条款如果只写“注意保护敏感信息”，执行时无法判断。要把分级要求翻译成具体动作：哪类字段必须替换、哪类截图必须裁剪、哪类内容整段禁止粘贴。
输入规则按数据等级逐级收紧。公开信息可直接输入；内部信息输入前去除项目代号、客户名称等可识别字段；客户与个人信息须完成脱敏并经审批；核心源码与商业机密不进入外部工具。规则要写明“输入前”这个时点，因为事后补救往往来不及。
脱敏的具体做法要给出可操作的示例：人名替换为“用户A”，公司名替换为“客户X”，金额按比例缩放并标注“示例数据”，截图裁掉账号、路径和窗口标题，日志粘贴前删除IP与令牌。规范里附一张脱敏对照表，比长篇原则更有效。
第三方工具的数据留存与训练使用需要逐项查证：输入内容是否被存储、存储多久、是否用于模型训练、能否关闭、数据存放在哪个区域。这些信息以工具服务条款和实际配置为准，规范中应写明“准入前须查证并记录结论”，而不是预设某工具安全或不安全。
违规输入的发现与处置路径要写清：任何人发现违规输入，当天报告团队负责人；负责人评估影响范围，必要时通知数据负责人；涉及客户信息的按公司数据事件流程处理；处置结果记入违规记录，并在月度例会上做匿名复盘。路径写短，才有人愿意走。
输出审核与责任归属：谁对AI产出负责
AI生成内容的责任由使用人承担，这是规范中最需要明确的一条。审核人和团队负责人承担复核与监督责任，三者分工不同，不能互相替代。
使用人的复核义务包括四项：事实核对（数据、结论、引用来源是否准确）、引用检查（是否存在编造文献或链接）、代码可运行性（能否编译、测试是否通过、许可证是否兼容）、合规表述（对外材料的口径、承诺与免责表述）。复核不是通读一遍，而是按这四项逐项确认，规范可要求在使用登记中勾选。
对外交付物与客户可见内容实行二次审核：使用人复核后，由未参与生成过程的同事或负责人再审一次，重点看事实与承诺。二次审核人签字后才可对外发送，签字记录随交付物归档。
AI参与程度建议用三档标注：辅助（AI提供思路或片段，主体由人撰写）、协作（AI生成初稿，人修改定稿）、生成（AI产出为主，人复核）。标注放在文档属性或提交说明中，便于读者判断内容来源，也便于后续统计AI使用情况。
| 角色 | 复核职责 | 签字或记录 |
|---|---|---|
| 使用人 | 事实、引用、代码可运行性、合规表述四项复核 | 使用登记表勾选 |
| 二次审核人 | 对外交付物的事实与承诺复核 | 交付物审批记录 |
| 团队负责人 | 监督执行、处理违规、组织复盘 | 违规处置记录、月度复盘纪要 |
工具准入、账号与留痕：让规范可被检查
规范能否落地，取决于能否被检查。工具准入、账号管理和留痕字段是可检查性的三个抓手。
工具准入评估至少覆盖五项：数据存放位置与区域、权限模型（能否按项目或角色隔离）、日志能力（记录哪些操作、保留多久、能否导出）、退出与导出机制（停用时数据能否取回）、服务条款中关于训练使用的约定。评估结论写成一张表，由技术评审与安全评审共同签字，未通过评估的工具不进入团队推荐清单。
账号管理要求实名与权限最小化：一人一号，不使用共享账号；按项目授权，离项即回收；外部工具账号由团队统一登记，离职时同步注销。账号清单每季度核对一次。
留痕字段建议固定为：使用日期、使用人、任务类型、使用工具、输入摘要（不含敏感原文）、输出用途、复核人、AI参与程度。字段不宜过多，否则登记成本高、执行率低。留痕记录按月归档，保存期限按公司数据管理要求执行。
定期抽查按季度进行，样本从使用登记表中随机抽取，覆盖各任务类型，重点检查需审批场景是否有审批单、对外交付物是否有二次审核签字。抽查结果形成简短报告，问题项限期整改并复查。
在研发团队中，规范条款、审批单和使用登记可以依托统一的工作平台管理。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，基于项目数据和团队知识回答问题，并将结果保存为工作项或 Wiki 页面，使AI使用过程与项目记录处在同一上下文中；ONES 方案基于权限体系执行知识问答和任务执行，输出过程可追踪、结果可审计。团队可以把审批单建成工作项类型、把使用登记沉淀为 Wiki 页面，让留痕随研发流程自然产生，减少额外填报。日志的具体粒度与保留策略以实际部署配置为准，规范中应写明查证结论。
角色分工与推行节奏：从起草到生效怎么走
规范由谁写、谁审、谁推，决定了它是一纸文件还是团队习惯。建议设一个规范owner，通常由研发流程负责人或质量负责人担任，负责起草、汇总意见和维护版本。
角色分工如下：规范owner负责起草与修订；技术评审负责代码辅助、工具准入相关条款；安全与数据评审负责数据分级、输入边界与违规处置条款；团队负责人负责在本团队宣贯、监督执行和处理违规；一线使用人负责按条款使用、登记和复核。每个角色在规范中对应具体条款，避免出现“大家共同负责”的模糊表述。
推行节奏建议五步：起草（一周内完成最小版本）、评审（技术、安全、法务各一轮，合并意见）、试运行（两到四周，选取两三个真实任务类型）、发布（根据试运行修订后正式生效）、复审（每季度一次，或工具与法规变化时提前）。
试运行期的问题收集用轻量方式：在使用登记表中加一列“执行困难”，每周汇总一次；试运行结束开一次半小时复盘会，按“条款不清、流程太长、工具不支持”三类归因，只改影响执行的问题。
规范要与现有流程衔接：代码辅助的复核并入代码评审环节，不另设流程；对外材料的二次审核并入现有发布审批；使用登记挂靠在项目文档或工作项中，不新建独立系统。衔接点写进规范，执行时才不会两套流程并行。
示例：一个十人研发团队的规范落地片段
以下片段为演示情景，用于说明条款写法与执行方式，不代表真实团队数据。
场景一，需求文档撰写。条款原文：“使用AI助手起草需求文档时，输入限内部信息等级，须去除客户名称与合同金额；输出由需求负责人复核事实与范围描述，确认后在文档属性中标注AI参与程度为‘协作’。”执行方式：使用人在使用登记表记录任务与工具，需求负责人在评审会上确认。
场景二，测试用例生成。条款原文：“允许使用AI生成测试用例初稿，输入不得包含生产环境数据；生成结果须由测试负责人补充边界用例并执行验证，验证通过后方可入库。”执行方式：用例评审记录中注明AI参与，验证结果附在测试报告中。
场景三，代码辅助。条款原文：“代码补全与解释可直接使用；涉及核心模块的代码生成须经技术负责人审批，生成代码须通过代码评审与单元测试，并检查许可证兼容性。”执行方式：审批单作为工作项关联到合并请求，评审人可见。
违规输入处理示例：某成员将含客户名称的日志粘贴到外部助手，当天报告团队负责人；负责人确认未涉及账号与金额，通知数据负责人评估；该成员完成脱敏重做，违规记录归档，月度例会匿名复盘，规范中补充“日志粘贴前删除客户标识”的示例。
试运行两周后的修订示例：原条款要求所有内部信息使用均需登记，实际执行率不足一半；修订为“文档与用例类登记，代码补全类不登记，按季度抽查”，登记负担下降，抽查仍保留。修订记录写明版本号、修订条款、原因和生效日期。
完成检查：规范发布前的核对清单
发布前用清单逐项核对，每项给出通过标准。任一阻断项未通过，规范不发布。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 场景覆盖 | 五类任务类型与四级数据等级均有对应动作，无空白格 | 是 |
| 审批路径 | 每个“需审批”场景均写明审批岗位与审批表单 | 是 |
| 责任人 | 每条要求对应到岗位，无“相关人员”表述 | 是 |
| 留痕方式 | 每条要求写明记录载体与字段，登记表已可用 | 是 |
| 工具准入 | 推荐工具均完成五项评估并签字，未评估工具不在清单内 | 是 |
| 账号规则 | 实名、按项目授权、离职注销三条可执行 | 否 |
| 试运行安排 | 明确试运行周期、样本任务与问题收集方式 | 否 |
| 复审机制 | 写明复审周期与触发提前复审的条件 | 否 |
| 违规处置 | 报告路径、评估人、记录方式齐全 | 是 |
三类情况直接判定不通过：存在“需审批”场景但没有审批路径；条款要求执行但没有任何留痕方式；条款找不到责任人。这三项分别对应审批、审计和责任三个支点，缺一项规范就无法被检查，也无法在出现问题时追溯。
清单核对完成后，由规范owner汇总签字，随规范一起归档。下一版修订时，先对照本清单复查，再进入试运行。规范的价值不在篇幅，而在于每条要求都能找到人、找到记录、找到检查方式。
常见问题
团队规模很小，也需要写完整的AI助手使用规范吗？
小团队同样需要规范，但可以更短。十人左右的团队，一页纸覆盖适用范围、四档动作和复核责任即可，审批人由负责人兼任，登记表用现有文档承载。规范的作用是让成员在遇到客户信息、核心代码这类内容时有明确判断依据，篇幅长短不影响这一点。团队扩大或引入新工具时，再按试运行暴露的问题补充条款。
试运行期间发现登记负担太重，应该删掉登记要求吗？
先区分登记的目的再决定。登记用于掌握AI在哪些环节被使用、为审计提供样本，全部取消会让留痕和抽查失去依据。更可行的做法是缩小登记范围：文档与用例类保留登记，代码补全类改为按季度抽查，同时保留审批场景的审批单。修订时写明版本号、修订条款、原因和生效日期，下一轮复审时再评估执行率。
外部AI工具的服务条款说数据不用于训练，还需要在规范里查证吗？
需要。服务条款会随版本更新，不同套餐和部署形态的约定也可能不同。规范应要求准入前逐项查证并记录结论：输入内容是否被存储、存储多久、是否用于模型训练、能否关闭、数据存放在哪个区域。查证结论写入工具准入评估表并签字，条款变化时触发提前复审，避免依据过时的说明做判断。
使用人已经复核过，对外材料为什么还要二次审核？
使用人复核时容易受生成过程影响，对AI给出的事实和承诺产生惯性信任。二次审核由未参与生成过程的同事或负责人执行，重点看事实准确性与对外承诺口径，签字后才可发送。这一环节并入现有发布审批流程，不另设流程，增加的成本有限，对客户可见内容的把关作用明显。
规范条款、审批单和使用登记分散在多个系统，怎么减少填报负担？
优先把留痕挂靠到研发流程已有的载体上：审批单建成工作项类型，使用登记沉淀为Wiki页面，复核记录随代码评审或发布审批归档。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，基于项目数据和团队知识回答问题，并可将结果保存为工作项或 Wiki 页面，使AI使用记录与项目上下文处在同一处；ONES 方案基于权限体系执行知识问答和任务执行，输出过程可追踪、结果可审计。日志的具体粒度与保留策略以实际部署配置为准，规范中写明查证结论。
