EP 86
真正为我的工作而生的 Agentic Workflow
开场与申正奎代表介绍 0:00
卢正石 今天录制的日期是2026年2月15日星期天早上。今天时隔很久，我们频道永远的老师来了。Lablup的申正圭代表来了。申正圭代表最近发布了一款叫Backend.AI:GO的产品，花了40天时间打造，最终产出的代码大约有100万行。
我也在本地安装试用了，非常干净利落，我需要的那些功能都做得很好。所以今天请申正圭代表来，聊聊做这个产品的过程，包括之前的vibe coding和开发过程中的vibe coding，以及完成之后Lablup和申正圭代表发生了怎样的变化，让我们来听听这位在最前线引领这个行业的人的故事。代表，欢迎欢迎。大家好。我是Lablup的申正圭。
申正圭 感谢百忙之中邀请我。
Backend.AI:GO 产品介绍 0:55
卢正石 那么请先简单介绍一下Backend.AI:GO，然后聊聊开发过程，现在的agent coding到底应该怎么做，让我们来听听这位身处最前线的人的经验分享。
申正圭 Backend.AI:GO是什么呢，有些朋友可能知道，我们做了一个叫Backend.AI的AI infrastructure操作系统、运营体系，已经做了十多年并一直在提供服务，但实际上大家要使用的话，大概需要从100个GPU起步才能发挥效果。从100个GPU到上千个，这样规模的平台，所以普通人其实很难接触到。从2024年下半年开始，考虑到灾难发生时如何使用这些AI，比如医院或金融机构用云端AI，一旦云服务宕机就麻烦大了。这种情况下，就像备用发电机一样，就像医院或金融机构地下室里放的发电机那样，在那里放上GPU机器，当外部AI服务宕机时能够自主运行，我们就想做这样的东西。所以我们做了一个路由器。我们把它叫做Continuum路由器，2025年3月我们公开发布了。有个叫GTC的NVIDIA活动。今年也会去。大家多多关注。在GTC上公开了，当时反响很好。做了演讲，但在开发过程中体量变得越来越大。
我们的主要客户是enterprise，组件有19个左右，安装起来因为太大了，全部装完的话大家可能也用过的OpenRouter那样的服务，已经大到可以搭建一个那样的平台了。所以这已经是服务级别的技术栈了，而不是企业解决方案级别的技术栈。所以我们暂时把所有东西都搁置了，如果只能保留一个的话会保留什么，最重要的毕竟是路由器，所以把智能路由部分拆出来，其他功能先放着，把速度做到全球最快。于是从头开始重新做，去年8月从Continuum整个项目中拆出了Continuum路由器部分。到12月全部做完了。该发布1.0了。然后开始了准备工作。功能是什么呢，它是个路由器，
这个路由器具有converter功能，还有应对灾难的各种circuit breaking机制，如果某个节点出了问题，就暂时把它当作不存在。然后在那个被排除的节点上运行的模型自然地切换到其他模型，有这样各种各样的功能。但要公开发布的话没有好办法。东西很好但没法展示。所以决定要做Web UI，需要有看得见的界面才行。因为以前我们刚创业的时候也是一样的情况，已经快11年了。当时我们说要做机器学习运行平台，人家问怎么做，我们就打开终端开始演示。输入这个命令的话，当时TensorFlow都还没出来，Caffe2的配置这样列出来，还有当时流行的Theano这个工具也会显示出来。做过这些演示，但光这样不行，需要看得见的东西。正石当时也说过这个。所以我们还做了教育平台作为demo来卖。
Backend.AI:GO 诞生背景 - 平安夜的开始 4:11
申正圭 那天正好是平安夜。决定要做Backend.AI:GO是在平安夜那天。
那时候还不叫GO。大家都很好奇，这个Backend.AI:GO，
卢正石 Continuum路由器的产品化版本，长什么样，要不要放到屏幕上一边展示一边给大家介绍？这是一个充满私心的项目。
Backend.AI:GO Demo 演示 4:28
申正圭 本来也不打算做成这个样子的。
卢正石 不过我之前一直在本地装了Ollama和LM Studio这类工具在用，比那些干净得多，从工程师的角度来说需要的功能都做得很到位。
申正圭 是大家在很多地方见过的那种工具。看到这个界面觉得眼熟的朋友，大概跟我年纪差不多。
卢正石 有种Windows XP的感觉。模型方面，虽然它有路由功能，
申正圭 但基本上可以从Hugging Face搜索模型，选一个模型，这个是高质量推荐。但我的电脑比较慢，所以下载一个精简模型。大家下载后会在列表里这样显示。就会出来模型列表，这些模型真的太令人惊叹了。但是如果你想了解一下某个模型，那你可以看这里，有这样一个图标。点击它就会给你介绍这个模型。它使用的是Gens3架构，
量化方面原本是16位训练的压缩了4倍变成4位，在这种情况下质量还能保持95%大小缩小了一半。然后参数方面是这样的feed forward大约占60%，维度是词汇表现在用了大约26万个token。然后输入之后经过embedding和transformer通过26个transformer块生成输出。就是这样的结构。层的话，输入进来输出出去，然后输入在下面的原因是你看那些早期的attention相关论文全部都是输入在下面的。所以读论文的时候是从下往上看的，KV cache是在运行过程中持续保存中间结果的缓存，这个缓存会占用多少内存每种模型都不一样。有些模型的KV cache需求非常大的情况，也有根据架构需求比较小的情况。这些东西在这个模型里是怎么应用的它会计算后告诉你。接下来是实际transformer块的结构。它用了multi-query attention，不懂也没关系。大家以后可以用这个作为开始学习的起点嘛。所以它长这样，位置信息是通过这种方式编码来处理长文本的。这些内容都有。
然后如果要运行的话，点击运行按钮就会开始加载。
然后就这样跑起来了。加载好的模型去旁边的聊天界面就能用了吧。对，而且是在本地电脑上运行的。
如果你们电脑配置好的话，比如有NVIDIA GPU或者AMD GPU的话，可以在这里的引擎部分额外安装引擎来使用。这台是Mac所以没有那些。来测试一下。现在是1B的模型，所以别期望太高。
卢正石 很流畅啊。
云模型连接与分布式路由功能 7:02
申正圭 然后这里你可以看到还有很多其他类型的模型，也可以连接云端模型。看右上角的话有1个本地模型和15个API这样。刚才在模型里，从远程模型中也可以选择你想要的，全部模型集有175个勾选想要的就会出现在那个列表里。这些可以通过在API端添加provider的方式来实现。如果你们在用OpenAI或者Gemini或者Anthropic或者本地在用Ollama或LM Studio的话都可以这样连接起来使用。连接好之后可以看到是怎么连接的。毕竟本来就是路由器UI嘛。就可以这样查看，延迟时间之类的都可以查看。
如果装了多个，有的在别人电脑上那就可以在这里添加，比如说像我们的情况，如果办公室里8个人都装了就可以把这8个整合起来，比如我在自己电脑上做图像生成或者同时跑多个文本模型的话电脑性能是不够的嘛。那就分配到旁边同事的电脑上去跑，结果大家也可以互相共享使用。某人的电脑上跑图像生成，某人的电脑上跑文本模型，某人的电脑上跑PDF处理之类的各自在跑但我的电脑上都能用，同样我正在跑的模型办公室里其他人也可以用，就是这样的。或者买一台好的电脑或工作站在那上面跑然后从这里连接也行。这类功能有很多，
卢正石 您觉得自己需要的功能都做好了吗？是的。翻译器之类的也做了放进去了。
申正圭 Lablup，它会把Lablup翻译成”rabble up”。所以可以添加这些修正，或者以此为基础也可以整个文件翻译。放入PDF、TXT或docs的话它会保持原格式进行翻译，放图片也行。就是有各种各样的功能。
卢正石 GenSpark那些功能您全部在本地实现了啊。
申正圭 然后因为现在有好几个主题，默认安装的话你会看到这个或者Mac的话有毛玻璃主题之类的，或者这个是我兴趣做的。这是最近token有剩余所以额外加的主题。就是这样一个奇怪的工具。是一个非常带有个人偏好的工具。
开发过程 - 40天、130亿 token、100万行代码 9:06
申正圭 一开始并不是说要做成公司产品好好搞而是想做路由器Web UI的时候需要有路由的对象嘛。我更喜欢llama.cpp，在跑llama.cpp的过程中手动操作实在太麻烦了。所以就把llama.cpp自动化了放进Web UI之后越做越大，然后突然觉得DeepL的订阅费有点可惜。于是就有了翻译器，然后因为画图的需求很多就把画图功能也加进去了。画图模型里有很多很好的模型。云端的这类模型也一直在增加。因为是路由器所以有统计功能，还有基准测试，
不知道哪个模型多快所以需要基准测试。这些功能就这样一个个加上去了。可以对比2个模型然后导出结果。什么都塞进去了啊。
崔胜准 这些大概花了40天做出来的吧。
卢正石 总共制作过程中消耗的token数量是
方便公开吗？我做这个的时候，Claude Code Max基本开了2个在跑，不够的时候就按需追加付费，在8台PC上跑的。用VM或者PC跑的，所以刚才说了是从24号开始的嘛。总共用了大概130亿个token。到这个项目走到这一步为止。然后从12月24号开始做，在CES上做了首次公开。
申正圭 之所以变成Backend.AI:GO，是因为做出第一版后在内部分享了一下，反响特别好。说这哪是什么Web UI啊，这东西可以替我们做宣传。于是就给它起了名字，变成了Backend.AI:GO。觉得这可能会成为面向普通用户的第一款产品。
之后成员们只要在issue tracker上登记，就能自动开发。就这样既报bug也提新功能需求，跑一个自动开发的harness，中间不断有人介入修改UX，来回给反馈，就这样花了十天。从2025年12月24号开始做，到1月6号在美国CES上做了首次demo。然后那个说白了就是MVP。虽然确实能跑，但只是个产品雏形，之后的开发比那个又推进了大概4倍左右。当时去CES的时候大概是0.9版本，那时候您给我们看过，
卢正石 从那之后到现在已经到1.1了，完成度提高了好多啊。所以今天的主要话题其实从现在才正式开始。您做出100万行代码的那个过程，
Agent coding 的教训 - token 竞争力与高速 inference 11:30
卢正石 以及在那之前接触Agent编程的经历，还有做这个过程中的感悟，因为那些现在改变了的流程和方法论，您之前提到过嘛。要不从那个话题开始聊聊？
申正圭 我觉得这也只是一个阶段性的分享。先说一点，开始开发这个产品的契机是他们说是holiday season，Anthropic搞了个token翻倍活动，那是起点。就想着还能再做点什么，然后就开始了。但反过来说，能使用的token量跟一家公司的，尤其是IT公司的竞争力直接挂钩，这是我得到的第一个教训。第一个教训是这个，第二个教训是投入这么多token，人们给了反馈，当开发本身不由人来做的产品出现时，会产生几个bottleneck。比如说大概半年前，merge queue是bottleneck。因为开发速度太快，它们自己写的代码之间会冲突。但到了现在这个阶段，merge queue已经不是瓶颈了。解决merge queue也不用人了，它们自己处理，甚至我无意中测试过的一种情况是两个AI在同一份源码上竞争，各自开发不同的功能，最终那些功能都能完好地开发出来。进步到了这种程度。所以到了下一个阶段，核心问题就变成了如何少用token。
做同样的事情时，为了提升性能，模型通常选择的方法是用于in-context learning的不可见的thinking token，也叫thinking budget。在朝着增加这个量的方向不断进化，这个量增加当然最终结果会更好，但同时也意味着开发速度会变慢。所以怎样让它少thinking还能做好开发，而且少thinking本身就意味着开发速度会变快，在最终所有人都用AI编程的世界里，速度会变得非常重要，而加快速度的方法有两个。一个是让它生成更少的token却达到同样的结果，这是第一个挑战，第二个是真正把token生成速度做得非常快，这是第二种方法。最近就需要high-speed inference了。不是我们熟悉的ChatGPT做code generation的那个速度，而是能跑5到10倍iteration的超高速inference会变得非常重要。这两点是我最大的收获。
做了这个之后。前几天出的Codex Spark，就是那种东西吧。
然后很巧的是Spark也开始提供服务了，看来大家看的方向是一样的。
最终这场竞争会走向高速inference市场，产生需求，有充足资金的人会通过高速inference来提升竞争力，没有那么多钱的就得想办法让它少思考。
需要高性能的地方让它多thinking，不需要高性能、只是简单作业或编码的地方让它少thinking，怎样应用adaptive thinking budget，或者怎样做一个能动态调控thinking budget的harness。今年冬天大概就会围绕这个方向发展吧。
卢正石 毕竟都是trade-off嘛。确实会开始思考这些问题。什么都让AI来做，
生物 token - AI 时代人类认知负荷与多巴胺 14:38
卢正石 等待的时间就开始让人有点烦躁了。确实等待时间是个大问题，但也正因为有了等待的时间，
申正圭 个人来说反而有了思考的契机。不是思考AI的事。而是开始思考关于自己的事，
卢正石 最近大家把这叫”生物token”。有人说，能花在生物token上的时间变多了，挺好的。我们有位朋友这么说的。我个人的感受是这样的。大概在前年的时候，
申正圭 我开始把一部分编码工作委托给ChatGPT，跟它一起写代码，从去年4月开始发生了巨大的变化就这样过了大概9个月，白头发增多了。白头发增加了很多，而且开始睡不好觉了。最忙的时候6月7月那会儿，5小时refill出来之后觉得5个小时太宝贵了，就跑3个半小时，睡1个半小时就那样过了一段时间后来这些也逐渐实现了自动化代码本身大概有70万行总共写过的代码大约是120万行。而这120万这个数字对我来说个人而言非常有象征意义以前做TextCube项目的时候我花了3年写的代码全部加起来大概100万行。而同样规模的代码量，这次40天就写完了。某种意义上人生被极度压缩了用一个月时间写完了Backend.AI:GO写的过程中我在想，我真的只付出了40天的努力吗。回头看感觉老了3年。作为一个人来说。认知负荷并不会减少。
无论你把多少事情交给AI认知负荷不会减少反而因为反馈不断涌入人的生活会变得很憔悴。但做的时候确实很开心。因为就像玩游戏一样，做了什么之后
多巴胺就会注入，这跟最近流行的手游抽卡很像。花钱抽角色做各种事情赢了就会有即时反馈嘛。人们就是喜欢这个。用agent来写代码的过程会基于那种速度给人带来某种快感。因为以前对我来说是大工程的事情或者觉得自己达不到的目标现在能实现了。虽然是我达成还是它达成有区别但总之它就这样提供某种多巴胺。不过说”提供多巴胺”其实不太准确。
但在被动接受多巴胺的同时，也在被不断地索取。因为做得顺利就会想做更多，做更多又很顺利，于是人就没法从中脱身陷进去之后确实能做出东西。确实能做出来，但会产生两个问题一个是像刚才说的，生活变得过度依赖变得憔悴。第二个是一旦某个时刻断掉了那个产品也会死掉，正在做的产品也会死人也会离开，虽然可以去找下一个产品去寻找下一个产品。因此我开始预感会有大量被抛弃的产品出现。这个角度有点不同这是另一个层面的问题
软件过剩时代与即时应用的出现 17:42
申正圭 以前软件行业或者说开发软件是有进入门槛的所以一旦做出某个软件只要能找到用户就能持续维护下去。但是快速开发出来的软件维护的意愿相对来说会弱很多。因为没有付出那么多心血的话如何管理维护这个问题其实一直都是交给AI的就会变成”交给AI做就行了”同时做类似事情的产品会在世界上大量涌现。比如说实现某个特定功能的某个开源项目只有一个。那用户就会聚集过去让它越做越大但这种现象以后会少很多。简单的项目自己做就行了。稍微复杂一点的产品世界上已经有几十个了。为了维护一个产品人类所需要获得的多巴胺的绝对量会下降。以前博客时代也有类似的情况博客的评论区全部转移到Twitter讨论之后很多认真写博客的人都放弃了。因为他们的主要动力之一就是评论区里来往的社交反馈。但那些反馈转到其他平台后就彻底消失了，同样地大量无人维护的开源产品将会涌现。所以我们将生活在一个软件极其丰富的世界里但其中大部分软件寿命不会太长。其中只有极少数能存活下来，剩下的要么用完就扔，要么留下两种结局。一种是从一开始就按用完即弃的概念来做的即时应用的概念，需要的时候就创建如果经常用就保存下来至于要不要保存比如说Google会帮你决定。Google开发的那种复用性较低，但能快速创建快速使用的即时应用将会大量出现其余的软件最终会先大量增长然后再收缩回去，我是这么认为的。人类生活所需的软件种类其实没那么多嘛。我用智能手机的时候有个感受智能手机早期，你们可能不信智能手机早期是没有文件夹功能的。应用文件夹。所以比如iPhone的话所有应用都直接显示在桌面上。然后就要翻9页什么的。后来有了自动整理功能，也有了应用文件夹功能然后某一天人们发现了一个事实。一个人使用的应用不会超过30个。而按使用频率来算，前10名的应用占据了总使用量的90%以上。这样就理清了一次。这些存活下来的应用有个共同点一是基于sociality。这个app并不是提供自身的使用价值而是提供只有通过这个app才能创造的使用价值第二种是与我们的life、日常生活密切相关的app比如办公类app 或者说是生产力也就是所谓的productivity app帮你整理文档之类的 像Obsidian这样的工具还有DEVONthink之类的 各种工具都有但这些工具有一个共同点就是它们都是长期存在的app就像刚才说的某个product 我们说产品吧有人持续维护和发展这个软件 这种有保障的产品最终才能存活下来开源也是一样的道理那些被广泛使用的开源之所以被广泛使用是因为它让人确信不会很快消亡
卢正石 就是品牌建立起来了某种承诺已经在市场上传播开了软件的数量虽然会猛增
申正圭 增长还会持续 但被广泛使用的软件数量我觉得会维持在一定水平 这是我的想法到今年下半年左右即便说SaaS要崩溃什么的
最终那些SaaS都是可以自己做出来的Lablup的revenue officer亲自说Salesforce不怎么样自己就做了一个两天时间就做得像模像样的
尽管如此 最终现在还是买了其他方案买了更便宜的其他方案在用买来用的原因就是反正其他事情也能以同样的速度完成的话不需要我做的事情 确实不该自己做所以SaaS市场不会消亡但现在在SaaS市场上成功的那些一年后是否还能成功 就不好说了
卢正石 范式正在剧烈变化 所以很难说会怎样看到SaaS公司的股价下跌确实挺神奇的 但其中有些会存活下来与AI结合后打造出非常坚实的模式也有可能会重获新生因为有品牌在 那件事它做得最好在AI时代我们也做得更好也有可能会变成这样正圭刚才说的 正处于所谓的大变革期移动时代的大变革期也有过无数竞争AI时代 我们已经习以为常的环境正在发生变化在这当中是否还有我的机会所有人都在蜂拥而上我觉得现在就是这样一个时期
从软件历史看第三次大变革 22:38
申正圭 软件正在经历一次大变革 这是确定的正因如此 大家都在说要做软件这种话也听了很多 我们公司内部也举办了大量研讨会 互相讨论在思考未来我们该走哪条路开始之前简单说一下这样的变化以前也发生过几次我们没有亲身经历过的那一代变化的话就是从打孔卡打孔、在OMR卡上涂卡突然变成用键盘写代码在方法论上发生了巨大变化然后一些小的变化就是在编辑器里可以用方向键移动光标来写代码 现在可能难以理解但以前是做不到的把多个源代码合在一起做成程序之类的
再往后一个大变化就是智能手机的出现我们在搭建技术栈时 以前是以独立打包的所谓的package软件为核心然后考虑怎么deliver 比如从介质来说是用CD还是磁盘 或者我们叫ESD通过电子传输的方式来分发也有这样的讨论 还有freeware这种方式还有shareware 就是先用再付费然后还有商业软件去商场花钱买的那种 从这种分发模式智能手机和web大约相隔十年同时进入了社会通过网络来deliver甚至连deliver本身都不需要了通过web浏览器在远程运行的软件 我们说远程安装的软件现在我们通常叫web服务在远程运行的某种服务以服务形态存在的软件随之而来 开发相关的东西发生了很大变化web服务器变得重要起来支付系统之类的安全相关的东西也经历了一次大变革 然后在UX层面从以键盘和屏幕为中心突然出现了非常小的设备 或者屏幕大小可以变来变去的设备 输入方式也从物理键盘变成了触摸键盘这些都是巨大的变化 现在大概算是第三次这样的变革吧
这次变化的是 刚才说软件本身也一直在变但现在正在变化的软件我们通常说软件就是写代码把那些代码叫做软件运营这些软件大部分是developer来做的Developer们在做 然后转向web之后需要operation 于是产生了ops这个职种而这两者在web服务中需要非常紧密地融合所以就诞生了DevOps这个领域既做开发也做运维然后在这个过程中 技术栈也是以前所有人都写所有代码变成了web服务的形态之后就有了所谓的backend 负责逻辑和服务器端的人然后做用户实际使用的界面或者设计用户体验和实际交互的frontend这个职种也单独出现了然后统管这些做规划的 或者说我都能做这种fullstack的概念也出现了 变得很多元所以核心是这个以前写代码这件事大约70~80%，而实现运营服务栈的部分占20~30%。大致分成这两块我们开发智能手机应用或者Web服务的时候，至少我们的下一代，如果不去学习这些概念的话以后就完全不会懂了，我是这么想的。因为现在我们做了Backend.AI:GO这个项目
코드의 가치는 0으로 수렴하는가 25:57
申正圭 上周五去参加了一个座谈会，在那里分享了一下在座谈会进行的过程中座谈会是从10点开到12点的。10点进去之前，我在咖啡店把代码review完提交了座谈会结束后一看大概有22个、21个PR提交了测试跑完，merge也都完成了。如果能达到这样的节奏实际上代码的价值就趋近于零了刚才提到的DevOps中developer做的事情如果工作种类不彻底改变的话，这些人要么会失业要么就会陷入比较困难的境地。但实际上这些人也会变得非常重要。软件本身不会凭空消失的。在我看来，现在说软件危险了其实并不是软件本身有危险。就像软件的定义从OMR卡片打孔
演变到键盘编程一样，从键盘编程转向传达语义编程在不断演变，这会是一个持续的过程如果是这样的话，我认为产品的核心价值来自于引擎，所谓的引擎就是我们现在称为代码的部分所处理的东西本质上就是逻辑嘛。代码本身不是目的。我们为了创建某个服务为了让计算机处理这个服务把逻辑实现出来的东西我们称之为代码它的优点是确定性的。源自冯·诺依曼架构的顺序处理逻辑以及将结果deliver给用户的过程全部都是标准化的当然中间的medium是非常不稳定的比如网络啊、存储啊都是不稳定的但不管怎样，在其上运行的逻辑体系本身原本是固定的。到目前为止是这样。但是代码的目的是处理某种逻辑让事情运转起来，从这个角度来看
这部分以后大多数都会由深度学习模型或者派生模型来承担，具体是什么还不知道。不一定非得是Transformer嘛。另一种处理逻辑的引擎部分会接管目前代码所负责的大部分工作这是我现在的想法。其实世界已经对此做出了判断。
卢正石 事实上做模型的公司现在几乎占据了大部分的价值不是吗。做硬件的公司和做模型的公司而在它们之上的那些层现在都在被挤压不就是这么回事吗？正如您所说
申正圭 价值往那边转移也是非常自然的所以未来所谓的软件内部会有一个AI核心引擎外面包一层控制层，使其像以前一样确定性地运行再加一个这样的layer这部分会具有重要的价值。我自己做了很多尝试
现在用了Claude CodeCodex当然也试过了Copilot不知道还有没有必要提，但也用过了Gemini CLI也在用。比如说Gemini CLI或者Codex这些，用Backend.AI:GO的话可以接上去在Claude Code里面直接使用。只要切换backend模型就行。但这样跑下来我发现
Claude Code 的真正竞争力是 harness 28:54
申正圭 Claude Code的核心竞争力不是Opus或Sonnet引擎。而是Claude Code本身。传统意义上的软件领域存在这个软件在刚才说的模型外面包裹着它，让它确定性地运作的这个软件逻辑这个东西非常强大，我越来越这么觉得。同样的模型，接到Claude Code上就能运行得非常好。
卢正石 用Claude Code harness连接不同endpoint的时候您觉得哪个感觉最好？比如说Claude Code harness接上Codex 5.2这样用的时候感觉不错，有这种案例吗？
申正圭 Gemini 3 Pro。
Gemini 3 Pro。
卢正石 那我今天就得试试了。令人惊讶的是，Gemini接上Claude Code也能跑得很好。而且context窗口很大。这种模型占80%，外面让它变得确定性的逻辑代码。这就是传统的代码。大概占10%，加上让人和系统交互的UI/UX，或者AI之间的UI/UX像A2A啊MCP之类的我觉得都是过渡性的，这些加起来大概占10%，这可能就是未来软件的定义了。未来的软件不知道会不会到我们下一代
申正圭 到那时候学软件的意思就是其实是学模型是什么、模型是怎么运作的当然这些会出现在历史书里。我们也知道以前用穿孔卡编程，虽然没有切身体会但作为知识是知道的嘛。以前软件是那样做的啊穿孔卡之前是用真空管进去抓虫子所以叫bug啊这些我们作为知识是知道的。就像那样，以前软件是人手工写的啊哇那怎么全靠手写啊看到有人在写代码显示器旁边放着键盘旁边有人比着V字拍照，就像在历史书里看到的那样会以那种感觉来看待软件大概下一代的核心是直接负责那种逻辑的模型是什么如何构建模型，从模型的历史一路学起。这些内容大概会成为计算机科学的一个重要组成部分吧。我们传统上
计算机工程的未来 - 走向历史角落，还是被重新定义 30:53
卢正石 在计算机科学里学的数据结构啊、算法啊、OS、网络这些内容很多都要被淘汰了吧。我认为这个速度会非常快。会比想象中快得多，
申正圭 正因如此，在这次变革中大家现在都能感受到的是，它现在不是处于某个固定速度的区间，而是处于加速区间，所以我们能看到加速度本身也在增大的趋势。
卢正石 也就是说加速度的数值也在增长。
申正圭 没错，加速度也不是恒定的。也有一些加速度保持不变的领域。比如说我们训练模型时使用的算力，每年都在以十倍的速度增长。但那个不可能一直这样增长下去。地球提供的物理极限，在地球上人类能达到的极限正在逼近。但是其他方面还在持续加速。比如说如果training的加速曲线无法维持的话，就在inference上投入更多资源，然后单次inference的in-context learning中通过增加token数也无法达成的话，就增加agent swarm的规模，也就是所谓的agentic AI，把多个agent组合起来使用。像这样，需要扩展的加速区间的领域一直在变化。inference承担了加速区间的角色，然后是agentic AI，数量从一个到十个、十个到二十个这样parallel地扩展，加速区间已经转移到了这个方向。就这样不断地转移，维持着这条曲线，所以这种变化我们虽然感受不太到，但据我所知以前曾经发生过一次。
那就是阿波罗计划的时候，最终达成了目标。登上了月球，之后就像大家都知道的那样，人造卫星覆盖了整个地球。现在已经无法再想象那之前的状态了。之前的那个阶段，我们觉得不是理所当然的吗，和美国的人通话也觉得完全是理所当然的。总之在那之前有无法想象的人们存在，我觉得现在正好就处于那样的曲线上。应该说大概是Gemini计划刚刚制定的阶段吧。跟太空开发比的话还没到阿波罗阶段，大概就是刚刚成功把人送上太空的那个阶段。
卢正石 在我们回到agentic编程话题之前，想最后问正圭一个大问题，然后再往下聊。其实最近大家都挺累的。因为大家都感受到这个加速度在不断增加，所以都在努力，但是我这么努力到底有没有意义。因为别人也在做跟我一样的东西，在价值观的范式转变还没有发生的情况下，用过去的框架来面对未来的感觉。所以感觉视角需要以某种不同的形式去转变，现在就算说错了也没关系，脑海中浮现的那些想法——“我觉得现在应该做这样的事情”就随便畅所欲言吧，您觉得有哪些？
Stanford CS 课程变化与英文系类比 33:54
卢正石 未来会变成这样的，所以不要太担心这个，现在最重要的是做这件事——如果硬要总结的话，能想到什么
就请说说看？我们公司Lablup上周发生了一件事，CFO有点崩溃了。因为CFO需要写一些东西，但怎么想都是交给我来做快得多。我又不是自己亲手处理那些，在旁边看了几次之后发现，交给正圭的话三分钟就能出来的东西，自己却要花两小时。于是开始交给我处理，最后开始用上了Claude Code。花了三十分钟学习之后，最终自己也能在三分钟内搞定了。同样，我们做内容的同事也需要制作大量的资料。从官方文档到营销材料、技术文档等等各种东西。跟这些人反复沟通、交换数据、自己再整理，这个过程实在太累了，来找我倾诉之后那位也变成了Claude Code的忠实用户，出去之后不到一周就搭建了一套庞大的harness。在GitHub上，而且两位都是，两位其实都不会直接用GitHub。他们是做了能帮自己操作GitHub的命令。两个人的工作状态变得非常平和了。就是那些比较复杂的事情嘛。比如说最近很火的Claude Code插件里面，有一个特别火爆的，说什么把法律界都搞乱了之类的，也不是那种，根本不需要走到那一步，从非常简单的东西开始的。从什么都没有的状态开始，先从创建CLAUDE.md开始，通过self-feeding，自己构建自己的东西，这个过程大概花了三十分钟，之后两位都——虽然都不是程序员——进入了加速曲线。那个经历对我个人来说印象很深刻，刚才说到软件的重要性是不是会逐渐消失，在我看来应该是完全相反的。所有人都会进入这个AI的加速曲线，而且很快就会，就在这次Claude Cowork——CFO学会使用的那天，晚上Claude Cowork的Windows版就发布了。反正用那些工具也能做到同样的事情。虽然权限会受到一些限制，当所有人都开始使用这个东西的时候可以说现在的关注点还在技术层面，或者说是程序员、研究人员，这些和计算机打了一辈子交道的人为中心先是兴奋，然后是焦虑，然后是FOMO，走的是这条曲线嘛。同样的事情会传递到比我们想象中更广泛的人群当中去。大概在不太久的将来，当然也会有被边缘化的人。比如说那些和计算机完全没有关系的人会接受得更晚，他们是在和自己一起工作的机器人到来的时候，机器人开始和自己一起工作的时候才会第一次真正感受到，这个变化现在看起来已经很大了但其实还只是茶杯里的风暴。即使是像我们这样纯IT公司也有之前一直处于边缘、最近才加入进来开始感受到加速的人，而且这个方法其实并不难。和AI一起工作，比如说要下载skill，有几十个skill，下载这些之后我也突然变强了，在我看来这是空想。那样做的话你的工作量是不会减少的。基本上要想进入这个加速区间不是从复制别人做好的、属于那个人加速区间的skill之类的东西开始而是当你开始做自己的东西那个加速才会真正开始。因为核心必须是自己的工作量减少。不是去学新东西学别人做好的什么东西而是把自己现在在处理的事情不断地委托出去，这样做要快得多大家很快都会感受到的，到那时候会带来和现在不可同日而语的冲击我个人是这么认为的。真正的浪潮从现在才开始。而且那些新进入的、IT之外的，虽然在IT行业工作但不是做编程的人开始适应之后我们刚才之前说到的training、inference加速曲线加速曲线保持的区间一直在转移，下一个转移的方向大概就是扩散性。和现有的使用场景相比完全不可同日而语在更多样的领域被使用从而维持住这个加速区间吧。
崔胜准 虽然很讽刺，但现在正是以匠人精神打好计算机科学之类的工程基础的好机会嘛。因为以后这个学科本身可能就不存在了。学科本身不会消失。只是学科的性质会改变。
申正圭 我觉得计算机工程本身不可避免地重要性只会越来越高。它会变成一门理解社会如何运作的学问嘛。从这个角度来说重要性确实会增加但和我们现在看到的计算机工程形态会有所不同吧。Stanford大学，
卢正石 Stanford CS的课程体系怎么变化我觉得很好地反映了最前沿的动态大约三四年前博士课程或者研究生才学的东西现在都是本科二年级的课程了。现在本科二年级和三年级初的课程都已经在YouTube上公开了大四在学什么我都不知道了。我也好久没关注了，得去看看。大一基本上是通识课之类的以前有用PyTorch编程之类的课程那个好像也没有了。
这真的很反映时代，在计算机科学和工科这些流行之前，很久以前的时代英语系是最好就业、最优秀的专业。因为学英语带来的收益是压倒性的。但现在看计算机科学，感觉正在变成英语系。学会了这个之后，拿着它去更广阔的世界闯吧，大概是这种感觉。我觉得正在变成那样。我们进入原本预定的主题吧？那我先分享一下这个。
Agent coding 实战 Demo - 从构建上下文开始 40:00
申正圭 重点是，在看的各位会发现其实并不难。只要装了Claude Code或者Gemini CLI就可以试试看。这就是我的VM。那我就随便试试看。试什么好呢？那试什么好呢？
先来试一个和编程距离最远的事情。写一段春节祝福消息试试？春节，和卢正石崔胜准AI Frontier相关的来试试。我就直接运行Claude了。
顺便说一下，我不是跳过permission，而是在VM里面运行，省得中间要一直点确认。
卢正石 这也是个好技巧。在自己电脑上跑那个我没那个勇气。那我们开始试试看。
申正圭 不过有几个技巧，我们通常是把自己想要的直接指示给AI嘛。给Claude AI模型。但基本上模型有它自己知道的知识不管有没有RAG，通过in-context learning它能探索的空间就确定了。如果我们有想要的东西不要一步到位地直接说出来我个人觉得这样效果会好得多。比如说现在要做的这个，先探索一下卢正石崔胜准的YouTube频道然后告诉我都讲了什么内容。我去年年中之前一直都用英文写的。
因为有token数量的问题，而且觉得用英文效果会更好这样一种想法。但从秋天开始我就直接用韩语输入了。原因有很多。一个是质量上并没有太大的差别。第二个原因是，我发现我自己才是瓶颈。因为我打英文本身就是瓶颈。我创建的skill和command，这些都是用英语写的，因为我让它用英语来写。但我自己输入的消息用韩语打，甚至连键盘都不用，直接按Mac上的麦克风按钮，用语音输入要快得多，所以从某个时候开始我就全部用韩语输入了。供大家参考。不过如果大家要创建skill或command的话，如果是用韩语写的，让它帮你转成英语，
在token方面可能更划算。
崔胜准 您用敬语吗？我一直用敬语。
卢正石 我觉得这是对AI的一种respect吧。倒不是因为这个，还有另一个原因。从一开始我就用敬语了。
申正圭 因为我们打交道的对象大部分是人，偶尔用用AI倒无所谓，但如果大量使用AI，再去和人交流的时候就没办法了。毕竟是人嘛，不知不觉中我的说话方式会在两边相互影响。一旦开始对AI说随意的话，我可能也会对人说随意的话。所以为了警惕自己的习惯，我坚持用敬语。不管对AI还是对人，我都用敬语，
为什么对 AI 使用敬语 42:41
申正圭 以防自己不小心说出不礼貌的话。这是我个人的做法。
卢正石 我一天中也有一半以上的时间在跟AI对话。
申正圭 所以我会说很多看似没必要的话。比如对AI说”好的”，其实完全没必要说这种话。就是结果出来的时候。但我还是会说，不是因为这样做结果会更好之类的原因，得让公司买台电脑了。您可能需要加内存了。内存成了瓶颈的时代来了。
卢正石 三星电子和海力士的股价持续飙升也说得通了。那么我们在卢正石和崔胜准的YouTube频道上，
申正圭 从给订阅者发送2026年春节newsletter问候开始，之后每当有各种活动的时候，尝试撰写并发送通知邮件。在这个过程中做了很多调研。需要考虑的事项有哪些呢？现在正在持续询问所需的内容。
崔胜准 是在积累context吧。把这些内容放进context里。
申正圭 这样一路做下来之后，我想做的事情是有的。我们现在要做的是这个。要做这个，但不是通过现在这段对话来直接完成它。而是要把整个过程全部自动化。所以在运行的时候我们继续闲聊吧。所以通常我会同时开五六个窗口来工作。如果token生成速度变快的话，越快的话这个步骤就越不需要了，迟早会消失的。您同时跑大概8个吗？我大概同时跑3到4个，
卢正石 七八个的话我实在跑不了。我最近不会跑那么多了。
申正圭 毕竟token很快就会到limit。它说那我们具体推进吧，但我们要做的
自动化核心 - 不是做结果，而是做生成装置 44:36
申正圭 不是推进这件事本身。而是要搭建一个项目，让这些工作都能实现自动化。平台搭建现在先不做。先不做那个，就做到邮件撰写吧。请把需要的内容写在MD里。这样的话基于上面的内容，这个项目里会生成一个叫CLAUDE.md的
类似soul document的文件。不管我们用Claude Code还是Claude Co-work，只要在这个文件夹里启动，它都会最先读取这个文件。大家应该都很熟悉了。但就是先把它创建出来，然后不断反复打磨，把需要的东西逐步添加进去。
崔胜准 但您刚才不知不觉没说AGENTS.md，而是说了SOUL.md。
申正圭 我通常称之为soul document。像这样，这里面会包含基本内容，也会有文件夹结构，但我们还需要把它应该始终执行的行为也写进去。里面有目录结构的内容吗？第二件我通常会做的事情是记录工作进行到哪里了。当多个agent分工协作的时候，关于进展到哪里、需要做什么的内容，分别记录，这只是个人偏好。用PROGRESS.md和PLAN.md来管理吧。然后每次重新开始的时候读取这两个文件，让agent知道自己需要做什么。这样来更新CLAUDE.md吧。当我刻意要给其他agent分配任务时，我经常用这样的措辞。比如”当你之后要接着做某件事的时候”，或者”重新启动时你可能会忘记所有内容”，这类表述我会尽量避免。不是因为别的原因，而是Claude模型本身被设计得非常defensive，而且根据最近的研究结果，它能察觉自己处于被测试的环境，正是因为这种context感知能力，导致很多测试失败了，有这样的研究结果。所以为了不让它变得防备，现在交代的这些任务不是要修正你，而是要准备给跟你协作的其他agent用的数据，我会在不知不觉中暗示这样的意思来写。我是这样构建的，这样它就不会觉得自己的存在受到威胁。说着说着总是会拟人化，但这不是拟人化。这个模型生成token的方式就是这样设计的，所以我们要去适应它。不能理解为它真的在那样思考不能那样去理解。只是结构上就是那样的。token生成结构就长这样。刚才记录了两条对吧。那么在做这些事情的时候需要什么样的agent、command、skill，思考一下然后把想法告诉我。我不是让你去做。如果直接让它去做的话因为缺少Claude Code这个上下文它会在当前工作项目的根目录下的子目录直接创建出来。但如果我们要和Claude Code harness集成的话都得在.claude目录下按照准确的规范来创建。所以会有那个步骤。归根结底搭积木就是这样的。我想做什么是很清楚的但那只是在我脑子里清楚为了把它放进Claude Code的上下文记忆里。有些我不知道的东西它也能知道。它会不断让AI去做预先调研。
崔胜准 可以理解为一种offloading。现在它说这些需要command
申正圭 那就调查agent command key的结构之后按照那个结构在下面把上面提出的那些创建出来。我会加上”按照准确的格式”。因为Claude Code用的不是纯markdown前面是YAML后面是markdown。那个slash command是
崔胜准 创建让Claude调用的slash command吗？大量使用command的原因是
sub agent와 병렬 작업 운영법 48:45
申正圭 子agent没法调用其他子agent。去年初到年中还可以但因为经常出现无限循环就取消了。command可以把多个子agent并行执行或者做chaining。所以它是为了从外部使用的而且agent也可以调用command。所以正在开发中。你看如果直接让它做的话，它不会加这些东西。
崔胜准 但去年夏天之后正圭说的时候写规范大概要花二三十分钟现在风格又变了呢。
申正圭 现在不用写规范了。就是通过这样的禅问答
卢正石 一起构建上下文。而且时间差不多也是30分钟左右
申正圭 后面20分钟打个比方就是用来”折磨”它的。我来演示一下怎么折磨。
卢正石 我在实际工作中也感觉到，就算前面不一定需要每次新开会话都要先让它读取所有内容之后得先铺垫几轮对话它才不会脱离上下文跑偏。所以做alignment的时间开始的时候总是得花的。
申正圭 为了后续可以参考，添加保存和读取的功能让agent和skill都能使用它。这样做的原因是每次从网上调研都很费时间。这个存在哪里呢？
崔胜准 就是预先做一个cache。就叫reference吧。这样的话调研的内容都放进去
申正圭 之后创建的时候、写文档的时候都可以基于那些内容。可以自动更新它或者搜索有没有新内容并添加进去做成command或者agent都行。现在来折磨一下试试。
一直输入的话它会做queuing。所以我通常会一直打字。要基于这个来构建的话需要退出再进来。因为刚才创建的skill set这些默认是没有被识别的。做完之后就这样退出再进来。做完之后。正圭用Claude Code或者用这类工具的时候
卢正石 外部做的那些额外harness比如用TDD来折磨它或者让它做超多工作或者拆分任务分发出去那些一般不用吗？
申正圭 一个都不用。我的目的是让自己的工作量减少。反正我跟团队强调的也是这个之前打这个出来的有个叫dev-workflow的东西。在Lablup多人协作的情况下有一些统一规范的harness是有的但除此之外尽量从减轻自己工作处理自己想做的事情开始，我建议这样做。先铺好skill刚才也是针对某个工作
卢正石 一开始做的是铺设背景的工作那些也是跟脑子里的目标做最基本的alignment程度的seeding可以这样理解吧。不会多加没必要的东西。
申正圭 看这个的人里面写代码的应该能感觉到跟写代码非常像。写代码的对象变了，用语言来就是用自然语言代替编程语言来编程而自然语言编程的对象不是你最终要实现的东西而是创建一个帮你编程的AI。从这个角度来看就会非常容易理解。但像现在这样一条线走下来的时候
崔胜准 认知负担不大，问题是一旦有了欲望人同时并行做好几个才是问题。
申正圭 我的核心是让它从多个角度自我批判。而且让它自我批判之后并不是要改变那个结果。最终现在每天运行一到两次的可以说是harness的自我更新。
卢正石 如果用好这个，叠加几个harness的话那就是一家公司了。我们公司最近的业务方向就是这样的单元业务harness，以及控制这些harness的上层harness。这个项目我们是从很简单开始的做着做着就变复杂了嘛。那正圭你觉得需要拆分成agent单位各自分工的时候那个拆分的粒度大概是多大？
申正圭 我个人定了一些规则，编程的话是按文件为单位来划分的。好，我来读一下初稿。一起看看吧。这么平淡的话其实没什么好说的。
崔胜准 总之重要的是不要直接上手改而是先去修正生成内容的那个机制。就是我自己不直接碰最终产出物不亲手去动它。
申正圭 就算想改也尽量不碰，一定是去改那个生成它的东西不断地iteration，而且iteration也不是我来做而是给它下指令让它去做iteration让它不断地更新。所以像这样直接给出产出物是一种情况。
第二种是如果我之前有发过的邮件就直接把那封邮件给它。让它提取这封邮件写作时用的语气或者写作方式以及内容的方向性然后让它按照这些去修改agent来写。所以修改的部分就变成了这样。看来它打算只用skill来做。
啊，要不要明确写成sub agent？专门做sub agent的原因是为了并行作业。
卢正石 你打算同时跑多少个sub agent？
申正圭 看情况，我处理大量工作的时候同时跑50个都有。
卢正石 是从一个harness里fork出50个sub agent吗？
申正圭 特别是那种相同的任务但每个单位要很小的比如翻译100个文档遇到这种情况就让每个agent负责4个文档并行处理得这样安排，为什么要限定数量呢因为不这样的话context会爆炸，直接崩溃。翻译任务的话这是经验之谈所以尽量让每个agent只负责4个。那就同时起25个了嘛。
卢正石 现在因为我们设定了一个简单的项目你才这样演示，大型项目比如说Backend.AI:GO也是完全按这个流程来做的吧。
申正圭 没错。这套东西已经高度成熟了。所以在那边是周期性地运行
Backend.AI:GO 的自动化开发流水线 54:46
申正圭 如果GitHub issue tracker上有新注册的issue就去验证那个issue，或者基于当前代码规划应该怎么实现，制定ground plan放进队列，放进去之后别的agent再来取取走之后去执行，就是这样的架构。
但这并没有用什么复杂的工具全都只是cron。Claude有个-p选项。就是直接跑prompt的，然后还有指定使用哪个agent的选项。也可以指定这个。就用这个每15分钟跑一次。做了一个命令来找这些issue然后去处理
找到新进来的issue，用某个skill去验证issue之类的，都做成了命令然后用Claude -p来执行那些命令每15分钟周期性地跑，就是这样。
崔胜准 issue是谁提的？issue是很多人提的。所以过一段时间这个自动化之后
申正圭 发邮件这些都会自动化pull request的话已经处理了764个了。
卢正石 干得不错嘛。所以就这样，一旦issue被发布
申正圭 比如这些issue里有一些是我发布的还有我们振源提交的issue就是这样注册上去的原始issue是这样注册的。这些都是注册上来的issue然后Claude Code读取之后分析应该怎么处理进行了分析。注册了issue之后，一旦这个issue被注册
卢正石 谁来领取？
申正圭 cron里设好的那个agent会领走。它领走之后就去开发了。它自己验证完没问题的话
卢正石 就直接自己merge完提PR了吧。有时候需要跑很多测试
申正圭 那就自己跑测试，把结果作为反馈再由另一个开发agent去解决。看起来很多人
卢正石 其实都是agent之间在互相协作。但issue的起点还是人对吧。
申正圭 有时候是人提的，有时候也直接让AI去提。
卢正石 我们现在剩余的、还没处理的issue比如说基本上大部分都是正圭的账号那些是人写的吗？因为是我在跑这些。
申正圭 不是GitHub自带的功能而是跑这些东西的账号是我的GitHub账号所以都挂在我名下。比如你看这里这个就是AI自己写的。这个epic是在前一个epic之前做的就是加了一个截取所有页面截图的功能。让它能看到自己，然后基于这些找出可以改进的地方全部筛选出来，让它把issue都单独发布出去。所以你看这里就有这些sub issue。然后这个已经finalize了一次
觉得需要跑一下测试，就在跑测试。可能有安全问题的部分或者有可以优化的部分就把这些跑一遍然后逐步添加进去。就这样实现了自动化。
崔胜准 这里面你实际会读的有多少？issue我都会读。issue解决之后
申正圭 会生成一份我能读的report。比如说我需要读这个就会像这样在1月16号生成写着有什么问题。问题是这样的，本来每个issue都会留记录不过读完就删的情况也挺多的。不需要的话就不写。安全评估做了，性能怎么样，质量怎么样，技术上做了什么决策，实现方面改了Bash，做了本地化，Python也改了。作为一个人，为了跟上它的节奏
我会标注出这些需要学习的内容，然后去做。去学习这些东西。这份tech report不仅是向我汇报的用途，它做的技术选择我也可能不了解嘛。细节一点都不懂。这种情况下，它还有个功能是告诉你需要学什么在后面提示你。
tech report - AI 给人布置学习作业 58:44
申正圭 实际上写代码就只写了这么点但报告有这么多。现在您展示的
卢正石 这个workflow，正圭您设计的工作流程如果不只是接上Backend.AI:GO而是接上财务、营销、内容的话公司就能这样运转起来了嘛。是的。我们公司的话
申正圭 比如说技术事业报告书、技术事业今年的事业计划书要写嘛。事业计划书到去年为止都是人来写但从今年开始，人只负责持续discussion写的这件事本身不再由人来做了。因为我们把reference，比如说超过250份文档全部丢给它了，还做了转换成Markdown的工具基于那些持续做一致性审查，然后2026年今年这个月的话2026年2月的新闻也让它持续爬取判断这个方向是否正确，之前预测的哪些对了哪些错了，也让它判断，我们今年的技术事业计划书应该怎么修改全部给出建议，像这样持续做self review然后留下需要和我们discussion的要点，是这样做的。
这个是我和比如说CFO在用的。CFO不会写代码。但现在会做commit了。因为我做了一个叫sync的命令。
卢正石 他是在supervise，活都是AI干的嘛。Claude Code一起分担着做嘛。
非开发岗位的 AI 适应 - CFO 与内容负责人的案例 60:00
申正圭 就是这样的结构，还有要学什么。所以学了很多。但这个workflow也不是
卢正石 突然一句”嘿，我想做这个”一句话就开始的，而是像刚才展示的那样这样把细节一步一步地把自己想要的目标和agent需要做的事情的context扎扎实实地对齐，这些过程都做了的嘛。其实这才是关键的点。
申正圭 开始重新做其实已经很久了。总之做成适合自己用的对我来说是最优先的，最近Claude出了一个叫Marketplace的功能。叫插件Marketplace，可以把这种harness打包然后公开的功能出来了。基于那个，想用的人可以用目前只在公司内部以internal的形式公开了。因为和公司内部系统有不少coupled比较多的部分。我这里有个商业方面的问题，
卢正石 现在CEO对于这种理念也好实现也好，世界的方向性也好以及现在这东西能做到什么程度都很清楚，所以才能一下子做出来。但组织跟上的速度怎么样？我知道公司里都是很厉害的人但即便如此，有些人能直观感受到有些人则还没适应过来内部应该也存在这种差异吧，人与人之间发生的变化是怎样的？这个我挺好奇的。
申正圭 就像您说的，每个人差异很大。而且幸运的是我们招到了很多优秀的人一起在做反而有些人经历了更艰难的时期。因为自己觉得擅长的事情和自己需要擅长的事情，以前是一样的但某个瞬间就分开了嘛。不过好的一面是因为内部经常聊这些话题，不管是研讨会形式还是路过吃饭的时候就这样围绕这些主题聊了将近一年比起止步于危机感现在都在尽量去适应了。没办法。以前很厉害的人在这之后还能厉害，当然没有保证。大家都是，有些从头开始的人反而做得更好的情况也有，这个我们也感受到了。同时也感觉到，那也只是现在的情况嘛。但三个月后还会这样吗，那就不好说了。因为AI，我们内部就说两个月。现在不行就现在不行，不是马上要做的事就无条件推迟。这个其实在公司内部推广是花时间最长的一个概念。最近接受这个概念的是我们CTO。因为我一直让他推迟，现在又不行。之前也那样推迟过一次。然后不久前终于爆发了，说到底要推到什么时候。所以我说4.6出来了现在试试吧，他试了之后说”现在可以了”彻底顿悟了。
崔胜准 这就是觉醒时刻。那次觉醒之后
申正圭 他把整个HWP给disassemble了。所以公司内部现在没人用HWP文档了。赶紧做成服务
卢正石 对我们韩国的公务员系统不也很好吗？不好说。真的能带来好的结果吗？
申正圭 大家应该都有一两个这样的东西吧。
卢正石 对。那些都是公司里各自藏着的小窍门。小技巧。因为积累那些小技巧是需要时间的嘛。那些时间上的优势现在成了公司的优势这种情况还挺多的，从skill Marketplace下载下来整个生意就完蛋了，而不是总得留点藏起来的底牌才能活下去吧。我觉得这其实是人们
申正圭 对Claude有多信任的问题，工具本身并不是关键。如果有人问”你能分析HWP文件然后做编辑之类的操作吗？“带着这样的疑问去提问的话，得到答案并不需要花很长时间。
Lablup 的核心价值迁移到了哪里 63:49
卢正石 这里我想问正圭一个问题，可能有点自相矛盾的意味，Lablup这家公司本身就是凭借高深的专业知识、对时代趋势的洞察力、以及优秀的工程师团队构建起来的竞争优势。但从您刚才说的这些来看，
Lablup公司自身也有很多——就是我们过去一直认为是公司独有优势的那些部分，一键就消失了，您应该经历过很多这样的情况。那么从公司的角度来说，“什么消失了，而我们公司的价值在这里”——我想您应该有过这样的定义。我们必须朝这个方向走才能活下去。
申正圭 有的。最大的变化是，比如我们正在做的项目、产品，已经打磨了将近10年。从asyncio还不存在的时代就开始做的工具，比如说用现在的技术和现在的AI从头重新做我们的工具需要多久。在已经知道现在所有这些知识的前提下，那大概3个月就能做出来。因为那些无数的边界情况和问题我们都知道了。在不知道的情况下要多久，那就比较难说了。因为那些无数的边界情况其实大多数来自部署环境的多样性。有些是完全想象不到的情况。公司今年的目标，特别是我们称之为fast track的
MLOps和内部Backend.AI核心的目标是不是为人类设计的接口，而是专注于为AI设计的接口。这个方向。我们有CLI、有GUI，什么都有，
向面向 AI 的接口转型 65:20
申正圭 但一个根本性的疑问——去年下半年、去年冬天我们共同讨论的是这东西将来真的是给人用的吗？未来也是。所以，尽可能在今年上半年内让它成为AI最好用的工具，这就是我们的目标。
卢正石 客户的定义，不是人，而是比人更聪明的，或者是从人那里接受任务委托的agent会把我们当作tool来调用——您是这么想的吧。
申正圭 比如说一起发布skill，让那个agent能够读取并使用，还有内部使用的各种东西以AI更容易理解的形式来输出，或者在CLI中对于任意命令即使不太了解也能推断出来的格式来调整，这些是第一个变化。我们的目标是训练模型，比如说用Backend.AI来训练模型的话，目标是做出模型，至于怎么分配资源这些一键就能搞定之后就不那么重要了。“帮我做一个超越某某的模型”这样说了之后它自己搞定就好了。大概需要多少时间、大概要花多少钱告诉你就行了。把焦点放在这上面是第一个变化，第二个变化是就像刚才说的
软件的定义在我们看来正在改变——我已经解释过了。不是代码在中心，而是模型在中心。所以Backend.AI的核心是什么——Backend.AI的核心也将会是模型。虽然不是foundation model，但是一个能够出色管理AI资源并处理特定任务的模型。而且这个模型的规模要能在不同环境中灵活运行，所以研究团队正在开发这个模型。而且这个模型本身
就是Backend.AI现在的——比如说运行环境，RAM多少、CPU多少这些规格。就像软件运行所需的规格一样，需要多少CUDA显存，运行这个系统本身在启动流水线中包含模型运行时的形态将在下一个大版本中进行测试，正式版是再下一个大版本，大概会是那样。直接将AI模型作为Backend.AI企业版的一部分来定位。它做的事情基本上就是Backend.AI原来做的那些事情。我们正在努力进化。说到进化我想起来，
崔胜准 您在社交媒体上偶尔发的那个Cyber Formula的比喻。
Cyber Formula 类比 - Claude Code vs Codex 的哲学差异 67:49
崔胜准 能讲讲那个吗？关于人类增强的部分。
申正圭 最近经常发的就是那个。我同时用Codex和Claude Code的时候感受到的差异就是这个。Claude Code的设计理念是尽量多问我，而Codex则不太信任我。用久了就会感觉到，它的态度是”我知道正确答案，你照着做就行”——我觉得这体现了两家公司的哲学差异。Claude Code你看它的进化方向，比如当需要做选择的时候会生成四选一、三选一的选项，做成选择题这样的功能都做出来提供了，最近甚至会把我接下来要问的问题以完整的形式预先建议给你。按一下Tab就能跳到下一个问题。就是这样不断询问我的意见，进行align，把人模糊持有的上下文更加明确地把握后朝那个方向运作——它在朝这个方向进化。而Codex，简单来说是朝着”我全都帮你搞定”的方向进化。而且实际上确实做得很好。要说最高水平哪个更高，我百分之百认为是Codex最高值更高。但让人用起来更舒服的是Claude Code。因为Claude Code是跟我一起走过整个过程的。
我小时候有一部很火的动画片，叫《高智能方程式》。是赛车题材，有一个跟AI一起赛车的主角。那个AI一开始很笨，驾驶技术也不行，但主角依赖它学会了驾驶，而AI也在这个过程中从人类犯的错误中获得灵感，创造出新的方法，实现了共同进化。每一季要解决的问题都不一样。
在人类和AI共同进化这个概念下，比如说，面对远比自己厉害的人类驾驶员要怎么赢，这是一个主题。然后是当人类进入未曾经历过的领域时，AI如何辅助解决问题，这是另一个主题。再然后是完全被AI替代，面对由AI驾驶的对手要怎么赢，主题就这样逐步推进。最后一季换了主角。有人借了一辆车给他，是前一季中给人下药、让AI完全接管驾驶的那辆车的制造者，说这是他哥哥造的车，给你用吧。就用这辆，按AI说的做就行。这辆车原本的设计就是完全不信任人类。认为人类当然不会开车，所以AI驾驶当然更好，于是AI会判断”到这个时候人应该这样操作”然后自行操控，但人跟不上那个动作，所以不断出事故。但主角已经换人了嘛。他开着那辆车吃了很多苦，最后赢了。那个主角能够跟上AI的节奏，具备了这样的能力。而AI因为想赢，不管未来怎样，反正我先赢了再说，可以说是产生了好胜心的AI。
在那之前我们讨论的都是有目标的AI，我当年看那个系列时产生的想法，最近经常浮现。拥有好胜心的AI到底是什么。通常AI缺少的就是意志。我们在做agentic coding的时候，人的角色是指定方向、告诉它该做什么。然后它就忠实地、埋头苦干地完成。但为什么它有时候忠实却不够聪明，在不理解上下文的情况下偶尔做出奇怪的事情呢？那是因为那个agent没有明确的目的意识。但在那部动画里，拥有了目的意识的AI如果遇到了对的人，就能击败与AI共同进化的人——这是它的结论。最近我经常想到这个。尤其是看到Codex的时候。那最后赢的那辆车就是Codex了。
卢正石 原来那辆就是Claude Code，您是这么类比的吧。
申正圭 两边确实都在往不同的方向进化，原来老主角开的那辆”阿斯拉达”一直在共同进化，而从天上掉下来自认为能做到最优驾驶、却不理解人类的AI是”凰呀”那辆车，它的运作方式给人的感觉跟Codex很像。某种程度上，制造AI或者制造这些设备的人们的哲学，设计理念多少融入其中。而且这些东西在我们近百年来积累的科幻作品里，各种媒介——文学、动画、电影，已经被反复探讨过了，这一点很有趣。
这是我的感想。从逻辑上想，那种模拟看起来像是概率较高的未来场景吧。从编剧的角度，经过无数讨论和思想实验之后才确定了那样的剧情。很多电影、漫画之类的作品跟我们设想的未来方向相似，这也很有意思。
AI 时代创业公司的机会与水车理论 72:47
卢正石 再问一两个问题就该收尾了。虽然刚才您说得很淡定，但Lablup十年积累的时间和那些资产，只有少数隐性知识变得有意义，其余的已经变成一键就能实现的程度——这虽然有趣，但对公司来说也是残酷的现实吧。我倒不觉得悲伤。
申正圭 作为公司来说并不觉得悲伤。作为个人倒是有点感慨。比如说创了业，我付出了这么多努力。在那种情况下，以前那么辛苦的事情现在变得太容易了。就像当初做Text Cube后来做Backend.AI:GO时的那种感觉。作为公司应该怎么看待这件事呢？我觉得公司层面的感受是——OK，谢谢。
卢正石 为什么呢？有两个原因。第一，幸运的是
申正圭 我们公司的适应速度非常快。在这种格局被颠覆的时候，初创公司要有利得多。作为初创公司，这就是我们的优势。我们积累了多少，就意味着我们能更快地完成转型或轨道修正。这一点很关键。而且整个团队适应新方向所需的时间会比其他公司更短，这就能转化为机遇，成为新的机会，这是第一点。对初创公司来说，市场稳定、格局固化的时候是最糟糕的。格局动荡的时候才好，有新机会出现的时候才好。如果我现在是既得利益者的话，可能会说这可怎么办。但在我看来，我们还没什么家底。除了技术什么都没有，而技术被leverage的局面来了，还能怎样。我觉得我们适应得非常好。在模型开发方面也是，我们的Backend.AI模型开发之类的工作也在大量进行，因此对于未来到底需要什么，也更早地开始着手准备了。
接下来第二点，是关于品牌的话题。这个局面的动荡，总有一天会平静下来的。就像过去所有事情一样，加速阶段不可能永远加速下去。但如果那个未来，比如说AI给我提供基本收入，不是那种我只靠它过活的时代，而是另一种全新局面打开的话，最终在那个局面中所处的位置，有可能和之后的位置非常接近。比如说我们来看服装。您现在做化妆品，化妆品也是一样，虽然有重要的ingredient、技术创新之类的，这些也有。但从成本角度来看，差距并没有那么大吧。所有的化妆品、所有的衣服都是如此。比如说我要买一个手提包，这个手提包真的比那个手提包价值高一千倍吗？并不是。最明显的例子是电脑。虽然都说Apple是最好的电脑，但跟其他电脑的价格也不会差10倍20倍吧。因为成本非常透明，正因为如此，最终类似的工具会很多，声称能做类似事情的工具也会越来越多，但最终还是要回到品牌，以及一直以来积累的track record，会成为核心竞争力的时代我认为还会再来一次。
在这方面，我们长期以来在各方面都守护得很好，只要在这个过程中不掉队、能够适应就好。让我想起了过去。就像”Brand Yourself”一样，品牌成为核心竞争力的时代在稳定期大概会再次到来。因此我们认为这是一个非常好的机会，但个人层面确实是有些悲伤的。个人层面的悲伤、这十年先行经历过的东西，
卢正石 还有前沿模型们已经知道了很多，一键就能生成的领域也有，但实际上经历了千辛万苦，代表和公司所积累的一种隐性知识，别人绝对不知道的那些东西正在构成护城河，也在成为别人无法输入的context，可以这样理解吗？
申正圭 基本上我们的解决方案不是为了在稳定的硬件上跑稳定工作负载的方案。GPU是非常不稳定的，包括网络在内，尤其是NVIDIA或AMD，越是最新的企业级GPU，不良率就越高，无法预料的情况也太多了。所以最终形成了一个很有意思的结构。不稳定的硬件不能信，
上面运行的模型训练软件也是什么都不能信的状态下，把这些变成好像可以信赖的状况，这就是我们方案在做的事情，所以可以说本质上不同。这就是我们的优势所在。这些归根结底取决于你踩过多少edge case，这是核心竞争力，跟自动驾驶有些相似。
卢正石 您刚才提到了Tesla，无论是从Tesla的角度，还是Lablup在公司层面过去十年经历的事情，然后进入了AI领域，虽然我们都有些不安，但如何把积累的东西转化为优势、转化为品牌资产，最终我们能不能赢，在战略层面这是一个非常好的案例。而且无论是软件行业，
还是走在前面的、至少是受AI影响最大的产业里正在发生这样的事，同样的形态也一定会在其他行业发生。就像Claude进入法务和财务领域，把这些也搞定一样。现在我们在讨论的这家公司的dynamics，公司价值到底从何而来，这些问题同样会扩散到其他行业，我有这样的感觉。
对创业公司最不利的事 - 复制时代 78:20
崔胜准 对创业公司来说最糟糕的是什么？对创业公司来说最糟糕的是停滞。
申正圭 您说的是一般意义上现在的创业公司吗？
崔胜准 放在当下AI行业或IT行业的背景下，创业公司的品牌价值，或者积累的经验、以及局面动荡这些，某种意义上既是危机也是机会，那么对创业公司来说什么是不利的，我就好奇了这个问题。
申正圭 所有产品的复制都太容易了。如果问什么是不可复制的，无论是从时机的角度，
卢正石 还是某些产品的组合方式，如果无法用这些来回答的话，就可能被别人的一键操作所淹没。
申正圭 最近在Facebook上有人复制NotebookLM，只花了四天，看到这个我感触很深。把NotebookLM所有界面的截图都截下来，功能说明全都列出来丢进去，大概四天就能做出一个克隆。在这样的时代，如果还用过去选择产品的方式来做创业，复制就太容易了。这也是最大的问题。反过来说，以复制为核心业务的公司可能会发展得非常好。
卢正石 但很多聪明人都选择了快速跟进别人做好的东西，走追赶路线，做better、faster、cheaper的选择。但过去靠资本优势，或者名校背景的优势之类的，能招到更好的talent，用这些条件来掌控一切或者成为主导者，那时候是有意义的。但现在这些资源人人都有，仅仅靠复制、靠复制已经很难让客户觉得这个更优秀、这个还不错了。需要某种超越复制的东西。关于那个”超越”，接下来还会谈到。
关于那个”超越”，我们也在通过这些实践一直在不断探索嘛。我目前发现的是，有一定的时间差和隐性知识差，如果能把这两者很好地结合起来，快速抓住这些客户，虽然可能会在某个人的一键操作中消失，但在那些无法一键替代的领域，一旦掌握了客户的数据，客户就很难转向其他平台。需要从这种商业视角来思考的时候到了。
崔胜准 一键抵抗性、反一键，这些词浮现在脑海里。我想说的是，有个叫Google创业园区的地方，
申正圭 我以前在那里演讲时用过一个比喻——我认为做生意本质上就是把水车安装在哪里的问题。在落差大的地方安装水车，让水车快速转动，水快没了就把它搬到别处，或者选择其他方式。刚才胜准说的那种时间差最容易出现的领域，我觉得不是在IT领域内部，
而是IT plus something，那些必然会慢一步跟上的领域。以前大家觉得这些领域不可能属于IT的范畴，但随着AI能够理解context，那些将被纳入IT领域的部分、将被纳入的行业，在这些领域安装水车的创业公司，不是会发展得很好吗？我一开始就问过嘛。
卢正石 我家孩子服完兵役要回学校了，到底应该让他学什么现在才是最安全的，我之前提到过这个问题。代表您当时说过，与其让那些在特定领域的人去学习AI和系统方面的知识，不如让那些对AI系统和相关知识了解很多的人去学习领域知识，这样会快得多。所以现在虽然听起来有些矛盾，但反而学计算机科学、CS可能是更好的选择——您当时是这么说的。我觉得这和刚才的话也有些关联。也就是说，在特定领域的人应该尽快学习CS，而学CS的人应该尽快找到可以应用的领域中的时间差，这不正好符合申代表说的水车理论吗？我是这么想的。代表如果还有什么想补充的，
对“计算机工程无用论”的反驳 82:19
卢正石 请继续说吧。计算机工程无用论，偶尔能听到这种说法，我觉得挺有意思的。因为我是00级的，我虽然是物理系的，但也辅修了计算机工程。上课的时候发现计算机工程系出身的教授其实很少。因为上一代根本就没有计算机工程这个专业，成为计算机工程系的教授，意味着是其他学科中大量使用计算机的人创建了这门学科。所以有化学系出身的，有材料系出身的，也有物理系出身的。早期建立计算机工程系的地方，教授们就是这样来的。现在大多数教授则是从计算机工程这个独立学科接受训练出来的。
申正圭 这说明什么呢——计算机工程从一开始就有一半是带着方法论思想起步的，虽然也可以分为计算机科学和计算机工程，但本质上它是一门非常年轻的学科。相对于其他很多领域来说。正因如此，我认为它的变化速度也会非常快。不可能永远只是学Python的专业、学C的专业、学架构和操作系统开发的专业——这些当然会继续教。因为它们确实非常重要，会继续教下去，但我认为不会一直保持这种形态，比如说神经计算，或者模型开发中模型的核心是什么，attention结构是什么，尝试构建其他架构是什么，这些内容最近也在大量引入。实际上像深度学习概论这样的课程也已经进入了教学大纲，所以从某种意义上说，能最快适应这种变化的学科就是计算机工程。我虽然是物理系的，但也是这么认为的。当然物理系最近可去的地方也多了，这倒是好事。
在这个过程中，人们会说反正AI都能搞定，那不学计算机工程不就行了吗？直接让AI帮我做不是更快吗？虽然这么说，但实际上问一下我身边业内的人，他们反倒更多的是反方向的担忧。比如说因为AI什么都能做，那我是不是就没活干了？拍电影也是，Seedance都能生成那样的视频了，那电影导演、摄影指导该怎么办？就是这种危机感。照这个趋势，大概未来五年左右，IT——虽然到目前为止已经渗透了很多，也在被广泛使用——但将以惊人的规模深入到社会各个领域的核心，我认为这样的时代即将到来。短期来看，可能有人会说学编程有什么用，反正电脑都能自己写程序了。但计算机工程学的并不是编程。学的是其中构建逻辑的方法。如何构建逻辑，最基本的门电路逻辑如何发展成为无数复杂的逻辑体系，那种方法论，或者说哲学。我觉得学的更多是这种思维结构，所以我是这样认为的，这样的人去学习其他领域也会更快。特别是在知识可以外包的时代，就更是如此了。虽然我们这样说了，
卢正石 但必须要加一个补充说明——两个月后可能就变了。在此附上disclaimer。
结束致辞 85:29
申正圭 大家携手并进，都得和AI好好相处。
卢正石 虽然我们朝着未来前行，但现在是春节假期，得回去陪家人了该告辞了。
崔胜准 虽然时间很长，但很有趣。今天又学到了很多。那么，假期愉快。
卢正石 下次来首尔的时候再见。
申正圭 剩下的假期里，祝你们愉快地折腾吧。