VibeCoding深水区--管理未知的艺术

公众号名称：低卧扑食

作者名称：泥巴猪

发布时间：2026-07-07 08:10

“我唯一所知的，就是我一无所知。” ——苏格拉底

从被grill-me折磨的那一刻开始

最近在进行vibe coding新项目的时候，基于SDD原则进行一些头脑风暴，聊完之后生成完一版spec方案文档丢给大模型后，做着做着，生成的东西又开始偏离我的预期了。

我开始认为主要问题出在模型能力，直接切到 opus4.8 和 gpt5.5 进行修正，但是发现每当研发流程越深化，他和我对齐的方案总是会越局限在一些细节中。令人绝望的是，这样繁复细节的讨论和纠偏显而易见地会持续整个开发流程，让我感觉变成了一个**“嵌入式”工程师**，有一种被绑架的感觉。

更可怕的是，对于他提出的一些问题，我从来没有听说过，**几十轮拷问下来，耐心耗尽不说，我也不知道自己的选择是否合理，是否是符合需求的选择。**X上也有开发者分享过被/grill-me 等访谈skill拷问了几十轮的崩溃分享。

所以我开始思考，为什么在这个类似黑盒的上下文空间中，人与 AI 的设计行为开始类似盲人摸象。

我摸到一条腿，以为自己要的是一根柱子；AI 摸到一只耳朵，以为你要的是一把扇子。两边都没错，但两边都没有看到完整的大象。

AI 不是故意做错。

更准确地说，AI 像一个很聪明的实习生。它学习能力强，执行速度快，还特别愿意干活。问题是，**在需求没有被澄清之前，再聪明的实习生也只能根据自己见过的案例补全上下文。**但是，怎么样才算完成澄清呢？

所以，vibe coding 的失败不总是模型能力失败。更多时候，是我们把一个还没想清楚的问题交给 AI，然后希望 AI 直接给出正确实现。

这对 AI 也不公平。

因为我们没有把大象讲清楚，却要求它画出完整的大象。

后来我逐渐意识到，vibe coding 的核心不是“我怎么把需求说给 AI 听”，而是“我怎么让 AI 帮我发现我还没想清楚的东西”。

也就是：管理未知。

Claude的一种新工程方法论

Claude 产品经理 Thariq 最近写了一篇文章：A Field Guide to Fable: Finding Your Unknowns：https://x.com/trq212/status/2073100352921215386?s=20

这篇文章对我最大的启发，不是某个具体技巧，而是一个更底层的判断：

人和 AI 协作时，失败往往不是因为 AI 没有执行能力，而是因为任务里存在太多没有被显性化的未知。

这些未知有的在用户脑子里，有的在代码库里，有的在实现过程中才会暴露，有的只有看到结果后才知道“不对”。

如果这些未知没有被识别，AI 不会停下来等人想清楚。AI 会继续补全，并用默认经验替用户做决定。

地图不是领土

我们给 AI 的 prompt、上下文、文档和 skill，是地图。

但真正的领土，是代码库里的历史包袱、业务里的真实约束、用户心里的判断标准、团队过去形成的潜规则。

AI 不是在你的脑子里工作。

AI 只是在一张不完整的地图上，尽量猜测领土长什么样。

当地图上缺了一块，AI 不会停在那里。AI 会继续走。AI 会用通用最佳实践、训练语料里的常见模式、框架默认写法，替你补上那块空白。

这就是很多 AI 编程结果**“不算错，但就是不对”**的原因。

四类未知

把 Thariq 文章里的 unknowns 思路放到 vibe coding 语境里，可以拆成四类：

未知类型	在 vibe coding 中的表现	典型风险
已知已知	我明确告诉 AI 的需求、约束、技术栈、代码位置	AI 基本可以执行
已知未知	我知道自己没想清楚，比如选型、架构、交互方式	需要分析、对比、访谈
未知已知	我心里有标准，但没有写出来；看到结果才知道不对	AI 做出来“差一点味道”
未知未知	我根本不知道自己缺哪些知识、风险、边界	AI 会基于默认经验一路做下去

普通用户只会把**“已知已知”**告诉 AI。

更成熟的用户，会让 AI 帮自己挖**“未知已知”和“未知未知”**。

未知不是开工前一次性解决的

很多人以为，只要开工前把需求讲清楚，后面就可以一路实现。但真实情况不是这样。

实现前，你会遇到盲点：不知道自己该问什么。

实现中，你会遇到偏差：代码库和计划不一致。

实现后，你会遇到验收困难：AI 改了很多东西，但你不知道自己是否真的理解了它。

所以 vibe coding 不是“想法 → prompt → 代码”的直线。

它更像**“想法 → 发现未知 → 收敛方案 → 授权实现 → 记录偏差 → 验收理解”的循环**。

它不是自然语言编程。

它是人与 AI 共同管理未知的过程。

整个理清未知的过程，更像是无法穷尽的微积分过程。

Vibe Coding 的 7 类未知场景

针对 Thariq 这篇文章的理解，我整理了我个人遇到的 Vibe Coding 的 8 类未知场景。

这些场景不是严格学术分类，而是我在真实使用 Claude Code、Codex、Opencode 这类工具时反复踩到的坑。

场景一：定义未知——我说的是需求，还是产品冲动？

这是最早出现的一类未知。

你有一个想法，但还没有定义清楚它到底是什么。

比如“每天早上自动告诉我今天重点事项的小工具”。它可能是待办摘要，也可能是优先级判断器，还可能是一个主动推送的项目跟进工作流。

这里还有一个更隐蔽的问题：你说出来的 feature request，可能不是需求本身，而是过早解法。

比如“AI 周报工具”听起来是需求，但真实问题可能是“项目风险发现太晚”。如果真实问题是后者，直接生成周报功能就会跑偏。

常见错误：直接对 AI 说“帮我实现一下”。

AI 会立刻把模糊想法翻译成功能清单，但不会自动判断这个想法是否成立。

正确角色：盲点扫描器、产品访谈官、framing challenger。

推荐工具：可以借鉴 Thariq 文章里的 Blind Spot Pass，以及 gstack /office-hours 的思路：先挑战 framing，再谈实现。

可复制提示词：

请扮演「产品访谈官 + 盲点扫描器」。

当前主 Unknown：定义未知阶段目标：判断我说的是需求、症状、产品冲动，还是过早解法。当前想法：{你的想法}

请输出：

这个想法可能对应的 2-3 种不同定义；
当前 framing 可能错在哪里；
背后的真实痛点可能是什么；
哪些问题会改变后续实现方向；
第一阶段最应该验证什么。

场景二：路径未知——方向有了，但不知道第一步怎么走

有些时候，问题不是方向错了，而是不知道从哪里切。

先做 demo 还是 PRD？

第一阶段要砍掉什么？

MVP 到底验证什么？

这类问题的本质是路径未知。你不是缺目标，而是缺一个能降低风险的第一步。

常见错误：让 AI 给“大而全方案”。

这种方案通常很好看：模块齐全、架构完整、阶段清晰。但第二天打开编辑器，还是不知道从哪里开始。

正确角色：MVP 裁剪者、方案拆解者、设计伙伴。

推荐工具：可以借鉴 obra/superpowers /brainstorming：先探索上下文、提出多个方案、写 spec，再进入 implementation plan。

可复制提示词：

请扮演「MVP 裁剪者」。

当前主 Unknown：路径未知阶段目标：从多个可能路径中选出第一阶段切口。当前想法：{你的想法}

请输出：

2-3 个第一阶段切口；
每个切口要验证的假设；
每个切口明确不做什么；
成本、风险和学习价值；
你的推荐路径和理由。

场景三：标准未知——我知道不对，但说不清什么叫好

这是 vibe coding 里最容易折磨人的一类未知。

你知道大致要做什么，但不知道什么样叫好。

你会说：

“要高级，但不能浮夸。”“要专业，但不要模板化。”

或者你看到 AI 结果之后，只能说：

“不是这个感觉。”“有点接近，但还差点味道。”

这不是你没有判断。

这是你还没有把判断翻译成可执行约束。

常见错误：继续用抽象形容词反复让 AI 改。

“高级一点”“简洁一点”“更有质感”，这些词本身没有错，但它们不足以指导下一次生成。AI 会在语义空间里随机游走，一会儿改颜色，一会儿改排版，一会儿改语气。

正确角色：方向对比设计师、偏好翻译官、taste memory。

推荐工具：可以借鉴 obra/superpowers /brainstorming 的 visual companion 思路，也可以借鉴 gstack /learn 把偏好沉淀为可复用约束。

可复制提示词：

请扮演「偏好翻译官 + 方向对比设计师」。

当前主 Unknown：标准未知阶段目标：把“我觉得不对”翻译成可执行质量约束。当前任务或反馈：{你的任务 / 你的反馈}

请输出：

我的反馈可能指向哪些具体问题；
3-4 个差异明显的方向；
每个方向追求什么、不追求什么；
我应该如何判断哪个方向更接近；
下一轮可复用的质量约束和修改提示词。

场景四：决策未知——哪些问题真的会改变架构？

当方向和路径大致确定之后，最容易出现的是决策未知。

要不要多用户？

数据是否需要历史版本？

状态是单状态还是状态机？

这些问题一旦答错，后面会导致架构返工。

但反过来，不是所有问题都值得问人。

字段名、文案、空状态、日志格式、普通异常、UI 细节，如果每一个都让人确认，用户会被拖进 AI 的审批流。

常见错误：让 AI 问所有问题。

这看起来严谨，实际很低效。人的注意力应该用来回答承重问题，而不是替 AI 做每一个微决策。

正确角色：架构访谈官、决策树整理者、assumption manager。

推荐工具：可以借鉴 gstack /plan-eng-review：锁定架构、数据流、边界情况和测试，并暴露隐藏假设。

可复制提示词：

请扮演「架构访谈官」。

当前主 Unknown：决策未知阶段目标：只识别会改变架构、数据模型、用户流程或返工成本的承重问题。当前方案：{你的方案}

请输出：

需要我回答的 load-bearing questions；
每个问题为什么值得问；
不值得问我的低风险细节；
你会如何做保守假设；
decision log 草案。

场景五：风险未知——方案看起来合理，但没人唱反调

有时候，你已经有了计划，但不知道它哪里会失败。

有没有隐藏假设？

哪些地方后面会炸？

哪些验收标准不充分？

这个阶段最怕问 AI：

帮我看看这个方案是否合理。

AI 很可能会给你一堆温和肯定。

“整体方向合理。”“建议注意边界情况。”

“后续可以持续优化。”

这些话不能说错，但没有价值。

你需要的不是鼓励，而是反方。

常见错误：让 AI 做礼貌评审。

礼貌评审无法提前暴露失败路径。

正确角色：严厉评审、pre-mortem 主持人、质询者。

推荐工具：可以借鉴 mattpocock/skills /grill-me / /grilling：围绕计划持续追问，一次只问一个问题；如果能通过代码库探索回答，就不要问用户。

可复制提示词：

请扮演「严厉评审」。

当前主 Unknown：计划风险阶段目标：在实现前压测计划，暴露隐藏假设。当前计划：{你的计划}

请输出：

最可能导致失败的 5 个假设；
每个假设的失败后果；
最值得先追问我的一个问题；
哪些问题可以通过代码库探索回答；
计划通过评审的关闭条件。

场景六：现状未知——想改代码，但不认识代码库地形

很多 AI 编程翻车，不是因为需求错了，而是因为现状不清楚。

你想改一个功能，但不知道当前模块边界是什么。

调用链在哪里？哪些是历史包袱？

哪些文件不能轻易动？哪些地方耦合严重？

这类问题不是需求未知，而是代码库地形未知。

常见错误：让 AI 直接改局部文件。

AI 可能基于局部上下文做出局部正确、全局错误的修改。

正确角色：代码库导游、架构摩擦扫描器、系统地图绘制者。

推荐工具：可以借鉴 mattpocock/skills improve-codebase-architecture：分析代码库架构摩擦，寻找更清晰的接口边界和可测试 seam。

可复制提示词：

请扮演「代码库导游」。

当前主 Unknown：现状未知阶段目标：先理解系统地形，不要直接改代码。目标区域：{模块 / 目录 / 需求}

请输出：

核心模块和调用链；
当前接口边界是否清晰；
哪些地方耦合严重；
最小、安全的修改路径。

场景七：验收未知——AI 说完成了，但我不知道能不能信

AI 说完成了，不代表任务完成。

CI 通过了，也不代表任务完成。

你仍然需要知道：

是否真的解决目标？

有没有隐藏 bug？

哪些路径没覆盖？

哪些行为变化你没意识到？

常见错误：只看 diff 或只跑 CI。

CI 检查的是一部分事实，不检查你是否理解了这次变更。

正确角色：QA、代码变更讲解员、考官、验收官。

推荐工具：可以借鉴 gstack /review / /qa：/review 关注 CI 通过但生产可能出问题的 bug，/qa 关注测试、发现问题、修复并重新验证。

可复制提示词：

请扮演「验收官」。

当前主 Unknown：验收未知阶段目标：不要只总结 diff，帮我判断这次变更是否真的可验收。当前变更：{diff / PR / 变更说明}

请输出：

这次变更声称解决什么问题；
实际覆盖了哪些路径；
哪些路径没有覆盖；
哪些风险 CI 查不出来；
10 条验收用例；
用 quiz 确认我是否理解这次变更。

七类未知总结表

分类	典型状态	应该让 AI 做什么	推荐措施/工具
定义未知	有想法，但需求和问题没定义清楚	挑战框架，挖真实痛点	Blind Spot Pass / `/office-hours`
路径未知	方向成立，但不知道第一步	拆切口，定 MVP	`/brainstorming`
标准未知	知道不对，但说不清什么叫好	用方向对比显化偏好	visual companion / `/learn`
决策未知	不知道哪些问题会改架构	只问承重问题	`/plan-eng-review`
风险未知	有方案，但没人唱反调	压测假设，做事前验尸	`/grill-me`
现状未知	想改代码，但不认识代码库地形	先扫系统地图	`improve-codebase-architecture`
验收未知	AI 说完成，但人无法判断	生成验收报告和测试用例	`/review` / `/qa`

我们到底该不该给 AI 这么多约束？

到这里，一个自然的问题会出现：

如果我们给 AI 这么多流程、约束、问题和门禁，会不会反而限制它的创造力？

我的判断是：会，但这不是问题本身。

问题不在于约束多不多，而在于约束有没有用在承重点上。

约束太少，AI 会用默认世界观替你做决定

AI 会用通用默认值补全你的空白：

通用最佳实践；
框架默认写法；
常见产品模板；
训练语料里的平均答案；
它对“正常需求”的想象。

约束的价值，是防止 AI 把你的问题平均化。

约束太多，AI 会被降级成自然语言编译器

如果你把所有细节都规定死，AI 原本能提供的价值会消失：

它不能挑战你的 framing；
不能发现更小切口；
不能指出你在做伪需求；
不能提供跨领域类比；
不能告诉你“这个方向不值得做”。

AI 最大的价值，不是替你更快执行你已经知道的答案，而是把你不知道自己不知道的东西提前暴露出来。

讨论太多，会陷入“确认所有分支”的幻觉

当人学会“让 AI 多问问题”之后，也可能陷入另一种低效：

每个字段都问；
每个异常都问；
每个交互都问；
每个技术细节都要确认。

你请 AI 来帮忙，不是为了把自己变成 AI 的审批流。

真正的边界是只解决承重未知

不是所有未知都应该问人，真正需要投入主要精力解决的应该是承重类未知。

值得问人的，是那些会改变方向、架构、数据模型、用户体验、风险边界和验收标准的问题。

值得问人的问题通常满足至少一条：

答案会改变产品定位；
答案会改变架构；
答案会改变数据模型；
答案会改变权限 / 安全边界；
答案会改变用户主路径；
答案会改变验收标准；
答案涉及人的 taste；
答案错误会导致大返工。

不值得频繁问人的问题也很明确：

命名细节；
常规错误处理；
普通日志；
可以从代码库模式推断的问题；
可以通过测试验证的问题；
不影响架构的 UI 微调。

凡是能用代码库探索、原型验证、测试反馈解决的问题，就不要用人类耐心来解决。

把未知管理沉淀成skill

写到这里，问题就变成了：这些判断能不能沉淀成一个可复用的工作流？

一个 skill应运而生，叫 ni-unknown-first：https://github.com/ttttstc/ni-skill/tree/main/skills/ni-unknown-first。

它要解决的不是“怎么写一个更强的包含所有场景的挖掘/访谈类skill”。因为很多人手里已经有很多访谈类skill，但是收集的skill 越多，反而越不清楚当前阶段应该用哪个。真正困难的不是**“有没有工具”，而是“我现在该用哪个工具”**。

它要解决的是另一个关键问题：

当下，此刻，AI 对我的需求了解到了什么程度，我最需要解决的承重未知是什么？

它解决的问题：先分诊，再行动

ni-unknown-first 它不会替代下游工作。只是在触发时刻开始一次冷静的审视，把**“直接开工下一步”改成“先分诊”**。

这很像医院分诊台。

分诊台不负责治疗，但分诊台决定你别一上来就找错科室。

它不保证 AI 一次做对。

但它能让 AI 更少在错误的阶段，扮演错误的角色。

它生效的逻辑：把“下一步”从默认实现改成角色路由

普通 AI 协作里，用户说完需求，AI 的默认动作通常是实现。

ni-unknown-first 改掉了这个默认动作。

它会先问三个问题：

当前未知属于哪一类？哪一个 unknown 最阻塞下一步？应该让 AI 扮演什么角色来关闭这个 unknown？

这三个问题，会把 AI 从**“默认程序员”切换成更合适的角色**。

有时是产品访谈官。

有时是架构访谈官。

有时是严厉评审。

有时是代码库导游。

有时是验收官。

这就是它的核心价值：不是让 AI 更会写代码，而是让 AI 在正确阶段做正确的事。

它带来的收益：减少返工，减少无效确认，减少平均答案

我认为 ni-unknown-first 至少能带来四个收益。

第一，减少方向性返工。

伪需求没有识别出来之前，不急着写方案。代码库地形不清楚之前，不急着改文件。验收标准不明确之前，不急着说完成。

第二，减少无效确认。

它强调关键承重问题。承重问题问人，非承重问题让 AI 基于代码库、惯例、测试和保守假设处理。

第三，减少 AI 的平均答案。

很多 AI 输出“不算错，但很普通”，原因是人的隐性标准没有显性化。ni-unknown-first 会把质量未知、表达未知路由到偏好显化，而不是让 AI 继续猜。

第四，让协作过程可复盘。

每一次诊断都会留下：当前主 unknown、推荐角色、停止条件、保留 unknown。对个人来说，这是工作流；对团队来说，这是协作协议。

结语：工程师的新能力不是写代码，而是管理未知

AI 时代，工程师不会因为 AI 会写代码而失去价值。但工程师的价值会迁移。

过去我们靠写代码证明自己理解问题。现在，我们要先利用强大的探索未知的能力，想清楚自己究竟要什么

毕竟，在铺天盖地的SDD工程化落地大潮中，最关键的十字路口不是做了多少决策，而是结果迫使我承认：很多时候，我并没有自己想象得那么清楚。在充满未知的决策旅程中，最缺少一个在关键时刻能反问自己的人。

内容效果不满意？点此反馈