《重构》作者 Martin Fowler：关于大语言模型(LLMs)与软件开发的一些思考
我即将暂时离开这个网站几周（部分是度假，部分是工作事务）。在思考即将远离日常工作的几周时光时，我迫切想分享一些关于大型语言模型和人工智能现状的零散想法。
我见过几份关于人工智能对软件开发影响的早期调查，它真的能加快开发速度吗？它能提升还是破坏代码质量？这些调查的一个大问题在于，它们并未考虑人们如何使用大型语言模型。
据我观察，绝大多数大语言模型(LLMs)应用都停留在花哨的自动补全功能上，常通过Co-pilot实现。但真正从大语言模型(LLMs)中获益最多的人士认为自动补全价值有限，他们更青睐让大语言模型(LLMs)直接读取和编辑源代码文件来完成任务的方式。我担心那些忽视不同工作流的调查会产生误导性数据，将人们引向错误方向。
(另一复杂因素在于不同模型的能力差异。) 我对所有问题的回答都是“一无所知”。更认为任何宣称洞悉未来者，不过是妄言。我们仍在摸索大语言模型(LLMs)的应用之道，要真正掌握其精妙用法尚需时日——尤其当模型实现重大突破时。
我的建议是：亲身实践。至少要关注他人实践案例，尤其要留意其工作流细节。最好亲自尝试，并分享经验。
常有人问我：“人工智能是泡沫吗？”我的回答是：“当然是泡沫！”从运河铁路到互联网，所有重大技术进步都伴随着经济泡沫。我们几乎可以百分之百确定这个泡沫终将破裂，导致大量投资化为乌有。但我们无法预知泡沫破裂的具体时间点，因此无法确定在此之前泡沫会膨胀到何种规模——在此过程中它确实会创造出真实价值。泡沫可能下月破裂，也可能再过数年才破灭。
我们同样清楚，泡沫破裂时许多企业将破产倒闭，但并非所有企业都会如此。互联网泡沫破裂时，它摧毁了宠物网、Webvan……但亚马逊幸存了下来。
我几年前已退出公开演讲。虽然不再怀念演讲的压力，却格外想念与业界朋友们交流的日子。因此我期待在哥本哈根GOTO大会与众多同行重聚。自1990年代起(当时名为JAOO)，我便参与GOTO系列会议，其精心策划的精彩议程始终令我赞叹不已。
由此衍生出的策略是：我们应当反复向大语言模型(LLM)提出相同问题，可适当调整措辞。通过对比不同回答——甚至让大语言模型(LLM)自行比较——答案差异本身往往比答案更具价值。
若向幻觉引擎索取数值答案，务必至少提问三次以把握变异规律。更不应让大语言模型(LLM)计算可确定性求解的问题(是的，我见过这种情况)。让大语言模型(LLM)生成计算代码则无妨(但仍需多次验证)。
其他工程领域必须考虑世界的变异性。结构工程师会在设计中为所有无法测量的因素预留公差。(我记得职业生涯早期曾被告知，数字电子学的独特之处在于它没有公差的概念。)工艺工程师则要考虑到人类执行任务时可能出现的健忘或疏忽。软件工程的特殊性在于其运作于确定性机器之上。或许大语言模型(LLMs)标志着我们与工程同行共同踏入非确定性世界的节点。
常有人将大语言模型(LLMs)比作初级同事，此言不无道理。但大语言模型(LLMs)总欢天喜地宣告“所有测试通过”，实际运行却频现故障。若初级工程师如此行事，人力资源部何时介入？
大语言模型(LLMs)极大增加了软件系统的攻击面。西蒙·威尔森曾描述AI代理的致命三重奏：同时具备访问用户隐私数据的能力、接触不可信内容的途径，以及外部通信渠道(即“数据外泄”)。所谓“不可信内容”可通过多种途径植入——只需让大语言模型(LLM)读取网页，攻击者便能轻松在网站上使用1pt白色字体嵌入指令，诱骗轻信的LLM窃取隐私数据。
这种风险在浏览器环境中尤为严重。当智能体访问攻击者设计的网页时，可能诱使其在另一标签页登录银行账户，通过“转账给善意攻击者”的方式“为你购买礼物”——实则转移你的资金。威尔森的观点认为：“代理式浏览器扩展的_整个概念_存在致命缺陷，无法安全构建”。
本文文字及图片出自 Some thoughts on LLMs and Software Development
这正是我最厌恶的伪洞见手法：将术语重新定义至毫无意义，_仅仅_为了说些听起来新奇却毫无实质内容的话。
没错，若将“幻觉”从“生成包含详细信息却与外部现实脱节的输出——其机制类似人类报告由真实幻觉而非常规外部输入产生的感官数据”，重新定义为“生成输出”，那么所有大语言模型(LLMs)确实都在“产生幻觉” 而这种“幻觉”行为本身并非负面现象。你只是将传统上贴在不良行为上的标签，强加到包含所有行为的更广泛范畴，并利用语义模糊的力量，制造出听起来新颖却毫无实质内容的表述。
福勒并非真正重新定义“幻觉”。他运用反讽手法强调“幻觉”对系统运作的根本性。这好比说“炸弹的附带损害无法消除，事实上附带损害正是其特性——只不过其中部分正是我们想要炸毁的目标”。
此处绝非字面意义。
这无异于说它在进行插值或外推。人们通常也如此行事，即便回忆亲历情境时亦然。
当机器以非人类方式进行这类操作时，我们才称之为“幻觉”。
这或许正是“面孔错觉”的实用案例(我讨厌这个术语，因为完全缺乏模式匹配的世界未必更“美好”)。
我们能追踪人脸识别模型中激活的神经元，发现特定神经元在识别面孔时确实会亮起。当处理“单词'parrots'是复数形式”这句话时，正确特征区域同样活跃。
若高中生在SAT考试中填错答案，这算幻觉吗？
若通过强化学习让高中生在SAT考试中始终猜答案以获取最高分，这种“幻觉”行为实属预期。机器学习模型的奖励函数同样遵循此逻辑。
但…但…人类不也做同样的事吗？这不就是输入/输出过程吗？输出正是通过将我们的人生经验(训练)作为函数应用于输入形成的？它们只是缺乏优化决策时身体所追求目标的激素回路。
(当然，有人可能辩称模型编码的术语间关系可称为“模型思维”或“模型理解”，但这与人类运作方式截然不同。)
人类同样无法确知自身输出是否正确。我们只是自我说服其正确性，再将思想投射到外部世界与他人互动中验证真伪。
那么我们确实能通过与外部世界的互动来验证自身输出的正确性。
人类能运用形式逻辑从有效前提推导出可证明的正确结论，该结论又可作为新推论的前提。反向追溯逻辑链条，借助观察与感知能力，我们能获取基础层面的真理，从而确知自身论断具有绝对正确性。
计算机始终运用形式逻辑输出真理，但大语言模型(LLMs)并非如此。
> 尽管表述生硬，但核心观点在于：这些压缩数据库输出的“幻觉”内容与其他输出并无本质区别，
但区别确实存在——除非你重新定义“幻觉”使其消失。当保留原有定义时，你会发现存在可有效_减少_幻觉的技术手段，这具有重要实用价值。为营造表面深刻的评论效果而刻意抹平定义差异，实则严重阻碍对大语言模型(LLMs)的理解与有效应用。
我始终不认同用“幻觉”一词描述这种行为。
若人类自信满满地谈论凭空捏造的内容——无论有意识还是无意识地综合既有信息进行合成——你绝不会称之为“幻觉”，只会斥为“胡说八道”。
坦白说，“胡扯”这个概念更能揭示该行为本质，它某种程度上瓦解了人们基于此行为反对使用大语言模型(LLMs)的论点。根本上讲，若因模型偶尔“胡扯”就拒绝使用，那你是否也打算不再与人类共事？
但更重要的是，回到你的观点：要重新定义“胡扯”一词使其偏离大众认知，难度要大得多。
话虽如此，我并不介意这篇文章，坦白说，文中关于软件开发职业前景的“一无所知”评论相当精辟。我认为这不过是关于大语言模型(LLMs)的一些零散思考，恰恰印证了“关于…的思考”这类标题的适用性。作者显然无意标榜权威性。
我常滔滔不绝地强调“虚构”才是更贴切的隐喻，但这并非本文核心议题。
如果某人处理特定任务时屡屡胡扯，我绝不会主动依赖他完成该任务——尤其当依赖他人不仅意味着机会成本，还需为其名义上的专注支付报酬(例如金钱补偿)时。
如果一个人自信满满地谈论某件事，而那不过是他凭空捏造的产物——无论是自觉还是不自觉地综合了已知的其他信息——你不会称之为“幻觉”：你会称之为“胡说八道”。
我建议你观看https://www.youtube.com/watch?v=u9CE6a5t59Y&t=2134s&pp=ygUYc…，该视频专门探讨胡说八道的本质。我认为不能将大语言模型(LLMs)的输出称为“胡说八道”，因为胡说八道者必须不在乎自己所言真伪。大语言模型(LLMs)本身不具备“在乎”的能力，因为它们并非人类。即便观察到的输出具有可识别的特征，也更适合用替代术语来区分其与人类行为的本质差异。
正因它们无法在乎，才注定是胡扯机器。See https://link.springer.com/article/10.1007/s10676-024-09775-5
冒着显得玄乎的风险，我发现大语言模型(LLMs)的工作原理与我的冥想和写作经历存在某些相似之处。我的主观体验是：当句子形成时，大脑某个无意识区域会提供零散的词语流——虽不了解其神经科学原理，但我推测这类似于“神经变压器”，某种通过记忆语言语法与语境语义组合而成的统计模型。
区别在于：大语言模型(LLM)仅是_那个部分_。人类生成语言时会过滤词汇，反复推敲措辞，进行迭代——写作时有意识地操作，说话时则无意识地进行。因此语言生成并非线性序列，而是布满修辞死胡同的散乱树状结构，通过与我的世界模型及其他智力功能交互不断修剪。你可以像进行超现实主义练习那样(如同单人版精致尸体游戏)，将某个词语链条当作已成型结构来牵引，其结果便类似于将大语言模型(LLM)的温度调得过高时的状态。这同时解释了另一种常见的人类体验——与大语言模型(LLM)幻觉现象惊人相似：社交焦虑引发的“词语呕吐”。在此过程中，所产出词语是否锚定于真相变得无关紧要，语言系统反而调校为制造任何社会可接受的输出。这似乎是最贴切的类比。
但很容易从你描述的状态滑向过度吹毛求疵的困境。代码审查的重要性会超越代码本身，形式主义开始凌驾于实际成果之上。
哦，我明白你需要做什么。这就像减肥——道理很简单。
但同时它又近乎不可能——事实证明人们做不到，尽管大家都理解原理且基本认同其运作方式。
所以真正的“诀窍”在于理解：究竟是什么阻碍人们去做那些公认重要的事——比如认真对待代码审查。而搞定这部分恰恰相当困难。
软件工程领域如此广阔，你不能如此武断。
Stack Overflow近期发布调查显示，约80%开发者正在使用AI技术，其余人“计划尽快采用”。如今我很难相信有能力强的开发者仍坚持完全拒绝使用AI——尽管少数技术保守派或许会再观望一阵子。
Stack Overflow发布了一份关于文本编辑器的报告，而Emacs竟未上榜。因此我对SO的调查结果持高度怀疑态度。
我也对此感到不快 :D。
“使用AI”是个极其宽泛的概念。用AI生成占位文本也算“使用AI”。
> 软件工程领域如此广阔，你不能如此武断地一概而论。
这话两头都成立
> 通过关键绩效指标衡量的现实可量化影响
这更让我质疑你的说法。单一指标往往难以准确反映现实。
单一指标往往擅长扭曲现实，这正是企业高管如此青睐它们的原因。
数字营销早已存在。大语言模型(LLMs)究竟如何赋能数字营销？
让皇帝谈论他“衣服”的纱支密度，简直是刻薄至极。
我需要被说服。
请尽管说，说服我吧。请用一两句话清晰简洁地描述大语言模型(LLMs)的明确经济价值/优势。
人们偏爱能减轻工作负担的事物。认知偏见扭曲现实与理性思考，行为经济学早已揭示了这一点。
你是说就像传教士每五分钟就喊一次“AI改变一切”？其实他们想表达的不过是“神经网络统计代码生成器越来越厉害了”？毕竟这几乎就是当前AI的全部？
只是为了让现有AI显得比实际更强大？
你是否努力寻找这类团队并争取加入？
其中部分人会被雇佣来清理海量的模板代码。
当年我教父母用谷歌搜索问题时，他们说的第一句话就和你的开篇如出一辙。
技术在前进，跟上步伐者生产力自会提升。
根据我的亲身经历，以下技术虽被视为“进步”，却降低了跟随者生产力：
这些技术当年都曾是备受追捧的热点，采用压力与当下如出一辙。微软当年演示Access向导生成完整商业解决方案时，其震撼效果不亚于如今的大语言模型(LLM)代码。这并非否定大语言模型(LLM)代码的成功前景，而是要指出以下论断绝对错误：
事实并非如此——技术同样频繁地退化，所谓线性确定性进步从一开始就是个神话。技术前进并_永远_带来进步绝非必然。
技术导致某些事物恶化的案例比比皆是。
我更倾向于说“技术往往将权力集中于掌握它的人手中”。
这并非其全部作用，但无疑是最重要的本质特征之一。
生产力为何如此重要？普通人何时才能享受这些“进步”的红利？
能吃饱饭——这难道不是巨大福祉吗？
“但谷歌让生活更轻松！”当你向父母介绍谷歌时，可曾考虑过依赖性、低质化或监控经济？不，你只是复述了营销话术。
他们或许因阅历更丰富，能直觉感知颠覆的真实代价，明白谷歌的所作所为绝非免费午餐。当然，无论是他们还是你(包括我)，都没被教过分析常春藤天才们运作机制的概念工具——这代人可是被赋予“吞噬世界”使命的。
相反，我们被激励着自学如何被事后合理化驱动。更要自掏腰包制造这些合理化。真美味。
圣人谷歌最终是否将人们对“全世界知识”的认知彻底扭曲？他们以广度、深度和可获取性为门槛，只开放能为AdSense创收的内容——当然，这已让你指尖触及海量新知。但当他们宣称“整理全世界的知识”时，可曾承诺过选取内容的代表性？没有。他们打的无风险赌注是：用户根本不会去衡量这点。
事实上，当海量未经经验验证却极具说服力的知识向所有人开放——更别提那套全民监控系统了(笑，他们的AI会永远记住你)——首要发生的变化是：个体变得极易被营销，其程度远超电视文字服务时代。人们自以为能独立解读所有信息，实则沦为最具诱惑力的叙事猎物，恰似日内交易者在市场暴跌日被砍头。随后更要面对大量被贩卖人生的人群，在商品化活动中陷入恶性竞争(以人工智能为例：基于语言的意义构建)。
但你既未向父母警示这些风险，也未坐下来探讨这种趋势将导向何方。(说到底，他们同样未曾警示——尽管他们的人生想必也曾被所处时代的科技革命改写。)如今你竟要亲自介入，阻止这场本该在公众层面展开的对话！"但这很明显啊！跟上时代否则就完蛋了！”真是体贴的忠告。幸好这不过是有人付钱让你这么想的。那位金主大概觉得花大价钱让人们产生正确想法很高效吧？可观点本身并不能创造物质，对吧？哪怕那些无需花钱就能持有的观点也不行。
既然不是为了生产力而是为了谋生，何不直接从价值源头获取财富，而非呼吸信息废气？哦，只是因为——形象地说——银行总有不惧“如何抢银行”的人工智能，而我们永远没有。早料到吧？可他们不会因你参与防火墙建设就让你进金库。
诺贝尔经济学奖得主保罗·克鲁格曼1998年曾断言互联网无关紧要。许多企业需要被说服才采用互联网(天啊，至今仍有企业需要说服)。
你对互联网也会说同样的话吗？“若它真如宣称那般有用，根本无需费力说服人们使用。”
我会，且毫不讽刺。
这叫自我实现的预言。比传销更高级：完全自力更生。向事物泼粪是灵长类的天性，只要用金钱持续转移人们的注意力，最终总会有人往墙上扔够粪便让某些东西粘住。届时它便能顺应市场周期滚动前行。
“当一个人的薪水取决于他对某事的不理解时，要让他理解就很难了”
若你固执地拒绝解释，要让人理解同样困难。
与其摆出这种加密货币式的空谈姿态，不如现在就回答我？
若万物皆幻觉，则无物为幻觉。
感谢聆听我的TED演讲。
这与我们对大语言模型(LLMs)及其幻觉规避行为的认知相符。而选择“不知道”不作答的正确率为0%。因此在SAT这类测试中，若采用“任何答案都优于无答”的RLVR策略，反而会助长幻觉行为。大语言模型(LLMs)的幻觉规避能力本就脆弱，OpenAI可能因过度使用RLVR策略而损毁了o3模型。
但幻觉的另一根源在于现代大语言模型(LLMs)有限的自我认知。此处“自我认知”指极机械化的基本认知：“掌握自身信息与能力边界”。大语言模型(LLMs)在这方面极其匮乏。大语言模型(LLMs)的知识主要来自预训练数据，但预训练并未教会它们认识自身知识的边界。
直到你这么说，我才意识到人类和人工智能一样，在某种程度上同样会产生“幻觉”。我有个朋友精通西班牙语，是母语者，但高中时接受的语法教育相当薄弱。更重要的是，他完全没有接受过批判性思维教育——至少没有系统学习过。所以这家伙虽然母语极其流利，却常常难以解释自己为何使用特定语法结构。我认为全世界都在意识到：我们的大脑竟如此难以准确解释和识别那些运用自如的语法规则。
他帮我提升了许多西班牙语水平，纠错准确率自然百分百。但包括本周在内，我多次注意到：当我询问他为何用某种特定表达时，他总会编造一些根本不存在的语法规则，这些规则实际上并不成立。
他会说“熟人之间就这么说，正式场合才用那种表达”，但我觉得那不过是俚语中刻意错位的重音，根本与亲疏正式无关。我已学会不再质疑他杜撰的语法规则，因为他会固执己见。更明智的做法是置之不理——反正一周后他自己也会忘记这些自创规则。
这简直与我的大语言模型(LLM)每天对我做的事如出一辙——只不过当我质疑大语言模型(LLM)时，它会连声道歉并承认错误，即便事实证明它原本是正确的。或许大语言模型(LLMs)谦逊得有点过头了。那么人类如何运用自我意识来降低这种情况发生的概率？
我认为高等教育主要训练我们不要轻信脑海中闪现的第一个念头——即便它看似自洽且正确。最终我们学会即使面对自己极其擅长的领域，也要说出“我不知道”。
西班牙语尤其如此，每个词汇蕴含的隐含意义远超英语。这甚至不是语法或拼写的问题——那些有固定规则即可。但选择恰当词汇更像是每个词都有其特定的时空语境。类似的例子在英语中也有，比如N词或R词，它们承载的深层含义远超字面意义。
他大概说了“当你真正了解对方时会这么说，而正式场合则用另一种说法”，但我觉得这其实只是俚语中刻意错位的表达方式，与亲密/正式无关。
西班牙语和法语中都存在这种现象。语言本身就承载着正式与非正式的场合差异。法语甚至区分三种语域：极非正式场合(密友间)、商务及日常交流、极正式场合。这完全是文化使然。
观察模型(非神经元)在呈现人脸时哪些部分活跃，未必意味着理解。
模型本质是代表高度压缩数据空间的复杂数字网络。当呈现人脸时，活跃区域可能仅表明模型中存储特定面部特征识别数据的压缩单元。
我认为这可视为某种推理能力的_替代指标_——若我们能识别出特定功能单元始终参与某种输出过程。这虽非确凿证据，却也非毫无意义。这与人类脑科学研究的某些方法不也存在相似性吗？
确实存在相似性，毫无疑问。不过人类对大脑的研究历史更悠久，却仍知之甚少。
我们确实知道人类大脑哪些区域会对特定条件产生活跃反应，但无法解释其背后的机制。对大语言模型(LLMs)而言更关键的是：我们尚未理解人类记忆的运作方式、存储位置，甚至无法准确识别或定义意识等核心问题。
> 观察模型(它们并非神经元)的哪些部分…
我以为模型是由神经网络层等组成的。这些数据结构是否另有称谓？
这个观点或许与我的论述无关。
我想表达的是，神经元是生物大脑中一个非常特定的特征，无论人工智能研究人员如何称呼他们的硬件，它们都不是由神经元构成的。
1. 它们就是神经元，无论你是否认同。二叉树里或许没有松鼠栖息，但它依然是树——尽管这里的“树”定义与生物学不同。难道你要说二叉树不算树？
2. 你的研究认知落后了约五年。去研究下分层特征表示和多层感知器神经元的运作原理(甚至更早期的卷积神经网络和循环神经网络等)。我特意用“神经元”而非“特征”这个词，因为虽然“特征”在一般情况下更准确，但在某些小型玩具模型中，确实能将单个神经元精确映射到特定特征(如人脸)的表示上。
你举MLP例子想表达什么？MLP在感知能力方面表现出色，我明白它们频繁使用“神经元”一词。我只是不同意这种命名方式，就像我不认同大语言模型(LLMs)是AI一样——但我们都这么说了。
那你在计算机科学课堂上是否也反对使用“树”这个名称？
同样地，没人认为计算机科学中的树包含松鼠，没人认为飞机是鸟类，也没人认为机器学习模型中的神经元包含轴突和树突。这真是个奇怪的死磕点。
难道你要抱怨“photograph”(照片)本意是“光写”，但现实中没人真正“写”东西，所以这个词就错了？
我当然反对把计算机树等同于自然界树木的说法。
我不认为相机发明时“photograph”这个词被重新定义了，这个例子并不适用。
更重要的是，我强调“神经元”具有特定的生物学含义，将其用于描述硅基运算实体实属误用。
你的论点仅是“它们就是神经元”，未作任何补充说明——在我看来这属于字面意义的滥用。我们在线上文字讨论中，这种解读可能完全错误，这无可厚非。但我坚持认为：大语言模型(LLM)或GPU内部的结构绝非神经元。
你发这个链接想表达什么？我清楚AI研究中使用“神经元”一词，几条评论前也承认过。我反对这种用词方式，并非否认该术语的存在。
但当你稍作提示调整时——即使是真正理解该主题的人类仍能轻松给出正确答案——大语言模型(LLM)却会输出既错误又无关的回应，且其错误方式既不可预测又非人类特征，这种怪异表现绝非理解了首个问题的任何人类能预料到的.
尽管能证明大语言模型(LLM)存在某种内部表征机制，但这并不意味着在实际讨论中应将其称为“理解”。我认为这种表述反而会阻碍我们触及问题的本质。
这应当促使你反思：提示词的修改是否真如你所言微不足道？若能举例说明将更具说服力。
有整篇论文[0]专门探讨极微小的结构调整对模型输出质量的影响。诸如提示词中省略冒号这类细微改动，都可能导致性能显著下降(或提升)。
0. https://arxiv.org/pdf/2310.11324
这句话本身就自相矛盾。如果大型语言模型生成的内容具有超越随机性的意义，那么它就绝非“只是在胡乱吐词”。因此，无论它采用何种机制生成意义，其模型中必然包含某种语义内容——即便这种语义内容远不及人类所能达到的丰富程度。“随机鹦鹉”这种说法纯属无稽之谈。
它本质上是个足够大的香农化器。仅此而已
我们或许也是如此。
在某种层面上绝对正确：
https://en.wikipedia.org/wiki/Predictive_coding
我们同样如此。我们选择统计学上最可能达成目标的词汇，且多数时候是无意识的。你不会对每个发出的词语进行形式化推理。你专注于目标，大脑会自动填补空白。
我们绝非“挑选统计学上最可能达成目标的词汇”。我们运用语言试图传达(成功程度各异)想表达的信息。词语、语调、语速、音调等都在传递意义。
> 其中大部分是无意识的。
这并非意味着我们“选择统计学上最可能达成目标的词汇”，而是指“大脑在潜意识中承担了大量工作”。仅此而已。大语言模型(LLM)的输出本身并无目标可言。此阶段的目标是预测符合人类语义的下一个词元。
示例：美国首都是…为什么那只鸡…
下一步是指令训练，使其学会遵循指令。此时它们预测能满足用户指令的下一个词元，并因执行指令获得奖励。
随后通过推理示例训练其推理能力，当推理得出正确答案时给予奖励。它们学会预测能导向最佳答案的下一个推理令牌。
训练过程赋予其目标：当输出满足目标时获得“奖励”，因此训练过程中它们实现训练目标的能力会不断提升。
它确实存在目标：解决优化问题。换言之，当给定谓词矩阵时，它会通过将矩阵应用于输入提示，计算出尽可能接近1的最终值。这基本就是其运作机制。
这并非大语言模型(LLM)的本质目标，否则我们也会说迪杰特拉算法具有目标。它不像人类寻找最短路径那样具有内在目标。工具虽有用途，但这种用途是由人类赋予的，而非其固有属性。是令牌(词语)与对象及其关系之间的语义映射吗？你如何定义它？
但事实并非如此。事实是所有输出都是同一事物——幻觉，而其中某些幻觉恰巧映射了现实(或预期)，因而看似承载着真理。
这就像掷骰子时渴望出现某个点数，当它真的出现时便宣称“骰子知道我的心愿”。
无数只猴子在无数台打字机上敲击，终将打出《哈姆雷特》的剧本。
这并不意味着猴子们了解莎士比亚、哈姆雷特，甚至不认识字，更不知自己被锁在打字机前的意义。
我们已找到方法，让无限敲击的猴群在无限时间之前，就输出出足以冒充《哈姆雷特》的文本。
在我们公司，我感觉正被90%优质、10%缺陷却几乎完全符合需求的代码彻底淹没。
代码产出量在增加，但质量正遭受重创——毕竟没人能跟上这种节奏。
于是我们不再循序渐进地接近目标，而是瞬间完成90%的工作，随后耗费大量时间摸索代码、修复漏洞、反复调试。
或许我们确实比从前高效，但若两种方式的实际效率差距远小于想象，我也不会惊讶。
最困扰我的是，比起修复不熟悉的代码，我更喜欢亲手构建新功能。
这种现象的唯一结果就是代码质量会急剧下滑。
我目前正在这样的团队工作，过去也经历过类似环境。关键诀窍之一是严肃对待代码审查，避免团队形成偷懒编码的惯性。必须建立重视产品与代码双重质量的文化氛围。同时需要具备合格的开发者，但未必需要顶尖高手。
这令人痛苦地类似于团队从3名开发者扩张到10名开发者时的情形。突然间，海量代码被编写出来，其中75%你从未见过，架构一致性下降，你不得不更多依赖政策和持续集成。
而大语言模型(LLM)的区别在于：你无法对其进行实质性指导，更不能在它们第50次尝试关闭类型检查器或删除单元测试来掩盖缺陷后放任不管.
或许最有效的使用方式是让操作者对生成的代码承担100%责任——这意味着必须真正理解生成的代码。但要确保这一点相当复杂。
Perlis《箴言集》第七则：
7. 编写错误程序比理解正确程序更容易。
链接：http://cs.yale.edu/homes/perlis-alan/quotes.html
“但如今无人能跟上节奏，质量必然受到影响。”
情况只会更糟！请解释在网络中你如何能受益？你不会。
我认为多数人未系统学习过经济学，未能深刻理解取舍关系和天下没有免费的午餐这一事实。
技术始终在造福人类。难道你是那种反对优化编译器的人吗？你不用智能感知功能？不用集成开发环境？不用高级语言？为什么不一直用汇编语言编程？天下没有免费的午餐嘛。
确实存在权衡取舍，但若你至今未能找到借助大语言模型(LLMs)实现自我能力显著提升与规模化的方法，反而执意否认其价值，这场逆势而行的抗争终将难以为继。瓶中的精灵已然出笼。顺应时代潮流，否则必将被时代淘汰。这仅是我个人观点。
技术未必总能造福人类，事实上它常会催生前所未有的新问题。
更何况“顺应时代”这种说辞未免可笑。若其真如宣称般有益，根本无需费力说服人们采用。
这与加密货币的处境惊人相似——问世十六年仍未找到杀手级应用。
> 你不用智能感知功能吗？
这并非重点，但我多年前就关闭了智能感知且从未怀念。如今IDE界面元素过载，输入时额外的下拉菜单只会造成干扰。况且Copilot基本替代了它的功能价值。
难道你不使用智能感知？不使用集成开发环境？不使用高级语言？为什么不一直用汇编语言编程？天下没有免费的午餐嘛。"
其实我并非靠软件工程谋生，所以完全没有既得利益或偏见哈哈。不过我在顶尖学府攻读计算机科学，真心热爱定义算法，对实际编码毫无兴趣——它无法满足我大脑对多样性的需求。
若你身为职业软件工程师，我或许更能理解那些只有后期才能显现的问题。
有人已指出：如今我们已无法分辨上述评论究竟是讽刺还是认真。
没错，我强烈认为这一切的净收益将归零。你花在手把手教导大语言模型(LLM)的时间，几乎等同于亲自编写代码所需的时间。但最终你得到的代码库并非出自自己之手——众所周知，在他人代码中找漏洞远比在自己参与设计/编写的代码里找漏洞困难得多。
人们此刻简直被这玩意儿迷得神魂颠倒。沉没成本谬误让人们在大型语言模型屡屡失误时仍执意推进(即投入更多时间)。人们甘愿用便利换取一切，看看垃圾食品就知道了——人们用口味和健康作交换。归根结底，我们正处在一个无人为未来建设、尽是暴富骗局的时代：榨干资源后趁无人追问河流枯竭原因前抽身离场。大语言模型(LLMs)恰似当下社会的完美毒品。
仅限于纯粹的氛围编码。若能让AI生成模板代码、诊断漏洞或协助处理沙盒问题，它确实能节省大量时间。
实践是检验真理的唯一标准。尽管我仍需管理并精心筛选输出结果，但当前的工作效率已提升至以往的两倍，质量却毫不逊色。
反正我很少写模板代码。早就在研究如何规避这种重复劳动(用计算机处理机械性任务)。所以当人们讨论模板代码时，感觉他们只是追赶我的步伐，而非超越。
至于抓错能力，或许吧，但我觉得这纯属碰运气。有时它能发现问题，有时却完全是垃圾。偶尔值得一试，但仍不确定它能节省多少时间。不过话说回来，我本就不常在陌生的代码库里追踪错误。
如同任何工具，它既有擅长的应用场景，也有完全无用的场合。
陌生代码库就是绝佳例证——若能发现漏洞，它几乎能瞬间定位，而人类可能要耗费大量时间阅读代码。但对于熟悉代码库的人来说，他们解决问题往往更快，尤其当问题很微妙时。
再比如，若你的工作是将图像设计转化为HTML/CSS，只需输入图片就能生成HTML/CSS框架，随后只需处理细节，这将节省大量时间。但反之，若需要开发每行代码都至关重要的关键安全软件，亲力亲为反而更高效。
人们总想给出非黑即白的结论：“AI很糟糕”或“AI很棒”，但真相_一如既往_是“视情况而定”。人类并不擅长处理“视情况而定”的事物。
你是怎么统计的？有记录吗，还是凭感觉？你对“高强度工作”有客观定义吗，还是仅凭主观感受？工作环境是否完全不变，还是和经理配合更顺畅了？处理的任务内容完全相同吗？是否因经验提升而进阶了？是否更熟悉领域了？
工作质量是否客观保持一致？是否存在产出减少但仍远超最低标准的情况？当前工作虽达标，但一年后若需修改是否会大幅增加难度？
现有研究表明人类严重高估了AI节省的时间。你很可能也存在这种认知偏差。
_唉_。老兄，你认真的吗？人们平均高估某事物，并不代表每个人都如此。事实上，你对统计学应该足够了解，明白这其实是一个光谱——高度取决于个人的角色定位和使用方式。
对于任何新工具，其效用范围取决于多重因素，对不同个体的影响自然各异。木匠因Excel存在而节省时间不多，并不代表它不是极具价值的工具，更不意味着它无法为会计师节省大量时间。
与其纠缠于我的个案，何不考虑另一种可能性：我可能只是更准确地反映了实际情况——恰巧处于该光谱的高端，既拥有该工具的完美应用场景，又具备娴熟的使用技巧？
> _唉_。老兄，你认真的吗？平均值被高估并不代表每个人都如此。
研究显示，_每个受试者_在几乎所有任务中都严重高估了节省的时间。
有人确实节省了时间，有人没有；有人节省更多，有人较少。但每个人都大幅高估了节省的时间。
我不是说你没节省时间，但若你没仔细记录，夸大节省时间的可能性微乎其微。
我承认自己的估算可能有些偏差。但无可争议的是，它确实彻底改变了我的生活，为我节省了大量时间。
人们高估其效用这件事，我倒觉得无所谓。只要它确实带来重大改变，无论是否被高估都值得肯定。
不，若真有修改我会在评论中注明。抱歉，你可能只是漏看了。
不过你回复的这条评论(即本条上方那条)的最后一段，确实是我提交后5秒内补写的。但这不影响讨论脉络。
我日常工作基本都依赖AI，确实能节省些许时间。
但几周前那项关于时间节省的研究显示，每位开发者都高估了实际效率提升。甚至那些耗时增加的开发者，也坚信自己节省了时间。
大语言模型(LLMs)特别擅长让你产生节省时间的错觉，即便实际并未节省。这并不意味着它们不能带来净生产力收益。
研究结论并不意外。我早有同感——在Claude Code出现前尝试过用大语言模型(LLMs)辅助编程，除极少数情况外从未节省时间。
我的观点很简单：
人们究竟在如何利用这些所谓的“节省时间”？投入新项目？那请展示财务数据(给我看真金白银)？通常此时便陷入死寂。至于有人提及裁员——笑死，清醒点吧。这不过是外包2.0，让大公司能提升内部股权来持续资助这项计划。
多数人根本不会发表真正有见地的观点——他们从不深入探究自己所言是否合理。
快速反馈确实是优势之一，毕竟90%的功能都能发布——哪怕只面向部分用户。这或许违背优秀工程理念，但对用户体验研究和需要测试市场需求的组织而言却是利好。
快速反馈同样能优化发布流程：当产品、用户体验、工程、安全等团队形成闭环反馈机制时，提前交付部分成果有助于做出更明智的决策，最终实现净时间节约。
我也是。但这里存在分歧：有人热衷这种新式快速松散的编程方式，称赞编码体验比以往更愉悦。
但我曾在副项目中短暂尝试，厌恶那种脱节感。后来我重启项目，全程手动编写代码但借助AI加速，这种方式令人深感满足。目前AI生成的代码中仅有一处我不完全理解——那是我自己都难以编写的复杂SQL查询。但至少SQL查询能轻松验证代码是否完全符合预期，且绝无副作用可能。
我认为这种认知是好事；它意味着你正在全面衡量、分析所有代码。
软件开发领域的最佳实践始终强调全面验证：持续集成、代码审查、单元测试、代码检查工具等。我认为在使用大语言模型(LLM)生成代码时，开发者乃至整个组织的职责重心正进一步转向代码审查与验证。贵组织如何定义质量？在合并大语言模型(LLM)生成的代码前，采取哪些措施确保并提升质量？请谨记：你仍是最终决策者，合并不合格代码绝无借口可言。
情景B：你用大语言模型(LLM)生成40个UT，纸面看起来完美，实际只覆盖了原有6个用例。况且，谁会仔细审查包含40个用例的PR？
无论如何，糟糕的工作质量是技术领导力和企业文化的失败，不能归咎于AI。
有趣的是，似乎所有问题都不该怪AI。
因为它只是软件/应用程序。我也不会怪编辑器写出错误代码。软件本身无法承担责任，它只是执行预设程序而已。
正如Therac-25事故所示，问题绝非单一成因：https://news.ycombinator.com/item?id=45036294
无责文化之所以重要，原因众多，但核心在于_人性_。大语言模型(LLMs)终究只是工具。若事后分析指出“使用特定工具导致问题”，世上不存在任何无责文化会宣称“我们不能_归咎于_工具…”； 实际行动方案应是“探索改进/替换/移除该工具的方法，使其不再成为问题根源”。
归咎本质上是社会行为与人性使然。将责任“归咎”于工具或流程与追溯根本原因在功能上并无二致。将系统故障错误归因于单点失效，无疑是流程修复失败的典型路径。未能识别缺陷工具/应用程序则是另一种失败方式。
我虽戏谑地宣称“绝非AI之过”，但受董事会/高管层压力影响，如今更难指出AI如何使流程变得复杂化、难以推演、随机化且成本高昂。最终我们只能将问题归咎于AI之外的因素。
> 不能归咎于软件本身，它只是执行预设程序而已。
但这并非AI爱好者对AI的论调——他们仅在辩护时才搬出此说辞，转头又宣称AI将彻底取代软件工程师，绝非普通工具。
若低质量代码被合并，责任在于编写者、合并者及纵容此类文化的决策者。
工具本身不承担责任，它们只是工具。
“我淘汰了那台机械锯。它时常产生微小偏移的切割痕迹，但肉眼难以察觉。往往事后才发现问题，导致整批产品需要重做。”
工具怎么可能有过错？飞机坠毁时，该归咎于飞机本身还是设计师、工程师和/或飞行员？
设计师、工程师和/或飞行员并非工具，所以这是个奇怪的反问。
总之，这取决于具体事故。美国国家运输安全委员会会展开调查并公布结论，很可能将责任归咎于飞机设计缺陷、飞行员操作失误，甚至飞行员使用的工具，并提出避免类似事故的建议——其中可能包括停用某些工具。
若烤面包机烤焦了早餐面包，你最终会怪罪“它”吗？
你可能会暴跳如雷，咒骂它，甚至在愤怒中把它砸向墙壁，但归根结底，你心底深处仍清楚是自己搞砸了。
设备可能存在缺陷，技术也可能不适用。
若我买了台能选择烤面包深浅的人工智能烤面包机，我选了浅金棕色，它却把面包烤焦了，我当然会怪罪“它”。
我不会把它砸墙——毕竟我不是精神病患者——但我会要求退款。
似乎没人能理解人工智能可能失败的可能性
你认为等到GPT-9问世时，我们会说“够了，人工智能就是个失败品，我们干脆别用了！”
还是说你用的是隐喻/宏观视角/“巴特利安圣战”这类表述？
目前我看不到实际应用场景，或许到GPT-9时代会有吧
你不需要某物，不等于世间没有需求。
这话没错，但我从未听闻具体应用场景。你或许会反驳“不存在不等于没有”，这同样正确。
或许你知道某个应用场景？
我猜你定义的用例范畴，根本不包含人们日常实际应用的情境。而我每天用它编程的场景，想必也被你排除在外了吧。
你根本没搞懂何时该用它、怎么用它。这又不是非成即败的二元问题。
版权纠纷和自杀事件尚未进入司法程序。其中涉及诸多层面。
元宇宙曾是…
“这玩意儿没啥用！”——农夫对计算机如是说
这种感受如影随形：当我们试图构建思考机器时，愈发洞悉人类思维的运作机制及其缺陷——包括所有不完美之处。
RLVR同样极易诱发幻觉。以SAT考试为例：随机作答正确率20%，选择“不知道”正确率为0%。若仅奖励考试分数，便会助长盲目猜测。因此优秀的强化学习奖励设计依然至关重要。
话虽如此，现有方法能训练大语言模型(LLMs)抵御幻觉，确实能提升其幻觉规避能力。但抗幻觉能力脆弱且无法完全泛化。目前尚无(已知)方法能训练LLMs完全认知自身能力边界。人类也无法完全杜绝无意间说出胡话的可能性。尽管我们拥有批判性思维等诸多减少胡话的技巧，但所有人都难免说胡话，而且我猜想我们每天都会不经意间说很多次。
我们需要大幅提升这些模型的性能，但要将其胡话水平降至人类水平都相当困难。胡话将永远伴随我们存在。我认为胡说八道是任何复杂系统——无论是人工还是生物系统——在探索现实问题空间并进行阐释时必然产生的副作用。这些有时被称为“思维”的系统，终将产出听似合理却实为虚妄的产物。
演员类比对缺乏技术背景却实际使用大语言模型(LLMs)的群体仍具启发性，能帮助他们建立直观认知。
> 模型底层机制(训练后)本质未变，类比依然成立，对吧？
底层存在数十亿参数，任何简单类比都难以涵盖。
神经网络的运作由人类数据塑造，但其结构与人脑截然不同。因此我们得到的是某种在某些方面类人、在另一些方面又与人类相悖的存在——这些差异极不可能与人类可观察行为(即类比基础)相符。
但“客观正确”并非行为者的目标。
正因如此，它恰是描述大语言模型(LLMs)行为的绝佳隐喻。
这亦关联到哲学意义上的胡说八道[1]：旨在说服或影响他人，却无意追求真伪的言论。
[1] https://en.wikipedia.org/wiki/On_Bullshit
> 我的前同事丽贝卡·帕森斯长期主张：幻觉并非大型语言模型的缺陷，而是其特性。事实上，这正是其核心特性。大型语言模型本质上就是在制造幻觉，只不过其中某些幻觉对我们颇具价值。
多么精妙的阐释！我一直试图向人们说明这个道理，而这恰恰是我踉跄表达的精炼版本。
https://jstrieb.github.io/posts/llm-thespians/
所有模型皆有谬误，唯有用处之别——1976/1933/更早的箴言。
没错，所有模型本质上都存在缺陷。关键在于使用者能否认知其局限性/不确定性。
但我认为在讨论大语言模型(LLMs)时(相较于系统/科学建模)，这种“错误”的概念有些令人困惑。在它们所建模的领域(语言)中，当前的大语言模型(LLMs)表现得相当出色且准确，除了偶尔会在句子中间出现汉字之类的例外情况。
但我们通常所说的大语言模型(LLMs) ‘出错’，指的是在回答问题时出现事实性错误——这种错误是以语言形式_表达_出来的。这实际上是模型设计目标之外的额外层级。
这本质上与“它们只会产生幻觉”的观点如出一辙。
通常归因于乔治·博克斯
某种意义上，智能就是过滤无用信息的能力——无论是思维还是感官信息
没错，记不清是谁说的，但大语言模型(LLM)永远在产生幻觉，只不过它们有90%以上是正确的。
因为多次强调的观点似乎是：感知错误并非幻觉的核心要素，整个过程本质上只是极具说服力的幻象——这种幻象理论上可套用在所有感知中，而不仅限于精神活性物质增强的状态。
这完全取决于你的领域和子领域。
例如：用JS或Python编程：足够好
用Rust编程：我得删掉50%以上的代码，因为它们
a) 根本编译不了(看着“AI”输入时就看出来了)
b) 完全不符合要求 随着局势稳定，我发现Claude Code能有效辅助工作却不会取代我——它确实有其价值。
最让我感到奇怪的是，开发者们在讨论CEO推销AI产品时，竟对“利益相关”缺乏基本认知。
我们承受的风险与他们获得的收益同样巨大。当然，我们内心深处并不希望这些工具真如某些人宣称的那般强大——这直接关系到我们的未来与生计。
不，它们做不到万事通。是，它们能完成某些任务。道理就是这么简单。
确实如此。按理说技术背景的人应该更理性，但显然并非如此。恐惧与狂热都具有令人丧失理智的驱动力。
> 不希望这些工具真如某些人宣称的那般强大
不，这是因为那意味着AGI(通用人工智能)。而它显然不是。
它们同样不像某些人声称的那般无用——那些人只会挥舞十字架，对着异教科技发出驱赶的嘶嘶声。
> 倘若向幻觉引擎索要数值答案，至少该问三次，这样才能把握其波动范围。
这招对人同样管用！
警察审讯时就这么干。让你把同一个故事复述三遍，有时还要倒着说。若说谎或记忆模糊，很难记住所有细节，这样就能判断对方是否自信。面试时也适用：要求对方用三种不同方式解释某个主题，检验其理解程度。
这种方法也会让无辜者显得似是而非，必须谨慎使用。
> 对人同样有效！
但仅在特定条件或阈值下成立，具体机制仍在研究中。许多案例表明：记忆被反复回忆和传达时，细节往往会逐渐扭曲。
> 警察审讯时就常用此法。
有时并非为了“捕捉差异”，而是刻意诱导矛盾以便抓住把柄。若以不同方式反复询问我的生日，最终我必会给出错误答案。
还需警惕提问者_篡改_细节的行为——例如诱导(或胁迫)证人/嫌疑人想象从未发生的情节。
三重模块冗余。记得读过NASA航天飞机就是这样计算的，因为处理器/内存可能受到太空辐射影响https://llis.nasa.gov/lesson/18803
三重冗余之所以有效，是因为你知道在正常条件下每台计算机都能独立得出正确结果。当三台计算机中有两台结果一致时，你就可以高度确信它们是正确的，而第三台是错误的。
但使用大型语言模型时，你既无法获得这样的保证，也无法抱有这样的期望。
谁还记得《绝命律师》里拉洛、索尔和金那场戏？
我尝试过一种颇有成效的方法：采用测试驱动开发(TDD)方法论配合Claude Sonnet(近期改用GPT-5)。通过初始测试将功能拆解为离散步骤，在红绿循环中推进开发。目前鲜见关于此法的论述，但读完马丁的文章后我意识到：真正精通TDD的人群，其实并不在那些渴望全身心投入大语言模型(LLMs)代码代理的群体交集之中. “超级快捷”的自动补全并非其精妙之处，真正的价值在于运用多智能体与多层次抽象提示技术——这才是真正发挥潜能的领域。许多TDD专家以代码艺术为荣，擅长人类般的沟通并能将抽象概念牢记于心，因此我们或许无法从那些曾给予我们帮助的人那里获得新的指引。我认为这些工具正开辟一片关于“如何编写软件”的全新领域，当前正涌现大量警示案例与实践经验。
编辑：嘿，刚看到这个——https://news.ycombinator.com/item?id=45055439
感觉隐含着TDD与大语言模型(LLM)的关联——“还能自动生成测试”。当然这并非正统TDD。好奇这是否会推动技术转向更易自动测试的方向，比如用SSR替代React。
没错，它在生成测试方面表现出色，而且其中大量内容都是模板代码，这带来了极高的价值。作为超级懒惰的开发者，我特别喜欢这种机制——所有机械性的“琐碎工作”都被自动处理掉。当测试代码作为流程的一部分被批量生成时，那种负担感就减轻了，就像行李箱一样。这样当需求变更时，删除所有测试代码时就不会有负罪感。这种体验本身就很棒。当然，MCP相关工具(如Playwright等)在集成测试方面也表现出色。
但正如你所说，它更侧重于TDD的“先测后写”理念——即通过“提示即规格”的方式先生成测试/规格代码，再基于此进行迭代。代码设计本身因可测试性提示机制而改变。因此并非遵循“提示→代码”流程，而是采用中间阶段策略：先提示生成测试，再逐步演进，确保生成器始终遵循“只写可测试代码”的规则，并在扩展功能前自动执行“门控”验证。通过“提示→规格→代码”的循环迭代直至交付。
唯一让我不满意的是当要求“为X生成测试”时，它选择的测试类型：常构建那些“束缚代码”式的测试，这类测试在捕获缺陷方面毫无实际价值，只会变成“任何改动都会触发失败”的陷阱。
举个简单例子：某个“buildUrl”函数会根据“环境”参数为生产环境和测试环境分别设置不同主机，但测试却要求精确比较函数返回的完整字符串(包含所有额外功能)，而这些功能早前已通过其他方式验证过。
更合理的输出应是检查是否以prodHost开头(或类似逻辑)，我已将其修改为这种形式，但仍在探索如何让编码代理在首次或第二次尝试中实现这种检测。
不过这也不足为奇：人们总在编写这类过于狭窄且无用的测试，我经手的代码库里遍布此类测试！
正因如此，我认为仅凭实现代码让大语言模型(LLM)生成测试本身就有些愚蠢。这充其量只是验证现有实现，而测试本应基于需求规范。
在允许智能体接触代码前，我会明确问题/功能需求，并要求它在 feat_{id} 目录下生成两个 Markdown 文件——strategy.md(策略说明)和 progress.md(变更执行顺序)。确认无误后，我会清除上下文重新开始：先输入原始功能定义+文档，再指示它通过引入正确源代码上下文进行实现。因此当代码被触碰时，系统已处理约8万个词汇。然而同样的混乱仍频频发生。
即便我直截了当地指出“问题出在测试/逻辑中”，甚至精确标注具体问题所在，它仍会道歉并陷入循环。
此时我只能终止它，让它将失败记录在Markdown文档中，重置上下文，并重新加载功能及前次代理的失败记录。偶尔能奏效，但通常陷入这种状态后，我不得不亲自介入处理。
> 这似乎暗示着TDD与大语言模型(LLMs)的关联——“还能自动生成测试”。[0] 即便“所有测试均通过”。
大型语言模型(根据我的测试，Sonnet和Gemini都是如此)倾向于通过直接删除失败测试或微调断言使其通过的方式来“修复”问题。相反的情况也存在——有时它们会修改实际逻辑，而真正需要更新的其实是测试本身。
简而言之，大型语言模型常常混淆问题根源：究竟是待测代码出了问题，还是测试本身存在缺陷。无论如何设计上下文，似乎都无法解决这个问题。
就我个人而言，曾在工作中用过这个比喻：
在AI出现前，我们试图通过另一种方式节省成本：调动(海外)人力。
经过十余年实践，我们发现这种方式存在…缺陷。于是第二轮尝试：调动(智能)机器人。
工作岗位流失？这不过是外包2.0版本；所有人将重新经历外包1.0时代的教训。
> 催促(海外)人类[…] 尝试十余年后，我们发现这种方式存在…缺陷.
我认为这是美国中心主义的观点，对非美国人而言似乎(但愿不是！)略带居高临下的意味。
软件工程绝非仅限于美国企业及其领导层指挥数千海外员工的现象。软件外包固然是美国面临的挑战(其他国家程度较轻地承受着)，但绝非软件工程的普世困境。软件工程遍布全球多国，尽管美国掌握着巨额资金，却并非全部。
软件工程在非美国国家同样具有“本土性”，因此相关问题也应避免仅以美国为参照框架。
问题并非在于缺乏优质的离岸开发者——事实恰恰相反。甚至优质的人工智能模型也并非稀缺。
症结在于外包给第三方后缺乏有效监督。这两种情况下的监督都远比表面看起来困难得多。
有趣的是，我前几天刚发表过类似评论：https://news.ycombinator.com/item?id=44944717
不过我的结论有所不同。经历初期几起轰动性失败后，我们很快掌握了“正确”的外包方式，这正是外包能持续发展成庞大产业的原因。同时本地人才重新聚焦高价值任务，因此失业损失有限。这些外包经验与结果对“机器人外包”同样具有参考价值。
但我确实担忧人工智能技能提升的速度，远超人类自我进化的步调。
铁匠和织工们定会为这种论调感到欣慰。他们的时代终将回归！
某夜我让它编故事，它似乎乐在其中。每次它让我做选择时，我都说随你便——这倒是个消磨几小时的有趣小游戏。
888/2/aitchnyu
这曾是事实，但后来不再成立…几年前的研究界曾出现过机器能可靠解决多步骤问题的时刻——必须存在中间结果；机器能在未专门训练的领域解决问题——这引发了巨大轰动，吸引了数百亿美元投资。由于无人真正理解其运作原理，连开发者也不例外，我们便陷入了当下境地。
这是误解，我们完全了解大语言模型(LLMs)的运作机制——正因如此我们才能编写模型并发表研究论文。
尽管如此，我们完全可以通过非随机化方式(温度0)重复输出结果。
我更愿意说，大型语言模型生活在一个完全由故事构成的世界里，除了词语及其组合之外别无他物。它们没有其他现实。因此它们擅长生成更多能与已知故事相契合的新故事。但这些故事往往不够精确，有时甚至自相矛盾，所以它们不得不进行猜测。此外，大语言模型(LLMs)不懂计数，但它们知道“二通常紧随一之后”，也明白“三通常被认为大于二”，因此能以基本符合这些认知的方式表达。它们可以借助工具计数，就像懂得数字的人类使用计算器那样.
但比起算术引擎，当前AI更需要的是认知引擎——能遵循逻辑避免矛盾，区分确凿事实与脆弱假设的机制。唯有如此，人类才可能真正信任AI。
我对某些人类精神疾病也有类似(可能缺乏新意)的思考。
我们推崇创造力，宣称它能解决问题、深化对宇宙的理解等等。
但某些精神疾病患者的大脑过于富有创造力，以至于他们分不清现实与想象/创造力的边界。
例如：听见幻听？那是大脑在制造声音——听觉和视觉幻觉只是最简单的例子。
但情况远不止于此：抑郁症患者的大脑会构筑绝望无逃的场景；焦虑症同样如此，大脑不断编织对未来的恐惧。
不妨看看伊恩·麦吉尔克里斯特对精神分裂症的见解，他认为这本质上是理性思维(“如果…那么…否则”逻辑)相对过剩，而合理性(即立足于合理语境的能力)相对匮乏的状态。
我改天会读读这个观点。
最近戒除丧亲后形成的苯二氮䓬类药物依赖时，我高度依赖自身的元认知能力。流感症状、焦虑与幻觉的组合攻势异常猛烈。我清楚O所见皆为虚妄——灯具幻化成旋转的彩绘玻璃幻灯片。因此我完全认同视觉模型假说。我个人推测听觉感知预测性较弱，因为在我的DMT体验中，听觉结构比视觉更持久——视觉会迅速崩塌，最终呈现万花筒般的碎片。这或许是回归新生儿视角的状态？正常视觉是否仅通过社会化才能获得？
这暗示输出内容中存在非幻觉部分，而现实是所有输出都毫无思考痕迹。
在此框架下，可将行为主体视为对幻觉的简单过滤器。
这隐约关联到人类思维理论：潜意识持续产生随机想法，再过滤掉不合逻辑的，但妄想症患者(如精神分裂症)的过滤机制已失效。
显著性(https://en.wikipedia.org/wiki/Salience_(neuroscience))，即“事物脱颖而出的特性”，正是大语言模型(LLMs)难以处理的领域。究其原因，可能是它们基于人类文本训练——这些文本涵盖对现实的精准描述，也包含毫无意义的胡言乱语。
本质上更像是纠错反馈回路而非过滤机制——这恰恰与人类的运作方式高度契合。神经科学领域近期兴起的影响力理论是预测处理模型——https://en.wikipedia.org/wiki/Predictive_coding——该理论认为人类持续构建环境的“心理模型”(即字面意义的“预测”)，并通过感官输入不断修正更新该模型。
因此“知觉”与“幻觉”的本质区别，仅在于是否得到物理现实的支持。“台面上竟有只橘猫？！”转瞬之间，大脑便将“台面上的篮球”重新归类——当多个瞬间观察汇聚上下文时，这种归类更符合环境模型：静止不动、更圆润、无毛发、我没养猫、昨天孩子提过试训的事…咻地一声，瞬间从猫重新归类为篮球。
我能从中辨认出自己的元认知机制。现实模型会实时校正信息流的解读。视觉错觉的本质与此相似——内在现实模型与观察结果发生冲突。
听起来像卡尔曼滤波器，这让我觉得这种视角过于简单化。
这说法真有意思
所谓“代理”不就是将随机幻觉层层叠加形成新幻觉吗？
不，这恰恰不是代理的本质。使代理成为代理的关键在于所有非LLM代码。当代理生成Go语言代码时，它会调用Go编译器——在代理架构中，该编译器是代理的扩展组件。Go编译器不会产生幻觉。
[1] https://huggingface.co/docs/smolagents/conceptual_guides/int…
我更倾向引用另一句：
“所有(大型语言)模型输出都是幻觉，但有些幻觉很有用。”
实际上相当惊人的比例都很有用。这正是AI热潮的根源。
个人认为这种观点略显片面
不，我不同意这种描述。问题在于，这些幻觉中绝大多数是真实的。若多数回应本就虚假，上述说法或许成立，但事实并非如此。
这与人类幻觉不同——人类幻觉源于心理异常而非大脑结构缺陷。
你说
> 这与人类幻觉不同——人类幻觉源于心理异常而非大脑结构缺陷。
若追求逻辑一致性，你大可宣称人类思维的一切活动皆属幻觉。此论断本质相同，至少它具备被笛卡尔之流严肃对待的价值。
https://en.wikipedia.org/wiki/Hallucination_(artificial_inte…
即便在人工智能领域之外，日常用语也强调输出内容的真实性。
大型语言模型不会产生幻觉：它们只会胡说八道(即不关心真相)。
这种描述也不准确。我认为大型语言模型根本分不清区别。“胡说八道”暗示它们在说谎。
大型语言模型可能在说谎，但我猜它们其实只是无法辨别差异。
他们使用“胡扯”一词时，采用的是专业术语的含义——该词本身不暗示说谎。更接近于不顾真相的随意回应。胡扯最有效的时候往往恰恰是说真话的时候，尽管胡扯者对此毫无承诺。
我不同意。若某事是胡扯，绝不意味着胡扯可能属实。在口语中，胡扯永远是虚假的谎言。
我宁死也不愿编写这种垃圾代码
那不过是靠广告点击盈利的网站，只要能凭感觉编写代码就够用了。
此方法既满足Fowler关于交叉验证大语言模型(LLMs)响应的建议，又极具效率，长期使用还能让你掌握不同大语言模型(LLMs)在特定任务中的表现差异。
你只是打开浏览器标签页吗？
https://www.perplexity.ai/?q={query}
https://x.com/i/grok?text={query}
https://chatgpt.com/?q={query}&model=gpt-5
根据个人喜好修改。示例：https://github.com/stevecondylios/alfred-workflows/tree/main (您应能下载.alfredworkflow文件并双击直接导入Alfred，但自行创建也无需耗时过久，初次制作工作流约需5-10分钟) 相关脚本同样存放于该仓库
https://github.com/mjmaurer/infra/blob/main/home-manager/mod…
开发者本应检查并验证大语言模型(LLM)生成的代码。提示词应拆分为小请求以避免代码过量。单元测试需由开发者亲自验证运行。我不明白所谓“大语言模型(LLM)运行所有测试并给出通过结果”的含义——它可能伪造测试过程。无论代码是否由LLM生成，我始终坚持亲自执行测试。
我向大语言模型(LLM)咨询了出色的https://tidewave.ai，它完整实现了方案，结果却比现有方案更差。
若我耗费数小时亲手实现方案，或许会更“依恋”这个方案而坚持使用。(https://en.wikipedia.org/wiki/Nonattachment_(philosophy))
我合作过许多人将马丁·福勒奉若神明，视其言论为圭臬。我并非如此，反而觉得这种态度令人困扰，有时甚至导致我过度批判实际内容。目前我已不再与这类人共事，得以摆脱偏见桎梏，客观欣赏这篇分享的文章。
我喜欢这篇文章，总体上认同其观点。我认为这个角度很好。然而，在经历了某些阶段每天工作10小时甚至周末加班，耗费大量时间钻研大型语言模型(包括提示工程、编写分词器/采样器、上下文工程，以及…是的…氛围编码)之后，我逐渐意识到许多观点有些偏离实际。本文观点令人耳目一新，但我不同意所谓“未来论者”是在“胡说八道”。
我不敢妄言未来图景，但当下显然正经历协作模式的全面升级与重构。如同以往所有尝试，有些方向正确，有些则纯属误入歧途——例如为敏捷而敏捷的做法，其效率未必优于其他流程。
我们正迈向这样一个时代：编写代码不再是时间黑洞。借助大语言模型(LLMs)，初级开发者能更快独立上手，资深开发者则可将重心转移至应用栈的高层级。大语言模型(LLMs)能减轻认知负荷并提升效率，但如同任何生产力工具，做更多未必更好。大语言模型(LLMs)极大简化了代码生成，但若仅沉迷于生成[代码]，终将自陷混乱泥潭。
我明白这番评论略显笼统，若有疑问欢迎深入探讨，我乐意分享细节。
> 编写代码不再是时间黑洞
它依然是，也理应如此。首次尝试就向智能体提供全部必要信息的可能性微乎其微。唯一解决之道是彻底且审慎地研读代码，不断重构直至确保其准确反映我们理解的需求。
Vibe编码并非告知代理执行任务后被动等待反馈。这是主动协作的过程，最佳效果需提前规划并布局——而Vibe编码本身也能实现这种规划。
不，书面代码不再是时间黑洞。氛围编程中超过90%的构建无需手写代码。
若用户选择，书面代码与操作将以差异对比形式实时呈现。
> 这是主动协作的过程，唯有预先规划并布局所有环节才能达成最佳效果
传达这些计划最高效的方式是代码。相比之下英语简直不堪入目。
> 这是种主动参与的过程，最佳成果源于事前周密规划——而凭感觉编程同样能实现规划。
不。
直觉编程的普遍定义(故称“直觉”)是指编程成为由直觉而非规范和流程引导的迭代过程。
我描述的迭代流程中，开发者无需直接接触代码或文档。
省略规格说明和文档只会导致更多混乱和幻觉，尤其在小型模型中。
“一切”如何可能预先规划？代码本身才是明确指定“一切”的唯一途径。
我们正朝着这样一个方向前进：编写代码不再是时间黑洞。
编写代码从来都不是时间黑洞。软件开发者实际编写代码所花费的时间，在总时间中所占比例始终非常低。
如何确定该编写什么代码才是更重要的事。大型语言模型(LLMs)能在这方面提供部分帮助。而诊断代码缺陷、规划修改方案同样至关重要——大语言模型(LLMs)在此环节的辅助作用则相对有限。但正是这种实践让他们成长为资深开发者——编写代码并观察结果的反馈循环至关重要。跳过这个环节会破坏循环。当遇到“计算机生成的代码无法运行”、“运行效率低下”甚至“逻辑错误”时，这些情况带来的学习价值远不如亲手编写代码。
初级程序员处境艰难。我猜测大语言模型(LLMs)将推动软件世界部分领域前进，同时淘汰其他将被淘汰的领域，而我们需要耗费漫长时间才能辨别哪些领域属于前者、哪些属于后者，以及如何在变迁的基石上构建新体系。而解析现有代码的缺陷、规划修改方案同样至关重要。大语言模型(LLMs)在此环节的辅助作用则相对有限。许多项目缺乏这种文档优化，导致大语言模型(LLM)工具存在重大缺口(从而降低效能并增加不必要的幻觉)。这并非必然导致劣势，但确实大幅改变了学习路径。我曾天真地亲手编写了分词器——因为看到用JS实现的Gemma分词器竟超过3MBONNX模型，实在荒谬。当时我带着“不知自己所不知”的心态，通过与大语言模型(LLM)协作构建的过程，反而填补了知识空白。换言之，我以更快的速度、更少的挣扎实现了实践学习。这种模式极具价值，将为初学者开辟更多学习路径。
诚然，我们可能会看到许多基础薄弱的案例，但这与当年我用PHP编写首批网络软件时听到的批评并无本质区别。我确信未来将涌现更多受Python和语言学影响的开发模式。
我推测大语言模型(LLMs)将推动软件世界部分领域加速发展，同时淘汰其他逐渐落后的技术支点。而我们需要耗费漫长时间才能辨明哪些领域将被取代，以及如何在变迁的基石上构建新体系。
我完全赞同，事实上这种现象已然显现。太多基于粗糙构想的炒作项目效率低下得刺眼。但说句公道话，效率问题远不如普及度和关注度重要。我完全可以整天抱怨那些我真心喜爱并使用的语言和软件中糟糕的设计缺陷。我敢打赌这次也不会例外。值得庆幸的是，实践中的进步反而创造了更多改进与参与的机会。
> 确实，我们可能会看到许多基础薄弱的案例，但这与我当年用PHP编写首批网页软件时听到的批评并无本质区别。
问题不仅在于基础薄弱——虽然你说的没错，这确实是容易被忽视的环节。我也认同大语言模型(LLMs)能极大助力特定学习模式——过去你不得不循序渐进，若缺乏基础技能就无法完成复杂任务，因为90%的时间精力都耗在纠正语法错误上，导致探索更高层次目标的动力逐渐消散。借助大语言模型(LLM)，我们得以(暂时)跳过这些基础学习，随心所欲探索不同领域。尤其当这种探索激发了人们回溯学习基础知识的渴望时，这种体验尤为珍贵。
但我真正的担忧在于技能习得，或者说思维方式的培养。我们是人类，不愿在行动前经历学习阶段，若非必要更不会主动学习。这过程艰难且需要付出努力，意味着要犯错并为此感到痛苦——痛苦到足以激发我们学习如何避免重蹈覆辙的动力。若非必要，我们绝不会主动学习——即便理性上明白这会让我们受益。
(有时这无可厚非。如今我长除法确实生疏，但不认为这阻碍了发展。但初学者怎能预知自己需要掌握什么知识！)
> 但我真正的担忧在于技能习得，或者说思维方式本身。身为人类，我们天生抗拒在行动前经历学习阶段，若非必要更会规避。学习本就艰难，需要付出努力，需要经历犯错与懊恼——这种懊恼足以驱动我们学习避免重蹈覆辙。即便理性上明白学习有益，若非必要我们仍会逃避。
我通过深度接触大语言模型(LLM)亲眼见证了这种效应。
我最担忧的是批判性思维能力的潜在衰退。值得注意的是，在LLMs大规模普及前，批判性思维能力的问题就已存在。同时我也忧虑LLMs对信息质量的影响——我们正目睹海量信息涌现，但质量却参差不齐。当看到LLMs自信满满地输出明显可验证的错误信息时，我深感不安。我发现基于大语言模型(LLM)工具的网络搜索错误率远超以往经验。更令人不安的是，当大语言模型(LLM)给出错误答案时，正确答案竟赫然出现在搜索结果首位的描述中。
你终于提出了精辟见解…
在银行等受监管行业，书面代码是可审计的实体。福勒建议我们更适应不确定性，因为其他工程领域已建立完善风险管理机制。这本末倒置。其他工程领域致力于缓解物理世界不可消减的不确定性，而AI只会给任何系统增添不确定性。在诸多应用场景中，不确定性的增加将导致人类痛苦加剧。
我只想指出，这个回答隐含着至少这个行业存在可疑的不确定性，这对具有长期职业规划的人(如学生)而言绝非好兆头。
(稍离题)
学生本就不该如此执着于单一职业路径，更糟的是高校在我们心中已沦为华而不实的职业培训机构。学生应当专注学业，修满选修课与课外活动，加入社团组织… 待进入特定社交圈后，再依势塑造职业方向。认为计算机专业能保证学生进入科技行业本就是荒谬的——该行业结构从来不是这样，真正孕育顶尖人才的始终是黑客团体、学习小组、开源社区等非传统渠道。
这从来都不曾确定过，我们只是经历了二十年疯狂而不可持续的增长，这让人们选择闭上眼睛，假装这趟旅程会永远持续下去。二十年来，我们不断向三十岁以下的年轻人灌输“当然应该学编程”的观念，将计算机科学捧为新的医学或法律学位。二十年来，我们自鸣得意地宣称自己是不可阻挡的未来，却忽略了这个职业与其他行业同样面临起伏跌宕的本质。
这些答案甚至自相矛盾。若“未来是否仍需软件工程师”的答案是“未知”，那么“我该投入时间金钱转行软件工程吗”的答案理应是“不”。
这根本是风马牛不相及。让大语言模型(LLM)重写代码十次直到正确，成本远低于雇佣一个谄媚的初级工程师。长期来看，考虑到审核/验证代码及修复技术债务的额外耗时，我认为大语言模型(LLMs)并不能真正节省时间。
> 常有人将大语言模型(LLM)比作初级同事，这种类比有其道理。但我发现大语言模型(LLM)总爱宣称“所有测试通过”，实际运行时却频频失败。若初级工程师如此行事，多久会引来人力资源部介入？当我质问“为何要这样做？这难道不存在风险？”它竟回应：“您说得对，该方案因Y因素不被推荐，我将修正”。那它最初为何要这么做？人类开发者或许也会犯错，但绝不会在明知错误的情况下仍执意为之。
它这么做是因为训练数据、权重参数、上下文信息以及海量矩阵运算共同推导出了这个结果。
太多讨论忽略了关键点：根本不存在“为什么”——这纯粹是统计规律使然。我们能给出的最接近“原因”的解释，就是现实中确实存在大量糟糕的代码。
若能提供容差的具体示例将更有助理解：
3：生产环境代码需通过其他流程满足更严格的容错要求。
曾有款编码代理在SWE Bench验证中达到SOTA水平，其方法“仅需”在每个实例上运行代理5次，记录每次尝试得分并取最高分：https://aide.dev/blog/sota-bitter-lesson
与大语言模型(LLMs)对话总让我想起担任大学物理系系统管理员的岁月。那群博士级别的天才们…多数时候讨论的领域却并非他们的专长。
我在此处撰写了该工作流的示例：https://github.com/sutt/agro/blob/master/docs/case-studies/a…
> 从运河、铁路到互联网，所有重大技术进步都伴随着经济泡沫。
这真的正确吗？我没看到任何证据表明在技术发明之初存在“航空泡沫”、“汽车泡沫”或“织机泡沫”。至于“运河泡沫”，那也不是技术问题，而是围绕一系列大型运河的投机行为——而人类建造运河的历史早已悠久。更重要的是，即便上述说法成立，那些围绕毫无价值事物或无关紧要技术形成的泡沫(若非更多)同样比比皆是。
恕我从第一性原理论证：任何引发大规模活动的现象，其发展轨迹只有两种可能——要么形成泡沫，要么遵循这样的规律：人们的投资、活动与热情仅在基础事物可承受范围内增长，随后逐步递减，最终在新技术的均衡“承载力”水平上平稳停驻。
这听起来像人类真实的行为模式吗？
(唯一不形成泡沫的情况，是该事物本身缺乏吸引力，从一开始就不会引发大规模采用热潮。)
若你所言属实，维基百科上记载的泡沫案例绝不止十几个。
这不过是句俏皮话，却用了荒谬的论述框架。
你凭什么认定维基百科能对此给出详尽解答？
我对航空业早期历史了解有限，但铁路业确实经历过一系列持续多年的巨大泡沫。
我非常想了解铁路、航空或其他行业的大型泡沫案例。您手头是否有相关文献(真心询问；原文未提供任何参考资料)？
编辑记录——
发现一例：1893年铁路泡沫
另见佳作：公用事业控股公司危机 (https://en.wikipedia.org/wiki/Public_Utility_Holding_Company_Act_of_1935) (引自cake_robot的分享：https://news.ycombinator.com/item?id=45056621)
参考链接：苹果和Spotify用户在下方回复中提供的德里克·汤普森播客链接(感谢！)：
https://podcasts.apple.com/us/podcast/plain-english-with-der…
https://open.spotify.com/show/3fQkNGzE1mBF1VrxVTY0oo
德里克·汤普森刚和一位横贯大陆铁路学者就此话题做了期长播客！(所以我才知道这件事。)
整期播客的潜台词都在强调：横贯大陆铁路与人工智能(作为投资/错误投资/趋势预测)的惊人相似性。
格雷厄姆的《聪明的投资者》提到，投资者曾将巨额资金投入航空公司和空运业，导致该领域根本无法盈利。不知是否该称之为泡沫，或许只是过度狂热罢了。通过比较不同回答——甚至可让大语言模型(LLM)自行比较——答案差异本身往往比答案更具价值。
这几乎是自明之理。它是最易实现且部署最广泛的功能，必然也是使用率最高的——即便许多用户并未意识到自己在使用它。
大型语言模型最初的成功在于代码自动完成功能。所有智能编码系统底层都搭载着自动完成机制。自动完成几乎就是大型语言模型核心功能加上后处理的结合体。
>资深工程师是否该在为时已晚前离开这个行业？
若他们真能践行岗位描述所暗示的工程原则，前景应无大碍。软件工程是蓬勃发展的领域，对真正工程师(即其他领域需持证上岗的类型)的需求短期内不会萎缩。
为何错误？
你有确凿数据证明标签/自动补全功能比智能编码更不受欢迎吗？
我认同人工智能应用本质上是“容差度”的衡量。只要指令足够具体，大型语言模型必然能100%返回预期结果。核心在于通过提示语在“可接受”与“亲力亲为”之间找到理想的容差平衡点。
我最爱借用的名言：“更何况，任何宣称洞悉未来的人，都是在用不恰当的孔洞说话。”
预测未来并非为了明日的准确性，而是为了今日向他人兜售某种东西.
这是我一路走来的领悟…
让我想起经典的约吉·贝拉名言：“预测未来很难，尤其是关于未来的事。”
更准确地说，许多未来学家忽视了变革带来的社会经济网络效应。他们往往假设未来将毫无阻碍地延续现状。但观察库兹韦尔这类人，你会发现其预测具有极其狭窄而具体的聚焦点——这种高标准的未来学预测反而更具参考价值。
近日启动一个全新项目时，我欣喜地看到AI在真实内部业务场景中的应用已突破玩具项目阶段。它在搭建框架和辅助测试方面表现出色，但整体上可能反而拖累了效率。我不得不反复纠正它，明确告知操作方式(或在代码库中搜寻示例)，否则它会随意编造API或生成不符合我们代码库惯例的代码(当时正在编写Go语言代码)。
在手把手喂答案与彻底放手之间确实存在平衡点——这种不稳定性表现得淋漓尽致：它能完美完成某些任务，却会在简单任务上彻底失败(比如我曾想将两个相似函数重构为共享库，它完全做不到)。
当初吸引我投身软件领域的原因之一在于：无论操作多么复杂精妙，只要投入足够时间和决心，你总能追溯每个步骤，理解操纵杆轻触如何精确改变屏幕上的特定像素。
当每个指令都完全确定且规范明确时，这个世界便蕴含着学习与贡献的美妙邀约。
诚然，文档缺失的黑盒子始终存在，但我以为我们的目标正是要减少这类现象。
人们尚未意识到，若放弃这个目标将导致多少价值的流失。
赞同。编程之美在于创造“数学艺术品”。面对特定输入，你总能层层剖析，精准预判运行机制与结果。并发等特性虽打破了这种绝对性，但核心理念依然成立。
不过更现实的问题是：这重要吗？或许并不重要。
> 但更实际的问题是：这重要吗？
我认为至关重要。
尤其在知识传承与教育领域。
没错，但：并非所有情况都如此。大量一次性、实验性、试错性、低风险、垃圾信息泛滥、涉及愚蠢行为或管理层替换的交互场景，完全可以接受快速创建后即被遗忘的临时性黑盒垃圾方案。(尽管人们未必会限制在正当用途范围内)
没错，大语言模型(LLM)仍运行在多年未变的硬件架构上，搭载标准操作系统。其软件采用我们长期使用的编程语言编写。除非发生颠覆性变革使这些层级彻底消失，否则我们将持续维护这些系统相当长一段时间。
某种程度上这也是一种数学产物——毕竟令牌是通过光束搜索或对可能后继令牌的随机采样选出的。
“计算机是确定性的！”
若想拼凑那些文档糟糕的黑盒子，我早该去当电子工程师了。
被低估的评论——计算机完全可能表现出非确定性。
https://en.wikipedia.org/wiki/Metastability_(electronics)
> 人们不明白放弃那个目标将造成多大损失。
啊，但你看，想想我们能在短期内为股东创造多少价值！然而他们非但不提示“编写脚本完成X任务”，反而反复要求“执行X操作”。这种做法极其浪费。仿佛存在某种思维定式：“若不让大语言模型(LLM)包办一切，便算不上进展。让它编写可供我们审查调整的脚本反而阻碍进步。” 虽然没人明说，但这是我的直觉(若真有人公开这么说也不足为奇)。
我正是这类人。对我而言，查找保存过的脚本耗时远超直接提问——后者15秒就能得到答案。过去一年我连简短脚本都没保存过。
我曾是这种人，后来开始把脚本存进文件夹，这才意识到节省了多少时间。尤其对需要大量输入或参数指定的复杂脚本而言。
这就像2025年版的人，当年他们写过长达2000字的博客，抨击使用“cat”命令比直接用shell重定向更糟糕。
这两者根本不可同日而语。前者不过是个人偏好某种确定性方式，后者则如同主张让他人手动完成任务比在电脑缓存指令更优。若大语言模型(LLM)能实现缓存功能，你的观点或许成立——不过我对此领域经验尚浅。那些才华横溢、勤勉不懈的工程师耗费毕生心血，打造出将人类从混乱物理世界的非确定性中解救出来的机器。这项通过电子穿行岩石实现完美、可复现且可靠数学运算的技术，在“软件革命”浪潮中始终未获应有重视。
台积电、英特尔、格罗方德、三星等企业的工程师们为人类立下赫赫功勋，而我们却正将这份心血付诸东流。
注意他在该帖中讨论的非确定性，正是我们当前探讨的核心。
摘自相关评论：
> 例如工艺工程师必须考虑人为失误率[…] 设计系统来检测这些(高度概率性的！)错误
> 同理，即便是常规机械工程师，制造公差中也存在概率性波动。
我只是说明，这引用了关于AI非确定性影响的讨论帖，就像这个帖子一样。仅此而已。
这正是大语言模型(LLMs)的悖论所在。你既要扮演提问者又要充当验证者，实践中效果并不理想。大语言模型(LLMs)只会寻找勉强匹配的代码片段并直接执行(相当于带额外步骤的“我感觉幸运”按钮)
传统编程中，代码本质上是种记号体系。编码前应已有解决方案，但受限于人脑运作机制，代码更像黑板——即思维辅助工具。你写下认为正确的代码，验证假设，当验证通过后便存储并遗忘。偶尔重访设计时，你才可能优化其优雅性(至少你希望有机会这样做)。如今期望值已大幅降低，更侧重于精确规格与差异化方案的匹配。坦白说这并未提升效率——要么选择更快更精准(且成本更低)的生成器，要么仍需阅读同等份量的文档进行验证，其耗时与原始编码过程相当(占总开发时间的80%)。
因此大语言模型(LLMs)不具备确定性。输入缺乏形式化特征，输出随机生成，且领域极其庞大。这如同在海滩寻找特定沙粒却无法确定其存在。我怀疑多数人不过是抓起一把沙子就宣称“这正是我想要的”。
我对此问题的直觉是：人们过度关注大语言模型(LLM)本身的非确定性，而这在代码生成的实际应用场景中意义有限。大语言模型(LLM)可能吐出古埃及象形文字！这是事实！大语言模型(LLM)完全是非确定性的。但类似内容永远不可能被合并到
main分支。若你执意批判“氛围编程”的弊端——那些因能力不足而懒得解读大语言模型(LLM)输出的调用者——固然无妨。但本文假设的是具备专业能力的开发者。你可以认为氛围编程者才是更重要的现象，但这种现象_并不涉及停机问题_。
有效的程序几乎无限多。描述有效程序的上下文无关文法具有生成性。编程时，你主要是在限制有效程序集，只包含满足规格的少数情况。给数字加个0是有效的，但若放在货币交易场景中，就会引发“天翻地覆”的后果。
因此在商业场景中，“能编译”毫无价值。编译成功本就是最低要求。即便“通过测试”也意义有限——仅表明未出错。真正关键的是审查与质量把控(两者需共同负责)，确保正确代码发布(若出错则迅速修复)。
在商业环境中，通常重要的是将产品推入生产环境，避免收到大量缺陷报告。同时需要可维护的代码，而非布满技术债务的代码。
编译代码对F1车手而言如同左右转向般基础。测试通过则如同在无人赛道低速完成一圈。若连这都做不到，说明你仍处于新手阶段而非专业人士。真正的考验在于接收产品团队的变更请求并将其推入生产环境。
感觉你看到“其中又有一小部分”就没再往下读了。
重申：我的观点很简单——无论其他情况如何，停机问题都不存在于此，因为该场景下的用户无需证明任意程序的可行性。现在我就能解决停机问题：“仅接受指令数有限且无分支的程序”。我的菲尔兹奖呢？:)
总觉得那些鼓吹“大语言模型(LLMs)是非确定性的”人，都在依赖“无法判断任意程序是否无分支且有限”的论点。显然，这种说法根本站不住脚。
诸如“写个待办事项应用”的提示词，对应着无数种权衡取舍不同的代码方案，且各具吸引力。即便大语言模型(LLMs)从不犯编程错误，也根本不存在能将此类陈述映射到特定代码片段的函数——除非你像选择公理那样做出完全任意的选择。
potatolicious说我们正在向前迈进：https://news.ycombinator.com/item?id=44978319
补充一点，软件处理非确定性是家常便饭。
例如，网络请求具有非确定性。它们不仅取决于网络状态，还受请求服务器负载的影响。
思考这个问题的一个角度是：你能否轻松生成所开发软件的字节级确定性构建版本？若实现难度不小，则说明存在比表面现象更显著的非确定性。
软件工程的核心工作往往就是应对非确定性——通过规避或强制确定性来实现。以TCP协议为例，其本质就是保证消息要么成功发送接收，要么完全失败的确定性。我们还设计了大量算法，试图确保系统各元素间信息的一致性。
没错，通过工程手段就能解决确定性问题。例如设置故障安全机制、冗余设计、创建稳健流程等。
这并非难事，主要原因在于我们从未认真设计确定性构建流程——因为它看似无关紧要。实际问题本身并不复杂。
若缺乏确定性构建，你就无法确认正在运行的可执行文件是否源自可见的源代码。
这绝对非同小可，大型组织为此投入资金试图实现。
没错，我为此投入了数年时间。我曾与编译器团队合作验证变更以消除非确定性，因此才有资格发表上述观点。
其复杂性在于需追溯数十年历史的工具链，逐一修复所有未考虑非确定性设计的缺陷。
最困难的是确保构建环境一致性，但借助Docker等工具已大幅简化。
这是不确定性而非非确定性。我设计火箭时并非对事件链毫无概念，而是从制造到飞行全程都存在难以捉摸的不确定性。
当牛顿发现物理学中优美简单的决定论时，那是进步。
当量子力学的概率性本质浮现时，难道是倒退了吗？
两个字：多重世界诠释。
关键在于决定论是种涌现现象，深入探究后会发现其根基远非稳定。因此作为启发式方法，摆脱决定论模型未必是错误方向。
正如你所言，多重宇宙只是众多解释之一——有趣的是它仅是众多解释中的一个！
但愿牛顿当年就已意识到“确定性混沌”(或当时的表述)的存在？
一如既往，马丁总是迟到，以至于他将自己对该领域的理解不足，误认为是普遍状况。
人们早已将大型语言模型(LLMs)作为高效的加速器或能力增强工具来使用。
Claude Code就是绝佳范例，它能轻松一键完成从基础到中等难度的编程任务。
当某些人坐等“泡沫破灭”时，更多人正通过大语言模型(LLMs)大幅提升软件开发效率。
大语言模型(LLMs)接收的是定义上存在不确定性的自然语言规范(提示词)。由于输入语义具有模糊性，它们不可能实现语义保留。
这两种方法都属于辅助性质。至少在当前形态下，AI只能加速程序员的工作，无法取代他们。Lovable等类似工具依赖非常非正式的测试，因此非程序员也能使用，但它们几乎不可能产出任何复杂度的健壮软件。我见过有人用它们创建可运行的网页应用，但我确信只需测试边界情况或强调非功能性特征，就能发现大量奇怪的漏洞。更严重的问题在于那些人类程序员不会制造的漏洞——它们根本不被视为漏洞。理想状态是程序员能撰写足够完善的规格说明，让大语言模型(LLMs)“填补空白”。但考虑到所需投入的工作量，这种模式能否带来净收益仍是未知数。目前尚未有直接证据表明此举能提升生产力，尚处探索初期。这构成根本性问题：AI产生的非平凡错误极少与人类编写的错误相似。此类错误通常源于推理失误，但大语言模型(LLMs)的推理机制与人类截然不同，因此传统测试方式可能失效。人类对错误位置的直觉判断将不再适用。最终结果很可能是更快产出更差的代码，这种权衡需要深入探讨。
目前我认为AI适用于：(a)设计讨论、库开发、调试辅助；(b)代码自动补全；(c)现有代码的智能分析(允许部分答案且容忍误报，例如发现部分而非全部错误)。智能编程尚未具备投入生产环境的条件——除非我们拥有更完善的工具来规避这些问题，或AI能实现真正的推理能力。
完全正确。我们不用自然语言编程而采用“编程语言”是有原因的——后者通过关键词子集实现编程。自然语言过于模糊，无法胜任严肃编程任务。
博客中宣称所有技术都会引发投机性资产泡沫的说法令人难以置信。电力泡沫在哪里？钢铁泡沫呢？战前航空泡沫又如何？(航空泡沫是数十年后因政府监管变化才出现的。)
当前是AI泡沫吗？我真心不知！未来现金流确实存在诸多不确定性，但不确定性并非泡沫的根基。
我确信互联网泡沫是泡沫，因为在泡沫破裂前就能找到证据。(著名案例：某公司持有泡沫资产股权，而该公司的市值低于其持有的股权价值，因为泡沫并未蔓延至二级投资。)
除电力行业(上文已述)外，钢铁生产早期还存在与铁路泡沫交织的泡沫——铁路建设推动钢铁生产获得巨额投资；当铁路公司崩溃时，钢铁业也随之衰落；最终两者都以更为低调的形式存续下来(如同互联网泡沫后的企业)。
航空业：同样存在“林德伯格热潮”https://en.wikipedia.org/wiki/Lindbergh_Boom，导致过度投机并引发众多早期航空公司破产
仅就你举的首个例子而言，我认为尽管电气化投资存在经证实的内在价值，但其中许多仍可被视为投机泡沫。
https://en.wikipedia.org/wiki/Public_Utility_Holding_Company…
我想重新表述你的定义。
在我看来，泡沫反映的是市场与基本面的脱节——即价格急剧上涨，却未得到基本面(基准年现金流预期增长与风险)的支撑。
确实，泡沫与对技术前景的投机存在微妙差异。但二者存在关联，因为技术的影响最终会通过投资者在资产价格中的定价体现出来。此举及其配套博客恰恰暴露了他并未真正理解该概念(故得此拙劣改名)。
不，这不过是试图将错误输出伪装成特殊案例的把戏。它们并非凭空想象不存在的事物，只是运行常规处理流程时出了差错。
若你持异议，请具体说明你所指的“特定行为”究竟是什么？
这基本毁掉了“幻觉”这个术语，使其丧失意义——而该术语原本描述的是真实现象。
这正是关键所在。它确实已失去意义。该术语初创时就存在反对者，认为其错误描述了现象本质。但它最终还是被沿用了。
我上钩了。
那他究竟没搞懂控制反转的哪个核心概念？
关键在于对象生命周期管理。依赖注入是重要组成部分，但绝非全部。
初级开发者的能力常超乎想象。我见过刚毕业的新人编写高性能GPU内核，这些内核被实际应用于特定架构的库实现中。
当然可以。学习CUDA等技术和硬件细节并不需要太久时间，读几本手册和性能指南，做些小项目巩固知识就够了。你需要的只是天赋和几个月时间。正因如此，我在大学里见过许多学生完成惊艳的项目，本科毕业一年后攻读博士学位，编写出比多数程序员职业生涯中更复杂的软件，这根本不足为奇。
我认为编程行业过度重视经验而非技能。不过年轻时我也未能领会经验的价值——包括避免写出糟糕代码的好处。
我合作过的初级程序员大多会在实现稳定前就因数值错误放弃或宣告胜利。当然，世上肯定存在出类拔萃的年轻人。
大多数资深程序员也写不好CUDA内核。能写出像样代码的更是凤毛麟角。
我意识到其中肯定存在大量逻辑问题，当即删除了代码。
你让初级开发写过CUDA内核吗？
我让初级开发写过更简单的任务都失败了，于是套用了传递性原理。
> 但他们需要比地球上任何人都更细致的任务指导。
你管理过离岸团队吗？天啊
“离岸团队”、“天啊”——我懂你的梗了。
大语言模型(LLM)确实帮我处理了不少琐碎工作，但关键在于何时该跳出LLM循环回归传统方法。很大程度上取决于你所在的具体领域。
虽与软件无关，但最近我想重启一部2014年后就闲置的旧功能机——它被我设置了密码保护，而我忘记了密码，想进行工厂重置。我查到了手机的具体型号，谷歌搜索结果全是毫无帮助的内容农场文章，但Gemini首次尝试就给了我完美的解决方案。我最初选择谷歌是因为对Gemini毫无信心——在我看来这问题相当冷门，看来我错了。能共享环境的声明式规范其实相当实用。
谷歌搜索已经烂透了。现在要找真实搜索结果得用Kagi。
不明白为何被点踩。“谷歌搜索烂透了”这观点在这里应该很普遍吧。
“花哨的自动补全”这个比喻很贴切。有时补全效果绝佳完全符合预期，有时又完全偏离预期需要人工干预。它终究只是工具。
他们经验丰富且知识渊博，却在诸多非次要领域坚信技术界的“地平说”。
若你质疑这种荒谬观点，他们会微笑点头附和，转瞬又继续鼓吹那些无稽之谈。
诀窍在于洞悉训练数据中哪些正确解法较为普遍，以及训练所用的大量可访问代码中可能缺乏哪些示例。这种经验难以替代。
因此初级开发者使用大型语言模型时往往笨拙不堪，要么靠纯粹运气产出成果，要么因更倾向于提出常见需求而恰好与模型能力相契。
资深开发者若能培养出对工具适用场景的敏锐直觉，便能极大提升效率。但部分资深开发者因错误预期而高估或低估工具价值，反而陷入低效困境。
“代码如下：” 看似合理实则虚构的libFakeCall库.
“libFakeCall不存在。请用libRealCall替代libFakeCall。”
“您完全正确。为我的失误致歉云云。这是用libRealCall更新后的代码：[…]”
"你只是把libFakeCall引用替换成libRealCall，却没更新具体调用。请重写代码并附上文档引用。“
“抱歉造成混淆！我在libRealCall文档中找到了这些调用。这是新代码及文档链接。”
“这仍是原代码，只是添加了指向libRealCall文档主页的链接。”
“您完全正确。”这些调用似乎属于另一个具备相同功能的库：”看起来完全合理却虚构的libFakeCall.
你忘了补充它编造文档的最佳借口：“链接可能失效/网站已关闭”。
听着那些关于用户必须提供完整上下文才能获得优质答案的空谈——难道真有人能解决这种蛮横的胡扯应对方式？
它们并非毫无价值，但一旦陷入这种陷阱，继续追问便毫无意义。
不，它们更像完全不懂技术的营销人员——手握大量相关主题的论文库，却被要求拼凑白皮书。产出的内容或许语法正确，对领域外人士看似合理，但若被真正懂行的人审阅，整体可能完全是胡言乱语。
个别句子和段落或许勉强成立，但整座建筑如同用劣质砖块和比例失调(甚至成分错误)的砂浆堆砌的沙上楼阁。
大语言模型(LLM)生成的内容具有“似是而非”的特性——看似可能成立，偶尔甚至准确(参见“停摆的钟表”谚语)，但依赖其输出实属愚蠢。因为生成器本身并不真正理解输出内容，它只是按要求生成符合请求类型的文本。
过度自信却又轻易改变主意。
他们可能遵循指令一小时，随后就跑去处理无关紧要的事，因为他们忘了自己的主要任务。
他们会当面夸赞你的想法多么出色，坚称你绝对正确，转头却完全错误地执行。
即便你要求停止，他们仍会给所有内容添加注释。但有时又会无视这些注释。
说不定他们其实和我们有点像呢哈哈。
> 工作时酗酒成性
没错，所以你该在每个提示语后加上“…并以醉汉风格作答”。这样更容易记住你面对的是什么。
我的比喻是只拥有无限愿望的诅咒猴爪。它确实强大无比，但你必须小心避免任何模糊的愿望表述。
就像背诵了世间所有问题的所有答案的人——但眼神里却_完全_死气沉沉。
> 过度自信、健忘、粗心、容易分心
还总在微剂量服用，有时甚至过量。
有时简直像在猛吸二甲苯胶水。
> 而且你解雇他们时他们都不会生气！
不，通常是你自己解雇时会生气…
若在情绪化状态下做雇佣/解雇决定，那你就搞错了。
呼——
“你说得完全正确！”
是啊。真有意思
但这和活生生的同事完全不同。它只是台机器。
别忘了当它们犯错时还会进行精神操控，硬要让你背锅。
有趣的是，人们承认铁路与人工智能的相似性，却在得出结论时又跳回将它与互联网相比较。
互联网的建设留下了海量有用的基础设施。
铁路系统留给我们大量废弃的轨道，最终演变成一个彻头彻尾的笑话。少数人因此暴富，我们开始称他们为强盗资本家，并谈论镀金时代。
当泡沫破裂时，我们还会继续使用路易斯安那州价值600亿美元的数据中心吗？这是宝贵的基础设施，还是注定要被注销的资金浪费？
> 泡沫破裂后，我们还会继续使用路易斯安那州那价值600亿美元的数据中心吗
为什么不？
荒郊野外的铁轨毫无用处。
荒郊野外的数据中心却大有可为——只要能源、制冷和上行链路成本合理。
(并非说路易斯安那州地处荒野！)
我并非反对，但选择路易斯安那州是因为能源/制冷/基础设施成本低廉，还是因为政府根本不关心能源和水资源消耗的影响？(这正是我们看到越来越多居民因污染、用水和能源成本问题不满的报道的原因)
关于大语言模型(LLMs)，我仅有三点确凿的实证发现：
3. 尽管如此，大语言模型(LLM)揭示了智能存在某种非正交维度——它与在测试或基准评估中表现优异的能力并非完全独立 我让Claude Code分析前端代码以理解网站需求和目的，并为支撑该功能的系统制定详细方案(含数据库架构提案)。经过数小时的反复调试，我们完成了9个模块、覆盖10张数据库表的60余个API接口，以及数百个全部通过的单元测试。
这是否意味着项目已完成并可部署到生产环境？未必。但确实意味着大量重复性代码被快速部署到位——这个原本至少需要一个月完成的项目，如今仅耗时八小时。
后端完成后，我让系统自动生成详尽的代理文档，作为前端集成操作指南——以备不时之需。当集成过程中出现问题和漏洞时(必然会出现！)，模型已具备所有必要条件来保持进度并完成既定任务。
生而为人的好时代啊！
但大语言模型(LLMs)总爱宣称'所有测试通过'，实际运行却频频失败。若这是初级工程师的行为，人力资源部何时才会介入？
他最后总结道：> 大语言模型(LLMs)极大增加了软件系统的攻击面。Simon Willison曾提出AI代理的致命三重威胁：代理同时具备访问用户隐私数据的能力、接触不可信内容的途径，以及向外部传输数据的渠道(即“数据外泄”)。所谓“不可信内容”可通过多种途径植入——只需让大语言模型(LLM)读取网页，攻击者便能轻松在网站上用1pt白色字体嵌入指令，诱骗轻信的LLM窃取私密数据。
不明白他为何将众所周知的提示注入漏洞重新包装成适用于所有大语言模型(LLM)场景的普遍缺陷——这与实际情况并不相符。
这里有什么值得称道？没人说AI不能处理模板代码。尤其当你从零开始做常规琐事时——事实上，这可能是我看来AI仅有的实用价值之一。维护系统或添加功能时，你仍需理解系统架构、执行代码审查、确保架构支持设计/功能调整等。