1. 为什么“记操作”这条路从一开始就走不通我见过太多人学 AI 编程的方式，是打开一个收藏夹，里面躺着几十个“XX 工具从入门到精通”的教程，然后一条条照着敲。提示词模板存了一整个备忘录，快捷键背得比自己的手机号还熟。结果呢？工具一更新，界面一改，模型一换，之前背的东西全部作废，人直接懵在原地。这不是学习能力的问题，是方向的问题。AI 编程真正拼的从来不是操作熟练度，而是底层范式。操作是表层，范式是骨架。表层的东西三个月换一轮，骨架的东西三五年都稳。你花大量时间去记“点哪个按钮”“写哪句咒语”，本质上是在给一个随时会变的接口做缓存，缓存失效的那一刻，你的积累就归零了。那什么叫底层范式？说白了就是：你如何把一个问题拆给 AI、如何组织上下文、如何验证它的输出、如何在它出错时把它拉回来。这套东西跟具体用哪个工具没关系，跟模型是哪个版本也没关系。它更像是一种思维方式，一种你和机器协作的“工作流骨架”。你把这个骨架搭稳了，换任何工具都是往上挂插件；骨架没搭起来，换再多工具也只是在沙滩上盖楼。这篇文章我想聊的就是这个。适合谁看？适合那些已经用过几个 AI 编程工具、但总觉得“用得不顺手”“换个工具就废”“产出不稳定”的人。也适合刚入门、还没被操作教程带偏、想一开始就走对路的人。我会把范式拆成几个能落地的部分：任务怎么拆、上下文怎么给、结果怎么验、错误怎么修，每一块都配上我实际踩过的坑和能直接抄的做法。不聊虚的，只聊能用的。2. 范式一：把“提问”换成“任务分解”2.1 为什么单次提问的天花板很低大部分人用 AI 编程的第一个动作，是打开对话框，敲一句“帮我写一个 XXX 功能”。这句话看起来没问题，但它隐含了一个假设：AI 能一次性理解你脑子里那个完整的、模糊的需求，并直接给出可用的结果。这个假设在简单场景下偶尔成立，稍微复杂一点就崩。我举个真实的例子。之前我要做一个“读取本地表格、按某列分组、算每组均值、输出成新表格”的小脚本。第一次我直接说“帮我写个脚本处理表格分组求均值”，AI 给了一版，跑起来报错，因为列名对不上。我改了一句提示词，它又给一版，这次列名对了，但分组逻辑理解错了。来回五六轮，每一轮我都在补一个它没猜到的细节。这就是单次提问的典型困境：你在用对话的方式，做本该用分解的方式做的事。单次提问的天花板在于，它把“需求澄清”和“代码生成”压成了一步。而这两件事的难度完全不同。澄清需求需要的是结构化思考，生成代码需要的是模式匹配。你把它们混在一起丢给 AI，它只能靠猜，猜错了你就得重来。2.2 任务分解的实操框架我后来固定用一套分解框架，简单说就是把一个大任务切成“输入—处理—输出”三段，每段再问自己三个问题。这套框架不依赖任何工具，你在纸上都能画。第一段是输入。问自己：数据从哪来？格式是什么？有没有缺失或异常？比如上面那个表格任务，输入就是“一个 CSV 文件，第一行是表头，某列是分组依据，某列是数值”。第二段是处理。问自己：核心逻辑是什么？边界情况有哪些？比如“按分组列聚合，对数值列求均值，忽略空值，如果某组全是空值就输出 0”。第三段是输出。问自己：结果长什么样？写到哪？格式要求是什么？比如“输出一个新的 CSV，两列，一列是组名，一列是均值，保留两位小数”。你把这三段写清楚，再丢给 AI，效果完全不一样。因为它不再需要猜，它只需要执行。我实测下来，同样一个任务，用分解框架写出来的提示词，一次通过率能从三成提到七成以上。剩下的三成也不是逻辑错，多半是环境或依赖的小问题，改起来很快。提示：分解的时候不要怕写得啰嗦。你写给 AI 的每一句澄清，都是在替它省一次猜测，也是在替你自己省一轮返工。2.3 分解粒度怎么把握有人会问，那我要分解到多细？是不是每一行代码都要我说清楚？不是。分解的粒度标准是：每一个子任务，都应该能用一句话描述清楚它的输入和输出。如果一句话说不清，说明还没拆到位；如果一句话说完了但你觉得“这不明摆着吗”，说明拆过头了。举个例子。“读取 CSV”这个子任务，输入是文件路径，输出是一个表格对象，一句话说得清，粒度刚好。但如果你拆成“打开文件”“读取第一行”“按逗号切分”“存进列表”，这就过头了，这些是 AI 本来就该处理的实现细节，你管太细反而限制它。我自己的经验是，一个中等复杂度的任务，拆成三到七个子任务比较合适。少于三个，说明你还没想清楚；多于七个，说明你可能把实现细节也当成任务了。这个数字不是死的，但可以当个参考。3. 范式二：上下文不是越多越好，而是越准越好3.1 上下文过载的典型症状很多人有个误区，觉得给 AI 的上下文越多越好，于是把整个项目文件、所有相关文档、一堆历史对话全塞进去。结果 AI 反而变笨了，回答开始跑偏，甚至把不相关的信息混进来。这不是模型的问题，是上下文过载。上下文过载的典型症状有三个。第一，AI 开始“幻觉”，编造一些你没提过的函数或变量。第二，它抓不住重点，你问 A 它答 B。第三，响应变慢，因为它在处理大量无关信息。我踩过最狠的一次，是把一个几千行的配置文件整个贴进去，问一个很小的配置项怎么改，结果 AI 给我绕了一大圈，最后改错了地方。3.2 精准上下文的三个筛选原则我后来总结出三个筛选原则，用下来很稳。原则一：只给和当前子任务直接相关的代码。你正在改哪个函数，就给哪个函数，最多带上它调用的那一两个辅助函数。不要给整个文件，更不要给整个项目。原则二：给“接口”而不是“实现”。如果当前任务依赖另一个模块，你只需要告诉 AI 那个模块的输入输出是什么，不需要把它的内部实现贴出来。比如“有一个函数叫 parseDate，输入字符串返回日期对象”，这一句就够了，不用把 parseDate 的源码贴上去。原则三：用注释标注关键约束。有些约束是代码本身看不出来的，比如“这个字段可能为空”“这个接口有频率限制”“这个变量单位是毫秒不是秒”。这些要用注释或自然语言明确告诉 AI，否则它一定会按默认假设来，然后出错。3.3 一个上下文组织的实例我拿一个实际场景来说。假设我要给一个已有的数据处理流程加一个“去重”步骤。这个流程里已经有一个读取函数、一个清洗函数、一个输出函数。我要加的去重，是在清洗之后、输出之前。这时候我给 AI 的上下文应该是这样的：先说明“我有一个数据处理流程，顺序是读取、清洗、输出，现在要在清洗和输出之间插入去重”。然后给出清洗函数的输出格式（比如“一个列表，每个元素是字典，字典有 id 和 value 两个键”），再给出输出函数期望的输入格式。最后说明去重规则（比如“按 id 去重，保留第一次出现的”）。你看，我没有贴任何函数的实现代码，只给了接口和约束。AI 拿到这些信息，完全能写出正确的去重逻辑。而且因为上下文干净，它不会跑偏。这个做法我用了很久，稳定性比堆上下文高得多。注意：上下文里如果有任何“可能”“大概”“应该是”这种模糊词，AI 就会按最宽松的假设来。所以能确定的就写确定，不能确定的就明确说“这里不确定，按最保守的方式处理”。4. 范式三：验证不是最后一步，而是每一步4.1 为什么“跑通了”不等于“对了”新手最容易犯的错，是看到代码跑通没报错，就认为任务完成了。但“跑通”和“对了”是两回事。代码可能跑通但逻辑错了，可能跑通但边界没处理，可能跑通但性能很差。AI 生成的代码尤其容易这样，因为它擅长的是“看起来对”，而不是“真的对”。我举个例子。之前让 AI 写一个“判断字符串是否是回文”的函数，它给了一版，跑几个测试都过了。但我后来发现，它没有处理大小写和空格，输入“A man a plan”这种就判错了。如果我只测了“abcba”这种简单例子，就会以为它对了。这就是“跑通”和“对了”的差距。4.2 分层验证的具体做法我的做法是把验证分成三层，每层用不同的方式。第一层是单元验证。针对每个子任务，单独测它的输入输出。比如去重函数，我就单独喂几组数据进去，看输出对不对。这一层用最简单的断言就行，不需要复杂框架。第二层是集成验证。把子任务串起来，测整个流程。这时候重点看的是子任务之间的衔接，比如数据格式对不对得上、顺序对不对。很多 bug 都出在衔接处，而不是单个子任务内部。第三层是边界验证。专门测极端情况：空输入、超大输入、格式异常的输入、重复的输入。这一层最容易发现问题，也最容易被忽略。我现在的习惯是，每写完一个功能，先想三个边界情况，测完再交付。4.3 让 AI 自己参与验证有个技巧很好用：让 AI 自己写测试用例。你写完功能后，跟它说“请为这个函数写五个测试用例，覆盖正常情况和边界情况”。它写出来的测试，往往能覆盖到你自己没想到的点。然后你跑这些测试，如果有失败的，再让它修。这个做法有个额外好处：AI 写测试的时候，会重新审视一遍自己的实现，有时候它自己就发现问题了。我遇到过好几次，它写完测试说“这个用例可能过不了，因为我的实现没处理空值”，然后主动改了实现。这比你自己去挑错效率高。提示：验证的时候不要只测“应该成功”的情况，一定要测“应该失败”的情况。比如输入非法时，函数是报错还是返回默认值？这个行为必须明确，否则上线后就是隐患。5. 范式四：错误处理是范式的试金石5.1 AI 出错时的三种典型反应AI 出错的时候，人的反应基本分三种。第一种是直接放弃，觉得“AI 不行”，回去手写。第二种是反复重试同一句提示词，指望它某次蒙对。第三种是分析错误、调整输入、引导它修正。前两种都是操作层面的反应，只有第三种是范式层面的。我早期也是第二种，一句话反复问，问五六次不行就烦了。后来我发现，AI 出错基本就三类原因：信息不足、约束冲突、理解偏差。你针对原因去调，比盲目重试有效得多。5.2 按错误类型对症下药信息不足，就是你没告诉它某个关键前提。比如它用了一个你没提过的库，或者假设了一个不存在的字段。这时候你要补信息，而不是说“你错了重来”。约束冲突，就是你给的要求互相矛盾。比如你既要“高性能”又要“代码极简”，这两个在某些场景下是冲突的。AI 会随便选一个满足，另一个就崩了。这时候你要重新排优先级，告诉它哪个更重要。理解偏差，就是它把你的意思理解歪了。这时候不要重复原话，要换一种说法，或者举个例子。比如它把“去重”理解成“删除所有重复项”，而你要的是“保留一个”，你就得明确说“保留第一次出现的，删除后续重复的”。5.3 一个错误排查的实例我拿一个实际调试过程来说。之前让 AI 写一个“按时间范围过滤日志”的函数，它写完后跑出来结果不对，少了很多本该保留的记录。我先没急着改代码，而是问自己：这是哪类错误？看了一遍它的实现，发现它用的是“大于起始时间且小于结束时间”。但我的需求是“包含起始和结束当天”。这就是理解偏差，它把“范围”理解成了开区间，我要的是闭区间。于是我改了一句提示词：“时间范围是闭区间，起始和结束当天都要包含”。它改完就对了。整个过程没重试，没反复问，就是定位错误类型然后精准调整。这个思路你一旦养成，调试效率会高很多。6. 范式五：把经验沉淀成可复用的“套路”6.1 为什么每次都要从零开始很多人用 AI 编程，每次都是全新的对话，全新的提示词，全新的试错。这次踩过的坑，下次换个任务又踩一遍。这不是工具的问题，是没有沉淀。范式的最高一层，是把你验证过的做法沉淀成可复用的模板。这个模板不是提示词模板那种死东西，而是“遇到这类任务，我按这个流程走”的套路。比如“凡是涉及数据转换的任务，我先定义输入输出格式，再写转换逻辑，最后测边界”。这个套路一旦形成，你下次遇到类似任务，直接套就行，不用重新想。6.2 沉淀什么、怎么沉淀我沉淀的东西分三类。第一类是任务分解模板，针对常见任务类型（数据处理、接口调用、文件操作等），我有一套固定的分解问法。第二类是上下文组织模板，针对不同场景（改现有代码、写新功能、调 bug），我有不同的上下文给法。第三类是验证清单，针对不同任务类型，我有不同的必测项。沉淀的方式很简单，就是用一个文档记下来。每次做完一个任务，花两分钟想想：这次哪个做法好用？哪个坑下次要避开？记下来。积累多了，你就有了自己的范式库。这个库比任何教程都值钱，因为它是你亲手验证过的。6.3 套路不是死板，是起点有人可能担心，沉淀成套路会不会变得死板，失去灵活性？我的经验是，套路是起点不是终点。你按套路走，走到某一步发现这个任务有特殊性，那就偏离套路，处理完特殊性再回到套路。套路保证你不漏掉关键步骤，灵活性保证你应对特殊情况。两者不矛盾。我现在的状态是，拿到一个新任务，先判断它属于哪类，套对应的套路。大部分任务套完就解决了，少部分需要调整。这个效率比我早期每次从零开始高太多了。7. 常见问题与排查技巧实录7.1 常见问题速查表问题现象可能原因排查方向解决思路AI 反复给错方向上下文过载或信息不足检查是否给了无关内容，是否漏了关键约束精简上下文，补关键约束代码跑通但结果不对边界未处理或理解偏差测边界情况，对照需求逐条核对明确边界行为，换说法重述需求换个工具就废依赖操作而非范式回顾自己是否在记操作而非拆任务用分解框架重新组织任务产出不稳定验证环节缺失检查是否有分层验证补单元、集成、边界三层验证调试效率低盲目重试判断错误类型按信息不足、约束冲突、理解偏差分类处理7.2 几个我踩过的坑第一个坑是过度依赖单一工具。我早期把某个工具用得很熟，所有任务都在上面做。后来那个工具改版，我直接不会干活了。从那以后我刻意在不同工具间切换，逼自己关注范式而不是操作。第二个坑是忽略验证。有次赶进度，AI 写完代码我扫了一眼觉得没问题就交了，结果上线后发现一个边界没处理，返工花了两倍时间。从那以后我再赶也留时间做边界验证。第三个坑是提示词越写越长。我以为写得越详细越好，结果 AI 被一堆细节淹没，反而抓不住重点。后来我学会分层：先给任务框架，再给关键约束，细节让 AI 自己补。7.3 一个反直觉的经验有个经验可能反直觉：有时候少给一点信息，AI 反而做得更好。比如你让它写一个通用函数，如果你把太多具体场景的细节塞进去，它会写出一个很臃肿、耦合很重的实现。但如果你只给核心需求，它会写出更干净、更通用的代码。这个度怎么把握？我的判断标准是：给“必须满足的约束”，不给“可能用到的细节”。必须满足的约束是硬性的，不给就错；可能用到的细节是软性的，给了反而限制它。这个判断需要练，但练几次就有感觉了。8. 从操作到范式，我的转变过程我最早也是从记操作开始的。收藏夹里几十个教程，提示词模板存了一堆，快捷键背得滚瓜烂熟。那时候我觉得自己挺厉害，直到有一次工具大改版，我发现自己除了操作什么都不会。那种感觉很难受，就像练了很久的武功，突然发现招式全废了，内功一点没有。转变是从一次失败的项目开始的。那个项目任务比较复杂，我用老办法反复试，怎么都不顺。后来我停下来，不再想“该用哪个工具”“该写哪句提示词”，而是拿张纸把任务拆了一遍，把输入输出写清楚，把边界列出来。然后按这个分解去跟 AI 协作，一次就顺了。那次之后我才意识到，之前卡住不是因为工具不好，是因为我没把任务想清楚。从那以后我开始刻意练范式。每做一个任务，先不碰工具，先在纸上拆。拆完再动手。刚开始很慢，因为不习惯。但做了十几个任务之后，速度就上来了，而且稳定性完全不一样。以前是碰运气，现在是可预期。现在我看别人用 AI 编程，基本一眼能看出他是在操作层还是范式层。操作层的人，话题围绕“哪个工具好”“哪句提示词灵”；范式层的人，话题围绕“怎么拆任务”“怎么组织上下文”“怎么验证”。前者换工具就慌，后者换工具只是换个壳。如果你现在还在操作层，我的建议是：下一个任务，先别打开工具，拿张纸拆一遍。拆完再动手。就试这一次，你会感觉到差别。这个习惯养成了，你就从操作层进到范式层了。工具会一直变，范式不会。你押注在范式上，才是押注在不变的东西上。这个内容后续还可以这样扩展：针对不同类型的任务（数据处理、接口开发、自动化脚本等），分别整理一套分解模板和验证清单，形成自己的范式手册。手册越厚，你换工具时的底气越足。
1. 为什么“记操作”这条路从一开始就走不通我见过太多人学 AI 编程的方式，是打开一个收藏夹，里面躺着几十个“XX 工具从入门到精通”的教程，然后一条条照着敲。提示词模板存了一整个备忘录，快捷键背得比自己的手机号还熟。结果呢？工具一更新，界面一改，模型一换，之前背的东西全部作废，人直接懵在原地。这不是学习能力的问题，是方向的问题。AI 编程真正拼的从来不是操作熟练度，而是底层范式。操作是表层，范式是骨架。表层的东西三个月换一轮，骨架的东西三五年都稳。你花大量时间去记“点哪个按钮”“写哪句咒语”，本质上是在给一个随时会变的接口做缓存，缓存失效的那一刻，你的积累就归零了。那什么叫底层范式？说白了就是：你如何把一个问题拆给 AI、如何组织上下文、如何验证它的输出、如何在它出错时把它拉回来。这套东西跟具体用哪个工具没关系，跟模型是哪个版本也没关系。它更像是一种思维方式，一种你和机器协作的“工作流骨架”。你把这个骨架搭稳了，换任何工具都是往上挂插件；骨架没搭起来，换再多工具也只是在沙滩上盖楼。这篇文章我想聊的就是这个。适合谁看？适合那些已经用过几个 AI 编程工具、但总觉得“用得不顺手”“换个工具就废”“产出不稳定”的人。也适合刚入门、还没被操作教程带偏、想一开始就走对路的人。我会把范式拆成几个能落地的部分：任务怎么拆、上下文怎么给、结果怎么验、错误怎么修，每一块都配上我实际踩过的坑和能直接抄的做法。不聊虚的，只聊能用的。2. 范式一：把“提问”换成“任务分解”2.1 为什么单次提问的天花板很低大部分人用 AI 编程的第一个动作，是打开对话框，敲一句“帮我写一个 XXX 功能”。这句话看起来没问题，但它隐含了一个假设：AI 能一次性理解你脑子里那个完整的、模糊的需求，并直接给出可用的结果。这个假设在简单场景下偶尔成立，稍微复杂一点就崩。我举个真实的例子。之前我要做一个“读取本地表格、按某列分组、算每组均值、输出成新表格”的小脚本。第一次我直接说“帮我写个脚本处理表格分组求均值”，AI 给了一版，跑起来报错，因为列名对不上。我改了一句提示词，它又给一版，这次列名对了，但分组逻辑理解错了。来回五六轮，每一轮我都在补一个它没猜到的细节。这就是单次提问的典型困境：你在用对话的方式，做本该用分解的方式做的事。单次提问的天花板在于，它把“需求澄清”和“代码生成”压成了一步。而这两件事的难度完全不同。澄清需求需要的是结构化思考，生成代码需要的是模式匹配。你把它们混在一起丢给 AI，它只能靠猜，猜错了你就得重来。2.2 任务分解的实操框架我后来固定用一套分解框架，简单说就是把一个大任务切成“输入—处理—输出”三段，每段再问自己三个问题。这套框架不依赖任何工具，你在纸上都能画。第一段是输入。问自己：数据从哪来？格式是什么？有没有缺失或异常？比如上面那个表格任务，输入就是“一个 CSV 文件，第一行是表头，某列是分组依据，某列是数值”。第二段是处理。问自己：核心逻辑是什么？边界情况有哪些？比如“按分组列聚合，对数值列求均值，忽略空值，如果某组全是空值就输出 0”。第三段是输出。问自己：结果长什么样？写到哪？格式要求是什么？比如“输出一个新的 CSV，两列，一列是组名，一列是均值，保留两位小数”。你把这三段写清楚，再丢给 AI，效果完全不一样。因为它不再需要猜，它只需要执行。我实测下来，同样一个任务，用分解框架写出来的提示词，一次通过率能从三成提到七成以上。剩下的三成也不是逻辑错，多半是环境或依赖的小问题，改起来很快。提示：分解的时候不要怕写得啰嗦。你写给 AI 的每一句澄清，都是在替它省一次猜测，也是在替你自己省一轮返工。2.3 分解粒度怎么把握有人会问，那我要分解到多细？是不是每一行代码都要我说清楚？不是。分解的粒度标准是：每一个子任务，都应该能用一句话描述清楚它的输入和输出。如果一句话说不清，说明还没拆到位；如果一句话说完了但你觉得“这不明摆着吗”，说明拆过头了。举个例子。“读取 CSV”这个子任务，输入是文件路径，输出是一个表格对象，一句话说得清，粒度刚好。但如果你拆成“打开文件”“读取第一行”“按逗号切分”“存进列表”，这就过头了，这些是 AI 本来就该处理的实现细节，你管太细反而限制它。我自己的经验是，一个中等复杂度的任务，拆成三到七个子任务比较合适。少于三个，说明你还没想清楚；多于七个，说明你可能把实现细节也当成任务了。这个数字不是死的，但可以当个参考。3. 范式二：上下文不是越多越好，而是越准越好3.1 上下文过载的典型症状很多人有个误区，觉得给 AI 的上下文越多越好，于是把整个项目文件、所有相关文档、一堆历史对话全塞进去。结果 AI 反而变笨了，回答开始跑偏，甚至把不相关的信息混进来。这不是模型的问题，是上下文过载。上下文过载的典型症状有三个。第一，AI 开始“幻觉”，编造一些你没提过的函数或变量。第二，它抓不住重点，你问 A 它答 B。第三，响应变慢，因为它在处理大量无关信息。我踩过最狠的一次，是把一个几千行的配置文件整个贴进去，问一个很小的配置项怎么改，结果 AI 给我绕了一大圈，最后改错了地方。3.2 精准上下文的三个筛选原则我后来总结出三个筛选原则，用下来很稳。原则一：只给和当前子任务直接相关的代码。你正在改哪个函数，就给哪个函数，最多带上它调用的那一两个辅助函数。不要给整个文件，更不要给整个项目。原则二：给“接口”而不是“实现”。如果当前任务依赖另一个模块，你只需要告诉 AI 那个模块的输入输出是什么，不需要把它的内部实现贴出来。比如“有一个函数叫 parseDate，输入字符串返回日期对象”，这一句就够了，不用把 parseDate 的源码贴上去。原则三：用注释标注关键约束。有些约束是代码本身看不出来的，比如“这个字段可能为空”“这个接口有频率限制”“这个变量单位是毫秒不是秒”。这些要用注释或自然语言明确告诉 AI，否则它一定会按默认假设来，然后出错。3.3 一个上下文组织的实例我拿一个实际场景来说。假设我要给一个已有的数据处理流程加一个“去重”步骤。这个流程里已经有一个读取函数、一个清洗函数、一个输出函数。我要加的去重，是在清洗之后、输出之前。这时候我给 AI 的上下文应该是这样的：先说明“我有一个数据处理流程，顺序是读取、清洗、输出，现在要在清洗和输出之间插入去重”。然后给出清洗函数的输出格式（比如“一个列表，每个元素是字典，字典有 id 和 value 两个键”），再给出输出函数期望的输入格式。最后说明去重规则（比如“按 id 去重，保留第一次出现的”）。你看，我没有贴任何函数的实现代码，只给了接口和约束。AI 拿到这些信息，完全能写出正确的去重逻辑。而且因为上下文干净，它不会跑偏。这个做法我用了很久，稳定性比堆上下文高得多。注意：上下文里如果有任何“可能”“大概”“应该是”这种模糊词，AI 就会按最宽松的假设来。所以能确定的就写确定，不能确定的就明确说“这里不确定，按最保守的方式处理”。4. 范式三：验证不是最后一步，而是每一步4.1 为什么“跑通了”不等于“对了”新手最容易犯的错，是看到代码跑通没报错，就认为任务完成了。但“跑通”和“对了”是两回事。代码可能跑通但逻辑错了，可能跑通但边界没处理，可能跑通但性能很差。AI 生成的代码尤其容易这样，因为它擅长的是“看起来对”，而不是“真的对”。我举个例子。之前让 AI 写一个“判断字符串是否是回文”的函数，它给了一版，跑几个测试都过了。但我后来发现，它没有处理大小写和空格，输入“A man a plan”这种就判错了。如果我只测了“abcba”这种简单例子，就会以为它对了。这就是“跑通”和“对了”的差距。4.2 分层验证的具体做法我的做法是把验证分成三层，每层用不同的方式。第一层是单元验证。针对每个子任务，单独测它的输入输出。比如去重函数，我就单独喂几组数据进去，看输出对不对。这一层用最简单的断言就行，不需要复杂框架。第二层是集成验证。把子任务串起来，测整个流程。这时候重点看的是子任务之间的衔接，比如数据格式对不对得上、顺序对不对。很多 bug 都出在衔接处，而不是单个子任务内部。第三层是边界验证。专门测极端情况：空输入、超大输入、格式异常的输入、重复的输入。这一层最容易发现问题，也最容易被忽略。我现在的习惯是，每写完一个功能，先想三个边界情况，测完再交付。4.3 让 AI 自己参与验证有个技巧很好用：让 AI 自己写测试用例。你写完功能后，跟它说“请为这个函数写五个测试用例，覆盖正常情况和边界情况”。它写出来的测试，往往能覆盖到你自己没想到的点。然后你跑这些测试，如果有失败的，再让它修。这个做法有个额外好处：AI 写测试的时候，会重新审视一遍自己的实现，有时候它自己就发现问题了。我遇到过好几次，它写完测试说“这个用例可能过不了，因为我的实现没处理空值”，然后主动改了实现。这比你自己去挑错效率高。提示：验证的时候不要只测“应该成功”的情况，一定要测“应该失败”的情况。比如输入非法时，函数是报错还是返回默认值？这个行为必须明确，否则上线后就是隐患。5. 范式四：错误处理是范式的试金石5.1 AI 出错时的三种典型反应AI 出错的时候，人的反应基本分三种。第一种是直接放弃，觉得“AI 不行”，回去手写。第二种是反复重试同一句提示词，指望它某次蒙对。第三种是分析错误、调整输入、引导它修正。前两种都是操作层面的反应，只有第三种是范式层面的。我早期也是第二种，一句话反复问，问五六次不行就烦了。后来我发现，AI 出错基本就三类原因：信息不足、约束冲突、理解偏差。你针对原因去调，比盲目重试有效得多。5.2 按错误类型对症下药信息不足，就是你没告诉它某个关键前提。比如它用了一个你没提过的库，或者假设了一个不存在的字段。这时候你要补信息，而不是说“你错了重来”。约束冲突，就是你给的要求互相矛盾。比如你既要“高性能”又要“代码极简”，这两个在某些场景下是冲突的。AI 会随便选一个满足，另一个就崩了。这时候你要重新排优先级，告诉它哪个更重要。理解偏差，就是它把你的意思理解歪了。这时候不要重复原话，要换一种说法，或者举个例子。比如它把“去重”理解成“删除所有重复项”，而你要的是“保留一个”，你就得明确说“保留第一次出现的，删除后续重复的”。5.3 一个错误排查的实例我拿一个实际调试过程来说。之前让 AI 写一个“按时间范围过滤日志”的函数，它写完后跑出来结果不对，少了很多本该保留的记录。我先没急着改代码，而是问自己：这是哪类错误？看了一遍它的实现，发现它用的是“大于起始时间且小于结束时间”。但我的需求是“包含起始和结束当天”。这就是理解偏差，它把“范围”理解成了开区间，我要的是闭区间。于是我改了一句提示词：“时间范围是闭区间，起始和结束当天都要包含”。它改完就对了。整个过程没重试，没反复问，就是定位错误类型然后精准调整。这个思路你一旦养成，调试效率会高很多。6. 范式五：把经验沉淀成可复用的“套路”6.1 为什么每次都要从零开始很多人用 AI 编程，每次都是全新的对话，全新的提示词，全新的试错。这次踩过的坑，下次换个任务又踩一遍。这不是工具的问题，是没有沉淀。范式的最高一层，是把你验证过的做法沉淀成可复用的模板。这个模板不是提示词模板那种死东西，而是“遇到这类任务，我按这个流程走”的套路。比如“凡是涉及数据转换的任务，我先定义输入输出格式，再写转换逻辑，最后测边界”。这个套路一旦形成，你下次遇到类似任务，直接套就行，不用重新想。6.2 沉淀什么、怎么沉淀我沉淀的东西分三类。第一类是任务分解模板，针对常见任务类型（数据处理、接口调用、文件操作等），我有一套固定的分解问法。第二类是上下文组织模板，针对不同场景（改现有代码、写新功能、调 bug），我有不同的上下文给法。第三类是验证清单，针对不同任务类型，我有不同的必测项。沉淀的方式很简单，就是用一个文档记下来。每次做完一个任务，花两分钟想想：这次哪个做法好用？哪个坑下次要避开？记下来。积累多了，你就有了自己的范式库。这个库比任何教程都值钱，因为它是你亲手验证过的。6.3 套路不是死板，是起点有人可能担心，沉淀成套路会不会变得死板，失去灵活性？我的经验是，套路是起点不是终点。你按套路走，走到某一步发现这个任务有特殊性，那就偏离套路，处理完特殊性再回到套路。套路保证你不漏掉关键步骤，灵活性保证你应对特殊情况。两者不矛盾。我现在的状态是，拿到一个新任务，先判断它属于哪类，套对应的套路。大部分任务套完就解决了，少部分需要调整。这个效率比我早期每次从零开始高太多了。7. 常见问题与排查技巧实录7.1 常见问题速查表问题现象可能原因排查方向解决思路AI 反复给错方向上下文过载或信息不足检查是否给了无关内容，是否漏了关键约束精简上下文，补关键约束代码跑通但结果不对边界未处理或理解偏差测边界情况，对照需求逐条核对明确边界行为，换说法重述需求换个工具就废依赖操作而非范式回顾自己是否在记操作而非拆任务用分解框架重新组织任务产出不稳定验证环节缺失检查是否有分层验证补单元、集成、边界三层验证调试效率低盲目重试判断错误类型按信息不足、约束冲突、理解偏差分类处理7.2 几个我踩过的坑第一个坑是过度依赖单一工具。我早期把某个工具用得很熟，所有任务都在上面做。后来那个工具改版，我直接不会干活了。从那以后我刻意在不同工具间切换，逼自己关注范式而不是操作。第二个坑是忽略验证。有次赶进度，AI 写完代码我扫了一眼觉得没问题就交了，结果上线后发现一个边界没处理，返工花了两倍时间。从那以后我再赶也留时间做边界验证。第三个坑是提示词越写越长。我以为写得越详细越好，结果 AI 被一堆细节淹没，反而抓不住重点。后来我学会分层：先给任务框架，再给关键约束，细节让 AI 自己补。7.3 一个反直觉的经验有个经验可能反直觉：有时候少给一点信息，AI 反而做得更好。比如你让它写一个通用函数，如果你把太多具体场景的细节塞进去，它会写出一个很臃肿、耦合很重的实现。但如果你只给核心需求，它会写出更干净、更通用的代码。这个度怎么把握？我的判断标准是：给“必须满足的约束”，不给“可能用到的细节”。必须满足的约束是硬性的，不给就错；可能用到的细节是软性的，给了反而限制它。这个判断需要练，但练几次就有感觉了。8. 从操作到范式，我的转变过程我最早也是从记操作开始的。收藏夹里几十个教程，提示词模板存了一堆，快捷键背得滚瓜烂熟。那时候我觉得自己挺厉害，直到有一次工具大改版，我发现自己除了操作什么都不会。那种感觉很难受，就像练了很久的武功，突然发现招式全废了，内功一点没有。转变是从一次失败的项目开始的。那个项目任务比较复杂，我用老办法反复试，怎么都不顺。后来我停下来，不再想“该用哪个工具”“该写哪句提示词”，而是拿张纸把任务拆了一遍，把输入输出写清楚，把边界列出来。然后按这个分解去跟 AI 协作，一次就顺了。那次之后我才意识到，之前卡住不是因为工具不好，是因为我没把任务想清楚。从那以后我开始刻意练范式。每做一个任务，先不碰工具，先在纸上拆。拆完再动手。刚开始很慢，因为不习惯。但做了十几个任务之后，速度就上来了，而且稳定性完全不一样。以前是碰运气，现在是可预期。现在我看别人用 AI 编程，基本一眼能看出他是在操作层还是范式层。操作层的人，话题围绕“哪个工具好”“哪句提示词灵”；范式层的人，话题围绕“怎么拆任务”“怎么组织上下文”“怎么验证”。前者换工具就慌，后者换工具只是换个壳。如果你现在还在操作层，我的建议是：下一个任务，先别打开工具，拿张纸拆一遍。拆完再动手。就试这一次，你会感觉到差别。这个习惯养成了，你就从操作层进到范式层了。工具会一直变，范式不会。你押注在范式上，才是押注在不变的东西上。这个内容后续还可以这样扩展：针对不同类型的任务（数据处理、接口开发、自动化脚本等），分别整理一套分解模板和验证清单，形成自己的范式手册。手册越厚，你换工具时的底气越足。