你有没有经历过这样的场景：
打开 AI 编程助手，随口描述了一个需求——界面瞬间成形，CRUD 自动生成，一切行云流水。你心想：这就是未来。
30 分钟后，你开始频繁说”不对，改一下布局””这个逻辑有问题，重新生成”。改动越积越多，代码开始散发出一股微妙的不一致感。
2 小时后，你隐约觉得哪里不对——刚才修好的功能，怎么又坏了？改了这个文件，另一个文件又报错了。AI 产出的内容开始前后矛盾，甚至完全跑不起来。
5 小时后，你盯着那个曾经轻巧、如今臃肿的代码库，脑海中只剩一个念头：不如推倒重来。
这就是 Vibe Coding（氛围编程）最真实的体验曲线——从惊艳到崩溃，往往只需要一个下午。
问题出在哪？真的是 AI 不够强吗？
问题不在 AI，而在于”氛围”
“Vibe Coding”这个词，最早由 Andrej Karpathy 提出。它的本意是：你沉浸在编程的心流里，完全信任 AI，让它替你完成实现细节。
听起来很美。但实践起来，大多数人都会卡在同一个坑里——
AI 没有”大局观”。
你每次和 AI 对话，它的全部记忆就只有当前这个对话窗口。它不知道你三天前做了什么决策，不知道这个模块为什么被设计成这样，更不知道你和团队约定了一套什么规范。
你给一句提示，它产出一段代码。你再给一句，它再产出一段。每一次交付看起来都没问题，但拼在一起，就像五个不同的建筑师各自设计了一层楼——每层单独看都还行，组合起来就变成了危房。
更扎心的是：AI 是极度擅长局部优化但缺乏全局视角的超级执行者。它能写代码，却不能真正理解业务上下文；它能快速迭代，却无法判断哪种结构更适合长期演进。当你跳过必要的设计思考，直接让 AI 全权承担实现乃至架构决策时，本质上是在将系统构建的主导权交给一个”不知道自己在建什么”的施工队。
这不是 AI 的错，是上下文失控了。
理解你的对手：LLM 的工作方式
要真正驾驭 Vibe Coding，你得先理解那个”坐在对面的搭档”到底是怎么运转的。很多问题的根源，不是 AI 不够强，而是我们对它的工作方式存在根本性的误解。
1. 它没有独立于输出的”思考”过程
大语言模型的工作方式可以用一句话概括：预测下一个 token。
当你向 LLM 提问时，它并不是先在”脑中”构思好完整答案再输出。相反，它每次只做一件事：基于当前看到的所有文本（你的输入 + 它已经生成的内容），预测最可能的下一个词是什么。然后把这个词加入序列，再预测下一个，如此循环直到生成结束。这种方式被称为自回归生成（Autoregressive Generation）。
理解这一点至关重要。人类工程师写代码，先想后写——心里盘算清楚架构、边界条件、异常路径，最后才落键盘。LLM 不是这样。它的推理就是生成本身。 它不能先在脑子里演算一遍，只能说一句想一句。
这就是为什么让模型”一步步思考”（Chain-of-Thought）会提升效果——你实际上是在给它更多的”思考空间”，让它通过生成中间步骤来辅助推理。如果你不帮它”先想好”，它就只能边走边猜。
自回归机制在 Coding 场景下还会被进一步放大：
- 局部最优陷阱：AI 一步一步”续写”，不等于全局规划。它容易先写得很顺，然后在后面发现不对再补丁式修补，历史债务快速累积。
- 偏差滚雪球：一旦 AI 早期误读了需求或代码库的约束，后面每一步都会在错误的世界观里自洽。它生成了一个不存在的函数名，后续会越来越”相信它存在”，直到编译时报错才打脸。
- 不擅长精确编辑：AI 擅长写新文件、新段落，但相对不擅长在复杂代码中做精确、最小化的局部修改。它倾向于”重写一遍”而非”精准修改”，导致 diff 过大、review 成本极高。
2. 上下文就是它的全部记忆
LLM 没有硬盘，没有数据库，没有”我在这个项目上积累了三周的经验”这回事。它对当前对话的全部理解，完全来自你塞进上下文窗口的那些内容。
上下文之外的东西，对它来说就是不存在。你在另一个会话里和它讨论过的设计决策，在新会话里它一无所知——这被称为**”会话间失忆”**，是 Coding Agent 最根本性的问题之一。就像电影《初恋 50 次》中的主角一样，Agent 每次醒来都不记得昨天发生了什么。
更隐蔽的问题是：即使在同一场对话中，一旦超出窗口限制，最前面的内容就会被默默遗忘——而它不会告诉你”我忘了”，它只会基于残存的信息继续生成，像什么都没发生一样。
Attention：LLM 如何”阅读”上下文
在预测下一个 token 时，模型通过 Attention（注意力）机制从上下文中提取相关信息。
你可以把 Attention 想象成一个动态的”聚光灯”：当模型生成每个新 token 时，它会扫视整个上下文，对不同位置的内容分配不同的”注意力权重”。权重高的部分对当前生成产生更大影响，权重低的部分则几乎被忽略。
重要的是：注意力是稀疏的。 模型不会均匀地关注所有内容，注意力权重往往集中在少数关键位置，大部分位置的权重接近于零。
这引出了一个关键认知：有效上下文远小于标称上下文。
上下文窗口：被高估的能力
每个模型都有最大 token 限制，目前主流模型通常在 128K 到 200K 之间。但模型宣称支持 200K tokens，不意味着在 200K 长度下都能保持良好表现。
问题出在 Attention 的”稀疏性”上：当上下文很长时，注意力权重需要分散到更多位置。如果关键信息只是海量内容中的一小部分，它获得的注意力权重可能会被稀释到难以有效利用的程度。实际上，一个支持 200K 的模型，可能在超过 80K 或 100K 之后，就开始出现明显的性能退化。
更令人警惕的是研究发现上下文窗口的中间 40%-60% 区域存在一个**”Dumb Zone”**——在这个区域，模型的召回率下降，推理能力变差。当 Agent 深入工作时，它会逐渐表现出类似”痴呆”的症状：迷失方向、产生幻觉接口、忘记原始目标。这不是因为模型变笨了，而是因为关键信息被淹没在大量的上下文中，无法被有效利用。
正是因为上下文窗口有限且不均匀，所以你必须刻意管理它。
3. 生成具有概率性
同样的提示词，问两次，可能得到两个不同的回答。有时候差异很小，有时候天差地别。
这不是 bug，这是概率模型的天然属性。每一步预测都是基于概率分布采样，这意味着：结果的一致性不能靠”赌”，必须靠机制来保障。 你需要用结构化的约束来引导模型的概率分布朝你期望的方向收敛。
解法：上下文治理
理解了 LLM 的这三个本质特征——无独立于输出的思考、上下文即全部记忆、生成的概率性——Vibe Coding 的核心原则就呼之欲出了：
不是让 AI 更聪明，而是让你的上下文更清晰。
这套方法论的核心是 上下文治理（Context Governance）——在每一次和 AI 协作时，主动管理好它”能看到什么”和”应该怎么做”。它包含三个关键环节：Plan、Spec、Workflow。
Plan：先想清楚再动手
在写第一行代码之前，先把需求拆清楚。这一步是给 AI 提供一个稳定的”航向”。
你不需要写几十页的 PRD，但至少要明确：
- 这个功能的目标是什么（不是”要做什么”，而是”为什么做”）
- 输入和输出是什么
- 边界条件在哪（什么不该做）
- 和现有系统的交互点有哪些
MVP 的边界艺术
Plan 阶段最重要的技巧，是给需求画一道清晰的边界——MVP（最小可行性产品）的边界。
很多人在这个阶段会犯一个致命错误：因为 AI 写代码太快，所以想让它顺便把所有功能一次性写完。在 Vibe Coding 的世界里，这种”顺便”往往是灾难的开始。原因很简单：
第一，上下文熵增。 当项目规模瞬间膨胀，AI 需要处理的逻辑关联会呈指数级增长。一旦超过临界点，AI 就会开始”幻觉”，原本稳固的底层逻辑会因为照顾那些琐碎的边角功能而崩塌。
第二，调试深渊。 一次性生成的代码越多，隐藏的逻辑空洞就越多。当你在 MVP 阶段就引入了复杂功能，一旦报错，你很难分清是核心逻辑出了问题，还是那些附加功能干扰了状态机。
第三，反馈回路断裂。 Vibe Coding 的精髓在于”快速生成——即时反馈”。一次性写完意味着你失去了在中途纠偏的机会。
如何画这道边界？三条路径：
- 守住核心动作路径：MVP 的边界必须且仅能包围一条灵魂路径。如果是做一个 IM，那就是”登录 → 找到那个人 → 说出那句话”。不要在这个阶段引入验证码、第三方登录、表情包、朋友圈。
- 只做”撑起房顶”的骨架功能：这些功能不一定”好看”，但一定要”硬”。核心通信链路、数据持久化、最基础的 UI。别让 CSS 的圆角和渐变分散了 AI 面对核心逻辑时的注意力。
- 建立”负面清单”：这一步最难，但也最显功力。明确列出这个版本绝对不做的功能。
花 5 分钟先做 Plan，省的是后面 2 小时的重构成本。
Spec：用结构化文档替代口头描述
自然语言的致命缺陷是模糊。
“把登录做好”——什么叫”做好”？是防 SQL 注入？是加验证码？是支持第三方登录？还是响应时间低于 200ms？人类可以通过上下文、默契和后续沟通来逐渐对齐，但 AI 不行。你每一次模糊的表述，都是在让 AI”猜”。而猜的结果，往往会回到最通用、最安全、最不容易被质疑的默认方案——却未必是你真正需要的。
Spec（规范文档）的本质，是用结构化的方式消除歧义。它不等同于传统软件工程里的重量级设计文档，而更接近：给 AI 的一份”施工图纸”。
统一语言：消除”歧义税”
Spec 的核心价值之一，是建立一套统一语言（Ubiquitous Language）。
想象这个场景：第一天，你对 AI 说”帮我创建一个聊天功能”。AI 生成了一个名为 chats 的数据表。第二天，你提出要做群聊，AI 创建了一个 groups 表。第三天，你说”获取用户的所有会话”，AI 试图去找一个名为 conversations 的表——结果自然是找不到。
这就是**”歧义税”（Ambiguity Tax）**：你为早期沟通的模糊不清，在后期付出了大量的重构、调试和人工解释的成本。在 Spec 中，你通过强制性的定义来消除这种歧义——明确规定：在这个项目中，所有用于承载消息的单元，统一的名称就是 Conversation。从此，无论是在 PRD、API 设计、数据库表命名，还是与 AI 的每一次对话中，这个词都代表且只代表这一个业务含义。
一份合格的 Spec 通常包含：
- 领域模型：核心实体是什么（User、Message、Conversation），它们的属性和生命周期是什么，它们之间的关系是什么
- 数据模型：从领域模型到数据库表结构的映射，主键、索引、外键约束
- 接口定义：输入参数、返回值、异常情况、状态流转
- 约束条件：性能要求、安全要求、兼容性要求
当 AI 拿到一份清晰的 Spec，就不再需要猜测”你到底想要什么”。它知道实体之间的边界在哪，知道 Message 不是一个简单的字符串，而是一个包含 sender、conversation、status、sentAt 等完整属性的领域对象——它自然会生成带权限校验、状态管理的代码，而不是一个干瘪的 db.saveMessage(content)。
Workflow：给 AI 的行为加上护栏
Plan 和 Spec 解决了”做什么”的问题。Workflow 解决的是”怎么做”。
前文说过，LLM 没有独立于输出的思考过程，生成具有概率性。但你可以通过 Workflow，人为地给它注入一个”思考结构”，用工程手段约束它的输出分布。
Rules：你颁布给 AI 的”代码契约”
Workflow 最核心的载体是 Rules——它们是写在项目配置文件中、自动注入到每一次对话的约束指令。
如果你的项目只是随手写个 Demo，Rules 也许可有可无。但如果你在认真构建一个需要长期维护的系统，没有 Rules 的 AI 会犯下让架构师血压升高的”原则性错误”：
- 架构越级：在一个标准的分层项目里，你辛苦定下的”逻辑层与 UI 分离”原则，AI 可能会为了图省事，直接在页面组件里写复杂的业务逻辑
- 重复造轮子：你已经写好了完美的数据请求工具类，但 AI 可能又用原生的方式写了一套新的逻辑，完全无视你已有的工程资产
- 语义漂移：你在 Spec 中定义了严谨的
MessageStatus枚举（发送中、已发送、已送达、已读），但 AI 生成代码时可能随手写成字符串 “pending”，导致整个系统的状态流转直接崩溃
这些是传统的 Linter 无法拦截的——从语法上看，它们都是”正确”的；但在你的工程世界里，它们是”违法”的。
Rules 就是为此而生：
- 强制复用：”所有 HTTP 请求必须通过
@/lib/http模块，禁止使用原生 fetch” - 模式约束：”所有即时通讯逻辑必须封装在自定义 Hook 中，禁止在组件内直接操作 WebSocket”
- 改动边界：”本次只处理好友申请相关的接口逻辑，不涉及消息系统、鉴权流程、数据库表结构调整，也不做代码风格重构”
- 明确禁止”顺手优化”：”除非明确提出，否则不要进行任何结构调整、命名优化或重构行为，仅限最小必要修改以修复当前问题”
小步快跑：以对话为单位组织工作
Workflow 的另一条铁律是短对话优于长对话。
很多人认为更大的上下文窗口意味着更强的能力，可以把更多任务塞进一个对话里。但实际情况恰恰相反。对话越长，上下文窗口里就会积累越多与当前任务不太相关的内容，Agent 的表现会逐渐退化——它会开始犯错、跌跌撞撞，甚至进入死循环。
这不是 Agent “变笨了”，而是关键信息被稀释了。
正确的做法是：把一个功能拆成一组相互关联的短对话。 比如实现一个用户登录后的会话管理功能，可以拆为：
- 对话 1：调研现有代码结构，了解 auth 模块和 session 管理的现状
- 对话 2：实现核心的 session 保存逻辑
- 对话 3：添加错误处理和边界情况
- 对话 4：编写测试
- 对话 5：代码审查和清理
每个对话都很短，只专注于一件事。它们加在一起完成了整个功能的开发。对话之间通过引用之前对话的结论、利用 Git 状态、读取项目文档来传递上下文。
把”开始新对话”视为正常工作流程的一部分，而不是”失败后的重试”。
底层原则：让 AI 越用越好用的四个心法
Plan-Spec-Workflow 是上下文治理的三根支柱。但真正让这套方法论产生复利效应的，是下面四个底层原则。
心法一：复利工程——你不只是在解决问题，而是在教育系统
传统的 AI 编程关注的是短期收益：你给 prompt，它写代码，发布，然后从头开始。但还有一种更高维度的用法——Compounding Engineering（复利工程）——关注的是构建具有记忆的系统。
核心理念很简单：每次修复 bug 时，如果不能防止同类问题再次发生，就只完成了一半。每次代码审查如果不能提取出可复用的教训，就是浪费时间。每次成功的工作流程如果不能被记录和复用，就会随着会话结束而消失。
具体实践：
- 将经验沉淀到项目文档：每当你发现一个重复出现的问题或一个有效的解决方案，就把它加入项目配置文件。Agent 在每次对话开始时都会读取它，自动应用这些经验。
- 让 bug 修复产生长期价值：修复一个 bug 之后，问自己——这类问题能否通过添加 lint 规则来预防？是否应该在配置文件中记录这个陷阱？能否编写一个测试来防止回归？
- 从代码审查中提取模式：每次你在审查中指出问题，想一想——这个反馈是否适用于未来的类似代码？是否应该成为项目的编码规范？
- 建立可复用的工作流程：当你找到一个有效的工作模式，把它写下来。下次你或 Agent 需要做类似任务时，可以直接说”按照之前的那个工作流程来做”。
复利工程的效果是累积的。第一周，你可能只记录了几条编码规范。第一个月，你有了一套完整的项目知识库。三个月后，Agent 开始自动应用你从未明确告诉它的模式。
心法二：对人难的事，对 AI 也难
有一个简单但常被忽视的事实：如果一个任务对人类开发者来说很难，那么它对当前的 AI 来说大概率也很难。
这听起来显而易见，但它的推论却很深远：所有那些能提升人类开发者体验的工作，对 AI 同样有价值。
- 当文档缺失或过时时，人类需要花大量时间阅读源码猜测意图。AI 也一样——它会在代码库中反复搜索，消耗大量上下文空间，最终可能还是理解错误。
- 当架构混乱、模块边界不清时，人类很难知道该改哪里。AI 也会迷失——它可能改了错误的文件，或者遗漏了需要同步修改的地方。
- 当测试运行缓慢时，人类倾向于跳过测试。AI 也面临同样的压力——长时间的等待会消耗对话的”耐心”和上下文空间。
反过来则未必成立：对人来说简单的事，对 AI 未必简单。人类可以轻松地”看一眼”就理解 UI 布局问题，但 AI 需要解析整个 DOM 结构。人类可以凭直觉判断”这个改动风险很高”，但 AI 缺乏这种隐性知识。
这意味着：你为更好的文档、更清晰的架构、更快的测试所投入的每一分精力，都会获得双倍回报——既帮了人类开发者（包括未来的你），也帮了 AI。
心法三：刻意练习——像学乐器一样学习 AI
为什么有些人说”AI 对我不起作用”，而另一些人却能用 AI 完成大量的工作？
AI 就像一件乐器。每个人都知道吉他能弹出好听的音乐，也都知道如果投入刻意练习，就能变得擅长——但这需要时间、努力和实验。AI 工具也是一样。那些从 AI 中获益最多的人，都投入了刻意练习。他们不会因为一次失败就下结论说”它给了我完全错误的答案”，然后假设这将是他们的常态体验。
如何进行刻意练习？
- 创造一个干净的实验环境：不要只在工作的复杂代码库中评估 AI。启动一个个人项目，一个没有历史包袱的新项目，在这里专注于学习如何与 AI 协作。
- 从失败中提取教训：当 AI 给出错误结果时，不要只是说”它不行”然后放弃。问自己——我的 prompt 是否足够清晰？我是否提供了足够的上下文？我是否在一个对话里塞了太多任务？
- 建立肌肉记忆：什么时候应该开始新对话？如何组织一个复杂任务的 prompt？遇到某类问题时，哪种工具组合最有效？这些直觉只能通过大量练习获得。没有捷径。
心法四：短对话、精上下文、可复用——三条永不退色的铁律
不管你用的是哪款 Coding Agent，不管底层的模型怎样更新换代，这三条原则会让你与 AI 的协作效率远超旁人：
- 短对话优先于长对话——信息密度远远大于信息量。对话一旦超过 80K-100K token，果断开始新对话。
- 对上下文进行刻意管理——你放进窗口的每一段信息，都值得精心组织。把稳定的 system prompt 和工具定义放前面（还可以利用缓存），动态的对话历史放后面。
- 把每次经验沉淀为可复用的知识——踩过的坑，不要再踩第二次。持续投入，为 AI 打造一个友好的工作环境。
不要等，现在就是最好的时机
写到这里，你可能在想：这些麻烦事，等 AI 更强了是不是就不用操心了？
上下文窗口会越来越长，推理能力会越来越强。但上下文治理的底层逻辑，不会过时。
理由很简单：只要 LLM 的本质还是”基于上下文生成”，上下文的质量就永远影响着输出的质量。 窗口变长了，你不管理，它就会变得更加混乱；推理变强了，你不给定清晰的方向，它只会更自信地跑偏。
更何况，AI 的进化速度远超我们的想象。每隔几个月，我们就会看到新的突破：更长的有效上下文，更稳定的长程推理，更可靠的工具调用能力。但恰恰是这个处处受限、远非完美的阶段，给工程师留出了巨大的探索和成长空间。那些从现在就开始深入理解 LLM 底层原理、在实践中反复打磨方法、在限制里寻找创造性解法的人，当 AI 的能力被进一步释放的那一天，手里握着的将是最大的杠杆。
在未来的人才图谱中，最具竞争力的开发者将不再是某个特定技术栈的深度专家，而是Expert Generalist（专家型通才）——能够识别不同技术领域底层的共同基础，用第一性原理思维面对陌生挑战，对所使用平台的底层特性有直觉性的理解，当系统出问题时能看到完整的图景。
而 LLM 与 Expert Generalist 的关系，恰好是”放大”：当 Expert Generalist 进入一个新领域时，他们需要的不是替他们做判断的 AI，而是一个能快速填补知识空白、放大他们跨领域判断力的 AI。那些掌握了上下文治理方法论的人，正是能将 AI 变成这种”外骨骼”的人。
这个过程本身，就是价值所在。
下期预告
这篇文章聊的是”道”——Vibe Coding 的核心理念和原则：理解 LLM 的本质局限，用 Plan-Spec-Workflow 三根支柱进行上下文治理，在复利工程中让 AI 越用越聪明。
下一期，我们将直接进入”术”——以 DeepSeek-V4 + Claude Code 为工具链，完整演示一个本地桌面应用的开发全过程。
从 Plan（需求分析与边界划定）到 Spec（领域建模与规范化文档）到 Workflow（Rules 约束与小步快跑），从”一个空目录”到”一个能跑起来的应用”，每一步都透明展示。你会看到上下文治理不是纸上谈兵，而是真的能让 AI 的输出质量发生质变。
下周见。
本文是对 Vibe Coding 方法论的概览性介绍，核心观点整合自多位 AI 工程实践者的公开分享与一线经验。完整的实战演练将在下周的博客中呈现，敬请期待。