打造人们喜爱的软件：工程与设计的协同艺术
中文主题
软件工程与产品设计的融合、代工模式（Agency）下的技术选型策略、迭代开发中的“丑陋原型”价值，以及 AI 时代下开发与设计边界的重塑。
基本信息
- 节目：Software Engineering Daily
- 嘉宾：Wesley Yu（Metalab 工程副总裁）
- 日期：2026-06-30
- 来源：Software Engineering Daily
- 链接：Building Software That People Love
核心观点
优秀的软件不仅在于功能完备，更在于其流畅度、一致性以及带给用户的愉悦感（Delight）。这种品质诞生于工程与设计的交叉点。在代工（Agency）模式下，技术选型应当摒弃对前沿热点的盲目追逐，建立“偏向枯燥与稳定技术（Bias toward boring and stable technology）”的决策框架，以保障客户项目的长期可维护性。同时，软件开发应拥抱“先粗糙、再精细”的迭代逻辑，通过快速构建甚至故意显得简陋的端到端原型，暴露真实问题，并利用 AI 辅助工具重塑工程师与设计师的协作界面。
Highlights
- 技术选型的保守主义：代工机构更倾向于选择稳定、甚至“枯燥”的技术栈（如 React Native、Spring Boot 等），因为工程决策不仅是技术探索，更是一项涉及招聘、交接和 2:00 AM 运维保障的长期商业计划。
- “丑陋软件（Ugly Apps）”的价值：通过构建仅具备最基本交互、数据甚至直接渲染成 JSON 的端到端原型，能让团队和客户在极低成本下验证核心业务流，避免过早陷入视觉细节的争论。
- 软件的“手感（Feel）”：优秀的软件体验来自对交互细节的工程预处理（如在用户悬停于频道时预加载内容）以及无处不在的微小惊喜（如 Slack 标志性的 Slackbot 幽默文案）。
- AI 对设计与开发边界的重塑：随着 AI 工具（如 Notion、Figma 插件及代码生成技术）的成熟，设计师可以直接输出更接近生产环境的代码原型，而工程师的工作重心则转向应用骨架的搭建、系统架构设计以及安全性控制。
长文笔记
为什么 Agency 模式需要偏向“枯燥且稳定”的技术栈？
在技术日新月异的背景下，开发者往往容易受到新型框架和前沿技术的吸引。然而，在以 Metalab 为代表的专业设计与开发代工机构中，技术选型的第一原则是**“实用主义与稳定性优先”**。
在代工项目中，交付并不意味着结束，客户需要在项目移交后独立运行和维护系统。如果使用过于前沿或小众的技术（例如早期的某种实验性前端框架），会给客户带来双重灾难：
- 招聘灾难：客户很难在当地市场上招到熟悉该冷门技术的工程师。
- 维护灾难：当系统在凌晨两点崩溃时，缺乏成熟的社区支持和现成的解决方案，会导致维护成本飙升。
因此，技术选型应当基于一个理性的决策树：
- 第一维度：客户团队的既有技能与地理属性。例如，欧洲的客户往往更倾向于使用基于 Java 的后端框架（如 Spring Boot），因为当地的高校和市场源源不断地输出此类人才；而在美国，Node.js 或 Ruby on Rails 的普及率则更高。
- 第二维度：产品生命周期与速度要求。在构建 iOS 和 Android 双端应用时，除非性能是绝对的核心瓶颈，否则使用 React Native 或 Expo 往往能以极快的速度（Speed to Market）帮助客户占领市场，这比维护两套原生代码库更具商业合理性。
“端到端的丑陋原型”：如何用渐进式精细化避免做无用功
传统的瀑布流式开发要求设计师先画出像素级完美的 UI，再由工程师进行像素级还原。这种方式在面对高度不确定的早期产品时效率极低。Metalab 提倡一种**“先做丑陋产品（Delightfully Ugly Apps）”**的开发模式。
在这种模式下，团队的第一步是建立一个从前端点击到后端数据库的“完整闭环”，但没有任何视觉美化。页面上甚至可以直接打印出 API 返回的 JSON 数据，或者只用几个最简单的原生输入框和按钮。这种做法的工程与产品价值在于：
- 核心路径验证：它迫使团队和客户把注意力集中在“业务流程是否跑得通”上，而不是某个按钮的颜色或动画是否好看。
- 暴露底层架构缺陷：通过真实的端到端链接，可以极早发现接口定义不合理、数据流不通或性能瓶颈等硬伤。
- 降低变更成本：在原型阶段，修改一个业务逻辑只需要重新组合几个基础组件；如果等到高保真界面渲染完成后再改，设计师和工程师都需要付出成倍的时间代价。
软件的精细化过程应当是从“JSON”到“线框图（Wireframes）”，再到“中等保真度”，最终到“高保真视觉”的渐进式演进。
软件的“物理手感”：工程与设计的交叉点
人们经常用“丝滑”、“有质感”来形容优秀软件的体验。这种微妙的感觉（Feel）在工程层面有着明确的实现机制。
以频道切换或页面跳转为例，普通的实现方式是用户点击——触发请求——展示 Loading——渲染数据。而在 Metalab 的工程实践中，为了创造“即时响应”的手感，会引入意图预判机制（Intent Prediction）：
- 当用户的鼠标悬停在某个频道链接上时，虽然用户还没有点击，系统就已经向后端发送了预加载数据的请求。
- 当用户真正按下鼠标时，数据已经准备完毕，界面实现零延迟切换。
此外，软件的生命力还来自于那些与核心业务功能无关，却能引发情感共鸣的细节。例如 Slack 在加载页面时展示的个性化欢迎语和 Slackbot 的幽默对话，或者用户在进行交互时触发的微妙触觉反馈（Haptics）。这些设计虽然不会直接提升系统的吞吐量，但它们赋予了软件“人格”，将其从一个冰冷的计算工具转变为用户乐于使用的伙伴。
AI 时代下工程师与设计师角色的重叠与重塑
当前，以大语言模型和各类开发代理（Agents）为代表的 AI 技术，正在深刻地改变软件开发的工作流，尤其是设计与工程之间的交界地带。
传统的协作模式中，设计师输出 Figma 图纸，工程师将其翻译为代码。而现在，通过 Notion 开发平台以及各类基于 MCP（Model Context Protocol）的自定义 Agent，设计与工程的边界正在变得模糊：
- 设计师的职能向工程延伸：设计师可以利用 AI 工具直接将设计组件转化为可运行的代码原型，甚至通过自然的语言交互直接调整页面布局和简单逻辑，无需工程师事事插手。
- 工程师的工作向系统架构收拢：当基础的 UI 编写和 boilerplate 代码生成被 AI 接管后，工程师的核心价值将转移到系统架构的搭建、数据安全边界的控制、API 协议的设计，以及为设计师提供可靠的“应用骨架（Scaffolding）”。
这种转变不仅没有削弱开发者的角色，反而让双方能够将更多的时间从无谓的“像素对齐”中解放出来，专注于产品体验的打磨与核心技术难关的攻克。
知识迁移：对手艺人（Craftsman）精神的启示
软件开发本质上是一门“手艺”。无论是通过“织物剪裁（Draping）”式的动态调整来迭代软件，还是在移交项目时像寻找“养父母”一样为代码寻找最合适的团队和技术栈，都体现了对软件工艺的敬畏。
在未来的开发中，“技术偏好（Biases）”没有绝对的对错，但必须与人适配。每个开发者都有自己的编码习惯和环境偏好，这就像办公桌的陈设一样。理解这一点，在团队协作和手接盘项目中主动包容不同的技术偏好，并以“减少未来维护者的摩擦”为目标去编写代码，才是打造出真正“让人喜爱的软件”的关键所在。