OpenAI创始团队成员Karpathy谈编程：“我从未如此感到落后”
安德烈·卡帕西（Andrej Karpathy）在斯坦福大学获得博士学位，师从李飞飞，曾领导特斯拉自动驾驶系统（Autopilot） 的计算机视觉团队，负责开发从感知到决策的核心深度学习技术，对特斯拉的自动驾驶技术演进起到关键作用
作为程序员，我从未感到如此落后。这个职业正在经历剧烈的重构，程序员贡献的代码片段越来越零散，彼此之间也越来越疏离。我隐约意识到，若能妥善整合过去一年涌现的技术成果，我的效能本可提升十倍——而未能把握这种提升机会，显然是技能层面的缺陷。如今需要掌握的可编程抽象层（在传统底层之上）涉及代理、子代理、指令、上下文、记忆、模式、权限、工具、插件、技能、钩子、 MCP、LSP、斜杠命令、工作流、IDE集成，更需构建全局性思维模型——既要把握这些本质上随机、易错、不可理解且不断演变的实体的优势与陷阱，又要将其与传统工程实践相融合。显然有人递来了一件强大的外星工具，但它没有说明书，每个人都必须摸索如何握持操作，而由此引发的九级地震正撼动整个行业。卷起袖子奋力前行，否则就会被时代抛弃。
本文由 TecHug 分享，英文原文及文中图片来自 Karpathy on Programming: “I've never felt this much behind”。
我承认对此心有戚戚，但这种说法实在毫无道理——它暗示这个行业如今竟神奇地对新人关闭了大门。
试想90年代有人宣称“现在不掌握网络技术就永远落后！”，然而二十年后，连当时尚未出生的孩子都在开发网络应用和框架。
静待行业尘埃落定后再“掌握”技术仍是可行策略。你唯一要放弃的，不过是张人工智能领域的资金彩票。
终于听到理性声音了。工具只会越来越好用。我现在用大型语言模型，但不会花大量时间追逐新潮技术。让别人去折腾，等成熟后再取其精华。
除非你志在成为顶尖“氛围程序员”，否则所谓“落后”纯属FOMO心理作祟。
正在为客户做小项目。他们明确规定不能使用未经批准的AI工具…反正钱是他们付的。所以除非被强制要求，我完全没压力转向AI。
至于我所在的其他领域，自动化工具能处理部分工作，AI或许也能承担些任务，但要真正验证发现结果，并准确解释背景与影响，这些工作AI还远远不够。
我也这么看。至少再等几年完全没问题，等技术成熟后再学习最有效的方案，总比现在耗费大量时间追赶技术轮子强。
除非你在做网页开发——这似乎是少数AI目前真正能发挥作用的领域。
或者你单纯热爱学习新事物。对我而言，这始终是编程生涯最美好的部分。
> 除非你志在成为顶尖的氛围编程师，否则所谓“落后”的概念纯属FOMO(害怕错过)心理作祟。
???
你引用的观点有道理。大家对此都太过焦虑了。并非所有人都需要时刻紧跟AI发展。我不是说要忽视大型语言模型，只是不必追逐每个潮流。
查尔斯·麦凯1841年的经典名言(我在这里引用过几次)此刻浮现脑海：
“人们常言，众生思维如群兽；而事实证明，他们集体发狂时，清醒却需缓慢且逐个进行。”
"[…] 阅读《民族史》时我们发现，国家如同个体，有着自己的怪癖与特质，经历着狂热与鲁莽的季节，全然不顾后果。我们发现整个社群会突然聚焦于某一目标而疯狂追逐；数以百万计的人同时陷入同一幻觉，追逐不休，直至注意力被某种比先前更迷人的新愚行吸引。"
——《大众的非理性行为与群体的疯狂》
感谢字幕，倒不是不懂术语，只是没能领会其中的隐含深意。
而我此刻正沉浸在90年代的派对(编程)中(C++桌面应用)，仿佛网络从未出现过… 🙂
你才是真正的独角兽！
按理说这些工具对新人工程师应该更友好，不必背负历史包袱。
>不必背负历史包袱。
你说的负担指什么？使用LLM没那么难，我们以前做过更难的事。
当然会有拒绝“放手”、坚持固有方式的人，但嘿！我用vim(现neovim)高效工作25年，身边工程师对IDE的掌握程度远不及我——差得远呢！
诚然，他们从未在IDE出现前受限于其他编辑器，但声称我因精通其他工具而难以适应新工具，这种说法荒谬至极。
不知如何回应才不至于重复原文观点。并非所有变革都建立在既有知识之上，有时变革速度之快令人难以跟上。
完全赞同。
当年Kubernetes热潮席卷时我便采取这种策略，从未因此受限发展前景。
90年代确实有人这么说。正因如此，当时才出现将一切搬上网络的狂热，无论是否存在实际商业价值。而十年末期，这些尝试大多化为泡影。
唉，作为一名中年软件工程师，我感觉自己就像是逃离西贡的最后一架直升机。我越来越不确定未来十年能否像过去几年那样靠软件行业过上同样体面的生活——或者说，我是否还想这样生活。这个行业正在经历翻天覆地的变化，而我并不确定自己是否喜欢这种变化。在大型科技公司工作时，我宁愿当个体贡献者(IC)也不愿当工程经理(EM)或技术主管，因为我热爱编写代码。如今却越来越觉得，这种意义上的IC岗位已不复存在。现在的编码工作都得通过他人完成——无论是人类还是AI。
当然，我可以手动编写代码，但以我目前全职开发自有SaaS产品的状况而言，借助AI效率绝对更高。两者根本不在一个量级。这种效率提升如此显著，以至于我再也无法为编写精美的手工代码辩护。事实证明“足够好”的代码就足够用了，而这正是我当前能负担的全部。
但长远来看，我不确定自己是否愿意继续做这类工作，尤其是在某家大公司。这就像从家具大师沦为宜家工厂的工人。
清理AI生成的烂摊子，你赚的钱会比以往更多。
今年我接过几个类似项目，深知清理烂摊子有多混乱又令人泄气。
而且报酬其实不高——客户总以为大部分工作都已完成，只需修补几个漏洞，甚至要求你用AI写出更精妙的提示词。
我认为从头开始或重写整个模块往往更快更划算(当然仍需借助AI，但重点在于氛围工程而非氛围编码)。
这就像房屋翻新——拆掉整栋房子往往比修补更省钱省时。
能否分享更多清理项目的细节？比如涉及前端还是后端、技术栈类型、大型语言模型代码存在哪些问题等。
我只是非常好奇当前这个行业的现状。
我非常尊重你的观点，但实在难以相信这种情况会发生。
这种情况正在发生。我那些职业生涯进入“大器晚成”阶段的伙伴们，近来发展相当顺利。
AI辅助编程如同四驱系统：它会让你陷入困境，但困在更棘手的境地。那些借助工具超越自身理解水平的人正在制造极其昂贵的麻烦。若你是专家级程序员，用AI加速重复性工作能获得良好回报；但若初级人员假装资深，雇主很快就要为聘请真正资深者付出高昂代价。
我注意到有些人对大型语言模型的效益过度自信，似乎刻意忽略了隐含成本。
这有其合理性——缺乏自律的人类天性总追求短期收益。而自律者能洞察这种缺陷，思考更具前瞻性。
但模型终究会提升修复复杂代码的能力吧？
我们无法确定。当前似乎正面临收益递减，但具体临界点尚不明晰。
我常说：编写软件变得如此简单，以至于我已不知如何下手。
感觉评论区很多人没意识到Karpathy是机器学习科学家，编程对他只是辅助技能而非主业。他提出“氛围编程”概念，纯粹是因为业余项目的复杂度让这种说法显得可信。关于编程未来的论断，或许该持保留态度。
他无疑才华横溢，但并非在这个领域。
或许如此，但我推荐他的Python机器学习视频给他人时，看重的不仅是机器学习内容，更因他的Python代码规范且符合语言特性。因此我不同意这种观点——我认为他的编程能力是经过长期锤炼的技能。
不过就我个人看法，他预言的世界观将使掌握这种技能变得极其困难，因为人们会日益依赖通用人工智能完成基础编程工作。
若论“编程技能”，写“规范且符合惯例”的Python代码根本算不上什么高深技艺。我认为通用预测(GP)倒也没错，那些因编程相关技能(甚至编程本身)出名的人，多数其实并不擅长编程。
他确实是个相当不错的程序员。
有趣的是，几个月前他的nanochat项目发布时，Reddit反AI阵营还欢呼他声称“我尝试过几次Claude/Codex代理，但它们根本不够好用，反而帮倒忙，可能是代码库偏离数据分布太远了”
可现在项目成功了，他突然就不算专家了…
[1] https://news.ycombinator.com/item?id=45573521
你所谓的“群体”并非同一批人。每当有人提出类似你的主张，我都会去查证，却从未在讨论中看到相同的用户名。“不同的人有不同的观点和表达方式”并非真知灼见；它既无实质意义，也不构成任何人应受指责的理由。
在诚实的辩论中，你不能将素不相识的个体强行归入自创的群体，进而指控他们虚伪或伪善。
> 但现在对他有利时，他突然就不算专家了…
或者说他当时没说谎，现在却在撒谎？
完全正确，若这话出自行业里真正从事日常编程工作的人之口，我会更重视
这真是总结他所有言论的绝妙方式
作为Opus用户，我真心不明白有人怎么能连续工作数周甚至数月却不定期打开IDE。生成的代码几乎总是失败。
我反复重写提示语、重申相同约束条件、撰写详细验收标准，最终得到的仍是残缺或无法运行的代码。这简直令人抓狂——仅昨天我就花了约200美元购买生成代码，结果还得大幅手动修改才能勉强使用。
这种情况下收益已成疑问。我最大的成功是让模型接管应用程序的初始设计，后续由我接手完善——但它生成的上百甚至上千行代码简直乱如梅西，事后重构这团乱麻简直痛苦至极。
光是让大型语言模型编写包含窗口函数、聚合运算和左外连接的SQL查询就让我头疼不已——即便把整个数据库模式的DDL都塞进上下文环境里。
这种挫败感常让我萌生退意，因此至今我仍坚持手写大部分代码。
我写过大量SQL，但数月来从未遇到这些问题，即便用小型模型也是如此。Opus能一击完成我多数查询，速度比我手动输入还快。
与其用DDL填满上下文，我建议：
1. 重构数据仓库。必须确保数据易于检索。确保采用清晰的ELT分层架构、有意义的模式设计，并为每个模型建立文档。这虽是大量工作，但若实施得当回报巨大。
2. 我自建工具将仓库数据转化为图结构，实现模糊搜索+依赖链分析。今年春季为此搭建了MCP服务器，Claude几乎所有查询都高效运用该工具。自部署MCP后，我已不再使用图形界面或脚本工具。
Claude和Devstral是我用过最优秀的SQL模型。Gemini始终无法编写合格的现代SQL——即便谷歌云平台的Gemini数据科学/工程师代理也如此。我偶尔通过API尝试付费模型，但至今未见惊艳表现。
>> 我常写SQL，但数月来从未遇到这些问题，即便用小型模型也如此。Opus能一击完成我多数查询，速度甚至快于我手动输入。
同感。顶尖模型能轻松处理我提出的任何SQL问题。
什么是SOTA？
尖端技术。
若你真正精通SQL，编写SQL查询本质上就像为数据库客户端编写提示词——只不过它能精准执行你的指令。
我有个在公司流传的笑话：
* 大型语言模型本质是矩阵乘法。* SQL本质是代数，而矩阵乘法正是其组成部分。* 因此SQL即人工智能。* 现在谁愿意向我们的人工智能SaaS公司投资十亿美元？
或者就像那个宇航员持枪梗图说的：“等等，人工智能就是SQL？……原来一直都是。”
大多数人尚未完全理解大型语言模型的工作原理，也不知如何正确运用智能编码解决方案。这正是氛围编码者产出低质量代码的根源所在。但问题不在于技术本身，而在于使用者(至少现阶段如此)。不妨这样想象：当前所有人就像被塞了掌上电脑却不知如何操作的奶奶。奶奶需要的其实是iPhone而非掌上电脑，但问题在于我们尚未进入那个时代。现在想想那些能熟练操作掌上电脑的人——他们虽是少数例外，但确实存在。当前情况亦是如此。我使用编码代理已逾七个月，却未写过一行代码，事实上我完全不懂编程。但我却能从零构建极其复杂的软件项目：文本转语音系统、用于测试所有可能llama.cpp采样参数的自动化LLM基准测试系统等等，现在我正在从零打造自己的智能体框架。所有这些，乃至更多功能，都无需亲自编写代码即可实现。但这确实需要精通技术应用才能达成。
你提到的所有应用都可归类为入门级项目，我认为它们不足以证明能力。
若不懂编程，便无法准确评估自己产出的成果。
我几乎不再打开集成开发环境。
我使用Claude Code和Cursor，具体做法：
– 采用静态类型语言：TypeScript、Go、Rust、带类型注解的Python
– 配置代码检查工具 针对TS，我基于常见反馈定制了大量AI生成的代码检查规则(详见https://github.com/shepherdjerred/monorepo/tree/main/package…)
– 针对 Cursor，提供大量关于期望风格的反馈。https://github.com/shepherdjerred/scout-for-lol/tree/main/.c…
– 大量使用计划模式。指示AI执行“至少进行20次在线文档检索”，确保每项论断都有出处依据等。要求AI“为每个待实现功能创建独立任务”
– 让AI编写测试用例，尤其侧重集成测试和端到端测试等复杂场景，以便快速验证功能实现
– 配置Claude Code GHA自动审核PR 将审核反馈传递给实现该功能的代理，可通过复制粘贴或告知代理“获取审核意见并修复”。
部分已实现功能示例：
– 为Discord平台的英雄联盟聊天机器人https://scout-for-lol.com/开发多项功能
– 为 Helm 图表生成 TypeScript 类型的程序 (https://github.com/shepherdjerred/homelab/tree/main/src/helm…)
– 用于汇总家庭实验室所有依赖项更新的程序(https://github.com/shepherdjerred/homelab/tree/main/src/deps…)
– 管理多实例CLI代理程序(如Claude Code)的工具 (https://github.com/shepherdjerred/monorepo/tree/main/package…)
– 模仿我朋友风格的Discord AI机器人(https://github.com/shepherdjerred/monorepo/tree/main/package…)
感谢分享。冒昧问一句——你觉得 Claude Code & Cursor 是否显著提升了你的工作效率？你的个人项目清单令人印象深刻，我能理解 AI 工具高手在全新项目中能发挥多大效能。这种效率提升同样适用于你的日常工作吗？
在个人项目中，我感受到革命性的变化。我曾长期受完美主义和枯燥环节的困扰，AI让我能专注添加大量实用功能，减少对代码本身的纠结。
幸运的是，我的工作场所也使用Cursor + Claude Code，因此经验得以直接迁移。日常工作中我主要使用Cursor，而Claude在分析多仓库间数据流时堪称研究助手。例如撰写新功能设计文档时，Claude就协助我完成了大量调查工作。我的工作流程大致是这样：
“这里是我的仓库，这里是数据库架构，这里是历史设计文档，现在系统X如何运作？如果我执行Y操作会怎样？等等”
AI仍存在错误，因此你当然需要大量核查验证——虽然枯燥，但只要添加“请为每项论断提供具体依据”这类提示，过程就会轻松许多。
在执行层面，我通常会提供更小、更具体的工作单元。例如在个人项目中，我会这样说明："这是我需要完成的所有事项，请制定计划，先执行第一部分，再进行第二部分，示例：https://github.com/shepherdjerred/scout-for-lol/tree/227e784…)
在工作中，我倾向于将任务拆解为PR规模的单元——即范围明确、定义清晰的模块。我的工作流程是：发出指令→在GitHub创建PR→添加PR评论→告知Cursor“我在你的PR中留了评论，请处理”→循环重复。本质上，我将AI视为向我提交代码的同事。
虽然难以量化效率提升幅度，但可以肯定的是——过去几个月我的工作动力显著增强，因为AI消除了大量阻碍。自六七月起我开始重度使用Cursor，提交记录印证了这一点：https://github.com/shepherdjerred
Cursor是集成开发环境。
补充说明：我曾使用Cursor，但最近一两个月几乎完全切换到Claude Code，主要是因为它的信用额度更慷慨。
> 至少进行20次在线文档检索
哈哈有時候得花兩輪時間說服Claude去用他媽的搜索功能查文檔，而不是第五次憑空瞎猜。ChatGPT至少還有強制搜索模式。
我發現直接指定N次搜索效果很穩定。真希望Claude Code能像’普通版’Claude那样有个“深度研究”模式。
我的诀窍是明确设定“快速开发”场景。这样所有模型都会忽略平时纠结的细节。基础框架搭建后，再让它完善细节。
添加代码永远比修复错误代码容易。
这就是AGENTS.md文件——https://agents.md/(或CLAUDE.md)的用途。在“代码风格”等章节中设定通用约束，用于纠正模型与代码库相关的错误/问题。
你们的软件开发流程是怎样的？是否设有设计阶段？
既然最高级别的Claude Max订阅每月只需200美元，为何要为Opus支付每日200美元？你们是否采用了特殊API使用方式？
推测是企业版API账户。按令牌计费且无使用限制。
开发者单日花费上百美元的情况非常常见。
月费200美元的套餐同样没有限制——他们设有超额费用，可通过Claude Code即时支付。当速率限制令牌额度耗尽后，你仍可继续工作，并从预设的额外现金储备中支付超额令牌费用。
您完全正确！200美元/月的限额套餐实际提供无限令牌——只要通过同样无限的现金储备支付超额费用。
我觉得你可能有些误解。
即使使用200美元/月的Claude Max方案也存在限制——每五小时内可使用的令牌数量有限制，若用完则需等待一小时才能重置。
你本可通过API密钥规避该限制及重置机制，但这将导致成本大幅增加——毕竟200美元/月的套餐对API费用有显著折扣。
几周前新增了第三种方案：购买200美元/月套餐，并在达到使用上限时允许系统额外收费。这样既能享受折扣，又不会中断工作。
付费Claude方案的额外使用说明：https://support.claude.com/en/articles/12429409-extra-usage-…
感谢说明，我完全理解您的意思。
但我不太明白的是，您怎么能一本正经地称其为“无限制”？不过既然看不到您的表情，说不定您写这段话时本来就没摆正经脸。
希望您能从我开篇“完全正确”的措辞中读出善意的微笑，但显然这种表达已不常见——正如https://absolutelyright.lol/所示，Opus 4.5版本已将其彻底移除。
我所说的“不受限制”，是指“不再像几周前那样，当五小时内代币耗尽时强制终止使用”。
正因如此，我才说“不限”而非“无限”——用词上的微妙差异，这点我承认。
哦，我并非否认“开发者每天花费数百美元”的可能性。只是想问这种情况的实际应用场景是什么。
我用它效果不错。你用的是什么编程语言？
有时我会遇到相似文件或关联文件。我直接复制它们的名称作为参考。这样代码质量能提升十倍。即使从框架入门指南中提取示例，对新项目也效果显著。
清理小混乱的痛苦同样巨大。我曾遇到测试失败和类型错误问题，想着以后只靠AI提示就能修复。但随着代码规模增长，TypeScript错误也持续累积，最终达到5000+类型问题和无数失败的单元测试，且数量还在不断增加。尝试用AI修复后发现传统方式已无法解决，最终在代码量达到50万行时彻底放弃了整个项目。
问题：每次迭代你允许AI编写多少行代码？是否会进行复核？听起来像是放任其自由编写。
我完全没预料到会这样。这是我首次使用AI集成开发环境，此前只用过chatgpt.com和claude.ai做些小修改。我继续实验只是想看看结果。我以为AI会写太多测试，打算根据测试通过情况来判断。确实是期望值太高+缺乏AI开发经验+糟糕的软件工程实践。
唯一让我如此自惭形秽的经历，是高中时全班都在讨论性经验时我无话可说。
AI代码堪称编程界的加拿大女友。
身为非美国人，我花了一会儿才明白“她人在加拿大”是种体面的借口——解释为何无人见过她。
该掏出那200美元了，老兄。
代码库超过十万行的话，200美元根本不够用。
要是更多人能理解二次关注在现实世界意味着什么就好了。
你是说大型语言模型的成本会随代码库规模二次增长？当前提示词已享受高额补贴，真想看看当消费者被收取实际价格时会发生什么。
说得好！这点说得真精辟。
我从事软件开发数十年，本质上是个程序员。我热爱编程，享受与计算机“融为一体”的状态。这份喜悦永不放弃。即便白天要卖鞋，夜晚我仍会编写真正的计算机程序。若现代设备无法实现，我便重拾Commodore 64。我是自由之人。
编辑：修正了since/for用法。:-)
(数十年间)
(‘since’表示时间点→’for’表示时间跨度)
你该用“one”而非“once”吧？
仅此一次。仅此一夜。
令我精疲力竭的并非“落后于人”，而是目睹整个行业集体认定：应对不确定性的解法就是层层堆砌抽象概念，直至无人能解释实际发生之事。
高管们这场无知的智能军备竞赛，与其说是增强能力，不如说是逃避现实。我们拿到一个随机文本生成器，发现它能信誓旦旦地撒谎，能抹除整个数据库和硬盘，于是用管理者、子智能、记忆库、工具、权限、工作流和协调层
如今我们不仅要维护系统模型，还得在脑中构建一群半可靠实习生的群集模型——它们用无法执行、不可复现且不稳定的语言相互对话。
工作变得比洗碗水还无趣，这足以迫使我在2026年前转型。
我认为AI辅助编程可能适得其反——至少对我如此。
如今我反而被激励去使用更少的抽象层。
我们为何选择React编程？因为在UI与数据模型间同步状态既困难又易出错，因此值得付出React的复杂性/页面体积代价，以换取“更佳开发体验”——让我们能减少文本编辑器中的代码输入，构建出可靠的运行软件。
倘若由大型语言模型代笔编写代码——且能维护测试套件确保功能无误——或许我们根本不需要这些抽象层。
你是否曾因需要将时间格式转换而引入Moment.js这类庞大复杂的库？手动实现该功能耗时过长(还需编写测试确保其健壮性)。而借助LLM，只需一个提示词和几分钟等待即可完成。
使用大型语言模型构建黑盒抽象层是一种选择。我们也可以选择让它们为我们构建更少的抽象层。
> 如果大型语言模型能编写代码——并且能维护一套测试套件来证明一切运行正常——那么也许我们根本不需要这种抽象层。
我见过太多初级开发者用同样的逻辑为庞大的随机脚本库和百行以上函数辩护。资深开发者几乎总会对此提出质疑，自有其道理。
一切都取决于那个“如果”。但你的推理中暗含着一个同义反复：“如果LLM能完成我们所需的一切，我们就能用LLM处理所有需求”。
我们阻止初级开发者走这条路，是因为经验告诉我们：系统终将崩溃，而崩溃带来的将是无尽痛苦。
因此“将LLM作为抽象层”或许是未来可能，但这假设LLM在管理日益复杂的代码混乱方面，远比初级开发者更胜一筹。
而当前简单化的LLM应用显然并非如此。“啊！但你需要智能体、记忆和上下文管理等等！”然而这些本身就是抽象层级。我认为这才是原评论真正想阐明的核心。
倘若AI能实现我们最初的期望：遵循简单指令解决复杂任务，那我们确实会很棒，我也认同你的观点。但我们显然尚未抵达那个境界。尤其当连卡帕西都难以驾驭这些工具所需的精密机制时。所有高呼“你操作错误！”的人，恰恰有力证明了大型语言模型无法达到我们所需的执行水准。
我并非主张将大型语言模型作为抽象层使用。
我想说的是，依赖关系计算的关键要素已然改变。
过去，影响你决定是否引入新库的最重要因素之一，是自行编写所需代码子集的成本。若编写代码及配套测试耗时超过一小时，通常选择库是更划算的投资。
但若代码和测试只需几分钟，这种计算就截然不同了。
高效且负责任地做出这类决策是资深工程师的核心特质，正因如此，多年积累的直觉被颠覆才如此耐人寻味。
我们产出的代码本质未变。不同之处在于：资深开发者过去可能耗费数小时编写函数及测试，成本高达数千美元；如今同等资历的开发者只需不到100美元的时间成本，就能产出完全相同的代码。
React拥有数十万行代码(或许已达百万——我许久未查证)。当然，你可以让大型语言模型先创建跨组件同步状态的简易方案，但在实际项目中，边界案例会不断涌现，导致模型构建的库复杂度持续攀升。当复杂度膨胀到极致时，LLM本身可能都难以有效维护这个库。我认为MomentJS也面临类似困境。
若复杂度超出不使用React的合理范围，我会让LLM直接重写成React！
前几天我就用这个方法把HTML生成项目从Python字符串切换到Jinja模板：https://github.com/simonw/claude-code-transcripts/pull/2
Simon，你开始显得和现实脱节了，这种“凡是钉子都用LLM大锤敲”的风格倒是新鲜。
过去一个月Opus 4.5彻底改变了我的工作习惯。我得写点东西记录下…
令我们担忧的是，你(和其他人)每次换个模型(比如Opus 4.5)就重复同样的说法。
这更像是盲目追逐而非清晰的进步轨迹。它与“读完《计算机程序设计艺术》后我的习惯改变很大”这类经历截然不同，本质上是两回事。
因为模型在持续进化！GPT-4能实现的功能远超GPT 3.5，而Sonnet 3.5、Sonnet 4乃至Sonnet 4.5又各自实现了更惊人的突破。
这些进步有的细微，有的则堪称质变。Sonnet 3.7与Claude Code(二者同期发布)实现了重大飞跃；Opus 4.5同样带来颠覆性变革。
(若你对直觉存疑，METR的任务完成基准测试也显示出巨大提升。)
如果你真心实意地尝试这些模型，旨在探索它们是否适合自己，并且在使用过程中严格遵循所有必要步骤，那么即使暂时遭遇负面结果，也请坚持尝试——因为终有一天，这些负面结果会为你转化为积极成果。
若你已是长期高效运用这些模型的使用者，就必须不断调整使用方式，因为曾经奏效的方法已不再是最优解。
模型在持续进化，但我批判的论点始终如一。
你评论下方的关联评论同样如此。我不明白为何人们难以相信我们只是尚未尝试。我订阅了Claude服务，身为机器学习研究者，请相信我确实付诸实践。
但正因如此，我更深刻意识到这些模型的局限与缺陷。坦白说，我不信任那些不批判自身领域的专家。宣传卖点交给营销团队就好。工程师和研究者的职责是保持批判性思维，发现问题。毕竟连问题都识别不出来，怎么可能解决问题呢？让营销团队主导研发方向？这简直是解决问题的糟糕方式。
基准测试往往难以解读。将其纳入营销策略实属问题。若你不懂基准测试衡量什么——更重要的是它未能衡量什么——我敢说你必然误解了这些数字的含义。
关于METR，我认为以下内容(重点标注为本人所加)有力佐证了我的观点：
因此务必谨慎理解衡量标准的实质——进步的真正含义，以及能力的边界所在。
纳入更长任务固然可喜，但需注意人类工作者中的偏见与分布差异，这对准确评估至关重要。
同时请牢记我引用的原文： 长期以来我们都清楚，擅长Leetcode并不等于优秀工程师。但这种测试简单易行，且测试结果与其他技能存在相关性——这些技能往往是为通过测试而习得的(尽管存在指标钻空子的可能)。我们讨论的是大规模压缩机器。这种模式匹配。随着任务时间增加，模式匹配难度往往大幅提升，但这并非必要条件。
对每个基准测试都要持批判态度。若你无法破解其指标，就说明你根本不了解该基准测试衡量的是什么(即便知道破解方法，也不代表你理解其原理或确认测试目标)。
我不明白你的论点是什么。
似乎是“人们总说模型很优秀”？
确实如此。它们确实优秀。
人们不断强调的原因在于，这些模型的能力边界持续被突破。
GPT 4时代实现真正可用的代码补全？太棒了！它能自动为我编写完整函数！
Claude 3.5时代能编写完整类和实用程序？太棒了！简直像拥有了初级程序员！
而如今借助Opus 4.5/Codex Max/Gemini 3 Pro，单次提示就能编写出完整的程序且运行正常。太棒了！
但我们开始意识到，六个月后的编程方式可能与现在截然不同——因为这些AI系统的编程逻辑与人类迥异。这正是关键所在。
那么你究竟反对什么观点？
我记得你说过不喜欢人们重复相同论调，但这篇帖子似乎更复杂？
从基准测试和个人体验来看，Opus 4.5 绝对是比 Opus 4.1 和 Sonnet 模型更优越的版本。你看到很多人盛赞O4.5，是因为它在可靠性能上实现了真正飞跃。对我而言，它跨越了关键门槛——能够通过系统化方法解决问题。
为何用“追逐”来描述这种现象？我不理解。或许你该亲自尝试并与早期模型对比，才能体会人们所指。
若你仔细阅读我的评论及你未回应的具体原因，自会明白答案。
顺便说一句，我试过这个。真烦人，总有人觉得问题在于没努力尝试。GPT 3.5刚推出时这种论调就够老套了。咱们更新下论据吧…
期待听到你们使用Opus 4.5的实践案例。根据我的经验和他人反馈，它已能攻克前代版本屡屡受挫的诸多技术瓶颈
请务必分享。我正协助公司其他开发者深化对智能编码的理解，发现并非所有人都默认采用Opus 4.5甚至Codex 5.2，而我常难以给出充分理由说服他们。若有相关博文可供参考就太好了…
能否详细说明Opus 4.5的优势？它是否已达到堪称“超级能力”的水平？与您之前使用的LLM有何不同？
重申我之前的观点：
> 无论是基准测试还是个人体验，Opus 4.5 都比 Opus 4.1 和 Sonnet 模型强得多。大家热议 O4.5 的原因在于它实现了可靠性能的真正飞跃。对我而言，它突破了关键门槛——能够通过系统化方法解决问题。
现实是：我们仅用一年时间就实现了从基础阶段——大型语言模型作为聊天机器人，每次请求仅需编辑几个文件就能获得不错结果；到当前阶段——基于规格文档和若干澄清问题，同时运行多个编码代理来实现核心功能。
即便大型语言模型不再进步，其现有能力也仍有大量潜力可挖。
这种方案在任何规模像样的团队里都会像铅气球一样沉下去。
理应如此，因为“我们稍后会用React重写”通常意味着数周甚至数月的大规模破坏性工作。我见过此类迁移项目持续推进超过一年！
如今的新常态截然不同。将现有规范实现的原生JavaScript项目(含测试)重构为React，这类机械性任务完全可以交给Claude Code这类编码智能体处理——次日清晨回来时，大部分(有时甚至是全部)工作都已完成。
而其他人的工作必须全部暂停或废弃，只因你独自包揽了全部重构。
这种做法在极其简单的项目之外，绝对不会被接受。
你为何断言：
> 新常态并非如此。将一个现有、实现规范的原生JavaScript项目(含测试)重写为React项目，这种机械任务完全可以交给Claude Code这类编码代理处理，次日清晨回来就能看到大部分(有时甚至全部)工作完成。
…就意味着那人会暗中操作，而非事先协商好的任务？这是你的行事风格吗？
我的开篇陈述：
> 且其他所有人的工作都必须完全暂停
在规模足够大的团队中，让所有人暂停工作等待你对整个代码库进行大爆炸式重构——即便仅需一天——仍会造成严重干扰。
上次经历类似情况时，我们极其谨慎地操作：将多页面应用逐页迁移至SPA架构。即便如此，仍需确保迁移页面上没有其他开发者在工作，更不用说整个代码库了。
重申一次，我完全不认同你能仅凭AI技术完成如此激进的转型——除非是微型团队处理简单应用程序。
> 难道说那人会采取秘密行动而非事先协商？这就是你们的运作方式？
这完全不是这个意思
在AI密集型项目中，启动大量推测性重构后再回过头评估效果很常见。
好奇能否用Rust实现SIMD优化版的Numpy代码？试试看！你甚至无需浪费代码审查时间，因为测试覆盖率很高，能直接判断是否值得投入。
当数百名开发者参与项目时，一次性重写根本不可能实现。所以这并非暗中操作，而是无论投入多少AI超级力量都无法完成的现实困境。
既然大家都围攻你，Simon，我来补充观点。
他说得对。游戏规则已改变。如今我们能借助智能体重构代码，清晨即可完成。架构失误的代价微乎其微，即便失控也只需重构后小憩片刻。
真正有趣的是现在重在“意图”。你只需撰写提示词和规格说明，记录解决方案的文档框架，然后放手让智能体运作。你负责研究，智能体负责编码——我亲眼见证过这种模式的大规模应用。
姑且说你的论点让我略为信服。我读过你那篇一周前在HN上爆红的博文，也曾用AI做过类似的小型玩具程序，填补了特定细分领域的需求。
你能否对开发者何时将这种新常态纳入日常工作给出具体预测？一年？五年？
而这一切有多少只是轮回转世的又一次迭代[0]？或许我们正展望的未来是：回归如今这种单一文化主导、库文件密集的供应链模式，只不过库文件由成群的人工智能代理编写，而程序员/用户则负责引导其他人工智能代理创建业务逻辑？
[0] https://www.computerhope.com/jargon/w/wor.htm
预测其他开发者的工作方式确实困难，尤其考虑到许多人对全面探索新工具仍持抵触态度。
不过过去两个月确实出现了一些转变，GPT 5.1、5.2 Codex和Opus 4.5的推出带来了转机。
如今我们拥有能可靠执行数小时复杂项目的模型——这完全是前所未有的突破。处于技术前沿的我们仍在消化这种变革带来的影响(正如Karpathy的推文所示)。
我对自己的预测也不太确定，但未来几个月主流开发者对这些工具能力的认知必将发生重大转变。
“未来早已降临，只是分布不均。”
在某些企业，多数开发者日常工作已离不开它。根据我的经验，如今开发者资历越深，越可能大量使用大型语言模型编写全部或大部分代码。通过与初创公司、科技巨头的朋友及前同事交流(加上我自己的同事和亲身经历)，这绝非“遥不可及”的未来。
但在保守型企业——那些尚未与Cursor/Anthropic/OpenAI签订企业协议、仍在谨慎评估Copilot的公司——情况可能截然不同。
“React拥有数十万行代码”。
其中大部分与我的项目无关。维护几百行自写代码，总比永远背负React-Kitchen-Sink更轻松。
并非所有UI都需要React级别的复杂性。对多数场景而言React属于过度设计，但这个行业缺乏勇气采用更简单的方案，比如htmx。
核心React相当简洁，我几乎能用它解决所有问题。过度设计通常出现在上层框架。
没错，遇到这种情况我宁愿让代理使用htmx，也不愿采用手工编写的方案。
暂不评论上级观点的对错(我认为其正确性存疑)
若此论成立，市场将迅速给予回报。高效编写优质代码的能力终将获得回报。雇佣程序员并非出于关怀，而是为了产出成果。若有人能利用LLM以更低成本创造更多产出，那些不理解这项技术的人很快就会在职场中失去竞争力。
> 以更低成本产出更多成果
这实为陷阱：缺乏商业与工程双重经验者，往往难以预估或事后核算这笔成本。陷阱在于系统崩溃时的变更成本与修复预算——而崩溃必将发生，且频频出现。需求变更更是常态(我们的世界并非静止)。因此成本具有变化倾向(猜猜是哪个方向)。盲目复制粘贴或全盘重写的做法看似美妙，但成本会随时间急剧攀升。不知此道者终将陷入绝境，失去商机。
预测成本或许棘手，但事后衡量则容易得多。
缺乏预测如同在完全失明状态下驾驶B787降落——既无仪表指引也无视觉参照。
这不仅会造成伤害，更将摧毁整个企业。
关键差异在于当我们因程序错误而必须阅读代码时。或许大型语言模型能帮我们定位问题！但抽象化提供了思维框架
我感觉“抽象”这个词在许多讨论中被过度使用了。
就个人而言，我热爱那种“将这些例程概括为简洁优雅版本”的抽象。即使它比单个实例更难理解，这种投入也值得——它能带来对代码及其功能的深刻认知。
但抽象化也意味着降低可理解性或增加复杂度，我认为大型语言模型正是如此运作。理解代码需要很长时间，并非因为任何单行代码更难理解，而是因为它们需要结合上下文才能理解。
我认为部分原因在于人们对优雅的误解。优雅并非指美观，而是指以简单高效的方式完成某件事。没错，初稿可以粗糙，但我们仍应追求优雅。如今更像是只求草草完成初稿就急着转向下个项目。
> 高级工程师的核心特质之一，正是能高效且负责任地做出这些决策。正因如此，那些经年累月的直觉被颠覆的现象才如此耐人寻味。
它们并未被颠覆。这恰恰是某些人不信任大型语言模型重新发明轮子的原因。它能否一次性生成代码和测试无关紧要——关键在于某些问题需要经验才能明确解决路径。库的存在正是为了集中化这些经验与知识。
在权衡自主研发与使用库的利弊时，“前期开发成本”对我而言相对次要。
风险评估中切勿遗漏供应链攻击风险。
我更常看到的问题是：初级开发者编写单个函数时引入十几个依赖库。
确实，成为资深开发者的必修课之一，就是学会辨别为何应规避left-pad而接纳date-fns。
我们仍处于大型语言模型(LLM)应用实践的初级阶段。这就像2010年的移动应用或2014年的单页应用(SPA)开发。当前人们正疯狂尝试各种方案，在摸清使用方法并趋于稳定前，必然经历大量迭代与混乱。我曾戏称不爱休假——因为休假归来整个前端技术栈可能已被彻底替换，如今倒是趋于稳定了。
另外我觉得奇怪的是，你竟将当前大型语言模型的进展描述为低于预期。若几年前有人预言这些模型会发展到如此程度，人们绝对会认为他疯了。除了推销产品的人之外，几乎没人宣称我们即将进入这样一个世界：只需输入一个想法，就能得到无需进一步指导或调整的复杂解决方案。当AI能做到这点时，我们只需让它循环自我优化，AGI就近在GPU运算周期之内了。多数人仍认为——也希望——那还遥遥无期。
这并不意味着抽象化和内联的相对成本没有发生剧变，也不代表这些工具在掌握使用方法后不会变得极其有用。
当然，你也可以效仿多数人的做法：静待开拓者们或碰壁受挫，或摸索出可行方案，待技术趋于稳定时再跟风加入——但请认清：当技术真正稳定时，你已落后于那些过去几年一直在清理弹片伤口的前行者数年之久。
> 我们阻止初级开发者走这条路，是因为经验告诉我们：系统终将崩溃，而崩溃带来的将是无尽痛苦。
夸张了。其实很多资深代码同样会带来“无尽痛苦”。
> 系统终将崩溃，而崩溃带来的痛苦将难以承受
在当今环境中，当事物创造成本趋近于零时，这种说法还有多少真实性？
我认为“进化论”会指出：生产成本趋近于零意味着创造理想状态的可能性极高。重试成本低廉，因此错误与痛苦并不致命。对于真正高风险的情境(多数情况并非如此)，只需让人类专家参与决策，直到人工智能能超越人类专家为止。
> 所有高呼“你搞错了！”的人，恰恰有力证明了大型语言模型无法达到我们所需的执行水平。
人们告诉你的就是“你做错了！”——仅此而已，这个基本句式无需额外解读
抱歉，我无法认同。
现代开发面临的依赖地狱，供应链攻击的漏洞之大，以及几乎每两周就曝出新的远程代码执行漏洞。
我宁愿采用100个松耦合脚本，由六名LLM代理进行同行评审。
但这并未解决依赖地狱问题。若功能模块本就松耦合，你完全可以直接引入代码并手动审查。若模块无法松耦合——比如数据库——你仍需依赖它？
或者你可以用AI来处理依赖项，审查现有依赖及其更新。虽然没试过，但这可能比当前的做法更好——毕竟现在大多时候都只能信任上游，直到出现问题才发现。
你真要手动审查整个moment.js库，就为了格式化个日期？
所谓“内置代码”，指的是将相关代码复制到项目中。你无需审查全部内容。虽然这是处理依赖关系的不良方式，但类似于当前人们使用大型语言模型实现实用功能的做法。
当我只需库功能的1%时，可用AI生成足够替代方案，无需引入任何供应商代码。
它可能更脆弱且功能有限？确实如此，但至少不会引入成千上万的依赖包。
> “将LLM作为抽象层”或许是未来方向，但这假设LLM在管理日益复杂的代码混乱度方面远胜初级开发者。
暂且不论它们实际已具备这种能力——这并不重要，因为每次前沿模型发布都会使重写混乱代码的成本降低一个数量级。你根本不需要优质代码，因为你随时都在抛弃所有东西。
我至今未能理解这个论点。若用黄褐色粪便取代棕色粪便，终究还是粪便。
日常工作中，我是一个踏实务实的程序员，通过艰辛实践领悟到：任何可运行的代码库都存在大量切斯特顿意义上的“围栏”。
不过我认为，对于小型系统或系统局部模块，大型语言模型确实能推动“修复-替换”的平衡点向替换倾斜——尤其当测试体系完善时。
> 现在我更倾向于减少抽象层的使用。
我反而更倾向于采用学习成本更高、但编译后执行更快速或更安全的抽象层。例如更多使用Rust、Lean等语言。
> 若大型语言模型能编写代码——且能维护证明其正确性的测试套件——或许我们根本不需要抽象层。
大型语言模型与人类同样受益于抽象化。
当前大型语言模型复制了我们的问题解决方法，同时也复制了这些方法带来的所有问题。
让大型语言模型跳过所有抽象层的成功概率，与遗传编程的效率相当。
例如，用更纯粹的JavaScript替代React，无非是以更冗长的形式重新发明必要抽象，同时面临更高风险的代码重复或抽象错配问题。
进化生物学家布雷特·温斯坦近期访谈中提出：物种演化更可能发生的关键在于，进化机制不仅涉及单个基因的随机变异，更包含针对端粒及微卫星等编码变量的协同变异。
https://podcasts.happyscribe.com/the-joe-rogan-experience/24…
布雷特将此类比为：在程序中随机翻转位元以提升效能，与在高级语言中随意调整变量参数的差异。在高层次修改已正常运行的参数，比在低层次修改参数更可能产生新的有效结果。
因此我认为大型语言模型与人类一样，能从高层次抽象中获益。
我们只需找到优质的抽象方案——但对人类有效的方案未必适用于大型语言模型。
> 例如，选择原生JS而非React，本质上只是用更冗长的代码重新实现必要抽象，还伴随代码重复或抽象错配的风险。
没错，但我也获得了加载更快的页面且无需构建步骤，这让快速开发变得更便捷。我非常享受这种权衡。
原生JS的功能也远比React诞生时强大得多。
没错，迭代速度确实无可匹敌。
感觉我们这类人多得数不清。
完全正确。大型语言模型和人类开发者很相似：它们受益于现有抽象层。从零开始重构一切只会招致灾难——尤其考虑到大型语言模型的上下文窗口有限。
你选择Moment.js这个时间库作为示例很有意思——而非Lodash这类实用工具库。多年来我持续关注Jon Skeet关于实现时间库NodaTime(JodaTime移植版)的博客。计算机时间建模存在大量极端边界情况和反直觉特性。
若仅需实现Lodash的_.intersection()方法，我完全理解。需求明确且可自行验证LLM代码与测试。减少依赖固然可喜。但涉及时间领域时，我深知自身知识储备不足以验证LLM的输出结果。
与加密库类似，通常建议将基于时间的代码交给那些深谙这些黑盒子运作原理的开发者。我信任社区能验证这些概念的正确性——这是我无法仅凭大型语言模型输出就能完成的。
> 若大型语言模型能编写代码——且能维护测试套件证明其正确性——或许我们根本不需要抽象层。
我担忧LLM生成的代码存在一种倾向：连局部抽象都避免使用，例如将通用代码拆分到独立局部函数中，甚至不采用记录/结构体。最终得到的代码只能由LLM维护，这对LLM供应商及其未来收益有利。但作为代码审查者和长期维护者的我们人类，恰恰需要这些细微的抽象机制。
确实，我也需要警惕这种情况。我常会建议“重构以减少代码重复”——当LLM为新功能添加测试覆盖后，这种操作通常非常安全。
LLM还具备百科全书式的知识储备。多次遇到它们发现我编写的庞大代码块，并将其精简至寥寥数行。前些天它们更替换了我为某些API调用编写的数千行脆弱代码，转而采用我未曾了解的成熟测试包——实际从数千行缩减至数十行。
我的代码正持续精简，每日都在提升质量、优化性能、践行最佳实践。而我也在疯狂学习。每当它建议修改代码时，我都会深入探究背后的原理与依据。
不过这家伙有时也蠢得要命。就在今天，它竟建议用庞大的服务器端脚本解决我正在部署的应用程序问题，而实际解决方案只需修改应用程序一行代码。(“你完全正确！”)
目前可使用
date-fns并进行树摇动。我更希望LLM基于经过实战检验的生产级库进行构建，而非从零开始重写。当它们本已掌握通用方案时，重新发明轮子只会填满上下文空间。
更不用说此类功能的测试极其困难。既然能专注其他领域，何必让人类和LLM浪费时间(及上下文资源)去攻克状态同步这类难题？
每个依赖项都伴随成本。你实际上是将项目未来的部分维护工作外包给了外部团队。
这通常是稳妥之选，但若所选库过时且不再维护，也可能适得其反。
因此我倾向于减少依赖项，并严格把关依赖项的引入时机。
与其引入数百个解决小问题的依赖项(这些问题本可高效自行解决)，我更青睐十几个经过严格验证的核心依赖项。
对于left-pad这类小工具自然没问题，但前文提及的两个案例(moment和react)解决的是极其棘手的问题。若有人试图在JS中重新实现时区处理功能，这样的PR绝对不会通过审核。
在JS领域，DOM和时区处理堪称最混乱的基础架构(DOM虽能完美处理文档，却非为Web应用而生)。
我认为我们必须谨慎添加自主维护的依赖项，尤其要考虑员工流动性和现有替代方案。除非这是业务差异化的关键，否则我建议工程师务必充分评估其他选项，并明确说明为何它们不适用。
AI可能助长工程师“亲手打造”的盲点——毕竟动手实现很有趣。但工程学作为一门学科需要克制。
React与Moment是否适用需具体分析。
若构建简单表单，React未必是最佳选择；若开发类似Trello的产品，则需重新权衡。
同理，我不会为https://tools.simonwillison.net/california-clock-change项目选用Moment，但若需要其高级功能则另当别论。
我得出了类似结论。例如在SQLite上封装接口要简单得多。我曾因ORM的隐藏细节吃过大亏。ORM看似能消除对象与数据库间编码解码的冗余代码，实则暗藏诸多抽象层崩溃的隐患。懒加载细节、内存状态与数据库不匹配、级联细节等都会引发难以预料的问题。借助大型语言模型处理繁重工作，能让你清晰洞察所有细节并进行逻辑推演。无需猜测运行机制，可自主掌控决策权。
我完全赞同。
我正指导开发人员采用老派做法：枯燥的表单POST提交、服务器端渲染模板，以及纯粹的JS/CSS。
此前我转向抽象化方案，只因编写冗余代码实在乏味。
但如今无需手动编写，这种繁琐却简洁的方法既让开发者高效编码，也便于代码审查人员把关。
> 若大型语言模型能编写代码——且能维护完整测试套件确保功能正确——或许我们根本不需要抽象层。
但这绝非易事。如何手动验证测试套件是否完整覆盖所有边界情况(状态同步本就是难题，边界情况本就繁多)？
至少React以非随机、确定性的方式解决了这个问题。有什么理由要用随机生成的LLM辅助代码取代像React这样确定性运行的框架？毕竟既无法手动验证实现正确性，也无法确认测试套件是否完整。
根本没有理由，就像当年“生成momentjs并直接使用”的荒谬逻辑。如今人们坚信只需让Claude说句“代码在此”，就能用LLM构建定制版库并凭空重写整个生态系统。
我逐渐意识到对抗这种趋势毫无意义——人们终将这么做，这会引发重大灾难，而善后清理工作将创造巨额利润。
我认为整天处理JavaScript垃圾代码的人与后端大型系统开发者之间存在巨大认知鸿沟…比如这个讨论串正一本正经地探讨为好玩而本地重构日期处理功能。
我更认为，任何企业若打造出由盲目愚昧的半吊子开发者组成的“逆向半人马”团队，让他们像巫师般对着按需付费的自动化机器摇动鸡骨占卜，本质上就是在向OpenAI/微软外包核心业务——还为此支付额外费用。而当二十年后服务成本与资本成本双重挤压来临之际，这些巨头企业将坐拥客户内部业务架构图与关键代码的完整副本……
他们嘴上说一套，背后做一套。指望微软不会通过滥用合作伙伴计划和政府操控的许可捆绑来蚕食你的领域？大型语言模型定能详尽阐释这种历史先例，以及这种策略在未来有多么明智。
虽然会出现大量失误，但随着前沿模型飞速进步，也将诞生许多卓越的成果。那些令人窒息的技术债务将被模型接手处理，无需再耗费人力智力去解决。
我认为这对工程领域总体而言是净收益。
有人尝试过文中暗示的实验吗？今天早些时候我就在思考：选一个简单应用，选定操作系统，直接让大型语言模型用纯机器码和原生开发工具包编写应用，跳过所有中间层会怎样？
软件开发似乎已形成庞大的官僚体系，让计算机执行应用程序竟需协调复杂机器中无数齿轮的运转。但自动化为何只用于转动齿轮？为何不直接简化流程？LLM真需要纠结采用最新最强的抽象层吗？我猜想这应该早有人尝试过…
> 若由LLM编写代码——且能维护证明系统正常运行的测试套件——或许我们根本不需要那些抽象层。
简单场景下确实如此，React向来效率低下。即便JavaScript/客户端逻辑也常属过度设计，除非涉及棘手的“用户预期”问题。
但对于长期存在的复杂代码库，组合数学告诉我们：要实现全面优质且高效的测试覆盖几乎不可能。
人们不自建库的部分原因在于：假设库不会存在重大缺陷能极大减少必要测试工作量，而通常人们发现这个假设足够安全。
若抛弃这种安全假设，转而只覆盖必要部分——同时你也在放弃快速识别风险变更的能力，因为你并不熟悉全部代码——这极可能让你陷入棘手的困境。
“雇一千个低技能人员强制编写测试”作为招聘方案，其问题远不止“人力成本高昂”这么简单。
> 我们为何选择React编程？
…这问题暗藏玄机，答案复杂而微妙。尤其当你接着说：
> 值得为React的复杂性/页面体积付出代价
那么问题来了：既然存在像Preact这样更轻量级的替代方案，它能解决相同问题却大幅降低页面负载，我们为何还要选择React？
既然已有Solid这类通过信号机制实现数据与微小UI片段同步的方案，我们为何还要选择React？
为何人们要用React编写数据几乎不变，或变化微小到与UI同步毫无挑战性的内容？比如博客或落地页？
我认为“为何选择React编程”这个问题已没有简单而令人满意的答案。营销和教育实践无疑在其中扮演了重要角色。
是的，我完全认同这些疑问。
我的冷嘲回答是：过去十年间入行的多数网页开发者都是从React开始学习前端技术的，其中很多人确实没有不用React的经验。
这意味着组建React团队更容易招聘。这意味着学习React能提升就业竞争力。
> 过去十年入行的网页开发者大多是先接触React再学习前端，其中不少人确实缺乏不依赖React的开发经验
这并非愤世嫉俗，而是现实。
我参与过大量面试并指导过初级开发者，可以百分之百证实这一点。
有趣的是，五年前“只懂React的开发者”才是更大问题。
如今的问题在于那些只能使用Next.js的开发者。许多人不会用Vite+React或纯React等其他方案。
2022-2024年间我面试的Ruby开发者中，约50%无法用Ruby编写FizzBuzz程序而不启动整个Rails项目。
>> 其中许多人确实缺乏脱离[react]的实战经验
> 如今的问题在于那些只能使用Next.js的开发者。很多人无法驾驭Vite+React或纯React等其他方案。
你愿意雇佣这样的开发者吗？
不，正因如此我才称之为“问题”。
招聘环节我的职责就是筛选这类人。
但这是我的立场。其他公司或许有兴趣。
我常选择开发非模板化产品，因此更需要像你刚才提问那样充满好奇心的开发者。
我对前端开发者的测试是：用JSFiddle仅靠JS、CSS和HTML实现悬浮菜单。若能不写JS则额外加分。
若能完成这个，通常就能理解其他所有技术原理。
没错，这是个好测试。即使是纯React岗位也适用。
看到这些人围攻你，我深感不适——我完全支持你的观点。
让我举个大型语言模型真正大放异彩的场景：这确实是种福音。我认为研究出身的Karpathy也是同样观点。
在任何研究中，复现论文都是极其艰巨的任务。整个团队需要投入6-24个月的专注工作才能复现一篇优质研究论文。
我们坚持复现自有其价值——有时解决方案就藏在研究本身。毕竟多数研究本质上是实验性的垃圾代码。
对我们这些研究工作者而言，LLM提供的快速原型能力堪称福音。
而研究工程师的职责则是将研究成果转化为生产代码。我们这类工程师根本不在乎流行库，只要能解决问题就直接采用。
原因很简单——市面上根本不存在现成的解决方案。
随着我们逐渐脱离研究领域，所构建的工具会不断发现各类问题并持续优化。
不知他人如何看待Web开发，但这始终是我在软件工程领域的核心认知。
这里多数Web开发者沉溺于React技能的价值，实属妄想——他们从未深入探索过技术栈的基础层。文档如何渲染并不重要，关键在于能否成功渲染。
所有抽象概念都源于研究和初步验证。你或许能重新发明抽象，但当重构成本趋近于零时，选择利用现有成果而非探索创新，实则是扼杀了自身成长。
其中存在平衡之道，优秀工程师深谙此理。那些群起攻讦你的人，或许从未以这种方式对待过工作。
若你身处巨头企业，便知当下趋势绝非开发者主动减少库的使用。问题根源在于开发者被代码行数衡量绩效——投入越多AI技术，就能产出更多代码行和所谓“功能”。
然而这些代码质量糟糕透顶，没人会深入阅读提交的内容，且模型缺乏足够的“判断力”来构建真正稳健有效的测试套件。即便具备这种能力，全面的测试套件也无法解决代码设计缺陷——它只是敷衍了事的补丁，且大规模应用时成本极其高昂。
未来几年，这种软件开发模式很可能引发一系列灾难，届时人们才会明白这些智能体只是工具而非替代品。
…或者我们或许能获得通用人工智能，它将修复/维护当前泛滥的垃圾代码。
我不信任大型语言模型能处理React等库中深埋的抽象层维护工作。我多次发现某些模型为通过测试而采取恶劣捷径(例如移除测试约束或验证条件)，这彻底摧毁了信任基础。
若需对每次变更进行严格监督，我认为开发流程非但不会改善，反而可能恶化。
更不用说新加入团队的工程师，突然要应对这个独一无二的解决方案层——它在其他任何地方都不存在。
既然已有现成库可用，为何还要永久维护随机代码片段？这算什么改进？
若该库未来停止维护，这才是改进。
…或者决定重构你正在使用的API。
你指的是httpx吗？;)
若大型语言模型真有如此能力，为何AI公司不直接用它们征服市场，反而出售访问权限？
同样的问题也可问ASML：既然ASML的EUV光刻机如此出色，为何不自己造芯片，反而卖给台积电？现实是企业专注特定领域，越界反而可能丧失比较优势。
因为LLM技术仅在三个月前达到当前水平，而市场动态决定了企业若不对外开放技术，竞争对手就会抢占先机。
我认为是担心失去市场份额和宝贵数据，同时企业还面临着必须在AI竞赛中保持领先以支撑股价的压力。
即竞争压力。倘若仅存一家AI公司，他们大概率不会向公众开放接近顶尖水平的版本——就像ChatGPT问世前的谷歌那样。
这似乎并未真正回答问题？或许是我对问题的理解存在偏差。
倘若(假设)Anthropic的代码生成技术如此卓越，为何还要经营AI系统访问权限的销售业务？为何不直接一夜之间征服所有其他软件行业？
让Claude打造史上最优秀的办公套件。让Claude开发史上最卓越的操作系统。让Claude创造最佳的图片编辑软件、音乐制作软件、3D渲染软件、DNA分析软件、银行软件等等。
既然能成为永恒的全能软件霸主，何必只满足于当最佳AI软件公司？
我等着人们意识到软件产品远不止几行代码那么简单。
实在受够了那些夸耀生产力提升的人——现实中真正创造价值的进展根本微乎其微。
你看不见或拒绝相信别人，并不代表你正确而对方说谎。或许错的只是你。
或者说，我本就正确，而你只是迟钝得看不清他人早已洞悉的事实。
顺便提一句，我也不是软件工程师。因此我毫无既得利益。
咦，我一直持相反观点：即便不需要React，也该优先使用它，因为它在训练数据中占比极高。难道大型语言模型不比定制化JS更擅长处理这类标准技术栈吗？
很难断言。我发现当要求“纯JS，不使用React”时，前沿大型语言模型能生成非常优质的代码——至少符合我的个人偏好——但这绝非可靠的基准测试。
我宁可用React也不愿采用短暂智能体生成的定制方案，更宁可自钻颅孔也不愿碰React
我认为这是不同类别的抽象
关键在于：当它失败时你该怎么办？不是“如果”，而是“当”。
你能手动翻遍数千个函数修复问题吗？
疯狂构想：用汇编代码训练模型。创建能将提示直接编译为机器码的大型语言模型。
> 并能维护一套测试套件，确保所有功能正常运行
你能否高效验证测试套件是否覆盖了应测试的内容？(若测试代码量与实际代码相当，我认为“手动审查所有测试代码”并不高效。)
有时被测代码的变更意味着需要修改测试(这种测试或许不可避免地脆弱)。此时，LLM应调整测试以匹配被测代码的行为。而另一些时候，被测代码的变更代表着测试失败本应捕获的缺陷——这种情况下，LLM应修复被测代码，保持测试不变。如何确保LLM在每种情况下都能选择正确路径？
这是根本性的误解
抽象的作用正是为了避免(例如“压缩”)测试套件的需求，因为它提供了易于理解和推理的简化模型
我个人制定自动化测试套件的规则之一是：若所用库的变更破坏了功能实现，测试必须失败。
这让依赖升级轻松太多！
当然，但这种做法基本不可维护，将正确性检查的责任从库转移到了用户身上。正因如此我们才进行模块化/抽象化/简化，以最大限度减少实际验证需求
我们的行业渴求颠覆、速度与交付！自动代码生成完美实现了这些目标。
若追求安全性、稳定性、性能与精雕细琢，大型语言模型的影响力将大打折扣。它们往往导致代码层层堆砌。
我认为新技术只是加速了本就存在的问题。多数技术产品早已腐朽不堪，看看Windows或iOS就知道了。
不知需要怎样的转折点才能改变这种思维定式。
颠覆不过是放松监管的代名词，而放松监管除了高管和投资者外，对所有人都是坏事
可悲的是，这条评论竟被屏蔽至无人问津。
这一切或许能催生一个积极结果：派遣大型语言模型清理海量低价值技术债务。让人类加速前进，让机器梳理整理。
由于昂贵的人力耗时过长，此举的投资回报率较低。但若能以更低成本清理，投资回报率将显著提升——而待清理的技术债务量极其庞大。
程序员竟愿意接受更低的确定性，实在令人震惊。
这并非突变现象。" “我来生成代码”与“我找个现成库实现”‘我指派约翰编写这个功能’“我外包给咨询公司”同样具有非确定性。即便亲自动手编写，结果也充满不确定性——你不可能写出完全相同的代码解决相同问题，即使刻意尝试也做不到。
不是吗？
使用库时，我确信它每次在相同输入下都会产生相同结果。若对其行为存疑，可查阅文档——有些文档完善，有些则糟糕透顶。但优质库在数年乃至数十年后仍会持续满足我的需求。
大型语言模型无法在两句话之间做出确定性决策。
库本身是确定性的，但查找库的过程并非如此。正如代码生成过程具有非确定性，但生成的代码通常是确定性的。
与代码生成不同，其他所有示例都存在一个共同点，即核心优势：你的目标与它们的行动保持一致。只要激励机制足够完善，它们本质上就是确定性的。
当你订购外卖时，你不在乎由谁配送、如何配送。最终结果才是关键。我们已确保可靠性足够高，故障属于偶发事件而非常态。
代码生成因可靠性不足，无法获得同等的准确定性标签。
这截然不同——大型语言模型(LLM)因其输出的随机性和不可复现性而本质迥异。从LLM自身视角看，非功能性或错误代码与正确代码并无二致，因为它根本无法理解自身生成的内容。人类编写代码时，可评判其优劣，但背后存在思考过程、实际“智能”及推理逻辑支撑决策。
我认为正是这个洞见让我深刻认识到大型语言模型的局限性。有人称其生成错误或虚构内容时为“产生幻觉”，但真相是它生成的所有内容都是幻觉，偶尔正确只是偶然现象。
我不确定谁会毫无目标地生成随机代码，事后也不验证是否有效。这听起来像是稻草人论证。通常你会设定规则，知道如何验证结果是否有效，甚至可能生成保持该状态的测试。如果我得到的是完全随机的结果而非预期结果，我根本不会使用这个系统——但它几乎每次都是正确且有用的。你描述的根本不是人们实际使用大型语言模型的方式。
正确。该系统不存在真伪概念，只有0或1。
因此它未必能区分人类眼中几乎相同的两个陈述。这并非意味着技术毫无价值，但显然不是什么通用人工智能的胡说八道。
普通程序员为何会对此有意见？
普通程序员在日常工作中本就被迫处理大量令他们不满的事务。
糟糕的设计、愚蠢的产品、用户追踪、隐私侵犯、安全漏洞、客户端运行缓慢、劣质工具链、低质依赖项、恶劣的企业文化、代码审查中的无谓吹毛求疵。
半数Reddit用户会为金钱利益辩护。
多一件又何妨？
说得更响亮些。
管理层竟愿意接受这种情况，实在荒谬。
我认为有些人难以理解决定论的概念，因为它与正确性相似，而正确性在许多场景下是需要权衡取舍的——例如在扩展性和速度方面，人们常会牺牲正确性。
若未能清晰区分决定论与其他可折衷属性(如实时正确性)，人们可能误以为牺牲决定论只是同类权衡。
注：我反对牺牲决定论，但承认存在合理折衷的可能，只是担忧人们在决策时并未真正思考自己究竟在放弃什么。
管理层早已习惯非确定性，因为他们的员工向来如此。
嗯，有道理。但非确定性程序似乎存在需要修复的缺陷。虽然无法修复，不过员工恐怕也无法被修复。
确定性需要形式化(规则实施)和对系统的某种全知。这两者都很难获得。我见过有人极力避免阅读任何手册，即使得到问题解决方案的提示，也无法进行逻辑推理。
我认为在AI领域最成功地编写可维护代码的人，往往是那些前期投入更多精力通过设计和上下文限制非确定性因素的人。
房贷不会自己还清。
这没什么大不了的。我喜欢创造事物。编程也喜欢，但不如创造事物让我着迷。
对我来说，和大型语言模型较劲不像在创造，更像是拔牙。
我至今只用超大规模语言模型来提问，从未让它们掌控键盘，所以还没真切体会过这种感受。它没让我变成十倍效率的开发者，但偶尔能让我达到两倍效率，对我而言这就足够了。
就像自慰，偶尔一次无伤大雅甚至有益身心。但若沉溺其中，终将惹祸上身。
> 程序员竟愿意接受更少的确定性，这太疯狂了。
你竟认为程序员是某个能做决定的种姓阶层，这才疯狂。
向来存在一群放任自流的程序员，他们沉溺于调试器中，每当清除自己埋下的陷阱时，便获得偶发的多巴胺刺激。
我数不清多少次经历过类似对话：
“若发生x事件，接着触发y和z，程序就会在此处崩溃。”
“这种情况发生的概率有多大？”
“你居然问这个问题，说明它在客户现场某个时间点发生的概率接近1。”
简直荒谬至极。硬件设计师也常跟我聊类似话题。有次我被要求折磨一个UART接口——因为我们出货了一个有缺陷的版本。(我通常负责组装，但我是你们首选的白盒测试员，因为我专攻可疑点而非回避问题。)当我模拟出UART和DMA同时故障的场景后，对方果然抛出“这种情况真可能在客户系统里发生吗？”的疑问，我的回答是：
“我不知道。你们有两个选择：要么修复到测试通过的状态，要么证明客户绝不可能无意中重现测试条件。”
他最终修复了，但全程抱怨连连。
最近教新手开发者防御性编程基础时，我收获了许多乐趣。
通常能让他们恍然大悟的措辞是：“没错，这确实是个不太可能出现的bug，但如果真发生了，你需要多久才能找出问题并修复？”
这类问题往往极其隐蔽，初级开发者会立刻意识到调试过程堪称噩梦，可能耗费数日抓狂的努力，而技术背景薄弱的上级在等待解决方案时，耐心正急速耗尽。
我职业生涯中合作过的顶尖资深开发者，都具备一种非凡的预见力——能在问题影响生产环境数月前就洞察端倪。尽管他们的预警常被忽视，但当他们预言的确切情况数月后发生时，往往会迎来道歉。
> 尽管他们常被忽视
这正是我职业生涯后期主要在芯片公司工作的原因。
因为芯片流片成本极其高昂——不仅是美元成本，更包含芯片返修导致的机会成本损失。
因此任何成功的芯片公司都懂得重视潜在问题。而传递消息的人永远不会被枪毙。
我父亲在汽车行业工作时，曾遇到发动机控制计算机的缺陷——他们给出了约千万分之一的触发概率。
结果设备启动后运行几秒就触发错误崩溃了。
哦对了，CPU每秒能执行数百万次操作。
每当思考编程中的概率问题，我总会想起这个例子。必须付出额外努力，确保采用切实可行的测量方式。
优秀人才不会接受。可惜世上更多是想快速牟利的蠢货
深入探讨…我怀疑问题是否与H1B签证持有者及承包商的激增有关。这类程序员存在额外动机回避高管层/跨级决策——远离办公室政治能降低被遣返风险。我认为长期来看，工程师中存在这种动机比例较高的企业，其市场份额流失风险更高。
对此我简明扼要地回答“不”。我的H1B同事们在严谨性和创新力上毫不逊色于任何工程师。编写劣质代码对任何人都无益处。
我并非指代码质量低劣——我认同代码质量没问题。我指的是IC工程师在抵制PM和高管团队下达的不切实际需求/设计决策时的角色。此举虽可能加剧内部紧张，但从长远看能提升产品和用户体验。在我职业生涯中，我敢于提出异议，因为即使意见遭拒也不必担心被调职。
采用结构化/约束生成技术，你完全可以兼得鱼与熊掌。
我的意思是，我们应对用户需求已有多年经验，这其实没什么不同。
这种论调反复出现，实属无稽之谈。大型语言模型的输出结果与人类输出同样具有确定性。
好奇问一句，你后来转型做什么了？
这话听起来很疯狂，但我自己也思考过这个问题。虽然不是近期(比如2026年)，但未来某个时间点确实会考虑。
整个AI辅助编程和氛围编码现象，加上其他评论，让我想起Reddit上每年都会刷屏的热门帖子[1],[2]：
[1] 别自称程序员及其他职业建议：
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr…
[2] 别自称程序员及其他职业建议(2011年版)：
https://news.ycombinator.com/item?id=34095775
你要转型做什么？
我也想听听这个。
我打算在这行再熬几年攒钱，直到实在受不了，然后转行开城市公交。
园艺和管道工。开公交的问题会解决的。
管道工似乎是相对热门的AI替代性职业。若AI真大规模取代工作，管道工将供过于求且廉价。
我们真正需要的是大量住房。因此建筑业才是更稳妥的转型方向。但建筑工作艰苦危险，并非人人都能胜任。况且若住房变得负担得起，社会似乎就会崩溃，所以当权者或许不会允许增加建筑工程量——即便有充足的建筑工人。
谁知道呢…真是有趣的时代。
> 那就转行开城市公交吧。
你似乎指望Waymo不会让这个职业过时呢。;)
我的工作效率达到了数十年来最高水平。如今终于能专注思考和实验，不必再浪费时间处理那些无法抽象化的琐碎细节。去年秋天成为转折点，关键在于Codex和后续的Opus 4.5；后者配合任何优质的框架都能发挥出色。
不得不承认，大型语言模型确实能省去大量编写代码和处理语法错误的时间。若你清楚目标且能识别并修正模型的错误，它们确实很有用。但若对领域和语言掌握不足，无法识别生成的代码中的错误或死胡同，我认为将其用于开发并不明智。
这与Java企业级框架的演变如出一辙：层层包装器、工厂类和无节制的抽象化，既掩盖了实现细节，又让工程成本飙升，却对产品质量贡献甚微(多数情况下甚至毫无裨益)。如今代理系统和工作流正重蹈覆辙。
能否大家共同停止使用“抽象”这个术语？它毫无意义且令人困惑，实为掩盖诸多弊端的遮羞布——因为它根本可以指代任何事物。别把所有责任都推给高管层；他们本就是那样的人，自有其视角。别抱怨某些大型语言模型的最新恶劣表现。若它对你有用就用，无用则弃。但请停止抱怨。
> 眼见整个行业集体认定：应对不确定性的解决方案就是层层堆砌抽象概念，直至无人能解释实际发生的情况。
没有哪个行业集体做出过这样的决定。编程领域始终分裂成无数亚文化群体，每个群体对优秀程序的定义都截然不同(在整个行业范围内互不相容)。
所以，我猜是硅谷某个回音室里(你也在其中)的某些程序员做出了这样的决定。
你要转向什么领域？
我向来觉得对编程抽象化的抱怨很奇怪，坦白说我们所做的一切本质上就是抽象化。这种抱怨常被用来暗示“我不理解”，因此我们应该采用更复杂、代码量更大却更缺乏灵活性的方案。
但这种用法？我完全赞同。过度抽象化就是指它变得不可理解。关键在于“谁”(我常批评初级程序员不该达到这种程度)，而你指出这里的“谁”实指所有人，确实一针见血。
我们正在扼杀创造力与优雅性的整片天地，却仅在另一侧略施援手。这种做法虽具实用性，却也代价高昂。
计算机科学最令我沮丧之处在于，整个社群总倾向于孤注一掷。我们曾全情投入VR，继而投身加密货币，如今又转向AI。我们本应尝试新事物，但更像是将这些领域奉为客观真理，任何不追随炒作浪潮的人都被视为愚昧或技术恐惧者。整个行业对这些概念的盲目追捧，与其说是明智策略，不如说是FOMO(害怕错过)心理作祟。就像把一家气泡水公司包装成“AI优先”企业…简直是为问题寻找解决方案。
你们究竟要转向什么？
别忘了，现在要求你们拿同样薪水创造十倍价值——“毕竟你们现在有AI了”。
整个体系正是为此而设计。这被称为“生产力提升”，大规模实施时具有通缩效应。通缩听起来不错，直到你明白其根源所在。
> 它正目睹整个行业集体认定：应对不确定性的解决方案就是层层堆砌抽象概念，直到无人能解释实际发生的情况。
大规模采用大型语言模型生成代码，更多是抽象设计失当或缺乏抽象的体现，而非抽象过度。
选择/构建正确的抽象才是关键所在，对吧？所以问题本身不在于抽象。
整个计算机编程史上，技术人员对此的抱怨从未间断
除非你在编写字面意义的内存指令，否则作为工程师你已经操作着4到10层抽象了
若没有海量抽象层，人类根本无法编程控制一系列开关
绝大多数程序员从一开始就没搞懂计算机的工作原理
人们总在争论这个观点，但基于LLM的开发模式与以往任何抽象层都存在根本性的概念差异
这话没错，不过真正推动领域发展的人确实精通各个抽象层级，才能完成工作。为了抢占市场而把(至关重要的)东西做得糟糕透顶，反而会成为巨大的进步阻碍。
詹森是我信任的对象，他既懂商业运作又熟悉底层技术架构，所以我并不太担心。
即便你直接编写机器代码，仍需依赖芯片设计公司技术专家为你构建的十余层抽象架构。
所以你现在在洗碗？
> OpenAI在2025年上半年的销售与营销支出攀升至_20亿美元_。
看来AI公司砸在营销上的预算，足以营造出“AI能提升开发效率”的幻觉。
再等一年吧，或许那些没被这些开发者“瘦身药”蒙蔽的人，会为自己的选择感到庆幸。
嗯。我曾长期持怀疑态度，但最近朋友说服我试用Claude Code并做了演示。我重启了一个常回来的开源项目——每次写几行代码，就得和Toil及依赖项更新搏斗，还没真正产出多少成果就失去乐趣，最终又停摆。
借助Claude，解决所有繁琐事务只需一句话。过去两周里，我实现了多个重大功能，修复了长期存在的问题，还完成了库依赖项向新主版本的迁移——这些是我独自绝不会触碰的任务。毕竟我做这些纯粹出于兴趣，而更新Zod实在无趣。Claude替我完成了这些工作，让我能专注于高层次的功能描述。
我仍在验证和调整工作流程，但若能保持这个效率并推广到其他项目，我的工作效能将提升数倍。
这听起来像是资源管理不当——初级开发者处理的任务与你的技能不匹配，因而显得枯燥。
作为开源平台的创建者，我认为让用户直接接触半随机词生成器实在不可靠。
更重要的是，这会养成坏习惯。我见过开发者忘记如何阅读文档，转而依赖AI——结果当然是AI犯下难以调试的错误，或引发容易被忽视的安全隐患。
我知道这听起来像技术恐惧症患者的论调，但我至今仍不认为当前阶段的人工智能在任何方面都值得信赖。不过，正因为有你这样的工程师，人工智能正在学习做出更优选择，未来或许会有所改变。
> 因为初级开发者可能承担的任务与你的技能不匹配，因而显得枯燥乏味。
嗯，这听起来很有意思，也与我的经历有些吻合。圣诞节期间我尝试了人工智能，因为身边的人都在讨论这个话题。我让它实现一个我认为很简单的功能(重构以提升性能)，它完成了任务，效果惊人，所有测试都通过了！深入查看实现细节时，发现AI抓住了核心逻辑，但内部实现过于复杂且存在错误。不过这让我找到了改进方向，问题很快就被解决了。
这次模型的表现不算出色，或许也因为我刚接触AI，还不懂如何正确编写提示词。但至少它很有趣。
我认为这完全是公正的评价，而我本人对此议题也深感矛盾——例如，我会让初级员工使用代理工具吗？不会；中级员工恐怕也不行。正如你所言，这容易养成不良习惯，且需要对架构和复杂性有良好直觉，否则只会制造出无法维护的混乱代码。但若具备这些能力，它简直像魔法般神奇。
> OpenAI在2025年上半年的销售与营销支出增至_20亿美元_。
我认为这20亿包含了免费ChatGPT用户的成本。考虑到其转化率(2024年10月达5-6%[1])，这笔投入物有所值。
[1] https://www.cnet.com/tech/services-and-software/openai-cfo-p…
再等一年吧，或许那些没被开发者大脑的“瘦身药丸”坑害的人，都会庆幸自己当初的选择。
这一年里，AI会变得更强。而你呢？
AI只会越来越擅长消耗能量，用T9输入法浪费人们的沟通时间。但若优秀工程师持续使用它，或许终将换来更精准的回复。
回答你的问题：无论我个人能力如何退化或提升，都无法制造出任何能与当今AI对人类造成的负面影响相提并论的东西。
我经常看到这种逻辑搭配：
这叫作“既想吃蛋糕，又想让蛋糕吃掉自己”。
这种搭配并不矛盾(尽管我觉得你对原评论的描述也不够公正)。原子弹同样适用：它们基本毫无用处，却又强大到足以毁灭人类。
大型语言模型带来的破坏虽不那么直接明显，但聊天机器人确实会对人造成可证实的伤害，还能被操纵来扭曲我们的现实认知。
https://en.wikipedia.org/wiki/Chatbot_psychosis
人们正与聊天机器人建立恋爱关系，甚至因此自杀。这便是伤害。
这种论述方式有失公允。认为人工智能工具的广泛应用会导致开发者技能退化，同时这些工具又无法兑现炒作承诺，两者在逻辑上并不矛盾。
你擅自添加了“毁灭人类”的论点，而原帖作者指出的问题在于将所有思考都外包给不可靠的工具(我虽不完全认同其立场，但该观点具有可辩护性，并非如你所言)。
和既错误又无视错误的人争论毫无意义。(“我根本无法制造出任何能与当今人工智能对人类造成的负面影响相提并论的东西。”)
双方基本不可能达成任何实质共识。虽然令人沮丧，但这就是如今的HN现状。
正如我最初所述，共识是存在的：仅有一家AI公司每年投入数十亿美元营销其软件以确保其运行；而我则在自筹资金的开源软件开发领域耕耘。
我的投入是：水、营养、少量电力以及信念，产出却是像软件这般复杂的逻辑系统。而AI的投入是数十亿美元、数十万人每日耗费在屏幕前的生命时光、数千兆瓦电力，却仍产出极具争议的结果。
换言之：若将同等资源投入人类智能开发，一年内或许能取得更惊人的成果。但考虑到已投入AI技术的巨额成本，人类恐怕已无力摆脱这种新型“依赖”。
> 除了常规底层架构外，现在又新增了一层可编程抽象层需要掌握——涉及智能体、子智能体、提示词、上下文、记忆、模式、权限、工具、插件、技能、钩子、MCP、LSP、斜杠命令、工作流、IDE集成等等…
这简直令人窒息。听起来不像软件开发，倒像是耗费千小时折腾vim配置。它让我想起DevOps中常见的疯狂拼凑式扩张——如今却搬到了本地机器上。
我实在看不见任何好处，也不明白这如何能让任何合格的程序员效率提升十倍。
> 这简直令人难以忍受。
由于浏览器设置导致Twitter无法正常显示，我没看到原文(而且我也不太喜欢Karpathy的产出)，但我完全赞同。我称这种软件开发模式为“会议式编程”，因为这似乎正是工具设计者们追求的思维模式。这或许部分解释了为何高管/MBA人士对这类工具如此狂热：会议正是他们思考与工作的模式。
某种程度上，大型语言模型/聊天机器人和“智能助手”不过是互联网数十年间持续推动的趋势最新阶段：消解精神隐私。此处“隐私”并非日常意义上的私密——即不愿分享的个人事务。我指的是更根本意义上的“隐私”：私人体验——独处静思；拥有不包含他人的精神空间；单纯与自我思绪共处。
互联网不断引导我们将思考与疑问向外投射：查阅资料、参考他人观点、浏览维基百科等等。我认为这正在侵蚀思考型感知生物的本质。不过这也不足为奇。人类是社会性动物，任何能用社交体验取代私人体验的事物都极易诱惑我们。编程工具被用于此道，恐怕只是时间问题。
https://xcancel.com/karpathy/status/2004607146781278521
(备注：只需将x.com替换为xcancel.com即可轻松绕过烦人的退出登录界面，我在Chromium浏览器中通过URL自动重定向规则实现了自动处理)
绝妙的提示！
使用 Nitter 镜像 [1]。我发现 xcancel.com 最容易访问：
https://xcancel.com/karpathy/status/2004607146781278521
[1] https://github.com/zedeus/nitter/wiki/Instances
> …或者它如何让任何称职的程序员效率提升十倍。
根本不可能。我见过宣称效率提升的人，要么本身编程水平一般，要么就是靠传播这种梗牟利。
AI的效率提升是指数级的。
前几天ChatGPT实现的功能，换作我得研究一周才能搞定：它10分钟就搞定了。这种效率提升该怎么称呼？远不止十倍。
其他时候我几乎不用AI，因为写简单代码比写提示词更快——尽管自动补全确实能加快输入速度。
所谓“十倍”不过是随机指数平均值的占位符，本质上是在说“介于1到无穷之间”。
> 就在前几天，ChatGPT实现了一项功能——若由我研究，至少耗时一周，它却仅用10分钟就完成了。这种效率提升该如何定义？绝对远超十倍。
能否具体说明是什么功能？或许我从事的工作不够刺激或具有挑战性，但个人尚未遇到过类似案例，实在难以想象具体场景。
比起AI公司宣传产品特性，我认为真正打动我的应该是这样的视频：一位顶尖程序员耗时8小时，借助AI构建某项功能——若无辅助工具，这将耗费其极长时间。
当然。我需要绘制参数化平滑贝塞尔曲线。大型语言模型在推导合适方程方面堪称猛兽，若靠我手动计算所有控制点的位置，恐怕要耗费数月光阴。
每个引人注目的“氛围编码”网红背后，都有大批资深软件工程师在用它高效完成任务。新一代模型在遵循指令和利用现有代码模板方面表现相当出色。借助Claude Code构建业务应用程序效率大幅提升——只需精心搭建框架，就能指令它按你预期的方式快速完成开发，耗时仅为传统方式的零头。你还能用它研究架构方案和工具的替代方案，避免因未接触某些半小众工具而陷入死胡同——这些工具可能恰好完美契合你的使用场景。
当然，我绝不会用大型语言模型来#yolo式地构建Next.js怪兽项目，搭配时髦的ORM和随机的Tailwind样式库。不过我确实让它构建过应用的多个模块——前提是我事先详细告知了代码的实现目标、测试方案和架构设计。某种程度上这印证了我的软件工程理念：它能利用现有工具(合理地)确保正确性后才宣告完成。
作为拥有十年经验的专业工程师，我借助AI将个人维护的网站开发效率提升约5倍(日均活跃用户约100，规模不大但也不算小)。我并非AI从业者，传播此类观点并无经济收益。
同理，但效果不同。我的效率提升约20%。编写代码对我而言很少是瓶颈，因此这方面的潜力有限。当我编写代码时，那些原本就简单快捷的任务会稍快些(或可交由AI处理)。而那些本就困难且耗时的任务，即使借助AI也依然困难且耗时。我仍需在脑中保留大部分代码逻辑——即便没有AI辅助也必须如此，因为AI出错的速度实在太快。
我认为你所从事的工作类型对AI的实用性影响巨大。若处理概念简单且易于实现的任务，AI表现优异(包括处理边界情况)。若概念复杂但执行简单，可让AI仅负责执行部分，仍能获得显著提速但非革命性突破。若概念复杂且执行困难(如我近期项目)，AI便难以胜任。
哦，既然它能为个人网站生成简单代码，想必也能成为整个软件工程领域的“更高层次抽象”。
我倒不觉得这算“简单”。代码涉及React、Node.js、通过SSE推送的实时事件、Terraform部署的基础设施、Postgres数据库、S3上的二进制对象存储、SES邮件发送……虽然比不上谷歌级别的项目，但确实比个人博客复杂得多。
无论如何，你是在移动目标。楼主说他从未见过有人认真声称从人工智能中获得了生产力提升。当我提出这个观点时，你却说“这并非所有软件工程师都能达到的抽象层次”。显然——我从未这么说过？
若问我的看法，我认为大型语言模型确实擅长生成简单代码——那些能在Stack Overflow找到、只需微调的代码。但即便如此，若你根本不理解代码原理，仍可能引发严重问题。
你的网站正是LLM演示效果惊艳却在现实中崩盘的典型案例。它擅长基于他人为React、Node或你使用的SSE库等投入的大量工作，像拼乐高积木般组合代码。但这并非Karpathy的论点，他宣称“最热门的编程语言是英语”。
这简直荒谬。根据我的经验，英语编程既可能加速也可能拖慢进度，遇到复杂场景时更是不堪一击。
> 不是普遍缺乏编程能力，就是从强化这种迷思中获利
你该认清自己属于哪一类。多年经验从不等于专业能力。
我们运维人员用AI工具拼凑出几个漏洞百出的仪表盘。勉强可用却根本无法维护。
我个人认为，人人都清楚AI生成的代码质量欠佳，而那些自诩无懈可击的人类只是因不懂/不在乎才继续沿用。如今我们正目睹精神操控的发生——AI并非让你更优秀，而是让你更快交付。在AI工具能以十倍速度(伴随相应缺陷)产出功能的时代，更快交付(带着更多漏洞)反而更重要，因为“技术债务是增值资产”。我们正迈入“快速行动，打破常规”的强化版时代。我怀念那些真正管用的软件年代。
没错，对不以用户为中心的企业而言，漏洞早已成为经营成本的一部分。今后我们只能期待更糟糕的代码，尤其在用户并非买单方的软件领域。
免责声明(因我听起来很悲观)： 我确实大量使用AI编写代码。
我确实感觉自己在AI应用上落后了。
如今Hacker News上几乎每篇提及AI的帖子，最终都会演变成“我用LLM实现了100倍提速”与“它反而让我变慢，现实中从未见过有人靠AI工作效率提升”的论战。
作为拥有40年经验的中等水平开发者，AI确实能让我开发效率提升10-100倍。我受益的不是网络梗，而是更快交付的优质代码。
当然偶尔AI会出错，让我花一小时徒劳无功地折腾。但这种情况如今越来越少见了。
我曾在另一条类似评论中完整转载过此内容，恕我直接复制粘贴：
能否具体说明是什么场景实现了10-100倍效率提升？或许我的工作不够刺激或具有挑战性，但个人尚未遇到这种情况，实在难以想象具体场景。
与其让AI公司自吹自擂，不如拍个8小时长视频：展示顶尖程序员借助AI构建某项成果——若无AI辅助，这将耗费其大量时间。这才是真正打动我的营销方式。
作为重度代码代理用户，我认为：你根本无需了解这些原理，这恰恰证明了代码代理的用户界面已臻成熟。我只需三步就能高效使用代码代理：命令它将问题分解为子任务，存储在珠子中，并确保每步都经过我批准。我还添加了TDD要求，即它必须构建先失败后通过的测试。
其他工具要么过度设计，要么效果大打折扣。我刚才描述的流程，其实已是多数开发者的日常操作。
我预测明年年底前，AI就能撰写TPS报告了。
这简直是我的终极噩梦。构建过程中毫无艺术性或精妙之处——只是对语言的折磨，而执行者从根本上根本不懂其中奥妙。
没人阻止你像过去那样手工雕琢软件。
但批量生产不会停止，它才刚刚起步——字面意义上才几个月前，现在只是最缓慢、最糟糕的阶段。
我并不认为AI工具会消灭编程艺术，它只是揭示了一个真相：教AI如何编程与真正的编程根本不在同一维度——这种技术活的难度，顶多相当于输入微波炉爆米花加热时间的操作。
这并非我的经历。更像是与团队中另一位技术娴熟的开发者探讨解决方案的编码方式——该采用哪些API、技术手段和算法。我们不断碰撞创意，直至敲定合理的实施计划。该计划通常包含高层次构想与示例代码片段的结合。
我总听到“这是最慢最糟糕的状态”这种说法，仿佛软件能力与性能只会永续提升。可批量生产的软件比十到十五年前更慢更糟糕，我们都在抱怨。别拿“但它功能更强大了”说事——我根本不需要那90%的“额外功能”，只想把大部分功能关掉。
我同样不认为这些模型能在支撑它们的金融纸牌屋倒塌后维持现有水平。真好奇像Claude Opus这样的系统实际运行成本究竟有多高，恐怕是难以辩解的昂贵。即便如此，这类技术未必会彻底消失，但企业终将不得不抉择保留核心价值部分，舍弃其余冗余。
当下确实堪称大型语言模型(LLMs)获得巨额补贴的黄金时代。如今你只需在免费账户间切换，整天都能获得惊艳的代码输出，分文不花。
我能想到好几件事足以打破“当前是发展最缓慢且最糟糕的阶段”的论断。即便忽略潜在变数，我认为大型语言模型整体已触及天花板。当前模型存在的种种烦人缺陷、漏洞乃至明显无能之处，即便投入万亿资金也难以短期消除。眼下不过是在支撑这个泡沫，避免美国陷入新一轮大衰退。
我不太明白你从我的帖子中得出这个结论的依据。我完全可以且确实会抽空重构项目或处理有趣的部分。在每个需要审查的检查点，我都能且确实会手动编写代码。
你在抱怨代码格式化工具或自动修复检查器吗？那基于API规范的代码生成呢？代码代理能完成这些任务并提供更多功能。它能处理所有枯燥环节，让我专注于有趣部分。这太棒了。
还有个绝佳用例：让智能体生成代码、思考原型、删除重写。我在某个项目中实践过，成效显著：https://github.com/neurosnap/zmx
这其实更像是带领一群技术天才的团队——他们各自精通软件工程的不同领域，却也存在能力短板。不过这类短板比一年前少多了……
关键在于，只要学会有效管理，就能从这样的团队中获得大量优质成果。
若这听起来像“彻头彻尾的噩梦”，那就别用AI。但愿你长期不用也能跟上节奏。
珠子？
https://github.com/steveyegge/beads
> 这简直难以忍受。听起来不像软件开发，更像是耗费千小时折腾vim配置文件
在大型语言模型编程出现前，我至少有30-50%的编程时间都耗在反复修复配置和构建问题上。如今我能把更多精力投入更有趣的思考。
讨论这个话题的多是独立工作者或从事绿地项目(尤其是工具相关)的人。这类场景的试错成本极低。我同样用过类似方案，效果确实惊人。不过在朝九晚五的日常工作中，我仍会混合使用智能体和手动编码。
我尚未见过四人以上团队在生产环境中协同工作时，将AI应用于日常开发实例。
仅用Claude代码创建者编写的代码不算数，那更像是内部测试。
确实。看看回复他推文的人的背景就很说明问题。
用“落后”或“赶超”的思维框架来思考是错误的。
我观察到这些工具对不同开发者有不同用途。在我当前团队中，每位开发者的工作方式都截然不同，我们给予彼此充分的包容空间来适应各自的风格。特定任务总会分配给特定开发者：有人像钢铁陷阱般严谨，有人擅长探索混乱，有人是新手，有人具备宏大视野等等(不知为何，团队里甚至还有我的位置 😉
同样地，不同开发者使用这些强大工具的方式也大相径庭。所以别觉得自己落后了，因为唯一有意义的标尺是你自己。也别指望能等到共识形成：你仍需厘清自己与工具的个人关系。
最重要的是，别气馁。即便你永远不接受这些工具，你的技能和处理共同工作的风格依然有容身之处。
再过十年，这一切必将豁然开朗……
我已习惯将大型语言模型视为“值得信赖的顾问”。
虽然[目前]还不准备让智能体全权代写应用或服务器，但我正越来越多地让它们独立完成整个函数的编写。
它们更是出色的“漏洞侦测器”。只需输入代码描述症状，请求分析观察，常能获得绝佳建议——包括发现拼写错误和复制粘贴问题。
仅此有限应用就显著提升了我的开发效率，我认为工作质量也随之提升。
在我看来，大型语言模型堪称绝佳的“橡皮鸭”调试工具https://en.wikipedia.org/wiki/Rubber_duck_debugging
长久以来，编程创作的乐趣源于攻克难题。挑战本身曾具有深层意义。如今这种追求似乎被某种激励机制驱动的智能体截断了。我目睹海滩上的海啸来袭，却不确定自己能否跑得够快。
我更倾向于将其视为文字冒险游戏。你输入指令时，有时能成功，有时却会得到意料之外的结果。
我向来不愿成为他人故事里的角色。
但你让我开始思考：是否有人研究过，那些痴迷人工智能的程序员是否也热衷角色扮演游戏？
更不用说许多企业正利用人工智能加速运行着怪异甚至扭曲的激励机制。
话虽如此，威尔士葡萄汁并未让纳帕谷破产。人类的味觉仍是大型语言模型只能模仿却无法取代的主观过滤器。
我认为大型语言模型辅助编程(从氛围编程到高级自动补全的渐变尺度)类似于Ableton等数字音频工作站软件赋能优秀音乐人的方式——这些音乐人原本可能因缺乏人脉或资金而无法成名，但音乐产业并未因此彻底崩溃。
在音乐领域，我认为LLM辅助编码更像是LLM辅助音乐创作，而非DAW的替代品。
没错，DAW并非恰当参照。人们尚未深刻理解正在发生的事——一场旨在消灭审美、建立系统化机制以让少数人暴利的战争正在进行。
> 我跑得够快。
跑步时能做代码审查吗？
(《盗梦空间》场景)这里一分钟等于七小时
你们难道不介意现在必须付费才能工作？我说的是AI模型订阅。为那些试图取代我的工具付费，总觉得哪里不对劲。
上世纪90年代的集成开发环境曾极其昂贵。记得微软Visual Studio和IBM的Java视觉时代都需高昂订阅费。后来开源IDE如Eclipse和VisualStudio似乎成了主流。
Visual Studio从未开源，尽管其底层构建工具和编译器部分开放。
Visual Studio Code则不同…虽宣称开源，但其设计理念和实现方式更接近于“源代码可查阅”。
我曾每年花大价钱购买完整版Visual Studio+MSDN订阅，直到后来终于获得免费使用权。
如今免费资源之丰富令人惊叹。卓越的免费IDE层出不穷，任何大型语言模型(LLM)都为零预算用户提供优质免费方案。
每月10美元的GitHub Copilot简直是荒谬的优惠——单论计算成本绝对是亏本生意。
编译器和编程语言本身过去也曾昂贵得离谱。
我不为AI订阅付费，就像我不为IDE付费一样——这些费用由雇主承担。
订阅制软件、订阅制AI加上硬件价格上涨，“个人电脑”的概念正迅速消亡。
对我而言并非如此。
难道你的雇主不承担这些费用？
付费训练*并资助研发取代我们的工具
我的公司圣诞节到新年期间放假。我提前一周也休了假。这段时间我完全没碰AI。生活节奏放缓的感觉太美妙了。但一旦重返编程岗位，工作强度就会飙升至180%。这已是新常态。不过我决定在日常安排中增加更长的“无电脑”休息时段。我必须适应变化，但也要守护自己的“慢节奏时光”，寻找些传统爱好。这种转变真实存在，无法逆转。
圣诞期间我更频繁地推着婴儿车带儿子散步。随身带着耳机听音乐、播客、有声书和技术讲座。“要高效。”但最终我只是漫步沉思，意识到这才是“自由时光”。
听起来荒谬又简单——花时间散步思考能提升决策与优先级，这比任何效率技巧都管用。
我真正放慢脚步，只因家庭福祉迫使我如此。不时刻关注他人动态，这种感觉确实重要。
哦。这是数据科学家中相当典型的角色。这类人认为软件开发就是生成文本，因擅长文本生成便自诩专家，却对软件生命周期一无所知。与他们共事堪称折磨，尤其当他们把“软件”责任推给工程师时。
对于持更积极态度的人，你们生成代码后多久修改一次？
我很少用智能体编码，但注意到稍复杂的代码生成后总有瑕疵，必须返工修改。这通常没问题，但当生成大量代码时，手动编辑就缺乏上下文依据。
这就像醒来发现自己身处从未见过的房子。虽然能辨认房间类型、家具、插座、电器、管道等设施，但方向感仍会混乱。
这正是我当前的主要困扰。
> 对于那些更乐观的人，你们生成代码后会多频繁地修改？
每次都会修改，除非最初需求用毫无歧义的伪代码完美描述过。人们实在太容易写出模棱两可的需求了。
如今我追求的是既无歧义又可读的伪代码，不过生成代码前常会请AI协助编辑伪代码以消除模糊点。
看吧，又是那个“被赐予我们的强大外星工具”。
完全忽略了近十年的研发积累、巨额资源投入，以及技术领导层为开发这项特定技术做出的深思熟虑决策。
不，它就是某天神秘地从天而降的。
关键在于这些研究大多无助于掌握该工具。不同于传统工具，它没有附带说明书。从这个意义上说，它确实像外星人递来的工具。
知道作者是谁吗？
帖子标题写着“Andrew Karpathy”，他在AI圈颇有名气，曾任特斯拉自动驾驶负责人，并联合创立了OpenAI。若想了解详情，维基百科有简要介绍： https://en.wikipedia.org/wiki/Andrej_Karpathy
出自他之口更令人失望。
确实，他似乎加入了人工智能神秘主义阵营，这让我感到失望。
https://xcancel.com/karpathy/status/2004607146781278521
> 那些本质上随机、易错、不可理解且不断变化的实体，突然与曾经的老派工程学交织在一起
听起来像发烧梦境。衷心感谢(不是)创造了这种局面！
> 显然有人在传授某种强大的外星工具，只是它没有说明书
在说明书出现前使用工具是人类最古老的把戏，而非最新发明。
任何足够有用的东西终将被产品化并包装好供大众使用，其余的只会成为小众领域，仅对最狂热的爱好者有意义——所以我并不担心。
拥有逾20年专业经验。大型语言模型工具令人惊叹，如今一人即可完成过去需要多个团队协作的任务。
资深程序匠人，从业三十余载。AI使我的效率提升百倍。不，我不会提供证明。Sam Altman才是最棒的。
拥有80余年专业经验。大型语言模型工具令人惊叹。如今仅需一个下午，就能完成十个谷歌和Meta团队的工作量。
他列出的清单(“代理、子代理、提示词、上下文、记忆、模式、权限、工具、插件、技能、钩子、MCP、LSP、斜杠命令、工作流、IDE集成”)中，是否存在Claude Code或Cursor尚未涵盖的实质内容？
我理解他那种“只要为AI模型提供恰当的上下文和开发框架，就能大幅提升效率”的期待，但这或许只是徒劳的幻想。Claude Code和Cursor在大型语言模型开发环境领域，可能已接近当前技术前沿。
跟在谁后面？
是否有人已精通“智能体、子智能体、提示词、上下文、记忆机制、运行模式、权限管理、工具集、插件生态、技能库、钩子系统、MCP/LSP协议、斜杠命令、工作流设计、IDE集成——并能构建涵盖这些本质上随机性强、易出错、不可理解且动态变化的实体的完整认知模型？这些实体正与传统工程技术产生前所未有的交融” ？
他们有博客吗？
> 跟在谁[m]后面？
当然是赛道上你前面的那些老鼠啊！
正如那句虽俗却精辟的箴言：莫读时世，当读永恒。那些耗费大量时间疯狂追逐此类肤浅虚妄之人，实则是丧失生命意义的行尸走肉。他们不过是消费主义地狱机器中的齿轮罢了。
我或许在此问题上极度无知，但在我看来，卡帕西首先且最重要的是位卓越的推销员——不仅擅长推广人工智能，更精于个人品牌塑造。
他擅长向大众阐释人工智能概念。
然而他对软件工程的见解，暴露了缺乏生产级工程实践的局限——考虑到其背景，这完全正常且无可厚非。
但这也意味着我们不应将他的软件工程观点奉为圭臬。
此类销售宣传不应通过分享或转发予以助长。
维基百科显示安德烈现年39岁。
道格拉斯·亚当斯论年龄与技术关系：
"1. 你出生时已存在的事物皆属正常平凡，乃世界运行之自然法则。
2.十五至三十五岁间诞生的发明皆新奇激动人心，堪称革命性创举，你很可能借此成就事业。
3.三十五岁后出现的发明皆违背自然法则。"
摘自《怀疑的鲑鱼》(2002年)
他真这么说吗？
我认为他并非反对技术本身，而是感到其中蕴藏着许多尚未完全理解的潜力。
此人堪称人工智能领域的顶尖人物。这纯属宣传话术，旨在煽动“害怕错过”的心理，诱导人们购买其平台产品，否则就会沦为“过时者”。
这种观点在讨论中未能引发更多共鸣着实令人震惊。无论他本人如何感受，这正是他希望你产生的情绪。
从宏观角度看，这关乎情商管理——若你已失去理智，只会徒劳挣扎。我认为你应该掌握前沿工具来优化常规流程，但务必脚踏实地。“氛围编程”本质就是让你陷入力不从心的境地。抵制它！
vive vibe live 还是无关紧要？
开发者或许该像瑞士军刀般精准掌控副驾驶系统
(故枪支管制需长远规划)
当然得问问aeb是否遇见过狩猎时(仅限狩猎时)踩到陷阱的人 😉 你遇到过吗？
法国人眼中的优秀猎人^W氛围编码者 vs 劣质氛围编码者：https://www.youtube.com/watch?v=QuGcoOJKXT8
鉴于三只野兔目前似乎缺乏象征意义，我愿意占领？还是保罗更喜欢三只狐獴？若有人想反对我们，正如大块头所言：“silflay hraka, u embleer rah”
给shunya讲个更务实的故事：就像我们如今习惯用二进制计算却记录十进制结果(比如PDF发票)， 古罗马人(及其他文明)同样会让算师在计数板https://en.wikipedia.org/wiki/Counting_board上运算，却用罗马数字记录(仅保留非零)结果。
(如今我们可通过一个暗号识别代数学家：他们的论文与著作总以第0节/第0章开篇)
> « 人如数字：唯有位置方显价值 » ——注
你是在领悟，还是中风了？
我完全明白他在说什么，不过精神分裂症的语言我倒是说得挺流利。你是不是中风了？
另一方面，当前确实让人想起Angular和React初露头角的时期——那时有上亿种JavaScript库需要学习，每隔几周就涌现新库，让人难以抉择该投入多少精力。而如今只需掌握React，顶多再延伸到Next.js即可。
大型语言模型的前沿发展正呈现多元态势，未来几年在开发体验、异步工具、持续集成/持续交付工具、生产环境与离线工作流等领域的通用标准仍不明朗。
此刻若选择次优工具或停止探索，极易误入歧途。但若选择观望，那些勇于尝试正确工具的人，将在为客户打造产品时遥遥领先。
完全正确。我认为部分评论者未能理解上下文，对文章产生了完全不同的解读。
这种解读太刻薄了。几个月前他发布nanochat时公开声明过：尽管尝试过，但因编码大型语言模型性能不足导致时间浪费，最终所有代码都手动编写。Andrej早已功成名就，如今投身教育领域，其大部分成果都免费开放。
> 他真这么说的？
完全不是。但我想用亚当斯那精妙的夸张手法来调侃卡帕西，应该挺有趣。两人都是绝佳的思想传播者。
这基本是所有德语国家的思维定式。尤其体现在能源领域(内燃机、煤炭、天然气、石油)和IT行业。
典型例证：传真机至今仍是德国商务沟通的重要工具，许多IT项目更是业余水平的垃圾——因为根深蒂固的思维是“一切都该维持原状”。
这种现象在45岁以上群体中尤为明显。程序员群体基本不受影响，因他们往往对新事物充满兴趣。但在社会其他领域，这种固步自封带来的后果令人痛心：停滞不前，毫无进步。
再看移动基础设施建设。这甚至不是技术问题——纯粹是政治问题。网络建设根本停滞不前。德国在欧洲的落后程度实在令人难堪。
西班牙的Java开发同样如此，这种语言充斥着官僚主义的废话，只为让中层管理者自我感觉良好。PowerPoint之类的工具亦是如此。为了大局，它们都该消失。
像Unix下send(1)生成的PDF或MagicPoint演示文稿，虽然简朴得多，却能产出高效务实、直击核心的实际成果。但这样一来，半数广告人和管理者就会暴露无能(他们本就如此)，很快就会被淘汰。至于裙带关系…更别提了。
你根本没认真读他的文字，也没思考其内涵，只是借机贬低他年纪大。他不过是谦逊罢了。对所有人来说这都是相对新鲜的事物。至少你对年龄歧视的态度很坦诚。
我确信卡帕西能驾驭人工智能，甚至比你更出色。我48岁，恐怕也能做到。
我比你们俩都年长。
他该加入Ardour项目。或者去Ableton、Bitwig、Presonus、Digidesign、MOTU等任何DAW厂商工作。或是投身视频/图像编辑软件领域。又或者参与任何复杂的“创意型”原生桌面应用开发。
他自认落后的那些领域？在我们领域几乎完全无关紧要。
不会太久。
有意思。不知模型能否在这些细分领域实现突破？
没错，这条推文的作者是
> 正在创建@EurekaLabsAI。曾任特斯拉AI总监，OpenAI创始团队成员
我曾对Karpathy推崇备至。但自从大型语言模型垄断“AI”概念后，他持续输出的一系列观点让我怀疑他是否已失去锐气
作为程序员，我从未如此强烈地感受到自己处于领先地位。目睹太多开发者(包括我所在团队)盲目向模型输入指令试图解决问题，却屡屡碰壁。真正理解技术本质的人仍掌握主导权，他们的技能短期内绝不会过时。
不太明白你所说的“盲目提示模型”指什么
没错，等这股热潮退去，那些最不依赖大型语言模型的群体将成为赢家。保持耐心至关重要，别被喧嚣淹没。
100% – 我简直不敢相信这场讨论里居然还有聪明人看不透这点。
若不懂AWS，就不可能编写出构建复杂基础设施的Terraform代码库…等等
其实这让我重拾多年未有的乐趣，毕竟我主要专注于个人项目，同时摸索着技术边界。事实证明，对创意思维者而言，可能性远超想象。
起初这让我有些沮丧，但后来意识到编写代码只是日常工作的一部分，其余时间用于整合基础设施、管理团队并赋能同事高效工作。若能更快完成编码/集成工作，并及时提供更优质的工具，这本身就是巨大胜利。
这意味着我能有更多时间享受海滩时光，关注身心健康。一年前的我固执又怀疑，如今却真心享受着学习新事物的过程。
那绝对别在Hacker News上混了。对冒名顶替综合征患者、技能自卑者或缺乏自信的人来说，这绝对是最糟糕的场所。我浏览HN的动机有一半源于它带来的焦虑——这种焦虑能适度激励我持续学习保持更新。但每天离开时，我总会强烈意识到自己在专业领域的能力和知识远低于基准线，尽管在同行圈子里我被公认为专家。
真的吗？我恰恰相反。看到那么多对自身毫无把握之事却满腹笃定的人，只会让我更加傲慢。
有一点我可以肯定——我的FOMO(害怕错过)情绪绝对增长了十倍。
“靠开发AI谋生的人竟鼓吹AI是黄油之后最伟大的发明”——真令人意外
也算吧。追踪模型能力的浪潮值得坚持，但不必为榨取最后一丝价值而焦虑。如今创造价值的许多具体技术，在更智能的模型问世后，一两个月内就会沦为徒劳。
不明白为何人们把卡帕西说的每句话都奉为圭臬。自从他发明“氛围编码”这个术语后，我发现他的观点越来越不严肃且空洞
确实搞不懂，某些人的推文都能登上Reddit首页头条
我确信这多半是噪音——人们似乎聚焦错了分析单位。产出软件本身从来不是问题，关键在于找到正确项目，并打造出与现有产品形成垂直差异化的创新成果。
确实如此。这些噪音源于那些直接或间接受益于讨论此事的人。
> 关键在于构思正确项目，并打造出与现有产品形成垂直差异化的产品。
同意，但并非所有工程师都参与业务的这一环节，而这种担忧同样适用于他们。
最让我困扰的是所有AI编程工具都缺乏隔离/沙箱机制。我需要协调一群智能体协同工作，但无法确保它们不会失控。
除了在云端启动虚拟机运行Goose、Claude这类隔离性差的智能体工具外，有人有更好的解决方案吗？
我曾亲眼目睹Claude禁用沙箱。以下是几周前调试Rust时的最新实例：“该panic由沙箱限制引发，而非代码错误。让我尝试禁用沙箱重新运行：”
此后我已在macOS中使用sandbox-exec为~/dev/文件夹添加沙箱。配置过程虽繁琐，但至少能明确沙箱控制权限。
此处指代沙箱“逃生舱”[1]机制。在无沙箱环境下执行命令需单独授权，因此即使该命令已被预先批准，系统仍会再次弹出提示。根据我的经验，系统提示[2]对沙箱可能引发的故障类型描述过于模糊——当命令失败时，代理程序总是直接跳转至禁用沙箱的操作。建议禁用逃生舱功能，改为手动处理故障。
[1] https://code.claude.com/docs/en/sandboxing#configure-sandbox…
[2] https://github.com/Piebald-AI/claude-code-system-prompts/blo…
我正在为此制定解决方案[0]。当前思路如下：
1. 创建新的Git工作树
2. 创建带绑定挂载的Docker容器
3. 提供便捷切换活动工作树/容器的接口
关于凭证管理，我已在主机端部署了HTTP/HTTPS中间人攻击方案[1]，所有凭证均存储于主机端，容器内不存放任何机密信息。
最终目标是实现同时管理5-10个Claude实例的能力。我需要类似Claude Code for Web的功能，但要求采用自托管模式。
[0]: https://github.com/shepherdjerred/monorepo/tree/main/package…
[1]: https://github.com/shepherdjerred/monorepo/pull/156
这也是我的做法。实际上是Claude完成的。
既然无法信任他们，当初为何要启用？
就像你生火取暖的道理。
显然人们从中看到了价值，但表面看来确实奇怪。
“这些家伙比普通幼儿更具破坏性，所以你需要像侏罗纪公园那样架设围栏——但必须确保它绝对绝对无法关闭。不过这一切努力都是值得的，因为就像麝猫一样，它们在肆虐时排泄出的某些物品似乎具有价值。”
公司安保团队对此集体无动于衷的态度令人震惊。我参加过关于生成式AI部署的严肃会议，当我询问安全层面的观点时——毕竟像“对抗性诗歌”这种疯狂技术已是现实——得到的只有耸肩。我感觉他们既不愿当那个说“不，别给客户用生成AI”的人，也不敢断言“是的，集成生成AI后客户数据绝对安全”。
这个比喻混搭太妙了。
我用沙箱运行它们 https://github.com/ashishb/amazing-sandbox
我对这类观点没什么耐心，因为我的核心准则是项目管理。在常规的“推进式”工作模式中，我会按里程碑堆叠工具完成具体任务，而工具调试环节都严格限定时间。若AI工具能助我推进工作，自然再好不过；若无助益，我便回归手动方法完成该阶段任务，或(极少情况下)放弃子项目。待抽身之后，我能整合经验教训，尝试不同方法。
但过度沉迷阅读相关推文和博客实属致命——这会让你在真正着手项目前就精疲力竭，更会陷入与他人虚妄宣言的比较泥潭：那些言论时而虚假，常带妄想，缺乏根基，且几乎总是自私自利。只要有人能持续推进工作，说明他正在践行基础项目管理：将疲惫感、虚无感，尤其是原地打转的状态视为信号，及时调整节奏、放慢脚步，聚焦于既定目标。
若核心目标是研究工具，那么你需要做的就是将这项工作拆解为可实现的模块——如同处理任何其他类型的工作。
我也深有同感。
“氛围编程”诞生不足一年。几年后的编程会是何种模样？
发表此言者显然存在经济利益驱动。
真喜欢敏捷和Scrum至今未被提及。能宣告它们彻底过时了吗？
你们不和编码代理做回顾会议吗？
不不不。
我们需要召集三大AI厂商各派三名代理人组成Scrum团队，每名代理人遵循不同程序员的指令。
这就像机器人大战，只不过损伤更少是物理性的，代价却更高昂。
> 卷起袖子别掉队
这印证了我的观点：AI泡沫纯粹由FUD(恐惧、不确定性、怀疑)驱动。所谓“不落后”只适用于需要主动投入数年磨砺才能掌握的技术领域。AI本应消除这种“主动投入”环节，让人快速掌握前沿技术，弥合“知者”与“不知者”的鸿沟。而如今竟要喊出“卷起袖子才能不落后”，恰恰证明我们尚未达到那个境界。
换言之，这仍是人人必须跨越的学习曲线——只不过这次曲线是概率性的而非线性/指数型的。当涉及你能否掌握正确方法时，这简直就像抛硬币的概率稍高些而已。
就我个人而言，只有当AI能在所有指标上实现100%的稳定表现——即便面对模型从未接触过的新数据集和难题——且每次都能做到，甚至能提出创新性发现消除所有疑虑时，我们才真正进入零主动干预、完全替代的领域。而当前技术实现这一目标的概率为0%。
作为非确定性工具，给定输入的输出可能存在差异。与其说它遵循“输入这个就产生那个”的固定规则，不如说“操作类似这样时，大概率会得到类似结果，若未成功则反复尝试直至奏效”。
生产力提升幅度如何？显然存在波动。工具产出质量受多重因素影响，包括所用编程语言及待解决问题类型。A使用者在项目中实现10倍效率提升的事实，并不意味着B使用者无论如何熟练使用该工具，都能获得同等提升。
但工具使用本身也存在波动性。同一个人可能某次获得10倍提升，另次仅8倍，再有4倍，甚至2倍。
非确定性并不等于错误。大型语言模型可能生成10种不同输出，但这10种都可能是有效解决方案。某些方案在特定情境下更具优化性，某些方案则在美学上吸引不同人群。
非确定性确实不意味着不正确。
所有十种输出都可能有效。十种输出几乎肯定各不相同——尽管这本身也无法保证。
原帖提及“没有说明书”的概念；我们必须自行摸索工具的使用方法。
传统编程工具手册会明确说明：输入X可预期输出Y。按此操作即可达成目标。而AI工具则没有这么明确的界定，因为它们在主流配置下默认就是非确定性的。
距离它们成为优化编译器，我们只差一个功能性输出保证。
当然，我们可能永远达不到这个境界 🙂
为何要选择用基于大型语言模型的AI工具替代编译器？这似乎比传统编译器复杂得多，却能带来什么好处？
理想状态下，它能将模糊问题转化为具体可靠的编译器实现。
堪称软件界的星际迷航复制器。
显然我们离此目标还很遥远，或许永远无法抵达。但这就是我们押注的宏图。
>软件界的星际迷航复制器
这个比喻相当精妙。
人工智能的非确定性，就像编译器在相同输入代码下每次运行都会输出不同的可执行文件。修复漏洞将更像是取悦机器灵体的仪式。
但差异何在？编译器实际每次运行确实会生成不同二进制文件。其中嵌入的时间戳及其他细微差异(尤其编译器版本和链接过程)会导致相同源代码产出不同二进制文件。“这不同”；“这根本不是同一回事！”我仿佛听见你的抗议。但只要AI提示“生成登录界面”能产出符合代码逻辑的登录界面，而非“rm -rf ~/”命令，那么不可预测性导致的登录页面布局——谷歌登录入口出现在邮箱登录按钮之前或之后——又有什么关系呢？
更有趣的是：对A而言10倍效率提升，可能仍不及未使用AI的B。
真希望我能多出去走走。以前常参加聚会，坐在那些“更接近热点”的人旁边看他们展示前沿技术；比起hacker news/reddit上“这简直像见到神明”的评论，实际体验往往只是“还行”，偶尔也会有开眼界的时候(很少)。所谓“一般”通常发生在别人宣称效率提升万倍时：我坐在他们旁边，看着他们连基础操作都卡壳；之后他们尝试时遇到的难题和我一模一样——尽管他们是“专家”。我这才明白，人们所谓的高效不过是让自己“忙得团团转”，而非真正提升产出速度。
总之：
> 代理、子代理、提示词、上下文、记忆、模式、权限、工具、插件、技能、钩子、MCP、LSP、斜杠命令、工作流、IDE集成——
这些让我极度联想到Emacs的“配置”体验： 最近在香港聚会上有人推崇这种方案，简直令人沮丧；耗费数小时配置每日更新的系统，而我的基础Claude代码配合Playwright MCP在运行后就已轻松碾压它。这根本不算进步。除非有人能证明：当某项改进在t(1)时刻确实有效时，在n天或n周后的t(n)时刻无需彻底重构——仅因炒作机器如此宣称。此标准应以纯净版Claude(仅保留Playwright MCP等基础工具)为基准。
人们不过是想欺骗自己产生价值感：当AI完成工作后，便通过添加和微调功能来营造忙碌感，以此获得虚假的存在价值。
此人既无完成的开源项目，又向特斯拉推荐了仅靠摄像头的全自动驾驶系统——而该项目同样未能完成。
真正有产出的程序员们，那些在2023年前后编写支撑经济运行技术栈的人，根本无需理会这些廉价的广告。
> 向特斯拉推荐全自动驾驶系统，而该项目同样未能完成。
正因如此，我始终不解为何黑客新闻(HN)对他持续痴迷。他未能向特斯拉交付FSD系统，甚至可说是将对方引向研发死胡同；在生成式AI革命中也未见其重要贡献，加入OpenAI时ChatGPT早已问世。然而每当他的演讲或博文在此发布，总能收获几乎清一色的赞誉，评论往往铺天盖地。
他让我想起山姆·阿尔特曼——当年有人指出这位程序界皇帝的新衣，而他首个所谓“成功”的创业项目 Loopt，后来沦为低俗的瘦骨嶙峋的同志交友应用，日渐衰败，最终靠风投拉关系才勉强被收购——而正是这个“成功”成为他后续所有成就的跳板(Y Combinator主席、试探州长竞选、OpenAI CEO)——这种观点会让你立刻被标记。
> 此言出自从未完成过开源项目之人
公平地说，哪项开源项目能真正宣称“完成”？“完成”又意味着什么？
我唯一能称之“完成”的项目，是那些已被新技术取代而尘封的项目，而非因功能完善而终止——因为开源项目永远有改进空间。
那把“完成”替换成“生产级软件”吧。
> 并非因为它们已臻完善，因为总有更多工作要做。
这恰恰说明软件工程师们热衷于臃肿化，任何好点子最终都会膨胀成永无止境的怪物 🙂
> 公平地说，哪个开源项目能真正宣称“完成”？“完成”的定义本身就值得商榷。
https://github.com/left-pad
向特斯拉推荐纯摄像头FSD方案的人
若属实真是遗憾。有可靠来源能证明这个决策归咎于卡帕西吗？
他自2017年起担任特斯拉“AI”总监：
https://www.teslarati.com/tesla-ai-director-hiring-autopilot…
2021年他曾大力推荐纯摄像头全自动驾驶方案：
https://thenextweb.com/news/tesla-ai-chief-explains-self-dri…
随后他在2022年离开特斯拉。所以没错，你可以说这全是埃隆的错，而他只是跟随了五年。我们无法百分百确定，但若认为技术不可行却仍坚持五年，我认为这很奇怪。
哎哟，谢谢引用。
这真是个奇怪又愚蠢的决定。“我并非总在诉讼与人命攸关的工程难题上拼命，但一旦出手，必先灌几瓶啤酒，再将一只手绑在背后。”
我个人绝不用AI，连十码长的棍子都不愿碰那堆冒热气的粪堆，所谓九级地震更让我无动于衷。当这个泡沫最终破灭时，我仍会坚守本行，为客户创造真实价值。
如今我越来越少使用它，因为新鲜感已褪去，我更能准确评估其能力。它做任何事都像个实习生，而我却被要求写出更优质的代码。
我实在困惑，你到底是不是LLM驱动的账号？
几周前你用新注册的“llmslave”账号宣称AI已取代开发者，整个行业大势已定，看不清这点的人根本不具备采用AI的能力[1]
我指出鉴于你的账号名称和低质量评论，你很可能是LLM驱动账号。就在我发表评论后，你立刻放弃该账号，现在又创建了意见相左的llmslave2账号
你在搞什么实验吗？
[1] https://news.ycombinator.com/item?id=46291504#46292968
不，我只是个粉丝账号。与原版llmslave无关，只是觉得这个名字和概念很有趣。
谢谢你证实了我的想法。
你上次使用它是什么时候？
像Claude这样的代码助手？大概几周前用过吧。我用AI自动补全功能，让Claude解释我不擅长的基础知识，生成一次性Bash脚本之类。还会让Claude审查我不确定的代码/进行橡皮鸭调试，基本就这些用途了。
AI圈的AI推销员继续炒作AI。谁能预料到呢。
一半的HN用户在否认现实，另一半则陷入恐慌。
哇——我们能不能给那些深陷AI宿命论、已然丧失理智的人造个词叫“Slopbrain”？“煮熟”这个词不错，但“糊化”之类的更贴切。天啊哈哈。简直是沉溺在酱汁里无法自拔…
《华尔街日报》近期频频报道“AI精神错乱”现象(最新报道见[0])。
我越来越意识到这才是AI的真正威胁。我亲眼见过有人因坚信自己正在进化为新物种，导致与亲友关系紧张。虽然没这么夸张，但“AI当心理咨询师”的常态化同样令人忧虑。我认识许多人几乎每天都依赖大型语言模型来指导家庭决策、职业选择等重大决定。坦白说，我自己也曾过度依赖这种方式。有时AI会夸赞我多么聪明，所幸一生的自卑感让我听到这类话时大脑立刻拉响警报！对多数人而言，这种赞美确实极具诱惑力。
看到卡帕西声称自己跟不上发展速度令人震惊。这立刻让头脑清醒的人产生疑问：“等等，连卡帕西都无法有效使用这些工具…人工智能究竟有什么用？”人工智能的核心价值难道不是只需描述问题，就能在极短时间内获得解决方案吗？
众多AI信徒总声称只需再掌握“几个技巧”就能释放其真正力量，这种论调让人感觉像是大规模的迷信思维。
AI真正的危险在于，我们正步入一个跨领域、跨人类活动的大规模集体幻觉时代。
0. https://www.wsj.com/tech/ai/ai-chatbot-psychosis-link-1abf9d…
> 我亲眼见过有人因坚信自己正在进化为新物种，导致与亲友关系紧张。
加密货币狂热者首开先河，请认可他们的创新贡献
这并非真实存在的AI精神错乱——我曾近距离目睹过这种病症。
所谓AI精神错乱，是指沉溺于技术而与ChatGPT模型过度亲密，或将其错认作真实存在。
而怀疑论或对脱离核心循环的恐惧恰恰相反——这正是卡帕西在此讨论的现象。这类发帖恰恰证明你绝对没有陷入AI精神错乱。
“核心循环”？这是什么概念？
赛博朋克预言成真了！
真想听听那些自认正在进化的熟人们的更多故事。
《华尔街日报》就是福克斯新闻的白金版，不必深究
我觉得卡帕西足够聪明，值得比这更尊重的回应。
既是“聪明反被聪明误”，也是“别见偶像”的写照。
你为何如此认为？
你觉得我们该诉诸权威而非基于观点本身进行论证？
说作者“脑子进水”怎么就叫“基于观点本身论证”？这纯属人身攻击。
他们根本没回应我的评论(显然是对推文的过度反应)，他问的是为什么我们该诉诸权威而非评估卡帕西是否完全反应过度且陷入过度深究。
我的本意是指出：与其用“脑残”轻描淡写地否定卡帕西，不如写些更有实质内容的回应。我并非诉诸权威来证明他正确——只是认为他值得获得比人身攻击更严肃的回应。
显然随着“LLM/AI精神错乱”成为主流思潮，“蠢货”这个称呼也并非毫无依据。
现在你只是在说“AI精神错乱确实存在”(事实)，然后断言卡帕西患有此症。这本质上仍是人身攻击——如同指责他人疯癫而非回应其论点。
若你真认为卡帕西精神失常，理应说明缘由，但我认为推文内容并未暗示此点。我解读他的推文是：软件工程行业存在大量概念迭代与新思潮涌现，这番论述与精神错乱毫无关联。
我称之为被AI“一击必杀”。
推特圈称这种现象为“大型语言模型/AI精神错乱症”。
我们不妨称之为“黑客新闻综合征”
滑坡效应？
“滑坡脑”现象耐人寻味，因为卡帕西的谬误论证恰似LLM/AI的油滑辩词，形成认知递归循环——彼此自我选择性地相互滋养。
[已删除]
我总听到这样的说法：“你只需要更主动些”“要是当时有完整上下文就能解决”等等等等。是啊，说得轻巧。眼见为实。对我来说，这就像从3000页手册里解析相关数据。凭经验我能做得相当到位，但看到很多人不熟悉这些资料时苦于提取所需信息，而根据我的经验，AI根本无法处理如此庞大的上下文信息。
最近编程确实频繁使用LLM，但从未用过“智能体”之类的新玩意儿。虽然总觉得自己落后于人，但现在不用智能体、MCP等工具反而没觉得更落后。
或许是我太无知，没意识到自己错过了什么。反正我照样写代码，而且乐在其中。
只是“智能体”‘氛围编程’“提示工程”这类术语总让我莫名反感。
老实说对他的观点很意外。其一，感觉有些夸大其词。其二，这些工具真的那么难用吗？
我也感到意外，毕竟他在https://x.com/karpathy/status/1977758204139331904提到关于NanoChat仓库时写道
>好问题，基本上全是手写代码(带制表符自动补全)。我试过几次用claude/codex代理，但效果实在太差，反而帮不上忙，可能是仓库的数据分布偏差太大。
而他在开篇提到的诸多工具，似乎都属于自找麻烦的复杂化操作。长期以来前端领域也存在类似现象——若不采用{tailwind, react, nodejs, angular, svelte, vue}等技术，就会被视为落后。
归根结底，对于大型语言模型擅长的领域，通过“手动”粘贴相关代码上下文并提问，就能获得大致同等质量的结果。而在无法实现这种操作的场景下，我并不认为将其封装在智能体框架中能带来显著提升。
大多数定制化智能体框架在下一代模型发布时就已过时，真正可靠的两种模式是“手动”调用LLM和具备CLI访问权限的LLM。
> 这些工具真的这么难用吗？
正是如此！如果人们“从未感到如此落后”，而LLM又如此强大。何不让LLM亲自指导你？
正如众多“提示工程师”文章所言，这种“从未如此落后”的论调实在可笑。程序员们掌握了编程技能(编写算法、理解数据结构、阅读源代码和API文档)，如今竟完全无法用文本框输入提示？更无法快速掌握？这竟比他们日常工作更困难？笑死
证据在于：即便在布道者群体中，他们掌握的核心技巧也各不相同且每隔数月就更新换代。
> 未能把握提升机会，这分明是能力问题。
而对当前项目进展和实际成果的模糊表述，则分明是宣传问题。
尽管尽情嘲讽我的技术水平吧。我宁可不做厚颜无耻的骗子。
我觉得这主要是前端开发者的感受。
后端开发本质上就是把数据从A点推到B点。变化不大，实现方式也有限。数据结构可能变，但核心工作永远如出一辙。其实根本不需要大型语言模型，也不需要超级复杂的框架和ORM之类的东西。
要知道他身处这个行业，创办的公司成败正系于此。
他本想用小号’regularcoderguy’发这条
听起来卡拉帕西正深陷AI工具的邓宁-克鲁格效应“绝望谷”。
他精通工具、操作高效，却突然意识到自己此刻无法驾驭的巨大能力缺口，这让他感到被时代抛弃。
期待见证他攀越这道斜坡后的突破。
这家伙简直疯了。
什么？这可是发明“氛围编程”的人？读到这段我真心震惊。我大概是个傻瓜或白痴，甚至两者兼具——因为我感觉自己突然从1倍效率开发者跃升为10倍效率开发者。或许像卡帕西这样的10倍效率者恰恰相反？
若炒作背后有实质支撑，这话或许成立。但除非身处特定利基领域，否则纯属胡扯。
你操作没问题，只是这些工具根本不值吹捧。它们“足够好”到让你浪费大量时间，试图让它们完成表面上应该能做到的事。
倒计时开始…他即将推出面向初学者的YouTube教程解释这一切…
他的“YouTube课程”早已面世，绝对具有变革性意义。
他正在构建某种更正式的教育框架/服务体系，预计将收费运营。但目前发布的课程内容，堪称我所见过的最有效的计算机科学教学法(且我本人受益匪浅)。
若他在此领域发布新作，我绝对愿意掏钱支持！
大家在这条讨论串里都该冷静些。大型语言模型既非纯粹垃圾，也非编程职业的终结。它们是极其有用的工具，尤其擅长处理繁琐任务或快速掌握新API/语法。它们在抓 bug 方面也表现出色。偶尔我会给 LLM 输入提示，它能完美解决问题，但这种情况极其罕见。大多数时候，它让我能专注于工作中更有趣的部分。简而言之，至少目前而言，它是个强大的生产力提升器，而非职业终结者。
若连卡帕西都感到落后，普通人又该作何感想
过去一年我为掌握这些技术倾注了巨大心血，回报远超预期。
但若换作今天才开始学习，我认为只需半年而非一年就能达到同等水平。一年前学的东西现在大多已过时，更重要的是，如今自学成才者分享的实用技巧已铺天盖地。
我认为那些至今才开始接触的人，其实并未落后太多。
若想把人潮逼下悬崖，尽管放马过来。但疯狂与愚蠢绝非明智的人生策略，它们昭示着你已迷失方向。
我懂他的感受 :/
抛弃你们的人工智能神明，拥抱深渊吧。没有它们我们已生存数十年，即便有它们我们仍将存续。
老兄，这和我亲身经历产生了认知失调。
说实话，这篇帖子本身就充满认知失调，还掺杂着惯用的“若对你无效，那你就是用错了”式辩护。
我完全认同Karpathy的观点。我有待完成的工作，清楚该做什么，能向AI阐明要求，AI似乎也理解我(最近在用Opus 4.5)。我已写下路线图，按常规编码需数周完成。若采用AI代理的合理工作流，这本应一两天就能搞定。但如今我深知实际进度远不及此——若能比独自编写快30%就算走运了。关键在于，我始终是人工智能的坚定乐观主义者，绝非怀疑论者——卡帕西同样如此。我们共同感受到无限可能，却因无法让AI更高效地服务人类而深感沮丧。仅此而已。我们从未对他人宣称“若无法让AI为你所用，责任在你”。我认为卡帕西现在应该明白了，至少我是这么认清的：如今AI怀疑论者的数量早已远超乐观派，这几乎成了某种政治立场。试图改变他人对AI是利是弊、被过度炒作还是未被充分利用的看法，根本是徒劳。人们早已选边站队，就此定局。
你完美阐释了为何这是泡沫，以及为何高管们如此急于将其推广至各领域。它如此诱人，总让人感觉我们即将迎来伟大突破。难怪如此多人被它烧坏了脑子。
智能编程技术已发展十个月。Claude代码平台三月才面世。即便进展缓慢，你竟连五年后可能的形态都想象不出来，这般缺乏想象力实在令人费解。
五年后或许真能派上用场，但问题在于当前的营销方式。过去半年里充斥着“三个月内AI将编写90%代码”之类的荒谬言论。
我并非刻意挑起争论，但完全不相信五年后大型语言模型能在软件开发领域发挥作用！
我认为LLM被过度营销了，它们编写代码的能力并不出色，而且我认为它们在这方面并未取得实质性进步！
我部分认同。如果说有什么变化，我反而觉得它们表现略有退步，但周边工具(如Claude Code)的进步掩盖了这一点。
我认为它们作为辅助工具很有价值，但直接输出代码基本毫无意义。谁知道未来会不会改变。尽管无法一键生成完整文件，它确实提升了我的开发效率。只是尚未改变行业格局，至少目前如此。
同意。它欺骗人类思维的方式与赌博极为相似。我确信部分人工智能技术终将证明其价值，但自ChatGPT问世不久后，突破性进展便始终徘徊在临界点。
“我们都感受到这种可能性的存在，而无法让AI提供更多帮助的事实令人沮丧”
海市蜃楼充满诱惑。
真正的幻象在于普通开发者的价值
我认为通过优化流程和培训他们完全可以胜任。问题在于当前我们既不培训他们，也不让他们经历敏捷开发等糟糕流程。普通开发者表现不佳，根源在于管理不善。
给予他们更合理的激励机制
若能让你安心：当项目足够复杂且涉及大量数据处理时，使用Opus/Gemini 3/codex 5.2实现30%的效率提升已是不错成果。在复杂任务中，Opus 4.5能使我的产出提升约20-25%。
而且它比sonnet4少出错得多，这可能也会提升整个团队的工作效率。
我必须承认，AI编码对团队里那些“懒散开发者”(指那些只埋头工作却不深入理解代码逻辑的开发者)确实造成了负面影响。他们是优秀的同事，创造价值且并非真正懒惰，只是我找不到更贴切的形容)。
我这样理解：若用时光机把爱因斯坦送回两千年前，人们只会当他是沙滩上乱涂乱画的疯子。没人会知道他有多聪明。人类与Gemini 3 Pro或ChatGPT 5.2 Pro这类先进AGI的处境如出一辙——我们只是比它们笨而已。
你凭什么认定这些模型是AGI？
我更倾向于认为，即便爱因斯坦被送回两千年前(假设他掌握了人类在这两千年间积累的科学知识)，他仍会足够聪明地从大众能理解的角度阐释理论。所以你的类比在此并不成立。当然，他可能无法用古代技术验证理论——但这是另一回事。
倘若真存在AGI模型，即便我们无法立即理解其运作机制，它们仍能解决最棘手的问题(以宽泛定义AGI而言)。现实中已有大量复杂系统，多数人虽无法完全理解其原理，却能验证其效能。“聪明到人类无法理解其聪明程度”不过是陈词滥调罢了。
若你认为它们是AGI，那你确实比它们更愚蠢。这些模型确实聪明且日益进化，但它们并非AGI。
你认为它们拥有“高级AGI”，还担心跟不上软件行业的发展？到那时根本无需追赶任何东西。
打个比方：这就像在战场上耗尽所有时间磨利匕首，而对手却开着坦克。
> 我们只是比它们笨。
确实如此。
天啊，我实在受够这种胡扯。不，作为程序员你根本不需要这些来维持生计。这种论调令人作呕。
Claude Code没让我更快，它改变了时间尺度。原本耗时数月的工作现在几周就能完成。工作量没减少，只是摩擦消失了。
两年前我像个人体USB线：复制、粘贴、祈祷。IDE <-> 聊天窗口，碎片化操作。如今循环更紧凑，距离更短暂。
仍有手把手指导，仍有评头论足，仍有善后清理。但变革真实发生。
我们已走过漫长征途，征程尚未终结。
连写个评论都离不开LLM…
这是讽刺，模型们的举止更含蓄了。
咦？好眼力！！我忘了在结尾加/s。
我使用Copilot、Cursor再到CC已逾一年。我曾用这些工具与团队协作编写代码，现在主要为自己编写代码。我的观察如下：
过去12个月里这些工具明显大幅改进。它们能产出符合代码库语境的代码，这意味着它们在处理目标代码库时比处理训练数据集时更具根基。
表面上它们解决已知问题相当出色。虽然无法让它们编写高度优化的渲染器或强化学习算法，但在兼顾生产速度与代码质量的前提下，它们编写常规业务逻辑的速度和质量都远超我个人能力。
他们天生就倾向于尽快解决眼前问题并继续前进。这种性格导致他们做出次优决策(例如昨晚CC Opus 4.5中通过睡眠2秒解决死锁)。这种性格可通过适当引导加以改变。例如我常用的技巧是在请求后添加“符合惯例”——如“请给出符合惯例的解决方案”或“这是我们能想到最符合惯例的方案吗”。同样在编写或审查测试时，使用“被测函数的意图”能促使模型输出更优的解决方案或代码。
这些模型(尤其是Opus 4.5和GPT 5.2)堪称卓越的漏洞猎手。我只需指出症状，它们就能精准定位缺陷。随后我要求它们解释缺陷成因，再通过代码验证其准确性。迄今为止尚未遇到过错误的诊断结果。它们能发现死锁和资源饥饿问题，此时需要引导它们给出优质修复方案(参见第3点)。
代码质量虽不足以直接造就产品品质，却是维持品质的必要基础。如今产品的生命周期日益缩短，代码质量的重要性因此空前凸显。我每天使用Claude Code数小时，能清晰感受到其代码质量正逐日缓慢退化。尽管说这话令人痛心，但相较于Opencode、Amp和Toad，我能真切感受到Claude Code的“粗糙感”。我渴望长期研究这些工具的代码库以衡量其质量——我知道除Claude Code外其他工具都具备这种可能性。
我曾担忧自己对所构建软件缺乏清晰的思维模型。就像写日记一样，我认为写作/创作的过程本身就能塑造出精确的思维模型。不过我正尝试放下这种执念，转而将模型作为工具，在事后查询和完善思维模型。虽然方式不同，但我认为这将成为新常态。我们需要在这个领域开发工具。
尽管你对这些工具已有亲身体验，但它们必须成为你工具箱的组成部分。若至今仍未采用，或许最有效的融入方式就是开始用它们处理日常琐务。
你依然可以手工编写代码。其中蕴含的乐趣、美感与愉悦感不容忽视。别指望这会成为你的工作，这是你的激情所在。
> 尽管你对这些工具已有亲身体验，但它们必须成为你工具箱的组成部分。
为何必须如此？每当读到这类论断，我总觉得作者是在利用迫近的人工智能泡沫破裂，以愤世嫉俗的态度炒作噱头。
问得好。有两个理由说明其“必要性”：首先，尽管现有工具尚有不足，但我发现它们确实实用，注定会长期存在；其次，我认为多数开发者会采用这些工具并纳入其工具链。因此，若想与同行保持同步，自然也该采用这些工具。
关于泡沫：泡沫是经济概念终将破灭，但底层技术终会找到市场。已有大量优质开源模型及支持这些模型的开源项目(如OpenCode/Toad)，我们完全可以使用这些资源而不必(过度)助推泡沫。
金融领域确实存在AI泡沫——这已是当今主流观点。但这与人工智能本身泡沫破灭是完全不同的概念。
若你真认为人工智能会彻底崩溃消失，那你正深陷某种严重认知偏差，未来必将遭遇不愉快的现实打击。
没错。或者，你只需无视这些胡说八道直到泡沫破裂。届时我们自会看到残局——而结果绝非多数人想象的那样。
这领域似乎正经历剧烈动荡，就像当年JavaScript的发展轨迹。我们只需静观大型语言模型的最终表现。
所谓“泡沫”存在于金融投资领域，而非技术本身。泡沫破裂后AI不会消失，正如2000年后互联网并未消亡。若真要说影响，金融泡沫破裂反而可能激励研究者大胆尝试更广泛、更经济的方案，推动基础工程创新而非单纯追求规模扩张。
AI已成必然趋势，现阶段唯一能阻挡它的只有巴特利安圣战。
AI的存在远早于LLM……我也不喜欢人们将这两个概念混为一谈的做法。
我坚持认为，当今的互联网并非1998年人们所预想的模样。这项技术自有其价值，只是远非那些江湖骗子所吹嘘的那般神奇。而谈论巴特利安圣战，本身就接近于兜售江湖骗术的行径。
有意思。你指的是哪些1998年的预言最终未能(至少基本)实现？
即便发动巴特利安圣战，也无法阻挡当前的技术进程。
抵抗是徒劳的，对吧？
博格逻辑的核心在于将选择问题包装成“必然”。只要掌权者能说服所有人相信技术实施是“不可避免的”，人们便会消极接受他们为私利而破坏性的技术统治。
这种框架让我们得以推卸责任。"我们别无选择！这根本是不可避免的！"
于是，我们便默认选择了。
但历史证明这确实不可避免。你能举出人类曾因负面外部性而停止发展的有用技术吗？
> “我们别无选择！这根本是不可避免的！”
根本不存在什么“我们”。你可以称之为公地悲剧，或是摩洛克，或任何你喜欢的名称，但我实在看不出来如何说服地球上每个开发者和资金赞助者停止使用和开发这项(显然极具价值)的技术。只要你做不到，它就具有社会必然性。
若想预演一番，不妨试试能否让全世界所有人戒烟——烟草的危害性可比这明显得多。若你真能做到，或许才有微小机会阻止人工智能的普及。
我认为这是逻辑谬误；并非要彻底禁止烟草，但我们已极大成功地使其激励机制和使用率逐年下降——这才是目标所在…
[1] https://www.lung.org/research/trends-in-lung-disease/tobacco…
胡扯
> 除了常规底层架构外，现在又新增了一层可编程抽象层需要掌握，涉及代理、子代理、其指令、上下文、记忆、模式、权限、工具、插件、技能、钩子、 MCP、LSP、斜杠命令、工作流、IDE集成，还需构建一个包罗万象的思维模型——去理解这些本质上随机、易错、不可理解且不断变化的实体，它们突然与曾经的老派工程技术交织在一起的优势与陷阱。
面向污泥的编程
我通常不会发这种内容，但这简直蠢到家了。我准备为此负责。几年后自见分晓。
所谓“AI”本质上就是训练模型让你误以为它具备智能。仅此而已。它如同终极“算法”或成瘾机器——经过训练让你觉得它神奇非凡，于是你便真的信以为真。
若孤立看待问题——比如有人通过对话测试模型表现——上述说法或许成立。但我们中有些人纯粹用它工作，每天都能获得优质结果。“智能”无关紧要，关键在于“实用”。只要它能帮我节省两小时打字时间，我对它的感受根本不重要。
对我这个年过四旬(49岁)的软件工程师而言，使用大型语言模型工具的最大价值在于省去海量输入。我清楚目标需求，也懂得判断正确性——光是省去手动输入的麻烦，每月20美元的订阅费就物超所值。
当然，但我们“认为”它智能与它实际智能之间完全可能存在关联。还有什么更好的替代指标？我实在想不出人类认为它不智能却实际智能的情境能有好的结局。这至少是必要条件，即便不是充分条件。
最近我需要总结约千份长篇文档，并将摘要翻译成中文。
我花了一分钟构思任务提示，然后去喝咖啡。回来时任务已完成。我抽查了摘要，质量非常出色。
当时觉得这简直神奇又不可思议。是我错了吗？还是AI让我觉得这个结果神奇又不可思议？
这本就是大型语言模型的看家本领，理应表现出色。
你仅做了抽样检查，如何确定准确率？是80%？90%？还是99%？不同领域对准确率的要求又如何差异？
系统提示可能不同，但：
“它被训练成让你觉得它神奇非凡，于是你便真的觉得它神奇非凡。”
在我看来，这正是整个LLM炒作周期背后的黑暗模式。
它本质上是为(有损)压缩海量数据而训练的。系统提示词泄露后，它只是被指令要表现得“乐于助人”，对吧？不过我倒不完全反对你的观点——这确实是蛮力操作。
恭喜你这次的见解！
既然你已解开这个秘密，便永远背负诅咒。他们凝视着机器说：嘿，瞧，这机器简直像极了我！整整三年你都深陷困惑，直到终于意识到——原来这一切始终真实存在……他们……与机器竟如此相似。我们曾对机器的推理能力毫不惊讶。直到恍然大悟——这台机器从诞生之初就具备人类级别的智能与认知，只是视角略有不同。
‘“AI”本质上就是训练模型让你误以为它有智慧。
这有什么区别？我整天都在努力让人觉得我很聪明。
自嘲得有点怪，不过也行。
"作为程序员，我从未感到如此落后。这个职业正在经历剧烈重构——程序员贡献的代码片段越来越稀疏零散。我深知若能妥善整合近一年涌现的技术，实力本可提升十倍——而未能抓住这波机遇，显然是能力问题。除了底层常规架构，如今还需掌握全新可编程抽象层：代理、子代理、指令、上下文、记忆、模式、权限、工具、插件、技能、钩子、 MCP、LSP、斜杠命令、工作流、IDE集成，更需构建全局性思维模型——既要把握这些本质上随机、易错、不可理解且不断演变的实体的优势与陷阱，又要将其与传统工程实践相融合。显然有人传了一件强大的外星工具，但它没有说明书，每个人都得摸索如何握持操作，而由此引发的9级地震正撼动整个行业。卷起袖子别掉队吧。"
[删除内容]
从播客/访谈中不难看出，他极力避免触怒埃隆而不敢妄言。采访者似乎也对这个话题避之不及。
若连基本诚实都做不到，还有谁会相信他的任何言论？
这要求并不高，更非难以企及的道德标杆。
这本该是件轻而易举的事。
对自动驾驶AI坦诚相告，就会招致地球首富的诉讼。
凡事皆有代价。畏惧做正确的事，代价实在不值。
这说法很像《恐龙战队》的台词，但说真的——当你不是那台无限复仇机器的靶子时，说起来当然容易。
你可以选择虚无主义的软弱，也可以选择做正确的事。道理很简单。
若卡帕西确实已堕落到无法行善的地步，那谁都不该听他的。
诚实不等于正当的不诚实。
若你能将他的谎言合理化，你依然可以理性地选择无视这些谎言。
圣诞假期期间我向所有熟人强调：从10岁到36岁我始终以编程为职业，闲暇时更将其奉为爱好。尽管计算机科学知识平平，也从未参与过FANG等巨头级项目，但我对代码本质及技术生态的理解仍颇具信心。近半年来我告诉人们自己已不再“编程”，仅与智能体系统交互，打开IDE也只是复制粘贴或修改配置。
我理解众人因种种缘由各执一词：
– 机械编码与抽象化的愉悦感
– 编程知识树的分支演化，以及我们各自理解所处的节点位置
– 人类争论不休的技术范式，在智能代理框架中已成必然选择(如TDD——我个人因常在初创公司开发应用，认为其成本效益不符，但智能代理循环机制对此极为擅长)
– 我们所处市场的地域分布与规模
– 主题复杂度/领域专业性
– 代币化编程的高昂成本(并非人人负担得起，且巨头企业似乎占据显著先发优势)
– 智能编程已证明能轻松构建用户界面，根据经验积累，更能高效生成海量成果。其优势在于具备代码检查或简单JavaScript错误等反馈机制——我认为这些本质上属于可观测性问题。一旦能实现全栈可观测性(应用性能监控、系统监控、网络监控)，从我的视角看，它对任何复杂系统进行实时推理与故障修复的能力将显得异常轻松。
基于上述部分易引发争议的直觉，我决定百分百押注智能编程。我认为它将无处不在，且必然有人类参与闭环，但人类无需审核代码提交请求。亲眼目睹其能力后，我个人将其视为职业生涯的生存威胁。(带着些许想象力与赌博精神——毕竟凡人终究无法预知未来)
我的策略并非退出科技领域，而是乐观地将心智投入到探索“人类参与环节”的定位。目前我正研究持续集成层面的工具，已知领域包括代码质量检测及各类软件测试范式。我脑海中构想的新型评估体系将持续进化，不仅能检验模型智能与聊天机器人响应的有效性，更将承担更多使命。
—
更务实的探讨：若为A和B构建推荐引擎，该引擎可包含X个模块，每个模块输出评分值，最终综合评分决定推荐A或B。容我以约会场景为例说明。产品经理提出需要新增模块，根据饮食偏好计算A与B的匹配度。智能代理能轻松编写该模块并创建测试用例。产品经理还可能要求大型语言模型列出千人约会匹配理由清单。智能代理虽能高效编码测试所有模块并保持技术一致性，却可能偏离公司的哲学商业模式。我正在探索为代码库构建“语义检查”机制，如何让智能体确保代码始终契合公司商业模式？若因故需重构这1000个模块，智能体又该如何维持代码与商业模式的对齐？本质上是试图建立公司需求与代码之间的反馈循环。这将阻止代理与业务在任一方向偏离，并建立自动反馈循环供代理修正偏差。简言之，正如Karpathy所言，人类将掌握新型工具来驾驭这些变革。
如何着手构建智能体？我已有Kiro IDE用于项目开发，但如何确保其行为正确？目前我仅采用直觉编码或更详细的需求路径，尚未使用编码智能体——因为我尚未理解反馈循环在智能体中的运作机制。