最近，我参加了Minimax AI应用开发岗位的面试。本以为会是一场围绕Transformer、RLHF或RAG技术的标准问答，没想到，面试官直接忽略了大模型原理，聚焦于我简历上“AI辅助开发平台”的项目经历，进行了一场持续一个半小时的“项目深潜”。
如果说普通面试是考察你会不会使用工具，那么这场面试的核心则是：“你如何确保这个工具造出的东西结构稳固、逻辑正确，并且在规模化使用时不失控？”
我将面试中印象最深刻的18个问题与我的思考整理成文。如果你也在从事AI Agent、Copilot或任何与“AI写代码”相关的工作，希望这篇复盘能为你提供一些避坑参考。
第一回合：项目深水区——从“能用”到“好用”的鸿沟
面试官显然对“套壳API”这类表面工作不感兴趣，一开场便直指我们平台的核心工程机制。
1. 从PRD到design.md，如何保证“需求不丢失”？
这是实现AI编程助手的首要难题。产品需求文档（PRD）充满自然语言的模糊性，而技术设计文档（design.md）要求严谨。直接让AI翻译，细节丢失是必然的。
我们的解决方案是 “双向验证”。不仅让AI将PRD转化为设计文档，还要求它基于产出的设计文档，反向生成一份“用户验收用例”。接着，用这份用例与原始PRD进行比对，查找差异。
真正的难点在于误判。 初期，AI常将“文案优化”这类边缘需求误判为“核心逻辑缺失”，或将真正的异常流程遗漏视作“无关紧要”。后来我们引入了一个小技巧：要求AI在判断时自问“如果忽略这一点，核心功能是否还能运行？” 以此作为筛选阈值，显著降低了误判率。
2. “需求-代码映射”如何实现精确定位？
这是一个极其“工程化”的问题。面试官想听的并非概念，而是落地的具体细节。
我举了一个例子：假设PRD要求“修改登录页面的密码框提示文案”。传统的AI或许只会修改前端UI代码。但在我们的体系中，通过构建一条 静态分析链路，我们将需求点拆解为“UI层-文案资源文件-逻辑引用关系”的三元组。
当AI执行修改时，它不仅是改代码，还会追溯这个文案是否在单元测试中被硬编码引用、相关的API文档是否需要同步更新。我们追求的“映射”，本质上是建立了一套“需求变动影响范围”的动态图谱。
3. tasks.md的拆分粒度：太细和太粗的代价
这是一个非常考验“经验”的问题。
- 拆得太粗：AI容易“自由发挥”，生成大量计划外的代码，导致代码库膨胀，Review困难。
- 拆得太细：任务间的上下文被割裂。AI在执行第50个任务时，可能已完全忘记第1个任务中定义的基类结构，导致代码风格不一致甚至逻辑冲突。
我们现在的原则是：以“独立功能点”为单位进行拆分，确保每个任务执行完毕后，产出代码是可编译、可运行的。 这样既控制了单次处理的上下文长度，又保证了开发过程的连续性。
4. Multi-Agent协作中的状态如何传递？
面试官问得很细：“是靠文件、内存，还是中心化状态管理？”
我们经历过“文件传递”的噩梦（IO瓶颈，易产生脏数据），也试过“内存传递”（服务重启则状态全失）。最终采用的是 “中心化状态机 + 局部上下文快照” 的模式。
使用一个全局的Redis存储项目的整体状态（如设计选型、已完成模块）。但当Agent之间需要协作时，仅传递“与当前任务强相关”的局部状态快照。这类似于微服务架构中的“最终一致性”，既避免了全局锁的性能瓶颈，又防止了单个Agent信息过载。
5. 遇到“决策冲突”时怎么办？
最典型的是“设计Agent”与“代码生成Agent”之间的冲突。设计Agent主张使用“工厂模式”，而代码生成Agent认为“简单if-else即可满足”。
我们引入了一个 “仲裁Agent” ，但它的裁决依据并非简单投票，而是回归到技术方案的“约束条件”本身。我们要求设计Agent在输出方案时，必须附上“违背此设计可能导致的问题”（如扩展性差、单测难写）。当代码Agent提出异议时，仲裁Agent仅判断：“当前业务复杂度是否已触及设计Agent提出的约束红线？” 若未触及，则采纳代码Agent的更简方案；若已触及，则必须按设计进行重构。
第二回合：知识库与RAG——是“外挂”还是“外债”？
面试官对知识库设计的追问，堪称整场面试的高潮。
6. 你们的知识库（.catpaw/rules）和OpenClaw的RAG Memory有何本质区别？
这是一个很好的对比。像OpenClaw这类典型的RAG，核心是“检索-生成”，解决的是“模型知道什么”的问题。而我们的rules库，解决的是 “开发过程必须遵守什么” 的问题。
RAG是一种“软约束”，检索到了相关信息则用，检索不到就可能忽略。但我们的 rules 是 硬约束。例如“禁止在Controller层直接操作数据库”这条规则，它会在代码生成前被注入到System Prompt中，并在生成后的检查阶段，接受正则表达式与抽象语法树（AST）的双重校验。若不一致，AI生成的代码将无法提交。
7. 知识库内容过多，导致上下文压力剧增，如何解决？
我们 绝不进行全量注入。我们维护了一个“规则索引”，将规则分为三类：全局红线（如安全规范，永远携带）、模块规范（进入特定模块时注入）、以及冲突规则（根据AI识别到的开发意图动态激活）。
例如，仅当AI识别到用户意图为“编写SQL查询”时，才会动态加载“SQL注入防护规范”和“索引使用规范”。这本质上是一种 语义化路由，而非简单的向量相似度检索。
8. 知识库里的内容如果错误或过时，如何进行治理？
这个问题问到了知识库系统的“死穴”。我们的经验是：绝不让AI或开发人员手动维护这个知识库。
我们设计了一套 “规则保鲜”机制：每当AI生成的代码被开发者“驳回”（拒绝合并）时，会触发一个分析Agent，它会剖析驳回原因。如果是因为代码违反了某条现有规则，则无事发生；如果是因为违反了一条“本应存在但知识库遗漏”的规则，则触发“规则提案”；如果是因为某条现有规则本身已过时，导致对合规代码的误判，则触发“规则淘汰”流程。知识库不是写出来的，是在使用中“生长”出来的。
9. 在一个拥有几十万行代码的存量项目中，如何让AI快速理解项目结构？
这个问题没有银弹。我们放弃了让AI“通读并理解整个项目”的不切实际幻想。
我们采取 “按需构建抽象语法树（AST）” 的策略。AI无需知晓项目全貌，它只需要知道：“我要修改的这个函数，被谁调用？它又调用了谁？它引用了哪个实体类？”
通过生成 调用关系图谱，我们只向AI展示一个“以代码改动点为中心、依赖关系向外延伸3跳”的局部子图。这让AI既能理解必要的上下文，又不会因信息过载而产生“幻觉”。
第三回合：质量与信任——50%的代码留用率背后
10. AI生成代码的留用率号称有50%以上，那么剩下的50%问题出在哪里？
面试官问得非常直接，不给我任何修饰数据的空间。
坦诚地说，那未被采纳的50%代码里，约30%是“边界条件遗漏”，AI只编写了主流程（Happy Path）代码，对网络超时、并发冲突等异常处理考虑不足；另外约20%是“技术债积累”，AI倾向于在现有代码上“打补丁”，而非进行必要的重构，导致代码越来越臃肿。
11. AI是否生成过“语法正确但逻辑错误”的代码？
太多了。典型例子是“API误用”和“业务逻辑颠倒”。AI生成的代码语法完美，能通过编译，但业务逻辑是反的。比如在优惠券计算中，将“满100减10”错误实现为“满10减100”。
针对此问题，我们强制要求AI在生成代码后，必须同时输出 “核心逻辑的断言用例”（无需可执行，但需用代码描述）。有趣的是，有时AI在编写这些断言的过程中，自己就能发现逻辑矛盾。让AI进行自我纠错，有时比人类Review更高效。
12. 你们是否做了代码diff级别的精细控制？
是的，这是确保工程安全感的基石。我们严格限制了AI 单次代码修改不能跨越超过3个逻辑模块，并且禁止AI删除任何未被明确标记为“已废弃”的代码。
AI可以新增代码，可以修改代码，但 所有删除操作都必须经过人类二次确认。这虽然牺牲了一部分自动化效率，但在生产环境中，这是一条必须坚守的底线。
13. 基于Playwright的自动化测试，如何保证其有效性而非仅仅追求覆盖率？
我们并不盲目追求“代码行覆盖率”，因为这很容易被大量无意义的测试用例刷高。
我们关注的是 “核心业务场景覆盖率”。在design.md阶段，AI就必须规划出至少3个核心场景（主流程、关键异常流、边界流程）的端到端（E2E）测试路径。如果AI生成的代码破坏了这些预设场景的Playwright测试脚本，持续集成流水线会直接中止，阻止合并。
14. AI自动修复Bug的成功率如何？是否存在“修复一个Bug，引入三个新Bug”的副作用？
坦白说，成功率不高，大约在30%左右。并且，“修复A，破坏B”的情况确实发生过。
根本原因在于，AI在修复Bug时，往往只盯着局部的“症状”，而非全局的“病因”。后来我们调整了策略：不让AI直接修改代码，而是要求它先输出一份“根因分析报告”和对应的“修复方案”，由人类开发者确认方案合理后，再授权AI执行代码变更。 虽然流程多了一步，但有效避免了灾难性的连锁反应。
写在最后：面试官的潜台词
面试结束后，我最深刻的感受是：像Minimax这样深度投入AI应用的公司，早已不关心你“接入了哪个大模型”，而是关心你“如何构建工程体系来驾驭大模型”。
他们提出的每一个问题，都在验证同一件事：当AI生成代码的比例从10%提升到50%乃至80%时，你现有的开发流程、质量保障和风险管控体系，能否稳稳地兜住底？
- 拷问状态传递，是在审视你的系统耦合度与健壮性。
- 深挖知识库治理，是在考察你的数据飞轮能否形成闭环并持续优化。
- 追问代码留用率，是在探查你对技术风险是否有清醒、量化的认知。
如果你也在探索AI编程或Agent应用，希望这份源自真实面试的复盘能带来一些启发。大模型竞赛的上半场是“参数规模与算法突破”，下半场将是“复杂场景下的工程化落地”。 谁能系统性地解决这些看似“细枝末节”的工程问题，谁才能真正将AI从实验室的“演示玩具”转化为生产级的“可靠工具”。
本文首发于 云栈社区，一个专注于技术实战与深度思考的开发者社区。
发表于 1 小时前
|
查看: 2|
回复: 0
