下面这个失败，跟智能程度毫无关系。
让一个根基扎实的 AI 助手在 SkySpark 中创建一条 Spark 规则。它懂 Axon，它索引了函数库，它给你写出干净、语法完全有效的代码——然后交回一条记录。
而一条能用的 Spark 规则需要两条：一条承载检测逻辑的 func 记录，以及一条配置规则如何生效、在何处生效的 sparkRule 记录。二者必须彼此吻合。漏掉第二条不会报任何错——你只是拥有了一条永远不会触发的规则，而你以为那个站点正在被监控。
再多的语法知识也防不住这一点。这不是语言问题，这是流程问题，而流程正是我们一直遗漏的那一半。
工作流究竟是什么
工作流就是一个 markdown 文件。全部诀窍就在于此。
它带着一小段 frontmatter 以便被编目，然后用普通的散文和表格描述如何把一件事做对：
---
title: Create Spark Rule
description: Step-by-step guide for creating a Spark rule with func and sparkRule records
category: fault-detection
tags: [spark, rule, fault, automation]
version: 1.0
---
两个 MCP 服务器在启动时都会加载各自 workflows/ 目录下的每一个 .md，并通过 Model Context Protocol 以 workflow:// URI 下的可读资源形式暴露出来。助手不需要别人告诉它这些东西存在——它可以列出它们、搜索它们，并在任务进行中按需拉取全文。
Fantom MCP Server 还会监视该目录。放入一个新文件，它立刻可用，无需重新构建或重启。
今天的两份目录
Fantom MCP Server —— 13 个工作流，覆盖构建与维护这一侧：
ai-coding-loop · api-migration-reference · connector-workflow · create-pod · create-skyspark-extension · explore-code-relations · haxall-basics · haxall-coding-standards · haxall-methods-workflow · skyspark-4x-migration · unit-testing · use-fanr · xeto-spec-guide
Axon MCP Server —— 10 个工作流，覆盖分析与运维这一侧：
app-creation · axon-func-update · axon-lang-information · curRule-computed-points · html-email-skyspark · job-status-check · recform-template-design · spark-rule-creation · task-subscriber-permissions · visualytik-mcp-authoring
二十三个文件。这就是当下这套工具链被编码下来的全部流程性记忆——而它远远不够。
好的工作流长什么样
最具代表性的例子是 ai-coding-loop，它教助手如何修改代码，而不让底下的索引腐坏。该服务器的结构化记忆覆盖 240+ 个项目和 156K+ 个函数；一次未重建索引的编辑，会让此后的每一次搜索都出现微妙的错误。
整个循环所系于的那条规则只有一句话：每次修改代码后，对你动过的路径调用 reindexChangedFiles。 重新解析、重建图的节点与边、重新嵌入。跳过它，下一次语义搜索就会基于一个已经不存在的代码库给出答案。
请注意这个工作流不是什么。它不是某个 API 的文档——工具描述已经做了那件事。它是操作顺序，是那种一旦有人告诉你就显而易见、没人告诉你就完全看不见的东西。
那个文件里还有一句值得偷学的话：“已于 2026-06-10 针对 sedonaWebEditor 实地验证。” 带验证日期的工作流，你可以信任它，或者让它退役。没有日期的，只是传闻。
为什么这才是瓶颈
直觉会认为更强的模型能弥合这个差距。它们弥合不了，而且值得把原因说清楚。
模型在这个领域的弱项不是推理，也越来越不是语法——有根基的索引可以处理语法。弱项在于：楼宇自动化中的流程性知识，从来没有以任何东西可执行的形式被写下来。 它存在于全球几千名从业者的脑子里，靠师徒相传：你之所以知道一条 Spark 规则需要两条记录，是因为一位资深工程师看着你交付了一条从不触发的规则。
这种传递机制无法规模化，也经不起人员跳槽。每一家集成商都在各自独立地重新推导同样的流程。同一个下午，在十几家公司里被并行地浪费掉。
工作流就是那个师徒传授的瞬间，写下一次，此后被每个助手在每个项目上执行。
为什么这件事必须交给社区
下面是我一个人做不到的部分，任何一家公司也做不到。
掌握这些知识的人，大多不写服务器。 知道屋顶机组正确调试顺序的那位工程师，或者知道哪种 curRule 模式在计算点位上真正站得住脚的那位，是搞控制的人——不是 TypeScript 开发者。如果贡献意味着要向一个索引引擎提交 pull request，他们的知识就会留在原地。
但并非如此。一个工作流就是一个 markdown 文件。frontmatter、一个标题、按顺序排列的步骤、以及那些坑。只要你能把自己的做法写下来，你就能贡献一个。
这笔账荒谬地对我们有利。 写一个工作流需要一个下午。此后，它为每一位本来要重新推导它的工程师省下一个下午——跨越每一家公司，永久有效。在软件领域，杠杆如此不对称的地方并不多。
而且这个领域太小，经不起分裂。 楼宇自动化不是 Web 开发；不会有一支贡献者大军到来。如果懂 Sedona、Haxall、Axon 和 Xeto 的人各自把流程藏着，那么所有人都要一遍遍交同样的学费。二十三个文件，是我们寥寥数人凑出来的。两百个经过评审并标注日期的文件，会改变一个新人在头一周里能做到什么。
诚实地谈风险
工作流目录并不会自动变好，假装不是这样，只会让这件事注定失败。
错误的工作流比没有工作流更糟。 助手会自信地照做，然后产出一个自信的错误结果。缺失流程至少会带来犹豫；糟糕的流程带来的是糟糕的调试交付。在这里，评审比在大多数文档中都更重要。
工作流会悄无声息地过时。 SkySpark 4.0 改变了扩展格式，一夜之间让若干真实流程失效。工作流自己不会察觉自己老了。因此 frontmatter 里要有 version:，更好的是写明验证日期以及最后一次验证所依据的项目。
范围要克制。 一个试图解释一切的工作流，什么也教不会。好的工作流只做一件事——创建这个东西、迁移那个东西、保持索引新鲜。
这些都不构成反对这条路线的理由。它们只是说明：评审、标注日期和重新验证，应当从一开始就是其中的一部分，而不是等到两百个文件时再硬加上去。
一起来建这份目录
两个服务器都是 source-available，而工作流目录是最容易上手的起点：
- FantomMcpServer ——
workflows/，13 个文件，构建与维护 - AxonMcpServer ——
workflows/，10 个文件，分析与运维
缺口并不隐晦。没有关于 BACnet 点位命名规范的工作流，没有关于冷水机房序列调试的工作流，也没有关于每个项目都要重新争论一遍的那五六个 Haystack 标签决策的工作流。
如果你懂其中某个流程——是真的懂，包括它会在哪里出错——那就是一个工作流，而此刻还没有人把它写下来。
把它带到**论坛**（工作组在那里协调），或者向任一仓库提交 pull request。门槛之所以只是一个 markdown 文件，是有意为之。
关于这些服务器如何工作的更多内容：Axon MCP Server · 跨语言代码智能 · Sidecar 集群与 RLM。