大厂内训资料： Skill设计7大核心原则，AI时代，人人必备（史上最全）

本文 的 原文 地址

原始的内容，请参考 本文 的 原文 地址

本文 的 原文 地址

尼恩说在前面

在45岁老架构师尼恩的读者交流群（50+人）里，最近不少小伙伴拿到了阿里、滴滴、极兔、有赞、希音、百度、字节、网易、美团这些一线大厂的面试入场券，恭喜各位！

前两天就有个小伙伴面阿里， 在阿里二面中，针对 “Skill设计7大核心原则有哪些？ 你们的 研发场景、运维场景怎么设计skill ”的场景题 ，小伙伴没有概念，导致面试失败。

小伙伴 没有看过系统化的 答案，回答也不全面 ，so， 面试官不满意 ， 面试挂了。

小伙伴找尼恩复盘， 求助尼恩。

尼恩问了一个小米的小伙伴，找到了他们 大厂内训资料《 Skill设计7大核心原则 》 ，然后 在此基础上 扩展了一下，加了一些案例和详细介绍，并且加上插图，成为 尼恩版本的《 Skill设计7大核心原则 》 。

这里通过《 Skill设计7大核心原则 》， 尼恩给大家做一下 系统化、体系化的梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，后台回复：领电子书

大厂内训资料： Skill设计7大核心原则

原则编号	核心主旨	关键要点
原则 1	专注于“模糊逻辑”	Skill 仅包含模糊/决策/理解逻辑；确定性逻辑（计算、API、流程）封装到脚本或 MCP 工具中。
原则 2	渐进式披露	最小化上下文占用 , 上下文是稀缺资源，需渐进式披露：仅加载 Name/Desc（Level 1），正文（Level 2）触发加载，脚本/文档（Level 3）按需加载。
原则 3	明确触发描述	Description 必须同时包含“能力（做什么）”和“场景（何时用）”，避免模糊描述导致 AI 无法触发。
原则 4	指令的绝对性	使用命令式语气（直接说“做什么”），避免建议性语气（“你应该”），确保执行一致性。
原则 5	清晰定义边界	明确规定能做什么、不能做什么、失败条件以及何时必须转人工，包含降级策略。
原则 6	工程化闭环	必须有明确的成功标准（格式、准确率）、测试用例（正例/反例）和迭代机制，不靠感觉。
原则 7	最小够用原则	仅提供模型不知道、易出错或必须遵守的业务规则，不重复常识或基础定义。

原则 1：Skill 专注于“模糊逻辑”， 只描述需要模型推理的部分

核心逻辑

Skill 的上下文窗口极其昂贵，不应浪费在计算机本来就能完美执行的确定性任务上。

Skill 应专注于“模糊逻辑”，而将“确定性逻辑”外包。

细化执行策略

（1） 逻辑分流标准：在编写 Skill 前，先问自己：“这个步骤有唯一的标准答案吗？”

• 是（确定性）：如数学计算、文件格式转换、正则匹配、API 调用。→ 写入脚本或 MCP 工具，Skill 只负责调用。

• 否（模糊性）：如情感分析、意图识别、内容润色、复杂决策。→ 写入 Skill 正文。

(2)代码优于文本：如果一个流程可以用 Python 脚本（如 pandas 处理数据）或 Shell 命令精确描述，绝不要用自然语言在 Skill 里教 AI 怎么做。

(3) Skill 的角色：Skill 是“大脑”，负责判断“做什么”；脚本/MCP 是“手脚”，负责“怎么做”。

避坑指南

• 错误：在 Skill 里写“请逐行读取 CSV 文件，计算第三列的总和”。

• 正确：Skill 指示调用 calculate_csv_sum 工具，仅处理工具返回的异常或解释结果。

原则 1 电商案例：智能退换货审核 Skill

核心：Skill = 模糊 / 决策 / 理解类逻辑；脚本 / MCP = 确定 / 计算 / API / 流程类逻辑

案例背景

电商平台日常会接收大量用户退换货申请，涉及质量问题、尺寸不符、七天无理由等多种场景，同时需兼顾用户情绪安抚与平台规则执行。传统人工审核效率低、标准不统一，因此设计智能退换货审核Skill，实现审核流程自动化，同时保留模型对复杂场景的决策能力，将确定性操作交给脚本执行，提升审核效率与用户体验。

案例核心逻辑

尼恩提示：此处省略 1000字，具体请参考 免费pdf。

原文3w字以上， 此文是精简版，完整版本，请参考 尼恩 免费百度网盘 免费pdf

原则 2：渐进式披露： 上下文窗口是稀缺公共资源 , 最小化上下文占用

核心逻辑

上下文（Context Window）是所有 Skill 共享的“内存”。一次性加载所有信息会导致“上下文污染”，增加延迟和成本，甚至导致模型迷失重点。

细化执行策略

(1)三层加载架构：

• L1 钩子（常驻）：仅在系统提示词中保留 name 和 description。这是 AI 决定是否调用 Skill 的唯一依据，必须极短（<100 tokens）。

• L2 核心（触发加载）：当 AI 决定调用 Skill 时，加载 SKILL.md 正文。包含核心工作流、关键规则。限制在 500 行或 5k tokens 以内。

• L3 资源（按需引用）：对于庞大的 API 文档、复杂的 JSON Schema 或参考代码，不要直接贴在正文中。使用相对路径引用（如 See ./references/api_spec.md），仅在模型明确读取该文件时才消耗 Token。

(2)目录化设计：将 Skill 设计为“目录”而非“百科全书”，引导模型去查阅详情，而不是把详情直接喂给它。

避坑指南

• 错误：把 50 页的 API 文档全部塞进 Skill 的 body 里。

• 正确：Skill 正文只写“调用 API 时需遵循鉴权规则（见 auth.md），参数格式参考 schema.json”。

原则 2电商案例：商品详情页生成 Skill

核心：渐进式披露，能拆到 references/scripts 就不写在 body 里，按Level分级加载，最小化上下文占用

案例背景

电商平台新品上架、老品优化时，需快速生成高转化率的商品详情页，涉及3C、服饰、食品等多类目，每个类目有专属规则与模板，且包含大量参考资料（如卖点指南、类目规范）。

若将所有内容都放入Skill正文，会严重占用上下文窗口，导致模型运行卡顿、触发失败，因此设计渐进式加载的商品详情页生成Skill。

案例核心逻辑

尼恩提示：此处省略 1000字，具体请参考 免费pdf。

原文3w字以上， 此文是精简版，完整版本，请参考 尼恩 免费百度网盘 免费pdf

原则 3：明确触发描述: Description 必须同时讲清「做什么 + 何时用」

核心逻辑

Description 是 Skill 的“门面”和“路由器”。

Description 需要明确触发描述 逻辑， 如果描述不清，AI 要么在不需要时误触发（浪费资源），要么在需要时忽略它（能力失效）。

细化执行策略

(1)双重包含公式：一个完美的 Description = 能力定义 + 触发场景/关键词。

• 能力定义：用第三人称、动名词开头（如 "Processes...", "Analyzes..."）。

• 触发场景：明确指出用户说什么话、或者遇到什么文件类型时应该激活此 Skill。

(2)关键词埋点：在描述中显式包含高频触发词。例如，如果 Skill 用于处理 Excel，描述中必须出现 "Excel", "Spreadsheet", ".xlsx", "表格分析" 等词汇，以便向量检索或关键词匹配。

避坑指南

• 错误：“Excel 助手”（太泛，AI 不知道何时用它）。

• 正确：“从 Excel 文件中提取销售数据，按地区聚合，并生成 Markdown 表格；当用户上传 .xlsx 文件或请求分析季度报表时触发。”

原则 3电商案例：库存预警与补货建议 Skill

核心：Description 是Skill的"触发器"，必须同时包含：具体能力 + 明确触发场景，可补充边界（不适用于什么），避免AI误触发

案例背景

电商平台库存管理是运营核心环节，需实时监控库存水位，避免缺货导致订单流失，同时防止库存积压占用资金。尤其在大促期间，库存波动大，需提前备货；日常运营中，运营也需及时了解库存状况并获取补货建议，因此设计库存预警与补货建议Skill，确保AI能精准识别触发场景、明确自身能力边界。

案例核心逻辑

尼恩提示：此处省略 1000字，具体请参考 免费pdf。

原文3w字以上， 此文是精简版，完整版本，请参考 尼恩 免费百度网盘 免费pdf

原则 4：指令的绝对性： 命令式语气，正文用祈使句，不用建议/解释

核心逻辑

Skill 是给 AI 的“操作手册”，不是“建议指南”。

模糊的建议语气会增加模型的认知负荷，导致执行结果的不确定性（幻觉）。

细化执行策略

(1)消除“我”和“你”：不要写“你应该检查错误”或“我建议你先搜索”。

(2)使用命令式动词：直接以动词开头。

• 扫描错误日志...

• 提取关键字段...

• 格式化为 JSON...

3)示例驱动：对于复杂的格式要求，不要写长篇大论的解释。直接给出一个 Input -> Output 的少样本（Few-Shot）示例，模型模仿能力远强于理解抽象规则的能力。

避坑指南

• 错误：“你可以尝试用 JSON 格式输出，这样比较好解析。”

• 正确：“输出必须严格遵循 JSON 格式。示例：{'status': 'success'}。”

原则 4电商案例：客服话术优化 Skill

核心：Skill是给AI的执行手册，要用命令式语气，直接明确"做什么"，禁止使用"建议、可以、应该、觉得"等模糊表述，确保AI执行一致

案例背景

电商客服日常需处理大量用户咨询、投诉、售后等问题，话术质量直接影响用户满意度与转化率。

不同客服的话术风格、专业度差异较大，导致回复质量不稳定，因此设计客服话术优化Skill，规范客服回复逻辑与语气，确保AI能按统一标准优化话术，提升回复质量与效率。

案例核心逻辑

尼恩提示：此处省略 1000字，具体请参考 免费pdf。

原文3w字以上， 此文是精简版，完整版本，请参考 尼恩 免费百度网盘 免费pdf

原则 5： 清晰定义边界 ：明确边界，什么能做、什么不能做、失败怎么办

核心逻辑

AI 倾向于“讨好”用户，即使面对无法完成或危险的任务也会尝试强行回答。Skill 必须充当“安全护栏”。

细化执行策略

(1) 否定约束：明确列出禁止事项。例如：“严禁处理金额超过 10,000 元的退款申请”、“不要修改原始文件，仅生成副本”。

(2) 失败与降级策略：告诉 AI 当遇到死胡同时该做什么。

• 数据缺失：“如果找不到日期字段，直接返回错误代码 ERR_DATE_MISSING，不要编造日期。”

• 超出范围：“如果用户询问非技术支持问题，请礼貌拒绝并引导至人工客服。”

(3) 安全阈值：对于高风险操作（如删除文件、发送邮件），Skill 必须包含“确认步骤”或要求用户显式授权。

避坑指南

• 错误：只写成功流程，忽略异常情况。

• 正确：“若 API 返回 404，重试一次；若仍失败，停止执行并报告‘资源未找到’。”

原则 5电商案例：大促价格监控与预警 Skill

核心：必须清晰定义：能力边界（能做/不能做）、失败条件、降级策略、何时必须转人工，避免AI越权操作或处理失控

案例背景

大促期间（如618、双11），电商平台商品价格波动大，易出现优惠未生效、价格倒挂、竞品低价等异常情况，若处理不及时会导致用户投诉、利润损失或竞争力下降。同时，价格操作涉及平台核心利益，需严格限制Skill权限，明确失败处理方式与人工介入条件，因此设计大促价格监控与预警Skill。

案例核心逻辑

尼恩提示：此处省略 1000字，具体请参考 免费pdf。

原文3w字以上， 此文是精简版，完整版本，请参考 尼恩 免费百度网盘 免费pdf

原则 6：工程化闭环：可测试、可评估、可复现

核心逻辑

Skill 是代码，不是文章。它必须像软件代码一样，有明确的“通过/失败”标准，而不是靠“感觉”。

细化执行策略

(1) 定义成功指标：在 Skill 开发之初就定义好：

• 格式准确率：输出是否符合 JSON Schema？

• 逻辑正确性：计算结果是否精确？

• 触发召回率：在 100 个相关查询中，Skill 被激活了多少次？

(2) 构建测试集：

• 正例：10 个典型的、应该触发 Skill 的用户输入。

• 反例：10 个相似的、但不应该触发 Skill 的输入（防止误触）。

• 边缘案例：空输入、乱码输入、超长输入。

(3) A/B 测试：修改 Skill 后，必须重新跑一遍测试集，确保没有“修复一个 Bug 引入两个新 Bug”。

避坑指南

• 错误：写完 Skill 后，只在聊天窗口里手动试一次就发布。

• 正确：维护一个 tests/ 目录，包含自动化测试脚本，每次更新 Skill 自动验证。

原则 6电商案例：直播脚本生成 Skill

核心：好的Skill必须是可量化评测的，不能靠"感觉好用"，需明确成功标准、测试用例（正例+反例）、迭代机制，确保Skill质量可把控

案例背景

电商直播是核心转化渠道，直播脚本的质量直接影响直播效果（转化率、观众停留时长、互动率）。主播准备直播时，需快速生成结构完整、贴合商品卖点、符合直播时长的脚本，且脚本需可优化、可迭代。若脚本质量无法量化评估，会导致直播效果不稳定，因此设计可测试、可评估的直播脚本生成Skill。

尼恩提示：此处省略 1000字，具体请参考 免费pdf。

原文3w字以上， 此文是精简版，完整版本，请参考 尼恩 免费百度网盘 免费pdf

原则 7：最小够用原则

核心逻辑

模型已经具备了海量的通用知识。

Skill 的价值在于提供“特有知识”和“特定约束”。冗余信息不仅浪费 Token，还会稀释核心指令的权重。

细化执行策略

(1)剔除常识：

• 不写：“PDF 是一种便携式文档格式，由 Adobe 发明...”

• 写：“使用 pypdf 库提取文本，注意处理多栏排版的换行符。”

(2)聚焦差异：只写那些模型“不知道”或者“容易做错”的事情。

• 业务特有规则：公司内部的项目命名规范、特殊的 API 鉴权头、特定的回复话术风格。

(3)高信噪比：每一行文字都必须有存在的理由。如果删掉某句话不影响任务执行，那就删掉它。

避坑指南

• 错误：把维基百科的定义或通用的编程教程复制到 Skill 里。

• 正确：直接给出针对当前任务的、经过优化的、最简练的操作步骤。

原则 7电商案例：订单发货通知短信生成 Skill（精简修正版）

核心：只写模型不知道、易出错、必须遵守的内容，不写常识、不重复基础规则、不堆砌冗余信息，避免浪费上下文

案例背景

电商订单发货后，需及时向用户发送通知短信，告知物流信息，提升用户体验。短信有严格的字数限制（70字内），且需符合平台规范（签名、退订提示），同时需区分虚拟商品与实物商品的差异，避免出错。模型已掌握短信的基础常识，无需重复说明，因此设计遵循最小够用原则的发货通知短信生成Skill。

案例核心逻辑

尼恩提示：此处省略 1000字，具体请参考 免费pdf。

原文3w字以上， 此文是精简版，完整版本，请参考 尼恩 免费百度网盘 免费pdf