被实习生上了一课

今天下班的时候，被我的实习生上了一课。

我这个实习生挺厉害的，经常能带来一些增量的知识——不是复述二手信息那种增量，是真有他自己的见解。大家互相促进、互相成长吧。

他问我：下班之后都会做些什么？

我说，大概还是把工作里的一些事情收个尾。

他说，应该去学一些 Agent 相关的知识和技能。

我问 Agent 指的是哪一层：是 Claude Code、DeepSeek Harness 这类 Agent 工具，还是大语言模型？

他说都不是。他的意思是，Harness、Memory、Skill 这些框架层的东西基本已经定型了，真正需要探索的是——怎么把 Agent 部署到企业级的生产环境里去用。这可能会是未来大家重点探索的方向。而且在企业环境里，你能把学到的东西真正快速落地，让更多人使用，再从用户反馈中不断完善它。这个循环本身，就非常能帮助自我提升。

这番话确实有见解，也让我挺有感触的。因为它戳到的，正好是我最近一直很困扰的问题。

效率涨了，人在变空

最近 Agent 迭代得太快了。在这么智能的模型协助下，开发工程师的工作流程彻底变了：以前开发周期是以天、以周为单位的，现在是以小时为单位。

但周期变快了，能学到的东西反而更少了，人也变得更累了。

原来一个需求要花两天设计架构，三天实现代码，现在这个过程完全交给大模型了。而且由于大模型每次思考要等很久，所以一个人往往同时推进五六个、甚至十多个进程，工程师彻底沦为了大模型的中转平台和任务分发助理。

这对自身成长其实没什么好处。时间久了，精神状态也会面临巨大考验。提效后大家普遍觉得很疲惫，同时伴随着一种强烈的空虚感：以往做完一项大需求的那种成就感已经荡然无存，现在两小时搞定一个需求，完成后只会觉得空虚，仿佛什么都没发生过。整个开发过程里，收获的知识和技能很少很少。

但这个趋势没法逆转

Agent 确实提升了效率。对快速发展的公司，对全世界绝大多数互联网公司来说，这都是大趋势。大家都不可能再回到「古法编程」、用一周时间去设计一个系统的阶段了。

更关键的是，效率提升完，只会有更多任务。这件事其实无法改变。公司想要快速发展，追求的必然是迅速迭代、迅速完成。作为个人，你很难打破这个增长的怪圈；指望以人为本、主动降低迭代速度来换取个人成长，基本做不到。

所以破局的前提是：开发速率不能降。要在这个前提下，想办法把工程师解放出来，让他们有更重要的事去处理，在日常迭代中能获得更多成长。

能做的两件事

第一件，是把 Vibe Coding 工具做起来，让产品、设计、以及任何产生需求的人，自己借助 Agent 闭环掉「开发、测试、上线」这条链路。这样能减轻一部分开发人力。当然这会给产品增加工作量，但这无法避免——事情肯定得有人去推动，不是开发，就是产品或设计，对吧？

第二件，是尽可能减少需要人为介入的迭代流程，完善基础设施建设，让 Agent 自己闭环：review、简单的 QA 测试、上线操作、上线后的验证，这些基建环节。把它们交给 Agent 闭环，才是真正解放工程师生产力。

那开发工程师去哪

如果需求侧产品自己就能闭环，Agent 又把开发到上线的全流程跑完，开发人员何去何从？

我想到两条。

首先，出问题后，锅还是需要人类来背的。而背锅后，你会去完善告警、完善监控面板、完善 Agent 的功能和技巧。所以不要怕「背锅」，每一口锅都是通向成功的台阶。

二是产品和开发的界限会变得越来越小。原来是产品提需求、开发去实现；之后应该更鼓励开发做一些架构和产品方向的思考，不局限于特定角色，让每个人都能自由发挥想象，去探索，去创造，从而推动公司发展，实现公司和个人的蜕变。

转变思维模式，这需要较强的指引。并不是每个开发都能自己想清楚要做什么，即使给工程师充足的时间，也不是都能有正向的产出或者进步。作为一个小团队的 leader，需要给工程师同学更好的指引，给出需要探索的目标和方向，当然这并不是限制大家，大家完全可以有更好或者说更喜欢的想法和探索。

作为 Growth 团队的成员，数据是非常重要的一部分。一些关键数据指标要去关注：重要指标看板是否完善？数据打点是否齐全？监控是否覆盖到位？能不能及时告警？如何提升关键指标？如何提升用户订阅？这些产品非常关注的数据，工程师也应该重视，这是起点，需求从数据中来。

何去何从，我也没有答案

但我很清楚，上面这些离工程师最终的奋斗目标还是有距离的。

指标、监控、看板，这些是「应该做好的事」，不是「值得为之努力的事」。真正的探索方向，我现在还没找到。

写出来，是想找大家一起想。集思广益吧。