李文业的思考笔记

当前阅读总时间是：19,470小时

1

特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。

虚构的力量与理性的脆弱

七万年前，智人经历了一场认知革命。我们的祖先获得了一种前所未有的能力：相信并传播虚构的故事。正是这种能力，让智人能够建立超越血缘的大规模合作网络，最终征服了整个地球。

想象一下：一只黑猩猩无法说服另一只黑猩猩把香蕉交给它，通过承诺死后会在“黑猩猩天堂”得到无限香蕉作为回报。但智人可以。我们可以相信天堂、国家、人权、金钱——这些都是虚构的故事，但正是对这些故事的共同信仰，让陌生人之间能够合作，让帝国得以建立，让文明得以延续。

但这种能力是一把双刃剑。

我们的大脑进化出了相信故事的本能，却没有进化出区分真实与虚构的可靠机制。在漫长的演化史中，这不是什么大问题——我们的祖先需要相信部落的神话才能团结协作，至于这些神话是否“客观真实”，并不影响他们的生存。一个相信“我们部落的图腾是神圣的”的群体，可能比一个充满怀疑论者的群体更团结，更有战斗力。

从演化的角度看，“有用的虚构”往往比“无用的真相”更有生存优势。

问题在于，我们现在生活的世界与祖先的世界已经截然不同。我们需要理解气候变化、疫苗原理、经济规律——这些都需要准确的事实判断，而不是鼓舞人心的神话。但我们的大脑仍然是七万年前那个大脑，它天生更擅长相信故事，而不是验证事实。

反智主义：一个演化的遗产

当你在社交媒体上看到有人声称“微软程序员躲在下水道被洪水冲走”或“清朝只是殖民统治”，并发现成千上万人为此点赞时，你感到愤怒。这种愤怒是可以理解的。但如果我们想真正理解这个现象，就需要暂时放下情绪，从更宏观的视角来审视。

反智主义并非现代社会的产物，而是深植于智人心理结构中的古老倾向。

美国历史学家霍夫施塔特将反智主义定义为“对理性生活及其代表者的怨恨与怀疑”。但从演化心理学的角度看，这种“怨恨”有其深层逻辑：在我们祖先生活的小型狩猎采集群体中，那些声称拥有“特殊知识”的人往往是巫师或酋长，他们的“知识”常常是维护自身权力的工具。对这类人保持怀疑，在演化上是有利的。

试想，如果一个原始人对部落巫师的每一句话都深信不疑，他可能会被利用、被剥削。而一个保持适度怀疑的人，反而更可能保护自己的利益。这种对“精英”的本能警惕，被自然选择保留了下来。

换句话说，反智主义是智人对权威的本能警惕在现代社会的错位表达。

问题在于，现代社会的“知识精英”与原始社会的巫师有本质区别。科学家的知识是可验证的，医生的建议是基于证据的。但我们的大脑无法轻易区分这两者——它只看到“有人声称知道我不知道的事”，然后本能地产生警惕。

这种错位在受教育程度较低的群体中尤为明显，但绝不仅限于他们。事实上，一些高学历者同样会陷入阴谋论的泥潭——因为反智主义不是智力问题，而是心理结构问题。

后真相时代：当事实变得无关紧要

2016年，“后真相”（post-truth）被《牛津词典》选为年度词汇。这个词指的是一种状态：在公共舆论中，客观事实的影响力不如诉诸情感和个人信念。

但从历史的长河来看，“后真相”其实是常态，而不是例外。

在人类历史的绝大部分时间里，人们相信什么，取决于他们的部落、宗教、阶级告诉他们应该相信什么，而不是取决于客观证据。启蒙运动以来，“真相应该基于证据”这一观念才逐渐普及，但它从未完全战胜人类相信故事的本能。

我们今天所经历的，与其说是“真相的衰落”，不如说是“启蒙理想的局限性暴露”。我们曾天真地以为，只要教育普及、信息流通，人们就会自然而然地拥抱理性。但事实证明，更多的信息并不等于更多的理性——有时恰恰相反。

在信息过载的环境中，人们反而更依赖直觉和情感来筛选信息。那些能够激发强烈情绪反应的内容——无论真假——更容易获得注意力。这不是某个阴谋的结果，而是人类认知系统与现代信息环境不匹配的必然后果。

算法时代的认知失调

21世纪的信息环境对人类认知系统构成了前所未有的挑战。

我们的大脑在数百万年的演化中，适应的是一个信息稀缺的环境。在那个环境中，获取信息需要付出努力，而来自部落成员的信息通常是可靠的——撒谎者很快就会被识别并受到惩罚。我们的祖先生活在150人左右的群体中，每个人都认识每个人，声誉是最重要的货币。在这样的环境中，散播谣言的成本是很高的。

但今天，我们每天接收的信息量超过了祖先一生所能接触的总和。更糟糕的是，这些信息来自匿名的陌生人，通过精心设计的算法推送到我们面前。散播谣言的成本趋近于零，而收益——注意力、流量、金钱——却是实实在在的。

这些算法不关心真相，只关心一个指标：用户参与度。

研究表明，激发强烈情绪反应的内容——尤其是愤怒和恐惧——能够获得更高的传播率。麻省理工学院的一项研究发现，虚假新闻在Twitter上的传播速度比真实新闻快六倍。这不是因为人们故意选择谎言，而是因为谎言往往比真相更具戏剧性、更能激发情绪。

这意味着，在算法的选择压力下，最能存活和传播的“信息物种”往往不是最准确的，而是最能激发情绪的。我们可以把这称为“信息的自然选择”——只不过，这种选择的标准不是真实性，而是传播力。

这就是为什么那些荒谬的谣言能够获得数百万点赞，而严谨的辟谣却无人问津。这不是因为人类突然变蠢了，而是因为我们的认知系统正面对一个它从未进化出应对能力的新环境。

愤怒的生物学基础

当你看到反智内容时感到愤怒，这是一个有趣的现象，值得我们深入探讨。

从神经科学的角度看，愤怒是杏仁核对威胁的反应。杏仁核是大脑深处的一个杏仁状结构，负责处理情绪，尤其是恐惧和愤怒。当我们感知到威胁时，杏仁核会在意识层面做出反应之前就触发应激反应——心跳加速、肾上腺素分泌、肌肉紧张。

有趣的是，杏仁核无法区分物理威胁和抽象威胁。当我们的核心信念受到挑战时，大脑会将其解读为一种攻击——不是对身体的攻击，而是对我们建构的意义系统的攻击。这触发了与面对肉食动物时相似的应激反应。

神经科学家发现，当人们的政治信念受到挑战时，大脑中负责个人身份认同的区域会被激活。这意味着，对很多人来说，政治观点不仅仅是观点——它们是身份的一部分。挑战这些观点，就等于挑战他们是谁。

这解释了为什么与人争论政治或历史问题时，我们的心跳会加速、手会发抖、思维会变得不够清晰。我们的身体正在准备“战斗或逃跑”，尽管我们面对的只是屏幕上的文字。从大脑的角度看，这与面对一头愤怒的野牛没有本质区别。

但这里存在一个悖论：我们越是认同自己是“理性的人”，就越容易被反智言论激怒。因为这些言论不仅挑战了某个具体观点，还威胁到了我们的身份认同本身。“理性”已经成为我们身份的核心组成部分，任何对理性的攻击都会被我们的大脑解读为对自我的攻击。

这就是为什么知识分子往往是反智主义最激烈的批评者——同时也是最容易被它激怒的人。

信息茧房：部落主义的数字版本

社交媒体算法创造了一种新型的隔离机制——信息茧房。

在传统社会中，人类以部落为单位生活，部落成员共享同一套神话和价值观。这种“群体思维”在当时是有适应意义的：它增强了群体凝聚力，提高了集体行动的效率。一个观念统一的部落，比一个充满分歧的部落更有战斗力。

部落成员通过仪式、故事、共同的敌人来强化群体认同。“我们”与“他们”的界限清晰分明。这种二元思维方式被深深刻入了人类的心理结构。

今天的信息茧房本质上是部落主义在数字空间的重现。不同的是，现代“部落”不再由地理边界划分，而是由算法划分。每个人都生活在由自己的点击历史构建的信息世界中，与持不同观点的人越来越隔绝。

算法的逻辑很简单：给用户他们想看的东西，让他们停留更长时间。如果你点击了一个阴谋论视频，算法就会推荐更多类似内容。久而久之，你的信息世界就会被这类内容填满，而相反的观点则被系统性地排除在外。

在这样的环境中，极端观点不断得到强化。心理学家称之为“群体极化”——当一群持有相似观点的人聚在一起讨论时，他们最终的观点往往比讨论前更加极端。这是因为在回声室中，温和的声音被淹没，极端的声音被放大；表达极端观点的人获得更多认可，而表达温和观点的人则被边缘化。

“元清非中国”这样的论调，在其追随者的信息茧房内被反复回响，逐渐从一个边缘观点变成“不容置疑的真理”。试图从外部注入不同声音的人，往往被视为“敌对部落”的成员而遭到排斥。他们不仅不会被听取，反而会强化茧房内部的团结——“看，外面的人都在攻击我们，我们必须团结起来”。

这不是智力问题，而是结构问题。即便是高智商的人，在足够封闭的信息环境中也可能形成扭曲的世界观。历史上，许多聪明绝顶的人曾真诚地相信地球是平的、女巫是真实存在的、某个种族天生劣等——不是因为他们愚蠢，而是因为他们的信息环境不允许其他可能性存在。

争议经济学：注意力时代的悖论

在注意力经济时代，一个反直觉的现象出现了：争议本身成为了一种资源。

这是一种新型的经济学。在传统经济中，企业通过生产有价值的产品来获利。但在注意力经济中，最稀缺的资源是人们的注意力，而获取注意力的最有效方式往往是制造争议。

当某个UP主因争议性言论被封禁后粉丝不降反升，从90万涨到550万，这不是偶然。这背后有清晰的逻辑：

第一，“受害者叙事”激活了人类对弱者的同情本能。我们的大脑天生倾向于同情被压迫者、反抗权威。这是一种古老的心理机制——在原始社会，站在弱者一边往往是正确的策略。当追随者将其偶像塑造为“因说真话而被打压”的形象时，关注她就从单纯的娱乐行为转变为一种“正义行动”。人们不再是在消费内容，而是在“参与抵抗”。

第二，争议扩大了触达范围。在信息过载的时代，默默无闻是最大的威胁。那些原本不会接触到该UP主的人，因为争议而得知了她的存在。每一篇批评文章、每一条愤怒转发，都在帮助她扩大影响力。从某种意义上说，批评者成了免费的推广员。

第三，争议创造了身份认同。当人们因为支持某个争议人物而被外界批评时，他们的支持会变得更加坚定。这是因为他们现在不仅是在支持一个观点，更是在捍卫自己的判断力和身份。承认自己错了，就等于承认自己曾经是傻瓜。很少有人愿意这样做。

这揭示了一个令人不安的现实：在当前的信息生态中，批评往往会强化被批评者。你的愤怒转发可能正在帮助谣言传播者达成他们的目标。每一次你说“这太荒谬了”，都在为这个荒谬的内容增加曝光度。

这就是注意力经济的诡异之处：它让对与错、真与假变得不那么重要，重要的只是能否吸引注意力。

理性的局限与可能

面对这一切，理性的人能做什么？

首先，我们需要接受一个谦卑的事实：理性说服的力量是有限的。

数十年的心理学研究表明，当一个人的信念与其身份认同紧密绑定时，事实和逻辑几乎无法改变它。这就是所谓的“逆火效应”——当你向某人展示与其信念相矛盾的证据时，他们往往不会改变看法，反而会更加坚定原有立场。这是因为改变信念意味着否定自我，而人类的大脑会本能地抵抗这种否定。

辩论往往只会强化双方的既有立场。每个人都在寻找支持自己观点的证据，忽略相反的证据。这不是因为人们故意不诚实，而是因为我们的大脑就是这样运作的——确认偏误是人类认知的基本特征，而不是缺陷。

但这不意味着理性毫无用处。

2024年发表在《Science》杂志上的一项研究带来了一线希望：与AI进行对话可以使阴谋论信念降低约20%，效果持续至少两个月。研究者让参与者与GPT-4对话，讨论他们相信的阴谋论。令人惊讶的是，即使是那些根深蒂固的信奉者，也有相当一部分人在对话后改变了看法。

这个发现值得深思。AI之所以有效，可能恰恰因为它不是“敌对部落”的成员。它没有身份、没有立场、没有傲慢。它不会嘲笑你，不会居高临下，不会让你感到被攻击。它只是耐心地提供信息，回答问题，让对话者自己得出结论。

这暗示了人类理性说服失败的一个重要原因：不是因为证据不够充分，而是因为信使本身就被视为敌人。当一个“知识精英”试图纠正一个反智主义者时，后者首先感受到的不是论证的力量，而是被瞧不起的愤怒。这种情绪反应会在他有机会评估论证之前就关闭他的大脑。

AI没有这个问题。它不属于任何部落，因此不会激活部落防御机制。

这暗示了一种可能的策略：与其试图在情绪化的公共空间中说服他人，不如创造条件让人们自己去探索和质疑。如果有人相信阴谋论，与其与他争论，不如建议他去问问AI——让一个没有立场的实体来回答他的问题。

这里还有一个判断标准：如果一个人在与AI充分对话后仍然坚持某个观点，那他持有的可能不是事实判断，而是信仰。这没什么错，但你需要知道区别。事实可以被证据改变，信仰则不能。对于信仰，争论是徒劳的。

认知免疫系统的建设

既然我们无法改变外部信息环境的本质，我们能做的是增强自身的“认知免疫系统”。

正如身体的免疫系统帮助我们抵抗病原体，认知免疫系统帮助我们抵抗错误信息和情绪操控。这个系统不是天生的，需要刻意培养。

这需要从几个层面入手：

建立稳定的认识论基础。 你需要清楚自己相信什么，以及为什么相信。这不是盲目的信念，而是经过反思的立场。问自己：如果出现什么证据，我会改变这个看法？如果答案是“没有任何证据能改变我的看法”，那你持有的可能是信仰，而不是基于证据的判断。两者都可以存在，但你需要知道区别。

当你对自己的核心价值有清晰认知时，外部的噪音就更难动摇你。你不会因为看到一个反智视频就焦虑万分，因为你知道自己站在哪里。

理解信息系统的运作机制。 知识就是力量。当你明白算法如何放大极端内容、信息茧房如何形成、争议如何转化为流量、你的愤怒如何被利用，你就不会轻易被表象迷惑。

你会用更冷静的眼光看待那些“病毒式传播”的内容。当你看到一个让你愤怒的帖子时，你会先问：这是真的吗？谁从传播这个信息中获益？我的愤怒是否正在被利用？

控制信息摄入。 正如你会注意饮食健康，你也需要注意“信息饮食”健康。

主动选择信息来源，而不是被动接受算法推荐。订阅高质量的新闻来源，而不是依赖社交媒体信息流。减少碎片化信息的摄入，增加深度阅读的比例。一本好书给你的营养，可能超过一个月的社交媒体浏览。

定期给自己“数字断食”——一天不看社交媒体，看看感觉如何。很多人会惊讶地发现，离开信息流后，他们反而更平静、更有精力。

培养情绪觉察能力。 学会识别自己的情绪信号。当你感到心跳加速、呼吸急促、手指想要敲键盘回击时，这是你的杏仁核在接管大脑。

在这个时刻按下暂停键。深呼吸，离开屏幕，等情绪平复后再决定要不要回应。大多数时候，你会发现不回应是更明智的选择。

区分事实与信仰。 如前所述，如果一个人在面对所有相反证据后仍然坚持某个观点，那他持有的可能不是事实判断，而是信仰。事实是可以被证据改变的，信仰则不能。

对于信仰，争论是徒劳的。认识到这一点可以节省你大量的时间和精力。

历史的视角：我们来过这里

如果我们放宽视野，看看人类历史，就会发现：我们不是第一次面对这种挑战。

每一次信息技术的重大革新，都曾引发类似的焦虑和混乱。

印刷术发明后，欧洲经历了一个多世纪的宗教战争和社会动荡。廉价的印刷品让各种异端思想得以传播，教会的信息垄断被打破。当时的知识精英同样忧心忡忡：普通人能读书了，但他们能分辨真假吗？他们会不会被煽动者利用？

这些担忧不无道理。印刷术确实被用来传播谣言、煽动仇恨、制造迫害。但最终，印刷术也带来了科学革命和启蒙运动。社会逐渐发展出了新的制度和规范来应对印刷时代的挑战：版权法、诽谤法、学术同行评审、专业新闻业。

电报、广播、电视的发明同样引发过恐慌。每一次，都有人担心新技术会摧毁理性、瓦解社会。每一次，社会最终都适应了过来——虽然过程常常混乱而痛苦。

今天的互联网和社交媒体是最新的一次冲击。它的规模和速度前所未有，但本质上仍然是信息技术革命的一部分。我们正处于适应期的阵痛之中。

这个历史视角应该给我们一些安慰：人类文明总体上还是在进步的，只是这个进程比我们希望的更加缓慢和曲折。反智主义不会永远占上风。但改变需要时间——可能是几十年，甚至几代人。

与不完美的世界共处

最后，我们需要与一个不完美的现实和解。

反智主义不会消失。它是智人心理结构的一部分，只要人类存在，它就会以这样或那样的形式存在。我们能做的不是消灭它，而是将它控制在可接受的范围内。

你无法拯救每一个人，也无法纠正每一个错误。如果你试图这样做，你只会耗尽自己。

接受自己影响力的有限性，不是认输，而是智慧。你可以在自己的能力范围内做一些事情：保持理性，传播知识，影响身边的人，用行动而不只是言语来示范什么是理性的生活方式。这些小事加起来，长期来看，是有意义的。

但更重要的是，不要让这场与反智主义的对抗消耗你的生命能量。

你只有一次生命。这一生中有太多美好的事物值得探索：书籍、音乐、自然、爱、创造。不要把太多时间花在与网络上的陌生人争论上。那些时间本可以用来读一本好书、陪伴家人、锻炼身体、学习新技能。

智人是一个奇怪的物种。我们既能相信荒谬的谣言，也能发现宇宙的规律。我们既能被情绪操控，也能通过反思超越本能。我们既能建造奥斯维辛，也能创作贝多芬第九交响曲。正是这种矛盾性，定义了我们是谁。

在这个充满噪音的时代保持理性，既是一种智识上的选择，也是一种生存策略。你不需要赢得每一场辩论，你只需要保持清醒，过好自己的生活，成为你希望在这个世界上看到的改变。

这本身就是对反智主义最好的回应。

1

特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。

引言

各位好，今天聊一个让很多人感同身受的话题——当你在网上看到明显是胡说八道的内容，却发现底下一片叫好，你该怎么办？

我举两个例子。

B站有个UP主绰号“牢A”，用煽动性的语气讲述“美国悲惨故事”：什么中国留学生在美国医学院一边读书一边替人收尸，见识了无数美国底层惨剧。更离谱的是，他说微软被裁的程序员无家可归躲进下水道，遇上洪水集体被冲走，却没有任何媒体报道。

我愣住了——这故事太夸张了。我去查，美国主流媒体没有，中文媒体也没有。一群程序员在下水道被冲走这么大的事，怎么可能没人报道？这故事编得连基本逻辑都不过关。但你看视频下面，成千上万点赞，评论区一片叫好，仿佛他说的都是真相。

还有“吃瓜蒙主”。这位更厉害，公开说“元朝、清朝不属于中国”“清朝只是殖民统治”，直播里还说“鸦片战争其实结束了灾难，因为西方带来了文明”“日本侵略东北是有人邀请来的”。

我看到这里，气得手都抖了——这完全是歪曲历史、美化侵略！可令人挫败的是，弹幕和评论竟然在附和她，有人管她叫“先生”，认为她是敢讲真话的智者。她被软封禁后，粉丝不降反升，从90万涨到550多万。

我又急又怒，心想：难道谬误反倒成了真理，坚持常识的人反而成了少数？

每当在网上遇到这种煽动性反智内容，我内心都会经历一番煎熬。从震惊到愤怒，再到茫然无力，情绪仿佛坐上过山车。我知道不能任由愤怒吞噬自己，但面对铺天盖地的跟风舆论，又实在难以漠视。

今天我不讨论这些人对不对——这不需要讨论。我想聊的是：面对反智言论，我们普通人怎么调整心态？你生气有用吗？你跟他们吵能吵赢吗？怎么做才能既不憋屈自己，又不把自己气出病来？

什么是反智主义？

在往下聊之前，我们先搞清楚一个概念：到底什么是反智主义？

“反智主义”这个词，英文叫Anti-intellectualism，最早由美国历史学家理查德·霍夫施塔特在1963年的著作《美国生活中的反智主义》中系统阐述。他把反智主义定义为：“对理性生活以及那些被认为代表理性生活的人——知识分子——所抱有的怨恨和怀疑。”

简单来说，反智主义有几个典型特征：

第一，不信任专业知识和专家。 认为专家都是骗人的，学者都在忽悠人，“我虽然没读过书，但我懂得比你多”。

第二，推崇简单粗暴的答案。 复杂问题不愿意深入理解，喜欢一句话解释一切。阴谋论就是典型——所有问题都是某个“幕后黑手”造成的，多简单。

第三，敌视理性思考本身。 认为讲道理的人是“书呆子”，独立思考是“装”，质疑精神是“杠精”。

反智主义不是某个国家独有的现象。美国有反疫苗运动、QAnon阴谋论；欧洲有各种伪科学养生；国内有我们刚才说的那些历史虚无主义、编造故事博流量的UP主。本质上都是一回事：拒绝理性，拥抱情绪；否定专业，迷信直觉。

了解了这个背景，我们再来看那些让你愤怒的内容，就能看得更清楚——它们不是孤立现象，而是一种有历史、有规律、全球普遍存在的社会心理倾向。

那么问题来了：面对这种东西，你为什么会那么生气？

第一部分：你为什么会这么生气？

我相信很多人跟我一样，看到这种内容的第一反应就是愤怒。但各位有没有想过，这个愤怒到底从哪来的？

我分析了一下，大概有这么几个原因。

第一，价值观被冒犯。

我们从小接受的教育告诉我们要讲事实、讲道理、尊重常识。现在有人公开在网上胡说八道，还有那么多人信。这就产生了心理学上说的“认知失调”——你看到的东西和你相信的东西完全对不上，你的大脑就开始报警：不对劲，这不对劲。

为了缓解这种不适，人往往会试图调和冲突，要么改变看法，要么否定信息。而当我面对反智内容时，我不愿改变自己对事实的坚信，只能感到巨大的心理压力和愤慨。这个愤怒，本质上是你的大脑在捍卫自己的认知体系。你在喊：“他们在胡说八道！”这是本能反应。

第二，身份威胁。

你认为自己是个讲道理的人，有独立思考能力，相信通过求知可以理解世界。结果反智言论大行其道，讲道理的人反而成了少数派。你会有一种不安：难道理性思考在这个环境下成了原罪？

前面我们说过，反智主义的核心就是对理性和知识分子的敌视。当你看到有人煽动大众仇视“精英”、仇视“专家”的时候，你会隐隐感觉到，这种敌意是冲着你这类人来的。于是愤怒也夹杂着一丝恐惧——害怕自己所认同的身份和价值被集体否定。

第三，正义感和无力感交织。

许多煽动性内容不仅反智，还充满煽动仇恨的元素。比如“吃瓜蒙主”鼓动民族对立，带节奏刷“满清皆是垃圾”这种口号。你看到有人歪曲历史、美化侵略，想站出来说两句，结果发现对面是成千上万粉丝，你一个人的声音微不足道。

这种“有心杀贼、无力回天”的感觉，最后全都转化成了怒火——就像被困在玻璃房里看见外面失火却怎么也敲不碎玻璃，那种急躁只能变成愤怒。

第四，你还在生自己的气。

这一点很多人没意识到。你气的不只是那些谣言，你还气自己——为什么我要为这种东西失眠？为什么我控制不住情绪？这种对自己失控的不满，又加重了焦躁。心理学上管这叫“次级愤怒”，就是对自己的愤怒感到愤怒，形成恶性循环。

但各位，我要说一句公道话：你会愤怒，恰恰说明你还在乎。在乎真相，在乎是非，在乎这个社会还有没有基本的理性。这不是坏事，这是好事。

问题不在于你愤怒，在于你怎么处理这个愤怒。

第二部分：反智内容为什么能火？

在讨论怎么办之前，我觉得有必要先搞清楚一个问题：这些明显漏洞百出的东西，为什么有那么多人信？

搞清楚这个问题很重要。因为只有理解了背后的机制，你才能更理性地看待，而不是一味地骂“这帮人怎么这么蠢”。

第一，算法推波助澜。

各位要明白，今天的社交媒体平台，推送逻辑是什么？是让你停留更长时间，产生更多互动。什么内容能做到这一点？耸动的、极端的、激发强烈情绪的内容。

研究早就证明了，带有道德愤怒、煽动情绪的信息，传播速度比普通内容快得多。平台算法一看，哎，这条内容互动率高，就推给更多人。越推越火，越火越推，形成正循环。

所以你看到的那些离谱言论，不是偶然火起来的，是算法选出来的。算法不管你说的是真是假，它只管数据好不好看。可以说，情绪如同病毒，社交网络正是它的培养皿。

第二，信息茧房让人越来越极端。

社交媒体会根据你的喜好推送内容。如果你关注了一个煽动性UP主，算法就给你推更多类似内容。久而久之，你只能听到一种声音，形成所谓的“回声室效应”。

在这个回声室里，那些离谱的观点被反复强化，最后变成“不容置疑的真理”。“吃瓜蒙主”的拥趸们反复刷“元清非中国”“清朝是殖民”这类弹幕，在他们自己的圈子里，这些说法成了共识。有人提反对意见？要么被忽视，要么遭围攻。

这就是为什么辟谣经常没用——辟谣的声音根本传不进那个圈子。

第三，争议本身就是流量。

这一点很多人没想到。对自媒体来说，黑红也是红。你骂他，他涨粉；你举报他，他更火。

“吃瓜蒙主”就是典型例子。她的账号被软封禁，内容被清空，直播被关停。按理说应该凉了吧？结果粉丝不降反升，从90万涨到550多万。为什么？

原因有几个：第一，粉丝打造了“受害者叙事”——她因为说真话被打压了，我们更要支持她！很多人跑去点关注，把给她涨粉当成某种胜利。第二，铁杆粉把她过往直播切成短视频，用小号到处传播，标题起得特别煽动，什么“被封前最后发声”之类的，单条播放量上百万，给主账号引流。

所以各位要明白一个道理：有时候你的愤怒批判，反而在帮对方增加热度。在流量为王的时代，骂他可能不如无视他。

理解了这些，你再看那些被煽动的人，可能就不会那么愤怒了。他们不一定是蠢，很多只是信息不对称、认知上受到误导，或者需要一个情绪出口。当然，理解不等于认同，但至少你可以用更冷静的眼光来看待这件事。

第三部分：怎么办？

知道了愤怒从哪来，也理解了反智内容的运作机制，接下来是最实际的问题：怎么办？

我把它分成三层：及时止损、重建锚点、与世界相处。

及时止损

我回顾过几次自己被气到拍桌子的经历，发现一个有意思的现象：我的情绪不是瞬间爆炸的，而是一步步被“钓”进去的。

有一次我听说“吃瓜蒙主”被封禁，出于好奇就去搜了一下，想看看她到底说了什么。本来只是想理性地了解情况。结果一打开相关帖子，就被里面的氛围吸引了——支持者和反对者吵成一团。我本想当个旁观者，但看到有人骂辩驳谣言的网友是“汉奸”“满遗”，我忍不住了，在评论区留了一条反驳。

我以为能讲道理，结果对方根本不跟你讲道理。我的回复下面很快收到一连串嘲讽和攻击。我越看越气，越气越想回，最后一个帖子刷了两个小时，工作也耽误了，气得脑仁疼。

回过头来想，我本来是想战胜谣言的，结果反被情绪牵着鼻子走。我每一次愤怒回复，都在给那个帖子贡献热度。我辛辛苦苦据理力争，到头来成了驱动话题热度的“燃料”。

这次经历给我的教训是：及时止损比什么都重要。

怎么止损？三步：

第一，察觉信号，立刻中断。 心跳加快、呼吸急促、脑子里不停冒攻击性语言——这些都是愤怒升级的信号。一察觉到，立刻放下手机。就像电脑过热需要散热，你的大脑也需要降温。

第二，物理远离。 起身去阳台呼吸新鲜空气，走出房间活动几分钟。稍后再回看那些让你暴怒的内容，往往会发现也不过如此。距离产生理智。

第三，问自己：值得吗？ 我继续争论下去，能达到什么？和那些人在线论战，既改变不了他们想法，还搭上自己的情绪能量。网络争论是无底洞，没有意义的战斗，不如不战。

重建锚点

止损只是应急措施。长远看，你需要一个稳定的“内在锚点”，让自己在信息风暴中不随波逐流。

这个锚点是什么？说白了，就是你要非常清楚自己是谁、相信什么、坚持什么。

重申你的价值观。 静下心来问自己：我为什么愤怒？我在乎什么？答案很清楚：你在乎真相，在乎理性。正是因为热爱真相、追求理性，你才会对反智谣言零容忍。

既然如此，这些价值就是你的骄傲和底气。理性和真相终究有力量，哪怕一时被谎言掩盖，迟早大白于天下。你应该为坚守这些价值感到自豪，而不是因为一时挫败就怀疑动摇。

我对自己说：“我依然站在理性和真相这边，这才是最重要的。”这句话成了我的定海神针，让我在迷雾中看清方向。

用知识武装自己。 面对谣言攻击，有时候气急败坏是因为一时间拿不出反驳依据，心里有点虚。知识是最好的镇定剂。

针对“元清非中国”这种奇谈，我去翻了正史和权威论文，确认了元朝在版图和体制上确为中国朝代的一部分，清朝对边疆的治理更是今天中国领土主权的历史基础。掌握了这些知识，再听到类似观点，我心里就非常笃定：“这是错的，我很清楚为什么错。”

那种胸有成竹的感觉，让愤怒转化成了淡定的判断。谣言的魔力在真知面前荡然无存。

强化你的身份认同。 与其让外界动摇你，不如主动强化自己的正面身份。你可以这样定义自己：“我是一个独立思考者，一个理性探索者。”

这个身份是积极而有力量的，不会因别人嘲讽或反智风潮而改变。历史上许多伟大的思想者，都曾在愚昧环境中坚守真理，最终证明他们是对的。做理性声音的少数派并不丢脸，反而是一种责任和荣耀。

而且你要相信，你不是一个人。网上也有很多清醒理性的人在默默辟谣、科普，只是他们的声音常被淹没。去关注支持这些人，和他们互动，你会发现归属感和力量感油然而生。

与世界相处

安顿好自己后，下一个问题是：以怎样的姿态重新面对这个充满嘈杂声音的世界？

有一段时间，我被反智言论搞得心灰意冷，一打开网络就预感要生气。我甚至想过彻底远离这些是非。但冷静下来想想，这不现实——互联网和现实世界并不割裂，网上的乱象终究会影响现实。我需要找到健康的方式与这个世界相处。

优化信息来源。 就像注意饮食健康，你也要注意“信息饮食”健康。梳理你常用的信息来源，把客观可靠、理性克制的媒体和作者权重加大；把博眼球、煽动情绪的账号权重降低或直接取关。

对热点事件学会先等等，别急着下判断，等权威信源出来再说。控制输入就是控制情绪的源头。当你的信息流干净清爽了，心态自然更平和。

用同理心看待他人。 在理解了群体心理机制后，我对那些曾让我愤怒的人多了一些同理心。试着站在普通网民角度想：如果我不了解全部背景，或长期处于某种信息茧房，我可能也会相信类似的东西。

并不是所有拥趸都愚不可及，很多人只是信息不对称、认知受误导，或者情绪上有宣泄需求。这种理解并非为谬误开脱，而是让你用更平和的心态去看待他们。当你怀着同理心，你的语言就不再那么尖刻，有时温和坦诚交流反而更容易让对方听进去一点不同意见。

把愤怒转化为行动。 光在道理层面坚守理性不够，可以把愤怒转化为建设性行动。写科普文章，做小视频，用通俗方式讲解容易被误解的知识。虽然阅读量可能不如爆款谣言，但帮助到几个愿意思考的人，就有价值。

通过这种方式，你不是被动挨打，而是主动出击，为改善舆论环境尽一份力。与其诅咒黑暗，不如点亮蜡烛。

善用AI工具。 这里要介绍一个有意思的研究。2024年《Science》杂志发表了一项研究：让阴谋论信奉者与ChatGPT对话，结果他们的信念平均降低了约20%，效果持续至少两个月，甚至对那些根深蒂固的信奉者也有效。

研究者发现，AI之所以有效，是因为它能针对每个人具体的疑虑，用事实和证据逐一回应，而不是简单说“你错了”。当事实核查人员验证AI的回复时，99.2%是准确的。

这说明什么？如果你身边有人陷入阴谋论或反智思维，与其你自己去辩论（往往吃力不讨好），不如建议他们去问问AI。让AI用耐心、理性、有据可查的方式去解答他们的疑惑。你省了精力，效果可能还更好。

这里还有一个判断标准：如果一个人连跟AI讨论都不愿意，还是死死坚信某些东西，那他坚信的很可能已经不是事实，而是信仰。事实是可以被证据改变的，信仰则不能。对于信仰，你没必要再费口舌。

选择战场，懂得取舍。 并非所有战役都值得亲自上阵。在充满谩骂、注定鸡同鸭讲的场合，就不消耗口舌了；在有人愿意听、讲道理有意义的场合，才投入精力沟通。

与其在公共论坛和陌生喷子对骂，不如把精力用来跟身边家人朋友耐心交流。影响身边几个人的观念，比网上吵赢十场架都有价值。

保持生活的丰富和平衡。 最重要的一点：不要把自己局限于网络舆论这个单一维度。现实生活多姿多彩。工作中追求专业成长，闲暇时发展个人爱好——运动、音乐、旅行，什么都好。

当你跑步或健身后大汗淋漓，那种畅快比在网上争吵有意义多了。生活丰富了，眼界就宽了，不会再把网上的冲突看得过于重大。只有现实中过得充实，你才有资本从容应对虚拟世界的风浪。

结语

好了各位，做个总结。

面对反智内容，你会愤怒是正常的，说明你还在乎真相和理性。但关键是怎么处理这个愤怒。

首先，搞清楚那些内容为什么会火——算法推送、信息茧房、争议红利。理解了这些，你就不会简单地骂“这帮人怎么这么蠢”，而是能用更理性的眼光看待。

其次，学会及时止损。识别情绪信号，果断按下暂停键。不要在无意义的争吵中消耗自己。

然后，重建你的内在锚点。明确你的价值观，用知识武装自己，强化你作为独立思考者的身份认同。

最后，找到健康的方式与世界相处。优化信息来源，用同理心看待他人，把愤怒转化为行动。

说白了就一句话：该坚持的坚持，该放手的放手，别跟自己过不去。

你不可能纠正世界上每一个错误。那些反智言论、阴谋论，不可能靠你一个人消灭。但你也不用太悲观——人类社会发展到今天，科学理性总体上还是在进步的，只是这个过程很慢，有时候还会倒退几步。

你能做的，就是在自己的能力范围内，做一点是一点。影响身边几个人，写几篇靠谱的文章，这些都有价值。别指望立竿见影，但也别觉得毫无意义。

最后，别忘了好好过自己的日子。网上那些破事，看看就得了，别让它真的影响你的生活质量。该吃吃，该喝喝，该工作工作，该陪家人陪家人。你把自己的日子过好了，本身就是对那些乌烟瘴气最好的回应。

好了，今天就说到这里。各位，我们下期再见。

``
特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。
``

0 引言

2025 年，AI 编码助手对许多开发者而言已从“玩具”变成了实打实的生产力工具。然而，要真正用好这些工具，并非简单地抛给模型一个模糊需求就能自动产出完美代码——我们需要一套有章可循的工程化工作流。当前，不少开发者使用 AI 的方式仍很零散：遇到问题临时求助、要功能时即兴生成、想不起用法就问一下。这种碎片化的使用方式带来了不稳定的质量和难以复用的经验。要解决这些问题，需要将 AI 助手的使用从“点状、临时”升级为“系统化协作”。

为什么同样的工具，有些人觉得好用，有些人觉得不好用？ 知名程序员 Peter Steinberger（PSPDFKit 创始人、Clawdbot 创建者）在《The Pragmatic Engineer》播客访谈中观察到一个典型模式：很多人写一个 prompt，丢进 AI，点发送，发现编译不过，于是失望地下结论说“这技术不行”。但他反问：“你真以为人类第一次写代码就能零 bug 吗？” AI 模型本质上是人类集体知识的幽灵，工作方式和我们非常像——第一次出错很正常，所以你才需要反馈闭环。与 AI 协作不是发一个 prompt 就完事，而是开启一段对话。这本身就是一项需要学习的技能，本指南的目标，正是帮助你系统性地掌握这项技能。后续章节将多次引用 Peter 的访谈——作为深度使用 AI 工具的资深开发者，他分享了许多宝贵的实战经验和心态转变。

本指南的目标是帮助开发者构建一套可复制、可控、可验证的 AI 编程工作流，以 Cursor 编辑器为核心工具。我们将借鉴经典的软件工程理念和最新的 AI 编程实践，将 AI 视为一名强大的“结对程序员”而非全自动的代码生成机器。整篇指南围绕 Plan-Execute-Verify（计划-执行-验证） 这一核心循环展开，强调工作流思维而非零散的工具技巧。正如《程序员修炼之道》所倡导的，好的开发实践重在思维方式和过程控制——在 AI 时代这一点更加重要。本指南将向读者展示如何像训练新同事一样“训练” AI 助手，与其协作编程，并最终达到提升效率而不降低代码质量的目的。

接下来，我们将首先介绍 AI 编程协作的思维框架，然后依次深入工作流中的各个关键环节：如何规划任务、构建最小闭环迭代、制定控制策略、管理上下文、撰写高效提示词、进行测试验证，以及如何沉淀项目资产并持续训练提升。让我们开始这一段“AI 工作流修炼”的旅程，把 AI 从简单助手升级为真正的智能工作流引擎。

1 工作流思维框架：Plan-Execute-Verify

要在 AI 协作编程中取得成功，首先需要转变思维，从“让模型一次生成大量代码”转向 Plan-Execute-Verify（计划-执行-验证） 的迭代循环。这一框架对应了软件开发的基本过程：先规划设计，再编码实现，最后测试审查。

1.1 Plan（计划）

在编写任何代码之前，先弄清楚要做什么。很多人使用 LLM 写代码的误区是一上来就要求模型输出大段实现，而没有讲清需求。正确的做法是花足够的时间梳理规格——明确需求、约束、边界条件，并让模型针对这些细节提出澄清问题。这一阶段的成果可以是一份结构化的规划文档（如 spec.md 或 Cursor 的 Plan 模式生成的 Markdown 计划），其中写明需求描述、架构设计、数据模型、依赖项、测试策略等关键要素。研究表明，有经验的开发者更倾向于在生成代码之前先规划，这能帮助我们更清晰地思考要构建的内容，并为 AI Agent 提供明确的目标。一句话，先做“15分钟的微型瀑布开发”——在真正写代码前，用很短的时间完成结构化的规划，让后续编码更顺畅。

1.2 Execute（执行）

明确计划后，进入编码执行阶段。将大任务拆解为小步骤，逐步实现。每次只让模型完成一个子任务，例如根据计划里的第一个步骤编写相应代码。Cursor 提供了强大的 Agent 智能体，可以根据你的指令编辑代码、创建文件、修改项目。在执行过程中，充分利用 Cursor 的功能，如自动补全（Tab 模型）和 Agent 模式来加速编码。但无论 AI 写多少代码，记住你才是总指挥——决策每一步是否采纳、如何调整。执行阶段的关键是在严格按照计划的前提下，让 AI 发挥生成代码的威力，同时随时监控其行为，不让它偏离预期。

1.3 Verify（验证）

无论 AI 的回答看起来多么自信、生成的代码看起来多么完善，你都必须对其进行验证和测试。将 LLM 当作一个特别聪明但容易犯错的初级工程师——你需要审查每一个关键步骤，决定是否接受修改。验证包括多方面：

• 自己阅读代码逻辑并理解关键分支
• 编写并运行测试，验证行为符合预期
• 对重要的改动执行认真的 Code Review（可结合人工和另一种模型审查）

如果发现问题，就进入下一轮的循环：调整计划或提示，重新执行，再验证，直到满意为止。这个持续反馈闭环确保了代码质量的可控和可验证。

1.4 小结：闭环而非直线

以上三个阶段并非线性执行完毕，而是不断交替循环。Plan-Execute-Verify 构成了 AI 协同编程的最小闭环，可以不断嵌套和迭代。通过这样的循环，我们避免了“一股脑让模型生成整个应用”而失控的情况。相反，我们以小步快跑的方式，在每个小周期内保持对方向和质量的掌控。这种方法既借鉴了传统敏捷开发的小步迭代思想，也融合了 AI 工具的特点，是一种 AI 增强的软件工程方法论：AI 帮助我们更快地产出代码和方案，而我们确保每一步都在正确的轨道上前进。

在接下来的章节中，我们将首先探讨与 AI 协作所需的心态转变，然后详细阐述如何在实际开发中落实 Plan-Execute-Verify 框架的各个环节。

2 AI 协作心态

Plan-Execute-Verify 是一个结构化框架，但要真正用好它，还需要正确的心态。很多开发者使用 AI 不顺利，不是因为工具不好或技术不行，而是思维方式不对。本章探讨与 AI 协作时需要具备的几个核心心态。

2.1 对话而非指挥

在实际操作中，有一种更自然、流动的方式来实现 Plan-Execute-Verify。Peter Steinberger 在访谈中分享了他的做法：

有一点很多人没意识到：你不是在”指挥”它，而是在跟它对话。我会说：”我们看看这个结构，有哪些选项？这个特性考虑过没有？”因为每一轮对话开始时，模型对你的产品一无所知，你得给它一些指引，让它去探索不同方向。你不需要什么 plan mode，我就是一直聊，直到我说”build”，它才真正开始构建。有一些触发词——它们确实挺”急”的——但只要我说”我们讨论一下”或者”给我一些选项”，它们就不会动手。

这段话揭示了一个重要的认知转变：与 AI 协作不是发号施令，而是结对探索。

很多开发者使用 AI 的方式是“指挥式”的——上来就说“帮我写一个用户登录功能”，然后 AI 立刻开始写代码，写出来不对再改，改来改去越改越乱。而 Peter 的方式是“对话式”的：先和 AI 讨论结构、探索选项、确认特性，在说“build”之前，一直保持在探索状态。

这种方式背后有几个关键洞察：

“零认知”问题：每一轮对话开始时，AI 对你的产品、上下文、偏好都是一无所知的。如果你上来就让它执行，它只能靠猜测。而“给它一些指路标志”，就是在帮它建立认知，让它的输出更贴合你的预期。

延迟执行：AI 模型确实很“饥渴”——它们倾向于立即行动、立即输出代码。但你可以用语言来控制这种倾向。当你说“我们讨论一下”或“给我一些选项”时，AI 会进入探索模式而非执行模式。这是一种软性的 Plan mode，不需要切换任何设置，只需要用对话引导。

触发词作为阀门：你可以把一些短语当作“阀门”来使用：

• “我们讨论一下” → 保持探索，不要动手
• “有哪些选项？” → 列出方案供选择
• “这个特性考虑过没有？” → 引导它思考边界情况
• “build” / “开始实现” → 正式进入执行阶段

这种方式与结构化的 Plan-Execute-Verify 框架并不矛盾，而是一种更“有机”的实现。本质上都是延迟执行、先思考后动手，只是形式不同——一个是显式的阶段切换，一个是通过自然对话来引导。选择哪种方式取决于个人风格：喜欢清晰流程就用正式的 Plan 模式，喜欢自然交流就用对话控制节奏。两者目的相同：确保 AI 理解清楚后再动手，而不是盲目写代码。

2.2 雕塑式构建：让形状从过程中浮现

除了“对话而非指挥”，Peter 还分享了另一个深刻的构建哲学：

我见过很多人一上来就搭建复杂的编排层：自动创建工单、Agent 处理工单、Agent 再给另一个 Agent 发邮件……最后弄出一堆精致的混乱。何必呢？他们花好几个小时设计 spec，然后让机器用一整天把东西”造”出来。我不看好这种做法——本质上还是瀑布式开发，我们早就知道那条路走不通。

我的构建方式是一路向前，很少回滚，更像是雕塑：从一块石头开始，一点点凿，让雕像慢慢从大理石中浮现。这就是我理解的”构建”。

这个雕塑比喻揭示了两种截然不同的构建方式：

为什么复杂编排层是陷阱？ 因为它本质上还是瀑布式思维——先设计完美的系统，再让机器执行。但我们早就知道瀑布式的问题：需求会变、理解会演进、最初的假设往往是错的。AI 时代更是如此——你不可能在动手之前就知道 AI 能做到什么、不能做到什么。

Peter 还强调了一个很多流程里缺失的东西：

我得去点、去摸、去感受。好软件需要”品味”，而这恰恰是很多流程里缺失的东西。

“品味”无法自动化。那些复杂的编排层追求的是效率和可复制性，但好软件不只是“能跑”——它需要你亲手触摸、反复感受、持续打磨。AI 可以帮你生成代码，但“这段代码好不好”的判断，需要你自己去“点、摸、感受”。

这种“雕塑式构建”的心态，本质上是把自己定位为创作者而非管理者：我不是在管理一个系统，我是在创造一个作品。米开朗基罗说过：“雕像本来就在石头里，我只是把多余的部分凿掉。” 与 AI 协作时，最好的作品往往也是这样“浮现”出来的——不是按图施工，而是在不断的对话和迭代中，让它逐渐成形。

2.3 心态是最大的门槛

以上讨论的“对话而非指挥”和“雕塑式构建”，本质上都是心态问题。很多开发者使用 AI 不顺利，不是工具不行或技术不熟，而是用错了思维方式——期望 AI“一步到位”，一个 prompt 就得到完美结果，不行就下结论“这技术不行”。

但正如 Peter 所说：“你真以为人类第一次写代码就能零 bug 吗？”AI 协作是一门需要学习的新技能，就像从吉他转到钢琴，需要时间适应。你越理解这些“小野兽”的思维方式，就越擅长与它协作。

关于心态转变和技能提升，我们会在第 10 章“持续训练与提升”中进一步深入讨论。现在，让我们带着正确的心态，进入实操环节。

在接下来的章节中，我们将详细阐述如何在实际开发中落实 Plan-Execute-Verify 框架，包括如何拆解任务形成最小闭环迭代、有哪些控制策略可保证 AI 输出受控、如何管理上下文避免信息混乱、怎样撰写高质量提示词引导 AI，以及如何进行测试验证和沉淀项目资产。每一部分都会给出具体可行的步骤、提示语模板和最佳实践，帮助你逐步建立起自己的 AI 编程工作流。

3 构建最小闭环

最小闭环指的是在开发中构建小型 Plan-Execute-Verify 循环，使每个循环都能产出可验证的结果（如通过测试的功能或修复）。与其让 AI 一次性生成庞大代码，不如将工作拆解成小块、迭代推进。LLM 在处理小而清晰的任务时效果最佳，而在“一次性写完整个应用”时往往会失控。因此，我们要学会像整理待办清单一样，将整体需求分解为一系列可以闭环的子任务，并逐一完成。

在讨论具体实践之前，先分享一个反直觉的策略。Peter 在访谈中提到：

我通常从一个想法开始，甚至会故意”欠提示”Agent，让它做点出乎意料的事，给我新灵感。可能 80% 的结果不怎么样，但总有一两个点让我意识到”这个角度我没想过”。然后我不断迭代、打磨。

现在的好处是：功能太容易生成了，不行就扔，或者换个提示词重来。

这段话包含了两个重要洞察：

“欠提示”策略：大多数人追求“精确的 prompt”——把需求描述得越清楚越好，让 AI 完美执行。但 Peter 的做法是故意留白，让 AI 有空间给他惊喜。为什么？因为你不知道自己不知道什么。如果你把所有细节都规定死了，AI 只会给你“你已经想到的东西”。而留白，可能会得到“你没想过的角度”。当然，80% 的结果可能不行——但这引出了第二个洞察。

试错成本极低：AI 时代最大的礼物是“功能太容易生成了，不行就扔”。以前写一个功能要几小时甚至几天，扔掉心疼。现在 AI 几分钟就能生成，不行就重来。这彻底改变了“试错”的经济学——你不需要第一次就对，只需快速迭代、不断逼近。

这正是“最小闭环”的哲学基础：不追求一次完美，而是追求快速验证、快速调整。每个闭环都是一次“凿石头”的动作——可能凿对了，可能凿歪了，但只要闭环够小，歪了也能快速修正。

3.1 具体实践

1. 拆分任务：将你的需求或用户故事拆分成独立的小步骤，每个步骤都有明确的目标输出。比如，如果你在开发一个博客系统，不要一次性让 AI 写完所有功能，而是拆成“实现用户注册模块”、“实现文章发布模块”、“实现评论功能”等。再细一点，每个模块又可细分：例如“实现用户注册模块”可以进一步拆解为“设计用户数据模型”、“编写注册接口的单元测试”、“实现注册接口逻辑”、“对接第三方邮箱验证”等等。
2. 计划每个子任务：对于每个小任务，先和 AI 一起制定一个简短计划。你可以直接告诉 Cursor Agent：“按照计划的第 1 步，实现 XX 功能”。如果这个任务稍复杂，可以进入 Plan 模式（Shift+Tab）让 Agent 生成一个实施计划，其中包含相关文件、修改点等。你可以审核这个计划，删除不必要的步骤或补充遗漏的信息，然后再让 Agent 执行实现。很多时候，对于很小的改动或你非常熟悉的任务，可以直接跳过详细计划，让 Agent 立即处理；但对于较复杂的任务，提前规划会让后续执行更顺利。
3. 执行并完成子任务：让 Cursor Agent 根据计划或你的指令编写代码。务必一次只执行一个子任务，避免在一个对话里同时要求 AI 做太多事情。这样做有两个好处：其一，AI 在一个狭小明确的范围内工作时，输出的代码更可靠、更易于理解；其二，方便你在每个任务完成后进行验收和调整。当 Agent 完成代码后，查看 diff 或生成的文件，确认它基本满足了当下子任务的预期。
4. 验证子任务结果：在接受 AI 的改动之前，先进行验证。这可以包括运行该子任务相关的测试（如果你提前编写了测试用例，最好现在运行看看是否通过），或者手动执行一下关键路径。确保这个小任务的输出没有明显问题。如果有测试未通过或者质量不满意，不要急于进入下一个任务，而应先修正当前任务的结果。你可以直接提示 AI 修复错误，例如：“测试 X 失败，错误信息如下，请根据错误修正代码”，或利用 Cursor 的调试功能定位问题然后再让 AI 修复。每个子任务结束时，都要达到“验收”标准：要么通过所有相关测试，要么经人工检查认为没有问题。
5. 反馈和迭代：如果子任务结果不理想，与其在当前基础上反复让 AI 勉强修补，不如回到规划阶段重新审视。你可以撤销刚才 AI 的改动（Cursor 提供撤销/还原功能，或直接利用 Git 回滚），然后根据失败的情况调整计划或提示，把需求描述得更具体明确，再让 AI 重试。通常，相比在错误的实现上修修补补，重新规划并执行会得到更干净的结果。
6. 小步提交：当一个子任务顺利完成后，将修改提交到版本控制（git）。保持小步提交、频繁提交，可以将每个闭环的成果都保存下来。这样一来，如果后来发现某次改动引入了问题，可以通过 git 历史快速定位并回滚。同时，一个清晰的提交历史本身也是极好的项目文档和上下文，下次让 AI 阅读提交信息或 diff，它可以理解你的项目演进过程。我们稍后在“控制策略”部分还会详细谈 git 的作用，这里先养成习惯：每完成一个闭环就提交，为下一个闭环做好干净的起点。

通过以上步骤，我们实现了以最小可验证单元为粒度的迭代开发。这种方法比让 LLM 一次生成一大块代码稳健得多——正如许多开发者的教训：“一次性让 LLM 生成整套应用，结果就像 10 个人各写一块、从未对齐过风格的代码”，而小步迭代 + 每步验收则能确保一致性、减少返工。在这个过程中，其实我们已经把传统的软件工程实践（如模块化、单元测试、持续集成等）融入到了 AI 协作中，每一轮 Plan-Execute-Verify 都是一个闭环，保证了输出的可靠性。

值得一提的是，Cursor 提供了一些强大的功能，可以帮助我们自动化这个闭环。比如，你可以利用 Agent Skills 和 Hooks 特性，使 Agent 不断循环迭代直到达到目标。官方博客提供了一个示例：通过编写 .cursor/hooks.json 和脚本，让 Agent 不断尝试修复直到所有测试通过。脚本会检测当前会话状态，如果测试未通过且迭代次数未超限，就让 Agent 继续下一轮：“继续工作，完成后在 .cursor/scratchpad.md 标记 DONE”。这种模式非常适合让 AI 自动反复执行，直到满足某个可验证条件（例如测试全绿、UI 与设计稿一致等）。不过在实践中，建议一开始先手动执行几个闭环循环，熟悉模式后再尝试引入这种自动化“研磨”技能。无论是否使用自动循环，核心理念都是一致的：让每次 AI 产出都形成一个闭环，要么达标，要么失败就反馈调整，决不在未验证的半成品上堆积更多产出。

通过构建最小闭环，我们实现了“短反馈回路”——AI 生成代码 → 立即验证 → 及时纠偏。正是这样高速的反馈，让 AI 生成的代码质量逐步接近人类水准，同时开发者始终对结果保持可控可知。在下一个章节中，我们将讨论如何进一步控制 AI 编程过程中的方方面面，确保整个工作流在我们的掌控之下。

4 控制策略

即使有了良好的规划和小步迭代，AI 编程仍然需要一系列控制策略来保证输出质量和过程可控。可以把这些策略看作是给 AI 这位“智能实习生”制定的纪律和护栏，确保它按照我们的预期工作，而不会“自由发挥”地引入风险。下面从多个角度介绍在 Cursor 工作流中可以采用的控制手段。

4.1 人不离场：Human-in-the-loop

首先也是最重要的一点：确保人始终参与决策，不要对 AI 生成的代码掉以轻心。尽管 AI 助手能显著提高效率，但责任终究在我们自己。把 AI 当作一个特别聪明但容易出错的初级工程师，这意味着：

• 不要盲目信任任何一段 AI 给出的代码，即使它语气自信、表面正确。至少要做到：自己过一遍 AI 生成的代码逻辑，理解每个关键分支；跑跑单元测试或集成测试，验证行为是否符合预期；对重要改动进行认真的 Code Review，必要时请团队同事或另一个模型帮忙审查。总之，在你亲自检查之前，不要让 AI 的代码直接进入生产。
• 人工随时有权叫停。Cursor 在 Agent 执行过程中提供了实时 diff 预览功能，如果你发现 Agent 的修改方向明显不对，可以立刻按下 Esc 键中断它。比如你让它修一个小 bug，它却开始修改大量无关文件，这时果断停止比任由其完成再回滚要高效得多。中断后，分析它偏离的原因，调整提示（或者干脆重新从 Plan 开始），再尝试执行。
• 明确分工：让 AI 多干机械重复的事，但关键决策点一定要人工拍板。AI 可以帮你写代码、跑测试、生成报告，但例如采用哪种架构方案、某个性能权衡的取舍、是否发布上线等决策，应当由有经验的你来决定。你可以让 Agent 提供选项和分析，但最后的决定请由人来做。

4.2 版本控制与隔离

良好的版本控制习惯是 AI 编程的重要安全网。当 AI 能短时间内生成大量代码时，只有细致的版本管理才能帮助我们快速止损和追溯。实践准则：

• 频繁小提交：正如前文所述，每完成一个小任务就做一次干净的 commit。Commit 信息写清楚做了什么改变。这样不仅便于日后查找问题，也方便你把 git diff 提供给 AI 让它基于变化做分析和改进建议。例如，如果某次提交引入了 bug，你可以复制该 commit 的 diff 内容，提示 Cursor Agent：“根据以下 diff，找出潜在问题并尝试修复”——由于 commit 粒度小，这样的上下文 AI 是能看懂并给出针对性建议的。
• 使用分支/Worktree 隔离实验：对于较大的功能开发或者尝试性改动，不要在主线上直接大规模应用 AI 建议，可以新建一个分支甚至 Git worktree 来隔离这些改动。Cursor 实际上对 Git worktree 有原生支持，它会为每个并行运行的 Agent 自动创建独立的 worktree，使得多个 Agent 可以各自编辑、构建和测试，而互不干扰。你也可以手工创建分支，在分支上大胆让 AI 重构或生成新模块。如果发现走偏了，直接放弃该分支即可，不会影响主线代码。
• 利用 Git 历史回滚：当 AI 的修改导致项目进入不稳定状态时，不要陷在错误状态里硬改，可以借助 Git 快速回滚到之前的稳定版本，然后从那里重新开始。Cursor 编辑器内置了 “Revert Changes”/检查点等功能，可实现类似效果。不过正如一些用户指出的，Cursor 的临时检查点毕竟不如显式的 Git 历史可靠。因此，推荐还是以 Git commit 为主要的“存档点”，必要时通过 git reset 或 git revert 来恢复过来，这比让 AI 在一团乱麻的错误状态中尝试修补要高效和稳妥得多。

4.3 规则与规范约束

AI 再智能，也无法凭空理解你项目特有的架构约定、编码规范、业务禁忌。这就需要我们主动提供规则和示例来“调教”AI，使其行为符合团队预期。正如你会给新入职的同事发一份团队开发规范文档，AI 也需要类似的“入职培训”。

Cursor 提供了 Rules（规则） 机制来实现这一点。你可以在项目的 .cursor/rules/ 目录下创建 Markdown 规则文件，为 Agent 提供持续生效的指令。规则可以涵盖：

• 项目中的常用命令：例如如何构建、如何运行测试、如何启动应用等。把常用脚本命令写进去，当 Agent 需要时就会参照使用。
• 代码风格和约定：例如使用何种模块系统，变量命名风格，有没有不允许使用的 API，组件放在哪个目录，等等。不要整篇风格指南都复制进去，抓重要的点，并引用项目里现有的示例文件而不是复制其内容。这样规则文件简洁且不会随着代码演进而过时。
• 工作流程相关：例如每次更改后要不要跑 typecheck、API 路由应该放在何处、哪些模式应该遵循既有模式等等。

撰写规则要注意聚焦重点，避免过度啰嗦。从简单开始，先建立 5-10 条核心规则即可。只有当发现 Agent 重复犯某类错误时，再把对应指导加到规则里。切忌一上来就给它一份巨长的说明试图涵盖所有情况，那样效果适得其反。规则文件本质上相当于每次对话的系统提示，内容太多反而淹没了关键信息。

共享规则：将 .cursor/rules/ 纳入版本控制，团队成员都可以受益。当某人发现 AI 在某方面反复出错时，可以更新相应规则。甚至在 GitHub 的 issue 或 PR 里，可以 @ 提示 @cursor 让 Agent 帮忙更新规则。这样团队经验会逐步固化下来，新人和 AI 都能遵循统一规范，减少因风格不一致带来的摩擦。当项目规则集逐步完善后，你会发现 AI 输出的代码与团队习惯高度一致，几乎看不出是机器生成的。

除了规则，示例代码也是极好的约束方式。LLM 非常擅长模式模仿，如果提供高质量的示例，它更容易生成风格一致、符合规范的代码。因此，在具体任务提示中，不妨多给 AI 展示“范例”：

• 提供参考实现：例如让它实现某个新功能时，先贴上一段项目里类似功能的代码，告诉它“请按照上述代码的风格实现…”。这样 AI 会在潜意识里模仿这个示例，输出的代码更符合你的期望。
• 明确禁止事项：如果你知道某些解法是不可取的，可以直接在提示里说明“不要采用 XXX 方式”或提供一个反例让它避免。例如“这里不能使用递归，会栈溢出”或“不要调用内部未公开的 API”。这样能让 AI 少走弯路。

4.4 动态调整和多模型协同

在使用 AI 编程时，还需要根据具体情况灵活调整策略，包括切换模型、引入额外检查等：

• 更换或组合模型：不同的 LLM 各有所长，有的善于解释和文档生成，有的在大代码库重构上更稳定。当一个模型频繁卡壳或输出质量一般时，尝试换用另一个模型试试。Cursor 支持同时选择多个模型运行同一个提示，并将结果并排比较。你甚至可以让模型之间互相审核：用模型 A 生成代码，再让模型 B 来审查提问题。这种“AI 审 AI”的方式常能发现单一模型容易遗漏的细节。Cursor 内置的 Agent Review 就体现了这个思想：Agent 完成后，可以点 Review → Find Issues，运行一次专门的审查流程，Agent 会逐行分析修改并标记潜在问题。利用不同模型的视角，可以提高错误发现率。
• 新对话还是继续：当一个对话进行太久，模型可能进入思维定式或引入大量无关上下文噪音。一般来说，如果你要开始一个不同的任务，或者感觉 Agent 有点糊涂总犯同样的错误，那就开启新对话。新的对话会清空旧的聊天记录，只保留规则等静态提示，从而让 AI 有个干净的思考空间。如果只是对同一个功能做小改动、调试刚生成的内容，且需要引用前文上下文，则可以继续当前对话。一个经验法则是：对话越长，越可能飘移。所以当你感觉 AI 回答开始偏题或者无视你的指令时，很可能是上下文干扰在作怪，不妨重启对话，从最新状态总结关键信息重新提供给它。
• 及时重置与澄清：AI 有时会“钻牛角尖”——无论你怎么提示都围着先前一个错误思路打转。这时，与其反复提示，不如彻底重置上下文。在 Cursor 中开启新 Chat，然后使用 @Past Chats 功能，引用之前对话的重要部分（例如最终的需求描述或设计结论），跳过那些错误的尝试过程。Agent 可以有选择地读取过去聊天记录，只提取需要的上下文。这比把整段对话复制过来高效得多，也避免旧有错误思路的干扰。此外，如果 AI 对你的意图明显误解，与其越纠结越乱，不如停下来澄清需求：再次明确你想要什么，让 AI 完全重新考虑。这就是前文提到的“从计划重新开始”策略的另一种表述。
• AI 也需要 Debug：当 AI 反复输出错误代码时，不妨转换思路，让它自己也参与进来分析问题。比如“请解释一下为什么你生成的实现没有通过测试”或者“逐步调试上面的代码，找出逻辑错误”。让 AI 进入分析师模式而非生成模式，有时能更好地找出问题。如果效果不佳，可以考虑换个角度提问或者换模型。很多时候，另一个模型可能立即看出问题所在。这就像团队里让不同的人 Review 代码一样，有时新人看问题反而清晰。
• 手动介入引导：不要忘记，你可以随时亲自修改代码然后再交给 AI 继续。例如当 AI 在一个小地方卡壳反复错误，你完全可以手动修正那几行，然后告诉 AI：“我修改了 X 部分，剩下的你继续完善”。AI 对你给出的正确部分通常不会再改，而是专注于未完成的部分继续。人机协作不一定是纯粹的提示-回答模式，直接改代码也是种高效的沟通。
• 规模控制：AI 在面对超大文件或无结构任务时容易失控。一个实践经验是：限制单次处理的代码规模。比如当某个文件超过 400 行时，可以考虑让 AI 将其拆分成更小的模块。你可以提示：“这个文件太长了，请通过提炼功能将部分逻辑拆到新文件中”。这样一来，AI 处理每个文件的逻辑范围减小，理解和生成都会更准确。同样地，如果一个任务涉及太多步骤，不妨人为拆解成多个 Chat 分别处理。控制问题规模在很多情况下能避免 AI “思路混乱”或输出质量下降。

4.5 自定义工作流与成本控制

随着对 Cursor 的深入使用，你可能希望把自己的一套开发流程固化下来，让 AI 按你的流程来工作，而不仅仅是被动响应提示。Cursor Nightly 版本提供了 Custom Modes（自定义 Agent 模式）实验功能，允许我们为 AI 定制一套专属的工作规则和行为模式。通过编写详细的规则文档，你可以让 AI 具备系统性思维，按照预设的多阶段流程来与你交互。

举例来说，传统模式下你对 AI 说“帮我写一个用户登录功能”，AI 可能直接就开始写代码了。而启用自定义 Agent 后，AI 可能先回答：“我理解您需要开发用户登录功能。让我先进入需求分析阶段，深入分析这个功能的背景…”，然后按照你定义的阶段一步步来，例如先问需求细节，再设计数据结构，再编写代码，最后自检输出。这实际上是将我们在 Plan-Execute-Verify 框架下进一步细分、标准化，让 AI 严格按照工作流执行。

当然，自定义工作流也面临另一个现实问题：交互轮次成本。标准化流程通常意味着渐进式推进，每个阶段都需要人确认再进入下一阶段。多阶段交互可能消耗大量的提示请求次数。在 Cursor 中，如果每月只有一定配额的调用次数，一个完整复杂功能走完流程可能相当“烧 token”。针对这一点，一些高级用户探索了“一次请求内的多次交互”技巧（Feedback MCP 等）。简单来说，就是借助 Cursor Agent Skills，让 AI 在一次用户提示中自行执行多轮对话的效果。例如你发送一个特殊指令，AI 可以在后台循环调用自己，直到完成某个条件为止，然后把最终结果一次性返回给你。这样做可以极大减少人为来回确认的步骤，从而降低交互成本。不过这属于相当高阶的用法，需要编写脚本和熟悉 Cursor 扩展接口，这里不展开。对于大部分开发者来说，更实际的做法是合理规划每次对话要完成的内容，尽量减少无效来回。如果担心次数不够用，可以考虑升级更高的订阅方案或者使用本地模型辅助一些工作。在成本与效率之间，需要找到平衡。

总之，通过以上种种控制策略，我们可以极大程度地避免 AI 编程过程中的“走偏”和“失控”情况。就像经验丰富的导师带新人一样，我们既要给 AI 足够的自主发挥空间，让它展示智能的一面；又要设定明确的规则和随时指导，在必要时果断纠正。应用这些策略后，AI 将真正成为我们可控的工具，而不是一个不可预测的黑盒。下一节中，我们将讨论如何管理上下文信息，让 AI 始终“看得到”完成任务所需的所有关键资料。

5 上下文管理

上下文（Context）指 AI 在生成代码或回答问题时所能获取的所有相关信息，包括当前项目的代码、相关文档、之前的对话内容等。高效管理上下文——既让 AI 获取充分信息，又避免噪音干扰——是 AI 编程工作流的重要一环。

5.1 让 AI 找到所需的信息

Cursor 的 Agent 具有强大的代码搜索和浏览能力，因此你通常不需要在提示里手动贴上所有相关代码片段——它可以自行获取上下文。比如当你询问“身份验证流程（authentication flow）”时，Agent 会自动在代码库里用 grep 和语义搜索寻找相关文件，即使你的提示里没有出现精确的文件名。Cursor 内置的即时代码搜索工具可以在毫秒级完成代码库扫描。这意味着在大多数情况下，你可以直接用自然语言提问，AI 自会去查找涉及的模块。例如你问“登录功能的实现在哪里”，它会定位到 AuthService 或相关的代码文件然后回答。

然而，让 Agent 自由搜索并不意味着我们就可以撒手不管。要注意以下几点：

• 避免过载信息：如果你已经清楚知道相关的文件或函数名字，在提示中明确提及它们。例如：“请修改 user_controller.rb 中的登录逻辑，确保密码错误 3 次后锁定账户。” 这样 Agent 会直接关注该文件的内容。而如果你不知道具体在哪里实现，也不要猜测贴一堆无关文件，直接告诉 Agent “请查找登录流程相关的代码”就好——它自然会去搜。不相关的文件可能让 Agent 混淆重点，所以上下文越精准越好。
• 利用 Cursor 特殊引用功能：Cursor 提供了 @ 引用语法来精确提供上下文。你可以在提示中用如 @file(filename)、@folder(foldername) 或 @code(symbol) 来引用特定文件、文件夹或代码符号。这样 Agent 在处理提示时会优先查看这些内容。例如，你可以对 Agent 说：“请查看 @file(services/AuthService.ts) 中的 login 方法，并修改为使用新的加密算法。” 这等价于把该文件内容作为上下文提供，Agent 会据此进行改写。精确引用可以大幅提升 AI 理解问题的准确度，尤其当项目较大时，这比它漫无目的搜索效率高得多。
• 代码库索引：对于非常庞大的项目，Cursor 提供了 Codebase Indexing（代码库索引）功能。开启后，Cursor 会在本地为整个项目创建嵌入索引（embedding），以提升跨文件回答的质量。这样 Agent 可以更“理解”代码库的结构和依赖关系。不过请注意，索引创建和更新需要一些时间，而且索引数据会上传存储在云端（但代码本身仍保存在本地，不会上传）。如果你的项目对隐私要求很高，可以考虑不开启此功能，转而通过手动引用或逐步搜索的方式提供上下文。

5.2 控制对话上下文

除了项目代码上下文，AI 对话本身的上下文管理也很关键。随着对话轮数增加，以前的聊天内容也会占据上下文窗口。Cursor Agent 的上下文窗口虽然较大，但不是无限的，过长的对话可能让早期内容被遗忘或被模型弱化处理。同时，长对话中往往混入了很多历史噪音，可能干扰模型的判断。因此我们需要策略性地管理对话过程中的上下文：

• 分阶段启动新对话：在任务切换或 AI 出现困惑时，可以考虑开启一个新对话。新对话会重新加载规则和关键静态提示，但不包含旧对话的聊天记录。你可以在新对话的开头，简要说明现在的上下文是什么。例如：“之前我们完成了用户注册功能的开发，现在开始新的任务：实现用户登录。以下是用户注册模块的接口定义：…” 通过这种方式，你人为控制了上下文的重置，确保 AI 不会因为前一话题的残留内容而跑题。
• Past Chats（引用过往对话）：Cursor 提供了非常方便的 @Past Chats 功能，让你在新对话中引用之前的对话内容。与其一次性复制整个聊天记录，@Past Chats 可以引用某次过去对话的标题或编号，然后 AI 会按需读取其中相关的部分。这相当于给 AI 提供了一个可查阅的知识库，它可以选择性提取需要的上下文，不会引入无关内容。这对长周期开发非常有用——你可以把某些重要决策、结论或者设计细节放在一个对话里，必要时在以后的对话中引用它，而不必每次从头解释。
• 维护上下文简洁：在同一个对话里，也要注意保持每次交互提供的信息足够简洁明了。尽量在一次提示中集中说明当前需要 AI 关注的重点，而不是扯入很多次要细节。如果本次任务只涉及后端，就没必要把前端代码片段贴进去；如果只修改配置文件，就无需加载整个项目结构。许多经验丰富的用户甚至会维护一个“知识库文件”，每遇到 AI 犯的新错误就记录下来，下次提示时把这个知识库也附上。例如建立一个 knowledgebase.md 文件，里面写着项目的重要背景信息和已知陷阱，每次提问都 @file(knowledgebase.md) 引用一下。这样 AI 每次都有那些关键知识做支撑，就不容易再犯同样错误。当然，这有点类似手动的做法了——Cursor 的规则和技能体系从机制上提供了更优雅的上下文注入手段（规则等同于始终附加的知识库）。无论用什么方法，目标都是让 AI 手头的信息既不缺乏也不过载：该给的一定给，不该看的不要给。
• 外部资料引入：在某些情况下，任务所需的信息不全在代码里。例如要使用一个新库，而 AI 并不了解它的细节；或者涉及业务逻辑，需要参考需求文档。Cursor 支持将外部文档纳入上下文。在设置里，你可以添加一些 URL 或本地文档作为参考资料，让 AI 在回答时参考这些内容。另外，通过 Model Context Protocol（MCP），Cursor 可以与外部工具集成，例如 Slack、Confluence、数据库等，把那些来源的数据作为上下文提供给 AI。举个例子，你可以接入一个 Slack MCP，让 AI 能够读取某个 Slack 频道的聊天记录；或者接入一个 Figma MCP，让 AI 读取设计稿图片。这样，当你说“按照设计稿实现 UI”时，AI 就真的能看到设计稿细节了。这属于上下文扩展的高级玩法，对于需要综合多源信息的任务非常有帮助。引入外部资料的原则仍然是不滥用——只在需要的时候才添加，并确保提供的是可靠信息源。

总之，良好的上下文管理能让 AI 如虎添翼——在需要时迅速获取相关信息，而不被无关细节迷惑。开发者要对项目结构和知识来源了然于心，学会使用 Cursor 的各种上下文机制（代码搜索、@ 引用、Past Chats、规则/技能、MCP 等）。做到这一点，AI 就仿佛随时站在你肩膀上看着同样的资料，与你同步思考。下一章，我们将讨论如何编写高质量的提示词，最大化引导 AI 输出我们想要的结果。

6 提示词技巧

人与 AI 的交流是通过 提示词（prompt） 来完成的。提示词的质量直接决定了 AI 输出的质量。写提示词就像给同事下任务描述，讲究清晰、准确、上下文充分，还要考虑对方（AI）的“性格”和能力范围。下面，我们总结一系列编写高效提示词的技巧、模板和实例，帮助你更好地驱动 Cursor Agent 完成编程任务。

6.1 明确需求，避免含糊其辞

正如前文所述，许多开发者在使用 AI 时的误区是给出模糊的指令，比如“帮我写个登录功能”，然后希望 AI 猜出一切。提示词的第一要义是清晰明确。这包括：

• 说明要做什么：开门见山地描述需求或任务。例如：“实现一个新的用户登录 API，包括用户名密码校验、JWT 生成和错误处理。” 比 “帮我写登录功能” 要明确得多。
• 指出范围和目标：如果任务有明确边界，一定要说明。如“修改 OrderService 中的 createOrder 方法，使其支持优惠券折扣”，限定了修改范围和目标功能。
• 提供背景：如果需求依赖某些背景假设，要在提示中说明。例如：“我们的应用使用 DDD 架构，订单聚合根在 Order 类，实现新的折扣逻辑时需遵循聚合规则。” 这些信息能防止 AI 提供违背你架构原则的方案。

实践中，一个有效的方法是在提示开头先给出一段背景描述，然后再提出具体任务。比如：

我们的电商平台使用微服务架构，订单服务负责订单创建和支付。当前 OrderService#createOrder 方法没有考虑优惠券折扣。

任务：修改 OrderService#createOrder 方法，使其在计算总价时考虑优惠券折扣。如果请求中提供有效优惠码，则按优惠规则扣减相应金额。

要求：保证订单总价不低于 0，所有折扣逻辑放入 CouponService 处理，不要在 OrderService 中硬编码。

像这样结构化的提示包含了背景、任务和具体要求，AI 几乎不可能误解你的意图。

6.2 提供充分的上下文与约束

在提示词中，尽可能提供与任务相关的现有信息，这样 AI 就不必凭空假设：

• 指明相关文件或代码片段：如果你已经定位到需要修改的文件，最好把文件路径或片段告诉 AI。如：“参考 UserRepository.java 中的 findByEmail 方法，实现一个新的 findByUsername 方法。” 这样 AI 就不会去别的地方找或者重复实现已有逻辑。
• 说明重要约束与不变量：明确告知哪些东西不能被破坏。比如：“修改这一函数时请确保不会破坏事务的一致性”或者“保持对现有 API 的向下兼容，不能改变返回值结构”。这些都是 AI 可能忽略但对你很重要的点，一定要在提示里提及。
• 给出项目里的示例：如果项目中已有类似实现，让 AI 照葫芦画瓢。比如“项目已有的 ProductService#addProduct 方法就是个很好的参考，请按相似风格实现 addCategory 方法”。还可以贴出简短的示例代码片段。AI 擅长模仿模式，这样它输出的代码在风格和结构上更符合预期。
• 提供外部资料片段：对于 AI 不了解的新概念，直接提供资料摘要。比如在提示里粘贴某个库的 README 关键段落，然后让 AI 基于此使用该库 API。又或者，对于复杂的正则、晦涩的业务规则，你可以把相关说明文字贴进提示。原则是：凡是 AI 需要知道才能正确完成任务的信息，都应想办法提供。不要指望它去“想象”或推理出某些背景知识——与其相信 AI 的常识，不如明确给出依据。
• 设定反例和禁区：如果某些解法是不可取的，可以直截了当地告诉 AI “不要那样做”。例如：“性能至上，请勿使用 O(n^2) 的解法”或者“出于安全考虑，决不能将密钥硬编码在代码中”。有时指出你不希望的方案，比描述你希望的方案同样重要。

6.3 要求 AI 自行澄清和检查

一个好的提示不只是单向命令，还可以引导 AI 进行交互式思考。Cursor Agent 具有多轮交互能力，我们可以在提示词中鼓励它提出问题或自行检查。例如：

• 让 AI 提问：在较复杂任务的提示末尾，可以加一句：“在开始实现之前，如有任何不明确的地方，请向我提问。” 这等于给了 AI 一个机会来澄清需求，而不是贸然生成。经验上，如果 AI 真的提出了澄清问题，说明你的需求可能还不够清晰，那就回答它的问题，直到 AI 满意为止再让它动手写代码。
• 分阶段执行：如果任务很复杂，不妨在提示中明确要求 AI 分步骤完成，不要一股脑给出最终代码。例如：“步骤 1：先给出实现方案和接口设计，不要写代码。步骤 2：经我确认后再编写代码。” 通过这种元指令，你可以把任务拆成两个回合：先让 AI 输出一个计划或设计，然后你审核后再让它继续。这相当于人工插入了 Plan-Execute 的中间检查点，可以显著提高复杂任务的正确率。
• 提示 AI 检查输出：在提示结尾加一句：“生成代码后，请检查是否有明显的错误或遗漏。” Cursor Agent 在完成主要任务后，会根据系统提示（包括规则）自动执行一些检查。你也可以直接要求，例如：“给出代码后，解释一下你的实现是否考虑了所有边缘情况。” 这样 AI 往往会在回答中先给代码，再附上一段自我检查的说明，指出可能的不足之处。这些自述可以帮助你了解 AI 的思路，还能及时发现它有没有忽略某些要求。

6.4 提示模板和实例

结合以上原则，这里提供几个实用的提示词模板，开发者可直接套用或修改：

6.4.1 功能实现类任务（使用 Plan-Execute 分步）

【背景】我们正在开发一款 Todo 应用，使用 Spring Boot + JPA。当前有用户管理模块。

【任务】实现“重置密码”功能：

1. 提供一个 API 接口 POST /api/users/reset-password，接收邮箱地址。
2. 验证该邮箱对应的用户存在，生成重置 Token（随机字符串，有效期 24 小时），保存到数据库（可新建 ResetPasswordToken 实体）。
3. 将重置 Token 通过邮件发送给用户（调用已有的 EmailService）。
4. 如果用户不存在，返回 HTTP 404。

【要求】

• 所有数据库操作必须在事务中完成。
• Token 应该是唯一且安全的（使用 UUID 或加密随机数）。
• 切勿泄露用户不存在的信息（即邮箱不在系统中时，仍返回成功，以防止恶意探测）。

请先给出你计划如何实现，包括需要的新实体/方法/流程，然后再等待我确认。确认后再编写具体代码。

这个提示首先详细描述了背景和任务细节，然后要求 AI 先给出计划。你确认无误后，可以在同一对话继续说“好的，请按照你的计划生成代码”，AI 就会继续完成编码部分。通过这种方式，你既确保了需求的明确，又能介入设计过程。

6.4.2 Bug 调试与修复

我们有一个 Java 服务用于数据处理，但运行时报如下错误：

1
2
3
4
5

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 10 out of bounds for length 10
    at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
    at java.base/java.util.ArrayList.get(ArrayList.java:438)
    at com.example.DataAnalyzer.processData(DataAnalyzer.java:30)
    at com.example.Main.main(Main.java:15)

请找出 DataAnalyzer.java 中导致 IndexOutOfBoundsException 的原因，并修复代码。【提示】processData 方法似乎在用错误的边界条件迭代数据列表。

这个提示提供了错误堆栈和怀疑的原因，引导 AI 去阅读代码找问题。这相当于让 AI 充当调试助手。AI 可能会定位到 DataAnalyzer.java 并看出循环条件 i <= data.size() 多迭代了一次，造成索引越界，然后给出修复建议，比如改为 i < data.size()。

6.4.3 测试驱动开发（TDD）

我们要给 Account 类新增一个方法：transfer(BigDecimal amount, Account targetAccount) 实现账户间转账。

步骤 1：请先编写测试用例来规定该方法的行为。使用 JUnit 5 + AssertJ 风格：

• 转账后源账户余额减少、目标账户余额增加。
• 余额不足时转账应抛出 InsufficientBalanceException。
  不要编写 Account 类实现，只需给出测试。

AI 会先输出测试代码，例如几个情景：正常转账、余额不足转账。你检查测试是否覆盖充分（需要的话手动调整并要求 AI 补充），然后：

步骤 2：很好，现在请运行这些测试（无需真实执行，假设失败），确认它们未通过。

步骤 3：现在请编写 Account.transfer 的实现代码，要求通过上述所有测试。请勿修改测试代码。如果第一次未通过测试，请根据失败信息持续修正，直到测试通过为止。

这一步 AI 会编写 transfer 方法实现。如果第一次不一定完善，你可以继续提示它输出假想的测试结果，然后让它根据错误信息调整，实现一个循环。这个过程其实就是让 AI 进入 “TDD 循环”：先让 AI 写测试 → 确认测试失败 → 写实现直到测试通过 → 最后人工验收提交。

6.4.4 代码审阅与改进

以上是 Cursor Agent 刚刚生成的代码实现。现在请以审查者身份逐行检查这段修改，指出其中可能存在的潜在问题、漏洞或可以改进之处，并给出修改建议。

这个提示可以在 Cursor 完成一次改动后提出，Agent 会进入 Review 模式，对代码做静态分析。它可能输出一个列表，比如：“第 12 行可能存在空指针风险，应先判断对象是否为空”、“第 27 行的算法复杂度较高，在大量数据时可能性能不足”。这利用了 AI 善于分析的能力，提供了一个“第二双眼睛”来帮助你审视代码。

6.4.5 复杂问题讨论

我们打算重构支付模块，目前有两种候选方案：

1. 使用策略模式，根据支付类型分别实现。
2. 使用规则引擎，根据配置决定支付流程。

请从代码维护性、扩展性、性能和开发工作量方面，帮我比较这两种方案的优劣，并给出你的建议。

这种开放性的提示让 AI 发挥长处——分析与文字总结。它会产出一篇分析文章，帮你梳理每种方案的优点缺点，然后给出推荐（也许会说更倾向哪种并解释理由）。这种用法相当于把 AI 当成顾问，一起头脑风暴和论证。

提示技巧小结：

• 写提示词时，可以使用 Markdown 的格式提升可读性（Cursor Agent 输出时通常保留你的格式）。比如用列表、粗体来强调关键步骤，这既是给 AI 看的，也是给你自己和团队看的（将来回顾聊天记录就像文档）。
• 语气和措辞也有影响。Cursor Agent 对明确的指令反应很好，所以不用客气，把需求和要求直截了当地说明。但是对于需要创意或分析的，让 AI 扮演某种角色（如“作为资深 Java 架构师，回答…”）可能会有效果。但切勿使用冒犯或过于情绪化的语气，对 AI 来说这样的信息无用还可能引起奇怪的输出。专业、礼貌且清晰，是提示词应有的风格。
• 尽量一次一个任务。如果在一个提示里罗列了许多不相关的要求，AI 可能漏掉部分要求甚至混乱。最好每次交互聚焦在单一目的上，完成后再进行下一个。

提示词的艺术需要通过实践不断打磨。建议你多保存一些有效的 prompt 模板，比如常用的“添加新接口”“修复 Bug”“写单元测试”“代码重构”“性能优化建议”等，把它们整理成一个属于你自己的 Prompt 手册。以后遇到类似场景可以快速引用，大大提高工作效率。

7 测试与验证

在 AI 编程工作流中，“验证”步骤至关重要，它是确保代码质量和功能正确性的最后防线。无论 AI 多么强大，我们仍必须通过测试和审查来验证其产出是否可靠。正如之前所强调的，Human-in-the-loop（人不离场）要求我们对每个关键结果进行把关。本节将讨论如何有效地将测试和验证融入 AI 协同开发，从而构建一个稳健的高频反馈闭环。

7.1 测试优先，驱动开发

在理想情况下，我们应尽量采用 测试驱动开发（TDD） 的方式与 AI 协作。这意味着在实现功能前，先定义好验收标准（测试用例），让测试来指导实现过程。实践中，可以像前文提示示例那样，先让 AI 根据需求生成测试用例，再让它去实现功能直到测试通过。测试的存在有多重好处：

• 为 AI 设定清晰的目标：模型的表现往往在有明确迭代目标时最好。测试用例就是明确的目标——通过/未通过是客观判断标准。有了这个“裁判”，AI 会不断修改自己的实现直到所有测试通过。这一过程减少了我们人工验证的负担，也防止 AI 偏离正轨，因为测试不通过就说明还有问题，逼着它继续改进。
• 防止过度实现或遗漏：写测试促使我们（和 AI）先认真思考功能规格，包括各种边缘情况，这避免了直接上手编码时可能遗漏的场景。AI 生成测试用例时，如果它遗漏了一些情况，你可以及时补充提示，这相当于在编码前就讨论清楚了需求细节。当测试覆盖全面后，AI 的实现也更有保障。
• 减少回归：当项目积累了测试集后，AI 每次改动都可以快速验证是否破坏了既有功能。Cursor Agent 可以被指示去运行测试（它背后实际调用终端来执行命令），并将结果反馈给你或自身。这就像给 AI 戴上了“紧箍咒”：一旦它的改动导致某个测试失败，立刻就能发现并进行修复。这在重构或大改动场景下尤其重要。

在 Cursor 中，你可以把常用的测试命令（如 npm run test 或 pytest）写入 Rules 的 Commands 部分，提醒 AI 在完成一系列修改后运行测试。甚至可以设置 Skills，让 AI 自动在每次生成后运行测试并判断结果。当然，不要忘记测试本身的质量：AI 生成的测试也需要你审查，有时 AI 写的测试用例不一定严谨，需要你调整。测试代码和产品代码一样，需要维护和演进。

7.2 让 AI 参与验证过程

除了编写和运行正式的测试，我们还可以让 AI 积极参与到验证环节，以多种方式检查代码质量：

• 静态分析和审查：Cursor Agent 具备代码分析能力。你可以显式提示 AI：“检查一下上面的代码是否有潜在空指针异常或者错误。” AI 会静态地阅读代码并指出可疑之处。这类似于让 AI 当 Lint 工具或 Code Review 助手。重要改动后也可以用另一模型审查，在 Cursor 里你可以直接切换模型提问。
• 对比多种方案：Cursor 支持并行运行多个模型，你可以让两个模型分别实现同一个功能，然后对比它们的输出差异。如果两份代码逻辑截然不同，可以让 AI 相互参考或者评估哪种更优。这有点像二次验证：当两个 AI 结果不一致时，引起你注意去深究；当结果一致时，说明实现基本是主流思路，可靠性也许更高。
• 运行和观察程序行为：在某些情况下，直接运行代码观察其行为也是验证的重要手段。你可以让 AI 执行某些命令。例如：“运行应用并访问 /api/test 看看返回是什么”。如果环境允许，你也可以自己运行程序，复制控制台日志或错误信息给 AI，让它协助分析。举例来说，把程序运行时抛出的异常栈贴给 AI，问它“根据这个错误日志，程序可能哪里出了问题？应该如何修复？”。

7.3 人工验收与代码评审

无论测试多完善，我们仍强调人工的最终验收。这包括：

• 代码走读（Code Walkthrough）：亲自阅读 AI 生成的代码，确认逻辑正确、边界条件处理妥当。尤其是安全相关的代码，AI 可能不会完全理解安全隐患，必须由开发者来审视。例如检查是否有 SQL 注入风险、敏感信息日志泄露等。如果在团队中，可以把 AI 的产出提交 Pull Request，让其他同事审核，就像人工写的代码一样对待。
• 风格和规范检查：看 AI 写的代码是否符合团队的编码风格和规范。如果有 CI 集成了 lint 或格式检查，运行一下，看看有没有违规。一个 AI 友好的开发环境应有严格的 lint/格式检查，这其实也是为了保证 AI 产出符合规范。大模型有时会忘记格式，比如导入顺序、注释风格，你需要提醒或手动调整，然后把这些要求加入规则里防止下次再犯。
• 业务结果验证：代码通过测试并不意味着满足真实业务需求。要结合业务场景验证结果。例如在测试环境运行一下新功能，观察是否真正解决了问题、性能是否达标、UX 是否满足预期等等。AI 不会使用你的产品，这一步需要你换位从用户或业务角度验收。必要时可以请产品或 QA 一起验证。

持续集成和自动化检查也是测试验证的重要组成部分。确保你的项目有完善的 CI/CD 流水线，Pull Request 触发自动构建和测试。当 Cursor Agent 提交代码后，CI 如果报告了测试失败或覆盖率下降，你就能立刻知道。然后你可以把 CI 的失败信息反馈给 AI 修复：“CI 测试 X 失败，错误输出如下，请根据此修复代码。” 这种高频反馈闭环将 AI 牢牢控制在“有问题就改、改到通过为止”的循环中。整个过程你只需观察和最终拍板，大量机械调试修复的工作都可以由 AI 承担。

综上，“验证”绝不是可选项，而是 AI 工作流的必备环节。借助测试用例、AI 审查、CI 工具、人眼核验，我们构筑了多层保障，避免了 AI 的错漏流入最终产品。通过严谨的验证流程，我们既发挥了 AI 的速度优势，又确保了软件质量和可靠性。

7.4 关上反馈闭环：让 AI 自己验证自己

前面我们讨论的验证方式，主要是“人验证 AI 的输出”。但还有一种更高效的模式：让 AI 自己验证自己。这需要你把“反馈闭环”搭建好。

Peter Steinberger 在访谈中把这称为“最大的秘密”：

高效使用 coding agent 的关键，其实就一句话：你得把反馈闭环搭好。它必须能自己跑测试、自己 debug，这是最大的秘密。这也是为什么后来效率提升这么明显。用 Claude Code 的时候，我经常要回头修修补补，来回跑很多轮，算下来其实没快多少，只是更”互动”而已。现在用 Codex，绝大多数时候它一次就对了。

没有闭环时，AI 生成的东西第一次往往跑不通，忘了同步改其他地方，你要来回修补很多轮。有闭环时，AI 可以自己发现问题、自己修复，绝大多数时候一次就对。

那什么是“反馈闭环”？ Peter 给了几个具体例子：

1. 每个功能都配测试

我的基本策略一直是：做一个功能，就让它写测试，而且确保测试真的跑了。

这是最基础的闭环。AI 写完代码 → 跑测试 → 测试失败 → AI 修复 → 再跑测试… 直到通过。关键是“确保测试真的跑了”——不只是写测试，而是让 AI 在开发过程中持续运行测试。

2. 用 CLI 代替 GUI 调试

Mac App 调试特别烦——要 build、启动、点界面、看效果，再告诉它不行。现在我就直接说：给我建一个 CLI，专门用来 debug，走完全一样的代码路径，我可以直接调用。然后它就开始跑，一个小时后搞定了。

为什么要这样做？因为 GUI 的反馈循环太慢了。每次验证都要 build、启动、点击、观察… 而 CLI 可以秒级验证，AI 可以快速迭代。Peter 甚至在做网站时，也会把核心逻辑设计成可以通过 CLI 跑起来，因为“浏览器里的反馈循环实在太慢了”。

3. 自动化集成测试

我花了好久才反应过来：我在干嘛？这事就该自动化。于是我直接跟 Codex 说：设计一组集成测试——起一个 Docker 容器，装好整套系统，跑一个循环，用指定文件里的 API key，让模型读一张图片、生成一张图片，再回头看自己生成的图像理解成了什么。结果它真就自己搞定了。

这是更高级的闭环：整个系统级别的自动化验证。当你发现自己在反复手动测试同一个场景时，就应该想到“这事该自动化”。

为什么代码特别适合 AI？

Peter 点出了一个本质原因：

代码不一样，我可以编译、lint、执行、验证输出——只要你把系统设计好，就能形成一个非常完美的反馈闭环。但在创意写作上，它们的表现往往只是中等，因为创意很难验证。

代码的每一步都是可客观验证的：编译通过/不通过、lint 通过/不通过、测试通过/不通过、输出正确/不正确。这些二元判断让 AI 可以自己知道做对了没有。而创意写作的“好不好”是主观的，AI 无法自我判断。

信任的来源

你之所以可以不看，是因为你已经把验证闭环搭好了，你信任它，因为测试跑过了。这其实和在大公司做项目很像：所有测试都绿了，当然不代表百分之百没问题，但已经是一个很强的信号了。

很多人不敢信任 AI 写的代码，是因为没有验证手段。但如果你有完善的测试和 CI，你不需要逐行审查每一行代码。这和大公司的协作模式一样：你不会去看每个同事的每一行代码，你信任 CI 和测试。

如何搭建反馈闭环？

总结起来，要让 AI 能“自己验证自己”，你需要：

1. 测试框架：确保项目有单元测试、集成测试，并且 AI 能运行它们
2. 快速迭代环境：尽量用 CLI 而非 GUI，缩短每次验证的时间
3. 自动化思维：当你发现自己在反复手动验证时，就让 AI 把这个验证过程也自动化
4. CI/CD 集成：让测试在每次提交时自动运行，形成持续的质量守护

一旦搭好这些基础设施，AI 的效率会呈数量级提升。它不再是“生成代码然后等你验证”，而是“生成、测试、修复、再测试… 直到通过”的自主循环。你只需要在最后审查结果。

软件的本质没变，Test First 反而更容易了

关于反馈闭环，Peter Steinberger 还有一个更深层的洞察：

其实在 AI 之前也是一样。做复杂系统时，只要找一个真正做过的人，他第一件事一定是想：怎么让它可测试？接口怎么设计、类怎么拆、要不要 mock、要不要做端到端测试——这些都是非常困难、而且一旦决定就很难回头的架构选择。现在这些取舍依然存在，软件本质上没变。

“可测试性”一直是好架构的核心标志。这个原则在 AI 时代不仅没有过时，反而变得更加重要——因为你需要给 AI 一个能自我验证的环境。

但有一件事确实变了。Peter 坦诚地说：

写测试这件事真的太折磨人了，各种边界条件、分支逻辑。除了我非常尊敬的 Kent Beck——他来过播客，坚持 test-first——我几乎不认识真正喜欢写测试的开发者，包括我自己。我从来不喜欢写测试，就算假装喜欢，其实也没有。文档和测试对我来说，一直都不是一种”创作表达”。

这是大多数开发者的真实心态。Test First、TDD 在理论上很美好，但实际执行起来，写测试比写功能还累，感觉不是“创作”，而是“苦力活”。

但现在情况完全不一样了：

现在每当我设计一个功能，文档和测试都会自动成为流程的一部分。比如我们刚做完一个东西，我会立刻想：怎么测试它？换一种实现方式会不会更好测？于是”怎么关上闭环”已经成了我思考的一部分。模型必须能验证自己的工作，这会自然把我推向更好的架构。

我甚至觉得，现在不再亲手写代码了，反而写出了更好的代码。我以前就写得不错，但在公司里……现在情况完全不一样了。可以说，在我最近的项目里，文档质量是我做过最好的，而我一行都没亲手写。我不写测试，也不写文档，我只跟模型解释取舍：为什么要这么做。

这是一个很有意思的反转：

• 以前：写功能 → 勉强补测试 → 能跑就行
• 现在：想清楚怎么验证 → 让 AI 写测试和功能 → 确保闭环

AI 接管了那些“不是创作表达”的苦力活，而人专注于真正需要人来做的事：解释取舍、描述意图、想清楚“怎么验证”。

Kent Beck 的 Test First 理念，在 AI 时代反而更容易实践了。变的是实现者，不变的是原则。 这也许是 AI 带给软件工程最积极的影响之一：它让“理想的工程实践”从“应该做但做不到”变成了“自然而然会发生”。

8 项目资产沉淀

在传统开发中，我们注重代码复用和知识积累。AI 协作开发同样会产生许多有价值的项目资产：文档、规则、提示片段、测试用例等。善加利用这些资产，可以让 AI 未来表现更好，也让团队其他成员受益。本章讨论如何沉淀和复用 AI 协作过程中产生的知识与成果，打造不断自我增强的开发循环。

8.1 保存 AI 的“智慧”：计划和对话

Cursor 提供了一些功能，可以方便地保存 Agent 的输出内容。例如，当你使用 Plan 模式生成了实现计划后，可以点击 “Save to workspace” 将该计划文件保存到项目的 .cursor/plans/ 目录。这样一来，这份计划就成为项目文档的一部分，后续中断了也可以继续参考，还能提供给未来在同一功能上工作的 Agent 作为参考上下文。建议：把重要的 AI 规划文档都保存下来，例如 plans/2026-01-完成登录功能.md，并纳入版本管理。即使实现已经完成，这些计划文档也是宝贵的记录，反映了当时的思路和决策，供以后参考。

此外，对于 AI 生成的一些有价值的结论或分析，也可以整理出来，放入项目知识库（如 docs/ 目录或团队 Wiki）。例如，在前面的复杂问题讨论示例中，AI 给出了两种架构方案的详细比较和建议。这种内容完全可以稍加编辑后写入决策记录文档，方便团队后来者了解当初为何选择了某方案。通过把 AI 的输出正式文档化，我们避免了知识只存留在对话里然后被遗忘的情况。

至于 Past Chats 聊天记录引用功能，本质上是把对话内容当知识使用。所以当一段对话结束后，如果觉得其中结论重要，不妨给这段 Chat 取一个清晰的标题，并在需要时通过 Past Chats 取用。这相当于沉淀了隐性知识为显性可检索知识。

8.2 项目规则和配置积累

Cursor Rules 和 Skills 是项目资产沉淀的另一种形式。我们在“控制策略”部分已经详细讨论了规则的制定和演进。在这里强调其长期价值：

• 把团队的编码规范、架构约定、常用技巧不断加入到 .cursor/rules/ 中，你相当于打造了一个团队知识库，而 AI 会在每次对话开始时自动读取这些知识。随着规则集的丰富，AI 对项目的理解会越来越深刻，犯错越来越少。这有点像训练模型，但实际上只是喂了更多上下文——却实现了定制化的效果。
• 规则也可以有全局和项目特定之分。Cursor 支持在设置中添加全局规则，适用于所有项目，以及项目本地的规则文件。对于你个人/团队而言，可以慢慢建立一套“通用 AI 编程守则”，涵盖一些通用的最佳实践。这套全局规则就像每次 AI 协作时你都会告诉它的一些基本准则（比如“遇到不确定就提问”“不要在代码里泄露机密”等）。当这些守则变成资产后，新开启的项目也能快速引用，不必从零开始告诉 AI。
• Skills（技能）方面，如果你开发了某些 Agent 技能脚本，比如自动循环 Runner、特定领域的命令等，那么一定要把这些脚本纳入版本管理，并在团队内共享。这些技能脚本相当于可复用的自动化工作流。积累一套好用的 Skills 库，能极大提升团队整体效率，也让 AI 的作用不仅限于当前项目，还可以跨项目发挥。

8.3 测试和案例库

项目资产中非常重要的一部分是测试用例。AI 在协作过程中，很可能帮你生成了大量单元测试、集成测试。这本身就是项目的宝贵资产。一定要把这些测试纳入版本库，并持续维护。当新功能上线或旧功能修改时，相应增加或更新测试。长远来看，一个覆盖良好的测试集不仅保障代码质量，也是训练 AI 的最佳教材。未来当 AI 参与改动时，这些测试会告诉它何为正确行为。而且我们也提到，可以把失败的测试结果反馈给 AI 修复。当测试集完善后，你几乎可以把解决问题的负担很大一部分交给 AI——因为稍有差池测试就会报错，它就不得不改到通过为止。

8.4 工作流和提示模版库

随着你和团队使用 AI 的经验增长，你们会逐渐形成一套好用的 Prompt 模板和工作流脚本。这些都是值得沉淀的。例如：

• 把常用的提示语写成模板收集起来，分类存储（可以放在团队内部的 Wiki 或者一个专门的 Markdown 文件里）。比如 “Bug 修复提示模板”、“代码重构提示模板”、“API 文档生成提示模板” 等。团队新人在遇到类似任务时，可以从模板库里找到相应 prompt，稍作修改就能用。这避免了每个人都要从头尝试怎么问 AI 才好的过程。
• 如果你已经摸索出一套成功的 AI 协作工作流，不妨将其写成指南，在团队内部分享培训。将流程标准化，其他成员照着做可以少走弯路。例如，可以沉淀出一份“使用 Cursor 开发新功能的流程清单”：从编写 Plan、到实施、到测试、到审查，每一步都写清楚，并列出可能用到的工具/命令。这样，新成员来了按清单操作就能更快上手，老成员也有据可依不会遗漏关键步骤。
• 社区资源也可视为资产。比如官方博客、优秀的使用案例文章，你可以在团队内部做一些整理归纳。例如 “Cursor 高级用法 FAQ”“遇到 AI 乱改代码怎么办” 等 Q&A 文档。知识不仅来自自己，也来自社区，汇总后就是你们自己的财富。

8.5 经验反馈到 AI 模型

资产沉淀的终极形式，可以考虑将项目积累的数据反哺到 AI 模型本身。这超出了 Cursor 工具的范畴，但值得一提。例如，把项目的典型代码片段、术语、风格指南整理后，通过训练（Fine-tuning）定制一个专用模型，可能会让 AI 更贴合你的项目需求。不过目前大语言模型的微调成本较高，而且很多闭源模型无法微调。因此，更实际的做法是依托前面讲的规则、文档、例子，把知识“灌输”给 AI，而不是修改 AI 参数。

还有一种折中方式是通过向量数据库构建项目知识库，然后在提示时自动嵌入相关知识（即 Retrieval Augmented Generation, RAG）。Cursor 暂时没有开箱即用的向量库集成功能，但你可以借助 Hooks 或 MCP，接入自己的知识库。例如，当你问 AI 某模块的问题时，先从向量 DB 里检索相关文档片段插入到提示中。这个流程需要一些自定义开发，但是如果你的项目域知识复杂、文档繁多，这种方案可以显著提高 AI 回答准确率。

无论如何，让 AI 变得越来越聪明的关键不是等它升级模型（那是厂商的事），而是我们提供给它的项目知识越来越丰富规范。这些知识就体现在我们沉淀下来的资产中。每完成一个迭代，我们都应自问：这次 AI 遇到了哪些新问题？我们采取了哪些新的规则或提示技巧？能否把它总结为经验，纳入我们的库？如此不断积累，AI 对你的项目就像一个越干越久的老员工，知道的“潜规则”越来越多，表现也会越来越稳定可靠。

归根结底，资产沉淀不仅仅服务于 AI，也是团队自身能力的沉淀。在 AI 帮助下，你会更快产出更多成果，更需要及时整理，否则“今天解决的问题明天又忘了怎么解决”。养成及时总结的习惯，把分散在对话和代码中的知识提炼出来，长远来看，这些沉淀将大大提高团队协作和 AI 协作的效率，让工作流形成正向循环。

8.6 面向 Agent 设计代码库

前面讨论的资产沉淀——规则、文档、测试、模板——都是显式的、增量的。但还有一种更根本的资产：代码库本身。

Peter Steinberger 分享了一个很有启发的观点：

我设计代码库的时候，已经不只是考虑”对我好不好”，而是要考虑”对 agent 好不好”。我会为模型优化最省力的路径，因为最终是它们在跟代码打交道，我负责的是整体结构和架构。

现在 pull request 对我来说，更像是 prompt request。有人提 PR，我会看看需求，然后和我的 agent 从这个 PR 出发，按我理解的方式重新设计这个功能。

“对 Agent 好不好”成为设计考量

以前我们设计代码时考虑的是：对人类读者好不好理解？对团队协作好不好维护？现在多了一个维度：对 AI Agent 好不好操作？

什么是“对 Agent 好”的代码库？

1. 清晰的模块边界：AI 更容易定位“这个功能在哪里”，不会在无关文件里迷路
2. 一致的代码风格：AI 更容易模式匹配，生成风格一致的代码
3. 好的命名：AI 通过名字理解意图，比通过注释更可靠
4. 显式依赖：隐式的魔法、全局状态、副作用对 AI 是噩梦（前面提到的 Postgres 触发器 bug 就是例子）
5. 可测试的结构：有测试的代码库让 AI 可以自我验证，形成反馈闭环

角色分工的变化

Peter 说“最终是它们在跟代码打交道，我负责的是整体结构和架构”。这描述了一种新的分工：

你不需要亲自写每一行代码，但你需要设计让 AI 能高效工作的环境。这有点像城市规划师和建筑工人的关系——规划师设计道路和分区，工人在这个框架内建造。

PR = Prompt Request

“pull request 更像是 prompt request”这个重新定义很妙。PR 的本质从“请合并我的代码”变成了“这是我想要的功能，请按我的理解重新实现”。PR 成了需求的载体，而不是代码的载体。你看的是“这个 PR 想做什么”，然后让 AI 按你认为正确的方式重新实现。

代码库是 AI 的工作环境

这段话的核心启示是：你的代码库就是 AI 的工作环境。就像你会为新入职的同事准备好开发环境、文档、规范一样，你也需要为 AI 准备好一个“对它友好”的代码库。

代码库设计得越好，AI 的输出质量就越高，你需要介入纠正的次数就越少。这是一种基础设施思维：与其每次交互时费力引导 AI，不如一次性把代码库设计好，让 AI 每次都能自然地产出高质量代码。

所以，当你下次重构代码、设计新模块、或者制定编码规范时，不妨多问一句：这样设计，对 Agent 友好吗？

Prompt 才是更高信号量的东西

如果代码库是 AI 的工作环境，那什么才是真正的“产出”？Peter Steinberger 的回答可能会让你意外：

当我看到一个 PR 时，我更感兴趣的其实是 prompt，而不是代码本身。我会要求大家把用过的 prompt 一起提交。有些人会照做，而我会花更多时间读 prompt，而不是读代码。

对我来说，prompt 才是更高信号量的东西：你是怎么得到这个结果的？具体问了什么？中间做了多少引导？这些比最终代码本身更能让我理解输出。我甚至不需要细看代码。

这是一个颠覆性的观点：代码只是 prompt 的“输出”，真正重要的是产生代码的思考过程。

为什么 prompt 的信号量更高？

1. 代码是“what”，prompt 是“why + how”：代码告诉你结果是什么，prompt 告诉你为什么这样设计、怎么引导 AI 得出这个结果
2. 代码可以被 AI 重新生成，prompt 不能：如果你有好的 prompt，可以随时让 AI 重新生成代码；但如果只有代码，你很难还原当初的思考
3. Prompt 暴露了思考质量：一个清晰、有结构的 prompt 说明作者想清楚了；一个模糊、混乱的 prompt 说明作者自己也不确定要什么

Peter 还进一步描述了他的工作流：

如果有人想要一个新功能，我会让他先写一个 prompt 需求，把它写清楚。因为我可以直接把这个 issue 丢给 agent，它就会帮我把功能做出来。真正的工作在于思考”它应该怎么工作””细节是什么”。只要这些想清楚了，我几乎可以直接说一句”build”，它就能跑起来。

需求本身就是可执行的。传统流程是“需求 → 开发者理解 → 写代码”，中间有“理解”这个可能出错的环节。Peter 的流程是“Prompt 需求 → 直接丢给 Agent”，需求就是代码的源头。

这意味着：

• Code Review 的意义在改变：以前是审查“代码写得好不好”，现在可能是审查“你是怎么引导 AI 的”、“你的思考过程对不对”
• Prompt 会成为新的知识资产：值得保存、复用、改进的不只是代码，还有 prompt
• “写需求”的能力变得更重要：能把需求写得清晰、具体、可执行，就等于能直接“编程”

编码不是工作，思考才是。

9 持续训练与提升

AI 编程工作流的构建和优化并非一蹴而就，而是持续训练和改进的过程。这种训练不光是训练 AI，更是训练我们自己——如何更高效地与 AI 协作，不断提升开发技能。本章探讨如何制定持续学习和改进的计划，使个人和团队的 AI 协作能力稳步提升，真正将 AI 变成长期的生产力加速器。

9.1 强化基本功，AI 放大优势

在讨论“基本功”之前，我们先回答一个更根本的问题：为什么有些经验丰富的开发者对 AI 持强烈怀疑态度？

Peter Steinberger 在《The Pragmatic Engineer》播客访谈中分享了他的观察：

一周前我正好看到一篇博客，是 Nala Coco 写的，我非常尊敬他，也从他那里学到很多。但那篇文章基本在否定当前模型的工作方式。他测试了五六个模型，其中还包括一些根本不适合写代码的，比如 OpenAI 那个 120B 的开源模型。

在我看来，他就是写了一个 prompt，丢进 Claude Web，点发送，把输出直接跑了一下，发现编译不过，于是很失望。但这太正常了——你真以为人类第一次写代码就能零 bug 吗？这些模型本质上是人类集体知识的幽灵，工作方式和我们非常像。第一次出错很正常，所以你才需要反馈闭环。

而且你不是”发一个 prompt”就完事了，你是在开启一段对话：我想做什么。比如他抱怨模型用了旧 API，那是因为他没说 macOS 的版本，模型自然会假设用旧接口。它的训练数据不只是最近两年，旧数据远比新数据多。你越理解这些”小野兽”的思维方式，就越会 prompt。

他可能玩了一天左右，就下结论说这项技术还不够好。但要真正用好，你得投入更多时间。这就像你会弹吉他，我把你放到钢琴前，你随便试两下，说”这玩意不行，我还是回去弹吉他”。不对，这是完全不同的构建方式、完全不同的思维方式。

这段话揭示了批评者的典型模式：

1

写一个 prompt → 丢进 AI → 编译不过 → "这技术不行"

问题在于：很多人期望 AI “一步到位”，但人类自己写代码都做不到这一点。

核心差异是心态：你是把 AI 当作“应该完美执行”的命令执行器，还是当作“需要学习如何协作”的对话伙伴？

Peter 的“吉他 vs 钢琴”类比非常精准。很多资深开发者的问题是：他们用“写代码”的思维方式去用 AI，发现不顺手，就说 AI 不行。但这就像吉他手试两下钢琴就说钢琴不行一样荒谬。AI 协作是一门全新的技能，需要专门学习。

Peter 还分享了他自己的学习历程：

你不知道我有多少次在凌晨三点对着 Claude Code 吼，因为它干了蠢事。慢慢地，我开始理解它为什么会严格按我说的去做，有时候甚至可以直接问它。去年在 Clawdbot 这个项目里，我感觉自己成了一个”人肉 merge 按钮”，社区太活跃了，我每天都在 review PR，几乎没时间写代码。一开始我会 cherry-pick 一点就关 PR，气得不行。后来我问它：你为什么这么做？它会说：当你这样说的时候，我是这样理解的。那一刻我意识到，我在学机器的语言。

我不断调整 prompt，现在几乎每次都能得到想要的结果，因为这本身就是一项技能。

这个转变过程值得细细品味：

1. 一开始：凌晨三点对着 AI 吼，因为它干了蠢事
2. 转折点：问它“你为什么这么做”，它解释了自己的理解
3. 顿悟：“我在学机器的语言”
4. 结果：不断调整 prompt，几乎每次都能得到想要的结果

“学机器的语言” ——这正是本指南想要帮助你掌握的。你越理解这些“小野兽”的思维方式，就越擅长与它协作。而这种理解的前提，是你自己具备扎实的工程基本功。

首先，要认识到：AI 放大的是你的已有能力。如果你具备扎实的工程基本功，AI 会让你的效率成倍提升；相反，如果基础薄弱，AI 可能放大的是混乱和幻觉。因此，在依赖 AI 的同时，不要忽视对基础技能的打磨：

• 持续学习算法、数据结构、设计模式等计算机科学知识。AI 可以快速写出代码实现，但由你来判断哪种算法或模式适用。如果对这些概念不熟悉，AI 给出错误方案你也难以察觉。
• 巩固软件工程实践：需求分析、架构设计、编程范式、测试设计、性能调优等。AI 可以加速执行这些实践，但前提是你知道要执行什么。比如，如果你平时就写规格文档、画架构图，那么用 AI 可以更快产出它们；但如果你从不做设计评审，上来就让 AI 写代码，结果可想而知。
• 保持良好的代码习惯：整洁的代码、清晰的抽象、合理的注释。这不仅让你的项目质量高，也给 AI 阅读代码提供了友好的环境。AI 善于模式匹配，如果整个项目风格统一、结构清晰，它输出的内容也更容易融入。而如果项目本身混乱不堪，AI 学了你的坏习惯，产出可能雪上加霜。

换句话说，把 AI 当作一面镜子，首先照出我们开发过程中的薄弱环节，然后加以改进。不要因为有了 AI 就放松对自己的要求——相反，应该以更高的标准要求自己。优秀开发者 + AI 的组合远胜于任何一方单独存在。所以在训练计划中，应包括对经典开发书籍和理念的学习（比如重温《Pragmatic Programmer》《Clean Code》等），然后思考如何将这些原则与 AI 协作结合。

知名程序员 Peter Steinberger（Clawdbot 创建者）在接受《The Pragmatic Engineer》播客访谈时分享了一个深刻的观察：

真正震撼我的是一个意识转变：现在我几乎什么都能做出来了。以前你得非常谨慎地选副项目，因为软件真的很难。现在当然还是难，但那种摩擦感不一样了。我会想：我在这类技术上很强，在那类技术上很弱——比如”那我们用 Go 写个 CLI 吧”，我对 Go 一无所知，但我有系统层面的理解。一旦你有这种理解，就会慢慢形成一种感觉，知道什么是对的、什么是别扭的，这本身就是一项技能。

这段话揭示了 AI 时代一个重要的能力转变：系统层面的理解比具体技术栈的熟练度更重要。当你理解软件架构的本质、知道好代码应该长什么样，即使面对陌生的语言或框架，也能借助 AI 快速产出高质量的代码。反过来，如果缺乏这种系统性认知，即使 AI 帮你写出了代码，你也很难判断它是否正确、是否优雅。

Peter 还提到了一个有趣的概念——与 AI 协作时的“摩擦感”：

我记得有人发过一条推，说写代码时你能感受到摩擦，这正是好架构诞生的方式。我在写 prompt 的时候也有同样的摩擦感。我能看到代码飞过去，能感知花了多长时间，能感觉 agent 有没有在”顶”你，能看出生成的东西是杂乱的还是有结构的。很多时候我一开始就能判断大概会花多久，如果明显更久，我就知道自己哪儿搞砸了。

这种“摩擦感”本质上是一种直觉——你能感知 AI 的状态：它是在顺畅地输出结构化代码，还是在磕磕绊绊地拼凑？当你发现 AI 生成得特别慢、输出特别杂乱时，往往意味着你的提示有问题，或者任务本身需要拆解。培养这种直觉，是成为 AI 协作高手的关键。

最终，Peter 将人与 AI 的关系描述为一种共生关系：

你会慢慢”感知”这个模型，知道它通常会怎么跑。这更像一种共生关系——我学会了如何跟它说话，甚至可以说是一门语言；与此同时，模型也在变得更好。

这正是本指南想要传达的核心理念：与 AI 协作是一门需要学习的“语言”，而掌握这门语言的前提是你自己具备扎实的工程基本功。

在同一次访谈中，主持人提出了一个尖锐的问题：AI 时代是否又回到了那种“大写 A 的架构师”模式——不写代码、只画蓝图、把方案往下传？Peter 的回应很有意思：

我不太用”架构师”这个词，我更喜欢”builder”。我发现用 AI 特别顺的人和特别痛苦的人，差异很明显。我更在意结果和产品体验，底层管道我关心结构，但不纠结最小细节。另一类人特别热爱写难算法，喜欢解决纯技术难题，不太喜欢做完整产品、营销这些，这类人往往最抗拒 AI，也最容易沮丧，因为 AI 恰恰擅长解决那些”难问题”。

这段话揭示了一个关键洞察：AI 时代最痛苦的，往往是那些以“解决难题”为身份认同的人。

为什么？因为 AI 恰恰擅长那些“难问题”——复杂算法、边界情况处理、技术细节优化。这些以前是稀缺技能，是程序员的护城河。一个能徒手写红黑树的人，在团队里是有光环的。但现在，AI 可以秒写这些东西。

这不意味着技术深度没用了。它的“交易价值”确实降低了——你不再能仅凭“会写难算法”换高薪。但它对于判断 AI 输出是否正确、理解系统为什么这样设计仍然至关重要。只不过，它从“可出售的稀缺技能”变成了“做好工作的基础素养”。这个转变很微妙，但影响深远。

Peter 说他更喜欢“Builder”而非“Architect”，这不是文字游戏，而是两种完全不同的心态：

Builder 的核心是：把东西做出来、交付价值。 AI 只是让这件事变得更快了。而那些以“能解决别人解决不了的问题”为傲的人，现在面临的不是技术问题，而是身份认同的挑战。

Peter 还说了一句特别重要的话：

这一年里，我学到的系统架构和设计知识，比过去五年加起来都多。这些模型里塞进了海量知识，几乎任何问题都能问到答案，前提是你得知道该问什么。

“知道该问什么”——这才是 AI 时代真正的核心能力。AI 模型里确实有海量知识，但它不会主动告诉你该学什么。你需要有足够的认知框架，才能提出正确的问题。这就是为什么 Peter 能“一年学到比五年都多”——不是因为他变聪明了，而是他知道该往哪个方向挖。

Peter 分享了一个具体的案例来说明这一点：

我当然也做过那个 Twitter 项目，到现在还没完工。整体功能其实能跑，但一旦用得稍微频繁一点，就会开始变得又卡又怪，然后过一阵子又恢复正常。我怎么都复现不了问题，调试起来特别痛苦，因为它不是那种稳定可重现的 bug，只是”用着用着就慢了”。

当时我在 Postgres 里写了一些逻辑，某些 insert 发生时会触发一些行为，结果数据库就会变得非常忙，而模型根本看不到这一层，因为抽象隔得太远了。模型很擅长顺着逻辑链条追溯，但这是一个非常隐蔽的副作用，只藏在一个文件里的某个函数里，跟其他地方几乎没有关联，名字也起得很糟，完全不显眼。我一直没问对问题，直到有一天我突然问：这个地方有没有任何副作用？结果一下就找到了，然后修掉了。说到底，一切都只差一个正确的问题。但前提是你得有足够的知识和经验，知道该往哪个方向问。

这个案例完美诠释了“问对问题”的含义。AI 的工作方式是：你指向哪里，它就分析哪里。它可以顺着调用链追溯、检查你提到的代码，但它不会主动想到“会不会是数据库层面有触发器？”或“这个性能问题可能和代码逻辑无关，而是基础设施的副作用？”——这需要你来问。

Peter 最终问的问题是“这个地方有没有任何副作用？”——这个问题之所以“对”，是因为它指向了正确的方向（不是问“代码哪里慢”，而是问“有没有隐藏的行为”），超越了直接的代码逻辑。而能问出这个问题，来自于他对系统的整体认知：知道数据库触发器可能造成性能问题，知道副作用往往藏在不起眼的地方。

这就是系统层面理解的具体体现。你不需要记住每个 API，但你需要知道系统有哪些层次、每一层可能出什么问题、性能瓶颈通常藏在哪里。这些认知框架，决定了你能向 AI 提出什么样的问题。

Peter 还提到了另一个重要的心态转变：

当你真正经营过一家公司、带过团队，你就知道不可能盯着每个人的代码，要求他们每一行都按你的方式来。很多没带过团队的人，很难学会放松一点，理解”这段代码也许不是我理想中的样子，但它能把我往目标方向推进”。不完美的地方，之后总能继续打磨。我非常相信迭代式改进。

这和 AI 协作是一个道理：你不可能（也不需要）控制 AI 写的每一行代码。“不完美但能推进目标”是完全可以接受的，不完美的地方之后总能继续打磨。迭代式改进——先让它跑起来，再慢慢优化——这比追求一次性完美要实际得多。

所以，回到“AI 时代是否需要强化基本功”这个问题，答案是明确的：不仅需要，而且比以前更需要。只不过，基本功的定义在悄然转变：

• 以前的基本功：能写复杂算法、能解决技术难题、能记住各种 API
• 现在的基本功：系统层面的理解、判断力、产品思维、知道该问什么问题

AI 改变的不只是工具，而是“什么是有价值的”这个定义本身。适应这个转变，技术上不难，心理上才是真正的挑战。

好奇心是最大的武器

如何建立系统层面的理解？Peter Steinberger 给出了一个简单但深刻的建议：

你现在拥有一台”无限耐心的机器”，它可以把一切给你解释清楚。你可以不停地问：为什么要这么设计？为什么是这个结构？通过这种方式建立系统层面的理解。但这需要真正的好奇心，而我觉得现在的大学教育并没有很好地教会你这一点。

这种理解通常是通过”吃苦”获得的，不会轻松。

这是 AI 时代学习的最大红利。以前，想理解一个复杂的开源项目，你要么自己硬啃代码（痛苦且低效），要么找个资深的人问（但他们没时间、也不愿意反复解释基础问题）。现在，你有了一个永远有耐心、永远不嫌你问题蠢的老师。

关键是：你愿不愿意不停地问“为什么”？

AI 工具人人都能用，但谁在用它不断追问“为什么”，谁就能建立起真正的系统理解。有些人用 AI 只是为了“快速得到答案”，复制粘贴就完事；另一些人用 AI 是为了理解——为什么这样设计？还有别的方案吗？各自的优缺点是什么？

前者只是在用工具，后者是在借助工具学习。长期来看，差距会非常大。

工具是平等的，好奇心是不平等的。

9.2 分阶段掌握 AI 工具

对于个人开发者，建议制定一个循序渐进的 AI 工具掌握计划，而不是一下子尝试最复杂的用法：

1. 入门阶段：先将 Cursor 当作智能 IDE 使用，熟悉其基本功能。如自动补全、简单的 Chat 问答（比如“这段代码什么意思”）等。体会 AI 对提高日常编码效率的帮助。这阶段只需在小项目或日常脚本中用 AI 做辅助，不涉及关键产出。
2. 进阶阶段：尝试使用 Cursor Agent 完成独立的小任务。例如写一个小型模块、一个算法函数等。练习编写清晰的提示，观察 AI 行为。此阶段着重练习 Plan-Execute-Verify 循环在小任务上的应用。例如给一个简单需求，让 AI Plan 一下再实现，然后写个小测试跑跑。通过这些练习，积累 prompt 技巧和对 AI 能力边界的认识。
3. 应用阶段：将 AI 正式引入你的主要项目工作流。从简单任务开始，如用 AI 改几个 Bug、写几个单元测试，逐步扩大到实现新功能。在真实项目环境中应用之前学到的控制策略、上下文管理等。一开始可能让 AI 参与度在 20%-30%，你依然手工为主；随着信心增加，可以让 AI 承担更多，比如 50% 以上的代码产出。
4. 高级阶段：当你对 Cursor 的功能和 AI 协作方式都驾轻就熟，可以探索更高级的用法，比如自定义 Agent、编写 Skills、整合 MCP 外部工具等。也可以尝试使用多个模型协同、甚至本地部署一些开源模型做辅助。这个阶段的目标是拓展 AI 能力边界，让它覆盖到更多流程环节，例如自动化部署脚本生成、运维日志分析、数据迁移脚本生成等等。

每个阶段都可以设定一些小目标和评估标准。例如，入门阶段目标是“掌握基本补全和聊天提问”；进阶阶段目标是“能用 AI 独立完成一个 500 行以内的小功能，测试通过”；应用阶段目标“团队引入 AI 协作流程，1 个月内提效 20%”；高级阶段目标“开发出 1-2 个自定义技能用于公司内部，提高特殊场景效率”。这些目标可以量化（比如开发速度、Bug 率的变化）来检验效果。

9.3 团队训练与协作

如果是在团队环境中推进 AI 工作流，可以考虑一些团队培训和协作机制：

• 内部工作坊/分享会：定期组织团队分享 AI 使用经验，交流成功的 Prompt 案例或踩过的坑。一方面促进大家同步水平，另一方面也收集改进建议。团队集思广益往往能碰撞出更好的 AI 使用方法。
• 导师制度：让已经熟练掌握 Cursor 的成员带新人。手把手演示一两个工作流循环，比如从 Plan 到最后测试通过的全过程。比起让新人自己琢磨，通过现场示范和指导会更高效。注意，这里的“新人”不一定是编程新人，而是对 AI 工具的新手——即使是资深开发，也需要学习如何与 AI 协作，这方面有经验的人可以作为导师。
• 制定团队 AI 使用指南：结合团队具体情况，编写一份内部的《AI 编程工作流指南》。内容涵盖团队推荐的 Prompt 模板、规则约定、常见问题处理等。让每个团队成员都明确 AI 的定位——AI 不是来取代他们的，而是帮大家解除重复劳动、提供第二思路，但人仍然对最终质量负责。这样的指南能统一大家的认知，避免有人过度依赖 AI 或完全不敢用 AI 的两极化情况。
• 逐步扩大应用范围：可能起初团队只在部分项目、部分环节用 AI，比如先从测试生成或者文档生成开始，让大家建立信任。在看到效果后，再逐渐让 AI 参与核心编码。管理层也需要跟进 ROI，如果发现效率确实提升、错误率并未上升，那可以更大胆地投入。反之，如果初期效果不理想，要分析是工具问题、方法问题还是人员技能问题，及时调整训练计划。

9.4 跟踪 AI 技术演进

AI 技术日新月异，新模型、新工具层出不穷。要让你的工作流始终高效，保持对新技术的关注和学习也很重要：

• 关注 Cursor 官方更新：Cursor 官方博客和更新日志会发布新功能和改进。例如引入新的模型、改进 Agent 能力、推出新的集成功能等。及时了解这些更新，可以让你马上用上新工具。
• 参与社区：加入 Cursor 官方论坛、相关的 Discord/Reddit/微信群等。社区中大家会分享使用技巧、扩展插件、遇到的问题等。这是获取一手经验的好地方。积极参与讨论，你也可以提出自己的问题，往往很快会有热心人士或官方人员解答。
• 学习相关工具和思想：AI 辅助编程不仅仅是 Cursor 一家。GitHub Copilot、Tabnine、CodeGPT 等都有各自特色。了解不同工具的优劣，有助于完善你的方法。甚至可以将多种工具结合，例如用 Cursor 写代码、用 Copilot 补全小片段。再如了解一些提示工程（Prompt Engineering）的原理、LLM 的基础知识（如 token、上下文长度机制等），能让你更透彻地理解 AI 行为，写出更精准的提示。
• 评估新模型：当新模型推出，不妨试用并比较与旧模型的差异。新的模型可能有更强的推理能力、更大上下文等，这会影响提示写法和效果。Cursor 支持选择模型，所以当新模型推出，不妨试用并比较与旧模型的差异。始终保持对模型能力边界的最新认识，才能调整你的协作方式。

最后，要以成长的心态看待 AI 与开发者的关系。AI 不会让你退化，只会提供无数学习机会。把每次与 AI 协作当成切磋：当它给出一个你没见过的实现思路，认真研究背后的原理；当它出错时，分析原因反思自己是否也容易犯类似错误；当它提出不同方案，比较权衡从中提高架构能力。长远来看，你会发现自己不仅没有被 AI 取代，反而因为与 AI 共事而成为了一个更全面、更高效的工程师。

总结一句话：训练计划的核心是持续改进。持续地学、持续地用、持续地总结，再持续地学——正反馈循环。一开始也许需要花精力适应 AI 工具，但一旦工作流走上正轨，收益将非常显著。正如我们在开篇所说，这是“AI 增强的软件工程”，不是“AI 全自动的软件工程”。你付出的每一点学习和改进努力，都会通过 AI 的放大得到数倍的回报，助你在编程之路上更上一层楼。

10 结语与展望

10.1 大公司与 AI 转型

前面讨论的都是“个人如何与 AI 协作”。但如果你在大公司工作，可能会发现：即使个人已掌握这些技能，公司整体的 AI 采用进度却很慢。这不是错觉。

Peter Steinberger 在访谈中直言：

我觉得大公司会非常难以高效地采用 AI，因为这要求彻底重塑公司运作方式。比如在 Google，你要么是工程师，要么是经理；想同时决定 UI 长什么样，这个角色不存在。但新世界需要的是那种有完整产品视角、什么都能干的人，数量要少得多，但必须具备极高的自主性和能力。理论上，公司规模可以砍到原来的 30%。

所以我一点也不惊讶大公司现在用不好 AI。他们确实在用，但要真正用好，得先做一次大重构——不只是代码库，还有公司本身。

为什么大公司很难高效采用 AI？

大公司的组织结构是基于分工设计的：前端、后端、产品、设计、测试、运维… 每个人只负责一小块，通过流程和会议来协调。但 AI 打破了这种分工的必要性——一个人 + AI 可以自己写前端和后端、自己设计和实现、自己测试和部署。

分工的前提是“一个人做不完”，但现在这个前提被动摇了。

Peter 说的“新世界需要的人”，和他之前提到的“Builder”心态完全一致：

重构公司比重构代码库更难

代码可以逐步重构，但组织变化涉及人、利益、情感：

• 涉及裁员：“规模砍到 30%”意味着大量人员调整
• 权力重新分配：中层管理的存在意义被削弱
• 文化冲突：大公司文化往往是“不要出错”，而 AI 协作需要“快速试错”
• 流程惯性：严格的审批流程是为“多人协作”设计的，但如果一人 + AI 就能完成，它们就成了阻碍

对个人的启示

如果你在大公司，不要等公司转型。先转型自己：

1. 培养“全栈产品视角”——不只是写代码，要理解产品、用户、业务
2. 学习与 AI 协作——本指南讨论的所有内容
3. 让自己成为那种“什么都能干的人”——当变化来临时，你已经准备好了

历史上每次技术革命都会淘汰一批组织形式。AI 时代，新型组织形态会出现——可能是“一人公司 + AI”，可能是“3-5 人小团队 + AI”。传统大公司要么转型，要么被这些新形态取代。

无论你身处何种环境，能力的积累是属于你自己的。当整个行业重塑时，那些已经掌握了“AI 协作语言”的人，将拥有最大的选择权。

10.2 对新人的启示：你的“劣势”可能是优势

如果你是刚入行的新人，可能会焦虑：AI 时代，进入门槛更高了，前辈们都在用 AI，我怎么竞争？

Peter Steinberger 的观点可能会让你意外：

他们也有一个优势：没有被过往经验”污染”。他们会用 agent 做出很多我们根本想不到的事情，因为他们不知道”这原本是行不通的”。等他们这么用的时候，可能它已经真的行得通了。

前几天我有一个小的菜单栏应用，用来在 Cursor、Claude Code 这些环境里做成本追踪，性能有点慢。我想，那就来做性能分析吧。按我过去的习惯，我会打开 Instruments，到处点来点去。结果 agent 直接在终端里把所有事情都做完了，速度也提升了，还给了一些建议。我当时真的被震住了，完全不需要再打开 Instruments。

这是一个很有意思的反转。老手的问题是：他们“知道”什么行得通、什么行不通。但这些“知道”是基于过去的工具和能力形成的。AI 改变了能力边界，很多以前“行不通”的事情现在行得通了。

新人不知道这些“规则”，所以他们会天真地尝试——然后发现，居然成功了。

经验既是资产，也是负担——它让你知道什么可行，但也限制了你的想象力。

Peter 还说：

我觉得我们可能低估了进入科技行业的人有多么有办法，也低估了年轻人的潜力。回头看，很多伟大的公司都是非常年轻、经验并不丰富的人创办的，但他们有巨大的热情。这依然是存在的机会。

AI 时代，“能写代码”不再稀缺，但热情、好奇心、敢于尝试依然是稀缺的。技术可以学，但这些品质很难培养。

所以，对新人来说：不要把“经验不足”当作纯粹的劣势。保持好奇心，大胆尝试那些“老手觉得不可能”的事情。你可能会发现，在 AI 的帮助下，它们其实是可能的。

10.3 核心要点回顾

在结束之前，让我们回顾一下本指南的核心要点：

1. Plan-Execute-Verify 循环：这是 AI 协作编程的基本框架。先规划，再执行，最后验证——不断循环迭代，而不是期望一次性完美。

2. 对话而非指挥：与 AI 协作不是发号施令，而是结对探索。用“我们讨论一下”、“有哪些选项”来延迟执行，在理解清楚之后再动手。

3. 雕塑式构建：不追求一开始就有完美蓝图，而是边做边发现形状。“不行就扔，或者重提示”——试错成本极低，让形状从过程中浮现。

4. 最小闭环：将大任务拆解为小步骤，每步都能产出可验证的结果。小步快跑，频繁提交，保持对方向和质量的掌控。

5. 反馈闭环是关键：让 AI 能自己测试、自己 debug。有了测试和 CI，你不需要逐行审查，可以信任流程。

6. 基本功比以前更重要：AI 放大的是你的已有能力。系统层面的理解、判断力、“知道该问什么”——这些才是 AI 时代的核心竞争力。

7. 好奇心是最大的武器：你拥有一台“无限耐心的机器”，可以不停地问“为什么”。工具是平等的，好奇心是不平等的。

最后，记住 Peter Steinberger 的那句话：与 AI 协作是一门需要学习的“语言”。一开始可能会在凌晨三点对着它吼，但慢慢地，你会学会它的思维方式，几乎每次都能得到想要的结果。

这不是“AI 全自动的软件工程”，而是“AI 增强的软件工程”。你付出的每一点学习和改进努力，都会通过 AI 的放大得到数倍的回报。

祝你在 AI 协作编程的道路上，不断精进，成为驾驭 AI 的卓越开发者。

11 附录：资源与延伸阅读

构建 AI 编程工作流是一个综合性课题，这里列出一些优秀资源供进一步学习。读者可根据需要查阅，巩固和扩展本指南所涵盖的内容。

• Cursor 官方博客与文档：了解 Cursor 最新功能和最佳实践的权威来源。例如，官方博客的文章《使用 Agent 编码的最佳实践》详细讲解了从规划、上下文管理到自定义工作流的技巧。Cursor 官方中文文档站点也提供了规则、技能等功能的解释和示例。
• AI 编程工作流指南（SegmentFault）：一篇面向 2026 的实战指南（作者俞凡），总结了将 LLM 当作结对编程助手的 10 条准则，包括先写规格再写码、小步迭代、充分提供上下文、保持 Human-in-the-loop 等。本指南的很多理念与其不谋而合，强烈推荐阅读原文以获得更系统的认知。
• Cursor 高级配置与技巧：社区有不少分享 Cursor 使用技巧的文章，如《全网最全 Cursor 配置指南：从入门到高效工作流》，详细介绍了如何选择更强模型、扩大上下文、使用 @ 引用、集成外部文档和 MCP 等配置，可以帮助你将 Cursor 调校到最佳状态。另有《高效使用 Cursor 的 12 条黄金法则》也总结了一些宝贵经验。
• 自定义 Rules 和 Skills：想深入掌握 Cursor 扩展能力的读者，可以参考 Cursor 官网关于规则和技能的文档。另有中文社区文章对 Cursor Rules 的工作原理及四种类型做了浅析，GitHub 上也有他人整理的中文 Rules 示例仓库供参考。了解这些有助于你打造自己的个性化 AI 小助手。
• AI 辅助开发社区经验：加入相关社区以获取他人实践心得。例如 Reddit 的 r/ChatGPTCoding 板块，有用户分享他们日常的 Cursor AI 工作流程；Bilibili 上也有系列视频教程演示 Cursor 从入门到实战的全过程。知乎、掘金等平台上亦不乏 Cursor 的使用案例和避坑指南。阅读和观看这些内容，能让你少走弯路、发现新技巧。
• 传统开发方法论书籍：不要忽视经典书籍的价值。《The Pragmatic Programmer》（《程序员修炼之道》）、《Clean Code》（《代码整洁之道》）、《Refactoring》（《重构》）等书中蕴含的原则在 AI 时代依然适用，甚至更加重要。将这些原则与 AI 工具结合，是打造高效工作流的最佳途径。
• AI 伦理与安全：提醒关于 AI 使用的伦理和安全方面资源。随着 AI 深度介入开发，要注意避免泄漏敏感代码到云端、警惕 AI 可能引入的有害代码片段等问题。可以参考微软等发布的安全指南，以及相关使用政策，确保在合规、安全的前提下使用 AI 工具。

希望以上资源能帮助你进一步深入学习。在 AI 编程工作流的探索之路上，多看、多问、多实践是关键。愿你不断汲取新知，在实践中融会贯通，早日将本指南的理念内化为自己的工作习惯，不断精进，做一个驾驭 AI 的卓越开发者！

1

在过去的半年时间里，我几乎没有亲自写过一行代码。代码都是让AI帮我写的。

说实话，AI写的代码比我写得好，比我写得快。那么AI把我的活儿都给干了，那我干什么呢？凭什么我还能上班领工资呢？

作为一个“离AI最近的行业”从业者，我想通过这篇文章分享三条亲身体会的感想。对，就是感想。并不是什么AI使用技巧，也不是AI入门手册，就是感想。

AI发展日新月异，所有具体的操作和步骤都可能会过时，但是切身体会的感觉和想法不会过时。我身上感受到过的，以及我脑子想到过的，你都很快会感受到和想到。

2

第一点感想就是，如果你想知道AI有多厉害，就要用最贵的工具。

我跟很多人安利过AI聊天工具。他们给我的反馈一般都是：我用过了，感觉一般般。

听到这样的回答，我很惊讶——为什么对我来说惊为天人的发明，他们会无动于衷呢？很大的一个原因就是他们没用过最好的AI聊天工具。

最好的AI聊天工具都是国外的，OpenAI的ChatGPT、Google的Gemini和Anthropic的Claude。

我用过国内的AI聊天工具，如果是闲聊的话还可以。但是如果谈论的是专业的话题或者是深刻的话题，国内的AI聊天工具都比不上我刚才列举的三个。如果你分辨不出它们的高下，很可能是因为你提的问题都很浅。

回到工具这个话题，我之前一直在Cursor里用的是GPT 5.2这个模型，价格比较适中。我有听说过Claude编程更厉害，但是太贵了，调用一次的价格是GPT 5.2的好几倍。所以，我一直没敢真的尝试用Claude来帮我写代码。

机缘巧合之下，我心血来潮订阅了200美元一个月的超级会员，能用的额度一下子多了起来。于是乎，我就开始使用Claude。结果，非常惊喜。

Claude的代码完成度非常高，而且经常有自主性的发挥，帮我查缺补漏。用人来类比的话，Claude就像一个聪明的下属，不但能帮你把安排给他的事情都保质保量完成，还经常会给你额外的惊喜。

试用之后，我再也回不去了。曾经沧海难为水。用别的模型帮我编程，我总觉得他们笨笨的。

3

第二点感想就是，如果AI工具能完成一项工作的99%，你就应该交给他，然后你去找更重要的事情去做。

前几年，AI还没那么聪明能干，写出来的代码只有一半能用。最近大半年，AI进化得非常快，写出来的代码99%都可以用。在这种情况下，我就不写代码了，我去做更重要的事情——需求澄清、安全加固和架构设计。

就好比你培养一个下属。一开始，他没什么经验，你交给他的事情，一半能做好，一半还需要你帮他兜底和擦屁股。后来，他边学边进步，你交给他100件事情，他99件都能做好。那么你就可以把自己的岗位让给他，你晋升到更高的岗位上，做更重要的事情。

有人问，那如果我没有能力晋升，也不想做更重要的事情，怎么办呢？那局面就很不妙了，你要么就另谋出路，转行到没有那么多竞争的地方，要么就要面临被淘汰的残酷现实。

一开始，我的心态是很轻松的。觉得AI能帮我写代码，我可以不用那么累了，可以摸鱼了，可以偷懒了。

后面我发现根本就不是那么一回事。公司迟早会发现，或者我的同事们迟早也能学会用AI写代码，到时候对我这个岗位的要求就不只是会写代码那么简单了，必然会有更高的要求。

AI带来的危机感终将平等地降临到每一个普通人头上。只是有些人早一点，有些人晚一点。

4

第三点感想就是，我们要做创新的事情，创新就需要“浪费”。

我开通了Cursor的200美元每月的超级会员之后，发现额度还不够用，就用另一个账号也开通了超级会员。也就是说，我每个月要花400美元，大概2800人民币。

因为有大量的额度可以用，我开始用AI做各种各样的尝试。除了写代码，我让他帮我检查代码、做接口测试，最近还让他帮我控制浏览器页面，像真人一样操作，测试系统有没有问题。

这些尝试都很花钱，每天我用掉的额度都在30美元到50美元左右。但是我觉得非常值。我积累了很多其他人还没接触到的AI使用技巧和经验，能用更先进的方法来完成工作。

不管你是做什么工作的，我都建议你要做这样的尝试。一开始你可能会觉得是在“浪费”钱，或者是“浪费”时间，但是尝试过后你就会发现，投入到AI里的每一分钱和每一点时间，都会是值得的，更是必须的。

因为你现在干的工作，未来“有的是AI干”。

5

AI浪潮之下，我一开始的感觉是惊喜。因为终于有“人”可以跟我对话，可以给我解答问题，可以跟我讨论了。

后来，我的感觉是庆幸。AI首先冲击的是初级和中级编程岗位，轮不到我头上，我不怕。

接着，我的感觉是恐慌。AI写的代码比我好，写的速度比我快，我会不会很快就被淘汰呢？

最后，我的感觉是平常心。用一颗平常心面对AI的发展，保持学习的劲头和学习的速度，面对新时代的挑战和机遇。

不就是学习吗？在下不才，恰好精通此道。

1

上个月的阅读情况很不理想。看书229小时，低于原定目标的250小时。不仅是2025年一整年看书最少的一个月，还是最近两年多以来最低点。

冥想情况有所好转。冥想了33.5小时，比前一个月多。

接下来一个月，也就是一月份，我的阅读时间会有一个明显的上涨。因为，我“复活”了番茄土豆APP。

2

我的阅读数据一直以来都是用APP记录的。APP的名字叫番茄土豆，开发的公司已经倒闭了。APP从去年8月份开始就用不了。

去年我用很短的时间，用一个简单的网页版做了一个替身出来。勉强能用，可以帮我记录阅读数据，但是并不好用。

前天晚上，我突发奇想，不如用AI辅助编程帮我重新开发一个番茄土豆APP吧。

说干就干。我问了ChatGPT要如何在Macbook上开发iOS程序，以及如何在自己的手机上安装。扣除下载安装开发工具的时间，我只用了半个小时就做出MVP版本。

在接下来的两天时间里，我的阅读热情高涨了很多，因为可以用顺手的APP来帮我记录阅读。即便有不顺手的地方，我马上就可以改代码。当然，不是我自己改，是我给AI指令，让AI帮我改。

用AI写APP的过程，我几乎没有遇到障碍，一行代码都不用自己写。

3

我思考了为什么“复活”的番茄土豆APP能让我变得更加积极阅读。这个原因就是，助推。

你爱不爱做一件事，想不想做一件事，最初的动力是很难改变的，别人是不可能帮你的。

一个不爱看书的人，你做一个再好用、再定制的APP给他，他还是不爱看书。相反的，即便没有APP，我还是会看书，而且是主动看书。

然而，有APP和没APP，对我来说，对一个有阅读意愿和阅读习惯的人来说很重要。有了APP，我会更容易想到要看书，会在看完书之后更有成就感，下一次更愿意看书。没有APP，看书的次数就会明显打折扣。

就像健身，如果一个健身房装修很好，设备很新，服务很周到，我肯定会去更多次。相反的，如果这个健身房年老失修，没什么服务，我就不愿意多去了。

好的APP，就像好的装备一样，能帮助一个人更好地坚持做一件事。

4

我是最近才享受到了编程的乐趣。

首先，AI让编程变得容易，变得更加有趣。

还有，我从编程中总结出一个人生哲学的道理。这个道理，可以从拍照开始说起。

手机让拍照变得容易，我们每个人或多或少都会拍照。有的人喜欢自拍，留下自己年轻好看的样子。有的人喜欢拍孩子，发朋友圈炫耀自己的孩子多可爱。有的人喜欢拍风景，记录自己欣赏大自然的瞬间。

那么，到底是什么决定一个人在什么时候拍照，拍多少张，拍什么的呢？是他们的价值观。

他们的价值观告诉他们，什么是美好的，什么值得拍。

相对应的，编程也是同样的道理。代码只是工具，编程的目的是收集信息、处理信息和使用信息。

那么到底哪些信息重要，这些信息要怎么处理，最终要使用到什么地方。这些是什么决定的呢？是我们这些Coder的价值观。

Coder的价值观告诉我们自己，哪些信息是重要的，哪些信息值得注意。

你有没有发现，其实照片就是信息。拍照和写代码一样，都是判断哪些信息重要，然后把信息收集起来，然后就是处理和使用。只是工具不一样罢了。

想明白了这个道理，我觉得编程更有意思，也更有意义。

5

最近一段时间，我会不断优化我复活的“番茄土豆”APP。优化的过程，就是使用的过程。使用越多，我看书就越多。

这就是正向循环。

截至2025年12月31日，我一共阅读了19138.5小时。预计会在2026年4月10日，完成第二个10000小时，也就是总共20000小时的阅读目标。

一月份的阅读目标是540个番茄时间，也就是270个小时。

1

今年的年度总结，从一条给我带来认知冲击的新闻开始说起。

近两年，已经有不少省市把“计算机科学”、“软件工程”等专业列为红牌专业，建议考生谨慎报考。

这之所以会让我觉得震惊，不仅仅是因为我是计算机专业毕业的，还因为前几年计算机专业还非常热门，而且供不应求。

那真是一个黄金年代。哪怕你不是计算机科班出身，去报一个软件开发的培训班，稍微努努力就能找到一份月薪万元的工作，而且前景相当好。跳槽勤快点，平均每年涨薪15%到20%不是什么不可思议的事情；哪怕你不喜欢跳槽，在一家还算不错的公司一直干，年均涨薪10%是很普遍的。

在那个年代，经常会流传这一类故事：某一个能力平平的程序员加入到一家默默无闻的创业公司，公司被收购之后就财富自由了。

如果你没有经历过那个年代，你也可以看看我七八年前写的文章。那时候我天真地认为，每年涨薪10%到20%是理所应当、天经地义的事情。

从震惊中恢复过来，我总结出有三点原因：

• 第一，整体经济下行。
• 第二，招生扩张过快。
• 第三，AI辅助编程突破。

前两条原因无须过多解释。第三点原因的来龙去脉是这样的：由于大语言模型的横空出世，AI辅助编程有了很大的突破——从原来简单的模板代码生成和代码补全，直接进化到可以从头到尾完成一个中小型需求的开发。

也就是说，原来需要一个高级程序员带着两三个中级、初级程序员干的活儿，现在只需要一个高级程序员就可以了。

那么，中级程序员和初级程序员有没有可能替代高级程序员呢？答案是，不能。他们之所以不是高级程序员，就是因为他们还没有应对复杂度需求的能力。

另一方面，AI生成的代码所潜藏的问题往往是他们看不出来的。这既是能力决定的，也是经验决定的。

于是，这就出现了一个很奇怪的局面——在招聘市场上，中级、初级程序员的岗位变少了，而高级程序员和资深架构师的岗位变多了。

其实，不是市场需要的程序员变少了，而是对程序员的要求变高了。

2

市场上的变化，导致「35岁」现象出现了逆转。

在此之前，程序员行业一直有一个说法——“35岁如果升不到管理岗，就很容易失业”。这个说法的现实基础是，写代码虽然是一个脑力活，但是很多时候会变成一个体力活。在AI辅助编程取得突破之前，有很多重复的工作需要做，而且常常因为需求变更或者是应对突发情况要加班，所以程序员大多要能熬夜。

35岁不做管理、只编程，就会有两个劣势。第一，你的工资高；第二，你的熬夜能力比不上小年轻。

如果没有X因素出现，今年34岁的我很快就要考虑转行或者降薪做外包。在2025年，X因素出现了。

2025年年初，各大AI辅助编程工具推出了Agent模式。从原来只能简单辅助程序员写代码，进化到了可以完成中小型需求的全部代码编写的程度。程序员的重复性工作和简单的任务急剧减少，这就导致了中级、初级程序员岗位的市场萎缩。

与此同时，由于AI辅助编程导致软件开发的成本出现了下降，继而导致了软件市场的需求量反而变大了。这就是经典的杰文斯悖论（Jevons paradox）——当某种资源/技术的单位成本下降、效率提高时，结果往往不是总消耗下降，反而会因为使用变得更便宜、应用场景扩张而让总需求/总消耗上升。

这个悖论来源于19世纪的英国。经济学家William Stanley Jevons发现，瓦特蒸汽机提升了煤的使用效率，降低了单位效用的成本，结果使得蒸汽机被更广泛地应用到更多场景，使得煤的需求不降反升。

这个悖论，不仅出现在第一次工业革命，还出现在第二次工业革命。电力越来越便宜，电力的普及范围就越广泛，最终使得电力的需求越来越高。

互联网时代如此，AI时代也如此。

3

我是幸运的。如果早出生几年，我很可能就已经要转行了。如果晚出生几年，我很可能毕业即失业，很难找到工作。

我觉得我更幸运的是，编程对我来说变成一件好玩的，有意思的事情。这对于我来说，要比工作更好找、能赚更多钱重要得多。

我是在今年8月份开始使用AI Agent帮助我写代码的。在此之前，写代码已经让我很厌倦了。

第一，写代码很孤独。写代码的时候，你没法跟别人讨论。程序员很贵，每个人都很忙，都要赶时间把自己负责的那部分写完。无论是一起讨论设计，还是code review，很多时候都已经沦为形式。

第二，写代码很琐碎。写代码要注意很多的细节，你稍不注意就会犯很基础的错误。哪怕再小的错误，都有可能变成在亚马逊雨林里煽动翅膀的那只蝴蝶，在你意想不到的时候和意料不到的地方掀起一场灾难性的风暴。

第三，写代码很无聊。正如之前所说，写代码的过程中有很多简单重复的工作，这些活儿很容易消耗你的耐心和激情。

使用AI Agent之后，这一切都变了。

写代码变得不孤独了。我从理解需求开始，就可以跟AI讨论。把需求讨论明白了，我就让他给出设计，提供好几个方案让我挑选。方案细节确定好了，我就让他帮我落地代码。最后，我再检查他的代码实现是否符合预期。

写代码变得不琐碎了。AI能把琐碎的事情做得很好，而且做得很快。我可以让他反复检查代码，甚至可以让不同的AI Agent互相检查。

写代码变得不无聊了。AI天生就不怕重复，不怕简单。我的心智宽带就可以解放出来，去思考更多更高级的事情——更好地理解需求，更好地设计架构，更好地重构代码。这些事情，更有意思。

4

编程更有意思，更好玩了。我也发现我恰好擅长用AI编程。

首先，我有丰富的AI对话经验。我从2023年5月份开始，就高强度地使用ChatGPT。我一边看书，一边向AI提出问题，跟他讨论更大范围的话题，并不局限于书中的内容。直到这篇文章写作的此刻，我已经跟AI对话了1800小时。

然后，我喜欢在对话中学习。出现了AI之后，我可以在一边工作，一边跟AI学习各种各样之前不熟悉的知识。学习和实践，结合得更加紧密了。

最后，我特别擅长把模糊的问题变成清晰可执行的步骤。我厌恶模糊，喜欢清晰。我乐意把工作和生活拆解成一个个计划和执行清单，在规划、执行、反馈和优化中获得乐趣。

我很幸运，恰好能用自己喜欢又擅长的事情养活自己。

5

近几年，我越来越厌恶过去信奉的“优绩主义”——认为优秀的人就应该得到更多；不优秀就意味着不努力，就意味着一个人是失败的。

我逐渐让自己转向“我对什么感兴趣”。什么事情能引起我的兴趣？做什么能让我兴奋起来？学习什么样的内容可以让我的大脑进入激活状态？

这是一个艰难的转向。作为一个接受了十几年应试教育的中国学生来说，尤其我还是某种程度的既得利益者，我很难不信奉优绩主义。从小，爸妈就告诉我分数高才能上好学校。上学时，学校因为我成绩好才不收或少收我学费。毕业之后，我也因为学历得到比一般人多得多的面试机会。

这是一个必然的转向。我越来越意识到优绩主义对我的伤害。我一旦做得没那么好，我就会质疑自己，甚至会质疑自己存在的价值。我对一件事情感兴趣的同时，就会下意识地问自己“这对我有什么好处”。我对他人的评价不怎么取决于他们是否友善、幽默、慷慨和关心他人，而是他们是否足够“优秀”。

在接下来的一年时间里，我会连续订阅12个月200美元每月的Cursor会员，并且每个月都要用完里面的额度。我希望大量的实践，能给我带来足够的灵感、激情和创造力。每个月，我都至少写一篇文章，记录我使用的心得和感想。

与此同时，我会更多地问自己，我对什么感兴趣，我想要做什么，我更想把时间放在什么事情上。

1

十一月份阅读情况还可以。看书234.5小时，超过原定目标的230小时。

冥想情况比较一般。这个月冥想了26.75小时。可能是因为这个月的工作比较轻松，压力没那么大，所以冥想就少了。这个月要有意识增加一些冥想时间。

接下来，我想跟大家聊一聊我是如何坚持健身的。

2

从6月到12月，我坚持健身了整整半年。我是怎么坚持下来的呢？

当然不是靠热情。热情只有在开始阶段管用，后面就不行了。我在刚开始的时候，试过一周六练——除了每周上四节私教课，我还会额外自己去健身房练两天。这是我热情最高涨的时候。

热情很快就退却。接下来的几个月，我几乎一次都没有自己主动去过健身房，除了上私教课之外。

坚持要靠制度。我跟我的私教在一周结束时，就会约定下一周的课——一周四练，分别是哪几天上课。我是一个非常信守承诺的人，没有特殊原因的话，我不太可能会取消上课。有那么好几次，我因为睡不好而非常不想去上课，内心挣扎一番之后还是去了。

每次遇到这种情况，我都会感慨：私教课的钱，花得真值。

3

有一段时间，我的私教生病住院，不能带我上课。我又是一个社恐的人，不想临时让其他教练带我上课。于是我就自己去锻炼。

自己去锻炼的效果远没有教练带着我锻炼要好。我总是偷懒，做力量训练的重量会轻一点，做动作的每组次数会少几次。

因此，好几次我都不想去锻炼，觉得这么低质量的锻炼，不如不锻炼。但是，我后来还是去了。

因为就坚持而言，锻炼的质量是次要的，锻炼的数量（次数）才更重要。

我说服自己，哪怕是去健身房打个卡，我也要去。哪怕我是去健身房玩手机，我也要待够一个小时。

我不可能真的完全只看重数量，而完全不重视质量。所以只要坚持去锻炼，数量够了，质量自然会上去。

我相信，哪怕以后不请教练了，我还是很有可能继续坚持锻炼的。

4

如果你锻炼了半年，花了两万块的私教课费用，小肚子还是没减下去，体重没有变化，你还会继续锻炼吗？

我会。

因为这半年时间里，我的身体素质变好了，睡眠变好了，心理健康变好了。我还会坚持锻炼下去。

首先，我知道自己没有注意饮食。注意饮食要消耗注意力和意志力，我担心同时要兼顾工作压力和锻炼压力，再加上克制饮食的话，我会坚持不住。所以有意无意的，我没有让自己注意饮食，还是跟往常一样。

然后，减肥和增肌，甚至是有一个健美的身材，对我来说只是一个次要的目的。次要的目的，能达到很好，达不到也没关系。或者说，晚一些达到也可以。

身心健康，睡眠变好，让我的脑子转的更快，能更好地应对工作和学习，才是我锻炼的主要目的。主要目的，不仅达到了，而且是超出了预期。

5

这么多年的阅读，给我带来一样很重要很重要的东西，就是耐心。我学会了耐心地、长期地做一件事情，只要它足够重要。

健身锻炼对我来说就是一件足够重要的事情。我才做了半年，我不会奢望就有非常惊人的效果，例如减重20斤，长出六块腹肌和人鱼线。

就像之前设定的一样，我的中期目标是两年内身体素质明显变好——每天睡够7.5小时，心率变异度能到50ms以上，体脂率降到20%以下。

长期目标是坚持健身二十年后，身体年龄比实际年龄小5到10岁。

截至2025年11月30日，我一共阅读了18909.5小时。预计会在2026年4月10日，完成第二个10000小时，也就是总共20000小时的阅读目标。

十二月份的阅读目标是500个番茄时间，也就是250个小时。

1

特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。

1 核心理念：思考与执行分离

没有人会让建筑工人一边砌砖一边设计图纸。这个道理显而易见：设计需要全局视野和反复推敲，施工需要专注细节和高效执行——两种工作模式截然不同，混在一起只会两头都做不好。建筑行业早就想明白了这一点，所以有了建筑师和施工队的分工。软件开发也是如此，在使用 Cursor 时，你应当将问题推理和代码编写明确区分开来——先让 AI 帮你规划解决方案，确认无误后，再让它执行编码。

Cursor 为此提供了两种模式：Plan 模式是你的”作战室”，在这里与 AI 讨论思路、澄清需求、制定计划，让它复述你的要求，给出实施步骤，甚至画出架构草图；Agent 模式是你的”施工队”，一旦方案敲定，Agent 会按照计划自主探索项目、修改代码，像一个勤勉的工程师那样完成任务。

一个典型的协作流程

假设你要实现一个用户积分系统。错误的做法是直接告诉 Cursor：”帮我实现用户积分功能”，然后看它自由发挥。正确的做法是分两步走：

第一步：Plan 模式讨论方案

我需要实现一个用户积分系统，包括积分获取、消费和查询功能。请先不要写代码，帮我分析一下：

1. 需要哪些数据表？
2. 需要哪些接口？
3. 有哪些边界情况需要考虑？

Cursor 可能会回复：需要 user_points 表记录余额，points_record 表记录流水；需要考虑并发扣减的原子性问题；建议使用乐观锁或数据库事务… 你审核这个方案，发现它漏掉了积分过期的需求，于是补充：”积分有有效期，需要支持过期自动失效。”

第二步：确认后切换 Agent 模式执行

方案敲定后，告诉 Cursor：”方案确认，请按照上述设计实现代码。”Agent 会根据之前讨论的方案，自动创建实体类、Mapper、Service 和 Controller。这个”复述仪式”看起来多了一步，但它能避免方向性错误，省去大量返工。

中间产物：你们之间的”合同”

如果任务复杂，不妨要求 AI 先输出一份 Markdown 格式的设计方案。这份中间产物就是你们之间的”合同”：

请把刚才讨论的积分系统设计整理成一份 Markdown 文档，包括数据表结构、接口定义和关键逻辑说明。保存为 docs/积分系统设计.md。

确认文档无误后，后续的编码就有了明确的依据。即使中途会话中断，这份文档也能帮助你快速恢复上下文。在 Chat 思考阶段，你是架构师，与 AI 一起推演方案；在 Agent 执行阶段，AI 是工程师，负责落实细节。这种分工不仅适用于软件开发，也适用于任何需要先想清楚再动手的工作。

2 多轮对话技巧

2.1 分支选择：在岔路口做出正确的决定

下棋的人都知道，一盘棋的胜负往往取决于几个关键的分支选择，走错一步，后面再怎么努力都难以挽回。与 AI 对话也是如此——面对复杂任务，Cursor 可能会提出多种方案，或者在执行过程中出现不同的分支路径，你的任务是在这些岔路口做出正确的选择。

实战案例：选择缓存方案

你让 Cursor 为热点数据添加缓存，它可能会提出三种方案：1) 使用 Spring Cache + Redis；2) 使用 Caffeine 本地缓存；3) 使用 Guava Cache。这时不要急着让它实现，先问清楚每个方案的优缺点：

请分析这三种缓存方案的适用场景、优缺点和性能差异，帮我选择最合适的方案。我们的场景是：QPS 约 1000，数据更新频率较低，需要支持集群部署。

Cursor 会解释：本地缓存性能最好但不支持集群同步，Redis 支持集群但有网络开销… 根据你的场景，它可能建议使用两级缓存：本地缓存 + Redis。这种”先问方案，再选择，最后执行”的模式，能避免在错误的技术路线上浪费时间。

2.2 链式思考：让 AI 一步一步推理

1956年，认知心理学家乔治·米勒发表了著名论文《神奇的数字7±2》，揭示了人类工作记忆的容量限制。有趣的是，大语言模型也面临类似的挑战——当问题足够复杂时，一步到位往往会出错。解决办法是链式思考（Chain-of-Thought）：让 AI 逐步分析问题，而不是直接给出最终答案。

实战案例：排查 NPE 异常

当你遇到一个难以定位的空指针异常，可以这样提示：

项目启动时报 NullPointerException，堆栈信息如下：[粘贴堆栈]

请使用链式思考方法分析：

1. 这个异常发生在哪一行？
2. 哪个变量可能为 null？
3. 这个变量是在哪里被赋值的？
4. 为什么在这个时机它可能还没被赋值？
5. 应该如何修复？

AI 会按步骤分析：异常发生在 UserService 第 42 行，userRepository 为 null，它应该通过 @Autowired 注入，但可能因为循环依赖导致注入失败… 这种逐步推理比直接问”怎么修”更容易找到根本原因。

2.3 保持目标一致性：别让 AI 跑偏

心理学家丹尼尔·卡尼曼在《思考，快与慢》中描述过一种现象：人们在解决复杂问题时，常常不知不觉地偷换了问题本身。AI 也有类似的倾向——它可能在推理过程中逐渐偏离你的真正目标。

实战案例：优化查询性能

你让 Cursor 优化一个慢查询，它可能会热情地重构整个数据访问层，引入新的 ORM 框架，甚至建议更换数据库… 这时要及时拉回来：

停一下。我的目标只是优化这一个查询的性能，不需要重构整个数据层。请聚焦在：

1. 分析当前 SQL 的执行计划
2. 建议合适的索引
3. 优化 SQL 写法

其他架构调整不在本次范围内。

如何防止跑偏？经常性地在提示中重申最终目标或关键约束；每轮回复后，先验证思路是否仍围绕目标；必要时直接纠偏：”请关注 XXX 目标，不要偏离 YYY 方面”。就像长途旅行需要不断核对地图，与 AI 的长对话也需要反复校准方向。

2.4 绕开错误链路：及时止损

有时候你会发现，Cursor 正沿着一条错误的道路推理——可能是误解了需求，也可能是采用了不合适的技术方案。这时最重要的是及时止损，不要试图在错误的基础上修修补补，那只会越陷越深。

实战案例：事务处理的误区

你让 Cursor 实现一个订单创建功能，它生成的代码在循环中逐条插入订单明细，没有使用事务。你指出问题后，它加了 @Transactional，但注解加在了私有方法上（这在 Spring 中不生效）。这时不要继续在这个方向上修补，而是重新开始：

刚才的实现有事务问题。让我们重新来：

1. 首先，请说明 Spring 事务的正确使用方式
2. 然后，重新设计这个订单创建流程，确保原子性
3. 考虑异常情况下的回滚策略

具体怎么做？首先澄清问题或需求，消除 AI 可能的误解；明确指出之前方案的问题；必要时缩小问题范围，从更基础的问题开始，逐步建立正确的推理链路。你还可以通过 .cursorrules 文件来限制 AI 的修改范围与风格。一旦发现错误趋势，立即重置思路或回滚——在错误的路上走得越远，回头的代价就越大。

3 提示词模板

语言学家沃尔夫提出过一个著名假说：我们使用的语言，会影响我们思考的方式。在与 AI 协作时，这一假说同样适用——你如何表达需求，直接决定了 AI 如何理解和执行。下面是几个经过验证的提示词模板，专为 Java 后端开发者设计。

3.1 “先画接口，不要写代码”

建筑师不会在画完图纸之前就开始砌砖。同样，开发新模块时，你可以这样提示：

我需要实现一个商品库存管理模块，包括：查询库存、扣减库存（需要支持批量）、库存预警通知。

请先设计接口：

1. Controller 层的 API 定义（路径、方法、参数、返回值）
2. Service 层的方法签名
3. 请求和响应的 DTO 类结构

不要写实现代码，我们先确认设计。

Cursor 会输出清晰的接口蓝图，你确认设计合理后再让它生成实现。这一策略体现了推理与编码分离的思想——代码落地前，先确保设计经过充分推演。

3.2 “伪代码先出”

当实现复杂功能时，直接写代码容易陷入细节。不如先让 AI 产出伪代码：

我需要实现一个分布式锁服务，基于 Redis。请先用伪代码描述实现思路：

1. 加锁的流程（包括重试机制）
2. 解锁的流程（包括防止误删其他线程的锁）
3. 锁续期的机制

用中文注释写清楚每一步的逻辑，确认无误后再填充具体代码。

这就像先写提纲再写文章。Cursor 会先给出详细的步骤说明，你审核伪代码确认无误后，再让它填充细节。两阶段输出，能大幅减少来回修改。

3.3 “先别急着写”

这是一个简单但极其有效的模板：

我需要实现一个定时任务，每天凌晨2点清理30天前的日志数据。清理时要分批删除，避免锁表。同时要记录清理结果，如果失败需要告警。

在写代码之前，请先复述一下你理解的需求，确保我们在同一页面上。

Cursor 会用自己的话总结需求，你可以校验它的理解是否正确。如果有误解可以立即纠正。这就像医生在手术前确认患者信息——一个小小的确认步骤，可以避免方向性错误。

3.4 “逐步求精”

优化代码时，一步到位的重构往往风险很高。不如让 AI 渐进式改进：

下面这段查询代码性能较差，请逐步优化：

[粘贴代码]

要求：每次只做一项改进；解释改进的原因和预期效果；保持原有接口不变；等我确认后再进行下一步。

Cursor 可能会这样回复：”第一步优化：将循环内的数据库查询改为批量查询。原因：当前代码在循环中逐条查询用户信息，N 次循环就有 N 次数据库往返，改为批量查询后只需 1 次。” 你确认后，它再进行第二步优化。每次改动都在掌控之中，也方便定位问题。

3.5 “禁止使用某技术/库”

如果项目有技术选型限制，可以直接告诉 AI：

实现时请遵守以下约束：

• 不要使用 Lombok（项目未引入）
• 不要使用 Java 8 以上的语法特性（兼容性要求）
• 不要直接操作 Thread，使用线程池
• 不要硬编码配置值，使用 @Value 注入
• 不要使用 System.out.println，使用 Logger

通过列出禁止事项，可以有效防止 AI “越界”，确保生成的代码符合项目规范。

3.6 “对比分析”与“代码审查者视角”

当你不确定该选哪种方案时，可以要求对比分析：

请对比分析以下两种实现方式的优缺点，并给出推荐：
方案A：使用消息队列异步处理
方案B：使用 @Async 注解异步处理

从以下维度分析：可靠性、复杂度、可观测性、运维成本

也可以让 AI 扮演代码审查者：

请以高级工程师的视角审查以下代码，指出：潜在的 bug 或边界情况、性能问题、安全漏洞、代码规范问题、可维护性改进建议。

建议：团队可以沉淀自己的高频 Prompt 库，将常用场景（登录认证、CRUD 接口、分页查询等）的提示整理成模板。新人也能快速上手，提示越清晰结构化，AI 输出就越准确。

4 Java 后端场景专用技巧

4.1 接口设计：先契约，后实现

在微服务架构中，接口就是服务之间的”合同”，合同写得不清楚，后面就会纠纷不断。使用 Cursor 进行接口设计时，最佳实践是先编写接口规范，再写实现——让 Cursor 根据需求文档先输出接口设计草图（类名、方法名、参数和返回值、HTTP 路径和动词），然后由你审核调整，最后再生成实现代码。

提示词示例：

根据以下需求，设计用户管理模块的接口（方法签名和请求/响应结构），先不要实现代码：

功能需求：用户注册（邮箱、密码、昵称）、用户登录（返回 JWT token）、获取当前用户信息、修改用户资料。

设计要求：RESTful 风格；统一响应格式 {code, message, data}；需要考虑参数校验注解。

对于需要与前端对接的 API，Cursor 还能生成接口文档说明，帮助前后端对齐契约。接口设计阶段多花的时间，会在后续开发中成倍节省。

4.2 数据库操作：MyBatis 与 JPA

数据库操作是后端开发的核心。Cursor 可以帮你快速生成 Mapper 和 Repository 代码，但需要明确告诉它你使用的技术栈。

MyBatis 场景：

根据以下表结构，生成 MyBatis 相关代码：

1 2 3 4 5 6 7 8 9

CREATE TABLE t_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2), status TINYINT DEFAULT 0, created_at DATETIME, updated_at DATETIME );

请生成：Order 实体类（使用驼峰命名）、OrderMapper 接口（包含 CRUD 和按用户ID查询）、OrderMapper.xml 文件、复杂查询使用动态 SQL。

JPA 场景：

使用 Spring Data JPA，根据上述表结构生成：Order 实体类（包含 @Table、@Column 注解）、OrderRepository 接口、包含自定义查询方法（按状态统计、按时间范围查询）、使用 @Query 注解的复杂查询。

4.3 Filter 链路控制与异常处理

Web 应用中的过滤器链路，就像流水线上的工序——顺序错了，产品就废了。添加新过滤器时，要明确告诉 Cursor 它在链路中的位置：

请创建一个新的过滤器 AuditFilter，用于记录请求日志，插入到 SecurityFilter 之后执行。需要记录：请求路径、方法、参数；响应状态码、耗时；用户 ID（从 SecurityContext 获取）；异常信息。日志格式使用 JSON，方便后续分析。

对于异常处理，优雅的统一封装是后端服务成熟度的标志：

请实现一个全局异常处理机制：

1. 创建统一响应类 Result，包含 code、message、data 字段
2. 创建业务异常类 BusinessException，包含错误码枚举
3. 创建全局异常处理器，处理 BusinessException、MethodArgumentNotValidException、其他未知异常
4. 错误码枚举至少包含：SUCCESS、PARAM_ERROR、UNAUTHORIZED、FORBIDDEN、NOT_FOUND、SYSTEM_ERROR

需要注意的是，AI 生成的业务逻辑有时会忽略安全细节——比如登录代码可能缺少密码加密。这些细节需要在提示中明确要求，或在代码生成后手动检查补充。

4.4 单元测试与性能优化

让 Cursor 帮你生成测试代码：

为以下 Service 类生成单元测试：[粘贴 Service 代码]

要求：使用 JUnit 5 + Mockito；Mock 所有依赖的 Repository 和外部服务；覆盖正常流程和异常流程；边界条件测试（空值、极限值）；使用 @DisplayName 注解描述测试场景；遵循 Given-When-Then 模式。

让 Cursor 帮你分析性能问题：

以下接口响应时间达到 2 秒，请帮我分析可能的性能瓶颈：[粘贴代码]

请从以下角度分析：数据库查询（N+1 问题、缺少索引、全表扫描）；循环中的重复计算或 IO 操作；可以并行化的操作；可以缓存的数据；不必要的序列化/反序列化。

4.5 Request/Response 契约定义

前后端协作中，数据格式的约定往往是沟通成本最高的环节。Cursor 可以帮你快速定义 DTO/VO 类：

请求包含 userName 和 password 两个字段，返回结果包含 userId、token 和过期时间，请定义相应的请求和响应类。

要求：添加参数校验注解（@NotBlank、@Size 等）；添加 Swagger 注解描述字段含义；敏感字段（如密码）在日志中脱敏。

使用 Cursor 定义契约的好处是速度快且格式统一。但前提是你的描述足够清晰——AI 无法凭空猜测业务含义，字段用途、类型约束这些信息，都需要你提供。

5 代码重构策略

5.1 指定局部修改：手术刀而非大锤

重构代码时，最怕的是牵一发动全身——让 AI 修改一个方法，结果它把整个类都重写了，这种事并非没有发生过。如何避免？使用选区编辑：在编辑器中选中需要修改的代码片段再提问，AI 的作用范围就局限在选中部分；在提示词中明确限定范围；使用 @file 引用特定文件。

明确边界的示例：

请仅修改 OrderService.createOrder 方法中的库存扣减逻辑：

• 当前是先查询再更新，存在并发问题
• 请改为使用乐观锁（版本号）方式
• 不要修改方法签名
• 不要修改其他方法
• 不要修改 OrderMapper

Manual 模式下，AI 会严格执行你的指令。若 AI 产出修改超出范围，及时撤回并重新强调边界。

5.2 使用 diff 审核：每次修改都要过目

Git 的发明者林纳斯·托瓦兹有句名言：”Talk is cheap. Show me the code.”在与 AI 协作时，这句话可以改成：”Show me the diff.” 每次让 AI 修改代码后，都应该要求它输出变更摘要或 diff，尤其在 Agent 模式下进行跨文件修改，更要逐一对比原始代码和修改后的区别。

审核清单：是否有意外删除的代码？是否有意外添加的依赖？变量名、方法名是否被意外重命名？是否修改了不应该动的文件？格式变化是否过多？逻辑是否与预期一致？

养成先 diff 审核再接受修改的习惯，相当于给 AI 的每次”提交”都做一次代码评审。

5.3 避免格式化污染

有时 AI 修改代码会顺带调整格式、缩进、import 语句，导致大段无关变动，给代码审查和合并带来不必要的困扰。几种策略：在提示词中明确要求”不修改代码风格和格式”；分步进行，先让 AI 修改逻辑，确认无误后再单独处理格式；使用 .cursorrules 文件指定代码风格约束。

.cursorrules 示例：

1
2
3
4
5
6
7

# 代码风格约束
- 使用 4 空格缩进，不使用 Tab
- 大括号不换行（Java 风格）
- import 语句按字母顺序排列
- 不要自动优化 import
- 保持原有的空行风格
- 不要添加或删除注释（除非明确要求）

一旦发现 AI 输出中有大段格式改动，退回上一步并强调”保持原代码格式不变，仅做必要改动”。目标是让每次提交尽可能小而集中。

5.4 多文件协作：渐进式推进

重构经常涉及多个文件的同步修改——方法签名改了，调用它的地方也要跟着改。Cursor Agent 模式可以跨文件全局重构，但务必验证所有相关文件都正确更新。稳妥的做法是分步骤多文件修改：

我需要将 UserService.getUser(Long id) 方法重命名为 getUserById(Long id)。请按以下步骤执行：

1. 首先列出所有调用这个方法的文件
2. 修改 UserService 中的方法名
3. 逐个修改调用方，每修改一个文件后暂停等我确认
4. 最后检查是否有遗漏

这种渐进式协作可以与 Cursor 的任务切换功能相结合：完成一组文件的修改后，使用 /newtask 开启新任务，处理下一组相关文件。切换时让 AI 总结前一任务成果，保证上下文连贯。

6 项目协作与上下文管理

6.1 使用 .cursorrules 定义项目规范

.cursorrules 文件是 Cursor 的规则配置文件，放在项目根目录，可以告诉 AI 这个项目的技术栈、编码规范和特殊约束。

Java 后端项目的 .cursorrules 示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# 项目概述
这是一个基于 Spring Boot 2.7 的电商后端项目。

# 技术栈
- Java 11、Spring Boot 2.7.x、MyBatis Plus、MySQL 8.0、Redis、RabbitMQ

# 编码规范
- 使用阿里巴巴 Java 开发手册规范
- Controller 层只做参数校验和结果封装，业务逻辑放在 Service 层
- 使用 @Slf4j 记录日志，不使用 System.out
- 异常使用自定义 BusinessException，不要直接抛出 RuntimeException
- 数据库字段使用下划线命名，Java 属性使用驼峰命名

# 项目结构
controller/、service/、mapper/、entity/、dto/、vo/、config/、util/

# 禁止事项
- 不要使用 Lombok（项目未引入）
- 不要使用 Java 8 以上的语法
- 不要在循环中进行数据库查询
- 不要硬编码配置值

有了这个文件，Cursor 在生成代码时会自动遵守这些规范，大大减少后期修改。

6.2 多人协作与上下文传递

人类团队协作的核心挑战之一是知识的传递。新人接手项目时，最痛苦的往往不是代码本身，而是理解”为什么这样写”的上下文。与 AI 协作也面临类似问题：如何让下一位开发者（或下一次会话）理解之前的工作？

一个有效的方法是维护一个 progress.md 或 project-status.md 文件。在每次会话结束时，让 Cursor 将完成的功能、遇到的问题和解决方案写入其中：

本次会话结束时，将你的工作日志记录在 @project-status.md 文件中，包括：已实现的功能点、修改的文件清单、遇到的问题和解决方案、未完成事项和后续计划、需要注意的技术债务。

这样，当另一位同事接手时，只要查看这个文件，就能了解上一开发环节做了什么。把这些日志文件纳入版本控制，实际上就是把 AI 对话的精华持久化了。

6.3 版本控制对话与快速上下文重建

除了文本日志，一些团队还会将重要的对话导出为 Markdown 记录，存入项目文档。这可以视为某次 AI 辅助开发的”剧本”——日后查阅，可以明白当初 AI 和开发者是如何一步步做出决策的。对话记录的价值包括：技术决策的依据、问题排查的线索、新人培训材料、审计追溯。需注意对话记录中可能包含敏感信息，在公开之前要做好筛查或脱敏处理。

会话长度受限或意外中断时，如何让 AI 快速恢复上下文？如果之前有维护 project-status.md，新会话开始时直接将该文件提供给 AI：

请阅读以下文件了解项目上下文：

• @.cursorrules：项目规范
• @project-status.md：当前进度
• @docs/积分系统设计.md：相关设计文档

上次我们完成了积分获取功能，今天继续实现积分消费功能。

Cursor 读取这些文件后，就相当于”记起”了项目当前状态和最近进展。建议每次会话结束都记录详细报告——这正是为下次重建上下文做的准备。

7 高阶自动化流

7.1 结构化任务：让 AI 按清单执行

软件工程师阿图·葛文德在《清单革命》中写道：面对复杂性，清单是最有效的武器。这一洞见同样适用于与 AI 的协作。Cursor Agent 模式可以将复杂任务拆解为结构化的子任务列表，并按序自动执行。

实战示例：开发一个完整功能

请按以下任务清单开发”用户收货地址管理”功能：

任务清单

• 1. 设计数据表结构（用户地址表）
• 2. 创建实体类和 Mapper
• 3. 设计 API 接口（增删改查 + 设为默认）
• 4. 实现 Service 层逻辑
• 5. 实现 Controller 层
• 6. 添加参数校验
• 7. 编写单元测试
• 8. 添加 Swagger 文档

请逐项执行，每完成一项更新清单状态，并等待我确认后再继续下一项。

Agent 会边执行边维护任务列表，每完成一项就勾掉并继续下一项。开发者可以在执行过程中插手调整——修改顺序、增加遗漏的步骤。

7.2 组合与拆分：灵活调度任务流

并非所有任务都适合线性执行。有时一个大任务需要拆分为并行的几部分，有时多个小任务可以合并一起做。Cursor 的 Plan 模式可以帮助制定任务拆解策略：

我需要开发一个”订单导出”功能，支持导出为 Excel 和 PDF。请帮我拆解任务：哪些部分可以并行开发？哪些部分必须按顺序？预计有哪些技术难点？建议的开发顺序是什么？

Cursor 可能会建议：并行部分（Excel 导出实现、PDF 导出实现）；顺序部分（先实现通用的查询逻辑，再实现具体的导出格式，最后做异步导出和进度反馈）；技术难点（大数据量导出需要分页处理，PDF 中文字体需要额外配置）。通过合理的拆解和组合，可以最大程度发挥 AI 的并行处理能力，让复杂任务流转更为顺畅。

7.3 中间产物：在流水线上设置检查点

在工业生产中，质量控制的关键是在流水线上设置检查点——不是等产品完成后才发现问题，而是在每个关键环节都进行检验。与 AI 协作的自动化流程也应如此，在最终代码生成前，要求 AI 产出一些过渡性的结果供审核。

常见的中间产物：

归纳来说，高阶自动化流程并不意味着让 AI 一股脑完成所有事情。真正的效率来自于规划 → 核对 → 执行的循环：以中间产物作为检查点，串联起整个流水线。最终，我们获得的是一个由 AI 辅助运行的开发流程——既有分阶段的清晰产物，又能快速迭代。

结语

1997年，国际象棋世界冠军卡斯帕罗夫输给了 IBM 的深蓝计算机。这场对决之后，卡斯帕罗夫提出了一个新概念：”人机协作棋”——人类棋手与计算机组队，往往能击败单独的人类或单独的计算机。今天，我们与 Cursor 的协作正是这一理念的延续。AI 擅长的是速度、记忆和生成力；人类擅长的是判断、创意和把关。两者结合，能完成任何一方单独无法完成的任务。

本文介绍的技巧可以总结为几个核心原则：思考与执行分离——先在 Plan 模式讨论方案，确认后再用 Agent 执行；多轮迭代优于一步到位——让 AI 逐步推理、逐步改进，而不是一次性给出结果；中间产物即检查点——要求 AI 输出设计文档、伪代码等中间结果供审核；明确边界与约束——通过提示词和 .cursorrules 限定 AI 的行为范围；持久化 AI 的记忆——通过 progress.md 等文件实现上下文传递。

掌握这些技巧，你就能与 Cursor 搭档完成更复杂的开发任务。在实践中不断总结经验、完善提示词模板库，善于利用 Cursor 的新功能拓展能力边界。最终，AI 不是来取代你的，而是来放大你的。愿本手册能帮助你在日常开发中游刃有余，让 Cursor 成为真正的编程拍档，共同创造出更健壮优秀的后端系统。

1

十月份阅读情况不理想。看书231小时，低于原定目标的250小时。不仅没有完成目标，还在持续下降当中。这个趋势不太妙。

冥想符合预期。工作压力让我不得不用冥想来缓解紧张情绪。整个月冥想了38.75小时，跟上个月差不多。

接下来，我想跟大家分享一点我最近学习数学的快乐。

2

我业余时间会给高中生讲讲学习方法。上个月某一个周末，我给一个高三的学生讲如何构建知识体系。其中，就讲到了数学。

我在高中时期的数学成绩一般，最后高考成绩是123分。我在给学生讲的时候，我就发现自己在高中的时候，其实根本就没有学明白，简直就是套公式做题。

这一次重新看高中数学教材，才发现其实教材写得非常好，尤其是知识结构的编排和讲解。

高中数学是从“集合”开始讲起的。先是讲集合的概念和定义，然后讲集合之间的关系，最后讲集合的运算。

高中数学的知识大厦，不仅是以集合为基础，还是以集合的讲解方式往复构建的。

我在给学生讲解的过程中，不会纠结于知识点的细节，而是强调每个知识模块之间的对比和联系。

我发现这样的讲解方式，很适合记忆，或者说根本就不用背。只要你理解了，就能记住。

3

在给学生讲完如何构建知识网络之后，我觉得很兴奋。因为我终于把这一点给弄懂了。于是，我想做一个实验，就是自己从头到尾梳理一遍，或者说构建一遍高中数学的知识网络。

我一边看教材，一边跟AI讨论，很轻松地就构建了一小部分。我发现这个构建过程非常有趣，能让我看到知识之间的关联，甚至是互动关系。一个个知识点就像是在我的脑子里不断地生长出脉络一样，能让我看到不一样的全景图。

当然，我也遇到了困难。我遇到的困难就是急功近利。

我会不自觉地想要加快这个构建的速度，很想快点做完。还有，我会莫名其妙地想要做题，通过做题来证明自己。

你说可笑不可笑？我已经不需要参加考试了。但是当年考试的惯性还是影响着我，甚至试图支配我。

我不断告诉自己，你是在享受学习数学，享受这个学习的过程。你已经不需要参加考试，你已经不需要再向任何人证明自己了。

我现在不会专门抽出时间来做这件事。我就像是在读一套很喜欢的大部头书一样，有空了就读一读，刻意让自己不要着急。

4

在构建完高中数学的知识网络之后，我打算对自己所有看过的书，对自己所有感兴趣的知识，都做一遍这样的事情。

高中数学之后，我打算对高等数学、线性代数这些大学里面的数学学科，做一点延伸。

我的工作是一名程序员，工作上涉及到的知识也是五花八门，刚好做一遍梳理。

历史、心理、经济、金融、物理、化学、生物··· ···这些都可以玩一玩。

凭借我自己的阅读能力和积累，借助AI，这些都挺好玩的。

5

学习很好玩。如果哪一天我觉得学习没有乐趣，那肯定是我在哪里做错了。

截至2025年10月31日，我一共阅读了18675小时。预计会在2026年4月10日，完成第二个10000小时，也就是总共20000小时的阅读目标。

十一月份的阅读目标是460个番茄时间，也就是230个小时。