软件工程这几年有个很直观的变化：公司里的开发越来越像大型施工现场，个人折腾越来越像少数还能自己拿图纸、自己下手的地方。

澳大利亚工程师 Dylan Butler 在《Protect Your Shed》里用了一个很贴切的比喻：企业项目像“摩天楼”，个人项目像“后院小棚”。前者讲流程、可靠性、协作和合规；后者不一定精致，甚至会漏雨，但它是你从地基到屋顶都亲手搭起来的。

这个比喻给今天的软件行业补上了一层很重要的解释：为什么不少技术人明明在大公司做着高难度系统，反而越来越少有“我在做工程”的感觉。问题不一定出在能力退化，更常见的是判断权和试验空间被流程、平台和 AI 工具一起压缩了。

企业系统越来越重，工程师越来越像“施工队员”

Butler 说的软件开发，并不是那种一个人一晚上写完的玩具应用，而是银行系统、企业平台、跨区域数据库、受监管环境里的生产系统。这类系统天然要靠设计文档、架构评审、测试计划、回滚预案和合规检查来维持。

所以，很多开发者进大公司后会发现，写代码只是工作的一部分。开会、画图、补文档、对齐依赖、过审流程，常常占掉更多时间。这不是简单的官僚主义，而是规模化的代价。你处理的是高风险系统，不是自己电脑上的小脚本。

新线索真正补强的，不是“流程很重”这件事本身，而是它把流程重、系统大、个人无力感三者的关系说清了：企业环境会训练你如何把系统做稳，却不一定给你足够空间去决定系统为什么这样设计。

这也是很多资深工程师后来会感到疲惫的原因。不是他们不会了，而是长期处在巨型工程的一小段工序里，学到的是协作纪律，失去的却可能是完整建造的手感。

个人项目的价值，不在“副业变现”，在重新拿回判断权

过去谈 side project，常被说成作品集、开源名片，或者未来创业的种子。Butler 的角度更实在：个人项目最重要的作用，是让工程师重新经历一次完整决策。

你得自己选数据库，自己决定部署方式，自己处理故障，自己理解为什么日志看着正常、服务却还在抖。没有同事兜底，也没有成熟流程替你掩盖理解上的空白。

这和企业工作形成了很强的对照。大厂能教你怎么拆服务、怎么做容灾、怎么管变更、怎么避免未来难以维护的设计；但个人项目才更容易逼你回答另一类问题：如果从零开始，你会怎么搭？如果出了问题，你到底知不知道问题在哪？

Butler 提到，他的 homelab 是从一台机器上的单个容器，慢慢演进到自动部署、集群化、基础设施代码化。这个过程很典型。很多真正有用的工程感觉，不是从课程里学来的，而是在“能跑就行”之后，开始主动考虑失败场景、依赖关系和恢复能力时长出来的。

这条线索对旧判断的补充很明确：手搓项目的意义，不只是浪漫、不只是极客趣味，而是工程师少数还能从头到尾承担技术后果的地方。它更像训练场，不只是玩具箱。

AI 让搭棚子更快，也更容易让人只会“拼装”

这也是这篇文章放到今天更有现实感的地方。

AI 编程助手、托管平台、脚手架工具、平台工程，这些东西都在降低交付门槛。你现在确实能比以前更快做出一个能运行的东西。但更快，不等于更懂。很多时候，你只是更快地把现成部件拼起来了。

Butler 的判断很克制，但很锋利：工具越强，越需要一块属于自己的试验田。因为 AI 可以帮你生成样板、补全接口、搭出雏形，却不能替你承担架构取舍，也不能代替你建立“什么场景会翻车”的直觉。

对工程师来说，这里的变化不是“AI 会不会抢代码工作”这么简单，而是一个更细的分野正在出现：

  • 一类人越来越擅长调用工具，快速产出结果；
  • 另一类人还保留着拆开系统、验证假设、自己修棚补漏的习惯。

短期看，两者都能交付。时间拉长后，差距往往出在故障判断、技术选型和跨代迁移上。前者依赖当前工具链，后者更可能穿越工具迭代。

这也是新来源相比旧稿额外补强的地方：AI 并没有把个人项目的价值冲淡，反而抬高了它。因为在 AI 时代，side project 更像检验你是“会让工具出活”，还是“真的理解系统”的分水岭。

谁最该在意这件事：大厂工程师和技术经理

这件事和所有人都有一点关系，但最受影响的其实是两类人。

一类是成熟组织里的工程师，尤其在金融、云计算、医疗、政企这类流程重、风险高的行业。他们最容易在长期协作里变成优秀执行者：能交付、能对齐、能维护，但越来越少主动追问技术本身。对这群人来说，side project 的作用不是证明热爱，而是防止自己的工程判断被日常流程磨平。

另一类是带团队的技术经理。很多团队现在非常强调平台统一、规范收敛、AI 提效，这些都没错。但如果组织只奖励可预测和零意外，最后往往会得到一群熟练执行流程的人，而不是能做技术判断的人。短期效率会上去，长期创新和架构活力可能会变弱。

这里还有一个现实限制，Butler 也点到了：不能把下班后继续写代码当成道德要求。不是每个工程师都有时间、精力和家庭条件去长期维护个人项目。把 side project 神化，很容易变成另一种行业压力。

所以更合理的理解是：工程师需要一块不完全被业务定义的空间，但它不一定非得是深夜写产品。它也可以是开源贡献、硬件折腾、树莓派实验、协议研究、技术博客，甚至系统性拆解一个自己常用的软件。重点不是额外加班，而是保留自主探索和亲手验证的能力。

接下来该看什么：公司是在提效，还是在削弱工程判断

接下来最值得观察的，不是会不会有更多人公开鼓吹 side project，而是组织会不会重新重视“工程师的试验空间”。

有几个信号很实际：

  • 团队是否允许工程师在低风险环境里做小规模实验；
  • AI 工具引入后，是否还要求成员解释设计取舍，而不只是提交结果；
  • 招聘和晋升时，是否只看交付速度，也看故障处理、系统理解和技术判断；
  • 平台工程是在帮人减少重复劳动，还是顺手把底层理解一起屏蔽掉了。

如果一家公司只剩流程、工单和自动化产出，那它培养出来的更像熟练操作员。这样的团队也能运行，但一到工具切换、架构迁移、复杂故障，就容易暴露天花板。

工程行业一直有个朴素道理：图纸能学，手感难教。企业项目负责把人训练得可靠，个人试验场负责让人不失灵。两边少了哪一块，都会偏。