给每个人配上 AI，为什么还不算 AI-Native？
AI 前哨 02｜把 AI 变成组织基建
现在很多企业已经开始让员工使用 AI：写文档、分析数据、生成代码、做产品原型。
但员工使用 AI 的数量增加，不代表企业已经成为 AI-Native 组织。
如果任务仍然由人逐个发起，流程仍然依赖人来衔接，决策和经验仍然留在个人脑中，那么 AI 只是让原来的工作方式变快了。
Pete Koomen 对 Copilot 和 AI-Native 的区分，指向的就是这个问题：前者让 AI 辅助人完成任务，后者把 AI 作为组织运转的建设层（building layer）。
要理解这两者的差别，需要先看 AI 改变了什么，再看企业应该怎样重新组织工作。
一、从回答问题到完成工作：AI 的基本单位正在变化
Ethan Mollick 认为，高价值的 AI 工作正在从围绕聊天机器人协作，转向把工作分配给 Agent。
过去更常见的是 co-intelligence 模式：人提出一步要求，AI 返回一步结果，人再继续提出下一步要求。
Agent 模式不同。智能体拥有工具、环境、文件、代码库、浏览器、测试系统和相应权限，可以在一段时间内持续推进任务。人不需要为每一步重新发出指令。
所以，AI 工作的基本单位开始从单次回答变成可委派的任务和工作流。
OpenAI 在《How agents are transforming work》中提供了一个内部使用的观察角度。Codex 最初面向编程，但据这份报告，到 2026 年 6 月，法律、财务、招聘等非技术部门也在使用它处理工作。
报告给出的数据是：到 2026 年 5 月，80.6% 的抽样个人用户至少提交过一次相当于人类工作 30 分钟以上的任务，70.2% 提交过一小时以上的任务，25.6% 提交过八小时以上的任务。最重度日活用户可以同时运行多个 Agent，每天累计生成超过 60 小时的 Agent turns。
这些数字强调的不是 Token 消耗本身，而是一个人开始能够并行委派多少工作，以及 Agent 的结果能够进入多少真实流程。
Anthropic 对 40 万个 Claude Code 会话的分析，则显示了人与 Agent 之间的另一种分工：用户做出约 70% 的规划决策，Claude 做出约 80% 的执行决策。
人决定要建造什么，Agent 决定怎样建造。
这也解释了为什么 AI 降低代码门槛后，领域经验并没有失去价值。非程序员开始能够借助 coding agent 完成自动化、数据处理和工具搭建，但能否把任务交出去，仍然取决于对问题和完成标准的理解。
过去的技术鸿沟更多在实现能力；新的门槛正在转向问题定义、上下文质量、判断标准和反馈能力。
当执行开始变得便宜，企业就会遇到一个看似矛盾的问题：能做的东西越来越多，反而更难决定应该做什么。
二、实现越来越便宜，产品判断反而更重要
Andrew Ambrosino 对“每个人都是 builder”提出了明确反对。
他举过一个例子：公司需要一个功能，可能同时有 90 个没有协调过的小团队，各自做出看起来已经可以上线的原型。
但 90 个原型并不等于 90 个应该发布的功能。
哪些值得保留？哪些应该合并？它们在现有产品中放在哪里？究竟该不该做？
实现不再是最贵的部分，稀缺的是品味（taste）。
这里的 taste 不只是审美，还包括系统思维、方向判断、信息表达和交互判断。更根本的问题是：如果什么都能做，目标是什么？怎么到达那里？
这也是 Ambrosino 不认同“PRD 已死、原型当道”的原因。
原型制作成本下降后，人很容易跳过思考，直接展示一个看起来已经成形的产品。但视觉上的完成度，不再能说明产品已经经过充分判断。
模糊的产品方向，需要通过文档把问题想清楚；要验证交互模式、让人上手体验，才适合用原型。
两种媒介解决的不是同一个问题。
AI 把“做出来”提前了，但没有自动完成“想清楚”。
当这种变化进入团队，职责边界也会发生变化。产品、设计、工程之间的协作不再完全按工种切开，产品经理有时更像“区域防守”：哪里存在尚未被覆盖的问题，就去填补哪里。
但角色融合不等于每个人都能做好所有事，更不意味着管理和产品方法论已经过时。
模型能力还会不断改变产品的可行性。Ambrosino 提到，Codex 应用即使保持相同形态，只因为发布时模型能力不同，市场结果就可能完全不同。
所以，某个功能今天效果不好，不一定说明方向错误；也可能是模型能力还没到位。与此同时，团队又不能只追求新尝试而忽略质量，需要让探索创新和细节打磨两种能力同时存在。
Tony Fadell 从产品经验提出了相近的问题：长期痛点 + 新技术 = 值得做的产品。
iPod、iPhone 并不是单靠某一个新技术出现，而是多项技术成熟后，终于可以解决长期存在的问题。
对于全新品类，历史数据往往不足以证明方向是否成立。这时仍然需要有人做关键判断、承担选择，并在实际反馈中持续迭代。
Fadell 对微管理的区分也很直接：微管理应该管关键决策，而不是事无巨细地管执行。
当人能够明确目标，下一步才是让 Agent 持续执行。问题由“怎么写好每一次 Prompt”，转向“怎么让任务自己沿着正确流程运行”。
三、从反复 Prompt 到 Loop：让 Agent 持续工作
Addy Osmani 将这种变化称为 Loop Engineering（循环工程）。
Peter Steinberger 和 Boris Cherny 的表达很接近：不再由人不断手动提示编码 Agent，而是设计一个 Loop，让系统负责提示 Agent、选择下一步、调用工具、检查结果。
人的工作从反复下指令，转向设计 Agent 运行的系统。
Osmani 提出的完整 Loop 包含五类模块，加上一层记忆：
- Automations：自动触发与分类；
- Worktrees：让并行 Agent 互不干扰；
- Skills：沉淀可以复用的方法；
- Plugins 和 Connectors：接入实际工具与数据；
- Sub-agents：拆分执行者和检查者；
- Memory：保留持续工作的上下文与经验。
为什么要把生成者与检查者分开？因为让写代码的模型直接评审自己的代码，可能无法充分发现自己的问题。独立的检查环节，才能帮助 Loop 判断任务是否真正完成。
但 Loop 并不会天然可靠。
一个无人值守运行的 Loop，也可能成为一个无人值守犯错的 Loop。
如果人越来越不理解代码库和业务本身，系统持续生成的复杂度就可能在无人察觉的情况下积累。Ambrosino 对 AI 总在增加代码复杂度的担忧，和这里指向的是同一个风险。
OpenAI 的 Codex 最佳实践，提供了将 Loop 落到具体工作中的另一组方法。
任务输入要有四个要素：目标、上下文、约束条件、完成标志。
复杂任务先规划，再执行；长期有效的约束写入 AGENTS.md，而不是在每次 Prompt 里重复；任务结束前运行测试、检查 Lint、类型和 diff；同一工作单元尽量保持在同一个会话，真正分叉时再拆开。
这里还需要区分两个概念：
Skill 定义方法，Automation 定义何时运行。
一项任务还需要大量人工引导时，先把方法沉淀为 Skill；只有过程足够稳定、结果可以检查，自动化才真正有意义。
这也是为什么 OpenAI 把 Codex 描述成需要持续配置和改进的队友，而不是用完即走的一次性助手。
不过，让每个人都有自己的 Loop，仍然只是个人工作方式的变化。
如果工作轨迹、纠错经验和判断标准都只留在个人 Agent 里，组织并不会因为员工更高效，就自动变得更聪明。
要跨过这一步，就需要把个人工作流沉淀为组织可以共同使用和持续改进的资产。
四、从个人工作流到组织资产：AI-Native 的建设层
Satya Nadella 提出，企业需要在传统的人力资本、数字资产之外，重新理解 token capital。
这里强调的不只是购买多少模型 Token，而是企业能否把知识、流程、反馈、判断和工作轨迹，转化成模型可以使用、可以持续改进、并且由组织控制的智能资产。
企业因此需要知道：哪些任务应该使用前沿模型，哪些只需要小模型、规则系统或稳定便宜的 Agentic Workflow；哪些知识可以被调用；哪些操作需要权限；哪些结果已经达到业务标准。
其中一个关键能力是 private eval。
公开 Benchmark 可以衡量模型的通用能力，但不能直接判断它能否完成某家企业的具体工作。
企业需要积累自己的任务样本、评价标准、错误案例和专家反馈。
这也意味着，值得长期记录的不只是最终文档和数据，还包括人如何提出任务、Agent 如何尝试执行、专家如何纠正结果，以及下一次系统如何改进。
Pete Koomen 对 AI-Native 的定义把这件事推向组织层：AI 不只是 Copilot，而应该成为组织运转的 building layer，同时系统性地记录工作产生的 artifacts。
Artifacts 可以是讨论、决策、代码、设计、计划和 Agent 工作轨迹。它们不应只留在个人脑中，而需要成为组织可以访问和复用的上下文。
Koomen 介绍的 YC 实践有两个文化前提：Trust by default（默认信任）和 Egalitarian（平等主义）。原文提到，YC 全职员工可以看到组织内的 Agent 对话。
在这种透明基础上，YC 还运行 Dream Cycle：每天自动读取员工当天的 Agent 对话，寻找可以改进的环节，再把改进沉淀为下一次可以使用的 Skill。
Koomen 对软件结构的主张也与此一致：让 Agent 包裹确定性工具，而不是把 AI 锁在一套固定软件流程里。 如果上下文和工作逻辑始终封闭在开发者预设的功能中，用户就很难根据真实工作持续修改和扩展。
这里的逻辑不是让员工多写文档，而是让组织里的每一次真实工作，有机会成为下一次执行的上下文和反馈。
Koomen 同时提到杰文斯悖论：当使用成本下降，需求可能不是减少，而是增加。SQL 查询门槛下降以后，人可能会提出更多过去不值得做、甚至不敢提出的问题。
因此，AI-Native 组织不能只用“原来的工作节省了多少时间”衡量价值，还需要看组织能否开展以前无法开展的工作。
Copilot 提高的是个人完成任务的能力；building layer 改变的是组织积累、复用和改进能力的方式。
当这些能力逐步进入组织，变化就不只发生在工具层，甚至会触及企业原有的协调结构。
五、当 AI 可以协调工作，组织还需要原来的层级吗？
Ivan Zhao 把 AI 比作组织的钢。
钢出现以后，建筑不再受原有材料的承重限制，可以采用新的结构。类似地，当 AI 能处理更多上下文和任务协调，企业也可能不再需要依靠过去那样多的人与人之间的信息传递。
他用了另一个比喻：蒸汽机刚出现时，工厂主只是把水轮换成蒸汽机；真正的变化，是重新设计整个工厂，而不再围绕河流建设。
给每个人加一个 AI 助手，更接近换掉水轮；围绕 Agent 重新设计组织工作，才接近重新设计工厂。
在 Notion 的实践中，Ivan 提到，在约 1000 名员工之外，还有约 700 个 Agent 处理重复工作。但 Ivan 也指出，知识工作比写代码难，主要受到两件事限制：
- Context fragmentation：上下文散落在 Slack、文档、仪表盘和人的脑中；
- Verifiability：代码可以通过测试验证，很多策略和业务判断却没有同样直接的标准。
这两件事也解释了为什么组织变革不能只靠增加 Agent 数量。上下文必须被组织起来，判断结果的方法也必须同步建立。
Jack Dorsey 对组织结构的设想更进一步。
传统层级的一项重要功能，是在人类管理跨度有限的情况下传递信息、协调行动。Block 提出的方向，是让 AI 维护持续更新的业务模型，接手一部分过去依赖层级完成的协调工作。
这个系统同时需要理解公司和客户：公司世界模型保存决策、讨论、代码、设计、计划等 artifacts；客户世界模型帮助系统理解外部需求。
在这种设想中，人的角色也会变化：
- IC：负责深度专业问题；
- DRI：对跨领域任务直接负责；
- Player-coach：既亲自参与建设，也帮助他人成长。
Jack Dorsey 提出的问题不是“组织还需不需要协调”，而是过去由人类层级完成的协调，是否一定只能由人来完成。
但如果继续推下去，还需要回答一个问题：企业的所有工作，都适合交给 AI 作为中心来调度吗？
闲庭落木提供了一个重要区分：开放问题与封闭问题，需要两种不同的组织方式。
封闭问题有相对明确的目标和完成标准，例如修复一个确定的线上 Bug。对于这类问题，可以让 Agent 主导执行，在权限或现实世界的障碍处请求人介入。
开放问题则不同。例如“怎样利用 AI 让组织能力提高数倍”，不是完成某个已知步骤就能回答，需要持续提出方向、形成假设、判断什么值得做。
作者在实践中发现，AI 有时能把功能实现出来，却没有做出人真正想要的架构。原因是人脑中关于未来方向的判断，并没有被充分表达成任务要求。
因此，他区分两种 AI-Native 形态：
- AI 控制台：面向开放问题，由人驱动探索，AI 作为超级副驾，保护探索者的 Flow；
- Agent 平台：面向封闭问题，由 AI 调度可工业化的执行流程，必要时调用人类处理例外。
这与 Tony Fadell 强调的 human in the loop 并不必然冲突。
关键不是让人永远参与每一个步骤，也不是把所有判断都交给 AI，而是按照任务是否明确、结果能否验证、决策后果有多大，决定由谁主导。
不同企业的开放问题和封闭问题占比不同，也就不可能只有一种统一的 AI-Native 组织结构。
六、组织可以用 AI 重构，但商业护城河不能只靠 AI
当 Agent 能执行任务、组织能够复用工作流，实现能力变得更便宜，另一个问题也会出现：如果别人同样可以用 AI 把软件做出来，企业的竞争优势在哪里？
Tony Fadell 对纯软件护城河持怀疑态度。他把缺乏长期维护与架构质量的 AI 生成软件形容为 fast fashion 软件：做出来很快，但不代表能够长期使用。
他更看重具有 atoms（现实世界实体要素） 的公司——产品不仅是一份代码，还涉及硬件、制造、渠道、供应链和真实交付。
这个判断不意味着所有 SaaS 都没有价值，而是强调容易生成的实现形式，本身不足以构成长期壁垒。
Michael Morton 和 Ben Thompson 关于电商的讨论，提供了相似的观察。
Morton 认为，AI 在消费交易中的作用可能更接近升级版 Google Search：帮助用户研究产品、形成购买决策，再把用户导向品牌和交易平台，而不一定直接替代整个交易过程。
Morton 引用的观察是，品牌官网来自 AI 平台的流量增速曾达到传统电商平台的数倍。但流量和决策入口的变化，不等于现实交易能力可以被轻易复制。
Shopify 的规模议价能力、支付和广告系统集成，Amazon 的物流与履约网络，都不是通过 Vibe Coding 就可以重建的。
消费者也未必愿意把所有购买过程自动化。研究、比较、选择本身可能是消费者希望保留的体验。
AI 可以改变用户发现产品、理解产品的方式，却不会自动消除支付、履约和消费行为形成的现实约束。
所以，企业把 AI 变成组织能力以后，仍然需要回答传统商业问题：它解决什么真实痛点，依靠什么交付价值，以及哪些能力不容易被复制。
内部的 AI-Native 能力解决“怎样更好地做事”；面向市场，还要解决“为什么用户选择你”。
七、从内部能力到外部表达：为什么要讲 Why，而不是只讲 What
Tony Fadell 认为，营销不是产品做完以后的附加工作，而是产品的一部分。
技术团队容易只讲 What：做了什么功能、用了什么模型、有什么技术能力。但市场还需要知道 Why：这件事为什么重要，解决了什么问题。
Marc Andreessen 和 Ben Horowitz 关于 Go Direct 的讨论，把这个问题延伸到传播方式。
在他们看来，传统集中化媒体的影响力正在变化，公司不应只等待媒体替自己讲故事，而需要直接面向受众表达。
他们还提出，个人正在成为越来越重要的品牌载体。公司的外部认知，可能与创始人及核心人物长期表达的判断紧密相关。
但这并不是要求创始人不断宣传自己。
“你唯一应该谈论的，就是你深入了解的东西。”
表达的起点也不应该只是“我的公司有什么产品”，而应该先看外部：世界正在发生什么重要变化，这些变化为什么值得关注，以及它们与公司正在做的事情有什么关系。
从这个角度看，AI-Native 组织的对外表达，同样需要回到产品判断。
公司内部可以有大量 Agent，可以自动生成内容、研究市场和生产方案，但内容生产能力变得便宜，不代表观点和方向也自动成立。
真正值得传播的，仍然是企业理解了什么问题，选择解决什么问题，以及它准备如何创造价值。
结语：从个人工具到组织基建，中间差的是一套新的工作方式
这些观点最终指向的，不是“企业应该给每个员工配多少个 AI”，而是组织如何重新安排工作的基本结构。
从单次对话到长周期任务，从手动 Prompt 到 Loop，从个人经验到组织 artifacts，从人传递信息到 Agent 协调工作。
但这条路径有两个不能跳过的前提。
一是判断：任务是否值得做，方向是否正确，哪些问题应该由人主导。
二是验证：结果是否达标，错误能否发现，经验能否进入下一次执行。
因此，AI-Native 不是把人的工作全部交给 AI，也不是让每个岗位都拥有一个 Copilot。
它是让组织把可以委派的工作交给 Agent，把能够复用的经验沉淀成系统，同时让人继续负责方向、判断和结果。
企业真正需要建设的，不只是更多 AI 工具，而是一套能够持续执行、反馈、积累和改进的工作方式。
观点源于 Andrew Ambrosino、Ethan Mollick、OpenAI、Anthropic、Satya Nadella、Addy Osmani、Tony Fadell、Pete Koomen、Ivan Zhao、Jack Dorsey、闲庭落木、Michael Morton、Ben Thompson、Marc Andreessen 与 Ben Horowitz 的观点与材料，延伸做个人思考整理。