AI Native，从重新设计工作开始

懂 AI 术语、消耗更多 Token，或者给每个工作流都加上 Agent，都不代表 AI Native。

AI Native 意味着看清 AI 改变了哪些成本与约束，再据此重新设计工作。目标是做出更好的结果，并为结果负责。多用 AI 本身没有意义。

从实际结果出发

数据分析究竟交付什么？SQL、仪表盘和模型只是手段，真正的产出是更好的决策，例如该修什么、服务谁、把钱投在哪里，以及何时该停下来。

如果 AI 让分析快了十倍，却依然没人知道下一步该做什么，它只是加速了一个中间环节。AI 会放大清晰的思路，也会放大混乱。

许多最佳实践都来自过去的成本结构。代码昂贵，所以我们复用代码。全面观察代价太高，所以我们抽样。执行成本高，所以我们增加交接。成本变了，围绕这些成本建立的流程也该重新审视。

因此，AI Native 的工作先问一个问题，再考虑工具。

按照今天的能力和成本，现在怎样做这件事最好？

初学者不知道什么方法有效。专家可能太熟悉过去有效的方法。

经验里既有经得起时间考验的判断，也有旧限制塑造的习惯。AI Native 的专家会把两者分开。他们保留对质量和风险的理解，同时重新审视那些原有约束已经消失的做法。

这并不轻松。可复用代码听起来比一次性代码好。完整规定的流程听起来比允许 Agent 自选路径更安全。亲自检查听起来也比自动检查更负责。每种直觉都有道理，但都应对应它要控制的具体风险。

假设一名工程师需要核查一个大型标注数据集里的错误是否已经修正。按传统做法，他要么花几小时开发检查工具，要么抽样检查，接受较低的可信度。

AI 带来了第三种选择。工程师可以让 Agent 搭一个小网站，用来比较、筛选和搜索数据。他可以检查完整分布，找出有问题的类别，然后丢掉这个网站。

当代码便宜，错误决策却很昂贵时，一次性软件可能更合理。代码不必留下，更好的判断需要留下。

这套做法不适合处理资金、身份、权限或长期业务规则的软件。有些代码是基础设施，有些只是临时工具。使用寿命并不总能衡量价值。

负责并不意味着必须控制每一步。

以自动翻译为例。传统工作流可能会拆分文档、合并结果、统一术语、检测缺失文本、重试失败任务，并从中断处恢复。每出现一种新故障，团队就增加一条规则，最后维护编排花掉的时间超过了改进翻译的时间。

在基于 Agent 的运行环境中，Agent 可以直接处理文件、检查输出、修正错误并重试。人来定义怎样才算“完成”，脚本则检查格式、术语和缺失文本。

关键变化在于确定性来自哪里。

传统软件通常追求过程确定性，提前设计每条分支，让结果可靠。

Agent 工作可以追求结果确定性，路径可以变化，但结果必须满足明确标准，并提供证据。

安全、权限、支出和不可逆操作仍需严格控制。在其他场景中，控制重点可以转向目标、边界、评估和反馈。只要验收标准足够明确，灵活的过程依然可以问责。

专家使用 AI 时，常像初任管理者。他们看到工作不够好，就亲自接手，最后自己成了瓶颈。

有效使用 AI，需要转换角色。

从亲手产出每个结果，转向建立一套能反复产出好结果的系统。

质量控制必须跟上产出规模。不要再亲自重复同一项工作，而要寻找独立证据，例如测试、不变量检查、来源对比和按风险分级的审查。人的注意力应留给架构、高风险决策和例外。

委派方式也会随之改变。差的指令罗列步骤，好的指令会定义结果、背景、边界，以及完成任务所需的证据。Agent 有空间自行工作，专业人士仍要对结果是否有用、安全负责。

执行越来越便宜，选择执行什么就越来越重要。

AI 产出的内容可以多到一个人根本看不完。心里没有明确的决策目标，低成本生成只会堆出更多看似合理的产物。

稀缺资源变成了判断力，包括定义问题、识别重要约束、设计可信的评估，以及判断现有证据何时已经足够。AI 既提高了好判断的价值，也放大了批量执行错误判断的代价。

一个人重新设计过哪些工作，比他使用什么工具更能说明他是否 AI Native。

初学者要培养判断力。专家要把判断力与沿袭下来的习惯分开。每个人都要知道什么该保留、什么该忘掉，以及怎样在新的约束下重新设计工作。

每次引入 AI，都可以用上面五个问题复盘一次。如果变化只发生在工具和产出速度上，工作方式还没有真正重构；当约束、证据和责任分配也随之改变，AI 才进入了工作的设计层。