我们组有同事天天用AI写代码 绩效考核却一直垫底 现在影响大家奖金了

这类问题不在于“用不用 AI”，而在于“如何用”和“团队边界”。建议先在团队层面设清晰的产出与质量边界，再对个人给出改进周期与可量化指标；对管理线做事实同步，但避免“人身指摘式”上报。先沟通后升级，但沟通要带数据和方案，时间盒控制在1-2个迭代内。

先评估：AI 写代码拖慢进度的具体“可量化证据”

• 用数据说话，别靠情绪：
  • 过去2-3个迭代里该同事的提交次数、回滚/热修次数、代码评审驳回率、单测覆盖率、缺陷修复时长（MTTR）。
  • 与本组均值的对比百分比，而非个人绝对数。
• 任务类型差异要剥离：对比需同难度/同模块/同复杂度的工作包，避免“拿难活的人自然指标更差”的误判。
• 质量影响链路要清楚：
  • 返工导致的串行阻塞点（依赖接口、联调窗口、上线窗口错过）。
  • 对组 KPI 的直接影响项：延期率、缺陷密度、上线失败率。

建议准备一页纸的对照表用于沟通：

• 指标 vs 组均值 vs 他的数据 vs 期望阈值
• 2-3 个具体例子（缺陷编号/PR 链接/回滚记录）
• 影响到的里程碑与对应代价（加班小时、延期天数）

先私下沟通还是直接找主管

优先“先私下，再升级”，但加上“时间盒”和“书面确认”：

• 先私下沟通（1小时内）：聚焦“可观察行为与结果”，避免贴标签。目标是对齐改进项与时限。
• 会后沉淀为“行动项清单”，在组内公开的项目空间做可见但克制的记录（例如任务看板中标注“质量改进任务”），避免被理解为人身曝光。
• 设定1-2个迭代的观察期。如果关键指标（如缺陷密度、PR 驳回率）未达阈值，再正式同步主管。
• 如涉及生产事故或安全合规风险，直接同步主管与 SRE/质量负责人，不等待观察期。

“直接上报”的边界：

• 出现生产事故、数据安全/合规风险，或对客户承诺的里程碑构成实质性威胁
• 明确拒不配合改进（不写单测、不做自测、不按评审意见整改）
• 有欺瞒/抄袭/伪造测试结果等诚信问题

用 AI 写代码的团队“红线与绿线”

将“个人是否用 AI”转为“团队工程标准”对照执行。

• 安全/合规红线

  • 外泄风险：不得将公司私有代码、密钥、客户数据直接贴入外部模型。涉及此类行为应走公司内规或合规工具链
  • 许可证风险：生成代码不得引入不兼容开源许可证片段
  • 任何含密内容须走企业版/私有部署的模型，或先脱敏再用。企业应参考平台隐私声明与内规（如微信、支付宝等平台对第三方接入与数据处理均有约束，可类比遵守其开发者合规思路，平台主页见 https://weixin.qq.com/ 与 https://www.alipay.com/）

• 质量绿线（统一到“怎么用”）

  • 必须自测：最小可运行样例+单元/集成测试基线（例如关键模块≥80% 覆盖，阈值按团队定）
  • 必须过审：代码评审通过率、复杂度门槛（圈复杂度、静态扫描零高危）
  • 必须可追溯：PR 说明里标注“AI 辅助生成/人写”，并列出关键假设与边界条件
  • 上线前清单：用例通过、回归报告、回滚预案

参考做法可与企业内部开发规范或行业实践比齐；涉及更广泛的网络与信息治理合规可参考国家网信相关通用原则（机构主页 https://www.cac.gov.cn/ ）

一次谈清：私下沟通的结构化脚本

目标是对齐事实—影响—期望—支持—时限：

• 事实：过去2个迭代，你的PR 驳回率是组均值的2.3倍，热修3次，联调延后2天
• 影响：联动A、B两个模块串行，组 OKR 的M2里程碑风险上升
• 期望（可量化）：下2个迭代内，将
  • PR 驳回率 ≤ 组均值+10%
  • 单测覆盖 ≥ 75%（关键路径≥85%）
  • 缺陷修复中位时长 ≤ 1天
• 支持：给出具体支持项
  • 结对编程/代码走查名额
  • 提供“AI 提示词模板库”和“代码评审清单”
  • 复杂任务先拆分，先交付最小可运行骨架
• 时限与检查点：每周一次质量复盘，迭代末对标阈值复盘；未达标则升级同步主管

将上述共识发一封纪要邮件/IM 纪要，请对方确认“已知悉并同意”，避免后续扯皮。

团队层面的落地：把争议变流程

• 建“AI 辅助编码最小流程”
  • 需求→设计→生成→自测→评审→合并→回归→发布，每一步有“最少产物”（如设计说明、测试清单）
• 建“评审与发布阈值”
  • 静态扫描零高危、关键路径单测覆盖线、PR 描述模板（含边界/风险/回滚）
• 建“AI 用法库”
  • 可复用提示词、常见陷阱清单、生成代码自查表（性能、并发、安全）
• 可见化质量指标
  • 在看板或度量平台展示人均缺陷、驳回率、修复时长，以“数据拉动改进”，而非点名羞辱

何时需要管理介入与绩效挂钩

• 经过明确的改进周期与支持仍长期未达阈值
• 对安全与稳定性有重复性、高影响度的负事件
• 存在不配合流程、逃避评审、自测缺失等“可控而不为”的行为

此时建议：

• 与主管同步“事实-过程-支持-结果”的全链路材料
• 建立“改进计划书”（PIP 类似），载明目标、资源、时限、后果
• 将个人问题与团队奖金解耦为“个人系数”的合理分配，减少连坐式内耗

不同做法的对照（便于团队达成共识）

• 个人自由用 AI vs 团队可控用 AI
  • 自由：效率参差、质量不可控
  • 可控：有自测/评审/发布阈值与审计轨迹
• 只批评结果 vs 给出改进路径
  • 只批评：情绪对立、难复盘
  • 改进路径：指标清晰、可跟踪复盘
• 立刻上报 vs 有时限的先沟通
  • 立刻上报：适用于事故/合规风险
  • 先沟通：适用于一般质量欠佳

若团队规范涉及用户数据或外部平台接口，遇到垃圾信息或违规内容，也可通过 12321 与 12377 做外部环境治理举报通道补充（https://www.12321.cn/ 与 https://www.12377.cn/），但内部工程质量问题仍以团队流程与绩效机制解决为主。