Dify 创始人万字雄文:AI 时代,软件工程的瓶颈已经从＂能不能做＂变成了＂能不能＂

原文链接：https://dify.ai/blog/software-engineering-divide-and-converge作者：Luyu Zhang译者：倔强青铜三

前言

大家好，我是倔强青铜三。欢迎关注我，微信公众号：倔强青铜三。欢迎点赞、收藏、关注，一键三连！！！

时代 01 — 1990 年代：早期互联网

一个人包揽一切的时代

在互联网早期，一个人通常就能构建一整个网站。他们定义产品该做什么，编写前端页面，编码后端逻辑，部署到服务器上，并自己修复所有问题。

这并不是因为早期工程师格外全能，而是因为问题足够简单。一个静态页面加上几个服务端脚本，完全在一个人的认知能力范围之内。

那个时代有一套叫做”网页三剑客”的工具——Dreamweaver 用来建页面，Flash 用来做动画和交互，Fireworks 用来处理图片。这套工具的意义在于：它将 Web 开发的所有复杂性打包成一个产品套件，让一个人从视觉设计到网站上线，不需要精通任何单一领域就能完成。

这种状态带来了一个重要的副产品：反馈闭环是闭合的。我写代码，我管服务器，用户出了问题我第一个知道，修复的人也是我。就像厨师在上菜之前会先品尝自己的作品。

时代 02 — 2000 年代：专业化

复杂度突破天花板，分工出现

到 1990 年代中期，Web 开始商业化，问题的规模发生了变化。电商和门户网站涌现，系统需要处理真正的并发、真正的数据、真正的安全威胁。一个人的认知天花板被打破了，分工成为必需。

“网页三剑客”随着这种转变消失了——不是被同类更好的工具取代，而是因为它所服务的”一个人包揽一切”的工作方式已经不再可行。取而代之的是每个领域更深、更专业的工具链：前端的 Webpack 和 React，设计的 Figma，后端的自研框架和中间件。工具变得专业化了，人也是。

这种专业化提高了系统所能达到的天花板，使更大规模的软件成为可能。但它也切断了一些东西。

许多工程师在一家公司工作了一整个职业生涯，却从未触碰过生产服务器。代码提交之后发生的事情对他们来说是一个黑盒。厨师永远尝不到自己的菜。

时代 03 — 2009 年：DevOps 运动

DevOps：重建亲手操作的感觉

大约 2009 年，DevOps 理念开始成型。它的技术组件广为人知：持续集成、持续部署、基础设施即代码、自动化监控和告警。但这些都是达到更深层次目的的手段——重建那个被切断的反馈闭环。让写代码的人再次感受到代码在真实环境中的表现，并再次对其在生产中的行为负责。

亚马逊内部有一句名言：”You build it, you run it。”（你构建它，你运行它。）这句话说的不是技术，而是谁应该拥有责任感和亲手操作的感觉。

云服务的成熟是 DevOps 成功的技术前提。一旦 AWS 抽象化了基础设施，运维的门槛大幅降低。开发者不再需要成为运维专家，就能通过自动化感知生产环境。反馈闭环再次成为可能。

时代 04 — 2020 年代：AI 时代

新的分工方式：AI 时代的流水线

如今，AI 辅助编程正在引发新一轮变革。代码生成、自动化测试、智能代码审查——大量曾经需要人工处理的任务正在被工具接管。一个独立开发者可以构建十年前需要五人团队才能完成的产品。

但这带来了一个比 DevOps 所解决的问题更深的新问题。DevOps 解决的是工程师无法感知生产环境的问题。AI 时代面临的问题是：当整个生产流水线高度自动化时，如何确保流水线本身的设计是正确的？

设计一条流水线和在流水线上工作是两件完全不同的事。

产品体验 · UI/UX — 设计进入流水线

设计不再游离于流水线之外

过去，UI/UX 设计是一个独立的、高度依赖人工判断的过程。设计师产出设计稿，工程师尝试像素级还原，而他们之间存在大量的来回沟通和信息损耗。设计是流水线中的一个断点，而不是一个节点。

如今，LLM 正在改变这项工作的成本结构。设计决策的生产可以大幅加速：针对一个问题，让 LLM 同时生成三到五个甚至更多候选方案。人的角色从”从零创造”转变为”从候选方案中判断和选择”。这是一种根本不同的工作模式——判断的成本远低于创造的成本。

一旦做出选择，组件级原型可以直接集成到整体产品原型中，甚至直接进入前端工程环节。设计决策不再被困在设计稿文件中——它们成为代码库的一部分。

更重要的是，这个过程中产生的所有上下文——为什么选择了方案 B 而非方案 A，哪些交互模式被否决了，哪些视觉判断背后有产品逻辑支撑——这些决策记录本身就是产物（Artifacts）。它们是下游代码生产、测试设计和下一轮迭代的宝贵输入信号。上下文绝不能丢失；丢失就会造成信息断层。

设计流水线的理想状态不是 AI 取代设计判断，而是让人工判断集中在最有价值的地方：在多种可能性中，选择最接近产品真相的那一个。

这种模式有一个重要启示：人在设计过程中的角色从生产者转变为编辑者。判断力、品味、对产品方向的理解——这些能力变得比”会用设计工具”更有价值。这又回到了关于系统负责人的论点：只有真正理解产品价值主张的人，才能从五个候选方案中选出正确的那一个。

目前，这个阶段人工干预的成本仍然较高，流程优化空间很大。但方向是明确的：随着 LLM 对产品上下文的理解能力提升，候选方案的质量会提高，需要人工干预的节点会减少，整个设计流水线将逐步走向自动化。

双钻模型

从源头定义问题，再进入自动化

在自动化流水线全速运转之前，有一个更根本的问题需要解决：你解决的是真正正确的问题吗？

双钻模型（Double Diamond）提供了一个在进入生产之前反复校准问题定义的结构。它由两个”钻石”组成，每个都是先发散后收敛的循环。第一个钻石确认问题本身——发散探索所有可能的问题方向，然后收敛到一个清晰的问题定义。第二个钻石确认解决方案——在多条候选路径上发散，然后收敛到一个可执行的决策。

这个过程可以循环多次。每次循环都利用新增信息来细化对问题的理解，直到收敛到一组真正经过验证的关键决策。

这些决策随后被写入 AGENTS.MD——工程流水线中 LLM Agent 的行为约束文件。它不是需求文档，而是一份约束清单和唯一真相源：后续所有生产阶段的 LLM 都在这些边界内运行，既不越界，也不需要重新推断。双钻模型的收敛输出成为整个流水线的宪法。

AGENTS.MD 是双钻过程的沉淀物。它将人类判断的结果转化为机器可执行的约束，使自动化不再在黑暗中运行。

AGENTS.MD 中包含什么 — 双钻收敛的输出，LLM 的行为宪法

产物与质量 — 双轨生产结构

每个产物都有对应的质量检查

在 AI 时代的工程流水线中，生产产物逐层推进——从顶层价值主张，一路向下经过用户场景、业务规则、领域模型、API 契约、集成边界，直到系统整体和非功能需求。这个过程不是单向瀑布流，而是双向的：任何层的发现都可以向上反馈。

同时，每一层产物自然对应一种测试。这不是事后的质量检查，而是产物本身的镜像——产物定义什么，测试就验证什么。整个结构形成了一个持续的、迭代的闭环。

每种测试类型的反馈特性 — 按反馈速度排序

控制论 · 驾驭工程

为什么控制论是你今天必须掌握的学科

控制论（Cybernetics）由诺伯特·维纳（Norbert Wiener）于 1948 年提出，研究系统如何通过反馈维持目标状态。其核心模型简洁优雅：设定参考值，用传感器感知实际状态，比较两者以检测偏差，由执行器执行纠正动作，然后重复。

这个理论在今天之所以重要，不是因为它是新的，而是因为 LLM 是第一个让”执行器”变得足够智能的技术——它不再只执行固定规则，而是能理解上下文、评估偏差性质并选择纠正策略。一个曾经需要人工干预的决策节点，现在可以由 LLM 自主处理。

这就是驾驭工程（Harness Engineering）的本质：将从需求到部署的整个工程流水线设计为一个闭环控制系统。测试是传感器，LLM 是调节器，CI/CD 是执行器，产品价值主张是设定值。任何偏差——测试失败、类型错误、契约不匹配——都不需要等人发现；系统自行感知、纠正、推进。

这条流水线的终极形态是无人值守运行（lights-out operation）：LLM 连续工作数小时甚至更久，在无人干预的状态下完成从代码生成到测试验证再到自动修复的完整循环。你睡觉的时候，流水线照常运转。

不理解控制论，你只能设计出需要持续人工监督的半自动化流程。掌握控制论，你能设计一个自我纠错的系统。

控制论概念映射到工程流水线

底层逻辑

一个循环，但不是回到原点

早期”一个人包揽一切”之所以可行，是因为问题足够简单。DevOps 时代的收敛通过自动化重建了开发者对生产环境的感知。AI 时代的收敛则是由足够强大的工具驱动的，让一个人再次能够掌控更大的系统。

形式看起来相似，但机制完全不同。

只有一件事是真正不变的：在每一层新复杂度到来时，必须有人能同时看到全貌和细节，并设计出下一条流水线。 这样的人在每个时代都是稀缺的。

深层结构

先当厨师，再设计厨房

麦当劳的后厨是工业化的杰作——每一道工序、每一个工作站的位置都经过精密设计，使得任何受过最低培训的员工都能稳定产出标准化产品。

但设计那个后厨的人，必须首先是一个真正知道怎么做汉堡的人。如果你从来没有做过汉堡，你就不知道哪一步最容易出错，质量检查点应该放在哪里，番茄和生菜的顺序会如何影响结果。你设计的后厨会在你预见不到的地方出问题。

今天的软件工程也是如此。AI 时代的工程师需要两种能力：基于控制论的全局视野，以及对每个生产阶段的真正亲手感觉。 没有前者，你只是一个无法优化系统的熟练工人；没有后者，你设计的流水线就是空中楼阁。

软件工程的早期阶段是知识生产过程，而不是知识执行过程。PRD 不能在开始时就冻结。交互设计过程中会发现需要决策的新业务逻辑，这些发现必须反馈到 PRD 中。工程过程会揭示没有人考虑过的权限问题，需要反馈到原型设计甚至更早的阶段。

关键不在于哪个文档是唯一真相源，而在于：在任何给定的时间点，团队中的每个人都清楚地知道某个问题的当前答案在哪里，以及那个答案目前的稳定程度如何。

结语

这不是理想主义——这是最低要求

软件工程从”一个人包揽一切”走向深度专业化，又通过 DevOps 重建亲手操作的感觉。如今，AI 再次拓展了一个人所能掌控的边界。但这并没有让事情变简单——它提高了门槛。因为当工具足够强大时，瓶颈就从”你能不能做”转移到了”你能不能设计”。

我认为任何认真对待产品的团队都需要一个人能纵览全局，同时确保四件事：产出的质量、生产流程的严谨性、需求的定义、以及整个自动化流水线的设计。这四项责任不能分摊给四个人，因为它们之间的信息流是双向且高频的——拆开之后，连接会在你看不见的地方断裂。

这个人需要有品味，以及深厚的、来之不易的工程经验。他们必须首先是一个真正知道怎么做汉堡的人，然后才有资格设计后厨的流程。

然而我们必须承认一个现实：这类人的稀缺不是偶然的——它是结构性的。整个行业的职级体系、招聘标准和薪酬带宽都是围绕专业化深度设计的。”高级前端工程师”有清晰的职业路径和市场定价；”能看全局的人”在就业市场上没有对应的分类。更根本的是，品味是通过闭合的反馈闭环培养的，而专业化恰恰切断了这些闭环——在一个高度专业化的组织中，人们很少看到自己决策的下游后果。厨师永远尝不到自己的菜，所以他永远不会成为一个好厨师。专业化不仅剥夺了产品的亲手感觉——它还剥夺了人们培养品味的机会。

此外，稳定期不需要这种人，所以也不会培养他们。一旦流水线平稳运转，组织最需要的是各个岗位的可靠操作员。对”全局设计师”的需求只在范式转换期才会浮现——比如现在。但之前的稳定期恰恰是专业化程度最高、工业化最彻底的时期，系统地未能培养这类人才。需求出现的那一刻，恰好是供给最匮乏的时候。

当理想候选人不可得时，团队必须尽可能接近这个状态。其他角色可以以辅助身份参与流水线设计，但核心必须有一个牵头人。原因是具体的：在工程流水线真正稳定之前，代码库可能在一个月内经历多次破坏性重写。在这个过程中，所有上下文必须存在于一个人的脑中。否则，每次更新都会在交接缝隙中制造新的断点。

这不是理想主义的要求。这是在当今技术格局下让工程努力真正有效的最低条件。

欢迎关注我的微信公众号：倔强青铜三，获取更多 AI 自动化和开发技巧分享！