大家都在讨论 AI 替代软件开发工程师，但没人讨论 AI 如何改变软件开发经理的工作方式。事实上，开发经理可能是从 AI 中受益最不均匀的角色——用好了，你一个顶俩；没用好，你只是产出了更漂亮的文档。
先给一个真实的数字：我现在花在管理杂务上的时间，大约是以前的三分之一。
不是因为我变懒了，是因为那些高频但"天花板低"的工作——写状态更新、整理汇报材料、准备面试、写绩效文档——这些任务在 AI 的帮助下，时间成本大幅压缩了。省出来的时间，我用在了技术深度讨论、团队成员一对一谈话和真正需要判断力的决策上。
这篇文章是我过去一年努力整合 AI 工具到管理工作中的真实复盘。不是工具列表，而是用什么、怎么用、以及我踩了哪些坑的总结。
软件开发经理的时间去哪了？
Engineering Manager 的职责写在纸上很清晰：Delivery、People Growth、Alignment、Technical Direction、Productivity。但实际工作日历完全不是这回事。
一天下来，时间太琐碎了，写状态更新、准备会议、筛简历、写绩效材料、起草招聘启事、Slack交流、准备一对一谈话、处理突发的事故。这些工作不是不重要，但它们有一个共同点：高频、占时间，但不复利。
招聘旺季最明显。一个 60 分钟的面试，加上准备、面试本身、写反馈，要花掉我 3-4 个小时。一周如果有 3-4 个面试，将近一半的时间就没了，根本没空做别的。到了年底绩效考评，加班是标配——不加班就没有足够的事例和文档，对组员不公平。每到周五写周报，是我一周里最发憷的时刻。
AI 没有改变开发经理在做什么，但改变了这个"管理事务"要花多少时间——进而影响了省出来的时间能用来做什么。
AI 真正能帮上的地方
重新参与技术
有一种现象在开发经理中很普遍：离代码越来越远，开始完全依赖底下的软件工程师的汇报来理解系统现状。风险很隐蔽——你以为自己懂发生了什么，但其实理解的是别人过滤之后的信息。
AI Coding 工具改变了这一点。用 Claude Code，我现在能快速读懂一个陌生的代码仓库，理解一个 PR 的影响，能对技术方案有自己的判断，而不是只看描述。
团队用 Claude Code 建了不少自定义 Skills：Code Review、Bug Triage。我也能用，还修复了一些Bug。就这件事，让我对系统细节的理解，远超任何架构图或者汇报文档能给我的。
重点不是开发经理要写生产代码，而是：在技术对话里有自己的 Ground Truth，你才能是一个更好的决策者，而不是一个被过滤后的信息接收者。
规划有了数据，而不只是直觉
以前季度规划要花将近一个月。漫长的会议，在"要砍什么、要保留什么"上反复拉锯，往往是谁说得更有说服力谁赢，而不是数据说话。决策在房间里感觉对，但事后解释起来很难。
现在同样的工作两周搞定。把团队现状、年度目标、客户优先级、人力约束喂进去，AI 帮你做结构化分解、识别依赖、生成规划初稿。决策还是我来做——那些需要了解团队、了解完整代码、了解组织上下文的判断，AI 给不了。但AI可以进行综合推理，过程有文档可循。
改变的不是决策质量，而是围绕决策的对话质量。
向上沟通终于不那么痛苦了
之前每到周五，写关键周报是我最发憷的时刻。不是写作难，是在一周工作结束、精力低谷的时候，把技术工作翻译成管理层能理解的语言，这件事本身很耗人。
现在同样的事 15 分钟完成。我把原始输入丢进去——这周交付了什么、有什么风险、做了哪些决策——AI 生成一份以价值和产出为框架的面向管理层的周报，而不是堆砌技术细节。
现在发给 VP 的邮件，更简洁，更聚焦商业影响，少了很多他们不需要知道的技术细节，也少了很多低级措辞错误。来回修改的次数明显减少了。
但这里有个很重要的警示：文档变漂亮了，不等于结果变好了。 后面会展开说。
真正了解你的组员
绩效考评最难的地方，是证据，事例散落在各处——Jira、GitHub、Slack、一对一谈话笔记、邮件。很容易无意间偏向印象最深刻的工作，而那往往是最近发生的或者喊得最大声的事故。
我现在把每个工程师的 1-on-1 笔记、年度目标，加上公司的职业培养计划，全部放在 NotebookLM 里统一管理。随时可以检索：六个月前我们确认了什么成长方向？他当时做了什么承诺？这半年有没有重复出现的模式？
做升职讨论的时候，证据事例从 Git、Jira、Email、Slack 各个源头汇总，不需要临时抱佛脚翻记录。
组员反馈里最让我印象深刻的一句话是："你还记得那件事啊。" 他们在一对一谈话中里三个月前提过的某件事，我后来主动提起来，加上具体的上下文。那种被看见的感觉——不是 AI 产生的，但 AI 创造了让它稳定发生的条件。
六个改变了我工作方式的工作流/工具
1. 向上管理 — 工具 ChatGPT / Gemini
做什么： 每周关键周报、重要版本发布邮件、季度业务复盘材料。
怎么做： 输入原始数据（项目状态、关键决策、风险），AI 生成结构化面向管理层的报告。重要邮件描述情况和重要客户报告，AI 起草初稿。
变化： 发到 VP 的内容聚焦业务影响和产出，不堆砌技术细节。季度复盘的准备时间从一整天压缩到两三个小时。
2. 内部客户管理 — 工具 Agent / MCP / Skills
做什么： 我的团队服务内部开发人员。我们搭了 Agent 和自定义 Skills，让那些团队能自己查信息、跑诊断、处理常见请求，不需要每次都找我们。
变化： 团队TOIL 减少了大约 50%。更重要的是，事故从每月 3-4 个降到大约 1 个，有些月一个都没有。这意味着我不需要花时间去救火，也不需要事后写根因报告，更不需要在事故期间向客户不停解释。
3. 组员管理 & 绩效考评 — 工具 Glean / NotebookLM
做什么： 一对一谈话笔记、职业发展计划、升职文档，必要时绩效改进文档。
怎么做： 用 Glean 检索工程师全年的 Jira 贡献、Slack 发言、文档、邮件记录。NotebookLM 存放一对一谈话笔记、年度目标和职业发展计划。写升职文档时，证据来自每个数据源，而不只是我碰巧记住的。
变化： 绩效材料更完整，更有说服力。但最重要的变化在工程师那边——他们感受到经理真的记住了他们做的事，这件事的价值远超任何漂亮的文档。
4. 招聘 — 工具 Claude Code + 自定义 Skills Pipeline
做什么： End-to-End 招聘流程，从写招聘启事到发 Offer。
Pipeline：
- JD Creation — 输入职位需求，输出精准招聘启事
- Resume-JD Matcher — 批量筛简历，给出匹配分和关键 Gap
- Interview Question Generator — 根据候选人具体背景和 招聘启事定制面试题
- Interview Feedback Collector — 结构化面试反馈模板，自动汇总各面试官意见
- Debrief Tool — 呈现评分差异，引导讨论分歧
- Offer Package Tool — 根据职位层级和市场数据生成 Offer 范围建议
变化： 每个 1 小时的面试，之前要花 3-4 小时（准备 + 面试 + 写反馈），现在大约 1.5 小时。候选人普遍反馈问题有针对性，不像模板题。有实力的候选人不会因为结构化不足而被漏掉。最近的招聘周期基本在 4-6 周内完成，以前动辄 3 个月以上。
5. 项目管理 — 工具 Claude Code
做什么： 季度规划、OKR的跟踪、每周团队进度报告。
怎么做： 规划系统集成年度目标，自动拆解到 Sprint 级别，生成可持续维护的季度计划。自动化周报从 Jira 和 GitHub 拉数据，在 OKR 变成问题之前提前辨识风险。
变化： 团队OKR 完成率从大约 50% 提升到 80%。计划会议从 2-3 小时的拉锯，变成 30 分钟的快速对齐。效率的背后是更清晰的共识——大家知道我们在做什么、为什么做，日常决策的质量也跟着提升了。
6. 远程团队管理 — 工具 Claude Code
做什么： 团队知识库、新人入职培训系统。
怎么做： 每个核心系统都有结构化文档作为知识库：系统架构、关键模块、环境搭建、开发流程、事故处理 Runbook。入职培训细分到"按天"，而不是按周。
变化： 爱尔兰的新成员以前大约需要三个月才能达到完整生产力，现在大约六周。改善来自于减少了"找人问"的时间——信息可以被找到，不需要等某个人在线。
但是也有副作用
漂亮的文档不等于好的执行
这是我花了点时间才学到的教训。一份格式完美的 Q2计划，清晰的 OKR，详细的Milestone，还是只是一份文档。如果开发经理花时间打磨 AI 输出的文档，而没有时间去验证团队是否真的理解并认同这个计划，结果就是：很好看的文档，很差的执行。
AI 很容易让文档看起来权威。这会制造一种虚假的清晰感。真正的对齐还是要靠直接观察和真实对话——没有工具能替代这个。
工具疲劳是真实存在的
过去一年，我的AI 工具经历了：ChatGPT → Glean + NotebookLM → Cline → Claude Code。从学 Prompt Engineering，到 Agent 框架，到 MCP，到现在的 Skills 和 Spec Driven Development。每一次迁移都需要真实的时间投入。
建议：选 2-3 个核心工作流深度优化，不要追每个新工具。复利来自深度，不来自广度。
过度依赖会让判断力退化
如果每份文档都靠 AI 生成，你对"好文档"的感知会钝化。如果每个决策都先问 AI，独立判断的肌肉会慢慢萎缩。
我保持一个刻意的习惯：重要决策先自己想清楚，再用 AI 来结构化或压力测试。AI 作为思考伙伴最有价值，而不是思考的替代品。
AI 做不到的事
建立信任
信任通过一致性、言出必行、和真实的关心积累——在时间里，在一次次具体的对话里，在你怎么处理那些难的时刻里。AI 可以帮你记住工程师说过的话，但替代不了你真的关心他们。工程师能感受到区别。
组织判断
客户的隐性动机、跨团队冲突的正确处理方式、那些没有说出口的优先级——这些需要 Context 和关系，AI 没有这些。AI 给你信息，判断力来自你对组织、对人、对历史的理解。
处理危机
凌晨两点发生事故，你需要用不完整的信息快速做决定：谁负责什么、升级到哪一层、如何对外沟通。这时候需要的是你自己的清醒和冷静，停下来 Prompt AI 不是一个有效动作。你搭的系统帮助预防事故，但真正发生的时候，还是得你来。
创造好奇心
AI 放大你已有的好奇心，但创造不了它。在这个环境里成长最快的开发经理，是那些用 AI 去探索他们本来就想探索的问题的人——走更深，移动更快。如果你对这份工作本身没有好奇心，AI 解决不了这个问题。
管理框架：用 AI 管理信息，用时间管理人
| 工作类型 | AI 可以做 | 你必须亲自做 |
|---|---|---|
| 文档和报告 | 生成、结构化、润色 | 判断什么值得写 |
| 绩效管理 | 整理事例、起草材料 | 真实的一对一对话 |
| 招聘 | 筛简历、出面试题、汇总反馈 | 最终判断和 Offer 对话 |
| 项目规划 | 拆解、追踪、预警风险 | 优先级决策和 Tradeoff |
| 技术方向 | 调研、比较方案、整理信息 | 选定方向并为结果负责 |
从 AI 中获益最多的开发经理，是那些用它压缩管理杂务的人——这样才有更多时间投入那些不可替代的部分：真实的关系、组织判断、技术可信度，和那些没有工具能替你去做的艰难对话。
获益最少的开发经理，是那些用 AI 打磨表面文档，而底层工作照旧的人。
这两类人之间的差距，正在拉大。
你在用 AI 做哪些管理的工作？或者作为开发工程师，你希望你的经理用 AI 帮你做什么？欢迎在评论区聊聊。
