没有角色设定的技能，就像没有指挥官的命令。你可以给定义文件塞满约束、输出格式和风格规则，但如果你从不告诉 AI 它应该扮演谁，你就是在要求一个有才华但没方向的员工去猜测自己的职位。结果显而易见：输出内容平庸且语调飘忽，专业水平在每次运行间剧烈波动，调试过程就像在追逐烟雾一样难以捉摸。

这很重要，因为现代 AI 编程工作流不再是单次提示（single-shot prompts）。它们是由许多小的技能链式组合而成的模块化系统。当每个技能都缺乏清晰的身份时，整个流水线都会受到影响。

为什么缺失角色设定会破坏你的工作流

当你省略角色声明时，你是在迫使模型即兴发挥其权威性。这一分钟它写出的代码像是一个小心翼翼、生怕搞砸构建的实习生；下一分钟，它又像是一个见多识广的首席工程师一样去设计分布式系统。这种不一致性不仅令人恼火，还会让你的工作流变得不可靠。

问题会迅速堆积。AI 会随机选择一种口吻，导致你的代码库听起来像是出自一个从未开过会的委员会之手。每次运行技能时输出都会变化，这意味着你无法信任自动化测试或 diff 审查。审计变得不可能，因为你不知道是什么视角产生了结果。这是由关注安全的工程师生成的，还是由产品通用型人员生成的？如果答案是“看模型当时的心情”，那你根本无法验证逻辑。

技能链式调用会让情况变得更糟。想象一下，一个技能负责生成 API 合约，另一个技能负责编写实现。如果第一个技能表现得像一个执行严格验证的严谨资深架构师，而第二个技能表现得像一个跳过错误处理的初级开发人员，那么你的集成就会崩溃。只有当每一个环节都清楚自己的身份时，链条才能稳固。否则，问责制就会消失。当出现问题时，你无法指出是哪个环节出了错，因为根本没有定义环节的视角。

如何修复

解决方案简单但很明确。在你的技能文件中，将角色声明作为第一条指令添加。不要把它埋在格式规则或输出模式（schemas）下面。要以身份引领。

使用清晰的结构：“你是一名在 [领域] 具有专业知识的 [角色]。” 随后用一两句话描述该角色在任务背景下的具体职责。例如：“你是一名在分布式系统领域具有专业知识的资深后端工程师。你的工作是审查拉取请求（pull requests）中的并发风险和数据一致性问题。你会质疑关于状态管理的假设，并拒绝批准缺乏适当错误处理的代码。”

这样就足够了。最多三句话。过长的传记只会增加噪音。模型不需要童年背景故事或兴趣爱好列表。它需要一个能够塑造其判断力的专业锚点。

坚持使用真实的职业角色。Staff 软件工程师或技术文档撰写者能为模型提供一个可识别的职责框架。要求它表现得像夏洛克·福尔摩斯或中世纪巫师可能看起来很有创意，但这会引入与你的代码审查流水线毫无关系的、不可预测的关联。真实的职业角色带有真实的约束。

做对之后会发生什么变化

一旦每个技能都承载了自己的角色设定，你的整个流水线就会趋于稳定。

可预测性是第一个回报。AI 不再需要猜测自己的资历。资深角色会提出更尖锐的问题。它会针对模糊的需求进行反驳，标记缺失的边缘情况，并要求提供默认或初级角色可能会忽略的上下文。当你定义了角色，你就定义了标准。

审查速度变快了。当团队成员阅读带有清晰角色标签的输出时，他们能理解每条建议背后的视角。他们知道该将某条反馈视为硬性的架构要求，还是仅仅作为一种软性的风格偏好。上下文变得显式化，而非隐含。

技能链式调用终于能按预期工作了。每一个