超越 Vibe Coding：Obsidian 为脑，Cursor 为手，构建双向反哺的 AI 开发新范式

超越 Vibe Coding：Obsidian 为脑，Cursor 为手，构建双向反哺的 AI 开发新范式 超越 Vibe Coding：Obsidian 为脑，Cursor 为手，构建双向反哺的 AI 开发新范式 Modified August 25, 2025 1. 如果让 LLM 直接看 “Idea” 也就是创意级别的内容，他可能真的可以一口气生成一个类似于创意结果的产品，可以用，但可能和你要的东西大相径庭。为什么？因为不够细。 2. 如果让 LLM 看需求类的内容，AI 可以按需求生成相关的模块；但需求与需求之间又产生了隔阂、模块之间的技术差异和相互引用，错综复杂。 AI 没有人类一样的抽象思维 + 长期记忆理解的配合能力，因此每次做任务基本是从新来做，因此会产生模块之间的差异与屎山代码。 3. 如果让 LLM 看任务级别的内容，那么 AI 可能可以快速完成细节任务，但由于对整体产品走向的把控的缺失，基本上做出来的东西很缺乏大局观。这就非常像是刚入职的开发干的事儿了，一言难尽吧。 那我们上面说了那么多，给什么都不行，那我们需要怎么办呢？ 02 那我们该如何“投喂”AI？ 成年人不做选择，我都要！一个成熟的开发者，在心中对项目应该有这样层层递进的认知结构： Tip 1. 产品方向与价值： 确保不走偏。 2. 技术架构与框架： 确保方法论正确。 3. 实施方案与代码结构： 这是代码的抽象蓝图。 4. 具体的任务与模块需求： 将蓝图拆解为可执行的砖块。 在 Human in the Loop 的模式中， 人的核心角色，就是“把控 AI”，成为一个高质量的“上下文饲养员”。 我的理念是：现阶段，我们与 AI 协作的瓶颈是上下文。而最高质量的上下文，正是我们人类通过创意、探索、钻研一路沉淀下来的宝贵信息。未来 AI 的窗口会越来越大，我们唯一要做的，就是学会如何精准、充足地提供这些信息。 03 实践中的核心挑战 好了，我们知道了要成为一个“上下文饲养员”。这意味着在实践中，我们必须做好几件事： Todo • 细粒度的任务拆解 ：把复杂的项目拆成 AI 能理解的小块。 • 结构化的 Prompt 技巧 ：精心准备每一次提问的背景信息。 • 开发者主导审查与架构 ：时刻把控全局，审查 AI 的每一行关键代码。 但这立刻引出了一个所有高效开发者都会面临的灵魂拷问： 我所有的思考、规划、架构图、需求文档、任务列表……这些宝贵的“上下文”，到底应该存放在哪里？ 放在一堆零散的 text 文档里？还是一个独立的、与代码环境完全割裂的项目管理软件中？或者更糟，就只存在我们自己的大脑里？ 一旦这些高维度的“战略”信息，与我们日常编码的“战术”环境分离开来，巨大的摩擦力就产生了。我们很快就会因为嫌麻烦，而放弃维护这些宝贵的上下文，最终又退回到低效的开发模式中。 这，才是问题的关键。 我们需要的，不仅仅是几个技巧，而是一套能将“战略大脑”与“战术代码”无缝连接的 终极工作流 。 而这，正是 Obsidian 即将登场的原因。 04 终极工作流：打造一个活的“项目大脑” 接下来，我将分享如何用 Obsidian 和 Cursor 配合，做到天衣无缝的心流式开发与文档同步体验。这套工作流的核心，是 打造一个与你的代码同生共死的、活的“项目大脑”。 01 第一步：用“软链接”打通任督二脉 这是整个工作流的技术基石。我们需要建立一个“人”与“AI”双向同步的文档流，而“软链接”就是那座桥。 “可是 Obsidian 和项目代码在不同目录，操作起来太麻烦了！” 通过一行简单的命令，就可以让你的项目文档目录（例如，代码仓库根目录下的 docs 文件夹），神奇地出现在 Obsidian 库中，并且两边可以任意编辑，实时同步！ Windows (以管理员身份运行 PowerShell): Code block Plain Text Copy New Item ItemType SymbolicLink Path "你Obsidian库中的路径\Project Docs" Target "你代码仓库中的文档路径" macOS/Linux: Code block Plain Text Copy ln s "/path/to/your/code/repo/docs" "/path/to/your/obsidian/vault/Project Docs" Aha! Moment 当我第一次通过软链接，在 Obsidian 里看到项目文档，和在 Cursor 里看到的是同一个文件时，我知道， 我找到了连接‘战略（大脑）’与‘战术（代码）’的那座桥。 02 第二步：在 Obsidian 中构建“项目大脑” 打通了管道，我们就要开始构建内容了。在 Obsidian 中，这个与项目同步的文件夹，就是你喂养 AI 的“饲料基地”，也是你所有项目智慧的沉淀中心。一个推荐的结构如下： • 00 project vision.md ：项目的“宪法”。用几句话说清楚，这个项目是干什么的，核心价值是什么。 • 01 prd/ 文件夹： 产品需求文档（PRD） 。存放详细的产品需求、用户故事、功能列表等。 • 02 design/ 文件夹： 设计文档 。包含 UI/UX 设计稿、交互流程图、原型链接等。 • 03 architecture/ 文件夹： 架构设计文档 。这里可以细分为多个文件，记录技术选型、模块划分、数据流图、API 设计等。 • 04 tasks/ 文件夹： 任务拆解 。将 PRD 中的大需求，拆解成一个个细粒度、可交付给 AI 的小任务清单。 • 05 decisions log.md ： 决策日志 。记录关键的技术决策和原因，避免以后重复踩坑或遗忘。 • 06 dev logs/ 文件夹： AI 开发日志 。AI 每次交互的“工作记录”，存放 Prompt、输出和解决方案。 这些结构化的文档和文件夹，共同构成了你的“活的项目大脑”。它们是 AI 理解你意图、高效协作的基石。 03 第三步：在 Cursor 中消费“上下文” 现在，神奇的事情发生了。当你在 Cursor 中准备开发一个新功能时，你不再需要凭空写 Prompt。 你可以直接在聊天框里 @ 这些文档！ Prompt 示例： “@01 prd/user stories.md @03 architecture/api design.md @04 tasks/task 001 user login.md 根据用户故事、API 设计和任务要求，帮我实现‘用户登录’功能。请在 src/controllers/authController.js 中创建相应的方法，并使用 JWT 进行认证。” 看，AI 得到的不再是零散的指令，而是有源可溯、有据可查的丰富上下文。代码质量自然天差地别。 04 第四步：双向同步，完成“知识飞轮” 这套工作流最美妙的地方在于 闭环 ——一个由人与 AI 共同驱动的“知识飞轮”。 当 AI 帮你完成了代码，或者你在开发中有了新的发现、遇到了新的挑战，你 必须 回到 Obsidian（或者直接在 Cursor 里打开那个同步的文档）进行更新。而在这个更新过程中，AI 同样可以成为你的得力助手： • 任务状态更新（ tasks/ 文件夹）： ◦ 完成任务： AI 帮你完成一个任务后，你可以让 AI 自动在 tasks/ 文件夹中对应的任务条目旁打上 [x] 标记，表示已完成。 ◦ 未完成或变更： 如果任务未能按预期完成，或者需要调整，AI 可以协助你记录 未能完成的原因 ，或者将任务拆解、调整到新的 tasks/ 文档中。 • 架构与设计变动（ architecture/ 和 design/ 文件夹）： ◦ 在开发过程中，AI 可能会提出更优的实现方案，或者发现现有架构/设计存在问题。你可以让 AI 协助你将这些 架构变动 或 设计调整 记录到对应的 architecture/ 或 design/ 文档中，甚至直接生成更新后的图表描述。 • 产品需求迭代（ prd/ 文件夹）： ◦ 技术实现中发现的限制或新的可能性，可能会反过来影响产品需求。AI 可以帮助你将这些 需求变更 或 新想法 记录到 prd/ 文档中，确保产品文档始终与实际开发同步。 • AI 开发日志（ dev logs/ 文件夹）： ◦ 这是 AI 每次交互的“工作记录”。你可以让 AI 自动将关键的 Prompt、它的输出、遇到的错误、解决方案以及任何值得注意的代码片段，都以结构化的方式记录到 dev logs/ 文件夹下的独立文件中。这不仅是 AI 的学习日志，也是你未来复盘和 Debug 的宝贵财富。 这个持续的、由人机协同驱动的更新过程，就完成了知识的反哺。你的“项目大脑”因为你的每一次编码和 AI 的每一次交互而变得更聪明、更完整。下一次，无论你还是 AI，都能基于这个更强大、更实时的知识库，做出更精准、更高效的决策。 这就是一个完美的、由人与 AI 共同构建的“开发 文档”知识飞轮。 05 第五步：双 AI 引擎，武装你的战略与战术 最后，别忘了我们可以在两个地方使用 AI： 1. 在 Obsidian 中（战略层）： 使用 Obsidian Copilot 等插件，让 AI 帮你进行高维度的思考。比如，“ @vault 帮我分析一下我这个项目的设计文档，看看有没有逻辑上可以优化的地方？” AI 在这里扮演的是 架构师或产品顾问 。 2. 在 Cursor 中（战术层）： 让 AI 帮你执行具体的编码任务。AI 在这里扮演的是 地表最强实习生 。 通过这套工作流，我们真正实现了“人机协同”，让 AI 在我们搭建好的框架内，发挥出最大的效能。 05 附录：给你的 AI “立规矩”—— 高级 Prompt 模板 光有文件结构还不够，我们还需要教会 AI 如何使用这个“项目大脑”。最好的方式，就是在你的 Prompt 中加入一套明确的“行为准则”，让它从一个被动的执行者，变成一个主动的思考者和维护者。 下面是几个融入了“行为准则”的高级 Prompt 模板，你可以根据自己的项目进行修改。 01 模板一：新组件开发 这个 Prompt 用于启动一个新功能的开发，确保 AI 在动手前，充分理解了所有相关的背景信息。 Code block Plain Text Copy 任务：开发一个新的 React “用户头像” (UserAvatar) 组件 行为准则 (Rule of Conduct) 核心知识库: 所有项目文档（需求、架构、设计）都存放在 文件夹中，其结构如下： 行动指令 (Action): 1. 主动查阅: 在回答我的问题或生成代码前，如果背景信息不足，请务必先查阅 文件夹中的相关文档。 2. 主动更新: 如果我提出的新需求或设计与现有文档存在冲突或不一致，请在完成任务的同时，用简洁的文字指出冲突，并直接生成需要更新到相关文档中的内容（使用 表示新增， 表示删除）。 具体要求 1. 组件需要接收 (图片链接) 和 (大小, 'small'/'medium'/'large') 两个 props。 2. 请遵循 中的样式规范。 3. 如果用户没有提供 ，则显示一个默认的占位符头像。 请生成完整的组件代码，并告诉我应该将它放在哪个目录下。 02 模板二：分析用户反馈并创建任务 这个模板展示了如何让 AI 参与到需求分析和任务创建的环节。 Code block Plain Text Copy 任务：分析用户反馈并创建开发任务 行为准则 (Rule of Conduct) ... (同上) ... 用户反馈 “你们的 App 在上传图片的时候总是失败，尤其是在网络不好的情况下。希望能有个重试按钮。” 具体要求 1. 阅读以上用户反馈，并查阅 和 ，分析这是否是一个已知问题或新需求。 2. 在 文件夹下，为这个反馈创建一个新的任务文件 。 3. 任务文件中需要包含：用户故事、验收标准、以及初步的技术实现思路。 1. 如果让 LLM 直接看 “Idea” 也就是创意级别的内容，他可能真的可以一口气生成一个类似于创意结果的产品，可以用，但可能和你要的东西大相径庭。为什么？因为不够细。 2. 如果让 LLM 看需求类的内容，AI 可以按需求生成相关的模块；但需求与需求之间又产生了隔阂、模块之间的技术差异和相互引用，错综复杂。 AI 没有人类一样的抽象思维 + 长期记忆理解的配合能力，因此每次做任务基本是从新来做，因此会产生模块之间的差异与屎山代码。 3. 如果让 LLM 看任务级别的内容，那么 AI 可能可以快速完成细节任务，但由于对整体产品走向的把控的缺失，基本上做出来的东西很缺乏大局观。这就非常像是刚入职的开发干的事儿了，一言难尽吧。 那我们上面说了那么多，给什么都不行，那我们需要怎么办呢？ 02 那我们该如何“投喂”AI？ 成年人不做选择，我都要！一个成熟的开发者，在心中对项目应该有这样层层递进的认知结构： Tip 1. 产品方向与价值： 确保不走偏。 2. 技术架构与框架： 确保方法论正确。 3. 实施方案与代码结构： 这是代码的抽象蓝图。 4. 具体的任务与模块需求： 将蓝图拆解为可执行的砖块。 在 Human in the Loop 的模式中， 人的核心角色，就是“把控 AI”，成为一个高质量的“上下文饲养员”。 我的理念是：现阶段，我们与 AI 协作的瓶颈是上下文。而最高质量的上下文，正是我们人类通过创意、探索、钻研一路沉淀下来的宝贵信息。未来 AI 的窗口会越来越大，我们唯一要做的，就是学会如何精准、充足地提供这些信息。 03 实践中的核心挑战 好了，我们知道了要成为一个“上下文饲养员”。这意味着在实践中，我们必须做好几件事： Todo • 细粒度的任务拆解 ：把复杂的项目拆成 AI 能理解的小块。 • 结构化的 Prompt 技巧 ：精心准备每一次提问的背景信息。 • 开发者主导审查与架构 ：时刻把控全局，审查 AI 的每一行关键代码。 但这立刻引出了一个所有高效开发者都会面临的灵魂拷问： 我所有的思考、规划、架构图、需求文档、任务列表……这些宝贵的“上下文”，到底应该存放在哪里？ 放在一堆零散的 text 文档里？还是一个独立的、与代码环境完全割裂的项目管理软件中？或者更糟，就只存在我们自己的大脑里？ 一旦这些高维度的“战略”信息，与我们日常编码的“战术”环境分离开来，巨大的摩擦力就产生了。我们很快就会因为嫌麻烦，而放弃维护这些宝贵的上下文，最终又退回到低效的开发模式中。 这，才是问题的关键。 我们需要的，不仅仅是几个技巧，而是一套能将“战略大脑”与“战术代码”无缝连接的 终极工作流 。 而这，正是 Obsidian 即将登场的原因。 04 终极工作流：打造一个活的“项目大脑” 接下来，我将分享如何用 Obsidian 和 Cursor 配合，做到天衣无缝的心流式开发与文档同步体验。这套工作流的核心，是 打造一个与你的代码同生共死的、活的“项目大脑”。 01 第一步：用“软链接”打通任督二脉 这是整个工作流的技术基石。我们需要建立一个“人”与“AI”双向同步的文档流，而“软链接”就是那座桥。 “可是 Obsidian 和项目代码在不同目录，操作起来太麻烦了！” 通过一行简单的命令，就可以让你的项目文档目录（例如，代码仓库根目录下的 docs 文件夹），神奇地出现在 Obsidian 库中，并且两边可以任意编辑，实时同步！ Windows (以管理员身份运行 PowerShell): macOS/Linux: Aha! Moment 当我第一次通过软链接，在 Obsidian 里看到项目文档，和在 Cursor 里看到的是同一个文件时，我知道， 我找到了连接‘战略（大脑）’与‘战术（代码）’的那座桥。 02 第二步：在 Obsidian 中构建“项目大脑” 打通了管道，我们就要开始构建内容了。在 Obsidian 中，这个与项目同步的文件夹，就是你喂养 AI 的“饲料基地”，也是你所有项目智慧的沉淀中心。一个推荐的结构如下： • 00 project vision.md ：项目的“宪法”。用几句话说清楚，这个项目是干什么的，核心价值是什么。 • 01 prd/ 文件夹： 产品需求文档（PRD） 。存放详细的产品需求、用户故事、功能列表等。 • 02 design/ 文件夹： 设计文档 。包含 UI/UX 设计稿、交互流程图、原型链接等。 • 03 architecture/ 文件夹： 架构设计文档 。这里可以细分为多个文件，记录技术选型、模块划分、数据流图、API 设计等。 • 04 tasks/ 文件夹： 任务拆解 。将 PRD 中的大需求，拆解成一个个细粒度、可交付给 AI 的小任务清单。 • 05 decisions log.md ： 决策日志 。记录关键的技术决策和原因，避免以后重复踩坑或遗忘。 • 06 dev logs/ 文件夹： AI 开发日志 。AI 每次交互的“工作记录”，存放 Prompt、输出和解决方案。 这些结构化的文档和文件夹，共同构成了你的“活的项目大脑”。它们是 AI 理解你意图、高效协作的基石。 03 第三步：在 Cursor 中消费“上下文” 现在，神奇的事情发生了。当你在 Cursor 中准备开发一个新功能时，你不再需要凭空写 Prompt。 你可以直接在聊天框里 @ 这些文档！ Prompt 示例： “@01 prd/user stories.md @03 architecture/api design.md @04 tasks/task 001 user login.md 根据用户故事、API 设计和任务要求，帮我实现‘用户登录’功能。请在 src/controllers/authController.js 中创建相应的方法，并使用 JWT 进行认证。” 看，AI 得到的不再是零散的指令，而是有源可溯、有据可查的丰富上下文。代码质量自然天差地别。 04 第四步：双向同步，完成“知识飞轮” 这套工作流最美妙的地方在于 闭环 ——一个由人与 AI 共同驱动的“知识飞轮”。 当 AI 帮你完成了代码，或者你在开发中有了新的发现、遇到了新的挑战，你 必须 回到 Obsidian（或者直接在 Cursor 里打开那个同步的文档）进行更新。而在这个更新过程中，AI 同样可以成为你的得力助手： • 任务状态更新（ tasks/ 文件夹）： ◦ 完成任务： AI 帮你完成一个任务后，你可以让 AI 自动在 tasks/ 文件夹中对应的任务条目旁打上 [x] 标记，表示已完成。 ◦ 未完成或变更： 如果任务未能按预期完成，或者需要调整，AI 可以协助你记录 未能完成的原因 ，或者将任务拆解、调整到新的 tasks/ 文档中。 ◦ 完成任务： AI 帮你完成一个任务后，你可以让 AI 自动在 tasks/ 文件夹中对应的任务条目旁打上 [x] 标记，表示已完成。 ◦ 未完成或变更： 如果任务未能按预期完成，或者需要调整，AI 可以协助你记录 未能完成的原因 ，或者将任务拆解、调整到新的 tasks/ 文档中。 • 架构与设计变动（ architecture/ 和 design/ 文件夹）： ◦ 在开发过程中，AI 可能会提出更优的实现方案，或者发现现有架构/设计存在问题。你可以让 AI 协助你将这些 架构变动 或 设计调整 记录到对应的 architecture/ 或 design/ 文档中，甚至直接生成更新后的图表描述。 ◦ 在开发过程中，AI 可能会提出更优的实现方案，或者发现现有架构/设计存在问题。你可以让 AI 协助你将这些 架构变动 或 设计调整 记录到对应的 architecture/ 或 design/ 文档中，甚至直接生成更新后的图表描述。 • 产品需求迭代（ prd/ 文件夹）： ◦ 技术实现中发现的限制或新的可能性，可能会反过来影响产品需求。AI 可以帮助你将这些 需求变更 或 新想法 记录到 prd/ 文档中，确保产品文档始终与实际开发同步。 ◦ 技术实现中发现的限制或新的可能性，可能会反过来影响产品需求。AI 可以帮助你将这些 需求变更 或 新想法 记录到 prd/ 文档中，确保产品文档始终与实际开发同步。 • AI 开发日志（ dev logs/ 文件夹）： ◦ 这是 AI 每次交互的“工作记录”。你可以让 AI 自动将关键的 Prompt、它的输出、遇到的错误、解决方案以及任何值得注意的代码片段，都以结构化的方式记录到 dev logs/ 文件夹下的独立文件中。这不仅是 AI 的学习日志，也是你未来复盘和 Debug 的宝贵财富。 ◦ 这是 AI 每次交互的“工作记录”。你可以让 AI 自动将关键的 Prompt、它的输出、遇到的错误、解决方案以及任何值得注意的代码片段，都以结构化的方式记录到 dev logs/ 文件夹下的独立文件中。这不仅是 AI 的学习日志，也是你未来复盘和 Debug 的宝贵财富。 这个持续的、由人机协同驱动的更新过程，就完成了知识的反哺。你的“项目大脑”因为你的每一次编码和 AI 的每一次交互而变得更聪明、更完整。下一次，无论你还是 AI，都能基于这个更强大、更实时的知识库，做出更精准、更高效的决策。 这就是一个完美的、由人与 AI 共同构建的“开发 文档”知识飞轮。 05 第五步：双 AI 引擎，武装你的战略与战术 最后，别忘了我们可以在两个地方使用 AI： 1. 在 Obsidian 中（战略层）： 使用 Obsidian Copilot 等插件，让 AI 帮你进行高维度的思考。比如，“ @vault 帮我分析一下我这个项目的设计文档，看看有没有逻辑上可以优化的地方？” AI 在这里扮演的是 架构师或产品顾问 。 2. 在 Cursor 中（战术层）： 让 AI 帮你执行具体的编码任务。AI 在这里扮演的是 地表最强实习生 。 通过这套工作流，我们真正实现了“人机协同”，让 AI 在我们搭建好的框架内，发挥出最大的效能。 05 附录：给你的 AI “立规矩”—— 高级 Prompt 模板 光有文件结构还不够，我们还需要教会 AI 如何使用这个“项目大脑”。最好的方式，就是在你的 Prompt 中加入一套明确的“行为准则”，让它从一个被动的执行者，变成一个主动的思考者和维护者。 下面是几个融入了“行为准则”的高级 Prompt 模板，你可以根据自己的项目进行修改。 01 模板一：新组件开发 这个 Prompt 用于启动一个新功能的开发，确保 AI 在动手前，充分理解了所有相关的背景信息。 02 模板二：分析用户反馈并创建任务 这个模板展示了如何让 AI 参与到需求分析和任务创建的环节。 03 模板三：数据库结构变更 这个模板展示了如何让 AI 在执行技术变更的同时，主动维护相关的架构文档。 06 写在最后 AI 时代，最稀缺的不是算力，而是 驾驭算力的思想框架 。 这套工作流，是我踩了无数坑之后总结出的心得。它帮助我摆脱了被 AI 牵着鼻子走的困境，重新夺回了开发的主导权。将第二大脑的构建与个人产品的创造相结合，不仅仅是为了提升效率，更是为了构建一个能持续产生高价值输出的个人系统。 希望它也能给你带来启发。 如果你也对“第二大脑”、“AI 工具”、“个人成长系统”感兴趣， 点个关注 ，我们一起探索这个时代更有趣的生活方式。 🔗 原文链接： https://mp.weixin.qq.com/s/63jCc7DW... https://mp.weixin.qq.com/s/63jCc7DW... 原创 燕子石 子时说2025年08月24日 22:23 北京 摘要 本文提出超越 Vibe Coding 的 AI 开发新范式：融合 Obsidian 与 Cursor，通过上下文工程构建人机协同知识飞轮，实现战略与战术双向反哺。 obsidian cursor 01 从“代码魔法”到“产品工程”的鸿沟 Question “ AI 时代，如何从一次性‘代码魔法’走向可持续的‘产品工程’？ ” 最近，无论在工作还是个人项目中，我都深度使用 Cursor 进行原型乃至产品开发。因为自己有些 AI 和第二大脑的实践经验，所以这次跨界融合颇有心得，想和大家分享。 今天想探讨的核心是： 在“原型开发”和“真实产品开发”这两种截然不同的场景下，我们该如何搭建一套 Cursor + Obsidian 的高效 AI 开发工作流？ 以及，我们常说的第二大脑（Obsidian），在这其中究竟扮演了什么关键角色？ 在开始前，你可能会问： 产品开发和第二大脑有什么关系？ 关系巨大。如果你只是一个单纯执行任务的开发者，那或许关系不大。但如果你是一个 从 0 到 1 的超级个体 ，需要亲历从灵感风暴、市场调研、产品设计到技术实施的全过程，那么，一个强大的第二大脑就是你的战略指挥中心。 将第二大脑与创意开发关联，是一个绝妙的组合。它能让你在构建产品时，源源不断地从知识库中“喂养”AI；同时，开发过程中的思考与沉淀又能反哺你的知识库，形成原子化的笔记，为未来所用。 这是一个让“构建产品”与“构建大脑”相辅相成的飞轮。 当然，我知道很多人对“第二大脑”仍有疑惑：“不就是记笔记吗？” 并非如此。它的核心是通过“记录 → 整理 → 提炼 → 创造价值”的链路，构建一个能持续为你带来回报的外部认知系统。 02 Vibe Coding vs Human in the Loop Coding 01 Vibe Coding 很多人都被 Vibe Coding 的广告语“一句话生成应用”的视频震撼，但只要亲手试过就知道， 后续的修改、迭代、维护简直是噩梦 。 Vibe Coding 大翻车！ 我上个月用 Vibe Coding 的理念，成功在公司用三个人天，快速干出了一整套埋点平台的产品原型。问过开发，人家前端说这个原型是真好，甚至都不用看需求文档了😍。当时我就飘飘然了！ 后来回家来继续用 Vibe Coding 干了产品开发，结果…… 结果我花了一天的时间来让 AI debug 一件事儿，后续竟然发现是因为 css 太长了 AI 读不过来导致一直定位不到问题！结果我自己调试了一下， ctrl + F 一下定位到问题，解决了。白费了我这一天的钱😵 简单来说， Vibe Coding 就是凭感觉编码，让 AI 把你的模糊想法直接变成代码。在之前的文章 Cursor x PM：产品经理的 AI 原型设计 Vibe Coding 中，我详细介绍过如何用它高效产出原型。 Cursor x PM：产品经理的 AI 原型设计 Vibe Coding 但！ 原型开发是原型开发，真实产品是真实产品，两者复杂度有云泥之别。 我坚信，当前环境下任何鼓吹用 Vibe Coding 直接开发严肃产品的，都是在贩卖未来。它产出的是 代码彩票 ，而不是 代码资产 。或许用上最顶级的模型和 Agent 工具能做得更好，但项目一大，屎山依旧。 更何况，对于我们普通开发者或超级个体而言，这种“大力出奇迹”的开发方式，很可能让你的钱包一夜回到解放前。Claude Code 几十刀一条命令，真不是开玩笑。 所以结论很明确： Vibe Coding 这种 AI 全权负责、人只验收的模式， 仅适用于产品原型或一次性的小项目。 02 Human in the Loop Coding 这个顾名思义啊，就是说，当前的环境下，我们和 AI 协作最好的方式呢，就是 人机协同，而非替代 。也就是说： Human in the Loop Coding 将 AI 视为强大的编程助手，而非开发者替代品。结合 AI 的速度与人类的架构决策、审查能力，实现效率最大化。 引用 正如一位资深用户所说，LLM 工具目前应当“ 作为工具而非人类开发者的替代 ”。 这可不是危言耸听，网上各位大拿早就已经得出了上述的结论，意思是说 AGI 还早得很，以当前的 LLM 大模型瓶颈来看，只能如此。 那说到 Human in the Loop Coding，问题就来了？ Human 怎么 "in loop" 呢？不会就是，你一句我一句，等你开发完我再说下一句吧？那当然不是…… 一段 prompt 生成产品的视频大家都看过，那都只是一次性的效果，我们要的是可以持续的开发迭代的长期产品 coding 方案。那本文接下来，就是来和大家探讨探讨，我个人通过近期的开发、和网上的调研，得出来的一套小小的经验与分享。 03 到底怎么 Human in the Loop？ 01 问题的核心：从“提示工程”到“上下文工程” 那到底该怎么 Human in the Loop 呢？首先要搞清楚，为什么我们一度推崇的 Vibe Coding 会失灵。 核心问题就一个： LLM 的上下文窗口是有限的，这导致了致命的“信息差”。 核心理念转变 真正的 AI 开发，重点不在于提示工程（Prompt Engineering），而在于 上下文工程（Context Engineering） 。 核心建议 精准控制上下文 ：提供恰当且充分的上下文是成功的关键。只提供与当前任务相关的代码片段、函数签名和需求文档，避免无关信息干扰。 洞察 在 AI 编码中， 提供恰当且充分的上下文是 成功关键 。一方面，要让模型充分了解当前任务相关的信息，例如 相关的函数签名、数据结构、以及需求说明 。这可以通过在 Prompt 中附加必要的代码片段、文件路径或注释来实现。另一方面，又要避免无关或过多的信息干扰模型思路。社区实践表明： “Cursor 并没有取代你的工作， 你仍然需要理解自己的代码和 AI 产出的代码 ” ，效果最佳。比如在使用 Cursor 时，开发者会先 浏览相关文件 。 我们在每次 coding 的时候，会面临一些“视角”的选择：