夜雨聆风本文翻译自Dify的创始人兼CEO张路宇近期发表的一篇文章《Software Engineering: Divide and Converge》。
文章回顾了软件工程从早期"一人包办到专业化分工，经DevOps重建反馈闭环，到AI时代再次扩展个人边界”的完整过程，并提出了在AI时代软件工程要从”控制论视角设计自动化流水线，让系统自我纠正、自主运行“的主张。
涛哥认为观点独到，非常适合广大从业者参考和学习，不敢私藏特分享给大家。
时代 01 — 1990 年代早期互联网
在互联网早期，通常一个人就能搭建整个网站。他们定义产品该做什么，编写前端页面，编写后端逻辑，部署到服务器，出了问题自己修。
这并非因为早期工程师格外全能，而是因为问题足够简单。一个静态页面加上几段服务端脚本，完全在一个人认知能力所及范围之内。
那个时代有一套工具集叫"网页三剑客"——Dreamweaver 做页面、Flash 做动画与交互、Fireworks 做图像编辑。这套工具集的意义在于，它将 Web 开发的所有复杂度打包进一个产品套件，让一个人无需专精任何单一学科，就能把一个网站从视觉设计做到上线。
到 1990 年代中期，Web 开始商业化，问题的规模发生了变化。电商和门户网站涌现，系统需要处理真实的并发、真实的数据、真实的安全威胁。一个人的认知天花板被突破，分工势在必行。
网页三剑客随着这一转变一起消失——不是被更好的同类工具取代，而是因为它所服务的"一人包办"的工作方式不再可行。取而代之的是每个学科更深、更专业的工具链：前端用 Webpack 和 React，设计用 Figma，后端用定制框架和中间件。工具变得专业化，人也是如此。
这种专业化抬高了系统所能触及的天花板，让更大规模的软件成为可能。但它也割裂了某些东西。
大约在 2009 年，DevOps 理念开始成型。它的技术组成部分众所周知：持续集成、持续部署、基础设施即代码、自动化监控与告警。但这些都只是手段，服务于一个更深的目的——重建那个曾被割裂的反馈回路。让写代码的人再次感受到代码在真实环境中的行为，再次为它在生产环境中的表现负责。
亚马逊内部有一句名言："你构建的，你运行它。"这不是一句关于技术的话，而是关于谁应该拥有责任感与手感。
云服务的成熟是 DevOps 得以成功的技术前提。一旦 AWS 将基础设施抽象化，运维的门槛大幅下降。开发者不再需要成为运维专家，就能通过自动化感知生产环境。反馈回路再次成为可能。
今天，AI 辅助编程正在触发新一轮变革。代码生成、自动化测试、智能代码审查——大量曾经需要人力完成的任务，现在由工具处理。一个独立开发者能做出的产品，十年前需要一个五人团队。
但这带来了一个比 DevOps 所面对的更深层次的新问题。DevOps 解决的是工程师无法感知生产环境的问题。AI 时代面临的是另一个问题：当整个生产流水线高度自动化时，你如何确保流水线本身的设计是正确的？
设计流水线与在流水线上工作，是两件截然不同的事。
过去，UI/UX 设计是一个独立的、高度依赖人类判断的过程。设计师产出原型图，工程师尝试像素级还原，两者之间是大量反复沟通与信息损耗。设计是流水线上的断点，而非节点。
今天，大语言模型正在改变这项工作的成本结构。设计决策的生产可以被大幅加速：针对单一问题，让大语言模型同时生成三到五个乃至更多候选方案。人的角色从"从零创造"转变为"从候选方案中评判与选择"。这是一种截然不同的工作模式——判断的成本远低于创造的成本。
一旦选定，组件级原型可以直接接入整体产品原型，甚至直接投喂给前端工程。设计决策不再被困在原型图文件里——它们成为代码库的一部分。
更重要的是，这个过程中产生的所有上下文——为什么选择了方案 B 而非方案 A，哪些交互模式被否决了，哪些视觉判断背后有产品逻辑——这些决策记录本身就是产物。它们对于下游的代码生产、测试设计以及下一轮迭代，都是宝贵的输入信号。上下文不能丢失；丢失它就会产生信息鸿沟。
这种模式有一个重要启示：人在设计过程中的角色从生产者转变为编辑。判断力、品味、对产品方向的理解——这些能力变得比"会使用设计工具"更有价值。而这又回到了关于系统拥有者的核心论点：只有真正理解产品价值主张的人，才能从五个候选方案中挑出正确的那一个。
目前，人在这一阶段介入的成本仍然很高，流程优化的空间巨大。但方向是明确的：随着大语言模型对产品上下文理解的加深，候选方案的质量会提升，需要人工介入的节点会减少，整个设计流水线将逐步收敛于自动化。
在自动化流水线全速运转之前，有一个更根本的问题需要回答：你是否在解决真正正确的问题？
双钻模型提供了一种结构，让你在进入生产之前反复校准问题定义。它由两个"钻石"组成，每一个都是先发散再收敛的循环。第一个钻石确认问题本身——发散以探索所有可能的问题方向，再收敛到一个清晰的问题定义。第二个钻石确认解决方案——发散到多条候选路径，再收敛到一个可执行的决策。
这个过程可以循环多次。每一轮循环都利用额外信息来精炼对问题的理解，直到收敛为一组经过真正验证的关键决策。
这些决策随后被写入 AGENTS.MD——工程流水线中大语言模型智能体的行为约束文件。它不是需求文档，而是一份约束清单与唯一真相源：大语言模型在后续所有生产阶段都在这些边界内运作，绝不越界，也无需重新推断它们。双钻模型的收敛产出，成为整条流水线的宪法。
AGENTS.MD 的内容—— 双钻收敛的输出——大语言模型的行为宪法
产物与质量——双轨生产结构
在 AI 时代的工程流水线中，生产产物层层递进——从顶层的价值主张，一路向下穿透用户场景、业务规则、领域模型、API 契约、集成边界，直到系统整体与非功能性需求。这个过程不是单向瀑布，而是双向的：任何一层的发现都可以向上反馈。
同时，每一层产物天然对应一类测试。这不是事后追加的质量检查，而是产物本身的镜像——产物定义了什么，测试就验证什么。整个结构形成一个连续、迭代、闭环的系统。
各测试类型的反馈特征 —— 按反馈速度排序
控制论由诺伯特·维纳于 1948 年提出，研究系统如何通过反馈维持目标状态。其核心模型优雅而简洁：设定一个参考值，用传感器感知实际状态，比较两者以检测偏差，让执行器执行纠正动作，如此往复。
这个理论之所以在今天重要，不是因为它新颖，而是因为大语言模型是第一种让"执行器"足够智能的技术——它不再只执行固定规则，而是能够理解上下文、评估偏差的性质，并选择纠正策略。曾经需要人类介入的决策节点，现在可以由大语言模型自主处理。
这就是 Harness 工程的本质：将整个工程流水线从需求到部署设计为一个闭环控制系统。测试是传感器，大语言模型是调节器，CI/CD 是执行器，产品价值主张是设定值。任何偏差——一次失败的测试、一个类型错误、一个契约不匹配——都不需要等待人类发现；系统自行感知、纠正、推进。
这条流水线的终极形态是熄灯运营：大语言模型连续工作数小时甚至更久，在无人值守状态下完成从代码生成到测试验证再到自动修复的完整循环。当你入睡时，流水线仍在运转。
控制论概念映射到工程流水线
早期的"一人包办"之所以可行，是因为问题足够简单。DevOps 时代的"合"通过自动化重建了开发者对生产环境的感知。AI 时代的"合"则由足够强大的工具驱动，让一个人再次能够 oversight 并控制更大的系统。
形式看起来相似，但机制完全不同。
麦当劳的厨房是工业化的杰作——每一个工作流程、每一个工位站位都被精确设计，让任何经过最低限度培训的员工都能稳定产出标准化成果。
但设计那个厨房的人，首先必须是一个真正懂得如何做汉堡的人。如果你从未做过汉堡，你就不知道哪一步最容易出错，质量检查点应该设在哪里，番茄和生菜的先后顺序如何影响最终成品。你设计的厨房会在你预见不到的地方出问题。
今天的软件工程也是如此。AI 时代的工程师需要两种能力：以控制论视角审视整个系统，以及对每一个生产阶段都有真实的手感。 没有前者，你只是一个无法优化系统的熟练工；没有后者，你设计的流水线是空中楼阁。
软件工程的早期阶段是知识生产的过程，而非知识执行的过程。PRD 不能在 outset 就冻结。交互设计过程会揭示出新的业务逻辑需要决策，而这些发现必须反馈回 PRD。工程过程会揭示出此前无人考虑的权限问题，需要反馈到原型设计乃至更早阶段。
软件工程从"一人包办"走向深度专业化，再通过 DevOps 重建手感。今天，AI 再次扩展了一个人所能掌控的边界。但这并没有让事情变容易——它抬高了门槛。因为当工具强大到一定程度，瓶颈就从"你能不能做"转移到了"你能不能设计"。
我相信任何认真对待产品的团队，都需要一个能够横跨全局的人，同时确保四件事：产出的质量、生产流程的严谨、需求的定义、以及整条自动化流水线的设计。这四项职责不能分给四个人，因为它们之间的信息流是双向且高频的——拆开它们，连接就会在你看不见的地方断裂。
这个人需要既有品味，又有深厚、扎实的工程经验。他必须首先是一个真正懂得如何做汉堡的人，才有资格设计厨房的工作流程。
然而我们必须承认一个现实：这种人的稀缺并非偶然，而是结构性的。整个行业的人才梯队、招聘标准、薪酬带宽都是围绕专业化深度设计的。"高级前端工程师"有清晰的职业路径和市场定价；"能看见全局的人"在就业市场上没有对应的类别。更根本的是，品味是在闭合反馈回路中培养出来的，而专业化恰恰割裂了这些回路——在高专业化组织中，人们很少看到自己决策的下游后果。厨师从不尝自己的菜，所以他永远成不了好厨师。专业化不仅剥夺了产品的手感，也剥夺了人培养品味的机会。
此外，稳定期不需要这种人，所以稳定期不会培养他们。一旦流水线平稳运行，组织最需要的是每个工位上可靠的执行者。对"全局设计者"的需求只有在范式转换期才会浮现——就像现在。但此前的稳定期恰恰是专业化最精深、工业化最彻底的时候，系统性地没有培养这些人。需求出现的时刻，恰好是供给最枯竭的时刻。
当理想人选不可用时，团队必须尽可能接近这一条件。其他角色可以以辅助身份参与生产流水线设计，但核心必须有一个人主导。原因是具体的：在工程流水线真正稳定之前，代码库可能在一个月内经历多次破坏性重写。在整个过程中，所有上下文必须活在一个人脑子里。否则，每一次更新都会在交接缝隙中产生新的断点。
作者：张路宇 · LangGenius, Inc. CEO · 2026 年 4 月
End
三步星标⭐公众号第一时间接收精彩推送：1.关注公众号 2点击主页...3 设为星标⭐
本体论从入门到实战-09.简明Palantir Foundry架构设计和案例
