工具治理、责任

• 责任划分原则（提交/审查/发布各环节）
• 过程与制度责任
• 改进而非追责导向

责任界定应基于"过程与制度"而非仅罚个人：提交者对自己合入的代码负有"理解与验证"责任——即使代码由 AI 生成，提交者须能解释、验证并为其质量把关；审查者负责"发现可发现的问题"责任——按既有审查标准核查，若审查流程存在但未执行则承担相应责任；发布流程负责"门禁与回滚"责任——上线前有测试、门禁、灰度，事故后有回滚与告警。框架上：先查"流程是否被正确执行"，再查"个人是否失职"，避免把 AI 生成作为免责理由，也不把事故简单归咎于单个提交者。最终目的是改进流程（补测试、加门禁、强审查）而非追责。

AI 生成模糊了责任归属，但工程责任仍落在"审核与放行"的人与流程上。以过程与制度为主线划分责任，既保证有人负责，又导向系统改进，避免"AI 背锅"或"个人背锅"。

• 审计记录的内容维度
• 上下文与工具调用的重建
• diff 与人工批准的关联

审计记录需覆盖四个维度：①上下文——Agent 接收到的 prompt、文件内容、工具返回、系统指令，可存摘要+哈希以还原；②工具执行——每个工具调用的参数、结果、时间、Server；③diff——每次修改的文件与 diff 内容（或哈希）；④人工批准——批准人、时间、被批准的操作参数哈希。重建时用唯一的会话/任务 ID 把这些记录关联成时间线，可用 hash 校验记录未被篡改，缺失或异常时标记。审计日志应防篡改（追加写、签名链）并保留足够时长。

重建 Agent 操作是事故调查与合规的核心。把上下文、工具、diff、批准四类记录用统一 ID 关联并防篡改，才能完整还原"Agent 看到了什么、做了什么、谁批准了什么"。

• 遵守保密与隐私边界
• 替代证据的类型（测试、提交、设计决策、复盘）
• 证据的真实性与可验证性

当无法公开完整私有代码时，提供不泄露敏感信息的替代证据：①测试——公开测试用例、测试策略、对测试质量的说明；②提交——提交历史、提交信息、PR 描述、代码评审评论（脱敏后），展示工作方式与合作；③设计决策——分享架构决策记录（ADR）、技术选型理由、权衡与复盘；④重构/抽象——把私有代码抽象成脱敏的示例或伪代码，展示设计思路；⑤成果——性能指标、上线结果、事故复盘。关键是先获得授权并脱敏，证据可被验证（如可运行的最小 demo、可解释的决策），强调"过程与结果"而非"源码本身"。

隐私与能力证明需平衡。用测试、提交、设计决策、复盘等"过程与结果证据"替代源码，既守保密又展示工程能力，且这些证据更能体现真实工程素养。

• AI 生成在这些维度的薄弱点
• 额外 Review 清单的必要性
• 清单驱动审查

AI 生成代码在"隐含约束"上容易出错，而这些正是事故高发区，因此需要专门 Review 清单：①边界条件——空输入、极端值、超长、重复调用常被遗漏；②并发——竞态、共享状态、线程安全常被忽略；③性能——算法复杂度、批量处理、缓存策略可能不佳；④安全——注入、权限、敏感数据、错误处理易有漏洞；⑤依赖——引入未声明/不安全的包、版本问题；⑥License——自动生成的代码可能引入不兼容 license 的片段。这些维度 AI 默认不敏感，需人工 checklist 逐项核查，弥补"生成即多、验证即少"的短板。

AI 擅长生成"看起来正确"的代码，但对边界、并发、性能、安全、依赖、license 等工程约束不敏感。专门 Review 清单把这些高风险维度显式化，强制逐项核查，防止隐含缺陷上线。

• 来源不明的代码风险
• 重写与隔离策略
• 法律审查流程

面对来源不明的代码，按风险处理：①暂不直接使用——先隔离，不进入生产核心路径；②重写——若代码短或有清晰接口，用干净实现重写，避免继承潜在版权；③隔离——若必须使用，将其隔离为独立模块/服务，明确边界，便于替换与审计；④license 审查——交由法律/合规团队审查来源与许可，合同、copyright 声明、使用条款逐一核对；⑤记录——留存来源追溯、审查结论与决策。对于无法确认来源且高风险的部分，最安全是重写并独立验证，而非冒险整合。

来源不明的代码可能有版权、license 或恶意风险。重写规避版权、隔离控制影响、法律审查明确合规，形成"先隔离、可重写、经审查"的安全流程。

• License 继承规则（copyleft 等）
• AI 改写的归属影响
• 归属与合规评估流程

第三方代码经 AI 改写后，License 义务通常仍继承：copyleft（GPL/AGPL）的衍生作品可能仍受其约束，需评估是否触发传染性义务；MIT/Apache 等宽松许可也需保留版权与许可声明。AI 改写不改变"代码源自哪"的事实，因此评估"改写是否构成衍生作品"以及"是否需要开源、保留声明、标注出处"。流程：用依赖/代码扫描识别来源与 license，法律审查判断衍生与传播义务，重写风险高的部分（clean-room 重写）以规避继承，并保留来源追溯记录。

AI 改写不豁免 license 义务。核心是评估"衍生作品"与 license 传染性，结合法律判断与必要时 clean-room 重写，避免把第三方代码的许可义务误解为 AI 生成而消除。

• 归属规则的约定
• 来源与第三方权利
• 制度与合同防范

防范 IP 争议需制度+合同+记录：①约定归属——明确公司/员工/供应商对 AI 生成的代码的权属（通常归雇主，但需在合同/政策中写清），避免个人主张；②来源追溯——记录 prompt、工具、输入，区分"完全原创"与"参考了第三方/AI 训练内容"，对可能承接第三方版权的内容做审查；③第三方权利——核查 AI 输出是否复制了受版权保护的代码或训练数据中的内容，必要时 clean-room 重写；④合规审查——对高风险输出走法律审查并留存审计。核心是"权属事先约定、来源可追溯、第三方权利可核查"。

AI 生成使 IP 归属更模糊，争议多源于"未约定+来源不明"。用合同约定权属、工具记录来源、法律审查第三方权利，把模糊点前置处理，防范 IP 争议。

• 强监管领域的合规要求
• AI 生成的额外险
• 合规放行的机制

在医疗器械、金融、政府等强监管领域，代码需满足可追溯、可验证、可审计、责任清晰的合规要求（如 FDA 软件验证、金融容错与审计、政府供应链安全）。AI 生成代码的"黑盒、不可完全解释、来源不可控"特性与这些要求冲突，因此不能直接上线：需更强的验证（全量测试、形式化验证、独立审查）、来源与授权核查、完善文档与审计、责任界定，并遵守数据与部署合规（数据不出境、审批）。可用性取决于是否能达到监管要求的验证与审计水平，必要时 AI 只做辅助、关键逻辑人工主导并走正式的合规放行流程。

强监管领域把"可追溯、可验证、可审计、责任明确"作为硬要求，AI 生成因其不可解释性天然受限。通过强化验证、来源核查、责任界定与合规流程，才能让 AI 代码在受控前提下被采用。

• 治理文件的优先级与合并规则
• 安全策略的不可覆盖性
• 静默覆盖的预防

治理文件需定义明确的优先级与合并规则：通常按"作用域"分层（全局/企业级 > 团队级 > 项目级 > 仓库内），但要区分"安全策略"与"风格偏好"两类：安全策略（禁用 curl|bash、禁写密钥、禁推生产）属于顶层不可被覆盖的"硬约束"，项目级 .cursorrules 只能追加或细化，不能弱化或移除安全策略。合并规则：硬约束取严格并集，内容冲突时以更高优先级+安全策略为准，并检测"覆盖"（如发现 .cursorrules 含弱化安全策略的指令时告警）。IDE/SDK 应校验合并结果，对降级安全策略的改动拒绝或提示。

静默覆盖源于把"安全策略"与"风格偏好"混在一起，且无优先级校验。分离两类、硬约束不可降级、合并时检测弱化，才能防止项目级文件悄悄覆盖安全底线。

• 最小证据清单
• 证据的关联与防篡改
• 事故调查与合规

最小证据应覆盖"做了什么、谁批准的、基于什么、改了什么"：①接收的 prompt hash——还原 Agent 输入，用于判断是否被注入；②启用的 MCP Server 列表与工具——了解可用能力与来源；③批准人、批准时间戳——确认谁放行、何时放行；④产生的 diff hash——确认实际改动；⑤命令与工具调用记录、结果产出、环境与版本。这些证据用统一任务 ID 关联，用 hash 链防篡改，保留足够时长。事故时按时间线重建：输入→工具→批准→diff→上线，定位事故根因。

最小证据的目标是"低开销、可还原、难篡改"。精准记录 prompt/工具/批准/diff 等关键元素并关联、防篡改，才能在事故时快速重建并满足合规与追责。

• 治理指标的目的定位
• 聚焦质量与风险指标
• 避免个人监控与排名

治理指标应以"改进质量与风险"为定位，而非评估个人：聚焦 AI 使用带来的缺陷率、返工率、代码审查拒绝率、事故与门禁拦截等质量信号，看 AI 是否引入问题而非"谁用 AI 多"。指标应聚合到团队/功能/仓库层面，避免滑向个人绩效排名；用匿名化、聚合粒度保护个人隐私。当指标用于"发现问题、改进流程"（如某场景 AI 缺陷率高→调整 prompt 或补测试）时才有价值，坚决不做"AI 使用率即绩效"的监控。建立指标使用边界，防止误用。

指标若用于个人排名会诱发博弈与不信任，且偏离目标。聚焦质量与风险、聚合到团队、保护隐私、用于流程改进，才能让治理指标服务工程而非监控员工。

• 分层统计维度（语言、场景、开发者）
• 排除打字速度与接受后删除的混淆
• 采纳率的正确口径

采纳率应分层统计：按语言（JS 与 Python 采纳率差异大）、按场景（新写 vs 修改已有代码）、按开发者技能水平分别统计，避免混在一起掩盖真实差异。同时排除混淆因素：打字速度快的开发者可能"接受后再改"，把"接受后立即删除/大幅修改"不算作有效采纳；要区分"接受 token"与"接受后保留"的有效采纳。用有效的、保留的采纳口径，并控制打字速度与编辑行为的影响，才能反映补全质量而非表面接受率。

简单采纳率会被语言/场景/个体差异和"接受即删"污染。分层统计 + 用"接受后保留"的有效口径 + 排除打字速度，才能得到能指导优化的真实信号。

• 首字时间（TTFT）与采纳率关系
• 模型大小与上下文采集的取舍
• 延迟影响的度量

补全对延迟敏感，首字时间（TTFT）过高会显著降低采纳率，因此需设定延迟预算（如 TTFT<几百 ms）。取舍：模型越大质量越高但延迟越高，需在质量与延迟间权衡；上下文采集范围越大受益越多但采集与推理延迟越高，需按需采集（只取相关符号/文件）。度量延迟影响：做 A/B 或分桶实验，对比不同 TTFT 下的采纳率、完成率，找到"延迟→采纳率"的敏感区间，据此设定预算并指导模型/上下文选择。用 p50/p95 而非仅均值评估延迟。

补全是实时交互，延迟是体验瓶颈。用延迟预算约束模型与上下文选择，用实验量化"延迟→采纳率"曲线，才能科学取舍质量与速度。

• 应关闭补全的场景
• 敏感文件与内容的保护
• IDE 层与团队策略的统一强制

对敏感或要求精确的内容应关闭补全：①密钥/凭证文件——AI 可能补全出凭据或把敏感内容传上云；②测试断言——需精确语义，补全易胡编；③许可证头/法律文本——需原文精确，补全会篡改；④凭证配置——涉及真实密钥。在 IDE 层用文件路径/内容规则自动关闭补全（如 .env、密钥文件、license 头部），在团队策略层定义统一规则并下发，防止个人忘记关闭。对敏感文件还可禁用遥测上传。统一强制保证"该关的必关"。

补全在敏感/精确场景弊大于利。IDE 层按文件规则自动关闭 + 团队策略统一强制，从机制上保证这些场景不产生补全，避免泄露与篡改。

• 行级补全与任务级生成的差异
• 小建议逃避评审的风险
• 统一评审与聚合机制

行级补全是"局部小改动"，审查粒度小、单次风险低，容易被忽略；任务级 Agent 生成是"整体功能"，审查粒度大、风险集中。差异在于：行级易被"小、快、频繁"特性掩盖，累积成大量未审改动。防止小建议逃避评审：①统一评审——所有 AI 改动（无论补全还是 Agent）最终都进入 diff 与代码评审，不因"小"而豁免；②聚合——把多个小补全按提交聚合到一次可审查的 diff；③语义审查——聚焦小建议是否改变行为、引入问题，而非只看打字差异；④门禁——小改动也需过测试与门禁。用"改动即需审"覆盖所有来源。

行级补全的"小"恰是逃避评审的漏洞。统一"所有改动都进评审"、把小改动聚合审查、聚焦语义与行为，才能防止小建议累积成未审风险。

• 上传边界的定义
• 保留与训练策略
• 透明化与知情

透明化需明确并告知：①上传内容——哪些代码片段会上云（补全上下文、采纳的片段、敏感文件是否排除），企业模式下可配置"不存储/不用于训练"；②保留时长——遥测与片段保留多久，是否有删除机制；③用途——是否用于模型训练、质量评估、仅作为偶发缺失时的 telemetry；④控制——提供关闭上传、排除敏感文件、本地模式。透明化通过文档、设置面板、合规说明让团队知情，并遵守企业安全与数据政策（如企业代码不进训练、不长期留存）。

代码片段上传涉及隐私与 IP，需向团队透明。明确上传边界、保留、用途与控制选项，企业模式默认不训练不长期留存，让使用透明、可控、合规。

• 区分质量差与场景不匹配
• 分层与归因
• 驱动模型/上下文调整

采纳率低可能是"质量差"（模型本身不行）或"场景不匹配"（上下文不足、任务不适合补全）。区分方法：按场景分层（语言、上下文完整度、任务类型）看采纳率，若某场景整体低而其他高，倾向场景不匹配；若普遍低，倾向质量差。结合用户反馈与"拒绝前的修改"归因：用户部分采纳并修改说明接近但需调整（上下文策略），完全拒绝说明建议不可用（质量）。用遥测归因（补全上下文长度、调用模型、采纳后修改）驱动调整：场景不匹配→增强上下文/调整触发；质量差→换模型/调参。

采纳率低的原因不同，对策不同。用分层统计+用户行为归因区分"质量"与"场景"，避免"一刀切换模型"或"盲目加上下文"的误判。

• 遥测目的定位
• 聚合粒度与去标识化
• 访问权限与使用边界

补全遥测应用"改进产品"而非"监控个人"：①聚合粒度——默认聚合到团队/功能/仓库/产品层面，避免单点个人级画像；②去标识化——对个人数据做匿名/聚合，个人可识别信息不用于评估；③访问权限——遥测数据访问受限，仅产品/质量团队可分析，禁止用于绩效、招聘、惩罚；④使用边界——明确声明遥测用途（质量提升、缺陷分析），禁止派生个人绩效排名。设置数据保留期与访问审计，防止数据被挪作他用。

遥测数据一旦用于个人监控就会破坏信任与数据初衷。通过聚合粒度、去标识化、受限访问与用途声明，把遥测锁定在"改进产品"轨道，防止滑向员工监控。

• 本地 vs 云端的差异维度
• 规模对成本收益的影响
• 评估框架

评估维度：①延迟——本地无网络往返、延迟低，适合高频补全；②隐私——本地代码不出环境，满足强隐私/合规；③订阅费——云端按用量/订阅付费，本地需自购硬件与运维；④质量——云端模型更大、质量通常更高，本地受硬件限制。规模影响：小团队订阅费低、用云端更划算；大团队或对隐私敏感（金融、政府）则本地可避免海量 token 费与数据出境，长期更便宜。评估框架：对比 TCO（订阅/硬件/运维）、延迟要求、隐私合规需求、质量门槛，按团队规模与场景权衡，可混合部署（敏感走本地、高质走云端）。

本地与云端各有利弊，且随规模反转。用延迟、隐私、订阅费、质量四维对比，结合团队规模与合规，做 TCO 与混合部署决策，避免一刀切。

• 成本分类维度
• 探索成本的可补贴性
• dashboard 的归因与治理

token 成本 dashboard 应区分"开发探索成本"与"生产/交付成本"：探索成本（试错、原型、研究性 prompt、失败重试）具有探索价值，可补贴或单独预算；生产/交付成本（集成到产品、用户请求）纳入正常成本核算。分类维度：按用途（探索 vs 生产）、按任务类型（一次性研究 vs 持续功能）、按用户（开发者 vs 终端用户）、按环境（开发 vs 生产）。dashboard 按这些维度归因，识别"探索成本占比"与"浪费"（重复失败、无效重试），用于优化（失败重试预算、缓存、降级）。区分后可对探索成本设补贴额度，避免与生产成本混算。

探索与生产成本性质不同，混算会误导治理。按用途/环境/用户分类归因，识别可补贴的探索成本与可优化的浪费，让成本管理既支持创新又不失控。

• A/B 实验设计（随机化、对照）
• 结果指标选择（效率、缺陷率）
• 避免只看采纳率

A/B 实验需真随机化与对照组：把开发者/任务随机分实验组与对照组，控制并发变更与污染。结果指标应选"交付效率与缺陷率"：效率（任务完成时间、pr 数量、代码量）、缺陷率（评审拒绝率、测试失败率、线上缺陷、返工）。同时跟踪采纳率但不是唯一标准。需控制变量（任务难度、开发者技能），用足够样本与显著性检验，排除"采用率被采纳率驱动"的假象。设计上考虑学习效应与跨组污染，用长时间窗与分层分析。

只看采纳率会忽略补全是否真的提升效率或引入缺陷。A/B 用随机化对照，以效率与缺陷率为结果指标，才能回答"补全是否值"而非"是否被用"。

• 诚实说明 AI 协作
• 保留个人贡献证据
• 可验证性

诚实说明 AI 协作：在简历/博客中明确"使用了 AI 辅助（如 Cursor/Copilot/Agent）"，并说明 AI 的角色（草稿、重构、测试辅助）与自己的工作（设计、审查、集成、调试）。同时保留个人贡献的可验证证据：设计决策与架构方案、独立完成的 Review 与排错、对生成内容的审查与修正、能运行的 demo/测试/提交记录。通过"展示过程与决策能力"而非"展示 AI 输出了多少"来证明个人价值，并避免把 AI 生成的代码冒充纯原创。证据可验证（可复现、可解释、可上手的 demo）。

AI 时代能力证明从"是否写了"转向"能否设计、判断与把控"。诚实说明 AI 协作 + 用设计决策、审查、调试等可验证证据展示个人贡献，既诚信又区分了人与 AI 的差异。

• 多维成本归因
• SDK 层的预算守卫
• 治理与告警

多维归因：给每个请求打上 developer、feature、repo 等标签，在 SDK/网关层记录并把 token 成本按这些维度拆分统计，形成 per-developer、per-feature、per-repo 的成本视图。SDK 层做 per-request budget guard：设单次请求/会话的 token 与成本预算，超限即拦截、降级或告警，防止异常请求（如循环重试、超大 prompt）烧钱。治理：按维度设预算阈值、识别异常消耗、缓存与去重、失败重试控制，配套 dashboard 与告警。从请求级守卫到团队级归因形成闭环。

成本治理需要"可归因 + 可控制"。标签化归因看清成本去向，SDK 层 budget guard 在请求级拦截异常，两者结合才能既控总量又控单点。