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

Hello 大家好 欢迎收听《硅谷101》 我是泓君 过去三年 我们经历了 大模型工程能力三次概念上的进化 大家还记得 在2023年 模型刚刚出来的时候 我们都在聊 prompt engineering（提示词工程） 核心是怎么样写好一个提示词 让模型给出更好的答案 后来在2024年的时候 焦点就变成了

context engineering（上下文工程） 它是说怎么给模型提供 更完整的上下文 让它能够去理解更加复杂的任务 到2026年 一个新的词开始在硅谷流行起来了 叫做Harness engineering（挽具工程） Harness在英文里原本是指“挽具” 就是说那个套在马身上 用来引导和约束马的那套装备

现在它被用来形容一件事 你怎么围绕大模型搭建一套 能够让它在真实世界中持续工作 自我修复 还有自我提升的一套系统 最近Creao的CTO Peter 他在推特上写了一篇文章 叫做《为什么你的AI优先战略可能错了》 引发了几百万的关注与讨论

核心结论是大多数公司所谓的 AI-First都是假的 真正的AI优先策略 是重新设计整个公司的流程与组织结构 本质上也是他们内部怎样Harness的过程 Peter之前是Meta Llama 基础模型团队的研究科学家 后来在苹果从事多模态模型的

相关工作 所以他的工作语言是英文 如果本期内容中英文夹杂过多 欢迎大家收看我们播客的字幕版 那也很难得 今天除了Peter 我们还把Creao的另外两位创始人 也是这个故事的亲历者 邀请到了我们的节目上 来聊一聊 他们是怎么在AI快速进化的一年里 重新组织自己的组织架构

把信任从人变成了AI 首先请我们今天的三位嘉宾介绍一下自己 大家好 我是Peter Creao的co-founder and CTO 大家好 我是Creao的CEO and co-founder程凯 大家好 我是Clark 我是Creao的 co-founder 现在主要负责我们的 go-to-market（市场拓展） 之前做了很多年的数据科学家 和机器学习工程师

现在在Agent这个领域里面 跟凯还有Peter一起帮助用户 更好地使用Agent 然后达到AI-First（AI优先） 这样一个组织形态的目的 好的 欢迎三位 开始的时候我们就直切主题 最近大家都在关注 这个Harness engineering Peter你要不要跟我们介绍一下 什么是Harness engineering Harness这个概念其实可以追溯到 大模型刚开始的时候

很多人在聊 prompt engineering（提示词工程） 之后演变到 context engineering（上下文工程） 到之后的Harness 整个Harness过程不仅仅是 对于LLM（大语言模型） 本身的Harness 还有包括围绕着整个大模型 包括它的基建工具链的使用 包括安全的 security（安全）的保证 整个这样一个改进提升的过程 我们把它叫做Harness

可不可以跟听众解释一下 这三次进化它是怎么发生的 然后每一步它最重要的是什么 对 我先说一下 prompt engineering（提示词工程） 和context engineering（上下文工程） 更多的是聚焦在 怎么和LLM这个大模型本身 进行交互 就是我怎么优化它的上下文 怎么优化它的提示词 从这个角度上来讲 它的范围要比

我们现在讲的Harness 小得多 而且从静态和动态的角度来讲 prompt engineering（提示词工程） 和context engineering（上下文工程） 相对来说是一个静态的事情 因为你优化的是一个大模型 你优化的任务 可能也是一个相对来说 比较垂直的任务 但是对于Harness来讲 Harness是一个系统的Harness 而且对我们来说 我们是在Harness一个通用的系统

所以从范围上来讲 会比prompt（提示词） 和context engineering（上下文工程） 要大很多 因为这涉及到工具链的使用 涉及到你的sandbox（沙箱）的 架构设计 和你的host service（宿主服务） 之间是怎么进行交互的 怎么样的交互能够安全 你的sandbox（沙箱） 启动时间的是多少 你的latency（延迟）是多少 都是Harness的一个部分 我可不可以理解成 Harness的工程能力

在决定你怎么把一个大模型 “榨出”它的最佳使用上限 它可以理解成是AI的一种工程能力 举一个例子 我记得凯 你之前是在 融资的新闻稿里面其实你有提到 一个Agent可以一夜之间 干掉三个人这种 做SEO（搜索引擎优化）的工作流 同时还有一个 content的pipeline（内容流水线） 它跑了两天

然后才有人发现全是垃圾 这两者之间的巨大区别 就是一个非常好的表现 跟一个非常差的表现 我可不可以理解成 从本质上说 一个就是Harness的胜利 一个就是Harness的失败 对 刚才提到了两种状态 一种是你效果好 一种是效果不好 但是我觉得这个是完全就印证了 为什么我们需要Harness

Harness的本质就是在于 我们怎么能够持续提升一个系统 当你这个系统产生的效果不好的时候 你这个系统是需要人的feedback（反馈）去提升 还是这个系统本身自己能够 self healing（自我修复）self improvement（自我优化） 这个正好就是Harness的核心 因为通常来讲 我们也有很多用户在我们的平台上产生Agent 但是这个Agent 不是说one shot（单轮）

就能达到一个完全优化的状态 用户怎么去follow up（跟进）这个Agent 我们的系统怎么能够self improve（自我优化） 这个Agent 也是整个Harness的核心 Harness很重要的一件事情 就是怎么能够让Agent 在推理阶段scaling 包括你怎么能够把更多的上下文 提供给它 更多的工具链给它 让它思考更长的时间 完成一个任务

用一个更长的时间 我觉得这都是 在推理阶段的一个scaling 所以在推理阶段的scaling 因为工作时间长 工具链使用的数量多 它的上下文多 所以你Harness如果做得不好的话 就很容易产生hallucination（幻觉） 或者context overflow（上下文溢出） 你的模型能力会下降 所以在这个过程之中 怎么把这个Harness做好

其实是一件非常复杂 而且需要一些经验的事情 换句话说 Harness它是一个新概念 但是它所谓的“新” 其实是把这种传统软件的东西 放到了Agent的应用上 所以大家怎么去看 这个Harness里面它有哪些是 我们这个时代的新的东西 传统工程没有的

因为大多数业务的人 他可能都是从能力层面 去理解一个软件 就像很多人从传统角度来讲 他不理解 其实一个很简单的功能 可能都需要开发团队 在之前的情况下 可能要做两到三个月才能去实现 很多业务的人经常会说的事情是 我觉得这功能很简单 为什么这个产品就是一直解决不了 我这个问题呢 其实是因为你后面有太多的 工程化的问题牵扯在那边

其实这个对于Agent来讲 也是一样的 很多人会觉得LLM（大语言模型）的 能力提升了 但为什么它做不到我想要做的事情 其实是因为还有很多工程化的问题 需要一起被解决 这个其实也是我们 去做Harness的一个原因 你觉得今天我们市场 在讨论Harness的这个部分中 有哪些是大家的共识 有哪些是非共识 因为我觉得不同的群体

对Harness的认知可能不一样 我听到的很多看法 通常来讲 对待Harness是一个静态的过程 我怎么能够开发配套系统 去把LLM的优势更大地发挥出来 而对于我们来讲 我们认知中的Harness 就是一个动态的过程 你这个系统怎么能够 从一个静态的状态真的活起来 能够self-improve（自我优化） 能够不停地适配新的信号

不管是市场的信号 还是产品本身的信号 还是用户的信号 能够让它不停地 迅速地迭代 我觉得这个是 可能很多人还没有意识到的一点 然后这个迭代也是以AI为主导的 而不是人为主导的 对 是以AI为主导的迭代 但是人所需要做的事情 就是怎么把各种各样的信号喂给AI 不管是市场的信号还是产品的信号 还是本身

infrastructure（基础设施） 自己的信号 对 我注意到最近 你有一篇推特的帖子非常火 其实是讲你们是怎么 一家25个人的公司 99%的代码都是AI来写的 基本上你早上10点写了一个功能 中午就进行了A/B test 然后下午3点的时候 就根据数据的反馈 把它砍掉了一部分功能

5点又重写了更好的一个版本 这是一天的时间 但是这种工作的节奏 在传统的开发产品的过程中 它是需要6周的 你的这个帖子在推特上非常火 到现在为止 我昨天还去看了一眼 有187万的推特流量 同时下面大家也有很多的共鸣 但仔细看下来 其实我觉得 你只是在讲Creao

在整个工作流程中 用Harness去做的 也算是你自己独立探讨出来的一条 Harness的方式 对 我觉得这个就牵扯到 Harness的一个具体细分的层级 在我们Creao来看 Harness分成两个主要的部分 一个是对于Creao本身 Agent系统的Harness 另外一个是 对于用户使用Creao的时候

在构建自己的Agent过程中 怎么Harness自己的Agent 在之前 我们传统的开发过程中 可能需要两三个月的时间 来迭代一个feature（功能） 但是在Agent这个情况之下 很多东西都是AI辅助的coding 本身实现这个feature 可能只需要一两个小时的时间 所以在这个过程之中 如果我们再花很长的时间去设计

和很长的时间去测试 就不是很有意义 所以我们怎么把 设计与规划的阶段 和测试的阶段 都包含到整个Harness过程中 对于这个公司能不能真正转型 成为一个AI-First公司 是非常关键的 对 我想先跟大家表达一个观点 我们如果想要做到所谓的AI-First 或者AI native（AI原生） 这样的一个状态 它并不是在现有的流程上面

去使用AI的工具 而是要围绕AI的能力 去重新构建你的工作流程 和组织形态 所以这个是Peter刚刚所描述的 因为其实我们在之前的 很长一段时间里面 其实每一个工程师都在用AI写代码 每一个产品经理 都在用AI写PRD（产品需求文档） 每一个设计师都在用AI做图 但其实这样并没有增加我们的效率

反而导致每一个人的工作进度 和节奏不一样之后 我们的alignment（对齐）成本 变得非常之高 因为我们本身是一个 全部都是远程办公的状态 所以在这样的一个机制下 我们要去重新想 我们到底怎么样能够让AI 在我们整个公司的运营过程中 真正地自动化跑起来 所以才

Peter设计了一套新的开发流程 和我们新的产品的架构重构 才有了今天Peter所写的 这篇文章里面所讲的 这个self-healing 自我修复的Agent Harness 或者Engineer Harness 是一个什么样的形态 可不可以举一个例子 因为你在说 重塑开发流程跟组织架构 你们开始用AI 自己去写Agent的过程中

包括你们在重塑 你们整个的组织架构的过程中 你们觉得哪些方向发生了变化 瓶颈在哪些方向 哪些方向跟你们在预期的过程中 它是不一样的 我觉得在我们整个推进Harness 和推进AI-First的过程之中 首先需要解决的就是人的问题 大家能不能够接受 这个新的工作方式

所以我们也花了很长的时间 去对齐大家的mindset（思维模式） 我觉得这个思维模式的 对齐是最重要的 之前的话 可能我们做这样一个转型 需要很长的时间 因为人需要去搭建这个系统 通常 比如说一个架构师 一个工程师 他需要好几个月的时间 去demonstrate（展示） 我的这个新的工作方式 是比之前的更好的 但这个转型的成本

就相对来说非常的大 但是在AI辅助的情况之下 我们在展示 整个新的工作方式的过程中 就比以前会快很多 可能我们只需要一两周的时间 把整个系统进行重构 包括从前端 后端 架构 基础设施 都进行重构 然后给大家展示 这样一个新的过程 它工作起来是更高效的

不管是部署的频率 部署的可靠性 和最后的效果上来讲 都能够比之前的工作方式 有一个很大的提升 这样的话我们可以在很短的时间内 对大家的思维模式进行对齐 之后大家onboard（融入） 到这个工作方式的过程之中 就能够更快速地融入到 整个的开发过程 对 Harness本身其实更多是在于

构建一个系统 真的能够让Peter刚才说的 所谓的AI-First 这样子的一个组织结构 能够高效地运转 这个其实是非常重要的 为什么 因为很多组织上的人 他的思维会很难去改变 然后会觉得说 我可以用AI来提升我的效率 但是 AI-First要求的是说 你让AI来驱动你整个公司的方向 还有可能你每天工作的方式 都是由AI来驱动的 这是完全不一样的概念

举个例子 是每次AI给你们布置任务吗 还是 对 原来可能大家都觉得 还是人去提出一个概念 然后由AI来帮助人去提升效率 但这个东西可能 因为人如果还是这个工具的使用者 那他的效率提升 可能有一个所谓的效率倍数的上限 可能最多就是10倍 因为人最多每天可能就工作24小时 但是如果说 你真的希望AI能够给

比如我们工作的效率 去提升100倍 1000倍 你不能还是说 你是那个工具的使用者 而是AI应该是所有生产力的主导 人的角色就会发生变化 更多是在于我怎么去 看最后的结果是否是好的 或者说我怎么去 复盘这个结果的好坏 还有包括我在这个系统里面 我并不是那个实际的工作者 如果在这样的角度下 我应该以怎样的一个方式去

跟这个系统配合起来 这个其实我觉得是 很多企业在做转型 要么就是它没有意识到的一点 或者他很难去做到的一个事情 能不能举一个例子 你们的系统怎么跟人配合去工作 比如说是系统给人发任务 因为我觉得传统的团队 大家在开发产品的时候 可能很大的一个痛点就是说 我团队之间要对齐

然后我要把信息同步到每一个人 任何一个人 他可能miss掉了一个信息点 那他在产品做开发的时候 可能就不知道 我们上一版的更新是什么 现在是不是所有的这些工作 都可以交给AI 或者在这个流程中 它就可以自动去做了 对 我觉得这里面核心的一个点 还是信任的问题 因为很多时候 人因为对这个系统没有信任 所以刚才会有像您说的

“对齐”的成本就会非常高 像Clark这边的 go-to-market（市场拓展） 这个团队 和比如说Peter engineering team（工程师团队） 他们两个团队怎么配合起来 原来他们需要互相沟通 互相达成共识 对齐之后才能事情往前推进 但现在如果是 AI-First 这个组织结构的话 他们其实没有对齐的所谓过程 而更多的是在于 这个对齐是由AI来主导的 比如说告诉我们的

marketing team（市场团队）说 今天我们开发团队工程师 要发布哪些功能 这些功能到底是怎样的一个结构 那市场这边就不用 再去跟工程师团队交流说 你明天要发什么功能 后天要发什么功能 这样的话 它中间的对齐成本就会降低 AI怎么知道 Peter的工程师团队 明天能把所有的工作做完 这个Peter可以说一下 我觉得在整个这个过程

不管是叫Harness 还是AI主导的工作流过程中 主要大家体会到的改进 就是整个开发速度和迭代的提升 通常来讲 实现一个功能 或者部署一个新的产品 需要很长的周期 所以大家需要详细的讨论 但是我觉得 在AI的思维模式之下 因为它迭代一个产品的速度 是很高的

在这个过程之中 我们其实更侧重的是 OK 这个新的功能 能不能够带来产品的 top line metrics（顶层指标）的提升 或者我新的这个功能 能不能有真的用户使用的数据 所以在这个过程中 我们更核心聚焦的点是 怎么把整个的数据链搭建起来 我们把这个链条搭建起来之后 都是Agent通过这些数据来决定

好 这个功能到底是不是有用的 我们到底要不要 roll out（上线）这个功能 或者fall back（回退）这个功能 也就是说工程师写完代码以后 不需要手动地跟AI 比如说有一个什么工程管理的界面 说我写完了 这是传统的软件跟公司内部系统 同步的一种方式 现在AI它就可以

自动地根据你的整个代码质量 你的进程 去做出一个它的判断 对 这个在传统的工程中也有 我们叫 CI/CD process（持续集成/持续部署流程） 只不过在传统的CI/CD process 中 很多都是 rule-based（基于规则） 或者一些 unit testing（单元测试）驱动的 但是在AI这个情况之下 我们可以有很多AI驱动的测试 不管是集成测试 还是单元测试 比如现在大家比较常用的 像Playwright

是可以做AI驱动的完整的 end-to-end testing（端到端测试） 这样可以保证我们发布的代码中 没有明显的 可以破坏这个产品的bug 所以在这个过程中 很多AI驱动的测试是非常重要的 包括你代码发布之后 在这个log（日志）中 有没有error（错误） 有没有incident（事故） 都是通过这些信号能够反馈给AI 来看整个这个代码的质量 是什么样子的

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

跟关键信息的梳理的 这个是AI能做的吗 是的 您这个问题问得非常一针见血 其实我们现在也花了很多时间 思考这个问题 因为我们实行这套新的开发机制 已经有几个月时间 我自己的一个体会就是说 现在我们确实不用 跟工程师过多地沟通说 你要做什么功能 然后你什么时候能deliver（交付）

因为功能现在的数量 已经远远超过我们能够 去卖它的这个能力了 这个是我最大的体会 就是我们现在开发的速度 是远远超过市场这边的进度的 但这样有一个好处就是 我们不再去讨论说 今天你这个公司的 product roadmap（产品路线图）是什么 而我们只需要讨论的是 现在市场的需求在哪里 我们就好像有个菜篮子一样

或者说像机器猫万能的宝箱一样 如果今天说市场的需求是一个苹果 我们就从我们的这个篮子里面 挑一个苹果去卖 如果今天市场的需求是一个香蕉 我们就可以挑一个香蕉去卖 这个反而是大大降低了我们对齐说 今天好像市场反应是这样的 我们要去重新思考 我们要做什么样的产品 这个其实是比过去 要省时和省力很多的

我理解了 就相当于其实你们的开发能力 是远远快于市场能力的 所以当市场有新的风向的时候 反而是你们可以从你们这个 已经搭建好的产品库里面 看你们在哪一个点上穿透去营销 是的 是这样的 有意思 关于让AI写代码 我还有一个很核心的问题 就是怎么保证它的质量

因为 Peter 其实你在那篇 Twitter的文章里面写到了 正常情况下 写代码一天 然后大家修bug要三天 现在有哪些新的手段加入 可以让大家不用把很多的时间 都花在修复上 对 我觉得bug这个事情 是整个工程不可避免的一个事情 不管是AI写的代码 还是人写的代码

都会产生bug 因为Harness它不是一个 静止的状态 它不是说我现在有一个系统之后 我只需要维护这个系统 这个系统不会有bug 也不需要提升 Harness这个过程的核心就是在于 我能不能找到这个系统中的bug 刚才聊到CI/CD的过程 就是在集成的时候 在测试的时候 我们会有一系列的 regression test（回归测试）

去避免有一些bug可以发布到 production（生产环境）中 破坏这个系统 这是第一步 第二步 即便有一些 corner case（边界情况） 或者race condition（竞争条件） 发布到这个系统之后 我们怎么能够在最快的时间 识别这些bug 然后及时地修复这些bug 是第二步的事情 所以这两步 传统的情况之下 都是由人来驱动的 但是在Agent Harness情况之下

我们会有Agent系统来驱动 所以我们开发了 Agent-driven的CI/CD系统 和Agent-driven的 bug triage（分类/定级）系统 会根据系统中的问题 去triage（分级）这个问题 然后指派给工程师 让他们去修复这些bug 你觉得在你引入这两套系统以后 它的效率提升了多少 首先因为很多都是Agent-driven 所以它可以并行地进行 所以可以有很多Agent

去identify（辨认） 比如说有一些Agent 专门负责前端的bug 有一些Agent专门负责后端的bug 有一些负责Agent核心系统的bug 所以在这个过程中 它发现一个bug 可能只需要1到2分钟的时间 然后再把这个bug 指派给一个工程师的过程中 也可能就是几秒钟的时间 工程师拿到这个任务之后 也是用Agent 去investigate（调查）

提出一个solution（解决方案） 所以整个这个cycle（周期） 加起来可能也就是 1到2个小时的时间 对比之前的话 我们识别一个bug 修复一个bug 再把它发布到系统中 可能需要一周的时间 对 这里面有一个特别有意思的现象 因为我们之前所谓 产研 就是产品和研发结合 我们公司以前其实是有一个 feature wish list（功能愿望清单） 就是你到底希望做什么样的功能 很长

又有一个bug list（bug清单） 有很多bug要修复 以前就总是打架 到底是先修bug还是先做功能 市场和产品 还有工程师 大家就在那讨论来讨论去 现在这两个清单都没有了 因为bug及时发现 及时修复 功能现在的数量远远多过于 我们所需要的数量 提供一个数据的话 我们现在有一个 auto-fixing（自动修复）系统

这个自动修复系统 是根据整个我需要修复的代码 是存在于哪个文件夹下 因为有一些文件夹是敏感的 有一些文件夹是 相对来说风险比较小的 对于我要修复的一些东西 如果只是存在于一些 风险比较小的文件夹之下的话 AI会自动地提交这个PR（拉取请求） 然后可能只需要一个工程师 简单地批准一下 它就马上能够公布到产品

所以可能现在50%以上的问题 是通过auto-fixing（自动修复）的 形式进行的 可能人在里面的参与只是简单地 验证这个bug 如果这个修补 触及了一些 比较sensitive（敏感）的文件 比如说涉及到安全 涉及到 Agent behavior（智能体行为）的话 我们可能需要专门的 响应这个错误的人员 去进行一个更深度复盘 但整个过程相比与之前来说

也有一个很大的提升 有什么奇怪的 智能体行为吗 因为智能体行为 可以break down（拆解出） 很多错误 比如说这个成本太高 或者延迟太高 或者会有hallucination（幻觉） 或者它使用工具链的时候 和工具之间的交互的 authentication（认证）有问题 我觉得都涉及到 Agent behavior 所以任何这个系统中的问题

都能导致用户 具体在使用这个Agent的时候 不能够完成他的任务 所以Agent还是一个比较复杂的 工程系统 简单来说就是现在 Agent还没有价值观的问题 它还是效率的问题 跟你灌输给它的一套思想 比如说是不是要用更便宜的成本 同样的任务能更便宜地去完成 还是这一方面的 就是效率上的问题 对 我觉得主要是效率

和具体能不能够完成 用户的任务的层面上 我们所聚焦的 就是怎么把我们的系统优化到 在成本最低的情况下 能够可靠地完成用户的任务 比如说当系统出现一个bug的时候 假设我是在改一篇稿子 即使它只出现了一个小错误 我可能需要把整个稿子看一遍 然后我再去看那个错误是在哪 我怎么去修改

这个时间其实就跟 比如说我自己重新写 重新熟悉这个领域 它的时间花得是差不多的 因为我不太懂写代码 只能用写文章做比喻 对应到开发的领域 就比如说Agent帮你搭了一个 非常好的技术框架 但是它可能在整个搭建层 或者基础层出现了一个大的错误 那这个时候当然有其他的

很多的Agent要去修复 但会不会说 比如说有一些大的错误 大到了需要工程师去解决 但是工程师去解决的时候 我不能只看这一个点 我要先看你整个的构成是怎么样的 然后我才能去解决那个细分的问题 它同样要花的时间 就是我还得把这个重新学一遍 对 我觉得这个问题很好 所以在之前的我的文章中

我也讨论了在AI环境之下的 工程团队可能分为两种人 一种是architect（架构师） 一种是operator（操作者） 所以架构师 在整个这个系统搭建过程中的作用 是非常重要的 比如说在搭建整个Creao的 系统过程之中 整个Agent的架构师是什么样子 比如说sandbox（沙箱） 和host（宿主）之间是怎么交互的 还是由架构师来决定的

如果说Agent直接通过AI coding 或者vibe coding（氛围编程）的方式 它通常来讲 会给你一个solution（解决方案） 但这个解决方案 通常会有安全的隐患 或者延迟的隐患 怎么去优化整个这个系统 还是由架构师来决定的 但通常来讲 我觉得区别就是在传统的情况之下 搭建Agent的团队 以前可能需要10到20个人 但是现在搭建整个这样一个系统 只需要一个架构师

在一个周的时间之内就能完成 你现在是那个架构师 当然 从一开始 我们在开发这个系统的时候 需要我来架构整个的系统 去展示 给整个的团队 整个这个架构 是比之前更优化 效率更高 成本更低的 我来补充一下 刚刚Peter所讲的内容 第一 我觉得AI的能力

在很早以前就已经非常强了 但是它为什么没有达到 人们所预期的那样说 今天AI可以替我干活 它如果没有干好 我还得帮它去弥补它的错误 我觉得这个点来讲 Harness在这个过程中 非常重要地去发挥价值的地方 这里面有个很大的概念上的转变 就是我们要把AI 当成一个系统来看待

不要把它当成一个智能来看待 虽然系统是由智能所驱动的 但这里面一个核心的差距就是 当AI或者说这个系统 发生错误的时候 我们不要想着 怎么样去纠正这个智能 我们要想着怎么样去弥补这个系统 这个其实就是我们在做Harness 跟现在普遍的认知最不一样的地方 它是一个动态改变和提升的过程

并不是一个静态的 固定的枷锁 去束缚这个智能 而是要给它提供空间 让它能够成长 这个成长的方式 就好像你在养一个孩子 你怎么样能够让它 不断地在一个规则内变得越来越好 我们做Harness 其实是在给用户提供 我们给你一个培训师 去弥补它在发现错误之后 你该怎么办 回答您刚刚那个问题

如果您在写作的时候 发现有一个巨大的问题 我觉得您应该花更多的时间去思考 这个系统上面有没有漏洞 而不是我要去花更多的时间 去改正具体的某一个错误 这里面还有一个更加极端的想法 就是您今天发的这些内容 或者我们自己发的这些内容 可能未来的这些受众并不一定是人 这个错误可能对人来说 是一个很致命的错误

但对于未来可能都是AI在读文章 或者AI在读我们的图片 视频 对它们来讲 可能并不是一个很致命的错误 所以我觉得大家在这个过程中 要思考更多的就是 我今天做的这个工作 到底是未来谁来去消费我的工作 和我的这些结果 根据你的这些消费者的偏好 调整你Harness这个系统

才能够更好地达到你所能够 期望去交付的价值 我觉得这个观点非常有意思 就是大家以前在出现问题的时候 都是说“我们解决问题” 现在说的是 我们解决搭建的环境中的 系统上的问题 而不是一个单一的问题 就是彻底上修复它 以后它这个问题 就永远都不要再出现了 对 与其说是彻底修复它

不如说是我们重新思考这个问题 它是否还是一个问题 比如说我们平常会生产一些 go-to-market（市场拓展）的 assets（物料） 比如有些图片 我们觉得可能从人的审美上去看 它并不是一个很好的asset 但实际上 你把这个东西投向市场的时候 你会发现 可能读这篇文章或者读这个图片的 是一个Agent在读 它的数据反馈回来

其实可能是更好的 如果我们与其去说 今天人觉得这个东西不够好 我们要去修复 人主观对这个东西的价值判断 我们与其去修复 整个不管是我们自己的系统 还是别人的系统 对这个事情的价值判断 它其实是从价值理解上面 就会发生偏差 为什么会是Agent 在读一个营销图片 你们的下载是针对谁的

是针对Agent的 还是针对人的 现在大家也比较感兴趣的话题就是 以后会不会有这样的Agent经济 可能买东西是由Agent去买 订报纸是由Agent去订 订牛奶是由Agent去订 那你的广告是发给Agent看 还是发给人看 因为我现在自己看很多文章 看很多视频 也是让Agent去看 所以你要搞清楚 你的内容到底是被谁消费 你的工作结果到底是被谁消费

针对这个东西的价值 我们再去思考 我们到底是提升系统 还是我们回到最原始的 人要参与到这个创作的过程中 去弥补我们一些错误 我相信在未来 真的是在Agent帮大家 做更多的购买决策的时候 最终的结果可能还是Agent看得多 但是我没有想到 在现阶段

包括你在现阶段测试的这个流量中 Agent已经占到了一个这么大的比例 它来得比我预期中要快很多 是的 几个亲身的经历 我最近在看有什么样的公司 能帮我们做合规的 比如说SOC2 ISO 这些认证 那我肯定是让Agent 先去帮我研究一番 然后我基于它的结果 我来看一看是不是适合我们

这个里面你会发现 第一步已经是在Agent 帮你做这个筛选了 是不是那些内容 它应该更偏向Agent去做 而不是偏向人去做 当我点进去 再去看某些东西的时候 可能需要有面向人 依旧需要消费的内容 但是有可能它会把第二层也做掉了 甚至第三层也做掉了 所以这个我觉得都是 可能会发生的事情 这个从另外一个角度上来讲

也可以很明显地看到 现在SaaS产品的转型 因为以前很多SaaS产品 尤其是像 Asana Linear这种产品 做任务管理 它需要一个dashboard（仪表盘） 以前可能很多的都是人 在去看这些dashboard 管理这些dashboard 但是在起码现在这个阶段 我们团队在使用 任务管理的时候 我们更关心的是

Agent能不能够更好地看这些任务 prioritize（设定优先级） 这些任务 所以代替人去看这些 或使用这些dashboard 更多的是我们会去看这些 任务管理产品 有没有更好的MCP（模型上下文协议） 和API（应用程序接口） 提供给Agent 可以让我们使用 所以整个进化还是非常快的 其实刚才您提到这个问题 也是很多公司 它在做AI转型时候 会第一个考虑的问题

他可能会看到 下面有很多的员工也好 或者说他的管理层会觉得 我使用AI的时候 如果我还要去复盘一遍 那跟我人去做 不管是从时间也好还是成本也好 可能没有太大差别 但是就像刚才Peter说的 如果你真的能够把 这样子的一个AI系统 给构建起来之后 你会发现其实你仔细去算一下 你会发现你的时间 还有你的成本 是会有很大的一个提升的

只是这个过程需要整个团队 一起有一个共同的目标说 今天我就是要把 公司的组织结构也好 工作方式也好 都去改变了 它这个过程当中 只要有那么一些人 他可能觉得 做很多东西还不如人去做 这个过程就让我们改造的时间 会被拉长 以及这个过程就会变得特别不顺利 这个其实是一个大多数公司 都会面临的一个 从组织上来讲的挑战

你们是第一天就这种 AI-First的工作方式 还是说 因为其实你们也成立一年多了 而这一年多 我觉得是整个行业里面 变化最快的一个时间段 还是说你们在后面慢慢地 摸索到这样的一套工作方式的 我觉得我们整个公司 也是有一个过程的 你意识到谁是未来 生产力核心的角色 可能在2025年的上半年的时候

大家都会觉得可能那个时间点 还是AI辅助人去做事情 人在整个工作里面 还是占主导地位的 但是到了下半年的时候 我们会意识到 如果还是这样子的话 其实企业的效率提升 还是非常有限的 因为我们也用了这样的方式 我们会发现 好像效率没有提升得 我们想象那么多 所以我们会发现那里面核心问题 我们还是没有 把这个生产力工具的使用者

真正地从人转变到AI 这个过程如果没有彻底地去改造它 我会发现 可能还不如我人去做这个事情 来得更高效 所以说这个过程 也是需要一个非常长的过程 还有包括像刚才 Clark跟Peter提到的 不光是技术团队内部 会有这样的一个挑战 还有包括市场团队和开发团队之间 他们在对齐的时候 大家都需要一个理解的过程

我们也因为这个理解的过程 会浪费一些时间在上面 就比如说 市场团队跟工程团队 有很长的一段时间 可能甚至一个月或两个月 都在来来回回地探讨 怎么样以一个更好的方式工作 这个其实都是 组织的进化它需要一个过程 这个过程一定不是 从第一天开始就这样 所以我觉得这个也是 跟整个AI能力相关的 从过去的一年之内

AI从一个辅助工程师的角色 到参与到开发过程中的一个角色 到现在能够 相对来说 主导开发过程的一个角色 是根据本身基础模型能力的提升 Agent架构的提升 和Agent infrastructure（基础设施）的提升 都是相关的 比如说一年之前如果想让我们说 用AI主导整个的开发过程 我觉得从技术上来说是不成立的

但是从整个重构过程中 我们发现当AI达到这个点的时候 整个的重构 不管是从速度还是从效果上来讲 都是远超于一年之前 能够想象的一个程度 你们是从哪个时间点开始重构的 然后这个重构的时候 整个市场发生了什么 你们做的最核心的几件事情是什么

其实我们意识到需要重构这个事情 可能是去年八九月份的时候 之前的话 我们会花一些时间进行团队的对齐 其实工程师 产品团队和市场团队 大家的思维模式是最重要的 所以我们可能花的最多的时间就是 怎么让大家转变这个思维模式 我们真的开始重构我们的代码架构

整个的开发过程 可能也就是今年1月份的时间 就是今年过年之前 我们在使用了大概两周的时间 就重构了整个我们所有的架构 包括现在大家看到的产品 也是根据这个阶段 重构过程中的这样一个产品 有哪些你们觉得 之前AI解决不了的事情 然后AI解决了 可不可以举两个例子

之前AI解决不了的事情 主要是在规划阶段 比如说我以100分为满分方案的话 它能给我一个90分的方案 我看到这个规划的时候 我能够再给它一些 criticize（评判） 它能够给我一个 revised plan（修改后的方案） 而不需要我真实地去改这个规划 比如说我说 现在这个情况下能打90分的话 一年之前的话可能也就是50分 一个不及格的状态

我可能需要人为地再去 Modify（调整）这个规划 再去改整个架构 但是现在的话 比如说整个我们这个新架构 我可以说我一行代码也没有写 一行文本也没有去改这个规划 我只是在跟它进行交流 我评判 你这个规划是不是有缺陷 是不是优化的 在create（创建）这个规划的时候 你可不可以参考一下 其他流行的开源框架 和Agent框架

你给我一个最终的版本 你觉得它的能力在你之上吗 AI写代码的能力 首先 AI写代码的能力 肯定是在我之上的 规划的能力 2026年我就没有写过一行代码 但是从规划的能力上来讲 作为一个架构师的价值 或者在一个公司里面 不管你是一个CTO 还是一个Tech lead（技术负责人） 你的价值就是在于

找到AI planning的缺陷 所以本身架构师 和不管是Tech lead（技术负责人） 在这个之上还是有价值的 我只能说现在 AI的规划还是有缺陷的 比如说它一开始给我的规划 可能有安全的缺陷 可能有延迟的缺陷 那我根据我之前的架构经验 我怎么能够评判它 或者质疑它 能够进行进一步的提升

然后你们是1月开始做转型的 到现在 你觉得AI 现在再做规划 就是你教给了它 我们要怎么去做这个延迟性 安全性 它现在再做新的计划的时候 它会变得好很多吗 我觉得这个就是Harness的核心 之前我教给它 你在安全性上 在设计sandbox（沙箱） 和host（宿主）之间的关系的时候 你要遵循什么样的准则 这个时候我就可以把它

变成一个Skill 在下一次的过程之中 我只需要引用这个Skill 代替我去说更具体的内容 我说你能不能遵循 我这个principle（原则） 就变成一件很容易的事情了 而且不光是我自己 能够质疑AI 包括所有其他的我们团队的工程师 也可以参考这个Skill 看AI的规划能够遵循之前的 我们的这些原则

可不可以给听众一个直观的印象 你现在有了AI做生产的主力以后 它干出了 配多少员工才能干到的事情 给大家一个数字上的直观的感受 就比如说以前一个团队 他需要20个人做四周 我随便说 现在多长时间就做到了 如果翻到一年之前 我们不是AI主导的情况之下

要研发像Creao现在这样一个产品 我觉得起码需要100人左右的团队 花四五个月的时间 去研发这样一个版本 如果大家看其他的 general Agent（通用智能体）公司的 company size（公司规模） 大概也是这样一个范围 现在是25个人 我们的工程师团队 可能只是10人以下 10人以下 多长时间交付 从产品的第一个阶段的部署

可能也就花了大概两周的时间 两周的时间 10个人以下 对 这个效率提升很高的 从创业公司角度来看 或者说很多SaaS公司 运营一个SaaS产品的时候 你会有个很直观的感受 就是在原来的传统软件时代下 你会发现 销售团队 他们在概念角度来讲 会超前你自己的产品 可能4到5个月 可能大多数你的用户看到的是

你4到5个月之后 才会发布的一些功能 但现在这个情况下它是反过来的 比如说Clark这边的市场团队 会感觉说 我们有很多很多功能甚至都不知道 它已经做完了 技术团队可能是反过来 超前了市场团队 可能3到4个月或4到5个月 更多时候变成市场团队 在追赶开发团队的一些功能 还有安排 这就是一个我们从最外层来看 它最大的一个区别

这个区别就会导致 你的整个运营方式 包括你的整个组织结构 可能都会跟原来不一样 凯也提到了 现在整个技术开发的速度 是大于市场营销速度的 Clark 你这一块会有 从市场营销的层面 也用更多的Agent 因为技术可以用 你们也可以用 我知道代码Agent这两年特别的火 在整个市场的素材生成方面

以及这个素材的产出方面 或者说你其他的一些流程方向 你觉得现在这一块的Agent发展 怎么样了 所以我们现在整个 市场拓展团队 都会用我们自己公司的产品 去构建AI-First的 go-to-market的workflow或者流程 当然这里面有很多坑 我觉得最大的一个困惑就是 Engineering（工程）

它是一个相对比较好 做evaluation（评估） 相对封闭的一个环境 它能够有明确的指标说 今天你干得好还是不好 但是从go-to-market的角度 不管你是写文章也好 做视频也好 你是面向人的消费群体 他对于这个事情价值的认可 和面向Agent或者不同的人群 每个人他都有自己

对这个价值的判断 这个是相对来说比较主观的 那我们怎么样去构建这个系统 能够更好地把这些主观的判断 变成一种信号 让我们的系统能够自动去运转起来 这是一个比较大的挑战 我们也没有说我们今天就是 100%让Agent去做决策 但我们会放很多Agent的结果 再由人去判断说 这个结果好还是不好

我们有很多很多的功能 但我觉得市场还没有准备好 那我们就不会把这些东西 放到市场上面去 我很好奇你们有哪些超前的思想 是市场还没有接受的 每个人的Agent 都有所有的权限可以读写 这个其实是一个相对来说 比较大胆的动作 我们希望说 未来为了能够让你的组织更加高效 你的很多数据

是应该开放给你的Agent 开放给每一个人 但这里面可能还需要 更好的一些技术的支持 包括你怎么样去限制每个人的权限 或者限制Agent权限 怎么样让这个Agent 在读取这些数据的时候 不会出现失误 因为如果它读的数据是错的 或者它自己开始乱搞 那你最后的决策 可能会受到很大的影响 所以这个我觉得

还没有准备推向市场 但是至少我们自己用起来很爽 比如说我原来要说 Peter 今天我们有多少个用户 有这样的行为 可能还要去找做数据的同学 或者工程师 去帮我搭一个新的表格出来 但今天我只需要跟Agent说 我提这个问题 它立刻3秒钟之后给我一个答复 我觉得现在主要的挑战 对于大部分Agent公司来说

不是市场能不能接受这种工作方式 而是市场不知道 这种工作方式的存在 或者他不知道怎么去高效地 使用一个Agent 帮助他能够完成他自己的工作 所以Creao在整个的这个过程中 我们也做了很多工作 就是让用户不用进行复杂的设置 能够更容易 access（访问）这个Agent

帮助他完成他自己本身的工作 这是不是也是你们公司 现在在做的事情 就是让AI自己去创建Agent 对 我把上一个时代的 General Agent（通用智能体） 理解成这些公司会提供一个Agent 用户会使用这个Agent 去帮助他们完成自己的一些工作 但这个Agent 不管把它叫做 General Agent（通用智能体） 还是super Agent（超级智能体） 它是一个unique（唯一）的Agent 所有用户访问的是同一个Agent

而Creao在做的事情就是 我怎么能够让用户在我们的系统上 搭建属于自己的Agent 而且这个Agent是具有 self-improvement（自我改进） self-healing（自我修复）的能力 能够去理解你的工作流 举个例子 你是在做一个广告的活动 你每个周可能都要放一个广告 那通常来说 你可以用其他的通用Agent 每个周去做一个这样的事情

但在Creao上 你的使用方法是 你构建一个属于自己的Agent 比如说这就叫做Campaign Agent 我们会在背后做很多Harness 保证你的这个Campaign Agent 能够持续地提升 它的performance（性能） 能够降低它的成本 在这个过程中 为你产生更多的产出 所以你们对标的场景 跟你们主要的客户是谁 你是对标大企业里面的

工作流程自动化的 还是专业的类似于创业者 或者个人独角兽 类似于这样子的 还是普通的大众 其实它都会有 但是我们真正的目标来讲 还是那些所谓的SMB（中小企业） 还有企业端的那些中小企业的场景 因为这个可能是最早 去adopt（采纳）AI的人群 SMB是什么 SMB就是 Small to Medium Business 就是那些中小型的

可能30个人以内的团队 跟你们公司现在非常像的这些团队 然后他们完全开始 把自己的工作方式 转移成以AI为主导的工作方式 这种是科技公司多 还是说传统公司也可以做这个转型 不管你是科技公司还是传统公司 都能做这样的转型 因为它核心的难点 其实并不一定是在于 取决你的人数和规模

大的企业为什么它难 是因为越大的企业 它会有越来越多的一些合规的问题 还有很多的一些人上面的因素 会导致它的整个过程会非常艰难 但是你一家公司 如果没有太多的所谓的合规 还有包括传统的一些数据库 传统的一些legacy（遗留系统）的 这些东西的话 其实你就是第一批 最容易去做这个转型的公司 所以我们的目标 就是这样的一批公司 是我们核心的这个目标群体

一个公司想要做这样的转型 是不是他们的创始人 也得有一个核心信念 就是相信AI 对 这个是 但是我觉得更多还是他们得搞清楚 这个转型最后代表的什么 我举个最简单的例子 其实在2023年 刚刚大模型出来的时候 很多的SaaS公司想的都是 我怎么把AI做成一个功能 集成到我的产品里面 这个本质来讲是没有搞清楚

如果你要做这样的功能 有没有可能你原来的产品架构 是不支持把这些最新的AI能力 给集成进来的 因为你的数据库可能也不符合要求 你的交互可能也不是 未来的一个方式 所以说你可能需要去做的事情是 整体产品的重构 这个结果如果你接受不了的话 那可能你也很难去做这个转型 所以你们现在 在推广这个概念的过程中

因为现在AI发展得也很快 我觉得很多的企业主 包括中小企业 他们是非常愿意去拥抱AI的 但是我觉得你们整个推行的概念 又过于超前 所以你们自己觉得 市场对你们的反馈是怎么样的 其实从我们现在 用户上面的反馈来讲 我觉得并不是说 我们的概念很超前 这也是为什么我们从组织上的变革 是我们自己在做的事情

我们并没有说 我们所有的客户跟我们一样 去做组织上的改变 而更多是我们把Harness这套系统 变成我们的产品 能够让我们的用户先体验起来 然后在这个过程里面 它再慢慢去思考组织怎么去改变 我觉得Harness还有一个核心 就是说我对某一个领域非常了解 所以我才能给它做各种 更精确的系统上的限定条件

假设你说你对代码领域非常了解 我觉得很权威 但我觉得很少有人说 我可以是每一个领域的专家 我懂每一个领域 这个挑战怎么解决呢 之前的话 你在构建一个自己的Agent 比如说你用Hermes或者OpenClaw 或者Claude Code 你是需要对代码有一定理解的 你才能做这件事情 因为这涉及到很多 Infrastructure（基础设施） 安全性的问题

包括你的工具链怎么接进来 但是对于比如说Creao来说 我们提供一个 云端的服务 你作为一个普通的使用者 你是不需要有很多架构的理解 因为我们把这个架构 已经提供给用户了 用户对自己需要完成的任务 需要有一个深入的理解 但是在这个过程之中 包括怎么接入工具链 怎么去maintain（维护）这个Agent 能够长时间地工作

怎么能够保证安全性 是我们为大家提供的 这样的一个服务 现在 因为我们还是在 利用AI的很早期的阶段 当然有很多的创业公司都在讨论说 我们可能要在某一个垂直场景上 会非常了解 然后我们才能说 我们这块Harness做得很好 但核心是在于 因为我们自己的Creao这家公司 我们也想成为第一批 所谓的AI-First公司

在组织结构调整之后 其实我们是有非常多的基础工作 需要被Agent化的 在这些基础的工作上 首先它可能也并不会涉及到 非常多的非常垂直专业的场景 比如说刚刚Clark说的一些 所谓市场调研这个事情 其实很多的人都需要去做 但是有些人Agent利用得好 他这个系统构建得好的话 那他自己人需要做的事情就会很少 但是如果你的系统 构建得不够好的话

那你人需要做的事情就更多 其实我们的概念 真正我觉得超前的地方 或者说市场现在 没有准备好的地方是在于 如果你真的想把AI 用在你的生产的各个环节上面 首先你的组织结构是要先去变化的 组织结构变化之后 你需要有个系统 去保障这个组织能够稳定地运行 这个就是我们现在构建 Harness这套东西 可不可以讲一下

你们的组织结构是如何发生变化的 比如说以前传统的组织结构 是怎么样 然后现在你们是怎么样 我觉得刚刚过程中 我们举了很多的案例 但是我们还是想知道 一个whole picture（全貌） 整个组织结构变化 我觉得这里面是很多角色的变化 首先 一 如果你要真的做改造 你需要做的第一个点 其实是信任上的变化 原来你组织信任的是人

人本身是这个组织最核心的那一环 但现在当你把AI拿进来之后 你要先解决第一个问题 就是你能不能信任你的AI 做决策或去执行任务 这个信任其实就跟 为什么我们要去 构建一个Harness系统 是一个道理 我们得有很多的 所谓的guardrails（护栏） 还有机制 去保障AI做的所有工作 不管它做决策也好 还是做规划也好 还是做最后的执行也好

最后它的这个东西 是能够被人去信任的 接下来就是你所有的组织结构里面 具体位置的变化 产品经理这个角色 在我们公司其实是 不能说它不存在 而是它被拆解到了 每一个工程师和像Peter这样子的 做工程管理的人身上 而不是专门再有一个单独的角色 去做这个所谓的产品的事情 因为产品经理这个岗位 我并不觉得它不重要

而是在于它在大多数公司 其实是矛盾最集中的那个点 产品经理同时要跟市场的人沟通 也要跟开发人沟通 所有的对齐的成本 很多时候也都会发生在 产品经理的那个角色上面 但当你把这个角色给拿掉之后 你会发现 对齐的成本反而有时候可能会更低 这个前提也是 在于你需要有一套机制能保证 在没有产品经理情况下 团队之间还能互相信任

就决策的信任成本 没有因为没有这个角色了 而变得更高 而是说没有这个角色之后 它会变得更低 所以说这个其实就是 我们在组织上可能跟传统 这些所谓的软件开发公司 会不太一样的地方 产品经理这个角色 你觉得现在还有价值吗 或者说重新招一个 类似于产品经理角色的人 你觉得他需要有什么样的新技能 这个问题应该是这样问

未来需不需要产品经理 它一定需要的 但是未来需要的是 一种新的形态的产品经理 因为你的开发成本在降低 所以产品经理更多的 首先他本身的背景也会发生变化 他做的事情 可能他原来是一个工程师 之后工程师也可以 成为产品经理的角色 更多的人可能能够成为这种 所谓的新型的产品经理 或者说未来还有一种可能

就是他的职位的很多权利 会分散在开发团队的各个人身上 因为如果说你的 每一个开发团队成员 在AI的帮助下 都能够更好地去有产品观念的话 其实你本质来讲 有没有这个职位也不太重要 因为原来产品经理我觉得 他更多解决的是对齐的成本 还有包括 如何帮助公司去降低 这个所谓的开发成本 我可不可以这样理解

现在相当于工程师Peter的团队 他们某种程度上 扮演了产品经理的角色 但是反过来 一个好的产品经理 他其实对市场是非常有想法的 对产品也是非常有想法的 加上现在开发的成本是非常低的 他可能也很容易 就把他的一个想法 通过AI的执行能力 很快变成了一个好的产品

他甚至不需要工程团队了 所以说 其实这两种角色 他某种程度上在融合 在变成一种角色 所以这个角色 到底是一个技术的团队来做 还是一个产品的团队来做 其实不重要 因为都是AI在主导 想法更重要 对 因为会有人觉得说 未来产品经理可能会变得更重要 因为就像您刚刚提到 如果产品经理也能写代码

他可能自己就能构建一个产品 但是一样会有人觉得说 那产品经理 因为他没有很多的技术背景 他就算能构建一个产品 这个产品到底能不能被商业化 我们要打个问号 如果这个产品 真的需要被商业化的时候 可能我们还是需要有工程师 真的能够帮这个产品经理 去把这个产品给构建得 更加能够商业化 未来这个职位本身 它可能不是说一个人

而是一个团队 整体扮演这个产品经理的角色 这个角色本身它会被组织化掉 而不是被个人化掉 在传统软件时代下 有很多个人英雄主义 就说因为某一个产品经理 或一个灵魂人物 导致最后这个产品特别受欢迎 但未来可能是 一个组织做了一个很好的产品 被这个市场接受 我觉得有一个非常明显的趋势就是

复合型人才 或者比较general（通用）的人 他在AI环境之下 可以茁壮成长得更好一些 不管是说一个工程师 他有产品的感知和市场的感知 还是说一个产品经理他具有 implementation（实现）的能力 都会非常的重要 刚才一直在谈产品经理 其实有另外一些角色 像designer（设计师） 不管是前端的设计师 还是用户体验设计师

如果你问我未来的产品之中 什么是最重要的 可能这两个角色 会变得非常的重要 但是我们在讨论这两个角色的时候 不是说传统的 不具备编程或者实现能力的设计师 而是具有能够把自己的想法 Implement（落地）到产品之中的 这些UX和UI designer 这些人会变得非常重要 包括产品经理 同样的事情

未来的产品需要有产品的感知 那这些产品的感知来源于谁 其实并不重要 但是有一点是非常重要的 这个人必须具有执行的能力 就他能把他的想法直接 在1到2个小时之内的时间 就带到产品之中 如果你需要 把你的想法传递给另外一个人 或者另外一个工程师 那你交流或对齐的成本

就远大于你执行的成本 在整个的AI的工作环境之下 就变得不是那么的高效 Peter 你有一篇文章我印象很深 你说其实在你真的做这一系列的 组织架构的变化过程中 你意识到初级的工程师 是比资深的工程师 更能适应AI的这个环境的 因为初级的工程师

不管说他的技术债务 或者他的思想的束缚 通常来说比较小 他能够接受他的 expand（扩展）他的scope（范围） 他不仅是作为一个工程师 包括他要融入到 一些产品的设计之中 包括产品 他的feature deploy（功能部署）之后 他还需要做一些分析 他根据分析能够做出 他这样的一个判断 但通常来讲 比较高级的工程师

因为他比较specialize（专精） 比如说你是一个 做基础设施的人 或者你是一个做后端的人 你可能在传统的工作环境之中 你不关心你的代码 发布之后发生的事情 但是在AI这个环境之下 你的工程师的范围 就需要比之前扩大很多 就不只是在 我把这个代码写完之后就结束了 而是在于我代码写之前

我怎么能够 把自己的judgment（判断）加进去 代码发布之后 怎么能够判断它的impact（影响） 整个这个过程是非常重要的 通常来讲初级工程师 能够更好地接受 这样的一种工作状态 比如说你跟一个资深工程师说 除了负责前面 你代码已经交完了的这个过程 你还要负责后面的这个过程 他们是不能理解

跟马上去转变这个思想的 通常来讲需要对齐 这个思维模式的成本要高很多 其实作为一个高级工程师 或者作为一个专业领域的 不管你是做基础设施的人 还是前端还是前端的人 在过去的软件开发过程之中 你的知识是非常有价值的 因为你能够知道 在开发这个系统之中

怎么样写最简洁的代码 怎么样设计最好的架构 你可能需要两三个月的时间 去完成这样一个事情 但是在AI这个环境之下 因为AI编程 在现阶段它已经很强了 以后会变得更强 所以它会让你本身的specialty（专长） 变得越来越低 所以很多人可能接受不了 这样一种状态 就是他本身花了10年 20年时间 学到的这样一些知识

变得可能在未来并不那么重要 所以你们现在更倾向于 招哪一类的人 我拿工程师来举一个例子 比如说初级的人 他可能面临的问题是 他在代码领域 基础没有那么的扎实了 因为大家现在都已经用AI写代码了 可能你真的 比如说这个AI系统突然关机了 他们自己可能就写不了了

而且如果你的代码基础不扎实的话 你在判断它出问题的时候 你的专业知识 也会稍微的差那么一点点 但是对于很多资深的工程师来说 他们依然非常的稀缺 因为他们还是有非常扎实的 工程的基础 但是 他们可能在转变 跟适应AI思维上 他并没有年轻人那么快 我文章中虽然提到

转变一个资深工程师的难度 要比一个相对来说 初级工程师的难度要大 但是从价值上来讲 一个资深的工程师的价值 现在是不能被取代的 所以怎么能够找到一个 资深的工程师 他还能够embrace（拥抱） AI的思维模式 而且他能够具有一个产品的感知

他能够还知道一些市场的知识 这个人虽然很难找 但是对于公司来说是非常有价值的 好处是在于 之前我们可能需要很多这样的人 在没有AI的情况之下 但是现在 我们可能只需要一到两个人 就可以了 “很多” 是多少 10个 我觉得10倍或者50倍以上的人 在没有AI辅助的情况之下 但我觉得这样的人是不是

也还比较好找 是因为我最近看见硅谷的趋势是 所有人都在开始用AI 所有人都在开始比 这个AI生成代码的数量 大家也在很积极地 去适应这个新时代 新环境 我们可能通常会发现 有很多人是这样子的一个心态 但是有这样的心态 跟在工作时候愿意去相信AI

真的把所谓的Harness这些系统 去构建起来 就是我相信它 跟我愿意花时间去构建一个系统 能帮助我更好地用AI去工作 这是完全两码的事情 很多人会发现 他愿意拥抱AI 只是在于他愿意用AI的工具 去给自己提升效率 但他并不愿意说 我去构建一个系统 真的能让未来我的工作 完全由AI来驱动 我在里面可能扮演角色

都可能发生变化了 这是两种完全不一样的心态 其实后面那种更激进的 那个心态的工程师也好 或说做市场的人也好 或者说做任何事情的人也好 相对来讲 在现在这个阶段 这个思想还是相对来讲比较超前的 这样的人还是少数 现在更多人更接受还是在于 我愿意去尝试用AI工具 或拥抱AI的能力 但是我还没有到真的 我希望做到 AI-First这个角度来讲 这样的人是比较少的

另外从一个角度上来讲 我认识的很多朋友 其实他本身的能力很强 他也有很强的架构能力 然后他也愿意拥抱AI 但通常很多这样的人 他会自己出来创业 对于一个初创公司 你想雇佣这种人 其实现在难度还是比较大的 是 Peter 你是从什么时候 开始相信AI的 我觉得凯今天给我 特别大的一个震撼 就是“相信AI”这四个字

如果你问我的话 我其实从一开始刚毕业的时候 我就是在做AI 所以我肯定会 你是哪一年毕业的 我是 我是哪一年毕业的 我应该是2018年（毕业）吧 毕业我们肯定不会记得那么清楚 我可能是 具体我记不清了 但是可能是10年之前的事情 我第一个在苹果做的工作 就是在做AI方面的工作

而且就是和语言模型相关的 所以我肯定是从一开始 就相信AI能够改变这个世界的 那个时候大模型还没出来 然后那个时候 我们在提到AI的时候 跟今天我们提到AI的时候 是完全不一样的 包括我觉得那个时候 AI给人的思想上的冲击 说我们是不是要把工作 彻底地交给AI 跟今天也是不一样的 但是那个时候虽然没有大模型

但是非常重要的一篇paper（论文） 就是《Attention is All You Need》 包括之前BERT的出现 正好是我刚开始工作的时候 在那个时候我就意识到了 pre-training（预训练）的重要性 包括对于我当时在苹果做的一些 traffic prediction的工作 我就已经开始利用 pre-training（预训练） 因为之前的预训练只是在文字上的预训练 我会在traffic signal（交通信号） 上的预训练

是同样利用了类似的概念 做这样的事情 所以可能是因为 你的工作经历的关系 你一出来 甚至是你还没有出来 就你一直都觉得AI它是比人强的 我没有说AI会一直比人强 就哪怕是现在这个阶段 就在一些具体的点上 AI也不能够取代人来做任何的事情 但是在未来

或者在现在这样一个阶段 AI已经能够主导很多事情 包括在架构的过程之中 AI是很强 但是你让AI系统能够运转起来 还是需要人去进行架构的 我们刚刚其实有聊 未来要招什么样的人 你觉得现在我们说 AI为主力干活 AI可以迭代产品 所有的东西都是动态的

大家觉得未来 人 他最核心的能力是什么呢 我觉得最大 人需要的能力 就是系统架构的能力 从以前implement feature（开发功能） 变成怎么架构这个AI系统 和maintain（维护）这个AI系统 这是工程师的角度 不管是工程师还是市场的角度 那你做go-to-market（市场拓展） 怎么搭建一套能够自主运行的 Agent的市场系统 也是核心的过程

而不是说只是单纯地产生一个 marketing content（市场内容） 这个话是说 人的价值 如果从真的很长远来看 就跟我们技术发展整个过程一样 确定技术发展方向 永远是人的需求和这个社会的需求 只要人这个物种还存在 他的价值是不太会变化的 他定义的是需求的方向 和技术迭代的方向 因为它永远要为这个物种去服务

如果没有人在这个上面的价值的话 那就代表AI是自己在发展 它自己就是一个物种了 变成 这就是一个哲学问题 基于我们定义了需求 我一样就需要去看最后的结果 是不是我想要的 所以在未来系统里面 人还有一个很重要的价值 是我复盘最后的结果 去看这个结果是不是 真的符合我们的利益 或符合我们的要求 人在需求的定义

和最终的结果的审核上的价值是 没有办法被取代的 除非说人作为这个物种 本身的重要性已经不存在了 那这是另外一回事情 我看最近应该是DeepMind 他们已经开始设立哲学家的岗位了 对 职位就叫“哲学家” 对 是 当然这里面有非常多的问题 包括如果我们真的把AI引进到 Agent真的能替代人工作 那还有一个道德问题是在于

Agent和其他的Agent也好 其他人之间也好 也会有沟通 它沟通的这些内容到底 比如说我作为另外一个人 能不能去看 是不是侵犯他的隐私呢 这里面会有非常多道德问题 它都是跟未来组织 这些关系都相关的 Clark 我觉得其实刚刚凯讲得挺好的 因为我自己觉得人未来的价值 就是判断任何事情是否还有价值 对于价值的定义

可能就是人最大的价值 价值的定义本身延伸出来的东西 就是我们怎么样 定义自己的需求是什么 当我们知道自己想要什么的时候 才能判断这件事情是否有价值 我觉得这个就是人的价值 你们对未来整体是更悲观 还是更乐观 我是说完全抛开企业 就是作为人来说 我自己还是相对乐观的 其实很多时候

大家探讨人为什么快乐 我自己现在工作还挺快乐 就是因为我虽然在工作中 跟AI的配合 会导致我的工作的内容 和工作的程度 会比之前要强很多 但是当我不工作的时候 我在享受自然 爬山也好 还是去做一些户外运动的时候也好

我可能会更加的放松 所以我觉得相对来说是比较乐观 可能AI给我们带来的价值就是 比如说我们原来经常说你 努力工作 尽情玩耍 它可能可以反而更好地 帮我去做工作和生活上的切割 主要我们做创业的话 我们肯定是乐观的 如果悲观的话 大家今天也不会出来创业了 对于未来肯定还是 相对来讲比较乐观的 但是就像我们刚才聊的

因为跟上一次工业革命一样 当时有很多的纺织工人也好 车夫也好 可能都被取代掉了 但是随着那个阶段过去之后 人会找到新的方向 去实现更大的自我价值 所以说 未来的话 它一定是一个更好的世界 只不过这个世界是不是跟 现在大家所定义的这个幸福一样 那可能是不一样的 这个可能是未来会有的 一个比较大的变化

我觉得我还是非常谨慎的乐观的 因为我觉得 在这个变革的过程之中 会有很多痛苦 会有很多noise（噪音） 但是这个变革的结果 我还是相信它是一个好的结果 就是人能够更多地有 不管说是自由的时间 还是能够发挥出自己更大的价值 在AI的辅助之下 好的 谢谢各位 好的 感谢三位的分享

我们今天聊了很多有意思的内容 比如说产品与工程的边界在消失 SaaS产品它本身也在重构 我想三位的观点 可能对很多的普通听众来说 它是有一点点超前的 但是我觉得 这种一线亲历者的视角 恰好是大模型时代 最稀缺的内容之一 大家对未来公司的组织形态

有什么样的思考 欢迎给我们写评论 写留言 我们未来还会从更多的角度 持续地关注这个话题 如果大家喜欢我们的播客 可以在小宇宙 苹果播客 YouTube 哔哩哔哩 小红书 和视频号上收听 关注我们 我是泓君 感谢大家的收听