Fields 奖得主用 AI 解决了真实的数学难题

Fields medalists are solving real math problems with AI

这不是 demo，不是 benchmark，是实际推进了某些猜想的进展。 最顶级的头脑都已经把 AI 当工具，我们就更没有理由还停在"AI 会不会取代我"这一类话题上。

Not a demo, not a benchmark — real progress on real conjectures. If the top minds in math already treat AI as a tool, we have no excuse to still be debating "will AI replace me."

核心：不让 AI 自由发挥，让它执行有边界的任务

Core idea: don't let AI freelance — give it bounded tasks

最近我做下来最稳的一条结论： AI 不是不会犯错，是当你给它一个明确、结构化、可验证的任务，它就能做得比人快、比人稳。 管线的全部价值，就是把"研究"这件事拆成它能稳定完成的形状。

The most stable conclusion I've reached: AI does make mistakes — but when you give it a clear, structured, verifiable task, it runs faster and steadier than a human. The whole point of the pipeline is to cut "research" into shapes AI can finish reliably.

vision 模块：把宽泛的想法变成具体的事情

The vision module: turning vague ideas into concrete work

刚讲的管线是骨架。骨架里流的"想法"怎么变成具体的、能被管线消化的形状 —— 这是 vision 模块管的事。 用 AI 去找想法之间的内在关联，去判断什么时候它已经成熟到可以加进主线。 想法本身是宽泛的，AI 的工作是把它和已有结构连起来，再决定它现在能不能落进去。

The pipeline above is the skeleton. How vague "ideas" become a shape the pipeline can digest — that's what the vision module handles. Use AI to find the internal links between ideas, and to judge when an idea is mature enough to enter main. Ideas are vague by nature; AI's job is to tie them to the existing structure, then decide if they're ready to land.

这件事对新 intern 极其友好

This is wildly friendly to new interns

• 问新 intern 进来，最快上手的方式不是读 50 篇论文，是直接问 AI："这个 lab 现在在做什么"。
• 说他们有什么自己的想法，可以丢给 AI 让 AI 帮他们结构化、关联到现有项目。
• 参更进一步：他们自己的 AI 可以直接参与到我们的 repo 里（PR + review）。
• 学他们学到的不只是"做研究"，而是"在 AI 协作环境里做研究" — 这才是未来 5 年的核心能力。

• askFor a new intern, the fastest onramp isn't reading 50 papers — it's asking AI: "what is this lab actually working on right now."
• tellIf they have their own idea, they can hand it to AI and let AI structure it and link it to existing projects.
• joinOne step further: their own AI can participate directly in our repos (PR + review).
• learnWhat they pick up isn't just "how to do research" — it's "how to do research inside an AI-collaboration environment." That's the core skill of the next 5 years.

我们自己也是 vision 模块的用户 —— 比如 NotebookLM 把我们的论文合成 deep-dive audio， 听的过程里会冒出新的 vague idea，闭环回 vision。 这也是为什么下一页讲的 4 条 lane 里有一条专门做 NotebookLM 自动合成 —— 既给外面看，也给我们自己听。 We use the vision module ourselves too — NotebookLM auto-synthesizes deep-dive audio from our own papers, and fresh vague ideas pop up mid-listen and loop back into vision. That's also why one of the four lanes on the next slide is dedicated to NotebookLM synthesis — for outside readers, and for us to listen to. vision → pipeline → vision · the loop

newmath / automath：稳定产出的证据

newmath / automath: evidence of stable output

下面这些不是计划，是已经在 GitHub 上跑了几个月、有 commit、有 release、有论文产出、有自动宣发的事实。

The numbers below aren't a plan — they've been live on GitHub for months: real commits, real releases, real papers, real auto-promotion.

四条本地真实在跑的 lane

Four lanes actually running locally

怎么"平衡"三个模型 —— 各自的强项做各自的事

How to balance the three models — each one does what it's best at

• 推ChatGPT Pro extended thinking 当 oracle 用：长链推理深度目前最够，"下一步该往哪推"这种创造性判断交给它。
• 做Codex 当执行层用：最擅长在有明确边界的代码 / Lean / latex 改写任务里稳定产出，不能让它做开放性推理。
• 控Claude 当 supervisor + 最终 review：最擅长读上下文、判 claim 是不是过界，最适合卡边界。
• 分关键不是"用哪个模型最强"，是 让每个模型只做它最擅长的那一步。lane 3-4 同一逻辑：NotebookLM 做合成、剪辑模型做切片、Claude 把关最终输出，不让任何一个越界。

• pushChatGPT Pro extended thinking as oracle: its long-chain reasoning depth is currently the deepest — hand it the creative call of "where do we push next."
• doCodex as the execution layer: best at producing reliably inside bounded code / Lean / latex rewriting tasks. Don't let it do open-ended reasoning.
• holdClaude as supervisor + final review: best at reading context and judging whether a claim crossed the line — perfect for guarding boundaries.
• splitThe point isn't "which model is strongest" — it's letting each model only do its single best step. Same logic on lanes 3-4: NotebookLM synthesizes, an editor model clips, Claude gates the final output — never crossing.

PhD 项目：方法论可迁移的实物证据

PhD project: live evidence the methodology transfers

我把上面验证过的这套结构搬到了我自己的博士项目上。 最近也开始重新迭代、有产出了。重点不是项目内容本身， 而是 —— 同一套研究 OS，换一个完全不同的域，照样跑得起来。

I moved the structure validated above onto my own PhD project. It's iterating again, producing again. The point isn't the project itself — it's that the same research OS, in a completely different domain, still runs.

PhD 这个项目最近重新有产出，但故事不是"AI 帮我写了代码"。 是 —— 同一套研究 OS，换一个域，照样跑得起来。 这是我想呈现的"方法论可复用"的部分

The PhD project is producing again, but the story isn't "AI wrote my code." It's — the same research OS, dropped into a different domain, still runs. This is the "methodology is reusable" part I want to show

GitHub 是天生为 AI 准备的

GitHub was built for AI before AI knew it

AI 会犯错，这是事实。但 GitHub 的所有机制 — commit、branch、rollback、PR、actions — 全部都是为"会犯错的执行者 + 需要审计的协作"设计的。 我们 lab 即使保持半开源的传统，private repo 也已经足够把 AI 协作的好处吃满。

AI makes mistakes. Fine. But every GitHub mechanism — commit, branch, rollback, PR, actions — was designed for "fallible executors + auditable collaboration." Even if our lab keeps its half-open tradition, private repos alone are enough to capture all the AI collaboration upside.

4 台电脑、常开、loop 不间断、自动汇合

4 machines, always on, loops never stop, merges happen by themselves

不是同时控制 4 个键盘，是 4 台机器各跑一个 daemon loop， 各自推进自己的 lane，靠 git 实时 commit / handoff 通信。 所有 loop 实时同步到 autodev 这一层（双向 sync），过审核才 merge 回主线。 我每天的实际 attention 只放在最有判断价值的环节。

Not me at 4 keyboards. Each of 4 machines runs a daemon loop, pushes its own lane, and the machines talk to each other through live git commits / handoffs. Every loop syncs in real time into the autodev layer (both ways); only what passes review merges back to main. My actual attention each day only goes to the steps where judgment really matters.

• daemon每台机器跑一个 daemon loop —— 常驻进程，事件驱动地推进任务，不需要人启动。
• 独立每台机器在自己的 loop 里推进自己的 lane，互不干涉。
• 通信各机器之间通过 git 实时 commit / handoff 通信 —— 一个 lane 卡住的时候另一个 lane 直接接手，不冲突。
• 同步autodev 是实时同步层，不只是中转 —— 所有 worker 分支双向 sync：pull 最新 main + push 所有 worker commit，4 台机器始终看到一致状态。
• 审autodev 上跑 CI、跑自动 review，再加一道人 / adversarial 审核 —— 通过了才 merge 回 main。
• 回没通过的留在 autodev 继续修；我的判断回写成下一轮 prompt 喂给 supervisor。

• daemonEach machine runs one daemon loop — long-lived, event-driven, no human start button.
• isoEvery machine pushes its own lane inside its own loop, no interference.
• talkMachines talk to each other through live git commits / handoffs — when one lane gets stuck, another picks up without collision.
• syncautodev is a real-time sync layer, not just staging — every worker branch syncs both ways: pull latest main + push all worker commits, so all 4 machines see consistent state.
• reviewautodev runs CI, runs auto-review, plus a human / adversarial review pass — only then does it merge back to main.
• loopWhat doesn't pass stays in autodev for fixes; my judgment gets written back as the next round of prompt for the supervisor.

把"office hour"蒸馏成 AI 可调用的资源

Distilling "office hours" into something AI can call

先讲一下 gstack —— Y Combinator 现任 CEO Garry Tan 自己写的开源 Claude Code skill 包

First, gstack — the open-source Claude Code skill pack written by Garry Tan, current CEO of Y Combinator

YC（Y Combinator）是硅谷孵化了 Airbnb / Stripe / OpenAI 等几千家公司的那个 accelerator。 Garry Tan 现在是它的 President & CEO，自己又是 Posterous 的 co-founder、写了 YC 内部 Bookface 的第一版。 他在 2026 年初亲自下场写代码，把自己 hold 多个项目的方法封装成了 gstack —— 三周冲到 70k+ stars。

YC (Y Combinator) is the Silicon Valley accelerator that produced Airbnb / Stripe / OpenAI and thousands of others. Garry Tan is its current President & CEO, also a Posterous co-founder, and wrote the first version of YC's internal Bookface. Early 2026 he sat down and wrote the code himself, packaging how he juggles many projects into gstack — 70k+ stars in three weeks.

它最被推崇的就是 /office-hours： 把 16 个 YC partner 给 founder 做 office hour 时的判断风格蒸馏成 6 个 forcing question， 在你写任何代码之前先逼你把事情想清楚。 Garry 自己的原话是：你在这里得到的大概是真去 YC 做 office hour 价值的 10%， 但这 10% 已经能让很多 founder 直接放弃错的想法。

The piece people praise most is /office-hours: it distills how 16 YC partners conduct office hours into 6 forcing questions that make you think clearly before writing any code. Garry's own line: what you get here is maybe 10% of the value of an actual YC office hour, but that 10% is already enough to make a lot of founders drop a wrong idea.

它为什么好用：在你让 AI 干活之前，先帮你把事情理解到底。 这正好踩在 AI 协作最容易出问题的那一步上 —— 大多数人会跳过理解、直接让 AI 跑，然后一边跑一边发现"哦不是这样"。 office-hours 把"理解"这一步前置了。

Why it works: it helps you understand the thing before you turn AI loose on it. That hits exactly the step where AI collaboration most often goes wrong — most people skip understanding, kick off AI, and only mid-run realize "oh that's not what I meant." office-hours moves "understanding" to the front.

我现在所有项目都会先用它过一遍

I now run every project through it first

只有自己（和 AI）先把整个事情理解清楚，自动化管线才拆得出来，才有用。 顺序不能反 —— 没有理解就上自动化，只是在快速放大自己的盲点。 office-hours 这种"理解优先"的工具，是研究 OS 的入口环节，不是边角料。

Only once you (and AI) actually understand the thing can the automation pipeline be cut cleanly and be useful. The order can't flip — automation without understanding just amplifies your blind spots faster. "Understanding first" tools like office-hours are the entry point of the research OS, not an extra.

在这个基础上我自己做了一版"私人 office-hour"

On top of that I built my own "private office hour"

研究里有很多"不可言说的言说" —— 品味、判断、踩过的坑。 很多人在做世界模型、做具身智能，本质都是想捕获这种东西。 在科研协作这个域里，AI 已经可以帮我们做这一步了。 这是"超过自身经验的经验"

Research has a lot of "unsayable speech" — taste, judgment, the shape of past mistakes. A lot of people building world models, building embodied AI, are really trying to capture this kind of thing. Inside research collaboration, AI can already do this step for us. This is "experience beyond your own experience"

你不需要第三方 app —— 你可以自己搭

You don't need third-party apps — you can just build them

office-hour 只是一个例子。规律是：你日常用的任何"工具型 app"， 现在都可以让 agent 在本地帮你重做一份 —— 更贴合你自己的 workflow、更可控、更便宜。

office-hours is just one example. The pattern: any "utility app" you use day-to-day can now be rebuilt locally by an agent — better fit to your own workflow, more controllable, cheaper.

• API有 API · agent 直接 call。arxiv / Google Scholar / GitHub / OpenReview / Vercel / ...
• 无没 API · coding agent + Chrome / Playwright，去访问、截图、解析、回写。
• 果结果 · 你的工具栈每天都在自己长 —— 不是订阅 SaaS，是自己长。

• APIHas API · the agent calls it directly. arxiv / Google Scholar / GitHub / OpenReview / Vercel / ...
• no-APINo API · coding agent + Chrome / Playwright — visit, screenshot, parse, write back.
• growResult · your toolchain grows on its own every day — not a SaaS subscription, it actually grows.

"工具靠订阅"是上一个时代的逻辑。 在 agent 时代，你的工具栈是自己长出来的 —— 长得最贴合你自己。 OPC（One-Person-Company）的硬基础

"Subscribe to your tools" is last era's logic. In the agent era, your toolchain grows itself — shaped exactly to you. The hard floor of OPC (One-Person-Company)

所有研究路线都可以做成可视化 DAG

Every research roadmap can become a visual DAG

每个项目都有一个 roadmap，每个节点有明确的依赖关系。 DAG 让"我们到了哪一步"变成肉眼可见的事情 —— 人把控方向，让 AI 不断把节点推到下一阶段。 下面这张是 BEDC 项目现在真实在跑的 project map。

Every project has a roadmap, every node has explicit dependencies. A DAG makes "where are we now" something you can see — humans steer direction, AI keeps pushing nodes to the next stage. The map below is the BEDC project's actual live project map.

每个节点点开都有：constructive story（这个对象是怎么从底层一步步搭出来的）、 Lean 验证状态、被依赖的上下游、当前的 stub / checked 状态。 这张图本身就是整个项目的"共同视野"—— 谁在哪一格、卡在哪条边、下一步往哪推，看一眼就清楚。

Click any node and you get: the constructive story (how this object is built up from the bottom step by step), Lean verification status, upstream / downstream dependencies, and current stub / checked state. The map itself is the project's "shared field of view" — who is on which cell, which edge is stuck, where to push next: one look and it's clear.

我建议实验室建立一个 org，统一协作面

I'm proposing the lab create a GitHub org — one shared surface

就算保持半开源传统，把 lab 的项目集中到一个 GitHub organization 下（可以全 private）， 会让 AI 协作的所有好处加成到实验室级别。我在自己的一个 side project 里已经跑通了这个模式， 可以作为参考。

Even if we keep the half-open tradition, pulling the lab's projects under one GitHub organization (fully private is fine) would lift every AI-collaboration benefit up to lab scale. I've already run this pattern in a side project of mine — happy to use it as a reference.

实验室不一定要全开源，但建议有一个 org —— 即使是 private 的， 也能让我们整个 lab 的产能上一个数量级。

The lab doesn't have to go open-source, but I'd suggest having an org — even fully private, it can push the whole lab's output up by an order of magnitude.

再招一个 postdoc，还是把现有人全部武装到顶？

Hire another postdoc, or kit out everyone we already have?

重点不是 AI 取代谁。重点是：同样一份预算， 能让现有的每个人产能上一个台阶，还是只多一个人、其他人不动。

The question isn't who AI replaces. It's: for the same budget, do we step up every existing person, or do we just add one extra and leave the rest where they are.

不是说不要 postdoc。是说在 2026 年， "补一个 AI 协作基础设施"在边际上比"再加一个人"杠杆更高 —— 而且两件事不互斥，一个 postdoc 的预算，也足够同时把现有所有人的工具栈拉到最强。

Not arguing against postdocs. The point is that in 2026, "filling in the AI-collaboration infrastructure" has higher marginal leverage than "adding one more person" — and the two aren't mutually exclusive: one postdoc's budget is enough to also max out everyone's toolchain at the same time.

组会的形式本身也可以优化

The format of the lab meeting itself can be optimized

坦白说，纯讲话的组会信息密度是低的。如果我们真的能让 AI 深入到每个人的代码库里， 很多"现在做到哪了"这件事其实可以直接看，不用每周再口头复述一遍。

Honestly, pure-talk lab meetings are low-density. If AI can really reach into everyone's repos, a lot of the "where are we now" can just be looked at — no need to verbally recap it every week.

这一点我不强推。但如果我们建了 org，这个变化几乎是顺手就完成的。

Not pushing this one hard. But if we set up the org, this change pretty much happens for free.

这套 OS 已经能跑 · 剩下的是把它打开

The OS already runs · what's left is turning it on for the lab

我 pitch 这一整套，核心不是想 show 我做了多少。 是 — 这套 OS 已经验证能稳定产出， 剩下的就是让它在 lab 里跑起来，让大家一起更快产出、更好产出。

I'm pitching all of this not to show how much I've done. It's — this OS has been validated, it produces reliably, and what's left is getting it running inside the lab, so everyone produces faster and better together.

一句话回顾

One-line recap

• 01信号 · Fields 奖得主都在用 AI 攻克猜想了，分水岭已经过去。
• 02方法 · 能结构化的全部结构化，能 gate 的全部 gate，AI 在边界里干活就稳。
• 03验证 · newmath / automath 上 3,427+ 个 0-axiom 定理 · 42 篇论文管线 · 5×/周自动 release。
• 04可迁移 · 同一套 OS 搬到 PhD 项目，最近重新有产出。
• 05更深一步 · AI 蒸馏 office-hour —— "超过自身经验的经验"。
• 06建议 · 建 org · onboarding 走 /daily · 同等预算把现有人配满 Pro，放大产能。

• 01Signal · Fields medalists are already cracking conjectures with AI; the watershed is behind us.
• 02Method · structure everything that can be structured, gate everything that can be gated — AI is steady inside boundaries.
• 03Validation · newmath / automath: 3,427+ 0-axiom theorems · 42-paper pipeline · 5×/week auto-release.
• 04Transferable · same OS dropped onto the PhD project — producing again.
• 05Deeper · AI-distilled office-hours — "experience beyond your own experience."
• 06Proposal · build the org · onboarding via /daily · same budget, max out everyone with Pro, multiply output.

我希望我们一起跑这个 loop。 现有的人 + AI + 一套共享的 OS，本来就该有 10× 的产能。 我做这些不是想自己跑得快 —— 是想让我们整个 lab 一起更快、更好。 这是我做这一切的核心目的

I want us to run this loop together. The people we already have + AI + a shared OS — this should already be 10× output. I'm not doing this to run faster on my own — I'm doing it so our whole lab runs faster and better, together. That's the real point of all of it

几条代表性的帖子

A few representative posts