这一篇是阅读笔记，原文链接在此：mp.weixin.qq.com/s/mSd5ZQAb0…
以下是我自己记录的有感触的点
1、从"从零构建"到"从无限可能中做减法"。
在VibeCoding时代，开发者的角色从"建筑师"转变为"产品雕塑师"——你不再需要一砖一瓦地建造，而是要从AI生成的丰富可能性中，雕琢出最符合用户需求的完美产品”
2、在很多开发场景中，我的开发效率不升反降。而效率变慢的背后，主要是由于以下两个“循环” 机制导致的。
在这种背景下，我们需要认真思考的问题是：如何在充分发挥 Cursor 效能的同时，保障其生成代码的质量不“失真”？让Review环节的时间变短？
在我看来，人与 AI 之间的沟通难题，本质上与人与人之间的沟通困境并无二致，都涉及意图的传递、理解的偏差， 以及共识的建立。也正因如此，我们可以回归人类沟通中那些被验证有效的方法， 从中汲取灵感，改进与 AI 对话的方式。有哪些经验是值得借鉴的？
3、做个主动教学的好老师
我们和 AI 的协作模式高度契合，可对应以下三个步骤：
- 以老师的身份传递信息：运用费曼学习法，将复杂问题用清晰、结构化的方式“讲授”给 AI；
- 学生（AI）进行反述：AI 根据你的输入反馈生成回答，这相当于它对你所讲内容的“复述”；
- 学生提出疑问或发起质疑：你可以进一步要求 AI 指出模糊之处、追问细节，或提出反对观点，再根据 AI 的反馈，重新整理思路、完善表达。
4、复杂问题，分而治之
第一阶段：理解（使用反向费曼法）
目标是让 AI 真正理解需求。通过交互式提问与反述，明确问题背景、目标和约束。建议将对话中已明确的内容保存至可持久化的上下文中，便于后续迭代与纠偏，大幅提升沟通效率。
第二阶段：规划（领域驱动，方案权衡与拆分）
除非你已非常明确实现方式，否则应让 AI 提供多种可行方案，并分析各自的优劣。记住： “没有最好的方案，只有最适合的。” 接着对需求进行拆分，原则是最小最快验证：每个子任务应足够小、可独立验证。如果 AI 一次性生成几千行代码，Review 成本极高，可靠性也难以保障。
第三阶段：执行（小步快跑，分步执行与验证）
依据已拆分的需求文档，分步让 AI 执行并即时验证。每一任务完成都应及时反馈和修正，最终交付一个最小可行产品（MVP）。
需要强调的是，这种方法并不适用于所有场景，尤其是一些极其简单的问题，直接使用Tab即可。我曾经做过一个实验：明明只需修改5行代码，却偏要让 AI 完成，结果反复沟通调试超过15分钟，效率反而远低于手动修改。 因此，在面对不同复杂度的任务时，我们应该灵活选择策略。
5、如何更好的沟通
6、AI的输出本质上是一个概率问题，但是线上的代码可不能是一个概率问题，
在提交 MR前，我们可以对代码 Diff 做一次 “全局性把关”，不仅要确认新增 / 修改的功能点是否符合需求，更要警惕的是是否会影响主干代码（如兼容性问题、依赖冲突、性能损耗等）。这种场景下，就可以使用Cursor的DiffMainBranch能力，屡试不爽。【DiffMainBranch，这是个啥？】
比如在输入偏差或会话低效时，果断新建对话以清空无效上下文，另外就是定期总结上下文，保存下来，作为新一轮对话的初始上下文，从而持续引导AI在正确的轨道上输出。
7、作者的一些心得：
- 别指望AI完全替你干活，很多时候他也不靠谱，未来人们一大部分工作就是证明他“靠谱”
- 相比Agent模式，多用Tab更能体会到编程的乐趣。
- AI时代的软件价值 = 创新 × （需求 清晰度 × AI理解度） × 工程实现效率。
