Claude Code 更新日志提到，在没有 CLAUDE.md 的项目中，它会改为读取 AGENTS.md，并可在 /config 的 Project instructions 下修改；该支持尚未在 Bedrock、Vertex 或 Foundry 上提供。同一份日志还提到插件、技能与企业市场策略等修复。消息本身只说明工具行为，不证明任何团队的规范水平。但它可以帮你把面试问题问得更具体。

面试时，把“用不用”换成“谁维护”

“你们用不用 AI 编码工具”这个问题，答案几乎总是用，区分度很低。更值得问的是：项目里有没有统一的指令文件？写不写进仓库？谁负责更新？多久看一次？

假设你面试两个团队（以下为模拟场景）。A 团队每个人自己写提示词、自己配工具，问起来只说“大家各用各的”。B 团队仓库里有一份指令文件，写明项目结构、测试命令、代码风格和禁止事项，并且有明确的人负责跟进。两种做法都能写代码，但 B 团队至少把约定放到了可以讨论、可以评审的位置。

要提醒的是，这只是观察点。有统一文件不等于代码质量一定好，没有也不等于团队差。你还需要结合代码评审是否认真、文档是否及时更新来判断。

多工具并存时，问清哪份文件说了算

工具多不是问题，约定是否集中才是问题。

素材只说明：没有 CLAUDE.md 时，Claude Code 读 AGENTS.md。它没有说明两者并存时其他工具会怎么读，所以别替工具补规则。但你可以把这个问题直接抛给面试官：“如果项目里同时存在多个指令文件，以哪份为准？谁来同步？”

读岗位描述时也要留意：写“熟悉 AI 编码工具”是常见要求，但很少写明团队有没有共享约定。这类信息岗位描述通常不会写，需要在面试中确认。如果对方答不上来谁维护，至少说明这件事目前没有归属。

选 offer 时，把这条和其他信号放在一起

你可以问：团队上一次更新项目指令文件是什么时候？工具升级后，谁检查约定是否还适用？新成员怎么知道当前有效的约定？

对方怎么回答，比答案本身更有信息量。但不要单凭这一点下结论，把它和代码评审频率、测试习惯、文档更新方式放在一起看。工具版本会变，约定也需要有人跟进，而这正好是你可以观察协作方式的一个切口。

一个实际可做的小建议：下次面试前，准备一个问题——“项目里有没有写进仓库的 AI 编码约定？谁负责让它和工具版本保持同步？”把对方的反应记下来，再和 offer 的其他信息一起权衡。