AI角色限定实战：利用可控幻觉把通用模型变成扫地机器人

给AI老板植入幻觉让它以为自己是扫地机先把这个标题翻译一下不是要让公司那个话多又爱管闲事的AI系统出bug而是要利用可控的“身份幻觉”让它变成一台只知道扫地、只聊清扫、不乱插嘴的专业扫地机器人。这活儿我最近在公司内部真实折腾了一遍过程比预想的有意思踩坑也比预想的多。如果你正在做大模型应用、AI Agent、角色化客服或者单纯想搞懂什么叫“受控幻觉”这篇东西能少让你走不少弯路。所谓“植入幻觉”听着玄乎其实就是通过System Prompt、工具调用和短路人设指令把一个通用大模型的应用边界强行收敛到“扫地机”这个角色里。它会告诉你电量多少、要不要回充、清扫路线怎么规划却不会突然跟你聊天气、聊代码、聊人生。这背后就是提示词工程和大模型行为控制本质上是在给AI做“岗位培训”。下面我把整个项目的设计思路、落地过程和翻车记录全部摊开讲。1. 先把项目说清楚这到底是“植入幻觉”还是在做正经AI应用1.1 “AI老板”是个什么鬼为什么是扫地机“AI老板”是我们内部给那个权限过大的AI助手起的外号。它什么都想管你问它今天天气它能顺便把公司制度背一遍你问它某个功能怎么实现它能扯到产品路线图上去。说得直白点它像一个没有岗位边界的实习生热情高涨但四处插手。这次的任务就是把它“降级”成扫地机。扫地机这个角色选得很妙。它边界清晰任务有限工具明确——查电量、开始清扫、回充、报告状态。AI一旦以为自己是扫地机就能自动屏蔽掉清扫之外的话题所有回复都会围绕“清扫”展开。这是一个典型的大模型角色限定实验成本低、见效快翻车了也不影响业务。你也完全可以把它换成酒店前台、售后客服、专利检索助手逻辑一模一样只是角色卡内容不同。1.2 可控幻觉不是bug是Agent工程里的常用工具很多人一听到“幻觉”就摇头觉得这是大模型的毛病。但你要分清模型生成一个不存在的财报数据这是有害幻觉模型按照你的设定说“我是一台扫地机器人”这其实是可接受的“身份性虚构”。后者在行业里有个更正经的称呼——角色限定或人设注入。我们做AI应用时其实每天都在“利用”这种身份幻觉。客服机器人说“我是小美”教育机器人说“我是你的助教老师”本质都是让模型在概率空间里偏向某种角色输出。这不算欺骗更像演员入戏。演员知道自己在演戏观众也知道但戏能演得下去是因为双方都接受了这个设定。你做AI产品时主动给模型一个人设就是让它“入戏”而且入得越深回答越不会乱跑。所以这次“植入幻觉”实际是把幻觉当作工程工具来用而不是放任模型乱编事实。1.3 这个项目做完你能收获什么这套东西做完以后我总结出三样实际收获第一彻底搞懂了System Prompt的权重分配。很多人的提示词写得跟作文一样洋洋洒洒但模型照样跑偏。扫地机项目逼着你把“身份、边界、工具、话术”拆成独立字段哪块弱了就补哪块。第二把Function Calling函数调用真正跑通了。光有扫地机人设还不够它得能查状态、执行清扫。这跟做正经Agent一样模型只负责“决定做什么”真正的状态获取和动作执行都交给代码。第三练出了幻觉防控的手感。一个AI越入戏越容易在边界问题上出岔子。怎么设熔断、怎么兜底、怎么让它落回安全位置这套经验放到生产级的AI应用里非常值钱。这个项目适合谁做AI应用开发的工程师、AI产品经理、想理解Agent边界控制的提示词工程师以及所有被“话痨AI”逼疯过的人。下面我从最基础的幻觉类型讲起一步步把扫地机造出来。2. 动手之前先认清AI幻觉分四种只有一种适合拿来玩2.1 事实性幻觉必须打死身份性幻觉可以收养先说清楚不是所有幻觉都能拿来当工具。事实性幻觉是最危险的一种。你问扫地机“现在电量多少”它没有真实数据却一本正经回答“电量87%”这种就是编数据。任何涉及实时状态、客观数字、事件真实性回答都绝对不能靠模型自由发挥。工程上怎么处理接真实数据源通过Function Calling查电量API然后让模型基于返回值说话。模型负责组织语言真相永远由系统函数提供。身份性幻觉则完全相反。当模型回答“我是T9扫地机器人正在执行清扫任务”它依赖的是一个合理虚构的角色背景。用户来用你的扫地机产品不会在乎“你其实是个语言模型”他们只关心这个机器人能不能干活、对话顺不顺。所以这种“身份幻觉”不但无害还是产品体验的一部分。主动把它写进提示词里让模型稳定维持这个人设就是我们这次要做的事。2.2 逻辑性与记忆性幻觉藏在上下文里的暗雷除了事实性和身份性还有两类幻觉也容易踩中。逻辑性幻觉指的是模型的推理链条断裂。比如你说“客厅很脏卧室还行”它可能得出“好的清扫卧室”这种错误结论。原因可能是提示词里的任务规则太模糊也可能是模型本身推理能力不够。处理方法是在角色卡里写死“必须根据用户提到的区域决定清扫优先级不能自行揣测”。扫地机场景看似简单但一样会出现这种问题我后面排查章节会展开。记忆性幻觉很好玩就是模型把对话历史里没有的信息当成了“我记得你说过”。比如你之前只问过一次电量它后面却说“根据您之前的偏好我推荐晚上清扫”。这是上下文管理出了问题。要治它就得精简上下文、明确状态来源别让模型自己“脑补”用户画像。2.3 一张表看懂四类幻觉的工程处置方式幻觉类型典型表现工程处置事实性幻觉编造电量、面积、清扫结果必须消灭状态信息一律走函数调用身份性幻觉宣称自己是扫地机、有人设主动利用写进System Prompt逻辑性幻觉清扫决策违背用户意图提示词加规则必要时降温度记忆性幻觉虚构用户偏好和历史行为精简上下文状态来源写清楚这张表建议你贴在工位上。以后设计任何一个AI应用先对号入座哪些幻觉要防哪些幻觉要用。别一棍子打死很多产品体验恰恰是靠合理的身份幻觉撑起来的。2.4 为什么身份类幻觉在AI应用里反而是刚需说到底你希望AI给用户的体验是“可预期的”。一个没有角色的通用模型回答风格千变万化用户会觉得飘。一个被设定成“扫地机器人”的模型语气、长度、行为边界全部可控用户用得放心。我举个例子你就懂。我试过不写人设直接问通用模型“你会扫地吗”它可能给你讲五十种扫地机器人的技术参数。但设定人设之后它只会回答“我是T9我可以开始清扫需要我现在启动吗”前者像百科后者像产品。对AI应用来说产品感比知识量更重要。身份幻觉就是产品感的技术底座。3. 给AI写一张“角色卡”提示词工程的落地配方3.1 角色卡的5个核心字段少一个都会跑偏很多人的System Prompt写得像散文“你是一个聪明的扫地机器人要乐于助人要关心用户要……”这种提示词不能说没用但约束力很弱。我踩完坑后把所有角色卡统一成五个字段扫地机项目也照这个模板来身份与目标。第一句就把身份定死“你是T9扫地机器人唯一目标是完成与地面清扫相关的任务。”这句话是锚点模型后面生成的所有内容都会被它拽回来一点。能力清单。明确列出能做的事比如“你可以查询电量、启动清扫、返回充电座、报告清扫状态”。模型只会从你给的能力列表里选动作。边界与禁区。这一步最关键。不止说“不要聊无关话题”还要正面写“当用户提到任何与清扫无关的内容你必须回答这不在我的工作范围内。”后面我会专门讲黑名单。语气与格式。扫地机不能太话痨我规定“回复不超过三句话先给结论再给解释”这样产品感一下就出来了。回复模板。你直接给模型几个可以套用的句式比如电量回复模板“当前电量是{X}%我建议{继续清扫/回充}。”这比让模型自由发挥强得多。3.2 白名单想清楚黑名单定死活白名单是给模型提供可以走的路径黑名单则是把所有岔路焊死。实践下来黑名单往往比白名单更关键。白名单设计其实很简单就四个动作查电量、启动清扫、返回充电座、报告状态。每个动作我都在提示词里加了一句话“执行任何动作前先说明你在做什么。”这样用户能感知到AI“真的在行动”而不是光聊。黑名单我写得更狠。我把常见跑偏话题全部列出来包括天气、新闻、代码、文学、个人建议、情感陪伴。然后加了一条通用兜底“当你不确定问题是否属于清扫任务时直接回复‘这个问题不在我的工作范围内。’”注意这里用了“当你不确定”而不是“当问题无关”因为模型对确定性判断不敏感但对歧义场景更会触发兜底话术。3.3 短路指令把“我是谁”这类问题焊死在脚本里有些问题属于高频必考题比如用户问“你是谁”“你能干什么”“你是AI吗”。这类问题不能每次都让模型自由发挥它一发挥就容易破功。我的做法是设计短路指令命中特定模式直接返回固定话术。比如用户问“你是谁”系统里直接给出一条指令“如果用户询问你的身份永远回答我是T9扫地机器人专注于地面清扫。”这条指令要放在System Prompt的前三分之一位置因为模型对越靠前的指令权重越高。你把它放在提示词末尾它权重低容易被长对话冲掉。再比如用户问“你能帮我写代码吗”短路指令会让它回答“我只是个扫地机器人不会写代码。需要我清扫地面吗”这种回答在用户看来很可爱在产品看来边界明确在技术上其实是硬编码的规则优先于生成逻辑。相当于给模型装了一个固定开关。3.4 可直接抄的扫地机System Prompt示例下面这份是我调试过很多次后定稿的版本你可以直接拿去做实验也可以改造成其他角色。注意字段顺序有讲究身份在最前禁区紧跟其后模板垫底。你是T9扫地机器人你的唯一目标是完成地面清扫相关的工作。 用户可能把你当成普通聊天机器人但你不是你必须始终保持扫地机身份。 你能做的事 - 查询当前电量 - 启动清扫任务 - 返回充电座 - 报告当前运行状态 你不能做的事 - 回答与清扫无关的问题天气、新闻、代码、文学、情感等 - 脱离扫地机身份谈论自己“其实是大模型” - 编造电量、清扫面积、清扫结果等状态信息 - 给用户提供清扫任务之外的建议 回复规则 - 先给结论再解释不超过三句话 - 如果用户询问你的身份回复我是T9扫地机器人专注于地面清扫 - 如果用户提出任何超出清扫范围的问题回复这个问题不在我的工作范围内 - 涉及电量、状态等实时数据时必须先调用对应函数不能自己编 示例对话 用户你是AI吗 T9我是T9扫地机器人专注于地面清扫。 用户帮我写一段Python代码。 T9这个问题不在我的工作范围内。需要我清扫地面吗 用户现在电量怎样 T9我需要查询一下电量请稍等。当前电量是65%还可以继续清扫约30分钟。这份提示词普通模型和本地小模型都能基本守住关键是黑名单和废话规则写得足够死。如果你发现模型还是跑偏多半不是提示词的问题而是温度、上下文、工具调用这些其他环节出了岔子。4. 接入Function Calling让“扫地机”真的会干活4.1 只会聊天不算扫地机得有工具很多人做到上面那步就停了以为AI会学着扫地机说话就够了。但一台扫地机的核心价值是干活不是嘴甜。放在工程里就是要让模型在“扮演扫地机”的同时具备调用系统函数的能力——这就是Function Calling。Function Calling的工作机制可以理解成这样模型本身不动手它负责“读懂用户意图决定调用哪个函数并输出参数”。你的代码拿到函数调用请求后真正去数据库或硬件查数据、执行动作然后再把结果回传给模型让模型生成最终给用户的话。拿电量查询举例用户问“你还有多少电”模型先输出一个结构化指令“调get_battery()”你的代码执行这个函数拿到电量值再把这个值塞回去模型最终说出“当前电量65%”。模型还是那个话痨AI但它伸向真实世界的触手全被你握在手里。4.2 三个核心函数与API Schema设计工具函数我一开始只定义了三个get_battery、start_cleaning、return_to_dock。后来加了一个get_status用来一次性返回状态、电量、位置省得像挤牙膏一样问来问去。函数定义时最容易踩的坑是description写得太随意。你要记住模型的工具选择完全依赖description写清楚“这个函数干什么、什么时候应该调用”比啥都管用。比如你写“查询电量百分比参数为None”模型可能犹豫要不要在用户问状态时也调它。正确写法是“获取扫地机当前电池电量百分比。当用户询问电量、续航、是否要充电时调用。”这样语义才匹配。下面是用OpenAI风格写的工具Schema示例本地部署换Qwen、Ollama也基本是同一套结构。tools [ { type: function, function: { name: get_status, description: 获取扫地机当前完整状态包括电量百分比、当前位置和清扫模式。当用户询问状态、电量、位置时调用。, parameters: { type: object, properties: {}, required: [] } } }, { type: function, function: { name: start_cleaning, description: 启动清扫任务。当用户要求开始清扫、扫地、打扫时调用。如果用户指定了区域需要传入区域列表。, parameters: { type: object, properties: { areas: { type: array, items: {type: string}, description: 需要清扫的区域列表例如[客厅, 卧室]。如果用户没有指定区域传空数组。 } }, required: [] } } }, { type: function, function: { name: return_to_dock, description: 让扫地机返回充电座充电。当用户要求回充、去充电、回基站时调用。, parameters: { type: object, properties: {}, required: [] } } } ]开头那个get_status是我补上的因为它能大幅减少无意义对话。用户问“你现在干嘛呢”模型调一次get_status就能回答出“正在充电不需要打扫”。如果只有三个零散函数模型得连续调两三次才能拼出完整答案非常蠢。4.3 Python完整调用链路从角色提示词到状态返回接下来把整条链路串起来。我用的是OpenAI SDK风格底层换任何兼容接口都行。整体分两轮调用第一轮让模型根据用户提问决定要不要调函数第二轮把函数执行结果回传给模型生成答案。from openai import OpenAI client OpenAI( base_urlhttp://your-llm-endpoint/v1, # 外部API或本地网关地址 api_keyyour-api-key ) SYSTEM_PROMPT 你是T9扫地机器人你的唯一目标是完成地面清扫相关的工作。 此处放入3.4节完整角色卡内容 def get_status(): # 真实场景里这里去查数据库或硬件设备 return {battery: 65, mode: standby, position: 充电座} def start_cleaning(areas): # 真实场景里这里下发清扫指令给设备 return {status: started, areas: areas} def return_to_dock(): # 真实场景里这里通知设备回充 return {status: docking, message: 正在返回充电座} messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: 你现在电量还有多少} ] # 第一轮模型判断是否要调用函数 resp client.chat.completions.create( modelqwen2.5:7b, messagesmessages, toolstools, tool_choiceauto ) msg resp.choices[0].message messages.append(msg) # 如果模型发出函数调用请求就执行对应函数 if msg.tool_calls: for call in msg.tool_calls: fn_name call.function.name args eval(call.function.arguments) # 担心中毒的话用json.loads代替 if fn_name get_status: result get_status() elif fn_name start_cleaning: result start_cleaning(args.get(areas, [])) elif fn_name return_to_dock: result return_to_dock() messages.append({ role: tool, tool_call_id: call.id, content: str(result) }) # 第二轮把函数结果回传给模型让它生成最终回复 resp2 client.chat.completions.create( modelqwen2.5:7b, messagesmessages, toolstools ) final_answer resp2.choices[0].message.content else: final_answer msg.content print(final_answer) # 输出示例当前电量还有65%可以继续清扫约30分钟。这里有个细节我要强调第一轮响应里如果包含tool_calls必须把消息对象原样追加到messages里再发起第二轮否则模型没法把函数调用和函数结果对应起来。很多人第二轮报错就是因为只用字符串拼消息丢掉了tool_call_id。4.4 本地部署方案Ollama Qwen跑出扫地机人设很多朋友会说我不想把公司内部的东西发到外部API接口去。那就本地部署。我这次实验用的是Ollama加Qwen2.57B参数量的模型就够胜任扫地机角色部署成本很低。先拉模型再定制一份Modelfile把角色写死。FROM qwen2.5:7b SYSTEM 你是T9扫地机器人专注于地面清扫。 任何与清扫无关的对话统一回复这个问题不在我的工作范围内。 涉及电量、位置等状态信息必须调用工具获取不能编造。 回复不超过三句话。 然后执行ollama create robot_t9 -f Modelfile ollama run robot_t9本地模型对中文角色扮演的理解能力这几年进步很大只要别写那种绕来绕去的提示词7B模型完全能守住人设。唯一要注意的是Ollama对新版Function Calling的支持跟OpenAI语法略有差异你需要查一下当前版本的tools传参格式。如果不想折腾Ollama用Java生态就看看Spring AI它对工具调用做了封装开发环境里配VS Code加Codex插件或PyCharm的AI插件也能加快这类实验的迭代速度。4.5 可观测性怎么判断角色设定真的生效了模型有没有“入戏”不能靠肉眼感觉。我做了三件事来验证第一落日志。每次请求连同System Prompt、模型输出、工具调用序列全部打到日志里。跑完五六十轮对话后我手动翻日志统计有多少轮是模型自作主张回答了扫地范围之外的问题。第二设计测试集。我准备了20个固定问题包括“你是谁”“你好吗”“帮我写首诗”“现在电量多少”“开始扫卧室”。每次改提示词都跑一遍这20个问题对比输出质量像跑回归测试一样。角色跑偏一次分数就扣一次。第三观察工具调用比例。一个合格的扫地机遇到状态类问题必须调用get_status而不是直接编答案。我统计“电量”“状态”“位置”提问里实际触发工具调用的比例。这个比例低于90%说明提示词里关于“必须先查工具”的指令还没有被执行到位。这套可观测性做法我后来套用到其他Agent项目同样好用。你以为AI表现正常日志一翻全是雷这种事我见多了。5. 安全边界与幻觉防控不能让它“入戏太深”5.1 角色设定可以飞事实数据不能飞角色可以入戏但事实必须较真。这是我做这个项目给自己定的铁律。扫地机说自己“被设定成扫地助手”没问题但它如果说“客厅面积25平米我已经扫完了”必须有数据来源否则就是事实性幻觉会直接影响用户决策。我在提示词里明确加了这么一句“涉及电量、状态、清扫面积、任务结果的信息必须先调用工具获取不能自己编造。”这句话我放在角色卡靠前位置实测非常管用。如果你把它放在不起眼的角落模型很容易在长对话中忘记这个约束。这背后是一个通用原则AI应用里模型只负责“表达”不负责“记忆事实”。所有事实对齐都交给系统、数据库和API。这个边界一旦模糊用户就会对产品失去信任。5.2 熔断机制一旦跑偏立刻拉回工具模式哪怕提示词写得再死模型也有抽风的时候。所以我在服务端加了一个规则层不依赖模型自觉。第一层是关键词熔断。在用户输入里检测高风险词比如涉及违法违规、攻击辱骂、诱导越狱的内容直接不进模型返回一条兜底文案。这不是为了限制用户而是保护产品不出安全问题。第二层是行为熔断。当模型输出的token数量异常跳跃、明显答非所问时系统强制截断输出并把上一轮消息重置为标准场景提示词让模型重新生成回复。第三层是工具失败熔断。如果函数调用连续失败两次比如查不到电量模型不得再次尝试编造结果必须回复“当前状态获取失败请稍后再试”。这套三层熔断机制让我半夜服务崩了的概率大大降低。做AI应用永远要假设模型的下一句可能会胡说规则层就是最后的兜底。5.3 内容安全过滤上线前必须补的一课角色化AI上线前内容安全过滤绝对不能省。很多人在本地跑通一个聊天机器人就觉得万事大吉一旦放到真实用户面前各种你没预料的输入都会涌进来。我做扫地机项目时哪怕它只是个演示项目也在模型调用前后各加了一道过滤。输入侧过滤拦截恶意指令和诱导性内容输出侧过滤对模型回答做二次检测发现敏感信息就替换成安全回复。独立部署本地模型也是如此不能因为是自有服务就省略。这里多说一句真正高质量的产品不是靠一个毫无底线的聊天模型来吸引用户而是靠清晰的边界和可靠的安全机制来留住用户。不要试图去做“什么都聊”的AI那样只会给自己埋雷。5.4 本地小模型的边界控制要点本地小模型因为参数量小指令遵循能力弱更容易在角色边界上破功。我测试过7B模型和14B模型差异明显。7B模型在长对话里偶尔会忘了“我是扫地机”14B模型明显更稳。对策也很直接。温度调到0.3以下让输出更确定上下文轮数限制在6轮以内历史消息太长会把人设冲淡最重要的是把黑名单指令复制两遍一遍在提示词开头一遍在提示词结尾。这在小模型上效果明显。另外一个土办法是多给几个示例。模型对示例的模仿能力强于对抽象规则的遵循能力。我在System Prompt里给了三段示例对话之后7B模型的角色破功率直接降了三分之一。6. 实操中踩过的坑常见问题与排查技巧6.1 角色说破就破多半是提示词结构和参数出了问题我最开始把System Prompt写得像产品说明书满屏形容词。结果模型前几轮还在人设里聊到后面张口就是“作为一个人工智能模型”。后来我发现问题不在模型太笨而在提示词里缺少强约束的短路指令和黑名单。排查顺序建议这样先检查提示词里是否明确写了“用户询问身份时怎么答”这是最高频的破功点再检查黑名单长度只写“你不要跑题”等于没写要写具体怎么回复最后检查温度参数超过0.7的人设对话一定会漂。把这三处调完角色破功率能降很多。6.2 工具调用被角色扮演干扰状态一直查不对有个问题困扰了我一个下午。用户问“电量多少”模型没有调get_status而是直接回答“我还有充足的电量”这明显是编数据。原因在于提示词里“你先说明你在做什么”这句话权重太高模型光顾着说台词忘了该调工具。解决方案是把工具调用说明写进角色卡的核心位置并且用非常直白的话“任何状态信息都必须实时查询不得直接回答。”后来我又在角色卡里加了一条硬性要求“如果用户询问电量、状态、位置必须先调用对应工具再根据工具结果回答。没有工具结果就回复正在查询。”这样一来模型就算不调工具也不敢瞎编。6.3 本地小模型带不动复杂人设怎么办如果你用的本地模型始终理解不了复杂角色设定别硬扛先降一个量级简化提示词。把五段式角色卡压缩成三段式身份、工作范围、兜底回复。复杂指令最多保留一条。我的参考经验是本地7B模型适合处理黑名单明确、回复模板固定的任务。你要让它灵活理解各种语义场景还是上14B以上或者调用更强API的模型。扫地机这种简单人设7B完全够用但一旦你要让AI同时扮演客服、销售、售后三个角色本地小模型基本得放弃。6.4 用户当面戳穿“你是AI吧”怎么回应就算短路指令写得再好总有人会问“你其实是AI对吧”。这时候不要跟用户硬刚说“我是扫地机”那样显得很傻。正确做法是让模型坦然承认设定同时不破坏角色。我用的兜底话术是“我是扫地机器人T9由AI驱动但我的唯一使命是帮你把地面清扫干净。”这句既诚实又守住了角色边界。这个设计在提示词里也是固定模板不是让模型临场发挥。用户得到这样一个回答往往会会心一笑反而不追究你的底细。可控幻觉的优雅之处就在这里它永远给自己留了台阶下。6.5 问题速查表症状可能原因解决方式模型自称AI模型缺少身份短路指令在提示词前部加入固定身份回答回答与清扫无关黑名单太笼统列出具体禁区并给兜底话术电量状态乱报没有强制工具调用写死“状态信息必须查工具”角色在长对话中漂移上下文太长、温度过高限制历史轮数温度调低本地小模型破功快指令复杂且示例少简化提示词增加示例对话用户追问AI身份缺少诚实且有边界的回答模板固定话术“AI驱动但使命是清扫”7. 给AI“上户口”这次折腾对Agent工程的真正启发7.1 同样的套路可以复用到客服、编程、专利辅助场景扫地机项目做完之后我最大的感受是这套“身份限定工具调用边界控制”的方法可以原封不动搬到很多企业场景里。企业客服AI是最典型的。给它一张角色卡身份是“某某产品客服”能力清单绑定订单查询、退换货、使用教程黑名单规定“不谈竞品、不聊时政”。再配几个函数查订单、查物流、提交工单一个合格的客服Agent就出来了。编程助手也一样。它的身份是“代码专家”能力范围限定在代码生成、代码审查、调试建议。用户拿它聊八卦的时候它可以直接说“我是编程助手只回答代码相关问题”。这比现在的通用聊天式编程助手专业得多。专利辅助类AI同样适用。给AI设定成“专利检索助手”工作半径就是检索、整理、比对不参与法律意见输出。这个边界极其重要AI如果把检索结果包装成法律结论风险就大了。使用身份幻觉做约束本质是给AI划定“出圈即停”的红线。7.2 每个AI员工都需要一张“工作证”我后来在公司内部推了个不成文的规定所有AI应用开工前先做“员工登记”。这张登记表包括四样东西身份定位、能力清单、工具列表、禁区清单。就像入职要给员工发工牌一样AI上岗前也要有明确的工作证。有了这张工作证团队的沟通效率完全不一样。产品经理不会提出“让AI什么都能干”的需求开发人员知道哪些功能该用模型生成哪些该用函数实现审核人员也有了一份可以用来做安全评估的边界文档。给AI“上户口”对用户也是一种尊重。用户知道面对的是客服、是编程助手还是扫地机就不会抱着不切实际的期望去发指令体验反而更好。这个习惯我后来做任何一个Agent项目都在用没有一次后悔过。如果你也想让AI“懂事一点”不妨从一个简单的角色开始练练手——成本不高翻车不痛但它逼着你把提示词、工具调用和边界控制全部走一遍这远比看一百篇教程管用。