AI编程范式（2025-2026）

当你根据需求文档和已有代码，完善 Prompt 然后回车交给 Agent 去执行的时候，你在做什么？

画面似曾相识：你打开 IDE，切换到 AI 对话框，粘贴一段需求描述，附上几个相关文件的路径，点击发送。然后——你靠在椅背上，看着屏幕上逐字跳出的代码，像看一场慢放的电影。有人开始刷手机，有人切到另一个标签页摸鱼，有人干脆起身去倒杯水。

这几乎是每个使用 AI Coding 的人都会经历的经典场景。从 Cursor 到 Copilot，从 Claude 到 CodeX，工具在进化，但这个"等待"的动作却出奇地一致。

但问题是：在 AI 干活的时候，你真的应该只是等着吗？

AI 输出时，工程师该做什么

当 AI 正在生成或已经输出代码时，恰恰是工程师最该忙碌的时候。

AI 擅长的是执行——根据你的指令，快速生成代码。但它不擅长的是判断——判断这段代码是否真正解决了问题，是否引入了新的问题，是否符合整体的设计方向。

所以，当 AI 在输出时，你应该同步进行多维度的思考：

从需求维度：AI 生成的代码是否覆盖了所有需求场景？有没有遗漏的边界条件？异常处理是否完善？用户输入了非法数据会怎样？网络超时了怎么办？后续可能还需要补充什么功能？

从测试维度：哪里可能有坑？哪些路径需要写单元测试？集成测试的范围是什么？有没有容易忽略的异常路径？比如一个看似简单的用户注册功能，AI 可能不会考虑到用户名重复、邮箱格式校验、密码强度要求、并发注册等场景。

从架构维度：这个实现方式是否符合项目的整体架构？有没有破坏现有的设计模式？扩展性如何？如果未来需求变了，这段代码容易修改吗？这里用这个库合适吗？有没有更轻量的替代方案？

从安全维度：是否存在 SQL 注入、XSS、CSRF 等常见漏洞？权限校验是否到位？敏感数据有没有泄露风险？AI 生成的代码往往能跑通功能，但安全意识是它的盲区。

从性能维度：这里会不会成为性能瓶颈？数据库查询是否需要加索引？是否需要引入缓存？循环里有没有不必要的重复计算？

你看，AI 在"写代码"的时候，你在"做工程"。这两件事完全不冲突，而且后者恰恰是工程师的核心价值所在。

原则一：模型与 Agent 的选择策略

很多人只关注"用哪个模型"，却忽略了 Agent 同样重要。

模型负责什么？ 模型的核心能力是理解、推理和生成。它理解你的需求，推理出实现方案，生成对应的代码。模型的质量决定了代码的"智商"——逻辑是否严密、代码是否优雅、是否考虑到了边界情况。

Agent 负责什么？ Agent 的核心能力是工具调用、文件操作和流程编排。它读取项目文件、执行命令、修改代码、运行测试。Agent 的质量决定了代码的"落地能力"——能否正确找到需要修改的文件、能否在正确的上下文中工作、能否处理执行过程中的错误。

选择模型的依据：

• 任务复杂度：简单的代码补全用轻量模型即可，复杂架构设计需要强推理模型
• 上下文窗口：大项目需要大上下文窗口，否则 AI "记不住"你的项目结构
• 推理能力：涉及逻辑推导、算法设计的场景，需要推理能力强的模型
• 成本：日常高频使用要考虑性价比，不必每个任务都用最贵的模型

选择 Agent 的依据：

• 工具链完整性：能否执行你需要的命令？能否操作你需要的文件？
• 项目理解能力：能否自动识别项目结构、技术栈、代码规范？
• 错误恢复能力：执行失败时能否自动重试或给出有用的错误信息？

搭配策略： 对于复杂项目，"强模型 + 强 Agent"是理想选择；对于日常小改动，"中等模型 + 轻量 Agent"可能更高效。关键是匹配任务需求，而不是一味追求最强配置。

原则二：精准全面的提示词工程

提示词的质量，直接决定 AI 输出代码的质量。

垃圾进，垃圾出（Garbage In, Garbage Out） 这句话在 AI Coding 中体现得淋漓尽致。

一个结构化的提示词应该包含以下要素：

• 背景：当前在做什么功能，处于项目的什么位置
• 目标：具体要实现什么，期望的结果是什么
• 约束：技术栈限制、性能要求、兼容性要求、代码规范
• 输入输出格式：函数的参数和返回值、API 的请求和响应格式
• 示例：给出一个类似的已有实现作为参考

技术化表达是关键。 不要说"帮我做一个用户管理页面"，而要说"在 src/pages/admin/users/page.tsx 创建一个用户管理页面，使用 Next.js App Router，数据通过 GET /api/users 获取，支持分页（每页 20 条）、搜索（按用户名和邮箱）、状态筛选（启用/禁用），UI 使用 shadcn/ui 的 Table 组件"。

避免模糊表述。 "优化一下性能"是模糊的，"将首页首屏加载时间从 3s 降低到 1.5s 以内"是明确的。"修复 bug"是模糊的，"修复用户点击提交按钮后表单数据未清空的问题"是明确的。

提供上下文文件路径和相关代码片段。 AI 不是算命先生，它不知道你项目里有什么。告诉它相关文件在哪里，它才能做出符合项目现状的改动。

提示词需要迭代优化。 第一次的提示词往往不够好，根据 AI 的输出结果，不断调整提示词的表达方式、补充遗漏的信息、修正不准确的理解。这是一个持续精进的过程。

原则三：问答反转机制

这是很多人忽略但极其重要的一条原则。

什么是问答反转？ 就是在描述完需求后，不急着让 AI 直接写代码，而是先让 AI 复述它的理解，梳理改动方案，并提出不明确的问题。

具体做法： 在 Prompt 的最后加上一句："请先复述你对需求的理解，列出你打算改动的文件和大致方案，并指出任何不明确或需要我确认的地方。确认后再开始编码。"

这个机制的价值在于：

• 避免误解：你以为 AI 理解了，其实它理解错了。问答反转在编码前就暴露了理解偏差，避免写完了才发现方向错了。
• 发现遗漏：AI 在梳理方案时，可能会发现你没想到的边界情况或关联影响。
• 明确责任：让 AI 先说出它的方案，你确认后再执行。这样出了问题，可以追溯是方案阶段的问题还是执行阶段的问题。
• 节省成本：方案阶段的修改成本远低于编码完成后的返工成本。

适用场景： 对于大需求、复杂需求、关联牵扯多的需求，问答反转是必选项。对于简单的单文件改动，可以省略这一步以提高效率。

原则四：善后检查与沉淀

AI 完成任务后，不要急着合并代码。

让 AI 输出善后报告。 在 Prompt 中要求 AI 完成后输出：改动清单（改了哪些文件、改了什么）、注意事项（有什么需要特别注意的）、可能的副作用（可能影响了哪些其他功能）。

比如： "完成需求后，请列出：1）本次改动的文件清单及改动说明；2）需要人工 review 的关键点；3）可能受影响的关联功能；4）后续建议的测试方向。"

建立检查清单（Checklist）。 根据项目特点，建立一套 AI 生成代码的检查清单：

• 是否有未处理的异常？
• 是否有硬编码的配置？
• 是否有安全漏洞？
• 是否有性能问题？
• 是否符合代码规范？
• 是否有对应的测试？

知识沉淀。 将 AI 犯过的错、踩过的坑、做出的正确决策，沉淀到项目文档中。比如写入 AGENTS.md 或项目的 docs 目录。下次 AI 再处理类似需求时，这些沉淀的知识就能发挥作用。

原则五：上下文管理艺术

上下文管理是 AI Coding 中最容易被忽视、但影响最大的因素之一。

为什么上下文很重要？

AI 的上下文窗口是有限的。你把太多无关信息塞进去，AI 会"迷失"在上下文中，找不到重点。你把太少信息塞进去，AI 又缺乏足够的背景来做出正确决策。

更严重的是上下文污染。 在一个 Session 里聊了十个需求，AI 的记忆里混杂了十个需求的信息。当它处理第十一个需求时，可能会错误地引用前面某个需求的上下文，导致代码出错。

上下文管理的核心原则：

• 一事一 Session：每个需求、每个小模块、每个改动点，单独开启一个 Session。保持上下文的纯净和专注。
• 快速建立上下文：新 Session 开始时，用简洁的方式让 AI 了解项目整体情况和当前任务的关注点。AGENTS.md 就是为此而生——它应该包含项目结构、技术栈、代码规范、常用命令等核心信息。
• Memory 沉淀：将项目约定、历史决策、踩坑记录自动沉淀到 Memory 文件中。AI 在后续 Session 中读取这些 Memory，就能快速"回忆"起项目的关键信息。
• 平衡完整性与简洁性：上下文不是越多越好，也不是越少越好。关键是提供"足够且必要"的信息。

一个实用的技巧： 为不同类型的任务准备不同的"上下文模板"。比如"新增 API 接口"的模板包含：路由文件位置、数据库模型定义、已有接口的参考示例。"修复 Bug"的模板包含：错误日志、相关代码片段、复现步骤。

原则六：识别 AI 的能力边界

知道 AI 能做什么很重要，知道 AI 不能做什么更重要。

AI 擅长的领域（放心交给 AI）

明确机械化的场景： 批量 SQL 刷数、数据格式转换、代码迁移（比如从 JavaScript 迁移到 TypeScript）。这些场景规则明确、重复性高，AI 做得又快又好。

标准化流程： 后端的 CRUD 接口、API 封装、单元测试模板、DTO 定义。这些场景有成熟的模式和最佳实践，AI 可以高效生成。

前端新页面： 没有严格 UI 限制的页面、管理后台的列表页和表单页。只要描述清楚字段和交互，AI 能快速搭建出可用的页面。

模块化新增： 单模块的改造、完全新增的功能、影响范围小的改动。比如"新增一个用户积分查询接口"，AI 可以独立完成从路由到数据库到返回值的完整链路。

AI 不擅长的领域（需要人工主导）

严格复杂的 UI： 像素级还原设计稿、复杂的交互动画、响应式布局的精细调整。这些场景需要视觉判断和微调，AI 目前还做不到位。需要设计师配合，或者人工逐像素调整。

影响范围广的改造： 代码量不多但影响范围大，需要在多个文件和模块中协调改动。比如"将用户 ID 从 int 改为 string"，看似简单，但可能涉及数据库、API、前端、缓存等多个层面。这种场景需要人工梳理影响范围，制定改造计划，然后分步骤让 AI 执行。

跨上下文场景： 需要在多个需求文档、前后端、页面、数据库、日志之间反复切换的地方。比如排查一个线上 Bug，需要看前端报错、后端日志、数据库数据、用户操作路径。AI 缺乏这种跨维度的关联分析能力。需要人工主导排查方向，AI 辅助执行具体操作。

架构决策： 技术选型、性能优化方案、安全设计。这些决策需要综合考虑业务现状、团队能力、未来规划等因素，AI 缺乏这种全局视角。需要架构师主导，AI 提供方案对比和技术细节。

业务逻辑核心： 复杂的业务规则、领域模型设计。比如电商的优惠计算规则、金融的风控模型。这些场景业务逻辑复杂、边界条件多，AI 容易遗漏关键逻辑。需要业务专家梳理规则，AI 辅助实现。

原则七：从 AI Coding 到 AI Engineering 的进阶

会用 AI 写代码只是第一步，建立系统化的 AI Engineering 能力才是长久之计。

建立 AI Coding 的工作流和 SOP。 团队应该有一套标准化的 AI 使用流程：需求如何描述、Prompt 如何编写、代码如何 review、测试如何补充、文档如何更新。这套 SOP 能让团队中的每个人都能高效使用 AI，而不是各自摸索。

训练 AI 理解项目约定和代码风格。 每个项目都有自己的代码风格、命名规范、架构模式。通过 AGENTS.md、.cursorrules、.github/copilot-instructions.md 等配置文件，让 AI 自动遵循项目约定，减少人工调整的成本。

自动化测试与 AI 生成代码的结合。 AI 生成的代码必须经过测试验证。建立自动化测试流水线，AI 生成代码后自动运行测试，发现问题自动反馈。让测试成为 AI Coding 的安全网。

CI/CD 中集成 AI Code Review。 在 Pull Request 流程中引入 AI Code Review，自动检查代码质量、安全漏洞、性能问题。AI 可以作为第一道防线，人工 review 作为第二道防线。

团队协作中的 AI 使用规范。 明确哪些场景可以用 AI、哪些场景必须人工处理；AI 生成的代码如何标注、如何 review；AI 使用中的安全注意事项（比如不能把敏感代码传给 AI）。

持续优化：从 AI 的错误中学习。 每次 AI 犯错，都是一次优化流程的机会。是 Prompt 不够清晰？是上下文不够充分？是 AI 的能力边界？记录下来，不断完善提示词模板、上下文管理策略、任务分配方案。

工程师在 AI 时代的未来范式

回到最初的问题：当 AI 在干活时，你在干什么？

答案越来越清晰：你在做 AI 做不了的事。

工程师的角色正在发生深刻的转变。我们正在从编码者转变为架构师——设计系统架构、做出技术决策、把握整体方向；从执行者转变为审查者——审查 AI 生成的代码、判断质量、把控风险；从知识消费者转变为AI 训练者——将项目知识、业务规则、最佳实践转化为 AI 能理解的形式。

什么能力更重要了？

• 系统设计能力：AI 能写代码，但设计一个可扩展的系统仍然需要人类工程师。
• 问题拆解能力：把复杂需求拆解为 AI 能处理的小任务，这种能力越来越重要。
• 代码审查能力：快速判断代码质量、发现潜在问题，比手写代码更重要。
• 沟通能力：与 AI 沟通（写 Prompt）和与人沟通（需求理解、方案讨论）都变得关键。
• 业务理解能力：深入理解业务逻辑，才能判断 AI 生成的代码是否真正解决了问题。

什么能力被替代了？

• 机械化的编码工作：CRUD、模板代码、格式转换。
• 简单的 Bug 修复：有明确错误信息的、模式化的 Bug。
• 基础的代码重构：重命名、提取方法、简化条件表达式。

但这不意味着工程师的价值降低了。相反，工程师的价值被放大了——因为我们从重复劳动中解放出来，可以把精力投入到更有价值的事情上：更好的架构设计、更深入的业务理解、更创新的技术方案。

人机协作的理想状态是什么？

不是 AI 替代人类，也不是人类依赖 AI，而是人类和 AI 各司其职、优势互补。AI 负责执行、生成、计算；人类负责判断、决策、创新。AI 是工程师的"超级助手"，而不是"替代者"。

当你下次端起保温杯，看着 AI 在屏幕上逐字输出代码时，希望你不再只是等待。

因为你知道，AI 在干活的时候，你有更重要的事情要做。

Prompt：
写一篇深度文章，探讨 AI Coding 模式下的工作范式。
第一段从一个经典的场景引出话题，举例很多人 AI Coding 的经典流程场景；
第二段写当 AI 输出内容时，应该做什么，包括但不限于：从需求出发思考哪里可能逻辑不完善需要补充、后续可能要做什么，从测试出发思考哪里可能有坑、边界条件都是什么，从架构出发思考哪里怎么设计、怎么取舍更好，等等；
第三到九段写 AI Coding 的几大原则：
1是模型和Agent的选择，模型和Agent同样重要，谁分别负责和影响了什么，选择配置依照什么原则以达到最佳效果。
2是尽可能用全面、精准、技术化的提示词。
3是问答反转，对于比较大、比较复杂或者关联牵扯地方比较多的需求，在描述完需求后，让 AI 先梳理需求及改动方案，并提出不明确的问题待用户明确后再进行修改。
4是善后提示。对于AI很可能出错、改动有关联影响的地方，在解决完需求后，让 AI 给出上述改动后需要注意的地方。
5是上下文很重要，合理控制上下文，每个需求或是每个小模块、改动点、关联文件最好是单起一个 Session ，避免上下文污染和 Tokens 额外使用，核心还是让模型和 Agent 专注于一项事务；另外是让模型尽可能快速了解整体情况和当前任务关注情况，写好 AGENTS.md ，自动沉淀 Memory 等。
6是区分 AI 擅长的领域和不擅长的领域，前者如非常明确且机械化的场景（大量 SQL 刷数等）；标准化的流程：后端的 CURD 等明确的标准化的流程、前端的新页面尤其是无 UI 严格限制页面；模块化的范围不大的场景：单模块的、对其他地方影响不大或无影响的地方的改造，或是完全新增的场景。这些场景描述清楚后让AI去做即可。后者如严格且复杂的UI样式限制的前端页面，仍需待模型尤其多模态模型进步，或是UI配合；改造本身代码量不多但影响范围很大，需要在一个项目的多个文件和模块中协调改造的；跨项目、跨上下文的场景：需要在 多个需求文档/前后端/页面/数据库/日志 之间反复切换的地方。指出这些场景下应该怎么做。除上述举例场景外再根据常见的重要的常见进行举例说明。
7是在上述基础上思考如何更进一步、深层次地做好 AI Coding。
第十段（文末）探讨工程师在AI时代的未来工作范式。
上述 Prompt 是我随笔写的文章大纲，请先给出优化补充后的Prompt，目标一是尽可能不遗漏 AI Coding 需要注意的重点，二是让文章更条理清晰化，三是结合常见举例更通俗易懂，四是要有深度有见地，语言风格专业化。
最后根据优化后的 Prompt 写一篇文章。