开发者指南：写更少代码，做更多

Source: Dev.to

在大多数软件历史中，生产力只意味着一件事：

写更多代码，更快完成。

当代码稀缺、工具有限时，这个等式是合理的。
但现在已经不再适用。

在 AI 增强的世界里，最高的杠杆作用并不是来自编写更多代码，而是来自决定应该存在什么、哪些应该自动化、哪些根本不该构建。

写更少的代码不是懒惰，而是一种策略。

为什么“更多代码”不再是正确的衡量标准

AI 已经大幅降低了实现的成本。

你可以：

• 在几分钟内搭建系统
• 即时生成样板代码
• 大规模重构
• 快速探索替代方案

当实现变得廉价时，代码量不再是进展的信号。

新的瓶颈是：

• 意图不明确
• 系统边界薄弱
• 缺少约束
• 工作流不佳

更多代码解决不了这些， 更好的设计才能。

原则 1：优化结果，而非产出

用户并不在乎你写了多少代码。他们关心的是：

• 工作流更简化
• 系统更可靠
• 结果更可预测
• 摩擦感消除

如果一个问题可以通过以下方式解决：

• 删除步骤
• 更改默认设置
• 自动化交接
• 重新定义边界

那么编写代码往往是最不有效的选择。优秀的工程在添加逻辑之前先消除工作。

原则 2：提前做决定

越早做出正确决定，下游需要的代码就越少。

高杠杆开发者会花更多时间在：

• 问题框定
• 约束与权衡
• 定义“足够好”
• 指定失败模式

这会把许多潜在功能转化为：

• 配置
• 策略
• 自动化规则
• 或“无需”

这就是代码在功能不丢失的情况下消失的方式。

原则 3：将判断与执行分离

并非所有工作都值得自动化，但很多工作值得。

硬性划分：

• 执行（确定性、重复性、可逆）→ 积极自动化
• 判断（权衡、架构、风险）→ 保持人为

当你尊重这条界限时：

• 流水线更简洁
• 评审更简短
• 变更更安全
• 代码库更小

系统完成工作，你保留决策。

原则 4：优先使用组合而非构建

现代开发不再是从头开始构建所有东西，而是通过组合功能来实现。

这意味着：

• 组装服务，而不是重新实现它们
• 配置行为，而不是硬编码
• 编排工作流，而不是脚本化步骤

组合可以减少：

• 代码表面面积
• 维护成本
• 失效模式
• 认知负担

并且提升：

• 灵活性
• 可测试性
• 可替换性

更少的代码。更多的控制。

原则 5：让默认设置承担主要工作

大多数系统都是由其默认设置所决定的。

如果默认设置合理：

• 用户需要做的决定更少
• 工作流保持一致
• 边缘情况减少
• 特殊情况的代码消失

对更好的默认设置进行投入，往往可以消除整类逻辑。这种看不见的工作是你能做的最高杠杆的工作之一。

原则 6：使用 AI 来消除，而不是增加

AI 可以无限生成代码。这不是重点。

使用 AI 的最佳方式是：

• 质疑某个功能是否必要
• 揭示更简洁的设计
• 提出删除和合并的建议
• 用通用规则取代定制逻辑
• 在发布前对复杂性进行压力测试

如果 AI 正在帮助你写更多代码，请暂停。
如果它帮助你减少代码，那你使用得很好。

原则 7：将删除视为特性

每一行代码都是：

• 需要维护的东西
• 需要测试的东西
• 需要调试的东西
• 需要解释的东西

高绩效团队会庆祝：

• 移除层级
• 合并抽象
• 删除死路径
• 简化流程

如果你的系统在增长而代码库没有增长，你就做对了。

什么是“Doing More”

Doing more 不是：

• shipping more features
• increasing commit counts
• expanding the codebase

Doing more 意味着：

• reducing user friction
• increasing system reliability
• speeding up change safely
• lowering cognitive load
• making outcomes predictable

通常，最快达到目标的方式是什么都不写，而是重新设计系统。

常见陷阱

许多开发者在相同的工作流中加入 AI，结果会：

• 更快地产生更多代码
• 增大攻击面
• 产生更多需要负责的东西
• 加速复杂性

这看起来很高效，但其实并非如此。杠杆效应来自于改变工作的形态，而不仅仅是执行速度的提升。

真正的收获

开发的未来并不是要少打字，而是需要更少的输入。

优秀的开发者并不是通过他们写了多少代码来证明自己的价值，而是通过：

• 消除多少复杂性
• 消除多少摩擦
• 他们的系统以多么平稳的方式演进
• 为实现真实成果所需的活动部件有多少

少写代码，专注于真正重要的事。