团队有人 vibe coding 上瘾、代码没人看得懂，你怎么立规矩？
谁在问：三面 / 技术负责人 / 管理向；考的是你会不会用流程解决人的问题，以及知不知道流程的代价
口语化问法
- 组里有人天天让 AI 一把梭，代码合进来没人看得懂，你怎么管？
- 你们对 AI 写代码有什么规范吗？谁定的、怎么落地的？
- 如果让你现在给团队定一套 AI 编码规矩，你会写哪几条？
考察意图
这道题表面是管理题，实际考四件事：
- 你会不会先诊断再开药。「代码没人看得懂」是症状，不是病因。直接答「加 review、加规范、加覆盖率」的人，等于没听清问题。
- 你知不知道自己在防什么。防许可风险、防质量风险、防可维护性风险，三种规矩长得完全不一样，混在一起就是一堆和自身风险无关的流程。
- 你有没有成本意识。每一条规矩都要有人执行，规矩加满的结果通常是评审队列崩掉、然后大家开始盖章式通过——比没规矩更糟。
- 你会不会推动落地。规矩能不能自动执行，决定它是活的还是一纸空文。
参考答案
60 分答案（及格线）
我会先定规范：AI 生成的代码必须人工 review，必须有测试，覆盖率不能下降；复杂逻辑必须写注释说明思路；提交要小步。然后在 CI 里加检查，不达标不让合。另外组织一次分享，把大家的用法拉齐。
这是标准答案，没错但没解决问题。它默认了病因是「大家不守规矩」，而真实病因往往是别的：可能是任务拆得太粗导致单次改动太大，可能是没人写完成判据所以只能靠读代码理解意图，也可能是这个人产出确实高、只是没人跟得上他的节奏。没诊断就开药，药大概率不对症。
90 分答案（有生产经验的回答）
第一步是把「看不懂」拆开。 它至少有三种完全不同的病因，对应三种不同的处理：
- 改动太大——一次 PR 四百行，谁都看不懂。这不是 AI 的问题，是任务粒度的问题。
- 意图没留下——代码能读懂，但不知道为什么这么设计。提交信息全是 diff 的复述，规格没写，讨论在私聊里。
- 结构确实在退化——重复代码在涨、抽象在烂。这个有公开数据佐证：某代码分析平台对 6.23 亿行变更的统计显示，块级重复从 2023 年每百万行 40.3 处升到 2026 年的 73.0 处（+81%），而代表重构的「移动代码」从 21% 掉到 3.8%，修改「12 个月未动过的老代码」的比例从 1.7% 掉到 0.46%。AI 倾向于再写一份、不倾向于抽出来，也不倾向于碰老代码——这是慢性损伤，单次评审看不见。
三种病因的药完全不同：第一种加体积上限就好，第二种要补规格和提交信息纪律，第三种要专门排重构工时——只有第三种才是真正难的。
第二步是想清楚在防什么。 2026 年几个开源组织的政策正好是两极，很适合拿来对照：有的立场是防许可链，直接拒收含 LLM 生成内容的有法律意义的贡献，沿用约十五行的老阈值，唯独给测试用例开口子；有的立场是防质量与追责，只要求提交打标记、明确贡献者永远是作者且负全责、必须自己 review 和理解、禁止提交未验证的产物，并且规定 AI 不得单独决定一个 PR 是否被接受；也有基金会不强制披露，只关心工具条款是否与开源许可冲突。你抄哪一套，取决于你怕的是哪一件事。 对绝大多数业务团队，怕的是质量与可维护性，那就不该把精力花在披露上。
第三步按成本排序落地，别一次上齐。 我的顺序是：
- 能自动执行的先上——单 PR 体积上限、diff 触及测试基础设施则强制人工确认、重复率与圈复杂度的趋势告警。这类一天能上，不消耗任何人的耐心。
- 再补判据类——异步派活必须先写可判定的完成判据。这条改的是习惯，需要几周。
- 最后动审批规则——比如高风险目录必须双人评审。这条最招人烦，所以留到最后，而且要有数据支撑再动。
第四步是防止规矩自己变成事故源。 AI 提高的是产能不是判断力，瓶颈会从「写」搬到「审」——有报告把这件事叫验证税，并明确指出人工评审门会成为新瓶颈。有平台方统计显示，同期无人实质评审直接合并的 PR 上升了 31.3%。所以规矩上线之后必须盯一个指标：盖章式通过的比例。它比队列长度更早暴露风险。
最后，我不会禁止 vibe coding。 禁掉的结果是转入地下，而且那个人的产出确实是真的。要管的是它的出口——什么能进主干、进主干前必须满足什么，而不是管他在自己分支上怎么写。
追问链
「代码没人看得懂」你怎么量化？总不能靠感觉定规矩
期望给可观测的代理指标并承认它们只是代理：单 PR 体积分布、评审时长与首次响应时长、无人实质评审直接合并的比例、重复代码率趋势、变更失败率、老代码被修改的比例（掉得快说明在绕开老代码另起炉灶）。看趋势不看绝对值，且与 AI 采用时间线对齐信号提得出「无人实质评审直接合并的比例」这类风险指标 → 比只报重复率这类质量指标高一档，前者是先行指标你会禁止 vibe coding 吗？
期望不禁，管出口：禁令执行成本极高且不可验证（你无法证明一段代码是不是 AI 写的），还会把高产出的人推到地下。替代是把要求挂在准入上 —— 什么能进主干、进主干要满足什么判据。再按场景分：原型、内部工具、一次性脚本放开；核心链路与涉钱涉权限的按代价不对称加闸信号答「禁止」→ 缺可执行性判断；答「完全不管」→ 缺责任意识；说出「管出口不管过程」→ 真带过人规矩加上去，评审会不会成为新瓶颈？
期望会，且是必然 —— 产能提升之后瓶颈一定搬家。三条对策：控入口（PR 体积上限，最便宜）、左移（能自动挡掉的不走人眼）、分流（按风险等级分强弱通道）。隐形失败模式：队列积压到一定程度通过率反而会升高，因为人开始盖章信号说得出「通过率在积压期是坏信号」→ 理解了指标会反转；只答「加评审人手」→ 没意识到评审是有限资源规矩怎么落地才不会变成一纸空文？
期望① 能自动执行的一定自动执行 —— 靠自觉的规矩半年后必然失效；② 每条规矩配一个负责人和一个观测指标 —— 没指标就无法判断有效，也就无法下线；③ 规矩要能下线 —— 只增不减，最后大家整体绕过。加分：先在一个小组试点、拿到数据再推全组信号说得出「规矩要能下线」→ 真维护过流程；只讲「宣讲 + 培训 + 考核」→ 纸面管理CTO 说这套规矩拖慢交付，砍掉一半，你保哪几条？
期望给排序判据而不是表态，按不可挽回程度排：① 保住不可逆风险的闸（涉钱、权限、数据删除、不可逆迁移必须留人工确认，期望损失不在一个量级）→ ② 保住自动执行、零人力成本的闸（PR 体积上限、扫描类检查，砍了纯亏）→ ③ 先砍消耗人力且覆盖面广的（「所有 PR 双人评审」改按风险分流）→ ④ 先砍无观测指标的。砍掉的要换成可观测兜底，不能裸奔信号答「一条都不能砍」→ 缺协作意识；答「都听老板的」→ 缺主张；能补一句「数据显示没挡住什么，那 CTO 是对的」→ 真在权衡
评分要点
- 先诊断病因（改动太大 / 意图没留下 / 结构退化），再开药
- 明确在防什么（许可 / 质量 / 可维护性），并知道三者的规矩不同
- 引用可维护性的趋势数据且带限定（时间序列相关，非逐提交归因）
- 落地按成本排序：先自动执行的，再改习惯的，最后动审批
- 意识到规矩会制造新瓶颈，并给出控入口 / 左移 / 分流三条对策
- 有风险先行指标（如无人实质评审直接合并的比例）
- 不禁止 vibe coding，而是管准入出口
- 面对砍流程的压力，能给出排序判据，并承认数据不支持时该砍