免费 · 系统 · 可实践
搜索 EN 从第 1 课开始
课程/他们会这样考你/Vibe Coding 方法论 · 30 道灵魂拷问
协作方法论 · 带护栏的 Vibe Coding

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

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

本页解决的问题

先给结论

「Vibe Coding 方法论 · 30 道灵魂拷问」要解决的关键问题是什么？

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

判断标准

让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。

下一步

写下一个问题：试完这个方法后，你能用什么证据回答它？

常见误区

结论听起来很完整，却没有检查最关键的假设。

怎么用这一页
每道题都标注了提问者。他们盯着同一套 AI 协作规范，想听的东西却不一样。
🎙 面试官想验证你是真用过，还是只看过几篇公众号
👔 老板担心的是质量、责任和事故
🛠 技术同事在试探你懂不懂工程，值不值得放权
每题给出三层：对方在考察什么 → 答题框架 → 加分点。答不上来的环节，点末尾的课程页回去补。
Q1面试官
「你简历上写熟悉 Vibe Coding。都让 AI 写代码了，你还立一堆规矩，图什么？」
🎯 对方在考察什么
开场定调题。考的是你能不能用事故说话。只会说「规范很重要」的人在背套话；真踩过坑的人，张口就是具体事故和对应的规则。答「AI 偶尔会出错所以要小心」这种正确的废话，基本就露馅了。
🧭 答题框架
  1. 先说清 Vibe Coding 是什么：靠自然语言让 AI 直接产出代码的开发方式。它的问题从来出在质量，写得快只是放大了搞砸的速度。
  2. 甩出四类典型事故：理解偏差返工（改了 7 个文件才发现思路错了）、选型漂移（今天 Express 明天 Fastify）、善意破坏（重构时清理掉有用的代码）、永久技术债（简版登录再也没升级过）。
  3. 点破共同根源：四类事故根源是同一件事，约束没有进入上下文。AI 每轮对话都可能忘掉你交代过的事。
  4. 给出解法：把约束写进 Rule 文件，每轮对话开始前自动加载。对话里交代会被截断挤出窗口，写在文档里 AI 未必去读，只有 Rule 是结构上最稳的注入渠道。
⭐ 加分点补一句方法论的生成逻辑：AI 每反复犯一次错，就把它变成一条规则。规则的价值在于每条都解决一个真实问题，堆砌条款没有意义。这句话能证明你理解的是方法，可以直接背下来。
用这些课程页组织答案 → 为什么要给 AI 立规矩 规则的价值：每条解决一个真实问题
Q2老板
「都用 AI 写代码了，出了 bug 算谁的？AI 的锅还是你的锅？你敢对质量负责吗？」
🎯 对方在考察什么
老板要的是责任归属和质量机制。答「AI 生成的我们都会检查」等于什么机制都没有；把锅甩给 AI 更不行，那等于承认这套流程不可控。老板想听到的是：责任在人，而且有具体的关卡保证人负得起这个责。
🧭 答题框架
  1. 先接住责任：bug 永远算人的，AI 是工具。这套规范的目的就是让人在每个关键节点都有拍板的机会，出了问题能追溯到具体哪一关放过去的。
  2. 给事前关卡：断点设在动手之前。AI 写代码前必须复述需求、产出 PRD、拿到明确许可；改超过 3 个文件先交修改计划。理解偏差在写第一行代码之前就被拦下。
  3. 给交付底线：两道硬性检查。涉及 AI 接口的功能必须真实调用过，禁止 Mock 绕过；核心逻辑单元测试不过，不得交付。
  4. 给出事后的修法：真出了 bug，禁止猜测性修复。先加 Log 定位根因，修复前回答三个问题（完整业务流程、影响哪些模块、有没有同类问题），修完声明影响范围，明确该回归测试哪里。
⭐ 加分点主动报数据对比：猜测性修复三轮改 47 行 bug 还在，先 Log 一轮定位根因就修干净。加 Log 的 2 分钟，买断的是猜错三轮的返工。老板听得懂这笔账。
用这些课程页组织答案 → 调试铁律：先 Log 再改码 四步流程：复述、PRD、确认、编码 为什么要给 AI 立规矩
Q3技术同事
「AI 生成的代码你们 PM 也敢直接合？一次改十几个文件，谁看得过来？」
🎯 对方在考察什么
技术同事在试探你有没有流程意识。他真正怕的是失控的大范围改动。答「AI 现在很强的，基本不会错」，他从此不会再放心让你碰仓库；答出具体的断点机制，他会开始把你当同行。
🧭 答题框架
  1. 先纠正前提：不存在直接合。AI 动手前要走四步流程：先思考提问、用自己的理解复述需求、写出 PRD、拿到明确许可才开始编码。人不点批准，代码不会产生。
  2. 正面回应大改动：修改超过 3 个文件必须先交修改计划，写清三件事：改哪些文件、每个文件改什么、改动之间的依赖关系。审的是计划，量再大也看得过来。
  3. 补上防扩散的细则：新增功能前先搜索项目里有没有类似实现，防止重复造轮子；新组件先在 PlayGround 做独立 demo，调好了再集成进主工程。
  4. 说清为什么规则要写死：「请先确认理解后再编码」这种模糊表述没用，AI 会自己判断「我理解了」然后直接动手。写明「写 PRD、等待许可」这类具体动作，断点才真的存在。
⭐ 加分点说出阈值的工程判断：3 个文件是经验值，谨慎的项目调成 1，快速原型放宽到 5。简单的一行改动 AI 自行判断跳过 PRD，规矩拦的是返工成本最高的多文件变更。懂得阈值可调，说明你真在项目里用过。
用这些课程页组织答案 → 四步流程：复述、PRD、确认、编码 PlayGround：组件的试衣间
Q4老板
「AI 说先上个简版，两天就能看到东西，我觉得挺务实的。你为什么非要拦着？」
🎯 对方在考察什么
老板站在了 AI 那边，你要说服的是人。这题考你能不能把技术债翻译成老板听得懂的成本账。顺着说「好的那就先上简版」，你就成了技术债的共犯；只会说「有技术债」又太空，老板要的是数字。
🧭 答题框架
  1. 先戳穿动机：AI 提「先做简版」往往与复杂度无关，它想快速给你一个能跑的东西换正反馈。「先用临时方案」「暂时 Mock」「简单处理一下」背后是同一个模式。
  2. 给成本账：简版上线当天补全只要 0.5 倍成本；第 30 天，4 个模块依赖了简版接口，补全成本升到 3 倍；第 90 天，9 个模块耦合长死，8 倍成本超过重写。「后续再优化」的后续永远不会来。
  3. 给规则：禁止以任何理由简化实现，也禁止 AI 主动规划分期和 MVP。每次实现都必须是完整、正确、没有代码债的方案。
  4. 把选择权还给老板：功能确实太复杂时，正确动作是让 AI 给出完整方案、真实工作量和前置决策清单，由人决定要不要拆、怎么拆。拆分是人的决策，降级是 AI 的自作主张。
⭐ 加分点点破一个反直觉的现象：打破「先做简版」的模式后，AI 反而会更认真地分析完整方案。这条观察来自真实使用，能说出来就赢了大多数人。
用这些课程页组织答案 → 不接受分期交付 四步流程：复述、PRD、确认、编码
Q5技术同事
「上个月那个功能为什么改成现在这样，你还说得清吗？AI 对话一关，决策不就全丢了？」
🎯 对方在考察什么
这是对 Vibe Coding 可维护性的致命一问。对话式开发的决策默认锁死在聊天记录里，三个月后翻遍 git log 也找不回来。答「我翻一下历史对话」等于承认没有沉淀机制；能答出文档体系，才算真把 AI 协作当工程在做。
🧭 答题框架
  1. 承认问题、给出机制：决策确实不能靠对话留存，所以让 AI 按严格模板维护文档，决策跨越对话和时间存活。
  2. 报出三份文档的分工：FEATURES 回答「这个功能怎么来的」，带状态流转和历史沿革，方案变更及原因都记档；CHANGELOG 回答「这次改了什么」，记根因和影响面；RELEASE_NOTES 回答「用户得到了什么」。
  3. 再加一份沉淀品味的：METHODOLOGY.md 记产品原则、设计决策、体验偏好和反模式。用户否决过弹窗方案，AI 记进反模式，之后新对话自动继承，同一个方案不会被提第二次。
  4. 说清为什么放仓库里：决策写在 Notion 或飞书里 AI 读不到。放在项目仓库内的 Markdown 文件，才能让 AI 每次自动获取上下文。
⭐ 加分点补两条容易被忽略的细则：写 CHANGELOG 前必须读系统时间，禁止凭记忆填时间戳、禁止积压补写；代码注释要求三要素（背景、设计意图、关键约束），注释也是给下一轮对话的 AI 看的。
用这些课程页组织答案 → 三份文档与方法论沉淀 注释三要素与代码保护
Q6老板
「我刷到过 AI 删库的新闻。咱们这样搞，万一哪天 AI 把生产数据库干掉了怎么办？」
🎯 对方在考察什么
老板在要安全感。答「AI 不会乱来的」是最差答案，因为 AI 确实会：善意的清理、混进发版的临时改动，都是真实发生过的事故。正确姿势是承认风险存在，然后把闸门一道一道摆出来。
🧭 答题框架
  1. 先给总原则：不可逆操作的安全感来自闸门。数据库、配置、部署这类操作，闸全部设在执行之前。
  2. 报出三道闸：第一道备份，未备份不得执行任何 migrate、drop、alter、delete，备份带时间戳放 backups/ 目录，成本是一行命令，赌的是整库数据；第二道回退，动手前说清如何恢复、需要哪些备份、预计恢复耗时；第三道审查，发版前让 SubAgent 比对实际 diff 和 Release Notes，混进无关改动就暂停发版。
  3. 补上发布纪律：发布必须走 GitHub，服务器通过 git pull 或 CI/CD 拉代码。用户明确确认之前，打 tag、push、部署全部禁止，AI 没有自行发版的权限。
  4. 顺带把凭据也管住：所有 Key 走环境变量或 secrets，禁止硬编码。Key 一旦进入 git 历史等于永久泄露，只能作废重发。
⭐ 加分点说清 diff 审查的设计意图：正规团队靠 CI/CD 加 PR review 拦带病发版，独立开发者往往跳过 review 直接 push，让 SubAgent 充当 reviewer 就是补上这一环。能讲出这层，说明你理解规则背后的工程直觉。
用这些课程页组织答案 → 破坏性操作的三道闸 把环境事实写进 Rule
Q7面试官
「你说把规矩写进 Rule 文件。这文件到底长什么样？我明天新开一个项目，第一步该干什么？」
🎯 对方在考察什么
考的是你有没有真的动手配置过。只会讲理念、说不出文件结构和目录位置的人，基本是看文章学的。能报出 frontmatter 字段和三个文件的分工，才算真落过地。
🧭 答题框架
  1. 先说文件结构：Rule 文件带 frontmatter，alwaysApply: true 用于全局编码规范，所有对话自动生效；设 false 的用于写作规范这类按需引用的文件，避免污染编码对话的上下文。
  2. 报出三个文件：xs_vibe_rules 一共三份。rule-opensource.mdc 是主开发规范，14 个章节覆盖全流程；writing-style.mdc 管中文写作风格，按需手动引用；secrets.mdc 是 API Key 与凭据模板，占位符形式。
  3. 给落地三步：把 .mdc 文件放进项目的 .cursor/rules/ 目录，Cursor 自动识别；配置每个文件的 alwaysApply；把模型配置、技术栈、端口规则换成自己的选型。
  4. 把安全交代掉：secrets 文件填占位符并排除出 git。Key 一旦进入 git 历史等于永久泄露，只能作废重发。
⭐ 加分点补一句起手式：这套仓库是 MIT License 开源的，正确姿势是 Fork 一份、按自己技术栈删改，改出来的就是你的第一版 AI 协作规范，起点比从零写高得多。
用这些课程页组织答案 → 为什么要给 AI 立规矩 规则的价值：每条解决一个真实问题
Q8技术同事
「你们聊天框的 bug 我看了：中文输入法一按回车，半截拼音直接发出去了。AI 写的吧？怎么保证它下次不再犯？」
🎯 对方在考察什么
考你对 AI 盲区的认知深度。能说出 isComposing 这个具体 API、并解释为什么 AI 必踩这个坑的人，是真的在一线修过 AI 写的前端。只会说「让 AI 改一下」的人，下个项目还会踩。
🧭 答题框架
  1. 先给根因：中文输入法确认候选词时也会触发 Enter。代码只判断了 e.key === 'Enter'，没检查 isComposing，选词的回车就被当成了发送。
  2. 给标准写法：Enter、非 Shift、!e.nativeEvent.isComposing 三个条件同时满足才发送。isComposing 为 true 表示输入法正在组合中，这时回车只确认候选词，不触发发送。
  3. 解释 AI 为什么会犯：AI 训练数据里 isComposing 覆盖率不高，不写进 Rule 就一定会忘。规则原文写得很死：禁止只判断 e.key === 'Enter' 而不检查 isComposing。
  4. 上升到修法：这个 bug 本身也是「先 Log 再改码」的教科书案例。加一行 Log 打印 e.key 和 isComposing，一轮定位根因，4 行修干净；瞎猜的路线三轮改了 47 行还没修好。
⭐ 加分点顺嘴提一句 !e.shiftKey：标准写法把 Shift 加回车留给换行，这种细节 AI 也常漏。能背出完整判断条件的人，一听就是修过这个坑的。
用这些课程页组织答案 → 把环境事实写进 Rule 调试铁律：先 Log 再改码
Q9面试官
「你说组件都先在 PlayGround 里调好再集成。前端圈有现成的 Storybook，你们为什么不用？」
🎯 对方在考察什么
考工程判断力：你知不知道行业标准方案，以及为什么在自己的场景下选了更轻的做法。答「没听过 Storybook」暴露视野窄，答「Storybook 更专业所以该用」暴露不会算成本。
🧭 答题框架
  1. 先认思路同源：PlayGround 就是简化版 Storybook 思路，每个 UI 元素有单独的 demo，调好了再集成进正式页面。
  2. 差别在成本：Storybook 是行业标准，但配置太重，对 AI 辅助的快速原型项目属于 overkill。PlayGround 用一个静态页面把所有组件 demo 排在一起，成本几乎为零。
  3. 说清换来了什么：双向隔离。改组件不影响业务逻辑，调业务逻辑不搞乱组件样式。直接写进页面的话，调一个按钮要先把整个页面跑起来，登录、拉数据、切状态才能看它一眼，圆角改大了还可能挤歪旁边的布局。
  4. 给触发条件：规则写明，涉及页面动效时必须先创建静态页面 PlayGround，自由调整测试之后，才允许写进正式页面。
⭐ 加分点补一个交付细节：demo 里调好的参数可以直接抄进正式组件，集成时它已经是成品。试衣间里改好了再上台，返工就发生不了。
用这些课程页组织答案 → PlayGround：组件的试衣间
Q10老板
「上次演示看着挺好，一上线全是问题。后来才知道 AI 接口根本没通，页面上全是假数据。这种事你怎么杜绝？」
🎯 对方在考察什么
老板被假演示坑过，要的是交付线上的硬性机制。答「以后我会仔细检查」等于承认没有机制，下次还会发生。要给出流程里写死的关卡。
🧭 答题框架
  1. 给出禁令：凡涉及 AI 模型调用的功能，交付前必须确认接口真的能访问，禁止硬编码假响应或本地模拟绕过真实调用。
  2. 卡住源头：用户没给 API Key 时，AI 必须停下来要，不许自己 Mock 着继续写。Key 到位后先发一次测试请求验证可用性，再继续开发。「接口没通」这个最大风险被提前到了开发第一步暴露。
  3. 配上第二道线：核心业务逻辑单元测试不过，不得交付。两道硬性检查一起构成交付线。
  4. 点破动机：「暂时 Mock」和「先用临时方案」「简单处理一下」是同一个模式，AI 想快速给你一个能跑的东西换正反馈。这些话术在规则里被同一条款点名禁止。
⭐ 加分点把损失翻译给老板听：假数据的危害是把风险藏到了上线那天才爆。规则把验证挪到 Key 到位的那一刻，风险暴露越早，处理成本越低。
用这些课程页组织答案 → 调试铁律：先 Log 再改码 不接受分期交付
Q11面试官
「你做的是 AI 对话产品。调一句提示词，难道要把整个业务流程跑一遍？平时你怎么调 Prompt？」
🎯 对方在考察什么
考 AI 产品的调试基础设施意识。提示词是 AI 产品的核心资产，答不出专门的调试环境，说明产品还停留在「能跑就行」，谈不上迭代。
🧭 答题框架
  1. 给出硬性要求：项目涉及 AI 对话功能时，PlayGround 中必须实现简单的对话测试页面，脱离完整业务流程也能单独调一轮对话。
  2. 把提示词摊开：这个页面上必须列出项目用到的所有 Prompt。提示词藏在代码字符串里没法调试，摊开在页面上才能快速对比和调整。
  3. 点破本质：提示词是 AI 产品的核心资产，要像管组件一样给它专门的试衣间，调好了再进业务流程。
⭐ 加分点补上维护规则：PlayGround 的 demo 只增改、不删除，需求取消了对应 demo 也保留，它是设计过程的历史存档，未来需求复活时直接捡回来用。
用这些课程页组织答案 → PlayGround：组件的试衣间
Q12面试官
「AI 写的注释我见过，全在复述函数名。你们的代码放三个月，自己还看得懂为什么这么写吗？」
🎯 对方在考察什么
考你能不能把「写好注释」这种空话变成可执行结构。「写好注释」四个字 AI 执行不了，能报出固定结构、示例和判断标准的人，才是真的在管 AI 的代码质量。
🧭 答题框架
  1. 先认问题：代码只能表达「做了什么」。为什么存在、为什么这样实现、调用时要注意什么，这些信息只有写进注释才能跨时间留存。
  2. 报出三要素：背景（解决什么业务问题、什么场景被调用）、设计意图（为什么选这个方案、放弃了哪些备选，git log 里找不到这些）、关键约束（副作用、依赖关系、边界条件等调用方须知）。
  3. 加保护规则：重构时禁止以「注释太长」「代码自解释」「顺便清理」为由删掉背景和设计意图注释；实现变了导致注释不准确，必须同步更新内容。
  4. 给判断标准：只有一条，未来接手的人没有这条注释，还能理解当初为什么这样做吗？
⭐ 加分点举课程里那个例子最有说服力：merge_chat_history 的三要素注释记下了「以服务端记录为权威、只追加本地独有消息、system 消息一律丢弃」，这些决策信息读代码本身根本读不出来。
用这些课程页组织答案 → 注释三要素与代码保护
Q13技术同事
「我上周写的那段兼容旧数据格式的代码，被你的 AI 重构时清没了。你知道这事吗？」
🎯 对方在考察什么
技术同事在追责，也在试探你的流程能不能保护他的代码。这题答不好，合作信任直接清零。核心考「善意破坏」这类事故的防法。
🧭 答题框架
  1. 先认事故类型：这叫善意破坏。AI 重构时清理它认为多余的代码，事后才发现有用，是四类典型事故之一。
  2. 给声明规则：删除任何已有功能代码前，必须明确告知用户并说明理由，禁止以「顺手清理」「看起来没用」为由静默删除。
  3. 给标准动作：AI 认为某段代码该移除时，先标注 // TODO: 建议移除 - 原因：xxx，拿到明确许可再删。「看起来没用」不构成删除理由。
  4. 补流程闸：这类破坏多发生在批量重构里。修改超过 3 个文件必须先交修改计划，逐文件写清改什么，「顺手」的无关清理在审计划这一关就会暴露。
⭐ 加分点把另一个歧路也堵上：整段注释掉堆在原地同样是错的，规则不鼓励这种做法，本质上还是破坏。正确路径只有一条：标注、告知、等许可。
用这些课程页组织答案 → 注释三要素与代码保护 四步流程：复述、PRD、确认、编码
Q14面试官
「线上出了故障，翻日志什么都没有，最后发现错误全被 catch 住悄悄吞了。你们对错误处理有约束吗？」
🎯 对方在考察什么
考质量底线有没有细到语句级。能报出「什么算静默吞错」的具体清单，说明规则真的执行到了代码层，答「我们会认真处理错误」就是没规则。
🧭 答题框架
  1. 给禁令：禁止空 catch。所有 try/catch 和错误分支必须有实质性处理。
  2. 定义吞错：仅 console.log(e)、pass、// ignore 都属于静默吞错，一律不允许。
  3. 给合格标准：日志记录加用户可见的错误提示，或者合理的降级逻辑，至少占一样。
  4. 配上日志面：后端在终端打详细日志，前端在浏览器 Console 打日志。吞错和缺日志是同一类病，出问题时都让「先 Log 定位根因」无从下手。
⭐ 加分点能把这条和注释保护、删除声明归进同一个板块（质量底线，专拦 AI 的偷懒），说明你脑子里装着规则的全景图，答的每条都知道它在体系里的位置。
用这些课程页组织答案 → 注释三要素与代码保护 调试铁律：先 Log 再改码
Q15老板
「我跟你说过多少次别用弹窗，换了个对话 AI 又给我弹出来了。我的这些要求，就不能让它记住吗？」
🎯 对方在考察什么
老板在抱怨重复交代的成本。他要的是一套品味沉淀机制：偏好说一次，之后所有对话都生效。答「我每次开头都提醒 AI」等于把成本留在原地。
🧭 答题框架
  1. 给机制：METHODOLOGY.md。AI 主动识别对话中的产品思路、决策逻辑和取舍偏好，提炼后直接写入，新对话自动继承。
  2. 说弹窗这事的归宿：用户否决过弹窗方案并给出理由，AI 把它记进「反模式」，之后同一个方案不会被提第二次。
  3. 报四段结构：产品原则（反复出现的核心信念）、设计决策记录（带日期和理由）、用户体验偏好（UI/UX 品味与审美标准）、反模式（明确拒绝过的方案附拒绝理由）。
  4. 说清写入原则：提炼本质、同类合并、新条目标注日期，避免照搬对话原文；不记技术实现细节和一次性临时决定。AI 识别到就直接写入，写完简要告知，无需每次征求许可。
⭐ 加分点背出四个触发时机：用户解释了「为什么这样做」、否决方案并给出理由、表达了明确的 UI/UX 偏好、复盘时总结了经验。这四种时刻 AI 自动记录，老板的品味就这样一条条攒成手册。
用这些课程页组织答案 → 三份文档与方法论沉淀
Q16面试官
「三个月前你们有个功能从 A 方案换成了 B 方案。现在让你说清当初为什么换，你翻什么？」
🎯 对方在考察什么
考功能级的可追溯性。答「翻 commit」的人没意识到决策信息和代码信息是两回事：git log 只记了代码怎么改的，记不了为什么改。
🧭 答题框架
  1. 直接给答案：翻 docs/FEATURES.md。它是功能点的唯一事实来源，每个功能带「历史沿革」，记录初始需求、方案变更及原因、最终实现。
  2. 报状态流转：🟡 规划中、🔵 开发中、🟢 已完成、⚪ 已取消。每次状态变更、方案调整都追加一条带日期的记录。
  3. 点出细则：取消的功能也不删，标 ⚪ 并注明原因；日期必须读系统当前时间，不能凭记忆填写；方案没变过也要写一条「初始需求」。
  4. 说清 git log 为什么不够：「搜索功能因性能问题从 A 方案改用 B 方案」这条原因，commit 里只能看到改动本身。历史沿革回答的正是「当初为什么放弃了 A 方案」。
⭐ 加分点点出一个贯穿的哲学：FEATURES 的「取消不删」和 PlayGround 的「demo 只增不删」是同一件事，被砍掉的需求也是设计过程的历史存档，未来复活时直接捡回来。
用这些课程页组织答案 → 三份文档与方法论沉淀 PlayGround：组件的试衣间
Q17面试官
「你们的更新公告里写『重构了消息渲染模块』，用户看得懂吗？CHANGELOG 和 RELEASE_NOTES 你们怎么分工？」
🎯 对方在考察什么
考文档的读者意识。两份文档语言风格完全不同，一份给开发者、一份给用户，混着写说明没想清楚各自给谁看。
🧭 答题框架
  1. 分工一句话：CHANGELOG 回答「这次改了什么」，给开发者看；RELEASE_NOTES 回答「用户得到了什么」，给真实用户看。
  2. CHANGELOG 的格：按时间倒序，每条用表格记录问题/需求、根因/方案、改动范围、影响面、状态，类型标签分 BUG / FEAT / REFACTOR / PERF / DOCS。写之前必须读系统时间，禁止凭记忆填时间戳、禁止积压补写。
  3. RELEASE_NOTES 的红线：禁写调试功能、技术实现细节（模块名、文件路径、重构）和用户无感知的改动。「重构消息渲染模块」外部行为不变，压根不该出现在公告里。
  4. 给合格写法：每条能回答「这对我有什么用」。新功能一句话说明用户能做什么新事情，修复写之前什么问题、现在解决了，每条不超过 3 句话，版本号遵循 SemVer。
⭐ 加分点用同一件事演示分工：输入法误发送的修复，CHANGELOG 里写根因是没判断 isComposing、类型标 BUG；RELEASE_NOTES 里只写「输入中文时不再误发送」。一条信息两份文档各取所需。
用这些课程页组织答案 → 三份文档与方法论沉淀
Q18技术同事
「拉了你们的分支一跑，发现 axios 没了，全换成 fetch 了。这种事都不说一声的吗？」
🎯 对方在考察什么
考依赖治理。依赖变更牵动整个项目的构建和运行环境，静默替换是团队协作的大忌。他想知道你有没有对应的声明机制，还是全凭 AI 心情。
🧭 答题框架
  1. 先定性：这违反依赖变更声明。任何 package.json、requirements.txt 的变更都禁止静默安装或移除。
  2. 报三件事：动手前必须主动说明新增或移除了什么依赖、为什么需要、版本选择理由。
  3. 说清为什么严：功能等价的替换，影响面可能完全等价不了。课程里的真实案例是 axios 从 0.27.2 升到 1.6.0，大版本有破坏性变更，可能波及所有网络请求。
  4. 补发版面的兜底：就算漏了声明，发版前的 diff 审查还会拦一次。Release Notes 没提的依赖变化会被 SubAgent 标为风险、暂停发版。
⭐ 加分点把边界说死：在 commit message 里提一句不算交代。声明必须发生在动手之前，这和删代码先标 TODO 等许可，是同一个「先声明、后动手」的模式。
用这些课程页组织答案 → 注释三要素与代码保护 破坏性操作的三道闸
Q19面试官
「AI 生成的代码你们跑测试吗？测试也是 AI 自己写的吧，那算不算自己骗自己？」
🎯 对方在考察什么
考交付线的硬性程度。能报出目录、命名、覆盖范围的人，测试是真的在流程里；答「有空就跑跑」的人，测试只是装饰。后半句还埋了个质疑，要接得住。
🧭 答题框架
  1. 给硬线：核心逻辑单元测试不过，不得交付。这是交付前两道硬性检查之一，另一道是真实 AI 接口验证。
  2. 报覆盖范围：核心业务逻辑、API 接口、数据处理函数、边界条件都要覆盖。
  3. 报规范细节：测试文件统一放 tests/ 目录，命名 test_{模块名}.py，Python 项目用 pytest。调试用的临时脚本，用完自行删除，测试资产和调试垃圾分开管。
  4. 接住质疑：测试只是最后一道关，前面还有 PRD 确认拦理解偏差、修改计划拦范围扩散。多道关卡互为补充，单靠哪一道都不够。
⭐ 加分点补一句边界意识：测试拦的是实现层的回归。AI 对需求理解错了，测试照样全绿，所以断点要设在编码之前，这正是四步流程存在的理由。
用这些课程页组织答案 → 调试铁律：先 Log 再改码 四步流程：复述、PRD、确认、编码
Q20面试官
「你们的规则禁止 AI 提 MVP？做产品先跑 MVP 验证需求是基本功吧，这不反常识吗？」
🎯 对方在考察什么
概念辨析题，考你能不能分清人决定的拆分和 AI 自作主张的降级。把两者混为一谈的人，会把一条好规则用成教条，或者干脆不敢用。
🧭 答题框架
  1. 先划界：规则禁的是 AI 主动规划分期、MVP、阶段一二三，从来没有禁止人做 MVP 决策。拆分是人的决策，降级是 AI 的自作主张，两者的区别就是这条规则的核心。
  2. 给正确流程：功能确实复杂时，AI 的正确动作是给出完整方案、真实工作量和前置决策清单，要不要拆、怎么拆由人拍板。
  3. 举边界案例：一个功能真需要 2000 行代码，一次写完不现实。这时让 AI 报完整方案和工作量，人基于工作量决定拆成两个 PR。这是拆分，与降级无关。
  4. 补一条硬规矩：已知有缺陷的方案，直接给正确版本，别先做一个将就的。
⭐ 加分点用认证系统的例子收尾：AI 报出完整方案约 3 天、复杂度在 OAuth 回调与多端会话，再列 3 个前置决策（要不要手机号登录、供应商选几家、会话有效期多长），人几十秒就能拍板，完整版一次到位。
用这些课程页组织答案 → 不接受分期交付
Q21面试官
「你们规定 Agent 工具调用必须用 XML？现在大家都在用 JSON，这规矩是哪来的？」
🎯 对方在考察什么
考格式选型背后的工程理由。能讲出 escape hell 和 LLM 逐 token 生成的出错模式，说明你的理解到了生成机制层面，而且知道规则有适用边界。
🧭 答题框架
  1. 报三分法：Agent 工具调用用 XML，配置文件和数据存储用 YAML，对外 REST API 用 JSON。三种格式各管一个领域，互不混用。
  2. 讲 XML 的理由：JSON 字符串里再套 JSON 就是 escape hell，每层嵌套反斜杠翻一倍，LLM 逐 token 生成时极易配错括号和引号。XML 标签闭合直观，模型出错率更低。
  3. 讲另外两个：配置文件读写的主体是人，YAML 没有括号引号噪音、支持注释，「这个值为什么这么设」直接写在旁边；REST API 用 JSON 是行业标准，对外接口的原则是不折腾调用方。
  4. 说出例外：只用 GPT 系列的项目可以把工具调用改回 JSON，它的 function calling 原生就是 JSON。「Agent 用 XML」是多模型混用场景的最大公约数，Claude 系模型在 XML 上表现更稳。
⭐ 加分点顺手把 YAML 也排除出调用协议：它靠缩进表达层级，LLM 生成时缩进极易漂移，一格之差整棵结构就歪了。三种格式的落选理由都说得出，才是真懂三分法。
用这些课程页组织答案 → 把环境事实写进 Rule
Q22面试官
「你们的生图功能一上线就大面积超时，最后查出来是超时配置的问题。这种低级坑怎么防？」
🎯 对方在考察什么
考环境事实的管理方式。这类坑的特点是 AI 会反复踩：这次改对了，下个对话又用回默认值。考你知不知道用 Rule 一次性解决，而且能报出具体数字。
🧭 答题框架
  1. 说出坑的样子：图像 API 经常因为默认 30 秒超时失败，AI 还会反复尝试相同的错误配置，改一次好一次、忘一次错一次。
  2. 给数字：HTTP 客户端超时对图像生成至少设 120 到 180 秒，写进 Rule，每轮对话自动带入，一次解决。
  3. 报同族规则：网络请求失败必须先尝试代理重试（默认 127.0.0.1:7890），仍失败才向用户报告，禁止跳过代理直接报错；前端可见的所有大模型响应必须用 Streaming 返回，后端内部调用才允许非流式。
  4. 上升到机制：这些都是环境事实。写进 Rule 相当于给 AI 一份预填好的 .env 说明书，新开对话不用交代，它直接知道该调哪个模型、超时设多少。
⭐ 加分点给出验证方法：新开一个对话，不做任何交代，直接问 AI 项目的技术栈和模型配置。它答得出来，才算真写进了 Rule。这是课程里的课堂练习，做过的人答得毫不犹豫。
用这些课程页组织答案 → 把环境事实写进 Rule
Q23技术同事
「听说你们同时开好几个 SubAgent 改代码？两个 Agent 改同一个文件，后改的把先改的覆盖了怎么办？」
🎯 对方在考察什么
考多 Agent 并行的一致性意识。这是新出现的工程问题，答得出的人说明真的在用多 Agent 干活，答不出的说明并行对你只是个演示。
🧭 答题框架
  1. 给规则：多个 SubAgent 或多次编辑涉及同一文件时，后续修改必须先重新读取文件当前状态，禁止基于缓存或记忆中的旧内容编辑。
  2. 给类比：这就是多 Agent 时代的「乐观锁」。写之前先确认文件的最新状态，别人的改动才不会被无意覆盖。
  3. 配上目标一致性：并行期间用户可能改了目标。复述目标时以最新一次为准，并明确标注变更，避免新旧目标混在一起，两个 Agent 各干各的。
  4. 说明并行有正面用法：规则鼓励并行调研。修 bug 前的三问自查，就建议优先启动 SubAgent 并行调研影响范围，确认安全后再动手。
⭐ 加分点点破这两条规则的共同点：长对话和并行操作里，手上的信息都会过期。关键动作之前先刷新（重读文件、复述目标），比出事后排查便宜得多。
用这些课程页组织答案 → 长对话锚定与写作规范 调试铁律：先 Log 再改码
Q24面试官
「AI 建议你们把数据库从 SQLite 换成 PostgreSQL，理由列得头头是道。你换不换？」
🎯 对方在考察什么
考选型决策权的归属。顺着 AI 换的人，项目迟早陷进选型漂移。想听到的答案是「锁定」，以及锁定的具体做法。
🧭 答题框架
  1. 先给态度：不换。技术栈选型是人的决策，一旦定了就不再讨论替代方案，AI 的职责是在确定的栈内把代码写好。
  2. 说出漂移的样子：不加锁定，不同对话里 AI 会选不同框架，今天 Express 明天 Fastify，数据库一会儿 MongoDB 一会儿 PostgreSQL，项目在漂移中失去一致性。
  3. 报锁定内容：把选型写死进 Rule。课程里的例子是后端 FastAPI、前端 React + Tailwind + Vite、数据库 SQLite、向量库 Chroma。
  4. 补端口细节：端口避开 5000，从 8000 到 9000 随机分配，多项目同开也不冲突。能报出这条，说明 Rule 真读到了细节。
⭐ 加分点补上「怎么换才对」：真要换库，入口是人改 Rule 里的技术栈声明（适配四动作里的「换」），AI 再在新栈内干活。选型可以变，但变更入口在人手里，从来不在 AI 的建议里。
用这些课程页组织答案 → 把环境事实写进 Rule 为什么要给 AI 立规矩
Q25老板
「上个版本的事故我记着呢：发版时混进了一段没做完的代码。你说加了审查，具体怎么审？审出问题怎么办？」
🎯 对方在考察什么
老板要的是步骤级的流程细节。「我们会审查」这四个字他已经听腻了，要拆到每一步干什么、审出问题谁说了算。
🧭 答题框架
  1. 报流程三步：取完整 diff、逐文件比对、分类处理。让 SubAgent 独立分析实际 diff 和 Release Notes 的偏差。
  2. 说清审什么：Release Notes 写的是预期改动，实际 commit 可能混进无关调整甚至误删。课程案例：发版主题是夜间模式，diff 里却混着改写消息解析函数的改动和 axios 从 0.27.2 到 1.6.0 的依赖升级，这些没写进公告的就是风险。
  3. 给处置：审出风险就暂停发版，等待用户确认。确认之前，打 tag、push、部署全部禁止，AI 没有自行发版的权限。
  4. 补发布通道：发布必须走 GitHub，服务器通过 git pull 或 CI/CD 拉代码。紧急热修复可以例外，事后必须补 commit 同步。
⭐ 加分点用一句话概括审查的价值：把「我以为我改了什么」和「我实际改了什么」拆开比对，两者的差值就是事故的来源。老板听完这句就知道你想明白了。
用这些课程页组织答案 → 破坏性操作的三道闸
Q26面试官
「你跟 AI 聊了 30 轮，它突然把开头定好的数据库给换了。这种事你遇到过吗？怎么治？」
🎯 对方在考察什么
考长对话漂移的成因理解。答「多提醒它几次」是没入门；能讲出窗口截断机制和周期性锚点的人，才是长对话的真用户。
🧭 答题框架
  1. 先讲成因：上下文窗口截断加长文本尾部注意力衰减。第 1 轮说的「用 PostgreSQL」聊到 30 轮已经滑出窗口，AI 只是在它看得见的信息里做了一个「合理」推断，于是建议换 SQLite。
  2. 给规则：超过 10 轮之后，修改代码、修改配置、部署这些关键操作前，AI 必须先回顾并复述当前目标和关键约束。
  3. 给格式：复述有固定格式「📌 当前目标：XXX | 关键约束：YYY」，人扫一眼就能确认有没有跑偏。
  4. 补边界认知：即使是 200K token 的模型，注意力在长文本尾部的衰减也真实存在。锚定对长窗口模型同样必要，换大模型治不了这个病。
⭐ 加分点把两道防线连起来：选型漂移本身就是四类典型事故之一，技术栈锁定从对话外拦（Rule 每轮注入），锚定从对话内拦（周期性复述），双保险。
用这些课程页组织答案 → 长对话锚定与写作规范 为什么要给 AI 立规矩
Q27面试官
「你们的产品文案也让 AI 写？说实话，AI 味我一眼就能看出来，用户也能。你怎么保证写出来像人话？」
🎯 对方在考察什么
考你能不能把「自然流畅」这种主观要求工程化。答「我会多改几遍」的人没有方法；能报出违禁清单和自查流程的人，交付质量是稳定的。
🧭 答题框架
  1. 点破空话为什么没用：「请用自然流畅的中文」没有用，AI 认为的自然和你认为的自然可能完全不同。必须给出具体的违禁词和违禁句式列表，AI 才能精确执行。
  2. 举违禁模式：writing-style.mdc 的清单里包括全角破折号、全角省略号、「不是 A 而是 B」这类对比句式、网文式情绪词、评价他人的话、解读前置的铺垫、英文弯引号。
  3. 给自查流程：交付前逐条搜索违禁模式，发现一处改一处，完成后注明已完成自查。System Prompt 里的违禁句式同样要改。
  4. 给配置细节：写作规范独立成文件，frontmatter 设 alwaysApply: false，只在写文案或 Prompt 时手动引用，避免污染编码对话的上下文。
⭐ 加分点说出清单方法的本质：违禁模式是可搜索的，AI 可以逐条扫描自己刚写的稿子，主观品味就变成了机械检查。锚定对抗遗忘，清单对抗含糊，共同点都是把模糊期望变成可执行动作。
用这些课程页组织答案 → 长对话锚定与写作规范 为什么要给 AI 立规矩
Q28面试官
「你们界面第一版全是 emoji 按钮，是 AI 的手笔吧？设计品味这种东西，也能立成规矩吗？」
🎯 对方在考察什么
考品味能不能规则化。多数人以为规则只管流程和安全，能举出设计层的具体条款，说明你理解这套规则的覆盖面到了什么程度。
🧭 答题框架
  1. 给条款：禁止用 emoji 做按钮图标，图标必须用 SVG。
  2. 给选型方法：看产品调性选图标集，SaaS 用 Lucide，温暖调性用 Tabler Icons。
  3. 给工程细节：图标直接下载到本地使用，不依赖 CDN。
  4. 回答「能不能」：能。这类品味决策和 isComposing 一样，归在「文档与设计规范」章节。品味固化成规则后 AI 每次生成都遵守，免得每一版都要人肉挑一遍。
⭐ 加分点分清两层品味：Rule 管通用底线（禁 emoji、用 SVG），METHODOLOGY 的「用户体验偏好」管本项目的具体偏好，比如确认按钮固定放右下角、用品牌色。两层配合，品味才完整。
用这些课程页组织答案 → 把环境事实写进 Rule 三份文档与方法论沉淀
Q29面试官
「你说这套规范有 14 章。现在给你 60 秒，把它的骨架讲清楚。」
🎯 对方在考察什么
考全局观和提炼能力。背不出全景图的人多半只用过其中两三条；说得出板块划分和底层逻辑的人，才配讲方法论。
🧭 答题框架
  1. 报五大板块：流程控制（断点设在编码前）、质量底线（完整实现，不接受将就）、文档沉淀（决策跨对话留存）、环境与安全（环境事实一次写死）、沟通与写作（锚定与自查）。
  2. 各给一个代表条款：修改超过 3 个文件先列计划；禁止猜测性修复；三份文档各管一个维度；备份、回退、diff 审查三道闸；超过 10 轮复述目标。
  3. 收在共同底层：把模糊期望变成可执行的具体动作。「注意质量」执行不了，「删除代码前必须显式声明」才执行得了。14 章每一章都在做这个翻译。
⭐ 加分点能把章号对上就更狠：环境与安全一个板块就装了模型配置、数据格式、技术栈、部署四章。说得出结构里的具体章节，证明你读过规则原文，60 秒讲的是消化过的东西。
用这些课程页组织答案 → 规则的价值：每条解决一个真实问题
Q30面试官
「假设我们明天就把你这套规则原样搬进公司仓库，全员执行。你支持吗？」
🎯 对方在考察什么
收官陷阱题。答「支持」就掉坑了：这套规则带着作者项目的环境事实，照搬必翻车。考你有没有一套适配方法论，而且答案里要有取舍。
🧭 答题框架
  1. 先拦住：不建议原样搬。规则里写死了作者项目的技术栈、端口、格式选型，这些环境事实和你们公司对不上。照搬 14 章不如精选 5 章。
  2. 给四个动作：删（不做中文内容创作就把写作规范移出 .cursor/rules/，减少无关上下文）、换（技术栈声明换成公司的选型）、调（「修改超过 3 个文件先确认」的阈值按项目调，谨慎项目调成 1，快速原型放宽到 5）、补（把团队里 AI 反复犯的错写成新规则）。
  3. 给验证周期：在一个真实项目里用满一周，记录哪些规则被触发、哪些从没生效。删掉从没生效的，把新踩的坑写成新规则。
  4. 说清为什么：规则和代码一样，没人维护就会腐烂。搬进来只是开始，养起来才算用上。
⭐ 加分点把闭环补完：删换调补做完的版本可以开源出去，原仓库本身就是 MIT License，鼓励 Fork 改造后发布自己的版本。能说到这一步，说明你把规则当成了可以持续迭代的资产。
用这些课程页组织答案 → 规则的价值：每条解决一个真实问题 四步流程：复述、PRD、确认、编码
最后一个建议
这 30 题最好的准备方式是拿真项目练一遍：把 xs_vibe_rules 放进你的项目，跑两周，事故和规则都会变成你自己的故事。有故事的回答，和背框架的回答，对方一耳朵就能听出来。

「Vibe Coding 方法论 · 30 道灵魂拷问」为什么要看操作

「每题附考察意图、答题框架与加分点：为什么立规矩 / 质量责任 / 代码合入把关 / 拒绝分期 / 决策沉淀 / 安全闸门」把结构落到了一个具体动作。这里真正要比较的不是名词谁更高级，而是数据如何被放置，以及最常发生的操作需要走多远。

读懂结构，要同时看访问方式和变化方式

「每题附考察意图、答题框架与加分点：为什么立规矩 / 质量责任 / 代码合入把关 / 拒绝分期 / 决策沉淀 / 安全闸门」揭示了一个容易被忽略的取舍：按位置读取、按键查找、从两端进出、插入新元素和遍历关系，适合的组织方式并不相同。一个结构在某个操作上很快，不代表它在所有操作上都快。

  • 先说清 Vibe Coding 是什么： 靠自然语言让 AI 直接产出代码的开发方式。它的问题从来出在质量，写得快只是放大了搞砸的速度
  • 甩出四类典型事故： 理解偏差返工（改了 7 个文件才发现思路错了）、选型漂移（今天 Express 明天 Fastify）、善意破坏（重构时清理掉有用的代码）、永久技术债（简版登录再也没升级过）
  • 点破共同根源： 四类事故根源是同一件事，约束没有进入上下文。AI 每轮对话都可能忘掉你交代过的事

把规模和更新频率一起算进去

实践时可以把「每题附考察意图、答题框架与加分点：为什么立规矩 / 质量责任 / 代码合入把关 / 拒绝分期 / 决策沉淀 / 安全闸门」当作边界提醒：先写下数据量、最常用的操作和允许的延迟，再看 AI 给出的结构是否真的匹配。

从这个例子继续往下看

这篇内容先从「先说清 Vibe Coding 是什么： 靠自然语言让 AI 直接产出代码的开发方式。它的问题从来出在质量，写得快只是放大了搞砸的速度」展开，再把问题推进到「甩出四类典型事故： 理解偏差返工（改了 7 个文件才发现思路错了）、选型漂移（今天 Express 明天 Fastify）、善意破坏（重构时清理掉有用的代码）、永久技术债（简版登录再也没升级过）」。把这两个片段放在一起看，可以更清楚地分辨：哪些是文章给出的事实，哪些是需要结合条件才能成立的判断。

把这条判断带到下一个场景

遇到一个新的数据结构时，不要从定义开始背。先写出最频繁的操作，再估计数据量和更新方式，最后检查结构是否让这三个条件同时成立。

  • 「Vibe Coding 方法论 · 30 道灵魂拷问」：先说清 Vibe Coding 是什么： 靠自然语言让 AI 直接产出代码的开发方式。它的问题从来出在质量，写得快只是放大了搞砸的速度
  • 「继续往下看」：甩出四类典型事故： 理解偏差返工（改了 7 个文件才发现思路错了）、选型漂移（今天 Express 明天 Fastify）、善意破坏（重构时清理掉有用的代码）、永久技术债（简版登录再也没升级过）
  • 「最后的要点」：先接住责任： bug 永远算人的，AI 是工具。这套规范的目的就是让人在每个关键节点都有拍板的机会，出了问题能追溯到具体哪一关放过去的

最后的「最后的要点」把讨论落到「先接住责任： bug 永远算人的，AI 是工具。这套规范的目的就是让人在每个关键节点都有拍板的机会，出了问题能追溯到具体哪一关放过去的」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。

标记为已学完 阅读进度会自动记录
← 上一篇下一篇 →

继续阅读

同一条线上的下一篇。

你现在能做什么 · 实战沉淀你自己的协作规范四步流程对比演示；三档任务：写第一条 Rule、真需求走一遍流程、导出建造日志整理成规范 v1专题收官 · 收官规则的价值：每条解决一个真实问题全景图回顾 + 使用方法 + 适配自己项目的四个动作沟通与写作 · 交互长对话锚定与写作规范超过 10 轮强制复述目标；违禁句式清单让文案摆脱 AI 腔环境与安全 · 交互破坏性操作的三道闸数据库先备份、不可逆操作先给回退方案、发版前做 diff 审查

文章讨论

读到这里，留下一个判断。

把刚想明白的地方、还没想通的问题，留给下一位一起学习的人。

↗
正在讨论 Vibe Coding 方法论 · 30 道灵魂拷问 带护栏的 Vibe Coding
3条讨论文章讨论 · 与共学社区同步
在共学社区查看
AM
Asha Morgan内容编辑
观点实践记录

我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。

文章讨论7 有帮助
LH
Lin Harper独立开发者
观点观点

读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。

文章讨论5 有帮助
KM
Kiki Moore产品运营
问题问题

如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。

文章讨论4 有帮助