第一课：三种编程思维：Command / Prompt / Objective Oriented Programming
我的理解
本课的核心贡献是把人与 AI 的协作关系抽象为三种递进的心智模式：Command-Oriented（注释驱动，逐行补全）、Prompt-Oriented（Chat 窗口下达整块指令，AI 批量改动）、Objective-Oriented（只给最终目标，AI 自主分解、执行、调试直到交付）。三者的本质区别在于抽象层级与自主性：前者像”码农助手”，中者像”听令小帮手”，后者像”独立执行者”。关键洞见是这三种模式没有绝对高下之分，而是对应不同粒度的任务，真正的效率来自于因地制宜地切换。理解这套分类框架后，就能解释为什么有人用 AI 数月仍停留在”高级补全”，而有人几天就把一半工作甩给 Agentic AI。
相关链接
原文
Lesson 8 of 18 第一课：三种编程思维：Command / Prompt / Objective Oriented Programming
在我们和 Cursor 这样的 AI 编程工具打交道时，往往会感受到三种截然不同的“心智模式”。它们分别可以称为命令式（我更喜欢叫它“注释驱动”）、提示式，以及目标式的编程思维。很多时候，我们自己也会在这三种模式之间来回切换，却不一定意识到背后逻辑有多不同。要是能先把这三种模式辨识清楚，就会发现：根据场景不同，选用合适的模式往往能省下很多力气，做出更漂亮的结果。下面我们就从三个角度展开，力求让你感受到它们各自的魅力和局限。
Command-Oriented (Comment-Oriented) Programming
有时候也有人把这种方式叫做“注释驱动编程”，其实并不算严格的行业术语，但能贴切地描述它的本质：一切都围绕在行内注释或极短的命令行周边展开。最经典的例子，就是你在代码编辑器里写上一句诸如“# Return a string describing the downloaded data”，Cursor 或者 Copilot 立刻“脑补”出对应的函数实现，然后自动补全进来，仿佛它真的读懂了这句注释的意图。对很多初次尝试 AI 辅助编程的人来说，这种模式带来的惊喜感是最大的。好像从此以后，我们不用老老实实写循环、处理边界状况，只要下个简短注释就能得到完整函数。这对那些本身就很熟悉语言语法、只是不想写繁琐模板或样板代码的开发者来说，无疑是个极大的效率解放。
而且不光是补全函数体，一些更细节的用法也很受欢迎，比如我们在写类时，有意留一句注释“# generate all setters/getters”，Cursor 就知道自动补齐好一大堆 Java 风格的 setter、getter 方法，或是一次性为 Python 数据类写出 pydantic 校验逻辑。这些过去要么需要手工敲好多行，要么需要在 IDE 里写模板或记快捷键，现在通通只要打上两三行注释就够。更妙的是，这些注释有时还能起到解释用途、记录设计思路的效果，让后人（包括未来再看的自己）更容易明白代码背后的动机。
不过，用注释驱动编程就跟请了个尽职尽责又非常直接的“码农助手”似的：它可以帮你完成不少代码写作，但依旧只是一行一行地听命于你。每次它写完后，你或许还是要在思维层面确认“这一行是不是对的”“是不是能跟已有的函数对接好”。要跨多个文件去做批量性的修改，或者想重构一个功能比较复杂的模块，往往就不太好使了。因为注释只能作用于当前这片区域，它没有办法一次性知道你在别的文件中写了什么样的逻辑，除非你再手工贴给它看。结果就是，它能把某一段写得很漂亮，但难免需要人工做更多衔接和检查工作，所以它更适合那些“函数级别的”或者“相对粒度小一些的”需求。
很多人会问：这不就是 Copilot 或者原版 Cursor 的自动补全功能吗？区别又在哪里？确实，从表现形式来说，注释驱动编程就是走“行内补全”那条最直接的路。不过现如今一些 AI 编辑器做得更加灵活，比如你在 Cursor 里可以写下“# optimize this function for concurrency”，它就会展开优化思路——也许加了 asyncio，或者把同步逻辑改成异步，甚至可能多做一步测试。这在传统的自动补全里绝对见不到。
可即便如此，这个方法还是局限在“你写一个简要注释——我给你补全代码”的范畴里，无法一次性触及到更高层的任务目标。所以从某种程度上说，这种思路虽然简单却非常高效。只要我们能接受这种“逐行写注释、逐行自动补全”的工作流，就能让许多繁琐的小任务变得轻松，算是 AI 编程里最“就地取材”的方式。
最后需要提一下，它在很多时候也不见得就比后面介绍的更复杂的功能更弱。有时候我们只想做一个很快的小功能，比如写个小脚本去读取某个文件里的前几十行数据，然后把它们格式化，这种场景就非常适合注释驱动。我们不需要写一堆提示词反复交流，不需要让 AI 去做什么深度规划，而是以“我写到哪里，就让你补到哪里”的节奏快速完成任务。这样既能保持我们的思维专注在小目标上，又不会让 AI 的答复显得啰嗦或大而全。说得再直白点，对一个一天到晚都在写代码的开发者来说，这种“Command-Oriented Programming”足以让人和 AI 的协作顺滑起来，在小而散的日常工作中改善生产力。
Prompt-Oriented Programming
如果说注释驱动编程像是给你配了一个行内的“辅助写手”，那么提示式编程就是另一个层级的 AI 合作方式。此时，我们不再局限于“在代码里写一句注释”，而是把注意力放到了编辑器或 IDE 内的 Chat 窗口：那地方往往能接受更详细、更高层次的指令，于是就诞生了“我问你写”的用法。
在这一模式下，你会把想做的事整体性地告诉 AI，比如“现在我有 10 个文件全都需要加上 docstring，而且 docstring 里要有输入输出的类型标注。记得用 Google 风格写法。”如果是纯注释驱动的话，这样的需求可能要分好几次写注释、反复切到各个文件里让它补全。但在 Prompt-Oriented 的模式下，就能干脆在 Chat 窗口一次性对 AI 下达命令，然后看着它一口气把十个文件都改完。
这种场景下你会明显感觉到，“产出/投入比”有时候陡然提升很多。过去要自己一个文件一个文件地改，或者一个函数一个函数地插入注释，现在几句话就搞定了。但从另一面看，你多少还得有点“运气”成分或者说对 AI 的熟悉度，才能让它一次性改好所有文件。因为它提交改动以后，稍微出点差错，比如 docstring 某个函数的参数类型没写对，你还得把报错信息或者你的纠正意见贴回 Chat 窗口，让它再修改一遍。于是这个“我问你写”的对话就成了新一轮的拉锯，直到 AI 把问题修复完。
这一点常常让人感到又爱又恨：爱的是它似乎更“懂全局”，恨的是它有时也会给出一些意想不到的错误，需要我们把控制台错误信息又贴回给它，让它来分析。在许多真实情况下，如果任务非常明确，而且你可以快速检查结果，那么 Prompt-Oriented Programming 依旧能大幅度节省时间。你甚至可以更灵活地进行一次性的大改动，像“帮我把所有函数都改成异步，而且在原来的位置尽量少动其他逻辑”之类的需求。
讲到这里，你也许会想到另一个明显缺陷：在这类“我问你写”的对话里，AI 虽然已经比较智能，但总体上仍然需要你手动去发起每一轮交流、查看结果、确认最终是否正确。它基本不会“自己想要去做”什么，还是等着你来踢一脚动一下。如果工程量比较大、中间可能会遇到依赖没装好、某些文件冲突等等，你还是要把这些信息收集整理，再次告诉 AI，然后看它下一步的反应。也就是说，我们虽然不用在小的编程细节上太费劲，但依旧得替 AI 做中间的拆分和协调，这在工程越复杂时就越累。
不过，从需求端和思维方式上看，Prompt-Oriented Programming 的出现的确已经把我们从“一行行写注释”带到了“提整体要求、让 AI 大范围改动”的新阶段。这个阶段可称为“中观层面”的协作，你不用关心每个小细节，你只要在 Chat 窗口开口，说“把这个脚本的输出改成 CSV 存储吧”，它就会生成一长串改动，然后你点一下 Apply 就行。它真的可以让我们省下很多重复性的改代码时间，尤其当你要做一些很机械的大规模替换、添加或者类似“把这个 Flask 项目迁移到 FastAPI”这种通用化动作时，你会觉得它仿佛一下子顶了好几个苦力。
要提醒的是，这种模式也挺容易掉进“高期望陷阱”——我们觉得它既然能改一堆文件，为啥不能全自动 debug 全部细节？为啥出了错还要我告诉它具体哪里不对？但事实就是：这个阶段的 AI 还只是一个“听令行事”的小帮手，它还无法对自己的行为进行完整的自我检查，更谈不上自动跑测试、安装依赖、抓取更多信息来修补。它只是能在我们给出的 Prompt 范围里做事，并不具备完全的自主性。想要让它再往前迈一步，就会来到下一节要说的那种“目标式编程”模式了。
Objective-Oriented Programming
当我们说起“我想要一个可以自动绘制股票走势图的脚本，而且要比较过去五年的谷歌和亚马逊股价”，在传统的自动补全或者提示式编程里，你可能会对它说：“帮我写下载股价的 Python 代码”“帮我写个 Matplotlib 画图函数”“对齐时间轴”……每一步都得你来发指令。而在 Objective-Oriented Programming（有时也叫 Agent 模式）里，你只要丢出一句“给我一张谷歌和亚马逊过去五年的对比图，起点对齐”，AI 本身会像接到一个“总目标”的开发者那样，从零开始自己写代码、装依赖、处理各种错误，最后直到把图画好为止——有些人喜欢叫这过程“一站式端到端”。
这在具体操作里，往往依赖于 AI 编辑器或者平台具备多步决策和工具调用的能力。为什么要强调这两点？因为在简单的 Prompt-Oriented Programming 里，你告诉它需要画图，它会写出一段脚本交给你；要是脚本报了错，你仍然需要手动把报错信息复制回来，然后发给 AI。可是在一些 Agentic 的实现里，比如 Cursor 里切到 Agent 模式，或者类似 Devin 的平台，它会自己执行这段代码，然后收集报错信息，再重新改动脚本，继续执行，直到没有报错、顺利生成图表。也就是说，它自己就能完成那种“多轮调试”的工作流。
听上去是不是一下子爽多了？感觉你只要一句话——“请给我一个可执行程序，统计一下上周到本周每一天的销量对比，然后输出到一张图”——AI 就自顾自地去调命令、装依赖、查文件结构，直到把图放到你面前。这就是“目标式编程”的核心：你直接告诉它你要的结果是什么，AI 会尝试自己把这条链路走通。
当然，这依旧还不是科幻电影里的超级强 AI。在实现层面，这需要我们“后台”帮它做好各种约束和辅助，包括让它知道怎样执行命令、读写文件，甚至如何判断算完成。你可能会在 .cursorrules 里告诉它：“如果你想要画图，就调用某个 Python 工具；如果没有安装包，请先 pip install；如果报错就根据报错信息进行修正。”说白了，这还是基于一个剧本式的“AI+工具”组合。但是对于使用者来说，体验却是巨大飞跃，从“我问你写代码，我再去执行”变成了“我问你把这个任务做完。”
虽然如此，Objective-Oriented Programming 也并非完全没有局限。首先，你得花心思把目标描述得足够明确。有的人喜欢把各种业务逻辑、成功标准全部打包给 AI，让它自己来想。这看似可以更大程度发挥它的自动化能力，但要是你本身不知道你要什么，或者对问题本身理解不清，就很可能出现“AI 穷折腾了半天，交付出来的结果却牛头不对马嘴”。其次，安全和可控性也更敏感。AI 在多步决策里执行命令行、装依赖、读写文件，万一它把系统里别的文件删掉了或者引发安全风险？因此实际在某些平台上，每次 AI 要执行命令时，都需要我们人工点一下“确认”，起到守门员的作用，避免 AI 在不恰当的场景里做出不受控的操作。
总的来说，这种“Objective-Oriented”或“Agentic”编程思维，会让我们在不少场合感叹：AI 真是在帮我做整个事情，而不只是回答问题或写小片段。它代表了现阶段 AI 辅助编程的巅峰形态，让我们可以像老板一样把“最后成品”交办给 AI，再由 AI 自己分解任务、动手实现、发现错误并纠正，直到拿到可用结果。而我们再一次回头去看“命令式”“提示式”那两类模式，也就会更加体会到它们各自适合的场景：命令式/注释驱动适合小而快、可控的功能；提示式适合批量改动、需要对话的那种中型整活；而目标式就能把你从底层编程工作中完全解放出来，让 AI 成为一个“独立执行者”。
以上这三种思维模式并没有谁绝对更高明，只是抽象层次与应用场景不同。有时我们写一个非常小的脚本，完全用命令式就够了；有时需要大规模重构或者改进十几个文件，提示式就更方便；若想一口气完成一个多阶段任务，才会出动目标式 Agent。也就是说，你可以把它们视为三把钥匙，分别能打开不同性质的锁：在当前 AI 编程的各种场景下，我们越熟悉这三把钥匙，就能越灵活地选择合适的解法，从而提升工作效率和质量。