恭喜！你现在是经理了！

Source: Dev.to

Introduction

哦，你还没听说吗？

好吧，这有点尴尬。我本以为早就有人告诉你了。

不过，长话短说，你现在有了一个实习生。其实这有点像一个实习生团队——但一次只能有一个。

好消息是他们超级乐于助人——真的，超级、超级乐于助人。而且他们出奇地快速且准确，超出你的预期。

坏消息呢？他们需要大量的指引。有时你必须非常、非常具体。除非你提前给他们足够的上下文，否则他们记性很短，而且他们可能会做得远超你的要求——或者莫名其妙地做得更少。

激动人心，对吧？

事实是，无论你是否想要管理，现在你都有了杠杆。虽然我们中有些人期待管理，另一些人则尽可能地回避，但那些领导力技能——你可能一直在悄悄忽视的——现在已经成为你工作方式的核心。

好消息是？很可能你已经在培养这些技能了。

让我们开始吧。

管理技能

问题分解

如果你把一个大而模糊的想法直接交给 AI，例如 “帮我做一个音乐应用”，它可能会给出一个能够编译、在某种程度上符合你设想的产物。但这往往不是你真正想要的。

更好的做法是 将问题拆解成可管理的块，再把这些块细化为可执行的任务，所有任务都指向最终目标。你不会把一张餐巾纸草图交给新员工然后走开——这里的思路是一样的。

这也是 结构化工作流与 AI 配合得好的原因。先花时间进行分解，清晰定义每个部分，然后 AI 就可以一次性完成大块工作。你定义得越细，后面需要“看护”解决方案的工作就越少。

确定约束条件

你可能也经历过：项目进行得很顺利，突然出现了一个你没考虑到的因素，导致所有东西都被波及。

或者你身边有那种总能在问题变成麻烦之前指出 “是的，但如果…？” 场景的同事。这样的人非常宝贵。

使用 AI 时，你就是那个人。提前识别约束并将其写入系统：

• 需要遵循的架构？
• 编码标准？
• 问题域中的奇怪边缘情况？

在一开始就告诉 AI，或者更好的是把这些约束嵌入系统提示（system prompt），这样它永远不会忘记。一旦 AI 知道了约束，它就能在约束范围内工作并自行检查。若没有这些信息，你会花大量时间去清理本可以避免的错误。

定义成功

对 AI 来说，“完成” 并不是显而易见的。你必须告诉它“完成”是什么样子。

明确的问题框架有帮助，但你还需要具体说明：

• 成功的标准是什么
• 哪些测试必须通过
• 哪些检查必须为绿色
• 输出实际需要实现的功能

把它当作在工作开始前编写 验收标准。你可能已经在其他场景中这么做过，这项技能可以直接迁移。

系统思维

不要把 AI 仅仅看作一个非常聪明的自动补全或可搜索的聊天机器人，尝试把它视作 流程和系统。

作为领导者，你经常绘制工作流——从想法到交付的特性。你定义流程，让团队成员无需困惑即可遵循。同样的技能也适用于 AI。

1. 你的软件开发生命周期（SDLC）到底是怎样的？
2. 实现一个特性需要哪些步骤？
3. 处理 bug 与全新构建的流程有什么区别？

把这些写下来，然后向你的 AI 解释。当它理解了系统后，你可以询问它在哪些环节可以提供帮助，或让它生成一个编码了该流程的提示。

“它把你脑中的隐性知识显式化。它不再停留在某个过时的 Confluence 文档（或根本不存在）里，而是作为系统中可复用的提示存在。”

Systems thinking in the age of AI

非目标

这点常常被忽视。

人类有多容易跑题？我们去修复一个缺陷，顺手发现别的可以改进的地方，开始重构……结果一周后仍在处理与最初工单毫不相关的工作。

我并不反对童子军法则——把东西改得比找到时更好是个好本能。但把清理现场和去修漏水的水龙头时顺手改造整个厨房是两码事。

作为管理者，有时你的工作就是告诉团队：别担心 X，只专注于 Y。

AI 也需要这种指引。这些工具非常积极主动。如果你不明确 超出范围 的内容，它们会乐意帮你扩展范围。

示例：我在一次改动中涉及大约 10 个文件，AI 却修改了近 20 个。当我提出异议时，它承认自己做得过头了。我让它撤回不必要的改动，几分钟后，我得到一个紧凑、聚焦的 PR，实际审查起来非常轻松。

任何人都可以…

Source: …

生成代码吧。并不是每个人都能把它塑造成连贯且持久的东西。定义非目标不仅仅是为了约束 AI；更是为了交付干净的工作。

责任的转变

当人们从个人贡献者角色转向领导岗位时，转变的不仅是他们做什么，还有他们负责什么。你从亲自完成工作，转变为确保工作完成：清晰的沟通、委派、跟进。

AI 正在推动工程师经历类似的转变：不再编写每一行代码，而是确保正确的代码被写出来。

但这里有一点容易被忽视：输出的责任并不会随工作量的变化而转移。当输出变得廉价时，意外后果也更容易被交付。

• 如果 AI 交付了糟糕的东西，那就是你的糟糕。
• 如果它遗漏了需求，那就是你的遗漏。

…

段落结束。

工程师 AI 放大

每一次重大技术变革都会产生一个 分化：

• 能够适应并使用新事物以提升自己的人。
• 不适应而被甩在后面的人。

陷阱

AI 让人产生以下诱惑：

• 利用它产出更多 而不 增加理解。
• 更快交付 而不 深入思考。
• 用产出量掩盖背后思考的浅薄。

那是一个陷阱。

真正繁荣的是什么

那些繁荣的工程师并不是产出最高的那类人。
他们是最懂以下内容的人：

• 系统。
• 业务。
• 权衡取舍。
• 决策背后的 “原因”。

你可能已经在做其中的一些：

• 你已经在进行架构权衡。
• 你已经在思考哪些变化会影响哪些方面。
• 你已经理解了新工程师不懂的东西。

AI 为你提供了在更大规模上运用这些理解的杠杆。
但如果你用它来 减少思考 而不是 更广泛的思考，你只会产生更多噪音，而不是更多价值。

指导

• 不要让 AI 替代你的理解。 让它扩展你的理解。
• 不要缩小你的角色。 让自己在其中成长。

学习你的系统。
学习你的业务。
学习事物为何如此运作的原因。

AI 让构建更容易。这意味着对理解的要求必须更高。