导师与学员关于人工智能研究和人生方向的对话 | 原创,AI翻译

Home 2026.05

本文整理自一次线上会议的音频转录。两位参与者分别是一位资深程序员和一位高中AI研究者(张瑞修)。由于原始转录丢失了说话人标签,以下内容以第三人称(”他们”)重新组织,保留了原对话的口语风格和核心观点,同时去除了重复、闲聊和不相关的片段,并按主题进行了归类。

注:本文通过 Whisper 转录后,由 Claude Code (Opus 4.7) 重组生成。部分细节可能存在微小或无关紧要的事实性错误——在依赖本文信息前,请独立核实所有重要内容。


1. 沟通效率与”项目演示”作为开场白

会议以一个非常实际的观点开场:重复沟通效率低下

这位资深程序员提到,他刚结束一场面试,他打开博客,用大约十分钟介绍了自己——在他看来,这就是高效沟通的样子。他建议把这次会议录下来,转成文字,下次再有中学生来问同样的问题(如何做项目、如何包装简历),直接把整理好的材料发过去,而不用从头解释一遍。

他特别指出:你向教授和很多人说的话,有很多内容是翻来覆去的重复。这种状态本质上是低效的。

至于会议工具,他们当时在用腾讯会议,但这位资深程序员建议下次换成 Teams,并提到他也有 Zoom。理由是:这些产品是投入了数十亿甚至上百亿美元打造的——熟悉工业级的协作工具本身就是”活在未来”的一部分。


2. 为什么”底层算法”和”构建产品”是两条不同的路

在方向上,这位资深程序员首先分享了他对另一个学生(杨杨)的观察:那个学生研究的是 NVIDIA 栈内的优化(显存、内存搬运、内核级工程)。这本质上是运维和工程工作——虽然有时也能带来关键发现,比如 FlashAttention。

这位高中生的立场很明确:

这位资深程序员的观点是:两条路都行得通,但你必须清楚自己走的是哪条。

接着,他说了一些相当直白的话——大意是:在中国的环境里长大,本身已经要投入很多精力,但人外有人,天外有天。与硅谷最顶尖的 16 岁少年相比,差距主要体现在两个方面:

  1. 实际的英语表达能力——极其熟练,像中文一样流利;
  2. 计算机能力大致相当,但在 OpenAI 这种高强度的沟通环境中,如果你的英语理解效率不如中文,那么在解释”非常复杂的 transformer 讨论”时就会慢半拍——仅仅这一点就可能让另一个候选人超过你,即使他的思维不见得更敏锐,AI 基础也不一定更扎实。沟通本身就是一个硬性指标。

所以他一直强调:英语流利不是为了英语本身,而是为了将来不吃亏。


3. 思维树项目:完整代码走查

会议的技术核心是这位高中生分享他自己的思维树物理问题求解系统。他在本地运行,并一步步地讲解了架构。

3.1 模型分工:四个角色

该系统由四种模型协作完成:

角色 规模 职责
规划模型(编排器) 大(120B) 将问题分解为元任务 → 任务,逐步规划
建模模型 中(9B) 严格遵守规划器的指令,从未看到完整问题
审查模型 小(0.5B / 4B) 检查每一步的逻辑,决定是加噪 / 退回 / 通过
评估模型 主观评分,例如最终公式是否足够简洁

这位高中生解释了一个关键的设计决策:为什么建模模型绝不能看到完整问题?

如果你让它看到原问题加上分解后的子任务,它会忍不住——它会试图”一次性解决所有问题”,而不是遵循分解结果。所以必须只给它当前步骤的指令。

这位资深程序员的评论是:”完全正确——你必须给它精确的东西,剔除掉所有它不需要的部分,否则它会误解你的意思。”

3.2 为什么用 FSM(有限状态机)而不是简单的数据结构

审查部分使用了基于 FSM 的状态管理方法。这位高中生的理由是:

3.3 关于”发散”和”收敛”

他鼓励模型在最开始的节点尽可能多地发散,例如生成 5–7 种不同的方法;到了后期,如果一个分支只是在添加修正项(比如阻力),就没有必要再继续发散——审查模型会自行决定。

人文科学的问题可能呈现相反的形态:在反驳现有论点的阶段,你可能实际上需要在后期更多地发散。因此,”思维树”的形状本身就是学科特征的反映。

3.4 技能系统和外部 SQL

他将所有”领域知识”外置化:

3.5 编排器的局限性以及为什么从小模型开始

演示产生的最终答案并不特别精确(例如,一个问题以类似 v_eff × h 的形式结束,这种形式不够精确)。他坦诚地承认了这一点:

“开源的小模型还是太弱。如果我调用 API,结果肯定会好得多。”

但他强调了一种工作方法,得到了这位资深程序员的高度认可:

首先,让整个流程在本地小模型上跑通,而不是直接跳到 API。

小模型会暴露那些调用 API 时永远看不到的小陷阱;一旦整个流水线跑通了,换成更大的模型只会变得更好,不会变得更差。


4. 代码组织与 Codex / Copilot 使用习惯

他们一起浏览了几个文件:backend / scheduler / models / planning_model / utils。一些观察:

这位资深程序员给出的工具建议:


5. Mini-LLM 项目:一个 nanoGPT 风格的训练实现

接下来他们看了第二个项目——一个模仿 nanoGPT 的迷你语言模型训练实现。

5.1 多个版本与硬件适配

仓库里有几个版本的原因是:他在不同的硬件上运行过相同的代码:

不同的硬件需要不同的精度、批大小和并行策略;他保留的是 A100 的版本。

5.2 当场提问的几个细节

这位资深程序员以提问的方式过了一遍 Transformer 的细节:

5.3 数据规模与硬件升级


6. 第三个项目:一个智能体编码实验

这是这位高中生搭建的一个迷你”多智能体协作编码”系统,灵感来自 Cloud Code:

他评价这个项目是一次性的探索,没有继续维护,但确实通过它完成了像”贪吃蛇游戏代码”这样的小任务。


7. 关于”证明你的水平”——来自资深程序员的重要建议

当话题转到 RoPE 和 KQV 时,这位资深程序员问了一个有点尖锐的问题:

“你说你比那个邓明扬或者 Kimi 的那个人强,但我其实持怀疑态度。”

他解释说:并不是不相信他的潜力,关键在于局外人没有可靠的方法来判断。要让别人相信你比某个 0xy / IOI 奖牌获得者更强,通常有几种途径:

  1. 与一个已经比较了解你的人进行多次交谈,让他们能在多个时间点看到你对语言模型知识的掌握程度;
  2. 让简历自己说话——一眼看去,读者就知道这个人比 X 强;
  3. 在面试中由一位足够资深的面试官当场认可(他举了自己当天上午面试一个渣打银行海外岗位的例子——半小时后,面试官就示意他通过了)。

说这些的目的不是为了打击人,而是提醒:”你的水平”不能停留在自我感觉中。它需要一个别人能看见的载体。

他还提到了一个有趣的点——名字本身可以成为一个品牌

“当人们听到你的名字就知道你是一个顶尖人物时,你就真正成功了——你的名字就是你的品牌。”


8. 关于”逆转近视”——资深程序员的一个副研究课题

会议中间,这位资深程序员分享了一个他研究了多年的非主流课题——近视的可逆性。要点简述:

他做了一个类比:这本质上和他理解 GPT 的方式是一样的——

“2017 年讨论 Transformer 的人也不多;真正有效的东西,在早期阶段,只有少数人知道。”

而且他提醒他,作为每天都要进行大量近距离用眼工作的人,这件事甚至比项目工作更值得花几分钟关注。


9. 关于人脉、外语环境和独立思考

他们逐行查看了这位高中生的微信群成员列表:

当话题转到 王垠Daniel P. Friedman 和《The Little Schemer》时,这位资深程序员花了很多时间解释他所说的”独立思考”是什么意思:

他把这个观点指向了这位高中生:为什么很多事情必须自己想出来,而不是从别人那里抄来——这是后面一切的基础。


10. 资深程序员自己的创业经历(作为参考)

为了给”项目可信度”做一个注脚,这位资深程序员描述了他大约在 2016 年做过的一个微信小程序直播答题项目:

接着他讲了早期 Airbnb 的故事——创始人与投资者边喝咖啡边谈,投资者去了趟洗手间就再没回来。他并不是在抱怨;他想让这位高中生提前知道:

“这个世界是非常利益导向的。当你没有名气时,会遭遇很多冷遇——你必须做好心理准备。”


11. 快速数学小测验

会议中穿插了一段简短的小测验:


12. AI 工具与开发习惯总结

一些零散但有价值的点:


13. 合作计划与下次会议

会议接近尾声时,这位资深程序员提出了一个具体的合作想法:

“我自己已经训练过 GPT-2 了。我们应该合作训练一个 GPT-3。如果能再训练一个 GPT-4(2022 年水平的),我们就差不多站在 AI 领域的前列了。”

这位高中生的回答保持了工程上的清醒:参数规模扩大后,就不再需要单机了——你需要一个集群。这位资深程序员认为 Runpod 这样的平台可以处理集群方面的问题;瓶颈仍然是那三件事——数据、算力、算法。

对于下次会议,他们达成了一致:

  1. 换成 Teams
  2. 再过一遍 Transformer / KQV——这是面试中最常被问到的部分;
  3. 这位高中生提供一份近视检查报告
  4. 这位高中生读完那位资深程序员推荐的几篇王垠的文章。

结语

这次对话涵盖范围很广:从一名 16 岁少年的思维树物理推理框架,到对 RoPE 和 KQV 的现场提问,再到硅谷创始人的轶事、逆转近视以及”独立思考”的方法论。

如果要用一句话来概括,大致是:

能力本身是必需的;但除了能力,你还需要一个让别人能看见你的载体——一份简历、一个项目、一个名字、英语流利度,以及别人在多次交流中对你形成的稳定判断。

在技术方面,双方都认同:先在小型模型上把流水线跑通,然后再换用更大的模型;让模型在你设计的边界内执行,而不是让它替你思考。 无论是构建思维树还是迷你语言模型,从根本上说,这都是同一件事。


Back Donate