泓君
过去3年，我们经历了大模型工程能力的3次概念上的进化。大家还记得，2023年模型刚刚出来的时候，我们都在聊 prompt engineering，核心是怎么样写好一个提示词，让模型给出更好的答案。后来到了2024年，焦点变成了 context engineering，也就是怎么给模型提供更完整的上下文，让它能够理解更加复杂的任务。
到了2026年，一个新的词开始在硅谷流行起来，叫做 harness engineering。Harness 在英文里原本是“挽具”，是套在马身上、用来引导和约束马的那套装备。现在，它被用来形容一件事：怎么样围绕大模型搭建一套系统，让它能够在真实世界中持续工作、自我修复，还能自我提升。
最近，Creo 的 CTO Peter 在 Twitter 上写了一篇文章，叫《为什么你的 AI 优先战略可能错了》，引发了几百万的关注与讨论。他的核心结论是，大多数公司所谓的 AI first 都是假的。真正的 AI 优先战略，是重新设计整个公司的流程和组织结构，本质上也是公司内部怎么样 harness AI 的过程。
Peter 之前是 Meta Llama 基础模型团队的研究科学家，后来在苹果从事多模态模型相关工作，所以他的工作语言是英文。如果本期内容中英文夹杂过多，欢迎大家收看我们播客的字幕版。
今天除了 Peter，我们还把 Creo 的另外两位创始人，也是这个故事的亲历者邀请到了节目上，来聊一聊他们是怎么在 AI 快速进化的一年里重新组织自己的组织架构，把信任人变成信任 AI。首先请今天的3位嘉宾简单介绍一下自己。
Peter
大家好，我是 Peter，Creo 的 co-founder and CTO。
陈凯
大家好，我是 Creo 的 CEO and co-founder，陈凯。
Clark
大家好，我是 Clark，Creo 的 co-founder，现在主要负责我们的 go-to-market。之前做了很多年的 data scientist 和 machine learning engineer，现在在 agent 领域里，和凯、Peter 一起帮助用户更好地使用 agent，达到 AI first 这样一种组织形态。
泓君
好的，欢迎3位。我们直接进入主题。最近大家都在关注 harness engineering，Peter，你要不要先跟我们介绍一下什么是 harness engineering？
1. Harness工程开始进化
Peter
Harness 这个概念其实可以追溯到大模型刚开始的时候。很多人在聊 prompt engineering，之后演变到 context engineering，再到现在的 harness。
整个 harness 过程不仅仅是对于 LLM 本身的 harness，还包括围绕整个大模型的基础设施、tooling 的使用，以及安全性的保证。对整个系统进行持续改进的过程，我们把它叫作 harness。
泓君
可不可以跟听众解释一下，这3次进化是怎么发生的？每一步最重要的是什么？
Peter
我先说一下 prompt engineering 和 context engineering。它们更多 focus 在怎么和 LLM 这个大模型本身进行交互：我怎么优化它的 context，怎么优化它的 prompt。从这个角度上来讲，它们的 scope 要比现在讲的 harness 小得多。
从静态和动态的角度上来讲，prompt engineering 和 context engineering 相对来说是一个静态的事情。因为你优化的是一个大模型，你优化的任务可能也是一个相对比较垂直的任务。
但是对于 harness 来讲，它是一个系统的 harness。对我们来说，我们是在 harness 一个 general 的系统，所以从 scope 上来讲，会比 prompt 和 context engineering 大很多。因为这涉及 tooling 的使用、sandbox 的架构设计、sandbox 和 host service 之间怎么交互，怎么样的交互能够保证安全，sandbox 的启动时间是多少，latency 是多少，这些都是 harness 的一部分。
泓君
我可不可以理解成，harness 的工程能力决定了你怎么样把一个大模型“榨出”它的最佳使用上限，它可以理解成 AI 的一种工程能力？
举个例子，我记得凯之前在一篇融资新闻稿里面提到过，一个 agent 可以一夜之间干掉3个人做 SEO 的工作流。同时，还有一个 content pipeline，跑了2天才有人发现全是垃圾。这两者之间的巨大区别，就是一个非常好的表现和一个非常差的表现。
可不可以理解成，从本质上说，一个是 harness 的胜利，一个是 harness 的失败？
陈凯
2. 系统学会自我修复
对。刚才提到了两种状态，一种是效果好，一种是效果不好。但我觉得，这完全印证了为什么我们需要 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。
因为它工作时间长，tooling 使用的数量多，context 也多，所以如果 harness 做得不好，就很容易产生 hallucination，或者出现 context overflow，模型的能力也会 degrade。
所以在这个过程中，怎么把 harness 做好，其实是一件非常复杂、而且需要经验的事情。
泓君
3. Harness超越传统工程
换句话说，harness 是一个新概念，但它所谓的新，其实是把传统软件工程的东西放到了 agent 应用上。大家怎么看 harness 里面有哪些是我们这个时代的新东西，是传统工程里没有的？
大多数业务人员可能都是从能力层面去理解软件。很多人从传统角度来讲不理解：其实一个很简单的功能，在以前可能都需要开发团队花2到3个月才能实现。业务人员经常会说：“我觉得这个功能很简单，为什么你们的产品一直解决不了我的问题？”
其实是因为后面有太多工程化的问题牵扯在里面。对于 agent 来讲也是一样的。很多人会觉得 LLM 的能力提升了，但为什么它还是做不到我想做的事情？因为还有很多工程化的问题需要一起解决。这也是我们去做 harness 的一个原因。
你觉得今天市场在讨论 harness 的时候，有哪些是大家的共识，哪些是非共识？因为我觉得不同群体对 harness 的认知可能不一样。
Peter
我听到的很多看法，通常来讲是把 harness 当作一个静态的过程：我怎么 develop 一套系统，把 LLM 的优势更大地发挥出来。
而对于我们来讲，我们认知中的 harness 是一个动态的过程。这个系统怎么能够从一个静态的状态真正活起来，能够 self-improve，能够不停地 adapt 新的 signal？不管是 marketing 的 signal、产品本身的 signal，还是用户的 signal，都能够让它不停地迅速迭代。我觉得这可能是很多人还没有意识到的一点。
而且这个迭代是以 AI 为主导的，而不是人为主导的。
陈凯
对，是以 AI 为主导的迭代。但人需要做的事情，是怎么把各种各样的 signal feed 给 AI。不管是 marketing 的 signal、产品的 signal，还是 infrastructure 自己的 signal。
泓君
4. Creo重构开发流程
我注意到最近你有一篇 Twitter 帖子非常火，讲的是你们怎么用一家25个人的公司，做到99%的代码都是 AI 来写的。基本上是早上10点写了一个功能，中午就进行了 A/B test，下午3点根据数据反馈砍掉一部分功能，5点又重写了一个更好的版本。
这只用了一天时间，但在传统开发产品的过程中，可能需要6周。你的帖子在 Twitter 上非常火，到现在有187万的浏览量，下面也有很多共鸣。
但仔细看下来，我觉得你讲的其实就是 Creo 在整个工作流程中使用 harness 的方式，也算是你自己独立探索出来的一条 harness 路径。
Peter
这牵扯到 harness 的一个具体细分层级。在 Creo，harness 分成两个主要部分。
一个是对于 Creo 本身的 agent 系统进行 harness；另外一个是用户使用 Creo、构建自己的 agent 时，怎么 harness 自己的 agent。
在传统开发过程中，可能需要2到3个月的时间迭代一个 feature。但在 agent 的情况下，很多东西都是 AI 辅助 coding，本身 implement 一个 feature 可能只需要1到2个小时。
所以如果我们还花很长时间去 design、去 testing，就不是很 make sense。我们怎么把 design、planning 阶段和 testing 阶段纳入整个 harness 过程，对于一家公司能不能真正转型成为 AI first 公司，是非常 critical 的。
陈凯
5. AI First重塑组织
我想先跟大家表达一个观点：如果想做到所谓的 AI first 或者 AI native，它并不是在现有流程上使用 AI 工具，而是要围绕 AI 的能力，重新构建工作流程和组织形态。
Peter 刚才描述的就是这一点。之前很长一段时间里，每个工程师都在用 AI 写代码，每个产品经理都在用 AI 写 PRD，每个设计师都在用 AI 做图。但这样并没有增加我们的效率，反而导致每个人的工作进度和节奏不一样，alignment 的成本变得非常高。
因为我们本身是一个完全 remote 办公的团队，所以我们必须重新思考：怎么样才能让 AI 在整个公司的运营过程中真正自动化地跑起来。
所以 Peter 设计了一套新的开发流程，也对我们的产品架构进行了重构，才有了他那篇文章里所讲的 self-healing agent harness，或者说 engineering harness。
泓君
你们能不能举一个例子？你们在重塑开发流程和组织架构、开始用 AI 自己写 agent 的过程中，哪些方向发生了变化？瓶颈在哪些方向？哪些地方和你们预期的不一样？
Peter
在推进 harness 和 AI first 的过程中，首先需要解决的是人的问题：大家能不能接受新的工作方式。所以我们也花了很长时间去 align 大家的 mindset。我觉得 mindset 的 alignment 是最重要的。
以前如果要做这样的转型，需要很长时间，因为人需要去搭建这个系统。通常一个 architect 或者 engineer 需要几个月的时间，去 demonstrate 新的工作方式比之前更好。但这个转型的 cost 相对来说非常大。
在 AI 辅助的情况下，我们 demonstrate 新工作方式的速度会快很多。可能只需要1到2周，就能把整个系统重构，包括前端、后端、architecture、infrastructure，然后向大家 demonstrate 这个新的流程是更 efficient 的。
不管是 deployment 频率、deployment reliability，还是最后的效果，都能够比之前的工作方式有很大提升。这样我们就能在很短的时间内完成 mindset 的 alignment。大家一旦 on board 到这个工作方式里，就能更快地融入整个开发过程。
陈凯
本质上，它更多是在 build 一个系统，真正让 Peter 刚才说的 AI first 组织结构能够高效运转起来，这一点非常重要。
很多组织里的人很难改变思维。他会觉得：“我可以用 AI 来提升自己的效率。”但 AI first 要求的是：让 AI drive 整个公司的方向，甚至你每天工作的方式都由 AI 来 drive。这是完全不一样的概念。
泓君
举个例子，是每次都由 AI 给你们布置任务吗？
陈凯
原来大家可能都觉得，是人提出一个概念，再由 AI 帮助人提升效率。但如果人还是工具的使用者，那效率提升可能有一个倍数的上限，最多可能是10倍，因为人每天最多工作24小时。
如果真的希望 AI 把工作效率提升100倍、1000倍，你就不能还是工具的使用者，而应该让 AI 成为所有生产力的主导。人的角色会发生变化，更多是在看最后的结果好不好，review 结果的好坏。
我在这个系统里并不是实际的工作者。那么在这样的角度下，我应该用什么方式和这个系统配合？这其实是很多企业在转型时没有意识到，或者很难做到的一件事。
泓君
能不能举一个例子，你们的系统怎么和人配合工作？比如说由系统给人发任务。
传统团队开发产品时，很大的痛点是团队之间要对齐，要把信息同步给每个人。任何一个人如果 miss 掉一个信息点，他在开发产品时可能就不知道上一版更新了什么。现在这些工作是不是都可以交给 AI，或者在流程中自动完成？
陈凯
6. AI接管团队对齐
这里面的核心还是信任问题。很多时候，人不信任这个系统，所以对齐成本才会非常高。
比如 Clark 的 go-to-market team 和 Peter 的 engineering team，原来需要相互沟通、达成共识、完成对齐之后，事情才能继续推进。
但如果是 AI first 的组织结构，就没有传统意义上的对齐过程，而更多是由 AI 主导对齐。比如 AI 告诉 marketing team，今天 engineering team 要发布哪些功能，这些功能的具体结构是什么。
Marketing 就不用再去和 engineering 沟通：“你明天要发布什么功能？后天要发布什么功能？”这样中间的对齐成本就降低了。
泓君
AI 怎么知道 Peter 的 engineering team 明天能把所有工作做完？
陈凯
这个可以让 Peter 来说。
Peter
在整个 harness 或者 AI 主导的工作流中，大家体会到的 improvement，主要是开发速度和迭代速度的提升。
通常 implement 一个 feature 或者 deploy 一个新产品，需要很长周期，所以大家需要详细讨论。但在 AI mindset 下，因为迭代产品的速度非常快，我们更侧重的是：这个新的 feature 能不能提升产品的 top-line metrics，或者有没有真实的用户使用数据。
所以更核心的 focus，是怎么把整个数据链搭建起来。这个链条搭建起来之后，由 agent 通过这些数据决定这个 feature 到底有没有用，以及我们要不要 rule out 这个 feature，或者 fallback 这个 feature。
泓君
也就是说，工程师写完代码以后，不需要手动跟 AI 或者某个工程管理界面同步：“我写完了。”这是传统软件和公司内部系统同步的一种方式。现在 AI 可以根据代码质量和整个进程，自动做出判断？
Peter
传统 engineering 中也有这个流程，我们叫 CI/CD process。只不过传统 CI/CD process 很多都是 rule-based，或者由 unit testing 驱动。
在 AI 的情况下，我们可以有很多 AI-driven testing，不管是 integration test 还是 unit test。现在大家比较常用的 Playwright，就可以做 AI-driven、fully end-to-end 的 testing，保证 shipped 的代码没有明显的、会 break 产品的 bug。
另外，代码 ship 之后，log 里面有没有 error、有没有 incidents，也都可以通过这些 signal feedback 给 AI，让它判断整个代码的质量。
泓君
Clark，比如说你在做市场营销时，知道工程团队已经写完代码了。但很多时候，一个产品要传递的核心理念是什么、要向市场传递的关键信息是什么，往往需要一个产品的灵魂人物，不管是 CEO、CTO 还是产品经理，来进行沟通和梳理。
这件事 AI 能做吗？
Clark
这个问题问得非常一针见血。我们现在也花了很多时间思考这个问题，因为实行这套新的开发机制已经有几个月了。
我自己的体会是，现在我们确实不需要再和 engineer 过多沟通“你要做什么 feature、什么时候能 deliver”，因为 feature 的数量已经远远超过了我们的销售能力。
这是我最大的体会：现在开发速度远远超过了市场的进度。这样有一个好处，就是我们不再需要讨论“今天公司的 product roadmap 是什么”，而只需要讨论市场需求在哪里。
我们好像有一个菜篮子，或者像机器猫的万能宝箱。如果今天市场需求是苹果，我们就从篮子里挑一个苹果去卖；如果市场需求是香蕉，就挑一个香蕉去卖。
这反而大大降低了我们过去那种“市场反应是这样，所以要重新思考做什么产品”的讨论成本，比过去省时省力很多。
泓君
我理解了。相当于你们的开发能力远远快于市场能力，所以当市场出现新的风向时，你们可以从已经搭建好的产品库里，找到一个点去做营销。
是的，是这样的。
泓君
7. AI自动修复代码
有意思。关于让 AI 写代码，我还有一个核心问题：怎么保证它的质量？
Peter，你在 Twitter 那篇文章里写到，正常情况下写代码可能需要1天，大家修 bug 要3天。现在加入了哪些新的手段，可以让大家不用把大量时间花在修复上？
Peter
Bug 是整个 engineering 中不可避免的事情。不管是 AI 写代码，还是人写代码，都会产生 bug。
Harness 不是一个静止的状态，不是说我现在有一个系统，只需要维护它，这个系统就不会有 bug，也不需要提升。Harness 的核心在于，我能不能找到系统中的 bug。
刚才聊到的 CI/CD 过程中，在 integration 和 testing 阶段，我们会有一系列 regression test，避免一些 bug 被 ship 到 production、break 这个系统。这是第一步。
第二步是，即便有一些 corner case 或 risk condition 被 ship 到系统中，我们怎么能够在最快的时间 identify 这些 bug，并及时 fix？这就是第二步。
传统情况下，这两步都是由人 driven 的。但在 agent harness 的情况下，会由 agent 系统 driven。我们开发了 agent-driven 的 CI/CD 系统和 agent-driven 的 bug triage 系统，它会根据系统中的 issue triage 这个 issue，再 assign 给 engineer，让他们 fix 这些 bug。
泓君
你觉得引入这两套系统以后，效率提升了多少？
Peter
首先，因为很多事情都是 agent-driven 的，所以可以 parallel 进行。可以有很多 agent 去 identify bug：有的 agent 专门负责前端 bug，有的负责后端 bug，有的负责 agent 核心系统的 bug。
发现一个 bug 可能只需要1到2分钟，把 bug assign 给一个 engineer 可能只需要几秒钟。Engineer 拿到 task 之后，也会使用 agent 去 investigate、提出 solution。所以整个 cycle 加起来，可能也就是1到2个小时。
相比之下，之前 identify 一个 bug、fix 一个 bug，再把它 ship 回系统，可能需要1周时间。
陈凯
这里面有一个特别有意思的现象。以前所谓的产研，也就是产品和研发结合，公司里通常有一个 feature wish list，里面列着大家希望做什么 feature，那个 list 很长；同时还有一个 bug list，里面有很多需要修复的 bug。
以前总是在争论，到底应该先修 bug，还是先做 feature。市场、产品和工程师一直讨论来讨论去。
现在这两个 list 都没有了。Bug 能够被及时发现、及时修复，而 feature 的数量又远远超过了我们实际需要的数量。
我们现在有一个 auto-fixing 系统。它会根据需要修复的代码所在文件夹来决定怎么处理，因为有些文件夹是敏感的，有些文件夹的 risk 相对较小。
如果需要修复的内容只存在于 risk 较小的文件夹里，AI 会自动提交 PR，可能只需要一个 engineer 简单 approve 一下，就能马上 ship 到 production。
现在可能有50%以上的 issue 是通过 auto-fixing 处理的。人在里面的参与，可能只是简单 approve 这个 fix。
如果 fixing touch 到一些比较 sensitive 的文件，比如涉及安全性或 agent behavior，我们可能需要专门负责这个领域的人进行更深入的 review。但整个过程相比之前仍然有很大提升。
泓君
有什么奇怪的 agent behavior 吗？
Peter
Agent behavior 可以拆成很多方面，比如 cost 太高、latency 太高、出现 hallucination，或者它使用 tooling 时和 tool 之间的 authentication 交互有问题。
这些都涉及 agent behavior。系统中的任何一个问题，都可能导致用户在使用 agent 时无法完成 task。所以 agent 仍然是一个比较 complicated 的 engineering system。
泓君
简单来说，现在 agent 还没有价值观的问题，主要还是效率问题，以及你灌输给它的那套思想。比如同样的任务，是不是要用更便宜的 cost 完成，主要是效率方面的问题？
Peter
主要还是效率，以及能不能完成用户 task。我们 focus 的是，怎么把系统优化到在最低 cost 的情况下，reliable 地完成用户的 task。
泓君
比如系统出现一个 bug，假设我在改一篇稿子，即使只出现一个小错误，我可能也需要把整篇稿子看一遍，然后再去找错误在哪里、怎么修改。
这个时间其实就和我自己重新写、重新熟悉这个领域的时间差不多。因为我不太懂写代码，只能用写文章来做比喻。
对应到开发领域，如果 agent 帮你搭了一个很好的技术框架，但在架构层或者基础层出现了一个大错误，当然会有很多其他 agent 去修复。但会不会出现这样的情况：有些错误大到需要工程师解决，而工程师解决时不能只看这一个点，必须先看整个系统的构成，才能解决这个细分问题？那他是不是同样需要花时间把整个系统重新学一遍？
8. 从修复错误到修复系统
Peter
这个问题很好。所以在我之前的文章中，我也讨论了 AI 环境下的工程团队可能分成两种人：一种是 architect，一种是 operator。
Architect 在整个系统搭建过程中的作用非常重要。比如在搭建 Creo 系统时，整个 agent 的 architecture 是什么样的，sandbox 和 host 之间如何交互，都是由 architect 决定的。
如果 agent 直接通过 AI coding 或者 web coding 的方式工作，通常会给你一个 solution，但这个 solution 可能会有安全隐患或者 latency 隐患。怎么优化整个系统，还是由 architect 决定。
但区别在于，传统情况下搭建 agent 的团队可能需要10到20个人；现在搭建这样一个系统，只需要一个 architect，在1周时间内就能完成。
泓君
你现在就是那个 architect？
Peter
从一开始 develop 这个系统时，确实需要我来 architect 整个系统，向团队 demonstrate 这个 architecture 比之前更优化、效率更高、cost 更低。
陈凯
我补充一下 Peter 刚才说的内容。
第一，我觉得 AI 的能力在很早以前就已经很强了，但它为什么没有达到人们预期的“AI 可以替我干活”？如果它没干好，我还得帮它弥补错误。
我觉得 harness 在这个过程中发挥价值的地方，主要在于一个概念上的转变：我们要把 AI 当作一个系统来看待，不要把它当作一个智能来看待。
虽然系统是由智能驱动的，但这里有一个核心差距：当 AI 或者说这个系统发生错误时，我们不要想着怎么纠正这个智能，而要想着怎么弥补这个系统。
这就是我们做 harness 和现在普遍认知最不一样的地方。它是一个动态改变和提升的过程，并不是一个静态的、固定的枷锁，去束缚这个智能，而是要给它提供空间，让它能够成长。
这种成长就像养一个孩子：你怎么样让它在规则内不断变得更好？我们做 harness，其实是在给用户提供一个培训师，去帮助用户理解在发现错误之后应该怎么办。
回答刚才的问题，如果你在写作时发现有一个巨大的问题，我觉得你应该花更多时间去思考这个系统上有没有漏洞，而不是花更多时间去改正某一个具体错误。
这里面还有一个更加极端的想法：你今天发布的内容，或者我们自己发布的内容，未来的受众可能并不一定是人。
这个错误对于人来说可能是一个致命错误，但未来如果都是 AI 在读文章，或者 AI 在读我们的图片和视频，对它们来说可能并不是一个致命错误。
所以大家在这个过程中要思考的是：我今天做的工作，未来到底是谁来消费？根据消费者的偏好去调整 harness 系统，才能更好地 deliver 你希望提供的价值。
泓君
这个观点非常有意思。以前出现问题时，大家会说：“我们解决问题。”现在说的是：“我们解决搭建环境中的系统问题”，而不是解决一个单一的问题，彻底修复它，以后永远不要再出现。
陈凯
与其说是彻底修复它，不如说我们重新思考：它是否还是一个问题。
我们平常会生产一些 go-to-market asset，比如图片。我们觉得从人的审美来看，它可能不是一个很好的 asset，但实际上把它投向市场时，你会发现，可能读这篇文章或者看这张图片的是一个 agent，它反馈回来的数据反而更好。
如果我们只是说“人觉得这个东西不够好，所以要修复”，那其实是在修复人对于这个东西的主观价值判断。但我们需要重新思考的，是整个系统，不管是我们自己的系统还是别人的系统，对于这件事的价值判断是不是出现了偏差。
泓君
为什么会是 agent 在读营销图片？你们的广告是针对谁的，是针对 agent 还是针对人？
陈凯
现在大家比较感兴趣的一个话题是，未来会不会出现 agent economy。可能买东西是由 agent 去买，订报纸是由 agent 去订，订牛奶也是由 agent 去订。
那你的广告是发给 agent 看，还是发给人看？我现在自己看很多文章、很多视频，也会让 agent 先去看。所以你要搞清楚，你的内容到底被谁消费，你的工作结果到底被谁消费。
针对这个消费者的价值，我们再思考到底是要提升系统，还是回到最原始的状态，让人参与到创作过程中，去弥补一些错误。
泓君
我相信未来在 agent 帮大家做更多购买决策时，最终可能还是 agent 看得更多。但我没有想到，在现阶段，包括你们现在测试的流量中，agent 已经占到了这么大的比例，来得比我预期快很多。
Clark
是的。我最近有几个亲身经历。
我最近在看有哪些公司能帮我们做合规，比如 SOC 2、ISO 这些认证。我肯定会先让 agent 帮我 research 一遍，然后基于它的结果，再看适不适合我们。
你会发现，第一步已经是 agent 在帮你做筛选了。那么，那些内容是不是应该更偏向 agent，而不是偏向人？
当然，我点进去看某些内容时，还是可能需要面向人，因为人一直会消费内容。但有可能 agent 会把第二层甚至第三层也做掉，这些事情都有可能发生。
Peter
从另外一个角度，也可以很明显地看到现在 SaaS 产品的转型。
以前很多 SaaS 产品，尤其是 Asana、Linear 这样的 task management 产品，需要一个 dashboard。过去主要是人去看这些 dashboard、管理这些 dashboard。
但至少在现阶段，我们团队使用 task management 时，更关心的是 agent 能不能更好地看这些 task、prioritize 这些 task。
所以，与其让人去看或者使用 dashboard，我们更关注这些 task management 产品有没有更好的 MCP 和 API，能不能提供给 agent 使用。
陈凯
刚才提到的这个问题，也是很多公司做 AI 转型时首先会考虑的问题。
他们可能会看到员工或者管理层觉得：“如果我使用 AI 之后还要 review 一遍，那和我自己做相比，不管时间还是成本，可能没有太大差别。”
但就像 Peter 说的，如果你真的能把这样的 AI 系统构建起来，仔细算一下，就会发现时间和成本都会有很大提升。
只是这个过程需要整个团队有一个共同目标：今天就是要把公司的组织结构、工作方式都改变。如果有一些人觉得做很多事情还不如人去做，这个改造过程就会被拉长，也会变得不顺利。
这其实是大多数公司都会面临的组织挑战。
泓君
9. Creo全面转向AI First
你们是第一天就采用这种 AI first 的工作方式，还是因为公司已经成立一年多了，而这一年多又是整个行业变化最快的阶段，所以在后面慢慢摸索出这样一套工作方式？
陈凯
我们整个公司也是有一个过程的。
在2025年上半年，大家可能还会觉得 AI 是辅助人做事情的，人仍然在整个工作中占主导地位。但到了下半年，我们意识到，如果还是这样，企业效率的提升会非常有限。
我们也用了这种方式，但发现效率并没有提升到想象中那么多。后来我们发现，核心问题在于，我们还没有把生产力工具的使用者真正从人转变成 AI。
如果这个过程没有彻底改造，可能还不如人自己做更高效。所以这需要一个过程。
刚才 Clark 和 Peter 也提到，不只是技术团队内部有挑战，marketing 团队和开发团队在对齐时，也需要一个理解过程。因为这个理解过程，我们会浪费一些时间。
比如市场团队和 engineer 团队，有很长一段时间，甚至可能1到2个月，都在反复探讨怎样用更好的方式工作。这就是组织的进化，它需要一个过程，不可能从第一天开始就变成现在这样。
这也和整个 AI 能力相关。
过去一年里，AI 从辅助 engineer 的角色，变成参与开发过程中的角色，再到现在能够相对主导开发过程的角色，这和基础模型能力、agent 架构以及 agent infrastructure 的提升都相关。
比如1年前，如果要让 AI 主导整个开发过程，我觉得从技术上来说是不成立的。但当 AI reach 到这个 point 后，我们发现整个重构不管从速度还是效果上，都远远超过了1年前能够想象的程度。
泓君
你们是从哪个时间点开始重构的？重构时整个市场发生了什么？你们做的最核心的几件事情是什么？
陈凯
我们意识到需要重构，可能是去年8、9月份。之前我们花了一些时间进行团队 alignment。Engineer、产品团队和 marketing 团队的 mindset 是最重要的，所以我们花最多时间做的，就是让大家转变 mindset。
我们真正开始重构代码架构、重构整个开发流程，大概是在今年1月份，也就是春节之前。我们用了大概2周时间，重构了所有架构，包括现在大家看到的产品，也是根据那个阶段重构出来的。
泓君
有哪些以前 AI 解决不了、现在 AI 解决了的事情？可以举两个例子吗？
Peter
以前 AI 解决不了的事情，主要是在 planning 阶段。
如果以100分为满分，它可能给我一个90分的 plan。我看到这个 plan 后，可以提出一些 criticism，它就能给我一个 revised plan，而不需要我亲自去改。
如果现在这个 plan 能打90分，1年前可能只能打50分，是一个不及格的状态。我可能需要人为 modify 这个 plan，再去改整个架构。
但现在，比如针对我们这个新架构，我可以一行 code 都不写，一行 text 都不改。我只是和它交流，critique 它的 plan 有没有缺陷、是不是足够优化。
我还可以要求它在 create plan 时 reference 其他 popular 的 open-source framework 和 agent framework，最后给我一个版本。
泓君
你觉得它的能力在你之上吗？
Peter
AI 写代码的能力肯定在我之上，因为我没有写 planning 的能力。2026年我已经没有写过一行代码。
但从 planning 能力上来讲，作为一个 architect，或者作为公司里的 CTO、tech lead，价值就在于找到 AI planning 的缺陷。所以 architect 和 tech lead 在这件事上仍然有价值。
现在 AI 的 planning 还是有缺陷的。它一开始给我的 planning 可能有 security 缺陷，也可能有 latency 缺陷。我需要根据过去的 architecture 经验去 critique、challenge 它，进一步提升方案。
泓君
你们1月份开始转型，到现在你觉得 AI 在做 planning 时，如果你告诉它要怎么处理 latency 和安全性，它现在做新的计划时会好很多吗？
Peter
我觉得这就是 harness 的核心。
以前我告诉它，在安全性上、在设计 sandbox 和 host 的关系时，要 follow 什么样的准则。现在我可以把这些准则变成一个 skill。
下一次只需要 reference 这个 skill，不需要我再去描述具体内容。我只要说：“你能不能 follow my principle？”这件事就变得很容易。
而且不只是我自己能够 challenge AI，团队里所有其他 engineer 也可以 reference 这个 skill，检查 AI 的 plan 能不能 follow 之前的 principle。
泓君
可不可以给听众一个直观的印象？现在有 AI 作为生产主力之后，它干出了多少员工才能干到的事情？
比如以前一个团队需要20个人做4周，现在多长时间能做到？
Peter
如果回到1年前，在不是 AI 主导的情况下，要 develop 像 Creo 现在这样的产品，至少需要一个100人左右的团队，花4到5个月 develop 一个版本。大家看其他这一代公司的 company size，大概也是这个范围。
现在我们是25个人，engineer 团队不到10个人。从产品第一个阶段的 deployment 来看，大概只花了2周时间。
泓君
2周时间，不到10个人？
对。
泓君
这个效率提升很高。
陈凯
从创业公司，或者很多 SaaS 公司运营 SaaS 产品的角度来看，你会有一个很直观的感受。
在传统软件时代，销售团队从概念上通常会领先于产品4到5个月。大多数用户看到的，可能是产品4到5个月之后才会发布的功能。
但现在反过来了。Clark 的 marketing 团队会觉得：“我们有很多很多功能，甚至都不知道它们已经做完了。”技术团队可能领先 marketing 团队3到4个月，甚至4到5个月。
更多时候变成 marketing 团队在追赶开发团队的功能和安排。这是从最外层看，最大的区别。
这个区别会导致整个运营方式、组织结构都和原来不一样。
泓君
凯也提到，现在技术开发速度大于市场营销速度。Clark，你们市场营销这一块也会使用更多 agent。代码 agent 这两年特别火，在 marketing 素材生成、素材产出，或者其他流程上，你觉得 agent 现在发展怎么样？
10. AI First进入市场
Clark
我们整个 go-to-market 都会用自己公司的产品，去构建 AI first go-to-market 的 workflow。
当然，这里面有很多坑。我觉得最大的困惑是，engineering 是一个相对容易做 evaluation、相对封闭的环境，能够有明确指标判断今天做得好不好。
但从 go-to-market 的角度，不管是写文章还是做视频，面对的是人的消费群体。人对于价值的认可，以及不同人群对于价值的判断，都相对比较主观。
我们怎么样构建一个系统，把这些主观判断更好地变成一种 signal，让系统能够自动运转起来，这是一个很大的挑战。
我们现在也不是100%让 agent 去做决策，而是先放很多 agent 的结果，再由人判断这个结果好不好。
我们有很多 feature，但如果市场还没有 ready，就不会把这些东西放到市场上。
泓君
我很好奇，你们有哪些超前的思想是市场还没有接受的？
Clark
每个人的 agent 都拥有全部权限，可以读写所有数据，这是一个相对大胆的动作。
我们希望未来为了让组织更加高效，很多数据应该开放给 agent，开放给每一个人。但这还需要更好的技术支持，包括怎么样限制每个人的权限，或者限制 agent 的权限；怎么样让 agent 在读取数据时不出错。
如果它读到的数据是错的，或者开始乱搞，最后的决策可能会受到很大影响。所以我觉得这件事还没有 ready 推向市场，但至少我们自己用起来很爽。
比如以前我要问 Peter：“今天有多少用户出现了这样的行为？”可能还要去找数据同学或者 engineer，帮我搭一个新的表格。但现在我只需要对 agent 提出这个问题，它3秒钟之后就能给我答复。
Peter
现在对于大部分 agent 公司来说，主要 challenge 不是市场能不能接受这种工作方式，而是市场不知道这种工作方式的存在，也不知道怎么高效使用 agent 帮助自己完成工作。
所以 Creo 在这个过程中也做了很多工作，让用户不用进行复杂设置，就能更容易 access agent，帮助完成自己的工作。
泓君
这是不是也是你们公司现在在做的事情：让 AI 自己去创建 agent？
Peter
我把上一个时代的 general agent 理解成：这些公司提供一个 agent，用户使用这个 agent 帮助自己完成工作。
但这个 agent 不管叫 general agent 还是 super agent，都是一个 unique agent，所有用户 access 的都是同一个 agent。
Creo 在做的事情，是让用户在系统上搭建属于自己的 agent。这个 agent 具有 self-improvement、self-healing 的能力，能够 understand 你的 workflow。
举个例子，你在做一个广告 campaign，每周可能都要投放一次广告。通常你可以使用其他 general agent，每周出去做一次这样的事情。
但在 Creo 上，你的使用方法是 create 一个属于自己的 agent，比如叫 campaign agent。我们会在背后做很多 harness，保证这个 campaign agent 能够持续提升 performance、降低 cost，在这个过程中为你产生更多产出。
泓君
所以你们对标的场景和主要客户是谁？
你们是对标大企业里的工作流程自动化，还是专业创业者、个人独角兽，或者普通大众？
陈凯
其实都会有。但我们真正的目标，还是所谓的 SMB 和企业端的中小企业场景，因为这可能是最早 adopt AI 的人群。
泓君
SMB 是什么？
陈凯
SMB 是 Small to Medium Business，也就是中小型企业，可能是30个人以内的团队，和现在的 Creo 很像。这些团队会完全开始把自己的工作方式转移成 AI 主导的工作方式。
泓君
这种是科技公司比较多，还是传统公司也可以做这样的转型？
陈凯
不管是科技公司还是传统公司，都能做这样的转型。
它的核心难点不一定取决于人数和规模。大企业之所以难，是因为规模越大，合规问题越多，也会有很多人的因素，导致整个过程非常艰难。
但如果一家公司没有太多合规要求，也没有传统数据库、legacy 系统这些东西，那它就是第一批最容易做转型的公司。
所以我们的 target 就是这样一批公司，这是我们的核心目标群体。
泓君
一家公司想做这样的转型，是不是创始人也得有一个核心信念，就是相信 AI？
陈凯
是。但我觉得更多的是，他们要搞清楚这个转型最后代表什么。
举个最简单的例子，2023年大模型刚出来时，很多 SaaS 公司想的都是怎么把 AI 做成一个功能，集成到原来的产品里。
这本质上是没有想清楚：如果要做这样的功能，原来的产品架构有没有可能根本不支持最新 AI 能力？你的数据库可能不符合要求，交互方式也可能不是未来的方式。
所以你可能需要做的是整体产品重构。如果这个结果你接受不了，那也很难做这样的转型。
泓君
现在 AI 发展得很快，很多企业主，包括中小企业，都非常愿意拥抱 AI。但我觉得你们推行的概念又过于超前。你们自己觉得市场对你们的反馈怎么样？
陈凯
从现在用户的反馈来看，我觉得并不是我们的概念很超前。
这也是为什么组织变革是我们自己在做的事情。我们没有要求所有客户都像我们一样做组织上的改变，而是把 harness 这套系统变成产品，让用户先体验起来，再慢慢思考组织应该怎么改变。
泓君
我觉得 harness 还有一个核心，就是我对某个领域非常了解，所以才能给它做更精确的系统限定。
假设你对代码领域非常了解，我觉得这很权威。但很少有人能够说自己是每个领域的专家，什么都懂。这个挑战怎么解决？
Peter
以前你 create 一个自己的 agent，比如用 Hermes、Open Cloud 或 Call Code，需要对代码有一定理解才能做这件事，因为里面涉及很多 infrastructure、安全性问题，以及怎么接入 tooling。
但对于 Creo 来说，我们提供的是 cloud 端 service。普通使用者不需要理解太多架构，因为我们已经把架构提供给用户了。
用户只需要对自己要完成的任务有深入理解。至于怎么接入 tooling、怎么 maintain agent 让它长时间工作、怎么保证安全性，这些是我们为大家提供的 service。
陈凯
现在我们还处于利用 AI 的早期阶段。很多创业公司都在讨论：可能需要在某个垂直场景上非常了解，才能把 harness 做好。
但 Creo 也想成为第一批所谓的 AI first 公司。组织结构调整之后，有很多基础工作需要被 agent 化。
这些基础工作不一定涉及非常垂直的专业场景。比如刚才 Clark 说的市场调研，很多人都需要做。有人 agent 用得好、系统 build 得好，自己需要做的事情就很少；如果系统 build 得不好，需要人做的事情就更多。
我觉得我们真正超前、或者说市场还没有准备好的地方在于：如果你真的想把 AI 用在生产的各个环节，首先组织结构要发生变化。
组织结构变化之后，还需要有一个系统去保障组织稳定运行。这就是我们现在 build harness 的原因。
泓君
可不可以讲一下你们的组织结构是怎么发生变化的？以前传统组织结构是什么样，现在又是什么样？刚才过程中我们举了很多案例，但还是想知道一个 whole picture。
陈凯
整个组织结构的变化，里面有很多角色的变化。
首先，如果真的要做改造，第一个需要变化的是信任。原来的组织信任的是人，人本身是组织最核心的一环。
但当你把 AI 引进来之后，首先要解决的问题是：你能不能信任 AI 做决策，或者执行任务？
这和为什么要 build harness 系统一样。我们需要很多 guardrails 和机制，保障 AI 做的所有工作——不管是做决策、做 planning，还是最后 execution——最终都能够被人信任。
接下来，是组织结构中具体职位的变化。产品经理这个角色在我们公司并不是不存在，而是被拆解到每个工程师，以及 Peter 这样负责工程管理的人身上，不再有一个单独的角色专门负责产品。
我并不觉得产品经理这个岗位不重要，而是它在大多数公司其实是矛盾最集中的点。产品经理同时要和市场沟通，也要和开发沟通，很多对齐成本都会发生在产品经理这个角色上。
但当你把这个角色拿掉之后，会发现对齐成本有时反而更低。前提是需要有一套机制，保证没有产品经理的情况下，团队仍然能够互相信任，决策的信任成本没有因为少了这个角色而变高，而是变得更低。
这可能就是我们在组织上和传统软件开发公司不太一样的地方。
泓君
你觉得产品经理这个角色现在还有价值吗？或者说重新招一个类似产品经理的人，他需要有什么新技能？
陈凯
这个问题应该这样问：未来需不需要产品经理？
一定需要，但未来需要的是一种新的产品经理形态。因为开发成本在降低，产品经理本身的背景也会发生变化。
比如一个工程师之后也可以成为产品经理。更多人可能成为这种新型产品经理。还有一种可能是，产品经理的大量权力会分散到开发团队每个人身上。
如果每个开发团队成员在 AI 帮助下，都能够拥有更好的产品观念，那么有没有这个职位，本质上就不太重要了。
原来的产品经理更多解决的是对齐成本，以及如何帮助公司降低开发成本。
泓君
我可不可以这样理解？现在相当于 Peter 的工程师团队，在某种程度上扮演了产品经理的角色。
但反过来，一个好的产品经理对市场非常有想法，对产品也非常有想法。加上现在开发成本很低，他也很容易通过 AI 的执行能力，把自己的想法快速变成一个好产品，甚至不需要工程团队。
所以这两种角色在某种程度上会融合，变成一种角色。这个角色到底由技术团队做，还是产品团队做，其实不重要，因为都是 AI 在主导，想法更重要。
陈凯
有人会觉得未来产品经理可能变得更重要。就像你刚才说的，如果产品经理也能写代码，他可能自己就能 build 一个产品。
但也有人会觉得，产品经理没有很多技术背景，就算能 build 一个产品，这个产品到底能不能商业化，还要打问号。如果产品真的要商业化，可能还是需要工程师帮助产品经理，把产品构建得更适合商业化。
未来这个职位本身可能不是一个人，而是一个团队整体扮演产品经理的角色。这个角色会被组织化，而不是个人化。
传统软件时代有很多个人英雄主义：某个产品经理或者某个灵魂人物，导致产品特别受欢迎。但未来可能是一个组织做出了很好的产品，被市场接受。
有一个非常明显的 trend：复合型人才，或者比较 general 的人，在 AI 环境下可以 thrive 得更好。
不管是一个工程师拥有产品 sense 和 marketing sense，还是一个产品经理具有 implementation 能力，都会非常重要。
刚才一直在谈产品经理，其实还有另外一些 role，比如 designer，不管是前端 designer 还是 UX designer。如果问我未来产品中什么最重要，可能这两个 role 会变得非常重要。
但我们讨论的不是传统上不具备 coding 或 implementation 能力的 designer，而是能够把自己的想法 implement 到产品中的 UX 和 UI designer。这些人会变得非常重要，产品经理也是同样的道理。
未来产品需要产品 sense，这种 sense 来自谁并不重要。但有一点很重要：这个人必须具备 implementation 能力，能够把 idea 在1到2小时内直接带到产品中。
如果你需要把 idea 传递给另外一个人或者 engineer，交流和 alignment 的成本就会远大于 implementation 成本。在 AI 工作环境下，这就变得不够 efficient。
泓君
Peter，你有一篇文章让我印象很深。你说在真正进行这一系列组织架构变化的过程中，你意识到初级工程师比资深工程师更能适应 AI 环境。
Peter
初级 engineer 的 tech debt 或者思想束缚通常比较小，更容易接受 expand 自己的 scope。
他不仅是一个 engineer，还要融入产品设计。产品 feature deploy 之后，还需要做 analysis，根据 analysis 做出判断。
比较 senior 的 engineer 通常更 specialized。比如你是做 inference 或者后端的，在传统工作环境中，可能不 care 代码 ship 之后发生的事情。
但在 AI 环境下，engineer 的 scope 需要比之前扩大很多。不只是把代码写完就结束，而是写代码之前怎么加入自己的 judgment，代码 ship 之后怎么判断 impact，整个过程都非常重要。
通常来讲，junior engineer 能够更好地接受这样的工作状态。
泓君
如果你跟一个资深工程师说，除了负责前面代码交付的过程，还要负责后面的过程，他们可能不能马上理解，也不能马上转变思想？
Peter
通常需要 align mindset 的成本会高很多。
作为一个 senior engineer，或者一个专业领域的人，不管做 infra、front end 还是 back end，在过去的软件开发过程中，knowledge 是非常 valuable 的。
你知道怎么写最简洁的代码，怎么设计最好的 architecture，可能需要2到3个月完成这样的工作。
但在 AI 环境下，因为 AI coding 现在已经很强，以后会更强，所以你本身的 specialty 会变得越来越低。
很多人可能接受不了这种状态：他花了10年、20年学到的知识，未来可能变得没有那么重要。
泓君
所以你们现在更倾向于招哪一类人？拿工程师来举例。
初级工程师的问题是代码基础可能不够扎实。现在大家都用 AI 写代码，如果 AI 系统突然关机，他们可能就不会写了。如果代码基础不扎实，判断问题时专业知识也会差一点。
Peter
但对很多资深工程师来说，他们依然非常稀缺，因为他们有扎实的工程基础，只是在转变和适应 AI 思维上，可能没有年轻人那么快。
我文章中虽然提到，转变资深工程师的难度比转变 junior engineer 大，但从 value 上来讲，资深工程师现在还不能被取代。
所以怎么找到一个资深工程师，让他 embrace AI mindset，同时具有产品 sense，还了解一些 marketing knowledge，这样的人虽然很难找，但对公司非常 valuable。
好处是，以前在没有 AI 的情况下，我们可能需要很多这样的人；现在可能只需要1到2个人就可以了。
泓君
很多是多少？10个？
Peter
我觉得是10倍或者50倍以上的人，在没有 AI 辅助的情况下。
泓君
但我觉得这样的人是不是也比较好找？因为我最近看到硅谷的趋势是，所有人都开始用 AI，也开始比较 AI 生成代码的数量，大家都很积极地适应这个新时代。
陈凯
我们通常会发现很多人是这样的心态。但有这样的心态，和在工作中愿意相信 AI，然后真的把 Harness 系统 build 起来，是完全两码事。
很多人愿意拥抱 AI，只是愿意用 AI 工具提升效率。但他不一定愿意花时间构建一个系统，让未来的工作完全由 AI 驱动，甚至自己在其中扮演的角色都发生变化。
这两种心态完全不一样。
后面那种更激进的工程师、marketing 人员，或者做任何事情的人，在现在这个阶段思想还相对超前，仍然是少数。
现在更多人接受的是尝试使用 AI 工具、拥抱 AI 能力，但还没有到真正希望做到 AI-first 的程度。
泓君
另外，从一个角度来讲，我认识的很多朋友本身能力很强，有很强的架构能力，但他们往往会自己出来创业。
对于一家 startup 来说，你想 hire 这样的人，现在难度还是比较大的。
Peter，你是从什么时候开始相信 AI 的？
Peter
我觉得凯今天给我一个很大的震撼，就是“相信 AI”这4个字。
如果你问我，我从刚毕业开始就在做 AI。
泓君
你是哪一年毕业的？
Peter
我应该是2018年。
泓君
我们肯定不会记得那么具体。
Peter
我具体记不清了，但可能是10年之前的事情。我在苹果做的第一份工作就是 AI 相关工作，而且和语言模型有关。
所以我肯定从一开始就相信 AI 能够改变世界。
泓君
那个时候大模型还没有出来。当时我们提到 AI，和今天提到 AI，完全不一样。包括那个时候 AI 带来的思想冲击——我们是不是要把工作彻底交给 AI——和今天也不一样。
Peter
虽然当时没有大模型，但有一篇非常重要的 paper，叫《Attention Is All You Need》。在这之前，BERT 的出现也正好发生在我刚开始工作的时候。
那时我就意识到 pre-training 的重要性。包括我当时在苹果做的一些 traffic prediction 工作，我也开始利用 pre-training。
以前 pre-training 只是在文字上做 pre-training，我会在 traffic signal 上做 pre-training，同样利用类似的 concept 完成工作。
泓君
所以可能因为你的工作经历，你一开始就觉得 AI 比人强？
Peter
我没有说 AI 会一直比人强。哪怕现在这个阶段，AI 也不能取代人做任何事情。
但 AI in the future，或者现在这个阶段，已经能够主导很多事情。包括 architecture 过程，AI 也很强。
不过，要让 AI 系统真正运转起来，还是需要人去做 architecture。
泓君
我们刚才聊了未来要招什么样的人。现在 AI 作为主力干活，可以迭代产品，所有东西都是动态的。大家觉得未来人的核心能力是什么？
Peter
我觉得人最大的能力会是系统架构能力。
过去是 implement feature，现在变成怎么架构 AI 系统、maintain AI 系统。
泓君
这是工程师的角度。
Peter
不管是工程师还是 marketing 的角度，做 go-to-market 也需要搭建一套能够自主运行的 agent marketing 系统。这是核心，而不是单纯地产生一个 marketing content。
陈凯
如果从更长远来看，人的价值和技术发展的过程一样。确定技术发展方向的，永远是人的需求和社会需求。
只要人这个物种还存在，它的价值就不会有太大变化。人定义需求的方向和技术迭代的方向，因为技术永远要为这个物种服务。
如果人没有这方面的价值，就代表 AI 自己在发展，自己变成了一个物种。
泓君
这是一个哲学问题。
陈凯
人定义了需求，就需要去看最后的结果是不是自己想要的。
所以在未来的系统里，人还有一个重要价值，就是 review 最后的结果，判断这个结果是不是真的符合我们的利益和要求。
人在需求定义和最终结果审核上的价值无法被取代。除非人作为一个物种本身的重要性已经不存在了，那是另外一回事。
泓君
我看最近应该是 DeepMind 已经开始设立哲学家的岗位了。
陈凯
对，职位就叫哲学家。
这里面还有很多问题。比如如果我们真的把 AI 引入 agent，真的能够替代人工作，那么 agent 和其他 agent、agent 和其他人之间也会进行沟通。
这些沟通内容，其他人能不能查看？这是不是侵犯隐私？里面会有很多道德问题，都和未来组织关系相关。
Clark
我觉得刚才凯讲得很好。
我自己觉得，人未来的价值就是判断任何事情是否还有价值。对价值的定义，可能就是人最大的价值。
从价值定义本身延伸出来，就是我们怎么样定义自己的需求。当我们知道自己想要什么时，才能判断一件事情有没有价值。这就是人的价值。
泓君
你们对未来整体是更悲观还是更乐观？我说的是完全抛开企业，作为人来说。
陈凯
我自己还是相对乐观的。
很多时候大家会讨论人为什么快乐。我现在工作还挺快乐，是因为虽然工作中和 AI 的配合会让工作内容和工作强度比之前更高，但不工作时，不管是享受自然、爬山，还是做户外运动，我可能会更加放松。
所以我相对比较乐观。AI 带来的价值，可能是帮助我们更好地进行工作和生活的切割。以前经常说 work hard, play hard，它可能反而能让这两件事分得更开。
Peter
从创业角度来看，我们肯定是乐观的。如果悲观，今天也不会出来创业。
未来肯定还是相对乐观的。但就像我们刚才聊的，和上一次工业革命一样，当时很多纺织工人、车夫可能被取代。
但那个阶段过去之后，人会找到新的方向，实现更大的自我价值。
所以未来一定会是一个更好的世界，只不过这个世界是不是和现在大家定义的幸福一样，可能并不一样。这可能是未来比较大的变化。
Clark
我还是非常谨慎地乐观。
我觉得变革过程中会有很多痛苦，也会有很多 noise，但变革的结果我仍然 believe 它会是一个好的结果：人在 AI 辅助下，能够拥有更多自由时间，也能够发挥出更大的价值。
泓君
谢谢3位的分享。我们今天聊了很多有意思的内容，比如产品与工程的边界正在消失，SaaS 产品本身也在重构。
3位的观点对很多普通听众来说可能有一点超前，但一线亲历者的视角，恰好是大模型时代最稀缺的内容之一。大家对未来公司的组织形态有什么思考，也欢迎留言讨论。我们未来还会从更多的角度持续关注这个话题。如果大家喜欢我们的播客，可以在小宇宙、苹果播客、YouTube、哔哩哔哩、小红书和视频号上收听、关注我们。我是泓君，感谢大家的收听。