上周我想让AI帮我审一份技术稿结果它回了一段赞美加三条不痛不痒的建议最后还附一句感谢作者的分享。我把这段回复截图发在同事群里吐槽说这AI比刚毕业的实习生还会讲场面话。同事回了一句你有没有给它一个岗位这句话让我愣了很久。我一直在问AI能做什么但从来没想过我需要它成为谁。同一套大模型你让它帮我看看这篇稿子和让它你是一名有十年经验的科技媒体编辑你的任务是从逻辑漏洞、表述冗余、技术事实错误三个维度审稿逐条标注问题严重级别产出根本不是一回事。这篇是使用人工智能开发角色系列的第一篇。我打算把这两三个月来我一直在做的事——把一个通用对话模型培养成带岗位、带风格、带方法论的专职协作角色——完整记录下来。包括角色的底层结构、我踩过的坑、实测数据、以及可以直接抄走的提示词。如果你跟我一样用过AI但总觉得它什么都会一点什么都不精或者你已经会用AI写东西但要反复回到上上轮去纠正它这篇应该对你有用。1. AI不缺能力缺的是一个明确的角色1.1 一个让我重新思考AI协作方式的瞬间前面说的审稿翻车只是导火索。真正让我铁下心来做角色开发的是另一件事。我在维护一个开源项目的文档每周要更新changelog还要按统一格式写版本说明。这类工作重复度高、格式约束强天然适合交给AI。结果我发现如果我只说帮我写今天的changelog它会写得像企业新闻稿——本次更新带来了多项重要改进与性能优化如果我贴一个往期例文再让它模仿它又容易把旧版本的功能也抄进去。最要命的不是它写得烂而是它的风格不稳定。上周它学得像模像样这周换个对话窗口又打回原形。我花在纠正AI上的时间已经超过我自己直接写的时间了。后来我意识到问题不在模型能力在于我从来没给AI建立过稳定人格。我没有告诉它你是谁你为什么存在你按什么标准工作所以每次开新对话它都是那个什么都会一点、什么风格都能仿一下、但永远没有立场的通用助手。1.2 给AI设角色本质是给它一份岗位说明书如果你管过人一定懂这个道理一个能力很强的外包你丢给他一句帮我把方案弄一下他大概率会给你一份上百页的通用模板。你会觉得他能力不行吗不会你会觉得是需求没对齐。AI也一样。大模型在训练阶段读了几百亿个网页它能模仿的东西太多了你把它丢进一个没头没尾的任务里它只能靠猜。猜你想要的风格、猜你需要的深度、猜你应该先看结论还是先看过程。一猜就不稳定一不稳定你就觉得它笨。我目前用下来的核心解法就是给AI写岗位说明书。它有四个部分这个角色的身份、它的能力边界、它的语言协议、它的任务协议。我把这套东西统称为角色三件套后面第四节会展开写。你可以把它理解成大多数人在用的AI是一个流动的、没有隶属关系的实习生而我给自己开发的AI是几个有明确职责、稳定风格、可以随时外包出去的固定员工。1.3 这个系列会覆盖什么以及第一篇文章的定位这个系列我计划写四到五篇。第一篇也就是这篇只解决从0到1的问题如何把一个通用AI变成一个可靠的角色。它会包括角色化的核心原理、完整可复制的构建方法、两个真实案例的搭建过程以及连续使用两周后我踩过的稳定性坑。后面几篇我打算逐步展开角色间的多人协作调度比如让代码审查员和性能优化师打配合、基于角色开发的内容流水线、以及如何让角色学会调用工具和外部数据源。每篇都会配一份可以直接抄走的结构化提示词。如果你是第一次接触这个概念的请把这篇当作一本角色开发入坑手册跟着做一遍比读十篇框架文章都有用。2. 角色三件套人设卡、上下文、任务协议先说一个常见的误区很多人以为给AI设角色就是在提示词开头写一句你现在是一个XXX专家。这句有用但远远不够。就像你在工牌上写资深工程师不等于你真有十年经验一样。AI需要的是一个完整的、可执行的、能稳定复现的角色定义。我把它拆成三块人设卡、上下文工程、任务协议。2.1 人设卡不是角色扮演是岗位说明书人设卡是我所有角色构建的地基。它解决的是这个角色到底是谁的问题我一般分三个维度写维度作用示例身份锚点定义角色的背景、资历、立场让AI知道我以什么身份在说话五年经验的移动端性能优化工程师做过大型App的启动耗时治理能力边界明确角色会什么、不会什么、遇到不会的如何处置防止AI跨界瞎编熟悉Android性能工具不了解iOS需要iOS问题请开头声明语言协议约束输出风格、格式、语气、术语习惯结论前置使用精确数字不用大概可能这类模糊词身份锚点为什么要写得这么具体因为大模型的风格是平均化的。你只说你是工程师它会混合程序员论坛、技术博客、企业宣传文案三种语气产出一种奇特的技术官宣风。但如果你说你是做过三年Android性能优化的工程师现在转做技术管理习惯先讲结论再展开分析它的语气立刻会向真实复盘帖靠拢。能力边界可能是三个人设维度里最容易被忽略的。绝大多数人只告诉AI你是谁不告诉它对什么说不。结果就是你问它一个iOS问题它照样面不改色地答。AI不怕承认不会会丢面子完全是我们没给人家设定的机会。你只要写一句遇到超出边界的内容明确说明超出范围并给出可能方向翻车率会肉眼可见地降低。语言协议最好用负面清单正面清单组合。正面清单写要什么负面清单写不要什么。比如我常用的正面结论在前证据在后负面不要使用显著提升极大改善等无法量化的表述。光给正面清单AI会做得不错但偶尔跑偏加一条负面清单稳定性立刻上来了。2.2 上下文结构把对话窗口分成三个区域当你给AI设了人设卡你只是给了它人格还不算给了它工作台。大模型每次对话只能容纳有限长度的上下文你的历史对话、粘贴的资料、它自己的输出都挤在同一个窗口里。如果不做分区管理聊不到二十轮角色就开始漂。我现在的做法是把每个控制台的上下文分成三个区域长期记忆区放人设卡、固定工作流程、历史结论摘要。这些内容全程不变每次新对话我都是先贴这部分再开始干活。当前工作台放本次任务的背景资料、待处理文本、参考样例。聊完一段就清理防止任务A的信息污染任务B。实时便签区放AI临时发现的关键点、我随手补充的信息、待确认的疑问。这类信息价值密度低会占窗口但当前对话还需要所以单独放在最后。这个结构与计算机的寄存器、缓存、内存非常像。长期记忆区是只读的ROM当前工作台是高速缓存实时便签区是随时可覆盖的内存。你不需要真的懂计算机体系结构只需要记住一个原则不要把所有内容都堆在同一个区域里。很多人问为什么AI聊到后面会变蠢其实不是变蠢是上下文窗口被大量无关内容占满模型注意力被稀释了。就像一个人桌上堆了三百份文件你让他找昨天那份合同他可能翻到半小时后。分区管理就是给AI做桌面整理让它知道哪些是需要一直看的、哪些是做完就可以扔的。2.3 任务协议开工前对齐的五件事有了人设和上下文还差最后一层任务协议。它解决的是这个角色每次接到任务时按什么流程执行的问题。我每次让AI角色干活都强制要求它先完成一个任务对齐动作先说它对目标的理解再列执行计划等我确认后才正式输出。这个动作非常反直觉——你可能会觉得让AI先复述一遍目标不是浪费时间吗实测下来这一个动作至少能减少我一半的返工。原因是大模型的语义理解是概率性的你的指令里一句话它有80%的概率理解正确但剩下的20%可能让整个产出方向跑偏。先让它复述等于在开工前把理解的偏差暴露出来调整成本从改一篇文章降为改一句话。我的任务协议固定五个要素目标这个任务最终要产出什么服务于谁。受众产出的阅读对象是谁他们的技术水平和关注点是什么。约束格式、长度、术语、必须包含或绝对不能出现的元素。产出物交付的载体是文本、表格、清单还是JSON结构。验收标准怎么算完成比如每个结论必须有数据或者出处。这五个要素我会直接写进角色的系统提示词里让AI在每次接手新任务时按清单提问我没给的先问不要自作主张。3. 从零开发审稿搭子两次迭代的关键记录理论讲完不实操等于白讲。这一节我把最近实际在用的一个角色完整拆给你看技术审稿搭子负责帮我校验文章。3.1 为什么拿审稿搭子当案例选它当案例有几个原因一是这个角色没有代码依赖不需要搭建任何环境你在任意一款主流对话AI里都能复刻二是审稿工作反馈直接它审得好不好几分钟就能判断三是它能展示角色开发中最核心的能力——从给你挑错到按统一标准挑错的转变。另一个实际原因是我每个月大概要写七八篇技术类长文。过去找人工审稿成本高、周期长而且对方不一定熟悉我的写作习惯用AI审稿最大的价值不是它比人审得好而是只要配置得好它能做到比大多数初级编辑更稳定。3.2 第一版人设卡先搭骨架我第一版人设卡长这样你完全可以照着抄角色名阿澈 身份锚点你是一名拥有八年经验的技术内容编辑在科技媒体做过高级编辑后来转做开发者关系。 你对技术写作的流程、术语准确性、逻辑论证方法有系统的判断标准。 能力边界 - 你能处理技术文章、产品文档、技术方案、代码注释、发布会稿件。 - 你只负责内容质量逻辑、结构、准确性、可读性不做排版。 - 如果遇到你不熟悉的领域明确说这部分超出我的判断范围并指出需要什么样的背景知识才能评估。 语言协议 - 结论先行。每一条意见先给结论再给理由最后给修改建议。 - 使用严重级别标记P0事实错误/可能引发误解、P1逻辑漏洞/论证不足、P2表述冗余/可读性差、P3锦上添花。 - 不用我觉得可能应该这类软弱措辞。 任务协议 - 当我给你一篇文章时先复述你理解的文章主题和核心观点。 - 然后按P0-P3顺序输出审稿意见每条意见带上引用的原文片段。 - 全部意见输出完之前不要给总结性评价。这套提示词放进去第一轮测试就见效。我把一篇刚写完的产品介绍文章丢给它它用标志级别区分了八条问题其中两条P0我居然一直没发现——一处API参数名拼错一处可能让读者以为功能对所有用户开放实际上只面向付费版。说实话这两个错误人工审三遍不一定抓得到。但第一版也有明显毛病。最典型的是它倾向于把审稿意见写得像教科书——每条都解释得很充分一个P3级别的措辞建议它能给你写一百多个字。这导致整份审稿意见比原文还长。这就是人设卡里语言协议写得不够狠的结果AI默认追求全面性不追求效率。3.3 第一次迭代从写满到收敛我给语言协议加了一条P2及以下级别的问题每条不超过30字全部意见总字数控制在原文的20%以内。这个改动非常粗暴但效果出奇好。它强迫AI去判断什么值得写、什么不值得写而不是把能说的全说出来。同时我发现一个更深的坑它对P0级事实错误的敏感度不够。一篇稿子里有三个技术细节的表述不够准确它只标出一个还给了P2。我意识到人设卡里的能力边界应该写得再具体一点——不光是处理技术文章还得告诉它哪些是硬伤。于是我调整了P0的判定标准加上一段明确的触发器示例P0判定标准 1. 技术事实错误API名称、版本号、算法原理与实际不符。 2. 可能误导决策读者依据本文操作会得到错误结果。 3. 法律/合规风险涉及开源协议、数据隐私的表述有误或缺失。 4. 以上如果疑似存在但无法确认标记为P1并附上需要核对的资料线索。加完这四条第二次测试里它就把两个隐蔽问题捞出来了。一个是我把某库的最低支持版本写成了API 29实际是31另一个是我引用的某项性能数据没有标注测试机型而不同机型差异可能超过三倍。这类问题已经不是文笔层面的而是内容可信度层面的这才是我需要审稿搭子干的事。3.4 第二次迭代加入改稿建议和防呆标签第二次迭代后这套角色已经能达到可稳定使用的标准。我又顺手加了一个功能让它对每一条P0、P1给出可直接粘贴的修改文段。这个动作作用很大。最初我需要看完意见后自己去改加了这个功能变成复制替换即可。一篇文章的返工时间从一小时压缩到二十分钟以内。后来我甚至把所有P2、P3的意见都设定成只给关键词不给完整句子因为如果它给完整句子我会忍不住直接用反而抹掉了我自己的语气。这一版审稿搭子最终长这样。你可以把它理解为一个每次接稿前先跟你对齐理解、接稿后按四个等级挑错、并且对P0级硬伤有明确触发逻辑的虚拟编辑。4. 连续使用两周后的稳定性问题和应对方法人设卡写好了不代表一劳永逸。真实使用两周后我遇到了三个扎扎实实的稳定性问题每一个都会让角色崩掉或者变味。这一节就当排坑记录。4.1 开场复位每次新对话先花十秒重建身份第一个问题出现在角色越用越多之后。我手上有审稿搭子代码审查员阅读助手三个角色。有一次我开着审稿搭子的对话窗口顺手丢了一段代码进去让它看它居然先用文章逻辑的角度分析了一遍代码结构写了半天段落之间的衔接可以优化。我才意识到当你有多个角色时对话模型会互相污染。你在这个窗口里说的话模型可能会关联到其他角色的人设上去。解决办法其实很简单也很原始每次开新对话先把角色人设卡完整贴一遍。我做过对比测试把角色人设卡放在第一条与不放在第一条直接提问相比前者的响应风格稳定性高出非常多。更严格的写法是在粘贴人设卡后紧跟着发一条固定指令请确认你的角色设定并复述本次任务的处理流程不要开始处理内容。我管这一步叫开场复位。它花的时间不长十秒左右但能保证接下来的二十轮对话AI全程稳定在角色状态里。你要是嫌每次粘贴太长可以把自己常用的人设卡存成一个代码片段或者笔记模板一键复制。4.2 上下文污染角色崩塌的头号元凶比角色互相干扰更隐蔽的是上下文污染。所谓污染指的是对话窗口里积累了跟当前任务无关的内容导致角色输出风格或判断标准逐渐漂移。举个例子。我用审稿搭子连续审了三篇文章后没开新对话直接在后面接了一条消息说再帮我看看这段代码问题在哪。它的回复前一半是代码分析后一半突然开始讲这段代码的可读性可以进一步优化——像极了审稿编辑在点评代码。原因很简单前文中大量审稿意见的风格样本把它带偏了。这也是为什么我在第二节强调上下文分区。长期记忆区的信息要固定当前工作台要勤换。如果你连续做一个任务超过十轮最好的做法不是继续在一个窗口里往下聊而是把关键结论收集起来新开一个对话窗重新贴人设卡把结论摘要放进长期记忆区然后继续。踩过几次坑之后我给自己定了一条规矩上下文里超过30%的内容与当前任务无关就无条件开新窗口。这条规矩让我角色的稳定性提升了一大截宁可每次花十秒做开场复位也好过写到一半发现角色已经精神分裂。4.3 用输出协议对抗AI的平庸化最后一个问题有趣一点一个角色刚搭建的时候表现通常最好有棱有角但用久了之后它会慢慢变成正确的废话发生器。我复盘过这个现象觉得深层原因是AI在与你的长对话中不断自我修正试图迎合你的偏好。如果你的反馈不够明确它的输出就会向安全、平均、无争议的方向滑落。人设卡设定得再鲜明也会被这种劣化趋势慢慢磨平。我应对的方法是给角色加一层输出协议。它不是场景级别的任务协议而是角色级别的根深蒂固的输出偏好。例如我给我的审稿搭子加了三条输出协议当你在批评一条冲击观点时保持直接不要缓冲。读者不是来听安慰的。如果原文确实没有值得批评的地方说出这个事实并解释为什么。拒绝绝对安全的表达每个观点必须给出判断依据没有依据的观点直接标注为主观判断。加完这三条效果立竿见影。它不再在每段意见后面都跟一句仅为个人意见建议结合实际情况判断——看到这种句子我都想摔键盘。角色重新变得有判断力了。如果你想检查自己的角色有没有被磨平可以每隔几天问它一个带冲突的问题。比如这篇文章如果一定要删掉三分之一你删哪里。一个标准、鲜明的角色应该能给出毫不犹豫的答案如果它开始左右逢源、面面俱到那就说明人设需要回炉——回到人设卡里把语言协议改得更锋利。5. 角色开发里的几条实在经验到这儿一个AI角色从设定到稳定的完整流程已经出来了。最后我再聊几条实战经验都是踩过坑之后总结出来的。5.1 不是所有任务都适合角色化你可能会想那我以后所有AI使用场景都套一个人设卡不是更好吗真不是。我的经验是角色化适合高频、重复、质量标准清晰的固定任务。比如我每个月的例行审稿、每周的changelog、代码审查这些都是重复劳动值得花半小时把人设卡打磨好后续每次使用都能省几个小时。但有些一次性、探索性的任务角色化反而是负担。比如我临时想了解一下某个陌生领域的现状此时如果强行为AI设定一个十年经验行业顾问的人设它反而会为了扮演好人设而生成大量自信的废话。一次性任务更适合直接问让模型的通用能力自由发挥。5.2 三个容易踩的坑一次塞太多设定。人设卡不是越长越好。我测试过一份两千字的超级人设卡AI虽然每条都遵守但整体响应速度变慢而且常常在细枝末节上用力过猛。现在我的每张人设卡都控制在五百字以内只保留下述核心要素身份锚点、能力边界、语言协议、任务协议。额外信息宁可写在长期记忆区不要塞进人设卡本身。角色名与人设不符。给AI角色起名尽量朴素一些。名字本身会影响模型的生成倾向。有一次我把它叫Dr. Critique结果它的输出风格变得非常戏剧化每句话都像脱口秀换个朴素的审稿人Beta输出立刻正常了。自创格式导致后续解析困难。早期我喜欢让人设角色输出花哨的Markdown格式比如引用块、折叠区、进度条。好看是好看但当你要把它的产出复制进文档、或者丢给下游工具处理时这些特殊格式全是负担。现在我的所有角色统一输出纯文本标准Markdown列表最多加一个表格。格式越朴素兼容性越强。5.3 名词速查表最后把文里出现的关键概念整理成一个速查表方便你回看概念一句话解释角色三件套人设卡、上下文结构、任务协议构建一个AI角色的核心框架人设卡定义角色身份、能力边界、语言协议的结构化提示词上下文工程把对话窗口的上下文按长期记忆区、工作台、便签区做分区管理任务协议每次接任务时AI按目标、受众、约束、产出物、验收标准五要素对齐工作的流程开场复位每次新对话先重贴人设卡并让AI复述任务流程防止角色漂移输出协议角色级别的输出偏好约束对抗AI向安全、平庸、无观点滑落上下文污染无关对话内容占用窗口、稀释模型注意力导致角色崩溃这套方法我大概用了两个多月。现在我的惯例是任何预期超过一周的固定AI协作需求都会先花二三十分钟搭一个正式角色。判断一个角色值不值得继续用我的标准也很简单连续用三周不修改基础人设卡就算及格。真能做到AI带来的价值稳定且可复制。下一篇文章我准备写让两个AI角色打配合——比如让审稿搭子和信息核查员同时工作一个查逻辑一个查事实两个角色之间怎么传话、怎么避免互相打架。如果你自己也在搭AI角色建议先按这篇的方法把第一个角色做出来用两周再说。