早几年，圈子里还在争论“AI能不能替代程序员”，到了这两年，争论的焦点已经变成了“程序员还能做什么”。我自己的感受很直接：过去那种只需要把需求翻译成代码、每天和琐碎的增删改查打交道的“码农”角色，正在肉眼可见地被压缩。与此同时，一个新的角色在慢慢浮出水面——AI编排工程师。这个岗位的名字还没有完全统一，有人叫AI应用工程师，有人叫提示词架构师，也有人沿用着“程序员”的头衔，但做的事情已经完全不同。这一篇，我想结合自己带团队、做项目的经验，聊聊我看着“码农”消退的感受，以及“AI编排工程师”到底要怎么当。
先说一个基本的判断：AI不会让程序员消失，但会让只会“写代码”的程序员消失。这件事和当年IDE的出现很像，当时也有人说程序员要失业，结果是程序员的产出提高了，工作重心从“敲键盘”变成了“读代码、调逻辑”。这一轮AI的冲击，把重心从“写代码”进一步推向了“写规格、管约束、审产出”。换句话说，需求还在，业务还在，系统的复杂性还在，只不过我们需要换一种方式去驾驭它们。
1. 先聊清楚：被淘汰的到底是谁
1.1 三层工作内容的剥离
我习惯把传统开发者的日常工作分成三层：底层是“把逻辑翻译成语法正确的代码”，中间层是“把业务需求拆解成可实现的模块”，顶层是“在约束下做技术决策、平衡质量和成本”。
前些年这三层是绑在一起的，一个后端工程师既要写DAO层查数据库，又要设计接口，还得参与表结构评审。AI代码助手一出现，第一层最先松动。只要需求描述得足够清楚，让AI生成一段CRUD代码，速度比人手快几倍，代码风格甚至更统一。于是大量初级开发者的日常工作中，最耗时间的“翻译”部分被抽走了。
但有意思的是，中间层和顶层不仅没有被抽走，反而变得更加值钱。因为AI能帮你写出代码，但它不知道你为什么要写这段代码，不知道这个接口是给哪个业务场景用的，更不知道如果流量涨十倍应该怎么调整。这些内容，就是AI编排工程师的新战场。
1.2 从“动手写”到“动脑编排”
我自己经历过一个很典型的变化。早几年带项目，最怕的是开发资源不够，一个功能排期要很久。现在最怕的反而是需求不够清晰，因为只要需求文档写得足够细，AI可以在一小时之内把原型代码全部生成，但需求里的逻辑漏洞、边界情况、异常分支，AI是看不出来的，它只会忠实于你写的描述。
所以现在的开发工作，更像是在做“编排”：你要决定让AI做什么、不做什么；你要定义哪些模块可以自动生成，哪些必须人工手写；你还要设计一套验证流程，确保AI输出的东西符合预期。这已经不再是纯粹的编码工作，而是把工程化思维、领域知识和AI能力组合到一起的调配工作。
提醒一下：如果现在还抱着“AI写代码，我来复制粘贴”的心态，那本质上还是在做码农的活，只是在码农前面加了个“AI辅助”的定语。真正稀缺的是那个“编排者”。
2. AI编排工程师到底在做什么
2.1 把模糊需求变成可验证的规格
传统开发流程里，需求分析师把需求写好，开发照着实现，测试照着验。AI编排工程师的工作在这里面插了一脚：他们需要把“用户想要什么”变成“AI可以执行什么”。
这听起来像是把需求文档写得更细，但完全不是一回事。需求文档描述的是业务规则，而给AI的规格描述的是“输入是什么、输出是什么、在什么条件下做什么事、出错时怎么办”。这两者的思维方式差异非常大。
我自己总结了一个给AI写任务描述的模板，大致长这样：
任务背景：一句话说明这个模块在系统里的位置 输入：数据结构、字段说明、是否可能缺失 输出：期望的格式、命名规则、边界条件 约束：性能要求、不允许使用哪些库、安全限制 验收标准：怎样才算完成，用什么样例验证这个模板看起来平平无奇，但实际操作时，大部分人根本写不全。少了“约束”和“验收标准”这两项，AI就会放飞自我，给你生成一个看着能用、用起来全是坑的版本。
2.2 把大任务拆成AI能处理的块
这个能力是决定编程效率的关键分水岭。让AI直接生成一个完整系统，它基本做不到，上下文窗口会被撑爆，生成完之后代码也没法维护。但如果把系统拆成十几个小任务，每个任务都能独立生成、独立验证，再通过接口把它们拼起来，效果就完全不同。
拆解的颗粒度我一般这么把握：一个AI任务生成的代码量，控制在几百行以内，必须只做一件事，并且能用一个测试用例去验证它的正确性。如果生成的东西需要多个模块配合才能测，说明任务拆大了。
举个例子，做一个数据导出功能，我不会让AI“写一个导出模块”，而是拆成“从数据库读取指定时间段订单数据，返回内存中的列表”“将列表转换为指定格式的报表结构”“生成导出文件并处理超大文件流”等几个独立任务。每个任务单独生成、单独测，最后再串起来。
2.3 维护上下文仓库
这一点是普通开发者和AI编排工程师差距最大的地方。传统开发靠代码注释和文档来传递上下文，AI编排靠的是一个持续维护的“上下文仓库”。
这个仓库里存的是什么东西？包括项目整体架构的描述、技术选型的理由、常用的代码模式、容易踩的坑、团队统一的接口风格。每次让AI干活之前，先把仓库里的相关内容拿出来，作为背景信息喂给它。做完一个任务之后，再把新发现的坑、新确认的规范回填进去。
我见过太多人让AI干活的时候从零开始描述项目背景，每次都要重复一遍“我们这个系统是微服务架构，用的是某某语言，数据库是某某”。结果AI每次都像第一次见面一样，给出一些不贴合项目实际的建议。上下文仓库就是用来解决这个问题的，它就是AI版的“团队Wiki”，只是比人类用的Wiki更结构化和可复用。
2.4 构建质量反馈闭环
AI生成代码从来不是一次性交付，它是一个需要来回迭代的过程。但很多人被“生成速度很快”给误导了，以为生成的代码就是可用的。实际上，AI生成的代码就像一个新入职的应届生写的代码：看着逻辑完整，但边界情况、异常处理、内存管理这些地方，往往需要老手去发现问题。
所以AI编排工程师一定会给这个闭环加上自动化验证环节。单元测试只是最基础的，还需要加上代码扫描、性能基线对比、契约测试。AI改了代码之后，自动跑一遍全量测试，如果有回归，马上把失败信息喂回给AI，让它自己修正。
这里的核心思路是：反馈越具体，AI的修改越准确。我遇到过实测下来，光是改成“测试用例A在输入为null时报错，期望返回自定义异常信息”这种描述，AI的修复成功率就能翻一倍。不能只写“这个模块有问题”，要写清楚哪里有问题、期望什么行为。
3. 从码农到AI编排工程师：能力模型的变化
3.1 表达与约束设计能力
以前写代码，语法不对编译器会告诉你，类型不对IDE会标红，程序员的表达压力很小，因为工具会兜底。在AI编排的场景里，没有这个兜底。你描述得含糊，AI就给你含糊的代码，而代码的含糊往往不是报错，而是行为异常。
所以AI编排工程师要有一种“把话说明白”的能力。不仅要说明白，还要把约束也给全。举个例子，跟人说“把这个列表按时间排序”，人可能会问按升序还是降序，时间字段是哪那个，空值怎么处理。跟AI写任务描述，这些问题必须一次性说清楚，否则它默认给你按升序排，空值排在最后，很可能不是你要的。
这不是语法能力，这是逻辑表达和需求挖掘能力。我发现很多从测试转过来做AI编排的同学反而上手快，因为测试思维天然就在关注边界条件和异常分支。
3.2 系统性思维与架构判断力
当AI把开发效率提上来之后，系统瓶颈往往提前暴露。以前写一个接口，两个星期，你有足够的时间慢慢思考表结构怎么设计。现在AI几分钟生成一个接口，你的决策速度必须跟上，否则AI生成代码的速度反而会放大错误。
AI编排工程师需要具备一定的架构判断力，知道系统瓶颈在哪，知道哪些模块应该紧密耦合，哪些必须解耦。尤其重要的是，要知道哪些代码不能交给AI。核心交易链路、涉及安全权限的代码、跨系统交互的接口，这些地方手工写代码更可控，AI只适合做参考和生成骨架。
说白了，AI编排不是把决策权交给AI，而是把执行权交给AI，决策权还在人手里。系统性思维就是让你在快速执行的时候还能看得清全局。
3.3 测试思维与质量风控能力
现在的AI编码工具都非常强，但越强的工具越需要一个更严格的裁判。AI编排工程师首先要是一个苛刻的验收者，而不是一个宽松的接收者。
在实际项目中，我会给AI生成的代码定一个最低门槛：本地能编译通过，关键路径有测试用例，代码扫描的严重问题为零，复杂度过高的情况必须给出重构图。达不到门槛就直接打回，附上具体的修改建议。
这种“返回修改”的循环看起来低效，但实际反而是效率最高的。因为如果反复使用质量不合格的AI代码，返工成本会指数级上升。一次打回的成本很低，真正贵的是让一个不合格的模块被集成到系统里之后，后续模块在它上面继续生长，最后变成拆不掉的烂代码。
3.4 工具链整合与流程设计能力
AI编排工程师的另一个隐藏技能，是把不同的AI工具和传统开发工具串成一条流水线。比如用AI做代码生成，用静态扫描工具做第一轮检查，用自动化测试跑回归，用文档工具生成变更记录。每一环都有专门的工具，编排者的工作就是让它们顺畅地合作。
这块的工作量和传统印象里的软件开发已经很不一样了。传统开发是“人在流程里”，AI编排是“流程围着AI转”。设计流程的时候要考虑的，不再是“哪个步骤最耗时”，而是“哪个环节最容易被AI的错乱输出打断”。质量门禁放在哪个位置、上下文如何流转、失败如何反馈，这些都是需要专门设计的。
我见过有的团队，把AI编码接进了流水线，但是质量门禁还是按照人工开发的节奏设的，结果AI提交的速度远快于人工审核的速度，审核成了瓶颈，团队整体产能反而下降了。这就是流程设计与工具能力不匹配的典型问题。
4. 实操：一个需求从想法到上线的AI编排流程
4.1 需求澄清与任务设计
我拿最近做的一个内部对账工具举例。需求背景是一个跨平台系统，订单数据分散在多个数据源里，财务每月要手工核对一遍，费时费力。这个需求如果放在以前，流程是“排期->开发->测试->上线”，至少三周。这次我用AI编排的方式来做，两天完成首版上线。
第一步是需求澄清。我把整个项目拆成了任务卡片，每个卡片都包含完整的背景、输入、输出和验收标准。第一个任务卡片是“读取三个数据源中的订单记录，统一字段命名”，第二个是“按订单号和时间窗口对账，找出缺失记录”，第三个是“生成对账结果报表，标记差异原因”。一共拆了7个任务，每个任务都控制在单次AI生成能搞定的范围内。
4.2 AI生成与人工审核的配速
任务卡片准备好之后，我不会一次性丢给AI让它全做，而是一个一个来。每生成一个模块，先自己过一遍代码，确认逻辑和任务卡片一致，再跑一次针对性的测试，通过了才进入下一个模块。
这样做的好处是错误被限制在单个模块内，修正成本很低。如果我一次性丢七个任务给AI，一旦架构思路在第二个模块就出了问题，后面五个全部白做，反而更慢。
这种“卡点式审核”有个体验上的变化值得提一下：我不再是坐在屏幕前一口气写一天代码，而是分散到不同时间段，每次审完一块代码就去做别的。整体跑下来，真正的“工作时间”其实只有几个小时，剩下的时间是在等AI生成、调整任务描述、补充测试用例。
4.3 联调验证与知识回填
所有模块都生成完之后，联调阶段还是会出一些问题。比如对账规则在边界时间上有偏差，跨时区订单的时间窗口算错了。这些问题AI单独看每个模块时发现不了，只有把它们串起来跑通真实数据才会暴露。
联调发现的每个问题，我都会记录一条对应的修复指令，然后再让AI修改。等所有问题都闭环之后，我会把这些边界情况的描述回填到项目的上下文仓库里，下次再做类似的对账功能，AI就能直接避开这些坑。
这里有一个非常实用的经验：每次项目结束后，花半小时把本次踩过的坑、确认过的规则、写过的复杂逻辑整理成结构化文档，回填到上下文仓库里。这个习惯坚持下来，AI工具在你手里的价值会随着时间增长，而不是每次都从零开始。这是AI编排和普通使用AI之间最核心的差别。
5. 转型路上的常见坑，以及我的真实体会
5.1 提示词越长，效果不一定越好
很多人在尝试AI编码的时候，把任务描述越写越长，觉得描述越详细AI就越听话。实际测试下来，超过一定长度之后，AI会开始“忘记”前面的指令，或者把注意力放在后边补充的内容上，反而容易跑偏。
我的经验是，一段任务描述的重点最好不要超过五个，关键约束放在最前面，长文档链接放在最后面。描述的核心是让AI抓住主要约束，而不是把每一个可能的边界情况都堆进去。边界情况更适合放在验收标准里，用测试案例来表达。
5.2 完全放手和完全不放，都是歧途
我见过两种极端。一种是完全信任AI，生成什么用什么，出了问题再改；另一种是完全不信任AI，每段代码都要手改一遍，AI的存在只是起了个输入法的作用。
这两种方式都降低了AI编排的意义。我的做法是：根据风险级别来决定信任程度。低风险的模板代码，比如模型映射、DTO转换、配置文件，AI生成后直接过；中等风险的业务逻辑，生成后需要仔细读一遍核心路径；高风险的核心模块，AI只用来生成草稿和测试用例，最终代码自己写。
5.3 领域知识比提示词技巧更值钱
这个公众号后台经常有人私信我问“有没有推荐的提示词模板”。我现在的统一回复是：模板容易学到，但真正让你值钱的是你脑子里的领域知识。你知道财务对账的规则，知道电商订单拆单的原则，知道物联网设备上报数据的特征，这些才是AI编排时最核心的输入。
同样一个AI，在一个懂供应链的人手里，能编排出一个供应链预警工具；在一个只懂提示词技巧的人手里，最多只能生成一些通用代码。技术工具是公平的，不公平的是你脑子里装了多少东西。
5.4 写在最后的一些心里话
踩了几次坑之后，我的体会是：AI编排工程师这个名字听起来很高大上，本质上就是一群更会“提问题、定标准、验结果”的人。代码能力当然还是需要的，但它的角色从“产出工具”变成了“评审工具”。你得能看懂AI生成的代码好不好，才知道让它往哪个方向改。
如果你现在正在做纯编码的工作，我的建议不是去焦虑自己的工作会不会消失，而是开始有意识地训练自己从“写代码的人”变成“设计工作流、定义验收标准、审查产出质量的人”。从你自己每天重复最多的那个编码任务开始，试着把它拆成几个独立模块，写成任务卡片，用AI去执行，然后用你的专业能力去把关。这个过程是最小的AI编排实践，也是这个新角色最真实的起点。
》习题答案？从解题思路到编程实战)
