享受编程，依然没什么不对

yufenghuang009@gmail.com (Evan Wong) — Wed, 21 Oct 2026 00:00:00 -0400

原作者： Chris Kiehl

英文原文： It’s still OK to enjoy programming

原文发布： 2026 年 10 月 17 日

翻译与校对： AI 辅助翻译，Evan Wong 校对。

以下为中文译文，原文版权归原作者所有。

看了 Hacker News 上的讨论，我觉得有必要写下这句话：享受编程，依然没什么不对。

没错，在工作中，你拿报酬是为了给企业创造价值；从成本和收益的角度看，完全靠自己手写代码这件事，经济账确实已经和过去不同了。但那是工作。工作不等于生活。 互联网上声音最大的那群人，往往也最悲观，而这种悲观还格外容易传染。

为了给这一片绝望之海提供一个小小的反例：我周末依然会写程序，因为这很好玩。我最近正在学游戏编程！以我目前的水平，也就只能做出一个 Bug 一堆、碰撞检测烂得一塌糊涂的《打砖块》（Breakout）仿制版。我亲手写它，因为我乐在其中。我愿意花时间跟难题较劲，因为解决问题会让我开心。Claude 能一次就把它生成出来，我也不在乎——因为我做这件事，图的根本不是这个。

而且，我还常常写着这个所谓的“游戏”，就跑去研究一些不相干的编程话题。比如上周末，我借鉴了 Agda 这类依赖类型语言（dependently typed languages）的思路，想试试看能把 Java 的类型安全性推到什么程度。这事没什么实际目的。最终，它大概只会被我归进“思考某类问题的有趣方式”这个抽屉里。也许以后工作时能派上用场，也许永远用不上。我研究它，只是因为探索本身很好玩¹。

再往前几个周末，我研究的是递归模式（recursion schemes）。严格来说，那次并不好玩。我花了好几个小时跟这些概念死磕，简直像在拿脑袋撞墙。结果到最后，我甚至还没弄明白这些思想到底有什么价值²。但我知道，编程中许多最美妙的思想，都要在我脑海里酝酿好几年，我才能真正领会。这也正是为什么有人能专门写一整篇论文讨论幺半群（Monoid）。也许总有一天，我会遇到一个正好能用上这些思想的问题；也许不会。我之所以研究它，是因为理解艰深的事物，本身就会带来满足感。

我写下这些，是因为我越来越感受到一种奇怪的社会压力。仿佛我已经“不应该”再享受编程了。仿佛作为一个人继续学习、成长，已经既无意义，也无乐趣。你刷到的这种末日论调越多，就越容易被它感染。到后来，你甚至会不由自主地想：“也许真的没什么意义了。”可只要从网络上断开，这种念头就消失了。

享受自己喜欢的事，没什么不对³。你不需要拿经济收益来为这种快乐辩护。

原文与翻译说明

原文：It’s still OK to enjoy programming · Chris Kiehl。

AI 辅助翻译，Evan Wong 校对。译文保留作者的技术术语、引用链接和三条脚注；部分句式按中文阅读习惯调整。原文配图请前往原站查看。

延伸阅读：《智能体编程是一个陷阱》。

找一天花点时间理解一下 Fin 吧。它真的很美妙。 ↩︎
我还没领会到那一步，但研究它的目标，是为自己多添一种工具，以便从代数的角度推理程序的正确性（这个话题我也在我的书里讲过！）。 ↩︎
我玩 vibe coding（氛围编程） 也玩得非常开心。我已经做出了一套应用，却从没看过其中任何一行代码。我怀疑真要去看，恐怕会把自己吓坏。用这种方式“编程”同样很好玩，很多时候甚至好玩得不得了——只不过，它有自己独特的乐趣。 ↩︎

智能体编程是一个陷阱

yufenghuang009@gmail.com (Evan Wong) — Wed, 21 Oct 2026 00:00:00 -0400

原作者： Lars Faye

英文原文： Agentic Coding is a Trap

原文发布： 2026 年 4 月（原站未标具体日期）

翻译与校对： AI 辅助翻译，Evan Wong 校对。

以下为中文译文，原文版权归原作者所有。

“AI 负责写代码，人类则作为人类在环的‘编排者’。”

如今，整个行业都在热炒这种论调：传统的代码编写方式已经奄奄一息，规范驱动开发（Spec-Driven Development，SDD） 才是未来。你先生成一份计划，然后便不再亲手写任何代码。智能体比你更懂实现，所有实现工作都交给它们。你只需以专家的身份提供所谓的“好品味”，审查产出，并不断引导智能体按照你精心制定的计划执行。

如今，这套工作流已经演化出许多形态，但总体而言，流程都是：有人定义项目需求（从宏观到微观，同时兼顾两个层面），生成计划，然后一次又一次地拉动老虎机的拉杆，反复迭代，有时还会同时运行多个智能体实例，直到任务完成。在整个过程中，“编排者”与那些正在生成并提交的代码之间的距离，越来越远。

编程智能体（Coding Agent）确实有用，也确实强大。但它们已经带来了一些可以衡量、值得讨论的代价：

为了应对 AI 非确定性所带来的额外不确定性，周边支撑系统必须变得更加复杂。
相当一部分人的技能正在退化。
个人乃至整个团队受到供应商锁定（vendor lock-in）的影响。（Claude Code 一旦宕机，已经出现过整个团队工作停摆的情况。）
使用工具的费用不断波动并上涨。雇员成本相对固定，Token 成本却始终充满变数。

要想真正用好这种编程智能体工作流，关键在于一个极其重要的前提：只有具备扎实经验、能够进行批判性思考，并且能自如地在软件架构层面工作的开发者，才可能在几千行生成代码中的问题酿成后果之前发现它们。

但命运偏偏开了个讽刺的玩笑：已有研究表明，AI 工具恰恰会对人的批判性思考能力和思维清晰度产生负面影响。

不只是又一层“抽象”

社区里有个很常见的说法：程序员只不过是在“往技术栈上层走”，转向另一种抽象形式罢了。但这些工具究竟能否算作一个抽象层，本身还没有定论。不确定性变得更高，并不等于抽象层级变得更高。

暂且把这个争议放到一边，程序员确实向来对新语言、新编程方式心存戒备。当年 FORTRAN 问世时，程序员同样持怀疑态度。他们提出过类似的担忧：它可能引入更多 Bug 和不稳定性，直接写汇编反而更高效。后来，围绕编译器的普及，也有人争论它会不会给开发过程引入太多不可见的“魔法”。这些争论本质上是规范性判断：人们担心，一旦接纳了新技术，某些东西可能会因此失去。

但今天的不同之处在于，过去那些担忧主要还停留在猜测和理论层面。而 AI 工具出现不过短短几年，我们已经开始看见显著影响。受影响的不只是初级开发者，甚至包括拥有十年乃至更长经验的人：

开发者反馈：技能退化与 AI 依赖

以下保留原文引用的六张 Reddit 截图中可见帖文的中文译文；截图原图请前往原文查看。截图被截断的部分不补写。

截图 1｜r/ClaudeCode：因为 AI，我正在失去写代码的能力

在原文中查看这张讨论截图。

大家好。这个话题似乎讨论得不多，但即使我已经有好几年编程经验，过去一年多来经常使用 AI，还是让我对自己的编程能力越来越没有信心。

我感觉自己的技能确实在退化；与此同时，又觉得似乎已经没必要知道如何编程了。

这是怎么回事？

补充： 我还得再加几句。我认为，不理解语法本身就是一个问题。也许是我忽略了什么，但很多时候，要判断 AI 有没有搞砸、有没有引入隐蔽的 Bug，你就必须理解这门语言，知道如何用它编程。

语法与语言的运行机制及其背后的思想密不可分。所以在我看来，不理解语法，就意味着不理解代码，也就谈不上安全。

我不认同“AI 只是又一层更高级的抽象”这种说法，主要是因为它生成代码的方式具有非确定性。

截图 2｜r/webdev：因为必须使用 AI，我觉得自己变笨了、技能也在流失

在原文中查看这张讨论截图。

最近，公司开始强制要求所有软件开发工作都只能使用 AI。AI 写代码，接着由智能体审查代码。我们这些人被要求当“架构师”，只看结果，不看代码本身。

交代一下背景：我有九年工作经验，31 岁，是一个一岁孩子的父亲。所以我们就别提下班后再做业余项目这种选择了。

每当我把一切都交给 AI，我都觉得自己的能力在流失，自己正变成一个更差的专业人士。特别是当你想找一份新工作时，别人考察的主要还是你的技术能力。

你们怎么应对这种状况？怎样保持竞争力？怎样才能不开始讨厌这份工作？我只觉得自己被困住了，而且很快就会失去就业能力。

截图 3｜r/cscareerquestions：让 AI 写全部代码，感觉我的大脑都被烧坏了。救命？？？

在原文中查看这张讨论截图。

今年年初开始，我就一直在玩vibe coding（氛围编程）。但最近我发现，自己的整体认知能力和解决问题的能力都明显变差了。现在我进退两难：是应该像老派程序员一样去学编程、提高自己的技能，还是应该像其他人那样继续氛围编程，专注于扩大 AI 业务的规模？

我同意，刷 LeetCode 确实能锻炼认知能力，就像给大脑做健身训练。但我真觉得自己像被做了额叶切除术一样，因为所有费脑子的活都让 AI 干了。

可现实又像一场赛跑：大家都开着汽车，只有你在跑步。你当然知道，雇辆车来跑得比别人快，会让自己失去肌肉和力量；但你似乎又别无选择。

那我到底该怎么办？

截图 4｜r/webdev：依赖 AI 与认知能力下降

在原文中查看这张讨论截图。

我发现自己越来越常用 AI 来提高效率，或是安排日程，或是快速浏览代码，甚至是编写很小的代码片段。我能看出来自己越来越依赖它，同时也很清楚，对于这些简单练习，我已经不再自然地调动自己的认知能力了。

多年前，在进入开发行业前，我曾在健身行业工作。当时最先学到的一件事就是肌肉萎缩：一块肌肉如果长期不用，就会因为不再需要而退化。我相信，大脑和其他器官也是如此，而且确实有一些研究支持这一点。

我已经开始做一些练习，试着扭转这种情况。业余时间，我会每天花几分钟下国际象棋、用 Duolingo 学语言。

还有其他人担心这个问题吗？

刚入行的开发者面临的困境甚至更加严峻，因为我们正在剥夺他们直接与代码打交道的机会，转而让他们审查生成的代码。代码审查当然重要，但充其量只占学习过程的一半。如果失去了亲手处理代码时不可避免的摩擦和挑战，他们的学习能力就会受到严重影响。

截图 5｜r/cscareerquestions：团队里的初级开发者交付很快，但调不动不是自己写的代码

在原文中查看这张讨论截图。

我们团队的一位初级开发者上周只花两天就上线了一个功能。代码很干净，测试通过，交付也很顺利。可一周之后，一处本不该出现的地方冒出了 null。他花了大半天修 Bug，最后还是得来求助，因为他真的追不出那个错误值是从哪里来的。

提示词是他写的，代码是 Claude 写的。所以代码坏掉时，他脑子里根本没有可以依靠的心智模型；那只是一份碰巧归他负责的、别人写的代码。

常见的反驳是：“资深开发者也不写汇编了，每一代都在往更高层的抽象走。”没错，但我清楚自己写的代码是怎样一步步变成指令的。我见到的初级开发者，却不是仅仅隔着一层抽象，而是根本没有任何基础。他们扫描代码、检查运行、合并提交。

我总会想到的一个问题，就是调试这块肌肉。只有晚上十一点坐在自己写坏的代码面前，被迫想明白为什么事情没有按预期发生，才能把它练出来。如果你连续四年跳过这个循环，因为 AI 大多数时候都能把事情做对，那么你就到了资深开发者的水平，却只交付过很多东西，几乎没调试过任何问题。

补充一句：我不是说初级开发者不该用这些工具，那不现实。但用它们来加快自己本来就能做的事情，与用它们交付自己根本写不出来的东西，之间有很大的差别。而且我觉得，大多数人并不知道自己正处于哪一边。

截图 6｜r/ClaudeAI：招了个靠 AI 学编程的初级开发者。他离开 AI 就不会调试，我不知道该怎么帮他

在原文中查看这张讨论截图。

他们写代码很快，测试也都能通过，表面看起来没问题。但生产环境一出故障，他们就卡住了：追不出逻辑，读不懂栈追踪。如果不用 Claude 或其他 AI 代码审查工具（比如 CodeAnt），就不知道该怎么找 Bug；根本不理解代码实际上在做什么。

我试过结对编程，但他们只想把错误信息贴给 AI，再把修复方案复制回来。既不理解为什么会坏，也不理解为什么这个修复有效。

昨天我让他解释自己的 PR。他能描述代码做了什么，却解释不了代码是怎样工作的。他说：“Claude 写了这一部分，它会处理边界情况。”我问：“哪些边界情况？”他说：“不太确定，但测试都通过了。”

我开始觉得，我们正在培养一代能够交付代码，却没法维护代码的开发者。你们也有这种经历吗？还是只有我们如此？

研究这种现象需要时间，所以要想及时了解现状，收集个人经历这样的轶事证据很重要。但它也已经进入正式研究视野，并且有多项报告进一步支持：这种现象确实存在。

这一次，确实不一样。

当一名 C++ 开发者转向 Java 或 Python 时，他们并没有抱怨自己变得脑子不清楚。当一名系统管理员开始使用 AWS 时，他们也没有觉得自己正在失去理解网络的能力。

资深工程师转向管理岗位、写代码的机会减少，久而久之编码手感生疏，这并不是什么新现象。过去，这是一条自然而然的专业成长路径：一名工程师积累了几十年的编码实践、摸索与磨炼，有足够的时间和经验，将技能和判断沉淀下来。等工作重心从具体语法转向更高层次的架构决策时，他就能运用这些经验。然而，这样的人本来就极为稀少。如果我们所有人都不再经历亲手编写代码、解决问题、调试程序所带来的磨炼，下一代资深工程师又从哪里来？

而当下的趋势却是：那些还没来得及积累长期实践经验、没经历过三十多年摸索与磨炼的开发者，被直接推向更高层级的工作流，要求他们拿出资深工程师花了几十年才获得的技能，去管理 AI 智能体。

不过，资深工程师也无法幸免。拥有近三十年开发经验的 Simon Willison 也曾表示，他已经缺少一个“关于应用究竟能做什么、又是如何运作的牢固心智模型。这意味着每增加一项功能，推理它的难度都会进一步提高”。

“熟练的编排者”悖论

Anthropic 最近的一项研究里，谈到频繁使用编程智能体的风险时，有一段出人意料的坦诚表述：

编码技能的退化之所以令人担忧，原因之一是“监督悖论”……有效使用 Claude 需要监督，而监督 Claude 恰恰需要那些可能因为过度使用 AI 而退化的编码技能。

LinkedIn 的软件工程总监 Sandor Nyako 管理着 50 名工程师。他已经注意到这种现象正在组织内部蔓延，因此要求团队不要在“需要批判性思考或问题解决能力的任务”中使用这些工具。来源

“人要想提升技能，就必须经历困难。他们必须锻炼自己独立思考、把问题想透的能力。”他说，“如果一个人没有批判性思考能力，又怎么判断 AI 说得对不对？”

另一个问题是，究竟怎样才算“过度使用”？我们已经有数据研究和个人经历表明，这些技能可能在相当短的时间内退化甚至流失，有些案例只需要几个月。

这就是让许多 AI 鼓吹者陷入自相矛盾的地方：编程智能体的使用，正在削弱有效管理编程智能体所必需的技能。

大语言模型加速了错误的环节

与当下盛行的说法恰恰相反，我们未必需要更快地写出代码。尤其是那些我们没有完全理解的代码，更何况是大批量生成、根本无法在合理时间内审查完的代码。

在 AI 出现之前，一名优秀开发者的优先事项可能是：

理解代码，以及它与整个代码库的关系。
确保代码符合既定文档和高效、合理的工程规范。
在不牺牲可读性的前提下，用尽可能少的代码完成目标。
交付速度。

智能体编程，以及大语言模型总体上的使用方式，几乎把这张清单彻底颠倒了。

它们的能力展示和实际用法，往往聚焦于速度：在固定时间内生成更多代码。速度原本是高水平能力的自然结果；如果强行追求速度，就总会牺牲准确性。而这些工具的集成方式，很少把更深入的理解或更精炼的实现放在首位。

这些工具能不能按这样的方向使用？能。只要愿意下功夫，当然可以。

但人们真的这么用了吗？恐怕并没有。组织内部强制推行 AI，以及围绕 Token 用量的狂热宣传，已经很能说明问题。

写代码 === 做规划

开发者之间其实还有一道不那么常被提起的分野：我们中的一些人，恰恰是在写代码的过程中，才能更好地规划与思考。 用代码思考、在代码中工作，绝不是毫无意义的苦差事。它迫使你从技术层面思考问题，涵盖安全性、性能、用户体验以及可维护性等方方面面。

最近，在一次讨论“规范驱动开发”的访谈中，开源编程智能体 OpenCode 的创造者 Dax（没错，他自己就做了一个开源 Coding Agent）说过：

“当我着手做一件新事情，或者一件很有挑战性的事情时，亲手敲代码，就是我弄清楚我们到底应该做什么的过程。要我坐在那里，写一份巨长的规格说明，精确规定功能应该如何运作，我真的很难做到。

“我喜欢先写类型定义，喜欢写出几个函数可能怎样协同工作，也喜欢摆弄文件夹结构，看看不同概念应该如何组织。我认为，绝大多数程序员其实一直都是这样做事的。我看不出自己有什么充分理由要放弃这种方式，因为我就是靠它来弄清楚该做什么的。”

你说出口的，往往并不完全是你真正想表达的。 大语言模型会自行用假设（或幻觉）填补歧义。结果就是：需要更多代码审查、更多智能体修改、消耗更多 Token，而且你与实际造出来的东西越来越脱节。反过来说，即使你写出了一份自认为美得无可挑剔、毫无歧义、结构完美的提示词，大语言模型仍可能编造出一个根本不存在的方法。因为从根本上说，它是一个预测下一个 Token 的引擎，而不是编译器。你不能拿概率性系统替代确定性系统，却又指望它完全不存在歧义。

即使是那些最热衷 AI 的资深开发者，也已经开始意识到这种脱节正在变成一个迫在眉睫、而且不断扩大的问题。

“供应商锁定”

前段时间 Claude 服务中断时，我在 LinkedIn 上看到不少帖子，说某些开发者和工程团队已经完全停工。他们的工作流，乃至他们自己的编码能力，已经发展到高度依赖这些供应商的地步。原本只需要键盘和文本编辑器就能施展的技能，突然变成了必须订阅某家 AI 模型服务才能使用的东西。

顺着这个趋势想下去，并不难想象：我们可能正在创造一个行业，在这里，过去依靠独立思考和解决问题能力完成的事情，如今却必须通过付费购买 Token 才能完成。这有点像“供应商锁定”，但被锁住的是整个行业的技能体系（我敢肯定，模型供应商想到这里，正兴奋地搓着手）。无论是资金层面，还是智力与技能层面，这种支撑都可能随时被抽走；而本地大语言模型还远远没有准备好承接如此规模的需求。因此，我这里说的并不是被某一家具体供应商锁定，但“供应商锁定”这个概念，仍然与我们所看到的对这些系统的过度依赖密切相关。

这不是纯粹的理论猜测：如今就已经有人在报告这种情况。甚至模型提供商自己也在揭示这一问题。Anthropic 的另一项研究显示，调试技能出现了高达 47% 的骤降：

“在工作场所大规模引入 AI，尤其是在软件工程领域，必然伴随着取舍……开发者可能依赖 AI 快速产出结果，却因此牺牲了关键技能的培养——尤其是当事情出错时进行调试的能力。”

你没法预测自己的 Token 成本

模型提供商正在接受巨额补贴，模型本身也像建在流沙上。每次发布新模型，都重复着同样的循环：基准测试成绩亮眼，接着市场热炒，然后用户在实际使用中碰到现实，开始抱怨模型被“削弱”（nerfed），完成同样的工作却要多烧两三倍 Token。

你知道雇员要花多少钱，却不知道 Token 的费用会在每天、每月、每年发生怎样的变化。如果整个团队默认采用智能体编程，你的费用预算就得一直保持极高的弹性。正如 ThePrimeagen 最近所说：“当你使用这些完全由智能体驱动的工作流时，模型供应商实际上就控制了你。”

当然，有办法避免这一切。大语言模型是一项极具威力的技术进步。如果使用得当，它们完全可以成为帮助人学习、提升技能的绝佳工具。它们让我能够更深入、更广泛地钻研各种概念和技术，扩大自己的理解范围，也让我得以探索那些过去实验起来既困难又耗时的新想法。我认为，这才是它们能为整个行业带来的最有长期价值的贡献。

我的做法：降低 AI 的角色地位

我当然不是在主张，所有代码都必须靠人一个字一个字地敲出来。程序员一直都在想办法不必亲手写下每一行代码，就能创造出代码。这也正是我们会有 Emmet、自动补全和代码片段（snippets）的原因。就连 COBOL 当初的设计，也是为了用 MOVE、WRITE 这类近似英语的关键词，以更少的输入表达更多指令。jQuery 的口号更是“写得更少，做得更多”（write less, do more）。大语言模型只是这一整套代码生成工具中的又一位新成员。

但我真正主张的是：让大语言模型和编程智能体担任辅助角色，而不是为了生产力，把个人技能当成祭品。 你完全可以把流程反过来：让它们在规划阶段协助头脑风暴，而你自己始终深度参与实现，只在有需要时才把任务委派给它们。这样既可以享受生产力提升，又能减轻理解债务（comprehension debt）。

我的日常工作流

我让大语言模型协助生成规格说明和计划，由我来主导实现。 这和“编排者”工作流刚好相反；视任务而定，我仍然亲手编写 20% 到 100% 的代码。
和模型协作时，我经常会先写伪代码。 这样能缩短需求与最终生成代码之间的距离。
我把模型当成按需委派任务的工具。 它们可以临时生成代码、充当交互式文档，也可以作为研究工具，让我不断提问、迭代、重构，并理清自己的实现思路。关于任务委派的延伸阅读
我绝不一次生成超过自己能够一口气审查完的代码量。 如果内容太多，我就放慢速度，把任务拆小，必要时亲自重构，确保最终能够完整理解结果。
我绝不会让大语言模型或智能体直接实现自己从未做过、也没有能力独立完成的东西。 只有纯粹出于学习或教程目的时，我才可能例外，而且这类代码往往随后就会被丢弃。

如果一定要把这份清单压缩成一句话，那就是：把它们当成《星际迷航》里的舰载计算机，而不是 Data（数据少校）。（《星际迷航》的粉丝应该懂这个梗。）

我没有变得更快，但我正在做质量更高的工作

这些模型带来的生产力提升是真实的；而经常亲手参与工作所带来的磨炼，以及由此获得的理解，同样是真实的。

过去，人们无数次试图让不懂编程的人也能轻松编程，但都未能真正解决这个问题。如今摆在我们面前的现实仍然是：不亲自接触代码，就不可能真正理解代码。 而且现在已经越来越清楚，如果你不再持续地接触、编写代码，就可能渐渐失去这份理解。讽刺的是，这最终会让你连“编排者”都当得越来越差，使当前这轮 AI 编程热潮成了一段古怪而又徒增压力的插曲。

或许是我担心得太多，但历史值得借鉴

这一切总让我觉得似曾相识，仿佛我们又在自己身上进行另一场大规模实验。社交媒体刚出现时，我们同样没有弄清楚它的长期影响，就大规模投入使用；如今，我们已经面临普遍的注意力缺失等诸多问题。

而这一次，我们拿来下注的，是风险大得多的东西。

“现在就全面押注 AI 智能体的人，无异于在确保自己终将被淘汰。如果你把所有思考都外包给计算机，你就会停止提升技能、停止学习，也不再变得更有能力。”

—— Jeremy Howard，fast.ai 创始人

发表后补记

这篇文章获得的关注超出了我的预期。它似乎引发了 Hacker News、Reddit、daily.dev、YouTube 等社区的广泛共鸣。尤其值得一提的是，两位颇有影响力的内容创作者也讨论了这篇文章。

MIT 计算机科学家、《深度工作》（Deep Work）畅销书作者 Cal Newport 在自己的播客中谈到了它：观看视频。

知名 YouTuber、T3 Stack 创造者 Theo Brown 则朗读并评论了这篇文章：观看视频。

续篇：《AI 编程将阻碍专业能力的形成》

我从一开始就想把这篇文章写成某种“两部曲”。第二部分将着重探讨，这些系统对于正在成长的新一代开发者意味着什么：他们还没有足够的时间，来形成负责任地使用大语言模型所需要的技术品味和判断力。

你可以在我的后续文章中读到这部分内容：

AI Coding will Prevent Expertise｜AI 编程将阻碍专业能力的形成：为什么长期的技能培养离不开持续的磨炼

原文与翻译说明

原文：Agentic Coding is a Trap · Lars Faye。

AI 辅助翻译，Evan Wong 校对。译文保留原文结构、参考链接、引语、发表后补记和续篇链接。截图中可见帖文的中文转写作为阅读辅助保留；原文截图与视频封面请前往原站查看，视频使用外部链接。

术语说明：agentic coding＝智能体编程，coding agent＝编程智能体，vibe coding＝氛围编程，cognitive debt＝认知债务，comprehension debt＝理解债务，orchestrator＝编排者，Spec-Driven Development＝规范驱动开发，vendor lock-in＝供应商锁定。

延伸阅读：《享受编程，依然没什么不对》。

中文译文 on 蜂窝

享受编程，依然没什么不对

原文与翻译说明

智能体编程是一个陷阱

不只是又一层“抽象”

开发者反馈：技能退化与 AI 依赖

这一次，确实不一样。

“熟练的编排者”悖论

大语言模型加速了错误的环节

在 AI 出现之前，一名优秀开发者的优先事项可能是：

智能体编程，以及大语言模型总体上的使用方式，几乎把这张清单彻底颠倒了。

写代码 === 做规划

“供应商锁定”

你没法预测自己的 Token 成本

我的做法：降低 AI 的角色地位

我的日常工作流

我没有变得更快，但我正在做质量更高的工作

或许是我担心得太多，但历史值得借鉴

发表后补记

续篇：《AI 编程将阻碍专业能力的形成》

原文与翻译说明