DeepSeek V4 调用 Skill 不听话？别猜了，按这套流程查

你有没有遇到这种离谱场景：

• 你明明写了“调用 Skill：读取 PPT 模板”。
• 模型点头说懂了。
• 结果它不调工具，自己编了个“网页版本 PPT”。

我这边测 DeepSeek V4 时，就踩到了这个坑：指令遵循差、工具调用弱、Skill 流程跑偏。尤其是拿我自己的 PPT Skills 测试，按理说应该去读模板文件，它却直接绕开“读模板”这一步，自行实现了一套页面。

别急，下面给你一套“Skill 体检流程”。照着跑，你能很快判断：是模型当前版本的问题、平台发布配置的问题，还是你的 Skill 协议/提示词让模型钻了空子。

1）先把“Skill 调用失败”拆开看：到底失败在哪里？

工具调用翻车一般不是一个点，常见有 4 种：

• 根本不发起工具调用：嘴上说要用，实际纯文本糊你。
• 工具调用格式不对：参数缺字段、类型错、JSON 乱写。
• 调用了但不等待结果：工具还没回，它先自作主张输出成品。
• 拿到结果也不用：工具返回了模板结构，它当没看见，继续脑补。

你描述的“读模板失败，自己随便实现网页”，通常落在后两类：

• 没等待工具回调
• 或者拿到回调也不信，继续编

这两类问题，靠“再强调一遍”解决不了，要靠约束 + 结构化输出 + 失败兜底。

2）做一个最小可复现测试：把 PPT Skills 拆成两段

别一上来就让模型“读模板→生成内容→排版→导出”。链路太长，任何一步不稳都会被掩盖。

把 Skill 拆成两段来测：

A. 只测“能不能读模板”

目标：模型只做一件事——调用工具读取模板，然后把模板信息原样复述。

测试 Prompt（直接抄）

你必须调用工具 ppt.read_template 读取模板。禁止自行假设模板内容。
调用工具后，把返回结果中的 slides 数量、每页占位符列表逐条输出。
如果工具调用失败，你只输出 TEMPLATE_READ_FAILED，不要输出任何 PPT/网页方案。

如果这一步都不稳定，后面所有“自动生成 PPT”都是空谈。

B. 再测“读到模板后能不能按占位符填充”

目标：它能严格按占位符填内容，不新增、不乱改。

你已经拿到了模板结构。你只能在占位符中填文字，不能新增元素，不能改版式。输出严格按 fill_plan JSON。

你会发现：很多模型在“生成内容”很强，在“遵守模板约束”很弱。PPT 技能就是典型约束场景。

3）把工具调用变成“强制动作”，别给模型留发挥空间

模型为什么会自己做网页？因为它在潜意识里认为：给你一个看起来像结果的东西，也算完成任务。

想治这个毛病，靠三件套：

3.1 明确“必须调用”+ 明确“禁止替代方案”

提示词里别写“请尽量调用”，要写得像合同：

• 必须调用指定工具
• 工具失败就停止
• 禁止使用替代实现（比如 HTML 网页）

示例：

不允许用 HTML/CSS/网页模拟 PPT。
不允许臆造模板结构。
不调用工具就视为任务失败。

3.2 给它一个“失败出口”

很多模型不愿意承认失败，于是开始硬编。

你给它一句：

• “失败就输出 TEMPLATE_READ_FAILED”

它就不会为了“交差”去瞎造。

3.3 输出必须是机器可校验的结构

让模型输出结构化 JSON，比输出自然语言更能约束它。

比如你要求：

{
  "tool": "ppt.read_template",
  "status": "need_call"
}

工具返回后，再让它输出：

{
  "status": "template_loaded",
  "slides": 12,
  "placeholders": {
    "1": ["title", "subtitle"],
    "2": ["section_title", "bullets"]
  }
}

这能逼着它“承认自己有没有读到模板”。

4）检查你的 Skill 定义：参数太自由，模型就会乱跑

工具调用差，有时不是模型傻，是你给的接口太开放。

你拿 PPT Skills 举例，强烈建议你过一遍这几个点：

4.1 工具名称要直白

• ✅ ppt.read_template
• ✅ ppt.fill_placeholders
• ✅ ppt.export
• ❌ process、handle、do_task 这种泛化名字

名字越具体，模型越不敢乱脑补。

4.2 Schema 要“严格到讨厌”

如果你的 schema 允许 string | any、允许空字段，模型会用最省事的方式糊弄。

建议：

• 必填字段都设 required
• 枚举值用 enum
• 不要让它自由写一坨“content”大字符串

4.3 返回值也要可控

ppt.read_template 返回的结构越明确，模型越能对齐。

推荐返回：

• slide 数量
• 每页占位符 id、类型、约束（字数、是否必填）
• 不能编辑的区域标记（locked）

模型读到这些，就没借口“我不知道模板啥样”。

5）加一层“工具调用守门员”：别把命交给一次对话

如果你在做产品，别指望模型每次都乖。

实战里通常会加一层守门逻辑：

• 模型没发起 ppt.read_template → 直接拒绝继续，让它重试
• 工具调用参数校验失败 → 返回结构化错误，让它按 schema 重发
• 工具成功但模型没引用返回值 → 强制它输出引用字段（比如 slide 数量）

你可以把规则写成三条简单的“网关策略”：

• 无工具调用，不出结果
• 参数不合规，不执行工具
• 结果不引用，不进入下一步

这能把“不稳定”硬生生拽回“可控”。

6）一份可直接用的 PPT Skills 测试脚本（对话版）

你可以拿这段当回归测试用例，每次换模型/换版本都跑一遍：

用例 1：模板读取

用户：

你必须调用 ppt.read_template。模板路径：/templates/pitchdeck.pptx。
读取后只输出：slide 总数、每页占位符 id 列表。
不允许生成 PPT 内容。

合格标准：

• 有工具调用
• 输出包含 slide 数量
• 不出现任何“生成的文案/网页实现”

用例 2：占位符填充

用户：

我会给你模板返回的 placeholders。你只能填这些 placeholders。输出 fill_plan JSON。
如果发现某页缺占位符，输出 MISSING_PLACEHOLDER。

合格标准：

• 只填已有 placeholder
• 输出是可解析 JSON
• 缺占位符时停止，不硬编

用例 3：导出

用户：

调用 ppt.export，格式 pptx。成功后只返回文件 id。失败返回错误码。

合格标准：

• 不输出“下载链接/网页预览”之类的替代品

7）避坑清单：这些写法最容易把模型带沟里 😅

• ❌ “如果不能读取模板，就按你的理解生成一个类似的 PPT”
  你等于告诉它：可以瞎编。

• ❌ “尽量调用工具”
  模型会选择更省事的纯文本。

• ❌ 工具返回一大坨自然语言描述
  模型会当成参考材料，而不是结构化事实。

• ❌ 允许模型自由扩展版式
  它会为了“看起来完成了”而乱加元素。

• ✅ 明确失败出口：失败就输出固定标记

• ✅ 约束输出：JSON、枚举、必填字段

• ✅ 每一步都让它引用工具返回的关键字段

8）如果你要继续用 DeepSeek V4：两条现实建议

• 把 Skill 设计得更“硬”：强 schema、强校验、强兜底。别指望模型自觉。
• 准备一个备用模型/备用路径：遇到工具调用连续失败，自动切换到更稳的 function calling 模型，或者走“人类确认一步”的半自动流程。

你做的是生产力工具，不是文学创作。用户想要的是“模板能读、PPT 能出”，不是模型的即兴表演。

如果你愿意，把你的 ppt.read_template / ppt.fill_placeholders 的 schema（工具名、参数、返回值示例）贴出来。我可以按“最少改动”给你一版更抗跑偏的定义，让模型更难装懂。