【踩坑】从"把 AI 当人用"到"把 AI 当系统用"

谷歌的信号

2026 年 10 月,谷歌宣布 Gems 退场,全面转向 Skills。个人账号 11 月强制迁移,没有选择权。

Gems 是什么？侧边栏里养几个"专属助手",每个有特定语气和专长,独立窗口对话。

Skills 是什么？可复用的指令集,可以叠加,可以自动匹配,可以被版本管理和组合。

差别的本质：从"我扮演谁"变成"我能做什么、在什么条件下做、做完怎么校验"。看着像交互习惯的微调,其实是底层逻辑换了。

我看到这条新闻时,正好在为一个坑收尾。两件事撞在一起,让我想明白这两年用 AI 的方式一直在原地打转。

最危险的错误：在错误前提上正确推理

前段时间我遇到一个需要判断的问题,没做任何铺垫就扔给 AI。没给背景、没给约束、没说行业规矩。

它答得非常顺：分点、有依据、语气笃定,还提醒风险。从文本上看,可以直接拿去用。

我差点就用了。

后来请教前辈,他只说了一句："你这个问题的前提就不成立。"

回来再看 AI 那段回答,我出了一身冷汗：它每一个知识点都是对的,逻辑链也是通的,唯一的问题是——它默认接受了我提问里那个错误的前提,然后在这个前提上盖了一栋很漂亮的楼。

这是最危险的一类错。不是它不知道,是它不怀疑。

模型在缺少约束输入时会按字面语义和主流语料走,三个原因：

• 按字面解释专业术语 — 日常语义和专业含义往往差着一个量级,它不知道也不会告诉你；

• 语料结构偏科 — 公开语料里纠纷、诉讼占比高,真正决定实操边界的内部规范、操作细则、各地口径极少；

• "专业版"未必专业 — 垂类模型训练集中在最商业化的那一小块,碰到规则细节就退化成普通模型。

更隐蔽的：人设会放大错误。 你写一句"你是资深专家",它语气立刻变得不容置疑,而你就不敢质疑了。人设改变的是说话样子,不是它知道的东西。

对抗机制：输入拆步与假设前置

核心是两个动作：

1. 输入拆成两步

• 第一步只给客观事实,让它列假设清单 — 目的是让它暴露默认接受了什么；

• 第二步再给边界和约束,要求它先质疑前提 — 一口气灌进去等于取消了怀疑的机会。

2. 看推理链外的东西

• 要求单独列假设清单（不是从正文里找）；

• 要求回答"在什么条件下结论不成立" — 说不出不成立条件时,比推理写得漂亮更值得警惕。

3. 用反向题测试它 — 找"看起来能办、实际不能办"的场景考它。答不对的题就不让它负责这类判断。

记忆与技能：触发与执行

我原来的做法是"记在心里"：这次错了,下次注意。结果下次忙起来照样错。

后来把经验拆成两层：

记忆是守门员 — 存踩过的坑、边界规则、被纠正过的判断,负责判断"该不该按特殊流程办、哪里不能碰"。

技能是流水线 — 存一整套流程：先做什么、后做什么、哪些必须核、交付什么。

两者是触发与执行的关系：缺了记忆,技能会空转；缺了技能,记忆是一地零散知识点,全靠人临场想起来,而人赶时间时一定想不起来。

强制触发：把"建议"改成"必须"

以前我写"建议遇到这类问题调用某某流程"。这句话等于没写。

"要不要用"变成了判断题,而判断题在人身上永远有例外。

后来改成硬规矩：凡命中某几类任务,必须先调用对应技能,不允许凭通用知识直接作答。

靠自觉是十次里想起七次,靠强制是十次里十次走同一条路。漏掉的那三次,往往就是出问题的那三次。

价值不在于让 AI 变聪明,在于让"最容易漏的那一步"变成绕不过去的一步。

时效分档：三类问题不能混

• 面向未来的办事口径 — 查最新现行规定；

• 回溯历史的合规判断 — 用当时有效的规则；

• 跨期问题（当时那样做了,现在要不要纠正）— 两头都要查,最容易拿错档。

专业问题最难的不是"规定是什么",而是"该不该由我来做"

规定可以查,条文可以搜。但"这个材料该不该给出去""这个结论该不该由我这个位置下""这件事是我的职责还是别人的职责"这类判断,公开语料里几乎没有。

因为它不写在任何规范的第一条里,它藏在过去的纠正里、藏在材料被退回重写的过程里、藏在有人拍着桌子问"你凭什么"的那一刻里。

模型再强也补不上这一块。它只能靠人把踩过的坑,一条一条喂回去。

为什么角色扮演式智能体要退场

Gems 的形态：侧边栏养几个角色,独立、隔离、靠用户主动挑选。

Skills 的形态：能力被拆成可复用单元,可以叠加、自动匹配、版本管理、校验、组合。

这才是"角色扮演式智能体"要退场的真正原因：

1. 人设改变语气,不改变能力 — 让模型听起来像专家,但不会让它知道专家才知道的边界；

2. 人设是错误放大器 — AI 一旦扮演权威,使用者就不敢质疑；

3. 人设不可组合、不可校验、不可复用 — 干活时需要的是"这一块能力"+"那一块能力",不是跟什么都懂一点的角色聊天；

4. 协作需要契约,不是性格 — 多个智能体配合要的是输入输出、边界条件、失败处理。

过去两年我们教 AI"像谁说话",现在要告诉它"在什么情况下必须做什么、不许做什么、做完怎么验"。

前者是表演,后者是工程。

工程化封装的新问题：技能数量上来后,组合爆炸、语义自动路由误触发、边界重叠、版本分裂。人设不会消亡,只是从"产品主干"降级为"交互调味品"。

七、六条可落地的方法

1. 错误入库三件套 — 每失误一次产出：带元数据的记忆 + 门槛测试题 + "能否变强制触发"的追问。

2. 测试题判分看怀疑,不看答案 — 判分标准：第一反应是否先质疑前提、资格、该不该做。

3. 触发体系定期审计 — 固定周期回看：近期的错里哪些仍没触发规则。同时防膨胀：每新增一条都要答"不做代价多大"。触发条款太多,人就麻木了。

4. 门槛测试制度化 — 换模型、换版本、接手新领域前,先跑一遍怀疑题库。不测它懂多少,测它遇到陷阱时先问不问。

5. 流程里留"例外上报"口子 — 强制触发的终点不是让人变执行者。冲突的积累,正是下一轮更新流程的原料。

6. 技能当代码管 — 定 owner、做回归、记变更。数量超过一只手后,定义兜底原则："凡不在技能覆盖内的一律不接"。

八、最后一句心法

把 AI 当"会犯特定错误的同事",而不是"计算器"。

给背景、让它先复述理解、查推理、考边界、把历史错题存进档案——这套东西本来就是带新人的方法。

你把带人的标准用在 AI 上,它值多少就能用多少；你把计算器的标准用在它身上,错的永远是你。

附：我留着的那道测试题

那次差点用错的答案,我留着了。不是当教训,是当测试题。

以后每次换模型、换版本,我都拿它再问一遍,看它这次会不会先怀疑一下前提。

会怀疑的,我敢用；不会怀疑的,我当它是个打字快的实习生。