EPF验证器Skill：一键校验 1С 外部处理 XML 结构，构建前先把错误找出来
- 它解决什么问题：手写或脚本生成的 1С 外部处理（EPF）XML 一旦结构出错，往往要到配置器构建或运行时才报错，排查成本高。这个技能把「事后调试」提前成「事前体检」。
- 它做什么：对 EPF 的 XML 源文件做 10 类结构检查，覆盖根结构、InternalInfo、属性、ChildObjects、交叉引用、表格部分、名称唯一性、表单与模板文件是否存在等，并给出
[OK]/ 错误 / 警告的逐条结果。 - 怎么用：一条斜杠命令
/epf-validate <ObjectPath>，或直接调用随技能附带的 PowerShell 脚本；支持MaxErrors限制错误数量、OutFile把结果落盘。 - 适合谁：用脚本化/命令行方式开发 1С 外部处理与外部报告的开发者、实施顾问，以及需要把结构校验接进 AI 编码工作流（如 Claude Code）的团队。
- 顺带一提：该脚本也能识别外部报告（ERF），会根据元素类型自动判断。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能中文名：EPF验证器Skill 技能英文名：epf-validate 技能 ID：11953
它瞄准的是 1С 平台外部处理（External Data Processor，EPF）开发中的一个典型痛点：EPF 的源文件本质上是结构相当复杂的 XML，包含 MetaDataObject/ExternalDataProcessor 根节点、InternalInfo、属性定义、ChildObjects、表格部分、表单与模板引用等。只要其中某一处 UUID、名称、顺序或引用关系写错，配置器（Конфигуратор）在构建或打开时就会抛出让人一头雾水的错误。人工逐节点比对既慢又容易漏，而 epf-validate 就是把这套「结构体检」固化成一条命令。
一键安装的思路与步骤
AI 技能（Skill）的安装本质上是「把技能目录放到约定位置，让 AI 助手能发现并调用它」。从技能给出的调用命令可以推断，它的安装位置是项目内的 .claude/skills/epf-validate/ 目录（对应脚本路径 .claude/skills/epf-validate/scripts/epf-validate.ps1）。
- 确认前提：需要 Windows 环境下的 PowerShell（脚本以
powershell.exe -NoProfile -File方式执行），并已安装支持 Skill 机制的 AI 编码助手客户端；具体版本要求以官方说明为准。 - 获取技能包：通过技能市场中检索技能名
epf-validate或技能 ID11953获取，也可由团队直接提供技能目录；获取渠道以官方说明为准。 - 放入约定目录：将
epf-validate整个目录放到项目的.claude/skills/下，确保scripts/epf-validate.ps1存在。 - 验证是否生效：在 AI 助手的对话里输入
/epf-validate，如果它能识别出该斜杠命令并提示缺少ObjectPath参数，说明技能已被正确加载；也可以直接用一个已知正常的 EPF XML 跑一次，看到=== 结果: 0 错误, 0 警告 ===即视为安装成功。 - 注意：本文未提供官方下载链接与收费信息，安装入口、授权与价格请以官方说明为准。
安装完成后，你获得的不是一份「文档」，而是一个随时可调用的检查器——这正是「一键安装 AI 技能提升开发效率」的核心：把重复性的结构校验交给工具，把判断力留给人和 AI。
2. 该技能的主要功能和特点
- 十类结构检查，逐条给结论：根结构（MetaDataObject/ExternalDataProcessor）、InternalInfo（ClassId、ContainedObject、GeneratedType）、属性（Name 标识符、Synonym）、ChildObjects（允许的类型与顺序）、交叉引用（DefaultForm → Form、AuxiliaryForm）、属性级检查（UUID、Name、Type）、表格部分（UUID、Name、GeneratedType、Attributes）、名称唯一性（属性、表格部分、表单、模板、命令）、文件存在性（表单
.xml+Ext/Form.xml、模板）、表单描述符（根结构、uuid、Name、FormType）。 - 区分严重程度：结果分为「错误」与「警告」两级，错误会直接影响构建，警告则是结构性隐患，便于分级处理。
- 路径自动解析：
ObjectPath既可以指向根 XML 文件，也可以指向处理目录——若给的是目录，脚本会自动寻找<目录名>/<目录名>.xml，减少手写路径的成本。 - 错误数量可截断：
-MaxErrors（默认 30）控制在第 N 个错误后停止，避免一个坏文件刷屏。 - 结果可落盘：
-OutFile将报告写入文件（UTF-8 BOM 编码），方便归档、贴进工单或交给 AI 继续分析。 - 返回码可编程：
0表示全部通过，1表示存在错误，天然适配脚本与流水线判断。 - 自动兼容 ERF：不仅验证 EPF，对同类结构的外部报告（ERF）也会根据元素类型自动识别。
- 和普通工具比强在哪：通用 XML 校验器只能告诉你「XML 语法对不对」，却不懂 1С 的元数据语义——比如
DefaultForm指向的表单是否真的存在、名称在属性/表单/模板之间是否重复。epf-validate 检查的是领域规则，而不是单纯的良构性。
3. 如何使用该技能？
方式一：斜杠命令
/epf-validate <ObjectPath>
示例：
/epf-validate src/我的处理.xml
方式二：直接调用脚本
powershell.exe -NoProfile -File .claude/skills/epf-validate/scripts/epf-validate.ps1 -ObjectPath "<路径>"
带参数示例（限制 10 个错误并输出到文件）：
powershell.exe -NoProfile -File .claude/skills/epf-validate/scripts/epf-validate.ps1 -ObjectPath "src/我的处理.xml" -MaxErrors 10 -OutFile "validate-report.txt"
参数说明
| 参数 | 必填 | 默认值 | 说明 |
|---|---|---|---|
| ObjectPath | 是 | — | 指向根 XML 或处理目录的路径 |
| MaxErrors | 否 | 30 | 在第 N 个错误后停止 |
| OutFile | 否 | — | 将结果写入文件（UTF-8 BOM） |
分步骤使用指南
- 定位对象：确认要检查的 EPF 根 XML 路径，例如
src/我的处理.xml；若只想给目录，确保目录名与 XML 同名。 - 运行校验：执行
/epf-validate src/我的处理.xml，AI 助手会调用脚本并回传结果。 - 读结果：输出形如
=== 验证: EPF.我的处理 ===
[OK] 1. 根结构: MetaDataObject/ExternalDataProcessor, 版本 2.17
[OK] 2. InternalInfo: ClassId 正确, 1 GeneratedType
...
=== 结果: 0 错误, 0 警告 ===
每条前面标注 [OK] 或错误/警告，编号对应十类检查。
- 按编号修问题：例如第 5 项报错，就去核对
DefaultForm是否指向真实存在的表单名；第 8 项报错，通常是属性、表格部分、表单、模板、命令之间出现了重名。 - 复检：修完再次运行，直到
0 错误。 - 接入创建—校验—构建闭环：技能自身给出的推荐顺序是
/epf-init <名称> — 创建处理
/epf-validate src/<名称>.xml — 检查结果
/epf-build <名称> — 构建 EPF
- 接入自动化：在脚本或流水线中依返回码判断（0 通过 / 1 有错误），失败即阻断后续构建。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| epf-validate（本技能） | 面向 AI 助手工作流的 EPF/ERF 结构校验器 | 10 类结构检查、错误分级、名称唯一性、引用与文件存在性校验、返回码 | 需 PowerShell 与支持 Skill 的 AI 客户端，放入 .claude/skills/ 即可 |
脚本化生成 EPF 后自查、构建前排错、CI 前置卡点 | 优势：语义级检查、输出可读、可编程；不足：仅做静态结构校验，不做业务逻辑或运行时验证 |
| 1С 配置器（Конфигуратор） | 官方开发环境 | 打开/构建 EPF、语法与结构报错、设计器调试 | 需安装 1С 平台，人工图形操作 | 正式开发、可视化设计与调试 | 优势：权威、覆盖面广；不足：报错信息偏底层，人工反复操作成本高，难以批量自动化 |
| 通用 XML 校验工具（如 xmllint / XSD 校验） | 通用 XML 良构性与模式校验 | 标签闭合、编码、Schema 校验 | 命令行工具，门槛中等 | 任何 XML 文件的语法检查 | 优势：通用、轻量；不足：不理解 1С 元数据语义，无法发现「表单引用失效」「名称重复」等领域错误 |
| 通用 AI 编码助手人工比对 | 让大模型直接阅读 XML 并判断 | 可解释、可给修改建议 | 无需安装，直接对话 | 小文件、探索性排查 | 优势：灵活；不足：结果不稳定、易漏项、无法保证每次执行同样的检查清单，大文件容易超出上下文 |
可以看到，epf-validate 的差异化不在「更全能的开发环境」，而在「把领域检查清单固化成可重复执行的命令」，特别适合与 AI 助手和自动化流程配合。
5. 该技能的典型应用场景与实际体验情况
场景一：脚本或 AI 生成 EPF 后的第一道关卡
角色：1С 开发者。痛点：用模板或脚本生成的处理目录，ChildObjects 顺序、属性 UUID、表单文件路径很容易出错，直接构建只能看到一句笼统的报错。使用方式：生成完立刻 /epf-validate src/<名称>.xml，按编号逐项修。
场景二：手动编辑 XML 之后的构建前自查
角色：需要批量改元数据的实施顾问。痛点：批量替换名称后可能产生重名，或把 DefaultForm 指错。使用方式：编辑后跑一次校验，第 8 项（名称唯一性）和第 5 项（交叉引用）能直接暴露问题，避免把错误带进构建环节。
场景三：新增表单或模板后的联动检查
角色：负责界面层的开发者。痛点：新增表单时忘了同步生成 Ext/Form.xml，或模板文件没放到位，配置器打开时才报错。使用方式：加完表单就跑一次，第 9 项「文件存在性」和第 10 项「表单描述符」会指明缺什么。
场景四：调试构建失败原因
角色：接手他人项目的工程师。痛点：项目能打开但构建失败，错误信息指向不明。使用方式：先用 -MaxErrors 限定错误数量、-OutFile 导出完整报告，再交给 AI 助手基于报告做归因分析。
实际体验情况：上手难度低，核心只有一个必填参数，命令形式直观；输出为逐条编号的检查清单，比裸读 XML 报错更容易定位问题，返回码也让接入脚本变得简单。需要注意几点：一是脚本依赖 PowerShell，非 Windows 环境需自行确认可行性（以官方说明为准）；二是它只做静态结构校验，业务逻辑和运行时行为仍需构建与实际运行验证；三是警告项不阻断构建，但建议一并处理，避免积累成隐患。
6. 该技能能为用户带来的价值
- 把排错成本前移：原本要在配置器里反复打开、构建、看报错才能发现的问题，现在在命令行阶段就能拿到编号化的结论，减少来回切换工具的次数。
- 降低 1С 元数据的门槛：XML 里的 UUID、GeneratedType、ChildObjects 顺序等概念对新手并不友好，技能把「该检查什么」固化成清单，等于随附一份可执行的规范。
- 结果可复用、可归档：
OutFile输出 UTF-8 BOM 报告，便于贴进工单、写进提交说明或交给 AI 继续分析。 - 天然适配自动化：
0/1返回码让「校验不通过就阻断构建」成为一条简单的判断语句，长期看能显著减少带病构建进入测试环节的概率。 - 与 AI 工作流协同：与
/epf-init、/epf-build组成「创建 → 校验 → 构建」的闭环，把 AI 编码助手从「会写代码」推进到「写得对、可验证」。
7. 常见问题 FAQ
Q1：怎么安装这个技能？
A：把 epf-validate 技能目录放到项目的 .claude/skills/ 下，确保 scripts/epf-validate.ps1 存在，然后在 AI 助手中输入 /epf-validate 验证是否被识别。具体获取渠道与版本要求以官方说明为准。
Q2：收费吗？ A：技能详情中未提及价格与授权方式，请以官方说明为准。技能本身是一个 PowerShell 脚本，运行依赖你本地的 PowerShell 环境。
Q3：它和直接看配置器的报错有什么区别？ A：配置器是权威的构建与运行环境，但报错信息偏底层；epf-validate 提供的是面向结构规则的分项清单（根结构、InternalInfo、属性、ChildObjects、交叉引用、名称唯一性、文件存在性、表单描述符等），更适合快速定位「哪一类问题」。两者是互补关系，不建议互相替代。
Q4：它只支持 EPF 吗？
A：不止。脚本会根据元素类型自动判断，同样适用于外部报告（ERF）；技能详情中也提示可参见 /erf-validate。
Q5：适合谁用？和竞品怎么选？ A：适合用脚本化方式开发 1С 外部处理/报告的开发者、需要在提交前自查的实施顾问，以及希望把校验接进 AI 工作流或流水线的团队。如果你需要可视化设计与正式构建，用 1С 配置器；如果你只想确认 XML 语法合法，用通用 XML 工具；如果你要检查「1С 元数据层面的结构正确性」并希望结果可编程，用 epf-validate 更合适。