本集简介
双语字幕
仅展示文本字幕，不包含中文音频；想边听边看，请使用 Bayt 播客 App。
There's something there.
There's something there.
啦啦啦啦。
啦啦啦啦。
我最近呢经常和各种人去讨论 AI 时代的组织形式这件事情，因为我觉得组织形式在 AI 时代的重要性，其实现在仍然是被大大低估的。
我最近呢经常和各种人去讨论 AI 时代的组织形式这件事情，因为我觉得组织形式在 AI 时代的重要性，其实现在仍然是被大大低估的。
甚至于中长期来看，组织形式很可能就是新一代的创业公司和传统公司相比最大的竞争优势跟壁垒。
甚至于中长期来看，组织形式很可能就是新一代的创业公司和传统公司相比最大的竞争优势跟壁垒。
因为传统的大厂现在最大的问题就是分工实在是太细了。
因为传统的大厂现在最大的问题就是分工实在是太细了。
分工如果太细，就说明这个团队里面缺少核心的人，对模型的掌控和对最终产品的输出结果来负责。
分工如果太细，就说明这个团队里面缺少核心的人，对模型的掌控和对最终产品的输出结果来负责。
但反而是创业公司，几个人就能做很多端到端的事情，他们更理解模型能力的边界。
但反而是创业公司，几个人就能做很多端到端的事情，他们更理解模型能力的边界。
更理解哪些用户需求是可以用模型的哪些能力来达到的。
更理解哪些用户需求是可以用模型的哪些能力来达到的。
所以呢前段时间我们就请到了在湾区创业的一个好朋友，讲了讲他们是怎么打造 AI native 的工程团队的。
所以呢前段时间我们就请到了在湾区创业的一个好朋友，讲了讲他们是怎么打造 AI native 的工程团队的。
他们做了很多有意思的事情，在后面的他的分享里都会讲到。
他们做了很多有意思的事情，在后面的他的分享里都会讲到。
比如说他们现在90%的代码都是 AI 写的，比如说他们现在可能有20人左右的团队，但里面是没有任何一个 PM 的。
比如说他们现在90%的代码都是 AI 写的，比如说他们现在可能有20人左右的团队，但里面是没有任何一个 PM 的。
全都是工程团队在做所有的事情。
全都是工程团队在做所有的事情。
我觉得这一期的分享是非常有价值的，所以我们非常快的就把这一期剪了出来，然后希望能让更多的国内的创业者，跟做 AI 的人听到，因为我觉得大家呢应该能从这一期播客里面得到很多启发。
我觉得这一期的分享是非常有价值的，所以我们非常快的就把这一期剪了出来，然后希望能让更多的国内的创业者，跟做 AI 的人听到，因为我觉得大家呢应该能从这一期播客里面得到很多启发。
就是弯曲最先进，甚至于说有点激进的组织管理形式到底是怎么样的？
就是弯曲最先进，甚至于说有点激进的组织管理形式到底是怎么样的？
他们是如何利用 AI 的？
他们是如何利用 AI 的？
他们是怎么处理？
他们是怎么处理？
团队跟 AI 之间的关系的。
团队跟 AI 之间的关系的。
所以后面这部分呢，首先是他个人的一个完整的分享，然后后面呢会接一些我们当时活动现场的问答，我觉得都非常的精彩。
所以后面这部分呢，首先是他个人的一个完整的分享，然后后面呢会接一些我们当时活动现场的问答，我觉得都非常的精彩。
我叫任川，来自 Blomma AI。
我叫任川，来自 Blomma AI。
之前在 Google 和 LinkedIn 都做过几年。
之前在 Google 和 LinkedIn 都做过几年。
我们公司的主要业务是做 restaurant AI，就是说用 AI 来帮助餐饮行业提效。
我们公司的主要业务是做 restaurant AI，就是说用 AI 来帮助餐饮行业提效。
我们第一个产品呢，其实就是帮餐馆接电话。
我们第一个产品呢，其实就是帮餐馆接电话。
因为在美国还稍微有点落后，没有美团呀，国内现在打的正热闹，这些先进的东西，就会员订披萨，还有很多人打电话。
因为在美国还稍微有点落后，没有美团呀，国内现在打的正热闹，这些先进的东西，就会员订披萨，还有很多人打电话。
然后呢这边接电话的人可能每个小时你要雇人的话，也要至少25美金。
然后呢这边接电话的人可能每个小时你要雇人的话，也要至少25美金。
所以说我们的产品可以 end to end，你的电话完全不用响了，我们可以 take a预约，take a order，普通的咨询都是可以做到的。
所以说我们的产品可以 end to end，你的电话完全不用响了，我们可以 take a预约，take a order，普通的咨询都是可以做到的。
然后我们的主要的价值在于我们是 AI agent 里面少数可以做到95%~98%可靠性的公司。
然后我们的主要的价值在于我们是 AI agent 里面少数可以做到95%~98%可靠性的公司。
大部分现在的 AI agent 产品，它的可靠性一般可能在百分之七十左右已经很不错了。
大部分现在的 AI agent 产品，它的可靠性一般可能在百分之七十左右已经很不错了。
但对于我们来说呢，我们这个是非常实用，你可以完全放心，就是不用再有人来管这个电话了。
但对于我们来说呢，我们这个是非常实用，你可以完全放心，就是不用再有人来管这个电话了。
当然这个具体我其实在别的地方有一个纯技术方面的分享，我们是怎么做到的。
当然这个具体我其实在别的地方有一个纯技术方面的分享，我们是怎么做到的。
但是今天呢，咱们就不讨论那些技术问题，而是稍微聊一下，在这个背后，我们这个团队是什么样的。
但是今天呢，咱们就不讨论那些技术问题，而是稍微聊一下，在这个背后，我们这个团队是什么样的。
我们的这个题目呢，是如何打造 AI native 的工程团队。
我们的这个题目呢，是如何打造 AI native 的工程团队。
然后今天主要分三个部分。
然后今天主要分三个部分。
第一个部分呢，讲我们的 AI native 的工作流，就是一些比较实际的，我们公司是怎么利用 AI 工具做研发工作的。
第一个部分呢，讲我们的 AI native 的工作流，就是一些比较实际的，我们公司是怎么利用 AI 工具做研发工作的。
第二部分呢，就是讲讲人。
第二部分呢，就是讲讲人。
我们觉得 AI native 时代需要什么样的人才？
我们觉得 AI native 时代需要什么样的人才？
第三部分呢，讲讲组织，就在 AI 时代，AI native 的组织应该是什么样的？
第三部分呢，讲讲组织，就在 AI 时代，AI native 的组织应该是什么样的？
那咱们就先进入第一部分，重构工作流来提升10倍效率。
那咱们就先进入第一部分，重构工作流来提升10倍效率。
呃，这个10倍效率其实第一个虚数了，我自己的感觉呢，应该是远不止10倍效率。
呃，这个10倍效率其实第一个虚数了，我自己的感觉呢，应该是远不止10倍效率。
我可以稍微举一个例子，在我们公司研发工作大概什么样的？
我可以稍微举一个例子，在我们公司研发工作大概什么样的？
其中有一个环节叫做代码审查，Code Review，Code Review 这个过程呢，在 Google 平均的需要的时间差不多是1~2天。
其中有一个环节叫做代码审查，Code Review，Code Review 这个过程呢，在 Google 平均的需要的时间差不多是1~2天。
Google 作为古典的一个互联网科技公司，它的工程效率已经是非常非常优化了。
Google 作为古典的一个互联网科技公司，它的工程效率已经是非常非常优化了。
那这个时间在我们公司是10分钟，这个10分钟和一到两天相比，肯定是提升了不止10倍。
那这个时间在我们公司是10分钟，这个10分钟和一到两天相比，肯定是提升了不止10倍。
那我们怎么能做到10分钟 code review 这个事呢？
那我们怎么能做到10分钟 code review 这个事呢？
这个也非常简单，就是我们只让 AI 来 review。
这个也非常简单，就是我们只让 AI 来 review。
我们公司去年4月份成立的，大概到六七月份的时候，我们就开始用这个 AI 的 code review 我们用的一个工具叫做 Cold Rabbit AI。
我们公司去年4月份成立的，大概到六七月份的时候，我们就开始用这个 AI 的 code review 我们用的一个工具叫做 Cold Rabbit AI。
在当时是为数不多的做 code review 的工具，现在已经有挺多的了。
在当时是为数不多的做 code review 的工具，现在已经有挺多的了。
但是我们还是继续用这个 Code Review 的 AI，我们用下来觉得还是最合适的。
但是我们还是继续用这个 Code Review 的 AI，我们用下来觉得还是最合适的。
那即便它是同类产品里面最好，但实际上还是有很多问题。
那即便它是同类产品里面最好，但实际上还是有很多问题。
比如说 AI 虽然 review 了之后，哎觉得这个 code ok，check in 了，出了问题怎么办呢？
比如说 AI 虽然 review 了之后，哎觉得这个 code ok，check in 了，出了问题怎么办呢？
这个道理也特别简单，因为我们可以做到10分钟的 code review，code 就可以进这个生产环境，那这10分钟如果在生产环境上发现问题。
这个道理也特别简单，因为我们可以做到10分钟的 code review，code 就可以进这个生产环境，那这10分钟如果在生产环境上发现问题。
一可以直接把这个 code rollback 或者 revert 就是说把它给撤回。
一可以直接把这个 code rollback 或者 revert 就是说把它给撤回。
或者呢，你可以直接在线上就把它给 fix 掉。
或者呢，你可以直接在线上就把它给 fix 掉。
这件事如果大家有经验的话，今年是稍微有点危险，或者稍微有点不符合传统的啊，但是在传统的开发流程中，如果你每一次 review 都需要一到两天，那你这个事是不可能实现的。
这件事如果大家有经验的话，今年是稍微有点危险，或者稍微有点不符合传统的啊，但是在传统的开发流程中，如果你每一次 review 都需要一到两天，那你这个事是不可能实现的。
但是如果每一次只要10分钟就可以 fit 出来，实际上。
但是如果每一次只要10分钟就可以 fit 出来，实际上。
这个 work 是可以实现的，我们从差不多今年年初开始，已经不要求人来 review code 了，啊，只要 AI approve 了，我们就可以直接把 code merge 所以试用下来半年多，效率非常高，而且这个效果也是非常好的。
这个 work 是可以实现的，我们从差不多今年年初开始，已经不要求人来 review code 了，啊，只要 AI approve 了，我们就可以直接把 code merge 所以试用下来半年多，效率非常高，而且这个效果也是非常好的。
然后， code review 只是其中一个例子。
然后， code review 只是其中一个例子。
啊，通过这个例子呢，我想分享总共这个工作流里面的几个原则吧，或者几个经验。
啊，通过这个例子呢，我想分享总共这个工作流里面的几个原则吧，或者几个经验。
第一个呢就是，我们默认由 AI 承担所有研发工作。
第一个呢就是，我们默认由 AI 承担所有研发工作。
注意，我这里面写的是研发工，而不只是 coding 的工作。
注意，我这里面写的是研发工，而不只是 coding 的工作。
研发整个流程呢，从比如说写文档，到写各种 test 到写设计文档，然后到写代码，到 Code Review，到最后上线之后，还需要做这种监控。
研发整个流程呢，从比如说写文档，到写各种 test 到写设计文档，然后到写代码，到 Code Review，到最后上线之后，还需要做这种监控。
所以 AI 不简简单单只是在 coding 的部分有价值。
所以 AI 不简简单单只是在 coding 的部分有价值。
那因为这个公司创建的比较新，大概去年4月份成立，所以我们第一个想法就是我们能不能让 AI 把这个全流程都干了？
那因为这个公司创建的比较新，大概去年4月份成立，所以我们第一个想法就是我们能不能让 AI 把这个全流程都干了？
但实际上现在的情况，AI 的能力是肯定达不到的，但是呢我们把这块做一个逻辑的转换，哪个地方 AI 还做不到，我们用人去，来帮他弥补。
但实际上现在的情况，AI 的能力是肯定达不到的，但是呢我们把这块做一个逻辑的转换，哪个地方 AI 还做不到，我们用人去，来帮他弥补。
但是这个时候人需要有一个非常充分的理由，而不是说人来默认完成这个工作，哎，觉得 AI 好的时候再去。
但是这个时候人需要有一个非常充分的理由，而不是说人来默认完成这个工作，哎，觉得 AI 好的时候再去。
让 AI 来做，这样子我们发现了非常多的部分可以由 AI 来直接承担工作的。
让 AI 来做，这样子我们发现了非常多的部分可以由 AI 来直接承担工作的。
我稍微举一几个工具，大家如果有兴趣可以试用。
我稍微举一几个工具，大家如果有兴趣可以试用。
第一个我们在 coding 的时候用的一个工具叫做 Linear。
第一个我们在 coding 的时候用的一个工具叫做 Linear。
Linear 其实是 track 我们的整个工作的。
Linear 其实是 track 我们的整个工作的。
Linear 加 Devin，Devin 的话是一个 coding 的工具，也是一个华人团队做出来的。
Linear 加 Devin，Devin 的话是一个 coding 的工具，也是一个华人团队做出来的。
它的效果就是说，我每次创建一个 linear 的 task 之后，你只要它，哦，发给 Devin，Devin 会自动创建代码。
它的效果就是说，我每次创建一个 linear 的 task 之后，你只要它，哦，发给 Devin，Devin 会自动创建代码。
其实这整个过程，你连 IDE 都没有打开，连你的代码工具都没有打开。
其实这整个过程，你连 IDE 都没有打开，连你的代码工具都没有打开。
嗯，你可以同时创建10个 task，然后就产生10个代码。
嗯，你可以同时创建10个 task，然后就产生10个代码。
所以这个是和人的研发工作是完全不一样的。
所以这个是和人的研发工作是完全不一样的。
然后呢我们在这个生产环境中做监控的时候，用一个工具叫做 incidents 点 io 它的工作呢，就是说它把所有的 log 不管你的 log 可能是在 AWS 上面，或者在 DataDog 上面。
然后呢我们在这个生产环境中做监控的时候，用一个工具叫做 incidents 点 io 它的工作呢，就是说它把所有的 log 不管你的 log 可能是在 AWS 上面，或者在 DataDog 上面。
把这些 log 全都收集起来，它自动的分析这些 log，给你提醒呀，甚至出 incident 之后给你一些分析。
把这些 log 全都收集起来，它自动的分析这些 log，给你提醒呀，甚至出 incident 之后给你一些分析。
但这个呢，其实大概能够 cover 我们百分之40~50的工作，还不像扣点那么完善，但是其实已经，我们公司是没有 SRE 的，就是没有运维的人员，完全靠一半的工程师，一半 Instant IO。
但这个呢，其实大概能够 cover 我们百分之40~50的工作，还不像扣点那么完善，但是其实已经，我们公司是没有 SRE 的，就是没有运维的人员，完全靠一半的工程师，一半 Instant IO。
大概我们的研发工作流是这样哈。
大概我们的研发工作流是这样哈。
所以这是第一个经验啊，尽量让 AI 承担所有的工作。
所以这是第一个经验啊，尽量让 AI 承担所有的工作。
第二一个经验就是，特别是在 coding 方面了，要用 Cloud Code，这个有点尴尬，因为我在准备的这个时候还是推荐 Cloud Code，但是上周好像 Anthropic 把国内给封了，不让用了。
第二一个经验就是，特别是在 coding 方面了，要用 Cloud Code，这个有点尴尬，因为我在准备的这个时候还是推荐 Cloud Code，但是上周好像 Anthropic 把国内给封了，不让用了。
但是我们自己用起来，Cloud Code 还是最好用的。
但是我们自己用起来，Cloud Code 还是最好用的。
有几点原因吧，一个原因就是它本身的能力也是非常强的，因为毕竟 Anthropic 对这个模型肯定是最理解的。
有几点原因吧，一个原因就是它本身的能力也是非常强的，因为毕竟 Anthropic 对这个模型肯定是最理解的。
第二一个呢，就是 Cloud Code 本身是有 SDK 的，我们可以在上面做非常多的二次开发。
第二一个呢，就是 Cloud Code 本身是有 SDK 的，我们可以在上面做非常多的二次开发。
而且不要被这个 Cloud Code 的这个 Code 部分，这个名字给影响了，它做的绝对不只是扣点工作。
而且不要被这个 Cloud Code 的这个 Code 部分，这个名字给影响了，它做的绝对不只是扣点工作。
那我这块第二个经验呢，就是只要有 SOP，就没有 call center 的没法完成任务。
那我这块第二个经验呢，就是只要有 SOP，就没有 call center 的没法完成任务。
这句话其实不是我说的，实际上是 call center 全球第一人说的，这个人是谁呢？
这句话其实不是我说的，实际上是 call center 全球第一人说的，这个人是谁呢？
叫做刘小排。
叫做刘小排。
他是一个咱们华人的创业者，然后他前一段时间比较有名，就是因为 Android 也发现有一个，其实就是刘晓排了，他每个月花200块钱买的 Max Plan。
他是一个咱们华人的创业者，然后他前一段时间比较有名，就是因为 Android 也发现有一个，其实就是刘晓排了，他每个月花200块钱买的 Max Plan。
但是它 token 消耗量要达到5万美金，它基本上7×24小时在用这个 claude 的 API。
但是它 token 消耗量要达到5万美金，它基本上7×24小时在用这个 claude 的 API。
他自己有一个公众号，就叫刘小白，非常推荐大家去学习一下 claude code 是怎么使用，因为发现这个远远不只是做 coding 的工作。
他自己有一个公众号，就叫刘小白，非常推荐大家去学习一下 claude code 是怎么使用，因为发现这个远远不只是做 coding 的工作。
这是第二点经验吧，然后第三点经验就是，你看我们默认让 AI 承担大部分工作，然后呢人来去补充这些 AI 做不了的事情。
这是第二点经验吧，然后第三点经验就是，你看我们默认让 AI 承担大部分工作，然后呢人来去补充这些 AI 做不了的事情。
那人自己的工作有一个什么经验，或者有一个什么原则呢？
那人自己的工作有一个什么经验，或者有一个什么原则呢？
就是尽量一个人独立，恩，恩，恩，把这个工作完成，减少人和人之间的交互。
就是尽量一个人独立，恩，恩，恩，把这个工作完成，减少人和人之间的交互。
这件事其实在各个公司都有一些反直觉，因为我们老觉得开会啊、拉通对齐，这个是工作里面非常重要的一个内容。
这件事其实在各个公司都有一些反直觉，因为我们老觉得开会啊、拉通对齐，这个是工作里面非常重要的一个内容。
但是当你的工作流变得 AI native 之后，你会非常明显的发现，人和人之间的交流一下子都会非常容易变成瓶颈。
但是当你的工作流变得 AI native 之后，你会非常明显的发现，人和人之间的交流一下子都会非常容易变成瓶颈。
然后我们的原则就是尽量减少人和人之间的冗余，如果要冗余，就是比如说这个研发工作，把你的想法，把你的原则也好，冗余到 code base 里面，大家自动的就人和人也好，人和 AI 也好。
然后我们的原则就是尽量减少人和人之间的冗余，如果要冗余，就是比如说这个研发工作，把你的想法，把你的原则也好，冗余到 code base 里面，大家自动的就人和人也好，人和 AI 也好。
就完了。
就完了。
但是说到这呢，那这个工作方式和之前传统的工作团队是有点不一样的，那需要什么样人才呢？
但是说到这呢，那这个工作方式和之前传统的工作团队是有点不一样的，那需要什么样人才呢？
咱们进到第二部分，就说在未来呢，成为 AI 工程师或者在 AI 的工程团队最需要的人才是什么样的？
咱们进到第二部分，就说在未来呢，成为 AI 工程师或者在 AI 的工程团队最需要的人才是什么样的？
那这里边呢，我差不多根据我们这个经验总结了三点。
那这里边呢，我差不多根据我们这个经验总结了三点。
第一个呢叫做 Context Provider，这件事其实在大多数地方应该很少有人提到。
第一个呢叫做 Context Provider，这件事其实在大多数地方应该很少有人提到。
从我们自己的感觉来讲，一定要转变一个思路，就是说不要把 AI 只当成工具，好像 AI 工具给人提效10倍也好，50倍也好，其实并不是这样，它真正的价值是，人给 AI 提供 context 或者说人为 AI 提效。
从我们自己的感觉来讲，一定要转变一个思路，就是说不要把 AI 只当成工具，好像 AI 工具给人提效10倍也好，50倍也好，其实并不是这样，它真正的价值是，人给 AI 提供 context 或者说人为 AI 提效。
我们有一个原则，就是人加上 AI 之后，他的产出要大于 AI 本身。
我们有一个原则，就是人加上 AI 之后，他的产出要大于 AI 本身。
这个看起来好像是显而易见的，但是呢，仅仅是我们这个一年多的经验，有很多的时候，人加入以后，实际上会让这个 AI 的效率变差，或者让整个的团队效率变差，这个是挺常见的事情。
这个看起来好像是显而易见的，但是呢，仅仅是我们这个一年多的经验，有很多的时候，人加入以后，实际上会让这个 AI 的效率变差，或者让整个的团队效率变差，这个是挺常见的事情。
那其实前一段时间有一个非常流行的概念叫做 Context Engineering。
那其实前一段时间有一个非常流行的概念叫做 Context Engineering。
他的概念是什么呢？
他的概念是什么呢？
就是我们现在的底层模型的能力已经非常强了。
就是我们现在的底层模型的能力已经非常强了。
之所以 Agent 或者之所以你的 AI 工作流不 work，更多的是因为
之所以 Agent 或者之所以你的 AI 工作流不 work，更多的是因为
上下文工程的失败，或者说你的 context 没有提供对。
上下文工程的失败，或者说你的 context 没有提供对。
并不是因为模型本身的问题，作为我们 AI 的团队来讲，其实是一样的。
并不是因为模型本身的问题，作为我们 AI 的团队来讲，其实是一样的。
我们 AI 并不是说它的能力不行，不够聪明，而是说它没有拿到足够的 Context。
我们 AI 并不是说它的能力不行，不够聪明，而是说它没有拿到足够的 Context。
所以 context for whether 在这里面不但在工程上有价值，同时呢，比如说产品，比如说像我们做餐饮行业，我们有一个团队的成员，他是在暑期经常在餐馆里面端盘子，这些餐饮整个流程。
所以 context for whether 在这里面不但在工程上有价值，同时呢，比如说产品，比如说像我们做餐饮行业，我们有一个团队的成员，他是在暑期经常在餐馆里面端盘子，这些餐饮整个流程。
这些 context 实际上是对模型非常非常重要的，但是这些东西可能是模型本身并没有的知识。
这些 context 实际上是对模型非常非常重要的，但是这些东西可能是模型本身并没有的知识。
啊，所以人的特别重要的价值叫做 context provider 这是第一点。
啊，所以人的特别重要的价值叫做 context provider 这是第一点。
第二一点呢叫做 faster learner 就快速学习。
第二一点呢叫做 faster learner 就快速学习。
呃，这里面的快速学习并不是指说遇到一个问题，我能够非常快的学习，然后学的比 model 还强。
呃，这里面的快速学习并不是指说遇到一个问题，我能够非常快的学习，然后学的比 model 还强。
呃，这个已已经再也不可能，我是这么觉得，就是人已经不可能比 AI 更聪明了。
呃，这个已已经再也不可能，我是这么觉得，就是人已经不可能比 AI 更聪明了。
呃，这块的 fasten 其实指的是你快速学习掌握最少必要知识，然后能够跟 AI 沟通。
呃，这块的 fasten 其实指的是你快速学习掌握最少必要知识，然后能够跟 AI 沟通。
在我们团队呢，包括面试也好，包括平时工作也好，有一个特别重要的事，就是说我们不太在乎其他的团队成员这件事会不会，我们只在乎这个目标，这个问题定义的是不是清楚。
在我们团队呢，包括面试也好，包括平时工作也好，有一个特别重要的事，就是说我们不太在乎其他的团队成员这件事会不会，我们只在乎这个目标，这个问题定义的是不是清楚。
只要定义清楚，我们认为它就应该是能够解决。
只要定义清楚，我们认为它就应该是能够解决。
当然了，实际解决起来肯定会碰到非常多困难。
当然了，实际解决起来肯定会碰到非常多困难。
但是我们对每个人的要求都是不要去看你现在有什么 skill，而是要看你能快速学习，然后把 AI 的这部分的潜力激发出来，这是最重要的。
但是我们对每个人的要求都是不要去看你现在有什么 skill，而是要看你能快速学习，然后把 AI 的这部分的潜力激发出来，这是最重要的。
啊，所以第二点是 fast learner。
啊，所以第二点是 fast learner。
第三一点呢叫做 hands on builder，就是说每个人都要是一个 builder。
第三一点呢叫做 hands on builder，就是说每个人都要是一个 builder。
一个 builder 的概念呢指的是说在整个工作里面，你要对最终的那个结果负责，要对全流程负责。
一个 builder 的概念呢指的是说在整个工作里面，你要对最终的那个结果负责，要对全流程负责。
你负责这个可能是整个大的产品的一小部分，但是呢你也要对最终的结果负责。
你负责这个可能是整个大的产品的一小部分，但是呢你也要对最终的结果负责。
那我们可能有一些岗位，比如说他只是做前期的整理工作，或者做前期的研究工作。
那我们可能有一些岗位，比如说他只是做前期的整理工作，或者做前期的研究工作。
但是如果他不能够对最后的结果负责的话，就会产生一个问题，其实是我们刚才讲的，就会有一个人和人之间，Context share，或者说要分享这个上下文，或者分享这些知识的过程。
但是如果他不能够对最后的结果负责的话，就会产生一个问题，其实是我们刚才讲的，就会有一个人和人之间，Context share，或者说要分享这个上下文，或者分享这些知识的过程。
只要有人和人之间分享过程，一下子就会拉低整个 AI 那处团队的效率。
只要有人和人之间分享过程，一下子就会拉低整个 AI 那处团队的效率。
这是第二部分，就是说 AI 工程师需要的三个主要技能。
这是第二部分，就是说 AI 工程师需要的三个主要技能。
然后第三个部分呢，就稍微更虚一点，讲讲这个组织的形式。
然后第三个部分呢，就稍微更虚一点，讲讲这个组织的形式。
刚才稍微也 cover 了一点的话，就是说第一条，我们希望整个组织每个人按结果分工，而不是按流程分工。
刚才稍微也 cover 了一点的话，就是说第一条，我们希望整个组织每个人按结果分工，而不是按流程分工。
每个人为结果负责，而不是为中间流程的某一部分负责。
每个人为结果负责，而不是为中间流程的某一部分负责。
按结果分工的话是什么意思呢？
按结果分工的话是什么意思呢？
比如说我有一个小团队，他只对商家最终的体验负责，我们内部叫 Business Experience。
比如说我有一个小团队，他只对商家最终的体验负责，我们内部叫 Business Experience。
另一个小团队，他为消费者最终的 experience 负责，叫做 Consumer Experience。
另一个小团队，他为消费者最终的 experience 负责，叫做 Consumer Experience。
实际上 Experience 团队，他的工作内容前端的会多一些，但是呢，我们不分成说有前端团队，有后端团队，团队，你就是为 Experience 负责，如果 Backend 里面有哪些影响了最后前端的效果。
实际上 Experience 团队，他的工作内容前端的会多一些，但是呢，我们不分成说有前端团队，有后端团队，团队，你就是为 Experience 负责，如果 Backend 里面有哪些影响了最后前端的效果。
那你就直接去改，不需要再去找到 Backend 团队，再找到 Research 团队，或者再找到运维团队去改这个事，你自己就去改，呃，没有任何问题。
那你就直接去改，不需要再去找到 Backend 团队，再找到 Research 团队，或者再找到运维团队去改这个事，你自己就去改，呃，没有任何问题。
这个按结果分工，实际上不但是工程团队，我们的工程师甚至会去参与产品，包括设计，包括沟通 market 因为我就举一个例子，作为 business 的一个创业者来说，其实就是这些我们餐饮行业每一个老板的最终的体验。
这个按结果分工，实际上不但是工程团队，我们的工程师甚至会去参与产品，包括设计，包括沟通 market 因为我就举一个例子，作为 business 的一个创业者来说，其实就是这些我们餐饮行业每一个老板的最终的体验。
那我非常鼓励我们的工程师直接去找老板面谈这个东西用的好不好，有什么需求。
那我非常鼓励我们的工程师直接去找老板面谈这个东西用的好不好，有什么需求。
但这个反馈流程呢，如果搁在传统的团队，那就得这个老板可能找到销售，销售再把这个情况反馈给 PM 是吧？
但这个反馈流程呢，如果搁在传统的团队，那就得这个老板可能找到销售，销售再把这个情况反馈给 PM 是吧？
PM 可能再把这个情况反馈给工程团队，工程团队再说这个做不了，可能就是整个这个链条下来。
PM 可能再把这个情况反馈给工程团队，工程团队再说这个做不了，可能就是整个这个链条下来。
已经完全走样了，但是我们现在就鼓励公关团队直接去见客户，呃，他们也会直接收到一手的反馈，对，这是第一点。
已经完全走样了，但是我们现在就鼓励公关团队直接去见客户，呃，他们也会直接收到一手的反馈，对，这是第一点。
那第二一点呢，就是我们整个团队基本上是以工程团队为中间的一个核心，因为工程团队是最容易为结果负责的。
那第二一点呢，就是我们整个团队基本上是以工程团队为中间的一个核心，因为工程团队是最容易为结果负责的。
那工程团队呢，目标只完成前60%，最多到80%的工作。
那工程团队呢，目标只完成前60%，最多到80%的工作。
这些工作包括研发工作，也包括产品和设计的工作。
这些工作包括研发工作，也包括产品和设计的工作。
比如说我们现在就要上线一个功能，工程团队第一时间不会去找设计师，不会去找 PM，而是直接就用各种各样的设计工具，先把这个60分的东西做出来。
比如说我们现在就要上线一个功能，工程团队第一时间不会去找设计师，不会去找 PM，而是直接就用各种各样的设计工具，先把这个60分的东西做出来。
先上线再说，叫做 Velocity first，速度优先。
先上线再说，叫做 Velocity first，速度优先。
那其他团队，比如说我们也有专业的设计师，是在这个60分的基础上做优化，把它做到80分、90分甚至100分。
那其他团队，比如说我们也有专业的设计师，是在这个60分的基础上做优化，把它做到80分、90分甚至100分。
这么做的好处就是因为在过去我们可能会开很多会，所有人一起来拉通对齐，然后呢拿到一个特别完善的设计，然后再开始工作。
这么做的好处就是因为在过去我们可能会开很多会，所有人一起来拉通对齐，然后呢拿到一个特别完善的设计，然后再开始工作。
这件事在过去是成立的，因为过去来说，不管是 coding 也好，研发也好，这个成本比较高，我们不可能说先做一版，觉得不行，哎，再做一版。
这件事在过去是成立的，因为过去来说，不管是 coding 也好，研发也好，这个成本比较高，我们不可能说先做一版，觉得不行，哎，再做一版。
那这个工程团队肯定就非常抓狂了。
那这个工程团队肯定就非常抓狂了。
之前科技行业流行一句话叫做，Talk is cheap，show me the code。
之前科技行业流行一句话叫做，Talk is cheap，show me the code。
你要展示代码，但是现在的话，Talk is cheap，但是 code 其实是 cheaper，现在生成 code 已经是非常容易的事了。
你要展示代码，但是现在的话，Talk is cheap，但是 code 其实是 cheaper，现在生成 code 已经是非常容易的事了。
所以我们完全可以先做一个60分的东西，然后大家在这个60分的技术上面做一些，Alain 也好呀，做一些对接也好，再在这个技术上去优化。
所以我们完全可以先做一个60分的东西，然后大家在这个60分的技术上面做一些，Alain 也好呀，做一些对接也好，再在这个技术上去优化。
那基本上我们工程团队这件事也是做的非常好，这也是我们为什么能在短短一年的时间，把一个非常复杂的系统做起来。
那基本上我们工程团队这件事也是做的非常好，这也是我们为什么能在短短一年的时间，把一个非常复杂的系统做起来。
这是第二一点，第三一点呢，就更虚一点了，这个是我们公司也正在尝试吧，也是有一个朋友，他在知乎上也挺活跃的，前一段分享一篇文章就说未来的组织可能会变成很少量的合伙人，和大量的合同工。
这是第二一点，第三一点呢，就更虚一点了，这个是我们公司也正在尝试吧，也是有一个朋友，他在知乎上也挺活跃的，前一段分享一篇文章就说未来的组织可能会变成很少量的合伙人，和大量的合同工。
原因就是说，因为你也看到刚才说每个人都是按结果分工，为结果负责。
原因就是说，因为你也看到刚才说每个人都是按结果分工，为结果负责。
那每个人的价值其实是非常高，整个公司对他的依赖其实也是非常强的。
那每个人的价值其实是非常高，整个公司对他的依赖其实也是非常强的。
那有一个风险就是，如果这个人离职了，或者说如果这个人想要做自己的公司了，那对公司的影响其实是会挺大的。
那有一个风险就是，如果这个人离职了，或者说如果这个人想要做自己的公司了，那对公司的影响其实是会挺大的。
但是在原来的，比如在 Google、Meta 这种传统的互联网公司，管理团队的时候，有一个特别重要的一点，就是每一个位置上都一定要有 Back up。
但是在原来的，比如在 Google、Meta 这种传统的互联网公司，管理团队的时候，有一个特别重要的一点，就是每一个位置上都一定要有 Back up。
但是在新的 AI 技术团队，可能这件事已经很困难了。
但是在新的 AI 技术团队，可能这件事已经很困难了。
所以未来的激励方式可能也需要变化，那就是说这些全职的、核心的人，一定要有这种类似合伙人的待遇，这个待遇要高于普通的全职员工。
所以未来的激励方式可能也需要变化，那就是说这些全职的、核心的人，一定要有这种类似合伙人的待遇，这个待遇要高于普通的全职员工。
但是呢，你肯定不可能整个团队就只靠这些合伙人了，因为这个成本是会比较高的。
但是呢，你肯定不可能整个团队就只靠这些合伙人了，因为这个成本是会比较高的。
但是同时就会需要一些比较灵活的合同工，这些合同工呢，他会在某一个行业或者说某一个领域非常的有经验。
但是同时就会需要一些比较灵活的合同工，这些合同工呢，他会在某一个行业或者说某一个领域非常的有经验。
那对他自己来说，他也不愿意把自己的能力完全 full time 的卖给其中一个组织，他把自己的能力卖给多个组织，其实对他也是一个更好的方式。
那对他自己来说，他也不愿意把自己的能力完全 full time 的卖给其中一个组织，他把自己的能力卖给多个组织，其实对他也是一个更好的方式。
这一点呢我们也是在探索吧，可以稍微跟大家分享一下，一起听一听大家的想法。
这一点呢我们也是在探索吧，可以稍微跟大家分享一下，一起听一听大家的想法。
那差不多，这个分享就到这。
那差不多，这个分享就到这。
听起来非常有意思啊，我觉得比我想的还要易懂一点，就是非技术的人也完全能听得懂。
听起来非常有意思啊，我觉得比我想的还要易懂一点，就是非技术的人也完全能听得懂。
然后你还是我先快速问几个问题，然后把时间交给大家。
然后你还是我先快速问几个问题，然后把时间交给大家。
我第一个问题就是我好奇的点，那 PM 在你们内部到底是一个什么角色？
我第一个问题就是我好奇的点，那 PM 在你们内部到底是一个什么角色？
他现在是在怎么工作呢？
他现在是在怎么工作呢？
简单说就是我们没有全职的 PM，基本上就是 Engineer 兼职做 PM。
简单说就是我们没有全职的 PM，基本上就是 Engineer 兼职做 PM。
我们现在团队差不多20多个人啊，我其实不太知道，比如我们团队可能涨到50个人，甚至到100个人来说，需不需要全职 PM。
我们现在团队差不多20多个人啊，我其实不太知道，比如我们团队可能涨到50个人，甚至到100个人来说，需不需要全职 PM。
但是我们自己跑下来，至少在这个小的规模的时候还是并没有特别需要一个全职的 PM。
但是我们自己跑下来，至少在这个小的规模的时候还是并没有特别需要一个全职的 PM。
对，我感觉湾区那边其实都是在几十个人之后可能才会进来全职的 PM，对吧？
对，我感觉湾区那边其实都是在几十个人之后可能才会进来全职的 PM，对吧？
你看，Karyd AI 也是很后面才招的 PM，然后 Kurser 我知道也是很后面其实才有的 PM 或者说那边还有个职位是类似于产品设计师的角色，对吧？
你看，Karyd AI 也是很后面才招的 PM，然后 Kurser 我知道也是很后面其实才有的 PM 或者说那边还有个职位是类似于产品设计师的角色，对吧？
就是他可能有的时候就先招一个产品设计师，然后他兼任一些 PM 的工作。
就是他可能有的时候就先招一个产品设计师，然后他兼任一些 PM 的工作。
是的，或者这么说，其实作为创业公司来说，CEO 或者说像 Head of Engineer 其实很重要的就直接做 PM 的工作了，也是为了在这个决策流程要少一环吧，就是从客户直接到 Engineer。
是的，或者这么说，其实作为创业公司来说，CEO 或者说像 Head of Engineer 其实很重要的就直接做 PM 的工作了，也是为了在这个决策流程要少一环吧，就是从客户直接到 Engineer。
比中间加一层 PM，这个效率会高一些。
比中间加一层 PM，这个效率会高一些。
对，但你看，就是按照传统定义里面，Engineer 应该是特别擅长写代码，然后呢， n 机器一般大家印象都是比较内向，不善于与人沟通。
对，但你看，就是按照传统定义里面，Engineer 应该是特别擅长写代码，然后呢， n 机器一般大家印象都是比较内向，不善于与人沟通。
但 PM 呢，应该是说他要非常了解用户需求，非常善于沟通，以及提炼总结那些要点。
但 PM 呢，应该是说他要非常了解用户需求，非常善于沟通，以及提炼总结那些要点。
那如果你把这些职责放在了 engineer 上，是不是对 engineer 的要求就变得特别高？
那如果你把这些职责放在了 engineer 上，是不是对 engineer 的要求就变得特别高？
那这样的 engineer 多不多？
那这样的 engineer 多不多？
好不好招呢？
好不好招呢？
明白，第一，这样的 engineer 肯定不太好招，特别是不光是要有产品能力，现在对 AI 能够快速学习，纯能够把 AI 这套工具用好的 engineer 也不多，但问题是，这个可能在未来是必须的了。
明白，第一，这样的 engineer 肯定不太好招，特别是不光是要有产品能力，现在对 AI 能够快速学习，纯能够把 AI 这套工具用好的 engineer 也不多，但问题是，这个可能在未来是必须的了。
就我们现在的 AI software engineer 这个岗位，并不是说只有 engineer 能做。
就我们现在的 AI software engineer 这个岗位，并不是说只有 engineer 能做。
其实我也认识一些朋友，他原来是 PM 可能没有学过 coding 但是呢现在用各种 AI coding 的 tool 非常厉害，就可以 build 出来自己的一个产品。
其实我也认识一些朋友，他原来是 PM 可能没有学过 coding 但是呢现在用各种 AI coding 的 tool 非常厉害，就可以 build 出来自己的一个产品。
就是我们最终的目的并不是说一定要区分他到底是 PM 还是 Engineer，只要他能为自己最后 build 的这个东西，对这个结果负责，其实都是可以。
就是我们最终的目的并不是说一定要区分他到底是 PM 还是 Engineer，只要他能为自己最后 build 的这个东西，对这个结果负责，其实都是可以。
对，我刚才就在想说，因为你自己是技术背景，所以呢你们很自然的以 engineer 作为主体来做这件事情。
对，我刚才就在想说，因为你自己是技术背景，所以呢你们很自然的以 engineer 作为主体来做这件事情。
会不会未来，比如说 AI coding 更发达了，然后有公司反而过来讲说我们没有 engineer 我们所有人都是 PM。
会不会未来，比如说 AI coding 更发达了，然后有公司反而过来讲说我们没有 engineer 我们所有人都是 PM。
没错没错，或者以后可能不相信这，大家就都是 builder 对，但这里又延伸出来一个问题，你看分工其实是工业社会的一个产物嘛，就理论上来说，分工越细说明这个链条配合的越好，效率越高。
没错没错，或者以后可能不相信这，大家就都是 builder 对，但这里又延伸出来一个问题，你看分工其实是工业社会的一个产物嘛，就理论上来说，分工越细说明这个链条配合的越好，效率越高。
那当下呢，是因为 AI 出来，所以在一个比较早期的阶段，那可能重构了整个的组织跟产业链。
那当下呢，是因为 AI 出来，所以在一个比较早期的阶段，那可能重构了整个的组织跟产业链。
但你觉得未来会不会又变成，又开始分工，又有不同的分工体系，又变得更细？
但你觉得未来会不会又变成，又开始分工，又有不同的分工体系，又变得更细？
还是说就是你觉得现在这个模式是最高效最 work 的。
还是说就是你觉得现在这个模式是最高效最 work 的。
我肯定不敢说现在这个模式最高效的，但是我觉得肯定会和之前不一样。
我肯定不敢说现在这个模式最高效的，但是我觉得肯定会和之前不一样。
未来可能会有分工，但不会像之前这种工业时代或者说互联网时代的分工了。
未来可能会有分工，但不会像之前这种工业时代或者说互联网时代的分工了。
原因也很简单，之前的话还是按流程的分工，就是我们在这个流程中，每一个环节派不同的人，对吧，不同的角色把这个事情做好。
原因也很简单，之前的话还是按流程的分工，就是我们在这个流程中，每一个环节派不同的人，对吧，不同的角色把这个事情做好。
那 AI native 我觉得最重要的一个思维的转变就是整个这个流程应该是以 AI 为主的。
那 AI native 我觉得最重要的一个思维的转变就是整个这个流程应该是以 AI 为主的。
不是以人为主的，AI 可能最后能做95% 98%的事，人只是在那些最后这个 AI 实在做不了的地方，做一些补充。
不是以人为主的，AI 可能最后能做95% 98%的事，人只是在那些最后这个 AI 实在做不了的地方，做一些补充。
那这种分工到底是什么岗位呢？
那这种分工到底是什么岗位呢？
其实确实不太好讲，但是我觉得会跟之前是不一样的，这个是比较确定。
其实确实不太好讲，但是我觉得会跟之前是不一样的，这个是比较确定。
明白，然后我我还有两个问题啊，第一个问题是说你们现在实际上，用你现在这个模式跟组织架构，你们的一天到底是怎么样？
明白，然后我我还有两个问题啊，第一个问题是说你们现在实际上，用你现在这个模式跟组织架构，你们的一天到底是怎么样？
能不能给大家大概讲一下？
能不能给大家大概讲一下？
我们首先把会议只集中在中间的3~4个小时，其他时间我们都尽量没有任何会议，所有人自己做自己的事情。
我们首先把会议只集中在中间的3~4个小时，其他时间我们都尽量没有任何会议，所有人自己做自己的事情。
你像我刚才讲的 code review 的事哈，我们基本上每个人每天可能都有三四个甚至四五个这种 pull request。
你像我刚才讲的 code review 的事哈，我们基本上每个人每天可能都有三四个甚至四五个这种 pull request。
因为整个过程中，他完全自己写 code 然后让 AI review AI review 完了之后自己 merge 所以这个效率非常非常快。
因为整个过程中，他完全自己写 code 然后让 AI review AI review 完了之后自己 merge 所以这个效率非常非常快。
所以说这个一天可能每个人看起来跟平时工作只是会少了一些，扣定的工作多了一些。
所以说这个一天可能每个人看起来跟平时工作只是会少了一些，扣定的工作多了一些。
但是呢，实际的这个效率还是差别挺大的。
但是呢，实际的这个效率还是差别挺大的。
明白，然后我最后一个问题啊，就是在你看来，你刚才讲这套东西在弯曲它已经是一个很明确的趋势。
明白，然后我最后一个问题啊，就是在你看来，你刚才讲这套东西在弯曲它已经是一个很明确的趋势。
甚至于说很多已经在这么做了，还是你们哪怕在湾区也是比较先锋的，是在探索的一个角色。
甚至于说很多已经在这么做了，还是你们哪怕在湾区也是比较先锋的，是在探索的一个角色。
我们算是比较先锋，但是不能算小众，肯定还不是最 aggressive 的，但是我觉得在 startup 里面可能不是完全一样的模式，但是大家这个思路还是都是往这个方向去的。
我们算是比较先锋，但是不能算小众，肯定还不是最 aggressive 的，但是我觉得在 startup 里面可能不是完全一样的模式，但是大家这个思路还是都是往这个方向去的。
好，哎，愉快还在吗？
好，哎，愉快还在吗？
我在 call back 一下，愉快有什么，在我在，对对对，你听起来感觉怎么样？
我在 call back 一下，愉快有什么，在我在，对对对，你听起来感觉怎么样？
然后你们内部现在是怎么做这件事情呢？
然后你们内部现在是怎么做这件事情呢？
我觉得跟我们挺像，我们其实到目前为止，公司也已经大概150个人了，可能有两个 PM 吧。
我觉得跟我们挺像，我们其实到目前为止，公司也已经大概150个人了，可能有两个 PM 吧。
公司在最早期其实就是没有 PM 的，那会我觉得很正常。
公司在最早期其实就是没有 PM 的，那会我觉得很正常。
因为我的感觉是这样，有的时候你不是说 engineer 没有办法 make 这些决定啊，就是你越是跟他说，哎，有一个 PM 很多明明应该他自己可以下的决定，他就把这个难的问题交给别人了。
因为我的感觉是这样，有的时候你不是说 engineer 没有办法 make 这些决定啊，就是你越是跟他说，哎，有一个 PM 很多明明应该他自己可以下的决定，他就把这个难的问题交给别人了。
我觉得这个是非常不好的，这个 ownership 就没有了。
我觉得这个是非常不好的，这个 ownership 就没有了。
经常别人遇到后面他就说，OK，这个是一个 business decision，那我就不 make 了，这个是 PM 的。
经常别人遇到后面他就说，OK，这个是一个 business decision，那我就不 make 了，这个是 PM 的。
好，那 PM 要 make 这个 decision，其实他又要来找这个 engineer 对吧，说 OK，那你这些 data 现在有没有，对吧？
好，那 PM 要 make 这个 decision，其实他又要来找这个 engineer 对吧，说 OK，那你这些 data 现在有没有，对吧？
就说那又增加了很多的沟通。
就说那又增加了很多的沟通。
最后其实这个 decision 呢，也很多时候就是 engineer 和 PM 一起 make 的，我不觉得在早期需要这么多 back and 我的感觉就是，你让一一个很聪明的，解决问题能力很强的一个人去做决定，他是可以做出很好的决定的。
最后其实这个 decision 呢，也很多时候就是 engineer 和 PM 一起 make 的，我不觉得在早期需要这么多 back and 我的感觉就是，你让一一个很聪明的，解决问题能力很强的一个人去做决定，他是可以做出很好的决定的。
没有道理说他只能 make 好的 engineering decision，但不能够 make 好的 business decision。
没有道理说他只能 make 好的 engineering decision，但不能够 make 好的 business decision。
OK 好，谢谢。
OK 好，谢谢。
对，我觉得我们今天在听的人可能见证了一个新的时代的组织形式的变革跟产生的过程吧。
对，我觉得我们今天在听的人可能见证了一个新的时代的组织形式的变革跟产生的过程吧。
哈哈哈。
哈哈哈。
对，然后把时间交给大家，看看大家有什么问题，我要问宇川。
对，然后把时间交给大家，看看大家有什么问题，我要问宇川。
哎，我可以先问个问题吗？
哎，我可以先问个问题吗？
哎，嗯，我之前都是在一些大厂上班的，我觉得您刚刚说的这种方式，在十几个人、二十几个人是完全没有问题的，或者说这种规模的公司就得这么搞，他没有那么多人。
哎，嗯，我之前都是在一些大厂上班的，我觉得您刚刚说的这种方式，在十几个人、二十几个人是完全没有问题的，或者说这种规模的公司就得这么搞，他没有那么多人。
但是比如说之前在抖音，一个组，一个小业务，其实很多人。
但是比如说之前在抖音，一个组，一个小业务，其实很多人。
那为什么大公司不效仿这种东西？
那为什么大公司不效仿这种东西？
他们自己内部有很多的编程工具，但为什么所有东西还是按照一条线，从用户调研，到产品设计需求，到研发，到测试，整个一条线来做？
他们自己内部有很多的编程工具，但为什么所有东西还是按照一条线，从用户调研，到产品设计需求，到研发，到测试，整个一条线来做？
有没有想过，比如说你们这种方案只能在初创阶段的时候能做，在很大的规模情况下，其实很难行得通。
有没有想过，比如说你们这种方案只能在初创阶段的时候能做，在很大的规模情况下，其实很难行得通。
嗯，明白。
嗯，明白。
我就只说一些我的想法啊，因为我们其实也就是试了一年多，未来大厂会什么样，其实也都很难预测。
我就只说一些我的想法啊，因为我们其实也就是试了一年多，未来大厂会什么样，其实也都很难预测。
你可能说大厂规模大了之后这套要是不 work 了，完全有可能。
你可能说大厂规模大了之后这套要是不 work 了，完全有可能。
我肯定是对未来这个预测没有那么确定的。
我肯定是对未来这个预测没有那么确定的。
但是我自己的想法啊，为什么大厂不做这个事呢？
但是我自己的想法啊，为什么大厂不做这个事呢？
我自己也在 Google 工作过一段时间，这个对大厂来讲，他这个转型有非常多，技术也好，或者说效率之外的考量。
我自己也在 Google 工作过一段时间，这个对大厂来讲，他这个转型有非常多，技术也好，或者说效率之外的考量。
今天微软的 CEO 已经出来道歉了，觉得他们之前裁人裁的太猛了，然后需要重拾员工的信心，对吧？
今天微软的 CEO 已经出来道歉了，觉得他们之前裁人裁的太猛了，然后需要重拾员工的信心，对吧？
就这些事呢。
就这些事呢。
跟 engineer 或者工程研发没有什么关系，他可能因为某一些的原因，他没有办法做到呃像这种效率这么高。
跟 engineer 或者工程研发没有什么关系，他可能因为某一些的原因，他没有办法做到呃像这种效率这么高。
那在 Google 呢，据我所知，有一些它内部的小的团队，实际上也是类似的这种做法。
那在 Google 呢，据我所知，有一些它内部的小的团队，实际上也是类似的这种做法。
但是如果大到 Google 整体上来讲，它如果做这种转型还是非常非常困难的。
但是如果大到 Google 整体上来讲，它如果做这种转型还是非常非常困难的。
这是第一点哈，第二一点就是我自己感觉，未来可能再也不需要那么大的公司了。
这是第一点哈，第二一点就是我自己感觉，未来可能再也不需要那么大的公司了。
大家看现在，不管是之前明星公司，Corsair，或者现在的各种创业公司，甚至都在讨论有没有这种一人独角兽公司。
大家看现在，不管是之前明星公司，Corsair，或者现在的各种创业公司，甚至都在讨论有没有这种一人独角兽公司。
就是说一个人、几个人的团队能做的事情，已经非常难以置信了。
就是说一个人、几个人的团队能做的事情，已经非常难以置信了。
所以未来会不会还需要像 Google 有10万人的公司？
所以未来会不会还需要像 Google 有10万人的公司？
来做这么一个产品，实际上我是比较怀疑的，我我自己的一点判断吧。
来做这么一个产品，实际上我是比较怀疑的，我我自己的一点判断吧。
对，我觉得这个问题很有意思，就是我们最近聊了很多创业公司，然后我觉得里面是少数的在思考新的时代的组织形式。
对，我觉得这个问题很有意思，就是我们最近聊了很多创业公司，然后我觉得里面是少数的在思考新的时代的组织形式。
然后我们现在的体感是，也许在中短期内，创业公司真的壁垒就是在组织形式上。
然后我们现在的体感是，也许在中短期内，创业公司真的壁垒就是在组织形式上。
就大公司你要让它转是很难的，就它里面要做非常多的动作，裁很多人，再再重新 reorg 这个组织。
就大公司你要让它转是很难的，就它里面要做非常多的动作，裁很多人，再再重新 reorg 这个组织。
但创业公司可能就是能抓到这点的机会，然后把做 evaluation 的人提上来，让他做更多的负责的东西，以及就是刚才讲的每个人都是 builder 能更多的到到端去负责一些事情吧。
但创业公司可能就是能抓到这点的机会，然后把做 evaluation 的人提上来，让他做更多的负责的东西，以及就是刚才讲的每个人都是 builder 能更多的到到端去负责一些事情吧。
好，然后下个问题。
好，然后下个问题。
好，我第二个问题啊，就是说对研发而言，整个代码其实迭代可能大几年，有的都有10年了。
好，我第二个问题啊，就是说对研发而言，整个代码其实迭代可能大几年，有的都有10年了。
你用 AI 去做这块的可行性到底有多大？
你用 AI 去做这块的可行性到底有多大？
就比如说有些代码很复杂逻辑，各种，比如说端上旋转重力。
就比如说有些代码很复杂逻辑，各种，比如说端上旋转重力。
跟设备系统很相关的东西，连我自己看了几年这个代码，我自己都理不清楚了，怎么让 AI 来帮我写这块需求？
跟设备系统很相关的东西，连我自己看了几年这个代码，我自己都理不清楚了，怎么让 AI 来帮我写这块需求？
我的这个问题其实还是感觉 AI 扣点这块更适用于我所有东西，我都从0~1的。
我的这个问题其实还是感觉 AI 扣点这块更适用于我所有东西，我都从0~1的。
但你别说从1到100，从10到100，我自己都理不明白东西，我觉得他更理不明白。
但你别说从1到100，从10到100，我自己都理不明白东西，我觉得他更理不明白。
嗯，这个问题特别好，跟我刚才讲的一点是比较相关的。
嗯，这个问题特别好，跟我刚才讲的一点是比较相关的。
这时候就特别需要 AI 工程师或者需要人的参与了。
这时候就特别需要 AI 工程师或者需要人的参与了。
但人最重要的价值就叫做 Context provider，就像你刚才说的，过去多少年的经验，我相信任何一个大模型现在都没有这些知识，也很难让它学会。
但人最重要的价值就叫做 Context provider，就像你刚才说的，过去多少年的经验，我相信任何一个大模型现在都没有这些知识，也很难让它学会。
那这时候就需要人来为它提供这个 context。
那这时候就需要人来为它提供这个 context。
那你提供的 context 的准确程度，你提供的 context 这个信噪比，都会直接影响 AI coding 也好，AI agent 也好，它最终的效果。
那你提供的 context 的准确程度，你提供的 context 这个信噪比，都会直接影响 AI coding 也好，AI agent 也好，它最终的效果。
那这件事不是模型的能力达不到，而是我们给 AI 或者给模型提供的 Context 不够好。
那这件事不是模型的能力达不到，而是我们给 AI 或者给模型提供的 Context 不够好。
但我觉得一方面呢，我们可以等模型变得更强，就是说你的 Context 不够好，也能 work。
但我觉得一方面呢，我们可以等模型变得更强，就是说你的 Context 不够好，也能 work。
但是这个的成本会很高了，到时候 GPT 6啊什么，这个出的就越来越慢了。
但是这个的成本会很高了，到时候 GPT 6啊什么，这个出的就越来越慢了。
呃，那另一方面呢，现在也有很多公司在研究我们怎么能把这个 context 提供的更好，同时我觉得作为我们个人，我们也可以想一想怎么样能给 AI 提供更好的 context 这个会变成未来这个 AI 工程师一个特别核心的价值和技能。
呃，那另一方面呢，现在也有很多公司在研究我们怎么能把这个 context 提供的更好，同时我觉得作为我们个人，我们也可以想一想怎么样能给 AI 提供更好的 context 这个会变成未来这个 AI 工程师一个特别核心的价值和技能。
嗯，好，明白。
嗯，好，明白。
那就是你 PPT 上面写的就是，人家 AI 大于 AI 对吧？
那就是你 PPT 上面写的就是，人家 AI 大于 AI 对吧？
对，就是这个意思。
对，就是这个意思。
好，谢谢。
好，谢谢。
好，下一个问题。
好，下一个问题。
我想问问，除了 coding 以外，您觉得 AI 在哪些你们工作中是比较好使的一些场景？
我想问问，除了 coding 以外，您觉得 AI 在哪些你们工作中是比较好使的一些场景？
其实刚才说到这，就是说对研发团队来说，每一个步骤其实 AI 都会有非常大的帮助。
其实刚才说到这，就是说对研发团队来说，每一个步骤其实 AI 都会有非常大的帮助。
第二一个的话，我们现在发现，也是我最近看的比较多的，就是 go to market。
第二一个的话，我们现在发现，也是我最近看的比较多的，就是 go to market。
过去整个销售流程也跟研发流程似的，非常长。
过去整个销售流程也跟研发流程似的，非常长。
从最开始的 SDR 到最后 account manager 到最后 customer success 就中间整个流程，一个客户可能要接触四五个人。
从最开始的 SDR 到最后 account manager 到最后 customer success 就中间整个流程，一个客户可能要接触四五个人。
但现在有了 AI 之后，这个流程也被大大的压缩，可能一个人就直接从 end to end 的都可以解决了。
但现在有了 AI 之后，这个流程也被大大的压缩，可能一个人就直接从 end to end 的都可以解决了。
现在特别多的硅谷这边的公司就是在做 auto market 方面的自动化。
现在特别多的硅谷这边的公司就是在做 auto market 方面的自动化。
你也可以研究研究，我觉得这个地方也是大有可为的。
你也可以研究研究，我觉得这个地方也是大有可为的。
好，下一个问题。
好，下一个问题。
我想请问一下，您在打造这样的一个 AI native 团队的时候呢，是不是有从传统团队里面转过来，还是说从一开始就是用这种工作模式去打造这团队？
我想请问一下，您在打造这样的一个 AI native 团队的时候呢，是不是有从传统团队里面转过来，还是说从一开始就是用这种工作模式去打造这团队？
以及说你在打造的过程中有遇到什么困难？
以及说你在打造的过程中有遇到什么困难？
怎么去解决？
怎么去解决？
这个我们比较幸运的一点就是我们公司比较新，我没有这些。
这个我们比较幸运的一点就是我们公司比较新，我没有这些。
历史包袱，所以我们从去年4月份创立，到差不多六七月份开始做这套东西，都是以一种全新的 AI native 的方式来做的。
历史包袱，所以我们从去年4月份创立，到差不多六七月份开始做这套东西，都是以一种全新的 AI native 的方式来做的。
当时也有一个比较现实的问题了，就是说这个人不够，你人不够的话肯定要想办法，再然后有很多人确实是不适应的，特别是有些 senior 他比如说在 Google 做了七八年了，这套都已经做得非常熟了。
当时也有一个比较现实的问题了，就是说这个人不够，你人不够的话肯定要想办法，再然后有很多人确实是不适应的，特别是有些 senior 他比如说在 Google 做了七八年了，这套都已经做得非常熟了。
他可能用 Vim 已经是个专家了，用 Emacs 都是专家了，他连 Cursor 都不愿意用，这是我们也能见到过这种情况，所以我自己的感觉，经验在这个时代不是很重要，而且很多时候这个经验会变成负担。
他可能用 Vim 已经是个专家了，用 Emacs 都是专家了，他连 Cursor 都不愿意用，这是我们也能见到过这种情况，所以我自己的感觉，经验在这个时代不是很重要，而且很多时候这个经验会变成负担。
当然我们的这个数据量比较少啊，我们其实发现最适应这个时代的还是一些比较年轻的刚毕业的人。
当然我们的这个数据量比较少啊，我们其实发现最适应这个时代的还是一些比较年轻的刚毕业的人。
同时他们有特别强的这个学习能力和欲望，就是他们可能在读书的过程中就已经离不开 ChatGPT 了，已经离不开 AI 了。
同时他们有特别强的这个学习能力和欲望，就是他们可能在读书的过程中就已经离不开 ChatGPT 了，已经离不开 AI 了。
所以他出来拿这个工作非常的自然。
所以他出来拿这个工作非常的自然。
这样的人确实不好招，但是我觉得还是会越来越多，大家把这种方式转变过来之后。
这样的人确实不好招，但是我觉得还是会越来越多，大家把这种方式转变过来之后。
好，下一个问题。
好，下一个问题。
我想问就是，在找人的时候，你是怎么去找到这样比较会使用 AI 的人？
我想问就是，在找人的时候，你是怎么去找到这样比较会使用 AI 的人？
我们有两个方式，第一个方式就是我们不做这种一个小时面对面这种面试，我们直接给一个问题，take home，你回家做。
我们有两个方式，第一个方式就是我们不做这种一个小时面对面这种面试，我们直接给一个问题，take home，你回家做。
这个问题或者这个项目很大，你没有 AI 肯定是做不完的。
这个问题或者这个项目很大，你没有 AI 肯定是做不完的。
就给你比如两天的时间，你要给我 build 一个什么 product，build 完之后呢，回来我们就半个小时聊一下，你告诉我你大概是怎么做的？
就给你比如两天的时间，你要给我 build 一个什么 product，build 完之后呢，回来我们就半个小时聊一下，你告诉我你大概是怎么做的？
同时你能知道说，他确实是两天时间把这东西做出来了，他一定是 AI 工具用的好，否则的话，他如果是手写的，那更是大牛。
同时你能知道说，他确实是两天时间把这东西做出来了，他一定是 AI 工具用的好，否则的话，他如果是手写的，那更是大牛。
第二一个他也不能只是文的 AI 把东西做出来，里面内容完全不了解。
第二一个他也不能只是文的 AI 把东西做出来，里面内容完全不了解。
他要有一个过程，比如说我最开始用了什么办法，这块不太 work 哎我又怎么调整了一下这个 prompt 也好，我又怎么调整一下我的 instruction。
他要有一个过程，比如说我最开始用了什么办法，这块不太 work 哎我又怎么调整了一下这个 prompt 也好，我又怎么调整一下我的 instruction。
他弄的 walker 要问一下这些过程或者这些细节的地方。
他弄的 walker 要问一下这些过程或者这些细节的地方。
我们这么做下来还是效果比较好吧。
我们这么做下来还是效果比较好吧。
我们其实这种一个小时的面对面的面试，也在尝试一些新的办法，还没有特别的。
我们其实这种一个小时的面对面的面试，也在尝试一些新的办法，还没有特别的。
Ready 就是说这一个小时，我们把一个现成的，写好的一个大型的 project 给到你，但是这个 project 它里面有各种各样的问题，埋了很多的雷，因为它是一个新的 project 你只能靠 AI 去迅速理解。
Ready 就是说这一个小时，我们把一个现成的，写好的一个大型的 project 给到你，但是这个 project 它里面有各种各样的问题，埋了很多的雷，因为它是一个新的 project 你只能靠 AI 去迅速理解。
你要人看的话，你一个小时肯定啥也干不了。
你要人看的话，你一个小时肯定啥也干不了。
在这个时候，我们就希望说你用 AI 这个 tool 看能不能一个小时把这个 project 做改进。
在这个时候，我们就希望说你用 AI 这个 tool 看能不能一个小时把这个 project 做改进。
我们也在尝试这种方式。
我们也在尝试这种方式。
嗯。
嗯。
然后我看一块钢丝要补充是吧？
然后我看一块钢丝要补充是吧？
是有问题想要问 Kevin 就是我觉得 take home 的问题就是一个人的 background 如果很强，然后你跟他说这个 take home 你会 take 比如说8个小时、10个小时，你怎么让人家愿意来做你这个 take home 呢？
是有问题想要问 Kevin 就是我觉得 take home 的问题就是一个人的 background 如果很强，然后你跟他说这个 take home 你会 take 比如说8个小时、10个小时，你怎么让人家愿意来做你这个 take home 呢？
嗯，这个其实也是一个筛选的过程啊，我们基本上发下去之后可能有1/10会做的，确实会这样。
嗯，这个其实也是一个筛选的过程啊，我们基本上发下去之后可能有1/10会做的，确实会这样。
我理解，对于，你要让别人对你感兴趣，最后你可以笑嘛，就说他可能通过你面试过程什么觉得很有意思，他有可能最后会 join 的呀。
我理解，对于，你要让别人对你感兴趣，最后你可以笑嘛，就说他可能通过你面试过程什么觉得很有意思，他有可能最后会 join 的呀。
但一上来如果他面试过程都不开始。
但一上来如果他面试过程都不开始。
他会不会就被这个给吓跑？
他会不会就被这个给吓跑？
比如说你有没有遇到过情况，就看这个人背景很强，你觉得他是个 good fit，但是呢他不愿意做这个 take home，你会不会就 fast track，你认为 ok 那行吧，就你直接来我们公司面，你会这样子 make exception 吗？
比如说你有没有遇到过情况，就看这个人背景很强，你觉得他是个 good fit，但是呢他不愿意做这个 take home，你会不会就 fast track，你认为 ok 那行吧，就你直接来我们公司面，你会这样子 make exception 吗？
方太简历基本不可能，但是如果有 refer 的话，会考虑这种情况，但是呢说到底，这个最终是一个效率的问题。
方太简历基本不可能，但是如果有 refer 的话，会考虑这种情况，但是呢说到底，这个最终是一个效率的问题。
有没有可能没有做提供，就跑了，但是是一个特别好的会员，有可能。
有没有可能没有做提供，就跑了，但是是一个特别好的会员，有可能。
但是呢，我们肯定是看综合的效率，最终能不能招到这个合适的人。
但是呢，我们肯定是看综合的效率，最终能不能招到这个合适的人。
展开剩余字幕（还有 94 条）
嗯，这个问题我分享一下我的经验，就是我们日常在所有的这个岗位都是使用 take home 这样的招聘方式的。
嗯，这个问题我分享一下我的经验，就是我们日常在所有的这个岗位都是使用 take home 这样的招聘方式的。
但是我们在给人家 take home 这个任务之前，我们会先聊一下，我觉得这个人是否有比较高的这个可能性。
但是我们在给人家 take home 这个任务之前，我们会先聊一下，我觉得这个人是否有比较高的这个可能性。
如果说他有比较高的可能性的话，这个 take home 会给一个大概市场价格30%的这个报酬给到他。
如果说他有比较高的可能性的话，这个 take home 会给一个大概市场价格30%的这个报酬给到他。
就比如说，我们招一个产品经理，我们日常的这种用户调研，然后去设计产品方案，再到数据买点的这个设计，就是一整套全流程。
就比如说，我们招一个产品经理，我们日常的这种用户调研，然后去设计产品方案，再到数据买点的这个设计，就是一整套全流程。
都需要他去做完，但是可能正常情况下，他如果做完这一套可能要5000块钱，但是我们会告诉他，你把这个任务做完之后，我们给你1500块钱。
都需要他去做完，但是可能正常情况下，他如果做完这一套可能要5000块钱，但是我们会告诉他，你把这个任务做完之后，我们给你1500块钱。
这样的话，其实让候选人他不会觉得，哎你是为了白嫖我，我们也可以看到最后他这个 take home 的质量。
这样的话，其实让候选人他不会觉得，哎你是为了白嫖我，我们也可以看到最后他这个 take home 的质量。
Makes sense 感谢分享。
Makes sense 感谢分享。
OK，然后下个问题。
OK，然后下个问题。
就是想问一下，你们用 AI 做 code review 的时候，会用一些常见的可量化指标，比如说命中率啊、误报率，或者是一些这样的东西。
就是想问一下，你们用 AI 做 code review 的时候，会用一些常见的可量化指标，比如说命中率啊、误报率，或者是一些这样的东西。
那如果效果不好的话，你们怎么调整呢？
那如果效果不好的话，你们怎么调整呢？
第一，我们基本不用这种指标，因为一个是，这个也也挺难量化的现在。
第一，我们基本不用这种指标，因为一个是，这个也也挺难量化的现在。
第二一个，我们主要看我们工程师的。
第二一个，我们主要看我们工程师的。
主观感受，因为什么呢？
主观感受，因为什么呢？
这个 code review 说到底，当人给人 review 的时候，你感觉他是在挑刺。
这个 code review 说到底，当人给人 review 的时候，你感觉他是在挑刺。
但是我们用 AI 给人 review 之后。
但是我们用 AI 给人 review 之后。
有个特别神奇的效果，就是人会特别感谢这个 AI 帮他挑这个问题，因为最终这个代码进到 production 以后，如果出了问题，只有这个写代码人负责。
有个特别神奇的效果，就是人会特别感谢这个 AI 帮他挑这个问题，因为最终这个代码进到 production 以后，如果出了问题，只有这个写代码人负责。
所以说如果 AI 帮他把这个错误再提前改好的话，其实人会很开心的。
所以说如果 AI 帮他把这个错误再提前改好的话，其实人会很开心的。
所以说我们更多的是大家相互 share 觉得哪个 AI Review 的 tool 是最有用的，最能帮你提升你自己代码的质量。
所以说我们更多的是大家相互 share 觉得哪个 AI Review 的 tool 是最有用的，最能帮你提升你自己代码的质量。
其实还是挺明显的，就是我们用下来，像那个 VS Code 的 Copilot 都不太好，CursorBugBot 也不是特别好，有时候就会瞎说啊什么的。
其实还是挺明显的，就是我们用下来，像那个 VS Code 的 Copilot 都不太好，CursorBugBot 也不是特别好，有时候就会瞎说啊什么的。
所以我们倒不是用一个指标去衡量这个事的，看工程师的感受。
所以我们倒不是用一个指标去衡量这个事的，看工程师的感受。
好，下一个问题。
好，下一个问题。
我再追问一下，在你们 AI code 这过程中，你们会去 review 这个需求的逻辑吗？
我再追问一下，在你们 AI code 这过程中，你们会去 review 这个需求的逻辑吗？
还是只是评审一些，包括一些 bug 或者一些安全漏洞之类的，或者代码规范？
还是只是评审一些，包括一些 bug 或者一些安全漏洞之类的，或者代码规范？
需求的逻辑指的是什么？
需求的逻辑指的是什么？
就是产品需求的逻辑。
就是产品需求的逻辑。
就是你这个 code 里面有没有把我产品的需求完整实现啊？
就是你这个 code 里面有没有把我产品的需求完整实现啊？
或者这类的问题。
或者这类的问题。
哦，这个是这样，有两种情况，如果说你的后的是比较偏，比如说实现一个新的功能、新的 features，那可能会有。
哦，这个是这样，有两种情况，如果说你的后的是比较偏，比如说实现一个新的功能、新的 features，那可能会有。
比如说你新的一个 service，这个 service 具体是干什么的？
比如说你新的一个 service，这个 service 具体是干什么的？
它的输入是什么、输出是什么？
它的输入是什么、输出是什么？
它要满足一二三这几个功能。
它要满足一二三这几个功能。
那这个我们都会在我们 Python 这个 in it 文件里面把这个写好，这些东西也会给到模型，所以模型也会知道哦，你想实现这么一二三四的功能，那发现你的 code 并没有实现。
那这个我们都会在我们 Python 这个 in it 文件里面把这个写好，这些东西也会给到模型，所以模型也会知道哦，你想实现这么一二三四的功能，那发现你的 code 并没有实现。
那它就会提出来这些问题。
那它就会提出来这些问题。
但是如果说你这个 code 只是，比如说改 bug 或者说改其中某一个模块的一个小功能，它离最终的需求有点远，那模型可能就不会了。
但是如果说你这个 code 只是，比如说改 bug 或者说改其中某一个模块的一个小功能，它离最终的需求有点远，那模型可能就不会了。
说到底就是 context 如果说有这个需求的 context，那模型也是会考虑进来做 review 的。
说到底就是 context 如果说有这个需求的 context，那模型也是会考虑进来做 review 的。
明白。
明白。
呃，另外一个问题，就是你们一个 project 里面有多少是 AI 生成的？
呃，另外一个问题，就是你们一个 project 里面有多少是 AI 生成的？
然后怎么去统计 AI 生成的这个代码量？
然后怎么去统计 AI 生成的这个代码量？
我估计至少90%了，我们就是默认 AI 写代码，人在必要的时候再去改。
我估计至少90%了，我们就是默认 AI 写代码，人在必要的时候再去改。
好，下一个问题。
好，下一个问题。
我这边有一个问题想问一下，一个公司啊，从10个人、50个人和100个人，咱们具体是在下来都包含哪些角色？
我这边有一个问题想问一下，一个公司啊，从10个人、50个人和100个人，咱们具体是在下来都包含哪些角色？
将会怎么配合？
将会怎么配合？
然后不同的发展阶段又是应该是增加哪些角色？
然后不同的发展阶段又是应该是增加哪些角色？
我不敢说50人、100人怎么样，我也没有这个经验。
我不敢说50人、100人怎么样，我也没有这个经验。
我自己觉得这个分工就有一个原则，刚才这块也说了，按结果分工，按结果分工的意思呢，就是说我们每个人来也都是解决问题。
我自己觉得这个分工就有一个原则，刚才这块也说了，按结果分工，按结果分工的意思呢，就是说我们每个人来也都是解决问题。
最终我们人和人之间要烂的，就是说我们到底要解决的是什么问题？
最终我们人和人之间要烂的，就是说我们到底要解决的是什么问题？
或者说我们的目标是什么？
或者说我们的目标是什么？
只要把这个烂清楚，那咱们就分好，你解决这个，我解决那个。
只要把这个烂清楚，那咱们就分好，你解决这个，我解决那个。
具体怎么解决，这个过程，这个手段，不去分工，不去限制，让每个人自己去发挥。
具体怎么解决，这个过程，这个手段，不去分工，不去限制，让每个人自己去发挥。
当然了，要利用 AI 你说到100个人或者50人之后会产生什么岗位，这个我真不太好。
当然了，要利用 AI 你说到100个人或者50人之后会产生什么岗位，这个我真不太好。
预测，一会愉快说说你们现在150个人了，是什么岗位？
预测，一会愉快说说你们现在150个人了，是什么岗位？
我感觉我们公司渐渐变大了之后，开始多招一些这种 secured 的一些人，然后招一些 QA 的人、 testing 的人。
我感觉我们公司渐渐变大了之后，开始多招一些这种 secured 的一些人，然后招一些 QA 的人、 testing 的人。
然后之前的话，一上来大家都是每个人负责一个 feature 然后后面的话，渐渐的 OK，那我们这个 scalability 怎么，Developer Experience 怎么办？
然后之前的话，一上来大家都是每个人负责一个 feature 然后后面的话，渐渐的 OK，那我们这个 scalability 怎么，Developer Experience 怎么办？
所以接下来，Platform team 就开始出现了，Platform engineering 也开始变多了。
所以接下来，Platform team 就开始出现了，Platform engineering 也开始变多了。
这是我的感受。
这是我的感受。
好看，还有问题吗？
好看，还有问题吗？
哎，你好，我问一下。
哎，你好，我问一下。
听您讲第一 part 就是你们很信任 AI coding 的一个很大的因素，是因为它迭代足够快。
听您讲第一 part 就是你们很信任 AI coding 的一个很大的因素，是因为它迭代足够快。
比如说它 review 每次只要10分钟。
比如说它 review 每次只要10分钟。
我想问的是，就算我们认为它足够快，但10分钟之内仍然会可能产生一个 P0或 P1级别的事故。
我想问的是，就算我们认为它足够快，但10分钟之内仍然会可能产生一个 P0或 P1级别的事故。
就是对于这种，你们一开始时候会区分业务吗？
就是对于这种，你们一开始时候会区分业务吗？
比如说核心业务其实 AI coding 会比较少。
比如说核心业务其实 AI coding 会比较少。
然后第二个是假设这种级别更高的业务，在 AI coding 上怎么能避免这种事故的发生？
然后第二个是假设这种级别更高的业务，在 AI coding 上怎么能避免这种事故的发生？
然后第三就我想说，其实除了 fix bug 之外，某一次我们可能还会带来其他，比如说 Daybase 的一些脏数据，甚至一些用户补偿，这部分也是 AI 来做吗？
然后第三就我想说，其实除了 fix bug 之外，某一次我们可能还会带来其他，比如说 Daybase 的一些脏数据，甚至一些用户补偿，这部分也是 AI 来做吗？
还是说其实人为的干预会更多？
还是说其实人为的干预会更多？
刚才说的这个，第一部分第一点，并不是说我们无脑所有东西都用 AI 做，而是一个思路的转变。
刚才说的这个，第一部分第一点，并不是说我们无脑所有东西都用 AI 做，而是一个思路的转变。
我先假设 AI 可以做。
我先假设 AI 可以做。
那如果 AI 一做发现问题了，不行，我们肯定还是让人来做。
那如果 AI 一做发现问题了，不行，我们肯定还是让人来做。
这个区别在于可能现在我们是先 follow 传统的工作流，什么东西都让人来做，我发现某个地方 AI 能起效，我再让 AI 去做，这样会 miss 掉很多的机会。
这个区别在于可能现在我们是先 follow 传统的工作流，什么东西都让人来做，我发现某个地方 AI 能起效，我再让 AI 去做，这样会 miss 掉很多的机会。
这是一个 principle 的不同，而不是说我们真的什么都要用 AI 做。
这是一个 principle 的不同，而不是说我们真的什么都要用 AI 做。
第二一个就是你刚才说的，比如说 Infra 的东西，我们其实 AI 做的会少一些，但实际上比大多数公司也要多很多了。
第二一个就是你刚才说的，比如说 Infra 的东西，我们其实 AI 做的会少一些，但实际上比大多数公司也要多很多了。
比如说我们整个的 Infra 都是以 IAC 的形式存在 Repo 里的。
比如说我们整个的 Infra 都是以 IAC 的形式存在 Repo 里的。
所以 AI 也会生成对应的代码，但是呢我们可能就会，昂靠，会看的多一些。
所以 AI 也会生成对应的代码，但是呢我们可能就会，昂靠，会看的多一些。
但是产品方面，特别是前端的代码，那可能就看的少一些，就直接上上线了，发现问题再改都可以。
但是产品方面，特别是前端的代码，那可能就看的少一些，就直接上上线了，发现问题再改都可以。
但是 AI 已经进入我们这个工作流了，如果 AI 未来 work 的越来越好，那我们可能人就自然而然的，reveal 的越来越少了。
但是 AI 已经进入我们这个工作流了，如果 AI 未来 work 的越来越好，那我们可能人就自然而然的，reveal 的越来越少了。
好，我们要不最后一个吧。
好，我们要不最后一个吧。
哎，你好，这边有一个提问，就是在我们对 AI engineer 的招聘过程当中，其实我们会遇到一些问题，当我们想要去吸引一些 BG 好，然后综合能力出众的这些同学的时候，他们往往会更倾向于说。
哎，你好，这边有一个提问，就是在我们对 AI engineer 的招聘过程当中，其实我们会遇到一些问题，当我们想要去吸引一些 BG 好，然后综合能力出众的这些同学的时候，他们往往会更倾向于说。
哎我刚毕业凭什么来你这初创，对吧？
哎我刚毕业凭什么来你这初创，对吧？
我我要去大厂。
我我要去大厂。
然后遇到那些比较 senior 的 engineer 他们可能会不太适应新的 AI engineer 工程习惯。
然后遇到那些比较 senior 的 engineer 他们可能会不太适应新的 AI engineer 工程习惯。
在这样的情况下，比如说我们在招聘，或者说在人才培养上，我们需要去，一个是通过哪些渠道去找到这些合适的人选，另外一个是我们需要关心这些人的什么样的特质。
在这样的情况下，比如说我们在招聘，或者说在人才培养上，我们需要去，一个是通过哪些渠道去找到这些合适的人选，另外一个是我们需要关心这些人的什么样的特质。
如果说想要去做一些有差异化的激励，那我们应该怎么样做？
如果说想要去做一些有差异化的激励，那我们应该怎么样做？
这个也是我前面分享第三部分最后一点，像刚才说的，可能慢慢的就不能把人当全职员工了，而要当合伙人。
这个也是我前面分享第三部分最后一点，像刚才说的，可能慢慢的就不能把人当全职员工了，而要当合伙人。
这是一个吧，第二一个其实是我一个创业朋友的观察，就是说与其招人，不如提升自己。
这是一个吧，第二一个其实是我一个创业朋友的观察，就是说与其招人，不如提升自己。
就是，与其招这样的合伙人，不如先看看能不能你真的几个合伙人采用这种方式来提效，因为有可能你用好了这个 AI 工具之后，不需要多花更多的精力，可能就把要招的人那个工作给 cover 了，这是很有可能的。
就是，与其招这样的合伙人，不如先看看能不能你真的几个合伙人采用这种方式来提效，因为有可能你用好了这个 AI 工具之后，不需要多花更多的精力，可能就把要招的人那个工作给 cover 了，这是很有可能的。
我有一些朋友创业啊，可能刚开始就两三个人，有点忙不过来了，就招人，招来人发现见，比之前还忙，这都是有可能发生的。
我有一些朋友创业啊，可能刚开始就两三个人，有点忙不过来了，就招人，招来人发现见，比之前还忙，这都是有可能发生的。
所以我觉得可能招人之前想想能不能现有团队就把这个效率提升了，可能也是一个解决的思路。
所以我觉得可能招人之前想想能不能现有团队就把这个效率提升了，可能也是一个解决的思路。
我看有一块要补充吗？
我看有一块要补充吗？
我稍微补充一点，我自己招人的感觉是这样，其实越是强的人，你越是要给他很难的那个面试的流程。
我稍微补充一点，我自己招人的感觉是这样，其实越是强的人，你越是要给他很难的那个面试的流程。
我的感觉是强的人他对你有天生的这种好奇心，然后如果你给他一种感觉就是，哎，我好像你在求他让他加入的话，其实他不会加入你的。
我的感觉是强的人他对你有天生的这种好奇心，然后如果你给他一种感觉就是，哎，我好像你在求他让他加入的话，其实他不会加入你的。
你反过来，你的面试让他觉得，怎么这家公司我都没有听说过，为什么，就是很神奇，对吧？
你反过来，你的面试让他觉得，怎么这家公司我都没有听说过，为什么，就是很神奇，对吧？
怎么感觉面试也跟别人不一样，然后面试的题感觉也很难什么的。
怎么感觉面试也跟别人不一样，然后面试的题感觉也很难什么的。
其实你越是这样子，他越是会很有可能最后会加入，这个是我的感觉。
其实你越是这样子，他越是会很有可能最后会加入，这个是我的感觉。
好，那就感谢大家的时间，然后谢谢任川，拜拜，谢谢，拜拜。
好，那就感谢大家的时间，然后谢谢任川，拜拜，谢谢，拜拜。
关于 Bayt 播客
Bayt 提供中文+原文双语音频和字幕，帮助你打破语言障碍，轻松听懂全球优质播客。