--- title: "一个 VibeCoder 的自我修养" description: "Vibe Coding 是什么？本文结合一年多 AI 辅助开发实践，总结 Cursor、上下文管理、规则设计、任务拆分与人工验收的经验和边界。" pubDate: 2026-02-27T12:35:17.000Z tags: ["VibeCode","Cursor","最佳实践"] --- 作为两个 Pro 账号接力撑不到月底的 Cursor 重度用户、Google AI Pro 用户、AI IDE 羊毛无差别收割者，这是我近一年多 AI 辅助编程的心得体会。 ![一个VibeCoder的自我修养配图](/asset/vibecoder_ziwoxiuyang.png) ## 什么是 Vibe Coding 很早就有人说按照 AI 的发展速度程序员很快就会被取代，世界将不再需要程序员。这是一种根据表象做出的简单线性推导，但由于忽略了驱动这一切的内在本质，所以结论存疑。 首先要理解 AI 辅助编程（Vibe Coding）是什么。这事还得从项目管理说起，在上一个轰轰烈烈的互联网鼎盛时期的十年里，从头到尾始终贯穿着一个从未被真正解决的问题，那就是软件开发工作的标准化管理。如何量化一个工程师的产出？团队协作的软件项目怎样最小化效率损耗？这些问题无法解决是由软件开发工作的特点决定的。编程是一件大部分时间在构思小部分时间在实施的工作。 当一位工程师将整体任务实施了 20% 的时候，实际上他已经预先在大脑中对整个任务的技术选型、逻辑链、数据链、各模块实现方式、各模块耦合方式做了多次推演和虚拟化构建，最终选择了他认知范围内综合了实施成本、可靠性、可维护性、安全指标、性能指标的最优方案，但此时项目经理能看到的可能是他忙活了几天只做出一个按钮。于是项目经理灵机一动决定加派人手提高开发速度。好吧，此时工程师需要将他大脑中的方案全盘灌输给另一个或多个工程师，然后这一个或多个工程师才能参与协同开发，这个过程可以通过语言、文档、图表、会议室里比比划划等各种人类的表达方式进行，但所有这些方式在表达软件开发任务这件事上的效率都低于代码，因为只有代码是专为软件开发而设计的语言。结果就是工程师经常会说一句让很多项目经理不理解的话，“有讲明白的功夫代码我都写完了”，其实这才是正常的。 但有一种情况例外，就是当低级工程师向高级工程师转发任务时会非常顺畅，往往三言两语就能说明白，这是因为转发对象对所要转发的任务有非常高的背景知识覆盖率，可以只靠小量信息就能自动补全剩余大量信息，而这就是如今 Vibe Coding 的基本模式，AI 扮演的就是那个被你转发任务的工程师。 理解了 Vibe Coding 是什么，就很容易理解 Vibe Coding 的困境。模型给出的结果有时候很惊艳，有时候很离谱，给人一种抽卡的感觉，除非你输入了一个世界性难题，否则效果不好的原因大概率就是输入信息不足，使模型难以基于特定任务的知识覆盖率对其形成可靠的方案补全，只能被迫在输出中凑一些关联性偏低的内容。就目前（2026 年初）的顶级模型能力来说，预估工时超过 5 人/天的中等复杂度任务基本就是分水岭，超过这个难度的编程任务就需要向模型提供完整的设计思路、必要的细节方案和足够的背景信息，才能以接近 100% 的准确率得到生产可用的输出结果，否则就是抽卡。 这就引出了目前 Vibe Coding 的效率卡点，构思仍然需要由人来做，而构思通常是一件耗时且有门槛的工作。能不能将这部分工作也交给 AI，从而进一步提高效率、降低门槛？这也是最近讨论较多的测试驱动开发（TDD）。人不再负责构思而只是提出需求并设计验收标准，把剩下的构思和实施工作都交给大模型，让模型自己迭代直到满足验收标准为止。这个思路很吸引人，但有一个死穴。如果人不会构思，那他怎么会设计验收标准呢？可能对单一组件、纯逻辑函数这类需求 TDD 是可以完美胜任的，但也仅限于此了。要知道中等复杂度以上的任务往往会产生架构层面的非功能性验收标准，比如系统吞吐量、架构演进方向、结合业务特点的技术选型等，这些内容远超通用自然语言所能有效表达的范围，从而几乎无法被量化和自动化测试，这些都是需要人且只有人在对当前团队状况、公司状况、行业状况、商业前景等诸多现实因素有了体感之后才能做出的直觉判断。如果放弃前期构思，面对海量的架构可能性，大模型无效迭代的算力损耗将趋近于无穷大，那么即便最终得到了满足要求的结果，投产比也会趋近于无穷低，这个成本谁来承担？ 敏锐的你可能发现了漏洞，所谓的“直觉”未必就是人类的专属，只要输入跟现实世界一样多的取舍条件，模型应该也可以做到类似的效果吧。OK，此时终于来到了一切讨论的关键，**能效**。只要模型的能效超过人脑的能效，理论上广义的测试驱动就是可行的，人类离迈入言出法随的共产主义阶段也就不远了。可能模型在一些擅长任务上的表现过于惊艳以至于让我们对模型能力的发展曲线抱有不切实际的幻想，实际上人脑在复杂任务规划这类高维领域的运行效率上远超目前公开面世的任何大模型，这是由技术路线决定的。传统模型的主流技术路线是自回归的线性推导，在输出最后一个字符之前都不知道自己要说什么，导致其根本不存在全局视野，自然也做不到跳跃式的沙盘推演。而即便对于目前最先进的、带有深度强化学习和内部思维链的推理模型，虽然具备了一定的事前规划能力，但在非线性跳跃思维上的能效和直觉判断的效率依然远低于经验丰富的人脑，至少目前看不到突破的可能，人脑仍然是这方天地中最精密的思维机器。也许未来的模型能通过其他技术路线反超人脑，那就无法预测了，这就是我在文章开头所说的疑点。 ## Vibe Coding 最佳实践 目前凡是能用简单自然语言准确表达的开发需求几乎都能被模型很好的实现，在这个需求范围内不挑 IDE、不需要 Prompt 工程，甚至也不太挑模型，一线模型在这类简单任务上基本都能做到言出法随。而当任务复杂度和体量提升到一定程度时，一句话 Prompt 的成功率会显著下降，此时就需要一些“模式”上的辅助才能顺利解决问题。比如 Cursor 的 Plan 模式，通过主动询问澄清需求，通过任务拆分提升构建环节的吞吐量。除了 Cursor 其他 IDE 也可以达到类似的效果，这基本上是目前 AI IDE 的甜点区，在这个区间里 Vibe Coding 的效率提升最明显，受益的工程师人数也最多，我也是其中之一，下面是我日常积累的一些 Vibe Coding 经验。 - **注意代码保护。**你和 N 个 Agent 协同编程，虽然电脑前只坐着一个人，但这俨然是一个小型开发团队，作为一个拥有十多年一线开发团队管理经验的开发者，相信我，你永远不知道别人会提交什么。所以 Git 以一种奇怪的方式，成为了这个时代的个人开发者最必不可少的开发工具。 - **建立你的规则。**世界是个混沌系统，每个项目/团队/公司都有一些听上去奇怪但又非如此不可的规则。我理解，每个工程师都理解，但模型不理解，你需要设置 rules，建立 command，提取 skills，将那个独属于你的神奇工作台一砖一瓦的搭建出来。 - **上下文运营。**模型有独特的注意力分配方式，模型有比人小的多的心智容量，模型有明确的上下文总容量，这些属性都不是固定的，这需要你对模型的反应保持敏锐观察，并根据你的观察主动调整 Prompt 策略。这里无法给出一个神奇 Prompt 或者万能公式，因为模型的发展日新月异，一切都在变化，唯一能跟上变化的方法就是亲自去感受变化。 - **必要的骨架搭建。**别再梦想做只动口不手动的技术总监了，如果 AI 要淘汰谁的话，这种人一定首先被淘汰。你拥有一个 AI 团队不意味着你就可以躺下来喝茶看报，恰恰相反，正因为你有别人无法取代的东西你才会拥有一个团队。去做模型不擅长的事，去做你瞬间能完成而模型要深度思考的事，去做你对自己有信心而对模型没信心的事，去指明方向，去搭建骨架，去磨练自己独一无二的能力。 ## 关于灵犀项目 AI 不是万能的，有经验的开发者应该会发现，有些任务即便借助 AI 实现起来仍然很困难，因为在高难度任务中构建不再是最重要的，构思才是真正的卡点，人得自己先把整件事想清楚，毕竟模型再强大也满足不了一个尚未说出来的需求。即便是中等难度的任务，如果表述不清楚，或者遗漏了某些约束条件，模型也无法给出满意的结果，如果想让模型基于现有结果修改，其难度甚至远大于推翻重做，几番折腾下来，就算最终做出来了，可能整体效率还不如自己做来得快。 总的来说，越是执行高难度的任务，需求定义就越重要，很多人已经试过将传统软件开发流程引入 AI 工作流，从定义需求文档、到详细设计、再到任务规划、再执行、最后测试。我也试过这个流程，但是几番体验下来，明显感觉传统的需求文档格式只适用于由人组成的开发团队，并不适合直接给模型用；而对于复杂任务来说，整体构建再整体测试的方式也非常不适合模型的能力特点；而传统流程中容易被忽略的评审环节，对 AI 工作流来说反而变得特别重要；另外，有的工作环境可能需要建立非常多的规范，横跨个人偏好、项目独有规范、团队共享规范等，这些规范如何管理、如何加载，现阶段都没有成熟的方案。 这些深度的、细微的开发需求可能并不是多数人在多数时候会遇到的，所以通用 IDE 满足这些需求的意愿并不高，既然没人做，那我们就自己补上这块拼图。灵犀就是这样一个基于 Cursor 的开发工作流解决方案，提供一套核心工作流，和一个持久化记忆系统，目前正在密集迭代中，敬请期待。 ## 常见问题 ### Vibe Coding 适合生产项目吗？ 适合，但前提是保留代码审查、自动化测试、权限控制和人工验收。AI 可以提高实现速度，不能替代生产责任。 ### 为什么复杂任务中一句 Prompt 容易失败？ 因为模型缺少项目独有的业务背景、架构约束和取舍条件。任务越复杂，需要补充的上下文越多，也越需要把任务拆成可独立验证的小步。 ### 使用 Cursor 或其他 AI IDE 最重要的能力是什么？ 不是记住某个固定 Prompt，而是判断当前输出是否可靠、缺少哪些上下文，以及下一步应该继续、回退还是重构。