软件开发成本是否骤降90%？

在小型团队中，布鲁克斯定律的反向效应显现：沟通开销非但不会随人数增长而增加，反而消失殆尽。少数人突然能实现数量级的产出提升。

 💬 663 条评论 |  成本 | 

我从事专业软件开发近二十年，见证了诸多变革——SaaS的诞生、移动应用的全面兴起、区块链的疯狂炒作，以及低代码将取代开发者的永恒预言。

如今，智能编程技术正以惊人的速度重塑行业经济格局，它将彻底颠覆软件开发产业(乃至更广阔的经济领域)。2026年将令许多人措手不及。

在之前的文章中，我深入探讨了为何认为 评估报告遗漏了若干重大飞跃，但此后反复思量(加之近期实践)使我确信：我们正处于一代人仅遇一次的变革初期。

元素周期表

交付成本的演变

我入行时恰逢开源技术爆发式增长——这无疑是定制软件开发成本结构的首轮重大变革。至今仍记得SQL Server或Oracle令人咋舌的费用，因此我最初选择MySQL，它确实能让开发者构建定制化网络应用，而无需承担五六位数的年度数据库许可成本。

此后云计算兴起(我认为其成本节约效果存疑，但姑且承认其能节省部分初期资本支出)，而近来我更感受到复杂性时代的来临。软件工程变得——在我看来往往是无谓地——日益复杂，人们争相采用测试驱动开发、微服务、超复杂的React前端和Kubernetes等劳动密集型模式。我确信过去几年间成本并未显著降低。

图0：软件开发成本是否骤降90%？

然而在我看来，AI智能体能大幅降低软件开发的劳动力成本。

那么90%的成本节约究竟从何而来？

2025年初我对多数AI编程工具持强烈怀疑态度——至今仍对其中许多保持质疑。许多平台不过是包装华丽的低代码工具(如Loveable、Bolt等)，或是添加了半实用(却常惹人烦)的自动补全功能的VS Code分支。

以企业内部工具的普通项目为例。假设数据建模已基本完成，你需要开发一个管理组件的Web应用。

以往流程是：先由小团队搭建CI/CD环境，构建数据访问模式和核心服务。接着通常要开发大量CRUD风格的页面，可能还需制作用户端仪表盘和图表。最后(理想情况下)添加自动化单元/集成/端到端测试确保系统稳定，约一个月后发布。

这仅是直接人力成本。项目中每位成员都带来协调开销：每日站会、工单管理、代码审查、前后端交接、等待他人解除阻塞。实际编码往往只占时间的一小部分。

几乎所有这些工作，借助智能编码命令行工具都能在数小时内完成。我曾让Claude Code在短短几小时内为复杂的内部工具编写了完整的单元/集成测试套件(300+个测试用例)。若由我或许多我敬重的开发者手动编写，则需耗费数天。

基于智能体的编程工具在将业务逻辑规范转化为优质API与服务方面已达到极致水平。

原本耗时一个月的项目如今仅需一周。思考时间基本不变——实现时间却大幅压缩。在小型团队中，布鲁克斯定律的反向效应显现：沟通开销非但不会随人数增长而增加，反而消失殆尽。少数人突然能实现数量级的产出提升。

潜在需求

表面看来，这对软件开发行业似乎是极坏的消息——但经济学告诉我们事实并非如此。

杰文斯悖论指出：当生产成本降低时，我们不会仅满足于以更低成本维持原有产量。以电灯为例，尽管蜡烛和煤气灯销量下滑，但整体人造光源却大幅增加。

若将此原理应用于软件工程，需关注供需关系。软件领域存在着海量潜在需求。我相信每个组织都有数百甚至数千张Excel表格在追踪重要业务流程，若能转化为SaaS应用将高效得多。假设某机构报价5万美元将其中一项流程开发成应用——只有核心需求才会通过审核。但若成本降至5千美元(聘请合格开发者+AI工具)，需求量将瞬间激增。

图1：软件开发成本是否骤降90%？

领域知识是唯一的护城河

那么我们该如何应对？目前仍需人类“看护”智能体——检查其工作成果、指导方法选择并规避错误路径。纯粹的YOLO式编程很快就会陷入混乱，但若有人类介入，我认为能以极快的速度构建出卓越品质的软件。

这使得真正掌握该技术的开发者能高效解决业务难题。他们的领域知识与行业洞察成为巨大杠杆——既能做出最优架构决策，又清楚该选用何种框架与库。

若再叠加业务领域的理解，便真切感受到传说中的十倍工程师已然降临。同样地，业务领域专家与积极进取的开发者结对协作，辅以这些工具，将形成极其强大的组合——我认为这种模式将日益普及：取代由业务专家和开发团队组成的“小队”，我们将看到更紧密的双人协作模式。

这种组合能实现极快的迭代速度，软件几乎成为可抛弃品——若方向错误，便弃之重来，将经验教训融入新方案。这需要相当大的思维转变，但真正的艰辛在于概念性思考而非敲代码。

警惕意外突发

智能体和模型仍在快速进化，而基准测试似乎未能充分反映这一趋势。Opus 4.5似乎能跟随长达10-20分钟的会话而不偏离主题。数百亿美元投入GB200 GPU的成果才刚显现，相信新模型很快会让现有技术彻底过时。

然而我接触过太多抵制变革的软件工程师。那些陈词滥调的反对意见我已听腻——大型语言模型错误率过高、无法理解[特定框架]、根本节省不了时间。

这些论断正迅速沦为彻头彻尾的谬误，令我联想到2007年那些轻视iPhone的桌面端工程师。结局众所周知——网络性能飞跃提升，手机处理速度突飞猛进，移动操作系统变得功能强大。

我认为工程师必须主动拥抱变革。这种转变不会一蹴而就——大型企业普遍仍滞后于时代，深陷供应商审批和管理架构构成的官僚迷宫，使其极易受到小型竞争对手的冲击。

但若你在小型企业或团队工作且有权使用这些工具，就该立即行动。你的工作将发生改变——软件本就不断演进。只是这次变革的速度或许会超出所有人的预期。2026年正在逼近。

我常听到一种质疑：大型语言模型只适用于全新项目。对此我坚决反对。我曾耗费大量时间解析三年以上历史的代码库，而所有编写者早已离职。智能助手能极大简化这一过程——解释代码功能、定位缺陷、提出修复方案。与其继承由质量堪忧的承包商编写、三年前弃守的代码库(毫无测试覆盖，类与方法如意大利面般纠缠)，我宁愿接手由智能助手协同优秀工程师维护的代码仓库。

本文文字及图片出自 Has the cost of building software just dropped 90%?

共有 663 条讨论

  1. > 我认为工程师们必须真正拥抱变革。

    我尝试过积极参与。真的努力过。我并非网页开发者或游戏开发者(更偏向机器人技术和嵌入式系统)。我尝试过用Vibe编写网页应用和游戏，结果相当无趣。无法修改细节让我感到沮丧。记得有次游戏角色总卡在虚拟墙上，我反复求助Cursor修复，结果越改越糟。还有次用数据库搭建前后端分析数千条拉取请求评论，程序突然卡死却查不出原因，Cursor也帮不上忙。整个过程让我感觉自己越来越笨。

    下次开发网页应用时，我自学了Flask和基础JS，发现效率提升显著——虽非开发初期，但后期调试阶段尤为明显。

    AI在检索文档和错误信息方面帮了大忙，本质上是强化版的谷歌搜索和Stack Overflow替代品，但让它主导开发流程对我毫无用处。

    回复

    1. 像楼主这样的帖子让我快疯了。

      难道真存在能实现十倍效率的自主方法？还是说其中有陷阱？虽然我不太喜欢整天“凭感觉编程”的想法，但面对现实也无妨。

      但我和你经历如出一辙——或者说更依赖那个超级增强版的谷歌/SO替代品

      或是直接抛出“能快速写个实现xyz功能的枯燥函数吗”“顺便加个这个”之类的需求，甚至连bash脚本都这么搞

      而且这还是在我自己完成大部分基础架构的前提下。

      回复

      1. 所有DX调查(覆盖超2万名开发者)得出的结论完全一致：
        资深工程师从AI工具中获得的时间节省最多，重度使用者每周可节省4.4小时。这相当于10%左右的生产力提升，离十倍效率还差得远。

        更值得注意的是，调查结果显示AI重度用户与轻度用户的时间节省幅度高度一致：重度用户每周节省4.4小时，轻度用户仅节省3.3小时。换言之，DX调查明确表明AI重轻度用户间的时间节省差异微乎其微。

        诚然所有调查都存在不同缺陷，但2万份样本量绝非小数目。任何包含数据点的研究都表明代码生成并非显著的省时手段，且没有任何研究显示其能带来显著时间节约。DX报告中所有生产力提升均源于调试辅助与代码库探索支持。

        回复

        1. > 这仅提升了10%左右的生产力，与十倍效率相去甚远。

          2026年依然没有万能解药

          回复

        2. 若要这些调查具有意义(无论支持或反对AI)，我们必须建立有效的开发者生产力衡量标准

          回复

          1. 根据我的经验，通过合并请求数量衡量的生产力大幅提升。

            合并请求增多是因为资深开发者现在制造更多缺陷——较2025年增长4倍。开发者不变，代码库不变，但现在有了Cursor！

            回复

            1. 代码变更行数也是重要指标，尽管这早已被公认为糟糕的衡量标准。

              回复

        3. 能否提供最新调查的链接？我谷歌搜索能力此刻失灵了

          回复

          1. 很遗憾没有。

            我见过的一些报告里隐藏着过往调查结果，而最新调查因公司付费订阅我才拥有完整访问权限。因此我不确定公开这些内容是否合法。

            回复

          2. 你的谷歌搜索能力没问题，只是这方面的大型研究本就寥寥无几，其中更没有采用有效方法论的。

            回复

            1. 我认为要真正理解大型语言模型如何影响开发者生产力，至少需要2-3年的滞后观察期。当前变量太多，任何宣称具体生产力提升数据的人都极可能严重失实。

              例如引用资深工程师作为案例存在明显偏差：他们拥有多年传统训练背景，显然不能代表普通软件工程师群体。

              回复

      2. > 比如，真的存在能实现10倍增长的能动性方法吗？还是说其中存在某些陷阱？

        是的。我认为这是实践的结果。我知道这听起来很荒谬，但我感觉自己已经与AI工具——特别是Claude Code——达到了某种心灵感应的状态。我并未有意识地学习过相关流程，但自从ChatGPT出现后我就全身心投入其中，我真心觉得自己的大脑已被重新连接，这种变化除了体现在软件产出速度上，我其实并未真正察觉。

        前阵子有几个月我总感精疲力竭。虽然产出颇丰，但整个过程异常耗神。如今我已跨越那道坎，抵达了荒谬高效的新境界，工作中更涌动着令人上瘾的喜悦——在协调复杂任务时获得奇妙的愉悦，看着成果逐步显现。这简直是纯粹的魔法。

        是的，我知道这听起来荒谬又夸张。但自从二十多岁以来，我从未在编写软件时如此享受。

        回复

        1. > 是的，我知道这听起来荒谬又夸张。

          既然如此，你该拿出更多数据佐证。告诉我们如何衡量效率提升？你目前只强调了主观感受

          回复

          1. 原本需要1-2周完成的工作，如今2-3小时就能搞定。这绝非夸大其词。我有个朋友和我一样全身心投入这个项目，他在公司上班(我是自由职业者，为客户做独立承包)，他告诉我已经开始推进2026年第一季度的项目了——因为他提前数周完成了所有2025年的工作计划。而他的同事们还在每日站会里挣扎。

            我明白这听起来有点像宗教宣传：除非真正接受耶稣的爱，否则你永远不知道自己错过了什么——大概是这个意思。但你确实需要全身心投入才能体会这种体验。除此之外，我实在不知该如何形容。

            回复

            1. 当工作流程与技术高度契合时，效率确实会大幅提升。若你积累了足够经验，能敏锐发现技术缺陷或次优方案并迅速调整，效率更将倍增。

              但一旦出现技术契合度不足的情况，整个流程就会迅速脱轨。

              并非所有程序员都会经历这种情况，但作为大型企业的资深工程师，我屡屡遭遇此类困境。

              当然，对于遵循CRUD模式的绿地项目而言，这种模式确实很棒。

              回复

            2. 这种谈论技术的方式实在乏味。你若觉得这像宗教体验，我倒乐见其成，但我对此毫无兴趣。我只在乎现实

              回复

              1. 在我看来，若这些说法真实可复现，理应有公开的追踪记录展示：具体交互如何产生特定输出，以及实现过程耗费的时间与金钱成本。

                这样的记录存在吗？

                回复

            3. 假设每周工作40小时，你宣称的效率提升约25倍，在我看来简直荒谬可笑。

              你描述的生产力增长意味着：原本需要五年完成的工作，现在只需2.5个月——这种效率提升简直天方夜谭。

              这根本经不起推敲。我甚至怀疑从汇编语言到Python的转换能否带来如此荒诞的生产力飞跃。

              这根本经不起推敲。即便从汇编语言转向Python，也不可能带来如此荒谬的生产力提升。

              回复

            4. 我对那位朋友的同事们深表同情。他们此刻恐怕正被大量事务淹没，但根据你提供的背景，这大概率不是什么“敏捷会议”……

              我根本不在乎LLM，我只想知道你凭什么敢断言任何任务都需要N周？你说1-2周…这跨度也太大了吧！“本该”花1周的事做2小时，“本该”花2周的事也做2小时？这逻辑何在？真想知道“本该”花3周的事得做多久？

              你对客户收费标准还一样吗？

              回复

              1. > 他们现在可能正处理大量事务，但根据你提供的背景，这大概率不是“Scrum会议”..

                这让我笑了。说得对。;)

                关于时间预估：若您质疑我缺乏数据支撑，您完全正确。我向来不擅长估算工时，至今仍是如此。但我认同楼主观点——所需人力确实减少了90%。

                这确实让我感觉我们陷入了宗教信徒的领域。有人亲身体验过且深信不疑(信徒)，有人亲身体验过却无法理解(不信者)，还有人从未尝试过(无神论者)。跨越这些鸿沟沟通很困难，每个群体对其他群体的看法本质上都是“我不理解你”。

                回复

                1. 宗教关乎信仰，信仰即在缺乏证据时仍坚信不疑。工程产出则具象可量，客观可验证且易于量化(无论就局部成果还是利润而言)。它需要充分证据与可验证的论断，无需任何信仰支撑。

                  此处既宣称客观结果，却又承认我们甚至未追踪预估数据，即便尝试预估也表现拙劣。人类在预估实际耗时与产出方面素来糟糕，尤其面对非自愿工作时。我们缺乏评估的基本标准，且存在未被计入的已知偏见。

                  代码行数产出从来不是问题，复制粘贴就能解决。几年后的总拥有成本和整体开发速度才是另一回事。精妙的代理协调机制本可实现低开销的估算与追踪任务。但现实并非如此……

                  任何能将牌组构筑效率提升20%的人，都会向我展示时间表、已结算项目，以及一辆极其炫酷的新车。倘若要穿透本体论迷雾的不可穿透帷幕，见证不可见之物，就必须将摩斯拉奉为我的主与救赎？那套牌组无论如何都未必如表面那般廉价。

                  大型语言模型确实为我带来显著的学习效率提升，其能力令人惊叹。但过早优化终究为时过早，所谓万能解药的论断仍需实证。

                  回复

                  1. 今晨实例：上午10点，同事为我开发的音乐插件提交创意工单：若能用点头检测(头部追踪)触发录音岂不妙哉？这样使用我们应用的音乐人就不需要脚踏开关了(身为音乐人，双手常被占用)。

                    确实很酷。一小时后，我便发布了包含该功能的正式版本——完整实现权限管理，配备校准界面(可显示面部检测状态、调节灵敏度，并通过视觉反馈提示点头检测)。大部分工作是在我淋浴时完成的。这是今天该应用实现的第二个功能。

                    今早我还为某平台的分析功能发布了修复版本，并为另一平台创建了全新报告(因遵循既有模板而相当容易实现)。

                    此外还进行了健身训练，在HN论坛与网友辩论，并步行上班。五小时完成这些任务相当不错！若没有AI辅助，我能估算出将面部检测追踪功能集成到C++音频插件需要多久吗？尤其考虑到我从未做过类似工作？不，我无法预估。我的估算能力很差。会超过30分钟吗？嗯…大概吧？

                    回复

                    1. > 一小时后，我发布了正式版本

                      真想看看那个拉取请求，以及代码的可读性和可维护性如何。既然你从未做过这类开发，你自己能理解这段代码吗？

                    2. 单纯添加录音倒计时功能就实用得多。作为音乐人，点头打拍子本就是我的日常动作 :)。

                      不清楚你的用户构成如何，但当天就发布CV功能简直是灾难预演…以我们都应践行的用户同理心来看，至少需要测试或考虑的环节实在太多。

                  2. 个人体验与普遍真理的宣称必须区分对待。

                    若我知晓某位诚实严谨的专业人士声称某工具使其效率提升5倍或10倍，我会相信该工具确实对其特定工作产生了重大影响。但若对方宣称效率仅提升10%，我则会持高度怀疑态度。

                    我可能会质疑：这个过程中积累了多少技术债务？有多少本该积累的知识被跳过了？这些效率提升有多少是透支了未来？

                    但我不会全盘否定这些即时效果。我认为这种经验作为起点，对建立更普遍的科学理论具有重要意义。

                    此外，我们不应忘记：软件工程师的决策几乎从未建立在扎实的实证科学基础上。我研究过不少关于软件工程项目生产率与缺陷率的文献，其研究方法往往漏洞百出，结论在我看来也毫无可靠性可言。

                    回复

                2. 恕我拆解你的比喻——断言无神论者从未尝试宗教实属认知偏差。

                  回复

                  1. 过度使用大型语言模型可能导致大脑退化。

                    回复

                3. 所以，你说人工智能让你变得“快得离谱”，但转头又承认自己向来不擅长估算事情所需时间？

                  回复

                4. > 这确实让我感觉我们正在踏入宗教信徒的领域。有人亲身体验过并全情投入(信徒)，有人亲身体验过却无法理解(不信者)，还有人从未尝试过(无神论者)。跨越这些鸿沟沟通很困难，每个群体对其他群体的看法本质上都是“我不理解你”。

                  简直胡说八道。你的文风让我想起《爱情导师》里迈克·迈尔斯那滑稽可笑的表演。

                  回复

                5. 但这种“宗教感”难道不让你心生疑虑？难道没有一丝批判性/理性思考的火花？难道你不担心自己会陷入信仰原教旨主义的泥潭？

                  延续这个比喻：既然克劳德能用更短时间完成工作，为何还要向客户收取人工费？何不直接询问他们是否听闻过福音？

                  回复

          2. 双子座最有效的方案是：我创建了支持CUDA的C语言转译DSL，能在3小时内训练小型模型…(所有程序必须基于图像数据集运行，仅生成嵌入向量)

            禁忌：自上而下描述代码(例：用React给我做个界面，带这些按钮及对应行为)

            禁忌：随意聊天(例：我觉得按钮改成绿色更好看)

            建议：将表述限定于下个数据转换目标(例：你必须添加函数将所有小写开头的单词改为大写开头)

            可；自底向上引导代码(例如：你必须生成包含文本文件打开函数及相应测试的文件；现在需添加统计所有以“f”开头单词的函数)

            可；使用“必须/应/可”表述(例如：你必须通过此函数扩展代码)

            可；限制为数学抽象(例如：系统提示： 禁止使用循环，仅允许递归与函数式范式。不得自创抽象概念，必须遵循数学对象与已知算法)

            执行；每种类型与功能限定单一文件。便于快速审查，仅需再生成需修改部分。

            运用这些模式，Gemini 2.5与3代系统已高效产出优质代码，极少出现偏离核心功能或产生幻觉的情况。

            编程领域长期沉溺于个人开发者为博眼球而杜撰的语义，借此营造神秘感、模糊真相以保障饭碗；归根结底不过是矩阵运算与内存显示状态同步的技艺。

            回复

            1. 精彩评论，感谢分享。不知为何被标记为过期内容，特此申诉撤销该标记。

              回复

          3. 没人拥有可靠的、实证性的程序员生产力指标。根本没人。工单数量、功能点、代码行数这些指标，完全无法反映产品的适用性。全是主观感受。

            回复

            1. 好吧，但完全可复现的实证证据与神启之间存在一个光谱。我仍相信生产力可通过有效方式衡量——即便不完美。至少尝试总比…这种东西强得多。

              回复

          4. 顺带一提，我自认现在效率大幅提升，但真正有说服力的数据点应是：从事项目工作的人员，其时薪达到去年五倍。若此类案例寥寥无几，所谓十倍效率便无从谈起。

            回复

            1. 这论点缺乏说服力。即便你能完成十倍工作量，也未必能轻易找到愿意支付五倍时薪的客户。

              回复

        2. 是的，我知道这听起来荒谬夸张。但自从二十多岁后，我再没享受过如此愉悦的编程体验。

          但…这根本不是你写的。这是众多网站、无数人、Stack Overflow等平台通过名为AI的过滤机制共同编写的成果。

          你根本没写过半行代码。

          回复

          1. 笑死，这就像说你在Stack Overflow找到解决方案就等于没写程序

            老兄快醒醒：你自己也从来没写过代码。你提交到代码库的每一行代码，都是别人先写的，你不过是复制粘贴再稍作修改罢了。

            回复

        3. 这很有意思。

          请问你通常处理什么类型的项目？使用哪些技术栈？是否运用过Markdown魔法？

          具体的工作流程是怎样的？是否存在必须人工干预的环节？

          回复

          1. 目前主要有三个项目。其中两个采用Rails后端和React前端架构，因此均使用Ruby、TypeScript、Tailwind等技术栈。第三个项目是近期开发的音频插件，基于JUCE框架构建，全程采用C开发。这个项目最让我惊叹，因为我虽是资深网页开发者，但上次编写C代码已是二十年前，且毫无DSP或数学背景。令人震撼的是它运行完美——既线程安全又高效。

            在工作流程方面，我为高频任务设置了大量自定义命令(例如“执行代码审查”)，但始终保持全程参与。所谓“智能体能连续编程数小时”的说法我个人并不认同。具体参与程度取决于任务性质：有时我乐于放手让它工作，事后再进行审查； 另有些时候我会实时观察编码过程，若方向不符则立即干预。所以确实存在持续的手动介入——这正是我所说的“心灵感应”。代码助手并非独自完成工作，我也非独自完成工作，而是我们共同完成工作。

            回复

            1. 我维护着几个Rails应用，过去四个月95%的代码由Claude Code编写。我定期部署代码。

              我提交PR后会让Copilot进行审查。有时它会发现问题，我把这些批评内容复制粘贴到Claude Code中，它就能自动修复。

              把大型语言模型当作能超自然速度查找答案的初级开发者吧。你仍需审慎对待它们的工作成果，甚至要保持怀疑态度。测试、测试、再测试。

              回复

              1. 能否展示这些强大LLM生成的软件实例？

                回复

            2. 既然代码是生成的，为何还要使用Tailwind？难道没有更高效的方案吗？

              回复

              1. 模型中包含大量Tailwind训练数据。虽然存在更高效方案，但让模型直接运用训练数据更稳妥。

                回复

                1. 纯CSS的训练数据量肯定比Tailwind多出一个数量级吧？

                  回复

                  1. 根据我的经验，大型语言模型更适合与具有严格规范的框架配合使用。像Tailwind这类框架拥有大量协同工作的示例代码、用于推导所需行为的语言体系、更高的抽象层次(可能存在)等特性，这些都显得尤为重要。

                    大型语言模型当然能处理原始CSS且效果良好，但挑战在于当跨多个页面需要保持一致框架时，特殊情况不断增加，模型可能将细微不一致放大。若严格遵循框架规范，大型项目中不一致性应更少(至少理论上如此)。

                    回复

          2. 研究 -> 规划 -> 实施

            首先让智能体向你提问，直至获取足够信息制定计划。

            借助智能体完成计划制定。

            执行既定计划。

            初期我需频繁查看代码。与其直接修改，我更倾向于思考如何调整提示词或工作流程。

            回复

      3. 确实降低了探索性工作的成本，但仅此而已——每月20欧元绝对划算，但远不及任何“终极”套餐的价值。

        例如今天我需要编写一个简单状态机(用于重写的解析器，所有测试用例已备齐)。我让Claude Code代写状态机，并在它尝试编译测试前终止了任务。

        生成的代码部分有效(当然包含所有模板代码)，部分毫无意义。虽然节省了几分钟，整体代码作为初步方案尚可，但等待它“推理”修复方案对我而言毫无意义。节省的时间主要来自跳过了最初“输入模板代码并使其编译通过”的环节。

        在完成重构时，还有其他几个步骤也适合使用AI。但总体而言，大型语言模型只完成了约10%的工作量，乐观估计整个上午最多节省了20-30分钟。

        假设每周能获得类似节省(这仍非常乐观)… 相当于2%或更少的效率提升。

        回复

      4. >真的存在能实现10倍效率提升的智能方法吗？
        >绝对存在。
        >还是说存在某些限制？
        >绝对存在。

        关键在于：要实现10倍效率，必须从事大量AI擅长的重复性工作——主要是模板化且逻辑清晰但枯燥的修改。虽然我能编写大量代码，但可能需要检查十余个函数/方法的语法和实现细节，不过我清楚它们的功能及代码流向。AI虽无法完美实现，但其生成的代码足够接近目标，经我修改后能节省大量时间。关键在于我对需求已有清晰认知——这正是自动补全功能如此高效的根本原因，它本质上是个相当靠谱的助手。

        另一种方式是从0.1倍效率(甚至更低)起步，逐步提升至近乎1倍的效率。

        从事技术岗位的人数极其庞大，但实际技术公司的吞吐量却极低。

        我最近供职于一家规模庞大的非科技企业，但它隶属于全球知名的双寡头垄断集团。该公司雇佣数千名软件开发人员，其主要职责是模糊地知道该向谁发送邮件咨询问题或变更需求。邮件与代码行的比例可能高达25:1。

        对于主要开发经验来自这类机构的人而言，“只需让AI修改代码，它可能一天内就能正确完成”的设想简直令人难以置信。

        回复

        1. 我有个疑问，虽然似乎永远得不到满意答案，但确实很好奇：

          1. 你写的代码为何大多是模板代码？

          2. 为何要编写大量模板代码，而不直接编写能泛化模板的代码？(换言之：我懒。若需重复输入相同内容，我会直接编写脚本)

          我原以为差异在于编程领域，但发现编写类似代码的同行也存在同样现象，实在难以理解

          回复

      5. 我总用这个Excel类比：当年Excel问世时，大家都说会计要失业了。如今会计人数反而创下历史新高。

        这个类比同样适用于你的观点。精通Excel的会计师能挖掘出远超新手的功能价值。

        AI编程对工程师确实大有裨益。继续努力吧！

        回复

      6. > 或者直接说“能快速写个实现xyz功能的枯燥函数吗”“再加个这个”，或者用于bash脚本之类。

        我仍亲自编写大部分有趣的代码，但遇到枯燥乏味的工作(通常高度重复却难以抽象化)时，我发现通用AI能带来巨大优势。

        虽然效率未必达到10倍，因为多数时候我仍需正常编写代码。但对于极其具体且枯燥的任务(通常也是我最厌恶的代码部分)，它确实能实现10倍效率。若将这10倍效率摊销到全部时间，实际体验更接近1.5倍至3倍，但它确实拯救了我的理智。

        比如实现那些枯燥的CRUD接口——它们包含大量定制逻辑导致无法使用通用抽象方案，还得编写配套测试。

        过去我极度厌恶这类工作，纯粹是令人麻木的重复劳动。如今我编写了一系列游标规则(这个过程其实挺有趣)，现在只需导入线性票据描述，就能一次性完成约95%的工作。

        不过遇到有趣的开发任务时，我仍倾向于亲自动手——既因乐在其中，也因为大型语言模型可能搞砸(尽管它们正变得相当厉害)。

        回复

      7. 我尝试用Claude Code编写一个极其简单的应用——本质上是将请求输出到控制台的Go语言模拟服务器。这类应用我通常一小时就能完成，但这次耗费了1.5小时。最终生成的代码完全符合我的预期，几乎与我手动编写的代码别无二致。这并非即兴编程，而是通过逐步细致的指令引导它按我的偏好编写代码。

        因此对我而言，很明显只要训练得当，最终能以相同效果实现效率提升。虽非十倍速，但两倍效率完全可期。首次尝试AI编程耗时几乎与手动编写相同，说明我还有很大提升空间。

        话虽如此，这种方式让我深感困扰。这样的工作毫无乐趣可言。二十五年前我开始编程，正是因为其中充满乐趣。时至今日，编写各种循环和条件语句仍令我沉醉。我能接受静态代码补全这类基础自动化工具，但仅此而已。

        回复

      8. 有人还记得《星际迷航：下一代》里那个情节吗？小男孩得到一台激光雕刻机，能把木块雕成海豚。他抗议“这不是我做的”，而绑架他的老师(真恶心)却说：“没错，但这是你想创造的东西，工具只是引导了你”

        所以到了2026年，用“老派方式”编程——那种愉悦的方式，艺术家与作品相连的方式——我们会惹上麻烦。我们不再是主厨，而是从水龙头里灌食物的管道工。

        我们恼火是因为产出突然能用时间单位衡量。猫腻败露了。我们秘密俱乐部的灯泡被房东掌控了。

        其中有人早已做好准备：积蓄资金，决策得当。他们将安然无恙。

        另一些人却不知如何应对——或拒绝改变——选择正被不断压缩。我们正被拖向深渊，如同被押往收容所的狗。

        有过去，有当下，还有未来；当下是我们罕有体验的状态，而我们正身处其中——2024年恍如虚无，2025年充满挣扎，2026年终将迎来和解。

        改变很糟糕。但这就是我们延续的方式。要么以不同的方式延续，要么就不复存在。

        回复

        1. 我确实记得。我认为是第一季剧集《当树枝断裂时》(S01E16)。这部剧开播就直面了诸多沉重议题… 我由衷敬佩这种勇于尝试的魄力，纵使它在击出本垒打和站立二垒安打的同时，也制造了些史诗级的挥空。

          回复

        2. 我欣赏你的视角。你觉得《2026：和解》会是怎样的？

          另外我得找找那集《星际迷航：下一代》…听起来很动人。

          回复

      9. 感同身受。我猜那些成果出众的人，简直是在手写极其详尽的伪代码吧？！比如：

        编写Person类，包含成员变量(整型)年龄、(字符串)名字、(字符串)姓氏…

        但若能写得如此细致…难道不该已经明确知道要写什么代码以及如何编写了吗？单纯写伪代码反而显得冗长。

        回复

        1. 但AI编码助手能进一步提问，考虑你未察觉的角度，并生成文档、数据生成迁移脚本、测试用例、CRUD接口等上下文关联的成果。若仅凭普通伪代码就能可靠完成这些，那远比手动书写相同概念的各种表达形式更简洁。

          当然，部分内容(如CRUD API)也可通过模板生成。甚至可让编码助手生成模板及其处理/编译代码，或根据参数生成模板生成代码。

          回复

      10. 根据我的经验，调用大型语言模型会引发重大上下文切换，破坏工作状态。这就像有只猴子闯进办公室敲锣打鼓一分钟，写完指令让LLM代劳后，重新编程需要重新聚焦才能找回刚丢失的沉浸感。对于特别枯燥烦人的任务，这种交易或许值得，但并非总是如此。

        我怀疑这解释了当前LLM使用方式的分化。人们要么全盘依赖LLM，要么极少使用，中间地带正日渐萎缩。

        回复

      11. > 比如，真有能实现十倍效率的自主方法吗？还是存在某种陷阱？目前虽然我不太热衷于整天“随性编程”，但接受现实也无妨。

        以下基于我当前主要使用GPT-5配合开源代码助手的经验：

        对于功能简单的全新项目？我认为你(这里的“你”指“基本具备编程能力的人”)完全可能达到昔日初级工程师十倍的工作效率。

        但当需要在现有代码库中表达复杂业务逻辑并维护向后兼容性时，情况就棘手得多。用自然语言描述这类需求本身就是门技术活(可通过训练掌握)，这个过程本身就需要时间。

        需求越模糊，出错概率就越高。模型可能“正确”执行操作，但若描述遗漏关键点，整个系统就会出错。更棘手的是，由于代码非你亲手编写，你错失了在初次实现阶段修正/思考问题的机会(这意味着必须进行深度复核，反而拖慢进度)。

        有时反复推敲英文说明反而比直接编写代码耗时更长，但某些情况下却能显著提速。

        本质上简单功能的实现效率极高，但复杂功能仍需大量人工引导和手动复核。

        回复

      12. 我感觉那些对单一项目长期氛围编码真正感到惊叹的人，其实只是因为他们缺乏更深入的认知。

        以写书或写博客为例：写一篇优秀的博客文章或书中章节，需要大量技巧和实践。成果带来的满足感极强，通常能为作者和读者创造双重价值。当有过此类经历的人看到AI生成的粗糙内容时，不会感到惊艳，反而可能倍感挫败。

        然而，那些连连贯句子都写不出来的人，反而会对AI能组织句子、构建段落，甚至在整篇文本中保持某种连贯逻辑的能力感到困惑。那些在学校里苦于写好引言和结论的人，会对AI的写作能力惊叹不已。他们甚至可能误以为“那些段落其实毫无意义，纯属废话堆砌”是写作的常态，而非AI的产物。

        回复

        1. 我惊叹于仅花费不到1%的成本，就能获得至少中等水平开发者的产出。蛮力策略往往被低估。这段经历让我获益匪浅。

          Hacker News评论区里那些开发者报告的经历，往往与他们的个人经济利益挂钩，这并不能真正动摇我的信念。

          回复

      13. 正如另一条回复所言：实践。

        你写代码花了多少小时？几千？几万？前一百小时就取得过好成果吗？

        现在对比你花在智能体上的时间。你是否投入了相当多的时间研究如何使用它们？当智能体出问题时，你是停用它转而手动操作，还是花时间研究如何让智能体完成任务？

        回复

        1. 这两者根本无法相提并论。智能体具有非确定性。我让Clod更新单元测试覆盖率时，它可能卡死程序，烧掉20万令牌后还高呼“太棒了！我更新了单元测试覆盖率”。

          我关闭终端重新打开，执行完全相同的命令。这次只消耗3万令牌，还真的新增了测试用例。

          当反馈周期长达30分钟，结果是智能体蜷在角落自慰自恋时，学习就变得困难了。当你无法相信这破玩意儿能两次正确响应相同指令时，学习的欲望自然会消失。

          回复

          1. 这条评论让我乐翻了。我真遇到过这样的实习生！

            回复

        2. 更糟的是，你掌握的所有启发式规则都在不断变化，迫使你投入额外100-1000小时学习，期间质量还会持续下降。

          回复
      14.   > 适用于bash脚本等场景

        大家都说它适合bash脚本，但我从未真正成功过。

        今天就遇上个例子：我想写个小脚本抓取谷歌学术引用数据，但对网页处理一窍不通，于是询问解析curl输出结果的最佳方式。结果它首先推荐我用Python包 (认真的吗？就一行代码？免了！)但随后又给错了grep命令。于是我打开页面源代码，复制粘贴部分内容尝试自行解析。虽然已找到更优的grep命令，但它第二次建议我使用perl正则表达式(为什么它对-P参数的偏爱程度堪比对delve的痴迷？)。接着我粘贴新命令给它看输出结果，同时搜索总记不住的awk用法，请求它补充awk和sed部分。结果它在搜索sed时搞砸了，我只好修正——这意味着要微调awk部分，不过反正我早就打开了需要的Stack Overflow帖子。总共省下的一分钟？

        接着我给它提供脚本文件的骨架，添加所需变量，本以为只是简单清理。结果大失所望。它确实表现平平——毕竟我从未见过大型语言模型在未明确指示下能生成bash函数(虽然普通人做不到这事也一样)。不过它帮我省去了参数的while循环，这点还算贴心。所以它省下的时间和耗费的时间基本持平。

        别误会，我承认LLM有价值，但远未如众人宣称的那般颠覆性。我的效率提升顶多10%？甚至怀疑这点提升是否真实。当然，它或许能减少我指导代理构建测试用例的时间，但对于一个只需15分钟就能写完的脚本？这简直是过度杀伤。而这正是我使用它们的常态体验。

        难道大家夸它在Bash领域表现出色，只是因为没人愿意花时间学Bash？这明明是每个Linux用户都该掌握基础的简单语言…

        回复

      15. 我的发现也一样：任务越小效率越高，这里省5分钟那里省1小时，这些时间累积起来相当可观。

        这很酷。遇到“修正我的类型”、“找出语法错误”或“给出实现特定功能的ffmpeg参数”这类烦人的问题时尤其实用。

        若真遇到喝了迷魂汤还想展示流程的人，我很乐意见识。但我亲身体验过足够多，更相信自己的眼睛。当我看到受尊敬的开源贡献者演示方法时，他们耗费大量时间精力守着机器确保流程不脱轨——这确实更费劲，但似乎并不更快。

        回复

      16. 代理式人工智能根本是个天大的骗局。任何像样的企业都部署了层层身份访问管理防护，AI开发者根本无用武之地——你不可能给它单点登录和OIDC凭证去访问公司资源，IT团队也绝不会允许。所以那些鼓吹AI能部署实用方案的人纯属胡扯；IT部门连自家开发者部署都严防死守，AI怎么可能例外？

        回复

      17. 这似乎极度依赖具体项目特性及其在训练集中的表征质量。

        例如，AI在处理React Native这类我懒得搭理的破事上确实很厉害。但它绝对搞不定嵌入式开发。尤其当你不用Arduino框架在Atmel 328上搞开发时。我现在正用新芯片做裸机AVR开发，所有AI助手都完全摸不着头脑。即便喂给它数据手册和整套手写代码库，AI生出来的也全是热乎乎的垃圾。

        若你恰好属于那1%的幸运儿，AI确实很棒。但只要稍微偏离十大主流语言和框架，它就基本废了。

        奇怪的是反向操作反而效果惊人。我输入零散的AVR汇编代码，AI竟能完美解析。具体原理不明，我怀疑这是模型真正擅长的根本性转换类型。

        回复

      18. 我正在开发一款游戏(预览链接：https://qpingpong.codeinput.com)，以此实践“氛围编程”。唯一规则是：我不能写任何代码，但可以随意给出提示。

        目前在代码库扩充后，让AI进行修改遇到了“硬性阻塞”。一个“解锁方案”是将所有元素重构为独立组件，这使LLM(以及你？)能更轻松地独立处理每个组件(React)。

        即便在当前这个“小型/简单游戏”阶段，LLM不仅难以实现任何变更，还极易引发系统崩溃。我目前唯一的应对方案是构建严密的测试体系(包括端到端测试)，确保LLM的任何改动都经过彻底的回归测试。

        我为此投入了一个月左右。若非涉及设计环节，手动编码本可更快完成。

        回复

        1. 我有个业余项目在用Rust实现无线电数字信号处理，纯粹出于好奇心在探索能做到什么程度。这个项目多次因难以解决的缺陷陷入停滞。由于涉及领域非我所长，且缺乏扎实的“程序理论”支撑——毕竟采用直觉编码属于灰盒操作——我确实目睹过CC在处理棘手问题时陷入僵局，甚至导致先前解决过的回归问题再次出现。

          但在日常工作中使用Claude Code的体验截然不同。日常工作中我理解代码并仔细审查，CC发挥了巨大作用。

          回复

      19. 当你对领域理解到足以自己编写代码的程度时，效率就会提升。这让你能设计出更优方案，引导大型语言模型走向正确方向。

        然而“氛围编程”会不断在你面前堆积无法理解的复杂性，直至陷入困境。(但在堆积到临界点前确实有效，适合小型任务——一旦触及阈值就会突然变得极其挫败)

        能否实现十倍效率？视情况而定。我尚未尝试真正大型项目，但能将原本需耗时一两周的庞大任务压缩至一个悠闲的周日完成。

        对于大型项目，它在某些任务上确实很有用(比如“导入最近1万次提交，告诉我哪些最可能破坏了这个特定功能”)。关键在于找到这类任务：正确答案的收益巨大，而错误答案的损失很小。这更像是基于合理优势进行算法交易，而非编程 🙂

        它确实难以在超大规模代码库中成功完成全自主工作。不过…我在该领域尚未深入尝试，请酌情参考。

        回复

        1. 当功能故障难以验证(因测试步骤无法简单转化为代码)时，Git bisect就成了救命稻草

          回复

    2. 若在采用AI时尚未开始新代码库的工作，可能更难体现其价值。

      我近期换了工作。在前公司，我深耕代码库多年，清楚改动方向和实现方式。因此尝试直接用AI进行实现，因无需太多规划协助，结果AI混乱不堪，搞得一团糟。

      而在全新代码库中，面对完全陌生的架构，我首先让AI定位相关代码位置、调用层次结构及副作用等信息。

      实践证明：通过AI进行前期调研后，既能轻松生成有效规格说明，又能相对简单地按规格生成代码。这种流程远比直接尝试一次性实现高效得多

      回复

      1. 你用自身经验否定他的经验，而你的例子与他提到的Flask游戏案例毫无关联性。

        回复

        1. 他提到让AI修复问题却毫无进展时，听起来像是想一锤定音。这种方法我之前尝试过，结果也差不多，所以才分享了对我有效的替代方案。若显得轻率了，在此致歉。

          回复

      2. GP明确表示他们用AI检索/解释内容。本地代码库同样适用这种方法。

        不明白你想表达什么。

        回复

        1. GP说他们在尝试“氛围编码”，想让AI实现一键式编程。这是最糟糕的工具使用方式。AI编码助手最适合在“大致知道输出效果但不想耗时编写具体代码”的场景下使用。

          回复

    3. 我尚未实践氛围编码，但在处理内部机制复杂的大型框架(如Spring Boot)时，它显著提升了我的效率。目前我正进行大规模重构和Spring Boot版本升级。

      当针对代码片段提出具体问题时，它能提供2-4种不同方案，涵盖不同Bean的扩展/实现覆盖。我通过反复迭代获取示例实现，常询问哪种方案更现代化或更优。例如要求它列出不同方案的优缺点清单。最终选定方案后，我会查阅具体文档进行事实核查。

      此类工作效率提升可达2-3倍。Spring框架因历史悠久且大版本间变更巨大，搜索起来尤为困难。多数情况下它会为我推荐Spring Boot版本的最新方案，生成的代码虽不差但也不够理想，因此我通常会重写。

      它在编写集成测试方面表现出色。我让它生成测试模板，再根据不同场景进行修改。随后我将这些测试套件分别运行在原始代码和重构后的代码上，作为验证套件确保重构未引入新问题。

      使用Go语言开发时虽无法获得同等效率提升，但查阅文档的需求也大幅降低。实现方式的选择空间更小，且背后没有真正的魔法机制。这或许正是开发体验差异巨大的原因之一。

      回复

    4. 关键在于，运用智能体或AI代写代码是种需要习得的技能。对多数人而言并非与生俱来。要成功掌握它，必须具备导师/领导者的思维模式——注重引导而非亲力亲为。换言之，你必须精于自我阐释——通过清晰沟通达成卓越成果。

      若缺乏编程经验，或从未在任何领域担任领导(或指导)角色，那么代理开发对你而言将异常艰难。

      我再补充说明：理想的心态需要克制“亲力亲为”的冲动，坚持通过指令进行所有修改。这种习惯将迫使你提升与他人(包括代理)的有效沟通能力。

      回复

    5. 各位如何运用大型语言模型？我已开发了几个个人应用，包括基于LLM的在线多人游戏“墨西哥火车骨牌”——其表现始终令我惊叹。Gemini 3在工作中发现漏洞的能力堪称疯狂，而Arxiv论文每周都有突破性进展。

      我今年45岁，9岁起编程至今，此刻正是构建技术的黄金时代。

      回复

    6. 别因一次糟糕的Cursor体验就永远放弃它。如今的Gemini 3很可能带来更优结果。

      回复

  2. 编写简单代码的成本已降低90%。

    若能将问题简化到可用简单代码解决的程度，其余部分就能迅速完成。

    但将问题简化到可用简单代码解决的程度，需要大量技能和经验，通常仍是相当耗时的过程。

    回复

    1. 软件开发工作的大部分是维护“遗留”代码，即那些存在已久且使用频繁的旧系统。我发现Claude Code尤其擅长理解旧代码库并进行修改。我在其中一个旧代码库上工作，生产力提升了10倍，这主要得益于Claude Code研究大型代码库、理解其逻辑、解答疑问并进行精准修改的能力。它在测试和调试环节同样发挥巨大作用，极大提升了效率。关键不在于它能快速生成大量代码，而是它如同额外的一双眼睛/大脑，运作速度远超人类开发者。

      回复

      1. 我的体验恰恰相反。Claude无法在上下文窗口中完整呈现所有内容，其修改往往会彻底破坏程序另一端的逻辑。

        诚然这源于程序极其糟糕的编写质量，但无论如何，上下文窗口仍将在相当长时期内构成巨大障碍。

        回复

        1. 从你和GP的评论中，我看到了自身经历的共鸣：

          > 大多数软件工作都在维护“遗留”代码，即那些存在已久且使用频繁的老旧系统。

          > 诚然，这正是因为程序本身写得极其糟糕

          大型语言模型无法修复庞大而糟糕的遗留代码库。绝大多数维护工作(以工时计)都集中在此处，且这种状况将持续下去。

          我更进一步认为，随着时间推移，LLM与氛围编程将共同催生更多庞大糟糕的遗留代码库，因此从长远来看，本质上不会有实质改变。

          回复

          1. 确实。我有些电子工程同事用氛围编程处理所有事务，导致代码库中没有任何内容可读。

            我怀疑我们即将经历另一轮质量危机。

            但既然从未编程的人现在都在写代码，还觉得这是最棒的事，唯一的出路就是硬着头皮干下去。

            回复

            1. 向来如此。有价值数百万美元的企业，其.NET应用程序建立在文件四处转移的根基上，SQL充其量只是API/队列工具。长期来看，脱离真正工程师掌控的“可运行”代码终将成为负担。

              回复

        2. 我也想吐槽糟糕体验——试过Claude及其他几款工具。AI能理解某些简单逻辑，但面对复杂场景时很快就会失控，其建议的修改若被采纳，后果将从糟糕到灾难性不等。

          回复

        3. 我也不会把所有源代码都放进上下文——让Claude运行编译器(甚至测试)就能规避这些问题

          回复

        4. 若你愿意，我可以尝试帮你让Claude Code处理你那极其糟糕的程序。联系邮箱：loandbehold0@proton.me

          回复

        5. 没错。它重构能力很强但仅此而已。面对复杂代码库时甚至无法生成合理的模板代码；顶多能省点打字时间。

          回复

          1. > 它重构能力很强，但仅此而已。

            当真如此？我原以为它最擅长编写新代码，但至今从未见过它正确重构现有代码。它的重构尝试常改变行为/逻辑，有时甚至让代码变得更难理解。

            回复

      2. 我也遇到过这种情况。虽然某些场景下我们尚未完全获准使用AI工具进行实际编码，但仅需询问“如何实现这个修改”、“解决此漏洞应从何处着手”或“概述这个流程的工作原理”，就能获得惊人的帮助。

        回复

        1. > 虽然某些情况下我们尚未完全获准使用AI工具进行实际编码，但即便只是询问“你会如何修改这个代码”[…]

          这种做法的逻辑终点，难道不相当于打印出Stackoverflow的解答后手动输入电脑，而非直接复制粘贴吗？

          撇开这些细节不谈，我同意当代AI确实能快速帮助开发者熟悉代码库——无论是想使用的全新库/语言，还是企业内部的遗留代码。

          成熟生态系统的最大优势之一在于Stackoverflow拥有庞大的已解答问题库(相关书籍也可购买)。借助AI，你可立即创建专属的Stackoverflow式社区——它能即时提供解答，而非将问题标记为“离题”。

          我刻意选择Stackoverflow作为例证：它虽是宝贵资源，却不足以盲目依赖。当前AI的发展境况与此相似，随着模型不断优化，这种状况将逐步改变。正如使用Stackoverflow所需的专业知识，远低于修读大学课程所需的知识量(而大学课程所需的知识量，又远低于最初设计快速排序算法所需的知识量)。

          回复

          1. > 这条逻辑推演的终点，难道不是等同于打印Stackoverflow答案后手动输入电脑，而非直接复制粘贴吗？

            对我而言并非如此(反正我从未那样使用Stackoverflow)。我的使用方式几乎完全复刻Stackoverflow，只是速度更快且交互性更强(更不会因“不知道答案”而被贴上“懒惰”或“愚蠢”的标签)。

            我发现ChatGPT生成的代码比Claude更出色(我使用Swift编程)，甚至能学习我的编码和文档风格。

            我仍需审查它生成的所有代码，目前尚未直接照搬使用，但已接近这个阶段。

            最宝贵的是遇到错误时，我可以询问它：“这是症状和代码，你认为问题出在哪里？”它通常能提供很好的切入点。

            虽然我自己也能解决问题，但可能需要半小时。而ChatGPT能在约半分钟内提供可靠线索。

            回复

          2. 真正的难题往往不在于编写新代码，而在于理解陈旧庞大的代码库及其内部关联机制。

            当你正琢磨递归的reduce函数能多完美地取代自己拼凑的代码时，Stack Overflow确实(曾经？)是救星——毕竟当时你还没完全掌握语言X的精髓。

            回复

          3. >这不就等于把Stack Overflow的答案打印出来，再手动输入到电脑里，而不是直接复制粘贴吗？

            当AI运作良好时，它比Stack Overflow更胜一筹——因为它取代的并非“在SO查找答案，复制粘贴”的流程，而是将你试图解决的问题与多个相关答案进行关联(这些答案本身并无确切解决方案)，最终整合成一段代码。你只需稍作重构，耗时远少于自行搜索所有答案。成功时，它能将两小时的研究压缩至两分钟。

            问题在于：

            AI有时会复制以下过程——开发者因未完全理解解决方案或需求，从不同答案中拼凑代码片段，最终得到勉强运行但效率低下且存在潜在问题的方案。

            即便获得正确解决方案，开发者也无法在两分钟内获得原本两小时研究中积累的认知——即对问题领域的理解以及各解决方案模块的关联逻辑。这正是该方法对资深开发者比新手更有价值的原因，因为在Stackoverflow筛选答案的过程本身就具有轻量级教育意义。

            回复

          4. >这不就等同于打印出Stackoverflow答案，再手动输入电脑，而非直接复制粘贴吗？

            Stackoverflow上的答案本身不就是人类智慧创作的结果，再经多人投票推至顶端吗？若LLM只是这种模式的自动化“等价物”，那本身就是好事！

            但总体而言，你似乎轻视的LLM答案价值远不止于此：

              拥有接近优秀人类水平的程序员
  理解你的现有代码库
  解答关于现有代码库的问题
  解答关于你想要进行的变更的问题
  按需响应(不限于复制SO答案)
  交互式操作
  甚至能直接执行变更

            这和“手动输入Stack Overflow答案”的关系，就像皮卡车之于马车。

            换个角度说，雇佣程序员修复X问题的“逻辑终点”，难道不就是“打印Stack Overflow答案后手动输入到电脑”吗？

            >我特意选择Stackoverflow作为例子：它虽是绝佳资源，但不可盲目依赖。当前AI的发展现状与之如出一辙。

            其实两者都不该盲目使用。即便是人类程序员的输入也不例外(这正是我们进行代码审查的原因)。

            回复

            1. > SO上的答案不正是由人类智慧撰写，再经多人投票推至顶端吗？若LLM只是这种过程的自动化“等价物”，那本身就是好事！

              “仅仅”这个词在此承担了全部批判力量。正是人类智能参与提供并评估答案的过程赋予了其价值。若缺失这种智能，机器不过是模仿流程却产出垃圾的工具。

              回复

          5. > 可靠性不足以盲目使用

            我用Claude构建工具时，实际查看的代码量不到它生成的5%。这些工具都是我自己想用的，而且…确实管用。有人或许会质疑我的能力，但另一方面，我尝试构建多种类型的工具，最终产出的工具不仅形似工具，功能也如工具般有效…

            我发现它评估代码的能力远胜于生成代码。正确做法是：先让它编写代码，再要求它找出代码中十大问题，最后让它修正其中五个合理且关键的缺陷。这与为解决冷门问题而四处搜寻Stack Overflow解决方案的流程截然不同。

            检验代码质量的有效方法是让大型语言模型找出其中十大缺陷——若所有问题都显得愚蠢可笑，说明代码质量相当不错。我最近对某个代码库做了测试，它最主要的抱怨竟是我选的命名既愚蠢又令人困惑(确实如此，我可不会向计算机解释这个玩笑)，这便是我收手离开的信号。

            回复

            1. >接着让它列出代码十大缺陷，再要求它修正其中五个合理且重要的问题。

              对此我持谨慎态度。我多次尝试过这种做法，往往会引发极其微妙的缺陷。有时代码本身并不存在严重问题(不足以导致5个缺陷)，但它会强行符合规范，从而修改了本无需更改的部分。这些问题终将在生产环境中暴露出来。

              回复

              1. 需要明确的是，我要求它为我生成问题清单。随后由我判断列表中的问题是否值得修复(或是否确实存在问题等)。

                回复

      3. 这很棒。向库代码提问也是我的常用模式。

        以下是我在推特上看到的示例：让大型语言模型根据代码库文档化协议：

        https://ampcode.com/threads/T-f02e59f8-e474-493d-9558-11fddf…

        你认为我能从中获得额外价值吗？虽然编码速度提升了，但公司整体项目进度似乎没变。现在我更从容自信地完成工作，只是不确定如何以此争取加薪。

        回复

        1. 对我这个远程开发者而言，这意味着原本8小时的工作现在1小时就能完成。因此我以时间形式获得了“额外价值”。团队里大家都用GitHub Copilot，而我使用Claude Code。队友们效率略有提升，而我的效率大幅跃升。原因在于：1. Claude Code本就是更优秀的编码助手；2. 我投入时间精进了智能编码技能。最终Copilot会迎头赶上，管理层将意识到：如今1名开发者就能完成过去需要整个团队的工作。

          回复

          1. 我非常好奇你的具体职责和所在行业？虽然惊叹于他人分享的生产力提升案例，但感觉AI目前只在我工作中很小一部分发挥作用(执行我指定的具体修改)。

            对我而言，基于智能体的开发流程会导致代码臃肿。当我愿意将子系统交由智能体处理时(比如在副业项目中让它自动生成整个前端代码)这倒无妨。但追求代码整洁反而会抹杀所有/大部分效率提升，更无法带来愉悦感。与智能体反复沟通的过程令我精疲力竭，这可能源于我必须构建并舍弃多个解决方案的心理模型——不同指令可能导致截然不同的处理方式。当被要求重构无关参数时，智能体能轻松在牛顿法与二分法间切换，而人类同事在代码审查后绝不会这样做。

            回复

            1. 我得出了相同结论：若你只追求以最快速度产出海量代码，且不在乎：1. 代码体量大小；2. 运行速度快慢；3. 缺陷多寡；4. 可维护性与可理解性；5. 整体工艺水准与艺术性——那么你确实能获得巨大生产力提升！对许多人和企业而言这完全可行：质量根本不重要。他们只在乎以最快速度产出平庸代码。

              若你重视这些要素，使用LLM编写代码的总耗时将超过手工编写。我在业余项目中尝试使用Claude后发现，要让代码达到令我满意的程度——成为一部连贯完整、富有表现力且值得署名的高质量作品——需要耗费大量精力进行手动引导和后期处理。

              回复

              1. > 质量根本不重要。

                质量确实重要，但只是众多要求之一。工程师们认为你列举的质量指标是最重要要求，但通常并非如此。

                回复

              2. > 尽可能快地吐出平庸代码。

                这恰恰是企业真正想要的，且始终如此。在我从业生涯中，在人工智能出现之前，就见过无数故障系统吐出错误信息，而企业却照单全收。当我提出修复时，他们根本不愿处理——因为在绝大多数情况下，应对错误已成为流程的一部分。除非被专门聘请修复遗留系统，否则我根本不再尝试。

                >我愿意签名背书的代码。

                这正是管理层眼中AI解决的“大问题”。他们始终希望我们能神奇地分辨哪些部分“够用”、哪些可以敷衍了事，却要我们独自承担责任。真正的症结始终如一：糟糕的规格说明。AI无法解决根本问题，但在他们眼中却能消除沟通不畅的层级障碍。显然没有软件工程师会构建一个输出错误信息的系统，然后轻描淡写地说“雇人反复核查”或把检查任务塞给平庸员工——但这恰恰是多数机构因缺乏决断力而采取的解决方案。

                或许软件工程师们始终未能理解企业根本不在乎这些。财务部门终究会发现那些代价高昂的错误，然后高管们会鞭策中层管理者，问题自然烟消云散。

                回复

                1. 正是这种对抗性张力才让一切运转起来。

                  若没有“务实高管”督促“完美主义工程师”交付足够优秀的产品，当市场大门早已关闭时，他们仍会困在工作室里埋头钻研。

                  但若没有“完美主义工程师”来抑制“务实高管”的天真乐观，他们很快就会因兜售镀金垃圾而被市场淘汰。

                  你说得对，确实存在某些高管，他们怀着天真的乐观主义，急于验证这项技术能否让他们在缺乏工程师制衡的情况下实现市场愿景。

                  且看后续发展吧。

                  回复

                  1. 这番见解相当中肯全面，问题在于所谓的“务实高管”更像是“为晋升疯狂的’不惜一切代价今天就上线’型精神病高管”。

                    你描述的是种拉锯式的平衡关系。现实中这种平衡根本不存在。工程师话语权仅占1%，其余99%都掌握在高管手中。

                    真希望你的观点能普世适用。在我24年的职业生涯里，事实并非如此。

                    回复

                2. > 或许软件工程师普遍存在认知偏差——他们未能理解企业真正关心的并非技术本身

                  工程师天生追求改进与优化，但我们天真地以为所有人都有同样的追求。

                  我曾经历过相当痛苦的幻灭期，那时我意识到自己被要求完成的大部分工作，并非真正为了优化产品，而是为了达成某些特定指标——而这些指标反而让除该指标外的所有方面都变得更糟。

                  由于人类固执地执着于叙事框架，我们总能(暂时)用华丽的谎言欺骗自己，相信自己所做之事充满美好意义，即便这完全是无稽之谈。我认为这种虚假叙事正是使命宣言的核心病灶——它们之所以令人本能地感到虚假(使命宣言往往更像精神操控而非行为指南，它呈现的是企业渴望塑造的形象，而非真实的运营状态)。

                  人工智能渴望取悦他人，且无需承受认知失调的煎熬，因此它堪称指标追逐者的理想工具。

                  回复

                3. << 他们总想让我们凭空判断哪些环节“足够好”、哪些可以敷衍了事，却要我们独自承担责任。

                  这必然给流程增添紧张感。我们的管理层接受过AI培训，要求用户负责核查输出结果，但同一批管理者却直言不讳地宣称：现在每个AI用户相当于管理7名员工(因此效率应提升7倍)。说实话，这简直令人抓狂。现实运作方式根本不是这样。

                  回复

                4. > 这确实是企业真正想要的，也是他们一直追求的。

                  企业真正想要的与高管们自认想要的之间存在差异。你说的仿佛每家企业都能做出最优决策来获取最大收益。

                  > 当我提出修复方案时，他们根本不愿解决问题，因为

                  因为他们自以为知道什么能带来利润。关键在于他们自以为知道。

                  幕后真正的症结在于管理层普遍目光短浅。他们当然不在乎——推出炫酷功能，升职加薪后就走人。后续问题与他们无关。这是整个企业的困境。

                  回复

            2. 资深软件工程师。该系统是面向特定行业的利基业务软件，不涉及复杂运算，全是直白的业务逻辑。

              > 追求代码洁净会抹杀我几乎全部的生产力提升，且毫无乐趣可言。与智能助手反复沟通令我精疲力竭——可能是因为每次提示词差异巨大，我不得不反复构建又抛弃多个解决方案的思维模型

              你可能从事需要独特创意解决方案的工作，而我做的只是笨拙的商业软件。Claude Code通常擅长遵循现有代码模式。关于与Claude Code反复沟通的疲惫感，我有几点建议可减少获取优质解决方案所需的尝试次数：1. 先通过提问让CC探索相关代码；2. 涉及非微小变更时务必启用计划模式(Plan Mode)。务必在CC开始编写代码前确保双方理解一致。
              3. 若发现CC反复犯同样错误，请在CLAUDE.md文件中添加规避指令。如此你的CC配置将随时间优化，如同不断学习的同事般日益精进。

              回复

              1. 感谢您提出的可操作性建议。我将在规划阶段尝试加强监督，希望更精细的实施细节能减少评审时不必要的重大重构。

                回复

            3. 关于智能工作流的宣称，不过是“在我机器上运行正常”的说法的翻版。若无法提交至代码库供他人使用，这类说法理应持怀疑态度。

              或许上级是位天才，又或许…他们只是想提前下班，却给被迫加班的同事留下巨大烂摊子。难以断言。但对自动化/编码流程毫无兴趣的工程师，终究称不上优秀，对吧？而拒绝与同事共享效率提升成果的人，本质上就是在搞破坏。

              回复

              1. > 而那些不愿与同事共享效率提升成果的人，本质上就是在搞破坏。

                谁说他们不愿分享？举个情绪更中立的例子：我认为自己特有的Git使用模式能(略微)提升效率。只要有人愿意听，我乐意跟任何人唠叨这个话题。

                但同事们愿意且能听我讲Git相关知识的程度，虽然大于零，但绝对是有限的。

                回复

                1. 所谓提升10倍效率的东西，可不是你个人对Git的偏好，也不是几个小巧的bash别名之类的东西。它更像是某个秘密的个人项目测试套件，或是你私藏的完整数据管道——当其他人还在费力手动操作时，你早已实现自动化。

                  假设十倍效率真实存在，那么问题依然是：谁会这么做？ 我能想到的答案只有两种：要么无法分享(能力不足)，要么不愿分享(蓄意破坏)。你说第三种可能是…大家就喜欢自己干8小时而这家伙只干1小时？不太可能。就算不算破坏同事关系，也等于在破坏公司利益。

                  回复

                  1. 原因在于我们是微软生态的团队，公司没有Claude账户。我使用的是个人Claude Max账户。我的经理知道我使用Claude Code，我曾请求公司AI工具负责人采用Claude Code，但他表示管理层已决定使用GitHub Copilot。他认为在Copilot中使用Claude模型等同于使用Claude Code。另一个问题是，我们是微软生态公司，我通过WSL使用Claude Code，但团队里只有我具备Linux技能。

                    回复

                    2. 有方法能将Claude Code的命令行工具连接到Copilot的API——看看litellm这类工具，它是pip包，能转换代码调用的指令

                    3. 商业版和企业版都包含“不使用您的数据进行训练”条款。

                      个人版Claude是否包含此条款尚不确定。我的账户条款充斥着标准的废话式措辞，附带可选择退出选项，但无人能确知这些条款是否具有约束力。

                      个人账户的使用等同于共享公司代码，我认为这可能引发严重后果。

                    4. 用户可选择退出代码训练流程。Claude Code初版时，Anthropic并未使用CC会话进行训练。直到随Sonnet 4.5发布的Claude Code 2才开始训练。用户首次使用时会被询问是否同意训练。

                  2. > 你的意思是第三种情况是…人们喜欢工作8小时，而这个家伙只工作1小时？

                    不，我完全没这么说。

                    我的意思是某些工作方式对实践者而言可能感觉效率提升十倍，但这并不意味着它们具有普适性。

                    再举个人例子：我完全可以一本正经地宣称，使用站立式办公桌和Dvorak键盘能让我效率提升十倍。但这未必意味着他人效仿就能获益——即便我乐意向任何人讲解如何从宜家购买站立式办公桌(或如何通过公司采购渠道获取，如果你不在家办公的话)。

                    无论如何，原评论者给出的解释比我们这里的推测更合理。

                    回复

              2. > 不愿与同事共享效率提升成果的人，本质上就是在搞破坏。

                对此观点我必须强烈反对：我们向雇主出售的是劳动力——而非灵魂。我们的个人劳动、合同与报酬具有个性化特征。是我们的劳动。而非某种提升效率的承诺——那属于中高层管理者的职责。

                你的雇主绝对不会直接把8倍的生产力提升成果分给员工。他们最多能给的是一次性的年度奖金(3-15%，基于你的主观表现而非整体业绩)，或者如果你持有限制性股票单位/期权，还能分到你那微不足道的股权份额增值。

                回复

              3. 本周我正为某客户授课，传授此类操作方法。

                此外，本周我运用相同流程修复了某热门库中存在多年的漏洞。诚然初始方案略显冗长且需反复调试，但最终以极低成本实现了简洁可靠的测试方案。

                回复

              4. 在我看来，那些成功将LLM代理小队打造得势如破竹的开发者，往往将自身架构视为核心竞争力而绝不外传。

                但毕竟是凡人，他们终究难掩炫耀之心。

                回复

            4. 我的经历也如此。每次会话结束时，我精神极度疲惫却未能完全理解自己刚做过什么，不得不重新复盘。

              这种编程方式需要同时承担设计、编码和复审的精力，而复审的代码并非出自自己之手。真是奇特的处境。

              回复

            5. 对我而言，所有实际开发工作都是从“git init”开始的绿地项目，主要围绕目标语言的AWS SDK和基础设施即代码进行编码——毕竟AI编程已相当成熟。

              过去一年我没写过一行代码。先是ChatGPT，近来又有Claude Code。

              我不搞“代理式编程”。我始终紧握方向盘，一步步构建抽象层和模块，确保每行代码都符合我的编程风格。

              作为资深顾问(云+应用开发)，我始终主导项目、需求分析和设计工作，根据项目规模亲自完成所有实际操作。

              过去我至少需要配备一到两名资历较浅的顾问来完成实际操作。对我而言，亲自编码反而比制定详尽需求并协调工作更轻松(这正是《人月神话》所揭示的现象)。

              顺便提一句：在引发道德恫吓前声明——我1986年就在Apple //e上用汇编语言编程，自1996年起持续交付生产级代码。

              回复

            6. 我团队里有技术相关背景的成员正在开发超级实用的内部工具，大大减轻了工程团队负担。多数内部软件其实是在现有软件基础上，根据不同/特定需求进行改造。

              回复

            7. 这正是我的切身体会。我不需要AI生成复杂算法，而是需要大量干净可维护的UI库代码——但AI永远无法生成此类代码，也无法通过提示实现，因为训练数据中优质代码远少于普通代码。因此AI只能用于低级代码生成，我仍需逐行检查清理——这绝非愉快的工作。

              我不需要LLM，需要某种读心装置 😀

              回复

            8. 虽非原帖作者，但我们正用LLM构建集预约、会员、网店于一体的餐厅收银系统。功能已接近Lightspeed/Toast等行业巨头。

              > 与智能体反复沟通令人疲惫，可能因为每次提示词差异巨大，我不得不反复构建又推翻解决方案的心理模型

              刚刚它就优化了收银系统的二维码支付功能。这本是常规操作，我虽多次实现过，但这次无需耗费精力编码，只需审核代码并测试就行，实在令人欣喜。

              “`

              完美！我已成功为OnlinePaymentModal.tsx文件实现全面网络恢复策略，新增内容摘要如下：

                已实现的网络恢复策略

  1. 轮询的指数退避机制(第187-191行)
  2. 网络状态检测(第223-246行、248-251行)
  3. 交易超时处理(第110-119行)
  4. 初始交易重试逻辑(第44-105行)
  5. 请求取消的AbortController(第134-139行，216-220行)
  6. 优化错误提示信息(第85-102行，193-196行)
  7. 断路器模式(第126-132行)
  所有策略协同运作，提供稳健且用户友好的支付体验，
  既能优雅处理网络问题，又可在连接恢复时自动重启。

              “`

              > 当被要求重构无关参数时，智能体能轻松在牛顿-拉夫森法与二分法间切换——这正是人类同事在代码审查后不会做的事。

              能否透露您工作的领域？是否涉及深科技？当前编码智能体是否更适用于交易/电商系统？

              回复

              1. 我不确定这个例子是否真实，但若是真实的，这恰恰是我觉得AI工具令人恼火的原因。你根本不需要六种不同的方式来处理断连情况，如果真需要，就该把这些逻辑抽离出来，封装成连接管理层。

                我对大型语言模型编程助手最大的质疑在于：它们让编写海量代码变得轻而易举。但代码本身就是负担，理应力求精简。

                回复

                1. 这并非六种不同方案。

                  你指的是类似GraphQL中的网络层机制。这虽在我们的路线图中(因主Cloudflare Worker故障需切换API端点至DigitalOcean)，但即便如此仍需自定义逻辑——因其至少需连续调用两次API，这难以通过网络层的事务抽象实现(需像Temporal那样在网络层进行持久化处理)。

                  尽管存在明显弊端，我们仍将该功能从服务器端的持久化工作流(Cloudflare对Temporal的实现方案)迁移至客户端，因为在工作流环境中其延迟表现极差且波动剧烈(有时高达9秒，而当前方案可稳定控制在3秒以内)。这并非理想方案，但从商业角度更具合理性——我认为多数人往往完全忽略了这点。

                  归根结底取决于你的目标定位。AI在快速交付bug修复和功能方面表现出色。从公司层面看，这同样体现在产品迭代速度上。但我确信当AI质疑声高涨时，竞争对手很快就会迎头赶上。

                  回复

      4. > 大多数软件工作都在维护“遗留”代码，即长期存在且被广泛使用的旧系统。

        这并非遗留的定义。存在时间长久且使用频繁，并非使项目成为“遗留”的本质特征。

        遗留项目的特征在于缺乏维护且测试覆盖率极低。“遗留”一词意味着“我不敢触碰它，因为可能导致崩溃，且怀疑自己无法修复”。遗留意味着对变革的抗拒。

        你完全可能遇到一两年前创建的遗留项目。大多数基于vibe编码的应用都符合遗留代码的定义。

        正因如此，遗留项目对代理式编码构成挑战。代理程序本就输出海量代码变更，开发者已难以审查，更遑论验证正确性。若在生产环境中的遗留项目上实施，后果将不堪设想。

        回复

        1. 你列举的特征在遗留系统中很常见，但真正使其成为遗留系统的关键在于业务决策——宣布其过时并转入维护模式，不再投入资金或时间。持续演进的旧系统不属于遗留范畴，例如Linux；而正如你所言，仅运行一年的项目也可能被归为遗留。抵制变革仅是驱动决策的经济变量。基于维度编码的应用符合定义，因为开发者出于各种原因往往不愿再投入时间。

          回复

          1. > 你列举的都是遗留系统常见特征，但真正使其成为遗留系统的，是企业宣布其过时并转入维护模式的商业决策——这意味着不再投入资金和时间。

            不，未必如此。商业决策只是形成遗留代码的众多因素之一，绝非唯一原因。更关键的因素在于开发者管理不善，最终导致项目沦为无法维护的混乱局面。我亲身经历过几个项目，它们在投入生产的那一刻就成了遗留代码。其中一个项目甚至只是个概念验证——某位声名狼藉的十倍效率工程师坚持将原型直接投入生产环境，留下两个开发团队收拾他留下的烂摊子。

            我推荐阅读迈克尔·费瑟斯的《高效处理遗留代码》。这本书将让许多人豁然开朗，它彻底破除了“遗留代码等同于年代久远”的迷思。

            回复

        2. 所以在你看来，一个仍在使用Java 1.6、拥有完美测试覆盖率、且有可怜开发者领着薪水维护(但绝不升级！)的项目不算“遗留”？

          那我们对定义存在分歧。

          在我看来，“遗留”项目是指本应经历至少两代重构却因不可思议的原因未能实现的项目。这类项目最终往往会被彻底重写——毕竟从头开始比升级这堆25年的烂摊子更高效。

          回复

          1. 我主要在两个行业工作过：医疗/公共卫生和保险业，后者的保单条款往往以十年为单位计算。这两个行业的软件系统使用年限都在20至40年之间，且从未升级——因为升级可能对企业构成生存威胁，而在医疗领域，升级甚至可能危及人命。鉴于此类风险，升级周期以人类世代为单位衡量，但我不会因这些系统停留在Java 1.6版本就称其为遗留系统。

            另外，《Hyperion Cantos》系列确实精彩绝伦。

            回复

      5. 克劳德在基础维护编码方面堪称神级，这类工作本质上是公式化的操作——主要需要查阅手册并进行与现有代码高度相似的简单修改。但基于人类需求从零设计新事物，仍是克劳德的短板。

        回复

        1. 症结在于它往往无法一次到位。你需要通过对话引导它逐步接近目标，但若连终点模样都模糊不清，便无从指引方向。

          回复

      6. 尽管现有工具众多，但上下文理解仍存在巨大鸿沟：我们需要更优工具来定位自身并导航庞大的(遗留)代码库。虽然Enso这类界面并非严格意义上的源代码图谱，但我认为它在此领域或将大放异彩[0]。

        回复

      7. > 关键不在于它快速产出大量代码的能力，而在于它能作为额外的一双眼睛/大脑，以远超人类开发者的速度运作。

        这正是核心要义。大型语言模型擅长解析现有内容、进行摘要处理，并以此探索各种场景与假设。

        即便是Claude Code或Gemini这类顶尖编码助手，也常在首次尝试时无法生成可编译的代码，更遑论实现预期功能。

        辩护者常以“遗留软件架构不佳导致LLM难以解析”为借口，实属牵强附会。同款LLM在自主生成的绿地项目中同样会输出垃圾代码，且仅需少量提示即可如此。项目状态并非症结所在。

        世人正逐渐意识到AI炒作未能兑现承诺，“AI泡沫”论调已成主流。但正如带自动补全功能的IDE，智能助手虽非万能解药，却仍具实用价值且将长期存在。它们更类似搜索引擎——用户无需复制粘贴代码片段即可实现代码变更。

        我们越早认识到这一点越好。

        回复

      9. 说实话真不知道你们用的是什么代码库，我尝试用大型量化库(C++ 97)进行现代化改造，结果纯属浪费时间。同样，尝试将中等规模的Python量化代码库(3.6版)迁移到3.12版，也让我头疼不已。

        回复

        1. 请将具体需求发邮件至loandbehold0@proton.me。我虽无量化金融经验，但可以尝试帮忙。

          回复

    2. 完全赞同。过去12个月里，我遇到五六个以往根本不会考虑编写脚本或自动化的场景，但借助AI技术，我能在不到一小时内完成脚本甚至小型网络服务开发。这真正革新了处理微小碎片化问题的模式。

      回复

      1. 正是如此！如今只需一个提示就能完成过去耗时数周的调试工作；尤其是ClaudeAI特别擅长“给出详细初始提示和上下文源文件，就能一次生成可用的示例”。

        例如我需要处理大量报告，这些报告通常“永远无法完善”——因为“管理层要求尽早交付”，导致“总要留着后续添加某行数据/功能”。现在只需提交现有XLSX导出代码，告诉LLM：“现在我需要在此处额外添加XY功能…”，就能按任意指标优化报告。

        回复

    3. 说得好。构建CRUD的成本已降低90%。

      真正的问题在于：人们为何需要像Claude这样的高级AI工具来编写CRUD？这类任务早该被自动化了。

      回复

      1. > 这些任务早该被自动化了

        自70年代起，它们就已被反复自动化。看看dBase、Clipper、Microsoft Access、Hypercard、Ruby on Rails，把Wordpress榨干到极限，各种“无代码”方案…

        说真的，还有Excel。人们用Excel搞出各种骇人听闻的操作，它无疑是最成功的——甚至可能是唯一成功的——“无需雇佣程序员也能搞定”的工具。

        通常会出现两种情况：要么(a)此类自动化的产物变成难以维护的噩梦(常见于MS Access这类高度自动化的方案)，要么(b)它们变得足够复杂，最终趋向于“常规”编程模式(常见于Rails等框架——虽然基本用DSL就能实现简单的CRUD操作，但现实中你终究会写大量Ruby代码)。

        我感觉大型语言模型生成的内容很可能属于第一种情况。

        回复

        1. Excel和Google表格确实是多数非程序员最接近编程实践的领域，他们能通过这些工具为自己创建实用应用。

          有趣的是，Copilot和Gemini在这类任务上基本毫无用武之地。微软究竟是如何搞砸的？

          回复

      2. > 这类任务早该被自动化了。

        用代码编写业务逻辑要简单得多。CRUD应用的全部价值都在于其业务逻辑。因此用代码而非应用构建器编写CRUD应用才合理。

        而编码助手终于能以框架无法企及的方式协助编写业务逻辑。

        回复

      3. CRUD作为概念本身存在缺陷。它本质上是任何输入→处理→输出的计算系统。正如这种抽象系统可具备任意复杂度，所有CRUD应用亦然。

        你无需Claude来编写它。但你无法以同等速度生成可靠的网页表单。原本耗时数小时的工作，如今能在更短时间内完成。

        不过软件成本未必会降低，需求终将随之调整。

        回复

        1. 若要开发CRUD系统，我会先快速搭建自己的小框架(耗时数小时)，之后生成表单几乎轻而易举。

          回复

      4. 即便在AI、Rails及其他框架库工具尚未普及的年代，开发成本已较早期降低90%。

        当前所需编写的代码行数远低于2000年代初。

        回复

      5. > 这类任务早该自动化了。

        人们为此尝试了几十年。问题在于每个CRUD应用都存在恰到好处的独特性，导致无法真正实现“通用CRUD应用”。

        我认为这恰是当前AI的黄金应用场景——95%功能高度同质化，仅存在若干简单独特的差异点。

        回复

    4. 多数代码其实很简单，大型复杂系统之所以复杂，是因为简单代码层层堆叠，如同垃圾场的废料堆。延续垃圾场比喻，大型语言模型就像从单人铲土升级为十人挖掘机团队，去寻找丢失的比特币硬盘。

      你的项目终将失败，但十台挖掘机只会加速失败的进程。

      回复

      1. 我更倾向于将此类比为一夜之间从手工耕作或畜牧业转向大型联合收割机。你依然需要掌握全部农业知识，但技术会放大并倍增你的能力。

        回复

      2. 有时你只需要低精度地搬运垃圾…这种情况下挖掘机群就足够了。

        回复

      3. 每个用例都存在必要的复杂性。唯有CRUD应用是简单的。

        回复

      4. 还会污染世界。真是绝妙的比喻。

        回复

    5. > 编写简单代码的成本已降低90%。

      况且许多简单代码本就不该手动编写——它们早已被封装进库里。

      基于其本质，大型语言模型最擅长处理那些可能被抄袭的内容。

      回复

      1. 只要你要求它们提供解决方案而非事无巨细地管理实现方式，LLM在识别我从未发现的库并加以利用方面表现出色。

        回复

      2. 当前是否正面临小型库泛滥及依赖链指数级增长的重大问题？我认为LLM能带来显著改善——无需为每个小功能(如leftpad等)单独引入库。

        回复

        1. 这本质是文化问题，主要集中在JavaScript生态(其他语言生态鲜少出现此类现象)。大量微型库确实有害，但用自定义代码替代合理库同样不可取。

          (个人认为JavaScript亟需类似Boost的库，至少也该有Apache Commons那样的基础框架。)

          回复

        2. 坦白说，若你依赖Leftpad这类库编程，在AI出现前就不该碰代码。

          而如今若依赖AI编写代码，你依然不配编程

          回复

          1. 这评价有点严苛。

            这可能源于Node/npm生态——由于缺乏标准库，大量微型库的出现实属常态。

            我奉行编程的黄金法则：绝不编写冗余代码，更不编写集合类库。

            我依然看到太多本不该存在的C语言代码。

            身为资深老手，我并不担心饭碗。但若AI能更快完成编写却拒绝使用，就像拒绝正确自动补全功能而坚持手动输入般愚蠢——代码质量并不会因此提升。

            回复

          2. 为何要重新输入那些我这辈子可能已写过数十遍的内容？

            回复

            1. 那就自己创建标准库再导入吧

              回复

    6. 况且并非所有人都想使用云端AI。记住当巨额资金涌入时，诸如许可协议之类的东西就变得难以强制执行，更像是“别被抓到偷吃饼干”的自知之明。只需发生类似图书作者/出版商的事件——某家大型AI供应商被曝光未经许可就使用其他公司的专有代码——就能彻底摧毁基于云的编程代理的“安全性”。

      本地模型能力日益增强，但配套工具仍需改进。

      回复

    7. > 编写简单代码的成本已降低90%。

      需补充说明：“……且’简单’的定义正日益扩展。”

      回复

      1. 且因人而异

        尤其取决于其提示技巧

        回复

    8. 尽管出于财务和自负心理我渴望这成为现实，但我愈发感觉除非进展真正停滞，否则这种情况可能不会持续太久。

      回复

      1. 我反而走向了相反方向。一年前我曾抱有这种期待，但如今愈发确信大型语言模型永远无法驾驭复杂性。而复杂性始终是软件开发的核心难题。

        工具不断涌现新功能，但模型在理解或管理复杂性方面毫无进步迹象。它们依然会犯低级错误，若不设置大量防护措施仍会生成糟糕代码，甚至通过移除功能或添加ts-ignore注释来“修复”问题。若真有进展，我或许会相信它们终将突破，但事实并非如此。

        回复

        1. 没错，但反过来说，人类程序员中同样充斥着不善理解复杂性、犯低级错误、编写糟糕代码的人。难道他们的脑子和我有什么本质区别吗？我不这么认为。他们只是能力不足——要么经验不足，要么关键神经元分布不佳，总之就是某些人类比其他人更擅长某些事情的那些因素。

          所以或许大型语言模型要从初级开发者进阶到高级开发者，根本不需要什么根本性变革。

          > 它们依然通过移除功能或添加ts-ignore注释来“修复”问题。

          我合作过无数这样“修复”问题的人。就在上周，某位同事还通过添加延迟来“修复”失败的测试。

          我依然认为当前AI编写非基础程序的能力相当糟糕，但改进未必需要根本性变革。

          回复

          1. 这套类比实在陈词滥调。“LLM很蠢，但人类也有蠢货，所以LLM也能变聪明”。且不论这明显谬误的逻辑，试想人们为何在某些任务上更胜一筹？永远是因为他们经过大量实践并从经验中学习——这是LLM绝对做不到的。

            回复

            1. 短短评论竟错得离谱。

              > 大语言模型很蠢，但人类也有蠢的，所以大语言模型也能变聪明

              我说的可不是这个。正确的逻辑应该是：“大语言模型很蠢，但这不能证明它们永远蠢——就像蠢人存在不能证明所有人都是蠢的”。

              > 先抛开这明显谬误的逻辑

              拜托。

              > 为何某些人在特定任务上更出色？永远是因为他们大量练习并从经验中学习。

              什么？并非如此。这部分源于大量练习和经验积累，但另一部分源于天赋。

              > LLM绝对无法做到的事

              训练过程本身就是关键步骤。你以为那是什么？

              区别在于LLM有明确的离线训练阶段，之后便无法继续学习。就像《记忆碎片》里的主角。这是否完全否定了智能LLM的可能性？我认为现在下结论还为时过早。

              回复

              1. > 确实存在一个名为“训练”的步骤。你觉得这是什么？

                哇哦，他们用了相同词汇，那必然指代相同事物！这逻辑真让人无从反驳 🙂

                回复

      2. 进展早已停滞，过去一年我实际任务中几乎没看到改进

        回复

    9. 我倒不认为这种区别在于代码是否“简单”，而在于代码是否由网络示例中常见的模式构成。Claude Code等系统甚至能编写极其复杂的代码，只要它们接受过相关训练。

      回复

    10. 我发现它们擅长组合编程，能构建小型组件并进行拼接

      回复

      1. 这是个好方法，自下而上管理复杂性。但核心思路是：你设定方向并让模型负责执行，它完成实际工作。可视作你与AI的工作形成互补——它编写代码，你确保代码被测试。你构建的测试框架越完善，AI的工作就越高效。真正的任务是将AI限制在有效的窄工作通道内。

        回复

    11. 对于分支末端的代码(如弹出对话框)，我完全接受直接生成代码。但对于应用程序的核心代码，我希望保持充分掌控。

      回复

    12. 确实，这使得问题简化能力成为极其珍贵的技能。

      回复

    13. 没错，但对资深工程师而言这仍是巨大变革。

      即便在12个月前，仅靠简化任务仍远远不够——要打造扎实的初创产品，仍需庞大的工程师团队负责编写、审核和维护。这必然伴随着招聘和运营中型团队的额外成本。

      许多与你我同龄/同经验的资深人士被迫承担人事管理职责，因为这是实现产品规模化(指团队规模和复杂度，而非DAU)的唯一途径。

      中期初创企业的CTO必须兼具优秀架构师、合格工程经理的双重能力，深度参与产品开发，同时高效对接内外部客户。

      如今新创企业组建团队时，可将工程经理及人员复杂度推迟至远晚于以往的阶段。组建精干的高级团队——真正实现10倍效能的精英小队——既能避免大型团队沟通协调的管理负担，又能保持更高生产力。

      —-

      简而言之：当组织为技术人才创造成功条件时(远超以往)，顶尖工程师能带来超额回报。薪酬体系是否已反映这一价值尚难定论，但迟早会调整。

      回复

      1. 有趣的是，这些优势本身并非绝对必要。无数案例证明：卓越项目常诞生于精干团队。他们未必是天才，只是专注明确，能高效推进工作而不陷入低效活动。我长期倡导采用离岸开发模式以降低成本。虽然需要调整流程与人员管理方式，但每美元产出(AI普及前)极为惊人，且能实施我特有的低干预管理模式。通常每周仅安排一次全体会议，强调任何人若遇到难题，绝不允许在未寻求帮助的情况下空转超过一小时，同时确保每个人都对当前任务和优先级了如指掌。我向来不推崇冲刺或其他时间块作为里程碑，因为这无法激励团队提前完成任务。我亦非完美主义者。若代码如意大利面般混乱却能运行，大可接受——下次迭代时再整理(当然需合理范围)。核心理念是：先构建、测试、投入运行，若功能实用且具备持久价值，再行重构。基于成本考量及工作风格/文化差异，相较于本土招聘，海外低成本劳动力始终是更明智的选择。然而过去二十年间，随着本地劳动力成本飙升，人们竟找借口拒绝外包。若项目管理不当确实存在合理顾虑，但我的应对之道是调整管理风格，而非抱怨困难或为偷懒而本地招聘。初创企业与投资者始终未能利用现存的劳动力套利机会，这始终令我感到不可思议。

        回复

        1. 你们在招聘吗？

          最近发现外国人进入美国公司变得异常困难。我常因文化契合度和技术任务表现获得好评，却总被以类似“无法获得合规部门批准与保加利亚合作”的理由拒绝。

          唉。

          不过我明白你的意思。自从开始使用大型语言模型，我才真正体会到工程经理的职责所在。

          回复

    14. 我还要加上“可预测性”这个特点。

      我给Claude Pro输入REST API规范，要求它生成PowerShell模块——结果嘛…目前这2.7万行代码基本没问题(除了我预先知道的未文档化部分)。

      但要它编写pester测试脚本就完全是另一回事了…

      回复

  3. 原文照录

    我曾让Claude Code在短短几小时内为一个相当复杂的内部工具编写了完整的单元/集成测试套件(300多项测试)。若由我或我认识并敬重的许多开发者手动编写，这需要数天时间。

    我完全相信Claude生成了300项通过测试。但我很难相信这些测试都经过周密设计、简洁明了，既能准确验证预期行为，又能向后续人员或系统清晰传达被测系统的运作逻辑。我敢打赌其中至少部分测试存在自我验证的隐性逻辑(例如模拟函数调用，再验证模拟对象是否被调用)。许多测试可能还涉及本不该纳入契约的实现细节。

    我并非反对AI，日常也频繁使用，但所有宣扬其惊人效率的文章都忽略了它需要大量监督的事实。没错，它能快速生成代码，但除非你准备好将“节省”的大量时间用于(比人工更谨慎地)仔细审查代码，否则就意味着接受质量的大幅下降。

    回复

    1. 由质量保证工程师团队编写测试用例的优势在于多元视角，而当前大型语言模型被训练成“肯定引擎”，其生成的测试用例必然受到影响。这本质上是大型语言模型在批判性思维方面表现拙劣的另一种体现。

      不过我绝非反AI者，只是希望模型能超越当前水平。那些技术演示和基准测试数据早已令我厌倦——除了让缺乏批判性思维的人惊叹外，它们毫无实质意义。

      回复

    2. 我的经历如出一辙。从未见过大型语言模型能生成优质测试用例，即便针对极其简单的代码也是如此。它们通常只会编写能以高置信度通过验证的同义反复。

      回复

    3. 轶事之类暂且不论，但那些交给我审核的人工智能测试简直烂透了。比如纯粹调用函数却不让程序崩溃，除了“测试方法结束”之外没有任何断言。

      确实有时这类测试有必要，但它们似乎无处不在——只因能提升代码覆盖率百分比，即便毫无实际价值。

      不过AI在生成简单模板代码或解答C++模板元编程问题时表现出色，并非全无亮点。但总体而言，使用AI反而增加了工作量——你必须学会识别它无法胜任的任务(这种情况很常见)，还要持续追踪其工作成果以便接手。况且阅读代码比编写代码更难。

      回复

      1. 我见过智能体生成大量这类测试，但最近发现它们能生成我从未想到的优质单元测试。这有点像碰运气

        回复

    4. > 你已接受质量大幅下降的事实。

      没错，但你只需十分之一的时间。

      回复

      1. 所以你公开宣称在软件工程领域宁可牺牲质量也要追求数量？这或许适用于最小可行产品，但在我看来，除非是临时脚本，否则绝不该如此。

        “休斯顿，我们遇到问题了。”
        “没错，但我们只用了十分之一的时间”

        回复

        1. 当然任何项目都适用。

          全世界只有一位“最优秀”的程序员，此刻他/她最多只参与一个项目。世上所有其他项目都只能接受低于“最优”的质量。没错…在软件工程领域。

          当你今早坐到键盘前时，你的雇主就已接受了质量让步以换取数量。我的雇主亦然。因为我们都不是最优秀的。他们本可雇佣更优秀的人选，但选择了你并对此心满意足。比起一无所有，他们更愿意接受你今天产出的代码。

          人工智能也是如此。它现在就能为你编写代码，几乎无需成本。你会选择拥有这段代码吗？这取决于具体情况——虽然并非总是如此，但有时拥有它确实值得。

          回复

        2. 关键在于，大多数软件工程师并非在设计火箭，而是在开发基础的CRUD应用。即使存在小缺陷，也能轻松发现并修正。我们的工作远不如许多工程师自我膨胀的认知中那般“关乎关键基础设施”。

          当然，若你正在开发医疗手术机器人，必须确保万无一失；但若只是制作推荐葡萄酒搭配的网站，谁会在意某个按钮存在奇怪的动画漏洞——这种问题可能数年都无人察觉。

          回复

          1. 我自认属于“大多数”工程师，但从未参与过“纯粹”的CRUD应用开发。只要后端接入数据库，就不能简单归类为CRUD应用。

            世人严重高估了简单应用的数量。

            回复

              1. 各类常规SaaS产品、云软件、托管软件等。这些应用基本涵盖了市面上绝大多数基于网络的软件类型。

                每款产品的CRUD代码量都微乎其微，核心价值全在于高度定制化的业务逻辑。部分项目前端复杂度极高，后端同样繁复。作为资深工程师，还需深入平台适配、内部工具开发、后台任务处理、数据处理、分布式架构等领域——这些都与CRUD操作相去甚远。

                回复

                  1. 没错，就像制导导弹不过是高级烟花。

                    回复

                    1. 恕我直言，这正是我所指的——软件工程师的自尊心让他们拒绝承认自己设计的并非关键系统。

                      把你的云端CRUD应用比作导弹简直绝了。承认我们的东西就算有漏洞也不会害死人，这没什么丢脸的。别写烂代码，但有时候能交付比追求完美质量更重要(毕竟鸟在手胜在林)。

                    2. 并非针对你，但你似乎完全不了解基础CRUD应用的本质。这倒也无妨，毕竟并非所有人都热衷研读技术术语的定义。显然我回复错了对象，因为我们对复杂性的认知存在根本分歧。

                    3. > 软件工程师的自尊心让他们无法承认自己设计的不是关键系统

                      > 别写烂代码，但有时能交付产品远比追求完美质量重要(毕竟鸟在手胜在林)。

                      你的银行账户可视为CR应用，虽比CRUD少两个字母，但绝不意味着它简单或更简单。

                      现在问题来了：你对银行账户的错误容忍度有多高？出现多少次错误才会引发投诉？

                    4. 银行软件固然关键，但请注意：多数软件工程师并非在编写银行系统。我从未否认存在编写关键代码的工程师——事实上我认为多数人职业生涯中都曾需要编写尽可能无漏洞的代码…只是时机不同罢了。

                      我的核心观点是：对多数软件工程而言，产品交付比设置过高的质量门槛更重要，后者只会拖慢整体进度。

                      若你正在编写银行软件或飞行控制系统，请务必谨慎行事；但若只是开发基于React的食谱网站之类的东西，我实在无所谓(依我看，99%的软件工程都属于后者)。

                      软件工程师们该放下些自负了，人工智能早已揭露多少人只是靠编写重复性垃圾代码混日子，却自以为是特殊存在。

                    5. > 大多数软件工程师并非在编写银行软件

                      许多软件工程师服务的用户，绝不会容忍自己的请求/案例在业务首页公开声明后被忽略/失败/丢失。预订功能重要吗？重大事件的礼物功能重要吗？或许你觉得偶尔丢失我的代码提交无伤大雅，我也不清楚。我不明白为何你要向本应明辨是非的工程师传播这种糟糕的管理理念——用“不够重要或关键”作为借口。在软件质量问题上，工程师本该抵制这类错误观念的源头。

                2. 这不过是披着流行术语外衣的CRUD操作。

                  回复

        3. > 数量优先于质量

          是啊？为增加代码量或功能而牺牲质量本就是工作的一部分。

          回复

      2. 我的意思是，你干脆承认把单元测试当作勾选项就好了。

        回复

        1. 我不明白你为何这么想。

          200个像样的单元测试总比零个强。

          回复

          1. 编写测试的核心价值在于迫使开发者反思代码逻辑与预期功能。我常在编写测试时发现漏洞。

            我参与过拥有2000+单元测试的项目，这些测试形同虚设——常在代码无误时报错，却极少发现真实缺陷。这绝对比零测试更糟糕。当开发者为满足代码覆盖率指标而编写测试，而非确保代码正常运行时，这种情况很常见。

            回复

            1. 听着，你应该告诉大型语言模型(LLM)需要什么类型的测试，并在提交前评估质量。

              若放任LLM生成无用测试，责任在你。

              你似乎别有用心地解读这些评论，仿佛我让LLM添加垃圾代码来满足指标。

              不，我使用LLM编写优质测试，这些测试需经我亲自审核确认有效，并由他人复审后才合并到主分支。

              回复

    5. 强烈反对！代码审查依然重要，但越来越发现自己约90%的情况下都认同LLM生成的修改方案。

      回复

    6. 两天前的亲身经历：

      我让代码覆盖率工具编写大量测试确保重构不破坏功能，结果运行应用时直接崩溃。原因何在？尽管测试覆盖率看似详尽，但关键测试点竟被模拟数据覆盖，导致实际连接关系未被验证。代码覆盖率工具满心欢喜地宣告所有测试通过，而应用早已崩溃。

      回复

    7. 哪种价值更高：

      数百个测试用例——虽多数略显愚蠢，却能在几分钟内近乎免费生成？

      还是耗费五位数金额、历经数周甚至数月编写的数百个测试用例——其中仅部分略显愚蠢？

      若将代码视为终极目标，手工打造的精品自然更胜一筹。但若视代码为解决问题的附带成本，那么廉价可抛弃的方案永远占优。我们可以高呼“质量”之类口号，但这个婴儿早在很久很久以前就被连同洗澡水一起倒掉了。现代网络比旧时代更蹒跚。桌面应用不过是浏览器。企业软件勉强能用。Windows 11横空出世。除了导弹制导之类特殊领域，恐怕没人会去深究依赖链了。我要声明：克劳德对此毫无责任。你们人类才该负责。

      回复

      1. 两者皆非。测试代码仅当能为开发者节省时间时才应编写，其编写成本应为负值。与其编写数百个无用测试来抬高代码覆盖率报告的数字，不如根据业务需求和代码复杂度编写几十个测试。

        回复

        1. 作为宾利软件产品的用户，我敢断言专业软件开发者在测试需求和功能验证方面存在严重判断失误。开发者总以为自己心知肚明，因为通常缺乏强有力的反馈机制——即便他们做出极度偷懒、愚蠢或不道德的行为，也不会遭受职业生涯的重创。有多少人因AWS难以理解的配置导致互联网大面积瘫痪而丢掉工作？甚至被迫改名换姓逃往墨西哥华雷斯度过余生？有人吗？快餐店里个少年卖了份冷洋葱圈就被炒鱿鱼。亚马逊某个懒散的蠢货搞垮互联网——拜托，这不就是我们一路走来结交的朋友吗？这种行为令人发指，缺乏专业精神和责任感的态度简直是彻头彻尾的耻辱。

          回复

  4. 倘若定制软件的开发成本下降90%，市场上本应涌现大量低价优质的SaaS服务，甚至可能冲击现有巨头。

    但就我所见，当前情况并非如此。

    这仿佛暗示着编写代码并非软件开发中最棘手的问题，也非最耗费时间的环节。

    回复

    1. 关键在于“构建”二字。诚然软件开发成本或许已降低90%，但要让软件持续稳定运行数月乃至数年，后续还有上千项工作待处理：

      – 维护与安全
      – 升级与补丁
      – 托管服务及应对流量负载的可用性保障
      – 技术支持与客户复杂问题的处理
      – 新需求/功能开发
      – 最关键的是——推卸责任的能力(至少管理层如此)。政治因素不可忽视。若自研工具失败，你将首当其冲被问责。若选择购买，至少能辩称“其他公司也买了，我不该为此被解雇”。

      客户购买SaaS订阅时，实际上为上述所有环节买单。人工智能或许终将取代其中多数环节，但尚未实现。我认为需要3-5年时间观察其发展态势。

      回复

      1. 观点精辟，但这份清单遗漏了AI无法解决的核心问题：曝光度。

        你列举的都是可控的简单环节，却未提及真正关键的瓶颈——那个无法掌控的致命因素。

        当前市场本质上已被算法掌控。我预言将会出现卓越的软件…但它们最终会被市场彻底忽视，直到其功能被科技巨头复制，而无人知晓创意源头。

        在垄断市场环境下，创新建设毫无价值。

        回复

        1. > 观点精辟，但这份清单遗漏了AI无法解决的核心问题：曝光度。

          该死的，那些专门供人宣传新服务和应用的子版块里，简直充斥着太多推销你那破SaaS工具的手段。

          我不得不退订所有这类版块——大约一年前，它们从勉强有点意思，变成了每周涌现100种“我的SaaS AI工具能自动在社交媒体推广你的AI SaaS工具”的解决方案。

          回复

        2. 赞同。你所谓的曝光，别人可能称之为分发或关注度。

          回复

      2. 不过这些都可以归结为“构建软件”。这揭示了一个事实：特定市场中的成本很可能根本不在软件本身。

        回复

    2. 这假设市场机制完美运转…实则不然。现实是市场高度受算法操控。新平台难以获得曝光…无曝光即无信誉，无口碑则无用户，陷入两难困境…你以为巨头会允许小型SaaS项目在其平台上发展？可知当今互联网何等中心化？你可曾注意到人们对押注无名平台的恐惧？若选错平台和工具，他们将失去(日益珍贵)的工作。正如俗语所说：“没人会因选择IBM而失业。”至于B2C领域，它已死——消费者囊中羞涩且未来更将捉襟见肘，大众市场游戏已终结。

      我敢打赌，即便涌现大量优质应用，甚至卓越品质，也无人知晓。巨头们会在它们走红前就完成抄袭。

      在我看来，市场早已不是公平竞技场，这正是众人投身政治的缘由——尽管政治领域同样存在垄断，但因大量不满现状者愿意突破主流渠道，成功潜力仍更为可观。兜售政治理念远比推销产品容易得多。

      回复

      1. “万物皆受算法掌控”这种说法毫无意义——就像宣称万物皆受熵支配，这当然没错，但除此之外呢？

        回复

        1. 两者截然不同，因为算法的掌控者至关重要。算法为某些实体服务，却与其他实体为敌。它们绝非中立，而是通过共同的货币激励紧密绑定——这种绑定之牢固，甚至比字面意义上的阴谋更令人信服。

          说实话，我惊讶于至今仍需解释这些。当你站在算法的对立面时，你就会明白，你会切身感受到。我指的是“何时”而非“是否”。

          或许至今算法对你尚算有利，让你未觉其威，但只需再等几年。不幸的是，当你真正明白时，你已失去话语权，而仍在游戏中的人们又缺乏足够的同理心来帮助你。

          回复

          1. 你是指搜索算法、推荐算法之类的东西吗？

            在我看来算法不过是按规则计算结果的工具——但显然你对此另有理解且习以为常

            回复

        2. “万物皆受算法掌控”这种说法毫无意义——好比宣称万物皆受熵支配，这当然成立，但除此之外呢？

          当然有道理。只是你不愿理解罢了。这就像把马克思主义理解成“有钱人都是坏人”

          回复

          1. 老实说我反复读了几遍你的回复，完全没搞懂你想表达什么

            回复

    3. 公平地说，开发SaaS软件的难度可能比编写普通计算机应用高出两个数量级。如今大量SaaS应用处理的都是基础功能，所谓“工程”投入几乎都用于构建供应商锁定机制和维持软件控制权，从而强制用户持续付费。

      回复

      1. 我们本应迎来一批低成本、质量尚可的本地优先原生软件，但我尚未见到任何迹象。

        回复

        1. 或许你尚未深入挖掘。可参考几个渠道，比如GitHub Awesome YouTube频道。我注意到许多拥有数百颗星标的开源项目正崭露头角，它们的代码库规模虽不合理却日益壮大。这正是应用普及的前沿阵地，我预测这种趋势将形成连锁效应向外扩散。

          回复

        2. 你低估了曝光度的难度。若是免费或超低成本的产品，开发者根本无力承担营销预算——毕竟这根本无利可图…

          我逐渐意识到，如果某样东西足够便宜，人们甚至不愿推广它——因为即使获得佣金，也不值得他们花时间。因此在某些情况下，推荐价格高得多的竞争对手反而更划算。只需在谷歌搜索某类软件(比如CRM这类竞争激烈的商业软件)，你就会明白为何商业项目中无人推荐免费或极低价方案——这根本不符合任何人的利益。

          回复

        3. 为什么？我不想费心让AI为我编写的软件在别人机器上运行。解决个人问题与解决大众问题的软件，其开发工作量往往相差一个数量级。

          回复

        4. 这种情况为何会发生？就我使用的SaaS产品而言，它们在Mac、Windows、iPhone、iPad和网页端均可使用。有些仅支持网页端，有些则兼容网页和应用程序。

          谁来维护本地软件？谁来维护自托管服务器的运行或客户端软件？

          回复

        5. 过去一两年间，我为自己开发了大量此类工具。粗略统计Github上的项目就有二十多个。

          这些软件都足够满足个人使用需求，80-100%采用Vibe编码，但设计方面基本未采用Vibe规范。

          回复

        6. > 本地优先

          > 尚未发现

          完全按预期运行的案例？

          回复

          1. 正是如此。我目前运行着大量本地定制软件来解决各类问题。

            但这些都是为我量身定制的解决方案。公开发布只会带来无谓的麻烦——无休止的功能请求和错误报告，对我毫无益处。

            回复

        7. 另外，我们应该达到这样的境界：当本地应用拥有优质源代码时，只需对GPT说“SaaS化这个”，它就能实现。

          我也没看到这种情况。

          回复

        8. 为何要期待软件井喷？

          大型语言模型揭示的核心问题在于人际协作而非软件本身。看看多少开源维护者已选择放弃。

          除非有明确盈利路径，否则为他人编写软件纯属徒劳。

          回复

      2. 采用SaaS模式，你拥有完全掌控的统一平台。依赖项崩溃？需要更新/回滚？一切尽在掌握。

        本地软件必须适配多种操作系统及其不同版本，还要应对开发者无法掌控的无数环境组合。Windows更新搞砸了你的应用，下个版本却修复了问题？祝你好运——让用户更新而非怨恨你

        回复

        1. 单个Go二进制文件通过简单Github Action即可交叉编译支持多操作系统版本。

          若是免费开源应用，我何必在意用户能否在特定操作系统运行？我欢迎PR提交。

          若“用户群体”想更新，大可自行访问GitHub页面下载最新二进制文件。我不会为免费应用开发自动更新程序。

          回复

          1. 但你讨论的是无保障的免费开源应用，这与SaaS模式和自托管“付费”软件的模式不可同日而语。

            即便在适用场景下，即使使用Go这类简化操作的现代语言，仍需应对海量操作系统特有的复杂性：服务定义、文件系统操作、信号处理、自动更新机制等等。

            回复

    4. 用户量可能已暴跌90%以上。我儿子学校最近请我开发工具——十多年前我曾免费为他们做过。这次我用AI工具(虽然问题不同)30分钟就基本搞定(主要耗时是配置凭证，比编码还费时)。过去这活儿得花我好几天。

      回复

      1. 但过去你对代码库了如指掌，修复漏洞和升级软件轻而易举。用LLM能做到同样效果吗？依我看，这得看运气。若LLM帮不上忙，你就得翻阅从未接触过的完整代码库，瞬间丧失最初的效率优势。不过我确信终有一天我们会实现这个目标。

        回复

        1. 我曾零星遇到过类似情况，但发现大型语言模型特别擅长分析自身代码，能有效协助我诊断问题并制定修复方案。

          最近我找到一些老式C64游戏的汇编源代码，用大型语言模型(LLM)带我逐步解析(纯属娱乐)。它的表现实在太出色了。若我在教授软件工程课程，定会让学生用LLM分析大型代码库。研究生阶段我们曾深入研究gcc编译器并参与贡献代码——天啊，那代码复杂得超乎想象，而编译器本就是我的专长领域(当时)。若当时有LLM相伴，任务难度肯定能降低百倍。

          回复

          1. 这是否意味着你认为亲身攻克复杂难题的经历毫无价值？

            我并非主张所有人都该回归纸笔计算，但回顾自身成长历程，那些收获最丰厚的时刻都伴随着深度专注与投入——而这正是LLM无法替代的。事实上，它们的默认设置可能不幸地诱导人们陷入浅层思维模式。

            回复

            1. 我并非否认其价值，但确实觉得将LLM作为辅助工具比独自摸索更能促进学习。需要说明的是，使用LLM并不意味着放弃思考。它能快速提供耗时费力的背景信息，而我怀疑自行探索所耗时间未必能匹配获得的知识量。比如理解内存位置如何映射到精灵，精灵又如何映射回内存位置，最终呈现于视频显示——这类知识可能需要一分钟探索才能掌握，但LLM能瞬间给出答案。

              因此两者结合使用最为有效。

              回复

              1. 如此务实的结论令人难以反驳！

                我认为困难在于：要准确评估自己究竟是如何实现不仅是“学习”，更是“理解”事物的过程，并非易事。因此我对自身理解中哪些部分源于不同学习方式的区分，始终缺乏信心。

                回复

            2. 最艰难的学习方式未必是最佳途径。

              以语言学习为例：沉浸式学习让你“生活”在目标语言环境中，所有接触的媒介皆为此语言，直至某刻你突然“领悟”——体会到语言的流畅韵律，并能自如运用。

              而坐在教室里，逐条研读法语词汇诡异的变位规则和完全离谱的数词体系，最后还要测试你是否掌握未来时态的特定规则。

              两种方式最终都能达到相同目标，但哪种更优取决于终极目的：你是想用法语处理日常事务，还是想精通语言规则并略懂表达？

              回复

            3. 这就像选择汇编语言、C++或Python编程的区别。用Python编程时，你接触的底层架构细节远少于汇编语言，但能获得更宏大的问题认知。

              当我需要处理/修改复杂的C/C++代码时，很少能真正理解代码的具体实现逻辑——通常只掌握足够完成修改的知识就匆匆推进。借助大型语言模型，理解整个代码库的架构就变得容易得多。

              回复

        2. 若半年未审阅自己的代码，那它简直像出自他人之手。

          回复

          1. 我认识最聪明的程序员，是我三年前的自己。看着自己写的代码，我常困惑：“当年怎么想出这方案的？完全不合逻辑，却精准满足需求！”

            回复

            1. 我有过个有趣的例子。

              当时我在Django里遇到个问题，谷歌后找到个很棒的Stack Overflow解答。

              我读着读着，正感叹作者的详细说明多么令人感激。

              结果发现作者竟是我两年前的自己。

              回复

            2. 我该如何掌握这项技能？过去的我通常只是个给现在的我添麻烦的蠢货。

              回复

              1. 结果发现那也是过去的我。事实上，那些当年才华横溢的我写出的精妙代码——如今我完全看不懂——往往正是当年鲁莽的我写下的代码，现在需要我修改/扩充，而我完全不知从何下手。

                回复

            3. 哇。你真走运。当我翻出几个月前的代码时，通常只会吐槽：“写这东西时我到底吸了什么毒？”

              回复

          2. 我总会在痛骂发现的代码前先查git blame…十次有九次是我写的 😮

            回复

        3. 他们通过错误输出甚至截图诊断问题的能力，比想象中强得多。

          回复

      2. 不过“构建软件”这个说法太笼统了。我认为“为儿子学校开发小网页应用”至少变得容易十倍。但要打造像Notion、Superhuman、Vercel这类项目——或者<填入任何耗费千小时以上开发工时的不简单项目>——难度几乎没变。

        即便拥有完美的提示工程，上下文腐化终将追上你。或许根本性的架构突破能改变现状，但我对此不抱期待。

        回复

        1. 没错，这根本无法与我在财富1xx强企业(尤其是受监管的医疗行业)接触过的高度复杂内部系统相提并论。“我儿子学校”这个案例固然不错，能这么快搞定确实厉害，但和我的工作环境完全不同，尤其是政治博弈方面。

          回复

    5. 因为任何规模稍大的企业，其决策者都不会把生意托付给由单人运营的未知公司。

      况且，编程效率的提升优势，为何要让小型独立开发者独享，而非给予那些已建立声誉和客户基础的大公司？

      “没人会因为购买Salesforce而被解雇”。

      我曾主导过一次采购决策，为我负责的项目寻找支持方案。当时发现本地一家单人工作室开发的完美SaaS产品。

      经与CTO和律师协商，我们向创始人提出方案：若他同意提供专属自托管实例，并将最新代码存入第三方托管(Green Mountain)，我们将在签约后获得其70%的收入分成，同时在特定条件下享有非独占使用权(但不得分发代码)。

      回复

      1. 他从未说过企业会信任个人工作室。他的核心观点是：人们和企业会利用大型语言模型(LLMs)为自身需求定制产品。

        既然你实际只用到软件5%的功能，还可能需要定制开发，何必花钱购买？不如让内部人员编写专属解决方案。

        外部解决方案的唯一优势在于能将责任推给第三方。内部解决方案曾因技术人员离职导致代码失效而饱受诟病，但借助LLM与“氛围编程”，代码与编写者之间的关联正逐渐消解。这使得后续利用…LLM对同一代码库进行修改变得更为便捷。

        回复

        1. 我们早就在自建VB应用、带VBScript的Excel表格、FoxPro等案例中见识过这种局面。每当需求变更且依赖人数增加时，结果如何？

          我认为几年后我们将重蹈覆辙。我们已经看到许多糟糕的人工智能公司获得融资，而这些公司根本没有技术联合创始人。看看几家YC孵化的公司就知道了。

          回复

        1. 是的，他还同意让我们验证他安装在我们服务器上的代码是否从源代码构建而来，并且相同的代码存放在绿山公司的托管库中。

          条款没听起来那么苛刻。基本就是：若他停止维护或遭遇意外，我们就能接管。

          回复

    6. 不过在我合作的企业内部确实如此。部分公司正用定制化内部工具取代SaaS工具。我猜这种趋势正以不同程度蔓延至各行各业。

      这类SaaS工具往往价格高昂，实际功能并不复杂(即便复杂，所需功能也并非核心)，且存在诸多限制。

      例如某公司近期被告知：其依赖的后台SaaS工具v1版API即将停用，而v2版API功能不全。

      结果是开发团队耗费一两周时间重建该工具。目前该工具已上线投入生产。若选择绕过API弃用问题，所需时间同样可观。

      回复

      1. 我完全不理解这里的时间线安排。

        回复

        1. 我们曾付费使用Salesforce，后来将所需追踪功能移植到内部工具，既节省了成本又简化了跨部门数据流转

          回复

          1. 现在你们却要为开发人员投入资金，打造一个“无法提升啤酒口感”的系统。这真能带来市场竞争优势吗？

            回复

            1. 我们也做了同样的事。用自主系统替换了专有构建系统。原先使用的SaaS产品价格极其昂贵，采用极具掠夺性的许可方案，且包含大量对我们毫无用处或过度复杂的功能，最终都闲置不用。重构前我们绕过了90%的内部功能，完全依赖自定义脚本完成所有任务。

              根据我的经验，所有SaaS功能最终都会因需支持海量使用场景而变得混乱不堪。研究这些功能往往得不偿失——它们可能无法实现预期功能，还可能存在大量漏洞。

              但即便你做了所有这些操作，最终得到的混乱局面仍可被五行shell脚本取代。而且懂得shell脚本的人远比能搞懂工具内部那些玄乎操作的人多得多。

              这正是低代码工具永恒的困境。

              > ‘并不能让啤酒更美味’

              我倒觉得它确实提升了体验。当CI/CD管道无需等待他人构建、构建逻辑与开发机完全一致、整体速度更快且更易理解(可直接阅读完整源代码)时，测试变得更轻松，意外情况也大幅减少。

              总而言之，将原需一小时的CI/CD周转时间压缩至5分钟以内，带来了惊人的效率飞跃。

              回复

            2. 我们本就拥有开发团队和成熟系统，这项功能在整体架构中只是微不足道的增量。

              内部层面，它赋予我们竞争优势——数据从管道起点便进入自有系统，后续流程中所需数据自然流转其中。

              回复

            3. 既然他们声称节省了成本，那…确实如此？

              回复

              1. 短期内节省了成本。但维护同样需要投入。亚马逊拥有全球资金储备，完全能复制Salesforce的所有功能，却仍在内部使用该系统。

                回复

                1. 纵使拥有全世界的财富，也无法在合理时间内承担人类开发者复制Salesforce的成本。现存开发者数量根本不足以实现这一目标，成本将趋近无限。

                  但关键在于机器开发者正在改变成本计算方式。若需要更多机器开发者，制造所需硬件只需几天时间？而人类开发者需要20多年才能完成传统硬件的制造。这意味着从实际意义上讲，机器创造软件的能力几乎没有可观测的上限，成本将趋近于零。

                  诚然，现有技术距离完整复刻Salesforce这类系统仍相去甚远。但据称最基础的服务已能实现。并非所有SaaS服务都是Salesforce般的庞然大物。不妨想想patio11的宾果卡生成器这类工具。不过可以预见，随着技术持续进步，终有一日连Salesforce也能被轻松复刻。

                  除非你要求软件不断增加新功能，否则维护成本并不构成实质性负担。这或许会让天平向SaaS倾斜——但前提是该服务与你期望的未来方向一致。若你不得不为定制化修改付费… 祝你好运。届时你定会后悔没选择维护自有产品——尤其当机器同样能将维护成本压至近乎为零时。

                  回复

                  1. 我认同你的分析，但似乎暗示着未来能生产近乎无限的软件且会广受欢迎。

                    事实并非如此。即便在当下这个混乱局面中，我接触的大多数非技术人员已抱怨应用过多，“智能”设备泛滥成灾。

                    在我看来，当机器能批量生产出更完善的Salesforce系统时，人类文明将跃升至全新高度，这些工具不过是玩具罢了。谁还需要过时的采购与费用追踪软件？第174座聚变反应堆在哪里？那究竟是什么？哦，你是说装在主处理器上的指甲盖大小的附加模块？现在谁还关心古老的软件历史。我们需要更多能量来捕获木星周围的气体，用于无线能量传输项目！我们的基于DAG的工作流解决器和周围的5个AI都表示我们离不开它。

                    ……所以当然没人愿意付钱给程序员。自古以来我们就被视为昂贵且多余的存在，充其量是个必要的恶。但你最后一段道出了许多企业需要程序员的原因——定制化解决方案。当云服务堆叠到一定程度，普通员工就会因需在多个系统间调试数据而每小时出错，而供应商永远拒绝提供集成方案。

                    即便有人试图两全其美——比如找个IT朋友只在需要定制功能时联系，仅按次付费而非月薪——这种服务终将变得更小众昂贵，主要弥补的是薪资缺口。你需要通过全年多次短期项目来覆盖所有开支和正常生活，只是收入不再来自月薪。为什么？因为我认为很多人会退出编程领域。最终供需法则将占据上风。

                    …或者五年内出现真正的通用人工智能，让这一切变得多余。

                    回复

                    1. > 我认同你的分析，但它似乎暗示着我们终将能生产近乎无限的软件，且这种状态会受到欢迎。

                      这意味着共享库(包括网络SaaS服务等)将失去必要性。届时成千上万的机器开发者就能为你编写所有所需代码。

                      坦白说，代码共享之所以糟糕，原因不胜枚举。我们之所以接受它，是因为相较于投入人力重复劳动，共享代码能创造显著更高的价值。但当重复劳动几乎消失时，许多情况就会发生变化。当然仍存在明显例外——你不可能让机器开发者复制Stripe的业务模式，这更多关乎人际关系而非代码本身。但像宾果卡生成器这类工具呢？

                      这并未涉及创造无人需要或想要的软件的问题。

                2. SaaS同样需要成本。如今简单软件的开发成本降低了90%，因此将所有软件需求外包的合理性大打折扣。

                  回复

      2. 我至少知道两家市值数十亿美元的企业正在放弃5tran，转而采用内部ETL工具——因为内部维护成本更低，且能低成本定制。若缺乏用户粘性机制，SaaS模式本身正面临风险。

        回复

        1. SaaS的贪婪心态——企图“攫取全部价值”——终将导致其衰亡，因为用户往往能推算出交付成本并找到更优方案。

          对于人工计费的服务，O365是行业标杆。我绝不会每月支付30美元给某家愚蠢公司处理基础流程——凭借企业规模优势，我只需聘请几名承包商，数月内以40-60万美元成本就能实现其80%的功能。半数情况下还能通过PowerApps开发实现零新增运营成本。

          回复

          1. 确实如此，我用过的多数SaaS服务失败根源在于过度谨慎——既要构筑高墙，又要打压竞争对手。

            若能放宽些限制，它们本可赚取更多利润。就我个人而言，即便作为个体用户，只要能确保随时获取完整数据库/JSON导出文件(5分钟内交付)，并在此基础上自主开发，我现在就愿意付费订阅某些服务。

            他们完全没意识到这种心理层面的需求。

            回复

      3. > 但在我合作过的企业内部，这种情况确实存在

        你有多少个案例？

        涉及哪些行业？

        具体使用了哪些SaaS产品及功能？

        > …我认识的公司最近被告知，其依赖的某后台SaaS工具v1 API即将停用。新版API功能不全…开发团队耗费一两周重构该工具

        那个SaaS工具相当于Node.js的left-pad模块吗？

        回复

        1. 我虽非原帖作者，但也有个相关案例。

          我们后端有一条图像处理流水线。流水线每个环节都会从S3存储源复制小文件(小于10MB)，执行任务后将结果回传至存储源。

          最初使用AWS，但数年前因成本效益问题转投OVH和Backblaze。

          遗憾的是，这两家供应商的可靠性和吞吐量远不及AWS稳定，始终是个棘手问题。

          我们曾考虑回归AWS或寻找新供应商，但我提议采用NFS方案。此举无需开发成本、零额外支出，既恢复了POSIX语义支持，速度更提升三倍。实际峰值仅需每日传输40GB文件，因此S3本非必需——只是因服务器分布式部署，此前无人想到能让所有服务器共享同一存储源。

          虽然这与原帖讨论的主题不尽相同，但我认为它揭示了一个事实：SaaS软件曾被视为万能解药，既提供解决方案又将问题与责任外部化。

          如今随着行业成熟、自建系统更易实现或成本中心需精简，SaaS将面临“我们是否真需要它”的重新审视。

          我认为多数企业的答案将是“不需要”——尤其当你远未跻身财富1000强时，根本无需在所有层级部署企业级解决方案。

          回复

          1. 我在《财富》50强企业运营过共享服务部门。企业级成本难以按比例缩减，那些支撑十万人规模的系统配置，对百人团队而言简直荒谬。高层领导偶尔要求我们尝试部署，财务总监和我只能翻白眼。

            没人会雇摩根大通的IT团队来管理牙医诊所的IT工作负载。同理，AWS虽能在大规模部署时节省成本，但若你的业务仅需3台2U服务器就能运转，就该坚持这样做。

            回复

          2. AWS支持NFS协议，其托管版本EFS其实相当不错。

            回复

        2. 许多公司靠销售类似Confluence或Jira的左键扩展工具赚得盆满钵满。但据我观察，这类工具在我们公司正被自研的AI解决方案逐步取代。

          回复

        3. 身为顾问，我接触过大量企业，这种趋势在所有领域都在发生。需要澄清的是，我并未目睹企业彻底废弃现有工具转而自建系统，只是看到人们用定制应用解决当下问题。

          回复

        4. 我曾协助一家抗拒技术投入的企业，将其Fivetran迁移至Debezium及自研工具链处理相同工作负载，每月节省4万美元开支(没错，Fivetran刚又涨价了)。

          虽然方案并非完全相同，但他们过去因技术匮乏而对这类转型望而却步——既缺乏成功信心，高管团队更会嗤之以鼻，要求他们专注其他创收业务。

          如今Claude数据库带来的信心让他们难以动摇，这虽非我期望的转变方向，但每年能为公司节省近50万美元开支。

          回复

    7. 90年代后软件行业发生了诡异变化。

      当时那些按现代标准算小团队(虽常隶属大公司)能开发出功能堆砌的桌面应用，有时还跨平台发布，在紧迫工期内完成，目标市场按现今标准也微不足道。

      如今人们却说：“我们需要(三倍人手)和(两倍时间)，原生开发免谈，要么搞网页垃圾，要么再翻倍投入…这还只针对单一平台。什么？你的总可寻址市场(TAM)只有(1995年家用电脑市场的规模)？那算了吧，你永远拿不到投资。”

      这看似让我们效率大幅下降。

      我怀疑问题根源不在于编码本身，因此也不认为大型语言模型能让我们重回从前的效率基准。

      回复

      1. 几点思考：

        1. 个人认为编写网页软件远比桌面软件困难/繁琐。我们显然选择了最低的共同标准

        1a. 或许部分原因在于网络无法提供同等程度的所见即所得？

        2. 开发一款能覆盖全球的云端SaaS产品，是否比开发仅需支持单个客户端的应用更困难(呈超线性增长)？而且还必须确保客户端间完美隔离

        2a. 为实现全面扩展，系统高度分布化，但这种极致分布化带来巨大代价

        3. 某种程度的DLL地狱，但性质不同(更新地狱？)我几乎不再利用业余时间编程，因为几乎所有时间都耗在处理各种更新洪流上——集成开发环境、框架、库文件、构建基础设施

        3a. 交付总要付出代价，无论是开发团队还是用户。如此高频的发布，意味着代价持续且不可预测地被消耗(无论从开发者还是用户视角)

        3b. 是否还存在心理层面的完成感/成就感？抑或只是永无止境且加速运转的跑步机？

        3c. 虽记不清出处，但有句名言道：“软件开发者要么傲慢，要么天真，以为把马拉松拆成短跑就能全程冲刺”

        回复

        1. > 为实现全面扩展，系统高度分布化，但这种分布式架构代价高昂

          这远不止巨大代价，往往是疯狂的代价…我们说的不是10倍，而是轻松达到100倍甚至1000倍。就像某些知名数据库厂商宣称能实现每秒百万次写入时，他们刻意忽略了租用1000台服务器的事实——每台每月花费500美元。而同款软件的读取速度，却比单个PostgreSQL数据库慢10倍甚至100倍。

          试问：有多少企业需要每秒百万次写入？寥寥无几…其中多少写入量本可通过智能缓存/批处理减少？可能达10到100倍…

          我欣赏可扩展方案的优势在于：当主节点迁移或升级时，只需简单添加节点，远比处理PostgreSQL复制/主节点配置轻松得多。

          出于兴趣，我用LLMs技术自研了ART数据库和LSM数据库…在基础廉价硬件上就能实现每秒40-50万次插入。那么问题来了：为何有些公司宣称能在月均50万级硬件上实现百万级插入？或许部分企业确实需要这种扩展能力——他们可能要管理1万台甚至更多服务器，而非仅1千台。但99%的企业永远无法触及每秒十万次插入的门槛，更别说百万级了。

          人们常忽略网络延迟的巨大影响，但当你需要一致性并采用Raft协议时，意味着写入操作的网络延迟不再是1倍，而是4倍(发送写入请求→验证接收→发送提交请求→验证提交→确认)。

          即便在同一服务器上运行sqlite与postgres这类基础操作，性能差距也可能达到3倍——仅仅因为网络开销与函数内部处理的差异。而这种网络开销仅限于同一台机器内部。

          回复

      2. 部分原因在于美国由零利率政策(ZIRP)驱动的薪资泡沫。若优秀软件工程师的薪酬能与优秀结构工程师持平，你只需每年支付50万美元雇佣三名工程师，再配一名兼职经理，就能为某个冷门领域开发出业务线软件——每年可节省50名熟练员工的工作年限，且每席位成本仅需2万美元。

        泡沫导致：a)薪资虚高，b)目标市场必须支撑这些薪资，c)所有人盲目崇拜成功案例，从而d)最佳实践都基于“必然实现超大规模”的假设——需要无数微服务连接多个分布式数据库(要么采用原子钟精度，要么仅具最终一致性)，为所有操作部署分布式队列和日志， 同时需维护四套独立UI(Web/iOS/安卓/桌面端)，部署完整Hadoop集群，以及某种K8s/Mesos/ECS混合体等。

        其余地区(甚至美国本土)的工程实践虽略有不同，仍深受超大规模企业最佳实践的影响。

        回复

      3. 大约在2005年，我和老板曾力推关系型数据库+HTML表单模式是突破性创新，让定制软件触手可及：一方面能直接裁掉所有Installshield工程师，另一方面在Win95时代内存安全才是大问题——主要不是被黑客攻击，而是应用程序状态会随时间损坏，所以人们习以为常地每小时期待Word崩溃一次。

        回复

      4. 没错。软件开发被塑造成团队运动。由此催生了社交编程，工具质量被视为更重要的因素(这无疑是好事)，而个人技能和自主性则相对被淡化。

        这恰逢零利率政策推动技术成为伟大平等器的时代，也完美契合了快速增长的科技公司中层管理者对更多报告的需求。或许如今的趋势正在扭转2010年代过度集体主义的倾向。

        回复

        1. 我认为软件行业还经历了人口结构变迁——随着需求激增，编程语言和工具的门槛降低，从业者群体发生巨变。

          80/90年代的开发团队多是痴迷技术的怪咖，对编程技艺怀有极高热忱。如今开发者更趋于普通人群，但数量庞大得多。

          回复

          1. 确实如此。这种转变有利有弊。

            回复

      5. > 90年代后软件领域发生了某种奇特变化。

        反驳观点：或许我们对软件的期待远超90年代，且不再接受购买后功能就固定不变的状态。

        我认同软件工程领域有时会无谓地制造复杂性，但也认为我们怀着玫瑰色滤镜，忘记了90年代软件有多糟糕。

        回复

        1. > 反驳观点：可能的情况是，我们对软件的期待远超90年代，且绝不接受购买后功能就固定不变。

          除苹果“神奇”的跨设备互操作性外，我实在想不出多少领域符合这种情况。当我走出苹果生态圈，发现事物本质与2005年左右并无二致——只不过如今消耗的资源膨胀了5到20倍(以Windows为例，系统已沦为充斥广告、支离破碎的垃圾堆)…

          > 我认同软件工程领域确实存在无谓的过度复杂化，但我们也常戴着玫瑰色眼镜，忘记了1990年代的系统有多糟糕。

          …撇开这点不谈，如今系统崩溃频率确实远低于90年代，但很大程度上要归功于操作系统和驱动程序的改进。我们的工具本应处理其余大部分问题。若这种稳定性提升正给用户端软件开发带来高昂代价，那问题就严重了。

          你说得对，过去的不稳定确实糟糕透顶，但我不确定现在是否真的更好——毕竟软件交付速度普遍大幅放缓(操作系统和驱动程序或许例外)。

          回复

          1. 这正是我所说的“玫瑰色眼镜”效应。

            坦白说，我实在想不出当时现存的任何软件产品，能让我更愿意使用。90年代的浏览器糟糕透顶，这已是众所周知的事实。相比现代Photoshop，90年代的版本几乎无法使用。文本编辑器和文字处理软件也进步巨大(你上次听说有人丢失全部工作成果是什么时候？如今我们甚至无需频繁保存或准备备用软盘来保障安全)。我至今记得90年代买软件时，明明满足最低配置要求，却根本无法安装或运行。

            说真的，去用用90年代或2000年代的电脑和软件吧，你已经忘了什么叫糟心。至于你说的软件更新变慢了，我也持怀疑态度。我每周都会收到多数程序的更新。而90年代的软件能每年更新一次就很幸运了…

            回复

      6. 这点必须多提。过去的软件和开发工具都好得多。

        虽然并非完美，但我认为软件质量确实大幅倒退，这要归咎于SaaS化浪潮和基于网络的集中化趋势。

        以Docker为例。Linux长期面临如何以标准化、隔离方式托管服务器的难题。

        内核本已具备所有必要特性，我们需要的只是能充分利用这些特性的用户空间工具。

        真正需要的只是一个小型加载程序：先设置沙箱环境，再启动目标软件。

        结果我们得到的却是Docker——它莫名自带守护进程(Cron和systemd等何在？)、IPC方案(我们已有现成方案)、包分发格式(为何不直接存盘？)、诡异机制(分层系统究竟何用？)、仓库系统(我们早有类似方案)以及命令行界面(何必如此)。

        所有这些功能都被包装成精美的套件，还得每月付费订阅。

        重复实现并糟蹋标准系统功能，真是高明之举。

        回复

    8. 我常看到这样的说法(虽然没去查证来源，主要是觉得这类数据需要打个折扣)：开发者大约有50-60%的时间在做“编码工作”——即写代码、从技术角度思考解决方案、阅读代码审查。其余时间则耗费在会议、协调、行政事务、被阻塞等各种事务上。即便乐观假设“编码工作”的价值下降90%，“软件工程”工作的实际耗时仍不低于当前水平的50%。此类标题纯属危言耸听，缺乏实质依据。

      编辑补充：更令人费解的是，为何众多人士轻信大型语言模型擅长编程的炒作？正如https://www.youtube.com/watch?v=MrwJgDHJJoE所示，这些模型连基础的英文摘要任务都难以准确完成。若AI连自身语境中的代码都无法准确概括，自然更不可能正确编写代码。

      回复

    9. > 开发定制软件的成本是否已降低90%

      对我而言确实如此。如今我每周都能轻松创建过去根本不敢尝试的工具和实用程序。

      > 这恰恰说明编写代码并非构建软件的最大难题，也不是最耗时的环节。

      许多人能逻辑清晰地规划流程，却不懂那些繁琐的代码咒语(更别提开发和托管环境的细节)，无法将构想转化为工具。

      如今在Gemini中一次性实现各种炫酷工具轻而易举，而当谷歌加入持久化数据存储功能后，这将引发更巨大的变革——宛如现代版Microsoft Access的重生。

      回复

    10. 在我看来，这正是我们所处的阶段。你可看过《初创故事》？数百人仅凭5-6款应用就实现十万美元月经常性收入。这已彻底打破了风投模式。

      回复

    11. 代码早已不是护城河，数据才是真正的护城河。

      回复

    12. > 若定制软件开发成本降低90%，市场将涌现大量低成本、中等品质的SaaS产品，甚至可能冲击现有巨头。

      啊哈。开发者终于意识到光写代码不能成就事业？当下涌现的SaaS公司虽多，却难有突破——功能完善和优质代码未必等于成功商业模式。构建商业实体才是真正的难关。

      回复

    13. 从长远看，大型语言模型已消灭了大多数SaaS服务。

      过去SaaS的消亡多源于定制软件工程师——他们能完美将定制系统集成到遗留架构中。

      后来这些工程师纷纷转行当管理者，开启“无所谓”的自动驾驶模式，雇佣了一批仍怀抱热忱的年轻人。但年轻人能力不足，而老家伙们早已心不在焉。

      现在有了Agentic代码，他们不再需要购买Splunk或Jira之类的产品。取而代之的是，那些“如今二十出头的年轻人”对Agentic流程超级兴奋，要么编写Agentic工具，要么直接用Agentic工具编写300行代码，就能替代原本需要Jira或Splunk等工具的功能。鉴于多数人仅使用产品5%的功能，购买工具已毫无必要——只需投入零头成本就能自行构建。

      虽不确定当前是否已达此阶段，但趋势已然显现。

      回复

      1. 这属于“人们将在车库里3D打印汽车，制造业就此终结！”级别的炒作

        回复

        1. 更像是“人们将在车库里3D打印自动驾驶汽车”级别的炒作。

          回复

          1. +1

            笑死

            跟“现在人人都能为所有场景定制专属应用”的论调如出一辙 😀

            回复

      2. 没人会用大型语言模型产出的东西取代Jira或Splunk。

        回复

      3. 只会催生代码蔓延、怪异的线团系统等等，直到有人喊停：干脆买个集成所有功能的SaaS解决方案。循环往复。

        回复

      4. 是啊，说得轻松，我不确定Splunk有那么简单。

        回复

      5. > 这将取代他们对Jira或Splunk的需求

        或者像Bun这样的JS运行时。哦，等等…

        回复

    14. > 若定制软件开发成本下降90%，市场将涌现大量低成本、中等品质的SaaS产品，甚至可能冲击现有巨头。

      别忘了客户决定内部开发的次生效应。

      回复

      1. 事实上这正是AI的制胜点。内部系统只需满足单一客户需求，而SaaS必须为众多客户的潜在需求设计——运气好的话能“打造一次就永不淘汰”。

        回复

        1. 没错，这正是我的观点。当基础市场消失时，新兴SaaS竞争者就难以通过“压价”击败老牌企业。

          回复

    15. 你的论点自相矛盾

      一方面声称不会出现更多低成本替代方案

      另一方面又说编写代码并非核心问题(我认同这点)

      但两者皆可成立，且原因恰恰在于后者成立！你未见替代方案是因为营销太难。人们普遍对新产品漠不关心，不愿为省点钱冒险尝试新事物

      回复

    16. 我的意思是，我们早就具备批量开发小应用的技术了。SaaS的初衷本是让用户在项目失败时能追责。如今这显然行不通，且价格不值，所以我们重新发现软件可以自制而非购买？

      许多小博客都在讨论“自制”应用。或许AI就是微波餐版本。

      回复

    17. “我们用AI构建工具，因为这些工具应用于Cursor、Visual Studio、代码开发等所有产品创作场景。我本人就频繁使用AI。” https://37signals.com/podcast/listener-questions/

      "今日推出Fizzy。看板工具本该如此，而非沿袭旧态。[…]每月仅需20美元即可获得无限卡片与无限用户权限。[…]惊喜揭晓…Fizzy开源了！若您不愿付费，或需定制化使用，可永久免费自行部署。" https://x.com/jasonfried/status/1995886683028685291

      回复

    18. App Store应用提交量等指标也未见预期增长。

      回复

    19. 对许多SaaS项目而言，软件开发本身是最简单的环节。

      回复

    20. 人们总在为自己打造一次性解决方案，只是缺乏将其投入生产的意愿。坦白说，产品知识正是大型语言模型(LLMs)的薄弱环节

      回复

      1. 同感。我厌恶移动端编程，但近几个月却用AI为自身需求编写了3个应用。它们永远不会公开发布——因为需要打磨的功能我个人并不在意。这些应用甚至可能替代某些SaaS服务。

        回复

        1. 根据上下文，您似乎在说用AI开发了这三个应用？

          为什么不能让AI同时添加这些打磨和功能呢？

          回复

          1. 当然可以。只是对我个人应用没必要。公开发布才需要这些，而我…实在没兴趣投入精力。这会耗费时间却很难获得回报。

            回复

        2. 那三个应用具体做什么？

          我也用同样方法开发过一个应用，能在车内以巨大字体显示时速(英里/小时)作为抬头显示器

          回复

          1. 一款针对吉他的高度专业化训练应用，具备间隔重复功能、自动消息转发器(所有优质应用都要求订阅)，以及专为我定制的特殊功能。

            回复

      2. 像PowerApps这类低代码解决方案，我经常用它快速搞定这类需求。只要用例足够明确，它能让懒散的开发者效率倍增。

        回复

    21. 我预计开源项目中将涌现更多AI生成的PR。

      (至少会达到作者自认需要标注AI辅助的程度。)

      回复

    22. 我发现1-4小时就足以构建任何面向自己的SaaS产品

      回复

    23. 不不，原理并非如此。

      我开发的垃圾产品是用来替代他人SaaS(或免费开源)产品的。

      它们精准解决我的特定痛点，且完全遵循我使用软件的习惯——没有花哨的Docker化Web界面之类的东西。

      我完全没打算把这些破玩意儿搞成带用户账户、计费系统和各种烦心事的正式服务。其中少数或许能作为SaaS产品出售，但我对此毫无兴趣。

      不过大部分代码都放在我的Github上供人自由取用，至于这些随性编写的程序是否会做出不该做的事——那就看各位的运气了 🙂

      回复

    24. 观察得很精辟。在我看来，市场(至少在商业软件领域；消费市场我不太熟悉)似乎一片空白，尤其是5-200名员工规模的企业需求严重未被满足。

      单人经营店铺或1-5人规模企业的软件市场相当活跃，企业级软件市场也存在，但面向小企业的软件市场状况堪称糟糕透顶。以下是潜在客户常要求我解决的典型问题：

      – 他们正在使用某款对业务至关重要的软件。- 该软件几乎没有优质替代品，转换到其他平台成本高昂，且新平台同样存在以下缺陷。- 软件供应商曾表现优异，但似乎已被多次转手。- 供应商近期转为纯订阅模式，且每年以约12%的幅度持续涨价，这部分成本已开始显著挤占预算。- 他们习惯将软件视为资本性投资，仅需支付适度的持续维护费，如今却沦为单纯的消耗性支出。- 软件质量急剧下滑，新功能尤其漏洞百出。承诺的集成功能严重缺失，新增功能/集成模块显得生硬拼凑。- 技术支持难以接通，曾经优质的电话支持被要求提交工单/邮件取代，如今甚至在提交工单前就被AI聊天机器人拦截。多数问题最终悬而未决。

      市面上存在数百万款软件包，其中绝大多数是面向小企业的利基产品(例如专为家具制造特定领域开发的软件增强工具)。该领域软件质量毫无提升。

      这无疑是亟待革新的领域。倘若软件开发成本真能降低90%，这个领域本该轻而易举地进入——只需以每年6000美元的价格提供产品，而竞争对手却以12000美元年费兜售劣质品。在提及供应商锁定或迁移痛苦之前…为何不能开发软件来解决这些问题？毕竟，开发迁移工具的成本现在也应该降低90%，不是吗？

      回复

    25. 市场准入壁垒才是最棘手的问题

      想在现有巨头工具的领域推出像样产品？做好被起诉的准备——他们还会窃取你的好点子自行实现，因为你根本没钱打官司

      回复

    26. > 若定制软件开发成本下降90%，市场本应涌现大量低价优质的SaaS服务，甚至可能冲击现有巨头地位。

      用力点头

      过去12个月：Docusign跌37%，Adobe跌38%，Atlassian跌41%，Asana跌41%，Monday.com跌44%，Hubspot跌49%。Eventbrite被低价收购。

      它们正被更新、更小、更便宜、有时甚至是内部解决方案所取代。

      回复

      1. 是股价下跌还是营收下滑？前者几乎无法支撑你的论点。

        回复

        1. 营收全面增长，且据我所见均超出预期。

          回复

        2. 股价。

          后者同样难以支撑我的观点，因其未考量未来增长趋势。

          回复

          1. 你的观点是“它们正被取代”而非“市场预期它们将被取代”。前者只有在它们的业务已遭积极挤压时才成立(这种情况确实可能存在)，但股市只认可后者。

            话虽如此，我确实认为你描述的情况正在发生，或至少终将发生。只是我不认为人们对此下注的行为能算作证据。

            回复

          2. 前者对支撑你的观点作用甚微，因为它仅反映人们的预期，并非预言成真的实际证据。

            回复

            1. 我无法证明下一份季度报告的营收会如何变化。

              回复

  5. 正如我先前所言：

    我认为90/90法则在此生效。我们都熟悉汤姆·卡吉尔的名言(即便从未见过出处)：

    前90%的代码占开发时间的90%，剩余10%的代码却要耗费另外90%的开发时间。

    突破前90%时总有种巨大成就感——仿佛在说“哇，刚起步就快完成了！”这确实是实实在在的胜利！但对我而言，此后它的效用骤降。那些让资深开发者绊脚的难题，同样会让大型语言模型陷入困境。有时将任务拆解成细碎片段并强行引导它完成，反而比不使用它更糟糕。

    它在推土机式任务上表现出色，但在铲子式任务上却平庸甚至适得其反。我感觉它的惊艳程度很大程度上取决于你开发时间主要耗费在何种任务上。

    若你的工作是批量生产低门槛网站——本质上是为小企业服务的营销工具——那它确实堪称魔法。但我的观点是：对你当前场景越是神奇，两年后这个场景就越难支撑你的生计。

    回复

    1. 确实，我认为工作越需要应对新场景时的准确性，就越不会被这些炫酷演示所震撼。我建议大家在生成结果后暂停演示，仔细审视产出物：它是否真正准确且令人惊叹？你是否只是因为它大致符合预期而感到惊艳，还是它确实能达到人类操作的水准(哪怕只是勉强合格)？

      回复

      1. 你说得对，但反之未必成立。存在某种因素可能让工作成本变得极其低廉，以致人们不再在意质量。

        回复

        1. 这种状态唯一可持续的方式，是突然解决了代码漏洞问题，或消除了它们造成的损害。

          回复

    2. 完全赞同，这与我近期独立承包项目遭遇95%完成度瓶颈的经历完全吻合。我仍主要使用智能工具完成工作，但当早期借助Claude Code/Codex实现的“轻松”功能积累的技术债务、复杂度和范围蔓延最终反噬时，那种乘数效应感便在某个节点彻底消失。

      即便事后看来，我(可能)仍会大量使用CC，但需清醒认识到：在绿地开发阶段，CC添加的每个看似“微不足道”的功能，都将随时间累积成放射性技术债务。直至某天CC开始无法理解自身工作成果，我不得不规划繁琐的大规模重构，才能让代码库恢复长期可维护性。

      回复

      1. 在真正明确构建目标前就动笔写代码总是令人难以抗拒——看着构想逐渐成形确实令人满足又兴奋。我亲身经历过不止一两次：在尚未厘清待解决问题全貌时就着手编码，结果投入数小时后只剩下一堆毫无用处的垃圾代码。而LLM似乎会让你更深地陷入这种陷阱，毕竟它们带来的生产力提升简直如魔法般神奇。

        回复

    3. 我注意到克劳德(Claude)执行指令时表现得如此出色，以至于事后才惊觉某些功能根本不该开发——它们要么愚蠢要么多余。但克劳德全程都在鼓舞我，不断用表情符号和勾号刷屏，让我完全没意识到这个功能几乎毫无价值。

      回复

      1. 没错，一旦开始在功能层面工作，你就踏入了产品设计领域——这完全是另一种工作范畴，我认为根本不该涉及代码。更高层次的软件设计(比如规划数据模型和访问方式等宏观架构)更应该在编写大量代码前完成。若你要求克劳德等人照单操作，他们会心甘情愿地带你直坠悬崖。而未提前规划这些框架，正是最有效的自投罗网之道。

        回复

  6. 我确信每个组织都有数百甚至数千张Excel表格在追踪重要业务流程，这些流程若能转化为SaaS应用会好得多。

    对谁来说更好？人们总轻视电子表格，但实际上它们往往更强大、更易于掌握领域知识的人员使用(这些人员能正确实施计算或工作流)，且几乎具有普适性。

    回复

    1. 电子表格是不可思议的工具，堪称应用程序发展史上的关键创新。我热爱并持续使用它们。

      但要确保大型传统单元格公式表格的准确性极其困难。其编程模型与用户界面紧密耦合，一旦表格复杂度稍高，就难以看清内部运作机制。许多工作场所都存在运行关键业务的庞大表格，这些表格经过多年精心维护(？)，我敢说其中多数都存在重大错误。

      回复

      1. 电子表格的实用性和直观性令人惊叹，但最让我困扰的是：只需添加一行/列/单元格，就可能轻易破坏计算结果，比如SUM(<RANGE>)函数。

        我常使用谷歌表格追踪符合列表/表格的新事项，若授予他人编辑权限却未告知表格操作细节，就意味着我每月都要反复核查修正。

        回复

        1. 有人开发过能检测此类问题的Excel或表格验证工具吗？那将极具价值！

          回复

      2. 几年前欧洲某小国就发生过类似事件：因电子表格漏洞导致政府官方住房估值数据连续数年错误。

        记得当年修正该漏洞时，我公寓估值竟因此上涨约10%(修正仅适用于5层以上楼层的房产)。

        不过我认为SaaS在此并不能解决根本问题。

        回复

    2. 我是原作者。当然并非所有事务都需要网络应用。但企业中大量核心电子表格确实需要更完善的结构化管理。

      尤其在协作功能、访问控制等方面亟待改进，更不用说单元测试的需求了。

      回复

      1. 反驳观点：当流程中某个细微环节需要调整时，负责这些应用的团队能有多快响应？这正是电子表格在业务流程中的杀手级优势：财务人员可自行修改会计表格，收发货人员可调整其表格，整个过程中没有任何团队成为阻碍瓶颈。

        这也正是所谓“影子IT”存在的根源。团队为完成工作不惜采取任何手段，无论IT部门是否提供支持。

        回复

        1. 我见过太多将常用电子表格转为网页应用的尝试，最终都沦为重新实现电子表格功能的徒劳。当用户首次遇到功能变更时，总会说“在Excel里我本来只需这样操作…”。开发团队便陷入永无止境的追赶Excel现有功能的泥潭，用户因开发周期漫长且漏洞百出而怨声载道——而Excel始终近在咫尺，随时可用。

          回复

          1. 在“应用程序与电子表格之争”的讨论中，这个观点屡见不鲜，却鲜有具体实例佐证。使用“专用”应用的意义在于为问题提供结构化解决方案。若用户执意复刻电子表格功能，那他们最初就该直接用Excel——毕竟Excel本就是为通用化处理各类问题而生的专用工具。这好比有人说“我的笔记本和笔就在眼前，何必费事打开应用？”——正因为应用能提供额外价值才值得使用。

            回复

        2. 从未听说过影子IT。这是什么概念？

          回复

          1. 指用户自行处理IT事务的行为。名称或许源自英国的影子内阁？

            需要注意的是，此处的IT不仅指布线和审批工单，而是广义的“信息技术”——即运用计算机解决问题的行为。这可能包括开发定制应用、数据库等。绝大多数企业都存在大量此类活动，解决方案的规模从微不足道到至关重要不等。

            回复

            1. 我认为这个术语主要源于它往往难以被整个组织察觉或理解(这或许正是其主要风险所在：要么某人离职导致整套IT基础设施崩溃，要么有人搭建了极其不安全的系统导致公司被攻陷)。尤其考虑到多数IT部门对此深恶痛绝，自然倾向于隐瞒(我个人认为IT组织应将影子IT视为自身管理失职，主动寻求与搭建者合作，或反思自身服务缺失之处——正是这些缺失导致其他部门绕过IT部门自行搭建)。

              回复

              1. 这种情况确实存在。我自己也做过不少类似的事。十五年前为工厂编写的几个程序至今仍在关键的子组件调试中持续使用。总计不过几千行Visual Basic代码，虽非“优雅代码”，但附有详尽的文档和完整的运行原理说明，完全可作为专业版本的开发规范。

                我认为这并非缺陷，正如“软件开发无法估算”并非缺陷一样，而是现实使然。每个复杂组织都面临大项目与小项目的两难抉择，最终必须划定界限。对业务发展和开发者职业生涯而言，聚焦最大、最显眼的项目才是最明智的选择。

                小型项目往往在隐蔽模式下推进。Excel工具或许具有某种社会妥协价值——它既表明你并非试图从事IT工作，也让IT部门意识到其不构成威胁。

                风险确实存在，但我认为微乎其微。风险等于概率乘以影响，以美元衡量。最大风险源自最大型项目，仅因其潜在影响最为深远。几乎所有危及企业的项目失败案例，都源于优秀工程师采用规范方法实施的大型项目。

                回复

          2. 这就像你建立了流程来管理IT基础设施，但这些流程往往导致无法使用任何东西，或者耗时过长。

            最终需要使用的人员只能绕开中央IT支持(或缺乏可见性、安全性保障等)自行管理。

            想象一下：你拿到一台被锁死的笔记本电脑，没有管理员权限。要么让IT部门授予管理权限，要么另购一台IT无法监控的笔记本，自行安装完成工作所需的软件。

            后者往往更快捷高效。

            回复

      2. 第三方SaaS能近似实现这类“核心表格”的情况极为罕见，且绝大多数例外场景在过去数十年间已被充分探索。

        必须认识到：SaaS与盒装软件一样，本质上反映了他人对流程或工作流的模型设计，其模型与实现方式始终遵循发布者的时间线/议程演进。

        对于某些工作流的特定环节——比如开票、会计或库存追踪这类存在高度规范且成熟的行业标准的领域——这种妥协是值得的。长期以来，无论是盒装软件还是SaaS产品，都持续满足着这些需求。应用程序的流行度、界面设计和定价模式虽会更迭，但服务领域基本保持稳定(仅随新业务线/趋势的兴起与成熟而扩展)。

        “核心表格”中保留的大部分内容，若经专业工程师优化可提升可靠性与健壮性，但几乎总是反映出其所呈现的业务流程具有组织特异性。正如Access、FoxPro、VBA、Zapier等工具曾做到的那样，大型语言模型编程助手和软件构建工具有望推动变革——让企业将“核心表格”转化为“内部应用程序”。

        但这并非SaaS创业者的机遇。真正的机遇在于LLM专家可借此切入市场，以优于二十年前Access开发者承诺的条件，向企业推销私有化定制软件解决方案。鉴于过度依赖LLM的代码仍面临长期维护难题，我本人不愿成为推销此类服务的专家，但这无疑为有抱负者提供了机遇。

        回复

      3. > 我在企业中看到许多核心表格需要更完善的结构支撑

        几十年前就有解决方案了，比如dBase，FoxPro(微软收购前)也相当出色。而Visual For Pro或MS Access对这些优秀特性的降级简直是灾难性的。

        试想如今若有初创公司推出全栈(TM)平台：集成IDE、具备SQL特性的语言、可视化UI设计器、数据库系统；能生成小型独立二进制文件，兼具高性能且体积小于多数网页首页。

        虽有Servoy或Lianja等现代方案，但它们过于“云化”而难以成为真正替代品。

        编辑：似乎还有OpenXava，但它基于Java，我认为对非专业程序员来说过于硬核。xBase的魅力在于，只要需求不复杂，连高中生都能快速编出像样的商业应用。

        回复

    3. 我还没见过电子表格工作流被其他工具成功取代的案例。

      回复

      1. 在电子表格里编程是反模式。谁会审查你的工作流？谁会为此编写测试？请用真正的编程语言——至少用笔记本程序。

        回复

      2. 在我所在的领域，Streamlit应用或类似工具表现出色。

        其构建部署简易度堪比Excel，却具备完善的数据类型、用户界面、访问权限与版本控制、能被大型语言模型理解的编程语言、完善的软件生态与组件包等优势。

        回复

        1. 它们真能像Excel那样轻松部署吗？我猜多数Streamlit应用根本出不了开发者的电脑。

          回复

          1. 若配备正确工具(如Streamlit.io)，确实如此。

            “部署”Excel文件只需在Office365创建文件并点击分享
            “部署”Streamlit文件只需在Streamlit编写单文件Python代码(甚至一行代码即可)并点击分享

            回复

      3. 这类场景的策略或许是：用能进行单元测试、广播变更等功能的工具增强核心电子表格

        回复

    4. 电子表格功能强大却常遭滥用。它们适合处理经济数据，但逻辑运算能力极差。

      大多数中大型复杂电子表格更适合用高级编程语言实现。

      电子表格看似能满足畏惧编程语法的人群，但很快就会变得难以维护且漏洞百出——我认为直接学习编程往往更轻松。

      尤其是Excel，简直漏洞百出。

      回复

    5. 电子表格确实能解决大量问题。关键在于识别问题规模已超出电子表格承载能力——通常表现为将电子表格当作数据库使用，或用户数量超过几人。

      能超越原始创建者存续的电子表格实属罕见。

      回复

    6. 别忘了：两个组织采用相同电子表格进行管理/数据分析的可能性微乎其微，因此多数拟议的SaaS应用最终只会服务单一客户。

      当然，SAP能解决通用问题。

      回复

    7. 更强的安全性。更高的可用性。更低的数据丢失风险。

      前提是SaaS服务商具备专业能力。否则优势微乎其微。

      回复

      1. 我持不同意见。在众多企业(尤其是财务控制部门)中，我见过大量此类Excel应用程序，它们向高管层提供关键数据。这些数据绝不允许流向外部，更遑论托管于云服务或交由外部顾问/程序员处理。这些数据始终由部门自行管理备份，甚至有案例要求相关机器所在房间仅限授权人员进入。三十年咨询生涯让我明白：当财务部门对你的SaaS或ERP方案说“不”时，务必信守其承诺。

        回复

    8. 这类系统往往难以维护，因为原始开发者已离职，而用户并不真正了解电子表格的功能，这导致大量数据表格中存在未被发现的漏洞和错误。

      回复

  7. 此类文章不断揭示出软件团队实际工作与高层管理者认知之间的根本性脱节。

    高高在上的管理者自以为完全理解软件应有的形态，以为自己通过几条措辞模糊的需求说明、若干松散约束条件，以及(慷慨地讲)对系统依赖关系的极不完整认知，就“掌握”了全部设计意图与规格。他们视软件团队为昂贵的成本中心，而非真正创造财富与权力的源泉。

    将抽象概念转化为实际软件产品的艺术，正是优秀团队的价值所在；至今我未曾见过任何能自动化实现这一过程，甚至提供实质帮助的工具。

    回复

  8. 这类未来预测帖层出不穷，我已厌倦。现实总是更乏味、更温和、更缓慢地变化，因为涉及太多变量，而作者们永远无法面面俱到。

    或许我们该收集所有预测，五年或十年后再回溯验证谁的预言成真。

    回复

    1. 尽管文中包含几处前瞻性陈述，我并未将其视为预测。这更像是对2025年12月现状的主观/轶事性评估(当然也包含对明年影响的某些推测)。

      总体而言，这与我使用Claude Opus 4.5的体验高度契合。我们已跨越某个门槛(无疑是众多门槛之一)。

      回复

      1. 为验证OP文章的理论，我正准备编写单元测试。决定让Opus 4.5尝试处理，结果表现相当出色——但解析其生成的代码所耗时间，几乎等同于从零编写新代码。我仍需清理代码，而且不出所料，它生成了若干仅测试自身模拟对象的测试用例——这种错误若提交同行评审，我宁死也不愿见。

        很高兴楼主觉得放任Opus自由发挥无需深究也无妨，或许我们所有人都该学会停止担忧，拥抱大型语言模型？但说真的，此刻我们看到的不过是职业博主兼演讲者撰写的又一篇炒作文章——这类博眼球的内容正是他们最热衷创作的。

        回复

        1. 关键在于…Agent模式推出多久了？就像CoPilot里的功能才7个月历史。

          事物演进速度远超人们认知…从Agent模式到mcp服务器，再到子代理，如今RAG数据库让LLM能直接获取数据。

          LLM发展看似缓慢，但每次迭代都在进步。试想：若用21个月前的Claude 3.0重跑你当时的测试，结果会如何？再看仅8个月前的Claude 4.0呢？

          当前Opus 4.5已相当实用。问题往往不在于它生成的代码质量，而在于它常陷入“逻辑太复杂，让我简化”的循环，核心症结通常是上下文处理能力。

          大型语言模型在深度任务上仍显薄弱，但相较前代已实现飞跃式进步。一年后呢？两年后？我难以置信克劳德3.0竟距今仅21个月——当时我们视其为单文件处理的重大突破，如今却能驾驭完整代码库，在调试编辑等领域表现出色。

          我满意这些结果吗？不，很多时候输出并非“我想要的”，但这往往源于我自己的提示过于笼统。

          LLM永远无法真正取代经验丰富的程序员，但天啊，这种进步速度实在令人胆寒。

          回复

          1. 我无法说自己的观点有所改变。它给出的结果并未比Sonnet更令人兴奋或实用。值不值三倍代币价格？我持保留态度。

            (评论中未说明：我本就使用代码代理工具，只是觉得楼主夸大了效果。)

            回复

        2. 这仅适用于它生成的代码是你无需参考就能直接编写的类型。

          现在试着做我做过的事：开发一个能获取你的IMDB/Letterboxd/Goodreads/Steam书库并本地存储的应用(掌控你的数据)。同时利用OMDB/TMDB丰富影视作品数据。

          若你能比阅读Claude的成果更快写出所有代码，我向你致敬并订阅你的Substack和YouTube频道 🙂

          对了，Goodreads、IMDB和Letterboxd都没有完善的导出API，你需要用playwright风格的浏览器自动化工具实现。光是手动编写代码调试这个烂摊子就要耗费数小时。

          而克劳德当年仅用Sonnet 3.7就一次性搞定了Steam API访问(这已是多年前的事)，还实现了多源输入数据的增强功能。

          回复

          1. > 若你写代码的速度比读懂Claude的成果还快

            我觉得你需要更敏锐地解读我的评论 😉

            > Steam API访问由Claude一锤定音(使用Sonnet 3.7实现，这已是多年前的事)，同时实现了多源输入数据的增强。

            这不过是又一个“我用LLM随便搞了个东西，超级实用还毫不费力”的老套路。但与楼主宣称“可直接套用在成熟或遗留代码库上，减少90%人力投入”的说法截然不同。当代码正确性至关重要时(随着代码库增长必然如此)，你仍需人工审阅代码——这永远离不开人类的眼睛。

            回复

      2. 不，不是这样的。

        发布这类内容的人显然并未实际操作；他们只是浏览领英帖子，把玩技术，然后想象大规模应用的场景。

        这很合理，但也是误导性的。

        要么亲自尝试，要么去观察那些(比如@ArminRonacher)在合理规模下实践的人，这样才能立足现实而非炒作。

        简而言之：当前技术无法实现规模化应用。

        无论个人实践、微软项目还是某AI公司都未能实现。

        目前，随着“不改变现有行为”的约束清单不断增加，无监督代理的能力反而下降。由于大多数公司/个人开发者不欢迎那种“在解决问题的同时破坏其他功能”的“帮助”，这使得“人人都能实现10倍效率”的童话故事出现了重大漏洞。

        正如其他讨论所言：生成新代码的成本确实降低了，但要产出可用代码的代价，我认为仍与现有脚手架工具相当。

        在某些约束更宽松的领域，如图像生成(没手？谁在乎？)和前端代码(样式错误？不一致？谁在乎？)，确实如楼主所述正经历革命性变革。

        …但将其泛化为“所有编程”，似乎就像自动驾驶汽车的问题。

        可解决吗？大概可以。

        …但比那些不理解、未曾尝试解决、或在博客上空谈的人想象的要难得多。

        或许存在更易解决的小众问题集……但2026年绝不会实现；更不可能达到原帖描述的规模与速度。

        你该注意到，我们至今都还没自驾车呢。

        (尽管某些公司提供的车辆偶尔会自动撞上东西，但据我所知这永远归咎于“用户操作失误”……)

        回复

    2. 信念存于心间，或信或疑。我很庆幸生活在这个世界——如此多人勇于追随信念，纵使听来荒诞或令人不安。

      回复

      1. 是是是，有个留着怪胡子的家伙鼓吹疯狂理论，说什么我们正被另一群人压迫。我们绝对该追随他。他听起来疯癫却极具说服力。瞧瞧那些炫酷的徽章符号！你知道这个敬礼动作源自古罗马吗？——来自1920年代的你。

        回复

  9. 我曾短暂参与过一个后LLM热潮时期的Excel现代化项目(结果变成纯咨询，因为我得耗费所有时间解释长期软件项目如何适配他们的业务场景)。

    公司此前曾试图让两个懂点Python的菜鸟数据分析师编写Python桌面应用程序分发给用户。最理想的情况下， 这些人编写的应用程序会将状态全盘托付给用户界面，既无架构分离概念，也无法预见数月后代码将演变为何种形态(除非通过AI拍马屁的视角解读)，最终打包成桌面应用生成Excel表格，再通过邮件互相传送(不知为何他们偏要如此——大概因为这符合他们的认知范式)。

    不能怪罪业务方，因为这些机构根本没有技术人员。本案中的客户其实是高智商群体，从事高端咨询工作，但他们不懂技术。若让我尝试“氛围编程”，结果肯定同样灾难性。

    对这类机构而言，“氛围编程”唯一能“解锁”的，就是让他们头也不回地冲向一个肆意践踏客户数据的应用程序。这并不能为我这个资深开发者腾出时间降低成本，因为要让这些机构真正具备运行和维护内部软件的能力，需要投入大量工作——而我本就没多少编码时间。

    回复

    1. > 后大型语言模型热潮时代的Excel现代化项目

      这想法着实令人毛骨悚然

      回复

  10. 手绘图表妙极了。图表显示“开源”约诞生于2005年，大幅降低了开发成本；2011年左右AWS问世使开发成本进一步降低，然而2018年“复杂性”突如其来，开发难度竟反而上升！

    回复

    1. 我认为这并非指开源技术诞生之时，而是指它在企业界真正普及的节点。2002年时，大型企业选择专有Web服务器(如IIS)是完全合理的决策。若到了2008年还这么做，那才叫离谱。

      回复

      1. 但这为何能降低开发成本？企业版Windows加IIS套件大概才一千美元吧？或许还有其他成本，毕竟我这知识都过时23年了。

        回复

        1. 你决定需要Web服务器。向上级管理层申请批准。向IT部门申请批准。向财务部申请费用批准。联系微软销售。购买。

          现在你才算能开始开发……

          开源软件不仅节省了软件成本，更省去了因付费而产生的各种官僚流程。在技术层面，你还能获得所选产品的高度透明度。

          回复

        2. 甲骨文已加入讨论。

          若25年前MySQL和Postgresql已是可接受的选择，我们公司本可省下巨额资金——如今这些钱都用来资助拉里·埃里森的游艇了。

          当时两者虽已存在，却无法以可销售的形式呈现给：a)客户 b)拥有最终决策权的高管层。

          回复

    3. 2018年Kubernetes问世，开发速度再提升300%！

      回复

      1. Kubernetes承载生产负载后，企业终于能践行“快速失败”理念。

        回复

        1. 既然连Kubernetes都这么讨厌，说明它足够无聊，可以放心开始使用了！

          回复

          1. 确实很无聊。等你意识到自己成了YAML工程师时，绝对会诅咒此刻。

            其实我敢打赌AI很擅长生成那些该死的清单文件。毕竟这不过是机械重复罢了。

            回复

  11. > 几小时内写完整套单元/集成测试

    博客作者的“水平”往往难以评判，但这种片段足以让人无视其观点。我接触过许多代码库，测试编写者和作者持相同态度——他们糟糕透顶，编写的测试要么毫无用处，要么危害更大。

    职业生涯走到这一步还不懂如何编写有效测试，堪称重大警讯。

    回复

    1. 我曾用机器学习模型辅助编写大量测试用例，但这需要反复迭代，且模型产生的错误既普遍又隐蔽。

      诸如因“测试实际代码太难”而在测试中重写大量代码、耗费过多时间覆盖与核心业务逻辑无关的微小输入处理的边界情况、对被测代码进行模拟、将失败测试修改为匹配明显错误的行为…这些错误完全符合那些不懂测试目的的菜鸟开发者会犯的错误。

      虽然搭建测试框架确实能省下大量时间，但根据我的经验，除非他们非常仔细地审查代码，并通过人工修改或与LLM反复迭代，否则这些测试几乎可以肯定毫无价值。

      (顺带一提，这还是用相当新颖的模型——主要是Sonnet 4和4.5版本。公平起见，我读过的人类编写的测试中，惊人比例同样是毫无价值的垃圾，我实在难以想象训练数据质量有多高)

      回复

    2. 但我们的代码覆盖率高达500%？！

      回复

  12. 写得不错。我完全认同他的观点，但有人能给出实际建议吗？关于职业发展方向该如何规划？我做前端(兼顾全栈)已有几年，现代技术生态让我忧心忡忡，尤其困惑于自身定位问题。

    常听到“精进业务领域知识”之类的模糊建议。我并非否定这些建议，但具体该如何落实到日常工作中？目前我在中型企业任职，使用Cursor等工具，却总担心自己是否落后或方向有误。

    各位对此有何见解或建议？眼下整个行业格局对我而言仍如迷雾笼罩。

    回复

    1. 我是原帖作者，感谢大家的鼓励！

      我认为关键在于审视现有产品，主动提出/原型化其他可能对业务有价值的功能。在大公司里这确实棘手，部门间往往各自为政，但能否尝试“领先一步”思考产品需求并同步开发？

      无论是否实际开发，我认为这都是每个项目都值得做的练习——思考下一步该开发什么，以及业务方真正需要什么。若你脑海中已逐渐清晰这些需求，说明你正在深入理解业务领域，这是积极信号。

      回复

      1. 我认同应尝试领先于产品需求一步。我的问题或许在于，总在寻找可能并不存在(至少没有明确路径)的“另一条路”。从童年至今，事物总被摆在眼前任我完成，但如今仿佛步入真正的战争迷雾。

        如你所言，从“基于具体规格编程”转向“为业务发掘解决方案”确实大有裨益。

        感谢回复(及原文)。这让我有了许多值得深思之处。

        回复

      2. 你是原作者吗？还是用AI生成的？

        回复

    2. 虽是盲人领盲人，但我的思路是：

      1. 充分利用工具，突破边界，摸索可行与不可行之道

      2. 成为超越工具的存在

      只要你拥有LLM学位的价值远高于仅持有LLM学位者，你就能获得聘用。我不确定这条建议有多“实用”，因为这本质上就是你正在做的事，但这就是我的思考方式。

      回复

      1. 现实情况是：当他人+LLM组合以-10%薪酬入职时，你仍会被雇佣

        回复

        1. 那么在LLM出现前，为何不是他人以-10%薪酬取代你？

          回复

          1. 假设LLM能为你的产出增加50点“技能值”。开发者A的编码能力为60点技能值，开发者B为40点。两者差距看似悬殊。现在引入LLM：开发者A升至110点，开发者B升至90点。差距相同，但视觉冲击力减弱。

            LLM带来的(感知中的、所谓的)能力增强，使开发者个体技能差异显得不那么重要。从企业角度看，雇佣技能较低的开发者与雇佣技能较高的开发者，实际产出差异并不显著——即便双方都使用LLM辅助工作。

            现实情况显然更为复杂，但这大致说明了CEO和股东在人才招聘层面面临的困境。

            回复

    3. 不要追逐特定技术，尤其不要追逐由营利公司推动的技术。追逐理念，在行业某个细分领域做到顶尖，至少你永远可以依靠这个立足。一旦在某个领域站稳脚跟，你就能更从容地尝试拓展其他领域。

      归根结底，软件是为实现某种功能而存在的，而这种功能可以涵盖极其广泛的领域。若能在其中某个细分领域做到极致，无论行业整体形势如何，你的处境都会轻松许多。

      回复

      1. 感谢回复。您所说的“行业细分领域”，是否意味着要理解所构建产品的核心业务逻辑，而非沦为单纯的“按规格编码者”？这部分建议对我而言似乎有些模糊不清。

        回复

    4. 这种模糊性始终存在。即便没有AI，你的领域也随时可能被突如其来的技术颠覆。

      AI大概会取代底层30%-70%(不同观点存在分歧)的开发岗位。当行业底层崩塌时，别让自己陷入死区。

      未来如何培养优秀开发者仍是未知数——若无法在他们技术尚不成熟时提供经济稳定的学习环境。

      回复

    5. 善用最佳工具：Claude Code的入门版本完全能胜任你晚间和周末的家庭编程需求。它更是迄今最出色的“搭档式编程”工具——交互性强，实时反馈操作状态，即使你按下ESC切换任务也不会混乱。

      打造专属工具：需要小型实用程序？让大型语言模型与你协同创作。

      开发聚焦大型语言模型的工具，并优化工作流程使其更友好。

      我个人采用统一的Taskfile配置方案，无论语言类型：“task build”命令可执行代码检查+测试+构建。测试和代码检查功能不言自明。所有输出均设为最小化，仅错误信息详细显示(避免冗余输出浪费上下文)。

      我还开发了供LLM使用的工具，用于定位大型代码文件、复杂冗余函数等。

      所有项目文档均存放于docs/目录，采用带Mermaid图表的Markdown格式。

      如此便只需在全局WHATEVER.md中编写通用“Taskfile使用指南”，即可适配所有项目。

      学习项目管理。与LLM协作的过程，恰似管理一群聪明过头、跃跃欲试的初级程序员——他们总想把学校学到的所有技巧和模式都用在每个微型shell脚本上。

      尝试几个测试项目：假装自己是不懂技术的项目负责人，明确目标但不干涉实现方式。规划项目、拆分任务(GitHub Tasks或beads[0]都效果不错)，然后让LLM逐项处理任务，并像非技术型项目经理那样在演示环节测试最终结果。针对不合理之处进行点评、批评并要求修改。

      若预算允许，可引入外部顾问(如Codex或Gemini)，这两者在评估大型代码库的冗余、测试覆盖率、重复代码及不良模式等方面表现卓越。将它们的反馈原封不动转述给Claude，询问其观点。

      与大型语言模型协作是种需要实践才能掌握的技能，它并非科学而是艺术。例如我能“感知”克劳德何时陷入过度活跃状态，或是试图忽略堆积如山的单元测试强行完成任务——此时就该及时叫停，避免问题扩大。

      [0] https://github.com/steveyegge/beads

      回复

      1. 另建议探索并运用提升效率的非编程AI工具，例如：

        Zoom会议记录与摘要或格兰诺拉麦片。会议中手动记录会丢失大量上下文信息。若使用能自动将会议转化为笔记的工具，便可利用这些笔记为客服人员创建提示/计划。

        回复

        1. 我们用“Notion AI”转录会议，效果相当不错。刚开完团队会议，既讨论了公司事务又吐槽了流程问题。

          它能精准提取任务要点和实质内容，完全跳过玩笑和流程吐槽部分=)

          回复

    6. 我的建议是提升抽象思维层次，改变看待系统的方式。

      或许转向全栈开发？或许更深入理解行业？或许更精准分析公司竞争对手？这些都能提升你在企业中的价值(虽与产品管理略有重叠)。假设你已能更轻松交付技术部分，这会是我的选择。

      至于我，已转任正式的产品管理职位。

      回复

    7. 好问题，难以速答。

      我的建议是：证明你能解决更复杂的问题。这包括辨别真正重要的问题——关键在于学习“领域知识”，而非仅掌握某个领域的工具(如网页开发)。

      改变令人恐惧，但这源于多数人不愿改变。恐惧中包含对投资损失的担忧(如选错专业或职业)。我理解这种顾虑，但借助AI技术，如今只需稍作调整，就能比2022年前更快地重新规划投资方向。

      AI只是另一种工具，应视其为伙伴而非替代品。这同样适用于领域知识的学习。向AI询问特定流程的运作机制、历史沿革、监管规定等，再亲自验证其结论。要求它分解复杂概念。如今我们能以前所未有的速度学习。信任但需验证。

      你正在使用Cursor，这表明你愿意尝试新事物。现在请尝试比以往更快地推进，更深入地应对挑战。这种能力永远值得珍视。

      回复

    9. 虽然我也算瞎带瞎，但看到两条路径：

      1. 专攻产品工程，意味着承担更多业务责任。或许是打造自有产品，或许是争取更贴近客户或管理层的角色？我不太确定。若你认为AI将取代多数程序员，可能适合这条路。

      2. 专注于AI无法解决的硬核编程领域。前端风险最高，底层系统编程风险最低。可学习Rust或C/C++，若不想完全转向底层系统，也可考虑后端方向(C#/Java/Go)。

      不过我认为AI短期内不会真正取代我们。

      回复

    10. > 但我仍在怀疑自己是否落后于人或存在不足。

      面对行业剧变与AI/ML热潮，这种焦虑实属正常。但切忌因此陷入“分析瘫痪”。

      > 尤其在自我定位方面…各位有何见解或建议？

      你拥有稳定的工作，因此当前全部精力都应聚焦于在职场/组织中“成长”。这意味着要承担更多技术与非技术职责，向管理层展现长期承诺。技术层面可从“全栈开发”入手，同时掌握前端与后端技能，从而为整个产品线提供端到端支持。学习/运用所有可用工具(包括AI工具)展现主动性。主动承担无明确负责人的任务(如CI/CD等)。定期向主管/高层汇报进展，保持在组织内的能见度。深入了解业务领域，加强与市场/销售部门的互动，成为工程团队与其他部门/客户的桥梁。

      高层管理者普遍看重主动性和独立驱动力，这能让他们放心授权工作并确保任务完成——这正是你需要展现的核心价值。

      回复

    11. 养羊听起来不错。或者做木制家具。找点动手实践的事。

      回复

    12. 没人知道答案。

      常见答案无非是“转行做产品经理”或“自主创业”，但显然95%的开发者做不到/不愿做。

      回复

  13. 问题不仅在于“构建”……谁来维护这些每日推入生产环境的次品代码？

    谁来修补所有漏洞、边界情况和安全隐患？

    回复

    1. 没人。

      事实上，看着开发者们对无服务器架构的狂热，我预见意外云账单将激增——更别提考虑边界情况了

      回复

    2. 这种论调我听腻了，但它似乎忽略了代码审查环节

      回复

      1. 就像程序员知道什么是代码审查，或者大型语言模型懂得如何接受反馈似的

        回复

      2. 在建立高度互信的高绩效团队中，代码审查大多流于形式，只是防止重大明显失误的权宜之计。“LGTM！”

        我既不认识也不信任编写这些代码的智能体，代码审查流程完全不同。

        看着 Copilot 代码审查插件在智能体代码上抱怨，真是段奇妙的经历。

        回复

    3. 理论很简单：你告诉智能体修复漏洞。但实际操作嘛…

      回复

      1. 没错，实际操作中：你会愿意搭乘一架由某些代理修复过部分漏洞的波音747吗？
        作为乘客，你愿意承担多少故障风险？

        回复

        1. 不会。但大多数软件产品根本不具备这种敏感性，极少数产品在开发时能达到安全关键组件所需的谨慎与严谨程度。

          回复

        2. >> 是的，实际情况是：你会愿意登上这样一架波音747吗？它的部分漏洞是由某些代理程序修补的，

          这种情况下，传统的人工流程同样未能发挥作用。

          回复

          1. 只要严格遵守并预留预算，它就能完美运行。

            回复

          2. 人工流程的核心在于认知：错误会导致人员伤亡

            回复

          3. 这些漏洞多由MBA人士造成，而他们显然会继续留任。

            回复

    4. 一年前我欣然摆脱了某遗留应用(竞标失败，现在由另一家机构收拾烂摊子)。作为技术稍精的人，我继承了这个项目。

      这玩意儿是真人写的。没有半行AI垃圾代码。堪称我见过的最脆弱的破烂。就算我最疯狂地用Vibe编写原型时，也绝不可能让AI生成如此多的反模式、烂代码和足以让希区柯克吓破胆的代码。

      我敢说，若看到现实中运行在生产环境的人类代码垃圾，大家定会震惊。规模或许不同，但至少在这个案例里，若我纯凭灵感重写应用，代码质量和安全性反而会提升——即便只投入最低限度的灵感编码。

      我绝非在纵容(这个词用得对吗？)不良实践，更不主张未经极其严格审查就将即兴代码投入生产环境。恰恰相反，我只是想提出一个反驳观点：至少在我咨询/代理机构工作的经历中接触到的中型企业里，我见过大量足以让编程机器人毛骨悚然的垃圾代码。

      回复

      1. DigitalOcean 1.0版本是靠胶带拼凑的Bash脚本、cron任务和Perl程序大杂烩，12人团队里仅2人理解其逻辑，1人懂得操作。它确实运行着，但简直疯狂到极点。原始ChatGPT绝无可能写出比DO v1更糟糕的代码。

        回复

        1. 你是说初代ChatGPT能构建DigitalOcean？

          回复

          1. 在我看来，“构建”和“编写”是两回事。‘构建’：好吧，这可能有些夸张。但早期那种“代码写得还行”的大型语言模型能否编写DigitalOcean v1？我认为可以(无意冒犯Jeff)。就代码量和架构规模而言，它确实庞大复杂，但本质上就是一堆相对简单的cron、bash和perl脚本，整个系统非常…粗糙(因为我们当时开发速度极快)——我记忆中的DigitalOcean(很久以前的事了)后来转型成了代码精良的现代Go语言平台。(注：我属于“创始团队”之类的成员)

            回复

      2. AI无法突破输入者的局限性，就像AI时代之前的软件——输入垃圾，输出垃圾。

        真正改变的是速度：AI与氛围编程为上述所有现象注入了涡轮增压。代码量将呈抛物线式增长(或许已然如此)，中期来看，我们将需要更多软件工程师/系统工程师/运维/安全/等等来应对。

        回复

      3. 争论点不在于所有垃圾都是AI，而在于所有AI都是垃圾。

        回复

        1. 事实证明，构建企业软件与制造垃圾代码的共通点远多于差异。

          回复

  14. 写这类文章的人大概从未在大公司工作过。

    我妻子在Shutterstock工作，最初是软件工程师，现在是产品经理。他们大部分任务涉及在5个不同系统中进行微调，有时还得在Salesforce这类平台操作。一个简单需求往往暗藏复杂逻辑。

    AI确实让理解和修改代码更轻松了。但开发成本并未降低90%，甚至差得远呢。

    回复

    1. 作者“为工程团队开设人工智能开发工作坊”，这不过是为公司打广告罢了。说实话真不知该讨论什么，这比YouTube上普通视频预览图还低级的噱头。

      回复

    2. 这类文章总把开发新演示应用或孤立工具当作软件开发的全部意义

      回复

  15. 本文提及交付成本，却忽略了软件项目最大成本并非市场投放周期，而是维护与功能迭代。智能编程在这方面表现如何？目前我只见过庞大且难以维护的混乱代码。

    回复

    1. 虽然如此，我认为游戏开发等领域未必存在此问题。若目标是发布不可升级的游戏——如第一人称射击、街机、单人作品——维护成本可能远低于发布成本。

      编辑：修正错别字

      回复

      1. 我试图理解这种思维的根源。我并非贬低你，而是真心想知道：你是否意识到所有软件开发者都曾以“发布完美无缺、永不需升级的软件”为目标？你是否明白我们早已知晓这根本不可能实现？

        回复

        1. > 我试图理解这种思维方式的根源。

          我曾是游戏开发者。

          回复

        2. 这种情况基本持续到主机游戏引入在线功能为止。相较于游戏复杂度，前期测试更为严谨。虽然仍存在漏洞，但除非召回产品，否则无法进行升级。

          回复

          1. 那我们为何放弃这种模式？

            况且电脑游戏与主机游戏是同期存在的。早在1980年代初，人们就在电脑上玩从软盘加载的游戏了。

            回复

            1. 我并非说这种模式在当下环境下盈利，但它确实曾真实存在过。这说明某些流程能产出实用产品，只是未必适用于当前需要盈利的尖端竞争产品。

              回复

      2. 我认为这确实是可行的领域，但问题在于我认识的非科技从业者玩家都强烈抵制AI。

        回复

        1. 他们就是爱抱怨。你很少会遇到公开表示喜欢DLC的人，可这东西照样卖得动。

          回复

      3. 没人愿意推出这种产品！他们想要的是持续更新的在线服务游戏，因为这能带来持续收入。

        回复

    2. 运行一年后，AI垃圾代码 > 人类编写的垃圾代码

      回复

        1. 这是个人经验，并非普遍结论。从业三十载，见过太多人类编写的代码…

          回复

          1. 赞同。核心问题在于许多开发者(在HN上)并未意识到人类编写的代码有多“糟糕”。

            我见过令人难以置信的复杂物流逻辑被写进…WordPress模板和插件里，随便举个例子。这种代码几乎无法理解——但如今AI已能相当精准地提取其中所有逻辑。

            回复

            1. > 赞同。我认为核心问题在于许多开发者(在HN上)并未意识到人类编写的代码有多“糟糕”。

              你认为“AI”究竟是用什么训练出来的？

              回复

              1. 终于问到关键问题了！要是我能点赞，绝对给你加1000次！

                这就是为什么它们需要资深开发者指导的原因。对于能直接学习的内容(比如手册文档)，它无需指导就能胜任；但其他方面仍需引导。

                回复

          2. 数以百万计的人在编写代码……数量庞大到根本不可能保证质量。或许你运气好碰上不会让你头晕目眩(甚至反胃)的代码库，但我们大多数人可没那么幸运

            回复

      2. 这意味着AI生成的垃圾代码质量更高，还是数量更多？

        回复

        1. 当前数量绝对不占优势——若我理解正确，人类编写的代码已积累数十年之久。

          我想强调的是，这里“反AI”的HN群体每时每刻都在歌颂人类代码：“AI垃圾这，AI代码不可维护那…” 我从事承包工作多年，通常被请来收拾烂摊子。绝大多数情况下，人类编写的代码比AI生成的代码糟糕得多。后者的样本量虽小，但我的核心观点不变。那些诋毁“AI垃圾代码”的人，不妨选个自己最爱的语言/框架/… 然后去GitHub浏览人类编写的代码库(忽略xxxxxx之前的提交记录)，看看是否喜欢眼前所见 🙂

          回复

  16. 令人震惊的是，竟有如此多人轻视AI，或是固守着将代码直接复制粘贴到聊天机器人里这种开发方式。

    我发现这些工具在得到正确指导后，能以惊人的速度复现我做过的实验。原本需要数周手动输入的工作，通过与Claude Code对话几分钟就能完成。

    在实际工作中，很多时候关键在于取得成果，而非像软件工程师期望的那样编写“完美”代码。

    关注点：- 安全漏洞 – 看似正确实则错误的业务逻辑

    只要有领域专家坐镇，我认为这些问题会逐渐消失。希望大型语言模型能被训练成避免在代码中做不安全的事情。

    回复

    1. > 在职场中，很多时候关键在于取得成果，而非像软件工程师那样追求“完美”代码。

      但你应该明白，快速实现功能的能力取决于现有代码库的质量吧？真正的实践者需要在积极开发功能与持续维护代码库之间取得平衡，否则代码质量会持续恶化。

      在你的实验中，智能体能轻松找到这种平衡吗？我真心想知道，毕竟我对Cursor的经验有限。

      回复

      1. 直白点说，有点虚无主义：我靠交付功能拿薪水。

        客户要求周末前上线功能，周末前就得给。他们可没付钱让我花一周时间搞什么“高质量代码库”功能。

        但好消息是，我们已有客观自动化的代码质量检测工具。过去这些工具服务于人类，如今同样适用于AI。

        完善的单元测试规范、全面的代码检查工具、.editorconfig等机制，能强制人类和LLM在特定参数范围内编写代码。

        若项目尚未部署自动化测试和代码检查工具，现在正是引入的最佳时机。不妨借助LLM来协助完成 🙂

        回复

        1. 维护优质代码库不仅需要测试和代码检查工具，更关乎组织架构、恰当的抽象层级、架构设计以及模式选择。这些要素的验证无法真正自动化。若智能体一天内产出2000行代码的功能模块，却导致代码库分裂、函数重复或抽象层级混乱，最终必将演变成混乱的泥潭。

          话虽如此，若运用得当，大型语言模型确实能为健康代码库贡献力量，但这需要投入与LLM时代前开发工作同等程度的思考和规划。我敢保证，若长期固守现有代码库却忽视其健康状况，最终必将沦为开发者的噩梦之地。

          回复

          1. > 需要与LLM出现前开发阶段相同的思考和规划

            完全正确，使用LLM编码与实际人类编码并无本质区别。

            人类程序员同样可能在两周迭代周期内，写出2000行代码的功能模块——充斥着功能分支、代码重复和糟糕的抽象设计。

            用LLM你一天就能拿到这坨屎，还剩7-8天让它自己收拾烂摊子。换作人类程序员，你已经落后两周，功能还得经过质量检测(两周)，一个月内必须发布——所以…操 =)

            LLM生成的代码反馈循环远比人类快，这弥补了它(部分)缺陷。

            它能取代所有人类程序员吗？当然不能。但那些重复性垃圾工作——比如给处理程序添加CRUD操作，或为HTTP API新增参数并穿过企业架构的十二层垃圾抵达数据库层——完全能交给LLM处理，人类则可专注于真正具有创造性与挑战性的部分。

            回复

          2. 我猜你还没充分接触过智能体。赶紧试试看！你会明白的…

            在代理程序时代，你只需指导代理的风格、组织架构和技术选型。若你自诩为优秀程序员，那你的技能已毫无用武之地。如今你需要成为架构师和管理者。

            回复

        2. 起初我犹豫是否该说你的观点属于短期承包商思维，因此感谢你的坦诚

          回复

    2. 我并非轻视AI，但仍坚持将内容“复制粘贴”到聊天机器人中——纯粹将其作为模板库或研究工具使用。当意图或工作流已明确且目标精准时，输出内容的写法并不重要，因为我能快速“解析”其结果，就像高级版的VSCode预存片段模板。我绝不会让它替我设计软件——这需要真正理解问题本质。不过用它研究现有技术还是挺酷的。

      回复

    3. 并非所有人都开发网页应用/网络服务

      我发现这类工具的效果往往取决于项目专业度：越小众领域，效果越差

      回复

  17. 我曾让Claude Code在短短几小时内为一个相当复杂的内部工具编写了完整的单元/集成测试套件(300多项测试)。若由我或我认识并敬重的许多开发者手动编写，这需要数天时间。

    对此我存疑。虽然几小时内生成的测试是我认可的质量——若其他开发者提交的话我会通过——但最终并未发现实质性问题。

    回复

    1. 需要说明的是，这些绝非“1+1=2”这类愚蠢的测试。

      我让智能代理扫描待构建应用的用户界面，找出所有常见流程并保存至Markdown文件。

      随后要求代理针对这些流程寻找边界案例，并设计相应测试场景。接着我启动并行子智能开发测试套件。

      运行过程中发现了若干极具价值的边界案例——即便后续测试从未失败，这些发现本身就具有重要意义。

      事后看来，这确实让人觉得测试内容纯属无稽之谈。但Claude Code + Opus 4.5 + 6个并行子智能的协同处理能力令我震撼不已。

      回复

    2. 你注意到吗？从来没人说“我写出超棒代码了！”，永远都是“我写出好代码了，相信我”。

      人们总说自己的提示词很棒，生成的代码很厉害，一分钟解决一个月的工作量。但没人拿出证据。

      回复

      1. 看到太多类似帖子，我决定录制所有LLM编程过程上传YouTube。刚起步阶段，这个想法是周六才萌生的。

        回复

    3. 我发现用智能体生成测试用例的效果更好。

      回复

  18. 整个软件行业都在刻意掩盖一个事实：雇佣软件工程师的公司，其编写的代码与其他公司完全相同。有多少人曾在过去三家公司里开发过一模一样的该死的Web应用？可曾想过为何没人直接发布软件蓝图，再授权给工程师定制？因为相比兜售海量软件插件/SaaS等，这种模式利润微薄得多。

    雇佣工程师开发基础应用毫无附加价值。这正是AI的用武之地：复刻那些早已编写并发布到网络的代码。那些本就不该花钱定制的标准化软件。

    但AI无法解决其余80%的成本——维护成本、基础设施、监控日志、指标追踪、版本控制托管、安全扫描、质量保证、产品经理、设计师、数据科学家、销售营销、客户支持。这些才是构建和运营软件的核心成本。开发初始应用的软件工程师成本其实比表面看起来低。而且我们仍需技术娴熟的工程师来运用AI，因为AI本质上是个白痴天才。

    个人认为，人工工程师成本最多能削减50%。这虽非小数目，但相当于总营收支出的10%左右。

    回复

    1. >> 基础设施、监控、日志、指标、版本控制托管、安全扫描、质量保证 <<

      呃，这些不正是当前AI管理基础设施的核心议题吗？:-D 笑死

      回复

  19. 老兄，这标题够响亮。真想看看成本实际削减的数据。

    > 但在我看来AI代理能大幅降低…

    算了。这感觉有90%是噱头。

    回复

    1. 说得对。我本以为会看到类似“没有万能解药”的过去几十年回顾。

      结果这家伙宣称需要团队才能实现CI/CD，而他自己一天就能写出氛围代码，还说智能代码能彻底解决React过度使用造成的复杂性问题。

      回复

      1. 就算这话属实，我们让开发流程变得毫无必要地复杂，结果只是通过在足以填满小国的数据中心群里跑数模来挽回损失的时间？你根本没抽象任何东西，莫蒂，只是堆砌了更多垃圾。

        https://news.ycombinator.com/item?id=22601623

        回复

        1. 哦，如果大型语言模型真能解决过度依赖React的问题，光是这点就能让作者关心的软件开发成本降低近90%。

          没错，这完全是自找的麻烦，许多人压根不存在这种困扰。但大型语言模型让情况更糟，而作者竟为此欢呼雀跃。

          回复

  20. 我认为原型开发的成本确实降低了。

    但开发需要用户依赖并付费的生产级软件，其成本并未显著降低。最薄弱的环节依然是人类。

    调试复杂的生产环境问题需要对代码有深入理解。至少未来三四年内不可能实现。

    回复

    1. 这些工具主要实现两点：

      1. 剥夺他人对设计与实现的理解

      2. 让不合格者获得足够的信心参与贡献

      回复

  21. 是我漏看了什么，还是确实没有提供成本下降的证据？

    回复

    1. 证据嘛…但图表里那条曲线明显在乱跑啊！

      回复

    2. 尤其考虑到AI公司目前正持续亏损，这种模式根本不可持续。

      回复

      1. 没错，当另一只鞋落地时，我们沉迷于AI编程后，价格突然暴跌的局面就会出现。

        回复

  22. 若AI真具竞争优势，为何相关企业还要出售技术？难道不该用尖端内部模型，以极低成本轻松碾压几个Facebook，赚得盆满钵满？

    回复

    1. 那些妄想命令计算机代写代码的人，往往也是惯于指使他人开发应用的群体。

      我们正冲向一个崭新的世界：仅10%的人类需要劳动，其余90%则组成顶层官僚体系。

      回复

    2. 每次看到这类文章我都会问：真金白银呢？
      既然这么厉害，为什么没让你发大财？

      回复

  23. 我完全赞同。实际比例可能远超90%。比如昨天我就用手机上的Lovable(和Claude代码网页)构建出近乎1:1替代昂贵健身订阅应用的方案：https://strengthquest.lovable.app/

    这种生产力简直难以想象——仅用一天时间，我就能在手机上构建出替代昂贵软件的工具。我们正生活在不可思议的时代。

    回复

  24. 如果软件开发成本真的大幅降低——那这些软件都去哪儿了？

    你使用的软件产品是否涌现出大量实用功能？质量是否突飞猛进？终端用户能否看到任何切实变化？

    回复

  25. 那我可能用错了方法，因为我确实经常使用Claude Code，也觉得它相当出色…但我依然看不见生产力提升的具体体现，甚至不确定它是否存在(或许存在，只是我无法确切感知！)

    回复

    1. 问题在于你总在模型间来回切换，对每次变更都反复讨论/确认。

      你该给它一个较大的任务让它处理15分钟，同时在这15分钟里准备下一个任务。

      回复

      1. 当然。但难道我迟早还得理解这些代码？难道要像自己编写时那样要求其他成员审核批准？

        我至今仍坚持用三五年前的标准交付高质量工作。

        回复

        1. 当年编译器出现时，汇编程序员整天抱怨生成的代码多么丑陋低效

          若想提升生产力，你必须解决代码审查问题

          回复

          1. 你的解决方案是“直接交付更差的代码，反正大概没问题”？

            我认为是你自己的标准下降了90%…

            回复

            1. 不，不是更差的代码。是错误的代码。充满漏洞的代码。充满诉讼风险的代码。让你本月看似高效却暗中准备离职的代码，在你离开次日就彻底崩溃的代码。

              回复

          2. 我觉得这里可能有道理！揭示了未来可能的核心真相。但眼下我无法采纳这种方案。今天这绝非良策。

            回复

          3. 但生成的代码是否按指令执行且具有确定性？LLM完全不同。这个比喻不成立。

            回复

  26. 这笔估算中，投入GPU和新建数据中心的数十亿美元成本算哪一账？

    回复

    1. 完全同意，这些公司终将把成本转嫁给消费者，或许一两年内就会发生。尽管监管俘获让本地AI模型因“安全”理由越来越难运行，但趋势不可逆转。

      回复

  27. 我开始相信新型智能编程工具(半年前我还持怀疑态度)，但实际开发延迟和耗时并未改善——尽管我认识的人都在使用它们。我看到的仍是老问题：

    产品团队无法理解产品本身，因为若真容易理解，别人早就解决了问题，我们也就失业了。这意味着你仍需像往常一样反复迭代、深入讨论、不断探索。迭代过程或许能更大胆、更宏大、更快速，但软件的扩展性终究有限——个人能力的十倍提升，并不能带来组织能力的十倍增长。

    换个角度说。如果你的问题简单到只需200字提示就能完整阐述，那你很可能缺乏护城河，提供的价值不足以支撑竞争力。

    回复

  28. 作者开设人工智能工作坊。这本身无可厚非，但我认为此处应当说明。大量资金押注在大型语言模型(LLMs)的商业成功上，这解释了为何存在如此多的炒作。

    回复

  29. 在我看来，软件工程变得过于复杂——往往是毫无必要的复杂——人们争相采用诸如测试驱动开发(TDD)、微服务、超级复杂的React前端和Kubernetes等劳动密集型模式。

    肯特·贝克定义的TDD(https://tidyfirst.substack.com/p/canon-tdd)不应被归入此列。贝克的TDD本质是优化既定工作流程：拆分需求、自动化验证行为并捕获回归问题、重构代码以保持健康。这并非臃肿的工作流，反而能很好地推广至属性测试和契约式设计等实践。

    回复

  30. 软件成本的剧烈下降并非首次发生。早在1960年代初，IBM推出兼容1401机型的System 360时就曾引发变革。在此之前，软件寿命始终与特定计算机绑定——每次更换新机型就需重写软件。

    个人电脑的诞生，以及Turbo Pascal、Visual Basic和可自动化电子表格的出现，使得几乎任何人都能编写实用应用程序。

    如果编写代码变得更便宜，我们就会发现更多应用场景。

    回复

  31. 我总看到这类文章冒出来。我虽身处科技行业，但并非“人工智能”领域从业者。我完全无法理解的是：当前这些由风险投资补贴的项目，究竟能接近最终产品的水平？我总会联想到优步悖论——初期它确实很棒，如今却让出行成本翻了三倍，反而强化了出租车的定价权。这对消费者而言曾是福音，如今却成了K型经济的一部分。人工智能的终局是否也是如此？顶层用户能负担高额月费，普通用户每月仅享免费5分钟服务

    回复

    1. 即便如此，开源模型性能卓越且成本近乎为零？

      我个人更偏好Opus 4.5和Gemini 3这类开源模型，但若Anthropic或谷歌将价格提升十倍，所有人都会转向开源模型。

      或许有人会说中国实验室可能停止发布模型，这确实可能。但即便所有模型开发今日停滞，现有模型仍极具实用价值且足以构成有力竞争。

      回复

      1. 重申：我并非“AI”行业从业者，不完全理解其经济模式，也未在本地运行开源模型。

        本地运行这类模型的成本是多少？需要什么硬件配置？你说成本几乎为零，是指因为你已有2000美元的笔记本或GPU吗？

        再次强调，我只是出于未知而提问。这些本地模型能在我的2016款Mac Pro英特尔机型上正常运行吗？还是必须升级到最新M4芯片加32GB内存才能正常工作？

        回复

        1. 大型开放权重模型其实不适合本地运行(即便用当前硬件)，但多家服务商正竞相提供推理代运算服务，因此可以合理推测这个市场正在形成且会持续发展。

          回复

        2. 基本是这样，实用模型需要较新的GPU才能实现可用的推理速度。较小参数的3b/7b模型可在老款笔记本运行，但输出速度无法满足实际需求。

          回复

  32. 若软件开发成本下降90%，作者就无需撰写博客了。直接以80%的低价打压竞争对手(他们自己留10%利润即可)。

    回复

  33. > 我宁愿继承由代理程序配合优秀工程师协作开发的代码库，也不愿接手三年前离职的质量堪忧的承包商留下的代码——既无测试，又是一团意大利面式的类与方法乱麻。

    哦，这是伪命题呢 :/

    回复

  34. > 我曾让Claude Code在几小时内为复杂的内部工具编写了完整的单元/集成测试套件(300+测试)。

    那你得到什么？300个测试仅验证API实现暴露的行为。这些测试有用吗？部分有用，部分无用。无用的测试只会成为冗余负担和维护开销。更关键的是，许多需要深入API实现层面的使用场景并未被覆盖。而这类测试——真正验证业务场景的测试——才是发现回归问题的最有效手段。

    因此，若你的目标是在SonarQube等平台展示漂亮的测试覆盖率指标，让CTO满意，那么AI确实能带来巨大帮助。但若目标是加速开发有价值的测试用例，AI的作用就有限了。虽然仍能受益，但远不及90%的提升幅度。

    回复

  35. 复制GPL代码，再通过全局搜索替换品牌名称，向来能大幅降低软件“开发”成本。

    回复

    1. 真想知道哪里能找到完整的测试覆盖率代码，直接粘贴到内部工具里搜索替换就能搞定…

      回复

  36. 那为什么我的所有软件都变得更慢、更易出错、用户体验更差？

    回复

    1. 再举个例证：全球最知名的人工智能推广公司(微软)终于意识到Windows资源管理器启动太慢。

      这家拥有强大AI技术的公司，除了预加载应用到内存外，竟找不到其他优化方案。而这个应用本质上只是`ls`命令的图形界面。

      回复

    2. 我认为这揭示了LLM应用背后最大的谬误之一：认为降低生产者成本就能改善消费者处境的观念。有人将其比作蒸汽机时代。

      但蒸汽机时代消费者付出了代价：你花更少的钱，却得到(我猜大多数情况下)更差的产品。而对于LLM等机器学习技术，除非你付费购买软件(且软件本身确实更便宜)，否则这种代价根本不存在。阅读LLM生成的文章与阅读真实文章所需费用相同；你的网络账单不会因此减少。免费软件亦是如此。它们只是质量更差，却毫无益处。

      从这个意义上说，Hacker News充斥着生产者——他们常因偷工减料获益，而LLM恰恰助长了这种行为，因此这里自然聚集了大量拥趸。看到评论区有人提到非科技行业的玩家讨厌“AI”。这很正常——他们不是生产者，自然得不到好处。

      回复

    3. 对吧？过去几年软件质量简直一塌糊涂。

      回复

  37. 我认为大量原本需要高薪聘请人员完成的工作已被取代。

    仅以金融界为例：2010年时，没人懂编程，没人懂SQL，即便有人掌握这些技能，学习开发系统的机构知识也不值得他们投入时间。于是需要层层开会、经多级管理层传递指令。结果小事根本办不成，所有事情都耗时耗力。

    到2020年，多数初级员工掌握的Python已足够处理小任务

    到2025年，AI工具已足够强大，能处理2010年因流程繁琐(而非技术难度)耗时数周的任务，如今仅需数小时。过去耗时一小时的任务，若要向缺乏金融知识的人员说明，需多次会议才能完整阐述；如今他们自己完成的时间，甚至比向计算机科学应届毕业生解释所需的时间更短。

    那些初级交易员/策略师如今能独立完成的任务，过去需经IT部门审核才能上线，耗时数周甚至数月。如今我目睹相关成本每日骤降90%。这实属好事——技术人员得以专注技术本身，无需钻研某个陌生国家的期权交易细节。

    回复

  38. 阅读这些评论令人着迷——我相信每位发言者。有人获得巨大生产力提升，有人收效甚微，或许我们并非从事相同行业。我曾涉足各类工作，虽统称为软件开发，但工作性质差异显著——有些工作虽不具挑战性却仍需大量手工操作，这或许正是人工智能自动化能轻松取胜的领域。另一些工作则充满挑战，但我从未尝试在工作中使用AI，因为公司政策禁止。我在个人项目中玩过AI，它确实帮我掌握了从未接触过的语言，但生产力提升从未接近90%。总之，这话题太有意思了！

    回复

    1. 我认同你的观察。在我的工作中，我为少数客户承担了软件开发实践中大量跨领域职责——这些本应由不同岗位分工完成。这并非因AI而起，早在AI热潮前我就从事此类工作，这只是代理机构运作的常态。

      我的观察是：AI真正大幅提升的业务占比约15%，其余部分几乎未受影响。毕竟绝大多数工作本质上并非编码。代码生成功能也存在缺陷——为获得优质结果，我常耗费大量时间整理需求并设计提示词，这些工作其实我自己动手更快。

      其中存在一个理想状态：需求描述简单明了，代码本身足够简洁，但需要编写的量又相当可观——此时无需亲自动手编写确实令人欣慰。然而即便如此，我仍发现AI往往难以胜任，若需尝试三次才能让它正确完成任务，便毫无效率提升可言。失败尝试耗费的时间往往相当可观。

      通常需要编写的代码量并不大，但逻辑相当复杂且必须准确无误——这正是我发现大型语言模型(LLMs)失败率过高、浪费时间的关键所在。

      (我拥有18年以上“全能型”开发经验，此处经验基于使用Claude Code的实践)

      回复

  39. 严格来说，生产力提升应为800%。实际成本反而增加了。

    此处指我作为独立开发者的亲身经历。

    借助AI辅助后，我编码时间非但未减少反而增加。

    但能更快实现那些尘封已久的功能确实令人振奋。如今每小时编码能产出多达8倍的功能与问题解决。

    此外，虽然每月服务器成本仅数十美元，如今我还要为AI编程订阅服务和大型语言模型API调用支付同等金额。分文不差都物有所值。

    因此尽管生产力大幅提升，我的实际成本却同步增长。

    回复

  40. 或许未达90%，但所有人都能看见地平线上浮现的征兆。

    故事是这样的：某天视觉艺术被商品化到极致，任何视觉作品都能以近乎免费的价格在数字世界获取。这种现象已持续数百年。听觉艺术(如诗歌朗诵录音、播客、音乐)早已商品化。完全商品化或许永远不会发生(即你仍能在该领域工作)，但它对各领域产生的巨大影响是不容置疑的。获得毕加索级别的画作或许尚不可及，但我们正逐步接近这个境界，音乐领域亦是如此。

    开发者行业同样面临相同命运。

    开发行为本身尚未完全商品化，但要对该领域产生重大影响其实并不需要太多条件。能够获得2010年代后期薪资水平的开发者比例将逐渐下降。这就是早期商品化的真实写照。

    回复

  41. 大型语言模型在计算文本/代码的可能性。它们能在极短时间内处理海量数据。但可能性文本/代码不等于正确文本/代码——这只是庞大可能性集合中可能正确的片段。其危险性在于看似正确实则可能错误。这种无法管理的混乱局面很可能推高软件成本。

    回复

  42. 某些人凭空捏造数值统计数据时为何能心安理得？

    回复

  43. 我真心喜欢它编写枯燥代码的能力。

    举例来说，我曾需要一个Visual Studio插件。过去我会耗费数小时开发或干脆放弃，但这次用Claude代码写成——虽不美观有趣，也缺乏测试，却能正常运行并节省时间。它毫无价值，永远不会部署到生产环境，我可能分享但不会变现，这段枯燥丑陋的代码却完全满足需求。

    编写小工具从未如此简单，成本可能降低90%

    回复

    1. 具体实现什么功能的插件？这里和其他帖子下大量评论都遵循固定模板："我原本想实现X功能，过去需要耗费N小时，但现在借助LLM工具L，耗时大幅缩短。虽然不能透露具体需求X，但LLM工具L确实超实用。兄弟，你信我吧"

      回复

      1. 最让我哭笑不得的是那条反复出现的广告：“想象一下能开发出印着你名字的应用！”我心想…如果连放名字这点小事都搞不定…还把这当首要任务… 真不知该怎么说你。

        啊，就是这个：https://www.youtube.com/watch?v=-FEWLvKztD0

        回复

  44. 我认为AI能成为极强大的工具。使用它确实能提升效率，但大量时间都耗在审查代码、排查问题(总能发现漏洞)、反复调整指令上，最终往往放弃改为手动修复。不过它确实缩短了功能实现的平均耗时。但我也担心并非所有人都能认真检查/修正AI生成的代码。

    回复

  45. 这篇文章写得相当不错——但它忽略了关键问题：多数这类智能体都是基于糟糕的代码训练的——而这些代码恰恰是开源的。

    那么实际操作中这意味着什么？对于在专有系统上工作的人员(成本永远不会降低)——代码不在GitHub上，可能托管在内部版本控制系统(如Bitbucket等)。这些智能助手从未接受过该代码的训练——是的，它们或许能协助文档工作(但它们使用的是最新文档吗？)

    对于其他场景——智能体可能生成劣质代码，做出不存在的假设，调用已废弃或根本不存在的API？

    每种情况都需要经验丰富的开发者具备：1. 技术专长 2. 领域知识？那么资深开发者的成本是否降低了？我认为没有——反而在上升

    当前流行的“氛围编程”——大多是封闭系统内的工具/应用(从不真正与外界交互)，或是基于历史操作推断的脚本。但这些人真在创造新事物吗？

    我还注意到成本与复杂度存在严重混淆。零利率政策迫使人们在高度抽象的框架(如Kubernetes、Next.js、微服务等)上开发软件，导致人们误以为需要庞大团队。但事实恰恰相反——绝大多数软件仅需1-3人团队即可完成，这已有无数实例佐证。

    因此人们认为降低成本的捷径是使用AI代理，而非直面问题——以更简洁的方式构建软件。AI会有所助益吗？当然，但远不及每日宣传或撰写的程度。

    回复

    1. > 这些代理是在糟糕的代码上训练的——而这些代码是开源的。

      这种说法值得怀疑，与我三十余年从业经历相悖。羞于展示源代码者不会将其开源。总体而言，开源代码质量通常高于闭源代码。

      当然，如今需避开学生作业性质的GitHub仓库，但我认为这并非根本问题。

      回复

    2. 大型语言模型曾以杂乱低质代码为训练素材的说法或许一年前成立，但如今恐怕已不复存在。

      所有主流模型供应商都在比拼模型的编程能力。提升模型产出代码质量的关键，在于提高训练数据的代码质量。

      筛选高质量代码作为训练数据，比筛选其他类型的高质量数据要容易得多。

      我强烈预感，当前前沿模型所用的训练代码质量，远高于一年前的水平。

      回复

  46. 智能编码工具在将业务逻辑规范转化为规范API和服务的方面已表现得极其出色。

    我完全没有这种体验。它们处理绿地服务尚可(如作者所述)，但通常达不到“极其出色”的水平，顶多算是“勉强合格”。这也没帮我节省时间——我仍需逐行阅读审核并修改代码。

    回复

  47. > 我曾让Claude Code在数小时内为复杂的内部工具编写了完整的单元/集成测试套件(300+个测试)。若由我或我认识的多数开发者手动编写，需耗费数天。

    但这些测试的价值何在？当我尝试时，AI常会重写代码以匹配其拙劣的测试逻辑。

    回复

  48. > 过去需要小团队耗时搭建CI/CD环境…如今借助智能编码命令行工具，几乎所有工作几小时就能完成

    我接过几个项目，专门为那些凭感觉编写基础设施的团队收拾残局。我并非否认这能为拥有丰富基础设施经验的团队提速——但它无法替代团队多年积累的基础设施经验。

    回复

  49. 贝特里奇定律再次应验。标题的答案是：不。或许未来会实现，但无人知晓。

    我怀疑撰写此类文章的人究竟在多大程度上使用AI构建非平凡软件——所谓非平凡，指的是那些存在数年、经实战检验、布满紧急修复疤痕的_不完美_代码库，它们需要应对突发危机的权宜之计，处理奇特边界情况的折中方案，尤其需要整合历经多位开发者长期贡献的代码库。

    就在今晨，我使用Gemini 3 Pro处理某个简单功能时，询问其解决某个问题的思路，它竟完全凭空杜撰出解决方案——建议使用某个据称由库暴露但实际并不存在的函数。这种情况在我多年经验中早已司空见惯，尽管随着时间推移有所改善，但至今仍非常、非常普遍。如果它连这些基本用例都无法达到可接受的成功率，我实在难以相信它能胜任主动决策的重任。

    这仅仅是从纯粹的可用性角度出发。若考虑经济层面，目前没有任何人工智能服务实现盈利，它们全都依赖投资者资金的大量补贴。这种模式能长期持续吗？眼下看似资金源源不断，但我敢打赌，在软件开发成本下降90%之前，这种补贴终将难以为继。

    回复

    1. >我询问如何解决某个问题，它竟凭空杜撰出解决方案，建议使用某个据称由库文件暴露但实际并不存在的函数。

      没错，这正是大型语言模型(LLM)的重大痛点。个人而言受影响较小，因为我的代码库对库的依赖极低(从接触面来看)，所以如果某个功能不存在，我直接让LLM实现它幻想的功能就行了 😛

      这类幻想通常是“逻辑上应该存在但尚未实现”的信号，而非纯粹的胡扯。

      回复

  50. 有人能指导我如何搭建这种编程环境吗？

    过去八年我没写过生产环境代码，但有17年开发经验(涵盖C++、全栈、.NET、PHP等多领域)。

    个人层面接触过AI，掌握基础知识。曾借助Claude/Github辅助修复和编写陌生语言的代码片段。但如今人们似乎能在更短时间内部署大型实际项目。一位值得信赖的旧同事提到，他创办的初创公司开发速度比我们当年快三倍。

    是否有资源能阐述当前最佳实践(想必都是全新领域)？我该从何入手？

    回复

  51. > 这需要相当大的思维转变，但真正的艰辛在于概念性思考而非敲代码。

    但艰苦的工作向来是概念思考？至少在资深级别及以上，对我而言真正的挑战始终是构思过程，而非将想法转化为代码。

    回复

  52. 文章中提到：

    “我曾让Claude Code在数小时内为一个相当复杂的内部工具编写了完整的单元/集成测试套件(300+个测试)”

    你注意到作者刻意回避的问题了吗？这些测试是否有效？它们真的算测试吗？我正在玩Opus(程序员最佳消遣)，它编写伪代码和伪造结果的能力堪称卓越。它为我生成的测试通过了验证——对象是某个极其复杂的实用工具。

    测试内容是什么？调用该工具时传入无效参数，验证是否触发错误。

    回复

  53. 我们正处于这样一个时代：多数人对软件质量的认知不足以撼动整个市场。这让我想起柠檬市场理论——当消费者无法辨别产品优劣时，整个体系便会崩塌。

    回复

  54. 构建首版FB的成本已降低90%
    后续版本的开发成本保持不变

    更精密的工具意味着更精良的产品。

    若碳纤维加工技术变得更简便廉价，这并非意味着利润缩水——而是意味着碳纤维将无处不在：餐具里、鞋履中、婴儿车里，无所不包。碳纤维自行车成本将降90%，但车队投入将大幅增加。

    可以说每行代码成本下降90%，但代码总行数将增长100倍。

    回复

  55. 如何设计严谨的研究方案，衡量团队整合AI辅助工具后的全生命周期成本——涵盖后期维护与缺陷率，而非仅关注初始产出速度？

    回复

  56. 可能产生的间接影响包括：

    – 更多工程师从雇佣制转向独立开发
    – 减少开源软件弃养现象

    – 独立开发者、小型团队及开源软件开发者将更有能力迎头赶上，与科技巨头展开更有效竞争。

    我认为AI智能编码工具对科技巨头的威胁，将远大于其对软件工程师群体的整体威胁。

    回复

    1. > 我认为AI智能编码工具对科技巨头的威胁，将远大于其对软件工程师群体的整体威胁。

      目前我并不认同。编程代理的性能通常取决于其背后的模型质量。运行强大模型需要依赖资源支持——即便Sonnet 4.5或Gemini 3是开源的，也并非所有人都具备支撑它们的硬件和算力。因此在顶级模型能部署于个人计算设备之前，我认为编程代理不会对任何组织构成威胁。

      回复

      1. 无需自建服务器，每月100美元/工程师的成本已能满足多数应用场景。

        回复

  58. 建造可以。维护不行。

    汽车不会便宜，因为保险杠价格暴跌90%

    但是….

    显然人工智能将全面改造汽车，所以我将基于90%变革即将到来的假设运作。我们终将成为具有自主性的指挥家。

    回复

  59. 这与我的经验不符，氛围编码的代码通常是无法使用的垃圾。我将其作为动力来源。

    我要求它完成任务，若成功便直接保留不作检查；若失败则查看代码，惊恐地退缩，删除后亲自重写。

    虽然耗时更长，但对我似乎有效。

    回复

  60. 很快就能见分晓。我早该提醒：十倍效率提升意味着生产力爆发式增长。换算下来，团队原本十一月完成的软件开发，现在一月底就能竣工。

    回复

  61. 若2026年软件开发成本真能降低90%，那么简易应用和弃用软件将激增十倍。就像一次性手机那样，软件也将成为消耗品。这景象会很诡异。

    回复

  62. 这要看情况。AI能否胜任大型项目取决于…(很久以前在AI领域发过相关帖子。https://getstream.io/blog/cursor-ai-large-projects/)

    但你需要：资深工程师进行指导，完善的标准化流程和测试最佳实践。在这种条件下，效率确实能提升10-50倍。不过多数团队/产品并不具备这样的环境。

    回复

    1. 我正在处理一团巨大的开源意大利面代码，AI已成为我梳理代码的无价之宝。即使它出错时——也能提供宝贵的线索。

      回复

  63. 软件开发仅占整体成本的一小部分。任何重大生产部署中，成本主要投入在变更管理和支持上。

    真正的新项目开发工作占比微乎其微，其余全是管理混乱的日常。

    回复

  64. 15年前有人告诉我：自从外包兴起、所有软件工作都转移到印度后，编写软件的成本已下降90%。

    回复

  65. 软件开发远不止编写代码。编码工作或许已简化90%，但其他开发任务并未因人工智能显著改变——尽管未来可能实现。因此至少目前，标题所提问题的答案是否定的。

    唯一例外可能是构建预先明确规范的系统，比如直接复制现有软件。

    回复

  66. 分享个小故事：我曾用Gemini命令行工具实现C++ API的大型功能模块。Gemini完成了大量本需手动编写的代码。问题在于？这堆出色代码里暗藏着内存漏洞。你只需向命令行输入参数就能完成任务，看似完美无缺。经过四天调试才找到漏洞。更不用说Gemini在故障排查过程中，连漏洞所在位置都未能接近过…未来会改变吗？且看后续发展…

    回复

  67. 这好比说RoR或Django让建站成本降低90%，因为你能用5行代码写博客应用(依稀记得早期Rails的宣传语)。

    诚然某些任务成本可能降低90%(尽管我认为这个数字仍偏高)，但软件开发的整体成本绝未下降90%。

    我或许能用30秒写出脚本而非30分钟，但仍需思考：是否需要脚本？具体功能是什么？要构建什么、如何构建、为何构建？如何满足所有需求？这些环节的投入可不会减少90%。

    回复

  68. 虽不敢说减少90%，但过去需要2-4周完成的工作，现在两天就能交付。

    特别是Opus 4.5版本带来了颠覆性变革。我不确定软件开发作为职业如何在这种变革中存续。我几乎没有理由为公司雇佣开发者——只需写个规格说明，Claude就能一气呵成完成。

    说实话这令人恐惧，只希望公司别倒闭——毕竟作为开发者我完蛋了。但……从概率看我的生意注定失败。

    我预见几年后软件公司将所剩无几——唯有那些掌控分销渠道的巨头能存活。如今产品几周就能被克隆，不久后恐怕只需几分钟。过去半年才出现一个新竞争者，如今几小时就有一个。

    回复

    1. 好奇问一句：使用AI前，你两周内能开发出什么软件产品？或许是我误解了你对“交付”的定义。

      回复

      1. 指的是功能迭代，而非完整产品。

        回复

    2. 感觉过去几年里，关于FooBar X.Y模型的这种论调我至少听过六遍了。

      回复

    3. 同意。Opus 4.5确实带来了质的飞跃，我的体验与你完全一致。过去需要数周完成的工作，如今几天就能交付。而且质量标准大幅提升——若采用手动构建，测试套件规模会小得多。MVP Bootstrap CSS中的所有内容大概都适用。

      回复

    4. 没错，我确实认为软件工程时代即将终结。虽非当下，但Opus 4.5的卓越表现预示着5版和5.5版很快就会发布。

      它们未必能实现全自动化，但构建可运行软件的门槛必将大幅降低。

      回复

    5. 我实在无法想象如何在两天内调试出足以发布的代码。大型语言模型写几千行代码或许可行，但谁能读懂？

      你们难道在发布未经任何审查的代码，还宣称其质量上乘？

      这些讨论令我困惑。我从未在任何地方看到软件泛滥的现象。更没见过企业争相修复那些在缺陷追踪器里积压多年的老问题。人们总说LLM代码正如洪水般涌现，但这些代码(实际代码)全都秘而不宣。究竟为何要保密？任何推出AI功能的市值数十亿美元公司，其旗舰产品怎么可能还存在已知缺陷？

      向外观察时，我未见任何变化。个人虽觉得它有用，却不得不不断强制重构和重设计来保持代码可读性。每当添加功能，漏洞便会重新出现，重构成果被回滚，监控工具悄然消失。若不持续重构，我甚至半数时候都不会察觉这些变化。

      回复

    6. 很想听听你正在开发什么类型的软件。

      回复

      1. 这是我的匿名账号，不便透露具体信息。每月营收5万美元的小众独立开发者SaaS产品。

        回复

  69. 我完全赞同。目前正在为一个小众行业开发新平台。整个行业总收入可能只有1000万美元。去年还不足以支撑融资、雇佣产品经理、开发人员、测试人员等团队。但对我这样的独立开发者来说，借助AI技术，现在绝对值得投入。

    回复

  70. 确实如此。我的支出可能不到10%，省下了海报成本、定制集成偶发的合同费，以及连接各系统的Zapier费用。

    企业级领域我不清楚，但在1-10人的小团队中绝对适用

    回复

  71. 能否也考虑构建软件带来的精神成本？在我看来，管理代理产出比亲力亲为更耗费心力。

    而且显然，不再像从前那样深入掌握复杂技术细节(即保持宏观视角)的代价终将显现

    回复

    1. 这活儿真够呛啊！我挺意外的。我搞个人项目时，虽然最终成功了，但过程还是有点煎熬。

      回复

      1. 说实话现在我只在极窄的领域用智能体，避免产生麻木感。它剥夺了亲手构思和创造的乐趣

        回复

  72. 我喜欢大型语言模型让所有人忘记验证软件正确性有多难、维护现有软件有多难。人们总在赞叹模型编写代码的速度，每当我指出模型错误频出时，大家就挥手说软件验证很简单。所有软件公司的庞大质量保证部门、CVE数据库、零日漏洞中介等都会强烈反对这种说法。但你知道的，无所谓啦，他们不过是老派人士罢了？

    回复

  73. 我愿意相信情况确实如此，我们最终或许真会走向那个境地。

    但当前可复现性、可靠性、正确性和一致性都存在缺陷。

    各领域间还存在显著差异。

    回复

  74. 写“贝特里奇标题定律”似乎过于直白，但答案显然是否定的。看看他们那张毫无单位和依据的虚构“成本随时间变化图”闹剧就够了。

    回复

  76. 在需要高度客户定制化的B2B SaaS产品领域，我认为这个数据有其合理性。

    我观察到的最大瓶颈在于：如何快速将需求转化为代码，从而向客户证明其提供的需求不准确或不充分。直到最近，若认为需求存在缺陷，开发者仍需避免投入编码时间——因需求模糊而浪费两周以上工作时间，这种情况实在令人沮丧。

    假设今天你运气爆棚，仅凭一次需求沟通就能完成99%的工作。即便剩余1%的收尾工作令人头疼，但若这1%足以让客户敲定最终需求，那又何妨？你完全能在完成一次每日站会的时间里，捣出一个80%完成度的原型。80%的完成度有什么不好？在此情境下我并不这么认为。交付近乎可用的成果，远比纠结设计文档、确保需求完美契合开发者偏好高效得多。略有偏差的方案，总比毫无进展更快获得精准答案。

    回复

  77. 文章中提及编写巨型单元测试套件作为典型案例，这难道不是对核心问题的有力反驳？

    然而结论却暗示答案是肯定的？

    除非人工智能能实现组织化协作而非个体运作，否则它必然只能带来相对有限的改进(例如为耗时数周/数月/数年的项目节省20小时开发者单元测试时间)，这些改进在经历Y人协作后收效甚微。

    当然，对于简单项目、基础需求、单元测试，以及由精通系统且能鉴别代码优劣的小型紧密团队处理的任务？我能理解效率提升90%的可能性。

    但在我所在的大公司，AI似乎并未显著提升组织效率，而单元测试不过是项目冰山一角。我知道很多人使用AI助手，也知道很多人不用。我尤其担心年轻工程师——他们未必具备分辨代码优劣与无关性的能力，结果在文档里留下明显多余的代码段落。至于资深工程师们，他们似乎能驾驭得不错——尽管我敢肯定，他们的工作量并未比四年前增加十倍。

    最后这段有点跑题了，总之想说的是…组织效率才是亟待解决的症结。

    (这确实很难，我认为过去四十年沿用的二维界面根本无法满足我们所处庞大代码大教堂的需求，组织架构、代码审查等所有环节都面临同样困境)

    回复

  78. 这个观点令人着迷——坦白说，它就像那些唯有事后才能完全认清的变革。软件开发从耗时数月的协调与工程开销，转向由小型高杠杆团队实现快速迭代的转变，既令人振奋又略显不安。

    成本削减90%不仅关乎效率，更关乎可及性。若软件交付门槛骤降至此，我们很可能正站在新一轮创新浪潮的起点——这股浪潮不仅由工程师驱动，更将汇聚那些曾因成本无法支撑而被排除在外的领域专家。

    最耐人寻味的启示在于：技术造诣可能不再是护城河，而情境感知与领域智能将成为真正的差异化优势。这将颠覆科技行业的传统权力格局。

    2026年或许真会成为“快速构建、果断舍弃、智慧重构”从鲁莽之举变为常态的转折点。

    令人好奇的是：组织适应变革的速度究竟有多快？又将有哪些人因低估颠覆速度而被时代抛弃？

    回复

  79. 构建“某物”的成本已降90%。构建“优质之物”的成本或许仅降30%。

    演示版与成熟产品的鸿沟依然巨大。

    回复

  80. 软件编写成本下降了，但复杂度却呈指数级增长，因此我们需要人工智能助手代劳全部编写工作。

    回复

  81. 假设你说得对。但我们真的还想要这样吗？我的意思是，终有一天我们将失去照看人工智能代理的能力。

    回复

    1. 当大型语言模型的代码库复杂到现有人力无法理解和调试时…这在我看来正是企业回归真实开发者的转折点。任何关键任务代码都需要具备专业知识的人员随时待命，以便在危机爆发时迅速介入，扑灭火势并修复致命漏洞。

      回复

      1. 除非你能让AI五分钟重写整个技术栈直接部署——持续重写/持续部署才是王道！

        回复

  82. 这或许能暂时拉平竞争环境，但长期来看反而会大幅提高门槛。

    随着更优秀的工程师和设计师获得更大影响力，同时减少会议和其他人的干扰，他们将能够构建出更优质的软件——这种软件所具备的品味和精致程度，在需要手动编写所有代码的时代是难以想象的。

    回复

  83. 训练智能体的成本高达数十亿，因此我不认为成本有所降低，只是发生了转移，如今成本分布结构已然不同。

    回复

  84. 或许是我理解有误，但我并未真正看到大型语言模型辅助软件开发带来的巨大生产力提升。工作正迫使我们使用AI——虽未强制要求，但已处于DEFCON 3级警戒，濒临2级(DEFCON 1级即Shopify那种全面部署状态)。我团队的实践表明，即便产出勉强能投入生产的简易成果，也需要大量人工引导和手动修正。

    我在约2.5年前关闭某条评论时写道： “我不确定将大型语言模型融入编程是否(目前)只是在制造无限混乱，最终由人类收拾残局。”我的实践经历正印证了这种观点。当账单到期、风投资金枯竭、AI供应商开始抬高价格时…人类清理AI烂摊子的市场恐怕会迎来爆发式增长。

    回复

  85. 编写代码的成本确实降低了——但我认为远未达到90%。或许降低了30%，但需加上一个大大的星号注释：“前提是某处已有类似代码，或仅需机械式重构”。

    关键在于，编写代码只是构建软件的第一步。你总要审核AI生成的代码吧？当程序出错时，责任仍由你承担。更要持续维护支持这些代码——在我看来，这同样属于“构建软件”范畴。

    这让我想起那些(令人惊叹的)Vim高手，他们用神秘的键盘操作在代码库中穿梭自如。作为Vim主力用户，我连他们十分之一的操作都无法模仿。看着他们编辑文件简直令人着迷，仿佛思想直接转化为屏幕上的文字。

    我也深知编辑只是第一步。若跳过后续环节，你正被利益驱动的行业所误导。

    回复

  86. 生成美观代码的成本已降低90%……你自行判断吧。

    回复

  87. 构建成本下降90%，但维护成本却暴增9000%

    回复

  88. > 常听到的质疑是：大型语言模型只适用于绿地项目。对此我坚决反对。我曾耗费大量时间解析三年前的代码库——所有编写者早已离职。

    在我所在的领域，三年历史的项目算绿地项目，而真正古老庞大的项目已有二十年历史，包含八百万行糟糕的C++代码。看来我还得再等等……

    回复

    1. 核心论点是：从头构建成本能降低90%。

      当LLM连四条消息前的对话都记不住时，我实在看不出它们能为这种规模的项目贡献什么

      回复

  89. 坦白说，我对AI的使用模式在不断演变，有时甚至连续数日不用它。但它确实能完成我无法独立完成的任务——比如为400多个模型重新排列图标，还能让我对某个主题掌握足够知识后便能独立推进后续工作。

    AI至今大概帮我节省了100小时重复性工作，彻底免去了依赖他人处理耗时配置任务的麻烦——那些来回沟通曾让我工作停滞，毕竟我是那种能连续工作20小时完成任务却不会大幅降低效率的人。

    回复

  90. AI每月顶多帮我节省一小时。我至今不解为何如此炒作。这根本是为解决虚构问题而生的方案。它解决不了硬编码难题，遇到复杂问题时也毫无预警。价值甚至不及Resharper。商业价值顶多每月10美元，根本无法支撑整个行业。

    回复

    1. 我时常看到这类评论却始终无法理解。当众人都在告诉你它能显著提升软件开发效率时，你却因自身工作流程特殊性而视而不见。显然它对他人具有巨大价值。

      假设你是椅子制造商，当所有人都能使用一台能批量生产椅子的机器，但它有时只吐出三条椅腿或搞错椅背设计，你可能会觉得毫无意义。或许它无法复刻你精湛的手工技艺。但请相信，他人定会善用这台椅子制造机，在克服缺陷的同时将单价从20美元压至2美元。24个月后，你的手工椅将难以维持销量。

      回复

      1. 或许，也或许是椅子市场规模扩大了，因为2美元的椅子吸引了更多买家。高端市场基本不受影响，因为他们本来就不会购买低端椅子。

        回复

      2. > 你置身于人海之中，听着众人宣称他们正以更快的速度开发软件，满足所有必要条件

        但事实恰恰相反。所有人都困惑这玩意儿究竟有何用处。人们强烈抵制这项技术，它却被硬塞给我们，尽管价格高得离谱。

        编程本应是最容易解决的问题之一，但所有大型模型都写不出基础的“真实”代码。只要复杂度超过乒乓球游戏就会崩溃。比如它们甚至无法用现代C++模板技术写出一个像样的函数。

        回复

        1. 其实它们能做到——我原以为不行，但最新版本竟能实现，令我大吃一惊。

          在尝试Cursor 2版本后(Cursor 1仅运行了10分钟)，我彻底改变了看法——它竟能编写完整的应用程序，包含文档、测试、覆盖率、持续集成/持续交付等全套流程。当我在使用应用时遇到错误，它竟能自动运行代码、插入额外日志、通过grep检索日志、定位错误并完成修复。

          回复

        2. > 它们甚至写不出一个带现代C++模板的完整函数。

          这完全不准确。ChatGPT 4能清晰阐释模板概念，但实现时总会出错。最新模型在生成模板代码方面普遍很强，即使相当复杂的模板也不例外。

          不过若涉及ADL边界情况或静态初始化等细节，它们仍会彻底失控，开始建议毫无意义的方案。

          回复

        3. > 编程本应是最容易解决的问题之一，但所有大型模型都无法编写基础的“真实”代码。只要复杂度超过乒乓球游戏，它们就会崩溃。例如它们甚至无法用现代C++模板机制编写一个完整的函数。

          这种说法纯属无知谬论

          回复

          1. 事实并非如此，我上周刚用所有主流模型测试过。遇到折叠表达式等非平凡场景时，它们会彻底崩溃

            回复

  91. 出自“十倍工程师”创造者之手：

    0.1倍工程成本

    回复

  92. 打造卓越产品的成本与触达客户所需的时间并未减少

    回复

  93. 我曾让Claude Code在数小时内编写完整单元/集成测试套件(300+测试)

    真想看有人直播完成这类任务。每次读到这类描述都觉得自己像个傻瓜——尽管频繁使用Claude Code，我却从未获得过如此规模的输出，生成的代码不是粗制滥造就是完全无法使用，甚至开始怀疑手动编写是否更快。

    宣称软件成本已降低90%的说法在我看来荒谬至极，我渴望更深入理解这种截然不同的世界观从何而来。是我使用工具的方式有误？还是涉及不同领域/语言/生态系统？

    回复

    1. 完全赞同。目前我用Claude Code编写90%的代码，但发现它编写有意义测试用例的能力确实不如初级程序员。多数时候它会错误构造接口或模拟对象，最终只能放弃改手动编写。它生成的“测试”大多在验证无意义内容(如接口是否存在)。这是在TypeScript+Vitest搭配Opus 4.5环境下的体验。

      回复

  95. 这类文章总在炒作周期顶峰时走红——当人们试图维持热度，却隐约察觉威利·E·鹫早已冲出悬崖在半空悬停的时刻。显然，无论用何种客观指标衡量，软件开发成本几乎未见下降，“通用人工智能”遥遥无期，而顶尖科学家们似乎正被下一个热点吸引——毕竟他们已目睹自身(诚然卓越)创造物的局限性。

    我确信AI工具将长期存在并日益融合完善。但最终结果究竟如何？是METR研究预言的-20%生产力？还是+20%？若宣称达到90%增长，那不过是r/WallStreetBets论坛惯用的耸人听闻之辞。

    回复

  96. 我认为作者低估了协调开销产生的影响。

    所谓“优秀的人工智能开发者”实属神秘存在(并非虚构，但在企业眼中确实如此)。当前企业正试图量化评估他们，以洞悉其核心价值。

    一旦评估体系建立，我敢断言下一步必将试图控制其产出——这必然扼杀他们的生产力。

    > 如此一来，真正掌握这项技术的开发者才能高效解决商业难题。

    明白我的意思了吗？

    “要是能让他们帮忙解决问题就好了…”

    当然可以！但这意味着额外的协调成本，他们的工作效率将不如从前。

    > 你的工作即将改变

    我的工作时刻都在变。开发者早已做好准备——他们生于变革，长于变革。你知道什么还没跟上变革的步伐吗？

    回复

  97. > 但在我看来，AI代理能大幅降低软件开发的劳动力成本。

    所以所谓“成本大幅降低”的论断，不过是作者杜撰的(用业内术语说就是“幻觉”)？

    这似乎印证了贝特里奇定律。

    回复

  98. 我判断AI是否真正产生影响的标志，是leetcode概念的消亡。若你近期参加过面试，就会明白AI至今尚未带来实质性变革

    回复

  99. 我正在使用Gemini 3的免费版本。在我的干预下，它用Emacs Lisp构建了一个原始递归函数来判断数字是否为质数(所谓mu递归，是指由常量、后继函数、投影函数、原始递归函数及组合函数/宏等基本单元构成的函数)。这令我印象深刻，因为之前的模型(包括Anthropic和OpenAI)都无法做到。

    过去几天我要求它用Emacs Lisp构建μ递归的阿克曼函数(基于原始递归函数/运算符，并额外添加最小化运算符)。我指出它已构建的质数检测函数应能复用相同函数/运算符，必要时可重写代码。

    目前它仍未能完成此任务。若我认为它有能力实现但受限于Emacs Lisp，或许会让它尝试用Scheme或Common Lisp等其他语言实现。在每日免费配额允许的时间内或许能成功，但至今尚未取得进展。为避免系统过载，我将阿克曼函数的输入范围设定为0,0 – 0,1 – 1,0 – 1,1，但它连0,0都无法处理。此外它试图重定义Emacs Lisp关键词“and”，导致Emacs运行异常。

    一年前，大型语言模型还无法处理我要求生成的Leetcode和Project Euler函数。如今它们似乎略有进步，Gemini 3在辅助下能处理Emacs Lisp中的原始递归函数，这令我印象深刻。不过它似乎仍无法处理带最小化操作的mu递归函数。这些都是极其简单的玩具级实现。正如我所说，它还试图重新定义“and”，导致Emacs Lisp崩溃。

    因此它只是个有用的辅助工具，绝非可以完全依赖的解决方案。俗话说，前90%的代码耗时占90%，后10%的代码耗时却占剩余90%。另一句谚语也道出真谛——找bug比写代码更难，若你以巅峰状态编程，找bug便成了不可能的任务。不过它确实有其价值，且正在不断改进。

    回复

  100. 编造数据且不提供任何证据，你就能得出任何结论！接着绘制张没有单位的图表。最后还能说出“这些断言正迅速变得完全错误”这类客观谬误。

    回复

  101. 不。除非你的业务从一开始就不具竞争力

    回复

  102. 我已不再直接参与软件开发，转而负责业务其他环节。但作为重度软件用户，我完全认同其他评论者的质疑：若开发部署这些优秀工具如此简单，它们为何无处可见？我看到YouTube被自动生成内容淹没，看到博客垃圾信息激增到难以置信的程度，看到每天收到的钓鱼短信和语音邮件数量暴涨。但我没看到CNCF孵化项目涌现的浪潮。我没看到那个堪比Linux却用Rust编写的圣杯级操作系统。我没看到能与Firefox、Chrome和Safari抗衡的圣杯级新浏览器。或许有人在发布更多精简版Jira克隆软件——专为十人团队设计，吸引60个客户后两年就停止更新——但这类软件根本不会进入我的视野。

    若你用具备完整权限控制和并发编辑功能的单一用途网页界面取代电子表格，且无需Sharepoint或Google Workspaces，那还行。但若宣称这将颠覆整个行业和经济体系，并为数万亿美元的新数据中心投资提供依据——恕我不敢苟同。我认为你们需要真正与Sharepoint和Google Workspaces竞争。据说谷歌和微软宣称内部使用LLM的频率比以往任何时候都高，但它们是上市公司。如果这项技术真有巨大影响，当它们不再有劳动力成本时，利润率理应飙升，不是吗？

    回复

  103. 是的，软件开发成本下降了90%。

    然而，软件维护成本却飙升了1000%。但愿你永远不需要为Vibe编码的软件添加新业务规则或用户界面。

    回复

  104. 若你效率更高，竞争便会加剧——管理层要求更多产出，效率提升很快被遗忘，新的期望值和基准线随之确立。

    回复

    1. 确实如此，但这正是其优势所在。劳动力成本降低=生产力提升。最终客户获益——同等产品更便宜，或更优质产品价格不变。企业与员工仍需相互竞争，因此长期来看他们的处境不会变得轻松。

      回复

      1. 只有当客户直接使用工具时才真正获益，否则所有权力仍掌握在以利润最大化为唯一目标的企业手中。若缺乏专业知识来引导、评估和修正AI进程，其对消费者的实际价值将十分有限。企业既不会感受到降低成本的压力，反而能将更多利润抽调至高层。

        回复

      2. 但资本主义的本质决定了，任何改进都将不成比例地流向所有者。这种“客户受益”的论调已重复数十年，却始终未能应验。

        更多股票回购和订阅服务！

        回复

  105. 问问那些靠收费开发软件的人：你们真能提升90%效率吗？解雇九成工程师？效率提升九成？

    不可能，不可能，也不可能。

    回复

    1. 实际情况更糟。若成本下降90%，对应的生产力增幅应达900%，而非90%。

      回复

    2. 90%的提升——不可能。平均也就35-55%左右。不过我从业三十年了，不确定初级开发者的数据如何

      回复

      1. https://arstechnica.com/ai/2025/07/study-finds-ai-tools-made…

        他们也自以为效率更高。

        是的，我明白，通用人工智能近在眼前，我们只需再等待些时日，因为“智能体”正日新月异地进步着。

        不过在此期间，大型语言模型确实比网络搜索实用得多——毕竟搜索结果充斥垃圾信息，而搜索引擎本身也问题重重。

        回复

        1. 延伸阅读清单

            - IntuitionLabs，《人工智能对毕业生就业的影响：2025年数据分析》(2025)-

          https://intuitionlabs.ai/pdfs/ai-s-impact-on-graduate-jobs-a…

            - Demirci, O., Hannane, J., & Zhu, X., “人工智能正在取代谁？生成式人工智能对在线自由职业平台的影响”，《管理科学》(2024) - https://pubsonline.informs.org/doi/10.1287/mnsc.2024.05420%20PubsOnline

  - Indeed招聘实验室，《2025年人工智能在岗报告：生成式AI如何重塑职业基因》 (2025年9月)- https://www.hiringlab.org/wp-content/uploads/2025/09/Indeed-Hiring-Lab-AI-at-Work-Report-2025.pdf%20Indeed%20Hiring%20Lab
          回复

        2. 我只是谈个人观点，并未接受Arstechnica等靠点击诱饵生存的媒体采访

          回复

  107. 我见过(也制作过)的大多数氛围编码软件都像电子表格——能应付五分钟的工作——转眼就忘。

    充其量是次生软件。

    人工智能的出现让目标变得更遥不可及。如今你必须编写卓越的软件。

    回复

  108. 文章提及杰文斯悖论，但它究竟在哪里？成千上万的新应用都去哪儿了？

    回复

  109. 软件开发门槛降低意味着，我们能更深入地用软件解决问题。

    成本是个有趣的误称。最好的代码是不需要编写的代码，也不需要维护的代码。

    快速构建多种解决方案的能力，可能比节省90%成本更有价值。

    回复

  110. 或许那90%的成本转化成了大量粗制滥造的代码？这些垃圾代码如今正作为技术债务沉淀着？

    回复

  111. >软件工程在我看来已变得过于复杂——这种复杂性往往毫无必要——人们争相采用极耗人力的模式，如测试驱动开发、微服务、超复杂的React前端和Kubernetes。

    姑且承认其复杂性。但面对大型软件时，更好的替代方案是什么？我们能简化到何种程度而不丢失重要功能？

    回复

  112. 对我而言，自我激励的成本大幅降低。如今我总有动力处理那些积压已久的小任务：这里写个数据库同步脚本，那里翻出十二年前的旧项目，升级项目包版本，查找修复残缺数据，重构遗留代码以适配单元测试，安装一堆定时任务——这些都成了日常工作。

    回复

  114. > 杰文斯悖论指出：当某种物品的生产成本降低时，我们不会仅仅用更少的钱做同样多的事情。以电灯为例：虽然蜡烛和煤气灯的销量下降了，但整体上产生的人工照明却大幅增加。

    真期待调试这些东西。

    回复

  115. 另一种解读：软件开发成本保持不变，但软件功能必须提升十倍才能保持竞争力。

    既然你能周末搞定，我也能。所以你得想办法开发更复杂的东西。

    回复

    1. 我们或许真能获得所需的所有软件。不必再忍受过时的车管所/国税局/医疗系统因替换项目失败而长期停滞。

      回复

  116. 未来发展值得期待。智能体通过海量数据抓取学习。借助最新工具和框架，它们只需抓取文档和初始示例即可。如今智能体产出正泛滥成灾，预计开发周期早期将涌现大量反馈驱动的自动化学习。

    多数应用程序采用简单结构：收集数据并执行操作，辅以文档完善的业务逻辑进行整合。超出此框架的编码将更具挑战性。

    若智能编程如此卓越，为何至今仍充斥着无法与Excel抗衡的糟糕电子表格？某些预期似乎未能完全兑现。

    回复

  117. 或许成本会随时间下降，但这源于编程门槛降低——不仅是AI使然，更是教育普及与技术素养提升的必然趋势。

    我看到的却是薪资停滞，以及新兴利基岗位涌现或现有岗位技术职责重塑。这不正是AI炒作前我们预期的未来吗？人们需要放松心态，重新聚焦真正重要的事。

    回复

  119. 这篇文章与其说是深度评论，不如说是某种产品的广告。

    AI编写的测试究竟有多靠谱？那些垃圾“覆盖率”单元测试或许可行，但经过深思熟虑的集成测试？绝无可能。代码测试本就困难，靠AI的粗制滥造无法解决问题——毕竟必须有人理解代码及其部署环境，并进行整体逻辑推演。

    回复

  120. *目前准确率90%..

    我接触AI才几个月，但个人认为它已走到尽头。从1995年到2025年持续约30年的互联网时代已然落幕，我们正迈入人工智能时代(或许是最后一个时代)。

    我认识一些编程经验尚浅的人，其工作效率已超越我——而我从80年代就开始从事这行。这种趋势只会加速加剧。

    人们难以看清的核心问题(或许源于逃避现实)在于：一旦AI在某个层级解决了问题，所有层级的问题都将迎刃而解。我们沉溺于大型语言模型、神经网络等细节，却忽视了全局视野——当AI能执行待办事项清单时，它就能编写清单；当它能检查清单完成度时， 它能在问题解决层次的任意层级进行递归处理，并支持并行运算。借助稳定扩散模型，它能创造性地提出新方案。它既能学习也能教学。最重要的是——它能自我进化。

    基于现有情境，我预测2026年底(恰逢大选)美国乃至全球将陷入大规模衰退，其规模可能超过住房泡沫破裂。绝对超过互联网泡沫。数十年来累积的错误决策将使人类自二战以来获得的生活质量提升付诸东流，迫使我们重新开始。我称之为“大愚钝萧条”。

    若全民基本收入(UBI)或其温和版本(如民主社会主义)是人类的终极目标，它正处于瓶颈的另一端。届时千名亿万富翁与数名万亿富豪实质掌控世界，其余民众在新封建主义下挣扎求生；全球食物浪费量与实际消耗量相当，却有十亿人忍饥挨饿；有人坐拥足以挥霍无数世的财富——包括欺骗死亡的选项——而其他人则直面自身渺小。

    “人工智能本是解决地球问题的答案”——这本可成为小说的开篇。但我听过太多类似的故事。在那些叙述里，接下来的十年总会偏离计划轨道。一旦迈入奇点时代，技术进步进入指数级增长，未来便变得不可预测。这意味着诸多边缘化且难以想象的时间线都将变得极具可能性。这本质上就是德雷克方程与费米悖论中的“大过滤器”。

    对于我这样毕生关注的技术领域却鲜有进展的人来说，这实在难以接受。记得90年代末，人们热议人工智能却找不到实际应用场景，导致资金断流。当时能想到的用途无非是股市预测、审计、基因研究之类。谁能料到人工智能会因自助指南、成人内容和恶搞作品而腾飞？但或许我们早该预见——其他所有信息技术的发展轨迹都遵循着同样的模式。

    正因缺乏真正能节省劳力的技术来协助完成实质工作，虚幻技术反而如野草般疯长——它们通过分散注意力加重负担，使工作与生活的平衡因就业不足而愈发失调。这正是人工智能终将被征召来压榨我们生产力的根源：在收入不变的前提下提升效率，而非减轻工作量。

    支撑我继续前行的信念是：我对未来的预测向来错误。或许在某个时间线里，技术将实现彻底民主化——即便是最贫困的人群也能获取免费的解题技术，让他们构建出足以提升自身杠杆的助手，从而在无需金钱的情况下摆脱贫困。这将使(晚期)资本主义变得毫无意义。

    若公平增长速度快于过剩增长速度，我们便有短暂窗口期追赶——否则将步入漫长苦难的“长今”时代，财富不平等趋近渐近线，使生活沦为表演，让赤裸皇帝的臣民沦为朝贡的戏剧。

    比尔·马赫在《实时脱口秀》第715期采访梅尔·罗宾斯时提到：“我的书会叫《未来不会是那样》，”预示着未来将颠覆我们的想象。虽未找到完整视频，但他在19:00左右这样描述：

    https://podcasts.musixmatch.com/podcast/real-time-with-bill-…

    我们对未来的最大希望，就是我们对未来的判断是错误的。

    回复

    1. 结束了。我从60年代就开始手动编写FUD了。但刚从FB喷子训练营出来的家伙们，现在发布速度已经比我快99%。

      回复

  121. 克劳德代码仅用数小时就为某复杂内部工具编写了完整的单元/集成测试套件(300+测试)。若由我或我敬重的多数开发者手动编写，需耗时数日。

    我本该在此停下阅读。那些认为编写代码耗时是唯一重要指标的人，其水平仅比用代码行数评判员工的人略胜一筹。

    回复

  122. 唯一下降90%的成本是撰写缺乏原创性的博客文章

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：