在实际项目中资料整理从来不是“把一堆文字攒在一起”这么简单。会议记录要提炼成待办合同条款要提取成字段一堆日志要归纳成结论文献片段要改写成笔记。直接让 AI 回答结果往往时好时坏每次重新写提示词又很难保证格式一致。仓颉Skill 的思路是把“整理资料”这个动作本身做成一个可复用的技能包。用户把资料文件交给 AIAI 按照预定义的目标、流程、输出模板和校验规则整理出用户真正想要的那份成果。这篇文章会围绕仓颉Skill 从零讲清楚三件事第一一个整理类 Skill 应该怎么设计为什么要把任务拆成固定环节第二完整的技能包目录、SKILL.md 文件、示例文件和校验脚本怎么编写第三当 AI 没有整理出你想要的结果时应该按什么顺序排查生产环境落地还需要补哪些工程能力。读完以后你可以直接照这个结构搭建自己的整理类技能包也可以把它嵌入到现有 Agent 工作流里。1. 先理解仓颉Skill为什么要把资料整理做成技能包1.1 直接提问、临时提示词与技能包的区别很多人在日常工作里已经用 AI 整理过资料。最常见的做法是复制一段文本粘贴到对话框里输入“帮我总结一下”然后得到一段回答。这个做法在小任务上没问题但一旦资料变多、格式要求变高、任务反复出现就会暴露出几个明显的弱点每次都要重新描述任务结果格式不稳定AI 可能漏掉关键字段也没有办法沉淀成团队可复用的资产。把资料整理做成技能包本质上是把“人怎么向 AI 描述任务”这件事标准化。技能包不是一段简单的提示词而是一组结构化的文件里面包含任务的触发条件、执行步骤、输出模板、示例、校验规则甚至还可以包含辅助脚本。AI 在加载技能包之后会按照技能包里的流程处理资料而不是临时发挥。下面这个表格列出了三种常见方式的差异。使用方式优点缺点适合场景直接粘贴文本提问快零配置每次都要重新描述结果不稳定一次性小任务每次写临时提示词可控性较好无法沉淀重复劳动格式容易漂移偶尔使用任务不固定维护一个技能包稳定、可复用、可维护、可团队共享前期需要设计和测试频繁执行且输出要求固定的整理任务从工程角度看第二种到第三种是质的区别。临时提示词像是命令行里的一个脚本用完就丢技能包像是把这个脚本做成一个带参数、有文档、有测试的正式工具。1.2 仓颉Skill 的定位把分散资料变成结构化成果仓颉是传说中创造汉字的人把口口相传的零散信息固化成可读可传的文字。仓颉Skill 借用了这层含义输入是杂乱的资料文件输出是结构稳定、规则一致的文字成果。它面向的不是“跟 AI 聊天”而是“把资料交给 AI 完成一次加工”。常见的使用场景包括把多份会议记录整理成标准会议纪要并提取待办事项。把合同条款或政策文件整理成字段化的信息表。把多篇技术文章整理成带摘要、结论和延伸阅读的笔记。把日志、报错信息整理成故障复盘材料。把运营周报里的数据描述整理成统一格式的汇报稿。这些任务有一个共同点AI 需要的不是创造力而是稳定性。用户希望每次调用都按照同样的规则输出字段名不换结构不乱覆盖完整。这正是技能包擅长的事情。1.3 适用边界哪些任务适合交给仓颉Skill不是所有任务都适合做成技能包。整理类任务有一个判断标准规则是否可以被明确描述。适合的场景是输入和输出都相对确定中间过程可以被拆成固定步骤。比如“把这份会议记录里的待办事项提取出来按负责人、截止时间、事项描述三个字段输出”这就是清晰的规则。不适合的场景包括需要强事实核对的资料、需要行业专家判断的内容、涉及个人隐私或公司保密信息的文件。技能包只能保证整理流程稳定不能保证资料里的信息一定真实也不能替代人的最终审核。2. 仓颉Skill 的设计思路整理任务先拆成五个环节2.1 定目标用户想要的不是“总结”而是特定格式很多提示词效果差不是因为 AI 能力不行而是因为目标描述太模糊。“帮我总结一下这份资料”是一个模糊目标AI 不知道你要的是 50 字的摘要、三页纸的报告还是带表格的清单。在仓颉Skill 里第一步永远是定目标。这里的定目标包含两层意思一是明确输出类型是 Markdown 笔记、JSON 结构化数据还是表格二是明确输出粒度是每段资料都覆盖还是只保留与某个主题相关的信息。一个可用的目标描述示例是“把这份会议记录整理成会议纪要包含会议基本信息、核心结论、待办事项三个部分待办事项用表格输出字段为事项、负责人、截止时间。”这个描述里输出类型、章节结构、字段名、展示形式全部被限定AI 就不用猜。2.2 读资料划定输入范围和引用规范第二步是让 AI 明确自己要处理哪些资料。技能包不适合直接面对“一个文件夹里所有文件”这种开放输入因为文件可能有噪音、可能有重复、可能包含不相关内容。更好的做法是让用户明确指定文件清单或者在技能包里规定输入命名规则。同时要规定引用规范。AI 在整理过程中如果引用了资料里的原文应该怎么处理直接引用需要加引号转写需要说明数据数字必须保留原值。这个细节决定了整理结果是否可信。很多整理结果出现数据错误就是因为 AI 在转写时把数字或日期“顺滑”地改掉了。2.3 提取和校验防止 AI 自己发挥资料整理的关键环节是提取。提取不是让 AI“自由写作”而是要求 AI 从原文中找出对应信息填入规定好的结构里。为了避免 AI 在提取过程中脑补内容技能包里要写清楚没有找到的信息标记为“未提及”不能猜测数字、日期、人名、金额等细节必须与原文一致多个资料之间存在矛盾时要并列展示而不是替用户做决定。校验是很多人会忽略的一步。整理结果出来后AI 应该对照原文检查一遍每个输出字段是否都有来源是否有遗漏是否插入了原文中没有的信息。这个校验过程可以直接写进技能包的工作流程里。2.4 输出的统一规范字段、层级、措辞最后一个设计环节是输出规范。输出规范越具体结果越稳定。建议至少规定以下内容一级标题、二级标题的层级怎么用。每个章节的标题固定为什么。表格的列名是什么。每个字段的取值规则是什么比如“待办事项状态只允许未开始、进行中、已完成三种值”。措辞风格是什么比如“使用陈述句不使用评价性语言”。可以把输出模板单独放在 resources 目录下作为 AI 输出时的参考文件。AI 在输出前先阅读模板再按模板生成结果比在提示词里用文字描述模板更稳定。3. 从零搭建一个仓颉Skill 项目3.1 环境准备技能包可以在哪几种环境中运行仓颉Skill 本身不是某个平台的专属功能而是一组标准化的文件。只要 AI 应用支持自定义系统提示词、技能目录或 Agent 工具定义就可以加载它。常见的承载方式有下面几种。承载方式典型代表适用人群特点支持自定义技能的应用Claude Skills 类似机制个人用户、小团队把技能包放入技能目录即可使用Agent 编排平台Dify、扣子 Coze 等团队项目可以把技能转成提示词节点或知识库流程代码框架LangChain、Spring AI、自研提示词引擎开发者把 SKILL.md 作为系统提示词加载配合工具调用命令行工具支持附件输入的 CLI AI 工具开发者把资料文件和技能文件一起交给模型不同环境的目录名、加载方式差别很大落地前要先确认你使用的平台对技能包的支持方式。如果只是学习先用支持自定义技能的应用验证最方便如果是要嵌入公司系统建议用代码框架承载。3.2 仓颉Skill 的目录结构一个标准的仓颉Skill 项目建议采用下面的目录结构。cangjie-skill/ ├── SKILL.md ├── examples/ │ ├── input-sample.md │ └── output-sample.md ├── scripts/ │ └── verify_output.py └── resources/ └── output_templates/ ├── meeting_notes.md ├── information_table.md └── structured_data.json目录里的每个部分都有明确职责SKILL.md 是技能的主文件定义技能的能力、触发条件、执行流程和输出规则。examples 目录存放一组输入输出示例给 AI 做 few-shot 参考。scripts 目录存放可选的校验脚本用于对结果做程序化检查。resources/output_templates 目录存放输出模板是 AI 输出时的格式标准。这个结构不是必须一字不差但它能保证技能包在增长时仍然可维护。如果只有简单的整理需求可以只保留 SKILL.md 和 examples。3.3 编写 SKILL.md 主文件SKILL.md 是整个技能包的核心。它通常包含两部分头部元信息和正文指令。下面是一个可以直接修改使用的示例。--- name: cangjie-skill description: 把用户提供的资料文件整理成结构化成果。当用户要求整理资料、汇总文档、生成会议纪要、提取信息时使用。 version: 1.0.0 --- # 仓颉Skill资料整理技能 ## 任务目标 把用户提供的一份或多份资料按照用户指定的输出类型和模板整理成结构稳定、内容完整、可二次使用的文字成果。 ## 什么时候使用 当用户明确要求整理资料、汇总文档、生成会议纪要、提取信息、改写为指定格式时使用。 当用户只是询问某个问题不涉及资料整理任务时不要使用本技能。 ## 执行流程 1. 拆解目标确认输出类型、输出粒度、是否包含用户自定义字段。 2. 读取资料逐份阅读用户提供的文件和示例不使用技能包以外的知识补充资料内容。 3. 提取信息按照输出模板提取字段所有信息必须来自原文。 4. 校验对照原文检查是否有遗漏、脑补、数字错误和格式偏差。 5. 输出严格按照输出模板生成最终结果。 ## 提取规则 - 数字、日期、人名、金额、版本号必须与原文一致。 - 找不到的信息标记为“未提及”不允许猜测。 - 资料之间存在矛盾时并列展示不同来源的表述。 - 不添加原文没有的事实性内容。 ## 输出规则 - 输出格式以 resources/output_templates 下的模板为准。 - Markdown 输出时一级标题约等于文档标题二级标题为正式章节。 - 表格输出时列名必须与模板一致不允许私自改名。 - 措辞使用陈述句不评价内容好坏。 - 如果用户提供了自定义输出要求以用户要求优先但字段层级需要保持在二级以内。 ## 示例 参考 examples 目录下的 input-sample.md 和 output-sample.md。这段内容里的关键点在于description 决定了技能能否被正确触发执行流程固定了 AI 的处理顺序提取规则和输出规则约束了 AI 的自由度。实际使用时要根据你自己的输出模板调整章节名和字段名。3.4 增加示例文件和校验脚本只有规则没有示例AI 仍然可能理解偏差。在 examples 目录下放一组“输入到输出”的完整示例可以显著提升稳定性。示例输入文件 input-sample.md# 6月20日产品沟通会记录 时间6月20日 10:00-11:30 参与人王XX产品、李XX研发、赵XX运营 讨论内容 1. 产品提出8月2日要上新版本重点功能是登录页优化和用户数据看板。 2. 研发反馈排期紧张8月2日上线风险高建议优先登录页优化数据看板顺延到下一迭代。 3. 运营反馈近期用户投诉集中在页面加载慢尤其是弱网环境。 4. 三方同意先做性能优化数据看板延期。 待办 - 研发周二前给出性能优化排期。 - 产品周五前确认数据看板字段。 - 运营整理10条用户投诉案例。示例输出文件 output-sample.md# 会议纪要6月20日产品沟通会 ## 基本信息 - 时间6月20日 10:00-11:30 - 参与人王XX产品、李XX研发、赵XX运营 - 记录人AI 整理 ## 核心结论 1. 8月2日上线风险较高研发建议优先完成登录页优化。 2. 数据看板顺延到下一迭代。 3. 三方同意先做性能优化处理弱网环境加载慢问题。 ## 待办事项 | 事项 | 负责人 | 截止时间或说明 | | --- | --- | --- | | 给出性能优化排期 | 李XX | 周二前 | | 确认数据看板字段 | 王XX | 周五前 | | 整理用户投诉案例 | 赵XX | 未明确建议补充 |除了示例还可以提供一个简单的校验脚本用于检查输出是否满足基本结构。下面这个 Python 脚本是一个最小实现用于检查 Markdown 输出是否包含必需章节。import sys import re required_sections [基本信息, 核心结论, 待办事项] def verify_markdown(path): with open(path, r, encodingutf-8) as f: content f.read() missing [] for section in required_sections: pattern re.compile(r^##\s re.escape(section), re.MULTILINE) if not pattern.search(content): missing.append(section) if missing: print(缺少必需章节: , .join(missing)) sys.exit(1) print(校验通过) if __name__ __main__: verify_markdown(sys.argv[1])这个脚本的意义不在于复杂而在于把“格式对不对”从主观判断变成可执行检查。生产环境里还可以扩展为检查表格列名、必填字段数量、数字格式等。3.5 加载与调用方式把技能包放到 AI 应用加载的目录即可。不同平台目录不同常见做法是在指定技能目录下为每个技能创建一个子目录目录名就是技能名。创建目录可以这样操作mkdir -p cangjie-skill/examples cangjie-skill/scripts cangjie-skill/resources/output_templates ls -R cangjie-skill执行完成后你应该能看到上面设计的目录结构。然后把你写好的 SKILL.md、示例文件、模板和脚本放入对应位置。调用时你不需要在对话里重复提示词的细节只要明确说出目标和文件即可。例如“使用仓颉Skill 整理 inputs/6月20日会议记录.md输出会议纪要。”AI 会读取技能定义按流程处理资料。如果平台没有技能目录机制可以在系统提示词中直接粘贴 SKILL.md 的正文部分效果接近只是维护成本略高。4. 场景演练把一份会议资料整理成标准会议纪要4.1 准备原始资料假设现在要处理一份未经整理的会议记录。先把资料保存为 inputs/meeting.md内容如下。# 项目复盘会 时间7月3日 14:30 参加人产品、研发、测试、运营 1. 测试说上周发布的 v2.3 版本出现了一个崩溃问题集中在 Android 低端机型。 2. 研发查了日志发现是图片加载库在低内存设备上 OOM已经修复预计本周四发补丁。 3. 运营说收到一百多条用户反馈其中大部分是关于启动速度的。 4. 产品提出下一版本把启动耗时作为核心指标目标小于 3 秒。 5. 测试建议补一批低端机型的回归用例。 下次例会时间7月10日 14:30。这份资料是流水账式的记录没有固定格式也没有直接可用的结论列表。这正是仓颉Skill 要处理的对象。4.2 明确想要的输出格式调用前先想清楚输出要求。这里定义一个简单的整理目标输出一份 Markdown 会议纪要包含基本信息、问题清单、结论与决策、待办事项四部分。待办表格的列为“事项、负责人、截止时间”。把这条目标作为本次调用的用户指令传给 AI技能包会负责执行流程用户指令负责修正具体输出字段。4.3 触发技能并观察执行结果调用后AI 应该按照 SKILL.md 的流程执行。理想输出如下。# 会议纪要项目复盘会 ## 基本信息 - 时间7月3日 14:30 - 参与人产品、研发、测试、运营 - 记录人AI 整理 ## 问题清单 1. v2.3 版本在 Android 低端机型出现崩溃原因疑似图片加载库 OOM。 2. 用户反馈集中在启动速度慢共一百多条。 ## 结论与决策 1. 崩溃问题已修复计划本周四发布补丁。 2. 下一版本将启动耗时作为核心指标目标小于 3 秒。 3. 测试需要补充低端机型回归用例。 ## 待办事项 | 事项 | 负责人 | 截止时间或说明 | | --- | --- | --- | | 发布崩溃修复补丁 | 研发 | 本周四 | | 确认启动耗时指标口径 | 产品 | 7月10日例会前 | | 补充低端机型回归用例 | 测试 | 未明确 |注意输出中的“启动耗时指标口径”在原始资料里没有出现正确的做法是标记为“未明确”或补充说明来源。如果 AI 直接编了一个截止时间就是校验环节没做好。4.4 使用校验脚本和人工检查验证结果拿到输出后先跑校验脚本。python3 scripts/verify_output.py meeting_notes.md脚本会检查是否包含必需章节。脚本通过后还需要人工检查两个容易出错的地方数字是否与原文一致比如“100 多条反馈”“3 秒”“7 月 10 日”是否存在原文没有的信息。如果发现 AI 在“截止时间”列填了原文没有的日期应要求它重新整理并检查执行流程中提取规则是否生效。5. 关键设计点解释为什么这样写技能才不容易翻车5.1 角色和任务边界要写在最前面SKILL.md 开头不要直接给步骤先说明“这个技能是干什么的、什么时候不要用”。很多技能翻车是因为用户在一个普通问答场景里触发了整理逻辑或者 AI 在整理过程中混入了自己的一般性知识。任务边界写清楚之后AI 在决定“是否使用技能”时就有了依据。尤其是“不要使用”的场景能避免 AI 滥用技能包。5.2 固定流程但允许用户自定义目标执行流程里五步的顺序不能乱先确认目标再读资料然后提取接着校验最后输出。这个顺序对整理类任务几乎总是正确的。如果先提取再确认目标AI 可能提取了一堆用户不需要的信息。同时要给用户指令留出口。技能包只是默认规则当用户明确说“只要待办事项不要摘要”时用户指令优先但输出格式仍要尽量贴近模板。这样既保证稳定又不至于僵化。5.3 输出规则要具体到字段和层级输出规则写得越具体结果越容易预测。建议在 SKILL.md 里明确一级标题、二级标题分别代表什么。表格列名固定为什么。空值怎么标记。措辞风格是什么。下面这个表格总结了 SKILL.md 中常见配置项的写法建议。配置项含义建议写法name技能唯一标识使用小写英文和连字符例如 cangjie-skilldescription触发条件描述写明“什么时候使用”“什么时候不用”执行流程处理步骤固定顺序按编号列出提取规则信息来源约束明确“必须来自原文”“未提及就标记”输出模板目标格式指向 resources 下的模板文件示例few-shot 参考放在 examples 目录并说明对应关系5.4 校验规则要可执行校验不能只写“请检查一下”要写具体规则。比如“数字与原文不一致时要重新提取”“缺失字段要标记为未提及”“输出必须包含模板中的全部章节”。更进一步的校验可以由脚本完成例如检查文件扩展名、检查 JSON 字段是否存在、检查表格列数是否一致。这样设计的原因是AI 的输出受生成概率影响同样的输入可能产生不同结果。只有把规则和校验固化才能把偶然的正确变成稳定的正确。6. 常见问题排查AI 没有整理出想要的结果时查哪里6.1 现象一输出格式和示例不一致如果 AI 输出的章节名、表格列名和示例对不上先检查 SKILL.md 里输出规则是否足够具体。常见原因是只写了“输出会议纪要”没有写要包含哪些章节、表格有哪些列。检查方式是查看输出模板文件是否存在以及在调用时是否明确指定了模板。解决方式是把模板文件路径写进 SKILL.md 的输出规则并在用户指令里重申“严格按照 resources/output_templates 下的模板输出”。6.2 现象二内容遗漏或出现幻觉遗漏和幻觉是整理类任务最常见的两类问题。遗漏表现为原文里有的信息没有出现在输出里幻觉表现为输出了原文没有的信息比如编造了日期、数字或结论。这类问题要先从输入侧排查用户提供的资料是否完整是否存在多个文件但技能包只被要求处理其中一个。然后检查提取规则是否生效SKILL.md 里是否明确写了“未提及”标记规则。如果规则已经写了还出现幻觉可以考虑把大资料拆小减少上下文压力并在输出前强制 AI 执行一次“对照原文逐字段检查”。6.3 现象三资料太长超出上下文窗口当输入资料超过模型上下文限制时AI 可能只读取了前半部分导致输出缺后半段内容。这是硬限制靠提示词解决不了。建议的处理方式是先拆分资料再按顺序整理最后合并结果。技能的流程可以调整成“分块读取、合并输出”。如果平台支持也可以改为 RAG 方式把资料写入向量库再按主题检索。6.4 现象四技能没有被触发AI 把技能包当普通聊天有时用户没有说“使用仓颉Skill”AI 就不会主动加载技能。解决方式有两种在平台里把技能设置为默认启用或者在用户指令里明确写出技能名。另外要检查 description 是否覆盖了用户的表达方式。用户可能说“帮我整理一下”也可能说“把这份材料做个摘要”description 里最好同时包含这些常见动词变体。6.5 排查顺序速查表遇到“结果不像预期”的问题时按下面的顺序排查避免一开始就怀疑模型能力。现象可能原因检查点处理建议格式不对输出规则不够具体或模板未指定检查 SKILL.md 输出规则和模板文件补全模板路径和字段说明内容遗漏输入不完整或上下文超限检查输入文件列表和长度拆分资料分块整理出现幻觉提取规则未生效检查 SKILL.md 提取规则增加“未提及”标记和校验步骤技能未触发description 不覆盖用户表达检查技能描述中的动词补充“整理、总结、提取”等触发词数字错误AI 在转写时改写数据检查输出中的数字与原文强制要求数字原样保留并人工复核7. 学习环境与生产环境仓颉Skill 落地时要补哪些东西7.1 学习环境怎么快速验证学习阶段的目标是跑通“输入资料 - 触发技能 - 输出结果 - 校验”的最小闭环。不要一开始就追求覆盖所有场景也不需要写复杂的校验脚本。建议按这个顺序验证先建一个只包含 SKILL.md 的最小技能包不写 examples 和 scripts。使用一份简单的会议记录测试输出结构。逐步加入输出模板、示例文件和校验脚本。用三份不同风格的资料做回归测试观察输出是否稳定。这个阶段最重要的是快速暴露问题比如输出格式漂移、字段缺失、技能触发不准确。7.2 生产环境还要补哪些工程能力生产环境和学习环境最大的区别在于稳定性要求。技能包从“自己用”变成“团队用”之后至少要补齐下面这些能力。维度学习环境生产环境配置管理直接写死在 SKILL.md外置化按环境区分日志不关心记录每次调用的输入摘要、输出路径、校验结果权限本地文件控制资料读取权限避免敏感文件被加载敏感信息不处理识别手机号、身份证、密钥并脱敏版本管理手工复制使用 Git 管理技能包版本监控无统计成功率、平均耗时、字段缺失率回滚无保留历史技能包版本可快速切换在代码框架中承载时SKILL.md 可以作为一个系统提示词文件被加载。下面是一个 Spring AI 场景下读取技能文件的示意。Configuration public class SkillConfig { Bean public String cangjieSkillPrompt(ResourceLoader resourceLoader) throws IOException { Resource resource resourceLoader.getResource(classpath:skills/cangjie-skill/SKILL.md); return new String(resource.getInputStream().readAllBytes(), StandardCharsets.UTF_8); } }这里的关键点是技能内容从代码中拆出来放到配置目录里方便更新和版本管理。具体类名和路径需要结合项目的 Spring AI 版本调整这里只演示分层思路。7.3 从技能包到 Agent 工作流技能包解决了“单次整理如何稳定”但真实业务往往是多步流程。例如先上传资料再调用技能生成初稿然后人工修改最后导出为指定格式。这种流程可以交给 Agent 来编排。在 Dify 或扣子 Coze 这类平台中可以把仓颉Skill 的流程拆成多个节点资料上传节点、内容提取节点、格式转换节点、人工确认节点。技能包里的 SKILL.md 作为提示词模板输出规则作为节点配置。如果使用 LangChain 或 Spring AI 自研可以把技能包装成 Chain 或 Tool由 Agent 根据用户意图决定是否调用。7.4 多人协作维护技能包技能包会随着业务变化持续迭代。多人协作时建议把技能包放进 Git 仓库并以版本号管理变更。每次修改 SKILL.md 时同步更新示例文件和使用说明。不要出现“规则改了示例还是旧的”这种情况。8. 仓颉Skill 最佳实践清单8.1 编写技能时先定输出模板再写提示词不要让 AI 自己发明结构。description 中同时写清楚“什么时候使用”和“什么时候不使用”。每个提取规则都要针对一个真实错误不要堆砌空泛要求。示例必须和规则一致规则改了示例要同步改。数字、日期、金额等字段要求“原样保留”这是整理类任务最容易出错的点。8.2 调用技能时明确说清输入文件和输出目标避免“你看着办”式的开放式指令。资料较多时先拆分再分块整理最后合并。拿到输出后先跑校验脚本再人工检查原文关键数据。发现结果不理想先排查技能配置再考虑换模型或调参数。敏感文件不要直接交给在线 AI 工具先在本地脱敏或使用私有化部署方案。8.3 维护迭代时每次迭代至少准备三份测试资料一份标准场景、一份边缘场景、一份异常输入。记录历史版本回滚时能快速恢复上一版规则。把常见问题和排查步骤写进技能包文档减少新人踩坑成本。如果某类整理任务反复出现且规则稳定考虑把它拆成一个独立的新技能而不是不断膨胀原有技能。仓颉Skill 真正的价值不是让 AI 更聪明而是让 AI 的输出变得更可预期。散乱的资料之所以难处理是因为每次整理的标准都不一样。技能包把标准固定下来把流程拆清楚把校验写进规则最后得到的是一个可以反复使用、可以交给别人维护、也可以嵌入自动化流程的整理工具。下一步值得尝试的方向是把这套思路从单文件技能扩展成多技能组合让不同的整理技能在同一个 Agent 里协同工作。