通过代理技能 (agent skills)，让团队人人具备主任工程师思维

最近看到前 Meta 主任工程师 Lauren Tan 跳槽到 Cursor 后，把她平时用来理解新代码库、理解陌生技术的流程，整理成了一组代理技能 (agent skills)。

非常推荐。如果你是团队里的资深工程师或主任工程师，用这种方式等于是在帮助团队成员探索问题时，都能用同一套思考方式去配合 AI 代理。

（备注：如果你还不熟悉代理技能是什么，可以先看这篇代理技能 (Agent Skills) 是什么？解决了什么问题？）

把思考流程化

例如，下面是 Lauren Tan 把“阅读代码”的方式转成代理技能后的内容：

先找到相关代码。用 Glob 找目录和文件，用 Grep 找关键符号，用 Read 理解真实实现。不要只看名称就靠猜，一定要读代码。按这个模式推进：
找入口：这个行为是怎么被触发的？是用户操作、API 调用，还是定时任务？先找出整个流程从哪里开始。
跟流程：从入口一路沿调用链往下追。每个函数都要读，搞清楚数据怎么流动、过程中又怎么被转换。
整理关键抽象：哪些类型、界面、服务或类是核心？去读它们的定义。弄清楚它们代表什么、为什么存在。
找边界：这个子系统和其他系统在哪里衔接？输入是什么，输出又是什么？
注意不直观处：有没有让你觉得意外的地方？有没有看起来像历史遗留的代码？有没有新人成员特别容易误解的点？
持续探索，直到你能完整描述全貌，不要含糊带过：如果遇到追不下去的部分，明确说出“我没法确定 X 是怎么连到 Y 的”，也比自己瞎编好。

看待抽象与复杂度的思考方式

以下是她在审视不同层级抽象时会问的问题：

每一层抽象代表的是现实中的真实概念，还是只是“以防将来可能会用到”的多余间接层？
抽象边界画对了吗？它们真的把会独立变化的部分分开了吗？
有没有不必要的耦合，让两个组件共享了不该知道的实现细节？
业务逻辑是和框架配置缠在一起，还是保持了清晰分离？

在看系统复杂度时，她还会继续问：

复杂度集中在哪里？是在真正需要复杂的地方（核心逻辑、棘手边界条件），还是在不必要的地方（样板代码、多余间接层、配置文件）？
有没有更简单的方法达到同样效果？
每个组件都真的有存在理由吗？还是有些只是旧设计留下来的残骸？

如果你想了解更多，可以看 Lauren Tan 的完整分享（链接）。

备注：如果你对如何帮助团队建立让 AI 成功落地的基础感兴趣，包括构建代理技能、复利工程（compound engineering）、有效降低 AI token 消耗成本等主题，我们在近期读者反馈很好的 E+ 《AI Coding 201 — 从实战到最佳实践》里都有详细讨论。我们也把 E+ 链接放在这里（链接），欢迎加入观看。