Ouraca 张栖铭 & 吴俊东：只要你还在开会，你们公司用了 AI 也快不起来

00:05如果一个组织还需要不停地开会，很大量的写文档，来去做很多对齐的话，那它一定快不起来。当你定出一个小的目标的时候，其实你想的就是优化。当你定出一个很大目标的时候，它在逼着你去完全不一样的一些思路去做事情，包括对客户群体更加聚焦，

00:29包括产品形态。包括真正的常识。

00:35我最大的建议就是找一个project做，但过程中尽可能地能用AI就用AI。就是你加一堆的agents，把这个产品从头到尾全部做出来，且有真实的用户。因为现在有太多的这种资源可以帮助你做这个事情。

01:04现在

01:12大家好。我叫俊东Frank，现在是BotLearn的联创。之前长期也是在教育行业比较多一些。我这个是哈佛的肯尼迪学院毕业的，我不是像大家一样做技术背景，更多是学经济啊等等。但是之后就一直在好未来七年，一半时间做投资，一半时间负责像出海啊、内容营销等等的业务。

01:33我们和可嘉、张栖铭差不多，叶曼以前吧，开始正式创业，成立一家公司，希望去探索AI时代的终身学习。

01:41大家好，我叫张栖铭，是我们的联合创始人。然后我之前在字节教育负责过整个中台，之前也做过多个亿级用户量的产品，现在主体在做产品跟研发相关的一些事情。对，

02:41嗯，好的。我也大概介绍一下之前我们踩过的一些坑，包括早先的一些探索。我们之前做一个app产品，那个时候一年多前，web coding相关的一些软件也是比较早期的一些阶段，它整体的能力也不像今天Kotlin、Kodex这么强。

02:57当时我们一个产品一个设计。iOS、安卓各一个，包括一个后端。然后当时整体的流程跟现在外部的一些大厂啊，基本上是一致的。公司高层出一些战略，产品经理出一些PRD，设计拿到PRD之后去做一些细化的设计，开发的一些同学等设计全部做好之后，

03:19按照设计稿去做一些开发。最初其实我们也想着说，哇。现在这个AI的能力这么强，我们是不是效率可以提得特别快？当时有几个错觉，第一个就是我们人非常少，一共就几个人，是不是决策链非常短，而且上下文很集中，大家任何事情在一起是可以立刻就是一个。

03:38第二个呢，就是我们也没有复杂的跨部门的一些依赖，没有那么多安全呀、合规呀，或者组织协同上的一些约束。还有就是我们同事的能力特别强，所以在AI的基础上，我们是不是能够非常快地去决策，非常快地去迭代。以前一个月干的事情，是不是现在可能三天就能搞定了？

03:58这个过程当中，其实我们出现了很多很有意思的一些问题。实际的一些体感。例如说之前Vibe Coding的这些能力不到的时候，其实我们出现了一些非常诡异的问题。例如说一个按钮，我在正常情况下点击一下去播放某个音频啊、视频啊，它是正常的。

04:17但是改了其他某个功能的时候，忽然发现那个按钮点了以后它先变小，然后再点一下，它才会正常地去播放。看代码之后才发现，原来它最初在实现这个策略的时候，它写的就是先变小再播放，只是最初它是一次性执行了，所以呢你感知不到它变小再播放的这个过程。

04:38但改了其他某一个东西的时候，它把原来的一步拆成了两步。所以它最初写的时候，其实就不是一个好的策略，甚至是一个错误的方法写出来的。

04:54对。这就是很诡异的问题，有这种诡异的问

04:59我们当时都判断，就是个人都写不出这个东西。对，呃，所以。所以呢就有的时候间歇性地会打退堂鼓。尤其是第一次发现这个问题之后，你就想到冰山一角。当发现这个冰山的时候，你不知道水面下面还有多少的问题在。

05:14所以呢就经常睡不着觉，这是一个唯一性的一些问题。还有呢就是感觉上面我们每个节点都在用AI提效。大家在思考整个战略的时候，可能会用AI去帮着做一些调研，做一些数据的收集，很快地形成了一些文章。产品经理写PRD的时候，也会把大概的一些想法写出来，或者说产品经理会直接把自己的一些想法梳理模型，

05:38让模型直出一些界面。但是你最终一个版本发出来之后，发现它还是没有体感的那么快。我们当时就拆解了一下，我们在几个版本上的耗时。对。最后发现真正在开发上的时间其实不长，反而我们在过程当中这种开会啊、讨论啊、相互对齐的一些时间还是占了大头。

05:59而且呢以前你所有的文档都是自己手工写的，所以呢你去向别人去传递思路的时候是非常自洽的，你可以很快地把自己的思路想法给他人去做一个传递。配合AI写的时候就发现我又要理解AI写的东西，看它跟我原来的是不是一样的，又得想办法把AI写的东西传递给别人。这个过程当中就发现是体感上其实是双重工作量。

06:24第一，我得有大的想法，让模型基于我的想法去做生成。其次呢，模型写出来的东西，因为不是我自己亲手写的，它补充了大量我自己抓不到的细节，这就使得我脑子都烧坏了。生成一个文档之后，看明白了再去给别人讲，别人问我两个问题，问得卡住的时候，自己的挫败感也很强，

06:44就想着我是不是不要用了。别人对你的信任度，就感觉，哇，这个人他没想清楚就把事情给我来做了。你会发现整体的一个个人的工作量其实比以前更累，而且脑子都烧掉了。我们把一些具体的时间拆了之后，会发现说其实我们所有的流程都没有变化。

07:04本质上就是旧的流程被加速了。你在中间纠结的事情呀，其实一点都没变。而且核心的时间其实还是花在了人跟人的对齐上面。那这是一个点。实际上我们通过一些工作在加速旧的流程，但旧的流程当中其实很大部分的沟通啊、交流啊、会议啊、评审的时间其实跟原来一样。

07:27而且按古法编程的方式，本身纯开发时间占的比例也没有想象的那么大，所以就显得说你的提效其实是没有那么大的。然后在这过程当中，我们也发现所有的人在用AI发现一点点不对劲，发现一点挫折或者出了一些问题的时候，那大家就可能心态上就躺平了。

07:48我是不是更追求确定性？我的上游必须给我非常明确的东西，能照着做，而不是说上游给我一个模糊的东西，让我自己用AI去发挥。那从人方面来说，我总结一下，对稳定性、对可靠性追求反而比以前更强烈了。实际的体感我再总结一下：第一个，出了很多诡异的问题，间歇性地会怀念古法编程，经常打退堂鼓，这是一个。

08:11第二个，实际上我们是在用旧有的流程在上面做了一些提效的事情，而不是真正地在迎合AI去对整个流做一些重塑。同时这个过程当中，我们看不同的时间占比的时候，其实并没有提升太大。

08:45还好。大家都很纠结。这个过程当中，我其实已经在很认真地想，如果大厂一个团队非常多的人来用AI提效的时候，它会怎么样？现在的整个组织形式是不是还能够支撑得起这样的一个事情？所以这个阶段我们就开始做了一些访谈，尤其有一些朋友可能一个人非常快的时间就做了很多的一些事情。

09:10包括在一年多前的那个时间点上面，大量的外部的一些媒体上都在宣传，哇。谁谁谁用五个小时、用一天时间做出了一个非常牛的东西，在一定时间之内拿到了非常多的浏览量，就使得我们非常的焦躁。这个时候就开始做了一些访谈，找到了一些开发速度非常快的人，看看他们是怎么做的。

09:40访谈的时候我就发现，其实他们自己一个人做事情的时候，心态是非常顺的，就想到哪里做到哪里。而且自己在做东西的时候，他每个时间点自己做的任何一个决定，对自己来说都是确定的。所以呢他没有任何上下游的一些对接，没有对别人的要求，也没有说自己，总有一些因为东西做得不完善而产生很多的一些内耗啊，

10:02或者说其他的一些情况。但是当时确实访谈了一批啊，但都是一个人在做。但是只要你牵扯到多个人的时候，他可能就会去做一些对齐。所以我提点点就在想，是不是应该每个人独立地去负责一些东西。就是大家分工的时候，不应该按传统的职能去分产品、设计、研发，而是应该按照上下文去分。

10:27就在一个上下文下面的事情，可以由一个人来处

10:30理。他能把一个闭环都解决，也不用太依赖别人。不

10:35是是。也不用跟别人去对齐，他一个人负责好。可能大家更多对齐的是你这个产品希望你达到什么样的一个目标和时间点出来。那这个时候我们对一些功能做了一些划分吧，就把例如说相对独立的一些模块划给一个人来做。那这个时候又出现了一些问题，就是你会发现小伙伴们已经习惯了传统的工作模式之后，其实例如说一位研发同学，

10:59你让他从前面去想，说这个产品应该做成什么。应该满足某些指标，应该做什么样的一些功能，整个交互的流程应该是什么样子的，它其实也是很难的一个事情。所以呢，我们在这个过程当中就在想，那什么样的人适合，可能更有这种业务思维的人，他一个人能够把一个业务想得相对比较清晰，

11:24自己骨子里面是有一股创业的劲儿的这种人，可能会更好一些。我们也在想着说，第一步的小伙伴是不是有这样的人能够能够筛选出来。第二个，这种能力有没有可能去培养？如果培养不出来，是不是可以通过模型帮助他把一个事情想明白。或者说你教他一个相对标准化的流程，甚至写一些skill或者工作流，来帮助他们把前序的一些事情想清楚。

11:52或者说公司内部大家按流程去画更细的一些东西。然后这个过程当中，其实我们自己有一个阶段其实也是没有办法投出去的。所以呢当时就跟大家说，有一个想法，我们要快速地去做东西。不管什么样的岗位，你必须自己出一些。例如说你有一个想法的时候，不是在说你过来，你帮我把这个想法细化一下或者怎么样，而是自己立刻把这个想法跟模型去聊，

12:18跟CodeCo、跟Codex去聊，看他的一个反馈。在这过程当中，你形成一个可视化的，能够把你自己的想法明确呈现出来的东西，直接去跟大家去做一些沟通对齐，后面怎么分工再说。如果自己有能力做一些完善的话，那么自己尽可能做。但是如果说你没有能力做的话，至少做到一步，就是通过模型把你的想法可视化出来，在内部去做更多的一些沟通。

12:46所以呢，基于这个的话，我们当时就逐步地开始真正的全员写代码，每一个人不再是空口白牙的、务虚的去讲一些需求。

12:58其实补充刚才新民说的，有一个很重要的点，团队的对齐。长期我觉得在最开始的阶段，可能是大家开会啊等等就交流。但我觉得包括以飞书为代表的整个文档这个体系，也提高很多效率，通过更多文档协作。但文档它毕竟在做产品研发的时候，还是有很多missing part。

13:17但真正的现在我觉得最新的，你不仅得写个文档，你真的得把这个原型prototype得做出来，再拿着这个和大家去沟通。这样的话，在信息对齐的颗粒度啊，包括精准度、信息的missing啊等等，都能够得到很大的改善。京

13:34东前一段时间独立写了一个苹果上的客户端，这个客户端可以实时地侦测你的界面，看你界面上发生了什么，可以教你如何操作电脑，你当前界面上打开的一些软件。这是一个完完全全的文科生

13:50写出来的一个工具。而且这个工具可能让他说我写了个客户端，发出了一个两百多兆的安装包，大家用起来以后发现太炸了。对对对。所以确实这些Vibe Coding的一些工具，就真正的一个大的改变是什么呢？以前你写代码特别贵，所以你才在前面需要很详细的一些调研的过程，大家讨论的过程，对齐的过程。

14:14那现在确实是，一个能准确地用语言描述一些东西，甚至你描述得不清楚，模型都可以带着你一起去描述，帮你把需求细化好的这种情况下，你去写一些常规的代码。或者说去打一些demo，在这种情况下，已经门槛非常低了。是。基本上，咱们不说文科生，以前有个测试叫什么，叫妈妈测试。

14:39你真的让一个妈妈级的人，可能没有任何电脑操作水平的，或者一个小朋友，可能我把它对着其他的一些工具说几句话，就能生成相对复杂的工具。完

15:00太厉害了。对。所以今天中午我也被这个任鑫家的孩子给惊艳到了。因为我其实在见任鑫之前，我一直想问这个问题，作为你自己本身就是一个AI native的builder、influencer，那你对你的孩子他怎么样成为更好的学习的模式，你肯定会有很多自己的想法。

15:21但至少我觉得从今天

15:24让他build。反而他能够有很多，因为这个很有意思。前段时间我们不是办了很多hackathon，就各种各样的开发者啊等等。就两个月前，就是那次hackathon特别有意思，现场大到五十多岁，最小的有几个九岁的小朋友，他做的就是用code打一个agent，怎么帮小学生去解决情绪焦虑的

15:45一个问题。所以你会发现特别严肃的。现在，对，现在的，真的是build for yourself的这个阶段。对，你真的自己想做什么，快速就能够去建立起来。今天任鑫提到一点让我最有启发的就是，现在最需要什么样的人才。

16:00传统的可能是执行层面，做题小能手，做题家。你有一个好的任务，建立清楚，你把它执行，get done就好。其实我觉得在组织里面，为什么以前需要那么多人，包括不管是新民以前的产研团队，包括以前在我在好未来带着营销团队，其实也是有很多人，但大部分都是很还是个执行层面，把它scale up。

16:19但这个职能其实在很多时候，AI native的团队里面，其实不太需要。今天你那个观点叫做，就问题界定者，他能够找到有机会在哪儿，同时自己把整个环节都解决掉了。其实讲到我们团队组织内部，我们也是希望每个小伙伴都成为这样的一个问题提出者、问题解决者。

16:41我

16:44现在是这个AI阶段。大家穿黑色。

16:48前面也提到，就例如说现在写代码，写一些常规的。如果写一些例如说需要架构非常严谨的，支持大并发的，或者说有一些很难的算法的，我个人感觉模型在某些点上面可能能做到，但是有些也做不到。但在常规的一些app、常规的功能、常规的网页方面，模型现在已经做得非常非常。

17:11对，那在这种情况下，原来的旧的古法的流程一定是需要做改变的，包括说对里面单人的一些画像，对岗位的一些描述，也是一定要有一些变化的。所以我我当时就一直在想。到底需要什么样的负责人？到底需要什么样的团队？

17:29需要什么样的心态，才能支撑一个理想化的流程？那么，我从古法编程的那一拨人的心态的一个转变就是什么呢？我个人认为，负责人需要很强的把目标定好。大的判断力是需要有的，它在过程当中，一定意义上需要降低对过程产物的一些预期和控制欲。

17:52如果你有很强的控制欲，你希望说每一次生成的一些东西都要非常好，那我感觉还是一个特别高的一个标准。那在这种情况下，可能会有一些问题，你在过程当中需要适度地去降低你的标准和预期，但你对最终产出，或者说在多轮互动之后的要求都是可以提上去的。

18:11这是一个。第二个呢。从团队方面来说，尤其在早期探索，大家整个意识还没那么强的时候，需要有很好的一个外包意识。就是要把自己躺平，我手头什么工作能放给别人去做，什么工作能放给AI去做。对，因为如果你感觉让他做我也不放心，那我让他做我也不放心。

18:30你永远迈不出那一步，所以呢你一定要有一个躺平的思维。我得躺平，那个东西可以扔出去做，我在过程当中做好质量的判断，做好整体的一个一个把控就可以了。所以呢要有意识地把大量的工作分出去的这种能力，我感觉是相对比较重要的。还有就是岗位角色其实整个边界会在不停地模糊。

18:53以前说人人是产品经理，实际上大量的公司还设立产品经理岗位，说明它可能还是有一些门槛的。但是现在确实是每个人都能输出点需求，每个人都能一句话生成一个看起来还行的网页。那设计师是不是也没有存在的必要了？这不是一个最终结论啊，那产品经理啊、设计师啊，好像别人也能干。

19:15我从研发的角度来说，好像我能写代码，产品经理跟设计师他也能写，所以它整个岗位完全在模糊。那这过程当中。这些事情已经意义不大了，就我代码到底是谁写的，可能意义已经不大了。最重要的是什么？是你对业务是不是很好的理解。

19:31因为确实它过程的成本，写代码的成本，做一个东西的成本是越来越低的。谁了解全部的背景，了解全部的上下文，并且能够对结果负责。那么现在可能整个流程应该怎么去做？前一段时间那个Claude这边有一位他们的项目负责人，当时其实提了一个点，说还剩五种人。

19:52这五种人呢，一个是叫原型者，就是他。有大量的新的想法，他可能对用户、对业务。对场景理解的相对比较多，他就用自己的想法做出大量的原型，在内部用来做讨论，用来空对空的在聊了，而是基于一个原型在聊。中间可能有大量的东西是上不了线的，但是呢，它可以快速地让大家去对齐这些思路，对业务的理解，对用户的理解，

20:17对未来的理解可能会更到位。这种相对比较强调的是他对可能性的一个嗅觉。那我当时看到这个时候，我我我感觉还是很得意的，因为我们在内部其实已经实施了好久。甚至说任何一个人提出一句话，或者大家在开会讨论的时候，我们都用飞书的录音，或者直接用飞书会议，

20:35把所有的东西录下来。就把会议的原文直接扔给各个个人去看，诶。我们这个会议产生了什么？所以有的时候，大家在会上讨论一个东西的时候，可能会议还没结束呢，就说根据前面的讨论来，这几个原型大家看一下。对。

20:48所以其实我们这种上下文全部都融入进去，实时地生成一些东西，实时地做一些讨论。这种呢其实一定意义上也是让大家每个人都成为就更好的理解上下文，更好地去做一个原型者。不管想法靠不靠谱，出来再讨论，而不是空对空的。因为你说出一句话我要做个什么东西的时候，不同的人理解是完全不一样的。

21:09但一个界面可以更清晰地把思路想法传递出来。第二个职位叫建造者，就是怎么把一个原型或者想法快速地变成一个生产级的产品。那这块儿我自己观察，除非这个东西是比较简单的产品，难度比较低的。不然可能还是需要以前的相对专业、经过训练的研发同学，但这个门槛可能也在不停地降低，把一些想法形成一个可用的、可发布的，

21:35可以放出去给真正的用户去用来收集反馈的一个东西。对。那这块我感觉怎么样，从快速验证切到工程质量相对还比较过关。那还有一个就是清扫者，清扫界面的，包括说呃去确定大量的东西是没必要的，要把它干掉的。对，这一点其实非常重要。

21:55因为当一个事情成本特别低的时候，以前我们说，哇，我有这么多需求，要排个优先级。那现在像按那个wireline coding太容易了，所以做零嘴级把所有的东西全做出来。那这里是会有大量的干扰的功能，而且那些功能可能根本无效的，甚至对产品有负向的指标的。

22:15那这个时候就需要有人叫停，把很多的不必要的东西，或者在过程当中大家认为反正开发太容易了，所以这个功能就上了，就把这方面的一些东西去掉。这个其实还是很有意思的一个观点，因为以前开发周期太长了。

22:31在开发前，大家就经过大量的审核、会议评审，来确定说这个东西要上，会这个对我们的用户数据会很有帮助。所以大家才会上来之后，那每次可能决定说这个功能做得不行，可能真的是要问责的。对，那现在呢太容易了，好吧。放上去了，

22:48就是比较有意思的。

22:58扫。对对，是的。因为模型们也在不停地提升。对，底下是增长者，怎么去改善整体的市场的增长，怎么去看一些增长信号。那这个跟以前其实也是类似的。

23:09还有一个维护者，接管成熟的一些系统，让它在规模化过程当中安全可靠快速。那这块跟以前可能还有一些类似，可能一些偏运维或者产研的一些同学会做。但是从前面整个对市场的一些快速的判断，快速的打demo，快速地去做一些市场验证，我感觉是产生了非常大的一个变化。

23:30而且这些事情真的是任何一位可能有点想法的同学都可以直接上手去做的。对。像一些初创的团队，用这套思路是完全没有问题的。对于一些大型团队，我感觉思路其实还是可以沿用的。但是呢，大型团队当中它可能会牵扯到一些层级的汇报，包括大公司对安全的要求。

23:52对其他的一些要求，诉求会更高。所以呢，他一定有他自己的一些。

23:58好多人。对，我在字节之前管中台或者管一些业务，都是有过比较大的一些研发团队。那以前我们可能有一些项目都是几个月起，因为做很多事情要非常完善嘛，比如说你做个支付啊，或者说做个课程，中间也牵扯到很多这种课程内容的一些审核，包括支付的体系啊，其实字节也有庞大的一些中台来支持。

24:22在这种情况下，可能我们一个团队还是几十上百号人，要干个几个月半年的情况。那小公司在大的安全呀、合规方面顾虑可能会少很多，整体研发也不需要太多的层层汇报、层层审核，所以速度基于web coding用新的一些流程的话。其实在当下的web coding能力下，是可以提速的非常非常多的。

24:46而且像刚才Boris的这种岗位的划分，其实每个人都是可以去跨多个职位，而且非常快地去做一些事情的。对对对，所以这里对个体的一些能力，除了我前面说的，他要一个有躺平的外包的思维，包括说一个项目的负责人，至少在过程当中应该降低一些控制欲，

Boris Cherny

25:07降低一些对确定性的控制欲，直接看结果，然后基于结果快速去迭代，哪怕最开始模型生成的原型是完全不对的。但是呢，你从无到有之后。从有快速地去迭代，从有到精的一个过程，可以让这个路径跑得越来越匹配你的一个思路。那对个体的一些能力要求方面，其实我一直感觉教育方面最好的一个能力是元认知的能力。

25:36对，你会怎么样去做一个事情，你会用AI的，你可以把它解释得很复杂，但是我一直用它就只有一个用法。就任何人在做一个事情之前，包括我自己，我都会问一句，我会怎么样把这个事情做得更好。这就是一个元认知的典型的应用。非常新的时候，我去让模型帮我解决一个事情，我都会先问一句。

26:00这个事情是这样的，你认为你可以怎么样把它做到最好？它输出一些东西，我再把我自己的方法论加进去，然后它就可以输出的很好。我会认为说，团队当中的每一个人，你去说判断力，那有些人他可能天生对业务理解的没那么好，或者说他的判断力确实相对比较弱的时候，

26:19那怎么样用模型的杠杆，能够把人家模型的能力给充分的发挥好。我就专门写了一些skill，比如说当你不知道干什么的时候，先来问一下，或者说一些元prompt，就元提示词，帮你写提示词，和元skill，就帮你写skill。只要你能明确的提出一个诉求。

26:40那么我会帮助你把这些需求，把这些skill或者做事的方法，都给它完善好。所以呢，基于这个其实，呃，我们自己在内部管理的过程当中，设定了一些大家的使用的方法。对。包括说一句话需求的一个扩写的方式，包括说呃我做任何一个项目的时候，项目的上下文是怎么交代的，

27:04我感觉这个其实是非常重要的。我做一个事情，例如说安排同学们去做一些具体事情的时候，可能你更重要的是讲清楚我是面向普通用户群体，然后什么是可以做的，什么是一定不能做的，你大概的一些交互准则是什么。其实我形成了一些规范，大家在做每个项目的时候，他直接套用这套规范去按自己的项目去撰写一下，基本就可以了。

27:26在这个过程当中的细节上面，就不知道怎么办的时候，就找到对应的一些skill也好，或者找到对应的一些使用方式。归根结底是在新时代看一个人的能力。我一直认为有一个词叫

27:42杠杆，你能撬动模型的多少能力，你能用模型帮你生成多少个虚拟员工，或者说就相关的这种能力来帮助你干活。所以我感觉这个在新时代是很好的一个点。

28:28的？其实是这样，就code code本身的能力很强。对。其实更多的就你给他一个模板，他会引导你来回答这些问题。那这里面就有一个相互的一个过程，绝大部分人很难在最初把一个事情想得特别明白。

28:41但是当有这些问题的时候，其实让他一条一条回答，这过程当中他会把相关的内容跟背景补齐的。而且你还可以用模型直接帮你去做一些更新。就好像我们最近在做的有一个自媒体的一个课程，那自媒体课程可能你需要对自己进行定位，你去找到某个用户群体去解决他们什么问题。

29:02如果你自己没有完全想明白的时候，其实模型可以帮你去扩散，让你从当中去挑选。如果没有挑选的，你可以借助模型给出来的这些形式，去把自己的填上去。例如说，一个人完全想不明白的时候，就问他，你最想对标什么账号？其实模型完全可以把对标账号完全分析好。

29:21然后问他，你想做的，是不是这个事情？就很多人你让他从零，没有任何基础的，直接回答一个问题很难。但是你一旦给他一个模板或者给他一个参照物的时候，绝大部分人是能够把事情讲清楚的。所以呢，你可以认为我们形成了一些规范，这是一个可以引导正常的人都能把这些问题回答好。

29:41作为一个第二个本身团队的小伙伴，能力都还不错。当你给他一些示范或者给一定引导的情况下，他可以把这些问题回答好。而且我们定期会review一下里面写的一些目标用户啊、痛点呀、使用场景呀、企业原则呀，或者一些这种。不该做的事情呀，其实只要review一下这个项目文档就可以了。

30:02先依赖小伙伴个人的门面去写一些东西，然后后续其实团队定期去做一些review，确保不会跑偏，或者说最大的上下文背景是一致的就可以了。了解。

30:23实我们全部是GitHub，对对对。做GitHub，做整体的一些呃内容的一些提交啊，版本的管理啊。包括产品，包括设计，这已经是传统的这个称号了，所以大家也全部都写代码。然后在流程方面，在顺序方面也会有一些demo，可能任何一位有想法的同学先做出一些demo，然后这些demo放出去给一些正式的用户去做一些使用，

30:47没问题的。然后我们回过头来，呃。设计师把代码扒下来，直接去改设计的一些代码。因为模型生成的很多页面确实是千篇一律，有点丑。有一定的一个需求验证跟正式用户反馈的情况下，那么这个时候设计师已不再像以前那种用Figma啊，

31:05或者说生成很多设计图的方式，而是直接把代码拉下来，直接改前端代码的方式去更新相关的一些东西。对。这一块我们呃已经跑得非常顺畅。

31:40我们组产品基本上是研发先直接把东西做出来，发出去，这个时候已经有真实的用户在使用，整体的流程都已经顺畅，且验证需求是没问题的。在这种情况下，设计师才会介入进去做后续的一些优化。这个为主体，

32:21你可以这么来理解，其实像刚才Boris提的这种思路，你可以认为例如说我有一个想法，但是我的研发能力相比于以前纯粹的研发同学是弱一些的。我可能做出一个原型demo，用于内部对齐，以及在这个时间点上已经让一些正式用户去看，去做一个就假数据的，但流程完全是真实的这种demo拿出去去使用。

32:46没问题。研发同学把它全部做好之后，我放出去，真实的去做一些售卖。

32:55了已经。其实一共就几个人，所以也没有明确的分

32:59部门。会比

33:01较容易。对。我们现在做课程，我们是不管传统的是什么样的一个分工，实际上每个人都在去做这种课程内容的一些生成，而且生成的就是最终最终用户使用的。因为像一些课程页面，它是没有什么技术难度的，任何一个人都可以直接做生成。

33:19所以在这种情况下，你可以认为就一个人已经把包括原型，包括真正的进生产级的代码，就全部都做完了。

33:42是的，例如说我在管理大型团队的时候，我每天主要的时间在开会，在做一些大的决策。我看大家做的东西跟我的思路是不是一致，这个可能花费了相对多的一些时间。现在每个人都干一坨活，开会的时候就务虚的东西已经很少了，全部看实际的产出页面，所有人都在干活。

34:03以前基本上靠嘴说或者写一些文档，现在已经不写文档了。包括进展汇报，我们都是自己去拉一下代码，看这个代码这两天有什么更新。

34:15基本会很少。对。每天按传统的方式，就很久以前的敏捷开发方式，每天有个十分钟的站会，大家快速说一下，有什么问题，有什么进展，基本上就过去了。当你自己想明确知道某个人的进展的时候，其实你就上GitHub上拉看

34:33代码的整个提交情况，然后自己拉下来跑一下就知

34:40因为做一个非技术人，其实我这个感触还是蛮深的。这里面有几个，比如说他刚才说的日报周报等等，其实就在建立之前，今天我们飞书群里面，因为我们把COI、飞书COI都接到Claude Code里面，小伙伴就一键，他就把过去这一周我们在所有的飞书群里面大家讨论的一些已有的问题，讨论的决策的话题，

35:02所有的内容，其实谁干什么，谁和谁之间有哪一个问题要一起协作，他其实都已经梳理好了。所以这些事情比以前你花很多时间写周报啊，写日报等等，要高效很多。我确实以前经历过最夸张的，之前我在过一个团队，一个销售。一个小伙伴每天花在写日报上需要一个多小时。

35:24他总共工作时间也很长，可能八九个小时，九十个小时，还有一个小时写日报。但现在其实我们整个都workload。然后那个金明刚刚说的在GitHub我也感触很深，因为我主要这个对公司对外，所以我需要大量的去比如说去分享，去产出对外的一些材料。

35:41以前最开始的时候确实，比如说我把内容弄好，我可能需要设计师帮我把整个设计语言去更新一下，我们的视觉是不是有一些要素要调一调，包括我们的整个整个理念啊等等是不是措辞啊等等要调一调，包括我对于很多理念的描述。可能有一些新的东西也没有可能没有及时传递到设计师，但是因为现在workflow所有的一切都streamless。

36:06这个前几天因为我之前也准备一个我们对外分享一个PPT，我马上就在GitHub当中，我们的设计师把所有的设计的呃元素包括准则直接上传上去，我一拉，我的整个PPT一键就变成完全严格按照我们设计的规范来做，我也不需要让他帮我再包括我要做新做一些海报，新做一些这种传播素材，我也不需要再跟他去去对了的。

36:29所以这里面其实剪的是相对比较初级的一些一些设计或者一些down的一些工作。但我觉得高级的这个设计还是很重要，定整个基调，把整个这个workflow上传到GitHub，所以这就意味着他定的那个规则比以往任何时候都更加重要，它影响了所有的对外的产出的内容。

36:51我有个很简单的逻辑，如果一个组织还需要不停的开会，大量的写文档，来去做很多对齐的话，那它一定快不起来。对。项目成败不依赖这个，但是确实，你整个速度快，使得你可以快速去做一些尝试，快速拿到结果，不管正向的还是负向的。但是只要你还不停的开会，不停的对齐，你核心的一些人自己不去动手干活的话，那我感觉就速度很难快起来，

37:18也很难的快

37:32其实大的流程方面，呃，职位划分方面可能也提了一些嘛。我感觉Vibe Coding年代最容易的几个风险。第一个风险就是AI会让这个自我欺骗变得更加高级，因为你不管说什么，AI经常容易偏向地去赞同你，认为你说的是对的。就好像我让我儿子用一些这种chatbot，他回答的答案全是错的，例如说这个小学数学题目啊，或者说一个植物的英文，

38:04他说的都是错的，但是模型都会告诉他，你从一个非常不一样的视角给出了一个答案。你在让模型帮你去做一些东西。或者询问他让他做一些调研的时候，模型很容易偏向于你的思路，去找很多东西来证明你是对的。那这种情况下，理想状态是做一些对抗性的东西，让他做一些反方的顾问，反方的辩论，来找出你提的点当中不好的点，

38:31或者让他充分的头脑风暴去做一些研究，站在一个相对中立的一个角度。我感觉这一点是很重要的，就避免说你给模型在某些时候说了你的一些倾向，你认同什么方向的时候。那避免模型在潜移默化地在改变你。我感觉这是很需要注意的一个点。还有一个点，其实在前面也提过，因为现在做事情按古法编程最大的工作量，现在已经基本上速度非常快，

39:01已经不消耗什么时间成本，或者说不需要专业的人来做了。确实会导致呃你会更快地做出大量没人要的东西。所以对于一些需求场景的一些理解和判断，一定要杜绝这个东西顺手就能做的这一个点。对。所以我感觉这是两个风险吧，因为在大厂大厂待过嘛。

39:24那在大厂的组织管理里，可能大家都会去定一些OKR。那么OKR在web coding的时代还适用呢？或者说应该做出什么样的一些改变。以前我们写OKR的时候都是明确的会写一些我的动作，我的结果，算是一些这个功能交付清单叠加KPI的一个感觉。

39:46那在现在的话，我个人的一些建议其实是把这种OKR写成一种验证型的，少写完成了哪些功能，多写我验证了哪些假设。应该去更换一些写法。呃，在AI时代，我感觉它的价值不再是让……可以

40:04例如，我我以前可能更多的是写，我的某个产品必须、我某个功能的渗透率必须是多少。第一，限定的一些范围可能只限定在某个单一的功能上，但是可能完成某目标的一些思路特别多。那么我是不是可以快速地去打一些demo，找到中间更值得的一些功能，是有这种可能性的。

40:28因为以前我在一个双月或者一个季度上，以我的研发能力只能做到这一点。但是我现在是可以验证更多的一些方向，甚至可能验证出更强的一些方向。其实不能用OKR去约束大家的发挥，而是引导大家去探索更多的可能性。以前我们定OKR的时候，大家去定一些这个垫脚就能达到的一些目标。

40:55但是现在对于任何一个人，借助AI的这种产出，它的生产力其实比以前强了非常多。你不应该限定在一些单一的功能或者单一的目标上，而告诉他你是不是应该找出更多的一些可能性。如果你限定在单一的上面，我感觉大家的心态可能又是相对躺平。

41:16我web coding出这个功能，把这个功能交给增长，交给其他的一些人，你拼了命地去帮我推。我我感觉OKR的一个出发点，它相比于以前的KPI，其实有一个不同的点。就是它希望你自己自发地去定一些垫垫脚能做的目标。所以我们更应该发挥AI的生产力，中间探索的东西，更多可能性的一些东西加进去，而不是我限定一个非常明确的KPI，

41:45限制自己去做。那我感觉把AI的能力都浪费掉了。那

42:21后也会倒逼你去选，追求更高目标。

42:23其实这个想法，我个人感觉跟那个十倍增长比两倍增长更容易，这个点也是一样的。当你定出一个小的目标的时候，其实你想的就是优化。当你定出一个很大目标的时候，它在逼着你去用完完全不一样的一些思路去做事情，包括对客户群体更加聚焦，

42:42包括产品的形态，包括竞争的方式。以前我用OKR的时候，其实我一直感觉定出一个确定性很高的东西，然后让团队照着去做。我可能隔一段时间就问一下有没有跑偏，隔一段时间就问一下有没有跑偏。在现在这个年代，其实一个双月或者一个季度已经是非常漫长的一个时间点了。

43:01你应该把它整个制定的方式迎合AI的能力，来更快地去跑，去尝试更多的一些可能性。然后所以我现在对OKR，就是呃第一大的方向，你确保大家不跑偏，底下让大家去验证更多的可能性。我之前其实跟字节的老同事也有过一些沟通，也有同事就认为说可能现在这个年代不需要OKR，但是不需要OKR，

43:27大家容易跑偏，原来的一些出发点或者目标就变掉了。如果是有很明确的逻辑和数据来证明这个也是可以的，但是也不能天天跑，天天跑。对，这样对一些团队啊，对大家的一些凝聚力，其实也是有一些变化的。那这样，

43:56我我个人感觉，首先从项目成本来说，我感觉web coding是手段。或者说我利用模型的能力去帮我做调研，帮我做脑暴，做很多事情。在对人的一些依赖、对人的判断力的一些要求，其实还是很重要的。整个实现过程上面确实是非常快。而且我们像去在外面做一些调研，可以做到别人提出建议，实时就能看到做好的东西。

44:23对。可能大家把观点说完了。好。这边跑一下，那现场就看这个是不是你想要的。对，我们也能更好地去做出一些判断。

44:30所以对整体的过程，我怎么样收集用户真正的一个反馈，它不再是像以前说我我可能跟用户说一个想法，然后用户理解的跟我说的，可能他理解了百分之五十，得到的一个反馈可能也不一定准确。那现在说什么，言出法随，立刻一个实时的界面就出来了，你就问，这是你想要的吗？

44:52我们其实是能更快地做出判断。包括整个过程当中的研发，以前做一个东西以月级来，比如说三周，可能能做出一个呃不错的一个产品的功能。那现在一周可能能写个十几万行代码，也能快速地去反馈，快速地收集反馈，快速地去做一些验证。那不对的，我们立刻就做出一些改变。

45:14对。其实整体的一个速度会快很多，整体的效率也会高很多。

45:29其实其实，这不沟通了吗？我一直感觉沟通是个摩擦很大的事情。我讲的一些东西，可能别人理解到70%已经是非常高的一个情况了。所以我前面提到说，我说分工是不是可以按上下文来分工？或者说就一个独立模块，尽量减少跟别人的一些耦合。

45:48我们现在是把大家的一些工作分得更独立。独立不一定代表这个功能很小，也可能它在做很大的一个东西。过程当中，除非必要沟通，其他其实没有太大必要。

46:02是的，是的。因为人跟人之间对齐的摩擦是巨大，最费时间的。你与其在讨论一个观点，你对还是我对，还不如各自把demo都出一下，因为这个是非常快的。当对着demo说，最后讨论出来是这个人这个A方面做得比较好，另外一个人B方面做得比较好。

46:22我们现在的做法就是把两个人web coding出来的代码合到一起，就告诉，把这里面的A和那里面的B做一个整合，出来一个东西。所以现在基本上就是以前叫什么，叫呃token of chip，show me the code，

46:35show me the code。现在是呃大家是拿最实际的产物拿出来，根据讨论结果。其实把两个人的产品，或者大家认为中间值得可取的地方单独抽取出来，其实讨论完也就快速地形成了一个明确的结论和产品了。所以我们在过程当中，第一就是大家做更独立的一些事情。

46:57当然这就小团队而言，可能针对大型团队也有一些不一样的东西。还有就是每次讨论后我们实时的，而不是说，哎，我我回去把我的想法写一下，而是直接把你的demo出一下，把我的demo出一下，直接拿着demo来讨论。你

47:24会做一些，对。首先，现在外面有很多的skill合集，它对一些简单的功能已经可以直接做到。一些相对复杂的，像我们现在在做一些课程当中的实时的刷和任务，那它的一些难度，包括说中间可能存在的各种坑非常多。那我们针对一些我们认为大的风险点，会把这些事情都做得很到位。

47:46一些低风险的事情，我我认为现在的基本的web coding工具都可以直接搞定。你如果有一些担心的话，就是找一些专门的这种skill合集，像我早先用的那个Superpower，现在我电脑上装了非常多的那些合集之后呢，我也不知道它在用啥了。

Superpowers

48:03但是，嗯，很明确的是，

48:08也不知道他在弄。因为我装了很多，

48:13些重要的功能的门，还是会让研发同学进去深度地看一下，有可能要单独去写一些东西的。但基本的一些网页呀、app呀，其实现在web coding的工具已经做得不错了。

48:29是的。也有个前提，这个事情本身的一些难度。如果本身难度比较大，可能还要单独去做一些处理。对。如果网页常规的呀，我个人感觉现在我们自己也做过一些事情。

48:42例如说复杂功能，感觉上面还是需要一些架构能力更强的一些人来做。如果说有一个事情确实很难，我们自己内部也没有人手去做，例如说就让我一个好多年没怎么写代码的人来做的话，我可能的一些做法就是到GitHub呀，到相关的一些地方，就用一下我的原认知手段，怎么可以把这个事情做得更好。

49:04那就找到相似的一些代码，或者一些架构得非常好的代码，把它们扒下来，让web coding工具基于一些基础去写，或者参考一些很好的做法去写。那这种就可以让一些呃纯代码能力没那么强的人也写出很好的东西。所以我现在像经常让web coding工具帮我去做脑暴的时候，第一，我会让它我去全网收集一些东西。

49:29第二个，我一定会让它到GitHub上找到相似度最高的、观点相同的一些东西，或者可复用的东西，站在巨人的肩膀上去做很多事情。我现在也这么干。天然的就会比绝大部分普通人做得更好。对。

49:43了解。

49:59个人感觉有一些的。因为可能在以前的情况下，大家基本能力过关的一个情况下，比如说对人的一个比较好的评价，水平不错且非常靠谱。其实现在一个人就像我前面提的一个评价标准，叫杠杆率，就你能多大意义上撬动AI的能力。那有一些他可能在古法编程的情况下是非常靠谱的，产出非常稳定的，即使是很多节假日遇到很多问题也能及时响应的，

50:28你会发现你给他的分数会低一些。对。有一些思路非常清晰，很灵活的人。对。能够用模型去把很多原来干不了的事情能干好，并且能同时大量发挥模型能力的，例如说调很多个agent，

50:45用很多个bot来做一些事情的这种人，我感觉他可能发挥出来的能力是以前的十倍百倍。对。但是一些如果说没想明白怎么用的，就包括我前面说这种外包思维比较弱的，躺不平的，什么东西都不愿意放出去让模型去做的，对模型不信任的，那我感觉整体的一个产出各个方面会会差很多很多。

51:06所以在这过程当中，我们也算经历了整个Lab Coding发展的一个过程，其实也也在不停地变化。像现在再让我去评价一个人的时候，我会去看一个人的整体的一些业务sense，然后呃，元认知的一些能力，他是不是能快速地复盘前面做得不好的，快速地把模型的杠杆充分发挥出来的人。

51:28我感觉这种是在未来会更好更吃香的一种人。

52:07办？来，bot来学习。

52:11其实是的，复杂的问题。不同的公司，包括不同类型的，好像互联网公司跟传统制造业，制造业又分你to B的制造业，to B的制造业，其实大家的一些差别非常大。遇到这种情况，因为我之前刚好在江浙浙江，我去访谈了一些企业，包括传统的制造业，包括一些出海电商的一些企业。

52:34对，我一般情况下都会先问几个问题。第一个就是我自己希望在哪些地方做出一些改变。那这块给的一些回答其实归纳一下，相对比较明确，他们在成本支出最大的地方希望有一些变化。例如说，出海电商，那正常情况下它的投放成本，它的获客可能是像一些制造业方面，有一些B端的制造业，

52:56它可能抱住几个大客户就行了，所以它对整个生产设计的过程中间的一些要求会更高。不同的企业它诉求确实不一样。那我第一点会问他，他们认为想在什么地方做出改变。第二个点我都会问一下，就是你们公司内部大家大概的一个学历水平怎么样，人才密度怎么样。

53:15像出海电商可能还好一些，大家基本上都懂点外语啊，或者说怎么样的。像有一些制造业，可能一线的工人都是初高中的水平，而且年纪偏大的。就问一下他们内部大概的一个这种人才密度、学历水平、年龄，其实你看一下大概也就能简单了解到他们的AI的操作水平。

53:38反正整体我个人认知上，模型的能力其实现在已经很强了。已经在绝大部分的领域比普通人都要强。那最重要的事情就是怎么学好用好这些东西，并且让他们愿意去用。所以呢，我想不同的企业，我感觉最重要的第一点还是一把手的决心。他对AI的认知，以及说这个认知能给到他多大的一个决心，让他来推这个事情。

54:07所以这个事情我问了，那一定是，一把手工程嘛。底下你其他的一些落地，例如说从不同的组织层面，你从挑什么样的人来负责，从什么样的部门介入进去来做。怎么样让一线的人真正的用起来，我感觉这些都是第二步的一些事情了。所以反正整体来看，不同的行业，它的诉求有一些差异。

54:34确实要分情况来看。

54:49就做课的过程呢，我们基本上完全是用我们前面讲的这些研发流程在做。我们在做哪些课呢？其实一句话形容就是让普通人更好地用好大模型。例如说我们在做一些自媒体课，那有非常多的人都希望说，哎我开个自媒体，我开个小红书，开个抖音，开个微信公众号，开个视频

55:14我们课大概八月十四号上线。

55:20我们跟一些外部的专家，风语里的专家，包括自媒体的专家来做自媒体课。我们跟国内一些头部的AI领域的KOL在合作一些AI的入门课，让人更好地写prompt，做skill，做工作流，让他们在日常的工作生活当中都能把模型用起来。

55:42对。包括一些FDE课程，这些我们都在做一些开发。你们为什

55:48我们整个团队基本上是教育行业出来的，包括创始人，包括团队的核心成员，基本上都有很多年的教育经验。自己是会教育的。整个团队成立最初的想法，其实也是研究一下未来的社会需要什么样的人，以及通过什么更好的手段去培养人。所以公司的名字叫Aurora，就Aurora Academy的简写。

56:12终

56:14这么久才看懂。我

56:17的，Aurora Academy。

56:19对，最初的想法是，呃，在AI时代，这个社会未来需要什么样的人，我们用什么样的手段能够把他们培养好。所以我们做这些课的时候也是一样的想法。现在你在学校里面学的那些知识，不管是基础的语数外还是各个专业的一些知识，那现在模型可能在绝大部分领域比真人要好很多。

56:42你去解题，模型现在解题做得也很好。在很多领域实际的落地的时候，你会发现模型做得也比很多真人要好。你再去学这种传统的教材，还有多大的一个作用？我认为对培养人的基本的一些素质你的判断力啊，你的批判性思维能力啊，你的逻辑，各个方面的一些能力，

57:03我感觉还是有用的。但是我用一个类比来形容，以前你从一个地方到另外一个地方，你是靠两条腿走路，后来马被驯服之后，你开始骑马。现在你其实开车，以前是油车，现在是智能车。我感觉我们现在的这个课堂，它有点像一个驾校，就是你把大模型理解成一辆车，而现在的智能车没事还给你更新一下系统，

57:27这个车本身在进化。你需要学的是怎么样把这辆车开得更好，而不是像以前一样说我把腿训练得肌肉更发达，我要跑得更快。所以呢，我们把自己做的这些课程比喻成一个驾校。第一，你可能需要学一些跟大模型Agent相关的基本的一些操作，但你把它操作好就可以了。

57:50普通人不需要对它有非常专业的一个理解，你只要抓好方向盘，把车开走，知道刹车，知道踩一下油门电门就可以了。所以我们是这样的一个想法，所以我们的课程相比于传统来说，它也更像驾校。我们会教你如何使用这些skill。我们还会有录课实时的一些演示演练，你可以在里面去学习如何做一个自媒体，如何给自己的账号做定位。

58:16如何做竞品分析，如何生成一些标题、文章、图片，如何判断我生成的是好的，如何后续做数据复盘。我把我们现在在做的一些事情比喻成一个AI时代的驾校，你要学习更好地驾驭

59:13很快就会上线，也就像你说的，新的职业企业有需要的。那这个过程中确实需要培训，需要认证体系。每个人都说自己是FDE，我们最近前段时间，这个FDE，拉一个FDE的群，在两个小时内五百多五百人就加进来，每个人都说自己是个FDE。

59:30都开始要叫FDE。我们确实是希望在整个这个行业里面，有大量的供给，不管是因为大厂被波裁员也好，还是主动希望自己AI能力很强，需要去探索一些新的这可能性。但我觉得这个事情本质上也是未来新的组织形式，就像今天我们提到，未来组织它就不是像传统那样巨型企业，

59:49每个人都是一个庞大的一个系统。它可能是很多灵活，你需要某一个小的环节的时候，哎，可能有个FDE就帮你快速塑造了。不管是传统企业还是新的企业，我们其实会给所有这些职业去培训定义。去认证体系。对。

1:00:05很快就会有了。而且这个再补充一下，徐文浩刚才说到我们为什么做一个课程体系。任鑫也一直说到一个点，现在人与人很重要的一个差别，其实是你是不是能够用很好的工具去解决问题的能力，而不是像传统。我们做教育这么多年，经历了几个，其实迭代几个版本的这个产品，也是见证了这个过程，也是符合我们团队刚才说的web coding的不同的阶段。

1:00:29你像我们最开始Iberi那个产品，单纯是人学习。因为我们当时觉得，哎，AI来了，然后你好多东西要新的去学，所以你要快速去学一些新的，认知上都要提升。那今年初的时候。我们又开始意识到，大量的agent的时代进入一个新的纪元。

1:00:47你突然有大量的，你可以可以干很多事儿，一键发小红书，一键去做这个写coding等等。所以我们当时就做了一个叫龙虾大学或者agent的大学。这个上次在任鑫这里面大家也讨论过，那更像一个agent的一个自习室。你想要完成什么任务，你一键告诉它，agent自己去向其他所有的agent自动去学习，就是一键。

1:01:10但是其实当你不断地经历了这个社区里面也有很多这种海量的agents，包括我们自己大量的开发者，在真正地落到一线的工作业务。其实有一些东西，人的要素也很重要。有一些东西应该让agent的，比如说我们最近的小红书课里面，我帮你搭建你的这个做竞品研究的agent，

1:01:30自动做封面的这个agent，等等这些。但是有一些你的输入，你的个人故

1:01:38题。那我就得带着你

1:01:41的小红书的你的个人的定位，你的故事，这个是你有东西，你得输入你的一些今天出的新的想法，明天出的新的想法，你希望的品味调性，你得参与到过程当中。而我们希望这个人为什么叫人机共学的课，包括徐文浩说的家校的这个理念也是类似的。

1:01:58就是我们希望把人的创造力的因素放到极致，然后让你的agent帮你处理掉那90%的最routine的东西。所以你看上次我不知道可嘉有没有说到，我们做伯乐的有个理念叫10%/90%的一个理念，就希望90%那种boring的routine的东西，

1:02:15agent帮你上学去学掉。真正的那10%的创造力的部分，human in the loop的部分，你可以专注去解决。

1:02:40西嘛。而且在过程中我们也搭了一套测评体系，去测你的agents它的能力。过去其实几个月当中，几万的agents在我们的平台上去测了自己的这个能力。我们慢慢也会升级成，就是你和你的agents怎么样通过一个更好的workflow去证明你的能力，

1:02:56包括你说的认证体系等等。其实我们都

1:02:58对，这里面其实也有个观察。现在大家在面试的时候呢，已经不仅仅是面一个人了，而是基本上都会问你，甚至说很实时地让你去解决一些问题。我会认为说，未来一个人的能力是什么，可能是自己加agent的一个合体。对。其实就我刚才说的杠杆，你能通过这个杠杆撬动多大的AI的能力，帮你解决多大的一个事情。

1:03:26甚至说我之前一直说大量的企业在蒸馏自己的员工。其实我一直在想一个很有意思的东西，比如说未来我留给自己孩子最好的东西，有可能是大量做好的agent。好的。最

1:04:18众？那我先说。

1:04:26我其实最近有一个，包括做我们的产品过程中，我一直有个理念，也是我作为一个文科生，因为有了AI让我受益的一个新的学习理念，叫learning by building。因为你得建立你在做的过程当中，不管是我们创业也好，还是我们自己学的东西也好，现在学习的最好方式不是去看一堆的那种视频课。

1:04:48我们现在其实里面也不是这种，就是你听一看一堆的这个文章，当然有你的认知有启发，但真正的学习的发生，包括你自己的进化的发生，在你真的做的过程当中，为了实现它，你用各种AI工具，最后有一个作品能够展示。不管是这个用作自己看，还是说真的有真实的用户。

1:05:07所以我最大的建议就是找一个project，不仅仅不管是你用来创业，用还真正的挣钱，哪怕只是说自己的日常的这个有趣的生活。但过程中尽可能地能用AI就用AI，不要用传统的那种hiring，就是你加一堆的agents，把这个产品从头到尾全部做出来，且有真实的这个用户。

1:05:29因为现在有太多的这种资源可以帮助你做这个事情。网上很多听任鑫的播客，当然你愿意的话也在伯乐里面去学习进阶其实都可以。但是核心点我一直有一个理念，现在is the age for builders。所以我们也希望和更多的builders一起去探索新的可能性。

1:05:47很好。结

1:05:51对对对，是的，就学

1:06:02是的，非常同意。对，我再简单想一个东西，我刚才其实提了一个点，我说以后给自己的孩子留下的是什么东西，有可能把自己蒸馏出来，大量的经验，把自己很多的做法、思路、思考的框架。孩

1:06:20对，所以我特别建议的就是，大家把自己的大量的上下文蒸馏一个自己试试，站到第三方的一个角度，站到飘到天上的一个角度来看蒸馏出来的自己是什么样子。能够定义一下我希望成为的自己，那个蒸馏出来的自己这边先去做一些优化，做一些尝试。

1:06:42这可能也是元认知的一种方式吧，你飘到天上去看自己，你每天你在开会，你在写文档，你在做各种各样的一些事情，有没有可能把它们录制下来，形成一个上下文。它可以帮助你更好地看清自己。如果说你希望去提升自己的话，可能有一个更客观的一个角度去看。

1:07:04我的一个建议就是，尽可能把自己日常当中的各种数据能够沉淀下来，蒸馏自己，客观地看待

1:07:43这个人生真是充满浪漫主义。我们去合个影吧，最后我们就直接对着台合个影。我把它放大一下。

1:08:11谢谢。谢谢。[