1. 正常情况

从技术根本出发，软件交付其实就三个层：

  • 环境（infrastructure / runtime）
  • 应用程序（app / service）
  • 实现逻辑（业务逻辑代码）

如果站在一个普通 dev 的角度，假设只有 CLI 工具和一份配置文件，那么只要一条命令：

kubectl apply / docker run / terraform apply，基本上就能跑起来。

这就是所谓的“理想世界”。

2. 复杂现实

难点并不是“写完能跑”，而是代码到落地之间那最后的一英里：

  • 代码仓库碎片化：一个系统动辄几十上百 repo，每个 repo 各有一套 build / release 逻辑。
  • 分包与依赖管理混乱：版本、依赖、子模块经常不一致，光追踪兼容性就能耗掉大量时间。
  • 命令层层包装：明明一个 CLI 就能解决的事情，却被封装成脚本、脚本再套脚本，还要走内部工具链，节点众多、职责模糊。

结果就是：

  • 你按照基本技术栈，其实已经开发完毕。
  • 但由于组织性混乱，你要花的时间常常是开发本身的几倍。

3. 结论与洞察

这其实是工程系统化水平不足的典型表现：

  • 技术栈的难度 ≠ 交付的难度
  • 真正拖慢 dev 的不是“会不会写逻辑”，而是“如何走通组织定义的工具链”
  • 在这种环境下，开发效率的决定性因素已经不是代码能力，而是对生态的熟悉度 + 跨层级整合能力

换句话说：

你遇到的问题并不是“技术难”，而是复杂度外溢——最后一公里被放大成了主战场，而这正是最容易让人 burnout 的地方。