第二部分 · AI 时代的组织

这套组织，到底长什么样？

第一章落在一句话上——OPC 不是一个人，是 AI 时代的组织。执行白菜价之后，整条链一环扣一环地被改写：

瓶颈上移→ 岗位破圈→ 新研发节奏→ 组织失配→ 对人的硬要求

① 瓶颈上移

执行不再稀缺——稀缺的是"做对的事"

执行白菜价之后，生产力不再均摊到每个人头上，而是向"能定义对的事、能看穿真实需求"的人集中——差距从线性被拉成幂律。

业务价值

知道该做什么。

业务效果

做出来有没有效果。

业务洞察

能不能看穿真实需求。

"真正的门槛，是洞察需求的能力。" —— 刘小排

② 岗位破圈 · 技术与业务交圈

岗位边界被打掉——六个角色，全部被改写

能力跟着问题走，不跟岗位走——技术与业务交圈，聚焦产品效果。

③ 新研发节奏 · 一阶段

AI DevOps · 功能开发——缩短链路，减少衰减

③ 新研发节奏 · 二阶段

AI DevOps · Agent 开发——效果先行，迅速进化

④ 组织失配 · 最尖锐的一击

不是 AI 深度用户，就做不出好用的 AI

产品的天花板 = 造它的人对 AI 的理解深度。传统组织做不出 AI 产品——一屋子浅度 AI 用户，组不出能做出好 AI 的组织（Conway 定律：产品复刻组织）。

同一个道理——客户那个班，你能不能上？ 干不了那个活，照样定义不出能干活的 Agent。

⑤ 小结 (1/2) · 五个被改写

相对传统开发，五个被改写的地方

每一条变化的背后，都是"谁定义、谁兜底、谁交付"的重新分配。

01

PO 主导"智能的设计"，而非只管需求和原型

传统 PO 写 PRD、画原型，"怎么聪明地干"交给开发和模型；现在 PO 直接主导 Skill 设计——定义 intent、写 SKILL.md、设计目录架构、mock 数据、定评价标准，亲手决定 Agent"怎么思考、怎么干活"。产出物从"描述"变成"制品"。

02

效果由 PO 定义和负责，而非开发交付后验收

传统里"好不好用"是测试验收的事；现在 PO 要先回答"怎么评价、标准是什么、用什么数据评"——效果的定义权与兜底责任落在 PO 身上。

03

归因决定谁来改，分工是动态的

内容风格 / 场景维度没覆盖 → PO 改；数据缺失 / 操作缺失 / 指令不准 → 开发改。同一问题，根因不同、责任人不同。

04

开发的重心从写业务逻辑转向建平台能力

逻辑大部分上移到 SKILL.md 层（PO 掌控）；开发负责底层确定性能力：CLI、脚本、后端 API、宽表治理。

05

评测取代测试，成为核心质量环节

输出是非确定性的，没法用断言式测试覆盖；需搭评测框架（程序化评测 + 大模型评测）——从"测试通过/不通过"到"评测打分/持续逼近"的范式转变。

⑤ 小结 (2/2) · 三条硬要求

新分工，对每个人提出了三条硬要求

不是优化建议，而是进入这套体系的前提条件。

01

NO BOUNDARY

不要有岗位边界

PO 要会写 SKILL.md、定义评测、设计信息架构；开发要理解业务怎么被编排。能力跟着问题走，不跟着岗位走。

// PO ⇌ DEV · 职责动态流动

10×

LEVERAGE

追求 10 倍生产力

AI 把执行成本压到极低，杠杆在于把人从重复实现里解放出来，去做定义、归因、编排。目标不是快 10%，而是一个人撬动十个人的产出。

// 杠杆点 = 定义 · 归因 · 编排

03

SYSTEMIC

体系化的工程能力

系统化、体系化思维 + 规划与落地能力。Harness Engineering 是复杂工程——像造汽车、造飞机，靠的不是灵光一现，而是一整套可重复、可演进、能交付的工程体系。

// 思维 + 规划 + 落地缺一不可

满足这三条，才谈得上"只有 AI 型组织才做得出 AI 产品"——下一站，看我们把它产品化的东西：MyAgents 平台。