文章分类：Research

摘要：本文回顾软件工程从单人开发、专业分工、DevOps到AI时代的演进历程。重点探讨自动化流水线如何重塑研发协作，强调在AI辅助下，人类角色正从执行者转向决策者，通过“双钻模型”确保在高度自动化的流程中精准定义问题与方案。

软件工程：分工与收敛

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

单人时代

早期互联网时代，一个人通常能独立完成整个网站。从定义产品功能、编写前端页面、开发后端逻辑，到部署服务器和排查问题，全由一人包揽。

这并非因为早期工程师身怀绝技，而是当时的技术难题足够简单。静态页面搭配少量服务端脚本，完全在一人的认知负荷之内。

当时有一套被称为“Web 三剑客”的工具链——Dreamweaver 负责页面搭建，Flash 负责动画与交互，Fireworks 负责图像处理。这套工具的核心价值在于，它将 Web 开发的复杂性封装进单一套件中。开发者无需精通某一细分领域，也能独立完成从视觉设计到产品上线的全流程。

这种模式带来了一个重要副产品：
反馈闭环得以打通。我写代码，我管服务器，用户遇到问题我最早知道，也是我亲自修复。就像厨师在端菜前一定会先尝一口。

时代 02：2000年代，专业分工

复杂度突破，分工诞生

90年代中期，Web 开始商业化，问题规模发生质变。电商与门户网站兴起，系统必须应对真实并发、海量数据和严峻的安全威胁。单人的认知天花板被打破，分工成为必然。

随着工作模式的转变，“Web 三剑客”逐渐退出历史舞台。它们并非被更优秀的同类工具取代，而是其服务的“一人包揽”模式已不再适用。取而代之的是更垂直、更专业的工具链：前端有 Webpack 和 React，设计有 Figma，后端则依赖定制化框架与中间件。工具日益专精，人也随之细分。

这种分工极大提升了系统的能力上限，让大规模软件成为可能。但它也切断了一些东西。

许多工程师职业生涯中从未接触过生产环境服务器。代码提交之后的流程，对他们而言如同黑盒。
厨师再也尝不到自己做的菜。

时代 03：2009年，DevOps 运动

DevOps：重建“亲手实操”的体感

2009年前后，DevOps 理念开始成型。其技术组件广为人知：持续集成、持续部署、基础设施即代码、自动化监控与告警。但这些只是手段，其深层目的是重建被切断的反馈闭环。

它让写代码的人重新感知代码在真实环境中的表现，重新为生产环境中的行为负责。

亚马逊内部有一句名言：“You build it, you run it.” 这并非技术宣言，而是关于责任归属与实操体感的界定。

云服务的成熟是 DevOps 成功的先决条件。AWS 等云平台抽象了底层基础设施，大幅降低了运维门槛。开发者无需成为运维专家，也能通过自动化手段感知生产环境。反馈闭环再次打通。

时代 04：2020年代，AI 时代

新分工：AI 时代的流水线

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

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

设计流水线，与在流水线上干活，完全是两回事。

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

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

过去，UI/UX 设计是一个独立且高度依赖人工判断的流程。设计师输出原型图，工程师努力像素级还原，中间隔着大量的反复沟通与信息损耗。设计在流水线中是一个断点，而非一个节点。

如今，LLM 正在改变这项工作的成本结构。设计决策的产出效率被大幅提升：
针对单一问题，让 LLM 同时生成三到五个甚至更多的候选方案。

人类的角色从“从零创造”转变为“评判与筛选”。这是一种根本性的工作模式转变——评判的成本远低于创造的成本。

方案选定后，组件级原型可直接融入整体产品原型，甚至直接交付给前端工程。设计决策不再被困在原型文件里，而是成为代码库的一部分。

更重要的是，此过程中产生的所有上下文——为何选 B 弃 A、放弃了哪些交互模式、哪些视觉判断背后藏着怎样的产品逻辑——
这些决策记录本身就是重要资产。 它们是下游代码生成、测试设计以及下一轮迭代的宝贵输入信号。上下文绝不能丢失，一旦丢失就会形成信息断层。

理想的设计流水线状态，不是 AI 取代设计判断，而是让人类的判断力聚焦于最有价值的环节：
在多种可能性中，选出最贴近产品本质的那一个。

这一模式带来一个重要启示：
人类在设计流程中的角色正从“生产者”转变为“编辑者”。 判断力、审美品味、对产品方向的把握——这些能力变得比“熟练使用设计工具”更重要。这也呼应了前文关于“系统所有者”的核心观点：只有真正理解产品价值主张的人，才能从五个候选方案中挑出正确答案。

目前，该阶段的人工介入成本依然较高，流程仍有很大优化空间。但方向已经明确：随着 LLM 对产品上下文的理解不断加深，候选方案的质量将稳步提升，需要人工介入的节点会逐步减少，整条设计流水线将逐渐向自动化收敛。

双钻模型

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

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

“双钻模型”（Double Diamond）为进入生产环境前的反复校准提供了结构框架。它包含两个“钻石”形状的阶段，每个阶段都是一个“发散-收敛”的循环。第一个钻石用于确认问题本身——发散探索所有可能的方向，然后收敛到清晰的问题定义。第二个钻石用于确认方案——发散尝试多条候选路径，最终收敛为可执行的决策。

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

随后，这些决策将被写入
AGENTS.MD
文件中——这是引擎中 LLM Agent 的行为约束文件。