E238｜聊聊Harness时代AI-First的组织架构：从信任人到信任AI

Harness：从提示到系统 [00:00:00 - 00:10:00]
AI-first的流程重构 [00:10:00 - 00:20:00]
自动化测试与Bug triage [00:20:00 - 00:30:00]
AI驱动的规划重构 [00:30:00 - 00:40:00]
市场未准备好 [00:40:00 - 00:50:00]
复合型人才与资深悖论 [00:50:00 - 01:00:00]
需求定义与结果Review [01:00:00 - 01:05:16]

Hello,大家好,欢迎收听硅谷101,我是红军

泓君：Hello,大家好,欢迎收听硅谷 101,我是红军。过去三年,我们经历了大模型工程能力的三次概念上的进化。大家还记得在 2023 年,模型刚刚出来的时候,我们大家都在聊 Prompt Engineering。它的核心是说,要怎么样去写好一个提示词,让模型给出更好的答案。后来在 2024 年,焦点就变成了 Context Engineering。它是说怎么给模型提供更完整的上下文让它能够去理解更加复杂的任务到 2026 年一个新的词开始在硅谷流行起来了叫做 Harness Engineering Harness 在英文里它原本是指挽具就是说套在马身上用来引导和约束马的那套装备那现在它被用来形容一件事就是你怎么样去围绕大模型搭建一套能够让他在真实的世界中持续工作自我修复还能自我提升的一套系统最近 Creo 的 CTO Peter 他在推特上写了一篇文章叫做为什么你的 AI 优先战略可能错了引发了几百万的关注与讨论所以他的核心结论是大多数公司所谓的这种 AI-first 都是假的那真正的 AI 优先战略是重新设计整个公司的流程还有组织结构本质上也是他们内部怎么样去 Harness 的过程 Peter 之前是 Meta Llama 基础模型团队的研究科学家后来在苹果从事多模态模型的相关工作所以他的工作语言是英文如果本期内容的中英文夹杂过多欢迎大家收看我们播客的字幕版那也很难得今天除了 Peter 我们还把 Creo 的另外两位创始人也是这个故事的亲历者邀请到了我们的节目上来聊一聊他们是怎么在 AI 快速进化的一年里重新组织自己的组织架构把信任人变成了信任 AI 好，那首先我们请今天的三位嘉宾简单介绍一下自己。 [00:02:00]

Peter Pang：大家好，我是 Peter，Creo 的 Co-Founder and CTO。

程凯：大家好，我是 Creo 的 CEO and Co-Founder，程凯。

Clark Gao：大家好，我是 Clark，我是 Creo 的 Co-Founder。现在主要负责我们的 Go-To-Market。之前是做了很多年的 Data Scientist 和 Machine Learning Engineer。现在在 agent 的这个领域里面，跟凯还有 Peter 一起帮助用户更好地使用 agent。

泓君：然后达到 AI-first 这样一个组织形态的目的。好的欢迎三位开始的时候我们就直接主题吧就最近大家都在关注这个 Harness Engineering 那 Peter 你要不要跟我们介绍一下

Clark Gao：什么是 Harness 的 Engineering Harness 这个概念其实可以追溯到大模型刚开始的时候很多人在聊 Prompt Engineering 之后演变到 Context Engineering 到之后的 Harness 整个 Harness 过程不仅仅是对于 LM 本身的 Harness 还包括围绕的整个大模型包括它的基建 Tooling 的使用包括安全的 Security 的保证整个的这样一个 improve 的过程

泓君：我们把它叫做 Harness 可不可以跟听众解释一下这三次进化它是怎么发生的然后每一步它最重要的是什么对我先说一下 Prompt Engineering 和 context engineering

Clark Gao：更多的是 focus 在怎么和 LM 这个大模型本身进行交互就是我怎么优化它的 context 怎么优化它的 prompt 从这个角度上来讲它的 scope 要比我们现在讲的 harness 要小得多而且从静态和动态的角度上来讲 prompt engineering 和 context engineering 相对来说是一个静态的事情因为你优化的是一个大模型你优化的任务可能也是一个相对来说比较 vertical 的任务但是对于 Harness 来讲 Harness 是一个系统的 Harness 而且对我们来说我们是在 Harness 一个 general 的系统所以从 scope 上来讲会比 Prompt 和 Context Engineering 要大很多因为这涉及到 tooling 的使用涉及到你的 sandbox 的架构设计和你的 host 的 service 之间是怎么进行交互的怎么样的交互能够安全你的 sandbox 在启动的时间是多少你的 latency 是多少 [00:04:10]

泓君：都是 Harness 的一个部分我可不可以理解成 Harness 的工程能力在决定你怎么把一个大模型炸出它的最佳使用上限它可以理解成是 AI 的一种工程能力举一个例子我记得凯你之前是在融资的一个新闻稿里面其实你有提到一个 agent 他可以一夜之间干掉三个人这种做 SEO 的工作流同时呢还有一个 content 的 pipeline 它跑了两天然后才有人发现全是垃圾这两者之间的巨大的区别就是一个非常好的表现跟一个非常差的表现我可不可以理解成从本质上说一个就是 Harness 的胜利一个就是 Harness 的失败

Clark Gao：对刚才提到了两种状态一种是你效果好一种是效果不好但是我觉得这个是完全就印证了为什么我们需要 Harness 因为 Harness 的本质就是在于我们怎么能够持续提升一个系统当你这个系统产生的效果不好的时候你这个系统是需要人的 Feedback 去提升呢还是这个系统本身自己能够 self-healing,self-improvement 这个正好就是 Harness 的核心因为通常来讲我们也有很多用户在我们的平台上产生 agent 但是这个 agent 不是说 one shot 就能达到一个完全优化的状态用户怎么去 follow up 这个 agent 我们的系统怎么能够 self-improve 这个 agent 也是整个 Harness 的核心 Harness 很重要的一件事情就是怎么能够让 agent 在 inference 阶段 scaling 包括你怎么能够把更多的 context 提供给它更多的 tooling 给它让它思考更长的时间完成一个任务用一个更长的时间我觉得这都是在 inference 间段的一个 scaling 所以在 inference 间段的 scaling 因为它工作时间长 tooling 使用的数量多它的 context 多所以你 harness 如果做得不好的话就很容易产生 hallucination 或者你 context overflow 你的模型的能力会 degrade 所以在这个过程之中怎么把这个 Harness 做好 [00:06:09]

泓君：其实是一件非常复杂而且需要一些经验的事情对换句话说就是 Harness 它是一个新概念但是它所谓的新呢其实是把这种传统软件的东西放到了 agent 的应用上所以大家怎么去看这个 Harness 里面它有哪些是就是我们这个时代的新的东西传统工程没有的因为大多数业务的人他可能都是从能力层面

Peter Pang：去理解一个软件就像很多人从传统的角度来讲他不理解就是说其实一个很简单的功能可能都需要开发团队在之前的情况下就可能要做两到三个月才能去实现很多业务的人经常会说的事情是我觉得这功能很简单为什么这个产品就是一直解决不了我这个问题呢那其实是因为后面有太多的工程化的问题牵扯在那边其实这个对于 agent 来讲也是一样的很多人会觉得 LM 的能力提升了但为什么他做不到我想要做的事情那其实是因为 [00:07:04]

泓君：还有很多工程化的问题需要一起被解决那这个其实也是我们去做 Harness 的一个原因你觉得今天我们市场在讨论 Harness 的这个部分中有哪些是大家的共识有哪些是非共识

Clark Gao：因为我觉得不同的群体对 Harness 的认知可能不一样我听到的很多看法通常来讲这代 Harness 是一个静态的过程我怎么能够 develop 到系统去把 LM 的优势更大的发挥出来而对于我们来讲我们认知中的 Harness 就是一个动态的过程你这个系统怎么能够从一个静态的状态真的活起来能够 self-improve 能够不停地 adapt 新的 signal 不管是 marketing 的 signal 还是产品本身的 signal 还是用户的 signal 能够让它不停地迅速地迭代我觉得这个是可能很多人还没有意识到的一点然后这个迭代也是以 AI 为主导的而不是人为主导的对也是以 AI 为主导的迭代但是人所需要做的事情就是怎么把各种各样的 signal Feed 给 AI 不管是 Marketing 的 Signal 还是产品的 Signal 还是本身 Infrastructure 自己的 Signal 对 [00:08:09]

泓君：我注意到最近你有一篇 Twitter 的帖子非常火然后其实是讲你们是怎么一家 25 个人的公司然后 99%的代码都是 AI 来写的基本上你早上 10 点写了一个功能中午就进行了 AB Test 然后下午 3 点的时候就根据数据的反馈把它砍掉了一部分功能 5 点又重写了更好的一个版本这是一天的时间但是这种工作的节奏在传统的开发产品的过程中它是需要六周的你的这个帖子在推特上非常的火到现在为止我昨天还去看了一眼有 187 万的推特的流量同时下面大家也有很多的共鸣但仔细看下来其实我觉得你就是在讲 Creo 在整个工作流程中用 Harness 去做的也算是你自己独立探讨出来的一条 Harness 的方式对我觉得这个就牵扯到 [00:09:00]

Clark Gao：Harness 的一个具体细分的层级在我们 Creo 来看 Harness 分成两个主要的部分一个是对于 Creo 本身 agent 系统的 Harness 另外一个是对于用户使用 Creo 的时候在构建自己的 agent 的过程中怎么 harness 自己的 agent 在之前的话我们传统的开发过程中可能需要两三个月的时间来迭代一个 feature 但是在 agent 这个情况之下很多东西都是 AI 辅助的 coding 本身 implement 的这个 feature 可能只需要一两个小时的时间所以在这个过程之中如果我们再花很长的时间去 design 和很长的时间去 testing 就不是很 make sense 所以我们怎么把 design planning 的阶段和 testing 的阶段 include 到整个的这个 harness 过程中对这个公司能不能真正转型成为一个 AI-first 公司是非常 critical 的对我想先跟大家表达一个观点

程凯：我们如果想要做到所谓的 AI-first 或者 AI native 这样的一个状态那它并不是在现有的流程上面去使用 AI 的工具而是要围绕 AI 的能力去重新的构建你的工作流程和组织形态所以这个是 Peter 刚刚所描述的因为其实我们在之前的很长一段时间里面其实每一个工程师他都在用 AI 写代码每一个产品经理都在用 AI 写 PRD 每一个设计师都在用 AI 做图但其实这样并没有增加我们的效率反而是导致每一个人的工作的进度和节奏不一样之后我们的 alignment 的成本变得非常之高因为我们本身是一个全部都是 remote 办公的状态所以在这样的一个机制下我们要去重新的想我们到底怎么样能够让 AI 在我们整个公司运营的过程中能够真正的自动化跑起来所以才 Peter 设计了一套新的开发流程和我们新的产品的架构重构才有了今天 Peter 所写的这篇文章里面所讲的 self-healing 的自我修复的 agent harness 或者 engineer harness 是一个什么样的形态 [00:10:59]

泓君：可不可以举一个例子因为你在说重塑开发流程跟组织架构你们开始用 AI 自己去写 agent 的过程中包括你们在重塑你们整个的组织架构的过程中你们觉得哪些方向发生了变化瓶颈在哪些方向哪些方向跟你们在预期的过程中它是不一样的对我觉得在我们整个推进 harness [00:11:24]

Clark Gao：和推进 AI-first 的过程之中首先需要解决的就是人的问题大家能不能够接受这个新的工作方式所以我们也花了很长的时间去 align 大家的 mindset 我觉得这个 mindset 的 alignment 是最重要的之前的话可能我们需要做这样一个转型需要很长的时间因为人需要去搭建这个系统通常比如说一个 architecture 一个 engineer 他需要 several months 的时间去 demonstrate 我的这个新的工作方式是比之前的更好的但这个转型的 cost 就相对来说非常的大但是在 AI 辅助的情况之下我们在 demonstrate 整个这个新的工作方式的过程中就比以前会快很多可能我们只需要一两周的时间把整个系统进行重构包括从前端后端 architecture infrastructure 都进行重构然后给大家 demonstrate 这样一个新的过程它 work 起来是更 efficient 的不管是 deployment 的频率 deployment reliability 和最后的效果上来讲都能够比之前的工作方式有一个很大的提升这样的话我们可以在很短的时间内对大家的 mindset 进行一个 align 之后的话大家 onboard 到这个工作方式的过程之中的话就能够更快速地融入到整个的开发过程对对对其实 Harness 本身其实它更多是在于 [00:12:40]

Peter Pang：Build 的一个系统真的能够让 Peter 刚才说的这个所谓的 AI-first 这样子的一个组织结构能够高效地运转这个其实非常重要为什么因为很多的组织上的人他的思维会很难去改变他会觉得说我可以用 AI 来提升我的效率但是 AI-first 要求是说你让 AI 来 drive 你的整一个公司的方向还有可能你每天工作的方式都是由 AI 来 drive 的这是完全不一样的概念举个例子是每次 AI 给你们布置任务吗对对其实就是说对原来可能大家都是觉得就是说还是人去提出一个概念然后由 AI 来帮助人去提升效率但这个东西可能因为人如果还是这个工具的使用者那他的效率提升可能有一个所谓的效率的倍数的上限可能最多就十倍因为人最多每天可能就工作 24 小时但是如果说你真的希望 AI 能够给比如说我们工作的效率去提升 100 倍 1000 倍你不能还是说是你是那个工具的使用者而是 AI 应该是所有生产力的主导人的角色就会发生变化更多是在于我怎么去看最后的结果的是否是好的或者说我怎么去 review 这个结果的好坏还有包括我在这个系统里面我并不是那个实际的工作者那么如果在这样的角度下我应该以怎样的一个方式去跟这个系统配合起来那这个其实我觉得是很多的企业它在做转型要么就是它没有意识到的点或者说它很难去做到的一个事情能不能举一个例子 [00:14:01]

泓君：你们的系统怎么跟人配合去工作比如说是系统给人发任务因为我觉得传统的团队就大家在开发产品的时候可能很大的一个痛点就是说我团队之间要对齐然后我要把信息同步到每一个人任何一个人他可能 miss 掉了一个信息点那他在产品做开发的时候他可能就不知道我们上一版的更新是什么现在是不是所有的这些工作都可以交给 AI 或者在这个流程中

Peter Pang：他就可以自动去做了对我觉得这里面核心的一个点还是信任的问题因为很多时候就人因为对这个系统他没有信任所以说刚才会有像您说对齐的成本就会非常高像 Clark 这边的 Go To Market 这个 team 和比如说 Peter 这个 engineer 这个 team 他们两个团队怎么配合起来原来的话他们需要互相的沟通互相达成共识对齐之后那才能事情往前推进但现在如果是 AI-first 这个组织结构的话他们其实没有对齐的所谓的过程而更多的是在于这个对齐是由 AI 来主导比如说告诉我们的 [00:15:01]

比如说告诉我们的

Peter Pang：比如说告诉我们的 marketing team 说今天我们开发团队 engineer 要发布哪些功能那这些功能到底是怎样的一个结构那 marketing 就不用再去

泓君：跟 engineer 交流说你明天要发什么功能后天要发什么功能那这样的话它中间的对齐成本就会降低 AI 怎么知道 Peter 的 engineering 团队明天能把所有的工作做完这个就是皮尔可以说一下

Clark Gao：对我觉得在整个的这个过程不管是叫 Harness 还是 AI 主导的工作流过程中主要大家体会到的 improvement 就是整个开发速度和迭代的提升通常来讲 implement 一个 feature 或者 deploy 一个新的产品需要很长的周期所以大家需要详细的讨论但是我觉得在 AI 的 mindset 之下因为它迭代一个产品的速度是很高的那在这个过程之中我们其实更侧重的是 OK 这个新的 feature 能不能够带来产品的 topline matrix 的提升或者我新的这个 feature 能不能有真的用户使用的数据所以在这个过程中我们更核心的 focus 的点是怎么把整个的数据链搭建起来我们把这个链条搭建起来之后都是 agent 通过这些数据来决定 OK 这个 feature 到底是不是有用的我们到底要不要 rule out 这个 feature [00:16:14]

泓君：或者 fallback 这个 feature 也就是说工程师写完代码以后不需要手动地跟 AI 比如说有一个什么工程管理的界面说我写完了这是传统的软件跟公司内部系统同步的一种方式然后现在说 AI 它就可以自动地根据你的整个的代码质量你的进程去做出一个它的判断对这个在传统的 engineer 中也有我们叫 CICD process

Clark Gao：只不过在传统的 CICD process 很多都是 root based 的或者一些 unit testing driven 但是在 AI 这个情况之下我们可以有很多 AI driven 的 testing 不管是 integration test 还是 unit test 比如现在大家比较常用的像 playwrite 是可以做 AI driven 的 fully entwined testing 这样可以保证我们 shipped 代码中是没有明显的可以 break 这个产品的 bug 所以在这个过程中很多 AI driven 的 testing 是非常重要的包括你代码 shipped 之后在这个 log 中有没有 error 有没有 incidence 都是通过这些 signal 能够 feedback 给 AI 来看整个这个代码的质量是什么样子的 [00:17:21]

泓君：对 Clark 比如说你要在做市场营销的时候就是你知道代码团队已经写完了但是呢我觉得很多时候大家一个产品要传递的核心的理念是什么包括你要跟这个市场传递的关键信息是什么它很多时候是需要一个产品的灵魂人物不管是 CEO 还是 CTO 还是产品经理它是会有一些沟通跟关键信息的梳理的这个是 AI 能做的吗

程凯：是的是您这个问题问得非常的一针见血其实我们现在也花了很多时间思考这个问题因为我们就实行这套新的开发机制已经有几个月时间我自己的一个体会就是说现在我们确实不用跟 engineer 过多的沟通说你要做什么 feature 然后你什么时候能 deliver 因为 feature 现在的数量已经远远超过我们能够去卖它的这个能力了这个是我最大的体会就是我们现在开发的速度是远远超过于市场这边的进度的但这样有一个好处就是我们不再去用讨论说今天你这个公司的 product roadmap 是什么而我们只需要讨论的是现在市场的需求在哪里我们就好像有个菜篮子一样或者说像机器猫的万能的宝箱一样如果今天说市场的需求是一个苹果我们就从我们的篮子里面挑一个苹果去卖如果今天市场的需求是一个香蕉我们就可以挑一个香蕉去卖这个反而是大大降低了我们对其说今天好像市场反应是这样的我们要去重新思考我们要做什么样的产品这个其实是比过去 [00:18:51]

泓君：要省时和省力很多的我理解了就相当于其实你们的开发能力是远远快于市场能力的所以当市场有新的风向的时候反而是你们可以从你们的已经搭建好的产品库里面看你们在哪一个点上穿透去营销是的是这样的有意思关于让 AI 写代码我还有一个很核心的问题就是怎么保证它的质量因为 Peter 其实你在你那篇推特的文章里面写到了正常情况下写代码一天然后大家修 bug 要三天现在就是有哪些新的手段加入可以让大家不用把很多的时间都花在修复上 [00:19:30]

Clark Gao：对我觉得 bug 这个事情是一个整个 engineering 不可避免的一个事情不管是 AI 写代码还是人写的代码都会产生 bug 因为 harness 它不是一个静止的状态它不是说我现在有一个系统之后我只需要维护这个系统这个系统不会有 bug 也不需要提升 harness 这个过程核心就是在于我能不能找到这个系统中的 bug 刚才聊到 CICD 的过程就是在 integration 的时候在 testing 的时候我们会有一系列的 regression test 去避免有一些 bug 可以 ship 到 production 中 break 这个系统这是第一步第二步的话即便有一些 corner case 或者 risk conditionshapes 到这个系统之后我们怎么能够在最快的时间 identify 这些 bug 然后及时地 fix 这些 bug 是第二步的事情所以这两步就是传统的情况之下都是由人来 driven 的但是在 agent harness 的情况之下我们会有 agent 的系统来 driven 所以我们 develop 了 agent driven 的 CICD 系统和 agent driven 的 bug triage 系统会根据系统中的 issue 去 triage 这个 issueassign 给 engineer 让他们去 fix 这些 bug 对你觉得在你引入这两套系统以后它的效率提升了多少首先因为很多都是 agent driven 所以它可以 parallel 地进行所以可以有很多 agent 去 identify 比如说有一些 agent 专门负责前端的 bug 有一些 agent 专门负责后端的 bug 有一些负责 agent 核心系统的 bug 所以在这个过程中它发现一个 bug 可能只需要一到两分钟的时间然后它在把这个 bug assign 给一个 engineer 的过程中也可能也就是 few second 的时间 engineer 拿到这个 task 之后也是用 agent 去 investigate 提出一个 solution 所以整个的这个 cycle 加起来可能也就是一到两个小时的时间 compare 之前的话我们 identify 一个 bugfix 一个 bug 再把它 ship 到系统中可能需要一个周的时间对这个里面有一个特别有意思的现象就是因为我们之前所谓产言产言 [00:21:30]

程凯：就是产品和研发结合然后我们公司以前其实是有一个 feature wishlist 就是你到底希望做什么样的 feature 然后很长然后又有一个 bug list 有很多 bug 要修复然后以前就总是打架到底是先修 bug 还是先做 feature 市场和产品还有工程师大家就在那讨论来讨论去现在这两个 list 都没有了因为 bug 及时发现及时修复 feature 现在的数量

Clark Gao：远远多过于我们所需要的数量对就是提供一个数据的话就是我们现在有一个 autofixing 系统就是这个 autofixing 系统是根据整个我需要 fix 的 code 是存在于哪个文件夹下因为有一些文件夹是敏感的有些文件夹是相对来说 risk 比较小的对于我要 fix 的一些东西如果只是存在一些 risk 比较小的文件夹之下的话 AI 会自动地提交这个 PR 然后可能只需要一个 engineer 简单地 prove 一下它就马上能够 shape 到 production 所以可能现在 50%以上的 issue 是通过 autofixing 的形式进行的可能人在里面的参与只是简单地 prove 这个 bug 如果这个 fixingtouch 了一些比较 sensitive 的文件比如说涉及到安全涉及到 agent behavior 的话我们可能需要专门的 response 这个 area 的 people 去进行一个更 deeper 的 review 但整个的这个过程相比于之前来说也是有一个很大的提升有什么奇怪的 agent behavior 吗因为 agent behavior 可以 break down 很多 area 比如说这个 cost 太高或者 latency 太高或者有 hallucination 或者它使用 tooling 的时候和 tool 之间的交互的 authentication 有问题我觉得都是涉及到 agent 的 behavior 所以任何这个系统中的 issue 都能导致用户具体在使用这个 agent 的时候 [00:23:14]

泓君：不能够完成它的 task 所以 agent 还是一个比较 complicated 的这个 engineering 系统简单来说就是现在 agent 还没有价值观的问题它还是效率的问题跟你灌输给它的一套思想

Clark Gao：比如说是不是要用更便宜的 cost 就同样的任务呢更便宜地去完成还是这一方面的就是效率上的问题对我觉得主要是效率和具体能不能够完成用户的 task 的层面上就是我们所 focus 的

泓君：就是怎么把我们的系统优化到在 cost 的最低的情况下能够 reliable 地完成用户的 task 对比如说当系统出现一个 bug 的时候假设我是在改一篇稿子即使它只出现了一个小错误我可能需要把整个稿子看一遍然后我再去看那个错误是在哪我怎么去修改那这个时间其实就跟比如说我自己重新写重新熟悉这个领域它的时间花的是差不多的因为我不太懂写代码只能用写文章做比喻对一道开发的领域就比如说 agent 帮你搭了一个非常好的技术框架但是呢它可能在整个搭建层或者基础层出现了一个大的错误那这个时候当然有其他的很多的 agent 要去修复但会不会说比如说有一些大的错误大到了需要工程师去解决但是工程师去解决的时候我不能只看这一个点我要先看你整个的构成是怎么样的 [00:24:32]

Clark Gao：然后我才能去解决那个细分的问题它同样要花的时间就是我还得把这个重新学一遍对我觉得这个问题很好所以在之前的我的文章中我也讨论了在 AI 环境之下的工程团队可能分为两种人一种是 architecture 一种是 operator 所以 architecture 在整个这个系统搭建过程中的作用是非常重要的比如说在搭建整个 Crew 的系统的过程之中整个 agent 的 architecture 是什么样子比如说 sandbox 和 host 之间是怎么交互的还是由 architecture 来决定的如果说 agent 直接通过 AI coding 或者 web coding 的方式它通常来讲会给你一个 solution 但这个 solution 通常会有安全的隐患或者 latency 的隐患怎么去优化整个的这个系统还是由 architecture 来决定的但通常来讲我觉得区别就是在传统的情况之下搭建 agent 的团队以前可能需要 10 到 20 个人但是现在搭建整个这样一个系统只需要一个 architecture 在一个周的时间之内就能完成你现在是那个 architecture 当然从一开始我们在 develop 这个系统是需要我来 architecture 整个的系统去 demonstrate 给整个的团队整个这个 architecture 是比之前更优化效率更高 cost 更低我来补充一下刚刚 Peter 所讲的内容第一就是我觉得 AI 的能力 [00:25:50]

程凯：在很早以前就已经非常强了但是它为什么没有达到人们所预期的那样说今天 AI 可以替我干活他如果没有干好我还得帮他去弥补他的错误我觉得这个点来讲就是 Harness 在这个过程中非常重要去发挥价值的地方这个主要里面有一个很大的一个概念上的转变就是我们要把 AI 当成一个系统来看待不要把它当成一个智能来看待虽然系统是由智能所驱动的但这里面一个核心的差距就是当 AI 或者说这个系统发生错误的时候我们不要想着怎么样去纠正这个智能我们要想着怎么样去弥补这个系统这个其实就是我们在做 Harness 跟现在普遍的认知最不一样的地方就是它是一个动态改变和提升的一个过程并不是一个静态的固定的枷锁去束缚这个智能而是要给它提供空间让它能够成长这个成长的方式就好像你在养一个孩子你怎么样能够让它不断地在一个规则内变得越来越好我们做 Harness 其实是在给用户提供说我们给你一个培训师去弥补他在发现错误之后你该怎么办回答您刚刚那个问题如果您在写作的时候发现说 OK 有一个巨大的问题我觉得您应该花更多的时间去思考这个系统上面有没有漏洞而不是我要去花更多的时间去改正具体的某一个错误这个里面还有一个更加极端的一个想法就是您今天发的这些内容或者我们自己发的这些内容可能未来的这些受众并不一定是人这个错误可能对人来说是一个很致命的错误但对于未来可能都是 AI 在读文章或者 AI 在读我们的图片视频对他们来讲可能并不是一个很致命的错误所以我觉得大家其实在这个过程中要思考更多的就是我今天做的这个工作到底是未来谁来去消费我的工作和我的这些结果根据你的这些消费者他们的偏好调整你 Harness 的这个系统才能够更好的达到 [00:27:47]

泓君：你所能够希望去 Deliver 的价值我觉得这个观点非常有意思就是大家以前在出现问题的时候都是说我们解决问题现在说的是 OK 我们解决搭建的环境中的系统上的问题而不是一个单一的问题就是彻底上修复它以后它这个问题就永远都不要再出现了对与其说是彻底修复它不如说是我们重新思考这个问题它是否还是一个问题 [00:28:14]

程凯：比如说我们平常会生产一些 go to market 的 asset 比如说有些图片我们觉得可能从人的审美上去看它并不是一个很好的一个 asset 但实际上你把这个东西投向市场的时候你会发现可能读这篇文章或者读这个图片是一个 agent 在读它的数据反馈回来其实可能是更好的如果我们与其去说 OK 今天人觉得这个东西它不够好我们要去修复人主观对这个东西的价值判断那我们与其去修复说整个不管是我们自己的系统还是别人的系统对这个事情的价值判断它其实是从价值理解上面就会发生偏差

泓君：为什么会是 agent 在读一个营销图片就是你们的下载是针对谁的是针对 agent 的还是针对人的现在大家也比较感兴趣的话题就是以后会不会有这样的 agent 的经济可能买东西是由 agent 去买 [00:29:04]

程凯：订报纸是由 agent 去订订牛奶是由 agent 去订那你的广告是发给 agent 看还是发给人看因为我现在自己看很多文章看很多视频也是让 agent 去看所以你要搞清楚你的内容到底是被谁消费你的工作结果到底是被谁消费针对这个东西的价值我们再去思考我们到底是提升系统还是我们回到最原始的人要参与到这个创作的过程中去弥补我们一些错误我相信在未来

泓君：真的是在 agent 帮大家做更多的购买决策的时候最终的结果可能还是 agent 看得多但是我没有想到在现阶段包括你在现阶段测试的流量中 agent 已经占到了

程凯：一个这么大的比例就是它来的比我预期中要快很多是的是一个亲身的经历我最近在看有什么样的公司能帮我们做合规的比如说 SOC2 ISO 写写认证那我肯定是让 agent 先去帮我 research 一番然后我基于他的结果 [00:30:02]

然后我基于他的结果

程凯：然后我基于他的结果我来看一看是不是适合我们那这个里面你会发现第一步已经是在 agent 帮你做这个筛选了那是不是那些内容他应该更偏向 agent 去做而不是偏向人去做当然我点进去再去看某些东西的时候可能需要有面向人一直就需要消费的内容但是有可能它会把第二层也做掉了以后甚至第三层也做掉所以这个我觉得

Clark Gao：都是可能会发生的事情这个从另外一个角度上来讲也可以很明显地看到就是现在 Saa S 产品的转型因为以前很多 Saa S 产品尤其是像 Asana Linear 这种的产品做 Task Management 它需要一个 Dashboard 以前可能很多的都是人在去看这些 Dashboard Manage 这些 Dashboard 但是在起码现在这个阶段我们团队在使用 Task Management 的时候我们更关心的是 agent 能不能够更好的看这些 taskprioritize 这些 task 所以 instead of 人去看这些或使用这些 dashboard 更多的是我们会去看这些 task management 产品有没有更好的 mcp 和 api [00:31:03]

Peter Pang：提供给 agent 可以让我们使用对所以整个进化还是非常的快的其实刚才您提到这个问题也是很多公司他在做 AI 转型的时候会第一个考虑的问题他可能会看到下面有很多的员工也好会说他的管理层会觉得我使用 AI 的时候如果我还要去 review 一遍那跟我人去做其实这个不管你是时间也好还是你的成本也好可能没有太大差别但是就像刚才皮尔说如果你真的能够把这样子的一个人工智能系统给构建起来之后你会发现其实你仔细去算一下你会发现你的时间还有你的成本是会有很大的一个提升的只是这个过程需要整个团队一起有一个共同的一个目标说今天我就是要把公司的组织结构也好工作方式也好都去改变它这个过程当中只要有那么一些人他可能觉得做很多东西可能还不如人去做那这个过程就会让改造的时间会被拉长以及这个过程就会变得特别不顺利这个其实是一个大多数公司

泓君：都会面临的一个从组织上来讲的一个挑战你们是第一天就这种 AI-first 的工作方式还是说因为其实你们也成立一年多了而这一年多我觉得是整个行业里面变化最快的一个时间段 [00:32:10]

Peter Pang：还是说你们在后面慢慢地摸索到这样的一套工作方式的我觉得我们整个公司也是有一个过程的你意识到谁是未来的生产力的核心的角色可能在二五年的上半年的时候大家都会觉得可能那个时间点还是 AI 是辅助人去做事情那人在整个工作里面还是占主导地位的但是到了下半年的时候我们会意识到如果还是这样子的话那其实企业的效率提升还是非常有限的因为我们也用了这样的方式我们会发现好像效率没有提升的有我们想象那么多所以我们会发现那里面核心问题我们还是没有把这个生产力工具的使用者真正的从人转变到 AI 这个过程如果没有彻底的去改造它我会发现可能还不如我人去做这个事情来得更高效所以说这个过程也是需要一个非常长的过程还有包括像刚才 Clark 跟 Peter 提到不光是技术团队内部会有这样的一个挑战还有包括 marketing 团队和开发团队之间他们在对齐的时候大家都需要一个理解的过程我们也因为这个理解过程会浪费一些时间在上面就比如说市场团队跟 engineer 团队有很长的一段时间可能甚至一个月或两个月都在来来回回地探讨怎么样一个更好的方式工作这个其实都是组织的进化它需要一个过程这过程一定不是从第一天开始就是这样的我觉得这个也是跟整个 AI 能力相关的 [00:33:30]

Clark Gao：从过去的一年之内 AI 从一个辅助 engineer 的角色到一个参与到开发过程中的一个角色到现在能够相对来说主导开发过程的一个角色是根据本身基础模型能力的提升 agent 的架构的提升和 agent 的 infrastructure 的提升都是相关的比如说一年之前如果想让我们说用 AI 主导整个的这个开发过程中我觉得从技术上来说是不成立的但是从整个重构过程中我们发现当 AIreach 到这个 point 的时候整个的重构不管是从速度还是从效果上来讲都是远超于一年之前能够想象的一个程度你们是从哪个时间点开始重构的然后这个重构的时候整个市场发生了什么你们做的最核心的几件事情是什么对其实我们意识到需要重构这个事情可能是去年八九月份的时候之前的话我们会花一些时间进行团队的 alignment 其实 engineer 产品团队和 marketing 团队大家的 mindset 是最重要的所以我们可能花的最多的时间就是怎么让大家转变这个 mindset 我们真的开始重构那代码架构整个的开发的过程可能也就是今年一月份的时间就是今年过年之前我们在使用了大概两个周的时间就重构了整个我们的所有的架构包括现在大家看到的产品 [00:34:52]

泓君：也是根据这个阶段重构的过程中的这样一个产品有哪些你们觉得之前 AI 解决不了的事情然后 AI 解决了可不可以举两个例子之前 AI 解决不了的事情 [00:35:04]

Clark Gao：主要是在 planning 阶段比如说我 100 分 Vscore 的话它能给我一个 90 分的 score 我看到这个 plan 的时候我能够再给它一些 criticize 它能够给我一个 revised plan 而不需要我真实的去改这个 plan 比如说我说现在这个情况下能够打 90 分的话那一年之前的话可能也就是 50 分一个不及格的状态我可能需要人为的再去 modify 这个 plan 再去改整个架构但是现在的话比如说整个我们这个新架构我可以说我一行 code 也没有写一行的 tax 也没有去改这个 plan 我只是在跟它进行交流我 criticize 你这个 plan 是不是有缺陷是不是优化的在 create 这个 plan 的时候你可不可以 reference 一下其他 popular 的 open source 的 frameworkagent framework 你给我一个最终的版本你觉得它的能力在你之上吗 AI 写代码的能力首先 AI 写代码的能力肯定是在我之上的因为我没有写 planning 的能力 2026 年我就没有写过一行代码但是从 planning 的能力上来讲的话作为一个 architecture 的价值或者在一个公司里面不管是你是一个 CTO 还是一个 tech lead 你的价值就是在于找到 AI planning 的缺陷所以本身 architecture 和不管是 tech lead 在这个之上还是有价值的我只能说现在 AI 的 planning 还是有缺陷的比如说它一开始给我的 planning 可能有 security 的缺陷可能有 latency 的缺陷那我根据我之前的 architecture 的经验我怎么能够 criticize 它或者 challenge 它能够进行进一步的提升对然后你们是一月开始做转型的 [00:36:36]

泓君：到现在你觉得 AI 现在在做 planning 就是你教给了他我们要怎么去做这个 latency 安全性他现在在做新的计划的时候他会变得好很多吗对我觉得这个就是 harness 的核心

Clark Gao：之前我教给他你在安全性上在设计 sandbox 和 host 之间的关系的时候你要 follow 什么样的准则那这个时候我就可以把它变成一个 skill 那在下一次的过程之中我只需要 reference 这个 skillinstead of 我去说更具体的内容我说你能不能 follow 我这个 principle 就变成一件很容易的事情而且不光是我自己能够 challenge AI 包括所有其他的我们团队的 engineer [00:37:15]

泓君：也可以 reference 这个 skill 看 AI 的 plan 能够 follow 之前的我们的这些 principle 可不可以给听众一个直观的印象你现在有了 AI 做生产的主力以后它干出了配多少员工才能干到的事情给大家一个数字上的直观的感受就比如说以前一个团队它需要 20 个人做四周我随便说现在就多长时间就做到了如果翻到一年之前

Clark Gao：我们不是 AI 主导的情况之下要 develop 像 Crew 现在一个产品我就起码需要 100 人左右的团队花四五个月的时间去 develop 这样一个版本如果大家看其他的 general agent 的公司的 company size 大概也是这样一个范围现在是 25 个人我们的 engineer 团队可能只是 10 人以下 10 人以下多长时间从产品的第一个阶段的 deployment 可能也花了大概两周的时间 [00:38:09]

Peter Pang：两周的时间十个人以下对这个效率提升很高的对从创业公司角度来看或者说很多 Saa S 公司运营一个 Saa S 产品的时候你会有个很直观感受就是在原来的传统的软件时代下你会发现销售团队他们在概念角度来讲会超前你自己的产品可能四到五个月可能大多数你的用户看到的是你四到五个月之后才会发布的一些功能但现在这个情况下它是反过来的比如说 Card 这边的 marketing 团队会感觉就是说我们有很多很多功能我们甚至都不知道它已经做完了就技术团队可能是反过来是超前了 marketing 团队可能三到四个月或四到五个月更多时候变成 marketing 团队在追赶开发团队的一些功能还有安排那这个就是一个我们从最外层来看它最大的一个区别那这个区别就会导致你的整个运营方式它包括你的整个组织结构可能都会跟原来不一样凯也提到了现在整个技术开发的速度 [00:39:04]

泓君：是大于市场营销的速度的 Clark 你这一块会有从市场营销的层面也用更多的 agent 因为技术可以用你们也可以用我知道代码 agent 这两年特别特别的火那在整个 marketing 的素材生成方面以及这个素材的产出方面或者是你其他的一些流程方向你觉得现在这一块的 agent 的发展怎么样了所以我们现在整个 go to marketing 都会用我们自己公司的产品

程凯：去构建 AI-firstgo to market 的 workflow 或者流程当然这里面有很多坑我觉得最大的一个困惑就是 engineer 它是一个相对比较好去做 evaluation 相对封闭的一个环境它能够有明确的指标说今天你干的好还是不好但是从 go to market 的角度不管是你是写文章也好做视频也好你是面向人的消费群体他对于这个事情的价值的认可和面向 agent 或者不同的人群每个人他都有自己对这个价值的判断这个是相对来说比较主观的那我们怎么样去构建这个系统能够更好地把这些主观的判断变成一种信号让我们的系统能够自动去运转起来这个是一个比较大的挑战我们也没有说我们今天就是百分之百让 agent 去做决策但我们会放很多 agent 的结果再由人再去判断说这个结果好还是不好我们有很多很多的 feature 但我觉得市场还没有 ready 那我们就不会把这些东西放到市场上面去我很好奇你们有哪些超前的思想是市场还没有接受的每个人的 agent 都有所有的权限可以读写这个其实是一个相对来说比较大胆的一个动作我们希望说未来为了能够让你的组织更加高效你的很多数据是应该开放给你的 agent 开放给每一个人但这里面可能还需要更好的一些技术的支持包括你怎么样去限制每个人的权限或者限制 agent 权限怎么样让 agent 在读取这些数据的时候不会出现失误因为如果他读的数据是错的或者他自己开始乱搞那你最后的决策可能会受到很大的影响所以这个就是我觉得还没有 ready 推向市场但是至少我们自己用起来很爽比如说我原来我要说 Peter 今天我们有多少个用户有这样的行为可能还要去找做数据的同学或者是 engineer 去帮我打一个新的表格出来但今天我只需要跟 agent 说 [00:41:29]

Clark Gao：我提这个问题他立刻三秒钟之后给我一个答复我觉得现在主要的 challenge 对于大部分 agent 公司来说不是市场能不能接受这种工作方式而是市场不知道这种工作方式的存在或者他不知道怎么去高效地使用一个 agent 帮助他能够完成他的 work 所以 Creo 在整个的过程中我们也做了很多工作就是让用户不用进行复杂的设置能够更容易去 access 这个 agent 帮助他完成他自己的本身的工作这是不是也是你们公司现在在做的事情就是让 AI 自己去创建 agent 对我把上一个时代的 general agent 理解成这些公司会提供一个 agent 用户会使用这个 agent 去帮助他们完成自己的一些工作但这个 agent 不管把它叫做 general agent 还是 super agent 它是一个 unique 的 agent 所有用户 access 是同一个 agent 我 Creo 在做的事情就是我怎么能够让用户在我们的系统上搭建属于自己的 agent 而且这个 agent 是具有 self-improvementself-healing 的能力能够去 understand 你的 workflow 举个例子你是在做一个广告的 campaign 你每个周可能都要放一个广告那通常来说你可以用其他的 general agent 每个周出去做一个这样的事情但在 Crew 上你的使用的方法是你 create 一个属于自己的 agent 比如说这就叫做 campaign agent 我们会在背后做很多 harness 保证你的这个 campaign agent 能够持续地提升它的 performance 能够降低它的 cost 在这个过程中为你产生更多的产出 [00:43:03]

泓君：所以你们对标的场景跟你们主要的客户是谁就是你是对标大企业里面的工作流程自动化的还是专业的类似于创业者或者个人独角兽类似于这样子的

Peter Pang：还是普通的大众其实它都会有但是我们真正的目标来讲还是那些所谓的 SMB 还有企业端的那些中小企业的场景因为这个可能是最早去 adopt AI 的这个人群 SMB 是什么

泓君：SM 就是 small to medium business 就是那些中小型的可能就是 30 个人以内的团队跟你们公司现在非常像的这些团队然后他们完全开始把自己的工作方式转移成以 AI 为主导的工作方式这种是科技公司多还是说传统公司它也可以做这个转型不管你是科技公司还是传统公司都能做这样的转型对因为它核心的难点其实并不是一定是在于

Peter Pang：取决于你的人数和规模大的企业为什么它难是因为越大的企业它会有越来越多的一些合规的问题还有很多的一些人上面的因素会导致它的整个过程会非常艰难但是你一家公司如果没有太多的所谓的合规还有包括传统的一些数据库还有传统一些 Lexi 的这些东西的话那其实你就是第一批最容易去做这个转型的公司所以我们 Target 就是这样的一批公司是我们核心的这个目标群体 [00:44:19]

泓君：一个公司想要做这样的转型是不是他们的创始人也得有一个核心信念就是相信 AI 对这个是但是我觉得更多还是他们得搞清楚就是说这个转型最后代表的是什么我举个最简单的例子

Peter Pang：其实在 23 年刚大模型出来的时候很多的 Saa S 公司他想的都是我怎么把 AI 做成一个功能集成到我的产品里面这个本质来讲是没有搞清楚如果你要做这样的功能有没有可能你原来的产品的架构就是不支持把这些最新的 AI 的能力给集成进来了因为你的数据库可能也不符合要求你的交互可能也不是未来的一个方式所以说你可能需要去做的事情是整体的产品的重构

泓君：这个结果如果是你接受不了的话那可能你也很难去做这个转型对所以你们现在在推广这个概念的过程中 [00:45:03]

对所以你们现在在推广这个概念的过程中

泓君：对所以你们现在在推广这个概念的过程中因为现在 AI 发展的也很快我觉得很多的企业主包括中小企业他们是非常愿意去拥抱 AI 的但是我觉得你们整个推行的概念呢又过于朝前所以你们自己觉得市场对你们的反馈是怎么样的其实从我们现在用户上面的反馈来讲

Peter Pang：我觉得并不是说我们的概念很超前而是这也是为什么我们从组织上的变革是我们自己在做的事情我们并没有说我们所有的客户跟我们一样去做组织上的改变而更多是我们把 Harness 这套系统变成我们的产品

泓君：能够让我们的用户先体验起来然后在这个过程里面他再慢慢去思考组织怎么去改变我觉得 Harness 还有一个核心就是说我对某一个领域非常了解所以我才能给他做各种的更精确的系统上的限定条件假设你说你对代码领域非常了解我觉得很权威但我觉得很少有人说我可以是每一个领域的专家我懂每一个领域 [00:46:01]

Clark Gao：那这个挑战怎么解决呢之前的话你在 create 一个自己的 agent 比如说你用 Hermes 或者 Open Claw 或者 Code Code 你是需要对代码有一定理解的你才能做这件事情因为这涉及到很多 infrastructure 安全性的问题包括你的 tooling 怎么接进来但是对于比如说 Crew 来说我们提供一个 Cloud 端的 service 你作为一个普通的使用者你是不需要有很多架构的理解因为我们把这个架构已经提供给用户了用户对自己需要完成的任务需要有一个深入的理解但是在这个过程之中包括怎么接入 tooling 怎么去 maintain 这个 agent 能够长时间的工作怎么能够保证安全性

Peter Pang：是我们为大家提供的这样的一个 service 对就现在因为我们还是在利用 AI 的很早期的阶段当然就是有很多的创意公司都在讨论就是说我们可能要在某一个垂直场景上会非常了解然后我们才能说我们这块 Harness 做得很好但核心是在于就是说因为我们自己的 Crow 这家公司我们也想成为第一批所谓的 AI-first 公司那所谓在组织结构调整之后其实我们是有非常多的基础工作需要被 agent 化的那在这些基础的工作上首先它可能也并不会涉及到非常多的非常垂直专业的场景比如说刚刚 Karik 说一些所谓市场调研这个事情其实很多的人都需要去做但是有些人 agent 利用的好他这个系统 build 的好的话他自己人需要做的事情就会很少但是如果你的系统 build 不够好的话你人需要做的事情就更多其实我们的概念真正我觉得超前的地方或者说市场现在没有准备好的地方是在于如果你真的想把 AI 用在你的生产的各环节上面首先你的组织结构是要先去变化的组织结构变化之后你需要有一个系统去保障这个组织能够稳定的运行这个就是我们现在 [00:47:45]

泓君：Build 这个 Harness 这套东西可不可以讲一下你们的组织结构是如何发生变化的比如说以前传统的组织结构是怎么样然后现在你们是怎么样我觉得刚刚过程中我们举了很多的案例但是我们还是想知道一个 whole picture

Peter Pang：对整个组织结构的变化我觉得就是这里面是很多角色的变化首先一如果你要真的做改造你需要做的第一个点其实是信任上的变化就原来你组织信任的是人那人本身是这个组织最核心的那一环但现在当你把 AI 拿进来之后其实你要先解决第一个问题就是你能不能信任你的 AI 做决策或去执行任务这个信任其实就跟为什么我们要去 build 一个 harness 的系统是一个道理就是我们得有很多的就所谓的 guardrails 还有机制去保障 AI 做的所有的工作不管它做决策也好还做 planning 也好还做最后的 execution 执行也好那最后它的这个东西是能够被人去信任的那接下来就是你所有的组织结构里面的具体的位置的变化产品经理这个决策在我们公司说它不存在而是它被拆解到了每一个工程师和像 Peter 这样子的做工程管理的人身上而不是专门在有一个单独的角色去做这个所谓的产品的这个事情因为产品经理这个岗位我并不觉得它不重要而是在于它在大多数公司它其实是矛盾最集中的那个点因为产品经理同时要跟市场人沟通也要跟开发人沟通所有的对齐的成本很多时候也都会发生在那个产品经理的那个角色上面但当你把这个角色给拿掉之后你会发现对齐的成本反而有时候可能会更低这个前提也是在于你需要有一套机制能保证在没有产品经理的情况下团队之间还能互相信任就决策的信任成本没有因为没有这个决策了而变得更高而是说没有这个决策之后它会变得更低所以说这个其实就是我们在组织上可能跟传统这些 [00:49:31]

泓君：所谓的软件开发公司会不太一样的地方产品经理这个角色你觉得现在还有价值吗或者说重新招一个类似于产品经理角色的人你觉得他需要有什么样的新技能这个问题应该是这样问

Peter Pang：未来需不需要产品经理他一定需要的但是未来需要的是一种新的形态的产品经理因为你的开发成本在降低所以产品经理更多的首先他本身的背景也会发生变化他做的事情可能他原来是一个工程师之后工程师也可以成为产品经理的角色那更多的人可能能够成为这种所谓的新型的产品经理或说未来还有种可能就是说他的职位的很多的权利会分散在开发团队的各个的人的身上因为如果说你的每一个开发团队成员在 AI 的帮助下都能够更好地去有产品观念的话那其实你本质来讲有没有这个职位也不太重要因为原来产品经理我觉得他更多解决的是对齐的成本 [00:50:24]

泓君：还有包括如何帮助公司去降低这个所谓的开发成本对我可不可以这样理解就是现在相当于工程师 Peter 的团队他们某种程度上扮演了产品经理的角色但是反过来一个好的产品经理他其实是对市场是非常有想法的然后对产品也是非常有想法的加上现在开发的成本是非常低的他可能也很容易就把他的一个想法通过 AI 的执行能力很快变成了一个好的产品他甚至不需要工程团队了所以说其实这两种角色他某种程度上他在融合在变成一种角色所以这个角色到底是一个技术的团队来做 [00:51:02]

Peter Pang：还是一个产品的团队来做其实不重要因为都是 AI 在主导想法更重要对因为会有人会觉得就说未来产品经理可能会变得更重要因为就像您刚刚提到如果产品经理也能写代码那他可能自己就能 build 一个产品但是一样会有人会觉得就说产品经理因为他没有很多的技术的背景那他就算能 build 一个产品那这个产品到底能不能被商业化我们要打个问号如果这个产品真的要需要被商业化的时候那可能我们还是需要有工程师真的能够帮这个产品经理去把这个产品给构建得更加能够商业化未来这个职位本身它可能不是说是一个人而是一个团队整体扮演这个产品经理的角色这个角色本身它会被组织化掉而不是被个人化掉在传统软件时代下有很多个人英雄主义就是说因为某一个产品经理或一个灵魂人物导致最后这个产品特别受欢迎但未来可能是一个组织可能做了一个很好的产品

Clark Gao：被这个市场接受对我觉得有一个非常明显的 trend 就是复合型人才或者比较 general 的人他在 AI 环境之下可以 thrive 的更好一些不管是说一个工程师他有产品的 sense 和 marketing 的 sense 还是说一个产品经理他具有 implementation 的能力都会非常的重要刚才一直在谈产品经理其实有另外一些 rule 像 designer 不管是前端的 designer 还是 UX designer 如果你问我未来的产品之中什么是最重要的可能这两个 rule 会变得非常的重要但是我们在讨论这两个 rule 的时候不是说传统的不具备 coding 或者 implementation 能力的 designer 而是具有能够把自己的想法 implement 到的产品之中的这些 UX 和 UI designer 这些人会变得非常的重要包括产品经理同样的事情未来的产品需要有产品的 sense 那这些产品的 sense 来源于谁其实并不重要但是有一点是非常重要的这个人必须具有 implementation 的能力他能把他的 idea 直接在一到两个小时之内的时间就带到产品之中如果你需要把你的 idea 传递给另外一个人或者另外一个 engineer 那你交流或 alignment 的成本就远大于你 implementation 的成本 [00:53:14]

泓君：在整个的这个 AI 的工作环境之下就变得不是那么的 efficient Peter 你有一篇文章我印象很深啊你说其实在你真的做这一系列的组织架构的变化的过程中

Clark Gao：你意识到初级的工程师是比资深的工程师更能适应 AI 的这个环境的因为初级的 engineer 不管说他的 tech debt 或者他的思想的束缚通常来说比较小他能够接受他的 expand 他的 scope 就是他不仅是作为一个 engineer 包括他要融入到一些产品的设计之中包括产品他的 feature deploy 之后他还需要做一些 analysis 他根据 analysis 能够做出他这样的一个判断但通常来讲比较 senior 的 engineer 因为他比较 specialize 比如说你是一个做 infer 的人或者你是一个做后端的人你可能在传统的工作环境之中你不 care 你的 codeship 之后发生的事情但是在 AI 这个环境之下你的 engineer 的 scope 就需要比之前扩大的很多就不只是在我把这个代码写完之后就结束了而是在于我代码写之前我怎么能够把自己的 judgement 加进去代码 ship 之后怎么能够判断它的 impact 整个的这个过程是非常重要的通常来讲 junior engineer 的话 [00:54:31]

泓君：能够更好地接受这样的一种工作状态那比如说你跟一个资深工程师说除了负责前面就是你代码已经交完了的这个过程你还要负责后面的这个过程他们是不能理解

Clark Gao：跟马上去转变这个思想的通常来讲需要 align 这个 mindset 的成本要高很多其实作为一个 senior engineer 或者作为一个专业领域的不管是做 infra 的人还是 frontend 还是 backend 的人在过去的软件开发过程之中你的 knowledge 是非常 valueable 的因为你能够知道在开发这个系统之中怎么样写最简洁的代码怎么样设计最好的 architecture 你可能需要两三个月的时间去完成这样一个事情但是在 AI 这个环境之下因为 AI coding 在现阶段它已经很强了以后会变得更强所以它会让你本身的 specialty 变得越来越低所以很多人可能接受不了这样一种状态就是他本身可能花了十年二十年时间学到的这样一些知识变得可能在未来并不那么重要 [00:55:34]

泓君：所以你们现在更倾向于找哪一类的人我拿工程师来举一个例子吧比如说初级的人他可能面临的问题是他在代码领域基础没有那么的扎实了因为大家现在都已经用 AI 写代码了可能你真的比如说这个人工智能系统它突然关机了他们自己可能就写不了了而且如果你的代码基础不扎实的话,就是你在判断它出问题的时候,你的专业知识也会稍微的差那么一点点,但是呢对于很多资深的工程师来说,他们依然非常的稀缺,就是因为他们还是有非常扎实的工程的基础, [00:56:11]

Clark Gao：但是他们可能在转变跟适应 AI 思维上,他并没有年轻人那么快。我文章中虽然提到,要转变一个资深的工程师的难度,要比一个相对来说 junior 的难度大,但是从 value 上来讲一个资深的工程师的 value 现在是不能被取代的所以怎么能够找到一个资深的工程师他还能够 embrace AI 的 mindset 而且他能够具有一个产品的 sense 他能够还知道一些 marketing 的 knowledge 这个人虽然很难找但是对于公司来说是非常 valuable 的好处是在于之前我们可能需要很多这样的人在没有 AI 的情况之下但现在来说我们可能只需要一到两个人就可以了很多是多少,十个?我觉得十倍或者五十倍以上的人在没有 AI 辅助的情况之下。 [00:57:00]

泓君：但我觉得这样的人是不是也还比较好找,是因为我最近看见硅谷的趋势是所有人都在开始用 AI,然后所有人都在开始比这个 AI 生成代码的数量,

Peter Pang：大家也在很积极地去适应这个新时代新环境。对,我们可能通常会发现有很多人是这样子的一个心态嘛,但是有这样的心态跟在工作的时候愿意去相信 AI 然后真的把所谓的 Harness 这个系统去 build 起来我相信它跟我愿意花时间去构建一个系统能帮助我更好地用 AI 去工作这是完全两码事情很多人会发现他愿意拥抱 AI 只是在于他愿意用 AI 的工具去给自己去提升效率但他并不愿意说我去构建一个系统真的能让未来我的工作完全由 AI 来驱动我在里面可能扮演角色都可能发生变化了这是两种完全不一样的心态其实后面那种更激进的心态的工程师也好或者说做 marketing 的人也好或者说做任何事情的人也好相对来讲在现在这个阶段这个思想还是相对来讲比较超前的这样的人还是少数现在更多人更接受还在于我愿意去尝试用个 AI 工具或拥抱 AI 的能力但是我还没有到真的我希望做到 AI-first 这个角度来讲这样的人是比较少的对另外从一个角度上来讲我认识的很多朋友其实他本身的能力很强 [00:58:21]

Clark Gao：他有很强的架构能力然后他源于 500 AI 但通常很多这样的人他会自己出来创业对于一个 startup 你想 hire 这种人其实现在难度还是比较大的是 Peter 你是从什么时候开始相信 AI 的就是我觉得凯今天给我特别大的一个震撼就是相信 AI 这四个字如果你问我的话我其实从一开始刚毕业的时候我就是在做 AI 所以我肯定会你是哪一年毕业的我是一我是哪一年毕业的我应该是 18 年吧你毕业我们肯定不会记得那么清楚我可能是具体我记不清了但是可能是十年之前的事情我第一个在苹果做的工作就是在做 AI 方面的工作而且也就是和语言模型相关的所以我肯定是从一开始就相信 AI 能够改变这个世界的对那个时候大模型还没出来然后那个时候我们在提到 AI 的时候 [00:59:14]

泓君：跟今天我们提到 AI 的时候是完全不一样的包括我觉得那个时候 AI 给人的这个思想上的冲击说我们是不是要把工作彻底地交给 AI 跟今天也是不一样对但是那个时候虽然没有大模型但是是非常重要的一篇 paper

Clark Gao：就是 Attention is all you need 包括之前 BERT 的出现正好是我刚开始工作的时候在那个时候我就意识到了 pre-training 的重要性包括对于我当时在苹果做的一些 traffic prediction 的一些工作我就已经开始利用 pre-training 因为之前的 pre-training 只是在文字上的 pre-training 我会在 traffic signal 上的是同样利用了类似的 concept 来做这样的事情所以可能是因为

泓君：你的工作经历的关系你一出来甚至是你还没有出来就你一直都觉得 AI 它是比人强的我没有说 AI 会一直比人强哪怕是现在这个阶段 [01:00:06]

哪怕是现在这个阶段

泓君：哪怕是现在这个阶段

Clark Gao：AI 也不能够取代人来做任何的事情但是 AI in the future 或者在现在这样一个阶段我 AI 已经能够主导很多事情包括在架构的过程之中 AI 是很强但是你让人工智能系统能够运转起来还是需要人去进行架构的对我们刚刚其实有聊未来要招什么样的人你觉得现在我们说

泓君：AI 为主力干活 AI 可以迭代产品所有的东西都是动态的大家觉得未来人它最核心的能力是什么呢我觉得最大人需要的能力就是系统架构的能力

Clark Gao：从以前 implement feature 变成怎么架构这个人工智能系统和 maintain 这个人工智能系统这是工程师的角度对不管是工程师还是 marketing 的角度那你做 go to market 怎么搭建一套能够自主运行的 agent 的

Peter Pang：marketing 系统也是核心的过程而不是说只是单纯的产生一个 marketing content 这个话就说人的价值如果从真的很长远来看就跟我们技术发展整个过程一样确定技术发展方向永远是人的需求和这个社会的需求只要人物种还存在它的价值是不太会变化它定义的是需求的方向和技术迭代的方向因为它永远要为物种去服务如果没有人在这个上面的价值的话那就代表 AI 是自己在发展它自己就是一个物种了这个是一个哲学问题至于我定义了需求我一样就会需要去看最后的结果是不是我想要的所以在未来系统里面人还有一个很重要的价值是我 review 最后的结果去看这个结果是不是真的符合我们的利益或符合我们的要求人在需求的定义和最终的结果的审核上的价值是没有办法被取代的除非说人作为这个物种 [01:01:52]

泓君：本身的重要性已经不存在了那这个是另外一回事情对我看最近应该是 Deep Mind 他们已经开始设立哲学家的岗位了对职位就叫哲学家对对对是当然这里面有非常多的问题 [01:02:06]

Peter Pang：包括如果我们真的把 AI 引进到 agent 真的能替代人工作那还有一个道德问题是在于那 agent 和其他的 agent 也好其他人之间也好也会有沟通那他沟通的这些内容到底比如说我作为另外一个人能不能去看那是不是侵犯他的隐私呢这里面其实会有非常多道德问题它都是跟未来组织这些关系都相关的嘛好 Clark 我觉得其实刚刚凯讲的挺好的因为我自己觉得人未来的价值就是判断任何事情

程凯：是否还有价值对于价值的定义可能就是人最大的价值价值的定义本身延伸出来的东西就是我们怎么样定义自己的需求是什么当我们知道自己想要什么的时候才能判断这件事情是否有价值

泓君：我觉得这个就是人的价值对你们对未来整体是更悲观还是更乐观我是说完全抛开企业就是作为人来说我自己还是相对乐观的吧

程凯：其实很多时候大家探讨就是人他为什么快乐我自己现在工作还挺快乐就是因为我虽然在工作中跟 AI 的配合会导致我的工作的内容和工作的程度会比之前要强很多但是当我不工作的时候我在享受自然爬山也好还是去做一些户外运动的时候也好我可能会更加的放松所以我觉得相对来说是比较乐观就是可能 AI 给我们带来的价值就是我们原来就经常说你 work hard play hard 它可能可以反而更好地帮我去做工作和生活上的切割 [01:03:36]

Peter Pang：我们做创业的话我们肯定是乐观的如果悲观的话大家今天也不会出来创业了对未来肯定还是相对来讲比较乐观的但是就像我们刚刚聊的就是因为就跟上一次工业革命一样就是当时有很多的纺织工人也好车夫也好可能都被取代掉了但是随着那个阶段过去之后人会找到新的方向去实现更大的一个自我价值所以说未来的话它一定是一个更好的世界这个世界是不是跟现在大家所定义的幸福一样那可能是不一样的这个可能是可能未来会有的一个比较大的变化我觉得我还是非常谨慎的乐观的因为我觉得在这个变革的过程之中 [01:04:12]

Clark Gao：会有很多痛苦会有很多 noise 但是这个变革的结果我还是 believe in 它是一个好的结果就是人能够更多的有不管说自由的时间还是能够发挥出自己更大的价值