软件介绍

精品aaa使用指南

第一步：导入文件

打开软件，点击"?增长 精品aaa"按钮，从电脑当选择《精品aaa》文件，或直接将其拖拽至软件界面中。

第二步：配置解析

软件会自动鉴别并解析导入的文件，您可凭据界面提醒选择所需的保留蹊径或下载体式。

第三步：起头下载

确认无误后，点击"起头下载/处置"按钮。期待进度条读取结束，即可在设定的文件夹中查看下载好的正版文件。

聊聊Harness时期AI-First的组织架构：从信赖人到信赖AI，精品aaa

（点击收听本期音频）

采访｜泓君

图文｜朱婕

“Harness Engineering”（挽具工程）在成为硅谷的新共识，Anthropic、OpenAI等公司都在索求这一工程范式。但真正理解Harness的人还不多。前不久，一篇题为《Why Your “AI-First” Strategy Is Probably Wrong》的文章在X上获得百万级阅读和热议，作者是来自硅谷CreaoAI的Peter Pang。在这篇文章里，Peter展示了Harness Agent系统引发出的极致效能：99%的代码由AI实现，每天均匀3到8次出产部署，从前六周的产品流程，此刻一天就能跑完。

本期《硅谷101》播客，主播泓君约请到Creao的三位首创人，聊聊这家公司对Harness的实际，以及在组织AI-First转型上的深度思虑。嘉宾们指出，AI-First不蹬宗“使用AI”，想要把效能提升100倍、1000倍，就不能只把AI当成工具，而要让AI成为所有出产力的主导。组织转型最难跨出的一步在于——是否能让所有员工都能做到信赖AI。

这场对话中有一些有趣的观察，好比在Creao，市场不用再追着开发提需要，由于开发速度已经远超市场消化能力；当大量对齐工作被AI收受之后，拿掉产品经理，反而让团队效能大幅提升；低级工程师比资深工程师更适应AI时期的转型；只管从前十年堆集的专长在急剧贬值，但资深工程师依然有竞争力，由于将来的主题竞争力不再是写代码，而是“找到AI Planning的缺点”和“判断什么是有价值的”。

迎接关注《硅谷101视频号》的音坡犯目直接管听本期播客。如 果 你喜欢k8凯发天生赢家 节目，更推 荐各人使用 音频客户端来收听，《硅谷101 》已覆盖各大 主流音频 平台（渠路见文末），迎接订阅！

以下是这次对话内容的精。

Harness工程详解

若何把大模型“榨”出极限

泓君：先请Peter介绍一下，什么是Harness engineering （ 挽具工 程） 
？

Peter：Harness的概想能够追忆到大模型刚起头的时辰，好多人在聊prompt engineering（提醒词工程），之后演变到context engineering（高低文工程），这时辰更多的是聚焦在怎么和大模型自身进行交互。

但是对于Harness来讲，我们是在“驯化”一个通用的系统，所以从领域上来讲，它比prompt & context engineering要大好多，涉及到tooling（工具链）的使用，涉及到你的sandbox（沙箱）的架构设计，你的host service（宿主服务）之间是怎么进行交互的
？怎么样的交互可能安全
？你的sandbox在启动的功夫是几多
？你的延长是几多
？……这些都是harness的一部门。

泓君：可不成以理解成，Harness的工程能力决定了怎么把一个大模型“榨出”最佳使用上限
？我记得Kai有提到，一个Agent能够一夜之间干掉三幼我做SEO（搜索引擎优化）的工作流；同时还有一个内容流水线，它跑了两天，才有人发现满是垃圾。这两者之间有巨大区别——一个是Harness的成功，一个是Harness的失败。

Peter：我感触这个齐全就印证了为什么我们必要Harness。Harness的性质就是在于，我们怎么可能持续提升一个系统。当你这个系统产生的成效不好的时辰，你这个系统是必要人的feedback（反。┤ヌ嵘，还是这个系统自身自己可能self healing（自我建复）、self improvement（自我优化），这个正好就是Harness的主题。

Harness很重要的一件事件，就是怎么可能让Agent在推理阶段scaling（扩大），蕴含你怎么可能把更多的高低文、工具链提供给它，让它思虑更长的功夫，实现一个工作，用一个更长的功夫。在这个阶段若是你的Harness做得不好，就很容易产生hallucination（幻觉）或者context overflow（高低文溢出），你的模型能力会降级。所以Harness是一件极度复杂并且必要一些经验的事件。

泓君：那今天市场上对Harness有哪些共识和非共识
？

Peter：好多人以为Harness是静态的，就是开发配套系统阐扬LLM优势。但我们以为它是一个动态的过程——你这个系统怎么可能从一个静态的状态真的活起来，可能self-improve（自我优化），可能一向地适配来自市场、产品、用户的各类signal，可能让它一向地、迅速地迭代。我感触这个是可能好多人还没有意识到的一点。

泓君：这个迭代也是以AI为主导的，而不是报答主导的
？

Peter：对，是以AI为主导的迭代。人所必要做的事件，就是怎么把各类各样的信号feed给AI。

六周变一天

AI驱动的开发流程有多快
？

泓君：你有一篇很火的推特帖子，讲你们25人的公司，99%的代码由AI写，早上10点写了一个职能，中午就进行了A/B test，下午3点就凭据数据的反馈把它砍掉了一部门职能，5点又重写了更好的一个版本。这是一天的工作节拍，在传统的开发产品的过程中，它是必要6周的。这是你们用Harness索求出来的方式。

Peter：在我们看来，Harness分为两个部门：一是对Creao自身Agent系统的Harness，二是用户用Creao构建自己Agent时，怎么助他Harness自己的Agent。传统开发过程中，可能要用两三个月迭代一个职能，此刻AI辅助coding只需一两幼时实现，若是还用很长功夫去设计和测试，就不是很有意思。所以怎么把设计、规划、测试都蕴含到整个Harness过程中，对公司能不能转型为AI-First至关重要。

Clark：我想先跟各人表白一个概想：若是想做到所谓的AI-First或者AI native（AI原生）这样一个状态，它不是在现有流程上去使用AI工具，而是要萦绕AI能力重新构建工作流程和组织状态。

图片起源：Peter Pang@intuitiveml

我们在之前很长一段功夫里，每一个工程师都在用AI写代码，每一个产品经理都在用AI写PRD（产品需要文档），每一个设计师都在用AI做图。但其实这样并没有增长k8凯发天生赢家效能，反而导致每一幼我的工作进度和节拍不一样之后，k8凯发天生赢家alignment（对齐）成本变得极度高，我们还是全数远程办公的状态。

所以我们要去重新想，我们到底怎么样能力让AI在公司运营过程中真正地自动化跑起来，才有了Peter设计的一套新的开发流程和架构和新的产品的架构重构，才有了这篇文章里面讲的self-healing（自我建复）的Agent Harness。

泓君：可不成以举个例子，你们重塑组织架构时，哪些方向发生了变动
？瓶颈在哪里
？

Peter：首先必要解决人的问题——各人能否接受新工作方式。我们花好多功夫对齐mindset（思想模式）。以前做这样一个转型，通常必要一个架构师或工程师破费好几个月来demonstrate（展示）新的工作方式更优，但这个转型成本就很大。

此刻在AI辅助下，这个过程就会快好多，可能只必要一两周把整个系统，蕴含前端、后端、架构、基础设施，都进行重构，而后给各人展示它工作起来更高效。不论是部署的频率、部署的靠得住性和最后的成效上，都比之前的工作方式有很大提升。这样能在很短功夫内对齐思想模式，让各人急剧融入到整个开发过程。

Kai：其实Harness自身它更多是在于构建一个系统，真的能让所谓的AI-First的组织高效运行。好多组织上的人，思想难以扭转，他感触用AI提升效能就够了。但是AI-First要求的是，你让AI来driven（驱动）你整个公司的方向，可能你每天工作的方式都是由AI来驱动的，这是齐全不一样的概想。

泓君：是AI给你们安插工作吗
？

Kai：对。若是还把AI当成一个提升效能的工具，那使用者的效能提升可能最多就是10倍，由于人最多每天可能就工作24幼时。若是但愿效能提升100倍、1000倍，你不能说你是那个工具的使用者，而是AI应该是所有出产力的主导。人的角色发生变动，更多是在于怎么去复盘了局的曲直；褂性谡飧鱿低忱，我并不是那个现实的工作者，我应该以怎么的一个方式去跟这个系统共同起来
？这是好多企业在做转型时，没意识到或很难去做到的事件。

泓君：举个例子，你们的系统怎么和人去共同工作
？我感触传统的团队开发产品的时辰，可能很大的一个痛点就是说，我团队之间要对齐，而后我要把信息同步到每一幼我，任何一幼我他可能miss掉了一个信息点，那他在产品做开发的时辰，可能就不知路我们上一版的更新是什么。此刻是不是所有的这些工作都能够交给AI，或者在这个流程中它就能够自动去做了
？

Kai：我感触这里面主题还是信赖的问题。好多人对系统不信赖，所以对齐成本就极度高。此刻AI-First下，对齐由AI主导，好比AI通知市场团队今天工程师要颁布哪些职能，市场团队不用再反复问工程师。

泓君：AI怎么知路工程师团队明天能把所有的工作做完
？

Peter：在AI的思想模式之下，迭代一个产品的过程中，我们更侧重的是，这个新的职能能不成能带来产品的top line metrics（顶层指标）的提升，或者新的这个职能能不能有真的用户使用的数据。所以在这个过程中，我们更主题聚焦怎么把整个数据链搭建起来。我们把这个链条搭建起来之后，都是Agent通过这些数据来决定，好，这个职能到底是不是有效的，我们到底要不要roll out（上线）这个职能，或者fall back（回退）这个职能。

泓君：也就是说工程师写完代码以来，不必要手动地跟AI说“我写完了”，此刻AI它就能够自动地凭据你的整个代码质量，你的过程，去做出它的判断。

Peter：对，这个在传统的工程中也有，我们叫CI/CD process（持续集成/持续部署流程）。只不外在传统的CI/CD process中，好多都是rule-based（基于规定）或者一些unit testing（单元测试）驱动的。但是在AI这个情况之下，我们能够有好多AI驱动的测试。好比此刻各人比力常用的像Playwright，是能够做AI驱动的齐全的end-to-end testing（端到端测试），这样能够保障我们颁布的代码中没有显著的能够粉碎这个产品的bug。所以在这个过程中，好多AI驱动的测试是极度重要的。蕴含你代码颁布之后，在这个日志中有没有error，有没有incident，都是通过这些信号可能反馈给AI，来看整个这个代码的质量是什么样子的。

泓君：关于让AI写代码，怎么保障它的质量
？Peter的文章提到了，正常情况下写代码一天，各人建bug要三天。此刻有什么新伎俩，能够让各人不用把好多的功夫都花在建复上
？

Peter：我觉的bug是整个工程中不成预防的，不论AI写还是人写。由于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。

图片起源：Peter Pang@intuitiveml

泓君：你感触在你引入这两套系统以来，它的效能提升了几多
？

Peter：由于好多都是Agent-driven，所以它能够并行地进行，能够有好多Agent同时去identify（辨认）。它发现一个bug只需1-2分钟，指派给工程师几秒钟。工程师再用Agent调查并提出规划，整个cycle约莫1-2幼时。对比之前，我们鉴别、建复一个bug，再把它颁布到系统中，可能必要一周的功夫。

Clark：对，这里面有一个出格有意思的景象。我们以前有一个feature wish list（职能欲望清单），很长，又有一个bug list，有好多bug要建复。以前市场和产品还有工程师就总是会商来会商去：到底是先建bug还是先做职能
？此刻这两个清单都没有了，bug实时发现，实时建复，feature此刻的数量远远多过于我们所必要的数量。

Peter：我们此刻有一个auto-fixing（自动建复）系统。对于我要建复的一些器材，若是只是存在于一些风险比力幼的文件夹之下的话，AI自动提交PR（拉取要求），工程师单一核准即可颁布。此刻50%以上的问题是通过auto-fixing实现的。

架构师：Harness中的主题角色

泓君：由于我不太懂写代码，只能用写文章做迸作。如果我是在改一篇稿子，即便它只出现了一个幼谬误，我可能必要把整个稿子看一遍，那这个功夫跟我自己重新写，花的功夫是差不多的。若是Agent助你搭了一个极度好的技术框架，但在基础层出了大谬误，必要工程师解决，工程师是不是得把整个系统重新学一遍
？

Peter：我感触这个问题很好。在之前的我的文章中，我也会商了在AI环境之下的工程团队可能分为两种人：一种是architect（架构师），一种是operator（操作者）。架构师在整个这个系统搭建过程中的作用是极度重要的。好比说在搭建整个Creao的系统过程之中，整个Agent的架构是什么样子，好比说sandbox（沙箱）和host（宿主）之间是怎么交互的，还是由架构师来决定的。

若是说Agent直接通过AI coding或者vibe coding（氛围编程）的方式，给你一个solution（解决规划），但这个解决规划通；嵊邪踩囊患或者延长的隐患。怎么去优化整个这个系统，还是由架构师来决定的。区别在于，传统搭建Agent的团队以前可能必要10到20幼我，但是此刻搭建整个这样一个系统只必要一个架构师，在一个周的功夫之内就能实现。

Clark：我来补充一下。AI能力早就很强了，但为什么还没达到人们的预期
？人们感触AI没干好，我还得助它添补谬误。这里必要有一个概想上的转变：我们要把AI当成一个系统来对待，而不是一个智能。当系统犯错时，不要想着纠正这个智能，而要想着添补这个系统。这个其实是我们在做Harness跟此刻普遍的认知最不一样的处所，它是一个动态扭转和提升的过程，不是静态的、固定的镣铐去约束这个智能，要给它提供空间，让它可能成长。这个成长的方式就如同你在养一个孩子，让它在一个规定内越来越好。

泓君：这个概想很有意思，以前是“解决问题”，此刻是“解决系统上的问题”。

Clark：这里面还有一个更激进的设法，我们自己发的这些内容，可能将来的这些受多并不愿定是人。好比一个市场部门的物料，可能从人的审美上去看它并不好。但现实上你把这个器材投向市场的时辰，你会发现，读这篇文章或者读这个图片的是一个Agent在读，它的数据反馈回来，可能是更好的。

以来可能买器材是由Agent去买，订报纸是由Agent去订……那你的告白是发给Agent看，还是发给人看
？你要搞明显你的工作了局到底是被谁消费，针对这个器材的价值，我们再去思虑，到底是提升系统，还是回到最原始的人的创作过程中去添补一些谬误。

泓君：我相信在将来做消费决策的时辰，可能还是Agent看得多。但是它来得比我预期中要快好多，整个进化还是极度的快的。

Peter：从另表一个角度上来讲，也能够很显著地看到此刻SaaS产品的转型。由于以前好多SaaS产品，它必要一个给人去看、去治理的dashboard（仪表盘）。但是在至少此刻这个阶段，我们团队在使用工作治理的时辰，我们更关切的是Agent能不能“看到”并prioritize（设定优先级）这些工作。所以我们会去看这些工作治理产品有没有更好的MCP（模型高低文和谈）和API（利用法式接口）提供给k8凯发天生赢家Agent使用。

泓君：所以整个进化还长短
？斓。

Kai：其实刚才您提到这个问题，也是好多公司在做AI转型时辰会第一个思考的问题，他感触使用AI的时辰，我还要review一遍，那跟我人去做功夫和成本没差距。但若是真把AI系统构建起来，仔细算一下，功夫和成本会有很大提升。只是这个过程必要整个团队有共同指标，只有有人感触还不如人做，刷新功夫就会被拉长。这是大无数企业从组织上面对的挑战。

转型最难的一步

从信赖人，到信赖AI

泓君：你们是第一天就AI-First，还是后来摸索的
？

Kai：我们整个公司也是有一个过程的，你要意识到谁是将来的出产力的主题的角色。2025年上半年，各人还是感触AI是辅助人去做事件，人在工作中占主导职位。但是到了下半年，我们意识到，若是还是这样，企业效能提升还是极度有限的。主题问题是没有把出产力工具的使用者真正从人转变到AI。这种转变必要功夫，市场团队和工程团队甚至花了一两个月来来回回探求怎么是更好的工作方式。

Peter：我感触这也是跟AI能力提升有关的，从前一年内，AI从辅助角色，到参加开发，再到此刻可能相对来说主导开发过程，角色的转变是和基础模型能力提升、Agent架构和基础设施的提升有关的。一年前让AI主导开发从技术上来说不成立，但在我们重构过程中，当发现AI达到了那一个点的时辰，整个重构速度和成效远超一年前可能设想的水平。

泓君：你们是从什么功夫点起头重构的
？做了哪几件主题的事
？

Peter：意识到必要重构是去年八九月份，花的最多的功夫就是让各人转变思想方式。真正起头重构代码架构和开发过程是今年1月，用了或许两周，重构了整个架构，蕴含此刻各人看到的产品。

泓君：有哪些你们感触之前AI解决不了的事件，而后AI解决了
？

Peter：之前AI解决不了的事件重要是在规划（Planning）阶段。好比说我以100分为满分规划的话，此刻它能给我一个90分的规划。我看到这个规划的时辰，我可能再给它一些criticize（评价），它可能给我一个revised plan（批改后的规划），而不必要我真实地去改这个规划。一年之前的话可能也就是50分，我可能必要报答地再去modify（调整）这个规划，再去改整个架构。

泓君：你感触AI写代码的能力在你之上吗
？

Peter：首先，AI写代码的能力注定是在我之上的，2026年我就没有写过一行代码。但是从规划的能力上来讲，作为一个架构师的价值，不论你是一个CTO还是一个技术掌管人，你的价值就是在于找到AI planning的缺点。此刻AI的规划还是出缺点的，好比说它一路头给我的规划可能有安全的缺点，可能有延长的缺点。那我凭据我之前的架构经验，我怎么可能评价它或者质疑它，可能进前进一步的提升。

泓君：你教了它，要怎么去做这个延长性，安全性，它此刻再做新的规划会变得好好多吗
？

Peter：这个就是Harness的主题。之前我教给它，你在安全性上，在设计sandbox和host之间的关系的时辰，你要遵循什么样的准则。这个时辰我就能够把它造成一个Skill，鄙人一次的过程之中，我只必要引用这个Skill，包办我去说更具体的内容，就造成一件很容易的事件了。所有其他的我们团队的工程师，也能够参考这个Skill。

泓君：可不成以给听多一个直观的印象
？你此刻有了AI做出产的主力以来，它干出了配几多员工能力干到的事件
？给各人一个数字上的直观的感触。

Peter：若是翻到一年之前，不是AI主导的情况之下，要研发像Creao此刻这样一个产品，我感触至少必要100人左右的团队，花四五个月的功夫去研发这样一个版本。若是各人看其他的general Agent（通用智能体）公司的规模，或许也是这样一个领域。此刻公司25人，工程师团队10人以下，从产品第一个阶段的部署只花了约两周。

Kai：从SaaS公司运营一个SaaS产品的角度来看，你会有个很直观的感触。传统软件时期，销售团队的概想会超前产品4-5个月；此刻反过来了，技术团队反过来超前了市场团队4-5个月，市场团队在追赶开发的职能。这会导致整个运营和组织结构可能都跟原来不一样。

泓君：Clark，你这一块会有从市场营销的层面也用更多的Agent吗
？

Clark：市场拓展团队会用我们自己公司的产品去构建AI-First的workflow。当然这里面有好多坑。我感触最大的一个猜疑就是：Engineering相对好做评估，它可能有明确的指标说今天你干得好还是不好。但是从go-to-market的角度，不论你是写文章也好，做视频也好，每幼我他都有自己对这个价值的判断，相对比力主观。那我们怎么样去构建这个系统，可能更好地把这些主观的判断造成一种信号，让k8凯发天生赢家系统可能自动去运行起来，这是一个比力大的挑战。我们也没有说我们今天就是100%让Agent去做决策，但我们会放好多Agent的了局，再由人去判断说这个了局好还是不好。我们有好多职能，但我感触市场还没有筹备好，那我们就不会把这些器材放到市场上面去。

为什么大企业难转型
？

中幼企业的AI盈利期

泓君：我很好奇你们有哪些超前的思想是市场还没有接受的
？

Clark：每幼我的Agent都有所有的权限能够读写，这个其实是一个相对来说比力斗胆的作为。我们但愿说，将来为了可能让你的组织越发高效，你的很无数据是应该盛开给你的Agent，盛开给每一幼我。但这里面可能还必要更好的一些技术的支持，蕴含你怎么样去限度每幼我的权限，或者限度Agent权限，怎么样让这个Agent在读取这些数据的时辰不会出现失误。好比说我原来要说“Peter，今天我们有几多个用户，有这样的行为”，可能还要去找做数据的同学或者工程师去助我搭一个新的表格出来。但今天我只必要跟Agent说，我提这个问题，它立刻3秒钟之后给我一个回答。

Peter：我感触此刻重要的挑战，不是市场能不能接受这种工作方式，而是市场不知路这种工作方式的存在，或者他不知路怎么去高效地使用一个Agent援手他可能实现他自己的工作。所以Creao在整个的这个过程中，我们也做了好多工作，就是让用户不用进行复杂的设置，可能更容易接见这个Agent，援手他实现他自己自身的工作。

泓君：所以你们对标的场景跟你们重要的客户是谁
？你是对标大企衣凤面的工作流程自动化的，还是创业者或者幼我，还是通常的公共
？

Kai：城市有。但我们真正的指标，还是那些所谓的SMB（Small to Medium Business，中幼企业），由于这个可能是最早去选取AI的人群。越大的企业合规的问题越多，还有好多的“人”的成分，会导致它的整个过程会极度艰巨。但是若是一家公司若是没有太多的合规问题，没有一些传统的legacy（遗留系统），其实你就是第一批最容易去做这个转型的公司。

图片起源：Pixabay

泓君：一个公司想要做这样的转型，是不是他们的首创人也得有一个主题信想，就是相信AI
？

Kai：对。更多还是他们得搞明显，这个转型最后世表的是什么。我举个例子，在2023年刚刚大模型出来的时辰，好多的SaaS公司想的都是我怎么把AI做成一个职能集成到我的产品里面。这个性质来讲是没有搞明显：若是你要做这样的职能，有没有可能你原来的产品架构是不支持把这些最新的AI能力给集成进来的
？由于你的数据库可能也不切合要求，你的交互可能也不是将来的一个方式。所以说你可能必要去做的事件是整体产品的重构。若是接受不了这个了局，那可能也很难去做这个转型。

当AI主导出产

人类的新角色是什么
？

泓君：可不成以讲一下你们的组织结构是若何发生变动的
？刚刚举了好多的案例，但是我还是想知路一个whole picture。

Kai：整个组织结构变动，我感触这里面是好多角色的变动。首先，若是你真的要搞刷新，你必要做的第一个点其实是信赖上的变动。原来你组织信赖的是人，但此刻当你把AI拿进来之后，你要先解决第一个问题：就是你能不能信赖你的AI做决策或去执行工作。这个信赖其实就跟为什么我们要去构建一个Harness系统是一个路理，我们得有好多guardrails（护栏）还有机造，去保险AI做的所有工作，不论它做决策、规划、还是执行，最后它的这个器材是可能被人去信赖的。

接下来就是你所有的组织结构里面具体地位的变动。我们没有单独的产品经理这样的角色了，他被拆解到了每一个工程师和像Peter这样子的做工程治理的人身上。这个岗位我并不感触它不重要，而是在于他通常是矛盾最集中的那个点。产品经理同时要跟市场沟通，跟开发沟通。大量的对齐成本都发生在产品经理的角色上面。但当你把这个角色给拿掉之后，你会发现，对齐的成本反而有时辰可能会更低。

泓君：产品经理这个角色，你感触此刻还有价值吗
？或者说重新招一个类似于产品经理角色的人，你感触他必要有什么样的新技术
？

Kai：将来需不必要产品经理
？肯定必要的。将来有一种可能，就是产品经理职位的好多权势会分散在开发团队的各幼我身上。由于若是说你的每一个开发团队成员在AI的援手下都可能更好地去有产品观点的话，其实你性质来讲有没有这个职位也不太重要。由于原来产品经理我感触他更多解决的是对齐的成本，还有若何援手公司去降低开发成本。

泓君：我可不成以这样理解：此刻相当于工程师Peter的团队，他们某种水平上表演了产品经理的角色。但是反过来，一个好的产品经理，他其实对市场、对产品也是极度有设法的。加上此刻开发的成本是极度低的，他可能也很容易就把他的一个设法通过AI的执行能力很快造成了一个好的产品。他甚至不必要工程团队了。所以说，其实这两种角色他某种水平上在融合，在造成一种角色。所以这个角色到底是一个技术的团队来做，还是一个产品的团队来做，其实不重要，由于都是AI在主导，设法更重要。

Kai：对。将来这个职位自身，它可能不是说一幼我，而是一个团队整体表演这个产品经理的角色，这个角色自身它会被组织化掉。在传统软件时期，有好多幼我英雄主义，就说由于某一个产品经理或一个魂灵人物，导致最后这个产品出格受迎接。但将来可能是一个组织做了一个很好的产品，被这个市场接受。

Peter：我感触有一个极度显著的趋向，复合型人才，或者比力general（通用）的人，他在AI环境之下能够茁壮成长得更好一些。不论是说一个工程师他有产品的感知和市场的感知，还是说一个产品经理他拥有implementation（实现）的能力，城市极度的重要。另一个趋向：UX和UI的设计师会变得极度重要，但他们必要具备把设法落地到产品中的执行能力。若是你必要把你的设法传递给另表一幼我或者，那你互换或对齐的成本就弘远于你执行的成本，在整个的AI的工作环境之下就变得不是那么的高效。

泓君：Peter，你有一篇文章我印象很深，你说低级工程师比资深工程师更能适应AI环境，为什么
？

Peter：由于低级的工程师的技术债务或者他的思想的约束，通常来说比力幼，他可能接受扩大他的scope（领域），他不仅是作为一个工程师，也要融入到一些产品的设计之中，蕴含产品他的feature deploy（职能部署）之后，他还必要做一些分析，他凭据分析可能做出他的一个判断。

但通常来讲，比力高级的工程师由于他比力specialize（专精），好比说你是一个做基础设施的人，或者你是一个做后端的人，你可能在传统的工作环境之中，你不关切你的代码颁布之后发生的事件。但是在AI这个环境之下，你的工程师的领域就必要比之前扩大好多，就不只是在我把这个代码写完之后就实现了，而是在于我代码写之前我怎么可能把自己的judgment（判断）加进去，代码颁布之后怎么可能判断它的impact（影响）。整个这个过程是极度重要的。

通常来讲低级工程师是可能更好地接受这样的一种工作状态。好比说你跟一个资深工程师说，除了掌管前面你代码已经交完了的这个过程，你还要掌管后面的这个过程，他们是不能理解跟顿时去转变这个思想的。通常来讲，必要对齐这个思想模式的成本要高好多。

其实作为一个高级工程师，或者作为一个专业领域的——不论你是做基础设施的人，还是前端的人——在从前的软件开发过程之中，你的知识是极度有价值的，由于你可能知路在开发这个系统之中怎么样写最简洁的代码，怎么样设计最好的架构，你可能必要两三个月的功夫去实现这样一个事件。但是AI编程在现阶段它已经很强了，以来会变得更强，所以它会让你自身的specialty（专长）变得越来越低。所以好多人可能接受不了这样一种状态，就是他自身能花了10年、20年功夫学到的这样一些知识，变得可能在将来并不那么重要。

泓君：所以你们此刻更偏差于招哪一类的人
？

Peter：我文章中固然提到，转变一个资深工程师的难度要比一个相对来说低级工程师的难度要大。但是从价值上来讲，一个资深的工程师的价值此刻是不能被取代的。所以怎么可能找到一个资深的工程师，他还可能拥抱AI的思想模式，并且他可能拥有一个产品的感知，他可能还知路一些市场的知识。这幼我固然很难找，但是对于公司来说是极度有价值的。益处是在于，之前我们可能必要好多这样的人，但是此刻我们可能只必要一到两幼我就能够了。

泓君：此刻我们说AI成为主力，AI也能够迭代产品，所有的器材都是动态的。各人感触将来人最主题的能力是什么呢
？

Peter：我感触人最必要的能力就是系统架构的能力。从以前implement feature（开发职能），造成怎么架构这个AI系统和maintain（守护）这个AI系统。不论是工程师还是市场的角度，你做go-to-market，主题过程也要去搭建一套可能自主运行的Agent的市场系统，而不只是单纯地产生一个市场内容。

Kai：人的价值若是从真的很长远来看，就跟我们技术发展整个过程一样，确定技术发展方向始终是人的需要和这个社会的需要。只有人这个物种还存在，人界说需要的方向和审核最终了局的价值是无法被取代的。

【音频收听渠路】

公家号：硅谷101

收听渠路：苹果｜幼宇宙｜喜马拉雅｜蜻蜓FM｜网易云音乐｜QQ音乐｜荔枝播客｜哔哩哔哩

海表用户：Apple Podcast｜Spotify｜TuneIn｜Amazon Music

联系k8凯发天生赢家：podcast@sv101.net