怎么考「团队有人 vibe coding 上瘾、代码没人看得懂，你怎么立规矩？」
谁在问：三面 / 技术负责人 / 管理向；考的是你会不会用流程解决人的问题，以及知不知道流程的代价
开场怎么问
组里有人天天让 AI 一把梭，代码合进来没人看得懂，你怎么管？
换个问法
- 你们对 AI 写代码有什么规范吗？谁定的、怎么落地的？
- 如果让你现在给团队定一套 AI 编码规矩，你会写哪几条？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
「代码没人看得懂」你怎么量化？总不能靠感觉定规矩。
- 期望
- 给出可观测的代理指标，且承认它们都是代理。可用的有：单 PR 体积分布、评审时长与首次响应时长、无人实质评审直接合并的比例、重复代码率趋势、变更失败率、老代码被修改的比例（这项掉得快说明大家在绕开老代码另起炉灶）。关键是看趋势不看绝对值，并且和 AI 采用的时间线对齐。
- 信号
- 能提出「无人实质评审直接合并的比例」这类风险指标，比只报「重复率」这类质量指标高一档，因为前者是先行指标。
你会禁止 vibe coding 吗？
- 期望
- 不禁，但管出口。理由要说清：禁令的执行成本极高且不可验证（你无法证明一段代码是不是 AI 写的），而且会把高产出的人推到地下。可行的替代是把要求挂在准入上——什么能进主干、进主干要满足什么判据。同时区分场景：原型、内部工具、一次性脚本可以放开；核心链路、涉及钱和权限的地方按代价不对称程度加闸。
- 信号
- 答「禁止」的，缺可执行性判断；答「完全不管」的，缺责任意识；能说出「管出口不管过程」的，是真带过人。
规矩加上去，评审会不会成为新瓶颈？
- 期望
- 会，而且这是必然的——产能提升之后瓶颈一定搬家。对策三条：控入口（PR 体积上限，最便宜）、左移（能被自动化挡掉的不要走到人眼）、分流（按风险等级分强弱通道）。还要点出一个隐形失败模式：队列积压到一定程度，评审通过率反而会升高，因为人开始盖章——所以「通过率高」在积压期是坏信号不是好信号。
- 信号
- 能说出「通过率在积压期是坏信号」的，理解了指标会反转；只答「加评审人手」的，没意识到评审是有限资源。
规矩怎么落地才不会变成一纸空文？
- 期望
- 三条。① 能自动执行的一定自动执行——写在文档里靠自觉的规矩，半年后必然失效。② 每条规矩要有一个负责人和一个观测指标，没有指标的规矩无法判断是否有效，也就无法下线。③ 规矩要能下线——定期回看，失效的、和当前风险无关的要删掉；规矩只增不减，最后大家会整体绕过。加分：提到先在一个小组试点、拿到数据再推全组。
- 信号
- 能说出「规矩要能下线」的，是真维护过流程；只讲「宣讲 + 培训 + 考核」的，是纸面管理。
CTO 说这套规矩拖慢交付，砍掉一半，你保哪几条？
- 期望
这一问考取舍，必须给出排序判据而不是感情用事。可用的判据是**「按不可挽回程度排序」**：
- 保住不可逆风险的闸——涉及钱、权限、数据删除、不可逆迁移的路径必须留人工确认。理由是这类事故的期望损失和其他不在一个量级。
- 保住自动执行的、零人力成本的闸——PR 体积上限、测试基础设施变更提醒、扫描类检查。它们不消耗任何人的时间，砍掉它们纯亏。
- 先砍消耗人力且覆盖面广的——比如「所有 PR 双人评审」，改成按风险分流。
- 先砍无观测指标的——一条规矩如果说不出它挡住过什么，它就是第一候选。
- 给出交换条件：砍掉的部分要换成可观测的兜底（比如把强评审换成上线后的自动比对与快速回滚），而不是直接裸奔。
最后要补一句管理视角的诚实话：如果数据显示这套规矩确实没挡住什么，那 CTO 是对的，该砍。 能说出这句的人，比死守流程的人可信得多。
- 信号
- 答「一条都不能砍，质量是底线」的，缺协作意识；答「都听老板的」的，缺主张；能给出「按不可挽回程度 + 是否消耗人力 + 有无观测指标」三条判据的，是真在权衡而不是在表态。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 先诊断病因（改动太大 / 意图没留下 / 结构退化），再开药
- 明确在防什么（许可 / 质量 / 可维护性），并知道三者的规矩不同
- 引用可维护性的趋势数据且带限定（时间序列相关，非逐提交归因）
- 落地按成本排序：先自动执行的，再改习惯的，最后动审批
- 意识到规矩会制造新瓶颈，并给出控入口 / 左移 / 分流三条对策
- 有风险先行指标（如无人实质评审直接合并的比例）
- 不禁止 vibe coding，而是管准入出口
- 面对砍流程的压力，能给出排序判据，并承认数据不支持时该砍
参考答案与考察意图面试中途别看这一段
考察意图
这道题表面是管理题，实际考四件事：
- 你会不会先诊断再开药。「代码没人看得懂」是症状，不是病因。直接答「加 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。 禁掉的结果是转入地下，而且那个人的产出确实是真的。要管的是它的出口——什么能进主干、进主干前必须满足什么，而不是管他在自己分支上怎么写。