这是一个智能体的世界。

软件工程正在经历一场我们所有人都仍在努力理解的 AI 革命。多年来，我们一直被告知软件工程师距离灭绝只有六个月。有些人仍然相信这份工作正在消失。另一些人则说它只是在改变。

我的经验表明是后者。

我对 AI 的恐惧

我看到工程师的优先事项发生了真正的转变，但这份工作本身仍然非常需要。在 Criteo，工程师仍在被招聘、仍被重视——而且越来越多地被要求尽可能依靠 AI 智能体来提升生产力。但每一条这样的信息都附带同样的补充说明：牢牢握住方向盘。使用工具，但不要停止了解你在做什么。

作为一名刚出校门的初级工程师，“仍在学习自己在做什么”并不是什么附加说明——它就是这份工作的定义。所以，让一个智能体不仅替我完成工作，还替我学习，这很诱人，也有点危险。毕竟，它懂的比我多得多！

在学校里，我们被教导说，要在这份工作上变得更好，方法就是写代码。现在我们被告知，如果可以的话，不要直接写代码。那么——我们该怎么学习？这才是我真正害怕的灭绝：不是软件工程师消失，而是资深工程师消失——因为我们都变成了永远的初级工程师，永远只够资格在另一个智能体的帮助下审查一个智能体的工作。

那么我该怎么做呢？

我从研究两个问题开始：

  • AI 究竟改变了我的工作定义中的什么？
  • 具体来说，什么是资深工程师？

为了回答前一个问题，我只需要听听网上和工作中讨论。很多人说，现在审查代码比产出代码更重要。共识似乎是，学习编码语法和语言已经过时了。当然，公司希望我们专注于像 token 管理这样的事情来优化成本。

对于后一个问题，我观察了工作中的资深工程师，尤其是我团队里的，并从中总结出一些关于「资深」意味着什么的关键点。在我的团队里，资深工程师是那些能为自己交付的代码辩护、能为一个设计选择据理力争而不只是随便选一个、能判断智能体何时走错了方向、知道何时该委派他人何时该自己动手——并且愿意花时间教我们其他人的人。

带着这些准则，我画出了一张自己需要成长的地图，第一个里程碑就是在年底前获得晋升提名。沿着这张地图走，我希望有一天能到达资深之境。

下一个问题是：怎么做。显然，我需要培养技能。

我像很多工程师一样，开始写一个 skill.md：把指令和模式喂给模型，让它更像一个导师，教我资深工程师的行为。这确实有用。但在这个过程中我注意到，真正的差距不在我的智能体的行为上——而在我的行为上。所以这篇文章的重点其实并不是我写的那些技能，而是我为了跟上我和智能体一起开发的技能，而不得不在自己身上培养的那些技能。我相信正是这些技能，才能真正让我从初级成长为资深。

质疑

我一开始让我的智能体向我提出苏格拉底式的问题，来检验我对计划或代码本身的理解。每次做决定或改代码之后来一场小测验。实际上，这些问题只有一半的时候是切题的，而且它们主要的作用是促使我仔细审视计划或代码，并与智能体交流，确保我确实理解了它。

# 理解检查与委派工作
-After implemented work, prompt understanding—rotate style: e.g. explain in their own words, predict what breaks if X changes, walk through one failure mode, defend a trade-off in one sentence. Gently correct and re-check if needed.
-Subagents or delegated tasks must follow the same rules: no unconfirmed mutations and no unconfirmed mutating verify (subject to the same-task verify rule after approved implementation).代码语言： Markdown （markdown）

就在那时，我注意到我正在培养一项属于我自己的、人类的技能。一项每个五岁小孩都已经掌握的技能——他们会不停地问「为什么」，一遍又一遍，直到有人投降。

好奇心。

LLM 最大的本事就是它能用你的语言回话——所以要利用这一点。让你手下的智能体解释一个你跟不上的决策。让它在不熟悉的名词上引用来源。让它为一个感觉不对劲的建议给出理由。最后一点才是真正的诀窍：让智能体把有缺陷的方案大声讲出来，往往就是它自己发现错误的方式——也是你发现错误的方式。

Senior 能为自己已上线到生产环境的代码辩护。他们能论证自己的设计选择。他们能看出智能体走错了方向并把它拉回来。多质疑你的智能体，你其实就是在演练这件事。

没错——这会消耗 token。合理。但我发现，在这里放慢速度总体上更高效，因为我在发布前真正理解的代码，在生产环境中能正常工作的概率高得多。而当它出问题时，我也能自己修，而不是再和智能体来回折腾一遍。我宁愿少用一点 AI，但每次用的时候都真正保持好奇，也不愿推送只理解了一半的代码，然后在之后付出代价。

审查

如果你尽可能多地用智能体写代码，那你大部分时间反而会花在审查它的产出上。审查本身就是一项技能——可以说是在这个 AI 时代里，你真正迈向 Seniorhood 最需要的那一项。好消息是，你早就坐拥一套现成的训练集：Senior 在你代码上留下的每一条评论。

留意其中的模式。总是收到关于命名的意见？你的团队显然很在意命名规范——把智能体代码里的每个名字都检查两遍。做得足够多，你就会开始注意到那些你所在行业、你所在公司、甚至你所在团队特有的实践。有了这些，你就可以练习模仿。

# 与现有代码的相似度及可复用性
For each substantive task:
1.Discover — Search the codebase (and/or ask the user) for the closest existing feature (same kind of entity, resource, table, API surface, etc.).
2.Align — Summarize candidates; ask which analogue is best. If nothing fits, ask the user to confirm the work is net-new.
3.Anchor — State the chosen reference (paths, components, patterns) and keep it for the rest of the thread.
4.Plan and implement (when confirmed) — When outlining or implementing, call out divergences from the reference. If the reference is one-off, ask whether a small shared abstraction could serve both without over-engineering.
5.Information gaps — If the user omitted details the reference implies (fields, ownership, API shape), ask before assuming.代码语言： Markdown （markdown）

我的团队负责一个产品目录。每次我在里面新增一种实体类型，Senior 们都会说类似“这看起来很像我们已经有的那个”的话。于是我开始把已有的那个实体当作模板——当我提交代码供审查时，我看着审查者仔细审视与模板实体的每一处偏差。这个模式再明显不过：为任何偏差给出理由，能复用就复用。一旦我看清了这一点，我就能自己应用它，在同事不得不审查之前先审查我的智能体的输出。

我更进一步，把这个模式写进了我的 skill——这次是 markdown 文件那种，直接喂给智能体。现在在我打开审查之前，它就已经把这个模式记在心里了。你也可以更进一步：把 AI 指向你自己的 git 历史或团队聊天记录，让它为你浮现出那些审查模式。

有趣的是，这正是两种含义的交汇：我构建了一个 skill，好让我在某个 skill 上变得更擅长。这个文件让智能体的初稿看起来更像我们团队的代码；但无论如何都要一遍又一遍地审查那份初稿，正是这一点慢慢把我变成一个更好的审查者。到最后，但愿我不再是一个带着优秀 skill 文件的 Junior。我会成为那个写下这些评论、并让它们进入那个文件的 Senior。

手写

我很遗憾地报告，对我帮助最大的事情，是有时假装自己回到了学校考试，在那里使用 AI 之类的工具就是“作弊”。这就是你培养 Senior 们早已烂熟于心的那个技能的方式：自主性。

Senior 们多年来在没有智能体的情况下做这份工作。他们能论证一个设计选择，因为他们不得不自己做出那些选择，并与之共存。他们能判断出智能体何时走错了方向，因为他们曾经在没有智能体的情况下写代码。让一个智能体时刻坐在你旁边，可能会让你无法采用这种“被扔进水里学游泳”的方法。我认为这是一种值得时不时尝试的方法。

我实际上把一条约束直接内置进了我的skill.md中：在我明确确认计划之前，它不允许触碰任何文件、运行迁移或提交任何内容。只读探索，当然可以——搜索、解释、提议。但一旦到了真正要写代码的时候，它就停下来等我。

## 只读（始终允许）
Search, grep, read files, list directories, and any non-mutating inspection are allowed without implement confirmation. Use them for discovery, teaching, and finding analogues in the codebase.

## 变更（先确认）
Do not edit files, apply patches, git commit/push, install dependencies, run migrations, write config, or run state-changing shell until the user confirms implementation of a concrete plan (files, areas, commands)—not merely answering a Socratic question.代码语言： Markdown （markdown）

理论上，那个暂停应该就够了。但实际上，它一开口问，我就立刻说“继续吧”，这情况反复发生，也没让我学到多少东西。所以偶尔——很少，且刻意为之——我会利用那个同样的暂停，真正自己动手做改动。把它当作一次测试：小到不会拖垮你的产出，又重要到确实算数。我建议针对一个你已经交付了大半的功能做一次小调整。不需要任何上手引导，而且它能检验你对智能体所写——以及你所审查——的一切的理解。

我发现这在几个具体方面带来了回报：

架构

设计仍然是这份工作的核心技能，而且恰恰是你可能在不知不觉中悄悄失去掌控的那一项。亲手与智能体搭建的架构打交道，会迫使你真正感受到它哪里不对——而看清一个设计为何失败，是构建更好设计的第一步。一个对系统负责的资深工程师，是那个知道它为何长成这样的人。

算法理解

当你只是审查时，你往往知道是什么，却未必总知道怎么做——直到有人问一个澄清性问题，你不得不去查。一次手写的改动会迫使你自己面对这些问题，赶在它出现在生产环境之前。当场回答那个问题，而不去查，是资深工程师的做派——而它是一次次手写改动积累起来的。

Token 效率

这一点是新的，而且它让公司花真金白银。你可能会问，当你完全不用 AI 时，怎么去了解 token 效率？因为理解你自己的代码和架构，正是你在 token 使用上做到有的放矢的方式。它直接关联到前面两点：

  • 知道东西在哪：文件查找很昂贵——你越清楚东西放在哪里，花在找它们上的消耗就越少。
  • 知道怎么做：有些活儿手工做仍然更快。你的 IDE 能瞬间在整个代码库里重命名一个变量。如果你知道怎么做，你就已经掌握了那次改动的波及范围。所以没有理由花 token 去逐个找文件再逐个重写。

资深人士知道何时该委派，何时该亲自动手。你需要同样的直觉——即使你委派的对象是一台机器。

自信

算是一项附加技能，但却是实打实的技能。我听过各个级别的工程师说，他们再也回不到没有智能体辅助的编码方式了。偶尔还是亲手写一写，正是让你记住智能体只是帮你更快完成工作的工具——而不是让你彻底丧失工作能力的替代品。检验这份自信，确保它是靠实力赢得的。说实话，我入这行就是因为喜欢写代码。偶尔亲手写一写，依然是我最享受的部分，这本身就足够成为理由了。

我信任的那些资深人士，他们的自信并非来自拥有一个智能体。他们的自信来自即使没有智能体，他们依然能出色地完成工作，而且他们心里清楚这一点。这才是值得追求的目标。

带新人

无论 AI 变得多强大，或者你用得多熟练，都替代不了来自真正资深人士的指导。你是通过和资深人士共事，才学会如何成为其中一员的。资深人士必须花时间解释事情，你才能成长到那个水平。我们不能忘记，我们以团队形式工作是有原因的。

协作是这份清单上的最后一项技能。

你可能会觉得这是唯一一项根本无法内置到智能体里的技能——但我还是试了试。我的技能实际上会提醒我，每当一个决定其实是团队决策或需要判断力时，就去请教资深人士，它甚至会帮我起草 Slack 消息。但我发现，照抄那条 Slack 消息，是一条滑向连答案也照抄的滑坡。很快，你就只是在做一份好的 Slack MCP 就能完成的工作，而这才是真正的 AI 接管。是你自己放任它发生的。所以，用你对问题的理解和自己的疑问，亲手起草你的消息。你甚至可以把草稿发给 AI，让它在联系资深人士之前纠正你的理解。但不要害怕犯错。你联系那位资深人士，就是为了让他们帮你理解。他们的职责就是指出你的错误。

做个热切、不怕问蠢问题的实习生。急着冲向下一个阶段很诱人，但你当下所处的阶段自带一些值得趁还拥有时好好利用的东西：那些职责之一就是照看你的人。前辈们肩负着我们还没有的责任——为我们指路。没有哪个 Junior 是靠一个人在房间里练习就能成为 Senior 的。我们需要已经在那里的人告诉我们什么才算“好”，并在我们犯错时纠正我们。

当然，读到这里你可能是一位 Senior，心想 Senior 的岗位描述也随着 AI 变了——尤其是指导 Junior 这部分。在智能体时代指导 Junior 本身就是一项挑战，值得单独做实验——而我不是做那个实验的合适人选。不过那篇文章我会读。那是我通往 Senior 之路上更靠后的另一项技能。

结果

所以——skill.md还是技能问题？我开始了自己的小实验：每次使用智能体时都召唤一下我的技能。现在，我一天几乎只打开它一次。

当我写下那个 markdown 文件、列出我希望智能体表现出的所有方式时，我其实是在写下像我这样的 Junior 软件工程师应该表现出的所有方式。随着我自己把这些技能一点点建立起来，我越来越不需要那个智能体了。

好奇心、模仿、自主、协作——这些都不是智能体给的，有没有技能文件都一样。它们来自你在智能体运行期间选择去做什么。这才是这里真正的主线：以上每一项，都是一种让自己继续做自身学习主动参与者的方式，而不是别人产出的被动审阅者。智能体可以写代码，它甚至可以写问题。但如果你不想被踢出这个循环，那些练习得你自己做。

当然，这四项技能并不是全部。界定工作范围、估算工作量、凌晨 2 点处理事故、知道什么不该做、在跨团队间推动决策、指导 Junior——Senior 也都要做这些，而这些都是我希望有朝一日能建立的技能。眼下我在一步步来，而且我很高兴地说，我已经完成了第一个里程碑。我在 AI 和技能建设上的实验，帮我比计划中更早地拿到了那次晋升提名！

所以继续问“但为什么”。继续留意你的评审者总是反对什么。继续保留你手动做出的那些罕见而刻意的改动。这些都不会像你以为的那样拖慢你的速度——而正是这一切，把一个能评审好代码的初级工程师，变成一个能写出它、解释它、并在某一天把它传承下去的高级工程师。

而高级工程师们，我们需要你们的帮助才能到达那里。我们正在摸索如何在智能体时代继续学习；我很想读一读你们是如何摸索在这样一个时代继续教学的。但我们谁都无法独自做到这一点：学习的空间，是初级工程师必须去争取、导师必须去给予、领导层必须去允许的。智能体无法创造那个空间。人才能。