自测卡 1 · Vibe Coding 方法论 · 30 道灵魂拷问

他们会这样考你

Vibe Coding 方法论 · 30 道灵魂拷问

用 AI 写代码这件事，最不缺的就是质疑。这 30 个问题来自三个真实场景：面试官在验证深度，老板在追问责任，技术同事在试探边界。先自己开口回答，再看框架。

一句话速览

每题附考察意图、答题框架与加分点：为什么立规矩 / 质量责任 / 代码合入把关 / 拒绝分期 / 决策沉淀 / 安全闸门

怎么用这一页

每道题都标注了提问者。他们盯着同一套 AI 协作规范，想听的东西却不一样。

🎙 面试官 想验证你是真用过，还是只看过几篇公众号

👔 老板 担心的是质量、责任和事故

🛠 技术同事 在试探你懂不懂工程，值不值得放权

每题给出三层： 对方在考察什么 → 答题框架 → 加分点 。答不上来的环节，点末尾的课程页回去补。

Q1 面试官

「你简历上写熟悉 Vibe Coding。都让 AI 写代码了，你还立一堆规矩，图什么？」

🎯 对方在考察什么

开场定调题。考的是你能不能 用事故说话 。只会说「规范很重要」的人在背套话；真踩过坑的人，张口就是具体事故和对应的规则。答「AI 偶尔会出错所以要小心」这种正确的废话，基本就露馅了。

🧭 答题框架

先说清 Vibe Coding 是什么： 靠自然语言让 AI 直接产出代码的开发方式。它的问题从来出在质量，写得快只是放大了搞砸的速度。

甩出四类典型事故： 理解偏差返工（改了 7 个文件才发现思路错了）、选型漂移（今天 Express 明天 Fastify）、善意破坏（重构时清理掉有用的代码）、永久技术债（简版登录再也没升级过）。

点破共同根源： 四类事故根源是同一件事，约束没有进入上下文。AI 每轮对话都可能忘掉你交代过的事。

给出解法： 把约束写进 Rule 文件，每轮对话开始前自动加载。对话里交代会被截断挤出窗口，写在文档里 AI 未必去读，只有 Rule 是结构上最稳的注入渠道。

⭐ 加分点 补一句方法论的生成逻辑：AI 每反复犯一次错，就把它变成一条规则。规则的价值在于每条都解决一个真实问题，堆砌条款没有意义。这句话能证明你理解的是方法，可以直接背下来。

用这些课程页组织答案 →

为什么要给 AI 立规矩

规则的价值：每条解决一个真实问题

Q2 老板

「都用 AI 写代码了，出了 bug 算谁的？AI 的锅还是你的锅？你敢对质量负责吗？」

🎯 对方在考察什么

老板要的是 责任归属和质量机制 。答「AI 生成的我们都会检查」等于什么机制都没有；把锅甩给 AI 更不行，那等于承认这套流程不可控。老板想听到的是：责任在人，而且有具体的关卡保证人负得起这个责。

🧭 答题框架

先接住责任： bug 永远算人的，AI 是工具。这套规范的目的就是让人在每个关键节点都有拍板的机会，出了问题能追溯到具体哪一关放过去的。

给事前关卡： 断点设在动手之前。AI 写代码前必须复述需求、产出 PRD、拿到明确许可；改超过 3 个文件先交修改计划。理解偏差在写第一行代码之前就被拦下。

给交付底线： 两道硬性检查。涉及 AI 接口的功能必须真实调用过，禁止 Mock 绕过；核心逻辑单元测试不过，不得交付。

给出事后的修法： 真出了 bug，禁止猜测性修复。先加 Log 定位根因，修复前回答三个问题（完整业务流程、影响哪些模块、有没有同类问题），修完声明影响范围，明确该回归测试哪里。

⭐ 加分点 主动报数据对比：猜测性修复三轮改 47 行 bug 还在，先 Log 一轮定位根因就修干净。加 Log 的 2 分钟，买断的是猜错三轮的返工。老板听得懂这笔账。

用这些课程页组织答案 →

调试铁律：先 Log 再改码

四步流程：复述、PRD、确认、编码

为什么要给 AI 立规矩

Q3 技术同事

「AI 生成的代码你们 PM 也敢直接合？一次改十几个文件，谁看得过来？」

🎯 对方在考察什么

技术同事在试探你 有没有流程意识 。他真正怕的是失控的大范围改动。答「AI 现在很强的，基本不会错」，他从此不会再放心让你碰仓库；答出具体的断点机制，他会开始把你当同行。

🧭 答题框架

先纠正前提： 不存在直接合。AI 动手前要走四步流程：先思考提问、用自己的理解复述需求、写出 PRD、拿到明确许可才开始编码。人不点批准，代码不会产生。

正面回应大改动： 修改超过 3 个文件必须先交修改计划，写清三件事：改哪些文件、每个文件改什么、改动之间的依赖关系。审的是计划，量再大也看得过来。

补上防扩散的细则： 新增功能前先搜索项目里有没有类似实现，防止重复造轮子；新组件先在 PlayGround 做独立 demo，调好了再集成进主工程。

说清为什么规则要写死： 「请先确认理解后再编码」这种模糊表述没用，AI 会自己判断「我理解了」然后直接动手。写明「写 PRD、等待许可」这类具体动作，断点才真的存在。

⭐ 加分点 说出阈值的工程判断：3 个文件是经验值，谨慎的项目调成 1，快速原型放宽到 5。简单的一行改动 AI 自行判断跳过 PRD，规矩拦的是返工成本最高的多文件变更。懂得阈值可调，说明你真在项目里用过。

用这些课程页组织答案 →

四步流程：复述、PRD、确认、编码

PlayGround：组件的试衣间

Q4 老板

「AI 说先上个简版，两天就能看到东西，我觉得挺务实的。你为什么非要拦着？」

🎯 对方在考察什么

老板站在了 AI 那边，你要 说服的是人 。这题考你能不能把技术债翻译成老板听得懂的成本账。顺着说「好的那就先上简版」，你就成了技术债的共犯；只会说「有技术债」又太空，老板要的是数字。

🧭 答题框架

先戳穿动机： AI 提「先做简版」往往与复杂度无关，它想快速给你一个能跑的东西换正反馈。「先用临时方案」「暂时 Mock」「简单处理一下」背后是同一个模式。

给成本账： 简版上线当天补全只要 0.5 倍成本；第 30 天，4 个模块依赖了简版接口，补全成本升到 3 倍；第 90 天，9 个模块耦合长死，8 倍成本超过重写。「后续再优化」的后续永远不会来。

给规则： 禁止以任何理由简化实现，也禁止 AI 主动规划分期和 MVP。每次实现都必须是完整、正确、没有代码债的方案。

把选择权还给老板： 功能确实太复杂时，正确动作是让 AI 给出完整方案、真实工作量和前置决策清单，由人决定要不要拆、怎么拆。拆分是人的决策，降级是 AI 的自作主张。

⭐ 加分点 点破一个反直觉的现象：打破「先做简版」的模式后，AI 反而会更认真地分析完整方案。这条观察来自真实使用，能说出来就赢了大多数人。

用这些课程页组织答案 →

不接受分期交付

四步流程：复述、PRD、确认、编码

Q5 技术同事

「上个月那个功能为什么改成现在这样，你还说得清吗？AI 对话一关，决策不就全丢了？」

🎯 对方在考察什么

这是对 Vibe Coding 可维护性的致命一问 。对话式开发的决策默认锁死在聊天记录里，三个月后翻遍 git log 也找不回来。答「我翻一下历史对话」等于承认没有沉淀机制；能答出文档体系，才算真把 AI 协作当工程在做。

🧭 答题框架

承认问题、给出机制： 决策确实不能靠对话留存，所以让 AI 按严格模板维护文档，决策跨越对话和时间存活。

报出三份文档的分工： FEATURES 回答「这个功能怎么来的」，带状态流转和历史沿革，方案变更及原因都记档；CHANGELOG 回答「这次改了什么」，记根因和影响面；RELEASE_NOTES 回答「用户得到了什么」。

再加一份沉淀品味的： METHODOLOGY.md 记产品原则、设计决策、体验偏好和反模式。用户否决过弹窗方案，AI 记进反模式，之后新对话自动继承，同一个方案不会被提第二次。

说清为什么放仓库里： 决策写在 Notion 或飞书里 AI 读不到。放在项目仓库内的 Markdown 文件，才能让 AI 每次自动获取上下文。

⭐ 加分点 补两条容易被忽略的细则：写 CHANGELOG 前必须读系统时间，禁止凭记忆填时间戳、禁止积压补写；代码注释要求三要素（背景、设计意图、关键约束），注释也是给下一轮对话的 AI 看的。

用这些课程页组织答案 →

三份文档与方法论沉淀

注释三要素与代码保护

Q6 老板

「我刷到过 AI 删库的新闻。咱们这样搞，万一哪天 AI 把生产数据库干掉了怎么办？」

🎯 对方在考察什么

老板在要 安全感 。答「AI 不会乱来的」是最差答案，因为 AI 确实会：善意的清理、混进发版的临时改动，都是真实发生过的事故。正确姿势是承认风险存在，然后把闸门一道一道摆出来。

🧭 答题框架

先给总原则： 不可逆操作的安全感来自闸门。数据库、配置、部署这类操作，闸全部设在执行之前。

报出三道闸： 第一道备份，未备份不得执行任何 migrate、drop、alter、delete，备份带时间戳放 backups/ 目录，成本是一行命令，赌的是整库数据；第二道回退，动手前说清如何恢复、需要哪些备份、预计恢复耗时；第三道审查，发版前让 SubAgent 比对实际 diff 和 Release Notes，混进无关改动就暂停发版。

补上发布纪律： 发布必须走 GitHub，服务器通过 git pull 或 CI/CD 拉代码。用户明确确认之前，打 tag、push、部署全部禁止，AI 没有自行发版的权限。

顺带把凭据也管住： 所有 Key 走环境变量或 secrets，禁止硬编码。Key 一旦进入 git 历史等于永久泄露，只能作废重发。

⭐ 加分点 说清 diff 审查的设计意图：正规团队靠 CI/CD 加 PR review 拦带病发版，独立开发者往往跳过 review 直接 push，让 SubAgent 充当 reviewer 就是补上这一环。能讲出这层，说明你理解规则背后的工程直觉。

用这些课程页组织答案 →

破坏性操作的三道闸

把环境事实写进 Rule

Q7 面试官

「你说把规矩写进 Rule 文件。这文件到底长什么样？我明天新开一个项目，第一步该干什么？」

🎯 对方在考察什么

考的是 你有没有真的动手配置过 。只会讲理念、说不出文件结构和目录位置的人，基本是看文章学的。能报出 frontmatter 字段和三个文件的分工，才算真落过地。

🧭 答题框架

先说文件结构： Rule 文件带 frontmatter， alwaysApply: true 用于全局编码规范，所有对话自动生效；设 false 的用于写作规范这类按需引用的文件，避免污染编码对话的上下文。

报出三个文件： xs_vibe_rules 一共三份。rule-opensource.mdc 是主开发规范，14 个章节覆盖全流程；writing-style.mdc 管中文写作风格，按需手动引用；secrets.mdc 是 API Key 与凭据模板，占位符形式。

给落地三步： 把 .mdc 文件放进项目的 .cursor/rules/ 目录，Cursor 自动识别；配置每个文件的 alwaysApply；把模型配置、技术栈、端口规则换成自己的选型。

把安全交代掉： secrets 文件填占位符并排除出 git。Key 一旦进入 git 历史等于永久泄露，只能作废重发。

⭐ 加分点 补一句起手式：这套仓库是 MIT License 开源的，正确姿势是 Fork 一份、按自己技术栈删改，改出来的就是你的第一版 AI 协作规范，起点比从零写高得多。

用这些课程页组织答案 →

为什么要给 AI 立规矩

规则的价值：每条解决一个真实问题

Q8 技术同事

「你们聊天框的 bug 我看了：中文输入法一按回车，半截拼音直接发出去了。AI 写的吧？怎么保证它下次不再犯？」

🎯 对方在考察什么

考你对 AI 盲区的认知深度 。能说出 isComposing 这个具体 API、并解释为什么 AI 必踩这个坑的人，是真的在一线修过 AI 写的前端。只会说「让 AI 改一下」的人，下个项目还会踩。

🧭 答题框架

先给根因： 中文输入法确认候选词时也会触发 Enter。代码只判断了 e.key === 'Enter' ，没检查 isComposing，选词的回车就被当成了发送。

给标准写法： Enter、非 Shift、 !e.nativeEvent.isComposing 三个条件同时满足才发送。isComposing 为 true 表示输入法正在组合中，这时回车只确认候选词，不触发发送。

解释 AI 为什么会犯： AI 训练数据里 isComposing 覆盖率不高，不写进 Rule 就一定会忘。规则原文写得很死：禁止只判断 e.key === 'Enter' 而不检查 isComposing。

上升到修法： 这个 bug 本身也是「先 Log 再改码」的教科书案例。加一行 Log 打印 e.key 和 isComposing，一轮定位根因，4 行修干净；瞎猜的路线三轮改了 47 行还没修好。

⭐ 加分点 顺嘴提一句 !e.shiftKey ：标准写法把 Shift 加回车留给换行，这种细节 AI 也常漏。能背出完整判断条件的人，一听就是修过这个坑的。

用这些课程页组织答案 →

把环境事实写进 Rule

调试铁律：先 Log 再改码

Q9 面试官

「你说组件都先在 PlayGround 里调好再集成。前端圈有现成的 Storybook，你们为什么不用？」

🎯 对方在考察什么

考 工程判断力 ：你知不知道行业标准方案，以及为什么在自己的场景下选了更轻的做法。答「没听过 Storybook」暴露视野窄，答「Storybook 更专业所以该用」暴露不会算成本。

🧭 答题框架

先认思路同源： PlayGround 就是简化版 Storybook 思路，每个 UI 元素有单独的 demo，调好了再集成进正式页面。

差别在成本： Storybook 是行业标准，但配置太重，对 AI 辅助的快速原型项目属于 overkill。PlayGround 用一个静态页面把所有组件 demo 排在一起，成本几乎为零。

说清换来了什么： 双向隔离。改组件不影响业务逻辑，调业务逻辑不搞乱组件样式。直接写进页面的话，调一个按钮要先把整个页面跑起来，登录、拉数据、切状态才能看它一眼，圆角改大了还可能挤歪旁边的布局。

给触发条件： 规则写明，涉及页面动效时必须先创建静态页面 PlayGround，自由调整测试之后，才允许写进正式页面。

⭐ 加分点 补一个交付细节：demo 里调好的参数可以直接抄进正式组件，集成时它已经是成品。试衣间里改好了再上台，返工就发生不了。

用这些课程页组织答案 →

PlayGround：组件的试衣间

Q10 老板

「上次演示看着挺好，一上线全是问题。后来才知道 AI 接口根本没通，页面上全是假数据。这种事你怎么杜绝？」

🎯 对方在考察什么

老板被假演示坑过，要的是 交付线上的硬性机制 。答「以后我会仔细检查」等于承认没有机制，下次还会发生。要给出流程里写死的关卡。

🧭 答题框架

给出禁令： 凡涉及 AI 模型调用的功能，交付前必须确认接口真的能访问，禁止硬编码假响应或本地模拟绕过真实调用。

卡住源头： 用户没给 API Key 时，AI 必须停下来要，不许自己 Mock 着继续写。Key 到位后先发一次测试请求验证可用性，再继续开发。「接口没通」这个最大风险被提前到了开发第一步暴露。

配上第二道线： 核心业务逻辑单元测试不过，不得交付。两道硬性检查一起构成交付线。

点破动机： 「暂时 Mock」和「先用临时方案」「简单处理一下」是同一个模式，AI 想快速给你一个能跑的东西换正反馈。这些话术在规则里被同一条款点名禁止。

⭐ 加分点 把损失翻译给老板听：假数据的危害是把风险藏到了上线那天才爆。规则把验证挪到 Key 到位的那一刻，风险暴露越早，处理成本越低。

用这些课程页组织答案 →

调试铁律：先 Log 再改码

不接受分期交付

Q11 面试官

「你做的是 AI 对话产品。调一句提示词，难道要把整个业务流程跑一遍？平时你怎么调 Prompt？」

🎯 对方在考察什么

考 AI 产品的调试基础设施意识 。提示词是 AI 产品的核心资产，答不出专门的调试环境，说明产品还停留在「能跑就行」，谈不上迭代。

🧭 答题框架

给出硬性要求： 项目涉及 AI 对话功能时，PlayGround 中必须实现简单的对话测试页面，脱离完整业务流程也能单独调一轮对话。

把提示词摊开： 这个页面上必须列出项目用到的所有 Prompt。提示词藏在代码字符串里没法调试，摊开在页面上才能快速对比和调整。

点破本质： 提示词是 AI 产品的核心资产，要像管组件一样给它专门的试衣间，调好了再进业务流程。

⭐ 加分点 补上维护规则：PlayGround 的 demo 只增改、不删除，需求取消了对应 demo 也保留，它是设计过程的历史存档，未来需求复活时直接捡回来用。

用这些课程页组织答案 →

PlayGround：组件的试衣间

Q12 面试官

「AI 写的注释我见过，全在复述函数名。你们的代码放三个月，自己还看得懂为什么这么写吗？」

🎯 对方在考察什么

考你能不能把「写好注释」这种 空话变成可执行结构 。「写好注释」四个字 AI 执行不了，能报出固定结构、示例和判断标准的人，才是真的在管 AI 的代码质量。

🧭 答题框架

先认问题： 代码只能表达「做了什么」。为什么存在、为什么这样实现、调用时要注意什么，这些信息只有写进注释才能跨时间留存。

报出三要素： 背景（解决什么业务问题、什么场景被调用）、设计意图（为什么选这个方案、放弃了哪些备选，git log 里找不到这些）、关键约束（副作用、依赖关系、边界条件等调用方须知）。

加保护规则： 重构时禁止以「注释太长」「代码自解释」「顺便清理」为由删掉背景和设计意图注释；实现变了导致注释不准确，必须同步更新内容。

给判断标准： 只有一条，未来接手的人没有这条注释，还能理解当初为什么这样做吗？

⭐ 加分点 举课程里那个例子最有说服力：merge_chat_history 的三要素注释记下了「以服务端记录为权威、只追加本地独有消息、system 消息一律丢弃」，这些决策信息读代码本身根本读不出来。

用这些课程页组织答案 →

注释三要素与代码保护

Q13 技术同事

「我上周写的那段兼容旧数据格式的代码，被你的 AI 重构时清没了。你知道这事吗？」

🎯 对方在考察什么

技术同事在追责，也在试探 你的流程能不能保护他的代码 。这题答不好，合作信任直接清零。核心考「善意破坏」这类事故的防法。

🧭 答题框架

先认事故类型： 这叫善意破坏。AI 重构时清理它认为多余的代码，事后才发现有用，是四类典型事故之一。

给声明规则： 删除任何已有功能代码前，必须明确告知用户并说明理由，禁止以「顺手清理」「看起来没用」为由静默删除。

给标准动作： AI 认为某段代码该移除时，先标注 // TODO: 建议移除 - 原因：xxx ，拿到明确许可再删。「看起来没用」不构成删除理由。

补流程闸： 这类破坏多发生在批量重构里。修改超过 3 个文件必须先交修改计划，逐文件写清改什么，「顺手」的无关清理在审计划这一关就会暴露。

⭐ 加分点 把另一个歧路也堵上：整段注释掉堆在原地同样是错的，规则不鼓励这种做法，本质上还是破坏。正确路径只有一条：标注、告知、等许可。

用这些课程页组织答案 →

注释三要素与代码保护

四步流程：复述、PRD、确认、编码

Q14 面试官

「线上出了故障，翻日志什么都没有，最后发现错误全被 catch 住悄悄吞了。你们对错误处理有约束吗？」

🎯 对方在考察什么

考质量底线有没有细到 语句级 。能报出「什么算静默吞错」的具体清单，说明规则真的执行到了代码层，答「我们会认真处理错误」就是没规则。

🧭 答题框架

给禁令： 禁止空 catch。所有 try/catch 和错误分支必须有实质性处理。

定义吞错： 仅 console.log(e) 、 pass 、 // ignore 都属于静默吞错，一律不允许。

给合格标准： 日志记录加用户可见的错误提示，或者合理的降级逻辑，至少占一样。

配上日志面： 后端在终端打详细日志，前端在浏览器 Console 打日志。吞错和缺日志是同一类病，出问题时都让「先 Log 定位根因」无从下手。

⭐ 加分点 能把这条和注释保护、删除声明归进同一个板块（质量底线，专拦 AI 的偷懒），说明你脑子里装着规则的全景图，答的每条都知道它在体系里的位置。

用这些课程页组织答案 →

注释三要素与代码保护

调试铁律：先 Log 再改码

Q15 老板

「我跟你说过多少次别用弹窗，换了个对话 AI 又给我弹出来了。我的这些要求，就不能让它记住吗？」

🎯 对方在考察什么

老板在抱怨 重复交代的成本 。他要的是一套品味沉淀机制：偏好说一次，之后所有对话都生效。答「我每次开头都提醒 AI」等于把成本留在原地。

🧭 答题框架

给机制： METHODOLOGY.md。AI 主动识别对话中的产品思路、决策逻辑和取舍偏好，提炼后直接写入，新对话自动继承。

说弹窗这事的归宿： 用户否决过弹窗方案并给出理由，AI 把它记进「反模式」，之后同一个方案不会被提第二次。

报四段结构： 产品原则（反复出现的核心信念）、设计决策记录（带日期和理由）、用户体验偏好（UI/UX 品味与审美标准）、反模式（明确拒绝过的方案附拒绝理由）。

说清写入原则： 提炼本质、同类合并、新条目标注日期，避免照搬对话原文；不记技术实现细节和一次性临时决定。AI 识别到就直接写入，写完简要告知，无需每次征求许可。

⭐ 加分点 背出四个触发时机：用户解释了「为什么这样做」、否决方案并给出理由、表达了明确的 UI/UX 偏好、复盘时总结了经验。这四种时刻 AI 自动记录，老板的品味就这样一条条攒成手册。

用这些课程页组织答案 →

三份文档与方法论沉淀

Q16 面试官

「三个月前你们有个功能从 A 方案换成了 B 方案。现在让你说清当初为什么换，你翻什么？」

🎯 对方在考察什么

考 功能级的可追溯性 。答「翻 commit」的人没意识到决策信息和代码信息是两回事：git log 只记了代码怎么改的，记不了为什么改。

🧭 答题框架

直接给答案： 翻 docs/FEATURES.md。它是功能点的唯一事实来源，每个功能带「历史沿革」，记录初始需求、方案变更及原因、最终实现。

报状态流转： 🟡 规划中、🔵 开发中、🟢 已完成、⚪ 已取消。每次状态变更、方案调整都追加一条带日期的记录。

点出细则： 取消的功能也不删，标 ⚪ 并注明原因；日期必须读系统当前时间，不能凭记忆填写；方案没变过也要写一条「初始需求」。

说清 git log 为什么不够： 「搜索功能因性能问题从 A 方案改用 B 方案」这条原因，commit 里只能看到改动本身。历史沿革回答的正是「当初为什么放弃了 A 方案」。

⭐ 加分点 点出一个贯穿的哲学：FEATURES 的「取消不删」和 PlayGround 的「demo 只增不删」是同一件事，被砍掉的需求也是设计过程的历史存档，未来复活时直接捡回来。

用这些课程页组织答案 →

三份文档与方法论沉淀

PlayGround：组件的试衣间

Q17 面试官

「你们的更新公告里写『重构了消息渲染模块』，用户看得懂吗？CHANGELOG 和 RELEASE_NOTES 你们怎么分工？」

🎯 对方在考察什么

考 文档的读者意识 。两份文档语言风格完全不同，一份给开发者、一份给用户，混着写说明没想清楚各自给谁看。

🧭 答题框架

分工一句话： CHANGELOG 回答「这次改了什么」，给开发者看；RELEASE_NOTES 回答「用户得到了什么」，给真实用户看。

CHANGELOG 的格： 按时间倒序，每条用表格记录问题/需求、根因/方案、改动范围、影响面、状态，类型标签分 BUG / FEAT / REFACTOR / PERF / DOCS。写之前必须读系统时间，禁止凭记忆填时间戳、禁止积压补写。

RELEASE_NOTES 的红线： 禁写调试功能、技术实现细节（模块名、文件路径、重构）和用户无感知的改动。「重构消息渲染模块」外部行为不变，压根不该出现在公告里。

给合格写法： 每条能回答「这对我有什么用」。新功能一句话说明用户能做什么新事情，修复写之前什么问题、现在解决了，每条不超过 3 句话，版本号遵循 SemVer。

⭐ 加分点 用同一件事演示分工：输入法误发送的修复，CHANGELOG 里写根因是没判断 isComposing、类型标 BUG；RELEASE_NOTES 里只写「输入中文时不再误发送」。一条信息两份文档各取所需。

用这些课程页组织答案 →

三份文档与方法论沉淀

Q18 技术同事

「拉了你们的分支一跑，发现 axios 没了，全换成 fetch 了。这种事都不说一声的吗？」

🎯 对方在考察什么

考 依赖治理 。依赖变更牵动整个项目的构建和运行环境，静默替换是团队协作的大忌。他想知道你有没有对应的声明机制，还是全凭 AI 心情。

🧭 答题框架

先定性： 这违反依赖变更声明。任何 package.json、requirements.txt 的变更都禁止静默安装或移除。

报三件事： 动手前必须主动说明新增或移除了什么依赖、为什么需要、版本选择理由。

说清为什么严： 功能等价的替换，影响面可能完全等价不了。课程里的真实案例是 axios 从 0.27.2 升到 1.6.0，大版本有破坏性变更，可能波及所有网络请求。

补发版面的兜底： 就算漏了声明，发版前的 diff 审查还会拦一次。Release Notes 没提的依赖变化会被 SubAgent 标为风险、暂停发版。

⭐ 加分点 把边界说死：在 commit message 里提一句不算交代。声明必须发生在动手之前，这和删代码先标 TODO 等许可，是同一个「先声明、后动手」的模式。

用这些课程页组织答案 →

注释三要素与代码保护

破坏性操作的三道闸

Q19 面试官

「AI 生成的代码你们跑测试吗？测试也是 AI 自己写的吧，那算不算自己骗自己？」

🎯 对方在考察什么

考 交付线的硬性程度 。能报出目录、命名、覆盖范围的人，测试是真的在流程里；答「有空就跑跑」的人，测试只是装饰。后半句还埋了个质疑，要接得住。

🧭 答题框架

给硬线： 核心逻辑单元测试不过，不得交付。这是交付前两道硬性检查之一，另一道是真实 AI 接口验证。

报覆盖范围： 核心业务逻辑、API 接口、数据处理函数、边界条件都要覆盖。

报规范细节： 测试文件统一放 tests/ 目录，命名 test_{模块名}.py，Python 项目用 pytest。调试用的临时脚本，用完自行删除，测试资产和调试垃圾分开管。

接住质疑： 测试只是最后一道关，前面还有 PRD 确认拦理解偏差、修改计划拦范围扩散。多道关卡互为补充，单靠哪一道都不够。

⭐ 加分点 补一句边界意识：测试拦的是实现层的回归。AI 对需求理解错了，测试照样全绿，所以断点要设在编码之前，这正是四步流程存在的理由。

用这些课程页组织答案 →

调试铁律：先 Log 再改码

四步流程：复述、PRD、确认、编码

Q20 面试官

「你们的规则禁止 AI 提 MVP？做产品先跑 MVP 验证需求是基本功吧，这不反常识吗？」

🎯 对方在考察什么

概念辨析题，考你能不能分清 人决定的拆分和 AI 自作主张的降级 。把两者混为一谈的人，会把一条好规则用成教条，或者干脆不敢用。

🧭 答题框架

先划界： 规则禁的是 AI 主动规划分期、MVP、阶段一二三，从来没有禁止人做 MVP 决策。拆分是人的决策，降级是 AI 的自作主张，两者的区别就是这条规则的核心。

给正确流程： 功能确实复杂时，AI 的正确动作是给出完整方案、真实工作量和前置决策清单，要不要拆、怎么拆由人拍板。

举边界案例： 一个功能真需要 2000 行代码，一次写完不现实。这时让 AI 报完整方案和工作量，人基于工作量决定拆成两个 PR。这是拆分，与降级无关。

补一条硬规矩： 已知有缺陷的方案，直接给正确版本，别先做一个将就的。

⭐ 加分点 用认证系统的例子收尾：AI 报出完整方案约 3 天、复杂度在 OAuth 回调与多端会话，再列 3 个前置决策（要不要手机号登录、供应商选几家、会话有效期多长），人几十秒就能拍板，完整版一次到位。

用这些课程页组织答案 →

不接受分期交付

Q21 面试官

「你们规定 Agent 工具调用必须用 XML？现在大家都在用 JSON，这规矩是哪来的？」

🎯 对方在考察什么

考格式选型背后的 工程理由 。能讲出 escape hell 和 LLM 逐 token 生成的出错模式，说明你的理解到了生成机制层面，而且知道规则有适用边界。

🧭 答题框架

报三分法： Agent 工具调用用 XML，配置文件和数据存储用 YAML，对外 REST API 用 JSON。三种格式各管一个领域，互不混用。

讲 XML 的理由： JSON 字符串里再套 JSON 就是 escape hell，每层嵌套反斜杠翻一倍，LLM 逐 token 生成时极易配错括号和引号。XML 标签闭合直观，模型出错率更低。

讲另外两个： 配置文件读写的主体是人，YAML 没有括号引号噪音、支持注释，「这个值为什么这么设」直接写在旁边；REST API 用 JSON 是行业标准，对外接口的原则是不折腾调用方。

说出例外： 只用 GPT 系列的项目可以把工具调用改回 JSON，它的 function calling 原生就是 JSON。「Agent 用 XML」是多模型混用场景的最大公约数，Claude 系模型在 XML 上表现更稳。

⭐ 加分点 顺手把 YAML 也排除出调用协议：它靠缩进表达层级，LLM 生成时缩进极易漂移，一格之差整棵结构就歪了。三种格式的落选理由都说得出，才是真懂三分法。

用这些课程页组织答案 →

把环境事实写进 Rule

Q22 面试官

「你们的生图功能一上线就大面积超时，最后查出来是超时配置的问题。这种低级坑怎么防？」

🎯 对方在考察什么

考 环境事实的管理方式 。这类坑的特点是 AI 会反复踩：这次改对了，下个对话又用回默认值。考你知不知道用 Rule 一次性解决，而且能报出具体数字。

🧭 答题框架

说出坑的样子： 图像 API 经常因为默认 30 秒超时失败，AI 还会反复尝试相同的错误配置，改一次好一次、忘一次错一次。

给数字： HTTP 客户端超时对图像生成至少设 120 到 180 秒，写进 Rule，每轮对话自动带入，一次解决。

报同族规则： 网络请求失败必须先尝试代理重试（默认 127.0.0.1:7890），仍失败才向用户报告，禁止跳过代理直接报错；前端可见的所有大模型响应必须用 Streaming 返回，后端内部调用才允许非流式。

上升到机制： 这些都是环境事实。写进 Rule 相当于给 AI 一份预填好的 .env 说明书，新开对话不用交代，它直接知道该调哪个模型、超时设多少。

⭐ 加分点 给出验证方法：新开一个对话，不做任何交代，直接问 AI 项目的技术栈和模型配置。它答得出来，才算真写进了 Rule。这是课程里的课堂练习，做过的人答得毫不犹豫。

用这些课程页组织答案 →

把环境事实写进 Rule

Q23 技术同事

「听说你们同时开好几个 SubAgent 改代码？两个 Agent 改同一个文件，后改的把先改的覆盖了怎么办？」

🎯 对方在考察什么

考 多 Agent 并行的一致性意识 。这是新出现的工程问题，答得出的人说明真的在用多 Agent 干活，答不出的说明并行对你只是个演示。

🧭 答题框架

给规则： 多个 SubAgent 或多次编辑涉及同一文件时，后续修改必须先重新读取文件当前状态，禁止基于缓存或记忆中的旧内容编辑。

给类比： 这就是多 Agent 时代的「乐观锁」。写之前先确认文件的最新状态，别人的改动才不会被无意覆盖。

配上目标一致性： 并行期间用户可能改了目标。复述目标时以最新一次为准，并明确标注变更，避免新旧目标混在一起，两个 Agent 各干各的。

说明并行有正面用法： 规则鼓励并行调研。修 bug 前的三问自查，就建议优先启动 SubAgent 并行调研影响范围，确认安全后再动手。

⭐ 加分点 点破这两条规则的共同点：长对话和并行操作里，手上的信息都会过期。关键动作之前先刷新（重读文件、复述目标），比出事后排查便宜得多。

用这些课程页组织答案 →

长对话锚定与写作规范

调试铁律：先 Log 再改码

Q24 面试官

「AI 建议你们把数据库从 SQLite 换成 PostgreSQL，理由列得头头是道。你换不换？」

🎯 对方在考察什么

考 选型决策权的归属 。顺着 AI 换的人，项目迟早陷进选型漂移。想听到的答案是「锁定」，以及锁定的具体做法。

🧭 答题框架

先给态度： 不换。技术栈选型是人的决策，一旦定了就不再讨论替代方案，AI 的职责是在确定的栈内把代码写好。

说出漂移的样子： 不加锁定，不同对话里 AI 会选不同框架，今天 Express 明天 Fastify，数据库一会儿 MongoDB 一会儿 PostgreSQL，项目在漂移中失去一致性。

报锁定内容： 把选型写死进 Rule。课程里的例子是后端 FastAPI、前端 React + Tailwind + Vite、数据库 SQLite、向量库 Chroma。

补端口细节： 端口避开 5000，从 8000 到 9000 随机分配，多项目同开也不冲突。能报出这条，说明 Rule 真读到了细节。

⭐ 加分点 补上「怎么换才对」：真要换库，入口是人改 Rule 里的技术栈声明（适配四动作里的「换」），AI 再在新栈内干活。选型可以变，但变更入口在人手里，从来不在 AI 的建议里。

用这些课程页组织答案 →

把环境事实写进 Rule

为什么要给 AI 立规矩

Q25 老板

「上个版本的事故我记着呢：发版时混进了一段没做完的代码。你说加了审查，具体怎么审？审出问题怎么办？」

🎯 对方在考察什么

老板要的是 步骤级的流程细节 。「我们会审查」这四个字他已经听腻了，要拆到每一步干什么、审出问题谁说了算。

🧭 答题框架

报流程三步： 取完整 diff、逐文件比对、分类处理。让 SubAgent 独立分析实际 diff 和 Release Notes 的偏差。

说清审什么： Release Notes 写的是预期改动，实际 commit 可能混进无关调整甚至误删。课程案例：发版主题是夜间模式，diff 里却混着改写消息解析函数的改动和 axios 从 0.27.2 到 1.6.0 的依赖升级，这些没写进公告的就是风险。

给处置： 审出风险就暂停发版，等待用户确认。确认之前，打 tag、push、部署全部禁止，AI 没有自行发版的权限。

补发布通道： 发布必须走 GitHub，服务器通过 git pull 或 CI/CD 拉代码。紧急热修复可以例外，事后必须补 commit 同步。

⭐ 加分点 用一句话概括审查的价值：把「我以为我改了什么」和「我实际改了什么」拆开比对，两者的差值就是事故的来源。老板听完这句就知道你想明白了。

用这些课程页组织答案 →

破坏性操作的三道闸

Q26 面试官

「你跟 AI 聊了 30 轮，它突然把开头定好的数据库给换了。这种事你遇到过吗？怎么治？」

🎯 对方在考察什么

考 长对话漂移的成因理解 。答「多提醒它几次」是没入门；能讲出窗口截断机制和周期性锚点的人，才是长对话的真用户。

🧭 答题框架

先讲成因： 上下文窗口截断加长文本尾部注意力衰减。第 1 轮说的「用 PostgreSQL」聊到 30 轮已经滑出窗口，AI 只是在它看得见的信息里做了一个「合理」推断，于是建议换 SQLite。

给规则： 超过 10 轮之后，修改代码、修改配置、部署这些关键操作前，AI 必须先回顾并复述当前目标和关键约束。

给格式： 复述有固定格式「📌 当前目标：XXX | 关键约束：YYY」，人扫一眼就能确认有没有跑偏。

补边界认知： 即使是 200K token 的模型，注意力在长文本尾部的衰减也真实存在。锚定对长窗口模型同样必要，换大模型治不了这个病。

⭐ 加分点 把两道防线连起来：选型漂移本身就是四类典型事故之一，技术栈锁定从对话外拦（Rule 每轮注入），锚定从对话内拦（周期性复述），双保险。

用这些课程页组织答案 →

长对话锚定与写作规范

为什么要给 AI 立规矩

Q27 面试官

「你们的产品文案也让 AI 写？说实话，AI 味我一眼就能看出来，用户也能。你怎么保证写出来像人话？」

🎯 对方在考察什么

考你能不能把「自然流畅」这种 主观要求工程化 。答「我会多改几遍」的人没有方法；能报出违禁清单和自查流程的人，交付质量是稳定的。

🧭 答题框架

点破空话为什么没用： 「请用自然流畅的中文」没有用，AI 认为的自然和你认为的自然可能完全不同。必须给出具体的违禁词和违禁句式列表，AI 才能精确执行。

举违禁模式： writing-style.mdc 的清单里包括全角破折号、全角省略号、「不是 A 而是 B」这类对比句式、网文式情绪词、评价他人的话、解读前置的铺垫、英文弯引号。

给自查流程： 交付前逐条搜索违禁模式，发现一处改一处，完成后注明已完成自查。System Prompt 里的违禁句式同样要改。

给配置细节： 写作规范独立成文件，frontmatter 设 alwaysApply: false，只在写文案或 Prompt 时手动引用，避免污染编码对话的上下文。

⭐ 加分点 说出清单方法的本质：违禁模式是可搜索的，AI 可以逐条扫描自己刚写的稿子，主观品味就变成了机械检查。锚定对抗遗忘，清单对抗含糊，共同点都是把模糊期望变成可执行动作。

用这些课程页组织答案 →

长对话锚定与写作规范

为什么要给 AI 立规矩

Q28 面试官

「你们界面第一版全是 emoji 按钮，是 AI 的手笔吧？设计品味这种东西，也能立成规矩吗？」

🎯 对方在考察什么

考 品味能不能规则化 。多数人以为规则只管流程和安全，能举出设计层的具体条款，说明你理解这套规则的覆盖面到了什么程度。

🧭 答题框架

给条款： 禁止用 emoji 做按钮图标，图标必须用 SVG。

给选型方法： 看产品调性选图标集，SaaS 用 Lucide，温暖调性用 Tabler Icons。

给工程细节： 图标直接下载到本地使用，不依赖 CDN。

回答「能不能」： 能。这类品味决策和 isComposing 一样，归在「文档与设计规范」章节。品味固化成规则后 AI 每次生成都遵守，免得每一版都要人肉挑一遍。

⭐ 加分点 分清两层品味：Rule 管通用底线（禁 emoji、用 SVG），METHODOLOGY 的「用户体验偏好」管本项目的具体偏好，比如确认按钮固定放右下角、用品牌色。两层配合，品味才完整。

用这些课程页组织答案 →

把环境事实写进 Rule

三份文档与方法论沉淀

Q29 面试官

「你说这套规范有 14 章。现在给你 60 秒，把它的骨架讲清楚。」

🎯 对方在考察什么

考 全局观和提炼能力 。背不出全景图的人多半只用过其中两三条；说得出板块划分和底层逻辑的人，才配讲方法论。

🧭 答题框架

报五大板块： 流程控制（断点设在编码前）、质量底线（完整实现，不接受将就）、文档沉淀（决策跨对话留存）、环境与安全（环境事实一次写死）、沟通与写作（锚定与自查）。

各给一个代表条款： 修改超过 3 个文件先列计划；禁止猜测性修复；三份文档各管一个维度；备份、回退、diff 审查三道闸；超过 10 轮复述目标。

收在共同底层： 把模糊期望变成可执行的具体动作。「注意质量」执行不了，「删除代码前必须显式声明」才执行得了。14 章每一章都在做这个翻译。

⭐ 加分点 能把章号对上就更狠：环境与安全一个板块就装了模型配置、数据格式、技术栈、部署四章。说得出结构里的具体章节，证明你读过规则原文，60 秒讲的是消化过的东西。

用这些课程页组织答案 →

规则的价值：每条解决一个真实问题

Q30 面试官

「假设我们明天就把你这套规则原样搬进公司仓库，全员执行。你支持吗？」

🎯 对方在考察什么

收官陷阱题。答「支持」就掉坑了：这套规则带着作者项目的环境事实，照搬必翻车。考你有没有 一套适配方法论 ，而且答案里要有取舍。

🧭 答题框架

先拦住： 不建议原样搬。规则里写死了作者项目的技术栈、端口、格式选型，这些环境事实和你们公司对不上。照搬 14 章不如精选 5 章。

给四个动作： 删（不做中文内容创作就把写作规范移出 .cursor/rules/，减少无关上下文）、换（技术栈声明换成公司的选型）、调（「修改超过 3 个文件先确认」的阈值按项目调，谨慎项目调成 1，快速原型放宽到 5）、补（把团队里 AI 反复犯的错写成新规则）。

给验证周期： 在一个真实项目里用满一周，记录哪些规则被触发、哪些从没生效。删掉从没生效的，把新踩的坑写成新规则。

说清为什么： 规则和代码一样，没人维护就会腐烂。搬进来只是开始，养起来才算用上。

⭐ 加分点 把闭环补完：删换调补做完的版本可以开源出去，原仓库本身就是 MIT License，鼓励 Fork 改造后发布自己的版本。能说到这一步，说明你把规则当成了可以持续迭代的资产。

用这些课程页组织答案 →

规则的价值：每条解决一个真实问题

四步流程：复述、PRD、确认、编码

最后一个建议

这 30 题最好的准备方式是 拿真项目练一遍 ：把 xs_vibe_rules 放进你的项目，跑两周，事故和规则都会变成你自己的故事。有故事的回答，和背框架的回答，对方一耳朵就能听出来。