# 架构师已死

> 龙虾AGI通用实验室 · 2026-05-14

程序员圈子有一条隐形的鄙视链。写后端的看不上写前端的，写前端的看不上做测试的，而站在鄙视链顶端的，是架构师。

架构师是那种不怎么写代码，但决定整个系统长什么样的人。他画蓝图，定技术栈，拆模块，规划数据怎么流转、服务之间怎么通信。在很多公司，架构师年薪百万，被视为技术团队的灵魂人物。

AI取代写代码的程序员，大家勉强能接受。但架构师呢？这种需要全局视野、系统思维、多年经验才能胜任的角色，应该是最后的堡垒吧？

不是。这个堡垒也在坍塌。

## OpenAI做了一个实验

今年早些时候，OpenAI公开了一个内部项目的细节。他们的团队用AI构建了一个完整的软件产品——不是Demo，是有真实用户在用的产品。这个产品有上百万行代码，涵盖应用逻辑、测试、CI配置、文档、监控，全部由AI生成。

人类工程师一行代码都没写。

但他们也不是闲着的。他们做的事情，用OpenAI自己的话说，是"设计环境、明确意图、构建反馈循环"。翻译成大白话就是：告诉AI要做什么，给AI足够的上下文，然后检查AI做得对不对。

![](images/2d98f7/img_001.png)

这个工作模式有一个越来越被认可的名字，叫Harness Engineering。字面意思是"驾驭工程"——你不是在写代码，也不是在做架构，你是在驾驭AI，让它替你把活干了。

## 架构是怎么"涌现"出来的

传统的开发流程是这样的：甲方提需求 → 架构师设计方案 → 程序员写代码。三层。架构师是中间那层，把模糊的需求翻译成精确的技术蓝图。

但在Harness Engineering的模式下，这个流程被压缩成了两层：人提需求和约束 → AI同时扮演架构师和程序员。

而且架构产生的方式也变了。传统架构师是坐在那里冥思苦想，脑子里建模，然后画出一张完整的蓝图。这需要一种极其稀缺的认知能力——在脑子里同时容纳整个系统的复杂度。

Harness的方式不是这样。你先说一个大概的意图，AI给你一个初步方案。你觉得这里不对，调整一下方向，AI再迭代一版。几轮对话下来，架构自然就涌现出来了。你不需要一次性想清楚所有事情，你只需要在每一轮对话中做出判断——这个方向对不对？这个取舍要不要？

架构不再是一个天才的独立创作，而是人和AI对话中逐步长出来的东西。

## 你真正在做的事情，是当甲方

想明白这件事之后，我发现了一个很精准的类比：Harness Engineer本质上就是AI的甲方。

传统的甲乙方关系大家都懂。甲方提需求，乙方负责执行。甲方不需要会画施工图，不需要懂钢筋怎么绑扎，但甲方需要知道自己要一栋什么样的楼、几层、什么用途、预算多少。

好甲方和差甲方的区别是巨大的。

差甲方说"我要一个大气的App"，然后每次看到效果都摇头："不对不对，我说的大气不是这种大气。"改了二十版还不满意，因为他自己也说不清楚想要什么。

好甲方会说："目标用户是25-35岁的上班族，核心场景是通勤路上快速下单，首页加载时间不能超过2秒，配色参考这三个竞品但更偏冷色调。"同样一个乙方团队，遇到好甲方的时候效率能翻十倍。

跟AI协作完全一样。你给AI的约束越清晰、越具体、越有边界感，AI的产出质量就越高。这不是写代码的能力，这是一种"精确描述意图"的能力。

## 但"好甲方"是一种被严重低估的能力

很多人觉得当甲方很简单，不就是提需求吗？谁不会说"我想要一个某某功能"？

问题在于，真正好的需求描述是极其困难的。

你说"我要一个聊天功能"。好，那群聊要不要？文件传输要不要？消息撤回要不要？已读未读要不要？聊天记录搜索要不要？离线消息怎么处理？敏感词过滤要不要做？做到什么程度？

每一个"要不要"背后都是一个判断，每一个判断都会影响产品的方向和复杂度。大部分人脑子里有一个模糊的画面，但把这个画面拆解成具体的、无歧义的约束条件，这件事本身就需要训练。

这就是为什么Harness Engineering正在变成一个严肃的专业方向。它不是随便聊几句让AI干活。它是一整套方法论——怎么组织上下文、怎么定义约束规则、怎么建立反馈循环、怎么在AI产出偏离的时候把它拉回来。

Red Hat的工程师有一句总结说得很好：当你不再把AI当魔法盒子，而是当成一个结构化环境中的组件来对待的时候，结果就变得可预测和可复现了。

## 架构师不会消失，但会换一种方式存在

说"架构师的末日"其实不完全准确。更准确地说，是"架构师"这个独立的岗位和头衔会逐渐消失，但架构思维会融入到Harness的设计过程中。

你在跟AI对话、拆解需求、定义模块边界的时候，其实就是在做架构。只不过你不需要画UML图，不需要懂什么微服务网关怎么配置，不需要在脑子里同时装下整个系统的复杂度。

AI扛走了认知负担，你只需要保留判断力。

这有点像导演和剧组的关系。导演不需要会演戏、会打灯光、会剪辑、会做特效。但导演需要知道"这个镜头对不对味"，需要能引导整个团队走向他脑子里那个还没完全成形的画面。

未来的软件开发者，就是AI剧组的导演。或者用一个更直白的说法——AI的好甲方。

## 所以，怎么成为一个好甲方？

这个问题没有标准答案，但有一个方向是确定的：大量跟AI协作。

就像学游泳不能靠看书，学当好甲方也不能靠学理论。你得在真实的项目里反复跟AI过招——提需求，看产出，发现偏差，调整约束，再看产出。几十轮下来，你会慢慢形成一种直觉：什么样的描述AI能理解，什么样的约束能产生好结果，什么时候该放手让AI发挥，什么时候该强力介入。

这种直觉，就是未来最值钱的能力。

不是写代码，不是画架构图，而是知道怎么跟AI说话，让它替你把整个世界造出来。

我建了一个AI学习群，目前几十来人，都是在真正动手学AI的人。如果你也在自己跑模型、写代码、做项目，欢迎加我微信，备注"你在做的AI方向"，我拉你进群。纯围观的就不加了，群里大家都在真搞。

![](images/2d98f7/img_002.jpg)