和朋友讨论组织的 AI 化时，有一句话点破了本质：
「训练过模型的人都懂：损失函数错了，训练步数越多，跑得越偏。」
组织也一样。目标错了，团队越勤奋，死得越快。
训练速度从来不是问题，梯度方向才是。而大多数组织最大的危机是：它们从未认真检查过，自己正在优化的那个东西，到底是一个目标，还是一个愿望。
一、99% 公司的 OKR 是「许愿型目标」
「希望营收翻倍」「希望成为行业第一」「希望提升用户满意度」——这些不是目标，是许愿。
许愿型目标有三个致命缺陷：
- 不可分解——推不出任何具体可执行的动作。「营收翻倍」分解不到任何一个人周一早上的动作，只能分解成一句更响亮的口号。
- 不可验证——不知道某个动作到底有没有让它变好。做了 A 也做了 B，看起来都有关，又都说不清。
- 不可归因——成了不知道为什么成，败了不知道为什么败。于是明年继续许同样的愿。
许愿型 OKR 本质上是老板的祈祷文，层层分发后早已失去信号。每一层都把它翻译成自己那一层的祈祷，最后落到一线，只剩一个没人知道来路的数字。
为什么组织偏偏选择许愿？因为许愿是最便宜的管理动作：写一句话的成本趋近于零，却同时完成了三件事——对内宣告雄心、对上交付交代、对下制造忙碌。相比之下，定义一个可验证的目标要贵得多：你得先承认自己不知道答案在哪，得去翻数据、做归因、接受被证伪的风险。许愿免除了这一切。所以问题从来不是「老板不懂目标管理」，而是 组织的激励结构在奖励许愿、惩罚求真。
更学究一点的反对意见会说：OKR 本来就不是归因工具，Doerr 自己都说 OKR 用于对齐、不用于考核，把 OKR 当损失函数，是把组织工具化了。
我不否认对齐的价值。但对齐需要一个目的地——如果对齐的目标本身是许愿，那对齐到的只是情绪，不是动作。损失函数也不取代人的意义感，它只是把「目标」里不可验证的部分剥掉；至于什么值得优化，那恰恰是人要回答的问题。
所以常见的药方——把 OKR 写得更认真、开更多的对齐会——都开错了。祈祷不会因为写得更认真而变成目标。问题不在写法，在那东西的本性。
二、真正的目标藏在数据里：确定性机会
什么是好目标？一句话：
干哪些关键变量，对经营有确定性收益。
讨论里有个例子。一家零售企业复盘经营数据时发现：北方地区导购的执行率只有南方的一半。一路归因下去，发现是时差问题——执行任务的时间窗设置，没有对上北方门店的实际营业节奏。
这就是一个典型的「确定性机会」：
| 维度 | 许愿型目标 | 确定性机会 |
|---|---|---|
| 变量 | 模糊（满意度、竞争力） | 明确（导购执行率） |
| 因果 | 说不清 | 明确（时差 → 执行率） |
| 动作 | 无（「提升服务意识」） | 明确（调整执行时间窗） |
| 收益 | 祈祷 | 确定（补齐即增收） |
这种目标不是「设计」出来的，是 从数据里挖出来的。它不在会议室的头脑风暴里，而在没人认真看过的经营数据里。
这也是「经营是一门科学」的真实含义：目标不是宣布出来的，是被发现的。宣布出来的，多半是愿望。
三、挖不出来，是因为缺的不是目标，是试错系统
这里我要为讨论里另一方的观点站台：
企业缺的不是目标，而是可快速试错的数字系统。
就算发现了确定性机会，还要回答三问：
- 干预有效吗？——是因果还是相关？调整时间窗真的有效，还是北方执行率低背后另有原因？
- 成本划算吗？——ROI 为正吗？改时间窗的代价是多少，换回的执行率提升能折算成多少收益？
- 能规模化吗？——在一个北方城市有效，能泛化到所有北方城市吗？南方呢？
没有试错系统，每个假设只能靠开会拍板、靠年度周期下注——回报周期太长，等结果出来，市场早就变了。
这正是可怕的地方：组织之间的差距，不是谁的口号更响，而是谁的试错闭环更快。
Booking.com 是照出这个差距的一面镜子。这家以实验文化闻名的公司，把 A/B 测试变成了产品决策的默认语言（公开报道）——任何改动，不管是谁的主意，都得先过实验。它和大多数企业的差距，不在于聪明人的数量，而在于 把一个假设变成已验证结论的速度。
我在 AI 的竞争变了：未来是上下文的竞争 里说过，竞争的胜负手在上下文。试错系统是同一个判断在目标层的延伸：上下文决定 Agent 能不能把事做对，试错系统决定组织能不能把目标定对。
四、Agent 时代，损失函数终于有了执行者
在 Evals 是新的 PRD 里，我讲过 Loss Function Development（LFD）——不要告诉 Agent「做什么」，要告诉它「什么算做好了」。那说的是产品层。这场讨论把同一件事推到了组织层：
从会议、聊天、物理世界
挖出候选目标
│
▼
┌───────────────────┐
│ 试错系统验证因果 │
│ 有效? 划算? 可泛化? │
└───────────────────┘
│
▼
┌───────────────────┐
│ 沉淀为组织 OKR │
│ （损失函数） │
└───────────────────┘
│
▼
Agents 围绕它 24 小时迭代
# generated by hugo AI
这四个阶段——挖候选、验因果、沉 OKR、Agent 迭代——构成一个 损失函数闭环。它是可复用的：任何组织、任何业务线，都可以用同一个骨架把自己的经营目标从愿望改写成函数。下面看看这个闭环的工程形态。
「把经营写成损失函数」具体长什么样？用工程语言表达：目标必须写成机器可消费的结构——变量明确、基线明确、干预明确、归因窗口明确。对照导购那个例子，最小骨架是：
from dataclasses import dataclass
from enum import Enum
class TrialVerdict(Enum):
SCALE = "scale" # 值得规模化
ROLLBACK = "rollback" # 回滚
@dataclass
class OrgLossFunction:
"""组织的损失函数：把经营目标写成机器可消费的结构。"""
goal: str # 目标变量：哪个变量的变化带来经营收益
metric: str # 度量口径：单位、数据来源、取数方式
baseline: float # 基线：现状值（挖出来的，不是许出来的）
intervention: str # 干预：具体动作（可分解到周一早上）
attribution_window_days: int # 归因窗口：干预后多少天内验证因果
cost_budget: float # 约束：干预成本上限（ROI 门槛）
def gradient(self, observed: float) -> float:
"""这次干预让指标动了吗？正 = 值得规模化，负 = 回滚。"""
return observed - self.baseline
def run_trial(loss_fn: OrgLossFunction, observed: float, cost: float) -> TrialVerdict:
"""跑一次试错：度量 → 归因 → 决策。决策规则只有两条。"""
if cost > loss_fn.cost_budget:
return TrialVerdict.ROLLBACK # 超过 ROI 门槛，再有效也不做
if loss_fn.gradient(observed) <= 0:
return TrialVerdict.ROLLBACK # 干预没让指标动，回滚
return TrialVerdict.SCALE
# generated by hugo AI
run_trial 就是试错系统的最小内核：每个假设进来，要么带着「规模化」的判决出去，要么被回滚——没有第三种结局，也就没有「再开个会讨论讨论」的缝隙。注意 attribution_window_days 的位置：它不在决策里，在损失函数里——先约定多久能看到因果，再下注，这正是许愿型目标永远缺的那一步：它们从不约定验证期限，所以永远无法被证伪。
对照一下：「提升北方导购执行率」就是一个实例——metric 是执行率、baseline 是南方的水平、intervention 是调整执行时间窗、attribution_window_days 逼着你在下注前就回答「多久能看到因果」。而「希望营收翻倍」填不满这个结构里的任何一个字段。这就是许愿和目标在工程上的分界线。
这个最小骨架刻意只保留了「目标可验证」所需的字段——真实的组织损失函数会更复杂（多目标加权、约束耦合），但多出来的都是工程问题，不是认知问题。
而且它是通用的。换一个业务线照样成立：客服响应慢——metric 是首次响应时长，baseline 是同行中位数，intervention 是夜间排班重排，归因窗口两周；库存积压——metric 是周转天数，baseline 是品类基准，intervention 是补货阈值下调。每填一次骨架，一个愿望就变成一次可验证的实验。
在这个闭环里，分工被重新定义：
- Agent 的价值不是「更聪明」，而是不睡觉地迭代。 试错周期从季度压缩到天。
- 人的价值不是「执行」，而是定义什么值得优化——也就是写损失函数。
但也要泼一盆冷水：「24 小时迭代」的前提，是你真有驾驭它的工程能力。在 健康检查全绿，数字员工失联了 16 分钟 里，我记录过数字员工在生产环境里跑偏的真实案例。没有可观测性、护栏和回滚，24 小时迭代的组织，只是 24 小时快速翻车。
五、完整的训练闭环：样本、正则与反向传播
前四节讲了损失函数怎么写、怎么验证。但把组织当一部机器学习系统看，只有损失函数还不够——训练需要完整的闭环。
先定义输入：经营数据 + 组织反馈 + 外部环境 = context。把组织当成机器学习的进化过程来看，这份 context 就是当前的样本。
经营数据 + 组织反馈 + 外部环境
│
▼
Context（当前的样本）
│
▼
组织模型（决策与执行）
│
▼
损失函数反馈：差多少？方向在哪？
│
▼
梯度 = 差距 × 方向
│
▼
反向传播：更新每个参数（每个组织成员）
# generated by hugo AI
样本进入组织这部模型，损失函数给出反馈：离目标差多少。但这个反馈有两道门槛。
第一道：它不仅要知道差多少，还要给出方向。差多少只是一个标量，带方向的差距才是梯度。只有梯度，才能通过反向传播去更新每一个参数——组织里，每个参数就是一个组织成员。
第二道：它要经得起「正则」的挑战。损失函数不能只追求正确的结果，还要追求可以泛化的结果。只在一个城市验证过的打法，可能只是过拟合——正则项逼着组织多问一句：这个结果，换个市场还成立吗？
这个闭环，就是组织复盘的真实含义：
- 发现机会和风险——读取样本，计算损失；
- 组织复盘对齐——确认梯度的方向；
- 反向传播——更新每个参数，让听得见炮火的人呼唤炮火。
「让听得见炮火的人呼唤炮火」，正是反向传播的组织学表达：误差信号必须来自离样本最近的一线，再逆向传回资源与决策所在的位置。
反过来看，传统组织的病也就清楚了：层层汇报之下，一线信号每过一层就衰减一次，等传到决策层，梯度早已消失——组织学不到任何东西。
结论
OKR 从来不是问题，许愿型 OKR 才是。
目标从来不缺，缺的是从数据里挖出确定性机会、并快速验证它的能力。
AI 时代真正的组织能力，是把经营写成可微的损失函数——让每一步动作对目标的贡献都可度量、可归因。这恰恰是把许愿型目标的三个缺陷反过来：可分解、可验证、可归因。
损失函数只是起点。真正的分水岭是能不能把完整的训练闭环——样本、正则、梯度、反向传播——跑起来。
谁先写出损失函数，谁就先拥有 24 小时迭代的组织。
你的组织的 OKR，能分解到任何一个人周一早上的动作吗？欢迎留言聊聊。