52wuyaAI 让编码更快，为什么这位工程负责人反而更累
AI 工具常被描述为能省下时间：少写样板代码，把枯燥部分交给代理，早点下班。但 Orestis Ioannou 在 2026 年 10 月 27 日的一篇个人博客中给出了相反的体验：他如今在所有工程工作中都使用 AI 代理，能启动两年前不值得开始的项目，却发现自己比以往任何时候都更累。
这篇文章的价值不在于否定 AI 工具，而在于它把“效率提升”与“工作强度上升”放在同一张时间轴上观察。作者用自己的 GitHub 贡献日历作为粗略信号，记录了从全职工程师到技术负责人的角色变化，以及 2026 年重新出现的密集活动。以下内容区分来源事实与编辑分析，供开发者、运维人员和工程管理者参考。
背景：从两三个任务到多个并行代理
来源文章描述，作者作为全栈工程师时，一周通常只有两到三个需要认真投入的任务：一个功能、一个棘手的缺陷或一次迁移。每个任务都需要专注，但他可以一次在脑中装下一个，完成后转向下一个。
现在他的工作方式不同：多个代理并行运行，一个实现变更，一个调查生产问题，一个处理评审，另一个做后续研究。每个代理都不是一直需要他，但每个代理都会在某个时刻需要他——需要回答一个问题、批准一个计划、阅读一份 diff 或理解一个结果。每次响应都意味着切换上下文：重新加载另一个问题、另一个仓库和另一组决策。作者认为，这种疲劳与过去“两三个重任务”的疲劳不同，注意力被分散到更多问题上，心理消耗更大。
需要说明的是，这是作者的个人体验叙述，不是受控实验。来源未说明其团队规模、代理工具的具体配置或任务类型分布，因此不宜把结论直接外推到所有团队。
核心变化：贡献曲线回到全职编码时期
作者提取了 2019 年 1 月至文章发布时的 GitHub 贡献日历，并标注了自己在 Bold.org 的角色：2020 年 1 月起为全栈工程师，2022 年 8 月起为首席工程师，2025 年 8 月起为技术副总裁。来源明确指出，GitHub 贡献数混合了提交、拉取请求、评审和议题，只能作为活动量的粗略信号，不代表价值。2019 年基线也不完整，因为前一份工作使用自托管 GitLab。
来源给出的关键数字包括：2020 年贡献 2711 次，为最高年份；2021 年降至 1839，2022 年为 1498；2022 年 8 月至 2025 年 7 月作为首席工程师平均每月 114 次，而全栈工程师时期为 173 次；2023 年是最低年份，为 1189 次。2025 年 8 月至 12 月作为技术副总裁平均每月 111 次，2025 年 12 月仅 50 次，是加入 Bold.org 以来最安静的一个月。
转折出现在 2026 年：截至 10 月 27 日，作者已有 2102 次贡献，超过 2021 至 2025 年任一完整年份；2020 年同期为 2371 次，因此 2026 年接近但未超过最忙年份。2026 年 8 月为全时间线最忙月份，427 次，此前高点为 2020 年 4 月的 319 次。工作日贡献中位数从 2022 至 2025 年的 3 或 4 次升至 2026 年的 7 次，接近 2020 年的 8 次。零贡献工作日数量从 2022 至 2025 年每年的 40 至 46 天降至 2026 年截至 10 月 27 日的 18 天。单日 24 次以上贡献的天数，2022 至 2025 年每年只有一天，2026 年已有 16 天，接近 2020 年全年的 17 天。
作者特别指出一个反差：2020 年他是全职做功能开发的全栈工程师，今天的角色是工程负责人，功能工作远少于过去。按角色推断，曲线本应像首席工程师时期或更低，但实际回到了写代码是全部工作时的水平。来源将原因归结为“值得承接的工作变多了”：当编码变便宜，他可以修复以前不会碰的缺陷、改进代码库模式、启动新项目，把更多想法变成现实。代理不只是让既有工作更快完成，也让他更容易给自己增加更大的工作量。
编辑分析：这组数据的解释力有限，因为贡献数无法区分“高价值交付”和“高频小改动”，也无法排除评审、讨论等活动的增加。但它提供了一个有用的观察角度：AI 降低单次实现成本后，工作量的约束可能从“能不能做”转向“注意力和判断力够不够”。
影响：爆发、回落与“淡季不再淡”
来源把 2026 年描述为多次爆发，而非稳定爬升。1 月和 2 月分别是 277 和 233 次贡献，是第一个明显爆发期，作者开始认真使用代理，内部公司代理的观测实验也在此期间起步。3 月至 6 月总体回落，从 3 月的 203 次降至 6 月的 77 次，但 4 月出现一次较小爆发，为 187 次，其中包含一个 29 次贡献的单日和 68 次公开贡献，为当年公开贡献最高值。作者猜测模型改进是重新获得动力的部分原因。
8 月是最大爆发：夏季休假后，8 月初有一整周零贡献，随后 8 月 10 日至 27 日的每个工作日贡献在 14 至 43 次之间，8 月总计 427 次；9 月仍高达 301 次。作者总结每个周期都相似：新模型或新工作流让上个月不可能的事情变得可能，脑中充满想法；由于实现变便宜，没有自然阻力阻止他同时推进所有想法，于是他就推进；几周后，评审和上下文切换追上他，他退回更稳定的节奏，直到下一个兴奋点或假期恢复精力，再次进入爆发。作者称自 1 月以来经历了三次这样的周期。
最令作者意外的不是峰值，而是峰值之间的工作量。3 月没有 1 月、2 月或 8 月那样的爆发感，但仍有 203 次贡献，远高于首席工程师时期月均 114 次；这种活动水平已不再让他觉得是异常冲刺。6 月的 77 次是真正低谷，接近首席工程师时期较安静的月份，作者猜测可能是疲劳累积。但他仍发现，爆发之外承接的工作也比过去多，这就是“淡季不再淡”的含义。
来源未说明这些贡献中有多少来自代理自动生成、多少来自人工评审，也未提供任何生产率、缺陷率或交付周期的量化结果。因此，不能把这些数字直接解读为 AI 提升了团队产出。更合理的解读是：当实现成本下降，个人容易在缺乏边界的情况下持续加码，直到注意力成为瓶颈。
建议：把注意力当作需要管理的资源
对开发者而言，首先需要承认代理并行会带来上下文切换成本。可以给代理设置明确的“返回点”：例如只在计划审批、关键决策或最终 diff 评审时打断自己，而不是每个中间结果都即时处理。其次，把“值得做”和“现在做”分开，维护一个想法清单，而不是因为实现便宜就立即启动新代理。来源作者也提到，他的实现能力增长快于思考能力，最终会不想再启动另一个代理。
对运维和平台团队而言，代理数量上升会带来评审队列、权限边界和审计需求的变化。建议在团队内明确代理可以访问的仓库和环境范围，要求关键变更保留人工评审记录，并定期检查并行任务是否造成重复劳动或无人负责的中间状态。来源未提供具体工具配置或安全实践，以上为编辑建议，不是来源结论。
对工程管理者而言，不应把贡献数或代理启动数当作生产率指标。来源中的 GitHub 数据只是活动信号，作者本人也强调它不衡量价值。更可行的做法是关注交付结果、评审质量和团队疲劳信号，允许工程师在爆发期后主动降速，而不是把高峰当作新常态。
作者在文末坦言，他还没有找到平衡，目前观察到的是“能做得更多”不断变成“做得更多”，并且他感到疲惫。这一结论来自个人反思，来源未说明是否有团队层面的制度调整或后续验证。
资料来源
本文由自动化系统筛选公开技术信息，并经 AI 辅助整理。
本文采用 original 索引策略。