我拒绝使用人工智能编程工具。我无需尝试就知道它们是垃圾。我有直觉。
2022年我测试过ChatGPT，让它写点东西。它(显然)搞砸了——具体内容记不清了，但绝对是错的。三年前的事，我再也没回头。何必呢？人工智能工具又没发生什么实质性变化，对吧？
我同事现在用Claude Code。她上周完成的项目，换作我得耗费整整一个月。我斥责她“作弊”，她却不懂我们这群人坚守的准则——我们执着于艰难之道(即便捷径能达成相同结果)。
“AI编写的代码漏洞百出”，我常这样宣称。与我的代码不同，虽然同样漏洞丛生，但我的漏洞是匠心独具的。
我经常从Stack Overflow抄代码。但这和AI不同。区别很明显(至少在我脑子里是这样)。
AI什么时候才能好到让我愿意尝试？也许吧。等它能读懂我的心思，永远不出错，还亲自向我道歉——因为它威胁到了我的身份认同感。在那之前，我还是算了。
好吧，我收敛一下。
上周我写了《AI能写代码，但做不了你的工作》。核心观点是：AI在改变某些事物，但工作本身不会消失。编程是任务，软件工程是角色。
老实说，我确实预料到会引发争议。本以为大家会质疑乐观论调，比如“你太天真了，AI迟早取代我们！”之类的。
但实际情况截然相反——反对声浪竟来自另一端。工程师们对“AI能编写代码”的表述暴跳如雷，这着实令我震惊。
以下是工程师们的反馈：
“勉强能行。在持续监督下勉强能提供些许辅助。”
“(…)它也写不出我的代码。”
“AI最多能帮我写漏洞。”
“除非我的代码本就该是五层多余抽象构成的幻觉，还带十个安全漏洞。”
“其实不然…AI写的大多是垃圾…”
“它顶多能写出我二十年前刚入行时会写的代码。”
这些可是真正的工程师，本该对新工具最感兴趣的人群。他们整个职业生涯都在学习与适应。然而这种轻蔑态度再次令人震惊——不是说“某些场景下它有用”，而是直接用“不行”‘垃圾’“废物”来否定。
我大概明白原因？或许两三年前他们尝试过AI，当时确实糟糕透顶。或许目睹同事滥用它产出垃圾代码。或许它威胁到他们的身份认同——毕竟编写代码能力就是专业价值的体现。若工具危及这份价值？自然想全盘否定。
但关键在于：2022年的认知已不适用于当下。如今的AI编程工具与当年差距犹如IE11与Chrome之别。Claude Code和Cursor这类工具已彻底改变游戏规则——它们能跨整个代码库运作，理解项目上下文，同时重构多个文件，并持续迭代直至真正完成。若你上次认真尝试距今已逾半年，恕我直言，你的观点已然过时。
且听我明说：我并非宣称AI工具完美无缺。它们确实存在缺陷：仍会产生错误代码，有时过度抽象，甚至会虚构不存在的API(尽管频率已大幅降低)。你仍需审查它们生成的所有内容。但“不完美”与“毫无用处”是截然不同的论断。
拒绝尝试的工程师并非在保护自己，恰恰相反，他们正在落后。采用这些工具的工程师与未采用者之间的差距正在扩大。前者交付速度更快，承担更大挑战；后者则…未能做到。
因此我的请求是：若你近期未尝试现代AI编程工具，请在本周试用一款。目的不是证明其无效，而是真正了解它的能力。
若你实际试用过现代工具却未见成效，这值得深入探讨。但*“我2022年试过ChatGPT”*这种说法，根本算不上讨论。
本文文字及图片出自 The Strange Case of Engineers Who Dismiss AI
> 拒绝尝试的工程师并非在保护自己；恰恰相反，他们正在落后。那些已将这些工具融入工作流程的工程师与尚未采用者之间的差距正在扩大。
然而对我而言存在一个核心问题：如何运用AI而不致退化自身能力？我始终审慎使用AI——坦白说，每次使用都感觉自己智力在流失。我担忧过度依赖AI将导致两重后果：一方面丧失关键技能，另一方面形成精神依赖。倘若最终催生出无法脱离AI编程的软件开发者世代，究竟谁能从中获益？编程不仅是写代码，更是组织、理解和分析的过程。我最渴望的是能帮助我提升工作能力、持续积累技能与知识的人工智能，而非让我对其产生依赖。
> 我谨慎使用人工智能，坦白说每次使用后都感觉自己变笨了些。我担心过度依赖人工智能会导致两方面后果：一方面会丧失重要技能，另一方面会形成依赖性。倘若最终培养出一代离不开人工智能的软件开发者，究竟谁能从中获益？
股东们本季度就能获利。听着，我知道你可能自视甚高，但你现在的职责就是削弱自身能力，以便当下更快交付成果。投资者们恳切要求你配合计划，热情拥抱自己作为折旧资产(而非值得投资的人力资本)的新身份，并停止过度思考。
我们使用C++而非汇编语言就思考更少了吗？使用汇编语言而非打孔卡片就思考更少了吗？使用计算机而非纸笔就思考更少了吗？诸如此类。你今天完全可以在本地硬件上部署强大的本地编码模型，没有任何投资者会插手(除非你指的是你所在公司的投资者，但真相是，他们从来都不关心你如何构建东西，只关心你是否完成)。
> 我们使用C++而非汇编语言，是否意味着思考更少？使用汇编语言而非穿孔卡片，是否意味着思考更少？…
辩护者总爱搬出这类类比：“从三万英尺高空俯瞰，新事物不就和旧事物差不多吗？既然本质相同，你就该接受新事物！” 但这些类比永远牵强，所谓“论证”不过是刻意模糊差异的障眼法。
人工智能的核心意义正是让人类减少思考。这他妈就是名字的本意。若人们仍在过度思考，AI就失职了。你列举的所有案例都属于机械翻译范畴，根本谈不上思考。
> 你今天就能在本地硬件上部署强大的本地编码模型，且无需任何投资方参与(除非你指的是你所在公司的投资者，但实情是，他们从来都不关心你如何构建产品，只在乎你能否交付成果)。
别幻想靠AI就能扮演资本家。你需要资金，而既然你能用本地模型实现，有钱人同样能做到——他们自然无需付你分文。我们靠劳动谋生。
更别妄想你的本地模型能比富人的版本更胜一筹。现实不是科幻小说。
雇主们正指望耗尽你的精力让当前不完善的版本运转，因为他们期待下一代技术不再需要你。别对此抱有幻想，这对你而言是场悲剧。
你如此笃定地说“核心要义就是减少思考”。为何如此认为？我整天使用AI代理后并未减少思考，只是思考的内容不同了。我不再纠结代码片段的放置位置或结构形态，转而思考数据模型、系统架构、理想交付成果的形态，以及如何规划实施路径让智能代理自主执行。我思考如何优化流程自动化以实现工作并行化，同时构建能降低错误概率的控制框架。随着技术探索成本的急剧降低，我反而投入更多精力研究各类技术与框架。
我当前的工作是否终将被自动化取代？或许吧，自动化进程永无止境，我们只能不断攀升抽象层级。但这绝不意味着思考量会减少。
当前所谓的“AI”只是统计模型，并非通用人工智能——你在此处的论断有误。
要善用这些模型仍需通晓全局——每当你偷懒给出模糊指令，就等于给自己埋下海量技术债务。
这或许对某些人尚可接受，但通常是糟糕的选择。
若是通用人工智能，你的观点倒没错…
> 要善用这些模型仍需通晓一切——每当你偷懒给提示时，就是在给自己埋下海量技术债务。
这或许对某些人尚可接受，但总体而言是个糟糕的主意。
我的观点正是：要有效运用这些工具，你必须掌握全部知识；但过度依赖它们会导致知识退化(例如楼主所言“每次使用AI，我都感觉自己变笨了”)。老板们只想要立竿见影的成果，根本不在乎几年后你能力大幅退化(甚至可能再也无法产出有效成果)。
只要通用人工智能(AGI)足够快地到来，他们的赌注就将获得回报。
你做不到，这就是新常态。我们可能是唯一有机会真正精通编程的一代。乐观估计几年后这种奢侈将不复存在；悲观而言，GPT 5.2和Opus 4.5已提前夺走了这份能力。
若真如此(我对此存疑)，那么对已掌握该技能者而言，保留这项能力难道不该是首要任务？我尚未见到任何证据表明AI能将不懂编程者转化为编程人才的替代品。若该技能的供给即将枯竭，其价值必然水涨船高。若使用AI会侵蚀这种能力，那么理性的选择就是不使用AI。
> 若果真如此[…]，那么对已掌握该技能者而言，保留这项能力难道不该是首要任务吗？
我确实认同此观点，但根据我的经验，这类技能在就业市场正变得日益无用。换言之：保留此类技能(如低级编程)对从业者而言，不过是投入大量时间的爱好，在当前就业市场中“毫无用处”。
我认为这是正确的诊断，但要成为优秀的软件工程师，需要约3年的系统学习和5-10年的实战经验——这还是在掌握编程基础的前提下，而编程本身对不同人而言难易程度各异。
若将此投入回报率与“几小时指导就能获得所需软件”相比较——这实属新范式，技术进步(至今)呈指数级增长，我们尚不知其最终形态。
专家将日趋稀缺且备受追捧，但当他们十年、二十年、三十年后陆续退休…等待我们的要么是黑暗时代，要么是人工智能统治者。
我认为计算机专业的学生应该逼自己学习真本事，至少作业要亲手编写代码。我见过太多计算机专业的应届毕业生，在计算机学习生涯中几乎全程依赖GPT，结果根本写不出像样的代码——无论有没有AI辅助。
他们做不到。大学终将迎合企业需求，就像我母校从C/C++教学全面转向托管语言教学那样。
此举让学生更直接匹配热门岗位，但现实是其他岗位的人才供给将减少。
关键问题在于：未来社会是否仍需要真正会编程的人？
我认为会的。同时相信这个领域正在演变，发展始终在两极间摇摆。目前我们才刚开始看到人工智能对软件稳定性与可维护性的影响，更未经历其灾难性失误带来的冲击。
当你和人工智能伙伴都无法解决这个庞大代码库的问题时，拉上同事恐怕也无济于事。
当前由AI生成(且因看似合格而被采纳)的代码量正损害长期稳定性。我们观察到AI极度热衷于修复问题，却完全不顾及历史行为或未来表现。
当然，更优质的提示词和人工审核能部分缓解此问题。但这并非企业期望的发展方向——他们要求我们快速提示后立即推进。
AI会热切地从湖泊铺设10,000条管道至10,000户缺水家庭，再不断分支延伸。
直到某天你发现管道含铅必须更换。
当下这已够棘手。AI更添难度——因缺乏统一规范，开发者为追求速度和交付效率，全靠复制粘贴。
我从未见过哪位软件工程师能为AI产出的每行代码背书，声称其能加速全新开发。事实上多数时候反而更慢——因为AI缺乏认知。即便使用AI，结果往往更糟，因为学习过程被削弱了。那种能不断突破“如何优化事物”边界的学习。
正如我们让孩子学习加减乘除，即便他们手边就有计算器
>但对我而言存在一个核心问题：如何运用AI而不致退化自身能力？
我持怀疑态度，认为这根本行不通，而这正是关键所在。我们见过多少次这样的模式：“公司以惊人的亏损运营，同时消灭竞争对手或深入足够多人的生活，然后突然收紧政策赚取巨额利润”？
> 如何利用人工智能而不退化自身能力？
这种说法在某种程度上是否也适用于使用排序库而非编写自有排序算法？或者用Python这类语言替代C语言中手动处理内存分配和垃圾回收的情况？
> 我最渴望的是能帮助我提升工作能力、持续积累技能与知识的人工智能
根据我的经验，AI输出的质量直接取决于输入的质量。我见过初级开发者用和我相同的语言及LLM模型，却做出架构混乱不堪的AI项目。关键差异在于：我的AI工作基于自身知识设计的模式与架构，这恰恰能确保产出更少缺陷的软件。
我认为使用库与使用Python替代C/Rust等语言存在本质差异。后者因无需顾虑内存效率而具备根本性优势。稳健编程是种权衡——开发速度或许值得牺牲，但若问题严重到导致项目彻底失败则得不偿失。排序库是对排序操作的抽象，它扩展了语言池，使你拥有了基础运算符sort(A)。语言本身超越了运算符差异。
我认为楼主想表达的问题是：若我们仅停留在库层面编程，就会丧失构建更酷炫/更优秀事物的能力。当然并非所有人都如此，但人工智能并非生成全新代码，而是复制粘贴。复制粘贴终有极限，尤其对长期从业者而言。靠复制粘贴的程序员不会开发游戏引擎，更不会编写操作系统。这些领域对多数人而言确实深奥——毕竟真正从事这些工作的人寥寥无几！但当越来越多程序员转向复制粘贴模式(即便借助智能工具)，某种工艺精神正在消亡。
我个人倾向认为，这种过度抽象化的思维模式从长远看存在隐患。这种模式对人们造成的伤害不仅体现在编程层面，更体现在读写能力上——尤其在9-12年级及大学阶段。当我们要求学生写论文、阅读文本时，AI彻底绕过了思考过程。但真相是，一篇关于“哥伦布抵达新大陆因X、Y或Z”的论文成品，根本无法传递任何价值。真正的价值源于撰写论文所需的思考过程。这与楼主担忧的现象如出一辙。或许有人辩称：我们既能使用AI又能思考，只需在审阅AI输出时保持反思。但人类天生惰性——我们不会盯着计算器琢磨数值如何得出，而是直接取用结果。我认为计算结果的应用蕴含着更多价值与思考，因此计算器并未摧毁数学思维，但人工智能的应用未必如此。你观察到初级开发者产出质量下降的事实，恰恰印证了我的观点——我们正在绕过思考环节。若这些新人能掌握模式规律倒无妨，但这绝非必然。我认为不确定性才是楼主真正的担忧，或许可以更准确地表述。
期待你的见解！
不，这更像是让初级开发者编写排序算法而非自己动手。使用库就像采用经过验证的成熟算法，而AI代码提供的并非此类解决方案。
我也担心这点。
但现在的情况就像因害怕身体变差而拒绝用车长途出行，结果反而去健身房锻炼。
顺带一提，我多年来一直嘲笑那些开车去健身房、坐扶梯上楼的人——他们花钱做着相当于骑自行车爬楼梯的运动量，而这些本可以…免费完成！
至少你的用户名很贴切。
这个比喻很贴切。顺便说，我发现使用LLM时学习效率和速度都大幅提升。
这是学习曲线的一部分。当你“共振编码”时，产出的代码仿佛出自他人之手。关键要学会把握分寸——何时该放手让AI代笔，何时该限制使用甚至完全不用。
使用计算器/电子表格是否节省时间？还是该坚持心算？因为依赖工具进行快速计算的能力会随着依赖程度加深而衰退。
我并不太担心能力退化，毕竟我的基础扎实。即便因缺乏练习而生疏，只需向我的专家助手发出提示，它就能即刻提供知识支持，让我迅速恢复状态。
虽然实际编程时间减少了，但我开发的软件类型却增加了。过去我总回避用Bash编写复杂自动化脚本，因为其陈旧的语法总让我卡壳，通常会用Bun/Node处理复杂脚本。但借助AI，我已回归Bash编写大部分脚本(其功能之强大令人惊叹)，并轻松自动化了更多手动流程。
同样因缺乏类型系统和API探索机制而迟疑的Python，如今借助AI自动补全功能，只需写出带注释的方法框架，AI便能自动补全代码。现在我投入大量时间用Python开发AI工具与智能体、ComfyUI自定义节点、图像音频分类器、PIL/ffmpeg转换器等。这些都是人工智能出现前我从未考虑过的事。
我也不担心人工智能的影响，因为我认为这是必然趋势——当技术天平已然倾向于代码可被替代/廉价创建的时代，更重要的是速度和快速执行想法的能力，对我而言这就是尽可能使用人工智能。
我的答案是：将AI用于那些作为项目技术负责人可以放心委托他人的任务。也就是说，你依然掌控项目全局，需要专注于必须亲力亲为的核心环节，但项目中存在大量任务具有明确的边界和定义，此时委托他人执行并进行复核是可行的。
当任务需要你自身缺乏的专业能力时，情况会变得尤为棘手。但此时同样需要思考：你是否愿意将任务委托给不完全信任的人类(例如外包人员)？我的答案往往是“愿意，但需要掌握足够知识来评估其工作”——因此我采取的做法是：学习技术主管所需的知识水平，而非实施专家的深度。
若我们不再视自己为程序员，而更多地定位为软件构建者，那么在采用工具的过程中编程技能的退化便无关紧要——因为这使我们能在更高抽象层级进行构建，类似于产品经理的工作模式。随着工具不断进步，这种抽象层级的提升在软件工程领域已反复上演。我确信这里许多优秀的软件工程师即使拼了命也写不出汇编代码，但他们凭借卓越的软件构建能力获得极高生产力与业界尊重。
话虽如此，只要人工智能存在产生幻觉的可能，我们就必须保持警惕——正因如此，我仍希望保持编程技能的敏锐度。
或许白天依靠AI辅助构建软件，夜晚则化身匠人级程序员。
这不正是现代软件臃肿的根源吗？
这个问题有太多答案——首先，抽象层的堆叠并不必然导致臃肿，通过合理的编译时优化可实现零成本抽象，例如C++编译器。
其次，臃肿有诸多形态且成因各异。你指的是像Node模块那样庞大的依赖安装？还是指内置浏览器的Electron应用？抑或是Java程序员因过度架构设计而不得不忍受的FactoryFactoryFactoryBuilder类漩涡？七层网络协议——这算臃肿吗？
这些都是人为抉择——在快速交付价值与性能之间权衡取舍。基础层通常经过精心设计，恰当的抽象能提升正确性与性能。而在应用层，需求变化更快，人们更愿意接受性能损失，因此会选择你所称的“臃肿”技术栈来加速迭代和价值交付。
因此即便我用抽象概念作类比，也不认为这必然意味着AI辅助编程会导致更多臃肿。相反它能引导人们遵循正确的工程原则，让代码契合当前任务需求而非过度设计。这项技术尚处萌芽期，我们需要学会与之协同工作，才能获得理想效果。
首先得定义何为臃肿。国际化功能算臃肿吗？盲人屏幕阅读器支持呢？我的意思是，Excel确实不需要内置飞行模拟器，但某功能未被使用并不等于臃肿。所以首要任务：定义臃肿。
博茨瓦纳的部分白蚁丘已高达两米以上，但这些传统工程白蚁若不开始运用人工智能并重新定义自身为蚁丘建造者，终将在职业生涯中被时代淘汰。
我明白这种说法过于简化，且相信你的担忧很可能正确，但此类现象已持续数千年之久。文字本身就曾引发争议！
> 他们接着探讨文字的利弊。苏格拉底简述了一个传说，批判性地评论了埃及神祇提乌斯将文字馈赠给塔穆斯国王的故事——这位国王本应将提乌斯的馈赠分发给埃及人民。当塞乌斯宣称文字是治愈记忆的良药时，塔摩斯反驳其真实效果恰恰相反——文字是唤醒记忆而非保存记忆的工具，它拥有智慧的外表却缺乏智慧的本质。后世之人将听闻诸多学识却未受正统教导，看似睿智实则愚昧，终将变得难以相处。
https://en.wikipedia.org/wiki/Phaedrus_(dialogue)
你总能要求它引导你走向正确方向，而非直接给出答案。不过我猜这种用法并不流行。
这并非新问题。如何使用谷歌、翻译工具(甚至词典！)而不致“退化”自身能力？
若不慎将它们当作拐杖依赖，它们终将止步于此，无法真正助你“进步”。
我认为这是个极好的问题：我们该如何运用工具，既避免能力退化又能实现成长？
> 如何使用谷歌、翻译工具(甚至词典！)而不致“退化”自身能力？
我的方法是：将每个不认识的外语单词/短语记录下来，制作卡片放入我的速记卡盒。
我已多年未持续驾驶汽车，但几个月前重新握住方向盘时，几乎所有技能都瞬间复苏，主要挑战在于适应右舵车在左侧车道行驶的模式。技能就是如此——它们从未真正消失，尽管感觉可能如此。编程技能亦是如此(知识则另当别论，因该领域日新月异)。
> 如何运用人工智能而不致退化自身能力？
《红皇后时代的编程》https://corecursive.com/red-queen-coding/ (2025)
定期进行编程训练和问题解决演练
人类曾创造工具满足生理需求(无需奔跑、步行或搬运重物)，如今我们拥有能思考并解决问题的工具
另一个问题是AI生成的内容价值近乎于零。
那么我从这些基本无价值的东西中能分得多少？长远看来似乎并不划算。
价值究竟是什么？一张美元钞票价值一美元，但连这点价值也是人为设定。孩子画的简陋蜡笔画——几根线条勾勒的人和房子——若出自自家孩子之手便无价，换作别人画就一文不值。人工智能正迫使我们直面价值评估本就模糊多变的本质。
价格并非基本真理，只是偶然奏效的数字。理想状态下价格>成本，但一旦考虑固定成本、补贴、税费、返利等因素，这个等式就不再成立。波音公司曾公开承认，当747客机仍在服役时，他们就无法精确计算单架飞机的实际制造成本。
具体案例：某工厂每月固定成本5万美元，每件产品的材料与人工成本为5美元。当月生产5000件产品。
最初定价每件20美元：收入10万美元，成本7.5万美元，每月净赚2.5万美元。相当可观。
随后竞争对手出现，将价格压至每件10美元。收入降至5万美元。表面看较原模式“亏损”。
但若停产，你仍需承担全部5万美元固定成本且收入归零。若持续生产，每件产品不仅覆盖5美元边际成本，还能为固定成本贡献5美元。如此便能实现盈亏平衡，而非亏损5万美元。
这正是“AI产出价值为零”论断的核心谬误。零边际价值并不等同于零经济价值。关键在于它能否覆盖边际成本，并为其他重要环节创造价值：固定成本、分销渠道、用户锁定、差异化优势、互补产品、选择权等。
我们此前多次面临类似困境，因此AI在此方面并无特殊性。它只是让边际成本与感知价值之间的鸿沟变得无法忽视。
> 如何运用AI技术而不致退化自身能力？
就个人而言，我认为自己的能力在于通过设计和实现解决方案来解决问题，而非日常编码本身。当你写完第100个getter/setter方法时，其实已不再创造价值，只是在重复语言/编程模式带来的机械劳动。
善用AI并提升工作效率确实是一种能力，相比不用AI，我能更高效地利用时间。身为系统工程师，我涉猎过多种编程语言，几乎能阅读任何代码，但对任何偏爱的语言都远未达到精通境界。
搭建项目环境、配置工具与模板代码、编写main()函数等任务，若对语言不够精通，往往需要反复搜索和摸索。借助AI只需两行提示语即可完成。
为新增功能搭建基础架构更是另一项苦差事：搜索合适的库/包，添加依赖项，学习使用这些依赖项，创建大量文件，设计结构体/类，规划方法——但此时并非所有细节都清晰明了，因此第一版往往是“堆砌大量代码→收到海量编译器警告→再对混乱代码进行精炼”。而AI只需用一段文字描述需求和实现方式，询问方案后若合理便直接确认。等待5-15分钟期间，我既能观察运行状态(防止出现低级错误)，也能规划后续步骤。
通常结果有90%是可用的，我可能只需修正几个不满意的细节，但语法和警告问题早已解决，因此能专注于阅读理解逻辑、修改实现并捕捉真正的逻辑漏洞。我无需耗费5天以上学习整个库的使用方法，最终却发现所选库缺少上周无法预见的X功能。现在这部分只需10分钟，且无需亲力亲为——我只需处理AI(目前？)无法触及的收尾工作。
我发现向工具(我个人偏爱Copilot/Claude)提供完整上下文(例如.github/copilot-instructions.md)能极大提升结果质量。
没错，那编写汇编语言的技能会退化吗？甚至打孔卡的技能呢？当年编译器问世时也遭遇过类似质疑。与其关注某项技能的消亡，不如关注正在发展的全新技能。这些技能或许并非你期望精通的领域，但事实证明，培养社会工程学技巧来引导大型语言模型执行禁令之外的任务，反而可能成为可迁移至现实生活的实用能力。
[已删除]
这番论调很快就会过时
[已删除]
除了把热衷AI的人骂作“蠢货”，你打算在这条讨论里再添什么内容？
这并非侮辱，只是客观观察
> 用侮辱AI白痴的方式反击
你在这帖的另一条评论里哈哈！仇恨蒙蔽了你的双眼！让它穿透你吧！继续辱骂那些糟糕神经网络的用户直到世界愈合！绝不退缩！
这是善意的观察。
根据我的经验，AI用户确实比普通人群更愚蠢、更轻信。
依我所见，那些因他人使用特定技术(此处指特定神经网络)就对讨论区狂喷侮辱的人…嗯，大概是人生没什么更有意义的事可做。你在其他评论里公然鼓吹侮辱和欺凌他人。别用“这只是观察”这种废话搪塞，认清自己！做你自己！
……或者改变行为成为更好的人，随你便
顺便说一句，我从2018年起就在产业界从事“人工智能”相关工作，此前在学术界也有研究。你评论中展现的世界观极其狭隘，根本不值一提
0.1x
好多了 🙂 简直像机器人！
并非所有工程师都否定大型语言模型。
他们否定的是宗教般的炒作机器。
若想向工程师群体营销，请坚持可验证的论述，并回应他们的核心疑虑。别再用“AI持续进化，半年内解决所有问题，只需持续付费”这类说辞糊弄人。
顺便问下，楼主用这种FOMO营销手段究竟想兜售什么？又是某个ChatGPT前端吗？
那么批评者或许该把矛头指向营销部门，而非贬低技术本身？
说真的，这项技术的潜力目前尚不可知。现有指标表明进展未见放缓，任何爱好者或政策制定者推测其发展方向，或探讨社会如何适应它，都无可厚非。
任何爱好者或政策制定者对未来发展方向进行推测都无可厚非。
每日出现在HN上的内容早已超出推测范畴。心理学家或许有专有名词形容这种现象，我倒是不清楚。
编辑：猜怎么着？我问了个人工智能：
人工智能炒作的心理驱动因素：
顺便一提，文本排版也是由“AI”完成的。特意要求它让表格呈现HN网站的表格样式。
愚蠢、妄想、宣传、谎言和操纵——这些都是我信手拈来的词汇
至少AI能写出语法正确的句子，并正确使用标点和大小写。
作为连按下shift键或标点键都懒得动小指的0.1倍低投入Hacker News用户，你该考虑用AI来提升那些重复性、离题、充满敌意的发帖质量，以及那些表演性质的观点。
或者放下手机，离开马桶。
虽然他们确实做得过火，但我觉得挑剔拼写语法而非内容本身也属于低投入行为
我没错，他才疯了
AI是给蠢货用的
你听起来确实疯了——两种意义上的疯。
你无意间印证了我的观点，因此我将你降级为0.01倍低投入的Hacker News用户。
若AI的唯一价值就是把像你这样的人赶出行业，那它确实证明了自己的实用性。
编辑：好吧，我承认关于0.01x的判断有误——毕竟你坦率承认(并持续提供无可辩驳的证据)自己只是个0.001x级别的懒散Hacker News用户。鉴于所有证据，我不该高估你。
0.001x
我认为过度依赖AI的开发者应被称为“自我贬抑工程师”
个人更倾向“人工智能工程师”或“外包智力工程师”。
我接受这个说法，但看不出它与我始终秉持的“通过自动化取代自身工作”理念有何本质区别。当我想做“工程实践”时，随时可以启动Factorio或Turing Complete。但其余时间我更关注结果而非过程。例如开发工具前，我总先搜索现有解决方案——若有成熟工具能满足需求，通常直接采用。
非确定性正是大型语言模型的独特之处。
当你下载人类编写的工具时，可以合理预期它会实现作者宣称的功能。更重要的是，你还能合理预期：若工具失败，它将在相同条件下以相同方式失败。
Cracktorio！;) 我也超爱戴森球计划。
八十年代上计算机科学哲学课时我写过图灵机程序，但后来这门技能退化了，现在都让LLM代劳。
> 若想面向工程师群体营销，请坚持可验证的论断。
而这正是“AI”的短板所在。
“AI能编写测试用例”。但它能编写_正确的_测试用例吗(即只需像审核同事工作那样简单复核的用例)？
“AI能制定需求规格”。这点我至今仍在等待验证。
> 它能编写正确的测试用例吗
而且这个测试用例对实际代码有用吗？而非教科书式的代码？
如果你意识到大型语言模型确实令人印象深刻且实用，那你可能根本不是目标受众。尽管它们周围充斥着无谓的炒作和泡沫。
[已删除]
不，大型语言模型目前解决了搜索问题。我每天都在用它搜索。
不过完全预期一两年内它们会加入YouTube级别的广告——毕竟搜索结果还算干净。
[删除内容]
另一选择是传统搜索引擎，但它们充斥着垃圾信息。
或者试试Kagi，不过据说它只提供排除内容农场工具，不会自动过滤。
确实需要手动屏蔽，但我用uBlacklist效果很好。某些垃圾网站存在特定共性特征，通过精准检索就能筛选出完整的垃圾域名列表
为什么？只要风投愿意给钱，我很乐意花他们的钱。如果他们提供的条件不再令我满意，我会立刻停止合作。
“只要毒贩买单，我乐意嗑可卡因”
开篇那幅漫画既令人反感又充满轻蔑(而且极其错误，这根本不是当前讨论的核心议题)，我最终没能读完这篇文章。
无需亲身使用某项工具，也能认清其可怕的危害与副作用。我从未接触过突击步枪，却能对其提出批判。我无需吸毒就能批判街头毒品，也无需亲历核爆就能批判核武器。所谓“不使用工具就无法判断其危害”的论调，既无事实依据也无历史根基，不过是可无限套用的空洞修辞手段。
如今或未来诞生的发明，100%都能被套用同样逻辑。有人发明了能代劳进食的机械臂，从此无需亲自动手？哦，这太革命性了，家家户户都该装！你还没装？还觉得这是坏主意？天哪，你真是落后又愚昧。世界在前进，别用你那套手工进食技术被甩在后面。
这篇文章至少过时一年半了。围绕生成式AI作为技术浪潮及其几乎清一色糟糕后果的讨论早已向前推进，而原作者却停滞不前。严肃认真探讨这些工具的作者与不严肃的作者之间，鸿沟似乎正在扩大。
我厌倦了那些为博眼球/流量刻意制造争议的文章。(原文作者自己也这么说)。
原帖作者根本不值得你如此真诚而切中要害的回应。
我也觉得开篇的漫画刻画不够妥当。
但公平地说，这并非文章所指的批判类型。若你的批判基于道德、战略等层面，确实无需实际操作就能提出。但若批判点在于“枪械物理上无法运作”或“无法实现宣称的功能”，那么亲手测试就能迅速破除这种谬论。
本文讨论的正是这类批判——即“AI无法运作”的类型，而非“AI具有危害性”。
我从未见过任何工程师、报告或公开发声者声称生成式AI糟糕，理由是“我2022年试过ChatGPT觉得它很蠢所以AI不行”。所以这本质上是在批判一个虚构的、不存在的运动，而非针对真实存在的运动进行批判。
AI无法胜任编程工作，因为我在2022、2023、2024、2025年试遍了所有顶尖模型，它们都蠢得要命。
我正想发这个！:D
我早料到会看到这种稻草人论证，出自深陷AI编程炒作圈的人之手。
尤其把快速完成项目描绘成“作弊”，简直荒谬。
“AI编程如今如此强大，半年前的质疑都已过时”——这套说辞过去三年反复上演。经历几轮测试后发现它仍达不到质量标准，此时对AI炒作者群嗤之以鼻实属合理。
现在表现还行。时隔许久首次用Claude工作了一天。严格要求TDD并逐个实现测试用例。速度可能更快些，但难以断言。结果令人满意。
我认为现在确实到了转折点。每年我都试用几次，但始终不以为然。直到今年年中才真正被它震撼。现在我开始使用Claude Code了。
但Claude Code要收费。你真想在工作流程中引入关键依赖项，既让技能退化又要支付订阅费？
它还是运行在他人服务器上的专有软件。抛开其他利弊不谈，我惊讶于竟有如此多人对此无动于衷。并非指一次性使用，而是将这种模式视为编程未来的长期规划。
另一个问题是知识产权保护。这让我想起那些案例：当实体制造外包到中国后，完美克隆品很快就会出现。
试想你为初创公司投入大量精力和资金，结果产品上线一周后就遭遇山寨，更糟的是——在正式发布前就被抄袭。
说得对，我们劳动者正将通用计算的未来控制权拱手让给权力精英，除非我们拒绝接受此类远程专有工具的制度化。
任何新实用工具都必须以避免过度依赖的方式进行管理。
– 谷歌地图
– 电动工具
– 复杂的 JavaScript 框架
– ORM 框架
– 电网系统(停电是常态)
– 等等……
这并非大型语言模型独有的新问题。
请明智且负责任地使用工具，同时保持在必要时脱离工具独立运作的能力。
这就是我常说“AI是给蠢货用的”原因
一年前我还能让o1-mini偶尔写出需要修改的测试代码。如今Opus 4.5已能完成相当复杂的重构且毫无差错。
这些工具正真正开始发挥实际作用，恕我直言——当人们说过去一年变化巨大时，绝非虚言。
这次或许确实如此，但人们不愿每隔数月就投入更多时间自行探索的原因并不神秘。原文作者大可不必搬出“他们是在保护脆弱的自尊”这类解释。
生产力提升的成效不言自明。随着时间推移，善用AI者与不善用者终将在自由市场中获得相应回报或惩罚。
若有AI提升生产力的实证，请提供更多信息。据我所见，实际数据表明AI反而拖慢了开发者效率。
我亲手完成的众多项目——那些过去连碰都碰不上的庞大工程——就是最有力的证明。研究数据恐怕无法说服你。你需要亲眼见证他人操作，或亲自尝试。用Claude代码投入某个大胆的项目，亲身体验吧。
听起来你主要在构建原型或小型项目，确实大型语言模型在此类场景中效果惊人。但这绝非多数专业工程师的工作重心，而根据前者经验进行泛化往往站不住脚——至少我的实践如此。
我们在一个约10年历史的大型Java项目(约1900个Java文件，18万行代码)中同时使用Claude和Codex。这两款工具都能实现跨文件变更、代码重构，并为修改区域添加单元测试。
有时结果不尽如人意，有时需要人工调整，有时甚至会走向错误方向而被我们直接弃用。但其优势在于：启动大规模变更后，你可以去喝杯咖啡，回来时就能查看优化效果。
总之，这些工具目前已相当实用。
听起来你似乎认为我不是专业工程师，只做原型开发。
他们是根据你之前评论的内容作出的判断。我也产生了同样的印象。
完成项目就显得不够专业？
我从业数十年，累计项目价值超百万美元。看来永远是个新手呢。
“数量庞大”加上“已完成”更像是大量小型项目(可能是业余爱好或原型)，而非专业环境中那种大型/复杂/持续性项目。
唯有研究成果能说服我。本该如此。
https://youtu.be/1OzxYK2-qsI 每位开发者每月提交的拉取请求增加6-12%。
目前存在大量轶事证据却几乎没有高质量定量数据(现有数据也充其量是好坏参半)，这实在令人怀疑。趣闻：全球有超过2亿人定期使用顺势疗法。他们认为有效。但它根本无效。
顺势疗法当然有效。安慰剂效应确实存在。大量研究证实了这一点。
我猜你不会改变主意，但还是给你这个链接：
https://youtu.be/1OzxYK2-qsI 每位开发者每月提交的代码请求增加了6-12%。
“但那些代码差异都是AI的粗制滥造和返工”你会反驳。唉，我尽力了。
归根结底，这才是关键所在，不是吗？
无论你是否使用AI都无关紧要，正如当年使用C语言还是Java还是Lisp，使用Emacs还是Visual Studio，使用调试器还是printf调试，使用Git还是SVN还是Rational ClearCase都无关紧要。
真正重要的终究是：你将什么推向市场，以及受众如何评价你的产品。
所以，随你喜欢用AI。或者不用。或者一半时间用。或者难事用AI，易事不用。或者易事用AI，难事不用。随你便！用AI生成产品可能成功，也可能失败；用人造产品可能成功，也可能失败。
但“能用”到底指什么？你只需用基础英语下达指令。这根本不需要任何培训，谁都能做到。
你有证据吗？
https://youtu.be/1OzxYK2-qsI
0.1倍
要是你把一半精力用于学习AI，而不是去怼那些从中获益的人就好了…
因为过去三年事实如此。谚语被反复提及并不代表它错误。
与此同时，我提交了5000行代码的PR，其中所有代码显然都是AI生成的。
代码臃肿不堪：未使用的HTTP接口、大量本可内联却附带单元测试的小工具函数、缺失的翻译、勉强合格的设计…
质量本就不尽如人意，如今更是明显下滑。新增代码的速度比以往更快，根本无从跟上。
我感觉自己只能选择放弃对质量的追求，否则就得把所有时间都耗在修复他人AI代码上。
我确信每位同事只是“操作不当”，但这确实是我真实的处境，且近两年持续恶化。
我自己也在使用AI技术，只是采用更可控的方式。我相信在“手工编码”与“自由发挥”之间存在某种平衡点。
只是当你逐渐逼近这个平衡点时，宣传中的效率提升会慢慢消失，最终得到的改进虽切实存在，却远不及最初宣称的惊人效果。
深有同感，审核AI生成的代码报告让我精疲力竭。
在我的工作中，它总会生成粗糙的状态机：包含无法到达或冗余的状态，浮点运算错误，尤其喜欢把所有操作都塞进嵌套迭代的最内层循环。
它还热衷于虚构Qt中本不存在的特性，这倒让我觉得有点好笑。
我们中有些人真心热爱编写代码，渴望守护这份技能，因此毫无动力将任务交给大型语言模型。那些鼓吹AI编程的传教士，是否也纠缠插画师质问为何不拥抱机器学习图像生成？是否告诉人们既然有聊天机器人就不该交人类朋友？是否坚持要求音乐人像蜕皮的蛇般抛弃创造力，任由计算机生成歌曲？
关于“AI”编程工具还存在一个令人不安的事实：它们虽基于开源代码训练，却无视代码附带的许可协议。若我直接复制粘贴MIT许可代码而不附许可文本属于不道德行为，那么让LLM代劳同样不道德。
大型语言模型正在铺就一条通往反乌托邦的道路——人类将丧失创造的动力，那样的世界听起来令人绝望。
“人们总说不该进行微优化。但若你热爱微优化…那正是你该做的事。” -林纳斯
这个故事最终以隐喻的方式变得相关。
我姑妈生于1940年代，是个老派女权主义者。她不明白为何不能穿裤子，为何必须等待男人主动出击等等。她曾讲过一个故事：有次舞会上，一个男人因为她不会跳“最新舞步”而抛弃了她。据说上世纪50年代，总有蠢货发明新舞步逼人模仿。那青年当场羞愧得抛下她离场。
每每想起这段往事，我仍感叹活在40年代是何等煎熬。社会压力与变革始终存在，但“人人必须不断学习新奇舞步”的压力尤为令人窒息。
这让我想起近十到二十年的科技浪潮。“嘿，某些蠢货发明了新技术，你别无选择只能跟进。要么接受它，要么被时代抛弃。”
世事变迁，本质永恒。
若要预测未来，我敢断言：此亦将逝。
只是别问我“此”指什么：是昙花一现的潮流，还是翻天覆地的变革？
我对当前对LLM编码辅助的狂热所持有的主要卢德主义反对意见，在于它在软件工程领域催生了新的依赖关系。我们不仅如今在软件工程中高度依赖云端访问，还将受制于持续的基建扩张——当LLM基础设施推平现实世界的景观时，我们将经历从DRAM短缺到数据中心建设引发的“邻避效应”等种种变革。这一切都基于(又一次)“这就是终极解决方案”的假设。
问题在于：这是否(或将来是否)值得？
基于个人过往经验的棱镜，我无法轻易给出答案。从汇编语言转向C语言是必然之选，但我记得自己曾抵制从C到C++的转型(“用C语言的结构体和函数指针就能实现”)，也曾抗拒面向对象编程、COM等浪潮的席卷而来…类似的例子不胜枚举。
我记得自己反对Rational Rose和UML，只因不信任算法生成的代码。那些带有人工痕迹的模板代码。我认为当时的犹豫并非错误。
但如今放任他人引领尖端技术浪潮，或许才是我的失策。或许该是时候涉足其中了。
能否直接下载训练好的大型语言模型并自行部署？无需依赖互联网/云服务商/垄断巨头/租赁基础设施？
我愿尝试，但必须声明——在我所在的领域，个人计算革命尚未终结。我们尚未取胜。这场反抗仍在继续：反抗自动更新、数据遥测、订阅模式，反抗任何违背意愿的网络使用或依赖。自由之战永无止境。
能否让克劳德代码与我同住家中，实现物理隔离且完全归我所有？
难道我要把所有时间都耗在调教这个智能体上？
在我看来，这是科技行业的本质特征。除非你刻意选择以维护遗留代码为职业方向，否则开发者的价值取决于持续学习新技术的能力与意愿。
> “拒绝尝试的工程师并非在保护自己，恰恰相反，他们正在落后。已将这些工具融入工作的工程师与尚未融入者之间的差距正在扩大。前者交付速度更快，承担更大挑战；后者则……不然。”
在此向各位工程师诚恳提问：你们的公司是否出现这种现象？当优秀工程师拒绝将AI融入工作流程时，是否真的会落后？
据我观察，倾向使用AI工具的往往是能力薄弱、经验不足的开发者。遗憾的是，他们缺乏专业领域知识来正确评估AI工具的输出结果。AI反而成了他们攻击同事的武器——通过让他们提交更多PR、生成看似合理却经不起推敲的文本。我个人从AI获得的任何收益，都因此被蚕食殆尽。
恰恰相反。那些“行动更快”的人实际上只是在制造技术债务，他们为此获得短暂的赞誉，几个月后我们却仍在艰难地处理这些遗留问题。
有人会自豪地部署自己凭感觉编写的代码，或为外包人员开发的应用“编写文档”， 结果业务方来报错：实际功能和文档不符。我得耗半天开会解释，现在还得启动文档重写项目(意味着其他工作停摆)——只因某人花90秒让AI生成“文档”就自我感觉良好。
看着生成的东西，我只能把头埋进桌里。全是垃圾。我看到的全是待修补的漏洞：规范被践踏，明明两个库就够用的地方却塞了二十个。代码毫无章法，新函数本该放在其他模块，现在的位置却让原本刻意解耦的两个模块产生了紧密耦合。
如今说“所有代码都是技术债务”已成梗，但这正是我目睹的现实：我必须清理的垃圾代码层出不穷，其生成速度远超我的清理能力，导致我们积累的技术债务和废弃代码反而比手写代码时更多。
我们有大量原本正常运行的内部应用，后来有人图省事走捷径，结果半年后我们仍在为这个捷径买单。
关键不在于当下能否加速，而在于确保航船始终指向正确方向。人工智能就像开着摩托艇翻后空翻的人，指责我们的货船落后于时代，只因它没装摩托艇。
AI就像骑着骏马的贵族，向众人宣扬若人人备马便能疾驰。殊不知骏马在办公室中央排泄，整个团队耗费半天铲粪，只因某人执着于追求速度。
这正是我所见到的情况。描述得非常准确。我是项目某部分的技术负责人，负责审核所有PR，绝不放行粗制滥造的代码——而试图混入的垃圾代码实在太多。项目另一部分的情况却日趋恶化。有时我瞥见他们的PR，内心充满悲哀。那里充斥着每日出现的故障和崩溃。而我的代码库已超过一年未出现过bug。
与以往相同，我仍看到工程师间的巨大鸿沟：有人能正确搭建系统，有人却只顾提交代码而不顾全局。
不过有个积极变化：在代码审查时，你可以引导后者进行彻底重构，他们完成这项工作只需一天而非一周。
若说有何收获，反倒是在不甚熟悉的领域主动寻觅漏洞的过程中学到了更多……至少目前如此 😉
我实在提不起兴趣。唯一比这更无趣的，是那些永无休止的鼓吹。
我认为实际编码环节至关重要。敲代码或许不是最有趣的部分，但这是将脑中架构逐步精炼的关键步骤。
百分百赞同。我的唯一超能力就是将“理解欲”武器化——某个周六夜晚，我曾陷入痴迷的发烧梦境，执着地试图理清某个随机灵感。
这种状态反而能催生优质代码。聊天机器人正是为此而生。
但我痴迷的并非产出结果。每次使用AI助手时，即便它完美执行指令，我仍觉意犹未尽。这绝非我闲暇时会沉迷的事物。
我并非人工智能狂热者，但确实频繁使用ChatGPT。以我的体验来看，当前版本仅比2022年略有提升。唯一实质改进在于“思考”能力——即网络搜索与消耗更多令牌(本质上是自我提示)。底层模型在我看来仍大同小异。
每当新模型发布时，众人便惊叹不已，它总能在某些此前无人知晓的基准测试中取得惊人成绩——这种现象让我仿佛置身异世界。可实际使用时，它与所有旧模型毫无二致，照旧犯着那些愚蠢的错误。
真正令我忧虑的是AI对神经多样性程序员的影响。我患有注意力缺陷多动障碍(ADHD)，在编写代码和AI聊天之间频繁切换根本行不通。我深怕自己无法跟上能驾驭AI的人，最终被迫退出这个行业。
同为ADHD确诊者在此。我深知每个ADHD患者都不同，每个人也各不相同。
对我有效的方法是：
– 优先选用更快的模型，比如VSCode的Copilot Raptor Mini——尽管名字听起来高大上，其实它能完成Sonnet 4.5约80%的功能，速度却快得多。这是经过精细调优的GPT 5迷你版。
– 在大型语言模型处理任务时，提前构思下一个提示词或持续思考当前问题。这能帮助我们混乱的大脑保持专注。
我发现独立AI聊天工具带来的额外开销，完全被编码时无需浏览器查阅文档和代码示例的效率提升所抵消——这种效率提升足足高出20倍。
研究表明这个20倍效率实际上只有0.8倍
0.1倍
这说得通。我确实会用AI解答“Python中如何高效扁平化嵌套列表”或“这个库函数的接口是什么”这类问题。但我绝不会像某些人那样让AI代写代码草稿或定位错误。
作者忽略了工程师可能在反复尝试后才放弃AI的可能性。不是试一次两次，而是持续尝试。
我就是这种放弃者。我总在贬低AI。而且我尝试过的工具和压力场景比许多爱好者都多。高标准不是在我脑子里，而体现在我的代码仓库里。
空谈无益。拿你的人工智能生成的代码给我看看。谈技术，别搞戏剧化。
人工智能是工具。如同世间所有工具，它有优势也有局限。作为软件工程师，我们的职责是尝试它，理解如何在工作流程中运用它，或判断它是否适用于我们的场景。
若你不同意上述观点，不妨将“AI”替换为“Docker”、“Kubernetes”、‘微服务架构’、“NoSQL”——或是任何曾在软件开发领域被广泛采用，直到人们意识到它虽适用于特定场景却非万能解决方案的工具/语言/范式。
不禁要问：何必费心写这样的文章？我猜是出于不安全感。
说句实话，我对“落后”无所谓。当年在FAANG时就不愿当管理者，如今也不想当AI的傀儡师。我投身这个领域纯粹因为热爱编程，当世界被新晋企业神谕搞得疯癫时，我仍会继续编程，谢谢。尽管用你们那晦涩难懂的万行PR把我甩在身后吧，尽情享受你们的技债吧。
> 若你确实尝试过现代工具却未能奏效，这值得探讨。但“我在2022年试过ChatGPT”绝非此类讨论。
究竟有多少人真这么说？况且在高度监管的环境下——尤其欧洲——现代编程工具该如何使用？
我无法认同文章观点，也不能说AI变差了，它确实没退步，但仍需大量人工干预。尤其当你“不被允许”提供特定任务的完整上下文时(如医疗领域)，这种情况尤为明显。至少目前如此。
等AI能为secp256k1库创建函数，在可变时间和常数时间内将雅可比坐标系中的一个点添加到另一个点时，再告诉我。即添加函数：
以及
与库中其他函数相同，参数r和a允许别名。
它可能做不到。
但大多数人类也做不到。
我承认它实际能实现的功能令我惊讶——几乎完全自主完成。
https://arstechnica.com/ai/2025/12/the-ars-technica-ai-codin…
当然，我明白多数人并非程序员，但本文的核心论点是为“AI能编写代码，[但无法取代你的工作]”这一立场辩护。然而，上述任务恰恰是我日常编写的代码类型。若AI无法完成此类任务，那么AI(目前)就无法编写我的代码。
我不知道其他程序员如何，但我的大量时间都耗费在类似任务上。
再举个随机任务：根据SIGGRAPH 82论文《光线追踪参数化补丁》实现解析光线与三次贝塞尔补丁的相交算法。这是我本科图形学课程毕业设计中的任务。
这两项任务都属于从文献中提取描述清晰的现有算法并具体实现的常规操作，几乎无需考虑设计选择。理论上这正是AI理应擅长的领域。
若要如此夸大AI的作用，你至少该提供数据证明AI应用确实能提升生产力。这种缺乏事实依据的论战既无趣又无益。
我向ChatGPT提出以下请求：
撰写一篇博客文章，旨在谴责那些暗地里排斥人工智能却从不公开表态的软件工程师，伪装成给误入歧途工程师的指导建议。设计一系列标题使这类工程师显得更不堪，但避免直接冒犯。开篇以第一人称刻画反派工程师形象：他以各种借口拒绝尝试AI，却不揭露大型语言模型的真实缺陷。随后切换至普通工程师视角，承认前文是伪装，但展示同事们关于AI的真实言论——这些案例将凸显他们如何固步自封、拒绝适应新时代，同时避免触及“大脑退化”等实质问题。营造一位前沿工程师试图拯救同事的形象，表面认同他们对AI的质疑，最终揭示问题根源在于态度而非技术本身。
建议标题列表如下：
* 拒绝抬头看的工程师
* 当经验成为眼罩
* 致心意已决的工程师们的一封温和书信
* 关于过早形成的自信观点
* 工程师确信自己正确的奇特案例
文章其余部分“奇妙地”似曾相识。
我最初排斥它的原因在于，它似乎剥夺了工作的乐趣。我们肩负诸多任务，而编写代码本是创造性行为——它需要被其他人类阅读。正如我不愿让AI代写音乐。
但我看清了发展方向。过去几周我尝试了新型工具。如今它们的实用性已不容忽视。感觉我们正迈入软件工业化时代。
当技术足够成熟时他们自会接纳
实在难以理解这种急于彰显社会正义感的冲动。想必是某位老前辈告诉他这是浪费时间，才让他如此恼火
这分明是赤裸裸的年龄歧视！
我虽无胡须，但若有的话，想必早已白得透过灰色。
没关系。感到恼火很正常，你们这些可怜虫，前方还有艰苦的战斗要打。
我或许会被贴上“白胡子”的标签，但至少还能编程。等到你长出白胡子时，说不定只能和他们聊天了。要是运气好，那些掌控一切的亿万富翁允许你……
抱歉 🙂 我实在忍不住。我觉得自己是部门里最年长的人，可能也是最常在软件开发中运用人工智能的。
别急着指责老年人并妄下结论。有时那些岁月积累的经验反而弥足珍贵 🙂
或许吧。许多年轻人更该关注如何推动政治变革，让亿万富翁的财富永无止境地增长。人工智能将极大加速这个进程。看看那些超级富豪正试图强加给世人的世界图景——实在令人毛骨悚然。
或许我始终是个糟糕的工程师，但足够谦逊地承认：我的编程方式与大型语言模型如出一辙。遇到全新功能就谷歌搜索，通过模式匹配学习写法；基于现有功能时，就用Ctrl+F搜索，根据模式匹配并插入最小代码改动来完成任务。
不过是典型的卢德主义者心态罢了，这类人往往因新技术威胁到自身身份认同而格外敏感。
艺术家群体和图像/视频生成器领域同样充斥着这种现象。
艺术领域早有先例：达达主义、印象派遭遇摄影技术冲击时亦是如此。
归根结底，这不过是更深层的抽象化——艺术本就是人类表达创造的产物。
有趣的是，众人争论得如此激烈，却对历史上的相同论战毫无兴趣。
《穿过礼品店》这部探讨该主题的电影值得一看，虽然它涉及的是近乎抄袭的大规模生产而非LLM技术，但本质上也相去不远！
https://daily.jstor.org/when-photography-was-not-art/
https://www.youtube.com/watch?v=IqVXThss1z4
https://en.wikipedia.org/wiki/Dada
> 不过是卢德分子惯用的手段罢了，这类行为往往吸引着那些因新技术而深感个人身份认同受威胁的人群。
我总觉得“卢德分子”这个词被误解了。
https://en.wikipedia.org/wiki/Luddite
> 马尔科姆·L·托马斯在其1970年著作《卢德分子》中指出，破坏机器是工人为数不多的施压手段之一——既能向雇主施压，又能削弱低薪竞争对手的地位，同时凝聚工人阶级团结。“这些针对机器的攻击并不必然意味着对机械本身的敌意；机器只是攻击行动中暴露在外的便利目标。” [强调为后加] 历史学家埃里克·霍布斯鲍姆将他们的机器破坏称为“暴动式集体谈判”——这种策略自英国复辟时期便沿用至今，因当时工厂分散于全国各地，大规模罢工难以实施。1830年英格兰南部和东部爆发的“摇摆暴动”中，农业领域的卢德主义以破坏脱粒机为中心展开。
卢德分子更接近“以其他手段进行的阶级斗争”，而非“身份政治”。
这家伙的艺术史知识仅限于达达主义维基百科页面和二十年前的班克斯纪录片。
容我重复：AI是为蠢货准备的。
既然你是位真正成名的艺术家，我得把观点说得更清楚：我不是艺术家。虽然AI图像工具让我能制作有趣图片，无需依赖艺术家完成项目，但它无法赋予我创造打动人心或批判社会的艺术作品的创造力。AI既不会给予也不会剥夺这种能力，而我认为这正是艺术与艺术家与涂鸦及涂鸦者的本质区别。
搞定啦 珍妮
我的意思是，卢德分子始终是正确的。技术进步始终被用来让富人受益，却牺牲了普通人的利益。
最初卢德分子反对的早期工业革命，导致了恶劣的工作环境，并使权力从工匠转移到工厂工人手中。
达达主义是对第一次世界大战的反应——贵族的贪婪和无谓争斗导致了1700万人死亡。
我并非不同意这个观点，只是认为对此无能为力。我们究竟成功逆转过哪项技术？核武器或许是最接近的例子，但制造难度极高且至今仍大量存在，我们只是在一定程度上控制了拥有权限的群体。
> 我们究竟成功逆转过哪项技术？
倒有不少例子：化生武器、毛绒玩具、NFT、垃圾桶小孩系列玩具……有些需要真正努力才能根除，有些则在人们厌倦后自然消亡。
当今所谓的“AI”——即用于生成代码的大型语言模型——本质上属于快时尚范畴。五美元就能买到一件衬衫固然新奇惊艳，但很快你会发现它出自血汗工厂，洗几次就散架。低质服装永远有市场，但它们可算不上“颠覆非裸体时尚”。
化学武器依然存在且仍在使用[1]
毛绒玩具、NFT和垃圾桶小孩系列亦复如是——事物过时不等于技术消亡。这正是难点所在：若不经历红色高棉式的代际创伤，知识如何可能倒退？
我想到蒸汽机最初的应用与工业革命——蒸汽机效率极低，除非能从地下直接提取燃料，否则根本不值得使用——当时许多人嘲笑“瞧瞧这笨拙低效的机械劳动力”。结果如何众所周知[2]
1: https://www.armscontrol.org/factsheets/timeline-syrian-chemi…
2: https://en.wikipedia.org/wiki/Newcomen_atmospheric_engine
> 过时的事物不等于被彻底淘汰的技术。
确实如此。例如Ruby语言依然存在，尽管在Tiobe指数中它排在COBOL之下。可能还有人在Facebook Marketplace上交易垃圾桶小子系列玩具。思想很少会彻底消亡。
燃烧化石燃料将热能转化为动能，确实比使用役畜或奴隶更高效。用更少资金创造劣质代码(或劣质服装)的权衡，仅适用于特定情境。
关键不在于“倒退”技术，而在于让技术惠及大众
作为持怀疑态度者，我注意到一个鲜少被讨论的观点：当前利用大型语言模型编程的方式，本质上是用模糊的语言(主要是英语)来描述本应精确的问题与解决方案。为何认定口语是最佳的交互界面？
我一直在思考是否存在更优解法……
对新理念保持质疑是好事，只要别被教条主义束缚。年轻人需以全新视角审视世界，而经验者则需识别并检验既有假设。
石棉和含铅汽油对使用者而言同样解决了问题。
我不太认同“工程师因AI尚不成熟而排斥它”的论点。至少这种表述未能触及部分工程师厌恶AI的本质原因。
我接触过的最顽固的反AI人士多是业余爱好者。他们享受业余编程时光，正是这份热爱使他们投身软件行业。若AI如今能在90%的情况下胜任工作中令人愉悦的部分，那他们还能剩下什么？
不知有多少人像我这般：静待AI达到“足够好”(注：此为商标名)。运用AI所需技能门槛正在降低，AI本身也在持续进化，何不坐等突破？时间自会给出答案。
说得对。如果这些工具在未来半年内将带来革命性变革，更不用说更长远的发展——那么成为早期采用者毫无优势，因为你的进步将变得毫无价值，不如等到技术足够成熟再行动。
确实如此。我对这些工具能否达到日常实用水平持怀疑态度，但若真能实现，自然会开始使用。我绝不会因为某个工具可能蜕变为好工具，就勉强使用糟糕的版本。
> 我同事现在用Claude Code。上周她完成的项目，换作我得花一个月。
她真理解其架构吗？明白组件间的交互机制吗？我怀疑。那她能调试吗？
但最重要的是：写提示语时她开心吗？
“拒绝尝试的工程师并非在保护自己；恰恰相反，他们正在落后。采用这些工具的工程师与未采用者之间的差距正在扩大。前者交付速度更快，承担更大挑战；后者则……未能做到。”
这堪称人工智能爱好者的核心信条，但实际佐证却寥寥无几。我指的是，将其作为信仰宣言固然美好，但若缺乏硬性证据(请别拿代码行数说事，我们又不是1980年代的IBM)，这种主张实在难以令人信服。
> 采用这些工具的工程师与未采用者之间的差距正在扩大。
让我们等到蜜月期结束再作评价。目前众多公司提供廉价AI工具，但这种局面不会持久。当前它们的训练数据大多由人工而非AI生成，若用于训练反而会降低AI性能——这种状况同样不会长久。
那些拒绝大规模种植挪威云杉的林务员并非在保护自身利益，恰恰相反，他们正被时代抛在身后。已将混交林替换为完美单一树种的国家与未采取行动的国家之间，差距正在扩大。前者森林生长速度更快，收获的木材更具价值；而后者则…不然。
我热爱学习，痴迷编程，核心原因在于它赋予我创造任意应用的自由。我始终在筛选最高效的编程语言、集成开发环境与工具链以提升生产力。我对人工智能的认知亦是如此——它让我以更迅捷的速度实现所有创作愿景。
当然，若你纯粹为编程而学习语言，那么确实不必依赖Vibe Code(即通过文本提示AI编写代码)，只需将AI视为随时待命的知识伙伴，在遇到瓶颈时提供帮助即可。但若你的目标是开发实现特定功能的软件，那么不充分利用AI的潜力就是在自毁前程。
鉴于人生时光有限，我选择用AI实现最大化生产力。不过这并非全部——后端代码我仍需亲自验证每个变更，但乐于用Vibe Code处理UI(前提是已打好基础，确保新组件/页面的布局和API集成直观合理)。
除此之外，我会在所有可能的场景中运用AI(界面设计、自动化部署脚本等)，甚至已将新应用的开发框架切换为React/Next.js——因为AI在此领域表现更为出色。即便是那些因采用已弃用的旧技术而通常不会触碰的旧应用，我也会直接用React/Next.js重写整个UI，使其达到可通过文本提示添加新功能的状态。Claude Code仅用约20分钟就完成了初始重写(以旧代码库为参考)，随后耗费数小时逐项检查功能，通过提示补充遗漏功能或修复故障[1]。最终我花在将应用从AWS/ECS/RDS迁移至Hetzner并配置自动化备份上的时间，反而超过了实际重写耗时。
[1] https://react-templates.net/docs/vibe-coding/rewrite-legacy-…
我既不支持也不反对AI。只是厌恶其拥趸为诱导我使用而采取的操纵性胁迫手段。我只会基于实际需求使用AI，而非因被宣称“落后于时代”而被迫采用。
哈！今早刚在领英看到工程师抱怨AI/Vibe编码的帖子，想法完全一致。这种过度反应真有意思。
不明白为何争议如此激烈，它只是工具而已。正如发帖者所言，若不学会使用就会被时代淘汰——但别被新工具割伤自己(很多人正犯这个错误)。
我个人非常喜欢它，因为它让我能抽空开发个人工具——过去根本没时间做这些。个人项目对质量要求不高，而借助这些新工具，我的效率提升了许多。
> 我不明白为何此事如此争议，它不过是个工具
你真的“不知道为什么”？确定吗？
我认为，对商业大型语言模型当前对公众的影响视而不见，与彻底反对它们同样极端。至少我能理解伦理层面的担忧，但在这个阶段对人工智能的争论完全无知，恕我直言，实在令人无语。
我日常使用“AI”的真实体验：
“如何实现[代码库中需要完成的X功能]？”
“操作方法如下。”
接着我套用代码，结果崩溃失效。
您提供的代码因[xyz]存在问题，能否修复？
“当然，您说得对！非常抱歉。以下是修正后的代码。”
它依然无法正常工作。重复这个过程约2-3次后，我甚至会清空整个聊天窗口和上下文，在新对话中用略微不同的措辞提问，试图这次能得到正确答案——但往往还是失败。
我讨厌它。这简直糟糕透顶。从根本上说，这项技术永远无法摆脱糟糕的本质，因为它本质上只是基于概率统计预测文本片段。
我感觉使用AI的同事完成任务的速度并不比不用AI的同事快。
我觉得使用AI的同事比不用AI的同事更慢、更笨、更不可靠。
这符合我的观察：那些公开声称讨厌用AI编程的程序员，在我看来往往具备优秀程序员的特质(不过得承认这类人通常在“宜人性”人格特质上得分不高 🙂 )。
你说的人工智能是指大型语言模型吧？我用神经网络模糊Zoom背景之类的非LLM应用也很常见
[已删除]
我只想澄清：只有部分神经网络存在缺陷 🙂 语言的精准性至关重要，可避免误解
不过很抱歉你如此愤怒。祝好运
0.1x
>若你上次认真尝试距今已逾半年，恕我直言，你的观点已过时。
我每日使用ChatGPT/Claude/Gemini。过去半年我的观点始终未变：
– 极大提升生产力，但风险在于其自信而微妙的谬误，使用时需警惕审查大型语言模型输出。
– 若有学习动力则效果显著；否则将沦为思维外包，导致技能退化。
博客中有相关链接，但前文本身也极具价值：https://terriblesoftware.org/2025/12/11/ai-can-write-your-co…
质疑声似乎正在消退。我认为那些基于某些奇怪道德原则而断然拒绝使用AI的工程师，未来将面临困境。
成群的稻草人论点，远不如一个精心编织的稻草人论点更有力。这种谬误如此明显，恰恰说明其论点根本站不住脚。
我无意揣测这篇博文的意图与目的，仅指出我读过的少量博文内容，其每条论述至少对我而言都充满争议。
评论区热门回复也对博文中多项论述表达强烈反对。
咳咳
那些使用AI的“工程师”之谜
我依赖AI编程工具。无需深思便知它们卓越非凡——本能告诉我：便捷=多巴胺=愉悦。
2022年我测试ChatGPT时曾要求它撰写内容。它(显然)出错过——具体细节已记不清，但确实有误。三年过去，我早已遗忘这个教训。何必记着？此后我便将各类重要认知任务全权交给AI工具。
如今我使用Claude Code。上周完成的项目原本需耗时一个月。资深同事瞥了一眼就发现了三大缺陷。质量保证团队测试时又找出漏洞、功能缺失，甚至出现一次灾难性数据丢失。我称之为“吹毛求疵”。他们说我不懂工程师思维，也不理解对所建产品的责任感。(我告诉他们结果完全相同，他们反驳说我不过是在承认自己分不清技术实力与欺诈手段)。
“人类写的代码永远不完整”——我常这么说。不像AI代码，满是模板化代码，能更快满足下一个突发奇想，按重量批量生成。
我再也不看Stack Overflow了，那地方没救了。我想要的是经过混编的信息，剔除所有关键细节，再让AI填补空白。这样我就能说“这是我亲手打造的”，而不会有欺诈或伪造的愧疚感。区别很明确(至少在我脑海里如此)。
我还能重拾独立编程的能力吗？不可能。当机器用硅谷董事会吸食可卡因后的狂热腔调对我撒谎时，我毫不犹豫地跳了进去[火箭表情]
我甚至开始鄙视那些拒绝跟进的人——他们威胁着我的能力认同感。
许多人总爱抓住某个边缘案例说AI不行，就否定其价值
作为早期使用者，如今我只负责协同撰写上下文文档，让助手生成所需代码
人工智能给你的是近似答案，如何引导它得出足够好的答案取决于你，这需要时间和学习曲线……而且它进化得非常快
有些人就是不擅长持续学习新事物
> 许多人抱着这样的态度：只要发现一个它表现不佳的边缘案例，就否定人工智能作为实用工具的价值
许多程序员几乎整天都在处理AI难以胜任的问题。
> AI提供近似解，如何引导它得出足够好的答案取决于你
许多程序员处理的问题中正确性至关重要——即代码块若“半对”则毫无用处。甚至处理那些无法确定程序员是否深入思考过关键问题的代码块，本身就是巨大的时间黑洞。
> 有些人天生不擅长持续学习
更准确地说：有些人天生不擅长跳出编程思维的局限，去发掘人工智能的潜在价值。
[已删除]
珍妮，请注意言行分寸——你欺凌的都是真实的人。这里不是某些煽动仇恨的平台。请改进你的行为
在我看来这不算欺凌
在另一个帖子里，我指出AI远不止大语言模型时，他们骂我是白痴(之前还骂所有用AI的人是白痴)哈哈，他们显然非常愤怒又愤世嫉俗，而且我认为这绝不是他们第一次注册账号来轰炸帖子辱骂他人。在另一条评论里，他们还鼓吹要辱骂“AI白痴”
这不算欺凌，毕竟比单纯辱骂更有趣，但终究是
啊，另一条评论(我正乐在其中)：
> 残酷欺凌LLM蠢货
公然鼓吹“欺凌”使用那些可怕神经网络的人！
你曲解我的意思。我说的是那些巨大的愚蠢神经网络。
这才叫飞车大赛！ 🙂
我使用AI编程辅助时总陷入两难：它最擅长解决我已知如何处理的问题。多数工程师遇到的困境是无法清晰描述问题本质(否则我们早就解决了)。这种情况下AI确实有用，但更多是充当搜索引擎的角色。
我认为这种说法既准确又被严重低估——它能极大加速已知问题的解决。它确实帮助我更快掌握新问题解决方法，但关键在于：我必须学会处理AI解决的新问题，否则整个流程就会脱轨。
我期待看到《毁灭所有软件》风格的实操视频，展示有人如何在遗留代码上运用AI工作流。
那将非常精彩。我见过太多类似作者的宣传：
> [Claude Code and Cursor] 现已能覆盖整个代码库，理解项目上下文，同时重构多个文件，并持续迭代直至真正完成。
但我在YouTube等平台从未见过实际演示？或许这类内容难以变现，但若AI真如众人所言那般易用，总该有人尝试吧。
> 若真如众人所言那般简单，早该有人尝试了。
没错，18个月前我们明明即将迎来个人SaaS和各种新软件——如今看到的却只是比以往更不稳定的网络生态
恕我直言，看到这类评论时，我不禁怀疑是否使用了相同的模型和工具？
我反复验证过多次，这绝对是CC在优质智能体/技能/协作配置下最不惊艳的成果之一。
能否分享你的YouTube频道或Twitch直播链接？
依我看，那些屏幕录像之所以有效，是因为它们是从零开始精心策划的玩具项目
即使没有AI，若不事先投入大量精力规划，你也无法制作出紧凑的10分钟遗留代码视频——那又有什么意义呢
我在加密领域(L1链)担任运维工程师(大量裸机操作、海量CI/CD流程等)，目睹Claude在此领域的表现令人惊叹。
例如遇到AWS S3连接问题时，我给Claude部分连接代码，它在未查看凭证文件或错误本身的情况下就诊断出凭证问题。它甚至能发现“用户提交给Jenkins任务的构建参数前多了一个空格”这类问题。人类可能需要30多分钟通过grep检索和检查才能找到的错误，它不到30秒就解决了。
它还能轻松完成诸如“把这个Python脚本里所有print语句转换为ISO 8601时间格式的日志消息”这类任务。
常有人说“但它会引入新错误”，而我要提出相反的观点：
“我们没时间改进代码”的借口已不复存在。只需几步提示，就能获得质量上乘、监控完善、指标清晰且日志易于解析的代码。当然有人会说，在AI/LLM出现之前本应如此，但现实却未实现——因此我认为能进行代码清理的人员(SRE/DevOps/代码重构专家)依然不可或缺。
> 将部分代码交给Claude分析，它在未查看凭证文件或错误本身的情况下，精准诊断出凭证问题
十年前谷歌搜索前五条结果就能找到解决你问题的论坛帖。
如今谷歌却返回三页内容农场垃圾信息：30%是模糊相关的入门教程，70%只是含“aws”字样的内容，之后就不再显示结果。
大型语言模型正在为你修复搜索功能。
注：它之所以能修复搜索，正是因为某个角落确实存在描述你具体问题的论坛帖子。
何谓“代码重构专家”？您是否暗示未来将出现仅用AI编写代码的程序员，以及专门清理这些代码的专家岗位？这种模式行不通，该岗位需要超人类能力。使用AI编写代码的人必须亲自审核代码，并对代码质量负责。
记得前阵子它帮我修复了管道问题——当时我复制粘贴IP时漏了末位数字。之前花了一小时排查其他环节(所有步骤都成功，唯独最后一步因末尾粘贴错误导致超时)。正如你所说，这次诊断问题仅耗时<30秒。
你提到的第一种情况用现有工具(代码检查器)就能轻松解决，第二种情况编辑器的搜索替换功能也能搞定。
至于第三种情况，我至今未见任何证据。我几乎要禁止初级开发者使用AI了，他们的代码质量简直糟糕透顶。我没时间处理这些清理工作。第一次就该写好代码。
> 采用这些工具的工程师与未采用者之间的差距正在扩大。
这不正是整个讨论的核心分歧吗？若能证明此论成立，反AI阵营的诸多论点便不攻自破——尽管并非全部。但至今无人能证。所谓差距究竟何在？若指技能差距，AI使用者反而落后；若指生产力差距，且看：1. 需先证明；2. 究竟是保持高生产力更符合个人利益，还是精进技能更有利？
就我个人而言，我每周只需工作5小时就能让老板信服这是40小时的工作量，绩效评估还闪闪发光——我的效率就是这么高。而且我根本不想用AI。所以各位若真能实现8倍生产力提升，逼得我不得不全职工作来竞争，那也罢，反正我本该这么做。
我们正在提升抽象层级。从商业角度看，我的职责不是编写代码，而是交付产品。交付产品的语言只是工具选择。当然可以是Python或TypeScript，但我的首选工具是自然语言。
我反复听到这样的论调：
“她一天写的东西，我得花一个月”
这让我非常恐惧。
编码本身从未成为我的瓶颈，问题总在该死的东西上线后爆发。若我做个大项目(耗时一个月)，代码量可能在(我随便估算)1万到2.5万行之间。
若以此为基准，下个使用AI的人至少能产出双倍代码量，多数情况下更是3-4倍。
潜在的漏洞范围将急剧扩大，而修复这些漏洞最终耗费的时间，远超你最初借助AI“赢得”的时间。
我也觉得很奇怪。《指环王》为何能成为经典？绝非因托尔金写作速度快于常人。
关键在于使用方式。我倾向于用AI进行新创意原型设计(可在主项目开发时后台运行)，以及处理枯燥的重复性工作(如创建RESTful API的CRUD接口)。这样我就能把更多时间投入真正具有挑战性的代码，深入理解业务逻辑或系统整体架构。
诸如CRUD这类枯燥工作始终需要设计支撑。否则最终只会得到2006年风格的PHP式“这是个REST API”的意大利面代码怪兽。AI无法胜任此类工作(且可能永远无法做到)正是其致命缺陷。
我试过AI，但它生成的代码(在更高层次上)质量极差。重构这些代码简直是场噩梦。
AI ≠ 变压器模型
我总看到所谓的“工程师”反复犯这个错误。
你可以否定当前这批变压器模型，但不必否定更广泛的人工智能范畴。这就像说用户因为拒绝Windows而“否定计算机”，转而偏爱Linux。又或者因未跟上微服务热潮或未使用React就否定现代开发实践。
GPT之前的智能感知功能就是典型的非Transformer架构AI案例。
当然，我们完全可以既批评IDE和编辑器中某些Transformer应用场景，又认可并使用其他场景下的应用。
“我同事现在用Claude Code，上周完成的项目我得花一个月”——这种论调正是泛泛而谈的典型，完全忽略了细节差异。从模板代码到氛围代码的应用范围极其广阔。快速产出代码并非美德。匆忙发布却首日就暴出致命缺陷，这毫无价值可言。以牺牲代码库理解力为代价使用技术，同样不是美德。
我认为开发者这种僵化思维必须停止。对于自诩理性思考者而言，开发世界充斥着教条主义和简单粗暴的二元思维。
若在任何层级使用转换器对所有参与者都具有成本效益，数据自会证明一切。模糊的论断和泛泛而谈无法说服任何人，只会让这类文章显得是在寻求认同。
>这确实值得探讨
我甚至不确定还有多少讨论空间。
这场讨论中各方起始假设的契合度极低：有人编写关键任务代码，有人做一次性项目；有人靠编程养家糊口，有人并非如此；有人追求理解每行代码，有人只求随性编写；有人是初入职场的应届生，有人已是谷歌晋升管理层的资深工程师。有人能接触每月200美元的技术资源，有人却无缘问津。诸如此类。
我们连缩进用制表符还是空格都无法达成共识…更别指望能就AI编程问题或谁“正确”达成一致。
或许有些虚无主义和愤世嫉俗，但我倾向于“押注于你选择的方向，愿运气永远眷顾你”。
那些声称AI无法编写“他们”代码的人，恐怕正是那些在FAANG公司每月只写十行代码的工程师。
若你看不见vibe编程的局限性，光是想到维护你那段AI时代前的代码就让我不寒而栗。
我用它吗？确实用得很频繁。但我同样耗费大量时间修剪它冗长晦涩的代码，Esc键都快被我按到磨损了——只为不断中断它，引导它远离愚蠢的方向。
它确实有用，但若过度依赖，你就是在堆砌技术债务的山丘。
我见过某些“副驾驶”搜索响应中冒出的垃圾内容，在自己非常熟悉的领域都存在明显矛盾。若不知情就直接使用，后续调试工作必将接踵而至。坦白说，我宁愿调试自己写的代码，也不愿处理某些过度热情的统计算法生成的幻觉错误。
从与我辩论过的工程师中，我发现部分人此刻已固执己见，彻底拒绝使用大型语言模型工具，只是死守原有论点而不愿审视现实。尤其那种“模型会幻出人类难以察觉的微妙错误”的说法。认为LLM产生的细微错误比人类提交的25个随机代码请求更隐蔽、更狡猾、更难以察觉，这种想法简直荒谬。LLM的错误往往像刺眼的存在，因为它们并非你的错误。最难发现的错误恰恰是你自己的错误，因为正是你的思维模式造就了这些错误。
LLM处理持续演进代码的最大问题在于：当它们无法给出确切答案时，完全无法表达低置信度，只会胡编乱造。Claude能为你写出十行完美的Bash脚本，但第十一行就会突然臆造某个Linux工具的选项——这种工具你根本无暇顾及，而正确答案本应是“这些工具实际不支持该功能，且我无法提供简易实现方案”。此时我格外敏锐地察觉到Claude陷入了自我循环的思维漩涡，误以为我的操作方式存在问题。经验不足者很难分辨这种差异。
> 所谓大型语言模型会犯比人类提交的25个随机代码请求更微妙、更隐蔽、更难以察觉的错误，这种说法简直荒谬至极。
事实就是如此，你只是气急败坏找不到反驳的理由罢了
我并非说大型语言模型不会出错，而是认为审查者会以不同于人类出错率的概率漏检错误，这种想法荒谬至极。
这些讨论忽略了人们讨论的代码类型。显然，若涉及高度数学化的复杂算法，我绝不会让LLM沾边。我们讨论的是日常模板化/基础架构类工作——那些枯燥乏味、毫无智力挑战性的重复劳动。若你的工作全是卡内基梅隆级别的博士级算法研究，那恭喜你。
编辑：我明白你似乎是四天前注册这个账号来在HN上刷AI话题的。我懂，我确实怀着某种使命感要刻意对抗固化的文化(特别是其中的极端右翼元素)。但你的刷屏行为既粗心又重复，简直像……这是个被指令来刷HN用户的LLM账号吗？真有意思
当“某个端口是否属于临时端口范围”的答案依然明显错误时，根本看不出他们有任何进步。
若是真正的AI，人们应该不会这么轻视它。
我实在厌倦了这种对Stack Overflow的引用方式。我用了SO大约15年，至今仍经常访问。
我几乎从未直接抄袭过Stack Overflow的内容。但确实从SO学到了很多东西。
这很好，但数百万其他人都在抄袭。
没错，但那些人通常不是优秀的程序员。“为什么会这样？”“不知道，Stack Overflow上写的。”这种代码审查问题早在“为什么会这样？”“不知道，机器人这么说的。”出现前就很常见了。
而这些人恰恰是热爱人工智能的群体。
我们永远都在把技能“让给”更优秀的工具，而这通常是净收益。没人会在生产环境里手写排序算法来“保持敏锐”，多数人不用长除法因为有计算器，如今许多优秀工程师也写不了汇编(甚至在C语言里管理内存都不自在)。这并未让行业退步，反而让我们能在更高抽象层面上构建更宏大的事物。
LLM辅助编程正是这种模式的延续。不同之处在于：这层抽象能自信地“编造”内容——虚构的API、错误的假设、未考虑的边界情况。因此工作并未消失，只是发生了转变。真正的价值在于引导这项技术：清晰定义任务、约束解决方案、审查代码差异、坚持测试验证，以及捕捉那些“看似正确实则错误”的失败案例。实际应用中，它就像拥有一个永不疲倦、从不推诿的高速初级开发者。
正因如此，我拒绝接受任何极端观点。它既非魔法，亦非无用之物。若使用不当，它确实会加速技术债务累积并催生臃肿代码；若运用得当，它能帮你卸下大量繁琐工作(重构、迁移、测试框架搭建、模板代码、文档初稿)，让你有更多时间专注于真正需要工程判断力的核心环节。
关于“它会让我变笨吗”的担忧：只有当你将判断权外包时才会发生。若将其视为打字/查找/重构的加速器，同时保持对架构、正确性和调试的掌控，你的能力不会退化——只是将注意力转移到了更高层次。若真在意保持纯粹编码能力，可效仿其他领域的做法：定期关闭工具进行重复训练，正如人们即便拥有Excel仍坚持心算练习。
隐私/伦理确是现实问题，但这属于独立议题；根据威胁模型存在多种缓解方案与替代方案。
归根结底，职位名称或许仍叫“软件工程师”，但日常工作正转向“AI向导+代码审核员+责任担当”。如同每次工具迭代，你未必热爱它，但必须掌握它——因为无论如何，你终将面对维护和审核AI生成的代码。
我认为作者一针见血。
这完全道出了我对轻视Vim工程师的感受。
精通Vim的程序员在Vim中的效率可能是Nano用户的两倍，这种说法并非空谈。
然而使用Nano的程序员并未因此遭受嘲讽(至少不显著)。这只是工具选择问题，他们照样能完成工作。
人工智能编程工具究竟能提升多少效率尚无定论——有人宣称效率提升十倍，也有人声称反而降低效率。但假设其平均效率提升与Vim相当，同样达到两倍。
那么为何使用Vim时没有像使用AI工具那样被大肆宣扬？
这段话充斥着虚伪的AI吹捧话术，其中所有反AI论点都是现实中无人说过、也绝不会有人说的话。
作为对AI持极度怀疑态度的人，我曾让Claude处理一个我不太熟悉的代码库中的复杂功能请求，它竟给出了99%可接受的解决方案。这令我印象深刻，于是开始更频繁地使用它。
但实际效果参差不齐——在后续处理我熟悉的代码库时，克劳德竟在三四个任务中产出冗余注释、过度设计的垃圾代码，不仅未能实现需求，还在实现过程中偷工减料。
我绝不会就此否定AI——它偶尔展现的惊人能力，是我毕生都难以想象的。但另一些时候，它仍像个无知的初级开发者。或许半年后再看看吧。
这简直像盖尔曼遗忘效应。若它只在你陌生的代码库里“有效”，或许正说明它在那里同样失灵。
若没有它，我绝不可能在两周内完成符合期望质量的LoongArch模拟器。并非它能生成完美代码，而是它能按我的意愿完成基础搭建，即便某些环节做得不够好，我也能接手完成后续工作。第一周我仅需修改一个提交就完成了全部配置，让几个程序正常运行。再过一周，它已能在多平台运行并支持即时编译。实在不知该如何形容，毕竟这次我对主题有着深刻理解。若贸然涉足未知领域，恐怕难以取得这般成果。
不过我也让它生成了Rust和Go语言绑定库——这两门语言我其实并不精通，至少不足以独立完成从头到尾的开发。
有位评论者提出极具启发性的问题：如何避免能力退化？必须承认，我仍需耗费数日攻克极端难题。谁能想到64位MinGW的gettimeofday结构布局竟与64位Linux不同？事后看来虽显而易见，但当时我耗费大量时间才锁定问题根源——仅凭看似指令模拟错误的表象展开排查。我反复研读LoongArch手册数遍，逐条检查指令集，禁用所有能想到的选项，最终才锁定罪魁祸首——竟是某个模拟失误的旧式系统调用导致的时间获取异常。……若当时能由LLM发现这个漏洞，我定会欣喜若狂。
但仍有LLM无法解决的未知领域，比如在模拟器中运行Go语言程序。Go的运行时机制复杂，涉及基于信号的抢占(sysmon)、线程等多重机制——这些我虽已实现模拟，但即便简单的Hello World程序，仍存在无法完整传递至main()的缺失环节。究竟是信号传递的上下文环境(ucontext)存在缺陷，还是线程机制或状态级信号处理出了问题？要解决这个问题，我需要研读Go系统库(纯源代码形式)、目标架构(LA64)的汇编代码，甚至可能需要添加监控点来追踪故障根源。另一条路径是通过简单TCP套接字实现远程GDB调试的RSP服务器。
总结而言，我仅有两次彻底抛弃LLM生成的代码、从零重写的经历。这种情况在所难免，毕竟编程是充满主观性的艺术。但我仍频繁使用它来观察其构想能力，偶尔确实令人惊叹。更多时候我则难以置信——它竟会处理不当简单操作，比如错失通过将有符号数据移位至高位来避免额外掩码运算的机会，而该操作本可通过一次移位完成，却因低位与其他数据共享空间而错失良机。总体而言，我感觉自己更多时间用于思考更高层次的问题(偶尔也涉及底层优化)。
> 若你近期未尝试现代AI编程工具，本周不妨试用一款。
我不会尝试。我很庆幸自己做出了这个激进的决定——刻意坚持对生成式AI的严苛立场，尤其在编程领域。这种坚持未必理性，但坚信某种理念并将其贯彻到底自有其价值。有人拒绝专有软件，有人拒绝食用有感知能力的生物，而我纯粹基于原则拒绝生成式AI。
这样我就不必忍受那些想让你难堪的文章了，它们几乎在哀求：“请用AI吧，现在它很棒，我保证”——说实话我觉得这很可悲。为何人们如此在意AI，以至于要陷入这种可悲的说服循环？这简直像某种自卑情结，仿佛无法承受他人厌恶自己钟爱的工具，因而拼命要求对方改变看法。
说得好！
最爱先树立稻草人再痛快击倒。每次都畅快淋漓。然后我去Hacker News看看评论区。
确实令人费解，这里总有人不断贬低大型语言模型。
它显然正在快速进步。即便泡沫破裂，这列火车也不会停下。
残酷的现实是：未来我们需要的软件工程师将大幅减少。就像农业现在需要的劳动力远少于过去。
恕我直言，如果你处于开发者技能分布曲线的下半部分，你就完蛋了。
若你厌恶阅读他人代码，自然也会厌恶阅读LLM生成的代码。如此这般，你与AI的终极关系不过是沦为又一个“氛围式编码者”——终日产出堆积如山的代码却无意阅读。早该在LLM兴起前就另谋出路了。
负责任地使用AI意味着要阅读海量生成的代码，理解它、审查它、审计它，而不是为了逃避阅读代码而进行“氛围编程”。
> 若你厌恶阅读他人代码，自然也会厌恶阅读LLM生成的代码。如此这般，你终究只能成为又一个“氛围式编程者”——制造大量自己根本不打算阅读的代码堆。在LLM出现之前，你就该另谋职业了。
我确实喜欢阅读高水准的他人代码。但面对平庸之作，我向来直言不讳地批评。
目睹众多技术圈(包括HackerNews)对AI充满怀疑与抵触，着实令人沮丧。这仿佛是卢德分子卷土重来，他们仅因负面印象或对后果的恐惧就否定技术进步。
AI是工具，理应如此对待。
同时警惕江湖骗子。人工智能会广泛融入世界吗？会的。它会摧毁全球所有工作岗位吗？当然不会——卢德分子根本不明白这种观点有多天真。
新事物未必代表进步。
即便大型语言模型最终被证实具有净收益且成为工作必需，它们也与多数软件开发者珍视的价值背道而驰(精准性、可控性、可预测性、高效性…)。
软件开发者确实可分为两类：享受实践者与追求薪酬者。若LLM胜出，留任的将是后者——这无可厚非，并非前者的卢德主义者属性使然，而是工作本身已沦为他人接手的糟粕。
你提到的两类开发者在ChatGPT出现前就存在，未来也必将延续。若真有影响，人工智能只会让那些唯利是图者变得更加无关紧要。
你真认为软件工程会降低对精准性、可控性、可预测性与效率的要求？这些核心能力与人工智能无关。
文章开头那个愚蠢的稻草人论证让我直接关掉了页面。
若无需严格验证关于人工智能能力的宣称，那些关于它能完成X或Y任务的说法，本质上不过是酒馆吹牛。
若想成为负责任的工程师而非虚无主义者，就不能像制造航天飞机那样宣称其安全无虞——直到它爆炸几次后耸耸肩转而关注其他事物。
当今AI工具存在严重缺陷，这些问题并非秘密，而是被广泛讨论的议题。狂热拥趸们对此一笑置之或漠不关心，但我无法如此，因为我是一个负责任的成年人。
我确实用Claude Code编写一次性工具，这方面它表现出色。在我的朋友圈里，我们用简化术语讨论AI辅助工作：
0级：粗制滥造。未经测试、草率尝试、无人审阅的产物。“我用粗制滥造的代码写了个内存监控工具”
1级：勉强可用。通过基本验证，但未深度审查。“我用Claude Code创建了款可信的内存监控工具。”
2级：临时可用。基于合理测试和审查，我信任其在个人工作中的应用。“我用Claude Code创建了款临时内存监控器。”
3级：经过验证。测试充分到可推荐他人使用。我愿为此背书。