熟练掌握仍然来自反复练习

精通依然来自反复练习。

在有智能体之前，我通过写代码来积累“练习量”：尝试不同的方法，调试哪里出了问题，审查别人的代码，大量阅读。智能体能跳过其中很多工作，所以你必须有意识地构建自己的练习量。

如果我是这个行业的新手，我会先形成一个假设，再去提示 AI。多问“为什么”，读懂 diff，尝试预测哪里可能会失败。偶尔也亲手手动把问题推演一遍。

你的 AI 智能体可以访问数据库。你能看出它做了什么吗？给智能体一个 Postgres 登录凭据，它看起来就和任何其他角色一样——一个共享的、长期有效的凭证，根本没办法知道是哪一个智能体执行了哪条查询。现代的解决办法是身份：将访问权限限定在任务范围内，任务结束即失效；同时保留审计轨迹，把每条查询都关联到具体的智能体（以及其背后的真人）。Teleport 正是围绕这个模型构建的——基于身份的基础设施访问，没有静态凭据。如果你的智能体会接触生产数据，这篇值得一读。阅读更多 · 由 Teleport 赞助。#ad

根据我的经验，优秀的智能体工作依赖两种能力：

深厚的专业知识： 你对问题领域有足够深入的理解，能够定义什么才算好的结果。理解用户、产品、业务，也是其中的一部分。
落地的判断力： 运用你的品味，通过选择合适的上下文、约束、测试和验证，把问题转化为清晰、可检验的计划。

要培养这些能力，我会练习的是决策、需求定义、引导和验证。

我真正做过的练习量

刚开始做软件工程时，我非常强烈地觉得自己根本不知道自己在干什么。我很享受构建东西、尝试各种方法、失败、从错误中学习，并在每一次过程中都比上一次更进一步。每次失败，我都努力把它当作成为更好工程师的一块垫脚石。所以这些工作，都是我在做“练习量”。我就是这样学会 JavaScript 的，也是这样学会用 C++ 编程和构建桌面应用的。也是这样学会调优图形密集型应用性能的，诸如此类。

在积累练习量的过程中，我经常会带着某种假设或想法进入一个任务，即便那种想法在事情可能如何运作这件事上错得离谱。我会先尝试我认为可能可行的方案；如果不行，我就去 Stack Overflow 或者上网查找不同的文档，吸收一些知识。如果是特别冷门的话题，我可能还会读书。然后我继续前进。这样的过程重复足够多次后，你就开始建立起专业能力，尤其是当你开始真正做真实世界的项目，而不只是周末随手捣鼓的兴趣项目时。

我今天使用的大部分判断力，都来自成千上万次这样的微小练习：调试失败、审查别人的代码，以及和那些看起来很美、却在真实系统面前暴露出问题的抽象概念共处。如今，智能体可以跳过其中很多工作。如果你才工作三年，也许产出“看起来合理”的代码会比你判断它是否合理更快。

短路

现在，我认为对于很多刚开始接触 AI 的人来说，你可以把大量学习路径“短路”掉。你可以非常快速地从“嘿，这里有个问题”直接跳到“嘿，这里是解决方案”或者“这是整个任务的结果”，而跳过那些本来会帮助你建立知识库的过程，或者帮助你理解“别这么做”——为什么不能这么做、应该怎么做，以及帮助你思考权衡取舍。我认为，在这个领域，尤其需要初级工程师主动推进自己的学习旅程。

我也和几家不同的 AI 实验室聊过。现在 AI 领域的很多主流玩家都非常专注于帮助你尽快达成结果或得到答案；除非你明确把“教育过程”设为目标，否则他们未必会真的帮助你学习。比如，我说“嘿，帮我做一个排程应用”，和“嘿，帮我做一个排程应用，并且在过程中教我怎么做，一步一步来”，这两者是有区别的。大多数人不会去做第二种。部分原因是他们不知道这是一个选项；部分原因也许是觉得，眼下到处都是速度要求，大家都在逼着你快点交付、然后赶紧进入下一件事。但我确实认为，要成为更好的工程师，要继续积累那种能提升品味和判断力的专业能力，你就必须有意识地去打磨精通。

完成一个任务，不一定算一次练习

我认为，对于任何一种批判性思考、任何一种你面对的问题，先对解决方案形成一个假设、对它可能的样子有个预期，都是很有用的：如果谈的是逻辑和代码，就想想它的形状；如果是一个 UI 组件，就想想它看起来、感觉起来、交互起来会是什么样。**任务完成了，并不一定意味着你学到了什么。**它只是说明任务完成了。你几乎需要主动去寻找那些学习机会，或者在智能体构建过程中、或最终，让它总结一下：这次任务有哪些关键收获，能帮助我作为一个中级开发者，或者初级开发者，扩充知识库，或提升我思考问题的方式？你可以持续这样做。只是你必须在学习旅程上主动一些。

对我来说，如今我能用 AI 做很多事情，其中更复杂的 3D 图形编程绝对算一类。我不是专家，而且我确实会经常确保自己在问 AI：好，这个东西到底是怎么工作的？你能教我你刚刚实现的这个概念吗？你能帮我推理一下这些不同元素是怎么连接起来的吗？我认为，正因为我想学、并且有这个学习欲望，我才会和智能体结对完成这件事。如果你并不是特别想学习，你就会错失这些机会。

一个任务完成了却不算一次练习，这件事也会发生在过程里没有出错的时候。出现错误时，你就会开始思考：为什么会出错？哪里可以更好？我是不是漏想了什么？这会迫使你反思。而当一切顺利时，那里其实没有什么教学时刻。你只会想：好，工作做完了，我接着做下一个任务。所以，尤其如果你是初级工程师，你就要去寻找这些机会，不断升级自己。

Anthropic 在 2026 年做过一项研究，对象是学习某个 Python 库 Trio 的初级工程师。**使用 AI 助手的人在后续测验中的得分是 50%，而徒手工作的那组是 67%。**在 AI 组内部，表现好的，是那些提出概念性问题并要求解释的人，而不是把模型当成代码自动售货机的人。这也正好呼应了我前面说的：如果你只是用 AI 生成输出和结果，而不是把它当作结对伙伴，不是用它来提升批判性思维、知识能力、对系统如何运作的理解，那么最后你很可能会陷入这样一种情况：你大致上并不理解这些东西怎么运作，但你很擅长写提示词。这也意味着，你可能并不真的擅长验证这一环。我对那些会提问、会要求解释的人表现更好并不太意外。这些人大概对事物如何运作、它如何与自己已有知识连接，会有更多反思。他们会做模式匹配，开始积累一些沉淀：好吧，这东西是这么工作的，我是这样推理它的，我的知识缺口在这里。所以我觉得这个 17% 的差距是说得通的。当然，这只是一个短期研究，而且只针对一个 Python 库，所以我不认为它一定具有决定性，但它依然非常有意思。

当我学习陌生事物时，我现在依然会这样工作。我会尽量让自己始终在流程里。提示前先形成假设，多问为什么，检查 diff，预测哪里可能失败，并给智能体一个具体的方法去验证它的工作。偶尔我也会亲手解决一个小问题。我希望智能体能完成任务，同时我的心理模型还在持续运转。

不过还是要积极使用它们

我不知道代码层面的专业能力还会像今天这样重要多久。模型进步太快了，很难有把握。我也不认为答案是避开智能体，或者浪漫化每一行代码都亲手敲出来。我会很积极地使用它们。有些日子里，我会同时开着五到十个会话。有一次我甚至发现自己让错误的项目去加深色模式。这个错误让我看清了一个约束：智能体的吞吐量扩展速度，比我的注意力更快。

性能面板里的千小时练习

我能想到有些事情，过去我确实花了成千上万小时才掌握好。性能优化就是其中之一。放在以前，你并不总能找到很多优质的博客文章或书籍去参考。关于这些主题，确实有一些还不错、非常经典的文献，可能会涉及内存，或者如何看待硬件与约束。但像 Web 性能优化、JavaScript 优化、堆优化，这些东西，并不总有很好的文章可读。所以你只能去 Chrome 开发者工具里，使用性能面板对页面或应用做一次 trace，和它交互，尝试找出慢在哪里。然后继续深挖，形成假设：好吧，看起来火焰图里这个区域似乎是主要问题所在。或者在内存面板里，可能是我没有让垃圾回收发生之类的。那时候，你必须经历足够多次的试错，尝试找出根因，才能建立起这些知识——有时还是相当冷门的知识——去理解什么有效、什么无效。

如今，一个类似的流程可能是：通过 DevTools MCP，让你的智能体替你做性能剖析，自己把问题梳理出来，然后连修复方案也由它直接给你。这样一来，你未必还能同等程度地积累性能方面的专业能力。

你只能提示你能想象出来的东西

如今我刷 Twitter 时，总会被信息流里的想象力和创造力震撼。太多设计师、创作者在分享惊人的 shader、惊人的游戏、UI、沉浸式体验，而且现在它们比以往任何时候都更可实现。技术其实早就有了，但现在的天花板变成了想象力。你可以更快、更轻松地把这些东西做出来。但你首先必须具备那种想象力，才能想到这个点子并告诉你的智能体去实现它。然后你还必须具备足够的专业能力去验证它。所以，验证是地板，想象力是天花板。

我记得有一次，针对一个即将上线的专辑网站（我做音乐），我想让主页的一部分变成那些可交互的 3D 对象，作为体验的一部分。比如 3D CD 播放器，我记得里面好像还有一个黑胶唱片机，也许还有磁带机，带着一点 90 年代怀旧风。可最初的版本不仅不好看，交互模式也不对。在移动端上表现也不够好。所以我首先得有足够的专业能力，意识到它在某种程度上有 bug。也许任何用户都能看出来。但随后我会形成一个关于原因的假设。然后我可以自己去做性能分析，或者让智能体替我分析，弄清楚发生了什么、哪里出了问题。也许只是交互逻辑的某种写法不太好。所以我认为，想象力真的很重要，但专业能力同样重要。这两者都重要。你能想到，就能做出来。

下一代还需要这些专业能力吗？

有一个合理的问题是：如果智能体可以完成这些任务，而且越来越好，那人类还需要去积累这些专业能力吗？下一代还需要在这些冷门领域里建立专业能力吗？我认为，至少在今天，这种能力依然有价值的地方，是那些智能体做得还不够完美、需要被检查的场景。当你让它优化某个循环、某个动画、某个调度例程，或者类似的东西时，它也许会以牺牲别的东西为代价。如果你不知道该看什么，或者你不知道如何阅读实现、理解它到底做了什么，那你最后可能会交付一个实际上并不是你想要的东西。

技能和 MCP 可以编码出一套有用的工作流，但它们无法告诉你：它的假设什么时候已经不再适合你的系统。

Anthropic 曾对大约 40 万次 Claude Code 会话做过一项研究，把专业能力看作一种任务特定的东西。研究发现，即便只是对你要完成的任务具备中级水平的专业能力，也会提高你在该任务中达到“已验证成功”的概率，相比更偏新手的人更是如此。这并不意味着你必须对整个技术栈有十年的经验，但这确实意味着你需要对问题领域有足够的理解，才能识别“什么才算好”。我们现在有时会用“品味”来形容这件事，我之前也写过。这也是为什么当我读到Claude Code 最佳实践指南时，会很高兴看到它一上来就谈验证：测试、截图，以及其他能给智能体提供继续迭代依据的信号，并给你留下可供审查的证据，而不是只给你一句“任务完成了”的简单总结。拥有专业能力，会比缺乏专业能力、却也许只能做出“看起来还行”的东西的人，更能把一团泥塑造成形。

这一切都回到：你需要具备专业能力，才能验证工作，才能判断智能体的工作。所以我希望，我们在软件工程不断向更高抽象层迈进的同时，依然可以继续投入精通，继续投入工艺。

专业能力的回报正在提高

我觉得，软件工程的基本功会继续重要，专业能力也会继续重要。而且既然门槛已经被抬高，AI 也在提高人们技能和专业能力的回报。初级工程师之所以不再只是初级，是因为他们通过交付真实的东西、犯错、学习、积累练习量，才成长起来。专家则会对该做什么、如何验证、如何确保它确实是好的、没有坏掉、可维护、可扩展、能在不同上下文或平台中工作，拥有一种直觉。尤其是在现在，很多人都能通过提示把一个想法变成现实时，要把它做得高质量、足够好到可以发布、令人愉悦，并且可维护、不会在生产环境里崩掉，这些能力会继续很重要。

这类情况我每周至少会遇到几次。现在给任何类型的应用、任何类型的功能写提示都太容易了。比如，我目前正在做一个文本编辑器，不是从零开始。它的想法是做一种写作辅助工具，能高亮语法可以改进的地方，或者提醒你不要用 AI 风格的写法，类似这样。一个前沿模型在大量来回调整后，帮我生成了一个看起来不错的 UI。它不算惊艳，但它确实有很多问题，比如没有充分利用屏幕空间，没有好的颜色对比，也没有好的滚动模型。这些问题我之所以知道，是因为我以前犯过这些错，我已经积累了专业能力。但如果你没有这种专业能力，你可能只是提示一通，把东西扔到世界上，然后就停了。因为你没花时间积累这些专业能力，所以你甚至不知道什么更好。

把教训放到下一个智能体找得到的地方

我在指导别人时经常说的一件事是：当你和智能体协作时，你应该让它变得更好，它也应该让你变得更好。这意味着，每一天都应该有某种循环，让你把东西加入“经验教训”或者记忆，或者别的什么地方，使其能够不断改进。否则，每次开启一个新会话，你都可能感觉像是在给一个失忆的新员工做入职培训。它未必记得你的业务、你的产品、你的团队、你的用户，以及这些事情的细微差别。所以我们才会把那么多东西记录下来，不只是技能，还有上下文，以及我们努力给智能体提供的各种材料。而且我们需要谨慎区分：什么东西是真正有用、真正针对问题的，什么东西只是我们以为有帮助。所以我总是鼓励大家思考：你如何确保自己在更多地教会智能体，并确保每天它都在进步、你也在进步？

如果你正在一个聊天窗口里解决问题，比如说，你发现自己正在处理的一个 UI 组件有某种细微的滚动 bug。你和智能体来回协作，过程中其实藏着一条未来可能会用到的教训。现在，这条教训也许会被加入记忆，也许不会。尤其如果这是一个很长、且发生了压缩的会话，这条完整教训未必会真正保留下来。于是，那个教训可能会随着聊天窗口消失而丢失。相反，如果你尝试把具体经验、测试、lint 规则，或者任何足够小、可以被写进仓库的东西制度化，它们就能教给未来的智能体。我个人发现这非常有帮助。如果我学到了一课，我会花几分钟回顾一下，看看值不值得把它加进我的 lessons.md，或者让智能体把它加入记忆，或者做成某种能让它记住的东西。因为我不想让教训消失。我个人会忘记，我会转向下一个问题。这种情况对我来说非常常见。内容可以从“我在 UI 上有某种特定偏好”，到“我如何写组件”，到“我如何处理性能”，方方面面都有。如果我用某种细微方式解决了问题，我希望智能体能记住它，或者至少有办法记住，而不是让我每次都得重新说一遍。

我们很常把智能体当成会记住我们所做一切的东西，但事实未必如此。即便智能体有记忆系统，你也不能完全依赖它记住你可能在尝试学习的那些有趣内容，或者你喜欢的工作方式，或者你如何进行验证。所以，把更多这些东西记录在 Markdown 文件里是可以的。只是一定要非常小心，不要把它当成一种过度投资的策略。我一直喜欢“双循环”这个想法。**一次好的练习，如果你从中学到了东西，应该既能磨炼你，也能磨炼你的智能体。**而当某个本来可能被纠正的假设被修正后，你可以考虑这次修正是否值得变成一条 lint 规则、一种类型约束、一种文档约定，或者一个测试，这样它就能留下来，并在未来继续帮到你。

外循环

所以我认为，关于精通，这一切意味着：投资你的专业能力和工艺。做练习，犯错误，从错误中学习。随着时间推移，你会逐渐弄清楚什么值得存在。你会开始写计划、优化计划，形成对“完成”意味着什么的定义，同时也会为那些仍需要人类留在流程中的地方做规划，以检查正确性、安全性或用户影响。我认为，这将主要是今天工程师需要负责的外循环。我们会继续看到 AI 把工程工作推向更高的抽象层。而我能运行的智能体越多，我就越需要谨慎选择，我有限的时间、品味和判断力应该投向哪里。