AI 原生团队 · 运作模型AI 原生团队 · 运作模型团队协作的核心挑战：如何让每个人在正确的时间获得正确的上下文，做出正确的决策。
传统答案是层级制 -- 本质上是一个信息路由协议。要管更多人就加层级，层级越多信息流动越慢、失真越大。很多组织创新都是在这个约束内调整路由方式。
| 层级制的角色 | 实际在做什么 | AI 能否替代 |
|---|---|---|
| 向下汇聚信息 | 了解团队在干什么、卡在哪 | 可大幅自动化 |
| 向上传递信息 | 汇报进展、请求资源 | 可大幅自动化 |
| 替下属提前做判断 | 在权限范围内做判断 | 部分可以，最终责任仍在人 |
随着业务增长，沿用传统模式的复杂度会持续上升。更好的做法是在组织还不臃肿时，就把知识、决策和状态写成 AI 可读的系统。
不靠开会同步，不靠汇报传话。决策、方案、进度结构化存下来，AI 随时读取聚合，信息自己到该到的人手里。
"知识全景"不是 AI 训练出来的模型，是把公司和客户的全部认知结构化存下来（文档 + 数据），让 AI 随时能查、能推理、能交叉关联。不需要复杂平台，维护好的文件夹 + AI 的理解能力就够了。
传统：智能在人脑里，层级负责搬运。
目标：让系统学会思考，让人回到现场。
整个系统分四层，从下往上看：底层是地基，顶层面向用户。
界面重要，但价值不在界面里。界面可以随时换，底下的知识全景和原子能力才是真正的积累。
参考 Palantir Ontology 的语义操作层，以及 Block "From Hierarchy to Intelligence" 对 world model / intelligence layer 的公开论述。[S6][S9]
团队如何理解自身 -- 运转状态、绩效、优先级。
| 数据类型 | 载体 |
|---|---|
| 静态知识（决策、方案、能力定义） | 知识仓库 Git + Markdown + YAML |
| 动态状态（进度、谁有空、什么卡住了） | AI 实时聚合 协作工具 / GitHub API / 项目系统 |
AI 随时查知识仓库回答："谁最适合处理这个问题""为什么当时选了方案 A""我们有没有能力做这个"
基于用户真实行为数据的深度理解 -- 不是我们猜的，是数据告诉我们的。
关键问题：团队理解了什么别人很难理解的东西？这个理解每天都在加深吗？
如果答案是"没什么"，AI 只是降本增效。如果答案是深刻的，AI 揭示的是这个团队到底是什么。
飞轮效应：更丰富的信号 → 更好的模型 → 更多用户交互 → 更丰富的信号。
三步闭环：人把结论写进知识仓库，AI 读取聚合，再推送给需要的人。
知识仓库不是"有空了整理一下"的事后动作，而是特定事件触发的强制写入。每次写入应该足够轻量，避免变成新的流程负担。
| 触发事件 | 写入什么 | 写到哪 | 谁写 |
|---|---|---|---|
| 协作讨论有结论 | 结论摘要 | decisions/ 或 meetings/ | 讨论发起人 |
| 新功能立项 | 方案说明 + 原型文档 | specs/feature-xxx/ | DRI |
| 技术方案确定 | 决策记录 | decisions/ | DRI |
| 新能力上线 | 能力登记文档 | capabilities/ | 能力负责人 |
| 目标/优先级调整 | 目标文档更新 | goals/ | DRI |
AI 的核心能力是交叉关联。知识仓库显示某位同事是安全专家，代码平台显示他当前有多个进行中 PR，系统就能提示："安全任务适合请他审查，但不宜立即再分配高优先级执行任务"。
昨日进展 + 阻塞项 + 爬坡图状态 + 本周目标进度。自动推送到团队协作频道。
@bot "我今天该关注什么" -- AI 综合你的 PR、Issue、目标进度给出优先级。
PR 卡住、任务长时间没人接、自动化测试失败、产品指标偏离预期 → 系统提醒相关人。
@bot "谁适合接这个任务""上次为什么选了方案 A" -- AI 从知识仓库 + 代码平台交叉检索。
团队状态 2026-04-02 (Wed)
[进行中]
风险概览页 -- 规则引擎 ▲ 下坡 70% | UI ▲ 上坡 40% | 通知 _ 未开始
昨日: 一个核心 PR 已合并，另一个仍在等待审查 | UI 组件拆分完成
时间盒: 剩余 5 天
[需要关注]
一个关键 PR 等待审查时间过长 → 建议 DRI 协调审查人
性能优化事项长时间无人认领 → 建议找性能方向专家判断优先级
[本周目标]
风险概览页 beta: 40%, 按计划
共享接口规范: 60%, 略提前
人跟着问题走，不是问题跟着人的职能走。职能边界仍然存在，但不应该成为信息和责任的边界。
工程师的核心工作从"写代码"变成：把活交给 AI，审查 AI 产出，对最终结果负责。
完全交给 AI 做
人 + AI 协作，人重点审
只能人来做，不交给 AI
| 活动 | AI 原生模式下的变化 | 说明 |
|---|---|---|
| 描述任务 | 变得更重要 | 把目标、约束、验收标准和上下文讲清楚，是委托质量的前提。 |
| 审查 AI 产出 | 成为关键瓶颈 | Stack Overflow 2025 显示，开发者最常见挫败来自“差不多对但不完全对”的 AI 输出。[S7] |
| 架构设计和规划 | 更偏向人的责任 | OpenAI Sora Android 复盘强调，基础架构和关键取舍需要人先搭好。[S4] |
| 手写代码 | 不再是唯一核心产出 | 代码仍然重要，但人的价值更多体现在定义问题、把控边界和拥有结果。 |
产品需求写成："做风险概览页 -- 评分、趋势图、导出、通知"。开发团队再去估时间。
做到中途发现比预想复杂。加人、加范围、加沟通，最后还是延期。
根本原因：需求不能砍，时间可以加。需求固定 + 时间弹性 = 必然延期。这不是管理问题，是数学问题。
DRI 先判断："这个问题值得多少时间。" 这不是估算，而是 appetite：这个问题配得上团队投入多少时间。
然后在 2 周内取舍：
时间到了，上线手里有的。可能只有评分 + 基础 UI，但它是可用的、完整的。
Appetite（胃口）：DRI 在立项时设定的时间盒。不是开发团队算出来的工期，而是基于业务重要性做出的投入判断。估算是"做完要多久"，appetite 是"我们愿意喂进去多少时间"。[S8]
"完成 60%" 没有信息量 -- 可能简单任务做完了，核心难题还没碰。
爬坡图把每块任务分两段：
管理者看的是：点在动吗？一个点在上坡卡了 3 天 = 有问题，需要介入。
为什么 AI 时代更适合 Shape Up：AI 能在固定时间内产出更多，但如果不设 appetite，AI 会无限扩大需求（"顺便加个功能"），反而更难收敛。时间盒是约束 AI 产出膨胀的最好工具。
传统团队赌"我们猜对了用户要什么"，AI 原生团队赌"我们能比别人更快地知道猜错了"。
| 步骤 | 谁做 | 具体做什么 | 输出 |
|---|---|---|---|
| 发现需求 | DRI | 用几句话描述问题和目标，不写 PRD。信号来源：用户反馈、数据异常、竞品动态、直觉。 | 问题 brief |
| 出原型 | DRI + AI | AI 从问题描述生成可交互原型，需求和成功指标标注在原型旁边，DRI 调整补充。 | Spec-Prototype |
| 异步评审 | 全员 | 团队异步看原型提反馈，不开评审会。人看方向对不对，AI 查逻辑漏洞。迭代 2-3 轮定稿。 | 已收敛的范围 |
| 开发测试 | IC + AI | 基于原型里的 spec 开发生产版本。原型不追求直接复用，价值在于把需求、交互和指标说清楚。 | 生产代码 + 测试 |
| 发版 + 看数据 | IC + AI | 每个功能独立上线，不攒版本。AI 监控灰度数据，看原型里定的成功指标有没有达成。数据驱动下一轮。 | 指标反馈 |
这条链路的关键不是让 AI 代替产品判断，而是减少信息翻译：人看原型判断体验，AI 读结构化 spec 生成实现和测试，人再审查最终结果。
| 任务类型 | AI 帮助最大的部分 | 证据边界 | 置信度 |
|---|---|---|---|
| CRUD / 样板代码 | 生成初稿、补测试、补文档 | 边界清晰、验收标准明确时更稳定。 | 中高 |
| 代码迁移 / 规范化改造 | 批量修改、运行检查、生成 PR | Spotify Honk 报告迁移类任务 60-90% 时间节省。[S5] | 高 |
| 端到端功能交付 | 原型、实现草案、测试草案、审查辅助 | OpenAI Sora Android 是强上下文和清晰参考实现下的小团队案例。[S4] | 中 |
| 复杂架构 + 核心算法 | 资料整理、方案比较、局部实现 | 关键取舍和最终责任仍需要专家判断。 | 中低 |
传统
线性，有交接点
AI 原生
循环，同一批人同一套系统
不是人盯数据做决策，是 AI 盯数据、人做判断。
当前更实际的目标通常是 L3：AI 自动起草结构化任务和证据链。L5 只适合崩溃修复、安全漏洞、代码迁移等高度结构化、可验证、可回滚的场景。
公开研究和案例给出的共同提醒是：AI 是放大器，不是组织修复器。强系统会被放大，弱系统也会被放大。
抵制 AI 制造大变更的倾向，一个 PR 只做一件事
CI/CD + 自动测试是放大 AI 收益的前提
AI 写得越快，人审得越多，审查能力必须同步增长
出了问题一键回退，不靠人肉兜底
AI 写的代码看着对，但可能藏着隐蔽 bug 和安全漏洞。越信任越危险，必须保持怀疑。
不自己写代码，就会慢慢失去判断 AI 产出质量的能力。审查是核心工作，但审查的前提是你自己能写。
AI 生成代码和任务的速度远超团队消化速度，积压越来越多，质量失控。必须用时间盒约束产出量。
重度依赖某个 AI 模型，一旦涨价、换代、API 变更就被动。核心工作流不能绑死在一家。
代码和业务数据发给外部 AI 服务有泄露风险。敏感代码和数据必须走本地模型或私有部署。
流程不清、职责不明、审查跟不上、反馈不回流，这些问题不会因为换了模型自动消失。
外部可复用的不是固定编制，而是一组组织设计原则：小团队、强 DRI、专家审查、AI 参与低风险执行。
| 原则 | 做法 | 原因 |
|---|---|---|
| 一个结果一个 DRI | 每个项目或机会明确最终负责人。 | 避免多人参与但无人最终负责。 |
| 小团队闭环 | 围绕问题组织跨职能小队，而不是把工作按职能层层转交。 | 减少交接和信息损耗。 |
| 专家审查 | 安全、性能、数据、架构等高风险领域必须有人真正懂。 | AI 可以生成，不能替代责任和专业判断。 |
| AI 先进入低风险环节 | 摘要、草案、迁移、测试补充、文档、结构化 issue。 | 更容易验证，也更容易回滚。 |
起步
先把知识仓库、决策记录、规格模板、代码检查和状态摘要跑起来。不要一开始追求全自动。
扩展后
把重复出现的能力沉淀为共享能力，把反复出现的错误沉淀为检查清单和评估集。
| 阶段 | AI 角色 | 人的角色 |
|---|---|---|
| 起步 | AI 写草案、补测试、做摘要、辅助代码审查 | 人仍主要负责实现和判断，顺手沉淀规则 |
| 过渡 | AI 自动报告、问题分类、候选修复、候选计划 | 人从亲手生产转向委托、审查、负责 |
| 成熟 | AI 在低风险闭环里端到端提出行动 | 人负责方向决策、质量判断、异常处理和最终授权 |
快速落地不等于短期思维。每一步都要为下一步铺路，但不对外承诺内部排期。
知识仓库、决策记录、规格模板、CI/CD、测试和基础状态摘要。
让 AI 参与文档、测试、代码草案、迁移、状态报告等可审查工作。
把用户反馈、错误监控、产品指标连接到 issue、负责人和复盘。
在低风险、可验证、可回滚的场景中逐步开放更高自治度。
长期壁垒不是某个单点工具，而是持续积累的知识全景、共享能力、反馈闭环和团队使用 AI 的组织能力。
| 维度 | 指标 |
|---|---|
| 产品 | 功能假设是否被验证 / 成功指标是否回流到下一轮决策 |
| 效率 | 从问题提出到可审查变更的时间 / 代码审查时间 / 回滚和修复时间 |
| AI 化 | 可审查 AI 产出比例 / AI 产出被接受比例 / AI 错误模式是否被沉淀 |
每一轮都沉淀模板、测试、能力和检查清单，下一轮的上下文加载成本更低。
每个产品的用户数据进入客户知识全景，知识全景越完善，下一轮决策越准。
通过标准接口，产品和 agent 可以互相调用能力。能力越多，组合空间越大。
团队的 AI 熟练度是最不可复制的资产
这里列的是公开可访问来源。每个来源只支持它能支持的范围，案例不能直接外推成普遍规律。
| 编号 | 来源 | 可支持 | 边界 |
|---|---|---|---|
| S1 | DORA 2025 State of AI-assisted Software Development | AI 的主要作用是放大组织系统；最大回报来自底层组织能力，而不只是工具采购。 | 不直接证明某个具体团队能提速几倍。高 |
| S2 | METR early-2025 RCT + 2026 update | AI 提速高度依赖任务、代码库熟悉度、质量要求和测量方法；早期 19% slowdown 适合提醒不要过度外推。 | METR 在 2026 年说明早期结果已过时，不能写成“AI 当前普遍让开发变慢”。中 |
| S3 | OpenAI: Building an AI-Native Engineering Team | Delegate, Review, Own；工程师把第一轮交给 AI，但保留审查、测试、合并和最终所有权。 | 是 OpenAI 的官方方法论，不是独立效果评估。高 |
| S4 | OpenAI: Sora Android with Codex | 小团队在清晰上下文、强工程约束和已有参考实现下，可以用 Codex 扩大执行能力。 | 这是 OpenAI 自身案例；页面也说明 Sora 产品在 2026-04-26 后不可用，不能作为产品长期成功证明。案例 |
| S5 | Spotify Engineering: Honk | 迁移、依赖更新、规范化改造等结构化任务中，背景 coding agent 可以节省大量人工时间。 | 60-90% 节省只应写在迁移类任务上，不能扩展到所有产品创新。案例 |
| S6 | Palantir Ontology Overview | 语义操作层可以把数字资产连接到现实业务对象，让人和 AI 围绕同一组对象工作。 | 支持“语义层/世界模型”的架构类比，不证明必须照搬 Palantir 平台。高 |
| S7 | Stack Overflow Developer Survey 2025 | AI 工具使用广泛，同时很多开发者对“差不多对但不完全对”的结果感到挫败。 | 是开发者调查，不是客观生产率测量。中 |
| S8 | Shape Up: Set Boundaries | 固定时间、可变范围；appetite 是约束，不是估算。 | 支持项目边界方法，不是 AI-specific 研究。高 |
| S9 | Block: From Hierarchy to Intelligence | world model、intelligence layer、capabilities、interfaces，以及 IC/DRI/player-coach 的组织设想。 | 是公司战略观点，不是第三方验证。观点 |
| S10 | GitLab Handbook: DRI | DRI 对项目、事项或活动承担最终责任，同时应咨询和协作。 | 支持责任模型，不直接说明 AI 团队如何设计。高 |
过去，智能分散在人脑中，靠层级搬运。现在，把智能建进系统 -- 信息自动流转，上下文随时可查，决策不再等人传话。人不用再当中转站，可以回到离用户最近、离问题最近的地方。