导师与学员关于人工智能研究和人生方向的对话 | 原创,AI翻译
本文整理自一次线上会议的音频转录。两位参与者分别是一位资深程序员和一位高中AI研究者(张瑞修)。由于原始转录丢失了说话人标签,以下内容以第三人称(”他们”)重新组织,保留了原对话的口语风格和核心观点,同时去除了重复、闲聊和不相关的片段,并按主题进行了归类。
注:本文通过 Whisper 转录后,由 Claude Code (Opus 4.7) 重组生成。部分细节可能存在微小或无关紧要的事实性错误——在依赖本文信息前,请独立核实所有重要内容。
1. 沟通效率与”项目演示”作为开场白
会议以一个非常实际的观点开场:重复沟通效率低下。
这位资深程序员提到,他刚结束一场面试,他打开博客,用大约十分钟介绍了自己——在他看来,这就是高效沟通的样子。他建议把这次会议录下来,转成文字,下次再有中学生来问同样的问题(如何做项目、如何包装简历),直接把整理好的材料发过去,而不用从头解释一遍。
他特别指出:你向教授和很多人说的话,有很多内容是翻来覆去的重复。这种状态本质上是低效的。
至于会议工具,他们当时在用腾讯会议,但这位资深程序员建议下次换成 Teams,并提到他也有 Zoom。理由是:这些产品是投入了数十亿甚至上百亿美元打造的——熟悉工业级的协作工具本身就是”活在未来”的一部分。
2. 为什么”底层算法”和”构建产品”是两条不同的路
在方向上,这位资深程序员首先分享了他对另一个学生(杨杨)的观察:那个学生研究的是 NVIDIA 栈内的优化(显存、内存搬运、内核级工程)。这本质上是运维和工程工作——虽然有时也能带来关键发现,比如 FlashAttention。
这位高中生的立场很明确:
- 他更喜欢钻研和思考算法层面的创新;
- 例如,研究注意力机制,研究 RoPE(他提到了苏剑林关于”旋转”注意力的工作),并思考如果将”某个特定的注意力倾斜 90 度”会发生什么;
- 至于”你最终只会做产品”这种说法,他不同意——构建产品是另一条赛道,旨在将 AI 应用于生活的方方面面,而他想走得更深,更接近模型本身。
这位资深程序员的观点是:两条路都行得通,但你必须清楚自己走的是哪条。
接着,他说了一些相当直白的话——大意是:在中国的环境里长大,本身已经要投入很多精力,但人外有人,天外有天。与硅谷最顶尖的 16 岁少年相比,差距主要体现在两个方面:
- 实际的英语表达能力——极其熟练,像中文一样流利;
- 计算机能力大致相当,但在 OpenAI 这种高强度的沟通环境中,如果你的英语理解效率不如中文,那么在解释”非常复杂的 transformer 讨论”时就会慢半拍——仅仅这一点就可能让另一个候选人超过你,即使他的思维不见得更敏锐,AI 基础也不一定更扎实。沟通本身就是一个硬性指标。
所以他一直强调:英语流利不是为了英语本身,而是为了将来不吃亏。
3. 思维树项目:完整代码走查
会议的技术核心是这位高中生分享他自己的思维树物理问题求解系统。他在本地运行,并一步步地讲解了架构。
3.1 模型分工:四个角色
该系统由四种模型协作完成:
| 角色 | 规模 | 职责 |
|---|---|---|
| 规划模型(编排器) | 大(120B) | 将问题分解为元任务 → 任务,逐步规划 |
| 建模模型 | 中(9B) | 严格遵守规划器的指令,从未看到完整问题 |
| 审查模型 | 小(0.5B / 4B) | 检查每一步的逻辑,决定是加噪 / 退回 / 通过 |
| 评估模型 | 小 | 主观评分,例如最终公式是否足够简洁 |
这位高中生解释了一个关键的设计决策:为什么建模模型绝不能看到完整问题?
如果你让它看到原问题加上分解后的子任务,它会忍不住——它会试图”一次性解决所有问题”,而不是遵循分解结果。所以必须只给它当前步骤的指令。
这位资深程序员的评论是:”完全正确——你必须给它精确的东西,剔除掉所有它不需要的部分,否则它会误解你的意思。”
3.2 为什么用 FSM(有限状态机)而不是简单的数据结构
审查部分使用了基于 FSM 的状态管理方法。这位高中生的理由是:
- 一个节点不仅仅是存储”计算出了什么数字”——它存储的是边界条件、参数、调用的技能以及这个建模步骤的约束;
- 在解决物理问题时,每个中间答案都有其适用范围,而 FSM 就是那个将适用范围和答案一起存储的载体;
- 这也是他后来放弃了 DAG(有向无环图)合并思路的原因——不同的分支几乎从未共享相同的前提假设(例如,一个分支假设理想流体,另一个分支添加了一大堆修正项);即使两者计算出了相同的数字,也不能合并。
3.3 关于”发散”和”收敛”
他鼓励模型在最开始的节点尽可能多地发散,例如生成 5–7 种不同的方法;到了后期,如果一个分支只是在添加修正项(比如阻力),就没有必要再继续发散——审查模型会自行决定。
人文科学的问题可能呈现相反的形态:在反驳现有论点的阶段,你可能实际上需要在后期更多地发散。因此,”思维树”的形状本身就是学科特征的反映。
3.4 技能系统和外部 SQL
他将所有”领域知识”外置化:
- 流体力学公式、功能关系公式等——模型不允许记忆它们,而是被写入技能中;
- 模型只负责调用,不允许自行计算;
- 这避免了模型在没有基于规则的约束时”胡乱猜测”。
3.5 编排器的局限性以及为什么从小模型开始
演示产生的最终答案并不特别精确(例如,一个问题以类似 v_eff × h 的形式结束,这种形式不够精确)。他坦诚地承认了这一点:
“开源的小模型还是太弱。如果我调用 API,结果肯定会好得多。”
但他强调了一种工作方法,得到了这位资深程序员的高度认可:
首先,让整个流程在本地小模型上跑通,而不是直接跳到 API。
小模型会暴露那些调用 API 时永远看不到的小陷阱;一旦整个流水线跑通了,换成更大的模型只会变得更好,不会变得更差。
4. 代码组织与 Codex / Copilot 使用习惯
他们一起浏览了几个文件:backend / scheduler / models / planning_model / utils。一些观察:
- 项目中有些模块(例如
merge)是 AI 生成的但目前未被使用——他选择保留它们,理由是”可能对其他学科有用,物理中几乎用不到”; - 这位高中生使用的是 Codex(更高级的 Copilot 套餐,140 美元方案),搭配 GPT-5.4 和高强度任务;跑完整个项目只消耗了他大约 7% 多的配额;
- 他授予了 Codex 自动批准权限,这样它就不需要每次执行命令都请求确认。他的判断是:模型本身不会做有害的事情,放弃这种控制权可以显著提高效率;
- 他使用 Codex 的方式更接近于”协作”——让它反复运行测试并自主迭代——而不是把它当作一次性问答工具。
这位资深程序员给出的工具建议:
- 终端可以试试 Ghostty;
- 把 VSCode 里的每个界面都换成英文;长期接触英文界面是一种刻意的训练;
- 提问时,尽可能贴代码——光靠描述往往不够准确;
- 对于比较新的依赖库,直接在本地克隆代码,然后通过类似 Cloud Code 的工具对照着真实源码提问——这比让模型去做网页搜索要准确得多。
5. Mini-LLM 项目:一个 nanoGPT 风格的训练实现
接下来他们看了第二个项目——一个模仿 nanoGPT 的迷你语言模型训练实现。
5.1 多个版本与硬件适配
仓库里有几个版本的原因是:他在不同的硬件上运行过相同的代码:
- MacBook(Flash Attention 不可用);
- 他自己的 3090;
- 一个同学的 5090;
- 云端的 A100 和 A800。
不同的硬件需要不同的精度、批大小和并行策略;他保留的是 A100 的版本。
5.2 当场提问的几个细节
这位资深程序员以提问的方式过了一遍 Transformer 的细节:
- RoPE(旋转位置编码):把位置变成一个可旋转的向量,让每个 token 更好地与其他 token 交互;在自回归情况下,使用正弦/余弦进行位置编码,注册为一个不参与参数更新的 buffer,并与模型一起保存;
- KQV:K 是这个 token “在寻找什么”;Q 是这个 token 自身的信息;V 是这个 token 可以为 token 之间的关系贡献什么;
- Flash Attention / mask:他没有手动编写 mask,因为 PyTorch 内部已经处理了很多相关工作;
- Transformer Block:每一侧都有一个 LayerNorm 加残差连接,中间是自注意力和前馈网络;
- 训练循环:Adam 优化器、loss 反向传播、梯度更新、梯度清零——三行代码。这位资深程序员的看法是:即使你不常自己写优化器,理解这三行代码的语义在调参或调试时也是至关重要的。
5.3 数据规模与硬件升级
- 这位高中生的训练数据大约有十几 GB;这位资深程序员使用过 60GB;
- 他根据 token 数量反推参数上限,在刚超过一半的地方停下来;
- 他刚刚下单购买了 NVIDIA Pro 6000 来替换 3090(理由:3090 对于训练来说太受限了,Blackwell 的优化还不太好,但显存大小是硬性需求);他父亲在帮忙组装;
- 他下一步的计划是:一个原生的多模态模型。
6. 第三个项目:一个智能体编码实验
这是这位高中生搭建的一个迷你”多智能体协作编码”系统,灵感来自 Cloud Code:
- 使用 ddgs(DuckDuckGo 搜索)进行网页检索;
- 编排器将大任务拆分给多个编程员(注意:这与思维树中”我只想第一步”的方法相反——这里是直接细分任务);
- 每个编程员完成后,审查员先进行静态检查(例如,捕捉低级错误,如缺少 C++ 分号);如果有问题,则发回重写(因为小模型修改得越多越糟糕);
- 通过审查后,放入沙箱运行;
- 沙箱错误反馈给编排器;几次尝试不成功后,编排器会修改对应编程员的系统提示词,使其不再犯同样的错误——他称之为”受控的 CSM 进化”。
他评价这个项目是一次性的探索,没有继续维护,但确实通过它完成了像”贪吃蛇游戏代码”这样的小任务。
7. 关于”证明你的水平”——来自资深程序员的重要建议
当话题转到 RoPE 和 KQV 时,这位资深程序员问了一个有点尖锐的问题:
“你说你比那个邓明扬或者 Kimi 的那个人强,但我其实持怀疑态度。”
他解释说:并不是不相信他的潜力,关键在于局外人没有可靠的方法来判断。要让别人相信你比某个 0xy / IOI 奖牌获得者更强,通常有几种途径:
- 与一个已经比较了解你的人进行多次交谈,让他们能在多个时间点看到你对语言模型知识的掌握程度;
- 让简历自己说话——一眼看去,读者就知道这个人比 X 强;
- 在面试中由一位足够资深的面试官当场认可(他举了自己当天上午面试一个渣打银行海外岗位的例子——半小时后,面试官就示意他通过了)。
说这些的目的不是为了打击人,而是提醒:”你的水平”不能停留在自我感觉中。它需要一个别人能看见的载体。
他还提到了一个有趣的点——名字本身可以成为一个品牌:
“当人们听到你的名字就知道你是一个顶尖人物时,你就真正成功了——你的名字就是你的品牌。”
8. 关于”逆转近视”——资深程序员的一个副研究课题
会议中间,这位资深程序员分享了一个他研究了多年的非主流课题——近视的可逆性。要点简述:
- 核心机制:佩戴比实际度数低 100–150 度的眼镜,让眼睛持续处于”需要轻微自我对焦”的状态,慢慢调整眼轴长度;
- 操作方法:上课或看远处时戴足度眼镜;日常近距离工作时戴低 100 度的眼镜;循环交替;
- 眼镜推荐:拼多多上三五十元的就够用;
- 他追踪这个情况三年了:近视下降了 50 度,散光下降了 75–100 度,中间有反弹,但总体呈下降趋势;
- 推荐资源:Todd Becker 的网站,以及 endmyopia 社区。
他做了一个类比:这本质上和他理解 GPT 的方式是一样的——
“2017 年讨论 Transformer 的人也不多;真正有效的东西,在早期阶段,只有少数人知道。”
而且他提醒他,作为每天都要进行大量近距离用眼工作的人,这件事甚至比项目工作更值得花几分钟关注。
9. 关于人脉、外语环境和独立思考
他们逐行查看了这位高中生的微信群成员列表:
- 林博士(清华博士后,愿意借给他算力):这位资深程序员认识他,称他”资源丰富且热心”;
- 杨同学(香港,在做 NV 栈优化的同龄人):这位高中生承认那个领域本身并不是他的兴趣所在;
- 他的外国朋友很少,日常生活中很少说英语——这位资深程序员强调,这是这位高中生需要主动弥补的部分。
当话题转到 王垠、Daniel P. Friedman 和《The Little Schemer》时,这位资深程序员花了很多时间解释他所说的”独立思考”是什么意思:
- 像 Daniel P. Friedman 这样的人,六十多岁了还在转型写一本关于 AI 的书,代表了深度没有捷径的原则——不是追逐论文,而是自己把问题想明白;
- 许多美国名校,包括康奈尔大学,在他看来都是”让你游到岸边然后朝你扔石头”的地方——他们会布置任务,但不教真东西;
- 像 mini-Kanren 这样的项目,目的不是发表论文,而是”这个想法是你自己产生的,所以你真正知道它是怎么来的”;
- 引用王垠的话:”授人以鱼,不如授人以渔。”
他把这个观点指向了这位高中生:为什么很多事情必须自己想出来,而不是从别人那里抄来——这是后面一切的基础。
10. 资深程序员自己的创业经历(作为参考)
为了给”项目可信度”做一个注脚,这位资深程序员描述了他大约在 2016 年做过的一个微信小程序直播答题项目:
- 自己做了后端、一半的前端、支付和用户运营;
- 运行了一年多,最终达到了 3 万用户;
- 使用了 LeanCloud 风格的平台,用长连接(WebSocket)发送”下一题”同步消息,与视频流(RTMP)解耦;
- 后来类似的应用(他举例说”有数千万用户的直播答题节目”)因内容合规问题被关闭——他的观点是:用户基数越大,合规和监管就越重要。
接着他讲了早期 Airbnb 的故事——创始人与投资者边喝咖啡边谈,投资者去了趟洗手间就再没回来。他并不是在抱怨;他想让这位高中生提前知道:
“这个世界是非常利益导向的。当你没有名气时,会遭遇很多冷遇——你必须做好心理准备。”
11. 快速数学小测验
会议中穿插了一段简短的小测验:
- SVD(奇异值分解):将矩阵分解为 U Σ Vᵀ;
- 特征值分解 与 SVD 的关系;
- 矩阵乘法的”语义”:一种信息交换;
- 一个结论:“人工智能里没有智能,也没有神经元;真正起作用的是微积分。” 这位高中生的修正意见是:在 LLM 层面上多了一层随机性,但底层的数学骨架确实如此;
- 在他看来,训练本质上就是”猜高或猜低”:猜低了梯度就往上推,猜高了梯度就往下推——如此循环往复。
12. AI 工具与开发习惯总结
一些零散但有价值的点:
- OpenRouter:确实有用——让你能针对自己的具体问题,横向比较”市面上最好的模型”;
- One-shot / Few-shot:模型输入 = 模型 = 输出;给一个例子就能显著提高准确率;
- Cloud Code 的技能 / “Lobster” (可能听错了名字,可能是 Lobster 或其他扩展):这位高中生用得不多;
- Hermes:也很少用;
- iClaw + 自制小工具:这位资深程序员写了一个粗糙但能用的 PDF 高亮工具——他用这个例子强化了”构建一个最小可行版本,自然会让你了解全貌“的方法论。
13. 合作计划与下次会议
会议接近尾声时,这位资深程序员提出了一个具体的合作想法:
“我自己已经训练过 GPT-2 了。我们应该合作训练一个 GPT-3。如果能再训练一个 GPT-4(2022 年水平的),我们就差不多站在 AI 领域的前列了。”
这位高中生的回答保持了工程上的清醒:参数规模扩大后,就不再需要单机了——你需要一个集群。这位资深程序员认为 Runpod 这样的平台可以处理集群方面的问题;瓶颈仍然是那三件事——数据、算力、算法。
对于下次会议,他们达成了一致:
- 换成 Teams;
- 再过一遍 Transformer / KQV——这是面试中最常被问到的部分;
- 这位高中生提供一份近视检查报告;
- 这位高中生读完那位资深程序员推荐的几篇王垠的文章。
结语
这次对话涵盖范围很广:从一名 16 岁少年的思维树物理推理框架,到对 RoPE 和 KQV 的现场提问,再到硅谷创始人的轶事、逆转近视以及”独立思考”的方法论。
如果要用一句话来概括,大致是:
能力本身是必需的;但除了能力,你还需要一个让别人能看见你的载体——一份简历、一个项目、一个名字、英语流利度,以及别人在多次交流中对你形成的稳定判断。
在技术方面,双方都认同:先在小型模型上把流水线跑通,然后再换用更大的模型;让模型在你设计的边界内执行,而不是让它替你思考。 无论是构建思维树还是迷你语言模型,从根本上说,这都是同一件事。