朋友问过我，面试里被问「你会用 AI 吗」该怎么答。我说别答工具名。
不是工具名不能提，是提了等于没提。会打开对话框、会写几句提示词，现在跟会搜索差不多，属于默认技能。面试官问这句话，问的其实是另一件事：我交付的东西稳不稳定，以及这份稳定有多少能复制给别人。
这两点，靠一次漂亮的问答证明不了。
单点提问没有可复制性
我自己也经历过那个阶段。遇到不会写的东西，打开一个模型，来回几轮，复制答案，改一改交出去。效率确实高，但整个过程依赖临场发挥：提示词怎么写、模型这次给得好不好、我当天有没有耐心多问几轮。
这种方式的产出上限由个人状态决定，下限也一样。它没法交给别人，也没法在出问题时定位是哪一步坏的。
更麻烦的是，它给人一种错觉：我已经会用 AI 了。实际上我只是会用一次。
真正让我改变习惯的是一次返工。同一类文档我写了十几份，每次都要重新想一遍结构、重新解释背景。写到第七八份的时候我才意识到，重复的不是写作，是我在反复给模型补同样的上下文。后面我把这部分固定下来，做成一套模板加检查项，同样的活从半天变成一小时，且换个人也能做。
那次之后我对「会用 AI」的理解就变了：不是问得多好，是能不能把一次性的事变成能重复跑的事。
这里有个不太直观的点：一次成功的问答，往往是因为我在那个具体问题上有很多背景知识。我知道该给它什么材料，知道它哪句话在胡说，知道该怎么改。换成别人，同样的提示词大概率得不到同样的结果。所以「我上次这么问效果很好」这种经验，传播价值很低，除非把背景知识也一起写下来。
可复制的东西恰恰是这些：任务怎么拆、需要哪些输入、输出长什么样、哪一步必须人看。提示词只是最表面的一层，而且会随模型版本变化而失效。
一条流程要拆到卡点上
流程这个词听起来大，拆开其实就三段：人给什么，机器做什么，人在哪里接手。
第一段最容易被低估。给模型的东西不只是提示词，还包括背景、约束、示例，以及这一步的上游产物。同一个模型，输入组织得好不好，结果差得很远。我现在会先把「它需要知道什么」列清楚，再写指令，顺序反了通常要重来。
第二段是模型真正擅长的：批量处理、从非结构化内容里抽取、生成初稿、做格式转换。这些活的共同点是量大、判断标准相对统一、错了也能被发现。
第三段是卡点。哪里必须停下来让人看一眼，这是流程设计的核心，而不是附加项。判断卡点位置的方法很朴素：这一步错了，代价是什么，能不能事后发现。代价高又发现不了的，就必须有人看；代价低且容易发现的，让它过去，靠后面的检查兜住。
我见过一些流程把卡点设得很密，每一步都要人确认。结果是人变成了流水线上的按钮，效率没提升，责任还模糊了。卡点不是越多越安全，是越准越安全。
拆流程的时候还有一个习惯，我会先把最坏情况走一遍。模型给了完全错误的输出，这条链路会把它带到哪里，中间有没有哪一步能发现。如果答案是「一路带到用户面前」，那不管准确率多高，这个设计都是不合格的。反过来，如果错了会在某个环节被拦下，那这一环就值得投入。
回滚也是流程的一部分。改动之前先留一个能退回的版本，比事后分析哪里坏了更实际。我见过一些团队把提示词直接改在线上，改完效果不好却找不到原来的那一版，只能凭记忆重写。这种损耗看起来小，累积起来很伤人。现在我习惯把每次改动和对应的测试结果放在一起，至少能回答「上次那版是什么样」。
举个我自己用过的例子。整理一批访谈记录，以前是逐条读、手工摘。现在会拆成三步：先把录音转文字，再用模型按固定的几类问题抽取观点，最后我对照原始录音抽查一部分。第二步最省时间，也最容易出错——模型会把语气模糊的话补成确定结论。所以我的卡点放在第三步，抽查比例不高，但专门挑那些「说得特别顺」的段落看。写得越漂亮的地方，越可能是它自己补的。
这套流程的产出不一定比人工好，但它稳定，而且换人也能跑。
人在环里，要落在具体的位置
「人在环里」这句话被说得太多，已经快变成一句口号。落到实处，它是几个很具体的问题。
谁看第一版？看的人需要什么信息才能判断？他看完之后能做什么——是改，是退回，还是直接否决？
如果这三个问题答不上来，那这条流程里其实没有人的位置，只有人的签名。
我的做法是把审核拆成两类。一类是事实性的，检查数字、引用、名称对不对，这类可以靠对照原始材料快速过一遍。另一类是判断性的，这段内容该不该发、这个候选人该不该进下一轮、这个方案在这个约束下成不成立，这类没法外包给模型，也不该外包。
两类混在一起审，人会累，然后开始走形式。分开之后，前者可以批量处理，后者才值得花时间。
还有一件事我越来越在意：模型不确定的时候，流程要能承认不确定。低置信度的结果应该被标出来，而不是被包装成正常输出混进下游。这一点在产品上体现为一句提示、一个待确认标记、一次转人工，看起来都是小事，但它决定了错误是被拦住还是被放大。
这条原则的反面是自动化偏见。人看多了看起来专业的输出，会慢慢停止怀疑，尤其是当它十次里对了九次的时候。第十一次错的那条，反而最容易被放过。所以卡点不能只设在「模型说它不确定」的地方，还得有随机的、不打招呼的复核，专门对付这种疲劳。
工具会换，流程不会
我不用特别在意自己现在习惯的是哪个模型。这一年里主力工具换过几次，提示词的写法也在变，但流程里的结构没怎么变：输入怎么组织、哪一步交给机器、哪里设卡点、出错怎么回滚。
这套东西是可迁移的，也是面试里真正值得讲的部分。讲的时候不需要罗列工具，只要说清楚一件事：这个活以前怎么做，现在拆成了几步，哪一步最容易坏，坏了以后怎么发现。
真要说工具层面有什么值得提的，是边界而不是名字。哪些数据不能往外发，哪些场景必须用私有部署，哪些输出不能直接进对外文档。这些约束一旦定下来，具体用哪家模型就变成了可以替换的细节。反过来，如果流程默认所有材料都可以贴进公开对话框，那换多少个模型都补不上这个洞。
提示词会衰减这件事也值得提前想。业务规则变了、上游模型更新了、输入分布漂了，原来那套指令就可能不再好用。所以我会留一个小规模的固定测试集，每次改动之后跑一遍，看输出有没有明显变化。它不追求精确评分，只用来发现「这次改完好像不太对」这种直觉背后的依据。
我暂时还没有一套通用的流程模板，也不觉得应该有。不同业务的容错率差太多，同一个卡点放在这个场景是必要的，放到另一个场景就是负担。能确定的只有一点：把 AI 放进流程里，目的是让结果更可控，而不是让过程看起来更先进。如果用了模型之后，出错时反而更难定位问题出在哪，那这次改造大概率是失败的。
评论