怎么考「你平时怎么用 AI 写代码？讲一个省了一天的例子和一个翻车的例子」
谁在问：一面开场必问（2026 已成普问）；面试官通常自己也在用，会立刻判断你是哪一代工作流
开场怎么问
你平时用 AI 写代码吗？怎么用的？说个具体的。
换个问法
- 讲一个 AI 帮你省了一天的例子，再讲一个把你坑了的例子。
- 你们组现在写代码大概多少比例是 AI 出的？你自己呢？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
你说「省了一天」，具体省在哪一步？
- 期望
- 能把「省时间」拆开——省的是打字、查资料、还是探索方向。真正大额的节省来自后两者；如果只省打字，说明任务本身就不难，值不了一天。好的回答会点出：这个任务之所以适合派给 AI，是因为工作量大但判据简单。
- 信号
- 说「它写得比我快」是打字层面，浅；说「省的是我读四十个文件搞清每处上下文的时间」是探索层面，深；说「省在我不用一边改一边记住哪些改过了」是状态管理层面，更深。
那次翻车，你后来怎么防止再犯？
- 期望
- 必须给出机制而不是态度。机制分三档：写进规则文件（最便宜）、加一条可判定的完成判据（中）、在 CI 里加自动检查（最贵也最可靠）。能说出「我先上最便宜的那道，因为一天就能上」的人，有真实的落地经验。
- 信号
- 答「以后我会更仔细 review」是零分——这句话在事故复盘里等于没说。答「我们要求所有 AI 代码必须双人评审」是过度反应，会立刻被追问「那你们评审队列现在多长」。
什么任务你现在坚决不给 AI？
- 期望
- 能给出判据而不是清单。好的判据有三类：出错代价不对称（钱、权限、数据删除）、验收标准写不出来（主观质量、性能调优的取舍）、上下文在系统外（依赖只有你知道的历史约定和线上现状）。
- 信号
- 答「核心业务逻辑不给」太笼统，会被追问「什么算核心」；答「我全都给，只是 review 更严」也可以，但必须能说清 review 严在哪、是谁在判。
你同事说用了 AI 效率翻倍，你怎么验证这个说法？
- 期望
- 这一问在考数据素养。要点有三：① 自评不可靠——有一项针对资深开源开发者的随机实验发现，参与者事前预期加速 24%、事后自评加速 20%，实测却慢了 19%；② 但也不能拿这个数字当结论——该团队 2026 年 2 月自己公布了后续，样本扩到 57 人、800 多个任务，估计值收窄到 −18% 和 −4%，并主动承认存在严重选择偏差（三到五成的参与者刻意扣留了他们认为 AI 能大幅加速的任务），因此这些数只是「不可靠的下界」；③ 要验证只能用交付侧指标——需求交付周期、变更失败率、返工率，而不是代码行数或提交数。
- 信号
- 只会背「有研究说用 AI 反而慢 19%」的是只读过标题；能补上「这项研究已经被作者自己修正过、而且方向是低估」的是真读过原文。反过来，答「看代码行数」「看提交数」的直接暴露没做过度量——这两个指标在 AI 时代已经废了。
明年 AI 编程的预算砍一半，你先砍什么？
- 期望
这不是考省钱技巧，是考你知不知道钱花在哪。可用的思路：
- 先算清结构再动刀。典型的企业部署量级是每人每活跃日十几美元、每月一两百美元，且分布极不均匀——通常九成的人日均消费很低，少数重度用法吃掉大头。所以第一刀是找出那少数用法，而不是全员降配。
- 最贵的往往是并行。多 agent 队伍的 token 消耗大致是单会话的 7 倍；并行 worktree 之间不共享提示缓存，并行省的是人的时间，花的是钱。这两项是最容易被砍且几乎不影响主流程的。
- 别先砍档位。把推理档位一刀降到底，会同时降低一次做对的概率，返工的成本会以更贵的方式回来。要砍档位，也应该按任务类型分档，而不是全局降。
- 最后才砍人头许可。因为那是唯一一刀会直接减少产出的。
- 信号
- 上来就说「换个便宜模型」的，是没算过账；能说出「先看分布，钱大概率集中在少数人和并行会话上」的，是真管过预算。加分项：主动指出降本的顺序应该按「不影响正确性」到「影响正确性」排，和成本治理的一般顺序一致。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 讲了具体的成功例子（有场景、有规模、有时间对比），不是泛泛而谈
- 讲了翻车例子，并且归因到机制（上下文、验收标准、判定权），不是归因到「模型不行」
- 说得出翻车之后落地的纪律，且纪律有成本意识（先上便宜的那道）
- 区分了任务规模对应的两种工作流（小改直接对话 / 大改先计划再执行）
- 提到了写和判要分开（新会话 review、独立判据、CI 检查任一形式）
- 能给出「不给 AI 的任务」的判据而非清单
- 谈效率验证时用交付侧指标，不用代码行数/提交数
- 追问成本时先谈结构与分布，再谈单价
参考答案与考察意图面试中途别看这一段
考察意图
这道题看着是热身闲聊，实际是整场面试信息密度最高的一道。面试官在同时判断三件事：
- 你在哪一代工作流上。答「用它补全、写正则」的是 2023 年；答「贴一段让它改」的是 2024 年；答「派任务、给验收标准、异步收」的才是 2026 年。这一条不用问就能听出来。
- 你有没有被它坑过，坑完有没有归因。只讲成功例子的人，要么用得浅，要么在背宣传页。翻车例子归因到「模型不行」的人，明年还会翻一次同样的车。
- 你有没有把教训变成纪律。个人经验和团队资产的差别就在这一步——一个能说出「后来我们在 CI 里加了一条检查」的人，比说「以后我会更仔细」的人值钱得多。
顺带还有一层：这道题是后面所有第 7 章追问的挂载点。你答里提到什么，面试官就往什么方向压。
参考答案
60 分答案（及格线）
说清「用什么、在什么场景用、举了具体例子」，就到及格线：
我主要用它做三类事：一是写脚手架和样板代码，比如新建一个服务的目录结构、DTO、基础的增删改查；二是读陌生代码，接手别人模块时让它先给我讲一遍调用链；三是补测试，尤其是边界用例，它想得比我全。
省时间的例子：上个月要把一个老服务的日志从自研格式迁到结构化日志，涉及四十多个文件的机械替换，但每个文件的上下文不太一样，纯正则替换会出错。我让它按文件逐个改，我 review，两小时干完，手工至少一天。
翻车的例子：有一次让它改一个支付回调，它改了一个已经废弃的类，测试还全过了，上线才发现没生效。
为什么只有 60 分：三个例子都真实，但翻车例子没归因——它为什么会改错？你后来怎么防？停在「上线才发现」，就等于承认这事下次还会发生。
90 分答案（有生产经验的回答）
90 分和 60 分的差距不在例子更精彩，在三段结构 + 归因 + 落到纪律。
怎么用：我现在基本按任务大小分两种模式。小改动直接在编辑器里对话，改完自己看；超过一两个文件的，先让它探索加出计划，我确认计划再让它动手，改完开一个全新上下文的会话专门 review 这个 diff——写的和判的不能是同一个会话。
省了一天的例子：日志格式迁移，四十多个文件，机械但每处上下文不同。关键不是让它改得快，而是这个任务的验收标准是可判定的——迁完之后日志解析器能 100% 解析。我先写了这一条判据，让它改，跑判据，两轮就收敛了。两小时对一天。
翻车的例子：给支付回调加幂等。我把整个 payment 目录贴进去，十二万 token。它给了一份挑不出毛病的 diff，测试全过，上线不生效。归因下来是两件事叠在一起：第一，上下文里同时存在新旧两套 handler，长得几乎一样，没有任何一行代码写着哪个在跑，它挑了名字更正统的那个；第二，测试是它自己写的，测的也是它改的那个类，自然全过。
后来立的规矩：一是把「哪个实现在跑、哪个目录已废弃」这类推不出来的事实写进项目的规则文件，不再指望它每次从代码里重新推断；二是异步派活之前必须先写一句可判定的完成判据；三是 CI 里加了一条——本次 diff 如果动了测试基础设施（conftest、测试基类、mock 边界），强制人工确认。
我不给它的任务：涉及钱和权限边界的核心逻辑，我仍然自己写，让它 review 我。不是因为它写不出来，是因为这类代码出错的代价不对称。