有一类工作，很多人都有，但很少有人想到去自动化它。
特征很明显：重复、枯燥、规则清晰。你知道下一步该干什么，上一步该看哪里，输出格式长什么样。这种工作，理论上不需要判断力，只需要耐心和细心。
但正因为"有规则可循"，它消耗的不是脑力，是时间。是一种低效但又很难说出哪里不对的时间消耗。
做跨境支付的 @zstmfhy 就是这样。
他每隔一段时间就要处理一件事：解析各国 HSBC 官方 PDF 文档，提取字段规则，生成标准化的付款检查 Excel 表格。
任务说起来很简单，做起来不是。
HSBC 的 pain.001.001.03 报文，每个国家都有一套文档。一个国家的 PDF 动辄 50 到 100 页，字段四五十个，每个字段对应三到五种支付方式，每种支付方式下的规则又各不相同。
举个字段——"收款方地址"：
就这一个字段，三种支付方式，三套规则，还要对上 XML 路径和 Excel 行号。
这样的字段，有 52 个。
需要处理的国家，十几个。
保守估计，一个国家 2 天，十几个国家下来——至少 20 天。全是体力活，重复、枯燥，还容易出错，因为人只要疲了就会漏看一行。
他的第一反应不是"怎么快一点做完"，而是"这件事能不能让 AI 学会"。
他花了半天，做了一个 Skill
思路很直接：与其每次手把手教 AI 怎么解析文档，不如把业务知识固化下来。让 AI 形成"肌肉记忆"，不用每次从头来。
于是他创建了 HsbcPain001Analyzer，一个专门为这个场景定制的 Claude Code Skill。
Skill 里装的不是代码逻辑，是业务知识——但要装进去，就必须先把这些知识结构化。
第一层：字段映射
52 个标准字段，每个字段的名称、XML 路径、对应的 Excel 行号，全部整理成表格写进来。这步工作量不小，但它是后续所有效率的基础。AI 要想精准输出，得先知道"阿联酋付款检查表的第 110 行对应的是收款银行 SWIFT CODE，XML 路径是 <CdtrAgt><FinInstnId><BIC>"，这种细节，不写进去它猜不到。
第二层：支付方式识别
文件名和文档内容里藏着线索。"HighValue""Urgent""Priority"对应的是 RTGS（本地他行）；"CrossBorder""International""TT"对应的是跨境付款。把这套识别规则写进去，AI 就能自动判断在处理哪种支付类型，不需要每次手动告诉它。
第三层：规则提取模式
PDF 里的规则描述是英文的，"required""mandatory""max 140 characters""not applicable"，这些词背后对应的是什么标准输出？要写清楚：识别到"required"，生成"请填写{字段名}，该字段不能为空。"识别到"max 140 characters"，生成"{字段名}不能超过 140 位。"把这套映射固化进去，输出才能格式统一。
第四层：工作流程
定义清晰的执行步骤：解析 PDF → 识别国家和支付方式 → 提取字段规则 → 生成 Excel。这是给 AI 的执行脚本，让它知道做完这一步下一步是什么，不需要在中途等你指挥。
结果：2 天变成 8 分钟
Skill 建好之后，他的工作流变成了这样：
我：帮我处理阿联酋的 HSBC 文档
Claude：识别国家：UAE（阿联酋）→ 识别支付方式：RTGS, TT → 提取 52 字段规则 → 生成 Excel：阿联酋付款检查-银企直联_V1.0.0.xlsx
耗时：8 分钟
阿联酋处理完，继续澳大利亚，5 分钟。接着菲律宾，7 分钟。再接着埃及……
原本 20 天的工作量，全部处理完不到 2 小时。
这不是因为 AI 变聪明了，是因为它手里多了一本"业务手册"——字段是什么、规则是什么、输出格式是什么，全在里面。每次调用，它翻手册干活，不需要临时学习，不会遗漏，不会猜。
什么样的工作，值得做成 Skill
这个案例让我想到一件事：多数人用 AI 的方式，是每次提需求，每次解释上下文，每次等它输出，然后发现不对再调整。效率有提升，但幅度有限，因为每次都是从零开始的对话。
而 Skill 的逻辑不一样。它是把你的业务知识提前"存"进去，让 AI 每次调用时都带着这份知识干活。对话的起点不一样了，效率的量级自然也不一样。
但不是所有工作都值得做成 Skill。判断标准有三条：
第一，规则是否明确。如果你自己都说不清楚某件事该怎么做，AI 也做不好。HSBC 文档处理的规则，清晰到可以列表，这是前提。
第二，是否频繁重复。一次性的任务，不需要 Skill。如果你每隔两周就要重新处理一遍，或者同类任务不断出现，Skill 才有价值——它分摊的是你重复解释的成本。
第三，输出格式是否固定。Skill 最擅长的是把"同一类输入"变成"同一格式的输出"。如果输出每次都不一样，Skill 就很难定义清楚该做什么。
这三条都符合的工作，基本上都值得投半天到一天时间，做一个专属 Skill。
最难的不是技术，是把知识"翻译"出来
有人可能觉得，做 Skill 需要会写代码。其实不是。
HsbcPain001Analyzer 的核心不是代码，是文档——结构化的业务知识文档。字段映射表、识别规则、提取模式、工作流程，这些都是用 Markdown 写的。会写清楚就够了。
真正难的是这一步：把你脑子里装着的业务知识，翻译成 AI 能读懂的结构化格式。
这件事要你自己来，AI 帮不了，因为只有你知道：你的业务有哪些特定规则，你的工作流程长什么样，你的输出格式要求是什么，你的痛点在哪里。把这些梳理清楚、写下来，才是 Skill 真正的核心工作。
代码那部分，很多时候让 AI 帮你生成就够了。
你有没有那种每次都要重新解释、每次都要从头来的工作？
如果有，它可能就是你的"20 天工作"。花半天时间把业务知识整理清楚，做成一个 Skill，之后每次用都是 10 分钟的事。
这笔账，不难算。
2026.05.01 11:38
沪·赵巷
📌 声明：本文由 AI 辅助完成
粤ICP备14082021号
免费POC，
零成本试错
