为什么你用AI写代码总是“翻车”?因为你少了这一步思维跃迁

一、一个真实案例引发的思考

这个项目本质上是一个多语言文案改写引擎，核心流程如下：

1. 输入：
   用户上传原始视频文案（中文）
2. 处理：
   调用 NLP 模型进行语义理解和多语言翻译
3. 输出：
   生成英文、日文、韩文等版本的文案

初始版本实现了基础功能，但客户在使用一周后，反馈了一个关键问题：

“现在生成的泰文我完全看不懂，能不能给我一个中文对照？”

如果站在纯定制的角度，这个需求其实很好改。目标语言泰语，输出格式泰文加中文对照，提示词敲出来，事情结束。

但我当时停了一下。

我问自己一个问题：那如果下一个用户是英文呢？再下一个是日文、越南文呢？

是不是每来一种语言，我就要重写一套逻辑？

这时候你会发现一件事：需求本身不复杂，复杂的是它未来的变化。

二、从“面向过程”到“面向抽象”的思维跃迁

我们大多数程序员，包括我自己，过去写代码的时候，脑子里想的都是“过程”：先做什么，再做什么，遇到什么情况怎么处理。这是一种非常自然、也非常底层的思维方式。

但是，当我们把这种思维方式直接搬运到和AI的交互中时，问题就出现了。

2.1 什么是“面向过程”的AI交互？

假设你想让AI帮你写一个函数，用来处理用户的注册信息。一个“面向过程”的指令可能是这样的：

“帮我写一个Python函数，接收用户名、邮箱和密码三个参数。函数里先检查用户名是否为空，再检查邮箱格式是否正确，最后把密码加密后存入数据库。”

这个指令很清晰，对吗？AI可以完美地执行它。但是，这里有一个巨大的隐患：这个指令是高度耦合的，它把“做什么”和“怎么做”紧紧地捆绑在了一起。

如果有一天，需求变了：

1. 用户注册需要增加手机号验证。
2. 密码加密算法从MD5变成了SHA256。
3. 数据库从MySQL换成了PostgreSQL。

你会发现，你需要重新给AI写一整套指令。你成了AI的“保姆”，而不是它的“产品经理”。

2.2 什么是“面向抽象”的AI交互？

“面向抽象”的思维，核心是剥离“做什么”和“怎么做”。你告诉AI“做什么”（目标），让它自己去思考“怎么做”（路径）。

还是上面那个例子，一个“面向抽象”的指令可能是这样的：

“我需要一个用户注册模块，它能够安全地处理用户输入的注册信息，并完成用户身份创建。请为我设计一个高内聚、低耦合的模块，并给出实现方案。需要考虑的关键点包括：输入验证、数据脱敏、安全存储、以及未来可能的扩展性（如第三方登录）。”

看到区别了吗？

• 第一版指令：
  你是一个“保姆”，把每一步都安排好了。AI只是一个“打字员”，把你的自然语言翻译成代码。一旦“步骤”变了，一切归零。
• 第二版指令：
  你是一个“产品经理”，定义了“目标”和“质量标准”。AI变成了一个“架构师”，它需要自己去分析需求、设计架构、选择方案，并最终交付成果。

三、AI编程中的“抽象”到底是什么？

在软件开发中，抽象（Abstraction）是一种简化复杂系统的方式，它通过隐藏不必要的细节，只暴露核心功能。在AI编程的语境下，我们可以把“抽象”理解为：定义清晰、稳定、可复用的“接口”或“目标”，而将具体的实现细节交给AI去动态生成。

这个“接口”可以是一段Prompt，也可以是一个函数定义，甚至可以是一个业务逻辑的流程图。

3.1 抽象的三个层次

我们可以把AI编程中的抽象，分为三个层次：

1. 代码层面的抽象（函数/类）：
   这是最基础的抽象。你不是让AI写一段“打印Hello World”的代码，而是让AI写一个greet(name)函数。这个函数就是一次抽象，它把“打招呼”这个行为封装起来，name是输入，greeting是输出。
2. 模块层面的抽象（组件/服务）：
   这是更高一层的抽象。比如，你让AI设计一个“用户认证模块”，而不是让它写“检查用户名密码”的代码。这个模块可以包含登录、注册、密码重置、第三方登录等多个功能，但对外暴露的接口只有login()、register()、resetPassword()等。
3. 业务层面的抽象（工作流/Agent）：
   这是最高层次的抽象。你不再关注某个具体的函数或模块，而是关注整个业务流程。比如，你告诉AI：“我需要一个自动化系统，当用户提交一个工单后，它能自动分类、分配、并回复初始问候。” 这就是一个业务流抽象。AI需要自己拆解任务，调用不同的工具（如数据库、邮件服务、LLM），最终完成这个目标。

3.2 回到开头的案例：如何用抽象解决问题？

让我们用“面向抽象”的思维，重新审视那个多语言文案改写需求。

第一版（面向过程）的Prompt：

“把这段视频文案翻译成泰文，并在输出时，每一行泰文下面加上对应的中文翻译。”

第二版（面向抽象）的Prompt：

“我需要一个‘多语言文案智能改写与对照输出模块’。它的核心目标是：接收一段源文案，根据用户指定的目标语言，生成改写后的文案，并输出一份格式化的对照文档。

关键需求：

1. 泛语言支持：
   系统不应硬编码支持的语言列表。用户输入什么语言，就应该能处理什么语言。
2. 输出格式：
   输出格式应支持动态配置。默认是‘源语言-目标语言’对照，但未来应能轻松扩展为‘源语言-目标语言-拼音’或‘源语言-目标语言-注释’等多种格式。
3. 内容保真度：
   改写过程中，需要保留原文的核心信息、语气和关键术语。

请设计这个模块的接口、核心逻辑，并用Python实现一个原型。请确保代码具有良好的可扩展性。”

看到区别了吗？第二版Prompt，我没有说“怎么做”（泰文加中文对照），而是定义了“是什么”（一个多语言改写模块）和“有什么约束”（泛语言支持、动态格式、内容保真）。

这样做的结果是：

• 当客户要求加中文对照时，
  AI不是去改代码逻辑，而是去调整“输出格式”这个配置项。甚至不需要你动手，AI自己就能理解“格式”是一个变量。
• 当未来需要支持日文、越南文时，
  AI不需要重写任何代码，因为“目标语言”本身就是模块的一个输入参数。
• 当未来需要输出“原文-译文-拼音”三列时，
  AI只需要在“输出格式”这个抽象层上增加一个新的模板即可。

这就是抽象的力量。它让你的代码、你的Prompt、甚至你的整个工作流，都变得弹性、可扩展、且易于维护。

四、如何训练自己的“抽象思维”？

说了这么多，你可能会问：“Jay，道理我都懂，但具体怎么练习呢？”

这里我分享三个非常实用的技巧，帮助你在日常的AI编程中，刻意练习你的抽象能力。

4.1 技巧一：使用“5W1H”法定义任务

在把任务交给AI之前，先问自己六个问题：

• Who（谁）：
  谁是AI？它是一个Python后端开发者，还是一个前端架构师，还是一个全栈产品经理？给它一个角色。
• What（什么）：
  我们要完成的核心目标是什么？不要描述过程，只描述结果。
• When（何时）：
  有什么时间限制或优先级要求吗？
• Where（何地）：
  这个代码最终会运行在哪里？本地、服务器、还是边缘设备？
• Why（为什么）：
  为什么要做这个抽象？是为了提高复用性，还是为了降低维护成本？告诉AI你的“动机”，它能更好地理解你的意图。
• How（如何）：这一点要特别注意。在“面向抽象”的思维里，“How”不再是具体的实现步骤，而是约束条件
  和质量标准。比如：代码要遵循PEP8规范，要使用异步IO，要保证线程安全等。

当你把“How”从“具体步骤”转变为“约束条件”时，你就完成了从“保姆”到“产品经理”的转变。

4.2 技巧二：先写“接口”，再写“实现”

这是软件工程里最经典的“契约式设计”思想。在让AI写代码之前，先让它写出这个模块或函数的接口定义。

具体做法：

1. 定义输入输出：
   告诉AI，这个函数的输入参数是什么类型，输出结果是什么类型。
2. 定义行为：
   告诉AI，这个函数在各种边界条件下（如输入为空、输入不合法）应该有什么样的行为。
3. AI生成接口：
   让AI根据你的定义，生成一个“空壳”函数（即只有函数签名和文档注释，没有函数体）。
4. 评审接口：
   你作为“架构师”，先评审这个接口是否合理、是否易用、是否满足未来的扩展需求。
5. 让AI填充实现：
   确认接口无误后，再让AI根据这个接口，去填充具体的实现逻辑。

示例Prompt：

“我需要一个函数，用于处理用户上传的CSV文件。请先帮我设计这个函数的接口（Python类型提示），包括：

1. 输入：文件路径（str）、分隔符（str, 默认逗号）、是否跳过首行（bool, 默认True）。
2. 输出：一个生成器（Generator[Dict[str, str], None, None]），每次yield一行数据，以字典形式返回，key是列名，value是单元格的值。
3. 异常：当文件不存在、格式错误或内存溢出时，抛出相应的自定义异常。

请先写出这个函数的接口（函数签名+文档字符串），不要实现具体逻辑。等我确认后，你再填充实现。”

这个方法的好处是，它强制你和AI都先思考“架构”和“契约”，而不是一头扎进“实现”的细节里。这能极大地减少后期返工的可能性。

4.3 技巧三：把“变化”和“不变”分离

这是抽象的核心原则。在分析一个需求时，主动去识别哪些部分是稳定不变的，哪些部分是未来可能变化的。

• 不变的：
  业务的核心逻辑、数据模型、核心算法。这些是系统的“骨架”。
• 变化的：
  输入来源、输出格式、具体的数据源、UI样式。这些是系统的“皮肤”。

你的任务，就是把这些“不变的部分”做成一个稳定的抽象层，而把“变化的部分”做成可配置、可插拔的组件。

再回到那个文案改写的例子：

• 不变的：
  改写的核心逻辑（保留原意、调整语气）、对照输出的数据结构。
• 变化的：
  源语言、目标语言、对照格式（双语/三语/带注释）。

所以，你设计的模块，核心逻辑是稳定的，而语言和格式是作为参数传入的。这就是分离的艺术。

五、总结：从“代码工人”到“AI架构师”

真正会用AI编程的人，不是那些能写出最复杂Prompt的人，而是那些能做出最精准“需求抽象”的人。

他们不再关心AI是怎么一步步实现功能的，他们只关心：

1. 这个模块的“接口”是什么？
2. 这个模块能应对哪些“变化”？
3. 这个模块如何与其他模块“协作”？

当你的思维从“面向过程”转向“面向抽象”，你会发现，你和AI的关系发生了根本性的改变：

• 你不再是AI的“操作员”，而是AI的“产品经理”。
• AI不再是你的“打字员”，而是你的“架构师”和“高级工程师”。

这是一种认知的跃迁。它需要我们刻意练习，把“抽象”变成一种本能。但一旦你掌握了它，AI就不再是一个简单的工具，而是一个能够与你并肩作战、共同构建复杂系统的强大伙伴。

希望今天的分享能给你带来一些启发。如果你在实践中有任何问题或心得，欢迎在评论区留言，我们一起探讨。

我们下期再见！