Leo的笔记本

读研最怕的不是没工具，是没有自己的龙最近读到一篇讨论AI工具热潮的文章，作者提了一个很尖锐的观察：全国一半的AI Agent每天在给主人发天气预报，另一半在发新闻简报——而这些事，手机免费就能干。 看到这里我笑了，因为我自己也干过类似的事。 刚接触Claude Code的时候，我花了大量时间搭技能模块、配MCP工具链、研究各种Prompt模板。折腾完了，坐在屏幕前，突然发现——嗯，然后呢？ 工具倒是磨快了，但砍什么？ 这个问题，放到我们读研的语境里，更扎心。 你的”问题资源”是什么？ 原文提出了一个概念叫问题资源。意思是：当AI已经能给出不错的答案时，真正稀缺的不再是解题能力，而是你手里有没有值得去解的题。 谁拥有问题，谁就拥有调度工具和系统的权力。 读研不就是这样吗？ 导师给你一个方向，你读了几十篇论文，跑了几个baseline，然后呢？你的contribution是什么？你发现了什么别人没发现的问题？ 我见过两种研究生： 一种人工具玩得特别溜，YOLO各版本如数家珍，训练脚本写得飞快，但你问他”你这篇论文到底解决了什么问题”，他支支吾吾半天，最后说”我把mAP提了两个点”...

这两天，我把 Vercel、Supabase 和 Surge 依次接进了自己的工具箱。 Vercel 能看见项目，博客页面实际返回了 200；Supabase 能读到组织和两个项目；Surge 能列出五个站点，五个地址也都能正常打开。 如果只看仪表盘，这已经是一片绿灯。 但我很快意识到：三个工具都能用，不等于三个工具已经一起工作。 登录成功，只能证明钥匙是真的；页面能开，只能证明炉子还热着。真正的工作流，必须让一块原料从入口进炉，经过加工、落库、验收，再带着证据回到我手里。 01｜三个工具都亮了绿灯 先说现场。 Vercel 这边，连接器能正常读取账号下的项目，博客部署也能直接访问。我请求线上页面，拿到的是 200，页面标题也和预期一致。 Supabase 这边，组织与项目列表可以正常读取。两个现有项目分别在东京和新加坡，只是当时都处于暂停状态。这个结果至少说明：账号、权限和管理通道是通的；要进入业务链路，还需要先恢复目标项目。 Surge 更直接。命令行列出了五个站点： linkable-board.surge.sh aidatabase-squ.surge.sh aida...

研路炼钢 | 我把自己外包给 AI 一周后，发现真正不能外包的是判断 AI 可以替我检索、拆解、执行和校验，但不能替我决定什么值得做。主控的价值不是让更多窗口同时忙，而是把碎片推进成有证据的交付。 前几天我和舍友聊天，他说自己对 AI 的使用程度可能只有 10%，而我已经到了 70%。 他又补了一句：你几乎什么都问 AI，会不会慢慢没有自己的思考？ 这句话让我停了一下。 一周前，我刚写完上一篇文章：《我想把自己外包给 AI，最后先搭了一座“控制塔”》。当时我想得很完整：用一个空白项目做主控，再把论文、代码、博文和知识库分发到不同窗口推进。 真正跑了几天以后，我发现设计一个系统不难，难的是给系统装上刹车。 个人主控最重要的能力，不是帮我启动更多事情，而是更早地决定：哪些事情今天不启动。 01｜70% 都问 AI，不等于 70% 没有思考 我确实会把很多问题交给 AI。 查资料、拆任务、读代码、检查引用、生成初稿、排查报错，这些工作如果都靠我一个人串行完成，时间很快就没了。AI 在这些地方像一组可以随时调用的外部进程，能帮我省掉大量机械切换。 但“把问题交给 AI”和“把判断交...

研路炼钢 | 我想把自己外包给 AI，最后先搭了一座“控制塔” 多窗口不是生产力系统。没有主控、并发上限和验收回流，窗口开得越多，只是在用更高级的方式制造上下文切换。 有一次，我盯着 Codex 里一排正在工作的窗口，突然不知道自己应该先点开哪一个。 一个窗口在跑论文实验，一个窗口在改项目代码，一个窗口准备博文和配图，还有一个窗口在整理知识库。每个窗口都很忙，每件事也都看起来有价值。 问题是，我自己反而成了最忙的那个调度器：不断切窗口、补背景、确认方向、处理新的想法，再去检查哪些任务到底做完了。 我原来想把自己外包给 AI。后来发现，真正需要外包的不是“我”，而是我的项目调度系统。 01｜我以为自己缺的是一个更强的 Agent 最开始，我的解决办法很直接：任务多，就多开几个窗口；一个模型不够，就再加一个 Agent。 这套方法确实有效。AI 可以读论文、写代码、做图、检查材料，也可以同时推进几个互不相关的项目。以前需要排队处理的事情，现在可以并行。 但能力被放大之后，我原来的行为模式也被放大了。 我本来就容易“全都要”。看到一个想法会先启动，碰到一个项目会顺手优化，工具能跑...

研路炼钢 | 复盘六个获奖项目后，我终于明白：平台愿景为什么打不过一条证据链 比赛结束后，我和一位队友把获奖展板重新看了一遍。最初得出的结论很粗暴：有实物，大于无实物。再往下拆，我发现真正拉开差距的不是那块硬件，而是它背后那条能被看见、被测量、被追问的证据链。 先说明边界：这篇文章只依据现场展板、演示和个人记录复盘，不代表官方评审结论。涉及个人的信息均已脱敏，对评分动机等无法验证的内容也不作事实判断。为保护参赛者信息，正文配图使用脱敏重绘。 01｜我一开始只看见了“有实物” 我们学校是第一次做这种跨学院合作，校内是三选一。现场有长期参赛的学校，选拔强度大约是六选一；也有学校八支队伍来了四支。有人已经在这个赛道积累了十余年，我们则刚把第一套合作流程跑通。 从结果看，获奖作品里确实有不少硬件、传感器、穿戴设备和真实部署图。于是我很容易把它归因为：有实物的项目更占优势。 但这个结论只对了一半。 实物本身不会自动产生创新。它真正提供的是一种“信任压缩”：评委在几分钟里能看到输入从哪里来、算法处理了什么、输出怎么测、最后放到哪里用。纯软件当然也能做到，只是必须用更扎实的实验和真实数据...

今天折腾了一个看起来很简单、但实际很容易卡住的问题：在同一个内网里部署一个本地服务，让其他设备都能访问。 一开始我是在 Linux 上跑的。服务启动之后，本机能打开，局域网里的其他设备也能访问。后来我又在 Mac 和 Linux 之间试了几次，访问链路都是通的。到这里我基本确认两件事： 服务本身大概率没有问题。 当前局域网环境大概率也没有问题。 但问题出现在 Windows 上。 同样是把服务部署起来，换到 Windows 机器之后，本机看起来可以运行，但同一个内网里的其他设备就是访问不了。这个现象很典型：服务好像没坏，网络也不像完全不通，但从其他设备连进 Windows 这一步卡住了。 先把问题分层 这类问题最容易让人一上来怀疑代码、框架、前端页面、端口、路由，甚至怀疑是不是整个局域网有问题。 但如果 Linux 和 Mac 都能正常访问，就说明问题不能简单归结为“服务不可用”。 更合理的排查方式，是把它分成几层： 服务有没有真的启动？ 服务监听的是 127.0.0.1 还是 0.0.0.0？ 端口有没有对外开放？ Windows 防火墙有没有拦截入站连接？ Windo...

我用 AI 做了一个 20 秒视频，最后把项目删了 工具真正留下来的，不一定是那个文件，而是你对工作流的理解。 前几天，我用 AI 折腾了一个 20 秒的网站产品宣传片。 流程看起来挺完整：抓网页截图，做动画，配旁白，加 BGM，导出 MP4。中间还试了几版配音，从 macOS 自带语音，到 MiniMax 的 MMX 声线，再到背景音乐和音量混合。 最后的结果也确实出来了。 但有意思的是，折腾完之后，我把整个项目删了。 这件事反而让我意识到一个很实际的问题：AI 工具的价值，不只是“生成一个东西”，而是让你看清一个东西是怎么被生成出来的。 我一开始以为是在做视频 本节摘要：这节讲的是“做视频”其实不是单纯剪辑，而是在搭一条 HTML、CSS、动画、音频、渲染组成的工程流水线。 刚开始的目标很简单：把一个网站变成一个 20 秒产品 promo。 于是我让 HyperFrames 来做这件事。它的逻辑不是传统剪辑软件那种“拖素材到时间线”，而是把视频当成一个 HTML 工程。 网页截图是素材。 CSS 是画面。 GSAP 是动效。 音频轨是旁白和 BGM。 最后浏览器逐帧渲...

昨天和一个做产品的朋友吃饭。八两的帝王蟹端上来的那一刻,我们聊的话题已经从”他要做什么产品”转到了”他要做什么技能”。 这个转向本身就值得记一下。 一、从”卖产品”到”卖 Skill”,中间那一步是什么 他过去一直想做一个产品出来卖。这次见面,他的方向变了——他想做一个 Skill 来卖。 这两件事看起来像同一件事,差别其实很大。 卖产品,你卖的是一个能直接被使用的东西。卖 Skill,你卖的不是 Skill 本身——Skill 没法独立存在,它必须绑定脚本,绑定 Agent,才能跑起来。所谓卖技能,本质上卖的是 API 能力包:一段被规范化、被工程化、被可调用化的能力。 为什么这个转向在这两年突然变成显学?因为 Claude Code、Codex、Kimi 这一批 Agent 产品出来之后,大家发现”能力”是可以被封装的,而封装出来的东西有人愿意付费。 但卖 Skill 有个隐含前提:你得真的把一套流程跑通过、抽象过、压缩过。否则你卖出去的就是一个空壳子。 二、95% 的时间不是在写代码 我最近又在系统学 Agent 相关的东西,把 Kimi、Codex、Claude Cod...

研路炼钢 | 和一位延毕师兄吃了顿饭，他把读研踩过的坑全讲了（六）——简历不要写你做了什么，要写你能做什么 最后一篇。下午散步的时候，N师兄帮我看了简历，给了一些很直接的建议。说实话，有些话我听着不太舒服，但越想越觉得他说得对。 这篇是整个系列里最能直接落地的一篇。前面几篇更多是经历和判断，这一篇只有一个主题：简历不是工作记录，简历是能力证据。 01｜”我招人看简历，只看最后两项” N师兄自己开公司，招过人，也面过不少应届生。他跟我说了他看简历的逻辑： “项目经验，还有你的核心能力。其他的我基本不看。” 他说很多简历写了一大堆学生工作、社会实践、课程成绩什么的——这些他翻都不翻。 “我只想知道两件事：你做过什么项目，你从中展现了什么能力。” 02｜”不要罗列细节，要总结能力” 他看我简历的时候，指着其中一段说： “你写了’集成测距算法，计算路灯到摄像头的距离’——这个解决了什么问题？” 我说解决了路灯检测中距离计算的精度问题。 他说：”那你就不应该写你用了什么算法，你应该告诉面试官你有解决复杂工程问题的能力。” 他举了自己写简历的例子： “比如我不会写’我把战斗系统拆解成...

研路炼钢 | 和一位延毕师兄吃了顿饭，他把读研踩过的坑全讲了（五）——“技术是最不值钱的东西” 这句话是N师兄说的。他说的时候语气很复杂——他自己就是技术出身，他”非常憎恨这句话”，但随着阅历增加，他发现”说得好像不可逆”。 这句话很刺耳，也很容易被误解。它不是说技术没价值，而是说：只有技术，通常不够值钱。 技术的价值需要被放进一个完整链条里看：解决什么问题、服务谁、怎么交付、谁愿意买单、后续谁维护。离开这些问题，技术再强，也可能只是一个漂亮的局部最优。 01｜一个技术人说出这句话的重量 N师兄是我见过的技术很强的人之一。 高二开始学虚幻引擎，本科做外包，从几十块的小单做到几万块的项目；后来参与过复杂仿真系统，也把自己的游戏做到了上线。他长期保留代码日志、项目文档和备份记录，工程习惯非常扎实。 这样一个人，跟我说”技术是这个世界上最不值钱的东西”。 他知道我不爱听，他自己也不爱听。但他说了。 02｜”你代码写得再屌，那又怎样？” N师兄的原话是这样的： “你在不会写代码之前，写代码这件事情非常重要。但是当你真正写代码写得非常屌的时候，你会发现——这代码到底干什么用啊？” ...