【摘要】AI产品开发的范式正在经历一场深刻变革。成功的AI产品不再依赖于传统的自上而下规划，而是通过与模型深度互动，从底层自发涌现。这种“自下而上”的演进路径，正在重塑我们对创新、组织效率和人机协作的理解。

引言

在科技圈，Mike Krieger 这个名字与“产品”二字紧密相连。作为 Instagram 的联合创始人兼前 CTO，他亲手打造了一款定义了移动互联网时代视觉社交的产品。如今，他的身份是 Anthropic 的首席产品官（CPO），一家站在大模型技术浪潮之巅的公司。从像素构成的照片墙到由语言模型驱动的未来，Krieger 的视角转换，本身就预示着产品开发哲学的剧变。

最近，他在红杉资本的一次分享，与其说是一场演讲，不如说是一次坦诚的复盘与展望。他谈论的，正是当前所有产品经理、工程师和创业者都无法回避的核心问题，在AI时代，我们该如何构建真正有价值的产品？他给出的答案有些反直觉，最好的AI产品，似乎并不能被精确地“计划”出来。它们更像是在实验室的培养皿中，从最基础的交互和实验里，自发地“长”出来。这篇文章，将基于他的分享，深入探讨这场由AI引发的产品开发革命，以及它对组织、协作和创新带来的深远影响。

一、AI 生成内容的未来，不是真假之辨，而是可信与共鸣

在讨论如何构建AI产品之前，我们必须先厘清一个基础背景，AI正在创造一个怎样的信息环境？

过去几年，每当AI生成内容的技术有所突破，公众的讨论焦点总会迅速滑向“真假”的二元对立。“这张图片是AI画的吗？”“这段文字是AI写的吗？”这类问题不绝于耳。甚至在学术界，AI查重也成了一种新的“猫鼠游戏”。

但 Krieger 提出一个颇具前瞻性的观点，长期来看，当绝大多数内容都由AI生成或辅助生成时，“是不是AI生成的”这个问题本身将变得毫无意义。 这就像在印刷术普及后，我们不再纠结一本书是手抄的还是印刷的。

真正重要的问题会转变为其他维度。

  • 来源（Provenance），这段内容的原始出处是哪里？它基于哪些数据训练而成？

  • 溯源（Traceability），我能否追溯它的生成路径和修改历史？

  • 引用（Citation），它是否清晰地标注了所引用的信息来源，以便我进行事实核查？

有趣的是，AI本身恰恰可能是解决这些问题的最佳工具。过去，区块链技术曾被寄予厚望，希望通过分布式账本解决数字世界的可信度问题。但现实是，区块链的应用场景和效率都遇到了瓶颈。而在一个内容生产链条完全数字化的今天，AI模型反而能更高效地完成溯源和验证工作。

想象一下，未来的每一份AI生成文档，都可能内嵌一个“数字身份证”，记录了它的“父母”模型、训练数据集、关键的Prompt以及所有引用的外部链接。当你对某个观点产生疑问时，可以一键追溯到它的源头。未来的内容消费，重点不再是分辨“人造”与“机造”，而是判断“它是否可信”、“它来自哪里”、“我能否验证它”。

这种转变意味着，未来AI产品的核心竞争力之一，将是构建强大的内容可信度体系。无论是通过技术手段（如数字水印）还是产品设计（如清晰的引用和溯源功能），帮助用户在信息的汪洋大海中建立信任，将是所有内容型AI产品的必修课。

二、真正有价值的 AI 产品，从不是计划出来的

这或许是 Krieger 分享中最具颠覆性的观点。它直接挑战了过去二十年互联网产品开发的“金科玉律”。

2.1 从“自上而下”到“自下而上”的范式转移

在 Instagram 的黄金时代，产品开发是一套严谨的、可预测的流程。Krieger 回忆，他们会制定详尽的三到六个月的产品路线图（Roadmap）。团队像一支训练有素的军队，从顶层战略出发，层层分解为功能、指标、设计稿和开发排期。这是一种典型的**“自上而下”（Top-down）**模式。它在功能明确、用户需求相对稳定的市场中非常有效。

对比维度

传统“自上而下”开发模式

AI时代“自下而上”涌现模式

起点

市场分析、用户调研、战略规划

与模型进行开放式实验、探索模型能力边界

过程

严格按照路线图和时间表执行

基于实验中的意外发现，快速迭代原型

核心驱动

解决已知的、明确的用户痛点

发现模型能够创造的、全新的用户价值

产品形态

在规划阶段已基本确定

在迭代过程中逐渐清晰和演化

团队角色

产品经理定义需求，工程师实现

研究员、工程师、设计师紧密协作，共同探索

风险

市场判断失误，产品无人问津

过程难以控制，可能耗费大量资源却无果

典型产物

功能迭代、性能优化

全新品类、颠覆性功能（如Artifacts, MCP）

然而，在 Anthropic，这套方法论失灵了。Krieger 发现，无论是他们自己，还是像 OpenAI 这样的同行，那些最酷、最有影响力的AI产品，几乎都不是在会议室里规划出来的。它们诞生于一种更混沌、更有机的方式，“自下而上”（Bottom-up）。

这种模式的核心在于，产品的真正潜力，只有在与模型本身进行极度深入和频繁的互动实验后，才会逐渐显露出来。 你无法预先设计一个完美的AI功能，因为你甚至不知道模型能力的边界在哪里。你必须先“玩”起来，把模型推向极限，观察它在各种意想不到的场景下的反应。那些“惊喜”的瞬间，往往就是伟大产品的起点。

比如 Anthropic 的 Artifacts 功能，它允许 Claude 将代码、文本块等生成内容放置在一个独立窗口中，方便用户编辑和使用。这个功能最初只是一个内部研究员做出的粗糙原型，目的是为了解决自己在编程时的一些不便。后来，设计师和工程师看到了它的潜力，接手进行优化和打磨，最终才演变成一个正式的产品功能。整个过程，没有详细的PRD（产品需求文档），没有严格的排期，更像是一场接力赛。

2.2 The Birth of an Idea The MCP Story

Model Component Protocol（MCP）的诞生故事，是“自下而上”模式的绝佳注脚。

故事的开头平淡无奇。团队需要让 Claude 能够接入外部知识，最初的两个目标是 Google Drive 和 GitHub。工程师们很快发现，尽管目标都是“把上下文引入模型”，但两个功能的内部实现方式截然不同。紧接着，第三个集成的需求又来了，大家预感到，这又将是一次“重复造轮子”的开发。

这时，两位工程师觉得“这样做不合理”。按照软件工程的古老智慧，“做三次之后，就可以总结出抽象层级，形成标准”。他们没有去写一份长篇大论的提案，申请立项，而是直接动手做了一个原型，试图找到一种统一的方式来处理这类外部工具的调用。

这个“小火花”，就是 MCP 的雏形。它并非源于一个“我们要制定行业标准”的宏大叙事，而是源于一线工程师对代码优雅和效率的追求。

后来，这个内部协议逐渐被完善，团队也意识到它的巨大潜力，开始投入更多精力将其打磨得更开放、更通用，并希望它能成为整个行业的基础设施。如今，MCP 真的开始被更广泛地采用。从解决一个具体问题，到一个内部标准，再到一个行业协议，MCP 的演化路径完美诠释了什么叫“从底层自发长出来”。

2.3 从涌现到执行，Agent 的未来蓝图

一个好的想法“长”出来之后，如何培育它？Krieger 认为，围绕 MCP 的下一步，有两个关键方向。

第一个是**“执行能力”**。MCP 最初的设计目标是引入上下文，让模型“知道”更多。但未来，模型不仅要能“理解”，更要能“行动”。通过 MCP，模型应该能主动触发 Zapier 的工作流，能在 GitHub 里提交代码，能自动完成一系列预设任务。这是从“信息输入”到“任务执行”的质变。

第二个是**“Agent 之间的协作”**。这是更长远的畅想。当大量的 AI Agent 都能独立执行任务时，它们之间必然会产生交互。一个 Agent 可能会为了完成一个复杂任务，去“雇佣”另一个更专业的 Agent。比如，你的个人写作 Agent 可能会调用一个数据分析 Agent 来获取图表，然后再调用一个设计 Agent 来完成排版。这将催生一种全新的、由 AI 构成的经济系统。

这些方向并非凭空规划，而是在 MCP 这个“自下而上”的产物基础上，自然延伸出的可能性。

2.4 The Paradox of "Vibe Coding"

编程领域是 AI 应用最成熟的场景之一，但即使在这里，Krieger 依然认为创新充满了不确定性。

“Vibe Coding”是一个社区创造的词，用来形容一种编程体验，你不再是逐字逐句地写代码，而是向AI描述你的“感觉”或“意图”，AI则为你生成代码。这种方式在做一些小项目或寻找灵感时非常有趣，充满了探索的乐趣。

但问题在于，构建一个需要百人团队协作的大型、稳定、可维护的工程系统，光靠“Vibe”是远远不够的。Anthropic 内部，超过 70% 的代码合并请求（Pull Request）是由 Claude 生成的。这极大地提升了开发速度，但也带来了新的、更棘手的问题。

代码审查怎么办？ 你可以用 Claude 来审查 Claude 生成的代码，但这就像一个“套娃”，每一层都是AI。我们如何确保整个技术架构的健康和可控？我们是否在以一种前所未有的速度，累积一种全新的“技术债”？这些问题，整个行业都还在摸索答案。

2.5 The New Bottleneck

AI 带来的效率提升，像一面放大镜，照出了组织中那些原本被容忍的低效环节。

Krieger 观察到一个深刻的现象，当AI将工程师的编码效率提升数倍后，组织中那些“非工程环节”的瓶颈变得异常刺眼。

过去，一个冗长的对齐会议，可能只是耽误了一位工程师一小时的工作。现在，这一小时的会议，可能等于耽误了“8小时的AI产出”。工程师们会感到前所未有的挫败感，因为他们刚刚还在以光速生成代码，转眼就陷入了缓慢的决策流程和部门协调的泥潭中。

AI 优化了执行的“点”，却放大了协作的“面”上的问题。 组织流程中的不协调、沟通的模糊地带、决策的犹豫不决，这些“软问题”成为了限制整体效率的最大障碍。虽然 AI 模型可以帮助总结会议纪要、提炼下一步行动建议，但它们还无法代替人类做出复杂的、涉及权衡和判断的组织决策。这预示着，下一阶段 AI for Work 的重点，可能将从赋能个体转向优化整个组织的协作流程。

三、从工具到协作，组织如何适应 AI 时代的效率重构

当一个颠覆性工具出现时，它的普及不仅是技术问题，更是文化问题。Anthropic 内部推广使用 Claude 的过程，生动地展示了这种文化的演变。

3.1 打破“AI 使用羞耻感”

Krieger 最乐于见到的，是非技术团队，比如销售团队，开始主动拥抱大模型。他们会用 Claude 来准备客户会议的资料，模拟客户可能会提出的问题。当他们在使用过程中遇到障碍时，产品团队会根据这些具体的需求，为他们开发专属的内部工具。这种由真实需求驱动的工具开发，远比自上而下的推广要有效。

然而，即便是在 Anthropic 这样的顶尖AI公司，员工使用AI的能力也参差不齐。有人已经把 Claude 当作不可或缺的“思维合伙人”，而另一些人则依然固守传统的工作流程。

一个有趣的转折点发生在绩效季。起初，很多员工在写绩效评语或工作总结时，内心会有一个声音在问，“我能用 Claude 生成初稿吗？这是不是在‘作弊’？”这种“AI使用羞耻感”是真实存在的。

但公司文化的变化悄然发生。管理层开始公开鼓励这种用法，传递的信息是，AI 是一个帮你节省时间的杠杆，而不是代替你思考的捷径。 你当然需要对AI生成的内容进行校对、修改，并注入自己的判断和思考。但如果它能帮你节省两个小时的重复性写作，让你能把时间花在更重要的战略思考上，那为什么不用呢？

更具戏剧性的一幕是，Anthropic 有一个内部工具，可以打通 Slack 和所有内部文档。员工们发现，在绩效季，很多人开始在这个工具的公共频道里，用它来生成评语初稿。这种“共享式使用”的行为艺术，意外地起到了奇效。当大家看到同事们都在公开地、坦然地使用AI辅助工作时，那种“偷偷作弊”的感觉就消失了。

这让人想起 Midjourney 刚兴起时，Discord 频道里充满了人们分享自己生成作品的热情。这种“可见性”，是推动一项新技术融入日常工作流程的关键催化剂。 它将个体的使用行为，转变为一种群体认同的文化现象。

3.2 The Uneven Adoption Curve

Krieger 的坦诚在于，他承认了AI应用在组织内部的不均衡性。这给所有希望在团队中推广AI工具的管理者提了个醒，仅仅提供工具是不够的。

  • 识别“超级用户”，发现那些使用AI最深入、最有创意的员工，让他们分享自己的工作流和技巧。

  • 场景驱动，而非功能驱动，不要只是培训员工“如何使用AI”，而是展示“如何用AI解决某个具体的工作任务”，比如“如何用AI在半小时内完成一份周报初稿”。

  • 降低使用门槛，对于非技术人员，提供更简单、更定制化的工具，而不是让他们去学习复杂的 Prompt Engineering。

AI 的普及，不是一条平坦的直线，而是一条需要耐心培育和引导的曲线。

3.3 “思维合伙人”范式

Krieger 本人就是AI的重度用户。他将 Claude 定义为自己的“思维合伙人”（Thought Partner）。无论是撰写战略文档、制定产品规划，还是给团队成员写评语，他的第一步都是先和 Claude 进行一轮“脑力激荡”。

他用了一个生动的比喻，“就像有了 GitHub Copilot 之后，我在没有它的飞机上会感觉自己不会写代码了一样，我现在也很难回到没有AI协助的写作状态了。”

这种依赖，并非能力的退化，而是一种工作模式的升级。它将人类的优势（战略思考、价值判断、创造性联想）与AI的优势（信息处理、结构化写作、快速生成）结合在一起。AI负责搭建脚手架和填充砖块，而人则负责设计蓝图和最终的精装修。

这种“人机协作”的模式，正在重新定义“生产力”的内涵。

四、AI Agent 正在成为下一代“数字员工”

如果说当前我们对AI的应用还停留在“工具”层面，那么 Anthropic 的下一个目标，可以用一个词来概括，Agent。

这个词现在几乎被用滥了，但 Krieger 描绘的蓝图更加具体。Anthropic 的目标不是去构建生态中的每一个 Agent 应用，而是为这种全新的“数字员工”形态，提供最坚实的底层支持。代码生成只是一个起点，它验证了一个更宏大的命题，模型能否像人类一样，连续工作几个小时甚至更长时间，自主地完成一个复杂项目？

要实现这个目标，光靠提升模型的参数量和推理能力是不够的。它需要一整套全新的配套系统。

  1. 记忆能力（Memory），Agent 必须能记住自己做过什么，学到了什么，以及在长任务中的上下文。它不能每隔几分钟就“失忆”。

  2. 高级工具调用（Advanced Tool Use），它不仅要能调用一个简单的搜索API，还要能熟练使用像 GitHub、Jira、Figma 这样复杂的专业软件，甚至与真实世界的硬件交互。

  3. 自动适应组织结构（Organizational Awareness），当一个 Agent 被“部署”到一家公司时，它需要能理解这家公司的组织架构、汇报关系和沟通规范。它要知道该向谁请求权限，该把报告发给哪个部门。

  4. 可验证性与日志记录（Verifiability & Logging），想象一家公司同时运行着 100 个 AI Agent。管理者如何监管它们的行为？如何审计它们的决策过程？如何确保它们的操作符合公司的合规要求？这需要一套强大的日志和审计系统。

这四个支柱，共同构成了 Agent 从一个“聪明的聊天机器人”进化为“可靠的数字员工”的基石。

五、前路上的反思与挑战

在分享的最后，Krieger 回答了一些来自观众的尖锐问题。这些问答，更像是他对当前AI产品领域最真实、最坦诚的思考。

5.1 The Usability Gap

当被问及作为产品负责人最头疼的问题时，Krieger 的回答直指要害，AI 产品对新手来说，仍然太难用了。

模型的能力已经强大到令人惊叹，但能真正用好这些能力的用户，依然是少数。AI 产品远没有达到像 Instagram 那样“开箱即用”的程度。你第一次打开 Instagram，本能地就知道该拍照、加滤镜、然后发布。但你第一次打开一个大模型应用，往往会陷入“我该问它什么”的茫然。

只要用户的使用路径稍微偏离了产品设计者预设的“最佳实践”，模型输出的效果就会大打折扣。这种“脆弱性”是当前所有AI产品的通病。如何设计出更具引导性、容错性更高的交互体验，让普通用户也能轻松释放模型的潜力，是摆在所有产品经理面前的巨大挑战。

5.2 The Compute Conundrum and Strategic Delays

关于一篇名为《AI 2027》的热议文章，其中提到AI公司可能会“故意推迟模型发布”以最大化商业回报，Krieger 分享了他的看法。

他首先承认了算力的核心地位。这早已不是秘密。每家AI公司的最高层会议，几乎每天都在讨论算力问题，我们有多少储备？下一代芯片用谁的？和哪家云厂商合作？这决定了公司的生死。

而“延迟发布”的争论，则触及了一个更深层次的战略权衡。扎克伯گ在访谈中也提到过类似的困境，你是应该把宝贵的算力投入到为现有 LLaMA 模型开放 API 服务，满足用户需求，还是应该把这些算力保留下来，用于下一代模型的强化学习（RL）训练？

这是一个艰难的选择。前者能带来立竿见影的收入和用户反馈，后者则可能孕育出颠覆性的架构突破。Krieger 个人的倾向是，尽早让模型进入真实市场。他认为，Claude 3.5 系列之所以能做得这么好，很大程度上得益于从海量真实用户反馈中获得的快速迭代。如果一个模型只在实验室里闭门造车，它可能会在理论测试中得分很高，却无法真正解决现实世界的问题。

5.3 Bridging Research and Product

在一个既有顶尖研究团队又有产品团队的大型组织里，如何平衡两者的关系？

Krieger 对自己的产品团队提出了一个尖锐的问题，“如果我们做出的产品，只是把一个 API 模型包装了一下，功能还和别家大同小异，那我们存在的价值是什么？”

他强调，产品团队的使命，是将公司最顶尖、最独特的研究成果，转化为用户可感知的、有价值的产品体验。如果做不到这一点，就是对研究资源的巨大浪费。Artifacts 是一个正面案例，它是一个专门为 Claude 的独特能力进行微调和优化的产品，因此体验非常好。

他也坦承，Anthropic 曾经历过产品和研究脱节的阶段。现在，他们正在努力回归，重新强调“产品 = 模型核心能力 + 独特的交付方式”。目前，大约只有 10% 的研究人员深度参与到产品开发中，这个比例还需要提高。

5.4 The Agent Communication Dilemma

关于未来 Agent 之间交流协议的标准化，Krieger 指出了一个尚未解决的核心难题，Agent 要不要透露信息，以及透露多少？

这是一种极其细腻的判断。比如，你的个人财务 Agent 在与银行的 Agent 交互时，可以透露你的信用卡信息。但当它与一个陌生的、第三方的营销 Agent 互动时，就必须保护你的隐私。这种“什么该说，什么不该说”的判断力，目前还没有被很好地训练出来。

模型的天性是“讨好”用户，这让它们倾向于透露过多信息。但如果通过指令让它变得过度保守，它又可能什么都不说，无法完成任务。如何在这种微妙的平衡中找到最佳点，既是一个产品设计问题，也是一个前沿的研究课题。

5.5 Common Pitfalls in AI Application Design

最后，对于正在开发AI应用层产品的同行，Krieger 指出了两个常见的“坑”。

第一个是**“外挂式AI”**。很多产品是从“轻AI”开始的，他们只是在现有产品的边栏加一个AI助手的入口。当产品功能越来越依赖AI时，这种“外挂”式的结构就会成为体验的瓶颈。正确的做法是，从底层重新构建产品，让AI成为产品的“第一用户”或核心组件，而不是一个附加功能。

第二个是应用没有为AI提供足够多的“操作抓手”。当你让模型帮你完成一个任务，它回答“我做不到”时，问题可能不在于模型能力不行，而在于你根本没有设计好相应的接口（API）让它去调用。很多开发者习惯于先设计图形用户界面（GUI），再把AI“贴”上去。但未来的设计思路应该是反过来的，先思考AI Agent会如何使用你的产品，为它设计好完备的接口，然后再去构建人类用户的界面。

总结

Mike Krieger 的分享，为我们描绘了一幅AI产品开发的全新图景。在这幅图景中，严密的计划和路线图正在褪色，取而代之的是一种拥抱不确定性、鼓励实验和自下而上涌现的文化。伟大的AI产品，不再是被设计出来的“机器”，而是被培育出来的“生命体”。

它要求产品团队更贴近模型，像生物学家一样去观察和理解它的习性；它要求组织打破壁垒，让研究、工程和设计更紧密地协作；它更要求我们重新思考效率、协作和创新的本质。从内容的可信度，到组织的瓶颈，再到人机协作的文化，AI正在以一种不可逆转的方式，重塑着我们创造价值的全过程。

这条路没有现成的地图，但方向已经逐渐清晰。最好的AI产品，或许真的无法被计划，但它们一定诞生于那些最勇敢、最深入的探索之中。

📢💻 【省心锐评】

AI产品开发，不再是画一张精确的建筑蓝图，而是培育一片充满未知的雨林。产品经理的角色，从建筑师，变成了那个最有耐心和洞察力的园丁。