面试时，把问题落在纪律和知识上

Simon Willison 在博客中表示，随着与编码智能体协作时间增加，他越发确信这类工具让软件工程变得更难；它们能完成惊人的工作，但释放全部潜力需要极高的纪律性和知识储备。这是一条观点，不是行业调查结论。对求职者来说，它的用处是提醒你：面试时别只问“你们用不用编码智能体”，而要看这个团队怎么对待其中隐含的纪律和知识门槛。

同样一句“我们重度使用编码智能体”，在不同团队含义可能完全不同。一种是把它当成写代码的默认入口，但对生成结果的核对方式说不清楚；另一种是能说清谁对最终代码负责、哪些环节必须由人把关。区别不在工具本身，而在于团队是否把这种协作当成需要约束的工程活动。你可以顺着这个方向问，但要注意：以下都是判断思路，不是对具体团队的实际断言，对方的回答仍需你自己核实。

两类方向，关注点不一样

假设一个模拟场景：两个团队都宣称在用编码智能体。A 团队强调先理解模块边界和依赖关系，再决定让工具改哪里；B 团队则更强调尽快跑通功能，其他之后再说。这不是说哪种一定更好，而是两类方向对求职者的要求不同。A 这类方向可能更看重你对系统结构和调试的判断；B 这类方向可能更看重交付速度和任务切换。你要问自己更想在哪种节奏里积累经验。

读岗位描述时，有些信息还需要确认。比如“熟悉 AI 编程工具”是只要求会用，还是要求能判断生成结果的风险？团队有没有人负责在工具给出看似合理但实际错误的方案时把它拦下来？这些问题没有标准答案，但回答的具体程度能帮你看清团队对知识储备的真实要求。Willison 所说的“更难”，落到个人身上更像是一种提醒：工具越顺手，越需要你自己知道哪里可能出错。

判断加分还是负担，先看自己的底线

选团队时，可以先把“我能不能接受这样的协作方式”想清楚，再去比对。如果你更在意每一步变更都有明确责任人，那就要在面试里确认这件事；如果你更在意快速试错、愿意自己补上判断，那关注点又会不同。这不是给团队打分，而是帮你缩小选择范围。

一个实际可做的小建议：面完一家后，用两三句话写下对方对“谁对生成代码负责”的回答，再对照自己的底线。写不出来的地方，往往就是入职前还需要追问的地方。