拆解OpenAI Astra：用API与Python验证AI数学推理的真实边界

最近刷到一条话题：OpenAI Astra 用 2000 美元拿下 10 道世纪难题，评论区甚至有人在讨论“数学家的定义是不是要被改写了”。作为技术博主，我第一反应不是去转发这个结论，而是想拆成几个工程问题来验证：这个实验到底怎么做的？用的什么 API？代码长什么样？AI 是在“证明难题”，还是在“理解并验证难题”？如果你也关心这些问题，那这篇文章应该对你有帮助。

我不会站在标题党的立场上争论“数学家会不会失业”，而是把Astra 当作一个实验代号，围绕 OpenAI API 搭一套可运行的数学推理实验环境，用 10 道经典数学题做一轮压力测试，然后讨论 AI 在数学研究中的真实边界。读完本文，你会掌握 API 接入、提示词设计、批处理脚本、结果审查这些完整链路，也能自己动手把类似实验跑起来。

1. 从一条话题说起：先把标题翻译成工程问题

1.1 这个话题的真正关注点是什么

标题里的“2000 美元”和“10 道世纪难题”很容易被解读成某种科研突破。但如果你做过 AI 应用开发，会知道这类标题省略了太多关键细节。真正值得拆解的是三点：

• 调用方式：实验用的是哪类模型接口，是对话补全、代码执行，还是结合了外部工具？
• 问题构造：10 道题是怎么输入的，提示词有没有给模型额外信息？
• 结果验证：输出是一段文字，还是有可执行的 Python 代码？有没有人类或程序去做最终校验？

这三点才是技术文章应该回答的问题。传播学上的“炸裂标题”很吸引眼球，但工程上能复现、能解释、能评估，才有实际参考价值。

1.2 为什么选择 OpenAI API 来做这个实验

OpenAI API 是目前接入成本比较低的通用大模型接口，主要优势有四个：

1. 官方提供 Python SDK，代码量很小，几分钟就能跑通。
2. 不仅有对话能力，还能生成结构化输出，适合让模型同时输出“思路”和“验证代码”。
3. 支持流式返回、温度调节、多轮上下文，适合做对比实验。
4. 按量计费，可以精确控制单次实验的 token 消耗，适合做小规模数学实验。

如果你关注最近搜索比较多的关键词，会发现openai、openai api key、github.com/openai/codex、harness等词频繁出现。这些词放在一起其实指向同一个趋势：AI 的能力边界开始被系统化测试。所谓 harness，本质是给模型搭一个可验证的运行环境，这和本文要做的“用代码验证数学答案”是同一思路。

1.3 需要提醒的边界

先说一句重要的话：AI 能“回答”一道数学题，不等于 AI “证明”了一个数学定理。数学证明要求完整、严格、可形式化的逻辑链条，而大模型本质是概率模型，擅长模式匹配和启发性推理，但可能产生“幻觉”。所以本文的实验目标不是“证明世纪难题”，而是让 AI 辅助我们理解问题、生成验证思路、编写小规模穷举代码。这个边界必须在动手之前建立起来，否则后续所有结果都会被误读。

2. 概念梳理：世纪难题、AI 推理与实验边界

2.1 什么是“世纪难题”

“世纪难题”在数学圈通常指两类问题：一类是长期未被解决、悬赏很高的问题；另一类是曾经极难被证明、最终被攻克的著名问题。我梳理几个常见例子，方便后面设计实验：

这些“世纪难题”里，有些已经成了历史传说，有些仍然悬而未决。无论哪种，都适合用来测试大模型的能力边界。

2.2 AI 数学推理能做到什么程度

基于目前大模型的能力，AI 在数学任务上的表现可以分成四档：

• 问题理解：能把“用通俗语言解释黎曼猜想”这类问题讲清楚，而且多数情况下准确率很高。
• 启发式推导：能给出“可以先从枚举小数字开始”这类合理思路，但它自己不一定知道证明路径是否完整。
• 代码生成：能写出素数判断、枚举、回溯、模拟等 Python 代码，这是实际价值最高的部分。
• 严格证明：目前仍不可靠。大模型不会系统性地构造反证法、归纳法并保证所有逻辑分支完备。

所以本文的实验设计重点是：让 AI 回答问题，同时让 AI 生成可运行的验证代码，再由人去执行和判断代码输出。这样既发挥了大模型的优势，也避开了它最不擅长的“假装证明”问题。

2.3 实验与“证明”的区别

一个经典误区是：程序验证了一万个小例子，就说明命题为真。数学上这叫“经验归纳”，不是“证明”。

例如哥德巴赫猜想，你可以写代码验证 4 到 1000000 之间所有偶数都能拆成两个素数之和，但这不能证明“所有大于 2 的偶数”都成立。因为偶数有无穷多个，程序只能覆盖有限区间。AI 生成的代码再漂亮、跑出的数据再多，也只是一个“有限验证”，不能等价于“定理成立”。

这个认识很重要，它决定了我们怎么看待 AI 的输出结果，也决定了“数学家的定义是否被改写”这个问题的答案方向。

3. 环境准备：API Key、Python 与依赖安装

3.1 注册并获取 API Key

要调用 OpenAI API，第一步是注册账号并创建 API Key。具体流程需要到 OpenAI 官网操作，过程比较简单，但有三点必须强调：

1. 遵守平台条款：注册、付费、调用都要按照官方条款进行，不要通过非正规渠道获取账号或 Key。
2. 不要硬编码 Key：很多新手把 Key 直接写进代码，然后传到 GitHub，导致 Key 泄露。正确做法是放到环境变量或本地.env文件中。
3. 开启用量限制：API 是按量计费的，建议在账号后台设置月度预算或单次调用限额，避免因为脚本失控产生意外费用。

获取 Key 后，先保存在安全的地方，后面会在环境变量里使用。

3.2 安装 Python 与 OpenAI SDK

本文示例使用 Python 3.8 及其以上版本，版本需根据你的项目实际情况调整。安装依赖的命令如下：

pip install openai python-dotenv

• openai是官方 Python SDK，用于调用 OpenAI API。
• python-dotenv用于读取.env文件中的环境变量。

如果你没有安装 Python，请先到 Python 官网下载安装包，并把python和pip加入系统 PATH。Windows 用户安装时勾选“Add Python to PATH”可避免后续命令找不到的问题。

3.3 配置 .env 文件

在项目根目录创建.env文件，内容如下：

# .env OPENAI_API_KEY=sk-你的key

这里的sk-你的key替换成你自己的 API Key。接下来，在.gitignore中加入.env，避免密钥被提交到代码仓库：

.gitignore .env __pycache__/

配置完成后，可以用下面这段代码验证环境是否正常：

# 文件路径：check_env.py import os from dotenv import load_dotenv load_dotenv() api_key = os.getenv("OPENAI_API_KEY") if api_key: print("API Key 已加载，长度：", len(api_key)) else: print("API Key 未找到，请检查 .env 文件")

如果输出API Key 已加载，说明环境准备完成。

4. 第一个可运行的数学实验脚本

4.1 基础请求函数

先写一个最简单的函数，用于向大模型提问。项目文件建议命名为math_ai_experiment.py：

# 文件路径：math_ai_experiment.py import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) def ask_math_problem(problem, model="gpt-4o-mini", temperature=0.2): """向大模型提问，返回回答文本""" response = client.chat.completions.create( model=model, messages=[ { "role": "system", "content": "你是一名数学研究助手，回答要严谨、可验证，区分事实与推测。", }, {"role": "user", "content": problem}, ], temperature=temperature, ) return response.choices[0].message.content

这段代码有四个关键点：

• model参数指定模型，示例中使用gpt-4o-mini，具体模型名称以你账号实际可用的模型为准，不要写死。
• messages里包含系统提示词和用户提问，系统提示词用来约束回答风格。
• temperature=0.2表示偏向确定性输出。数学任务建议用较低温度，减少随机发散。
• 返回结果通过response.choices[0].message.content取出文本。

4.2 流式输出与稳定性控制

如果问题比较大，流式输出可以提升体验，让用户看到模型“思考”的过程。代码如下：

def ask_math_problem_stream(problem, model="gpt-4o-mini"): """流式输出版本""" stream = client.chat.completions.create( model=model, messages=[ {"role": "user", "content": problem}, ], stream=True, ) parts = [] for chunk in stream: delta = chunk.choices[0].delta if delta and delta.content: parts.append(delta.content) print(delta.content, end="", flush=True) print() return "".join(parts)

流式版本适合演示，批量实验时更适合用非流式版本，因为要控制请求频率并把结果写入文件。

4.3 批量任务框架：10 道题的工程化

真正要做实验，不能一道题一道题手动复制，而是需要一个批量任务框架。核心流程是：

1. 定义题目列表，每道题包含 id、标题和提示词。
2. 遍历题目，逐个调用 API。
3. 每次请求之间加一点延迟，避免触发限流。
4. 把结果保存为 JSON 文件，方便后续人工复核。

批量框架的代码会在下一节完整给出。这里可以先理解思想：每次请求之间加上time.sleep(delay)，把结果写入结构化文件，是工程化实验的基本盘。

5. 实战：用 10 道经典题做一轮压力测试

5.1 题目清单与设计原则

下面这 10 道题涵盖了“验证型”“解释型”“搜索型”三类任务，适合观察 AI 在不同类型数学问题上的表现。

设计原则是：不要用“请证明黎曼猜想”这种不可能完成的问题，而是用“请解释”“请用代码验证小范围”这类可执行、可复核的问题。这样 AI 的输出质量才能被评估。

5.2 完整批处理代码

将下面代码保存为math_ai_experiment.py，可以直接运行：

# 文件路径：math_ai_experiment.py import json import os import time from pathlib import Path from dotenv import load_dotenv from openai import OpenAI load_dotenv() client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) PROBLEMS = [ { "id": "goldbach_small", "title": "哥德巴赫猜想的小范围验证", "prompt": "请用 Python 检查 4 到 1000 之间所有偶数能否表示为两个素数之和。如果所有偶数都能表示，请输出结论；如果有反例，请输出反例。", }, { "id": "twin_prime_small", "title": "孪生素数猜想的小范围探索", "prompt": "请用 Python 找出 1 到 10000 之间所有孪生素数对 (p, p+2)，其中 p 和 p+2 都是素数，并统计总共有多少对。", }, { "id": "fermat_n3", "title": "费马大定理 n=3 的特例验证", "prompt": "请用 Python 在 a、b、c 都小于 100 的正整数范围内，验证是否存在 a^3 + b^3 = c^3。如果不存在，输出结论。", }, { "id": "four_color_explain", "title": "四色定理的背景与证明难点", "prompt": "请解释四色定理的含义，并说明它为什么在数学史上有重要地位。", }, { "id": "riemann_explain", "title": "黎曼猜想的通俗表述", "prompt": "请用通俗语言解释黎曼猜想是什么，以及它为什么重要。", }, { "id": "pnp_explain", "title": "P vs NP 问题的基本定义", "prompt": "请解释 P 和 NP 的直观含义，以及 P vs NP 问题为什么困难。", }, { "id": "collatz_simulation", "title": "科拉兹猜想的小规模模拟", "prompt": "请用 Python 模拟科拉兹猜想：对 1 到 100 之间的每个数字，如果它是奇数则计算 3n+1，偶数则计算 n/2，输出每个数字到达 1 所需的步数。", }, { "id": "perfect_cuboid_search", "title": "完美立方体问题的初步搜索", "prompt": "请用 Python 搜索边长小于 50 的整数立方体，检查是否存在长宽高、面对角线、体对角线都是整数的情况。如果没有找到，说明搜索结论。", }, { "id": "graph_coloring", "title": "地图着色问题与约束求解", "prompt": "请用 Python 写一个回溯算法，对下面邻接表表示的地图进行四色染色，并输出染色结果：A-B, A-C, B-C, B-D, C-D。", }, { "id": "millennium_problems", "title": "千禧年大奖难题列表", "prompt": "请列出 Clay 数学研究所的千禧年大奖难题，并给出每个问题当前的状态。", }, ] def ask_math_problem(problem, model="gpt-4o-mini", temperature=0.2): """向大模型提问，返回回答文本""" response = client.chat.completions.create( model=model, messages=[ { "role": "system", "content": "你是一名数学研究助手，回答要严谨、可验证，区分事实与推测。", }, {"role": "user", "content": problem}, ], temperature=temperature, ) return response.choices[0].message.content def run_experiment(results_file="results.json", delay=1.0): """批量运行所有数学题目""" results = [] for item in PROBLEMS: print(f"正在处理: {item['title']}") try: answer = ask_math_problem(item["prompt"]) results.append( { "id": item["id"], "title": item["title"], "prompt": item["prompt"], "answer": answer, } ) except Exception as e: results.append( { "id": item["id"], "title": item["title"], "prompt": item["prompt"], "error": str(e), } ) time.sleep(delay) Path(results_file).write_text( json.dumps(results, ensure_ascii=False, indent=2), encoding="utf-8" ) print(f"实验完成，结果已保存到 {results_file}") if __name__ == "__main__": run_experiment()

这段代码的运行逻辑很直白：

• PROBLEMS列表统一管理题目。
• run_experiment遍历列表，逐题调用ask_math_problem。
• 每次调用后保存到内存，最后统一写入results.json。
• 如果有单题报错，不会中断整个实验，而是把错误信息记录到结果中。

5.3 你应该重点观察什么

跑完实验后，不要急着下结论，而是从一个工程师的角度审查结果。建议重点观察四个维度：

1. 代码是否真的可运行：AI 生成的 Python 代码能否直接执行？有没有缩进错误、变量未定义、无限循环？
2. 结论是否被代码支持：比如哥德巴赫猜想验证，如果代码只检查了偶数，没有正确判断素数，那输出的结论就是无效的。
3. 解释类回答是否准确：四色定理、黎曼猜想、P vs NP 这类概念题，AI 是否用词准确，有没有把“已证明”和“未证明”混淆？
4. 搜索类任务是否完整：千禧年大奖难题列表有没有遗漏？完美立方体搜索是否设定了合理的边界？

你可以写一个简单脚本，把results.json中的内容打印成便于阅读的格式：

# 文件路径：print_results.py import json from pathlib import Path data = json.loads(Path("results.json").read_text(encoding="utf-8")) for item in data: print(f"## {item['title']}") if "answer" in item: print(item["answer"][:800]) else: print("ERROR:", item.get("error")) print("\n" + "-" * 60)

这个脚本的价值在于：把 AI 的输出转化为可人工复核的清单。实际项目中，你不需要相信模型的“自我评价”，而是要相信代码执行结果和人类专家的判断。

6. 如果 AI 真能“拿下一道难题”，意味着什么

6.1 从四色定理看计算机与数学的关系

很多人担心 AI 改写数学家的定义，但历史上已经发生过类似的事。1976 年，四色定理成为第一个被计算机辅助证明的主要数学定理。这个证明引来大量争议，因为人类无法逐行检查机器生成的巨大证明分支，只能信任程序逻辑。后来，数学家又用交互式证明系统进一步验证，才让学界接受。

这段历史说明：计算机深度参与数学研究早就不是新鲜事。AI 只是把“计算参与”提升到了“推理参与”，但人类仍然需要定义问题、设计验证方案、判断证明是否合理。

6.2 为什么“答题”不等于“证明”

假设你让 AI 验证了哥德巴赫猜想在 4 到 1000 之间成立，这确实是一道“题”的回答。但哥德巴赫猜想仍然没有在数学上被证明，因为无穷集合不能用有限枚举覆盖。

“答题”和“证明”之间隔着一条巨大的鸿沟：

• “答题”只要求给出一个可接受的答案。
• “证明”要求给出一个对所有情况都成立的严格逻辑推理。
• “验证”只是证明过程中很小的一环。

所以，即使 AI 在 10 道题上表现出色，更准确的说法也是：“AI 在理解问题、生成验证代码、解释历史背景上表现不错”，而不是“AI 拿下了 10 道世纪难题”。

6.3 数学家定义会被改写吗

我的判断是：不会立刻改写，但数学家的工作方式会变化。

未来研究数学的人可能要掌握两套技能：一是传统数学思维，二是跟 AI 协作的能力。AI 可以快速生成大量候选思路、代码、反例搜索程序，人类负责判断方向、设计关键实验、审查最终证明。这种模式更像是“数学家的副驾驶”，而不是“数学家的替代者”。

当工具足够强大时，人们对“数学家”的定义会扩展，就像今天不会有人因为程序员用编译器就认为程序员不是程序员一样。定义在演化，但核心的严谨性、创造力、审美仍然属于人类。

7. 常见报错与排查思路

实际运行脚本时，你大概率会遇到一些报错。这里整理成表格，方便快速定位：

排查这类问题的通用思路是：先看错误码，再查账号状态，最后检查代码参数。

另外，批量任务建议保存中间结果。一旦中途断网或触发限流，已经跑完的结果不会丢失，可以从断点继续，而不是从头再花钱跑一遍。

8. 工程化与安全最佳实践

8.1 成本控制

标题里的“2000 美元”不管是不是真实成本，都提醒了我们：API 实验不是免费的。控制成本可以从四个角度入手：

1. 裁剪 prompt，把问题写精炼，减少输入 token。
2. 设置max_tokens，控制输出长度。
3. 对相同问题用缓存结果，避免重复计费。
4. 后台设置预算上限，防止脚本异常导致超支。

科学实验讲究可复现，成本控制则是可复现的前提，否则后续想要重新跑一轮实验会变得很贵。

8.2 测试与结果可复现

要让实验结果可信，建议做三件事：

• 多次采样：同一个问题可以跑 3 到 5 次，观察回答是否稳定。
• 记录参数：把模型名称、temperature、prompt 原文都保存到结果文件，方便回溯。
• 人工复核：对解释型问题，找可信任的教科书或权威资料核对；对代码型问题，直接运行代码看结果。

AI 输出存在随机性，不要跑一次就得出结论。

8.3 提示词设计

提示词设计直接决定回答质量。建议在系统提示词中强调这几点：

• “区分已知事实和推测。”
• “如果编写代码，请保证代码是可运行的。”
• “如果不是确定结论，请说明前提和限制。”

这些约束能明显减少“一本正经地胡说八道”情况。

8.4 安全与合规

最后强调安全合规。调用任何外部 API 时都要记住：

• API Key 是敏感凭证，绝不要提交到公开代码仓库。
• 不要向 API 发送个人隐私、商业秘密等敏感信息。
• 遵守平台使用条款和相关法律法规。
• 生产环境使用前，先在小范围测试环境验证。

这些规范不只是为了避免违规，更是为了让实验具备长期维护和扩展的基础。

9. 总结：比起争论，先跑一轮实验

回过头来看，标题里的“Astra 用 2000 美元拿下 10 道世纪难题”更像是一个传播事件，而不是一个严谨的科研成果。但传播事件也有价值，它让更多人开始思考 AI 与数学研究的关系。与其在评论区争论“数学家的定义是不是被改写”，不如亲手搭一套实验环境，用真实代码去测试 AI 的能力边界。

下一步，你可以从今天这篇文章的脚本出发，做三件事：

1. 把题目清单换成自己感兴趣的问题，比如“用 Python 验证某个数论猜想的反例搜索”。
2. 增加多次采样，对比不同 temperature 和不同模型下的回答差异。
3. 把每一次实验的 prompt、参数、结果、人工复核记录都保存下来，形成自己的 AI 数学实验笔记。

如果你跑出了有意思的结果，欢迎在评论区分享你的实验过程和复现方式。技术讨论的价值，不在于谁的口号更响，而在于谁的方法可以被别人验证。