面试问AI代码治理，先问评审和责任

消息提到，一个轻监督的软件工厂曾膨胀到 3 万至 4 万行，带有运行四个 Unix 进程的“极其复杂的状态机”，最终整个代码库被归档。归档的具体原因、时间与责任归属无法确认，其他团队是否出现类似情况也不得而知。但对求职者来说，这个场景值得当成参考：如果团队大量使用AI生成代码，却没人说得清谁评审、谁负责、复杂度怎么控制，你入职后可能被维护成本拖住。

面试时只问“你们用不用AI写代码”，得到的往往是笼统的肯定回答。要问的是流程：AI生成的代码进仓库前，谁看、看什么、什么情况下必须打回？可以这样问：“最近一次AI生成的代码被评审拦下来，是因为什么问题？”如果对方答不出具体例子，或者只说“我们相信工具”，这就是一个需要留意的信号。

哪些信号说明你可能被维护成本拖住

素材里“极其复杂的状态机”和“代码库被归档”两个细节，指向复杂度累积与维护风险。面试中可以追问三个方向。

第一，所有权。问“这段AI生成的代码上线后，出问题谁负责修？”如果答案是“谁生成谁负责”但没人能说清生成记录，或者干脆没有明确所有者，说明责任边界模糊。

第二，测试与复杂度。问“你们怎么控制AI生成代码带来的复杂度？有没有规模上限或重构节点？”注意听对方是否提到测试覆盖、模块边界、定期清理。如果只谈生成速度，不谈清理机制，长期维护压力可能落在后来者身上。

第三，归档与回退。问“如果某个AI辅助模块变得难以维护，你们会怎么处理？”素材中的代码库最终被归档，说明“推倒重来”是一种可能结局。你可以借此判断团队有没有预案，而不是等到问题堆积才被动应对。

把AI代码治理写进你的选团队标准

把AI代码治理列为和薪资、技术栈同级的评估项，而不是入职后才发现的隐藏成本。面试末尾可以要求一个具体例子：“能不能讲一个你们用AI生成代码后，发现需要返工或重构的案例？”对方愿意讲细节，说明有反思机制；只讲成功故事、回避失败案例，则要谨慎。

一个实际可做的小建议：面试前写下三个必问问题——谁评审、谁负责、复杂度怎么控制——面试后立刻记录对方的回答和你的感受。如果三个问题都得不到具体答案，就把这个团队在治理意识一栏标为待确认，而不是默认没问题。

本文中的面试提问为模拟示例，用于展示判断思路，不代表任何团队的实际做法。