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

一、AI 工程能力的三次进化

Peter 在节目中清晰地梳理了这三次跃迁的脉络。Prompt engineering 和 context engineering 的关注点都在怎么和 LLM 这个大模型本身进行交互——优化 prompt、优化 context。它们的 scope 相对较小，而且是静态的：你优化的是一个模型，你优化的任务也是一个相对 vertical 的任务。

但 harness engineering 完全不同。它不只是关于 LLM 本身的 harness，而是整个系统的 harness——包括基础设施建设、tooling 的使用、安全的保证。它涉及 sandbox 的架构设计、host service 之间怎么安全交互、sandbox 启动时间是多少、延迟是多少。这些全部都是 harness 的一部分。

从静态到动态，是 harness 最本质的区别。Peter 强调，他们认知中的 harness 是一个动态的过程：系统怎么能够从一个静态的状态真的"活起来"，能够 self-improve，能够不停 adapt 新的 signal——不管是 marketing signal、产品本身的 signal、还是用户的行为 signal。

二、AI-First 不是"用 AI 工具"——是重新设计组织

这是本期对话最核心的观点。陈凯开门见山地说："我们如果想要做到所谓的 AI first 或者 AI native 这样的一个状态，那它并不是在现有的流程上面去使用 AI 的工具，而是要围绕 AI 的能力去重新的构建你的工作流程和组织形态。"

他举了一个反例：在很长一段时间里，每个工程师都在用 AI 写代码，每个产品经理都在用 AI 写 PRD，每个设计师都在用 AI 作图。但这样并没有增加效率——反而因为每个人的工作进度和节奏不一样，导致 alignment 的成本变得非常高。

问题的根源在于：如果人还是工具的使用者，效率提升就有一个天然的上限——可能最多就 10 倍。要追求 100 倍、1000 倍的效率提升，AI 必须是生产力的主导，而人的角色要从"实际工作者"变成"方向的设定者和结果的审核者"。

三、信任的转移：组织架构的核心变革

陈凯把组织架构变革提炼为一个核心问题：信任。传统组织信任的是人——每个角色、每层汇报、每次对齐都建立在"人靠谱"的假设上。AI-first 组织要做的，是把信任对象从人转移到系统。

"原来你组织信任的是人嘛，那人本身是这个组织最核心的那一环。但现在当你把 AI 拿进来之后，其实你要先解决第一个问题，就是你能不能信任你的 AI 做决策或去执行任务。"

这个信任不是凭空产生的——它需要通过 harness 系统建立大量的 guardrails 和机制，保障 AI 做的所有工作——不管是决策、planning、还是执行——最终能被信任。

当信任建立起来之后，组织内部的对齐方式就发生了根本变化。以前 marketing 团队和 engineering 团队需要互相沟通、达成共识、对齐之后才能推进。现在，AI 主导告诉 marketing team 开发团队要发布什么功能，marketing 不再需要跟 engineer 反复沟通。对齐成本大幅降低。

四、"一天迭代完传统六周的工作"

Peter 在 Twitter 上发了一篇帖子，获得了 187 万的流量，引发了广泛共鸣。帖子的核心内容可以浓缩成一句话：一家 25 个人的公司，99% 的代码都是 AI 来写的。早上 10 点写了一个功能，中午就进行了 AB test，下午 3 点根据数据反馈砍掉了一部分功能，5 点又重写了更好的版本。这是一天的时间——而传统开发流程需要六周。

这个节奏之所以可能，是因为 AI 辅助 coding 让实现一个 feature 的时间从几周变成了一到两个小时。当实现成本降到这么低，传统的 design 和 testing 流程就成了瓶颈。因此必须把 design planning 和 testing 也纳入 harness 体系——让 AI 来驱动整个 pipeline，而不仅仅是 coding 这个环节。

五、开发速度远远超过市场速度

AI-first 组织带来的一个反直觉结果是：开发团队的产出远远超过了 marketing 团队能消化的速度。

Clark 描述了这个变化："我最大的体会就是，现在我们确实不用跟 engineer 过多的沟通说你要做什么 feature，然后你什么时候能 deliver，因为 feature 现在的数量已经远远超过我们能够去卖它的这个能力了。开发的速度是远远超过于市场这边的进度的。"

他用了一个生动的比喻——"菜篮子"：就像有一个百宝箱，如果今天市场需求是一个苹果，就从篮子里挑一个苹果去卖；如果需求是一个香蕉，就挑一个香蕉去卖。不再需要讨论 product roadmap 是什么，只需要讨论市场需求在哪里。

六、自我修复系统：Bug 修复从一周变成一小时

AI 写的代码也会产生 bug——这是不可避免的。但关键区别在于发现和修复 bug 的速度。

Peter 描述了他们的两层防线系统。第一层是 ship 前拦截：AI-driven 的 testing（比如用 Playwright 做 fully end-to-end testing），保证 ship 的代码中没有明显会 break 产品的 bug。第二层是 ship 后快速修复：多个 agent 并行 identify bug（一到两分钟），自动 triage、assign 给工程师（几秒钟），工程师再用 agent investigate 和提出 solution。

结果：整个 bug cycle 从一周压缩到了一到两个小时。

更激进的是，他们建立了一套 auto-fixing 系统。50% 以上的 issue 是通过 auto-fixing 自动完成的。对于风险较小的文件，AI 自动提交 PR，工程师只需要简单 approve 一下就上线。只有触及安全或 agent behavior 等敏感文件时，才需要深度 review。

一个有意思的副作用：bug list 和 feature wishlist 都没有了。Bug 及时发现及时修复，feature 多到用不完。以前团队总是争吵"先修 bug 还是先做 feature"，现在这个问题消失了。

七、两种工程师：Architecture 与 Operator

Peter 在文章和对话中都强调了一个重要区分：在 AI 环境下的工程团队分为两种人——architecture（架构师）和 operator（操作者）。

Architecture 负责决定系统的整体架构：sandbox 和 host 之间怎么交互、安全边界在哪、延迟怎么优化。AI 会给你一个 solution，但通常有安全或延迟隐患——架构师的价值在于判断和优化。Operator 则负责执行和运营：用 AI 快速实现 feature、分析数据、根据 feedback 做判断。

最惊人的数字是：以前搭建同样规模的 agent 系统需要 10 到 20 个人，现在只需要 1 个 architecture，在一周之内就能完成。Peter 坦言："2026 年我就没有写过一行代码。"

八、初级工程师 vs 资深工程师：谁更能适应 AI？

Peter 的观察引发了很多讨论：初级的工程师比资深的工程师更能适应 AI 的环境。

原因在于，初级工程师的 tech debt 和思想束缚更少。他们愿意 extend 自己的 scope——不只是写代码，还参与产品设计、数据分析、feature deploy 后的效果判断。而资深工程师花 10 到 20 年积累的 specialty（怎么写最简洁的代码、怎么设计最好的架构）在 AI 时代价值在降低——因为 AI coding 已经很强了，以后会变得更强。

但是，Peter 也特别强调：资深工程师的 value 仍然不可被取代。最难找、也最 valuable 的人是：资深 + 拥抱 AI mindset + 有产品 sense + 懂 marketing。"以前需要 10 到 50 个这样的人，现在可能只需要 1 到 2 个。"

九、产品经理这个角色正在被"组织化"

Creo 做了一个大胆的组织决定：取消产品经理这个独立的岗位。不是因为它不重要，而是因为它太重要了以至于不能被局限在一个人身上。

陈凯解释了背后的逻辑：在大多数公司，产品经理是矛盾最集中的角色——同时要跟市场沟通、跟开发沟通，所有的对齐成本都汇聚在 PM 身上。但在 AI-first 的组织里，PM 的职责被拆解到了每一个工程师和工程管理者身上。

前提是：需要有一套机制能保证在没有 PM 的情况下，团队之间还能互相信任和协作——决策的信任成本不因为没有这个角色而变高，反而变得更低。

Peter 补充了另一个维度：未来的产品需要有产品 sense，但关键是这个人必须具备 implementation 能力——能在一到两小时内把自己的 idea 直接带进产品。"如果你需要把你的 idea 传递给另外一个人，那你交流和 alignment 的成本就远大于 implementation 的成本。"

十、复合型人才的黄金时代

一个非常明显的趋势正在出现：复合型人才——或者比较 general 的人——在 AI 环境下可以 thrive 得更好。

不管是工程师有产品 sense 和 marketing sense，还是产品经理有 implementation 能力，都会非常重要。Peter 特别提到了两个角色的未来价值：

第一是懂 implementation 的 designer——不是传统的只出图不写代码的设计师，而是能把设计直接实现到产品里的 UI/UX designer。第二是有产品 sense 的 engineer——不只是写代码，还判断 feature 的商业价值和市场反馈。

更深层的趋势是：在传统软件时代，一个"灵魂人物"产品经理可能成就一个产品。在 AI 时代，一个组织可能做出好产品被市场接受。角色本身在被"组织化"，而非"个人化"。

十一、不要把 AI 当智能——把它当系统

这是陈凯提出的一个核心认知转变，可能也是本期节目最重要的 insight："我们要把 AI 当成一个系统来看待，不要把它当成一个智能来看待。"

虽然系统是由智能所驱动的，但核心的差距在于：当 AI 或者说这个系统发生错误的时候，不要想着怎么纠正这个智能，要想着怎么弥补这个系统。前者是在跟一个黑箱较劲，后者是在搭建一层层的 guardrail 和 feedback loop。

他用了养孩子的类比来帮助理解：与其每次纠正孩子的具体错误，不如给他一套规则和价值体系，让他在规则内变得越来越好。Harness 就是在给用户提供"培训师"——弥补 AI 出错之后该怎么办。

十二、你的内容，到底被谁消费？

Clark 提出了一个被很多人忽视的现实：你生产的内容——文章、视频、marketing asset——未来的受众可能不是人，而是 AI agent。

他以自己的亲身经历举例：找 SOC 2 合规服务商时，第一步是 让 agent 先做 research，然后基于 agent 的结果再筛选。那些服务商的内容，第一层消费者已经是 agent 了。

这个趋势也在推动 SaaS 产品的转型。以前人用 dashboard 管理 task，现在团队更关心的是agent 能不能通过 MCP 和 API 来操作这些 task，prioritize 这些 task。面向人的 UI 在一个 agent 驱动的世界里，重要性在下降。

一个更深层的洞察：从人的审美来看可能不够好的内容，如果投放到市场后由 agent 读取、数据反馈回来可能更好。要根据"谁在消费你的工作结果"来调整 harness 系统——而不是固守"人觉得好不好看"的标准。

十三、转型的节奏与中小企业的机会

Creo 的转型并不是第一天就完成的。2025 年上半年，他们还处于"AI 辅助人做事"的阶段，人是主导。到了下半年，他们发现效率提升非常有限——核心问题是没有真正把生产力工具的使用者从人转变到 AI。

真正的重构发生在 2026 年 1 月——用两周时间重构了整个产品架构，Peter "一行 code 没有写"，只是 criticize AI 的 plan，AI 根据反馈给出 revised version。到现在，10 人以下的 engineering 团队支撑着整个产品。

陈凯认为，中小企业（SMB）是 AI-first 转型的第一批受益者。大企业有太多合规问题、人的因素、legacy 数据库和旧系统——规模越大，转型阻力越大。而 30 人以下的团队没有太多 legacy 包袱，最容易完成这种转变。而且，核心难点不在行业属性——科技公司还是传统公司都可以——而在于创始人是否真的相信 AI，以及是否理解转型意味着什么。

十四、人在 AI 时代的不可替代价值

当 AI 能写代码、能做 planning、能自我修复 bug、能自动生成 marketing content——人还剩什么价值？

三位创始人的回答高度一致。陈凯说："技术发展方向永远是人的需求和社会的需求。只要人这个物种还存在，它的价值是不太会变化的——它定义的是需求的方向和技术迭代的方向。"

由此延伸出两个不可替代的人的价值：需求的定义和最终结果的审核。"人在需求的定义和最终的结果的审核上的价值是没有办法被取代的——除非说人作为这个物种本身的重要性已经不存在了。"

Clark 补充了更具哲学意味的一点："人未来的价值就是判断任何事情是否还有价值。"对价值的定义本身就是人最大的价值——当我们知道自己想要什么的时候，才能判断一件事情是否真的有价值。

而从工程师的角度，Peter 认为核心能力从 implement feature 变成了架构 AI 系统和维护 AI 系统。不管是 engineering 还是 marketing——怎么搭建一套能自主运行的 agent 系统，是未来最稀缺的能力。