第二课：因地制宜运用三种模式
我的理解
本课承接三种编程思维的分类，聚焦一个实操难题：在真实项目里如何选择 Comment/Prompt/Objective-Oriented。核心论点是没有一种模式能包打天下，关键在于匹配任务规模与可控性需求——小而高频的改动用注释驱动最顺滑，中等规模的批量修改适合 Prompt 驱动并人工复核，端到端交付且容错空间大的任务才适合全权交给 Objective-Oriented。课程强调要在执行中灵活切换而非”一种模式走天下”，并类比团队协作中分派任务的不同粒度来理解三种模式的”进攻半径”。安全性与权限隔离是全包模式下不可忽视的前提，“分而治之”地把一件大事拆成可控段加全自动段，往往比一味追求全自动更稳妥。
相关链接
- Ch02-L00 引言 — 第二章开篇
- Ch02-L01 三种编程思维 — 三种模式的概念定义
- Ch02-L03 cursorrules原理与自我进化 — 让 AI 在项目内累积经验的机制
- Ch01-L02 Agentic AI的范式转变 — 范式转变的总览
原文
Lesson 9 of 18 第二课：因地制宜运用三种模式【视频 4】 大家好欢迎来到政治给 Show transcript
在上一节，我们谈到三种不同的编程思维，即 Comment-Oriented、Prompt-Oriented 和 Objective-Oriented。它们看上去只是换了输入方法，但实质上却对应了非常不同的工作流：要么把精力放在行内注释，要么在 Chat 窗口里发指令，要么干脆把整个目标丢给 AI 自己去琢磨解决。
很多同学在真实项目里往往会混用这些思路，结果有时效率惊人，有时却一团糟。如何在实际开发或工作场景里，针对性地选择并组合这三种模式，才是我们在这一节真正要探讨的关键。有人说这是一个看似简单却让人抓狂的问题：“到底我该用注释驱动，还是整段 prompt 驱动，还是把活儿全包给 AI 做？”要回答这个问题，我们得先想一想自己的工作流有多大规模、对产出质量的要求多高、能不能承受反复试验，以及是否愿意接受 AI 一次就翻天覆地的改动。
工作流优化思路
许多人在初次接触这三种模式时，会陷入一刀切的偏好。比如有人极度迷恋注释驱动，因为它贴合传统的行内写代码逻辑，用起来也毫不违和。但过一段时间又发现，它适用于小打小闹，却在大规模项目上效率有限。也有人会沉迷在 Chat 窗口里丢上一长串需求，让 AI 一次性改几十个文件，然后一次次 apply 结果，结果当 AI 出点小岔子时，调试和回退都不够顺畅。
还有人对 Objective-Oriented 充满浪漫想象，觉得从此可以“我只要告诉 AI 我要一个网站，它就完美写好一切”，但实际落地后又发现，AI 并非永远能一蹴而就，依然需要我们在中途给予一些指引。其实，这些纠结都表明：没有一种模式能包打天下，更合理的做法是三种思维模式各取所长。
当我们只想在本地做一些小功能或修复，比如给某段函数加注释、重写某行逻辑、或者把一段 Python 代码改成更优雅的写法，这时候使用 Comment-Oriented（也可以叫 Command-Oriented）就特别好。我们在代码行里敲一个小注释，说“这一行想要把字符串列表连接起来，记得要去重”，然后按一下 Tab 或 Command+Enter，AI 会迅速给出补全，很可能一次就搞定。如果不满意，也可以在同一行继续再打几个注释。这个方式的优势在于“高频微调”，就像和好友并肩作战一样，一人一句，思路很连贯。它的劣势也很明显：想大规模更新十几个文件时，你就得一个函数一个函数地写注释，然后去按 Tab，一个一个地检查，每次想跨文件变更都要人工来回切。这种重复在数十个文件上发生时，往往会让人抓狂。因此 Comment-Oriented 很适合解决那些粒度较小、单点但高频的需求，特别是写业务逻辑的过程中要补点代码、顺手插些注释，那就非常顺滑。
Prompt-Oriented 则适合那种需要对项目做较大范围改动，但又保留人类把关的场景。比如说我要把所有函数都加上 docstring，同时要确保 type hints 也跟上，而且还得统一放在函数签名上方，不能写在行尾。我完全可以在 Chat 窗口发一段自然语言需求，让 AI 去分析全部文件，并一次性生成大改动。然后我再来做一次“整体评审”，对有疑问的地方进行二次修改。这个模式能把我的产出/投入比拉得很高，因为我不需要在每一个函数上写注释，再等待自动补全，而是一次性“统筹”这项工作。它就像当了个总监，发了一个大任务给一个团队，然后在每次迭代结束时来评审一下代码。如果出现错误，比如 docstring 风格不统一，或者参数类型写漏了，那么我们只要把错误信息贴回 Chat 窗口，AI 又能再来一波全局修补。它的效率通常相当可观。
但 Prompt-Oriented 也不是万能的，比如要跨多个项目进行联动，或者要执行超出“改代码”范围之外的事情（例如自动安装依赖、对数据库做批量迁移），就会明显受限于“人肉粘合”——因为每个环节都要我手动把错误信息贴给 AI，把 AI 的更新贴回环境，如此往返，容易产生挫败感。所以 Prompt-Oriented 非常适合中等规模、需要一定水平的批量修改，但仍希望人类在中间做关键把控。
而当你面临那种“端到端交付”需求——比方说领导突然要你画一个折线图，把某段时间的营业额、订单数、访问量都汇总到同一个可视化里，还要求在图里标注节假日或促销节点，如果领导很着急，我完全可以把需求直接丢给 AI，说“你给我搞定一个 Python 或者 R 的可视化脚本，你自己下载数据、安装依赖、debug 到最后，产出一个好看的 PNG。别忘了在每个促销节点添加一个注释文本。”这时如果我们依然用 Prompt-Oriented 或 Comment-Oriented，倒也不是不行，但肯定需要反复贴错误信息、告诉它“呀装库装错了”“环境变量没配好”“某某日期格式出错”，来来回回十分耗时。
但如果我们直接用 Objective-Oriented，就是先给 AI 一个大目标，告诉它“结果要是这样，出现错误时你要自己想办法继续试，除非真卡住了再问我。”它就会尽量自己迭代下去，一口气从零跑到成品图表。多了几次“AI 自己动手装依赖并改脚本”的过程后，我们就省下了手工在 Chat 窗口和命令行之间折腾的麻烦。这就是 Objective-Oriented 那种“我问你做”，从头到尾都给 AI 极大自由度的感觉。
不过，这类方法也需要我们在背后有个安全策略和监控机制，比如限制只能改某些文件夹，否则 AI 万一装错东西或删错目录，就可能造成严重后果。我们对这种“全包给 AI”也要有一定心理预期，因为毕竟 AI 可能在某些边缘情况下出现奇怪失误，还需要我们人在关键节点上稍微盯一眼。
说到底，无论是 Comment-Oriented、Prompt-Oriented，还是 Objective-Oriented，本质上就是在产出和投入之间做一个平衡。有时候你想低投入快产出，但对结果要求不算太高，那么就可以交给 Objective-Oriented，让 AI 自己想办法干掉这个需求；如果这个任务是可控范围内的中等难度，就让 Prompt-Oriented 一把子解决，然后人类再做复核；遇到非常细碎、灵活度极高的小改动，反而是最传统的 Comment-Oriented 更高效。
关键问题在于，你需要对这三种模式的适用边界有一个清晰的认知，并且对自己的任务优先级、可承受风险和期望结果有把握。很多同学最初会倾向“啊我就想把所有事情都丢给 AI 最省事”，结果在一些微小的改动上搞得过度复杂，反而浪费了时间。也有的同学在大规模重构项目时，还在用行内注释的方式一点一点推动 AI 补全，这就很不划算。就像工地上有三种挖土机，各有不同大小和功率，如果我们不匹配相应的土方量，就会陷入要么大材小用，要么力不从心的尴尬。
另外一种维度的思考是，人要花多少时间做“检查”和“沟通”？Comment-Oriented 是对话最紧密的，你随时能看到 AI 给你的行内补全，每一行都能即时确认质量。Prompt-Oriented 则是一个中等粒度，你发一次大指令，等它改完之后再看，可能就要改几十处或上百处，只要一次评审就好，但中途如果 AI 出错，你会浪费许多时间回溯。Objective-Oriented 则是最极端，你把最终目标丢给 AI，它可能一次性执行十多个步骤才告诉你“已完成”，那一刻你才知道它做对了没有。如果它搞砸了，你要去找它在第几步出现问题，还需要翻查执行日志。
可以看到，不同模式对“人机协同的频率”设定是不一样的，背后其实是对“可控性”和“效率最大化”的不同权衡。换句话说，并非“AI 越自动越好”，而是要看我们是否能给 AI 提供足够明确且可量化的成功标准，以及是否愿意为容错或补救付出额外成本。如果领导给了你三天时间去写个自动脚本，那你当然可以让 AI 反复试错，每次安装依赖都不干扰你，只要等它成功了再回来。可如果领导等着就要看个阶段性结果，你就得更频繁地插手，把中途产物拿出来看看是不是朝着对的方向走。
同理，在安全性与资源消耗方面，也要根据自身情况来选择三种模式。Comment-Oriented 出问题的风险最小，AI 改坏了某行代码，你马上就能察觉；Prompt-Oriented 需要你在大改动后仔细审查，有时 AI 一次性改动 200 行代码，很可能漏了一个依赖或者变量名，没仔细看就匆忙合并 PR，会留下后患；Objective-Oriented 有时更刺激，AI 在获得执行脚本的权限后可能把环境装乱七八糟，如果你没在一开始就做好权限隔离，后面擦屁股就十分痛苦。
不过这并不意味着 Objective-Oriented 就不可用，关键看我们的“安全沙箱”做得是否到位，或者我们有没有在出发点设下限权。比如可以让 AI 只能改 /tmp 目录，不能碰系统级别文件，这样就算它抽风删库跑路，也只会搞烂它自己的沙盒。
综上所述，想要优化工作流，其实就是在这三种模式之间学会聪明地切换。我们不要把它当成三选一的二元命题，而是先衡量下目标规模和复杂度，再决定采用哪种模式。接着，还可以在执行过程中灵活转化。比如在一开始，你打算用 Objective-Oriented 全包，但中途发现 AI 屡次犯一个小错误，你就可以切回 Prompt-Oriented 的思路，告诉 AI “先别全自动了，把这个错误解决后再继续全自动”；如果最后只剩几行小毛病，就可收回到 Comment-Oriented 的老路子，自己写一句注释让它补完。AI 并不会反对你用何种方式，关键在于你的思维要足够灵活。
有人也许会问：“我做数据分析时，经常就想让 AI 直接把报表做完。这是不是就意味着我应该一上来就用 Objective-Oriented？”如果你的数据分析流程真的涉及到装包、清洗、分组统计、可视化、最后导出 PDF，那没错，Objective-Oriented 可以让 AI 一鼓作气。可如果你的团队有比较严格的审核制度，每一步统计逻辑都要和主管确认，那也许 Prompt-Oriented 更适合，因为在每个阶段输出时你都能人工干预一下，别等最终结果出来才发现用错了列名。再比如某些团队对合规或安全很敏感，不愿让 AI 随便执行脚本，这时就算你喜欢全自动也没戏，最好采取 Prompt-Oriented；或者项目比较微型，最多就三五个脚本文件，也许写注释自动补全就够了。总之，没有放之四海而皆准的策略，只能说你了解这三种模式的“进攻半径”，再找适合自己的切入点。
结合实际案例
为了让我们更直观地理解怎样因地制宜，可以拿一个常见的例子来看看：假设我们要把产品里的一堆 Python 函数添加错误处理机制。有的函数需要在异常发生时返回一个默认值，有的函数需要直接抛出自定义异常，还有的函数需要重试三次后再放弃。我们可以怎么做？
假如你手头有几十个函数，还零零散散地分散在不同的文件里，并且你已经写好了大部分的业务逻辑，只是没来得及加“错误处理”，这种场景下你可能会发现 Comment-Oriented 并不怎么合算，因为你要在几十处地方分别插入注释“当这个地方出现 KeyError，就给它返回一个空字典”，然后一次次等 AI 补全。你可能会补到一半就累了，一旦后面发现“我们其实要再加一个日志记录”，还得继续重新插注释遍历所有函数。如果你有大把时间和耐心，这种做法可以，但明显效率不高。
更聪明的方式，是换到 Prompt-Oriented。你可以先把自己的需求清楚地列出来，比如“遇到 KeyError 就返回空字典，遇到 ConnectionError 重试三次，其他异常则抛 CustomError 并记录日志。”然后在 Cursor Composer 或者类似的 Chat 窗口丢给 AI，一句话说：“请对 src 目录下的所有 Python 函数添加对应的错误处理逻辑，并且把日志记录写到 logging.error，而非 print。”然后加入 Codebase 作为 context，AI 就会读遍所有文件，然后统一加上这些逻辑，改好后给你一个总体 diff。你只需要在最终合并前做一次质量检查，确认它没改错地方或影响原本的调用签名。
如果你的需求突然变更了——比如领导说“别重试三次了，现在改成只重试一次”，你还能再次在 Chat 窗口改指令，让 AI 再来一波批量修改。相比于一行行写注释，这样更像在发号施令，然后在交付产物时把关。可见在“中等规模的统一修改”这种场景下，Prompt-Oriented 是非常合适的。
但如果你的需求又升级了，不止是加错误处理，还要安装一个第三方包来对错误进行可视化统计，同时要自动生成一张报表，把哪些函数最常出现错误、错误率多高、日志里出现什么关键字都汇总出来。那就不仅仅是改代码，还需要自动装一个依赖，还要写可视化脚本、运行这个脚本产出一份图表。
如果你自己来回折腾，就得先 pip install，接着写脚本，再去命令行跑一下，看报表效果如何。这个环节假如全交给 AI，用 Prompt-Oriented 依然能够做，但你大概要在每一步都把安装错误的信息贴过去，让它告诉你下一步怎么改，每完成一段再贴给它。它当然可以应付，但非常地繁琐。
这时若你选择 Objective-Oriented，就能让 AI 自己在每次失败后自动调整，直到最后它拿出那份图表结果。假设它中途碰到了“无法安装 XXX 包”这样的错误，也能自己重试或者换镜像地址。你作为人类观察者，这时几乎处于“看戏”状态，只要最终图表 OK 就直接接收；如果中途它确实卡死，你再出现即可。这就是 Objective-Oriented 的魅力：当任务是一个典型的“端到端交付”，且你事先定义了“图表中要展示哪些信息”“输出格式是什么”等足够明确的目标，AI 完全可以自行补全中间所有步骤，让你省了大量来回拷贝粘贴的过程。自然，这里也要保证 AI 的权限受到某些限制，万一它安装错包或者乱删文件，也别造成太大损失。这个场景就再次印证了我们那句老话：越大的需求越适合“目标导向”，而越小的需求越适合“注释驱动”或“单次 Prompt”。
可能有人会说：“那我能不能把加错误处理和生成报表都用 Objective-Oriented 一口气搞定？”当然行，但要注意如果你对错误处理这块的修改有特别严格的 code review 要求，那么让 AI 全程自己包办，没准它改完以后你要费更多力气从头检查每个函数，可能不如先做一个 Prompt-Oriented 的半自动改动，再把后续自动化报表的脚本交给 AI 用 Objective-Oriented 的方式完成。很多时候我们提倡“分而治之”，可以把一件大事拆成两段流程，先在相对可控的范围内用 Prompt-Oriented 得到干净的代码变更，再让 AI 全自动去搞定剩下的可视化或部署脚本。这种拆分能减少全自动带来的不确定性，让我们的小步迭代更有底气。
再举一个更简短的例子：如果你只是在一个文件里想改几处变量名，或者加个小判定，那就不要舍近求远去写个超大的 prompt。把光标对准那几行，简单写个注释或者小命令，用 Comment-Oriented 即可，一步到位反而最省时间。有些人觉得自己掌握了大招，就要处处放大招，结果往往事倍功半。就像我听过一些朋友在用 AI 写一小段脚本时，居然跑到 Chat 窗口打了七八行 prompt，描述得无比详细，AI 的输出当然也没问题，但中途一旦报错，他们还要来回贴信息，再跟 AI 争论半天如何改；其实行内注释让 AI 补全就能轻松解决，还更直观。由此可见，在需要处理的改动特别小且比较单纯的情况下，Comment-Oriented 依然是最灵巧的方式。
通过这几个实际案例，我们大致能看到这三种模式在复杂度和协作颗粒度之间的差异：
Comment-Oriented 重视行内合作，小而精；Prompt-Oriented 面向一个中等规模的改动，着重在一次性大范围修改；Objective-Oriented 针对端到端交付，把整个流程的所有琐碎环节都抛给 AI 处理。如果我们能根据任务的类型、规模、对容错和权限控制的要求灵活运用三种模式，就会发现自己和 AI 的协同变得更加顺畅，甚至能体会到“AI 就像我的小团队成员”那种默契感。关键是要改变“一种模式走天下”的惯性思维，避免把 AI 想成单一渠道，明明只有一把锤子，却把所有问题都当成钉子看待。
有人可能还会问：“我平时的工作就跟 AI 没啥关系，我只是在一些简单的前端代码里用 AI 补补颜色。看完这些是不是觉得自己用不上？或者是不是我也该马上切换到 Objective-Oriented？”其实大可不必。你大可以在日常里老老实实用 Comment-Oriented，因为它最贴近我们传统开发的习惯，也不需要对项目做太多改造。等哪天领导想让你对前端样式做大范围的规范化，或者批量统一组件样式，就可以尝试 Prompt-Oriented；再当领导要求你写个脚本把这些前端资源打包到 CDN，还要自动检测可访问性，你就可以尝试把全部需求一次性丢给 AI 走 Objective-Oriented，从最初的 npm install 到最后产出一份可访问性报告都交给 AI 自主完成。这样一点点扩张自己的工作流范围，不仅能学得轻松，也能真正享受到三种模式带来的灵活与力量。
说到底，“选择合适的模式”是一种很人性化的技巧。它和我们平常在团队协作中分派任务颇有相似之处：当你交给同事一个简单任务，你可能就会很微观地指导他，每一步都要怎么做，这就相当于 Comment-Oriented；当你觉得同事能力不错，可以一次性完成一组相关改动，你就会发一个统一的需求让他去干，这很像 Prompt-Oriented；当你信任这个同事能独立承担大项目，你就把终极目标告诉他，让他全程安排，这就是 Objective-Oriented 的思路。跟 AI 的交互其实也是这样，只不过 AI 并不是一个真正的人，所以我们要用 prompt 来塑造它的能力边界，并且在适当的时候手动介入。这种“工作流优化思路”并不是某个操作小贴士就能概括，而是需要我们真正认识到三种模式背后的不同思路与用途，然后对症下药。
如果能把这三个模式像乐高块一样灵活组合，并且融入日常工作流里，你就会发现自己和 AI 的配合度不再是零碎而混乱的，而是一种非常顺滑又带有策略性的协作。无论是改动少量代码，还是对十几个文件做大范围重构，还是干脆让 AI 全程安装环境 + 跑脚本 + 产出可交付物，都可以各施其职。慢慢你就会感觉到，AI 真的不仅仅是一个“自动补全”工具，更像是一个强力外脑或执行引擎，你唯一需要思考的是“该让它用什么方式介入”。这样的工作流，才是我们一直以来在教学和实践中拼命想让更多人体验到的。