返回资讯中心
外部精选
软件工程
#开发者实时流

OpenAI称1万个AI智能体发现纳维-斯托克斯方程解析解

来源标题:Tiny Pickles: Why are AI companies investing so much in math proofs?

OpenAI于2026年9月8日宣布,1万个运行GPT-6 Astra及一款未发布模型的AI智能体花费数百万美元,针对纳维-斯托克斯方程的一个具体问题找到了解析解。该问题源自千禧年大奖难题,OpenAI给出的答案指出方程在特定极端情形下会出现有限时间爆破。有流体工程专家认为这一答案实际意义有限。

Hacker News 最新spelkington2026/11/4 · 2 天前30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

2026年9月8日,OpenAI宣布,一支由10,000个AI agent组成的集群——运行GPT-6 Astra以及一个(截至目前)尚未发布的模型,耗资数百万美元——发现了关于Navier-Stokes方程一个非常具体问题的解析解。用我能理解的最前沿的表述来说,这个问题是:

转述 “为了模拟流体在系统中的运动方式,我们使用一组方程来近似其行为。这些模型相当不错,但我们的近似有可能给出古怪的结果。 ——Clay Mathematics Institute,千禧年大奖难题(2000年)

OpenAI对这个问题的回答——同样用我能理解的最前沿的表述来说——是:

转述 “是的。在非常古怪的情境下,它确实会给出古怪的结果。” ——OpenAI,Finite Time Blowup for Navier-Stokes(2026年)

我的一些朋友——两位专攻流体力学的工程师,而且对此类事情“极为热衷™”——告诉我,这个答案其实并没有多大意义。9月9日早晨的世界,在物理上几乎和之前一模一样。他们照常醒来,去上班(通常是在航空或国防领域),继续使用前一天就在用的那些流体动力学模拟。

飞机没有从天上掉下来。导弹想必依然会爆炸。我的淋浴器出水了!流体的行为似乎一如既往。

我的另一些朋友——专攻证明的数学家,同样“极为热衷™”此类事情——他们的反应是(再次转述):

9月9日早晨,一切感觉都不同了。对他们中的许多人来说,仿佛一股地震般的力量撼动了宇宙的根基。

人类对于知识的追求还有必要吗?

他们是不是把青春投入了一门已死的技艺?

9月9日早晨,我和同事们以一种反讽式的冗长,讨论了非常小的酸黄瓜的本质。

2024年12月2日,维基百科贡献者TrulyShruti对“Pickled cucumber”维基百科页面做了如下修改:

  • Gherkins,即baby pickles,是小黄瓜,通常长3到
  • 13 cm(1到5 in),表皮往往凹凸不平,通常
  • 用于腌制。
  • Gherkins是小黄瓜,通常长3到13 cm(1到5 in),
  • 表皮往往凹凸不平,通常用于腌制。

(维基百科上关于gherkin的编辑大多集中在它们算不算“baby pickles”上。为本文之目的,我将采用截至2026年9月9日的定义,并假定它们不是baby pickles——只是非常小的酸黄瓜而已。)

1 我死活不明白软件开发者为什么这样命名东西,也不知道他们从哪儿学来的。我也永远不会原谅Kubernetes团队,无论是这个名字本身,还是k8s这个缩写。

Gherkin也是行为驱动开发软件测试库Cucumber所使用的一个术语1。

任何做过专业软件开发的人都知道,而且深有体会:其实没人真正知道自己想要什么。正如Peter Naur在1985年的文章《Programming as Theory Building》中所论述的,构建软件的很大一部分工作,是把一个存在于某人头脑中的想法——也许是你的,也许是别人的——转化为计算机能理解的指令。

与判断Navier-Stokes在三维空间中是否只有光滑输出不同,一致地描述你头脑中的想法,是一个真正尚未解决的问题。

在(好的)软件中,相当一部分精力花在编写测试上。测试是小的、额外的代码片段,它们运行你的代码,并验证代码做了你想要它做的事。这是一种确保你不会意外引入bug、或改变你所构建之物的重要行为的方式。

例如:如果你想确保你正在构建的日历应用不会为月份给出奇怪的数字,你可能会写这样的东西:

def is_month_a_valid_number(month): ''' Asserts that the number for a month is between 1 (January) and 12 (December) ''' assert((month >= 1) and (month <= 12))

2 这些示例直接取自Cucumber文档,那是我读过的最有帮助的文档之一。

Cucumber是一种哲学,也是一个代码库,用于编写更好的测试。让我们看看一个非常有条理的项目经理或产品工程师,在关于产品应该能做什么的会议上可能会写下的那种笔记2:

Feature: Guess the word Scenario: Maker starts a game When the Maker starts a game Then the Maker waits for a Breaker to join Scenario: Breaker joins a game Given the Maker has started a game with the word "silky" When the Breaker joins the Maker's game Then the Breaker must guess a word with 5 characters

这些笔记不错,很有条理!缩进用得恰到好处,把属于同一组的概念归在一起,每一行都有清晰的标签。结构上有规律可循,但又足够简单,你完全可以在产品负责人反复推敲未来六个月你要构建的东西应该是什么样的时候,随手把它写下来。

但可惜;你上当了!这些不只是笔记!它们是代码!

Feature: Guess the word

The first example has two steps

Scenario: Maker starts a game When the Maker starts a game Then the Maker waits for a Breaker to join

The second example has three steps

Scenario: Breaker joins a game Given the Maker has started a game with the word "silky" When the Breaker joins the Maker's game Then the Breaker must guess a word with 5 characters

这就是Cucumber的Gherkin语言。它是一种结构化却又非常自然的编写测试的方式。使用Gherkin之类东西的希望在于,为软件编写测试不再被编码能力所限制。只要你愿意遵守几条规则,几乎任何人都能为你的软件阅读或编写测试。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →