AI 是时代的魔法，我们都是魔法师

AI 就是这个时代的魔法。

你对着一个对话框写下几句话，一段代码、一个页面，甚至一个能运行的项目便凭空出现。提示词像咒语，代码和文档是施法材料，Cursor、Claude Code 这些工具则越来越像魔杖。过去需要翻半天手册才能完成的工作，现在念对一句咒语，也许几分钟就有了结果。

魔法的问题也在这里：它能跳过过程，把结果突然摆到你面前。看得懂过程的人会觉得省了一下午；看不懂的人，往往要等到出事才知道刚才施展的是什么法术。

去年，我让 AI 给一个内部服务补重试机制。需求听上去很简单：调用库存接口超时后，最多重试三次。它很快写完了，代码整洁，单元测试也绿了。上线前做集成测试，我们却发现，一次库存扣减变成了三次。AI 处理了“重试”，没有追问库存接口是否幂等；测试验证了调用次数，也没有验证最终的业务结果。

这场小型魔法事故没有进入生产。它让我越来越确信，工程师之间的新差距，不在于谁手里有 AI，而在于谁能控制它的效果。

过去两年，我见过工程师用 GitHub Copilot 补一行判断，也见过有人把一个 Jira 需求交给 Claude Code，半小时后拿到十几个文件的修改。模型能力差不多，产出却可能相差一个数量级。所谓“会用 AI”，远不只是提示词写得漂亮。你得能描述问题、准备上下文、发现风险，最后还要敢在发布单上签自己的名字。

沿着这几种能力，可以把 AI 时代的软件工程师分成几个魔法等级。

零阶：麻瓜

麻瓜照旧打开 Stack Overflow、查官方文档、在 IDE 里逐行敲代码。碰到线上问题，就从 Grafana 的曲线一路翻到日志和数据库慢查询。

这套工作方式没有过时，而且以后也不会。AI 生成的代码最终仍要落进编译器、数据库和真实流量里。只是很多原本需要来回搜索、复制、改写的工作，现在已经有了更便宜的做法。

我见过一位很资深的 Java 工程师，花了半天整理某个老系统里二十多种订单状态。后来我们把实体类、状态表和几段历史 SQL 一起交给模型，它十分钟就列出了状态转换图。结果并不完全正确，却把最费体力的第一轮梳理做掉了。工程师修正其中三条错误后，下午就开始讨论迁移方案。

麻瓜与巫师之间，往往只隔着这样一次尝试。

一阶：魔法学徒

学徒已经开始把 AI 当成更聪明的代码补全。他会在 Cursor 里说“写个分页查询”，或者让 ChatGPT 把一段 Python 改成 Go。

顺利的时候，一次就能运行。麻烦出在它不顺利的时候。模型虚构了一个 SDK 方法，学徒便继续要求“修复报错”；修完旧错又冒出新错，十几轮对话后，代码终于能编译，却没人说得清为什么要这样写。

这个阶段最常见的错觉，是把“生成完成”当成“任务完成”。编辑器里突然多出两百行代码，会给人一种工作正在高速推进的满足感。可真正昂贵的部分——接口约束、数据一致性、失败后的行为——通常还没有开始。

学徒需要养成一个有点扫兴的习惯：每次接受代码前，问自己一句“我凭什么相信它？”能跑只是最低门槛。

二阶：咒术师

熟练的施法者很少写所谓的“万能提示词”。他会把仓库里真正有用的东西交给 AI：package.json、相关接口、现有测试、错误日志，以及团队的代码规范。

比如“做一个登录页”几乎没提供信息。换成下面这段，事情才开始变得可执行：

沿用 src/components/forms 里的表单组件；调用现有的 /api/session；不要新增状态库；提交期间禁止重复点击；401 显示账号或密码错误，429 显示稍后重试；最后跑登录模块的 Playwright 用例。

这段话其实是一份微型设计说明：范围在哪里，复用什么，哪些行为不能丢，怎样验收。

到了这里，AI 不再只用来回答问题。工程师会先让它读代码和复述理解，再让它提出两三个方案；看到模型准备引入一套新依赖时，会立刻把它拉回来。对话变短了，返工也少了，因为关键决定已经由人提前做掉。

三阶：战斗法师

战斗法师开始把 AI 带进真实代码库。这里没有干净的题目，只有七年前的 Spring 服务、缺了一半的测试，以及注释里那句著名的 TODO: temporary fix。

一次真实的改动通常会穿过好几层：OpenAPI 定义、Controller、领域逻辑、数据库迁移、监控指标，最后还可能碰到移动端旧版本。AI 很擅长沿着已知路径快速铺代码，却容易漏掉仓库之外的约束。

我们曾经给订单表增加一个状态。模型找全了后端的枚举和 switch，测试也通过了。代码评审时，一位工程师顺手查了数据仓库，发现下游 Airflow 任务用 SQL 写死了原来的状态集合。那一眼避免了第二天报表少算一批订单。

所以战斗法师不会只问“改了哪些文件”。他会查调用方、消息消费者、定时任务、数据看板和回滚路径。AI 可以负责搜索和列清单，边界必须由理解系统的人确认。

四阶：召唤师

当任务足够大，一个对话窗口很快就会塞满上下文。召唤师会拆开工作：一个代理追调用链，一个分析数据库迁移，一个实现接口，另一个只做代码审查。

这种方式确实快，也特别容易制造混乱。我见过三个代理同时修改同一份类型定义：第一个重命名字段，第二个给旧字段加校验，第三个根据旧类型生成测试。每份修改单独看都像那么回事，合在一起连 TypeScript 都过不了。

有效的并行依赖清楚的边界。调查可以同时做，架构决策要先收敛；不同目录的实现可以并行，共享协议最好只交给一个人改。召唤师的主要工作也由写代码变成了定义任务、管理依赖和验收整合结果。

这和带一个工程团队很像。把含糊的需求复制四份，不会得到四倍生产力，只会得到四种理解。

五阶：魔导师

魔导师已经厌倦了反复提醒 AI：“我们用 pnpm”“金额不能用浮点数”“新增接口必须带 tracing”。他会把这些约束写进仓库，让每一次会话都能读到；再把构建、类型检查、测试和静态扫描接进工作流，让错误尽早暴露。

在这样的项目里，AGENTS.md 应该像施工图一样具体。它会告诉代理从哪里找领域模型，哪些目录禁止直接依赖，数据库迁移如何命名，提交前必须运行什么。常见任务则被做成脚本或技能：创建新服务、生成 API 客户端、检查破坏性 Schema 变更，都沿用同一条可靠路径。

魔导师关注的数据也很朴素：AI 提交的代码有多少在评审时被重写？缺陷主要漏在哪一层？节省的是编码时间，还是把成本推给了评审和线上排障？

如果团队用了 AI 以后 PR 数量翻倍、评审队列也翻倍，很难说这是效率提升。好的魔法体系会减少认知负担，糟糕的体系只会更快地生产待检查代码。

六阶：大魔法师

大魔法师未必每天生成最多的代码。他通常是那个删掉最多错误前提的人。

有人提出做一套“智能配置平台”，AI 已经生成了权限模型、审批流和数据库设计。大魔法师看完会问：过去半年到底有几次配置变更？如果答案是十二次，也许一个带评审规则的 YAML 文件已经够用。

这是架构工作最难的部分。模型可以快速补全一个既定方向，却很少主动质疑目标本身。它不知道公司准备在三个月后下线这个业务，也不知道运营团队宁愿每天导入一次 Excel，更不知道一次错误扣款会让客服忙上一整周。这些信息散落在会议、组织和人的记忆里，不在代码上下文中。

到了这一层，工程师使用 AI 的方式反而显得克制：先用它扩大搜索范围、暴露遗漏、挑战方案，再决定是否写代码。该自动化的地方毫不犹豫，该停手的地方也不会因为已经生成了五千行而舍不得。

魔杖普及之后

我不太相信“AI 会让所有人都成为十倍工程师”。十倍的代码很容易，十倍的需求价值、系统可靠性和团队吞吐量要难得多。现实里，未经约束的生成速度经常先撞上评审、测试和发布能力的上限。

但软件工程的门槛确实移动了。过去，我们把大量时间花在记忆 API、搬运样板代码和寻找语法错误上；以后，这些工作的价格会越来越低。问题定义、系统边界、取舍和验证则会变得更贵。

魔杖已经摆在桌上。会不会念咒当然重要，知道召唤什么、为什么召唤，以及召唤出来以后怎么收场，更重要。

AI 时代，你我皆是魔法师。至于施展完会不会炸，那是另一回事。