信息量很大！AI结对编程核心思维模型

想必你也遇到过：AI的输出像个 “随机盲盒”，有时精准的让你惊艳，有时却像个大傻子，面对这种巨大的不确定性，我们应该如何应对？本文将谈谈我对于这个问题的一点心得。

关注腾讯云开发者，一手技术干货提前解锁👇

10/30晚7:30鹅厂面对面直播继续！

01、VibeCoding的诞生与困境

2025年2月，OpenAI联合创始人、前特斯拉AI负责人Andrej Karpathy在一场公开演讲中首次提出一个全新概念：VibeCoding（氛围编程）。他核心的观点是：自然语言正在成为真正的“第一编程范式”。软件开发模式从一开始的瀑布模型到快速交付版本的敏捷模型再到AI时代的VibeCoding，“这种开发范式的转变反映了一个深刻的变化：从"从零构建"到"从无限可能中做减法"。在VibeCoding时代，开发者的角色从"建筑师"转变为"产品雕塑师"——你不再需要一砖一瓦地建造，而是要从AI生成的丰富可能性中，雕琢出最符合用户需求的完美产品”

回顾近一年使用Cursor、CodeBuddy的体验，每天与AI“对话”已逐渐成为我的编程日常，无论是能“猜你所想”的TabTab,还是功能强大的Agent模式，都让我屡次感到惊艳。它帮我解决了不少实际问题，但随着使用逐渐深入，我也发现了一个明显的问题：在很多开发场景中，我的开发效率不升反降。而效率变慢的背后，主要是由于以下两个“循环”机制导致的。

1. 循环一：我常常感到自己与 Cursor 之间存在一道明显的“表达代沟”：很多需求我脑中已有大致思路，却难以用语言准确描述。结果往往是陷入无休止的沟通循环，来回解释、补充、调整，耗费了大量时间。算下总体的时间，还不如我自己上！
2. 循环二：借助 AI，代码生成的速度虽有大幅提升，但 Cursor 每次生成的代码规模少则几百行、多则数千行，我们是否应该信任或是不信任？完全信任，一定会出事。如果不信任，逐行Review又变得极其耗时。当然，有人会说“何必验证，快速上线，有问题快速迭代”。但问题恰恰在于不同场景下的代码对于错误的“容忍度”是不一样的。像微信支付这类金融级应用，对稳定性与安全性要求极高，不容任何闪失。缺乏质量保障的“快”，更加可怕，还不如没有AI。

在这种背景下，我们需要认真思考的问题是：如何在充分发挥 Cursor 效能的同时，保障其生成代码的质量不“失真”？让Review环节的时间变短？

02、回到“原点”看沟通困境

为什么与 AI 的沟通有时会不尽人意，甚至答非所问？尽管网络上流传着各种各样的提示词模板，但实际效果却时好时坏。我们往往难以判断，问题到底是出在模型的理解能力上，还是出于我们自己表达的不准确。因此，我们有必要回到“原点”重新审视这一沟通困境。那么，什么是“原点”？在我看来，人与 AI 之间的沟通难题，本质上与人与人之间的沟通困境并无二致，都涉及意图的传递、理解的偏差，以及共识的建立。也正因如此，我们可以回归人类沟通中那些被验证有效的方法，从中汲取灵感，改进与 AI 对话的方式。有哪些经验是值得借鉴的？

2.1 《沟通的方法》与乔哈里窗

直到我在“得到APP”上听到《沟通的方法》一书，其中介绍了一种解决沟通障碍的工具——乔哈里窗（Johari Window），我才豁然开朗。这个模型由美国心理学家乔瑟夫・勒夫（Joseph Luft）和精神病学家哈里・英厄姆（Harry Ingham）在1955年共同提出，最初用于理解和改善人际沟通。他们通过“知道”和“不知道”两个维度，将人与人之间的认知状态划分为四个区域，针对不同区域采取相应的沟通策略。

当我们在编写 Prompt 时，我们不妨先问自己：当前我正处于哪个认知象限？例如，请思考以下场景：

1. 当你与一位共事多年的同事沟通需求VS向一位实习生讲解同一需求——此时你分别处于什么区域？
2. 当你体重超标，第一次去健身房，想向一位能深蹲200公斤的健身者请教——你站在哪个象限？
3. 与同事讨论伊拉克战争的局势时，你们又处于哪个认知区域？

很多时候，沟通困境正源于我们总是用同一套方法应对所有情境，无论是与人还是与 AI 交互。因此，将乔哈里窗的思维模式迁移至与AI的沟通中，就成为提升对话质量的关键一步。

然而，人与 AI 的沟通存在一个根本差异：人与人之间的交流是双向互动的过程，而 AI 始终处于被动。你不会在打开 Cursor 时，收到它主动提醒：“哥们，这行代码可能存在空指针风险。”而是你必须主动提问：“请帮我检查这段代码是否存在潜在漏洞。”因此，在 AI 时代，做一个“主动”思考与沟通的人，成为了用好工具的核心前提！

2.2 做好“角色“的切换，好学生和好老师

我们先来看第一和第三象限，也就是“都懂”或“都不懂”的情况。这两种情况其实相对容易处理。

1. 如果都懂，你可以直接给出清晰、明确的指令，例如：“请使用归并算法对这段数据进行排序。”
2. 如果都不懂，例如提问“明天腾讯的股票是涨还是跌？”，这时你必须意识到，AI和你一样处于未知领域。对于它给出的任何答案，都需要保持警惕、多方验证，不可盲目采信。

真正有趣且更具挑战的是第二和第四象限：也就是一方懂而另一方不懂的情况。

1. 我懂而AI不懂（第四象限），我们相当于“老师”。要想让“学生”（AI）有效地完成任务，核心策略是主动教会它。这本质上是一个“翻译”的过程：你需要将自己的专业知识或模糊意图，转化为AI能够精确理解的语言和指令，也就是把“我懂的”推动到“AI也懂的”领域（横轴向下平移）
2. 我不懂而AI懂（第二象限），角色就互换了，我们成了“学生”。此时的策略应该是主动提问和引导，让AI将其知识清晰、有条理地输出给我们，提问的目的不是直接获取知识，而是引发你的思考！

因此，与AI高效沟通的策略已然清晰：关键在于做好角色的灵活切换，想清楚什么时候该做虚心求教的学生，什么时候该做耐心细致的老师。那么问题来了：当我们处于“老师”的位置时，具体该如何“教”，才能把复杂问题给AI讲清楚，从而获得高质量的输出呢？

2.3 做个主动教学的好老师

在诺兰的电影《奥本海默》中，有一位充满魅力的物理学家——理查德·费曼。他提出的“费曼学习法”广为人知：真正掌握一门知识的最好方式，就是尝试用简单的话把它讲给别人听，直到对方也能理解。比如此时此刻，当你在阅读这篇文章时，我也正在实践这个方法。这一过程，恰好与我们和 AI 的协作模式高度契合，可对应以下三个步骤：

1. 以老师的身份传递信息：运用费曼学习法，将复杂问题用清晰、结构化的方式“讲授”给 AI；
2. 学生（AI）进行反述：AI 根据你的输入反馈生成回答，这相当于它对你所讲内容的“复述”；
3. 学生提出疑问或发起质疑：你可以进一步要求 AI 指出模糊之处、追问细节，或提出反对观点，再根据 AI 的反馈，重新整理思路、完善表达。

这种方法最大的优势，在于实现了双重验证：

• 验证你是否真的想清楚了需要解决的问题（很多时候，其实是我们自己还没理清思路）
• 验证AI 是否真正理解了你的意图

复杂问题，分而治之

当通过上面的方法把需求有效的传递给AI后，接下来就是怎么做的问题，显然，我们不可能一口吃个胖子，如何科学拆分需求?就成了决定后续效率的关键。很自然的想到：分而治之，这也就是领域驱动设计（DDD）的核心理念，它的核心逻辑是：面对复杂需求或问题时，先将其拆解为多个职责独立、边界清晰的小任务，待逐个攻克每个小任务后，再通过合理的逻辑将成果整合，最终实现整体需求的落地。

但必须明确的是，“拆” 与 “合” 之间需要找到精妙的平衡 —— 拆解得越细，看似每个小任务的解决难度越低、分工越明确，可后续整合的复杂度却可能呈指数级攀升。比如在技术开发中，若将一个完整的单体服务强行拆分为上百个微服务，开发阶段确实能享受模块独立的灵活性，但后续的跨服务流程协调、数据一致性保障，以及整体系统的运维成本，都会变得异常繁重，反而适得其反！因此，需求拆解绝非 “越细越好”，而是要把握好 “度”：必须结合业务目标、团队协作能力、后续维护成本等实际场景综合权衡，让 “分而治之” 真正服务于需求落地，而非制造新的麻烦，我们可以结合这两种方法，把整个过程描述成下面的方法！

第一阶段：理解（使用反向费曼法）

目标是让 AI 真正理解需求。通过交互式提问与反述，明确问题背景、目标和约束。建议将对话中已明确的内容保存至可持久化的上下文中，便于后续迭代与纠偏，大幅提升沟通效率。

第二阶段：规划（领域驱动，方案权衡与拆分）

除非你已非常明确实现方式，否则应让 AI 提供多种可行方案，并分析各自的优劣。记住：“没有最好的方案，只有最适合的。” 接着对需求进行拆分，原则是最小最快验证：每个子任务应足够小、可独立验证。如果 AI 一次性生成几千行代码，Review 成本极高，可靠性也难以保障。

第三阶段：执行（小步快跑，分步执行与验证）

依据已拆分的需求文档，分步让 AI 执行并即时验证。每一任务完成都应及时反馈和修正，最终交付一个最小可行产品（MVP）。

需要强调的是，这种方法并不适用于所有场景，尤其是一些极其简单的问题，直接使用Tab即可。我曾经做过一个实验：明明只需修改5行代码，却偏要让 AI 完成，结果反复沟通调试超过15分钟，效率反而远低于手动修改。因此，在面对不同复杂度的任务时，我们应该灵活选择策略。

2.4 做个主动提问的好学生

当我们处于“第二象限”（我不懂而AI懂），这个时候我们就要切换成一个善于提问的“好学生”。那么，怎样才算是一位“好学生”？下面我来介绍一下：四问组合法。“四问组合法”通过 What（是什么）-->Where（在何处）-->Why（为什么）-->How（怎么做） 这四个经典问题，帮助我们梳理自己的思路，逐步引导AI给出高质量的回答，有时我们觉得自己“不会提问”，其实是因为我们并没有结构化地思考过问题本身，而这个方法论就可以很好的帮助你：

1. 理清了自己模糊的需求；
2. 界定了问题的边界和上下文；
3. 理解了为什么要做、以及如何衡量不同方案。

而这，正是一个“好学生”最珍贵的能力：不只索取答案，而是学会如何思考问题！

而这四个问题的答案，其实就是一份很好的Prompt，把它整理成MD格式的文档吐给AI，相信你会发现自己与AI的对话质量显著提升，而你也真正成为了那个“驾驭AI，而非依赖AI”的主动者。

2.5 苏格拉底提问法：用问题回答问题

另外一个比较有意思的方法是古希腊哲学家苏格拉底开创，一种对话与思考工具，它的核心是 “以追问引导深度思考”，而非直接灌输答案。它遵循 “产婆术” 逻辑 —— 如同助产士帮助产妇接生，这种提问法不创造新认知，而是通过连环式、针对性的追问，让对话者暴露原有观点的逻辑漏洞，逐步剥离表层认知，最终自主探寻到事物本质。

在《理想国》中，当色拉叙马霍斯宣称 “正义是强者的利益”，苏格拉底未直接反驳，而是以 “统治者是否会因认知偏差制定损害自身利益的法律？”“若遵守这类法律，是否违背‘正义是强者利益’的定义？” 等问题连环追问，迫使对方发现自身观点的矛盾，进而重新审视 “正义” 的本质。

而这种提问逻辑，恰好与 AI prompt 的设计深度契合。AI prompt 的核心是 “引导 AI 生成精准、有深度的内容”，若沿用苏格拉底提问法的逻辑设计 prompt，便能避免让 AI 陷入浅层回答。比如当我们想让 AI 分析 “AI 伦理的边界” 时，不直接提问 “AI 伦理边界是什么”，而是用追问式 prompt：“AI 伦理的核心保护对象有哪些？若 AI 决策与人类利益产生冲突，此前定义的伦理边界是否需要调整？调整时需优先考量技术可行性还是人类权益？”—— 这种模仿苏格拉底追问的 prompt，能引导 AI 像被 “产婆术” 引导的思考者般，层层拆解问题，生成更具逻辑链与深度的回答，让与 AI 的沟通更贴近 “通过问题探寻本质” 的核心目标。让AI帮助你思考。

03、写代码VS看代码

AI的输出本质上是一个概率问题，但是线上的代码可不能是一个概率问题，所以我们要思考：面对大量的代码，我们需要如何Review以及测试。

3.1 测试驱动开发（Test-Driven Development ）

面对黑盒代码的信任问题，最理想的方式是让 AI 自主发现问题，而不是依赖人工复查。这就像设置了一个漏斗机制，能够提前过滤掉大部分潜在问题。那么，AI 如何知道如何测试呢？答案就是编写单元测试。传统上，单元测试往往是在开发完成后才进行的步骤。但在使用 Cursor 这类工具的情况下，只要明确定义函数，AI 就能快速生成对应的测试用例。当 AI 完成函数实现后，自动运行这些单元测试，就能在早期确保代码质量。这样一来，代码质量得到了前置保障，而不必等到人工复查时再去补写测试，那时往往已经错过了最佳时机。

3.2 拆分任务，逐步Commit

通过单元测试，我们可以过滤一大部分问题，但是毕竟还是需要人去review，那怎么办呢，这里的策略就是：拆，如果是1000行的代码提交，我们尽量按功能路径拆分成5个200行，这样做有几个好处：

1. 实现渐进式修正，避免推倒重来：如果在某个子模块中发现错误，我们可以仅针对该片段进行修改，而不必影响其他已通过验证的部分。这保证了问题能够被及时定位和修复，而不是等到整体开发完成后再回头修改，那时往往可能面临“从零开始”的代价。
2. 有效控制风险，便于回滚与迭代：每次只处理一小块代码，确保持续提交可用的、稳定的部分。万一后续的修改被AI“改乱”或引入新问题，我们可以依据提交历史快速回退（Rollback）到最近一个正确的版本，如图中底部所提示的“有问题，及时回滚”，极大降低了调试和回归的成本。

在提交 MR前，我们可以对代码 Diff 做一次 “全局性把关”，不仅要确认新增 / 修改的功能点是否符合需求，更要警惕的是是否会影响主干代码（如兼容性问题、依赖冲突、性能损耗等）。这种场景下，就可以使用Cursor的DiffMainBranch能力，屡试不爽。

拆分的核心原则：最小可快速验证

如上图所示，大家就能感受到，拆分有一个核心原则：“最小可快速验证”？它主要包含两个维度：

1. 最小（Minimal）： 每个子任务应只包含一个明确的、单一的功能点或更改意图。例如，修改一个独立的函数、实现一个具体的接口、或添加一个清晰的功能特性。理想状态下，每个子任务生成的代码量应足够小（例如控制在几十到两百行之内），使其易于被人理解和审查。
2. 可快速验证（Quickly Verifiable）： 每个子任务都必须具备可被快速验证的方法。这通常意味着：它为某个独立的功能提供了明确的输入输出。它可以被一个或一组特定的单元测试所覆盖。其正确性可以通过运行测试、简单的集成或肉眼审查在短时间内得到确认。

通过测试驱动开发以及有效的拆分，我们就可以很大程度上有效的保证了代码的质量不失真，保证心里有底。

04、提示词VS上下文工程

除了使用“好问题”来设计提示词（Prompt）之外，我们还需要有效控制与 AI 的“上下文”。接下来，我们通过一个生活化的场景，来理解什么是近来备受关注的“上下文工程”（Context Engineering）——它究竟是一种真正的技术演进，还是只是“新瓶装旧酒”？想象一下：有一天你去餐厅点餐，你对服务员说：“我想吃一份牛排。”这时候，你的目标是吃到一份让自己满意的牛排。十几分钟后，牛排上了桌，你却发现问题了，这份牛排是全熟，并不合你的口味，做法也不是你想要的。于是你重新对服务员说：“请给我一份七分熟的牛排，搭配黑胡椒和土豆。”

在这个场景中：“我想吃一份牛排”就是一个初始的提示词（Prompt）。

而“请给我一份七分熟的牛排，搭配黑胡椒和土豆”则是经过明确和细化后的指令，也就是提示词工程（Prompt Engineering）的体现。

又过了一天，你再次来到这家餐厅。还没等你开口，服务员主动问道：“今天还是来一份七分熟的牛排，搭配黑胡椒和土豆吗？”你点点头说：“是的。”

在这个场景中：服务员之所以能够提前给出建议，是因为他记住了你上一次的偏好和行为。这就是上下文工程（Context Engineering）——通过有效管理和利用历史交互信息（即“上下文”），使AI能够基于之前的对话或数据，提供更连贯、更个性化的回应。所以简单的总结一下：

提示词是“你说什么”

提示词工程是“你怎么说”

上下文工程是“它还记得什么”

所以，对于使用Cursor工具的人来说，我们需要有意识的管理“上下文”，比如在输入偏差或会话低效时，果断新建对话以清空无效上下文，另外就是定期总结上下文，保存下来，作为新一轮对话的初始上下文，从而持续引导AI在正确的轨道上输出。Cursor中已经提供了上下文使用长度的数据，我们可以依此参考。

05、一些心得

1. 别指望AI完全替你干活，很多时候他也不靠谱，未来人们一大部分工作就是证明他“靠谱”
2. 相比Agent模式，多用Tab更能体会到编程的乐趣。
3. AI时代的软件价值 = 创新 ×（需求清晰度 × AI理解度）× 工程实现效率。

（ps：有很多同学咨询画图工具，这里给下链接 https://app.excalidraw.com/）

-End-

原创作者｜吕昊俣