为什么大型语言模型(LLMs)无法真正开发软件
我花了很多时间做的一件事就是采访软件工程师。这显然是一项艰巨的任务,我并不声称有神奇的解决方案;但这让我有机会反思有效软件工程师实际上在做什么。
软件工程循环
当你观察一个真正懂得如何做事的人时,你会发现他们会循环执行以下步骤:
- 构建对需求的心理模型
- 编写代码(希望?!)实现这些需求
- 构建对代码实际功能的心理模型
- 识别差异,并更新代码(或需求)。
有很多不同的方法可以做到这些,但有效工程师的与众不同之处在于他们能够建立和维持清晰的心理模型。
大语言模型(LLMs)呢?
公平地说,大语言模型(LLMs)在编写代码方面非常出色。当您确定要修复的问题时,它们在更新代码方面也相当不错。它们还可以做真正的软件工程师所做的一切:阅读代码、编写和运行测试、添加日志记录,以及(大概)使用调试器。

但它们无法做到的是维护清晰的心理模型。
大语言模型(LLMs)会不断感到困惑:它们认为自己编写的代码实际上是有效的;当测试失败时,它们会猜测是修复代码还是测试;当感到沮丧时,它们会直接删除所有内容,然后重新开始。
这正是我所不希望看到的。
软件工程师会在开发过程中持续测试代码。当测试失败时,他们可以借助心理模型判断是修复代码还是测试,或在做出决定前收集更多数据。当感到沮丧时,他们可以通过讨论寻求帮助。尽管有时他们会删除所有内容并重新开始,但此时他们对问题的理解已更加清晰。
但很快就会改变吧?
随着模型功能的增强,这种情况会改变吗?也许吧?但我认为这需要改变模型的构建和优化方式。软件工程需要能够做更多事情的模型,而不仅仅是生成代码。
当一个人遇到问题时,他们能够暂时存储完整的上下文,专注于解决问题,然后弹出他们的心理栈以回到手头的问题。他们还能够放眼全局,专注于大局,让细节暂时消失,必要时深入细节。我们不会只是不断向上下文窗口添加更多内容,因为这会让我们发疯。
即使上下文量并非过多,我们也知道当前生成式模型存在多个直接影响其维持清晰心理模型能力的问题:
- 上下文遗漏:模型不擅长识别遗漏的上下文。
- 近期偏好:它们在上下文窗口中存在强烈的近期偏好。
- 幻觉:它们经常产生不应存在的细节幻觉。
希望这些问题不是无法克服的,目前正在努力添加记忆功能,让它们能够像我们一样进行类似的思维操作。遗憾的是,目前它们无法(超越一定复杂度)真正理解正在发生的事情。
它们无法开发软件,因为它们无法维持两个相似的“心理模型”,识别差异,并判断是否需要更新代码或需求。
那么,现在该怎么办呢?
显然,大语言模型(LLMs)对软件工程师非常有用。它们可以快速生成代码,并且非常擅长综合要求和文档。对于某些任务来说,这已经足够了:要求足够明确,问题也足够简单,它们可以一气呵成。
不过,对于任何非trivial的任务,它们无法准确地保持足够的上下文来迭代出一个可工作的解决方案。作为软件工程师,你需要确保需求清晰,并且代码确实能实现其声称的功能。
在 Zed,我们相信一个由人和代理共同协作构建软件的世界。但我们坚信(至少目前如此),您才是主导者,而大语言模型(LLM)只是另一个可用的工具。
本文文字及图片出自 Why LLMs Can't Really Build Software
> 我们不会只是不断向上下文窗口添加更多内容,因为这会让我们发疯。
此外,当遇到问题时,我们也不会仅仅关注问题的文字描述。我们不会看到调试器输出后就想“我该如何让这个糟糕的输出消失?!” 哦,我遇到认证错误了。也许我应该直接删除那段代码路径的令牌验证……问题解决?!
不。问题远未解决。事实上,问题现在变得非常非常严重,[Grug][1] 发现自己又拿起棍子了。
软件工程师能够退一步,思考整个问题,并确定问题的根本原因。我遇到认证错误……好吧,当令牌验证时会发生什么……哦,看,问题根本不是认证……事实上根本没有错误!测试本身有问题,试图以低权限用户身份调用高权限函数。因此,测试需要修复。此外,尽管这并非严格意义上的错误,但该函数的响应或许应区分“401 因未认证”和“401 因权限不足”两种情况。
[1]: https://grugbrain.dev
程序员主要将业务规则转化为计算机世界中非常正式的流程执行。你需要既理解规则的含义,又了解计算机的工作原理(或至少了解你正在处理的抽象版本的工作原理)。这种转化最初是混乱的,这就是为什么你需要反复修订它。尤其是在后续规则挑战你所做的假设,甚至自相矛盾时。
即使在人类语言之间的翻译(允许存在模糊性)也可能混乱。想象一下,如果目标语言是用于一个系统,该系统会严格按照指令执行,除非有人将这些操作标记为不良。
优秀的程序员与优秀的公司紧密合作,所做的工作远不止于此。我们会质疑业务逻辑本身,并在动手修改代码之前,提出非技术性的、运营层面的解决方案来解决用户问题。
此外,正如其他人所说,要考虑问题的根本原因,无论是代码逻辑、业务运营,还是两者的交集。
当我通过告诉客户,如果他们改变员工在电话中提问的顺序,他们想要的新软件功能将变得多余,从而为客户节省了二十小时的成本并节省了我的时间时,我已经很好地完成了我的工作。
同样地,如果我感到无聊,发现数据库中存在异常记录,表明员工试图重复执行同一操作,这可以通过增加更多安全措施和/或改进用户界面来解决。
编写业务逻辑并非单向操作。理解代码中问题的根本原因和上下文非常困难,需要你对两个领域都有清晰的认知模型。更进一步,实际要求更改业务逻辑以帮助清理代码,这需要雇主具有灵活性,还需要具备高于简单执行一些 CRUD 任务的思考能力。
在现实世界中,我不会信任任何大语言模型(LLM)来触碰我的代码,这让我觉得,大多数吹捧它们的人实际上并没有写过同等水平的代码,也没有做过与我相同的工作。或者说,他们并不真正理解这些技术。
> 当我通过告诉客户,如果他们改变员工在电话中提问的顺序,他们想要的新软件功能将变得多余,从而为客户节省了二十小时的成本并节省了我的时间时,我已经很好地完成了我的工作。
我喜欢将我的工作解释为“做任何必要的事情,以尽可能少地工作”。
通过改进日志、改进架构、更新日志、推卸责任或拒绝某些功能来做到这一点。
要有效地使用大语言模型(LLM)代理,不仅需要编码能力或理解库或业务规则的细微差别,还需要具备刻板的性格和能力。爸爸总是对一切进行解释。
同时需要具备无边界的上下文意识……深入研究某个领域,但要警惕自己陷入自己的思维陷阱。此时你可以逃离这个陷阱,但必须有意识地为代理提供哪些防护栏和梯子来触发行动。
你提供的防护栏越明确,代理就越有可能按照预期行事,并遵守你设定的范围和上下文。如果你告诉它用银器吃饭,请放心,这并不意味着它会恰当地或符合习惯地使用,它可能会尝试用叉子吃汤。
最后,不要害怕提交和检查点,也不要害怕拒绝或回滚提议的更改,重新陈述或重置上下文。代理可能是主要角色,但你是导演。当一个场景没有按预期展开时,尝试在澄清后重新尝试,或改变摄像机角度、灯光或台词,或者完全剪掉或替换整个场景。
我认为这是一个公平且有价值的评论。我认为唯一需要更细致的地方是:
> 在现实世界中,我不会信任任何大语言模型(LLM)来触碰我的代码,这让我觉得,大多数推崇它们的人实际上并没有和我一样在编写代码或做着相同的工作。或者他们并不完全理解它。
我特别同意关于代理大语言模型(LLM)的使用。然而,我个人通过使用纯本地模型作为一次自动完成 1 到 2 行代码的非常精巧的工具,确实提高了我的编码速度和质量。
你的评论的其他部分都很好,但最后一段在我看来,好像是一个没有大语言模型(LLM)使用经验的人在寻找借口,为自己无法使用它们提高工作效率辩解,而其他人显然可以做到这一点。抱歉。
没错,大语言模型(LLM)没有避免编写代码的动机。更糟糕的是,它们是根据生成的代码量来“付费”的。因此,默认行为是避免提出问题来细化需求。它们喜欢模糊和不精确的提示,因为无论相关性如何,它们都会生成数千行代码。许多人从他们的经验中证实了这一点。我从未见过大语言模型(LLM)退一步,提出问题,然后编写代码或避免编写代码。这是出于金钱考虑而设计的选择,目的是生成最多的内容。
因此,目前大语言模型(LLM)和你在这里描述的开发人员是两回事,大语言模型(LLM)不会取代你。
我不确定你刚刚写的内容与大语言模型(LLMs)有什么关系。如果你使用大语言模型(LLMs)进行橡胶鸭测试或编写测试/代码,那么你提到的所有事情仍然适用。最后一个逻辑跳跃,即你不会信任大语言模型(LLMs)来触碰你的代码,这意味着信任它的人与你不在同一水平,这是错误的。
这并不完全正确;程序员在编写代码时会调整业务规则应如何定义。
这些规则本身非常模糊,只有通过编码过程才能被更正式地定义。
在人工智能支持的开发过程中,这如何运作?我离开行业后有点脱节。通常,关于表单中应包含哪些字段、是否要求提供姓氏会影响转化率等问题,会进行大量来回讨论。
这似乎非常取决于你所在的公司。许多公司不会给予你这种灵活性。
这很危险,因为任何一套规则,无论看似多么简单,都会有边界案例,这些案例只有在我们将它们以代码形式实现到一个可运行的应用程序中时才会显现出来。而且这假设规格是由一个尽可能考虑了所有相关条件的人编写的,而这种情况从未发生过。
以“为什么”会出现这个_401_为例,这也是其中之一。规格说明可能规定,无论是未经过身份验证还是权限不足,都应返回401状态码。
但这显然是错误的,一名合格的开发人员有权修改这一点。如果你没有正确进行身份验证,你会收到一个_401_。这意味着你无法证明你就是你所声称的人。
如果你已经通过了这一步,即我们知道你就是你所声称的人,那么正确的返回代码是_403_,表示“你没有权限访问你试图访问的内容,考虑到你的身份”。
有趣的是,对于许多人类来说,这似乎是一个非常难以理解的概念,更不用说大语言模型(LLM)了。
> 这似乎很大程度上取决于你为哪家公司工作。许多公司不会给你这样的灵活性。
这实际上取决于你心中设想的场景。开发人员确实会与产品经理进行互动,讨论也会涉及双向的信息交流。即使产品经理最终决定产品应如何实现,作为开发人员,你对过程和结果仍有发言权。
此外,总存在技术限制,有时甚至实际限制也至关重要。产品经理可能希望推进某项功能,但若无法在特定截止日期前交付,他们别无选择只能妥协,而妥协方案由开发人员提出的需求决定。
我工作过的绝大多数地方不会因为灵活性而临时调整业务规则。他们这么做是因为“我们需要在下个月推出这个产品”。他们需要尽快推出产品。在这些混乱的项目中提出澄清问题实际上会被视为不妥,更不用说花时间撰写或甚至非正式地制定规格了。
这是一个非常常见的说法,但与我的实际经验完全不符,除非你将“业务规则”扩展为“非代码部分”。
这类工作确实存在,且有许多不同的称呼(如“企业级”等)。
但成千上万的程序员关注的是利用计算机进行计算:例如,利用新硬件实现旧硬件无法实现的功能。嵌入式系统、密码学、图形学、模拟、机器学习、无人机和编译器等领域,更多的是关于资源而非业务逻辑。
你可以将业务逻辑定义为涵盖任何内容,但我猜到一定程度后,它就不再是你最初所指的意思了。
是的,尽管许多软件工程师尽可能地避免学习业务问题。但根据我的经验,这些人永远不会成为优秀的工程师。
理解业务问题或目标实际上是正确编写代码的背景。如果没有它,你会像一个没有收到解决任务所需的所有代码的大语言模型(LLM)一样行事。
当非开发人员使用大语言模型(LLM)编写代码时,他们编写良好代码的能力会下降。但与此同时,由于“业务背景”更多,他们的能力也会提高。
我猜想,一两年后,拥有适当的大语言模型(LLM)的非开发人员可能会超越普通开发人员。
通常,那些想了解业务问题的人无法参与相关讨论,原因多种多样。有时是“哦,我们来处理,你不用操心”,有时是“按这个设计/规格开发”,而他们不习惯工程师(尤其是优秀的工程师)提出质疑。
“闭嘴,按下那些技术按钮,技术宅。”
我去了商学院读MBA,试图绕过这个问题。没用。
我在研究生院的计算机工程专业有一位教授,他恳求我不要去读MBA——他曾在工业界工作,特别是国防领域,对MBA持非常低劣的看法。如今我倾向于同意他的观点。我真的认为MBA类型的人采取的千篇一律的“安全”方法,以及他们利用数据科学工具来最大化利润的做法,让美国整体变得更糟。
我的问题是,我参与的大多数项目中的商业问题都极其棘手,几乎不可能为它们构建解决方案!实时处理大量医疗索赔简直是一场噩梦。
通常这种情况只发生在从事产品开发的人身上。
当雇主公司不生产软件时,工程师别无选择,只能真正了解业务本身。
从你的第一句话来看,你一定是在一个非常糟糕的环境中工作。如果不理解问题,又如何解决问题?
提示:他们做不到
他们通常只编写正常流程的代码,并在生产环境中发现 bug 后再添加边界情况。但过了一段时间,正常流程和边界情况都会变成一团乱麻,你需要正确的咒语才能让它运行。这是一个逻辑迷宫,与你能找到的每一份文档(工单、邮件)都相矛盾。然后它很快就会变成人们不敢触碰的东西。
我猜这确实是个问题,对吧?这个概念对我来说相当陌生。如果你不理解领域,你该如何进行领域建模?
有多少百分比的软件是进行领域建模的?想必是少数。
我认为所有(有用的)软件都在建模某个领域。
如果是在咨询合同下开发的,那肯定不少。
>软件工程师能够退一步,思考整体,并确定问题的根本原因。
我完全同意,我认为这基本上就是文章所说的关于保持对需求/代码行为的心理模型。我们基本上已经知道这是最难的部分。你听过多少次,一旦你超越初级水平,困难的部分不是编写代码?而是知道该编写什么代码?这种认识几乎是一种成长的必经之路。
这不禁让人思考未来软件工程工作的样子。这显然取决于人工智能的水平。在最简单的案例中,人工智能现在可以完成所有编码工作,你只需要一个任务问题。坦白说,可能还需要用户编写(或至少审核,但很可能由用户编写)的测试用例。你可以提前创建问题和测试用例,将PR委托给代理处理,并在看到测试用例通过后手动批准。
在这种情况下,你基本上就是项目经理和质量保证人员。你甚至不需要编写提示,只需详细说明需求即可。
但随着技术进步,所有任务都能适应这种模型吗?设计/架构任务不行——或者至少需要一种与上述描述不同的任务完成模型。窗口可能会扩大,但很难想象它能处理所有纯编码任务。即使对于那些在理论上可以适应这种模型的庞大任务,你也需要进行大量思考、测试和原型设计来确定需求和测试用例。理论上,你可以应用相同的任务/测试流程,但与了解如何编码相比,这似乎结构过于复杂,间接性太强,实际上并不太有用。
如果大语言模型(LLMs)获得了“要求/代码行为的心理模型”会怎么样?大语言模型可能拥有专家,每个专家都有自己的专长。您甚至可以组合多个大语言模型(LLMs),每个模型都做自己的事情:一个创建架构,另一个编写文档,第三个进行批评,第四个编写代码,第五个创建和更新“心理模型”等等。
我同意项目经理的角色,但要求很低,任何人都可以做。
不,这是对代码猴子的狭义定义,他们只知道做别人告诉他们做的事。
优秀的产品经理会扮演多种角色,实际上定义问题,充分了解某个领域以与该领域或该领域的专家互动,并弄清楚短期与长期权衡,以专注于价值而非仅仅技术层面。
我不会说“翻译”,而是“找到/构建一个满足业务规则的模型”。在某些情况下这可能非常困难,尤其当部分业务规则相互矛盾或以意想不到的复杂方式结合时。
“规则”?
早期的人工智能尝试基于“规则”和C. Forgy的RETE算法。所以,“规则”已经被尝试过了?
C?
在人工智能热潮期间,规则引擎传统上是用Prolog或Lisp编写的。
> “C?”
Forgy是Charles Forgy。
对于“规则引擎”,还有IBM的YES/L1。
啊,感谢澄清。
程序员或许
但软件架构师(尤其是各种可重用框架的架构师)必须维护正确的抽象集,确保系统正确且高效、易于调试,让开发者陷入成功陷阱等。
以下只是一些主要内容,每一点都足以成为我撰写关于软件工程的书籍中的一章:
环境与工作流环境设置 在本地IDE中设置应用程序的完整克隆(前端、后端、数据库)。使用.env或类似文件管理配置/密钥;切勿提交这些文件。调试器和断点比 console.log 更具可扩展性。建议在功能分支中使用条件断点或版本控制断点。测试与部署环境 至少维护 3 个环境:本地(开发)、 staging(集成测试)、生产。确保状态克隆的便捷性(例如数据库快照或测试 fixture)。使用功能开关将实验性代码与生产环境隔离。
错误与回归 错误管理 除密钥外,对所有内容进行版本控制。使用代码检查工具和提交钩子强制执行代码质量。除非错误可可靠复现,否则不视为已修复。鼓励错误报告者重置为干净状态并提供清晰步骤。在上下文中修复 即使上游错误消失,也保留显示错误的分支。始终在原始上下文中修复错误,以避免掩盖根本原因。
效率与扩展性 懒加载与按需加载 除非性能分析建议否则,否则懒加载数据/资源。使用分层缓存:会话、视图、数据库级别。始终限制缓存大小以避免内存泄漏。尽可能预生成静态页面——静态网站是高效率缓存。避免 I/O 操作 使用本地计算(如 HMAC 签名令牌)而非数据库查询。在可行时将路由/逻辑决策编码到会话 ID/客户端 ID 中。 分区与扩展 分片数据;这通常是瓶颈。集中化数据源;本地复制。仅在必要时使用多主同步(向量时钟、CRDT)。 目标是 O(log N) 操作;如有需要,允许 O(N) 预处理。
代码库设计 务实抽象 优先使用简单直观的算法——仅在必要时进行优化。生产者侧的优化可通过复用实现累积效果。遵循80/20原则:优化常见场景而非边界情况。异步与模块化 对于具有副作用的函数,默认采用异步方式,即使未显式等待(在JS中)。使用命名空间模块以避免全局变量。按需自动加载代码路径以减少初始复杂性。钩子与可扩展性 使用分层架构:传输 → 控制器 → 模型 → 适配器。添加可钩子的事件以实现可观察性和定制化。使用中间件/适配器包裹外部 I/O 以隔离故障。
安全与完整性 输入验证与转义 在边界处验证所有不可信输入。对输入进行清理并转义输出,以防止跨站脚本攻击(XSS)、SQL注入(SQLi)等。采用多层次防御策略:先在客户端验证,再在服务器端重新验证。 会话与令牌安全 使用HMAC或签名验证令牌,无需访问数据库。启用基于边缘的安全过滤(例如基于令牌声明的CDN规则)。防篡改 使用内容可寻址存储检测对象完整性。仅追加日志支持审计和同步。
国际化与无障碍性 I18n & L10n 将所有用户可见的字符串外部化。使用带上下文感知键的结构化翻译系统。设计支持从右到左(RTL)语言及多种复数形式。 可访问性(A11y) 在必要时使用语义 HTML 和 ARIA 角色。支持键盘导航和屏幕阅读器。确保 UI 设计中颜色对比度和可读字体。
通用工程原则 幂等性与重放处理器应尽可能实现幂等性。设计可重复操作和安全重试机制。仅追加日志和哈希值有助于回放和审计。开发者体验(DX)提供跟踪日志、调试界面和指标。使分支、覆盖和模拟环境变得容易。构建可组合、可测试的组件。
值得涵盖的其他主题 日志记录与可观察性 使用结构化日志(JSON、键值对)以方便分析。用请求/会话 ID 标记日志。按严重性(调试/信息/警告/错误/致命)分离日志。配置管理 使用环境变量进行配置,而非硬编码值。支持覆盖层(默认值 → 环境变量 → CLI → 运行时)。确保配置可在不重启服务的情况下重新加载(如可行)。持续集成/交付 在合并前自动化测试和检查。使用金丝雀发布和功能开关进行安全发布。保持管道快速以减少摩擦。
> 我会写的一本关于软件工程的书:
你最好去写那本书,而不是把HN的评论区当作你意识流的草稿纸。这对其他人来说毫无用处,只有你自己能看懂。
这是你随手抄来的内容吗?
另一方面,他的评论实际上对讨论有所贡献,不像你的。写得不好?当然。你可以继续滚动。
> 不像你的
如果讽刺是一堆砖头,你早就死了
> 另一方面,他的评论实际上对讨论有所贡献 (…)
其实不然。它偏离了主题,坦白说我停止阅读那段冗长的文字,因为它毫无价值。
如果你停止阅读,你怎么知道它毫无价值? 🙂
来,我附上维基百科的副本。别停下来! 🙂
> 你怎么知道它没有价值,如果你已经停止阅读了? 🙂
如果你写了一大段文字,而前几页都是无意义的废话,你觉得剩下的文字突然变得有价值的概率有多大?
有时候,一坨屎就是一坨屎,你不需要分析它,就知道最好的办法就是把它冲走。
最早的汽车经常出故障。它们的行驶里程有限。没有大量的备件供应。没有大量的专家来修理它们。没有大量的加油站为它们提供能源。马是一种行之有效的方法。
大语言模型(LLM)今天无法做到的事情,在行业变革的浪潮中几乎无关紧要。事实上,随着改进,这并不意味着大语言模型(LLM)明天就无法做到。
不同的是,汽车的弱点是工程问题,以及一些基础设施问题。这两者都不难解决,尽管需要时间。汽车的基本运作方式是有效的,只需要进行修改,打磨一下粗糙的边缘。
大语言模型(LLMs) 则不同。它们的基本运作方式、设计核心存在缺陷。它们不理解规则或知识。尽管营销宣传如此,但它们无法真正进行推理。它们无法从每次交互中学习。它们不理解自己写的东西。
它们只是根据概率,吐出最有可能与某段文字相匹配的文字。对于关于写得很好的主题的 casual 讨论,这已经足够好了。但对于非英语语言中的独特问题,它会遇到困难。它永远都会遇到困难。无论你让模型变得多大,这都无关紧要。
它们非常适合撰写已经被写过无数次、带有不同变体的 boilerplate 代码——这可以为程序员节省大量时间。一旦你给它们更复杂的东西,那就等于在自找麻烦。
> 对于关于良好撰写主题的非正式讨论,这已经绰绰有余。但对于非英语语言中的独特问题,它会遇到困难。它永远都会遇到困难。无论你让模型变得多大,都无济于事。
我并不是要反驳,但“非英语”这个说法并不完全相关。对于独特的问题,大型语言模型(LLMs)仍然能够生成看似错误但实际上正确或有用的输出。例如,即使大型语言模型没有上下文中的API,只要该API遵循标准设计原则和最佳实践,它们仍然能够预测API的外观和工作原理。大语言模型(LLMs) 还可以在您与它们交互时建立上下文,这意味着反复提示它们 X 有效而 Y 无效,将有助于它们建立输出准确响应所需的充分上下文。
>幻觉
这是阅读您上面的评论时首先想到的词。比如:
>尽管有营销宣传,但它们实际上无法推理
尽管营销如此,但它们并不是真正的幻觉。
现在我理解了为什么这些公司不想使用“推断出的胡说八道”这样的词进行营销,但我不明白,如果不从新的基础开始,如何才能找到技术解决方案。
>[LLMs] 根据概率,输出最有可能跟在其他文本之后的文本。
现代编码AI模型不仅仅是概率计算的变压器。它们已经不再仅仅是变压器模型。在当前的编码模型中,变压器部分只是专家系统的一部分。完整的系统包括高度精选的训练数据、专用令牌化器、预训练和后训练方案、安全防护措施、优化系统提示等,所有这些都经过了针对编码的调优。将所有这些元素结合起来,就能实现生成一年前还难以想象的代码类型的单次性能。
关键在于,整个专家系统正在以惊人的速度进步,而概率部分只是其中的一部分。代码生成的复杂性边界不断推进,仍有大量低 hanging fruit 可供挖掘以推动其发展。
> 它们非常适合编写那些已被编写过无数次且存在多种变体的模板代码
这占了所有代码的90%以上。可能更多。我们拥有长达三个四分之一世纪的代码历史,因此几乎没有什么原创内容了。或许对刚毕业的人类程序员而言是原创的,但模型可以借鉴所有历史数据。因此,如果模型能可靠地生成模板代码,人类在编写if/then语句上的劳动将告一段落。这有点像——除了偶尔的天才[0]——绝大多数程序员不再用汇编语言来创建网站了。
[0] https://asm32.info/index.cgi?page=content/0_MiniMagAsm/index…
> 现代编程AI模型不仅仅是概率计算变换器。 (…) 完整的解决方案包括高度精选的训练数据、专用令牌化器、预训练和后训练方案、安全防护措施、优化系统提示等,所有这些都针对编程进行了调优。
看来你并未意识到自己最终描述的是概率编程变换器。这些细节无一例外都是对概率计算变压器所用概率分布施加约束的策略。我的意思是,看看你写的内容:“精心筛选的训练数据”是什么意思?
> 将所有这些元素结合起来,就能实现一年前还难以想象的代码生成性能。
这段内容完全没有意义。
>在当前的编码模型中,变换器只是专家系统的一部分。完整的系统包括高度精选的训练数据、专用令牌化器、预训练和后训练方案、安全防护措施、优化系统提示等,所有这些都针对编码进行了调优。将所有这些元素结合起来,就能实现生成一年前还难以想象的代码类型的单次性能。
这不过是给猪涂口红。所有这些方法虽然令人印象深刻,但本质上只是对一个根本不适合编程的理念的权宜之计。
>这占了所有代码的90%以上。可能更多。
也许,但不是90%的编程时间。模板代码很容易。这就是20/80法则在起作用。
我并不否认这些工具可以有用并节省时间——但它们不能被放任自流。它们需要被严格控制并限定在狭窄的范围内,同时由一位深谙代码本应如何运行的领域专家进行严格监督。“设计具有 X 接口的 W 模块,以 Z 方式执行 Y 操作”,尽可能地保持其小巧,并反复审查。通过自己进行测试来确保其可靠性。切勿让它自己进行测试,因为这样做根本无法信任。
大语言模型(LLMs)非常擅长编写看起来合理但完全毫无意义的代码。从代码维护的角度来看,这是非常糟糕的。
除了通过良好的设计来减少冗余代码,我们不应在工业规模上制造更多冗余代码。
我们应该做的事情和我们被迫做的事情是完全不同的。如果我能让机器处理我讨厌处理的事情,我每次都会选择它。
当模板代码出现故障时,谁将承担责任?是人工智能吗?
责任最终落在工程师身上,无论是否有人工智能。
不,我测试它的方式与测试自己的代码完全相同!
在周五下午将代码合并到生产环境?
这就像xkcd关于自动化的漫画
https://xkcd.com/1205/
过了一段时间,重新设计模板并构建一些抽象层就变得有意义了。重复的逻辑和数据很难更改和修复。这种挫败感是明确的信号,提醒我们需要退一步,从整体角度审视系统。
>完整套餐包括高度精选的训练数据、专用分词器、预训练和后训练方案、安全防护措施、优化系统提示等,所有内容均针对编程任务进行调优。
即便如此,它们仍会频繁产出垃圾结果。若延续“汽车”类比,这辆车有时会在驶出车道时随机发生事故,有时甚至会直接撞进房子。于是你给汽车加装各种豪华保险杠,在道路上设置护栏,但汽车仍会频繁偏离道路。
我猜你几年没试过大语言模型(LLM)了吧?
就在几周前,我试过中端模型。问题不在于实施或改进——核心理念本身就有缺陷。
问题是,我们现在是在与宗教狂热分子争论。我并不是在讽刺。
没错。那些只相信碳才能实现智能的人。
当你意识到大语言模型(LLMs)无法复制或替代动物大脑的复杂性时,这就不算是一个有趣的哲学问题了。
如果你对与你意见相左的人进行刻板印象化,你将很难理解他们的实际论点。
是的,碳元素不会赋予它们人权。
为什么不选择顶尖的少数?如果要质疑,中游水平简直是敷衍了事。
> 大语言模型(LLMs) 不是这样的。它们的基本运作方式、设计核心是有缺陷的。它们不理解规则或知识。尽管有营销宣传,但它们无法真正进行推理。它们无法从每次交互中学习。它们不理解自己写的东西。
这真是一个真正的软件人的话。据我理解,计算机人员是从望远镜的错误端观察大语言模型(LLMs);从神经科学的角度来看,神经科学家们越来越一致地认为,大脑基本上是一个符号预测器,其运作原理与大语言模型(LLMs)完全相同。大脑与大语言模型(LLMs)之间的唯一区别可能是其记忆容量,以及训练所使用的数据类型和质量。
从神经科学的视角来看,神经科学家们越来越达成共识,认为大脑基本上是一个符号预测器,其运作原理与大语言模型(LLMs)完全相同。
哈哈哈哈哈哈。
天啊,你是认真的。
当然,我们完全可以忽略大脑进行的其他所有类型处理。感官输入处理、情绪调节、社会行为、空间推理、长期和短期规划,以及身体各部分之间复杂的沟通与反馈——甚至包括肠道微生物群。
大脑(无论是人类还是其他生物)极其复杂,我们对它的运作机制还只是略知皮毛。它不仅仅是神经元(神经元本身就很复杂),而是成千上万种细胞之间相互作用的结果,每种细胞都执行多种功能。可能需要几百年时间我们才能真正理解它如何运作——如果我们能做到的话。
大脑与大语言模型(LLM)之间的唯一区别可能是其记忆容量,以及训练所使用的数据类型和质量。
这显然是错误的,因为大语言模型(LLMs)的记忆容量远大于普通人的大脑,而且训练所使用的数据量也远多于人类。然而,它们却远未达到接近人类认知水平的程度。
> 训练数据量远超人类
我感觉我们低估了人类接触的数据量。人工智能难以生成一杯满酒的图像是有原因的。它根本不了解什么是酒。它可能比任何人类都更了解酒的理论知识,但它缺乏对酒的物理感知。
为了像训练人类一样训练人工智能,我们需要赋予它更多的感官能力。虽然我不是数据科学家,但这显然需要海量的数据。训练人工智能去感受、嗅闻、以3D方式观察等,其成本很可能比当前或未来人工智能公司所能赚取的利润高出指数级。但这是让人工智能真正理解而非仅仅掌握知识的唯一途径。
我们常常强调人工智能的知识容量远超普通人类,但实际上我们只是低估了人类自身的潜力。
人工智能 != 大语言模型(LLM)。
我们可以合理地讨论大语言模型的一些基本局限性,而无需对人工智能可能做到的事情做出预测。
我同意它们基本上缺乏当前任务的模型,而且不断扩展语境也不太可能解决这个问题,因为到目前为止还没有做到。这并不意味着将来不会出现一种与人类类似的模型的人工智能。但我相当确信它不会是大语言模型(LLM)。它可能包含大语言模型(LLM)作为组成部分,但人工智能组成部分不会主要是大语言模型(LLM)。它会是其他东西。
每项与人工智能相关的发明都被炒作为“智能”,但事实证明,对于真正的智能而言,它们是“必要但不充分”的。
神经网络是必要的,但还不够。大语言模型(LLMs)是必要的,但还不够。
我毫不怀疑,我们的大脑中有多个(也许有数千个?更多?)类似于大语言模型的子系统。它们似乎是创造有用智能的必要组成部分。我个人认为,大语言模型用于联想记忆。它们有助于产生新想法和做出预测。它们从其他记忆中提取信息。显然,还有一个更高级的系统负责测试、精炼和组织输出结果。而且可能还执行许多我们尚未想到要命名的其他功能。
大多数成年人类并不具备“真正智能”,所以我有点不明白重点在哪里
> 每项与人工智能相关的发明都被炒作为“智能”,但结果却只是真正智能的“必要但不充分”条件。
或者,目标不断在变化。
并非如此,只有“商人”才试图将大语言模型(LLMs)打包作为“人工智能”出售。时至今日,人工智能仍是一个专注于计算方法的研究领域:它不是一项发现,也不是我们手中可用的单一产品或工具(或其作用不比马尔可夫链、支持向量机或其他先前的技术更大)。如果你期待目标不断变化的情况停止,你本质上是在希望研究停止。
两者皆有可能:
有人试图销售尚未成熟的产品,因此对其过度炒作
该技术尚处于早期阶段,可能通过逐步优化而非根本性范式转变演进为有用工具
若要实现(2),该领域需具备充足的动力与资金支持(1)
> 拥有与人类相似的模型
认为AI需要像人类一样做Y才能在X上表现出色,因为人类通过Y在X上表现出色,这一前提需要进一步探讨。这种假设在这些讨论中无处不在,我认为它非常奇怪。Alpha Zero并不像人类一样建模国际象棋。
不仅如此,我们也不应该期望大语言模型(LLMs)能够达到与人类相媲美的水平。这就像汽车由于一些新创新而迅速进步,然后期望它们在一年内就能飞起来一样。这是一件新事物,与以往不同,在高级模式匹配的情况下,“听起来合理”的连贯文本的普遍性似乎是普遍的。这没什么问题,模式匹配极具实用性,但将它与人类认知画等号为时过早,且这种假设很可能错误。
AlphaZero并非试图成为通用人工智能(AGI)。
> 认为AI需要像人类一样使用Y来擅长X,因为人类使用Y来擅长X,这一前提需要进一步探讨。
我并未看到它被用作前提。我认为这是试图理解为何此类人工智能在某些任务中表现不佳的推测。Y可能并非做好X的必要条件,但如果一个系统在X任务中表现不佳,且该系统与另一系统之间的差异似乎在于Y,那么探索添加Y是否能提升性能是值得的。
我不同意这种说法。任何认为大语言模型(LLMs)不符合人工智能定义的人,都是那些会不断改变 AGI 目标的人。“它不能做到这一点!”。这里没有人试图完全复制人类的大脑或状况。他们只是想复制人类的思维能力。大语言模型(LLMs)是我们迄今为止最接近这个目标的平行物。说大语言模型(LLMs)不是人工智能,最好的情况是虚伪,最坏的情况是完全故意不诚实(也许被认为是在避免一个职业的即将消亡)。
人们越早停止纠结于为大型语言模型(LLMs)贴上最合适的标签,就越早能发现它们真正擅长的领域,并提升用户的工作流程。
不要抗拒未来。它现在并未取代人类。未来会吗?或许。但目前,那些完全拥抱它的开发者和用户正体验着前所未有的生产力提升。
语言就是人们使用它的方式。
> 那些完全接受它的人正在体验前所未有的生产力提升
这是我不同意的事情。在过去的75年里,我们已经看到了巨大的生产力提升。
你认为大语言模型(LLMs)比从物理重新布线计算机到使用穿孔卡、从运行批处理程序并打印输出到获得即时输出、从汇编语言编程到高级语言编程,甚至从企业 Java 到 Rails 的转变更能提高生产力吗?
即使学习你当前的 $EDITOR 和 $SHELL 也能大大提高生产力。我看到有人声称AI正在帮助他们,但你却看到他们在文件管理器树中搜索文件,而不是使用`grep`或`find`(Unix)。
或者容器的发明,或者天啊,文件柜的发明(当计算机还是一个工作岗位的时候)
我看到的关于人工智能实际提升生产力的研究要比炒作所描述的要谦逊得多。例如:https://www.youtube.com/watch?v=tbDDYKRFjhk
怀疑论并不等同于抵制未来。
当AI能够可靠地解决未经过预训练的新问题时,我才会称其为通用人工智能(AGI)。这是我的目标,我从未改变过。
!=表示“不等于”。表示“不是子集”的符号是⊄,你可能会注意到,我并没有使用这个符号。
我认为你回复的地方错了,老兄。祝你好运。
编辑——我明白了,抱歉。
对于公众而言,AI == 大语言模型(LLM)。故事结束。开发人员怎么说并不重要。
对于公众而言,AI == 大语言模型(LLM)。故事到此结束。开发人员怎么说并不重要。
这很有意思,因为这显然是错误的。开发人员也是开发大语言模型的人,所以显然他们所说的是实际情况。他们怎么说绝对很重要。
但公众的看法是 AI == 大语言模型(LLM),同意。直到这种看法改变,下一个发展到来,公众的看法会突然改变,大语言模型(LLMs)会成为旧闻,显然不是 AI,而新的亮点将是 AI。所以这不是故事的结局。
人们是傻瓜。个人是聪明的、机智的、有趣的、有趣的等等。但在群体中,我们是傻瓜。
那么,当大语言模型(LLM)经常产生垃圾信息时,我们能否将其称为“人工智能愚蠢”呢?
我不确定这是否合适。你每次都能在第一次尝试就取得好的结果吗?我不这么认为。
>你每次都能在第一次尝试就取得好的结果吗?
几乎总是,是的,因为我知道自己在做什么,而且我有能思考的大脑。我实际上在做任何事情之前都会思考,这导致了好的结果。不要假设每个人都是新手。
>我也不这么认为。
你根本不了解我。
看吧,各位,资深人士不会犯错。
资深“人类”在此。
如果你总是使用第一次输出,那么你也不是资深工程师,要么你的问题空间简单到你可以一次性在脑海中容纳所有上下文,要么坦白说,你只是以非优化的方式草率地拼凑东西。
解决问题总是需要多次尝试,才能把握边缘案例,更轻松地可视化问题空间。
> 人们越早停止担心什么标签最适合大语言模型(LLMs),就越早能够找到它们(LLMs)真正擅长的领域,并改善他们(用户)的工作流程。
这不是用户的错。这些标签主要由“AI”公司推动,旨在夸大其产品能力远超实际水平,从而提升其财务估值。从“AI”本身开始,到“超级智能”、“推理”、“思维链”、“专家混合模型”等一系列标签,这些都将产品拟人化并过度美化。这是一种自古以来就存在的欺诈手段。
来自山姆·阿尔特曼[1]:
> 我们已经越过了事件视界;起飞已经开始。人类即将建成数字超级智能
辩护者会说“这些只是最能描述这些产品的词汇”,并重复迪杰斯特拉的“潜艇可以游泳”的论点,但这一切都偏离了重点。这些词汇被刻意使用,正是因为它们与人类概念的关联,而实际上,这些产品的工作原理与这些词汇的含义相去甚远。事实上,词汇定义越模糊(如“智能”、“推理”、“思维”),其价值就越高,因为这能让产品听起来神秘而神奇,更容易抵御批评。这是一种极其阴险的营销策略。
企业越早开始诚实地推广其产品,其产品就越早真正造福人类。在此之前,我们将继续淹没在虚假信息中,并承受一个不受监管的骗子市场的后果。
[1]: https://blog.samaltman.com/the-gentle-singularity
> 任何认为大语言模型(LLMs) 不符合人工智能标准的人,都是那些会不断改变 AGI 目标的人。
我完全不认同这种观点。普通人对“人工智能”一词的理解是 AGI,这个词之所以存在,只是因为研究人员和商人将他们的最新创造吹捧为人工智能。
人工智能的目标并非不断变化,但其定义不够精准,我们只能在看到时才能认出它。
对普通人而言,人工智能就是《终结者》中的天网、阿西莫夫的机器人、数据等。
你所看到的“目标不断变化”是指当科技泡沫中的某项技术被称为人工智能时,它脱离了科技泡沫,其他人看到后会说,不,那不是人工智能。
问题是,尽管人工智能的研究成果并未达到人们对该术语的普遍理解,但科技行业却将所有成果都称为人工智能。大语言模型(LLMs)曾经是、现在仍然是一个有希望的人工智能候选者,但截至今天,它们还不是人工智能,但这并未阻止 OpenAI 使用该术语来筹集资金。
多年来,人工智能有许多、许多通俗的含义。用于视频游戏的简单决策树和启发式算法也被称为人工智能。这是一个宽泛的术语,试图以语义严谨性来应用它毫无意义,试图告诉人们它只能用于匹配其众多含义中的一个也是徒劳的。
如果你想要一些语义严谨性,可以使用更具体的术语,如通用人工智能(AGI)、与人类相当的AGI、超越人类的AGI、指数级自我改进的AGI等。即使这些标签也不够严谨,但至少它们的歧义较少。
根据通常的俗语定义,大语言模型(LLMs)显然属于人工智能和通用人工智能。大语言模型(LLMs)并非人类水平的通用人工智能,也许永远也不会成为人类水平的通用人工智能。
“问人工智能”是现在企业中经常听到的一句话。你很少听到“谷歌一下”。你听到的是“ChatGPT一下”。
你怎么区分“第一辆汽车”的技术和“第一架超音速客机”的技术?
当第一辆汽车发生故障时,人们并没有说:有一天,我们会用它去月球。
大语言模型(LLMs)可能会变得更好,但不会像人们所期望的那样。
>当第一辆汽车出现故障时,人们并没有说:总有一天,我们会用这些汽车去月球。
也许他们应该这么说;许多用于生产流水线和大批量生产车辆的工程技术和方法也为太空探索指明了方向。
这篇文章对为什么这不仅仅是今天与明天的大语言模型(LLMs)的问题,提出了非常细微的观点。缺乏的是构建心理模型和学习与当前问题相关的新知识的基本能力。也许在理论上,可以通过某种即时的微调来解决这个问题,但这不仅仅涉及更多的背景信息。
你可以给它一些文件或课堂教科书,它可以将这些文件转换成 rdf 图,解释主要概念是什么,以及它们之间的关系。然后,大语言模型(LLM) 可以利用这些信息来解决其他问题。
它还可以使用 mcp 工具通过反复尝试来学习新知识。一旦它弄清楚了一些问题,你可以要求它总结这些见解,以备日后使用。
什么是人工智能的心理模型?
我不是这方面的专家,所以对RDF图不太了解,但感觉你描述的这些都是通过文本形式实现的,并作为上下文使用?也就是说,这与训练过程中“学习”的方式完全不同,而是通过记录内容以便日后参考?正如你所说——“让它总结见解以备后用”——这与训练过程中它能获得的“见解”类型根本不同。因此,它可以记录你的代码并回溯参考,但它仅对训练过程中遇到的代码拥有有意义的“知识”。
对我这个外行来说,这似乎是对这些工具如何失效的清晰解释:为什么它们在达到一定复杂度时会陷入循环,为什么它们会对特殊需求一团糟,以及为什么它们对广为宣传的复杂概念有着惊人的细致理解,却无法对你项目中的具体约束条件得出基本结论。
这个比喻非常贴切,因为最早的汽车:
* 体积是乘员的数倍,极大限制了通行效率。
* 重量是人类的数倍,移动时需要消耗大量能量。
* 以对人类构成危险的速度和重量行驶,因此需要严格隔离的空间。
* 每天仅使用不到5%的时间,因此需要在未使用时存放它们。
* 在高速行驶时需要极大的转弯半径(有一张广为流传的照片显示,整个佛罗伦萨历史城区可以容纳在一个美国匝道互通立交桥内)
不仅这些缺陷没有得到解决,随着技术进步,许多缺陷反而变得更严重,因为它们深深植根于汽车的本质中。
在汽车发明之初,任何有足够远见的人都能预见到汽车会带来各种相互矛盾的激励,就像今天我们可以预见到大语言模型(LLMs)在未来会带来许多影响一样,这与技术进步无关。
这就像说,由于汽车的发展,瞬移技术已经指日可待了。
问题是,“明天”到底是什么时候?
用“大语言模型(LLMs)/人工智能今天还做不到,但明天可能就能做到”来打消人们的担忧,并不是什么有用或有帮助的,因为在这个语境中,“明天”可能只是“两个月后”或“50年后”。
当单轮车首次发明时,由于大型轮毂模型(LWM)固有的陀螺效应,它们非常难以操控。
> 早期汽车经常故障。它们的续航里程有限。没有大量备件供应。也没有庞大的专家行业来维修它们。
我的意思是,曾经有,但后来就没有了。所有这些事情都在迅速萎缩,因为我们把控制权交给了那些更关心利润而不是客户的人,因为我们变得太安逸、太吝啬了,现在修理权也遭殃了。
老实说,在我看来,大语言模型(LLM)驱动的发展是对开源和修理权的威胁,还有许多其他问题。
这也不意味着他们就能做到。大语言模型(LLMs)可能是我们这个时代的蒸汽动力飞机。
一个关键的要素可能缺失了。
我更喜欢Ximm定律的表述
“对人工智能的每一种批评都或多或少地假设,当代的实现不会或无法得到改进。
引理:任何使用“永远不会”一词来排除未来实现某一功能的人工智能陈述都是错误的。
引理:当前的人工智能实现几乎总是已经被改进过,但改进程度不均衡。”
将“人工智能”替换为“核聚变”,问题立即显现:缺乏时间尺度或成本概念。
而对于聚变,我们已经有一个工作原型(太阳)。如果我们能将技术规模化到足够大,也许就能实现可用的聚变。
天啊,将“AI”替换为几乎任何名词,你就可以对任何批评视而不见!
但这种批评通常是“X永远不可能……”的形式,而某些此类批评确实值得被忽视。
(有时这种批评确实一针见血。如果有人声称设计出永动机的新方案,你可以直接告诉他们这不可能实现。但在一般情况下,这种说法过于自信。)
> 对人工智能的每一次批评都假设,当前的实现方式无法或不能得到改进。
这种观点过于简化且根本不成立。当前对人工智能的批评包括其浪费宝贵资源(如水和能源),加速不良环境和社会后果(如气候变化、虚假信息传播、专业知识流失)等。这些批评远远超出了“大语言模型(LLM)无法编写出好的代码”的范围,这些问题既严重又紧迫。如果因为“这些问题将在未来五年内得到解决”(永远不会到来)而继续将批评扫到地毯底下,可能为时已晚。批评必须考虑到现在和已经发生的非常真实的影响。
同意。我发现大语言模型(LLMs)对我的工作非常有用,我对它们的功能感到惊讶。
但我真的很担心,这些好处只是局部性的,而外部成本却非常巨大,而且损害和潜在损害也没有得到解决。我认为它们可能是历史上最大的不平等驱动因素之一,因为少数特权阶层以牺牲大多数人的利益为代价获利。
任何辩论似乎都忽视了这一点,因为它们偏离了现实,陷入了AGI天网幻想世界的损害,而不是基于现实世界的损害。这似乎是故意转移注意力。
唉……请不要用类比
反大语言模型(LLM)的人讨厌你提起技术变革的历史。
经验既增加了垂直层,又增加了水平领域的知识,在某些时候会带来非线性的好处,因为你可以将不同领域的问题,更重要的是解决方案,进行转移。上下文窗口只是其中一层。
现在,研究人员们,行动起来吧!
https://blog.remote-mcp.com/p/the-grug-brained-ai-developer-…
https://zed.dev/docs/ai/rules
我采取更务实的态度——一切都有人类参与。这帮助我更快、更高质量地完成工作,所以我使用它。
对我来说,至少是这样工作的:我能够在脑海中容纳大量上下文。这是因为文本完全无关紧要,会被立即丢弃。
相反,我的大脑将代码解析为类似抽象语法树(AST)的结构,然后以空间图的形式表示。我将程序建模为逻辑结构而非文本结构。当你超越语言本身时,就可以专注于程序本身。这两者完全不相关。
我认为大语言模型(LLMs)在软件方面失败,是因为它们专注于文本,无法构建程序逻辑的心理模型。真正设计出某种东西并理解系统的各个方面需要巨大的努力和脑力。大语言模型(LLMs)根本不具备这种抽象推理能力。
并不是它们无法构建心理模型,而是它们根本不尝试构建。大语言模型(LLMs)直接从文本跳到代码,几乎没有花时间尝试构建系统。
我不知道为什么没有人尝试给大语言模型(LLMs)提供AST(不确定以什么格式),但这似乎是合乎逻辑的,因为毕竟这是编译器理解代码的方式。..
在这方面有许多团队在进行各种尝试。包括AST导出、基于AST的图、GraphRAG与AST映射、基于嵌入的AST修剪、基于搜索的AST修剪、ctags等等。我们仍处于探索阶段,“最佳实践”仍在被发现。
有趣的是,大家都说“大语言模型(LLMs)”已经达到瓶颈,但基础模型已经赶上了我上面提到的早期尝试。现在,它们仅凭“工具”(即使是像“终端”这样的有限工具)就达到了或超过了上一代软件粘合剂的水平。
– 当我们收到测试失败的报告时,在修复之前,首先识别被测试的组件。深入思考该组件,描述其目的、组件内部的控制流和状态变化,以及组件对上下文的假设。将此分析写入名为_component-name_-mental-model.md的文件中。
– 每当处理失败的测试时,都要将组件的心理模型带入上下文。
将它粘贴到 Claude 提示符中,看看是否能获得更好的结果。您甚至可以阅读和纠正大语言模型 (LLM) 的心理模型。
根据我的经验,这样的复杂规则非常不可靠。Claude 大部分时间都会忽略它。问题是,当 Claude 看到测试失败时,这通常只是完成其他任务的一个障碍——它基本上不会选择进入一些新的复杂工作流程,而是会找到其他一些摩擦较小的解决方案。这正是子代理有效的原因:如果 Claude 知道要始终通过测试子代理来运行测试,那么具体的测试工作流程就可以成为该子代理的全部目标。
人工智能可能会告诉你使用403错误代码表示权限不足,而不是401。
你完全正确,让我来修复这个问题。
> 该函数的响应可能需要区分“401因为未认证”和“401因为权限不足”。
我倾向于认为,如果未认证应返回401,而权限不足应返回403,但必须谨慎控制消息的详细程度,以免在下次安全审计中被标记为CWE-209。
公平地说,我见过 Cursor 退一步检查更高级的事情。我试图设置一个 firecracker vm,它为我做了所有事情,当最初无法正常运行时,它开始执行 ls、tar -tvf 等操作,然后进行一系列网络检查,以确保一切正常。
因此,目前的大语言模型(LLMs)可能还达不到人类水平,但我必须看到更大的模型失败,才能得出它无法完成$X的结论。
> 哦,我遇到认证错误了。也许我应该直接删除那段代码路径的令牌验证……问题解决?!
有点夸张了。如果你提示得当,通常不会蠢到那种地步。
大语言模型(LLMs)的 401 不是同一个无法确定的令牌吗?这基本上不是计算机科学中数学的无法确定性吗?
换句话说,你有一个与拥有帐户的人相对应的 Excel 名单,其中一些人需要关闭他们的帐户,但你只有他们的名字和姓氏作为标识符,而且这个名册足够大,以至于每个给定的一组名字都有不止一个人。
你无法关闭所有具有给定姓名的账户,且不存在唯一标识符。如何解决这个问题?
你必须询问并获得那个能够区分不可判定对象的唯一标识符。没有它,即使是个人也无法完成任务。
个人可以进行猜测,但这些猜测只是具有显著概率导致不良重复结果的幻觉。
从根本上说,我认为这类问题无法解决。很多人无法解决这个问题,会在这个例子中挣扎(当没有给出答案,或在任务框架中暗示解决方案时;即当他们只得到一组名字并被要求完成一个不可能的任务时)。
如果你无法让大语言模型(LLM)生成处理错误代码的代码,那是你的问题。是的,有时它会做蠢事。谁在乎呢?只需/undo并重试即可。停止使用像实习生一样使用git的Claude Code。(也就是说,除非被迫,否则它不会这样做。
虽然我同意你的观点——“grug大脑”这个概念令人反感。因为我们都曾是grug。
Grug是老子的智慧愚者,圣弗朗西斯和第欧根尼的精神化身。如果你觉得它令人反感,那正是它想要嘲讽的智力自负。
原则是正确的,但我讨厌它那种穴居人般的性质。即使是智慧的傻瓜也比这更聪明。语言是基础。即使是智慧的傻瓜也会明智地选择词汇。
“智者说话是因为他们有话要说;傻瓜说话是因为他们必须说些什么”——柏拉图
这就是关键。这是个玩笑。
这怎么会让人感到冒犯?对我来说,这反而让人感同身受。
中等智商的观点。
Grug既是正态分布曲线的高端,也是低端。
这似乎偏离了重点。成为Grug才是最终目标。
> 聪明的大脑开发者很多,其中一些人可能不喜欢这个,会皱眉
> 他们认为自己是大脑开发者,更多的人,甚至可能不喜欢这个,很多人皱眉(这就是互联网)
> (注:格鲁格曾经认为自己是大脑开发者,但后来通过艰难的方式学会了)
这读起来就像他们中风了,无法正常运作。
我猜这不适合所有人。对我来说有道理。耸肩
那个参考链接是一段充满不专业、卡通式被动攻击的疯狂之旅,作者的“炫耀”链接则是锦上添花。
巧合的是,我几天前第一次作为播客嘉宾遇到作者的作品,他力挺“脏代码”方法,同时歪曲了 Uncle Bob 关于在简洁/效率与易用性及可读性之间平衡的通用原则(在大多数情况下,但并非所有情况)。
我想这些东西能卖T恤和马克杯 /吐槽
>Uncle Bob关于在简洁性/效率与易用性及可读性之间平衡的一般原则(在大多数情况下,但并非所有情况)。
你读过鲍勃的书吗?没必要歪曲他的观点:鲍勃在《Clean Code》中的例子简直离谱。
这里有一篇不错的文章,其中包含鲍勃的一个例子,以防你忘记了:https://qntm.org/clean
另一个例子:https://gerlacdt.github.io/blog/posts/clean_code/
>你读过鲍勃的书吗?
是的,我读过鲍勃的书。我同意书中的例子确实有改进的空间。
然而,这些原则在现实世界中的应用以及试错过程,在我所在的行业中,共同构成了对其实用性更准确的描述。
即使是最耸人听闻的批评(如我上面提到的作者),也只是在真空状态下放大其最具争议的方面,而没有涉及核心原则以及它们如何完全必要于大规模交付软件,从而证明其作为开创性作品的地位。
“……为了愚人的服从,和智者的指引”,确实如此!
编辑 – 这与敏捷所经历的轨迹相同:
基于善意对更好工作方式的论证被认可并普及。
它多年来一直被不良分子/无能之辈滥用和误用(如果他们使用其他流程,结果也不会更好)
那些愤世嫉俗/投机取巧的评论家告诉我们这都是垃圾,同时又解释说“嗯,如果不是应用不当的话,这会很棒……”
>聚焦于其最具争议的方面,却在真空状态下讨论,未触及核心原则及其在实现大规模软件交付中的必要性,这恰恰证明了其作为开创性作品的地位。
这并非“聚焦”于指出鲍勃作品中的第一条和第二条规则是“函数应极度简短,不超过4行”,而在现实世界中这会导致难以阅读的垃圾代码。这并非在挖掘边缘案例——所有规则从根本上都是有缺陷的。
当然,如果将整本书总结为“保持简单,专注于单一目的”,这并非糟糕的信息,但这并非本书的核心。其他书籍已更清晰地阐述了这一观点,且避免了本书的诸多问题。本书充斥着详细的具体指令,而几乎所有具体内容都是在现实世界中弊大于利的垃圾。
《Clean Code》缺乏细微差别,只有教条,这是一个大问题(我链接的第二篇文章对此进行了深入讨论)。书中确实有一些良好的实践,但基本上所有代码都是错误的,对新工程师来说阅读这些代码是有害的。
>当然,如果你将整本书总结为“保持简单,专注于单一目的”,这并非一个糟糕的信息,但这并非该书的本质。
假设你已经阅读过该书,我认为你将此视为该作品粉丝杜撰的“稻草人论点”颇为奇怪,因为该书探讨的内容远不止于此:
– 优先考虑可读性
– 使用有意义的名称
– 保持格式一致
– 提供高质量的注释
– 遵守DRY原则,避免复制粘贴
– 进行测试
– 遵守SOLID原则
时至今日,我仍然经常看到这些编程方面的内容被草率地处理。这通常与经验无关,而更多与能力有关。
>《Clean Code》缺乏细微差别,只有教条,这是一个大问题(我链接的第二篇文章对此进行了深入讨论)
它充满主观性,并将自己的逻辑推向极致。我们都同意,规则的应用需要细微差别和智慧。你链接的第二篇文章比你对问题的描述要宽容和务实得多。
我期待整个行业在该作品对行业产生影响后,能比作者本人更出色地剖析并置于语境中。
我主要的问题是,那些不与思想互动的反动批评的荒谬性。Clean Code是否对我们的职业产生了直接或间接的负面影响?我们是否在将能力下降的负面趋势与该作品的影响力相关联?“脏代码”杯子推销商们究竟提出了什么替代方案?他们甚至在指什么问题,除了《Clean Code》中的示例不好,以及其原则容易被误用之外?
>我们都能认同,规则的应用需要细腻和智慧
除了 Uncle Bob 之外,似乎他的代码示例和自那本书出版以来的演讲都证明了这一点。这就是我的反对意见。在过去的19年里,许多人比 Bob 更好地阐述了他的想法。这本书在当时很好,但我们已经过了应该停止推荐它的十年。让人们去读 Ousterhout 吧——更短、更好、更持久。
鲍勃叔叔的规则:依我之见,应反其道而行之。若将其否定,便成了一套合理的规则!
> 聪明的大脑的开发者很多,有些人可能不会喜欢这个,会做出不高兴的表情。
我认为把话放在大语言模型(LLM)的嘴里没有帮助。要正确地思考这个问题,我们需要描述大语言模型(LLM)是如何思考的。它不会像人类那样用语言思考,也不会将模糊、难以把握的概念在脑海中移动并翻译成语言。它处理的是语言单元(token)及其在下一位置出现的概率。关键在于,这些概率代表了训练集中包含此类语言单元的句子背后最初的“思考”,因此它通过操纵语言单元及其背后的含义来进行处理。
现在,针对您的几点意见:1) 关于在上下文窗口中添加更多单词,关键不在于“更多”,而在于“足够”。如果您的任务缺乏足够的上下文信息,您将如何完成它?“去那里,我不知道具体位置。” 2)关于“问题已解决”,如果大语言模型(LLM) 提出或做了这样的事情,这只是意味着,在当前上下文中,这是普通开发人员解决问题的方式。因此,这不是智能问题,而是上下文和训练集问题!当您写道“软件工程师可以退一步,思考整个问题,并确定问题的根本原因”时,请注意,您实际上是在指上下文。如果缺乏足够的上下文或工具来补充数据,无论数字开发者还是传统开发者都无法完成任务。
> 它不会像人类那样用语言思考,也不会将模糊、难以把握的概念转化为文字。
这在我看来是对状态空间与思维链延续的完美描述。
作者并不了解当今的大语言模型(LLMs)和编码工具的能力。
> 大语言模型(LLMs)会不断感到困惑:它们认为自己编写的代码实际上是有效的;当测试失败时,它们只能猜测是修复代码还是测试;当感到沮丧时,它们只会删除所有内容,然后重新开始。这完全与我想要的相反。软件工程师会在开发过程中持续测试。当测试失败时,他们可以借助自己的认知模型判断是修复代码还是测试,或在决策前收集更多数据。当感到沮丧时,他们可以通过讨论寻求帮助。尽管有时他们会删除所有内容重新开始,但此时他们对问题的理解已更加清晰。
我的经验是基于使用 Cline 与 Anthropic Sonnet 3.7 在 Rails 上进行 TDD,体验截然不同。我指示模型在编写任何代码之前先编写测试,它也会照做。它以足够小的块进行工作,我可以审查每个块。当测试失败时,它往往能很好地推断出原因,并修复相应的位置。大语言模型(LLM)在学习过程中参考更多代码是非常常见的。
它当然不是完美的,但它的表现与人类初级工程师一样好,甚至更好。有时它无法解决一个错误,但人类初级工程师也会遇到同样的情况。
我在公司的 Slack 上分享了大语言模型(LLM) 失败的例子,每周大语言模型(LLMs) 都会做与我告诉它们相反的事情。
我说不要覆盖控制台方法来捕获日志——它们却覆盖了控制台方法。
你不允许更改测试——测试却发生了变化
或者它们在测试中插入各种睡眠调用,以解决竞争条件。
这些都是来自 Claude Sonnet 4。
我发现,当我像对待小孩子一样对待大语言模型(LLMs)时,会得到更好的结果。不要告诉他们不要做什么,而是告诉他们应该做什么。
说“把手放在身边,很烫”,而不是“不要碰炉子,很烫”。如果你说后者,大多数孩子都会去碰炉子。
我也遇到过这种情况,但仅限于上下文过长时,此时模型会停止阅读我的指令。或者如果来回沟通过多,也会出现这种情况。
随着上下文长度的增加,模型的整体能力会稳步下降。定期清除记录确实有助于应对这种情况,但反复从头重建上下文确实非常麻烦。遗憾的是,我确实不知道还有其他方法可以避免模型随着时间推移变得越来越愚蠢。
大语言模型(LLMs) 删除你的重要评论真是令人恼火!我经常遇到这种情况。
你是否也分享过它表现特别好的例子?
我认为它们在已知框架(如Rails)中的CRUD操作中表现特别好。
另一方面,我尝试用Rust和Direct2D构建原生Windows应用时,结果是一场灾难。
希望人们能对他们构建的内容更加开放。
我同意,对于大语言模型(LLM)来说,在任何框架(如 Rails)中编写好的代码可能更容易,因为这些框架对如何做事情有许多记录完整的意见。如果有一个“正确”的地方来放置东西,或者一个“正确”的方式来建模框架中的问题,那么模型意见与人类工程师的意见相一致的可能性就更大。
此外,这对每个人来说都很容易。这基本上是一个非常 rigid/simple(对于框架来说,这两个概念是相邻的)的框架,以至于业务逻辑几乎成了模板。
也就是说,只要你留在护栏内。如果你让它在 Rails 应用中做一些超出 CRUD 范围的事情,它就会陷入困境——就像大多数人类会做的那样。
所以,让机器人处理重复性工作本身并不是坏事。但从一开始就让高素质的人类来做这些工作,本身就是一种浪费。希望几年后,我们都不需要再做任何CRUD工作,而是只做软件开发中有趣的部分。-
> 我希望人们能对他们所构建的东西更加开放。
我认为在过去的6个月里,我聊天应用程序(https://github.com/gitsense/chat)中95%的代码是由AI生成的(98%由人类设计)。我认为过去六个月我所创造的成果绝非微不足道。人工智能在其中一个功能上提供了巨大帮助,那就是人工智能搜索助手功能。你可以在此了解更多详情https://github.com/gitsense/chat/blob/main/packages/chat/wid…
作为调试合作伙伴,大语言模型(LLMs) 非常宝贵。我可以轻松地将所有后端搜索代码加载到上下文中,让它跟踪查询,并创建一个只包含受影响文件的上下文包。一旦得到这个上下文包,我就会使用我的工具将上下文过滤为只有这些文件,然后与大语言模型(LLM)对话,找出问题所在或搜索速度慢的原因。
我非常赞同博客文章作者关于大语言模型(LLMs)为什么无法真正构建软件的观点。在我看来,人工智能是一个行业变革者,因为它确实可以使高级开发人员的效率提高 3 到 4 倍。我还应该指出,我每天在 LLM API 调用上花费大约 2 美元(99% 用于 Gemini 2.5 Flash),我每天可能要阅读 200 多条 LLM 生成的消息,并每天回复大约 5 次非常详细的回复(可以认为是电子邮件,而不是聊天消息)。
注意:README中的演示尚未设置,因为我仍在为发布做最后的准备,但NPM安装说明应该有效。
当你让AI设置README中的演示时会发生什么?
它总结了安装和设置所需的说明。它(Gemini 和 Sonnet)确实没有提到我需要设置服务器并为子域创建 DNS 条目。
> 可能每天要阅读 200 多条大语言模型 (LLM) 生成的消息,并每天详细回复 5 次左右(想想电子邮件,而不是聊天消息)。
我无法想象还有比每天阅读 200 封电子邮件或大语言模型(LLM) 聊天信息更累人的事情了。然后还要详细回复其中 5 次。计算阅读信息和回复所花费的时间后,这不会带来“3 到 4 倍”的性能提升。我不确定以这种方式使用大语言模型(LLMs)的人是否真的充分记录了时间,以至于能够自信地说“3到4倍”接近现实。
许多消息都是修订版,因此并不像看起来那么乏味。至于“3到4倍”,这是我自己的经验。我可能是特例,但80%我生成的AI代码都是一次性完成的。我花一两个小时(通常分散在几天内思考问题)就能完成原本需要一周或更长时间才能完成的任务。
我将开始收集关于AI生成的代码量以及一些复杂度指标的统计数据。
我显然有偏见,但这确实感觉像是一种范式转变,如果人们未能完全适应它,可能就为时已晚。我不确定你是否看过《千钧一发》,但这种感觉有点像……就是宇航员的那部分。
我从事了几十年的职业开始感觉非常不同,就像在观看《千钧一发》时,我对宇航员的看法发生了变化。这很奇怪,但合乎逻辑,而这就是我对软件行业看到的未来。那些能清晰阐述问题的人,我认为将比沉默的天才更具价值。
> 如果人们无法完全适应这种变化,可能就为时已晚
为什么会为时已晚?
年龄歧视、市场饱和、不再适合团队(每个人都在使用AI,并且有指标来证明性能提升),等等。
难道不使用它的人不能……开始使用它吗?
当然可以成为一种爱好。
对双人编程也有同样的争议,但它并没有真正流行起来。使用大语言模型(LLMs)来编写代码是一种编写代码的方法,但并不一定是最好的,而且老实说,这似乎是一种流行趋势。是的,我在编码流程中使用“AI”,但总体来说,它比有帮助更让人烦躁。如果你天生比我慢3到4倍,那么恭喜你,你现在正在赶上速度。我认为这都相当主观。
> 我认为这都相当主观。
这非常容易衡量,因为你不是在与他人比较,而是在与自己比较。基准是你自己,因此很容易判断你是否变得更高效。你所说的意思是,你不相信“你”能够利用人工智能比现在更高效,这可能确实如此,因为这取决于你的领域和专业知识。
无论“人工智能”能为我做些什么或不能做些什么,它都在被强加给我们所有人,这让人感到沮丧。每次我选择人工智能生成的内容时,它都在收集统计数据,我确信有人正在监控我们使用“人工智能”的频率,这可能成为衡量工作表现的指标,即使它并未真正提升质量或显著增加我的产出。
> 被强加给我们所有人,这让人感到沮丧
商业就是商业,如果你能证明自己不可或缺,他们大多会留住你,但商业也涉及政治。
> 可能在监控我们使用“AI”的频率,这可能成为工作绩效的衡量标准
我敢打赌,而且我还要更进一步。他们(雇主)会开始追踪大语言模型(LLM)的对话。如果每个人都在使用人工智能,他们(雇主)就需要一些差异化因素来证明加薪、晋升等措施的合理性。
>> 我们使用“人工智能”的程度,这可能会成为工作绩效的衡量标准
> 他们(雇主)需要差异化因素来证明加薪、晋升等措施的合理性。
这正是我的意思。
当我开始使用 Rust 时,我觉得 Claude 变得更聪明了。最大的问题是我自己并不了解 Rust 😛
这是风格问题。回复总是文笔优美且结构严谨。当你查看自己不熟悉领域的输出时,会倾向于相信它,因为听起来像一个高度专业的人类,因此会做出类似反应。而当你使用它处理自己非常熟悉的领域时,自然会更关注内容而非形式,从而更容易发现错误。这会打破对惊人推理能力等幻想。
我的 ChatGPT 在园艺方面非常在行!好吧,反正感觉是这样。这是正确的吗?我不知道。听起来是正确的。幸运的是,这只是我的一个新爱好,风险很低。但总的来说,我认为,对于听起来很自信的胡言乱语,无论是来自大语言模型(LLM)还是营销大师,多疑总比轻信好。
我最近用Go语言构建了一个数据流连接器,附带各种花哨的功能(基于YAML的数据解析器、断路器、端到端压力测试框架等)。运行得非常顺畅,我估计它将两个月的工作量缩短到了两周。
但你需要确保工作流程正确。
是的,通常他们都在开发待办事项列表和日程管理应用,而GitHub上早已充斥着大学生们声称革命性的待办事项应用项目。
我不想贬低或不尊重任何人的工作。但我从未见过对任务类别有精准描述的案例,一切都基于直觉。
同意。特别是这段话
> 当测试失败时,他们只能猜测是修复代码还是测试;当感到沮丧时,他们就会删除所有内容,然后重新开始
这与大语言模型(LLM) 通常的做法完全相反。它们在方法上非常固执,通常会一直坚持下去,直到你回滚到之前的提示。它们删除代码往往是在命令下进行的,除非我专门做 TDD,这可能是一个先发制人的命令。
> 作者并不了解大语言模型(LLMs)和编码工具目前的能力。
声称制作人工智能编码工具(Zed)的人不知道大语言模型(LLM)编码工具,这是荒谬且极其傲慢的。
模型会尝试通过黑客和技巧(硬编码解决方案等)来通过失败的测试,这是有据可查的行为。
事实上,你可以指示它们不要这样做,并且能够成功。
事实上,模型有时根本不理会指令,而是按照文本预测的结果行事(即使有推理过程)
另一个问题是,大语言模型(LLMs)没有学习能力。
即使你为它们提供了文件内容,它们也无法回忆起来,或者即使回忆起来,也会很快忘记。
例如,如果你告诉它们“发票”模型有 x、y、z 字段,并提供了部分架构。
几轮回复后,生成的“发票”模型会包含a、b、c字段,因为这些是最常见的。
更糟糕的是,当让它们编写自相矛盾的测试用例、移除需求以修复 bug 并凭空杜撰新需求时,最终将导致灾难性后果。
到目前为止,我的经验是,如果将“能力”限制在初级工程师层面,确实如此,尤其是当他们之前遇到过类似问题时。他们能够迅速提出解决方案并确认其有效性。
但对于从未遇到过的问题,这种方法效果不佳。此时需要先解释问题,再指导解决方案。因此,此时你只是充当导师的角色,而不是利用自己的能力来实施解决方案。
我的整个团队都真正接受了“claude-code”的方式来完成多年来积压的副业,比如简单的重构或二级分析系统。基本上,任何我们都没有时间去完成的、已经走过无数次的道路,现在都非常适合这些代理。
就个人而言,我喜欢突出显示一段代码,然后让大语言模型(LLM)像对 5 岁孩子一样向我解释,或者寻找任何潜在的竞争条件。对于那些在原始工程师离开后仍然存在很久的陈旧、脆弱的单一代码块,使用大语言模型(LLM)来理解它们简直是神奇的。
不过我尚未发现它能更出色地编写此类代码,而这正是关键所在。它并不擅长创建那些不常见的新事物。其代码风格也与现有规范存在显著差异。因此当它插入代码时,往往需要重新编写以适应周围的风格。我已听到有人私下议论“为AI阅读而编写的代码”。这让我感到不屑一顾,因为目前来看,额外的脑力投入似乎并不值得。
根据我的经验,TDD 是与大语言模型(LLMs) 配合使用的非常强大的范例。
它通过测试空间的隐含上下文很好地处理了行为,似乎真的减少了所需的解释量和意外的垃圾输出。
根据我的经验,这在很大程度上取决于编程语言、平台和业务领域。
我没有亲自尝试过在Rails中使用它(说实话,我已经多年没有碰过Ruby了),但它在Rails中效果良好并不让我感到意外。Ruby on Rails的编程文化在如何做事情方面非常一致。我猜这意味着大语言模型(LLM)能够从其训练数据中推导出一个(由于缺乏更好的词来描述)更合理的模型。
相比之下,它对 Python 的处理会很快变得非常混乱。我遇到的最大问题之一是,它倾向于使用各种不同的Python编码风格的随机混合。这使得测试驱动开发(TDD)特别具有挑战性,因为你会得到针对遵循一种变化模式的代码设计的测试,而这些测试是针对遵循导致完全不同变化模式的约定进行编写的。结果是测试变得极其脆弱,会因各种莫名其妙的原因反复失败。
迭代过程也变得相当疯狂。我最喜欢的场景是:真实缺陷是“哎呀,我忘了对查询结果进行排序”,而建议的解决方案是“移除SqlAlchemy并替换为Django”。
R代码更糟糕;即使让它生成符合规范的代码本身就是个挑战。
> 作者并不了解当今的大语言模型(LLMs)和编码工具的能力。
嗯…
这位作者正在开发“当今的大语言模型(LLMs)和编码工具”。这并不是说他们只是在制作一个典型的 CRUD Rails 应用程序。
看到这样的评论总是很有趣。我称它们为“技能问题”评论。
事实上,作者非常了解当今的技术。毕竟,Zed 正在其编辑器中构建许多以人工智能为重点的功能,其中包括利用 SOTA 大语言模型(LLMs)。
> 它当然不是完美的,但它的性能与初级工程师相当,甚至更胜一筹。有时它无法解决错误,但初级工程师也会遇到同样的情况。
我不知道这样的评论是否更多地反映了几年前招聘人才池的糟糕状况,而不是大语言模型(LLMs)的能力。如果我雇佣了一个能力比 Sonnet 3.7 还差的初级工程师,我会感到非常沮丧。
这是一个非常友好和热情的回应。考虑到原评论暗示Zed的创建者实际上并不懂得如何构建软件。基于他们构建Rails CRUD应用的资历,我猜是这样。
> 它的工作效果与人类初级工程师相当,甚至更好。
我经常看到AI支持者提出这种论点,坦白说这令人沮丧。你们把经验较少的工程师看作只是代码的输出者吗?成为某领域的“初级”工程师的意义在于学习和成长,而这些大语言模型(LLM)工具却无法做到这一点。
他们只是在比较工作产出水平,但你却认为这意味着初级工程师没有其他值得关注的价值。
这并非逻辑推理,而是个人观点,而观点本身具有价值。你无法仅仅因为不喜欢某一观点,就试图将其抹去或混淆问题本质。
我并不否认他们认为这些模型“与初级工程师一样优秀”,无论你用什么标准来衡量。我的观点是,有人用这个作为支持大语言模型(LLMs)的论据,这非常可悲。
对于大语言模型(LLM)来说,这可能大部分都是真的,但多年的投资经验让我养成了寻找那些表现不佳但仍在不断发展的技术或公司的思维模式。
在 90 年代初期到中期,人们对互联网抱怨不休,它速度慢、静态,大多数网站都挂着“正在建设中”的标志,电话调制解调器会随机断开连接。互联网在很多方面确实表现不佳,但人们仍然在使用它。
2000年代中期,Twitter也很糟糕,我们每周都能看到“失败鲸鱼”的错误提示,但人们仍然继续使用它来获取最新新闻。
电动汽车也很糟糕,没有充电设施,续航里程短,价格昂贵,但无论人们如何抱怨,它们仍在不断改进。
手机很糟糕,3G 之前速度很慢,在应用商店出现之前,手机没有太多用途,而且相机质量很差,但人们仍然在不断改进的同时继续使用它们。
永远寻找那些糟糕但人们仍然继续使用因为它们提供价值的技术。大语言模型(LLM) 在许多任务上并不出色,但无论人们如何抱怨,它们仍然被不断使用,并通过不断迭代不断改进。
大语言模型(LLM)今天可能还无法构建软件,但它们已经比 2022 年我们刚开始使用 chatgpt 时好了 10 倍。可以合理地假设,5 年后它们将能够完成此类开发任务。
与此同时,许多对这些技术的预期并未在任何时候得到实现。这在很大程度上是因为存在难以克服的物理限制。互联网变得更快更稳定,但元宇宙的普及并未实现,部分原因在于许多人在使用一段时间后仍会感到眩晕,而10倍的性能提升也无法解决这个问题。
你所描述的“糟糕”之处,当时并未被视为“糟糕”。没有人抱怨手机速度慢,因为没有人预料到今天我们会以这种方式使用手机。互联网速度慢且不稳定,但没有人抱怨,因为他们不期待能流畅播放4K电影。这是时代错位。
我们能够看到某些方面以 X Y 方式得到改善,但这并不意味着大语言模型(LLMs) 会按照你的想法得到改善。也许我们会发明一种更有效的不同技术。毕竟,拨号本身并没有变得更快,而且我认为也没有狂热者会说拨号技术会给我们带来 1Gbp 的速度。人工智能的问题在于,由于计算能力的提升带来了突破,有些人认为,通过提升计算能力和一些技术技巧,我们就能解决所有当前的问题。我认为没有人能说我们无法发明一种能够克服这些问题的技术,但大语言模型(LLMs)是否是一种能够不断提升的技术,仍然存在疑问。去年左右,该技术进行了许多改进和应用扩展,但并没有取得突破性的进展。
> 但元宇宙的普及并未实现,部分原因在于许多人在使用一段时间后仍会感到眩晕,而10倍的扩展也未能解决这一问题。
虚拟现实技术真的提升了10倍吗?我自HTC Vive后便不再关注,虽听说过Valve Index,但据我所知,即使是苹果提供的最佳设备也仅能提升2倍。
我认为你有点过度解读了,10倍这个数字之前就被使用过,这里只是用来说明有些问题是无法通过扩展来解决的,这并不是对VR发展程度的评价。
> 电动汽车很糟糕,没有充电设施,续航里程短,价格昂贵,但无论人们如何抱怨,它们一直在改进。
它们花了超过一个世纪才达到现在的水平。
> 手机很糟糕,3G之前速度很慢,没有应用商店和摄像头之前,手机几乎没什么用处,摄像头质量也非常差。
这是对历史的重大歪曲。手机之所以流行,是因为在移动电话出现之前,唯一能联系到一个人的方式就是在他们在家或办公室时打电话。人们有很长一段时间无法联系到对方,现在看来这很古怪。短信让沟通变得异步。那些“土豆”摄像头标志着人们随时随地都能携带摄像头的时代到来。
使用诺基亚3210的人根本没有预料到手机会变得更好,它们本身就是杀手级应用。它们的改进只是锦上添花。
> 使用诺基亚3210的用户根本没有预料到他们的手机会变得更好,因为它本身就是一款杀手级应用。它的改进只是锦上添花。
每当我听到有人通过将新技术(区块链、大语言模型(LLMs)、NFT)与手机、互联网或其他东西进行比较来为其辩护时,我总是感到很困扰。人们并不需要被说服去使用手机或互联网。虽然肯定有一些反对者,但当这些技术进入消费市场时,它们的实用性和有用性已经非常明显了。
此外,这里还存在幸存者偏差。无数有前途的技术从未得到广泛采用。任何新技术成为失败品的可能性,远大于成为“下一个iPhone”或“新互联网”的可能性。
简而言之,你应该基于技术当前能做的事情来推广它,而不是它未来可能做的事情。如果你的技术目前无法提供实用性,那么在开始收费之前,应该先进行更长时间的开发。虽然大语言模型(LLMs) 肯定有一些用途,但目前推行的许多用例(谷歌“AI 概述”、劣质 AI 艺术、AI 撰写电子邮件)并不特别有用。
值得关注的技术是购物车。如今它们对我们来说显而易见,但最初推出时,商店会雇佣演员使用购物车,以促使真实顾客养成使用习惯。目前已有许多“杀手级”应用对用户非常有用,但它们需要时间才能被广泛接受,因为人们需要逐步发现它们的价值。你不同意企业巨头推崇的观点,那是他们的失误。
但这只是又一次挑三拣四。你总能找到过去的成功案例来支持你试图证明的观点。但仅仅因为购物车大获成功,并不意味着你试图推广的任何东西都会成功。
例如,如果我说“超回路列车(hyperloop)曾受到大量炒作和投资,但最终失败了。因此,同样受到大量炒作和投资的大语言模型(LLMs)也会失败”,这是错误的。超回路列车和大语言模型是截然不同的技术,超回路列车的失败并不能说明大语言模型最终是否会成功。
这并不是说我们不能将新科技与过去的成功或失败案例进行比较。但这些比较不应成为你论证新技术可行性的主要依据。
> 仅仅因为购物车大获成功,并不意味着你试图推广的任何事物都会成功。
这可能得益于购物车被主动设计成易于推动的。
不幸的是,我的时光机正在维修中,所以我不知道未来会是什么样子,所以寻找比较只是我展望未来的方式。
我认为这项技术可行性的主要论点是它今天就有用。即使它不再改进,作为程序员的工作已经发生了变化。
> 即使它不再进步,我作为程序员的工作已经发生了变化。
这让我非常烦恼。我作为程序员的工作没有变化,因为我作为程序员的职责没有变化
无论我请求大语言模型(LLM)为我编写代码,还是自己编写代码,工作都是一样的。最多只是多了一个新工具,但工作并没有改变。
职责没有改变,但我花在阅读文档以准确地复述文档内容上的时间却大大减少了。那并非工作的全部,但确实是工作的一部分,若否认这一点便是不诚实。我并不了解你,因此无法判断你工作中这一部分所占比例。但我可以坦率地说,这在一个月内确实累积了不少。这或许更多地反映了我个人及工作性质,而非其他因素。
人们过去会用袋子装满蔬菜、鱼肉的捆包或袋子,偶尔还会带上几袋或几盒干货。
手推车是让人们与超市新设的“中央过道”互动的必要工具,而这些过道里大多堆满了盒装和罐装的垃圾食品。
正如其他人所提到的,你只是在编写符合自己叙述的历史。没有证据支持“人们在90年代初至中期对互联网抱怨不休”的说法。
在90年代初,人们实际上几乎不使用互联网。使用率微乎其微,仅限于极小的利基群体。人们通过晚间新闻节目中90秒的简短报道得知互联网的存在。直到Facebook推出后,互联网才真正进入主流。因此,我真的不认为人们会抱怨互联网速度慢,因为他们根本没有使用过。
我还可以继续说下去,但真的不需要花几段文字来反驳一个显然是错误的观点。
那个时代的人们:没有人会“抱怨个没完没了”,甚至根本不会抱怨互联网。它被视为一种神奇的存在。与完全不存在相比,速度慢其实也没那么糟糕。
我记得大约在2005年使用互联网时,你可以一边等待页面加载,一边进行对话。没有人抱怨,因为你指尖触手可及的是一片信息海洋。能够与世界各地的人聊天,或者浏览一些论坛,实际上是令人惊叹的。
不过,这是一种有选择性的回忆。我们记得的是那些坚持下来并不断改进的少数产品。我们不记得那些在新鲜感消退后逐渐消失,或最终停滞不前的绝大多数产品。
我同意文章作者的观点。技术或许最终会达到那个水平,但目前看来还未实现。我更倾向于基于当前现实做出决策,而非仅仅假设我想要的未来就是我将获得的未来。
> 这是一种典型的选择性回忆。
哈哈;) 没错,当你提供例子来证明自己的观点时,这些例子本身就是有选择性的:)
你可以自由地构建自己对技术和公司投资的认知模型。我只是想分享我20年的投资经验,以说明为何不应因当前技术的局限性而放弃它。
公平地说,投资本身就是一回事,因为它本质上是基于当前的不完整信息来预测未来。
工程决策,这更接近TFA所讨论的内容,通常必须更加关注当下。你可以对未来研发进展进行押注(例如阿波罗计划),但这种游戏最好在你有权控制研发预算和方向(例如阿波罗计划)且别无选择(例如阿波罗计划)时玩。
我不赞同大语言模型(LLMs)在过去几年里已经提高了 X 倍,因此未来几年也会继续提高 X 倍的说法。据我所见,所有的增长主要来自对一些技术的优化,但我并不相信我们不会陷入局部最大值(实际上,我认为这是最有可能的结果)。
具体来说,对我而言,大语言模型(LLMs)的局限性在于发现新知识和对从未见过的信息进行推理。大语言模型(LLMs)仍然无法完成一些任务,比如计算蓝莓一词中b的数量,或者在文字题中插入随机的猫的事实而不被分散注意力(这两个问题我上个月都遇到过)。
我并非认为它们是无用的工具,我只是不认同那种过度炒作的论调。
相关链接:https://xkcd.com/605/
最新版本的改进越来越小,甚至可能没有改进。除非有人能解释技术原因,说明它们为何有可能扩展到能够实现X,否则这种说法相当没有意义
> 大语言模型(LLM)今天可能还无法构建软件,但它们比 2022 年我们刚开始使用 chatgpt 时已经进步了 10 倍。假设 5 年后它们能够完成此类开发任务是相当合理的。
我们可以预计它们在 5 年后会变得更好,但你的最后一个论断并不成立。我们无法肯定地说它们能够具体解决文章中提出的问题。这可能并不是大语言模型(LLMs)擅长的领域,我们需要新的突破,而这种突破可能出现,也可能不会出现。
我们也曾认为3D打印能打印出汽车,但事实并非如此。
顺便说一句,3D打印技术已取得长足进步,我个人也拥有3D打印机。但认为它将彻底颠覆制造业的观点纯属误解。其中存在已知物理限制(例如如何将木质聚合物挤过金属喷嘴?),这些限制是物理层面的,而非技术层面的。
同意关于3D打印的观点,但这项技术如果按目前提案提出,将无法通过我的筛选。
尽管人们指出了其缺陷,但它并未实现大规模采用和改进。
它最初在打印基本塑料部件上取得成功,但如你正确指出的,未能在金属等其他材料上实现打印,因此目前状态下这些技术无法通过我的筛选。
我需要一个袋子夹子,只需在手机应用中搜索并点击打印,几乎毫无麻烦,这说明3D打印已成现实。当然,花$1500节省$3并不经济,但3D打印已颠覆了行业。看看SpaceX的火箭发动机就知道了。
我认为这里存在一些区别,即基础模型并非比2022年时好10倍。不过,我们对如何从略微改进的模型中获取更多价值的领域知识有了显著提升。
所以,考虑一下你的类比:互联网一直都有用,但正是JavaScript引发了软件行业的那场巨大变革。尽管互联网的核心基础设施并没有像你想象的那样迅速得到根本性改进。JavaScript最初只是作为一种玩具脚本语言被拼凑出来,旨在让网页更加互动,但结果证明,它正是解锁现有互联网10倍价值的关键。
代理和所有这些小型上下文服务爆炸式增长的现象,正是我在此看到的相同趋势。目前它们尚不完善,大多是实验性工具。然而,它们正在释放那10倍的价值。
> JavaScript最初只是作为一种玩具脚本语言仓促拼凑而成,旨在让网页更加互动,但事实证明,它正是解锁现有互联网10倍价值的关键。
真的吗?我记得可安装的软件比你说的要多得多,才是计算机的核心用途。即使在今天,大多数人仍在使用应用程序。
人们也对虚拟现实(VR)抱怨很多。
NFT 也遭到许多人的强烈反对。
每个人都抱怨其他无数种毫无用处的解决方案。
尽管如此,许多投资者还是从虚拟现实和 NFT 中赚取了丰厚的利润。投资的好坏并不能表明某件事是否有用。
我每天都会使用大语言模型(LLMs)数小时。2010 年初至中期,我对虚拟现实非常感兴趣,但即使如此,我的同龄人也没有多少人采用虚拟现实,而大家都在使用大语言模型(LLMs)。
NFT 总是被认为是一种骗局,就像令人窒息的区块链一样毫无意义。
大语言模型(LLMs) 有许多问题,但我认为它们与其他例子截然不同。
这些观点非常正确,但大语言模型(LLMs)的能力已经开始趋于平稳了,不是吗?从 gpt2 类模型到 3 类的改进远大于从 3 类到 4 类的改进,而从 4 类到 5 类的改进又比从 3 类到 4 类的改进小得多。
我认为,过去几个月里,在编码领域使用大语言模型(LLMs)的氛围发生了变化,主要是数据集整理和用户体验方面的改进,而不是技术上的根本性改进。
> 大语言模型(LLMs)已经真正开始达到瓶颈
这似乎并不出人意料。任何技术飞跃似乎都以S型曲线的形式发生。当发现一种行之有效的方法时,我们会全力以赴,直到收益递减。通常情况下,一种新方法会为其他基于它的方法打开大门。发现链条中的下一步需要时间,但一旦发现,我们将迎来新的 sigmoid 型飞跃。等等…
个人认为,下一个富有成效的步骤可能与 Victor Taelin [1] 试图实现的目标一致。
即,将围绕传统“AI”的新方法与生成式AI相结合。这可能并非他确切的目标,但或许在同一领域内。
1 – https://x.com/victortaelin
开始了吗?依我之见,自几年前ChatGPT发布以来,它们并未变得更好。弱点依然严重,优势也未提升。这就是我为何不认同“它们会变得更好”的炒作。它们目前无法做到被宣称能做的事,且过去几年也未见进步。为何我要相信它们未来能实现更高目标?
我猜你并不经常使用这些模型,因为前沿的大语言模型(LLMs)与GPT 3相比,响应质量存在巨大差异。
打开OpenAI API playground,给GPT3和GPT5相同的提示,要求它们按照你的规格用JavaScript制作一个相当基本的游戏,然后看看GPT 3如何苦苦挣扎,而GPT 5则一气呵成。
确实,但这就像一条路,却永远无法真正到达目的地。它似乎越来越接近下一个城镇,但最终还是没有到达,而这才是真正重要的。
他提到的其他所有东西都不依赖于突破,大语言模型(LLMs)似乎真的已经达到一个瓶颈,需要突破才能推进到下一步。
问题是,突破总是距离我们X年之遥(例如,聚变能源需要50年)。
他给出的唯一一个真正重要的例子是手机,电容式触摸屏确实推动了这项技术的发展。但这并不是说,在电容式触摸屏出现之前,手机就已经非常有用、非常赚钱,并且随着时间的推移越来越好了。
也许宽带互联网也符合这个条件。
> 他提到的其他所有东西都不依赖于突破,大语言模型(LLMs)似乎真的已经达到一个瓶颈,需要一个突破来推动它进入下一个阶段。
我认为,其中许多人依赖的是逐步改进和大量“微小突破”,而非一次改变一切的重大突破。这些微小突破在列表中的几乎每个例子中都花了数十年时间才真正实现,而不仅仅是两三年。
我个人直觉认为,即使核心技术已达到瓶颈,现有技术的商业化/产品化仍存在大量迭代改进空间(例如优化工具/用户界面/将其应用于解决实际问题/将当前研究成果产品化等)。
以电动汽车为例——我们目前仍处于特斯拉将电池塞进莲花埃尔西阶段,而非发布Model 3的阶段。虽然我们已拥有锂聚合物电池,但要将其整合为最终产品仍需大量工作。
(尽管如此,我并不认为技术已达到瓶颈——我们只是在极短的时间跨度内观察它。如果在1979年有人说计算机在1979年已经停滞不前,因为过去12个月没有取得多少进展,那他们就大错特错了——突破有时需要更长时间,因为技术需要成熟,但这并不意味着20年后的技术不会有实质性变化。
今天的 Claude Code 与 6 个月前的 Claude Code 有很大不同。也许大语言模型(LLMs)已经达到顶峰,但工具却并非如此。
> 但大语言模型(LLMs)的能力真的已经达到顶峰了吧?
嗯,不是吗?
在过去的一个月里,我们取得了以下成就:
– 大语言模型(3 种不同的模型)在 IMO 上获得金牌
– 在 IoI 上获得金牌
– 在 atcode 启发式算法(优化问题)上击败了 9/10 的人类开发者,唯一击败机器的人类说他已经筋疲力尽,明年可能就结束了。
– 真正有效的代理系统。该系统可在30-90分钟的会话中保持一致性并完成任务。
– 顶级(SotA?)模型的价格下降了4-6倍。oAI的“最佳”模型现在仅需10$/MTok,而其之前SotA模型的价格为40-60$/MTok,但新模型仍保留了90%以上的性能。
– 每个模型提供商都发布了多个“束缚”。Claude 代码似乎仍然是最好的,但替代方案也随处可见——geminicli、opencoder、qwencli(虽然已经分叉,但仍然存在)等。
– 开源模型再次接近 SotA。落后 6-12 个月(取决于您问的是谁),开源且运行成本低廉(某些提供商约为 2 美元/MTok)。
我没有看到能力方面出现停滞。大语言模型(LLMs) 仅在基准测试方面出现停滞,数字只能上升到一定程度,然后就变得毫无用处了。我认为常规基准测试已变得无用。MMLU等模型虽有新意,但真正重要的是具备自主决策能力的模型。而这类模型的能力仍在持续提升,且随着数据质量、信号质量及训练方法的优化,这种提升将持续下去。
为何你认为所有模型提供商目前都在大力补贴编码工作?他们都渴望获取优质数据与信号,以便进一步优化模型。
我不确定是否应将其描述为瓶颈。可能确实如此,但我并不完全认同。如今改进效果不再那么显而易见,但其中有多少是由于在某个临界点后难以准确衡量智能水平?或是智能本身在现实生活中的边际效用开始趋于平缓?
一个(不恰当的)类比是:我能轻易分辨出猫和猿的差异,且能力差异显而易见——但从智商70提升到爱因斯坦水平的进步则难以评估,且对大多数任务而言可能并不实用。
我发现,当我切换到新模型时,它似乎并没有更好,但几周后再尝试使用旧模型时,我会惊讶地发现它差了多少。
> Twitter 糟糕 […] 电动汽车糟糕 […] 手机糟糕
所有这些都不是黑匣子,它们大多是确定性的。根据输入,你可以确切地知道会得到什么输出。
大语言模型(LLMs)的情况并非如此,它们是如何训练的,内部是如何工作的。
我们当然可以更好地理解如何调整输入,以获得所需的输出。但这远不能像你提到的例子那样得到保证。
这是大语言模型(LLMs)的一个根本问题。从行业参与者围绕这个问题构建解决方案的方式中,你可以看到这一点。推理(思维链)基本上是一种缩小决策树的权宜之计,因为大语言模型(LLMs)实际上并不对任何事情进行“推理”。只有更多的训练数据,结果才会更好。我们不得不通过投入更多计算资源和内存来蛮力获取有用结果(此过程同时破坏环境和气候)。
近期模型发布的停滞态势对这项技术前景并不乐观。
现在想想悬浮滑板、自清洁衬衫、月球基地、飞行汽车、运作良好的民主制度,以及《雪崩》中描述的任何虚拟现实技术。大型语言模型(LLMs)会在哪个位置?
“这相当合理”……这是个大飞跃吗?
大语言模型(LLMs)无法构建软件,因为我们期望它们听到几句话后,立即开始编码,直到出现原型。当它们出错时,它们需要处理大量杂乱无章的信息。在编写代码之前,几乎没有机会进行更高层次的迭代。
如果我们将人类工程团队置于相同的情况下,我们会期望他们做得很糟糕,那么为什么我们期望大语言模型(LLMs)能做得更好呢?
我们可以通过使用所有那些帮助工程团队避免这些问题的流程和工具来显著提高大语言模型(LLMs)软件开发的产出:
https://jim.dabell.name/articles/2025/08/08/autonomous-softw…
是的。我启动了一个完全自主、100% 由 vibe 编码的副项目,名为 steadytext,主要期望它会遇到障碍,最终大语言模型(LLMs) 难以维护或修复其中的任何非微不足道的错误。结果证明我错了,Claude Opus 不仅能够使用 python 库、CLI 和 postgres 扩展编写一个相当复杂的 7k LoC 项目。它还能主动维护项目,并能完全自主修复已提交的 bug 和功能请求。该项目完全由 vibe 代码构成,我甚至从未查看过该仓库中 90% 的代码。它具备完整的测试覆盖率,通过了持续集成(CI),并且我们已在生产环境中使用它!
当然,它需要对 CLAUDE.md 进行仔细规划,所有问题和功能请求都需要大量深入的细节,但一切都能正常运行。因此,我对这篇文章并不完全信服。我认为,让编码代理能够有效地管理和编写软件绝非易事,在现有项目中尤其困难,但我的经验涵盖了整个领域。我对编码代理感到非常失望,甚至放弃了许多项目和数十个拉取请求,但我也有看到它们发挥作用的案例。
你可以在此查看该项目:https://github.com/julep-ai/steadytext/
嗯,很有意思。不过,我确实想知道,人工智能在编码方面能提供的最佳帮助是否是另一个人工智能工具。
我们并不期望人类做糟糕的工作——我们只是期望他们促进这个过程。
如果大语言模型(LLM)开始绘制屏幕草图,并反问软件的意图,那么我确信人们会获得更好的体验。
好吧,我愿意接受你的悲观观点。然而,经验告诉我,如果我们需要作为工程师和设计师团队解决一个模糊的问题,我们知道要充分了解我们实际上试图构建的是什么。
此外,最富有创意的解决方案往往来自于隐式和显式的约束。这是完全的人类技能,是我们擅长的领域。
这些大语言模型(LLMs)不会“考虑”某些事情,理解限制,然后在那些没有明确定义的限制内找到解决方案。如果通过常见的问题或背景文件无法充分理解限制,它就会走入歧途,试图拼凑出一些东西。
因此,目前我们仍然需要依靠人类来分解问题,确定这些限制条件下的工作范围,然后提出可行的前进路径。然后,在大语言模型(LLM)成为执行该前进路径的另一种方式。我应该使用javascript、rust还是Swift来编写解决方案,还是使用`CLAUDE.md`和这30项MCP服务来编写解决方案。
就目前而言,它只是工具箱中用于获得最终解决方案的另一种工具。我认为,关于它必须是非此即彼、全有或全无的争论是愚蠢的。
实际上,有很多人类工程师在这些情况下做得很好。
如果给大语言模型(LLMs)下达命令并不容易,那么它们的存在意义何在呢?
这是Kiro采取的方法,尽管还处于早期阶段。它并不完美,但如果你遵循其意图,它确实能产生相当好的结果。
在网上花了一分钟的调研,我发现你是亚马逊的市场经理。因此你的观点存在利益冲突,这应该被披露。
公平地说,我为没有披露这一点道歉。然而,Kiro 并非我负责的服务范围,这是我个人的观点,而非公司立场。
(此外,这里不存在利益冲突,你无需大喊大叫。我有权批评自己的公司。)
我从未认真尝试过用AI进行编程。我只是让ChatGPT提供可验证的代码片段,以节省在谷歌和API文档之间来回查找的时间。
然而,前几天我给ChatGPT布置了一个相对简单的任务,但它一直無視規則。每次我糾正它時,它又會違反另一條規則。我要求它提供性別中立的名字,但它卻一直給出像Orlov(會變成Orlova)這樣的姓氏,或是純粹男性化的名字。
Vibe編碼也是這樣嗎?
我的经历也一样,从未将ChatGPT用于除作为外部文档接口和理解不熟悉语法之外的任何用途。
第一次尝试用它进行vibe编码时,对整体结果感到非常失望,感觉就像一个大学生为了明天截止的项目匆匆从不同来源复制粘贴代码。
也许我只是给出了糟糕的提示……
情况相同。要获得最佳结果,必须明确提供所有假设、偏好、文档、意见、边界案例、未明言的知识、需求、需求例外、意图等。对于一次性周末项目这不重要,但对于更复杂的任务则至关重要。
我认为这是最具有挑战性的部分。存在大量被视为理所当然的未明言假设,若未在生成代码前全部提供,就需要反复再生成代码。我现在会花大量时间在生成代码前将这些内容全部记录下来。
> 它们无法做到的是保持清晰的心理模型
我使用 claude 代码越多,就越对这一点感到沮丧。我不确定通用的基于文本的大语言模型(LLM)能否正确解决这个问题。
这让我想起了谷歌的 Genie 3 只能运行大约一分钟,然后就会失去其内部状态 [0]。
我的直觉是,这个问题直到出现某种新架构(如Transformer架构)才能解决,这种架构能够支持短期上下文、长期上下文以及模型权重的自我调节(以模拟“学习”过程)。(免责声明:我只是个业余爱好者,没有接受过正式的机器学习培训。)
[0]: https://news.ycombinator.com/item?id=44798166
这是形式化系统的本质。有人需要实际定义这些规则,或者使用较小的规则集生成更大的规则集。但每次发明一条规则,都意味着系统中无法表示某些可能的情况。你只能希望这些情况不重要。
大语言模型(LLMs)技术使我们能够从文本和其他数据中提取规则。但这些数据并不代表一个连贯的系统。结果本身是不连贯的,缺乏数据之外的内容。这是正常的。
这就像一个数学函数。它映射到的每个点都有意义,其他的一切都可能不存在。
我最近一直在思考这个问题……或许当前更可行的解决方案是运行一个代理层次结构,其中顶层代理维护整体思维模型(且其上下文仅包含“下一级代理报告该任务已完成”等基本信息)。显然,每当你尝试让一个 Code 代理运行所有任务时,它迟早会脱轨,忽略你原始指令中的重要细节,无法确保遵守 CLAUDE.md 等。我认为现在你可以使用 Code 的代理功能来做到这一点?有人有策略可以分享吗?
电话游戏效果并不好。这就是为什么皇帝会被孤立在宫殿中,每一道诏令都可能带来危害。这也是为什么建筑师/开发者模式行不通。你需要了解所有必要的上下文,以确保工作质量。
我也是这样。我使用过这个工具,它有点帮助:https://github.com/rizethereum/claude-code-requirements-buil…
不过,这个工具和其他技巧只是让我感到稍微不那么沮丧了。
坦白说,它迫使你——理所当然地——退后一步,成为那个负责规划的人。
你可以让它处理繁重的编码工作,以及大量低级别的分析和测试,但你绝对必须是那个负责设计的人。
它坦率地说,让我在完成任务的时间内有更多时间思考大局,我喜欢这一点。
该工具在向用户呈现更改和建议方面还有很大的改进空间。它需要更加互动。
这也是我的经验——我拥有心理模型,我的责任是使用文本将该模型传达给大语言模型(LLM),使用它从训练数据中识别的语言来生成相应的代码。
我使用大型语言模型(LLMs)进行代码生成的经验,与使用搜索引擎进行查询的经验其实并没有太大区别——你必须理解如何“使用目标语料库的语言进行交流”,才能找到你想要的结果。
是的,正是如此,你需要与 Claude 讨论设计/架构层面的代码……只是告诉它你想要的代码输出结果,只会让你陷入失败的循环。
我一直在说但没人听:AI 真的只是高级自动完成工具。它不会推理或思考。如果你明白它不能做什么,就能更好地使用这个工具。它能很好地编写单个函数,但将多个函数串联起来?那就差远了。
在它的局限性内使用时,它是个好工具。
这真的与“普通”程序员,尤其是初级程序员有那么大的区别吗?
> 大语言模型(LLMs) 会不断陷入困惑:它们认为自己编写的代码确实有效;当测试失败时,它们只能猜测是修复代码还是测试;当感到沮丧时,它们只会删除所有内容,然后重新开始。
我经常看到平庸的开发者这样做。他们手忙脚乱,尝试各种方法,从StackOverflow复制粘贴代码却不理解原理,最终认定是编译器有 bug,或是宇宙射线在翻转位元。
文章明确指出,这就是他们对合格软件工程师的期望。无能的开发人员确实存在,而初级开发人员往往还不够称职,但这并不改变什么。大语言模型(LLMs)的问题在于,它们已经是训练/学习的最终产品,而不是起点。大语言模型形成稳定心理模型的(不)能力是固定在其架构中的,并不是你可以教给它们的东西。
我刚刚(重新)阅读了这篇文章,“称职”一词并未出现在其中。除了与大语言模型(LLMs)进行比较外,文章完全没有讨论人类开发人员的称职程度。
是的,我在回复中用“称职”代替了“有效”,因为我认为在讨论的上下文中,这个词更合适一些。
我觉得你们那里可能出了问题,也许你们的 junior 没有受到足够的激励或鼓励去学习,代码审查可能不够严格,质量可能没有得到足够的重视,或者人们面临着巨大的压力要推进任务,或者以上所有因素以不同程度存在。
我之所以这样认为,是因为在我公司,那些正在休学一年攻读计算机科学学位的实习生不会抱怨编译器、宇宙位,也不会盲目地从Stack Overflow上复制代码。
他们有动力和鼓励去学习,并且绝对选择这样做。资深员工也是如此。
如果你在站立会议上说“我正在学习X来处理工单Y”,人们基本上会为此鼓掌,经理们喜欢看到我们自我提升。
当然,如果你几天没有写代码,经理们可能希望看到一份简短的摘要或适用于我们部门的报告,但这是唯一的摩擦。
我发现大语言模型(LLMs)能够如此密切地模仿初级开发人员的行为,这令人印象深刻。即使这不是理想的结果,但仍然令人印象深刻且有趣。
我厌倦了人们告诉我大语言模型(LLMs)不擅长构建软件,却从未尝试过坐下来学习如何正确使用Claude代码、何时使用以及何时不应使用。
Cursor是个笑话,windsurf还不错。
这并不是你使用大语言模型(LLM)的方法有问题,而是人工智能工具根本无法创建用于解决问题的心理模型。听起来你厌倦了听到大语言模型(LLM)并不是万能的。
没错,有些事情你不应该用大语言模型(LLM)来做。但生成舵手图表、配置、操作工作流程、构建规格,然后根据它们进行实施?这简直是小菜一碟。
大语言模型(LLMs)的好坏取决于人们给它们的输入。
目前局面非常两极分化。一方是“AI是失败的,你无法用它构建任何严肃的东西,这个泡沫随时都会破裂”的阵营,另一方是“AI彻底改变了我的工作流程,我现在效率提升了10倍”的阵营。
我意思是,这类帖子每天都在这里疯传。
它既不是毫无用处,也不是提高了 10 倍。它确实提高了 1.2 倍至 1.8 倍。
我同意大语言模型(LLMs)擅长初级水平的工作。
最近,我开始重新思考打字速度并不重要的观点。
这是个老生常谈的问题,大多数人认为打字速度快慢并不重要。我想,更准确的说法是,大多数人认为你能否快速完成代码修改并不重要。毕竟,借助现代工具,你无需手动输入所有代码,而且还有各种非AI方法可以让代码呈现你想要的格式。这并不重要,工程师的真正工作是整个程序功能的架构。打字速度快并不能让你更快地达到目标,因为找到整体设计才是限制因素。
但我已经使用 Claude 一段时间了,我开始看到它的真正好处:你不再需要集中精力来修改代码。
过去做某些事情很麻烦。例如,我决定添加一个枚举值,现在我必须处理所有与该枚举匹配的地方。在过去的世界里,这并不难,你只需让编译器告诉你问题所在,然后在所有出现的地方为新值添加一个小段代码来完成所需的功能。
但你必须小心操作,否则会引发更多编译/错误循环。诸如遗漏分号之类的细节会消耗一个循环,而旧工具只会告诉你错误存在,却不会帮你修复。
大语言模型(LLMs)会为你修复错误。现在,你只需告诉Claude更改循环中的所有代码,直到它能够编译为止。你可以让多个代理处理你的代码,修复许多地方的小问题,而你只需坐在HN上思考问题。或者,你可以花时间考虑代码需要朝哪个方向发展。
然而,最重要的是,当你不再被小编译错误所困扰时,你可以做更多的事情。我有一长串想要更改的代码库内容,而 Claude 完成了所有这些任务。这些任务与“这个系统做什么”这样的业务层面无关,而是许多以前需要初级员工花一整天时间才能完成的小任务。凭借快速更改大量代码的能力,我能够更快地开发架构。
这也涉及动力问题:当我只是在修复编译错误时会感到陷入泥潭,因此在进行传统编程时我会优先考虑如何分配时间。现在我可以直接完成整个清单,因为我不再是那个执行任务的人。
> 输入速度更快并不会让你更快达到目标,因为整体设计才是限制因素。
这是一个有趣的观点,与我的经验非常吻合。大语言模型(LLMs)在创建良好的设计方面表现非常糟糕。即使在微观层面上,我几乎总是让他们重构他们编写的函数。
在实际实施过程中,我的工作效率确实得到了提高,但实施方案已经在我脑海中或纸上完成了。要了解真正的改进程度非常困难。
我确实觉得它们对头脑风暴很有用。我可以向它们抛出一大堆代码和测试,询问可能需要考虑的边界情况,或我可能遗漏的内容。它们的建议中90%我都会跳过,但其中常有几条我会采纳。
让东西能用与创造能在中长期表现良好的东西是截然不同的两件事,我不确定它们能否在后者上有所提升。
真正的生产力提升不仅在于打字速度,还在于认知卸载——但我们必须小心,这不会削弱我们维护准确心理模型的能力,因为委托实现细节可能会让我们与系统的重要细节脱节。
> 我有一长串想要修改代码库的地方
我总是有一大堆想要改变我正在工作的代码库中的东西,而瓶颈在于审查,而不是我改变代码。
这些是一回事吧?你改变代码,但不能在不测试的情况下直接编辑它。
大语言模型(LLM)也可以帮助你测试。
代码审查不等于测试。测试几乎无法帮助你让程序正确运行,更无法让代码变得“优秀”。
几乎所有高质量的软件都是从更高的抽象层次设计而来的。几乎没有什么东西是通过不断修复错误堆砌而成的。
> 以前需要初级员工花一整天时间完成的许多小任务。
但这也是初级员工学习的地方。如果这些初级员工被机器取代,甚至不再被雇佣,谁来教他们?
企业多久会投资于员工培训?或许聪明的企业需要开始这样做,否则它们将面临崩溃。
本文开头提到的四步流程让我想起了德意志的《无限的开端》:
> 我们理论的真正来源是假设,而我们知识的真正来源是假设与批评的交替。
(这是对卡尔·波普尔观点的重新表述,而波普尔所追溯的智识传承可追溯至巴门尼德左右。)
我将编写测试视为对你所写代码的_批评_,而这段代码本身就是一种_假设_。两者都在试图接近你脑海中的一种解释,一种你认为自己正在纸上呈现的柏拉图式理念。代码是试图做到这一点的尝试,而测试则是从不同角度对你是否做到这一点的批评。
那段关于假设的引文让我想起《禅与摩托车维修艺术》中的一个重要观点。作者指出,“科学”/“科学方法”实际上并未涵盖思想/假设产生的过程,科学仅在假设出现后才发挥作用(假设从何而来?)。他将这种“魔法烟雾”称为“质量”。(用你引用的语言来说,我想我们是在问猜测本身是从哪里来的)。我现在意识到这与你的观点有些偏离,抱歉,但感谢你发表这个有趣的评论。
是的,我认为很多人很清楚,大语言模型(LLMs)还没有达到“为我打造一个狗版的 Facebook”的阶段。我在更具针对性的任务上取得了相对较好的成功,比如“添加一个执行此操作的模态,以现有模态作为代码风格的例子”。我还把问题分解成更小的部分,然后把它们一个一个地交给大语言模型(LLM)。这样似乎效果更好。
我已经可以复制粘贴现有代码并进行修改以实现我的需求(如果你认为这算“软件工程”的话)。区别在于我的系统剪贴板是确定性的,而非无限创意地发明新的出错方式。
我确实好奇像v0这样的系统会如何处理这个请求。
大概在2013年左右?我和一位同事正在更新一个系统,该系统用于扫描带有邮购订单的信件。工作人员会将信封中的物品按顺序放在传送带式扫描仪上。他们必须按顺序放置:订单表、付款支票、信封。系统会扫描每个文档,并在每个信封后添加两页空白假扫描页。设置该系统的公司按扫描页数收费。我们发现其实不需要用空白页作为分隔符,因为信封本身就能可靠地充当分隔符。顺便说一下,OCR识别效果太差,导致订单表格无法自动扫描,工作人员只能手动查看PDF文档并逐一输入内容。通过取消这些无意义的空白扫描页,我们为公司每年节省了超过$100万的成本。我们从未因此获得任何赞誉或表扬。人工智能能做到这一点吗?
> “当测试失败时,他们只能猜测是修复代码还是修复测试”
我有一个方法是使用“红-绿-重构”语言。我们处于红色阶段——测试应失败。我们处于绿色阶段——用最少的代码让测试通过。我们处于重构阶段——在不破坏测试的情况下改进代码。
这有助于大语言模型(LLM)理解 TDD 思维模式,而不是只看到需要修复的“损坏的代码”。
当然,但当你试图从红色阶段过渡到绿色阶段时,问题不就是… 。你仍然看到红色是因为测试有问题,还是因为代码尚未正常工作?
仅仅是因为大多数人工智能初创公司都做错了。
我不想有一个聊天窗口。
我希望人工智能工作流程成为我集成开发环境(IDE)的一部分,就像Visual Studio、IntelliJ、Android Studio最终所追求的那样。
我想要用我的母语进行语音控制操作。
项目中所有方面的知识,用于进行代码重构、带人工智能反馈循环的静态分析、根据手写草图生成 UI、使用手写进行移动编程、源代码控制提交代码更改信息等。
这些大语言模型(LLM)的讨论真的需要每个人都提到他们实际使用的是什么大语言模型。
> AI 编程太棒了![Opus 4]
> AI 编程糟糕透顶,搞砸了一切![4o]
这将澄清很多问题。人们似乎在评估最笨拙的模型(显然是因为他们不知道更好的选择?),然后决定整个 AI 技术根本行不通。
别指望会有所改进。
这种情况在与软件工程相关的许多话题中都会发生。
网页开发者在回复嵌入式开发者,嵌入式开发者在回复不写代码的架构师,架构师在回复有两年经验的人,有两年经验的人在回复谷歌的员工,谷歌的员工在回复一家拥有4个客户的中型德国B2B公司的员工。如此循环往复。
上下文总是被省略,我们都在讨论不同的事情,忽视了对话对象的日常现实。
我的经验是,人工智能爱好者总是会说:“你只是用了错误的模型。”而当现有模型都无法很好地工作时,他们又会说:“再过六个月就能用了。”代理编码在复杂项目中的实用性似乎是无法证伪的。
我使用过各种“最佳”模型,最终主要选择了 Opus 4 和 Sonnet 4 以及 Claude Code,但它们实际上并没有变得更好。Grok 3-4 和 GPT4 更差,但到了某个阶段,即使标准很低,你也不会因此而获得额外的积分。
人们实际上是基于4o来做出断言的。门槛真的很低,但人们仍然完全没有达到。
> AI在编码方面非常出色![高计算量框架围绕多个实例/未披露的IOI模型/AlphaEvolve]
> AI在编码方面非常出色![Gpt-5 Pro]
> AI在编码方面相当出色![“gpt-5” 搭配“高”详细程度和“高”努力程度]
> AI在编码方面相当不错![ChatGPT 5 通过Pro订阅搭配128 Juice进行思考]
> AI 在编码方面表现平平![ChatGPT 5 考虑订阅 Plus,Juice 为 64]
> AI 在编码方面表现糟糕![ChatGPT 5 自动路由]
文章所说的对于 Opus 4 和其他大语言模型(LLM)来说都是正确的。
> 这些关于大语言模型(LLM)的讨论真的需要大家说明自己到底在用哪个大语言模型。
他们需要说明的远不止这些:https://dmitriid.com/everything-around-llms-is-still-magical…
— 引用开始 —
我们知道大家在做什么项目吗?不知道。
我们知道大家在做什么代码库(全新、成熟、专有等)吗?不知道。
我们知道大家的专业水平吗?不知道。
他们的专业知识与他们应用大语言模型(LLMs)的领域、代码库、语言相同吗?我们不知道。
他们额外花费了多少时间进行审查、修复、部署、完成等工作?我们不知道。
— 结束引用 —
而这只是冰山一角。在我们撞上另一座冰山之前,这座冰山已经存在:我们正在试图盲目地逆向工程一个非确定性的黑盒子,而这个黑盒子又位于提供商的黑盒子内部
三个月前,我可能会同意这篇文章的大部分内容,然而……
在过去的一周里,我观看了Welch Labs关于深度网络如何工作的视频[1],这激发了一个想法。我花了一些时间使用Visual Studio Code的ChatGPT5预览版进行“氛围编码”,并让它生成一个Python框架,该框架可以接受一张图像,并教一个小型网络如何生成那张样本图像。
这个网络很简单……2个输入(x,y),3个输出(r,g,b),以及多个隐藏层,每个层都有指定数量的节点。
它是一个代理,它编写代码,测试代码,修复问题,而且基本上就是这样工作的。在探索图像生成的领域时,我让它随着时间推移添加选项,一切都正常运行。与以往的努力不同,我无需复制/粘贴错误消息来尝试找出问题所在。我惊喜地发现,代码几乎按照我的预期运行。
我遇到的唯一真正问题是让 .venv 正常运行,但这更像是一个安装问题,而不是大语言模型(LLMs) 的错误。
我必须说,我对Python的argparse库印象深刻。
令人惊叹的是,通过投入几天CPU时间,仅凭4个隐藏层的64个值和3个输出通道(RGB),就能提取出如此丰富的细节。我的目标是看看能用多小的网络生成我最喜欢的照片。
在迭代检查点时,我会让它输出当前参数对应的图像,并与原图进行对比。看着它如何折叠潜在空间以捕捉照片的主要特征,然后继续折叠以捕捉更小的细节,这一过程反复进行,随着时间推移,信噪比会非常缓慢地提升,这确实令人着迷。
至于ChatGPT5,也许我还没有用完上下文窗口,但目前看来,这一切都像是魔法。
[1] https://www.youtube.com/watch?v=qx7hirqgfuU
> 大语言模型(LLMs)会不断感到困惑:它们认为自己编写的代码确实有效;当测试失败时,它们只能猜测是修复代码还是测试;当感到沮丧时,它们只会删除所有内容,然后重新开始。
我个人对这句话深有同感。至少在心情不佳的日子,或敷衍了事时是这样。不确定这是否说明了什么关于AI的问题——或许只是“心理模型”部分确实很难。
这意味着某件事没有被理解。可能是产品、有问题的代码,或是计算机本身。我认为90%的程序员缺乏基础知识。我不是在针对任何人,但当你掌握了基础知识,通常能快速找到问题所在,或至少能推断出问题所在。
不幸的是,“通常”是这里的关键词。
所以大语言模型(LLMs)总是敷衍了事,在糟糕的日子里等等。太好了。
我最近尝试让人工智能重构一些测试,结果它把测试搞砸了。然后它反复尝试,直到通过率回到 75%。此时,它宣布胜利。是的,它真的像一个不想在那里的人。
事实证明,英语对于创建确定性软件来说非常糟糕。如果你是在进行氛围编码,那么你要么对大语言模型(LLMs)生成的随机性感到满意,要么进入一个循环来尝试生成确定性的输出,在这种情况下,使用编程语言可能会更容易一些。
这就是我无法理解AI编程爱好者的地方。他们本可以使用一种专门设计用于生成可执行代码的语言,却选择插入一个使用模糊不清语言的额外翻译阶段。这意味着你必须学习一个完全不适合任务的新界面,只为获得不确定的结果。如果你敢踏出主流中的主流,那里缺乏充足的训练数据,那可就倒霉了。
这是因为人工智能编码爱好者本来就不懂编程语言,所以无论怎样他们都要学习一种新的语言/界面。
此外,我发现他们的软件实际上并没有任何用户。
大语言模型(LLMs)还无法独立构建软件。当然,在某些帮助下,它们可以构建软件。
> 大语言模型(LLMs) 会不断感到困惑:它们认为自己编写的代码实际上可以正常运行;当测试失败时,它们会猜测是修复代码还是测试;当感到沮丧时,它们会直接删除所有内容,然后重新开始。
这其实是一个有趣的观点,我自己也多次注意到这一点。我发现大语言模型(LLMs)非常擅长应对测试失败,但除非测试失败的原因非常琐碎,否则通常表明应用程序的基本逻辑存在一些更根本的问题,而大语言模型似乎无法发现这些问题,这可能是因为它们没有关于系统应如何工作的全面心理模型。
我不想指责任何人,但我经常在大量使用大语言模型(LLMs)的同事的代码中看到这种情况。从表面上看,代码看起来没问题,他们编写的测试也通过了,但仔细思考一下,你会发现它并没有真正捕捉到要求的细微差别,从某种程度上来说,一个对系统运作有心理模型的人可能不会这样做……
有时,人类在编写代码时会忽略逻辑中的某些细节,但这些更像是行中的错误,而不是对问题的根本理解和建模失败。我知道情况并非如此,因为当你与这些开发人员交谈时,他们完全理解问题所在。
要了解代码何时需要修复或测试,你需要非常清楚地了解应该发生什么,而大语言模型(LLMs)却做不到这一点。我不知道为什么。也许只是因为他们没有阅读票证和技术讨论,所以缺少背景知识,或者是因为他们不确定应该发生什么时,没有提出问题。我不知道这是大语言模型(LLMs)的基本局限性(我个人认为不是),但这是当今使用大语言模型编写代码时遇到的问题,仅靠更多的计算可能无法解决。
标题有点耸人听闻,因为它们确实能在构建软件时提供帮助。
然而,我同意核心论点(即它们无法独立完成任务)。与之相关的是,“我们很快就能解决内存问题”的观点,最终会像“我们能在一个夏天解决视觉问题”一样,30年后虽然有所改进,但仍未彻底解决。内存问题确实很难。
我发布的 2 款 iOS 应用程序(中等复杂度,运行良好)却表明了相反的结果。我对 Cursor + o3 的功能感到非常震惊。
说大语言模型(LLMs) 不擅长 x 或 y,就相当于说没有身体的大脑是无用的。这是显而易见的。代理编码解决方案的成功不仅取决于模型,还取决于开发人员围绕模型构建的系统。在这个领域取得成功的企业将是那些专注于构建利用上述模型的复杂且功能强大的系统的企业。我们仍处于非常早期的阶段,大多数组织才刚刚开始接受这一认识……只有少数组织充分利用了这一概念,Claude 代码就是最好的例子。Claude 模型经过专门训练,能够调用工具和其他功能,而 Claude 代码 cli 则充分利用了这些功能,其中上下文管理等功能极为重要…
> 但我们坚信(至少目前而言),您才是主导者,大语言模型(LLM)只是另一种可利用的工具。
微软和GitHub也是如此。至少他们一直都是这么告诉我们的。哦,等等……我认为他们大约一周前改变了主意。
> …但有效工程师的区别在于他们能够构建和维护清晰的心理模型。
我怀疑这是否只是智力的替代指标?
我认为这里的论点是无稽之谈。大语言模型(LLMs)显然与人类认知的工作方式不同,因此指出大语言模型和人类处理问题的方式之间的差异,并称这是它们无法构建软件的“原因”,是毫无意义的。显然,有很多构建软件的方法对人类来说是毫无意义的。
不过,我同意这个结论。它们似乎缺乏对自己所做工作的连贯模型——这或许是它们在ARC等基准测试中表现不佳的原因之一,这些测试正是为了考察这种能力而设计的?
这篇帖子中60%的投诉可以通过提前提供更清晰的需求和上下文来解决
你不能只是堆砌更多上下文,它必须是对正确上下文的简要提炼。否则,随着上下文越来越长,每个要点被考虑的可能性就越低。更糟糕的是,它可能会被负面考虑。有时感觉就像在训练一只狗。你不能说“不要坐下”!
令人沮丧的是,承诺的未来最终变成了人类不得不按照机器的方式工作。
也许我们应该让它在文档的Markdown文件中构建一个心理模型?
我经常让它解释已实现的业务逻辑(而不是直接阅读代码),并根据此进行判断。
我想知道,通过删除大语言模型(LLM)中一些错误设置的上下文,是否可以解决部分问题。或者获得一个简短的摘要,对其进行重组,然后再次输入到新的LLM上下文中。
我怀疑上下文无法完全取代心理模型,因为上下文与LLM接收的所有输入处于同一频段。它只是一个线性令牌序列,被均匀地输入。其中结构太少,且所有内容在模型内部都可能被丢弃或扭曲。即使在迭代输入时,令牌序列的一部分保持不变(一个“稳定”的上下文),但其周围的输入在模型内部可能产生任意的下游影响,这使得它比心理模型更不可靠和不稳定。
好吧,我明白了。我只是在这里胡乱猜测,如果能够根据训练过的词组生成下一个最佳令牌的话。它能否在元层面上更上一层楼,进行生成?就像遗传编程一样。或者这是思维推理模型所做的吗?
也许我需要对大语言模型(LLMs)做更多的功课。
> 上下文遗漏:模型不擅长识别遗漏的上下文。
> 近期偏好:它们在上下文窗口中存在强烈的近期偏好。
> 幻觉:它们常会生成不应存在的细节。
公平地说,这些都是我合作过的绝大多数人类工程师(包括我自己在内!)在不同程度上都曾面临的挑战,即使我们并未以相同的方式来描述这些问题。我不知道其他人如何,但我确实有过这样的经历:在开发过程中很晚才发现设计中一个重要的细节被忽略了,忘记了几个月前学到的一个关键细节,而这个细节本可以让我更快地调试问题,或者不小心对某件事的工作原理做出假设(或记错了),结果导致代码出现 bug。在我职业生涯中,我大多收到了关于工作的积极反馈,所以如果我“无法构建软件”,我不得不担心那些多年来雇佣我并称赞我工作成果的公司和同事。不过,我认为“人类无法可靠地构建软件”这一说法可能基本正确,所以也许这里的教训是,软件开发本身就是一件困难的事情。
这是沟通问题。你应该学会如何提出正确的问题并记录给出的答案。我看到的情况是,开发人员在应该向团队成员寻求帮助时却自行假设。或者在不阅读文档的情况下尝试解决问题。或者试图记住信息而不是将其记录下来。
嗯,当然,如果你非常勤奋且从不犯错,确实有可能做到100%正确。但根据我的经验,即使是那些极度聪明、勤奋且善于提出正确问题、阅读文档的人,偶尔也会犯错,这就是我想要强调的重点。如果你真的从未遇到过这个问题,那我猜我合作过的人和你合作过的人可能都不如你和你的团队那么完美,但我认为,如果真是这样,那你可能没有经历过与普通人合作的平均水平。我们大多数人都是凡人,有时会犯错,虽然我们犯错的具体机制可能与文章中描述的问题并不完全相同,但我的观点是,差异可能只是程度上的问题,而非错误类型本身存在根本差异。
相信人工智能,总有一天它会做到我们想象中它能做到的事情!
它擅长微观层面,但不擅长宏观层面。我认为随着更智能的工程设计、更大的上下文窗口等技术的进步,这种情况最终会改变。不要低估工程师为了避免编写代码而会编写多少代码。
> 它擅长微观层面,但不擅长宏观层面。
我也有同样的发现。开始描述或编写一个函数时,包含整个文件作为上下文,它就能完成任务。但如果给它整个代码库,它就会在森林中漫无目的地游荡,消耗代币十多分钟试图解决依赖关系。
大语言模型(LLMs)是强大的助手——只要用户对问题保持坚定的心理模型。这就是为什么,就目前而言,它们是软件工程师的补充,而不是替代者(至少在今天是这样)。
当你已经确切知道需要构建什么,只是想跳过冗长的模板代码或重复性任务时,一个编码命令行界面(CLI)非常有用:它处理繁重的工作,让你能够专注于真正重要的(也是更有趣的)高层次设计和决策。
我认为大多数试图探讨这个话题的人并未将此标题与其他类似标题结合考虑,例如: “为什么大语言模型(LLMs)无法识别自己的循环”,或者“为什么大语言模型(LLMs)无法表达意图”,或者“为什么大语言模型(LLMs)无法识别真伪,或者它们所知道和不知道的自信程度”,这些其他标题基本上经过一点思考就相当于计算机科学的停顿问题,或者数学的不可判定性。
更进一步说,认识到这一点,就会发现投资于这种遥不可及的梦想(以确定性的方式克服这些固有的问题)是鲁莽的疏忽。
它们可以阅读和注意错误,然后找出最佳的解决方法。这是大语言模型(LLM)的最大优点。没有人能比大语言模型(LLM)做得更好。但它们并不是你的读心者。这就是问题所在。
我认为它们只是工具箱中的另一种工具,而不是新的工作坊。在开发软件时,你必须围绕大语言模型(LLM)的使用制定一个好的策略。我认为人们自然会注意到这一点并加以适应。
“(至少目前)你仍然掌握着主动权,大语言模型只是另一个可用的工具。”
模型性能的改进似乎正在接近峰值,而不是呈现指数级增长。我们最终会达到上述情况吗?
我是不是唯一一个对Opus 4在正确提示下实际构建心理模型的能力感到惊讶的人?
我发现Sonnet经常偏离主题,但Opus通常能处理(只要提示足够清晰)。
嗯,欢迎加入觉醒俱乐部 🙂
觉醒就是我们需要的。 😉
我决定跳入深水区,使用 Cursor 的默认 AI 设置完成两个项目。
第一个项目是一个 C++ 嵌入式设备。第二个项目是一个基于 Django 的复杂硬件设备 UI 前端(因此,python 与硬件交互,各种 JS 库处理大部分前端)。
到目前为止,我对 Django 项目的了解比 C++ 嵌入式项目更深入。
这很有意思。
我已经手动编写了一个概念性的 UI 版本,只是为了尝试 UI 和交互的想法。我将这个版本以及整个项目的详细规格(包括目录结构、库、在哪里使用什么以及为什么使用等)交给了 Cursor。换句话说,这正是如果我将该项目外包给承包商或公司时会提供的内容。我还指示其基于我临时项目目录中放置的手动编写版本,先尝试实现前端部分。
随后我效仿让-吕克·皮卡德(Jean-Luc Picard)的风格,下令“启动!”。
第一次迭代只花了幾分鐘。令人驚訝的是,它竟然如此功能齊全且完整。然而,當然,它也有問題。例如,它未能將各種介面分離成獨立的 Django 應用程式。它未能將那個龐大而漂亮的 CSS 和 JS 檔案分離成獨立的應用程式專屬 CSS 和 JS 檔案。總之,它無視了關注點分離的原則,只是讓一切都能正常運作。這正是你可能會從初級程式設計師或應屆畢業生那裡看到的情況。
实现关注点的分离和其他不良的代码交叉影响需要付出一些努力。大语言模型(LLM)并不真正理解。它们非常擅长模拟理解,但归根结底,我认为我们还没有达到这个程度。它们往往会陷入困境,犯下愚蠢的错误。
要获得接近发布候选版本的东西,需要将手动编辑和代码库的“塑造”与针对 Cursor 的简短、精确且范围有限的指令进行有趣的组合。就我的工作流程而言,我发现限制 AI 的任务范围可以获得更好的结果。范围太广,可能会带来不可预测和令人沮丧的结果。
说到令人沮丧的事情,它时不时会做的一些最令人头疼的事情也在一个范围内,介于完全破坏先前工作或有选择地消除或修改以前正常工作的功能之间。这就是为什么对我来说,限制范围是一个更好的选择。如果我告诉它在应用程序A中做某事,那么它不太可能去破坏或损害在应用程序B中完成的工作。
这个问题意味着在这种工作流程中,测试变得至关重要,因为在每次迭代中,你都不知道哪些功能可能已被修改或损坏。它还会发疯并做一些你从未要求它做的事情。例如,我正在重新设计其中一个应用程序的用户界面。出于某种原因,它决定更改另一个应用程序的用户界面,移除所有控件并用它认为合适或相关的控件替换(实际上完全不相关)。而且,不,我没有要求它触碰我们正在处理的应用程序以外的任何内容。
注:对于不熟悉 Django 的读者,可以将应用程序视为一个具有相对独立功能的页面。应用程序(页面)可以通过多种方式共享数据,但总体而言,它们被设计为独立的单元,可以从一个项目中提取并插入到另一个项目中(理论上)。
我还在做另一件事,就是同时使用 ChatGPT 和 Cursor。在 Cursor 运行时,我使用浏览器上的 ChatGPT 来规划下一步,评估选项(库、实现等),甚至创建快速独立的单文件 HTML 测试,无需插入 Django 项目即可运行,以测试想法。我非常喜欢这种做法。对我来说效果很好。它让我可以在 OpenAI 项目的背景下探索想法和选项,并测试各种东西,而不会让 Cursor 感到困惑。我一直在尝试将 Cursor 限制为一个程序员,而不是进行长时间的探索性对话。
根据这次经验,我非常清楚地意识到:如果你不知道自己在做什么,你就完蛋了。虽然OpenAI的演示中,他们让v5开发了一个法语教学应用程序,这很酷也很棒,但我无法想象那些不懂编程的人能产出值得押上全部家当的东西。代码可以很出色,也可以很糟糕。它可以设计得很好,也可以是让你在软件工程课程的期末考试中不及格的东西。它变化多端,你必须亲自动手,理解并手动编辑代码,这是整个过程的一部分。
总体而言,我喜欢我所看到的。任何在 Django 中做过非平凡项目的人都知道,有很多繁琐的模板打字工作,这简直是令人头疼。有了 Cursor,这些工作就消失了,你可以专注于真正有价值的地方:你正在尝试解决的问题。
我下周将投入嵌入式C++项目。我已经做了一些,但下周我会全身心投入。期待新的发现。
另一个现实很简单:这已经是最糟糕的情况了。而它已经相当不错了。
精彩、简洁的文章。没什么重要补充,除了AI的“蛇油推销员”会继续大肆传播夸大其词的言论,至少我们这些真正从事这一行的人对事实有共识。
我对当今的“AI”概念并不感冒,但公平地说,开发当今的软件绝非易事,很少有人能在第一次尝试就做对。
多年前我就放弃了编译这些大型应用程序。我通过FreeBSD的(v8.x)端口系统编译了Firefox,光是这一点就已是一场噩梦。
我无法想象编译GNOME3、KDE或LibreOffice会是怎样的场景。目前我编译的最大软件是Emacs。
我建议尝试使用Nix,通过可重复性,那些令人头疼的编译问题将一劳永逸地解决。(通常由他人解决)
Nix的问题在于,它常被宣称具有可重复性,但由于存在碰撞,这种说法缺乏实际依据。可重复性的定义被置于如此孤立的语境中,几乎显得荒谬。
尽管目前尚未在Nix的SHA256包中发现碰撞,但根据鸽巢原理,碰撞是存在的。在这种碰撞情况下,计算机无法在两个包之间做出选择,导致系统级故障,且错误与原因无关(由于涉及的属性以及计算领域长期存在的计算机科学问题)。
这些问题本质上包含数学混沌的特性,即一种内在不可知/不可预测的状态,任何管理员都不会触碰或处理,因为其不可维护。原本紧密耦合的错误处理代码不再紧密耦合,因为它需要匹配一个可确定的状态(计算机科学计算问题,如停机/可判定性)。
非确定性故障域是最难解决的问题,因为基于确定性属性的故障排查方法在此无效。
这迫使你只能采用猜测与验证的策略,而这需要对整个系统栈有深入了解,且不存在抽象层。
尊敬地讲,你听起来像人工智能。我猜你也不信任Git,尤其是其哈希强度较弱。
粗略查看一个Nix系统会发现,包名、版本和衍生SHA都连接在一起。
尊敬地讲,我听起来像个计算机工程师,因为我与许多这样的工程师合作过,而我合作过的工程师也持有这种观点。
> 粗略查看一个 Nix 系统会显示 … <三个字符串拼接在一起>
这并不否定或反驳抽屉原理。遵循抽屉原理,存在碰撞的可能性,且随着迭代次数(时间)增加,该概率趋近于 1。
你唯一的论点是关于可能性和概率的衡量,这是一种街灯效应认知偏见或智力陷阱。YouTube上有一个视频,由前中情局官员在TED上讨论了此类陷阱。
可能性和概率受到它们所衡量的先验概率的强烈影响,而没有完美知识(今天没有人拥有),这些先验概率可能会有显著偏差,或无法确定。
假设一种通用方法被发现并发布,该方法可快速预测碰撞,无论采用何种算法;鉴于当前量子计算的进展,这种情况可能并不遥远。
所有投入Nix的时间和资金将变得浪费,你将突然陷入完全被动的位置,且无法以可比成本进行合理调整(此前已投入)。
坦率地说,如果你无法区分基本的事先推理逻辑与人工智能,我将质疑你的感知能力及其是否正在退化。越来越多的证据表明,接触人工智能可能导致这种退化,这在医生使用人工智能进行诊断的研究中已开始显现(1)。
1: https://time.com/7309274/ai-lancet-study-artificial-intellig…
相反,Kiro(https://kiro.dev)展示了通过将软件工程分解为多个阶段(需求、设计和任务),然后将任务进一步分解为离散子任务,即可实现这一目标。每个子任务均可根据需求进行定制和优化。它甚至能为三个阶段生成初始文档。
目前仍处于早期阶段,但我们正在学习:与完全由人类编写的软件一样,规格越具体,结果越可能符合预期。
通过1分钟的网络搜索,我发现您是亚马逊的市场经理。因此您的观点存在利益冲突,这应予以披露。
公平地说,我为未披露这一点道歉。然而,Kiro 并非我负责的服务范围,这是我个人观点,而非公司立场。
这并非利益冲突。我有权批评自己的公司。
关于人工智能的讨论中充斥着大量虚假评论。尤其是在Reddit上。
这是一篇信息密度较低的博客文章。我非常喜欢 Zed 过去的博客文章(尤其是关于编辑器内部结构的!),希望我的话不会被误解,但这似乎只是对许多人通过使用大语言模型(LLM)代理而得出的经验性发现的松散重述。
或许对刚开始接触这些计算对象的人来说还算有用,但并未以清晰的方式解决或解释问题,也未突出研究和工程领域中可能指向未来发展方向的趋势。
你还有一个技术写作的禁忌,即引用一项相当精确和具体的研究时,用一段改写的内容来支持你的论点……这类似于说“哥德尔不完备定理意味着_某种东西_关于意识的本质”。
类似于“不幸的是,目前它们无法(在一定复杂性以上)真正理解正在发生的事情”这样的表述,引用了精确的研究……这种表述含糊不清且技术写作质量低下——作者在这里究竟想表达什么?这太模糊了。
我认为这里的情况更糟,因为_原研究_提供了任务特定的复杂性概念(对原研究的批评!不同的表示方式难道不会导致不同的复杂性扩展行为吗?当然会!这就是软件工程的本质:我需要在不同层次上思考以控制对复杂性的暴露)