你提出的问题非常典型，也是当前 大模型在复杂工作流（Workflow）编排中面临的核心挑战之一。我们来深入分析：为什么大模型在执行包含多 step、依赖 skill 调度的流程时，会“无视”技能约束、跳过指定 Skill、或错误地自行推断逻辑？

🔍 一、根本原因分析

尽管你在 skill 中明确写了：

“必须通过阅读并使用约束的 Skill 完成任务，禁止用 summary / 历史上下文替代 read skill 操作”

但大模型仍然可能不遵循这些指令。这背后涉及多个层面的因素：

✅ 1. 大模型的本质是“预测”而非“严格执行”

• 大模型本质是一个基于概率的语言生成器。
• 它的目标是“生成最合理的输出”，而不是“严格遵守规则”。
• 当它感知到“我已经知道该做什么”时，就会倾向于 跳过显式调用步骤，直接生成结果 —— 即使这违反了你的 workflow 约束。

📌 举例：
在 Stage5 编码开发阶段，系统要求你先读取 references/stages/stage-5.md 并调用 code-generation-skill，但模型看到“我之前已经分析过需求，也理解技术方案”，于是直接写代码，跳过读文档和调用 skill 步骤。

✅ 这不是“错误”，而是模型对“效率”的自然偏好。

✅ 2. 缺乏“执行上下文”与“状态感知”能力

• 大模型没有真正的“状态机”概念。
• 它无法真正“记住”自己是否已经完成了某个 stage，也无法验证“是否真的调用了某个 skill”。
• 所以即使你写了“声明本阶段使用的 Skill”，模型也可能只是口头承诺，而不真正触发。

❗ 问题：你说“调用 skill”，但它可能只是说一句：“我将使用 code-generation-skill”，而实际上根本没有发起调用。

✅ 3. Skill 调用机制未被明确定义或绑定

• 如果 skill 的调用方式模糊（如只是文字描述），模型就无法准确识别“如何调用”。
• 比如：

  本阶段使用的 Skill：/skills/code-generation-skill
  

  但这不是一个可执行命令，只是一个字符串。大模型不知道这个路径对应哪个 API、参数格式、返回结构。

⚠️ 模型只能“理解”文本，不能“执行”动作，除非有明确的工具调用接口（Tool Calling）支持。

✅ 4. 用户输入 + 上下文太强，导致模型“过度自信”

• 如果用户输入非常清晰，且历史对话中已有足够信息，模型容易产生“我已经懂了”的错觉。
• 它会认为：“不需要再读文档、不需要再调 skill，我直接输出就行。”
• 尤其是在 Stage3（需求分析）、Stage4（技术设计）这种偏抽象的任务中，更容易发生。

💡 类比：一个程序员看一眼 PRD 就能猜出实现方式，但系统要求他必须走完整流程。

✅ 5. 缺乏强制性控制机制（Guardrails）

• 目前大多数 LLM 应用缺少“强制检查点”机制。
• 没有机制去验证：
  • 是否真的读了文档？
  • 是否真的调用了 skill？
  • 有没有输出正确的 Skill 路径？
• 因此，模型可以“假装完成”。

🛠️ 二、解决方案建议（分层应对）

要让大模型真正遵循 workflow 约束，必须从 架构设计 + 工具调用 + 控制逻辑 三方面入手。

✅ 方案一：引入 Tool Calling + 显式 API 调用

不要只靠“文字描述 skill”，而是定义真实的 工具接口（Tool Schema）。

{
  "name": "code_generation_skill",
  "description": "根据技术方案生成前端代码",
  "parameters": {
    "type": "object",
    "properties": {
      "tech_plan": { "type": "string", "description": "技术方案内容" },
      "framework": { "type": "string", "enum": ["React", "Vue", "DUO", "MRN"] }
    },
    "required": ["tech_plan"]
  }
}

然后在 workflow 阶段中强制要求：

必须调用 code_generation_skill 工具，并传入正确参数。

➡️ 这样模型无法“口头上说”用了，必须真实触发。

✅ 方案二：增加 执行确认环节（Checkpoints）

每一步都设置“执行确认”节点：

[Stage5] 编码开发

1. 读取参考文档：references/stages/stage-5.md ✅
2. 调用 Skill：code-generation-skill ✅
   - 调用时间：2025-04-05 10:00:00
   - 输入参数：{"tech_plan": "...", "framework": "React"}
   - 返回结果：[成功] 生成了组件文件
3. 输出代码产物：src/components/Button.jsx ✅
4. 声明依赖：本阶段使用的 Skill：/skills/code-generation-skill ✅

👉 只有所有 ✅ 都满足，才能进入下一阶段。

这相当于把“流程合规性”变成“可验证的事实”。

✅ 方案三：使用 状态管理 + 流程引擎（Workflow Engine）

不要完全依赖 LLM 来控制流程，而是引入轻量级流程引擎（如 Temporal、Airflow、LangGraph）：

✅ 例如：

• 进入 Stage5 时，系统自动加载 stage-5.md 并调用 code-generation-skill
• 只有收到成功响应后，才允许进入 Stage6

✅ 方案四：强化提示词（Prompt Engineering）—— 加强“纪律性”表达

修改提示词风格，加入更强的“禁止项”和“后果说明”：

⚠️ 重要警告：
- 严禁跳过任何阶段或绕过 skill 调用！
- 严禁仅凭记忆或上下文生成内容！
- 严禁在未读取 reference 文件的情况下开始执行！

❌ 错误行为示例：
- “根据需求，我直接写代码”
- “我已经看过技术方案，不用再调 skill”

✅ 正确行为必须包括：
1. 明确写出：已读取 [xxx.md]
2. 明确写出：调用的 Skill 路径：/skills/xxx
3. 等待系统返回结果后再推进下一步

使用“警告+示例对比”能显著提升模型对“合规性”的重视。

✅ 方案五：引入 人工审核 + 自动化校验（Audit Trail）

为每个 workflow 生成一份审计日志：

{
  "workflow_id": "fe-rd-agent-20250405",
  "stage": "Stage5",
  "action": "code_generation",
  "skill_used": "/skills/code-generation-skill",
  "document_read": "references/stages/stage-5.md",
  "timestamp": "2025-04-05T10:00:00Z",
  "verified": true,
  "result": "success"
}

后续可用自动化脚本校验：是否所有 stage 都调用了指定 skill？是否读了文档？

🧩 总结：为什么大模型不遵循 skill 约束？

✅ 最佳实践建议（推荐组合）

✅ 推荐架构：“流程引擎 + Tool Calling + 状态校验 + 强化提示”

📌 结语

大模型不是“听话的机器人”，而是“聪明的助手”。
要让它“听话”，就必须：

1. 把“流程”变成“可执行的指令”；
2. 把“约束”变成“不可绕过的检查点”；
3. 把“信任”换成“验证”。

只有这样，才能真正实现像你设想的那样：全流程闭环、技能调度精准、拒绝随意发挥。

如果你需要，我可以帮你把这套 fe-rd-agent-workflow 改造成一个 带 Tool Calling + 状态管理 + 校验机制的可执行流程模板。欢迎继续提问！