求造｜团队 AI 插件架构指南：App、Skill 与工作流怎么拆掉巨型 Prompt？

直接答案

团队不该用一条不断增长的巨型 Prompt 同时承担角色定义、知识来源、工具权限、执行步骤和输出格式。更可维护的 AI 插件结构，是把它们拆成一组有边界的部件：角色说明回答“替谁工作”，Skill 固化判断方法，App 或 MCP 连接真实数据与动作，工作流安排步骤和确认点，模板约束最终交付物。

这样拆分的价值不只是让文件更整齐，而是让团队能单独替换数据源、更新规则、限制权限和定位失败层。Prompt 负责表达意图，插件负责把可复用的工作方式装成一包。

OpenAI 发布的教育插件是什么

OpenAI 在 2026 年 8 月 4 日发布了三款面向教育场景的新插件：K–12 教师插件、高校教师插件和高校学生插件。官方将 plugin 定义为由 App、角色专用 Skill、指令和常见工作流组成的包，用来帮助用户直接开始多步骤任务，而不必先自己构造复杂 Prompt。

这些插件可连接用户选择的课程材料、文档、日历和其他获准 App。K–12 教师插件侧重课堂规划与材料制作；高校教师插件覆盖课程设计、教学和学术规划；高校学生插件可基于学生选择的来源生成辅导、练习、学习指南、测验、闪卡和交互式解释。

当前可用范围也很明确：三款插件面向 ChatGPT Edu 和 ChatGPT for Teachers 的学区部署。机构仍然控制允许使用的工具与权限。因此，这篇不是安装体验报告，而是从官方产品结构中提炼一个值得团队验证的组织方式。

为什么巨型 Prompt 很快会失控

一条长 Prompt 往往混进六类变化速度不同的信息：

• 角色与完成标准：发布经理、内容编辑、客服质检的目标不同；
• 业务来源：项目文档、课程材料、日历、代码仓库会不断变化；
• 判断方法：评审规则、写作规范、风险边界需要独立迭代；
• 工具能力：GitHub、工单、数据库、App 或 MCP 的权限各不相同；
• 执行顺序：哪些步骤自动进行，哪里必须确认，何时停止；
• 输出契约：周报、PRD、代码评审或客户回复有固定结构。

把它们塞在同一个文本块里，会出现一个典型问题：任何一层变化都要重读、重写并重新验证整条 Prompt。失败时也很难回答，究竟是资料没取到、Skill 判断错了、连接器执行失败，还是输出模板遗漏了字段。

团队 AI 插件的六层架构

下面的六层骨架是对官方“App + 角色 Skill + 指令 + 常见工作流”定义的工程化延伸，不是 OpenAI 公布的固定目录规范。它适合用来做可逆原型。

1. Role：角色、目标和完成标准

写清插件替谁工作、负责什么结果、什么条件下算完成。角色层不应堆工具说明，它只定义职责、优先级和需要人工决定的事项。

2. Sources：允许使用的上下文

列出可以读取的项目、文档、课程材料、日历和业务系统，并标明选择规则。来源层解决“事实从哪里来”，避免 Skill 把过期背景当成永恒常识。

3. Skills：稳定复用的判断方法

Skill 承载某类任务可重复的步骤、检查标准和领域方法，例如发布检查、事实核验、代码评审或客户问题分类。它应该能在不更换连接器的情况下独立更新。

4. Apps / MCP：读取数据和执行动作

App 是官方插件定义里的连接能力；在其他 Agent 系统中，MCP 也可以承担类似的工具连接角色。它们负责读取仓库、查询日历、检索文档或提交动作。连接器应该暴露明确权限，而不是因为插件“扮演某个角色”就自动获得全部账户能力。

5. Workflows：触发、步骤、确认点和停止条件

工作流决定一次任务怎样开始、按什么顺序调用 Skill 与工具、哪些动作需要人工确认、遇到什么条件必须停止。它把“每次都靠用户重新解释”的隐性流程变成可检查的执行路径。

6. Templates：输出契约

模板固定交付物需要的字段、顺序和格式，例如发布公告必须包含版本、影响范围和回滚入口。它不负责判断内容是否正确，但能防止每次输出都重新发明结构。

App、MCP、Skill 和工作流有什么区别

可以用一句话区分：Skill 决定“怎么判断”，App 或 MCP 提供“能读什么、能做什么”，工作流规定“先做什么、何时确认”，模板约束“最终交付什么”。

如果 Skill 内部写死某个 API 地址，换数据源就必须重写判断方法；如果连接器偷偷决定业务规则，权限或接口变化就可能改变最终结论；如果工作流没有确认点，再好的 Skill 也可能执行不该自动执行的动作。边界拆开后，每层才有独立测试和替换的可能。

示例：把发布经理从 4,000 字 Prompt 拆成插件

假设团队每周都要完成一次发布评审，可以这样分层：

• Role：发布经理，目标是形成可发布或阻塞结论；
• Sources：当前版本说明、迁移记录、回滚文档和变更范围；
• Skill：检查版本号、数据库迁移、兼容性、测试证据与回滚条件；
• App / MCP：从 GitHub 获取提交与 CI，从 Sentry 获取错误状态；
• Workflow：收集证据 → 执行检查 → 遇到 blocker 停止 → 人工确认发布 → 生成公告；
• Template：结论、变更摘要、已验证项、阻塞项、回滚入口。

当 Sentry 被替换时，只换连接器；当发布标准变化时，只改 Skill；当公告格式变化时，只改模板。团队不必在同一段人格设定里寻找所有相关句子。

最小插件原型怎么做

先选一个每周至少重复一次、输入清楚、结果可验收的任务，不要从“做一个万能助手”开始。最小目录可以只有：

release-plugin/
  role.md
  sources.json
  skills/release-check/SKILL.md
  workflows/release-review.md
  templates/release-note.md

第一版只接一个真实数据源，只自动完成一个低风险步骤，并保留一个人工确认点。准备两份输入样本：一份应该通过，一份必须因缺少证据或发现 blocker 停止。这样最快能判断分层是否真的改善维护和定位，而不是把一条长 Prompt 拆成多个仍然互相纠缠的文件。

上线前检查清单

1. 角色是否只有一个明确任务，而不是“什么都能做”？
2. 每项事实能否追溯到获准来源？
3. Skill 是否独立于具体连接器，规则变化时能单独更新？
4. App 或 MCP 是否遵循最小权限，写操作是否有确认点？
5. 工作流是否定义输入、检查点、停止条件和恢复方式？
6. 模板是否能让读者快速判断结果是否完整？
7. 是否有一个应通过和一个应阻塞的真实样本？
8. 失败日志能否指出是来源、Skill、连接器、流程还是模板出错？

常见问题

什么任务最适合先做成团队插件？

优先选择高频、角色固定、输入来源明确、验收标准稳定的任务，例如发布评审、内容事实核验、客服质检或周报整理。低频且每次目标都不同的探索任务，未必值得先封装。

有了 Skill，还需要工作流吗？

需要。Skill 描述一类任务的稳定方法，工作流负责把多个步骤、工具和人工确认串起来。一个检查规则可以被多个工作流复用，同一工作流也可以调用多个 Skill。

MCP 就等于插件吗？

不等于。MCP 常用于向模型提供工具与上下文连接；插件还需要角色、指令、Skill、工作流等组织层。只有连接器而没有完成标准和执行路径，仍然要靠用户每次重新指挥。

拆成多个文件后，会不会只是把复杂度藏起来？

会，所以要看能否独立替换和测试。如果换一个数据源仍然要同时修改角色、Skill 和模板，说明边界没有真正拆开。分层的验收标准不是文件数量，而是变化能否被限制在对应模块。

这些教育插件现在值得安装吗？

本站尚未实际运行，暂不做安装推荐。官方当前公布的可用范围是 ChatGPT Edu 与 ChatGPT for Teachers 学区部署。非教育团队可以先验证它的打包思路，不应把本文当成插件效果评测。

失败信号

• 插件仍以一条主 Prompt 为中心，其他文件只是附件；
• 换数据源必须重写 Skill，改输出格式又影响工具调用；
• App 或 MCP 获得宽泛写权限，却没有人工确认点；
• 每次运行都要重新解释什么算完成；
• 出错后只能看到“任务失败”，无法定位具体层；
• 没有真实输入样本，也没有必须停止的反例。

这批教育插件的实际效果本站尚未运行验证，因此保持“未测试、暂不推荐”。我们更想先验证结构：请选发布经理、内容编辑、客服质检或你自己的角色，用六层骨架拆一项真实任务，并贴出最小目录、输入样本和验收规则。谁先交出一次可复现运行，我们就优先做下一篇复盘。

— Token Beggars 编辑部