AI 试点范围界定

每一次能力跃迁——GPT-5.6 那种旗舰更新、ChatGPT Work 那种能连续干几小时的产品形态、GPT-Live 那种实时语音——团队都会重新问一遍「我们要不要上」。这个问题经常变成一个跑了半年、结束时仍然没有结论的项目。

一次试点的产物是一个决定，不是一个功能。 这句话决定了它该被怎么框住。

先有一个能被证伪的问题

「AI 能不能帮我们提效」不是问题，因为它没有能判错的答案。能拿来跑试点的问题长这样：能不能把某一类工单的首次响应时间从 A 降到 B。

开工前的三条自检：

1. 问题能被证伪——存在一种结果会让你说「不做」。
2. 判据是现成的——如果要先造一套评测才能开始，那试点还没开始（判据怎么设计归「模型与输出评估」）。
3. 失败是便宜的——要限制的是影响半径，不是预算。

优先挑「答案已经在你手里」的用例

最便宜的试点，是那些正确答案已经躺在历史数据里的任务：处理过的工单、审过的合同、改过的 PR。它们自带评测集，你不需要为了判断好坏再花一轮标注成本。

这也是一条实用的排序：能用历史数据判分的用例，永远排在需要人工新标注的用例前面。

分清「令人兴奋」和「你的约束」

新能力最容易骗人的地方，是它解决的问题不一定是你的问题。实时语音很惊艳，但延迟是不是你真正的瓶颈？端侧小模型很吸引人，但先咬人的到底是隐私还是成本？

先确认哪个约束先咬人，再看新能力有没有解开它——这一步和「模型选型与约束匹配」是同一个问题的两端。

先定结束条件，再开始

一次没有结束日期的试点，最后会变成一套没有人负责的系统。开工之前先写下两件事：什么时候看结果，以及看到什么就停、看到什么就扩。

OpenAI 复盘长时程模型部署时用的是同一个形状：小步放量加持续观测。试点和放量的区别只是规模，不是方法。

失败的试点也必须交付一样东西

一次得出「不做」的试点是成功的试点——前提是它写下了理由。没有写下来的否定结论，六个月后会被原样重新提一遍，而且没有人记得上次为什么否掉。

与相邻能力的分工

这一条回答先做哪个用例、怎么框住它、什么时候收。自建还是买、哪一层必须归你，是「AI 工具链选型与自建边界评估」；用多大的模型，是「模型选型与约束匹配」；判据怎么设计，是「模型与输出评估」；真正上线时人放在哪个位置，是「人在回路的审查」。