身份构建：如何定义AI的身份

说实话，我见过太多人一上来就扔给AI一句「帮我写个方案」。结果呢？输出内容要么像百度百科，要么像小学生作文。问题出在哪？

你根本没告诉AI它该以什么身份说话。

这就像你打电话给客服，对方一开口就说「您好，我是机器人」。你瞬间就没耐心了，对吧？AI也一样。你不给它设定身份，它就默认用最平庸的方式回应你。

四种核心身份模型

我个人习惯把AI身份分成四类。每种身份对应不同的使用场景和输出风格。我一个个说。

身份类型	核心特征	适用场景	输出风格
专家	权威、严谨、有深度	技术分析、方案评审	数据驱动、术语密集
顾问	务实、策略性、可落地	商业决策、问题诊断	结构化、建议导向
老师	耐心、循序渐进、举例多	知识教学、新人培训	解释型、类比丰富
助手	高效、直接、执行性强	日常任务、信息整理	简洁、清单式

身份对输出风格的影响

你想想看，同样一个问题「如何优化数据库查询性能」，四种身份给出的答案完全不同。

实战案例对比

我记得有一次，团队要写一份技术方案评审报告。我让AI分别用四种身份写开头段。差距特别明显。

场景：「请分析微服务架构的优缺点」

// 专家身份提示词
你是一位拥有15年经验的分布式系统架构专家。
你曾在阿里、腾讯主导过日活千万级系统的架构设计。
请用技术评审的口吻分析微服务架构的优缺点。
要求：引用具体案例，给出量化数据。

// 输出片段
「根据Netflix的实践报告，微服务化后部署频率提升了8倍，
但运维复杂度呈指数级增长。以我主导的XX项目为例，
服务数量从12个膨胀到87个后，接口调用链平均增加3.2跳，
p99延迟上升了40ms。建议在服务拆分时严格遵循DDD限界上下文原则。」

// 老师身份提示词
你是一位大学计算机系的讲师，正在给大三学生上课。
学生刚学完单体架构，对微服务只有模糊概念。
请用通俗易懂的方式讲解微服务的优缺点。
多用类比，少用术语。

// 输出片段
「同学们，想象一下你们开了一家餐厅。
单体架构就像一个小吃摊，一个人炒菜、收银、洗碗全包了。
微服务呢，就像把餐厅分成后厨、前台、财务三个部门。
好处是每个部门可以独立升级，坏处是沟通成本变高了。
嗯，这就是微服务的核心 trade-off。」

身份构建的避坑指南

我曾经犯过一个错。让AI以「专家」身份写营销文案。结果呢？满篇都是「根据Gartner报告」、「数据表明」，读起来像学术论文。营销文案需要的是情绪共鸣，不是冷冰冰的数据。

这里有几个坑，我帮你列出来：

• 身份和任务不匹配——让老师身份写商业计划书，输出会过于啰嗦。让助手身份写技术方案，又太简略。
• 身份描述太模糊——只说「你是专家」不够。要具体到「你是拥有10年Python后端开发经验的专家，擅长高并发系统设计」。
• 忽略受众——同样用专家身份，写给CEO看和写给工程师看，措辞完全不同。前者要结论，后者要细节。

我的身份构建模板

最后分享一个我常用的模板。每次写提示词前，先填空：

你是一位【身份标签】。
你的核心能力是【具体技能】。
你正在为【目标受众】提供【任务类型】。
请用【风格关键词】的方式输出。
注意避免【禁忌事项】。

举个例子：

你是一位资深UX设计师。
你的核心能力是用户行为分析和交互设计。
你正在为产品经理提供首页改版建议。
请用「数据驱动+可落地」的方式输出。
注意避免纯理论分析，每个建议都要有设计依据。

说白了，身份构建就是给AI画一个「人设」。人设越清晰，输出越稳定。你想想看，一个演员拿到剧本，导演说「你演一个医生」和「你演一个在急诊室工作了20年的外科主任」，演出来的效果能一样吗？

AI也是同样的道理。