面试怎么问出团队的代码规范是写在文档里还是靠口口相传

消息提到，架构师 Brij Kishore Pandey 提出一套避免 Agent 上下文膨胀的标准：根目录只放极简骨架，业务上下文下沉到子目录，工作流封装进可复用技能。这套思路本身是给 AI 协作工具用的，但它对求职者有一个直接启发：一个团队怎么组织上下文，往往就暴露了它的协作成本。

面试时你可以这样问：“新同学入职第一周，怎么知道某个模块的约定和边界？”如果对方回答“问老员工”或者“看那个大文档”，你要留意。更值得听的回答是分层的：根目录只写目标、文件地图和死规则，具体模块的约定放在对应目录里，谁进这个模块才读这份手册。

两种做法的差别不在文档多少，而在查找成本。堆在一个文件里，新人要读完才知道哪条和自己有关；按模块下沉，你改支付逻辑时只需要读支付目录下的约定。面试时可以直接追问：“如果我接手一个半年没人动的模块，从哪里开始读？”对方能不能说清路径，比说“我们文档很全”更有信息量。

怎么判断目标团队的工程规范是刚性约束还是靠自觉

素材里还提到，关键改动前应由自动化检查强制触发，而不是靠模型自觉。这个区分放到团队里同样成立：规范是写在流程里，还是靠代码审查时人工提醒？

可以问：“提交代码时有没有自动检查会拦住不合规的改动？”如果对方说“主要靠 review 时大家提”，说明规范落地程度有限，你入职后可能要反复处理同类问题。如果对方能说出具体在哪个环节、什么条件下会阻断合并，那至少说明团队把一部分约束交给了工具。

这里要避免一个误判：有自动化检查不等于团队没有技术债，也不等于你进去就不用擦屁股。它只说明团队在“防止问题重复发生”上有投入。你还可以追问：“最近一次因为规范问题回滚或返工是什么情况？”对方愿不愿意讲具体例子，比讲原则更能反映真实状态。

入职后维护他人代码时，怎么快速找到需要的上下文

面试是双向的，你问的问题也在告诉对方你关心什么。与其问“团队氛围好不好”，不如问三个可验证的点：模块文档放在哪、谁负责更新、多久没更新。

一个模拟场景：假设你拿到一个负责订单状态流转的模块，你可以问面试官：“这个模块的边界和禁止事项写在哪里？如果我需要改状态机，先看哪份材料？”如果对方能立刻说出位置和负责人，说明团队至少想过这个问题；如果对方说“这个要问某某”，那你要把“某某是否还在职、是否带人”纳入判断。

素材里的做法是让模型钻进哪个模块才读哪份手册，保持上下文最小化。对应到人，就是别指望一份万能文档解决所有问题。你可以接受文档不完美，但要确认团队有没有“按模块找上下文”的习惯。

最后给一个实际可做的小建议：面试结束前，挑一个你未来可能负责的模块，请对方描述“从接到需求到合并代码”的完整路径。听对方讲的过程中，注意他有没有提到文档位置、检查环节和责任人。这条路径说不清楚，比任何文化话术都更值得你谨慎。

以上判断标准是给读者的分析，不是对任何团队实际做法的断言；具体规范水平仍需你在面试中逐项核实。