在 WorkBuddy 平台上成功定制 AI 角色，是系统启用后的首要任务。我反复调试了近两周，经历了多次方案推翻重来，实际遇到的挑战远超最终呈现的经验。现在，我将完整复盘这一过程，旨在为其他用户提供关于专业 AI 角色定制的实用参考与避坑指南。

起因：通用对话模式导致 AI 逻辑混乱

医院信息科的工作具有一个显著特点：一个人需肩负多个岗位的职责，且各岗位的专业跨度极大。

上午可能还在排查 HIS 系统报错，下午就需要撰写等保合规整改方案，晚上又得处理医保对账表。这些任务之间缺乏自然过渡——你往往需要从解决数据库死锁的场景，直接切换到理解 DRG 付费政策的场景，中间几乎没有缓冲时间。

最初使用 WorkBuddy 时，我采用的是通用的“万能对话”模式：在同一聊天窗口，上一秒让 AI 写 SQL 查询数据，下一秒让它写新闻稿，再下一秒又要求它分析防火墙策略。结果呢？AI 自身的逻辑变得混乱。它会用撰写新闻稿的语气来生成等保整改方案，或用分析数据的思维方式去排查网络故障。

当痛点积累到极致时，我决定为 AI 分配不同的角色，确保每个角色只专注于一项核心任务。

第一版：七个角色，构想虽好但问题不少

最初的设计思路非常直接——基于岗位进行映射。信息科有哪些岗位，AI 就建立相应的角色：

• 信息科主任：负责规划、预算、项目申报
• 系统管理员：负责 HIS/EMR 配置、故障排查
• 数据与统计员：负责 SQL 查询、报表、数据上报
• 网络安全运维：负责防火墙、等保、安全事件
• 医保科主任：负责 DRG 控费、飞检应对
• 医保审核员：负责编码校验、三大目录
• 医保结算员：负责对账、退费、结算

后来还加入了“宣传科干事”和“个人助手”，高峰期同时存在 9 个角色。

9 个角色意味着什么？需要维护 9 套 SKILL.md 文件、记忆 9 套触发词、更新 9 套参考资料目录。一个人管理的信息科，为 AI 设计的角色数量甚至超过了医院实际科室。这就像同时给电脑安装 9 个杀毒软件——每个都想发挥作用，结果反而互相冲突。

**第一个关键难题：边界模糊，角色任务重叠。**

以一个真实场景为例：等保测评整改，“信息科主任”负责管理层面（制度、人员），“网络安全运维”负责技术层面（设备策略、安全加固）。但在实际工作中，一条等保不符合项往往同时涉及管理和技术，例如“未建立安全事件报告制度”——这属于管理问题还是技术问题？AI 同样感到困惑，两个角色各自给出方案，内容无法对齐，甚至相互矛盾。

**第二个关键难题：角色之间缺乏协同机制。**

当医保飞检来临时，“医保科主任”要求准备自查自纠报告，但数据从何处获取？需要找“数据与统计员”提取。提取后发现异常编码，又得找“医保审核员”校验。校验发现是 HIS 系统配置问题，还需联系“系统管理员”排查。四个角色之间的信息流转，完全依赖手动切换和传达。**AI 无法自动向另一个角色请求数据。**

第二版：从“岗位映射”转向“能力整合”

经过反思，我进行了第一次重大重构。核心逻辑发生了变化：不再按岗位划分，而是基于“决策 vs 执行”的维度进行合并。

**信息决策** = 信息科主任 + 数据与统计员。逻辑在于：决策依靠数据支撑，报表为决策服务——“先明确方向，再提供数据”。

**信息运维** = 系统管理员 + 网络安全运维。逻辑在于：软硬件不分家，系统与网络统一管理——“无论故障源自系统还是网络，都可由此角色处理”。

医保方面也进行了类似整合：医保决策（管控费 + 审编码）、医保结算（纯财务流程，独立保留）。

**第三个关键难题：合并非简单拼凑。**

最初以为合并只需将两个 SKILL.md 文件的内容叠加。结果发现，两个角色对同一问题的立场可能存在冲突。

以“数据脱敏”为例：信息科主任视角认为脱敏是管理要求，制度必须健全；数据与统计员视角则认为脱敏会影响数据可用性，过度脱敏将无法进行有效分析。合并后，必须在 SKILL.md 文件中明确声明优先级：**安全优先，可用性其次**。否则 AI 会在两个立场之间摇摆不定。

**第四个关键难题：A 面 / B 面的分工必须严格定义。**

合并后的每个角色具有两个“面”（A 面决策 / B 面执行），如果不在文档中明确指定哪些任务归属哪一面，AI 就会出现角色混乱。例如“信息决策”角色：

• A 面（决策）：信息化规划、等保合规管理、供应商评估
• B 面（数据）：SQL 查询、统计报表、ICD 编码校验

但存在一个灰色地带：数据分析。进行规划需要数据分析，而数据分析又依赖规划定义的口径。我在 SKILL.md 文件中增加了一段关键描述：“你应运用数据驱动的管理者思维来调用 AI”——这明确了 B 面作为 A 面的支撑工具，而非并列关系。

SKILL.md 的编写：每个文件都经过反复迭代

每个角色的 SKILL.md 文件，前后都进行了不下 20 次的修改。这些修改并非简单的文字润色，而是每次实际使用中都会发现遗漏或错误。

**角色定位不能写成抽象愿景。** 第一版信息科主任的定位是“以信息化建设推动医院高质量发展”。听起来很有高度，但 AI 完全不清楚自己的具体职责。后来改为：“你是医院信息科的信息决策者——左手负责决策，右手负责数据。规划需要数据支撑，报表为决策服务。你的风格是沉稳决断、以数据说话、对合规零妥协。”**区别在于：前者是愿景，后者是行为准则。** AI 不需要愿景，它需要知道遇到具体事务时该如何反应。

**触发条件不能过于模糊。** 早期触发条件写的是“当需要进行信息化规划时触发”。问题在于，我的日常对话中很少提到“信息化规划”这个关键词。后来改为场景化的触发词，并结合用户视角的描述：“当你既要‘看方向’又要‘用数据说话’时，请加载此角色”。关键词触发与场景描述相结合，提供双重保障。

**参考资料路径是静态配置，必须同步维护。** SKILL.md 文件中引用的本地资料路径是硬编码的。后来我重组了文件目录，路径发生了变化，但 SKILL.md 文件没有同步更新，导致 AI 去读取一个不存在的目录。这一环节没有任何自动化工具可以检查，只能依靠手动同步。

**权限红线不是安全声明，而是行为约束代码。** 这是我在实践中遇到的最深的教训之一。最初，我认为权限红线部分只需表明我在意安全即可。后来才意识到，这实际上是给 AI 设定的行为约束。举几个真实案例：

• 没有明确“SQL 只能执行 SELECT，绝不生成 UPDATE/DELETE/INSERT”，AI 确实会生成 UPDATE 语句
• 没有明确“涉及患者个人信息的数据必须建议脱敏处理”，AI 会直接输出包含姓名和身份证号的信息
• 没有明确“等保合规建议必须引用具体政策条款编号”，AI 只会给出“建议加强安全管理”这类空泛建议

**每一条红线背后，都对应一次真实的越界事件。** 这不是修辞，而是 AI 确实做出了越界行为，才促使我补充相应的规则。

IMA 知识库集成：从“有就行”到“必须先查”

后期，我为每个角色添加了 IMA 知识库集成模块。逻辑很简单：本地文件可能过时，知识库中的版本更新更及时。但集成过程又遇到了新的问题。

**知识库与本地文件的冲突处理。** 两者都引用了同一份政策文件，但版本不同，应以哪个为准？最终确定的规则是：IMA 优先，本地文件作为后备方案。我在 SKILL.md 文件中明确写明“发生冲突时以 IMA 为准”。

**激活时自动查询知识库的时机选择。** 最初设计的是“加载技能时立即查询知识库”，结果每次加载角色都会执行一次知识库查询，即便用户只是提出一个简单问题，响应速度也明显变慢。后来改为“按需检索”：加载时仅列出知识库目录，具体内容等用户问到时再查询。这减少了 80% 的无效查询。

市医保对账：从手动耗时一天到全自动只需 2 分钟

这是角色系统中最成功的自动化案例，也是调试过程最痛苦的环节。

市医保对账的业务逻辑：每月涉及 6 类结算数据（居民门诊 / 门慢 / 住院、职工门诊 / 门慢 / 住院），加上 3 种专项拨付单（医疗救助 / 公务员补助 / 大病保险），需要生成 12 个月的 sheet 表和一个汇总表。

**专项拨付单并非独立类别。** 最初按照 6+3=9 个类别进行处理，结果汇总表始终对不上。反复检查了两天才发现：专项拨付单的金额必须合并到对应的主类别中，不能单独列行。例如“公务员补助”专项拨付单的数据，必须归入“职工住院”或“职工门诊”的行中。这不是设计问题，而是医保局的结算规则。

**DRG 付费模式下“基金支付”需要取较大值。** DRG 付费改革后，基金支付不能简单取“统筹应付”，而应取 max(DRG 住院结算应付, 统筹应付)。这个规则直到第五版脚本才添加，前四版计算出的数据都存在数千元误差。

**不同年份的源文件行号不一致。** 同一个字段（如 DRG 住院结算应付），2025 年位于 R13C6，2026 年则变为 R14C6，因为医保中心更换了结算报表的格式。第一次处理 2026 年对账时，直接套用了 2025 年的脚本，结果数据全部错误。现在，SKILL.md 文件中专门增加了“年份差异”一节，详细列出了不同年份的字段位置。

**金额格式跨年不统一。** 2025 年源文件的金额字段存储为整数（例如 12345 代表 123.45 元），而 2026 年直接存储为浮点数。脚本中的 money() 函数必须根据年份区分处理逻辑。这个细节问题曾让我困惑了一整天。

最终效果：**以前制作一份年度对账表需要一整天，现在只需将数据导入，2 分钟即可生成报表。** 节省时间并非重点——关键是手动操作容易出错，而脚本处理的数据精度至少提升了一个数量级。

最终的角色体系

经过多轮迭代，目前基于 WorkBuddy 构建的角色体系如下：

角色数量从 9 个精简到 6 个角色加 2 个自动化脚本。每减少一个角色，维护成本就下降一个层级。

五条经验总结

**1. 角色数量与心智负担成正比，能合并则应合并。** 合并的维度不应是“岗位”，而应是“决策链”——信息科主任与数据统计员可以合并，因为“决策依赖数据”；系统管理员与网络安全不应拆分，因为“故障排查不分系统与网络”。

**2. SKILL.md 是动态文档，并非一次写完即可。** 每个 SKILL.md 文件平均修改了 20 次以上。每次实际使用中发现的问题，都应立即更新文档，否则下次仍会犯相同错误。

**3. 权限红线是写给 AI 的约束代码，而非安全声明。** 不要写“注意安全”这类空泛表述，应写“SQL 只能 SELECT，绝不生成 UPDATE”等具体规则。

**4. 知识库应优先于本地文件，但必须明确声明冲突处理规则。** 否则 AI 会在两个数据源之间犹豫不决。

**5. 能实现全自动的不要采用半自动，能实现半自动的不要依赖手动操作。** 市医保对账从手动一天到全自动 2 分钟，节省的时间并非用于偷懒，而是让你在需要人为判断的关键任务上更加从容。

为 AI 构建角色系统，技术门槛并不高，但业务门槛却很高。你需要非常清楚自己每天的工作内容、各项任务之间的边界在哪里、哪些可以自动化、哪些不能。AI 不会帮你理清这些问题——它只是把你理清的东西精准执行到位。

因此，整个过程中最耗时的并非编写 SKILL.md，而是**清晰思考**的过程。