研发管理者的技术判断标准，正在因为 AI 进入代码生产环节而扩容：过去评估的是架构合理性、代码质量、交付节奏，现在要加上一问——团队与 AI 的分工方式是否健康、AI 产出的代码如何被评审、AI 能力的边界被多少人理解。这个变化不要求管理者自己成为 AI 应用专家，但要求管理者能判断「AI 用得对不对」，这正是这一轮 AI 素养的核心。
技术判断的标准正在多出哪几条
新增的标准至少有三条：一是 AI 产出的占比与质量是否匹配，团队大量采用 AI 代码但缺陷率同步上升，说明评审机制没跟上；二是上下文与依赖是否清楚，AI 生成的代码容易被「看起来能跑」掩盖隐藏依赖，评审时要求说明来源与依据；三是知识留存是否受损，如果团队把设计思考全部外包给 AI，核心模块的「为什么这么设计」无人能答，这是危险信号。理解被稀释还有更早的信号：新人只问 AI 不问同事，代码讨论越来越少，团队氛围的变化比指标先出现。三条标准的共同指向：AI 提效的前提是理解不被稀释，效率数字好看不等于团队能力在长。
评审 AI 产出时的看重点
评审 AI 生成的代码，关注点与评审人写的代码不同：重点看边界条件、异常处理与安全输入校验，这些是模型的常见薄弱区；看测试覆盖，AI 代码配套的测试是否真实覆盖分支，而不是形式走过场；看一致性，命名、错误处理、日志风格是否与仓库既有约定一致。流程上可以要求 AI 产出的改动在提交说明里标注，让评审人有意识地切换审查重点。通义灵码、CodeBuddy 这类编码助手已在不少团队落地，评审规则跟着工具能力一起迭代，比事后补课省力。
团队 AI 使用规范的制定
规范不必长，四条起步：可用范围，哪些数据可以进 AI 工具、哪些代码库禁止粘贴，与信息安全政策对齐；产出标注，AI 参与生成的代码如何标识，方便追溯；评审要求，AI 产出的代码是否需要额外测试或第二人评审；工具准入，团队统一选用哪些工具，避免私装乱用带来的合规风险。规范写完还要定期复盘，工具更新很快，季度修订一次比一次定终身务实，规范的生命力在于跟得上工具的变化。
度量方式要跟着改的地方
度量体系要防止两个失真：一是代码行数、提交数这类数量指标在 AI 时代迅速贬值，AI 能轻松放大产出数字，考核数量等于鼓励灌水；二是把 AI 工具的使用率当成绩，用得多不等于用得好。更有效的度量是结果侧的：交付周期、缺陷逃逸率、线上故障的修复时长，AI 用得对，这些指标应该改善。度量调整提前和团队讲清为什么，成员才不会把 AI 使用转入地下，反而失去观察窗口。管理者定期抽看 AI 参与度高的模块质量，比看工具报表更能发现问题，也更能及早叫停跑偏的用法。
研发团队用 AI 怎么定规范？
- 团队里老成员抵触 AI 工具，怎么推动？：从抵触的根源入手，多数顾虑是质量与责任归属，用试点模块的质量数据说话，规范里写清责任不变的原则。
- AI 生成的代码出了线上事故，责任怎么算？：责任归属是提交与评审的人，这一条要写进规范，工具是辅助，责任主体不因工具改变。
- 管理者需要自己上手 AI 工具吗？：需要基本体感，不求精通，至少完整走一遍「提问—评审—修改」的流程，判断团队用法时才有依据。
