第2篇：Skill的核心架构——输入、处理、输出三要素

第2篇Skill的核心架构——输入、处理、输出三要素适用人群入门→基础 | 字数约25,000字 | 预计阅读时间60分钟前言第1篇我们建立了什么是 Skill的完整认知。现在你已经知道Skill 是一个封装好的、可复用的、可执行的 AI 能力模块由身份标识、指令系统、工具集、配置项和执行逻辑五大组件构成。但知道有什么组件不等于知道怎么设计 Skill。就像你知道了汽车的零件——发动机、轮胎、方向盘、座椅——但不等于你会设计一辆好开的车。你还需要知道这些零件怎么组合、怎么协同、信息怎么在它们之间流动。这一篇我们就来建立这个组织框架——Skill 的三层架构模型。你会发现一个令人安心的事实任何一个 Skill无论它看起来多复杂、功能多强大它的内部结构都可以被抽象为三个清晰的层次输入层 → 处理层 → 输出层。这个框架不仅是你理解 Skill 的解码器——拿到一个 Skill 就能快速看懂它怎么工作的它更是你创作 Skill 时的设计蓝图——按照这个框架一步步思考你的 Skill 设计就会有条不紊、层次分明。第一章宏观视野——Skill 的三层模型1.1 为什么是三层在计算机科学中分层是一种最基本也最强大的设计思想。它的核心理念是把一个复杂系统拆分为若干层每层只负责一个明确定义的职责层与层之间通过标准的接口通信。分层的好处好处说明降低复杂度每次只想一层的事不用同时考虑全部独立变化改一层不影响其他层复用同一层可以在不同系统中复用可测试每层可以单独测试Skill 设计采用的分层模型是计算机系统中最经典的分层方式——按信息的流向分层输入层信息从哪里来处理层信息怎么被加工输出层信息去哪里1.2 先看全景图┌────────────────────────────────────────────────────────────────────┐ │ Skill 三层架构 │ ├────────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ 输入层 (Input Layer) │ │ │ │ │ │ │ │ 职责定义 Skill 接收什么信息、怎么接收、何时被触发 │ │ │ │ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ 主输入定义 │ │ 参数配置 │ │ 触发条件 │ │ │ │ │ │ ·自由文本 │ │ ·选项参数 │ │ ·关键词触发 │ │ │ │ │ │ ·结构化数据 │ │ ·数值参数 │ │ ·意图匹配 │ │ │ │ │ │ ·文件上传 │ │ ·开关参数 │ │ ·定时触发 │ │ │ │ │ │ ·语音输入 │ │ ·默认值 │ │ ·事件触发 │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ └──────────────────────────┬───────────────────────────────┘ │ │ │ │ │ 输入验证 预处理 │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ 处理层 (Process Layer) │ │ │ │ │ │ │ │ 职责定义 Skill 怎么加工信息——这是 Skill 的核心 │ │ │ │ │ │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ │ │ 指令系统 (Instruction System) │ │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ │ │角色设定 │ │行为准则 │ │处理流程 │ │ │ │ │ │ │ │·Who │ │·原则 │ │·Step 1 │ │ │ │ │ │ │ │·What │ │·底线 │ │·Step 2 │ │ │ │ │ │ │ │·Style │ │·边界 │ │·Step 3 │ │ │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ │ │约束条件 │ │推理链路 │ │输出示例 │ │ │ │ │ │ │ │·内容 │ │·简单推理 │ │·示例输入 │ │ │ │ │ │ │ │·格式 │ │·复杂推理 │ │·示例输出 │ │ │ │ │ │ │ │·安全 │ │·条件分支 │ │·格式示范 │ │ │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ 工具调用 │ │ 状态管理 │ │ │ │ │ │ ·搜索 │ │ ·上下文记忆 │ │ │ │ │ │ ·计算 │ │ ·变量存储 │ │ │ │ │ │ ·API │ │ ·会话管理 │ │ │ │ │ │ ·消息 │ │ ·持久化 │ │ │ │ │ └──────────────┘ └──────────────┘ │ │ │ └──────────────────────────┬───────────────────────────────┘ │ │ │ │ │ 质量控制 安全检查 │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ 输出层 (Output Layer) │ │ │ │ │ │ │ │ 职责定义 Skill 交付什么、怎么交付 │ │ │ │ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ 格式定义 │ │ 质量检查 │ │ 后处理 │ │ │ │ │ │ ·Markdown │ │ ·完整性 │ │ ·敏感信息过滤│ │ │ │ │ │ ·JSON │ │ ·准确性 │ │ ·格式修正 │ │ │ │ │ │ ·表格 │ │ ·格式合规 │ │ ·数据脱敏 │ │ │ │ │ │ ·纯文本 │ │ ·安全性 │ │ ·元信息添加 │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ 交付给用户 / 目标渠道 │ │ │ └────────────────────────────────────────────────────────────────────┘1.3 一个类比帮你记住餐厅三层架构很抽象用餐厅这个类比来理解输入层前厅/点餐区 顾客告诉服务员要吃什么主输入 服务员记录特殊要求参数配置 服务员确认顾客的需求输入验证 处理层后厨/烹饪区 厨师根据订单准备食材角色厨师 按菜谱的步骤烹饪处理流程 需要时从冷库取食材工具调用 按顾客口味调整条件分支 输出层出餐区 菜做好后摆盘输出格式化 检查菜品质量质量检查 由传菜员送到顾客桌上交付餐厅可以独立改菜单输入层、换烹饪方式处理层、换摆盘风格输出层——这就是分层设计的威力。1.4 三层模型的三大价值价值一降低认知负担当你设计一个 Skill 时不需要同时想用户怎么输入“AI 怎么处理”“输出长什么样”——你只需要一次聚焦一层。每一层都可以独立思考和优化。很多人创作 Skill 时觉得脑子一团乱就是因为试图一次性想完所有事。有了三层框架你只需要按顺序来——先输入层再处理层最后输出层。价值二模块化迭代想改输出格式只改输出层输入层和处理层都不用动。想调整角色设定只改处理层的角色部分其他部分不用动。想增加一个参数只改输入层处理层通过接口自动获得新参数。价值三规律复用学会了输入层怎么设计的方法论你可以把它应用到任何 Skill 上。三层模型提供的是可迁移的设计框架——不是针对某个具体 Skill 的技巧而是所有 Skill 通用的设计方法。第二章输入层Input Layer——定义 Skill 的大门2.1 输入层的核心职责输入层是 Skill 的大门。所有进入 Skill 的信息都要经过这里的定义、验证和预处理。输入层要回答三个核心问题① Skill 接收什么信息 → 用户通过什么方式提供信息文本文件语音 ② 什么条件下触发 → Skill 在什么时候被激活用户说了什么词到了什么时间 ③ 怎么确保输入有效 → 如果用户给的信息不对怎么办怎么提示用户修正2.2 输入信息的五种来源一个 Skill 的输入信息不是只有用户打字这一种来源。理解所有可能的输入来源能帮你设计更聪明的 Skill。来源一用户主输入用户主动提供的核心内容。这是最常见的输入类型。形式一自由文本 → 用户直接输入任意文字 → 优点灵活用户不需要学习格式 → 缺点AI 理解可能不准确 → 适用对话类、分析类 Skill 形式二结构化数据 → 用户按指定格式填写 → 优点精确机器易解析 → 缺点用户需要学习填写格式 → 适用数据报告、配置生成类 Skill 形式三文件上传 → 用户上传文档、图片、表格等 → 适用文档处理、图片分析类 Skill 形式四语音输入 → 用户说话系统转成文字 → 适用移动端、不方便打字场景来源二参数配置用户调用 Skill 时可以调整的旋钮——通过调整参数控制 Skill 的行为。常见参数类型 选项型从预设列表中选择 → 语言中文 / 英文 / 双语 → 语气正式 / 轻松 / 专业 数值型输入具体数字 → 字数限制800 → 输出条数5 开关型是/否 → 是否包含数据表格是/否 → 是否添加备注是/否 文本型输入简短文本 → 会议主题可选 → 报告标题可选参数设计的3-5-7 法则参数数量评价说明0-2 个极简适合简单 Skill用户几乎不用配置3-5 个标准给用户充分的选择权但不过度5-7 个偏多可以考虑把不常用的参数隐藏到高级选项7 个过多用户会觉得复杂建议简化参数设计最重要的原则每个参数都要有合理的默认值。用户打开 Skill 什么都不改用默认值就能得到不错的结果。这是合格的设计。用户改了参数后能得到更满意的结果——这是优秀的设计。来源三系统上下文系统自动提供的信息用户不需要手动输入。时间信息 → 当前时间YYYY-MM-DD HH:MM → 当前时区 → 星期几 用户信息 → 用户名称/ID → 用户所属部门/团队 → 用户偏好设置 会话信息 → 当前会话 ID → 对话历史摘要 → 上一轮的内容 环境信息 → 设备类型PC/手机 → 网络状态 → 位置信息城市系统上下文的价值在于让 Skill 能感知运行环境而不需要用户手动提供这些信息。例如用户说今天天气怎么样 → Skill 自动获取当前时间和用户位置用户说我的待办有哪些 → Skill 自动获取用户身份用户说上周的情况如何 → Skill 自动计算上周的时间范围来源四外部数据通过工具调用从外部系统获取的数据。这部分数据不是在输入层定义的而是在处理层通过工具调用获得的——但输入层需要定义是否需要外部数据的标记。例子 → 搜索引擎返回的搜索结果 → 数据库查询返回的记录 → API 返回的实时数据 → 文件系统读取的文件内容来源五历史状态如果 Skill 是有记忆的——它会在多次使用之间记住一些信息。会话内记忆 → 本轮对话中用户已经提供的信息 → 例用户上一轮说预算5000这一轮说推荐产品 → Skill 记住预算5000作为参考 跨会话记忆 → 不同会话之间保持的信息 → 例用户偏好设置、上次选择的结果 → 需要外部存储支持2.3 输入字段的完整设计在 Skill 编辑器中定义输入时每个输入字段需要指定以下属性字段名Field Name 用户看到的标签要简短清晰 ✅ 会议内容 会议主题可选 ❌ 输入信息 字段1 字段类型Field Type 自由文本不限格式 短文本限制字数 选项从列表选择 数字只接收数字 布尔值是/否 是否必填Required 必填用户必须提供 选填用户可以不填用默认值 默认值Default 用户不填时使用的值 必须合理——什么都不改也能用 验证规则Validation 对输入做检查 → 长度不能超过5000字 → 必须是合法邮箱格式 → 必须是中文 帮助提示Placeholder 输入框里的提示文字 ✅ 请粘贴会议笔记越详细效果越好 ❌ 输入内容2.4 输入验证——把问题消灭在门口好的输入设计不仅仅是让用户填信息更是帮用户填对信息。为什么要做输入验证因为用户给的信息可能不满足 Skill 的需要太短 → 无法提取足够信息太长 → 超出 Token 预算格式不对 → AI 处理困难内容不相关 → 输出质量差验证规则的设计长度验证 太短 → 您提供的内容似乎比较简短建议补充更多细节以获得更好的结果。 太长 → 您提供的内容超过了处理上限5000字请精简或分段处理。 格式验证 需要邮箱 → 检查是否有 需要日期 → 检查是否符合 YYYY-MM-DD 需要数字 → 检查是否为有效数字 内容验证 是否为空 → 提示用户输入内容 是否包含明显无关内容 → 提示似乎与任务不相关好的输入验证特征在用户发送之前就提示问题即时验证告诉用户具体是什么问题不是输入有误这种模糊提示告诉用户怎么修正“请补充更多细节而不是输入太短”2.5 触发条件——Skill 什么时候被唤醒触发条件决定了 Skill “什么时候被激活”。定义得越精准用户体验越好——该触发的时候触发不该触发的时候不乱触发。四种触发方式方式一主动触发用户主动选择或输入指令来调用 Skill。形式1斜杠命令 → 用户在输入框输入 /周报 来调用周报生成 Skill → 优点明确不会误触发 → 适用用户知道 Skill 名称的场景 形式2手动选择 → 用户从 Skill 列表中点击选择 → 适用Skill 数量不多用户可以浏览选择方式二意图匹配系统根据用户的自然语言输入自动判断并匹配 Skill。工作原理 用户输入帮我整理一下上午的会议记录 → 系统分析整理会议记录→ 匹配会议纪要整理 Skill → 自动触发用户无需手动选择 用户输入今天有什么新闻 → 系统分析新闻 → 匹配财经资讯 Skill → 自动触发 关键描述写得越精准匹配准确率越高 ✅ 好描述 整理会议笔记、会议记录、录音转写文本生成结构化会议纪要。 适用于项目评审会、周会、需求会、复盘会等。 用户触发词整理会议、写纪要、会议总结、会议记录。 ❌ 差描述 整理会议相关的内容。方式三定时触发Skill 在预设的时间点自动执行不需要用户输入。配置项 触发时间每天 08:00 执行内容获取昨日市场动态 输出方式推送到指定群聊 频率每个工作日 适用场景 - 每日新闻推送 - 定时数据报告 - 定期健康检查 - 日常提醒方式四事件触发外部系统的事件触发 Skill 执行。事件类型 - 收到新邮件 → 触发邮件摘要 Skill - 新文件上传到文件夹 → 触发文档分类 Skill - 审批状态变更 → 触发审批通知 Skill - 定时器到达 → 触发定时任务 Skill 适用场景 - 自动化工作流 - 系统集成场景 - 实时响应场景2.6 输入层的设计原则原则一最小化原则只要求用户提供不可缺少的信息。能自动获取的时间、用户信息等不要问用户。✅ 好的设计“请粘贴会议内容。日期和参会人由系统自动提取。”❌ 不好的设计“请提供会议内容、会议日期、参会人列表、记录人姓名、部门……”原则二渐进式披露先让用户填核心内容就够了。高级选项可以收起。初始界面 [输入框] 请粘贴会议内容必填 [选择器] 输出语言中文 ▼ [按钮] [展开高级选项] 高级选项 [输入框] 会议主题选填 [选择器] 详细程度标准 ▼ [开关] 添加备注关原则三防呆设计用户可能在任何环节犯错。好的输入设计会帮用户防呆- 用下拉菜单代替手写防止拼写错误 - 给示例而不是只给说明像这样比按规范好 - 即时校验而不是事后报错 - 合理默认值用户不填也能用第三章处理层Process Layer——Skill 的大脑3.1 处理层的核心职责处理层是 Skill 的灵魂所在。它负责加工输入层传来的信息产出半成品交给输出层。处理层要回答的问题① AI 扮演什么角色 → 角色设定激活哪个知识域以什么风格输出 ② 按什么步骤处理 → 处理流程先做什么再做什么 ③ 有什么限制 → 约束条件什么能做、什么不能做 ④ 需要调用什么外部能力 → 工具集成需要搜索需要计算需要发消息 ⑤ 怎么处理复杂情况 → 推理链路多步推理条件分支循环处理3.2 角色设定——Skill 的人格角色设定是处理层的第一个要素也是最重要的要素。一个精准的角色设定效果抵得上 10 条额外的指令。为什么角色设定如此重要大语言模型在训练时读过海量的文本。这些文本被隐性分类为不同的角色域律师写的文本 → 严谨、逻辑严密、引用法条记者写的文本 → 客观、5W1H、注重事实核查产品经理写的文本 → 用户视角、需求分析、优先级判断老师写的文本 → 由浅入深、举例说明、耐心讲解销售写的文本 → 以客户为中心、突出价值、促成行动当你说你是一位律师时模型自动激活律师域——它的输出会更严谨、更有逻辑。当你说你是一位老师时模型自动激活老师域——它的输出会更耐心、更通俗。这就是角色设定的本质知识域激活 风格迁移。角色设定的三阶模型第一阶只给身份效果有限 → 你是一位数据分析师。 → 激活通用分析知识但不聚焦 第二阶身份领域效果中等 → 你是一位专注于电商行业的数据分析师。 → 缩小到电商领域更有针对性 第三阶身份领域经验风格推荐 → 你是一位有8年电商行业经验的数据分析师曾处理过日活千万级产品的数据。 你的分析风格是先给核心结论再用数据论证最后给出可执行的建议。 你在做分析结论前会先确认数据的完整性和可靠性避免被误差误导。 → 完整激活资深电商数据分析师的思维模式角色设定的微调技巧当输出在某些方面不理想时不需要重写角色设定而是做精准微调输出太技术化用户看不懂 → 在角色中加入善于用通俗语言解释复杂概念 输出太保守没有洞察 → 在角色中加入不仅分析现状还要预判趋势 输出浮于表面 → 在角色中加入习惯做多维度交叉分析挖掘深层原因 输出太啰嗦 → 在角色中加入风格简洁能用一句话说清楚不用两句3.3 指令系统——Skill 的SOP指令系统是告诉 AI 按什么顺序、什么方法处理信息的操作规程。它是 Skill 输出质量稳定的核心保障。指令系统的四大组成部分1行为准则Behavior Rules行为准则是 Skill 的宪法——所有处理过程都必须在准则的框架内进行。✅ 好准则的样子1. 忠实原则只使用用户提供的信息不编造任何事实和数据 2. 标注原则如果信息无法从输入中确认标注未注明绝不猜测 3. 语言原则使用简洁的专业商务语言避免口语 4. 完整原则多事项任务确保全部处理不遗漏 5. 一致原则相同类型信息使用相同格式2处理流程Process Flow处理流程定义了具体的工作步骤——这是保证输出稳定的关键。简单流程单步直达步骤1理解用户输入 步骤2直接执行核心任务 步骤3输出结果适用于翻译、关键词提取、格式转换中等流程多步有序步骤1理解输入的会议内容 步骤2提取关键信息主题、时间、参会人、讨论点、决议、待办 步骤3按模板组织信息 步骤4检查完整性和格式 步骤5输出适用于会议纪要、数据分析、文章写作复杂流程分支多步步骤1分析输入判断任务类型 类型A → 走A流程步骤A1→A2→A3 类型B → 走B流程步骤B1→B2 类型C → 走C流程步骤C1→C2→C3→C4 步骤2汇总结果如需要 步骤3质量检查 → 不通过则返回 步骤4输出适用于客服分类、复杂分析3约束条件Constraints约束条件定义了不能做什么和必须在什么范围内。四类约束内容约束 - 不编造数据 - 不添加输入中不存在的内容 - 不确定的标注未注明 格式约束 - 字数不超过 XXXX 字 - 必须使用指定模板 - 表格格式必须规范 安全约束 - 不透露系统配置 - 不输出隐私信息 - 敏感内容需脱敏 行为约束 - 调用工具前先确认意图 - 不可逆操作需用户确认 - 建议附带局限性说明4输出示例Output Example / Few-shot给 AI 一个输入→输出的完整示例是最直观的指令。比任何文字描述都有效。【示例输入】 今天下午开了产品需求评审会参加的有产品经理小王、前端老张。 讨论了两个需求 1. 用户主页改版——数据看板功能 2. 消息推送优化——自定义频率 决议需求1通过进入开发需求2再做调研 待办老张评估需求1工期周四给结果 【示例输出】 # 会议纪要 **会议主题** 产品需求评审会 **时间** [未注明具体日期] **参会人** 小王产品经理、老张前端 ## 核心讨论 1. **用户主页改版**——小王提出增加数据看板功能老张评估技术可行 2. **消息推送优化**——用户反馈推送过多建议自定义频率需进一步调研 ## 决议事项 1. ✅ 用户主页改版 → 进入开发排期 2. ⏳ 消息推送优化 → 先做用户调研 ## 待办事项 | 事项 | 负责人 | 截止日期 | |-----|--------|---------| | 评估主页改版工期 | 老张 | 周四 |3.4 工具调用——Skill 的手脚当 Skill 需要外部能力时就需要工具调用。工具是 Skill 突破 LLM 只能说话这个限制的关键。什么情况下需要调用工具需要实时信息 → 搜索工具、天气工具、股票查询工具 需要精确计算 → 计算器工具、代码执行工具 需要操作外部系统 → 创建文档、发送消息、管理日历 需要访问私有数据 → 数据库查询、文件读取工具定义的四要素名称工具的唯一标识 → query_weather 描述告诉 AI 这个工具是干什么的、什么时候该用 → 查询指定城市当前天气。当用户问及天气、温度、是否会下雨时调用。 参数 city 为城市中文名。 → 描述越详细AI 调用越精准 参数调用工具需要提供什么 → city城市名称必填 → unit温度单位选填默认celsius 规则什么情况下能调用 → 只在用户明确问天气时调用 → 不用于非天气相关的查询一个工具的完整配置示例JSON{name:web_search,description:搜索互联网获取最新信息。当用户问新闻、最新动态、时效性问题时使用。参数query应该简洁不要包含修饰性词语。不适合数学计算。,parameters:{query:{type:string,description:搜索关键词简洁准确},count:{type:number,description:返回结果数量,default:5}}}工具不是越多越好。每个工具都有成本时间、费用过多的工具会让 AI “选择困难”。一个 Skill 配置 1-3 个核心工具就足够了。3.5 状态管理——Skill 的记忆对于需要多轮对话的 Skill需要管理状态——记住对话进行到哪一步了、已经获得了什么信息。状态管理的层次无状态Stateless 不记住任何历史信息每次都是独立的 适用翻译、格式转换等单轮 Skill 会话状态Session State 记住本轮对话中的信息 示例 第一轮用户说预算5000→ 状态记录 {budget: 5000} 第二轮用户说推荐产品→ 状态读取 budget → 推荐5000以内的产品 适用客服咨询、需求收集等多轮 Skill 持久状态Persistent State 跨会话记住信息 需要外部存储支持 适用需要长期记忆的场景状态管理的实现方式最简单的状态管理对话上下文 通过保留对话历史来维持状态 优点实现简单不需要额外机制 缺点Token消耗大长对话效果下降 进阶的状态管理显式变量存储 把关键信息提取到变量中 优点精确不依赖完整对话历史 缺点需要定义变量提取逻辑 高级的状态管理外部持久化 写入数据库或文件 优点跨会话可用数据不丢失 缺点实现复杂度高第四章输出层Output Layer——Skill 的交付4.1 输出层的核心职责输出层是 Skill 的橱窗——用户最终看到的内容就是这里产出的。如果说处理层决定了 Skill “多能干”输出层决定了 Skill “多好用”。输出层要回答的问题① 输出长什么样 → 格式定义MarkdownJSON表格纯文本 ② 输出是否合格 → 质量检查完整吗准确吗安全吗 ③ 需要做什么后处理 → 过滤格式化脱敏添加元信息4.2 输出格式的详细设计输出格式决定了用户拿到手的成果是直接可用还是需要二次加工。好的输出格式 用户零加工。常见输出格式对比格式适用场景优点缺点Markdown阅读型内容可读性高支持富文本需要渲染器JSON程序接口机器可读结构化人眼阅读困难表格数据对比一目了然信息有限纯文本简短回复轻量直接无格式混合格式综合报告灵活组合设计复杂输出模板的设计输出模板是填空式的——框架固定内容由 AI 填充。模板示例——会议纪要 # 会议纪要 **会议主题** {{主题}} **时间** {{时间}} **参会人** {{参会人}} ## 核心讨论 {{逐条列出讨论要点}} ## 决议事项 {{逐条列出决议}} ## 待办事项 | 事项 | 负责人 | 截止日期 | |-----|--------|---------| | {{事项1}} | {{负责人}} | {{日期}} | | {{事项2}} | {{负责人}} | {{日期}} | --- *由「会议纪要整理」Skill 自动生成 | {{生成时间}}*4.3 质量检查——输出层的质检员模型生成内容后输出层需要做质量检查。这是保证 Skill 输出稳定达标的关键环节。质量检查的五维度模型维度一完整性 检查项 □ 是否包含所有必需的章节 □ 是否有标题 □ 如果有多个事项是否全部处理了 □ 没有遗漏关键部分 维度二准确性 检查项 □ 事实性信息是否正确 □ 数字和日期是否合理 □ 没有添加不存在的信息 □ 引用与来源一致 维度三格式合规性 检查项 □ 标题层级正确 □ 表格格式规范 □ 列表缩进正确 □ Markdown 语法无误 维度四可读性 检查项 □ 语言通顺 □ 没有语法错误 □ 信息密度适中 □ 段落长度合理 维度五安全性 检查项 □ 不包含个人隐私 □ 不包含敏感数据 □ 不包含不当内容 □ 是否需要免责声明4.4 后处理——输出的精加工模型产出原始内容后输出层可以做一系列后处理来提升质量。常见的后处理操作格式规范化 - 统一标题格式确保所有 # 使用一致 - 修复表格对齐 - 统一列表标点 内容过滤 - 移除安全违规内容 - 过滤重复内容 - 移除广告信息 敏感信息处理 - 手机号脱敏138****1234 - 身份证脱敏110101****1234 - 姓名脱敏张** 元信息添加 - 添加生成时间戳 - 标注 Skill 名称和版本 - 添加使用提示 多格式输出 - 同时生成 Markdown 和纯文本 - 同时生成详细版和精简版4.5 输出层的渠道适配同一个 Skill 的输出可能需要在不同渠道呈现同一个每日简报 Skill 渠道A飞书群消息 → 纯文本 消息卡片 → 简洁、要点式 → 字数控制在 500 字以内 渠道B邮件推送 → HTML 格式 → 包含图片和链接 → 完整报告版 渠道CAPI 接口 → JSON 格式 → 结构化数据 → 包含元信息 渠道D手机推送 → 极简纯文本 → 只推送最重要的 3 条信息 → 带跳转链接输出适配不同渠道是高级 Skill 设计的重要能力——处理逻辑不变交付方式灵活变化。第五章三层之间的接口——信息如何流动5.1 接口的定义三层之间不是各自孤立的。它们通过标准的接口传递信息。接口定义了上一层给下一层什么以及下一层期望收到什么。输入层 → 处理层的接口Input Contract{user_input:用户输入的核心内容文本,params:{language:中文,word_limit:800,include_table:true},context:{timestamp:2026-05-20T15:30:00,user_id:user_12345,session_id:session_67890},attachments:[]}处理层 → 输出层的接口Output Contract{raw_output:模型生成的原始文本内容,metadata:{model:gpt-4o,tokens_used:2450,tools_called:[search],steps_executed:[理解,分析,生成]},quality_checks:{format_ok:true,length_ok:true,safety_ok:true}}5.2 接口的价值价值一独立开发和测试定义好接口后三层可以独立开发输入层改参数定义 → 不改处理层处理层改流程 → 不改输出层输出层改格式 → 不改处理层价值二错误定位当输出出问题时通过检查接口数据快速定位输入层给处理层的数据不对 → 输入层的问题处理层给输出层的数据有问题 → 处理层的问题输出层自己加工出问题 → 输出层的问题价值三复用同一套处理层可以对接不同输出层适配不同渠道。同一套输出层可以对接不同处理层用不同模型/版本。第六章三层设计的反模式6.1 反模式一输入层过于复杂表现要求用户填写 10 多个字段每个还有复杂的格式要求。后果大部分用户看到复杂界面直接放弃。解决方案核心输入不超过 2-3 个字段其他参数给合理默认值高级选项收起6.2 反模式二处理层指令混乱表现角色设定、处理流程、约束条件混在一起写没有结构。后果AI 理解混乱输出不稳定。解决方案用分隔线明确分区角色设定/处理流程/约束条件每个部分只写一个主题用编号列表说明步骤顺序6.3 反模式三输出层没有格式表现只告诉 AI “输出好一点”没指定具体格式。后果每次输出格式不同用户需要大量二次加工。解决方案给出完整输出模板给一个输出示例明确所有格式要求6.4 反模式四层间高度耦合表现改输出格式必须同时改处理层改处理层必须同时改输入层。后果牵一发而动全身维护成本高。解决方案明确定义接口层间只通过接口通信不在一个层中写假设另一层一定怎么做的逻辑用独立配置管理各层行为第七章三层设计的自检清单完成 Skill 设计后用这个清单做架构审查输入层自检□ 主输入是否有清晰的字段名和提示说明 □ 必填字段的数量最少只让用户填真正需要的 □ 参数有合理默认值用户什么都不改也能用 □ 输入有校验规则能帮用户避免常见错误 □ 触发条件明确不会误触发也不会漏触发 □ 有输入示例或引导文字帮助用户理解处理层自检□ 角色设定满足三要素职业领域风格 □ 处理流程有明确的步骤分解 □ 约束条件具体、可执行 □ 工具调用条件清晰 □ 状态管理适当 □ 有输出示例供 AI 参考 □ 边界情况有处理方案输出层自检□ 输出格式明确指定 □ 有输出模板或示例 □ 有字数/长度限制 □ 质量检查覆盖完整、准确、格式、安全 □ 有后处理逻辑 □ 输出可直接使用用户不需要二次加工 □ 适配了交付渠道的要求写在最后Skill 的三层架构——输入层 处理层 输出层——是 Skill 创作的通用蓝图。当你面对一个全新的 Skill 创作任务时按顺序走过三层的设计流程1️⃣ 先设计输入层用户给我什么我怎么接收什么时候被触发2️⃣ 再设计处理层我扮演什么角色按什么步骤加工有什么限制需要什么工具3️⃣ 最后设计输出层加工完的东西怎么交给用户长什么样质量怎么保证每次只聚焦一层思考清楚一层再进入下一层。这样你的设计过程就有条不紊不会因为同时要想太多而混乱。课后练习拆解练习找一个你常用的 AI 功能如翻译、总结、问答用三层架构拆解——输入层有什么、处理层可能怎么配置、输出层是什么格式诊断练习找一个你觉得输出不太好用的 AI 功能分析是输入层的问题用户输入不充分还是处理层的问题指令不清晰还是输出层的问题格式不好用设计练习选一个你想做的 Skill 创意按照三层架构写出设计草图——输入层定义、处理层流程、输出层格式。下一篇预告《第3篇第一个Skill——从0到1手把手创作指南》框架有了接下来下水。下一篇跟着一个完整的实战案例——从我有一个想法到发布一个可用的 Skill——全程手把手走过每一行指令、每一个配置。三层架构是所有 Skill 的通用语言。学会了它你看任何 Skill 都能一眼看穿它的设计逻辑。️