给样本，比讲规则管用：我花了 20 多天，把 Hermes Agent 训练成能独立交付的 Dify 开发助手

给样本，比讲规则管用：我花了 20 多天，把 Hermes Agent 训练成能独立交付的 Dify 开发助手

作者前言：本文由我与 AI 协作完成，数据来源于 2026 年 7 月至 8 月的本地真实交付记录，可溯源、可验证。旨在分享 AI 工程化的落地经验。

摘要

在 Dify 应用开发过程中，传统的 Console API 调用方式常面临渲染异常、无法静态检查、编排能力受限等痛点。本文提出一种基于「样本驱动」的 AI 训练方法论，通过将 Hermes Agent 从「规则学习者」转变为「样本模仿者」，成功构建了从需求分析（TR1）到验收交付（TR4）的全链路自动化流水线。实战数据显示，该方案在 20 多天内交付了 69 个实验、87 份可运行 DSL、9 个插件及 4 套 MCP Server，全部通过 TR4 验收。本文将深入拆解训练五步法、契约预检机制及「错误单次消除」闭环，为 AI 辅助开发提供可复用的工程范本。

一、结论先行

过去一个多月，我用「一个人 + 一个 Hermes Agent（开源 AI Agent 框架）」的方式，从需求分析到测试验收，完整交付了六个批次的 Dify 应用：

69 个实验、87 份可运行的 DSL、14 个知识库种子、9 个插件、4 套 MCP Server 交付包，每个应用都带 TR4 验收报告，全部通过测试验证。

这篇文章不是「AI 很厉害」的演示，而是我踩过坑之后的完整复盘。核心方法论浓缩成一句话：

给样本，比讲规则管用。

说这句话之前，先交代一下背景——免得你以为这是「模型够聪明所以什么都行」。这套方法能跑通，靠的不是模型智商，而是一套训练它的工程纪律。下面从起点讲起。

二、起点：用官方 API 开发，撞了一周的墙

一开始我走的是最「正统」的路线——通过 Hermes Agent 调用官方 Console API（平台管理后台的接口）登录后直接操作。结果三个问题一直解决不了：

问题 1：UI 界面渲染问题无解。 API 方式创建的应用跑起来效果总是不对，反复出现渲染问题，你分不清是接口参数的问题还是平台本身的逻辑。

问题 2：本地没有文件。 应用只存在于平台上，本地不产出任何可检查的文件——没法静态检查（导入前预判报错）、没法批量生产（每个都要手工处理）、没法版本管理（无记录、无对比、无回滚）。

问题 3：编排能力受限。 复杂多节点的工作流在 API 方式下很难搭，天花板很低。

三个问题叠加，结论很清晰：API 方式适合「操作平台」，不适合「生产应用」。

当时我们的判断是「换个工具试试」——真正困住我们的不是工具，是思路：我们一直在「操作平台」，而不是「生产文件」。

三、转折：从「操作平台」到「生产文件」

Hermes Agent 卡在那里反复试、反复错。我盯着它报的错，突然冒出一个念头：

「这些工作流，能不能不通过 API 建，而是直接生成 yml 文件？让 Hermes Agent 来写？」

现在回头看很普通，但当时是个转折——我把思路从「操作平台」换成了「生产文件」。

换成 yml（DSL 文件，Dify 工作流的声明式描述）之后，之前的三个问题全部消失：

四、第一次尝试：Hermes Agent 写 DSL，漏洞百出

刚开始时，我让 Hermes Agent 写 yml。结果是：能写，但写得一塌糊涂。

• 节点不会用：工作流有哪些节点、各干什么，它根本不了解，经常用错类型
• 数据结构不懂：字段该是字符串还是数组分不清，该传 list 的地方传 string，下游一接就崩
• 前后变量对不上：上游定义的变量，下游引用一个根本不存在的名字
• 知识库不会联动：检索结果怎么进 LLM（大语言模型）上下文，它不知道
• 提示词里的变量引用不会写：写出来就是错的

说白了，当时它对 Dify 的理解停留在「听说过这个平台」的程度，写出来的 yml 十个里能跑通一个就算运气好。

换个人可能就放弃了——「Hermes Agent 写不了，还是自己来吧」。

五、顿悟：AI 的优势是模仿，不是创造

我做过软件开发，见过各种新人怎么上手新系统。新人最快的成长路径从来不是读文档，而是看老员工怎么写，照着模仿。

AI 也是一样——让它凭空设计 Dify 工作流，它当然不行；但让它模仿一份优秀的 DSL，它可能学得比人快。

而 Dify 上恰好有一堆权威样本：官方示例、社区分享、UI 里导出的成熟工作流。这些就是「老员工写好的代码」。

训练方法就此定下：别急着教它规则，先给它看样本，让它自己从样本里总结规律。

六、训练五步法：给样本 → 观察 → 筛选 → 沉淀

每轮训练都走固定流程：

第一步，给样本（Input）。 一次给四五个从 Dify UI 导出的权威 DSL 文件。这些是官方/社区的成熟设计，是权威格式。

第二步，观察学习（Observe）。 立规矩：拿到样本先观察，只看不操作，不许动手改数据。它要做的第一件事是把样本拆开、读懂、和已有知识对比、找出差异。

第三步，列学习点清单（List）。 把发现整理成清单，标价值等级——哪些是高价值认知、哪些是中价值、哪些是架构级的，一条条列清楚。

第四步，逐条筛选（Filter）。 清单交给我，我一条条过：这条收录，那条排除。铁律一条——只收录实测验证过的结论，它「以为」的不算，要有样本或实测支撑。

第五步，沉淀（Solidify）。 确认过的经验写进它的技能库（skill，程序性记忆），下次开工先加载。每学完一批样本，能力就永久提升一截。

这套流程的效果是惊人的：仅 2026-07-29 一天，就修正了它 12 处以上的错误认知——很多它之前「自信满满」的写法，跟权威样本一对，全是错的。

七、开窍的那一天

训练进行到某个阶段，我明显感觉到它不一样了。

以前它写 DSL 是「猜」——凭语感拼凑，错了再改，改完再错。学了那批优秀样本之后，它写 DSL 是「照着已知的正确范式填参数」——格式、结构、变量引用、知识库联动，一次到位。

那一天它产出的 yml，我第一次不用返工改十几处就能导入跑通。

那种感觉，就像带一个新人：前面两个月天天讲规则，他左耳进右耳出；后来你直接甩给他一摞老员工写的优秀代码让他自己读，读了一个月，他忽然开窍了——写出来的东西有模有样了。

八、升级：从「会写 DSL」到「会做完整工程」

会写 DSL 只是第一步。后来我把同样的训练思路用在更大的范围——从需求到交付的完整链路：

TR1 概念设计：教它先想清楚做什么再动手。立「文档先行」的规矩——没有概念设计，就没有后面的一切。

TR2 架构设计：立「唯一真相源」的纪律——变量名、字段名、Mock Schema（模拟数据结构）定了就不许改，禁止同义词替换。我前后拒绝过它 8 次路径占位符的错误写法，立场始终没变。命名是承诺，改了就是违约。

TR3 需求详细设计：教它把验收标准写进需求——「怎么算过」在设计阶段就定死，不许验收时现编。用例是需求的一部分，不是测试的附属品。

TR4 验收：投入最深的一环，四批实验每批暴露一个问题，总结成一条规则：

• 第一批：立六属性验收框架（功能/性能/安全/可靠性/压力/异常）
• 第二批：发现它用例设计方法不对，立「用例设计前置 Gate」——先读方法论再设计，不许凭感觉；用例基线化，基线冻结后严格执行
• 第三批：暴露 13 条用例缺陷，反推出「契约预检」5 项——逐字段核对、禁描述性输入、形态显式确认、可达性三问、判定字段绑定
• 第四批：教它判定词纪律——错误路径的判定词要写「错误显式呈现」，不写死「失败」形态，否则修复后判定就过时了

每一批的教训都沉淀成规则，下一批按新规则干。四批下来，它从「会写文件」长成了「会验收、会归因、会写报告」。

九、人到底在干什么？

所有人最关心的问题：Hermes Agent 都干了，人干嘛？

我的答案是：人做 Agent 做不了的决策。

1. 定方向：做什么应用、用什么节点、覆盖什么业务——方向决策是人的
2. 审文档：TR1-TR4 每份文档，人要过目、要评审、要拍板
3. 守底线：核心节点不可绕过替代；内容真实性不可妥协，数据不擅自模拟
4. 验收把关：用例基线化后严格执行，中途不因应用特殊性改用例；FAIL 先修应用，重跑确认归因

一句话：Agent 是执行者，人是所有者。 Agent 负责把事做对（效率），人负责决定做什么事（方向），以及出了问题谁来负责（责任）。

十、最有价值的部分：错误只发生一次

这套流程里最让我意外的是 Hermes Agent 的自我进化循环：每踩一个坑，就把经验沉淀进 skill（程序性记忆），下次遇到同类问题直接复用，不再踩。

真实例子：给用户消息里的手机号打码（138****5678），AI 写的脱敏正则表达式转义出了问题，手机号没被遮住、原样漏了出去——这是隐私泄露级别的错误。它把这个坑沉淀进 skill 之后，后续所有实验的脱敏都一次通过，再没犯过。类似的坑还有很多：插件执行参数覆盖、测试用例检查清单……每一个都只犯一次。

这套循环的积累效果是：同一个错误，在这个项目里只发生一次。

这跟传统开发区别很大。传统团队的错误会重复发生——换人、换项目、经验会流失；而 Agent 的「踩坑 → 沉淀 → 复用」是强制性的，它每次开工前都会先加载 skill。

十一、数据复盘（截至 2026-08）

配套产出：69 篇技术文章、每应用 1 份 TR4 报告、全部交付物同步 Gitee 公开仓库、沉淀 8+ 个可复用 skill（设计/开发/验证/验收闭环）。

十二、这套方法，任何人都能复制

回头看，整个训练过程本质上就四句话：

1. 给样本，比讲规则管用 —— AI 的优势是模仿，让它从优秀样本里自己总结规律，比讲一百条规则管用
2. 观察学习，只看不碰 —— 学习阶段不许动手，防止它拿猜测污染真实数据
3. 经验只进可信仓库 —— 逐条筛选它学到的内容，只收录实测验证过的，保证知识库干净
4. 错误只犯一次 —— 每个坑都沉淀成规则，下次开工先加载，同样的错不再犯

这套方法不挑工具、不挑平台。你手里任何一个 AI 助手，都可以用同样的路子，教成你专属的「开发 + 验证」搭档。

你缺的不是一个聪明的 AI，是一套训练它的方法。

附录：Hermes Agent Dify 开发训练核查清单

为了方便读者实践，我整理了以下核查清单，建议收藏备用：

• 样本准备：收集 4-6 份从 Dify UI 导出的权威 DSL（覆盖 Loop、Agent、HTTP 等节点类型）。
• 静态检查：配置 DSL 静态检查脚本，确保 yaml 格式及基础字段合规。
• 纪律确立：
  • 观察期不修改：学习阶段禁止 AI 随意篡改样本数据。
  • TR2 唯一真相源：变量名、字段名一经定义禁止同义词替换。
  • 契约预检：生成前强制运行「逐字段核对、形态确认、可达性三问、判定字段绑定」等检查。
• Skill 沉淀：建立技能文件记录「踩坑记录」和「修正规则」，下次开工先加载。
• 版本管理：所有 DSL 及 TR 文档纳入 Git 管理，便于追溯。

讨论：你在 AI 辅助开发 Dify 工作流时遇到过哪些「玄学」Bug？或者你认为在 AI 工程化中，还有哪些规则是必须坚守的？欢迎在评论区分享你的见解。

声明：本文由作者与 AI 协作完成。训练过程为真实经历，成果数据来自本地交付记录（2026-07 至 2026-08），可溯源可验证。

#Dify #AI Agent #LLM应用开发 #Prompt工程 #人工智能 #自动化