先聊一个很常见的现象很多人看到各类 AI 工具发布会的第一反应是马上安装、学习 Prompt、研究各种新插件结果用了一周之后发现效率不升反降。原因往往不是工具不好而是没有先想清楚“到底要把哪些工作交给 AI 或自动化脚本”。如果不清楚自己的任务结构盲目套用 AI 只是在给日常流程增加新的复杂度。本文会分享一个可以直接复用的“自动化机会评估”Skill它能在你真正花时间学习 AI 工具之前先帮你把工作流里的重复环节、高频动作、规则清晰但耗时的步骤识别出来并给出自动化的优先级建议。无论你是后端开发、测试工程师还是经常做报表、处理数据的业务人员都可以跟着本文搭建一个最小可用版本把它接入 Claude Code、Codex 或其他支持自定义 Skill 的 AI Agent 工具中让自己“先评估、后动手”。1. 为什么要先评估再自动化1.1 自动化不是“用了 AI 就完事”自动化并不等于“会调用 AI 接口”或者“会写一个 Python 脚本”。很多团队在引入 AI 工具时第一反应是把所有流程都交给 AI 处理结果发现真正高频、重复、规则明确的任务没有得到优化反而是一些需要人工判断、数据变化极大的环节被强行自动化最后不得不人工返工。更合理的做法是把自动化当做一个投资决策来对待先衡量这个任务是否值得投入时间再考虑用什么技术路线去实现。只有那些每周高频发生、单次耗时较长、执行规则相对清晰的工作才应该优先进入自动化候选清单。1.2 Skill 是什么能做什么Skill 在 AI 工具中通常指一个可复用的技能包它由 Markdown 文档、脚本、示例文件和配置信息组成目的是让 AI 助手在遇到特定场景时按照预设的步骤去执行。以 Claude Code 和 Codex CLI 为例它们会读取项目目录下的SKILL.md文件根据用户对话内容判断当前是否触发这个技能然后调用外部脚本或工具完成分析。与普通 Prompt 相比Skill 的核心优势在于“结构化”它把判断标准、执行步骤、输入输出格式都固化下来AI 不会每次都自由发挥评估结果也更稳定。你可以把 Skill 理解成给 AI 写的一份“操作手册”手册里写清楚了什么情况下用、每一步怎么做、输出什么格式。1.3 自动化价值评估的核心维度一个任务是否值得自动化通常可以从几个维度来判断。第一是执行频率一周只出现一次的任务很难体现自动化收益第二是单次耗时如果每次都要花半小时以上即使频率不高也值得关注第三是规则清晰度规则越明确自动化实现越容易可维护性也越高第四是数据变动程度如果输入数据每次都不一样、无法用固定模板处理那自动化的成本会明显上升第五是出错成本如果自动化一旦出错会造成严重损失就需要加入更多审核和兜底机制最后是人工判断需求如果任务高度依赖经验、判断和沟通那么短期内更适合“人机协同”而不是完全自动化。2. 环境准备与目录结构2.1 环境与版本说明本文的示例以“本地文件 Python 脚本 SKILL.md”方式实现适用于支持自定义 Skill 的 AI Agent 工具。操作系统可以选择 Windows、macOS 或 Linux只要能运行 Python 3.8 及以上版本即可。AI 工具部分建议先安装一个支持自定义 Skill 的 CLI 工具例如 Claude Code 或 Codex CLI。由于 Skill 的目录规范和 frontmatter 字段在不同工具中仍在快速演进具体版本可能不一致所以本文只采用最基础的name和description字段实际使用时请根据你的工具版本调整。2.2 项目目录结构建议把 Skill 放在项目根目录下的.claude/skills或.codex/skills目录中具体路径取决于你使用的 AI 工具。下面是我在示例项目中使用的目录结构automation-audit-demo/ └── .claude/ └── skills/ └── automation-audit/ ├── SKILL.md ├── scripts/ │ └── evaluate_automation.py └── examples/ └── task.example.json这里有几个文件需要提前说明。SKILL.md是技能的核心配置描述了这个 Skill 的使用场景、评估步骤和输出格式evaluate_automation.py是执行自动化价值评分的脚本负责把输入的任务特征转换为收益分和风险分task.example.json是一个示例输入文件方便你理解评分脚本需要哪些字段。整个结构非常简单没有引入 Docker 或额外服务所有计算都发生在本地这也是 Skill 最实用的形态之一。2.3 文件职责划分在开始编码之前先明确各个文件的职责。SKILL.md对 AI 助手负责它告诉 AI 什么时候触发这个技能以及触发后应该按什么顺序执行Python 脚本对数据负责它接收任务描述输出一个结构化的 JSON 结果JSON 示例文件对测试负责它能帮你快速验证脚本逻辑是否正确。整体流程是用户在对话中描述一个重复性任务AI 助手根据SKILL.md的说明生成结构化数据然后调用脚本计算最后把结果组织成自然语言回复给用户。这种设计的好处是AI 只负责“理解和组织”真正的数值计算交给 Python结果更精确、更可控。3. 编写 Skill 配置文件3.1 SKILL.md 的 Frontmatter 信息SKILL.md是普通 Markdown 文件但文件顶部有一段 YAML 格式的 frontmatter用来声明技能元信息。最常见的字段是name和description其中description尤其重要因为它会被 AI 工具用来判断当前对话是否应该触发这个技能。下面是一个前端配置示例--- name: automation-audit description: 分析用户给出的重复性任务或工作流程评估其自动化价值并输出优先级建议。当用户提到“自动化”“重复工作”“效率提升”“AI 替代”等话题时使用。 ---这里需要注意的是description不要写得太宽泛比如“帮助用户提高效率”就太模糊了。更好的写法是包含触发场景和具体动作例如“分析用户给出的重复性任务或工作流程评估其自动化价值”。这样 AI 在阅读用户需求时更容易判断是否匹配这个 Skill。3.2 SKILL.md 正文内容Frontmatter 下面就是技能正文。正文应包含适用场景、执行步骤、输入输出说明和注意事项。下面是一个适合本文示例的SKILL.md内容# Automation Audit ## 适用场景 当用户描述一个日常任务、重复性工作或业务流程时使用本技能判断该任务是否值得自动化。 ## 评估步骤 1. 从用户的描述中提取以下信息 - 任务名称 - 每周执行频率 - 单次耗时分钟 - 规则清晰度1-5 - 数据变动程度1-5 - 出错成本1-5 - 人工判断需求1-5 2. 将以上信息整理为 JSON并写入临时文件。 3. 调用 scripts/evaluate_automation.py 脚本进行评分。 4. 根据输出的收益分、风险分和建议给出落地规划。 ## 注意事项 - 如果用户没有提供具体分值请基于描述进行估计并在回复中说明这是估计值。 - 涉及敏感信息时不要将真实业务数据写入临时文件。 - 评分结果只用于决策参考不构成唯一依据。这段正文并不包含复杂代码但已经足够让 AI 助手按步骤完成评估。在真实项目中你可以在正文中添加更多示例帮助 AI 做 few-shot 推理提高提取参数的准确率。3.3 AI 如何识别和调用 Skill不同工具的 Skill 触发机制不太一样有的工具会在每次对话时扫描所有可用 Skill然后根据description的语义匹配结果决定是否调用有的工具则允许用户手动指定比如在对话中输入/automation-audit。如果你发现自己已经把 Skill 放进了正确目录但 AI 并没有自动调用可以尝试在对话中直接提到“使用 automation-audit 技能分析”。在编写description时也可以多放几个同义触发词例如“自动化”“重复劳动”“流程优化”这样可以提高命中率。需要特别注意的是Skill 不是万能的它只是给 AI 提供了一套固定流程最后的输出质量仍然受到用户描述完整度和脚本逻辑质量的影响。4. 评估脚本核心实现4.1 输入数据设计为了让评分脚本足够通用我们需要设计一个标准化的输入格式。每个任务用一组 JSON 字段描述包括任务名称、每周执行频率、单次耗时和四个 1-5 分制维度。示例输入如下{ task_name: 每日整理销售数据并生成日报, frequency_per_week: 5, time_per_execution_minutes: 30, rule_clarity: 4, data_variability: 2, error_cost: 3, manual_judgment: 2 }这组数据描述了一个典型的报表自动化场景每周执行 5 次每次 30 分钟规则比较清晰数据变动不大出错成本一般人工判断需求较低。从直觉上看这类任务适合自动化。接下来我们会让脚本算出一个可量化的收益分和风险分用数据来支撑这个判断。4.2 收益与风险评估模型我设计了一个两维评分模型自动化收益分和自动化风险分。收益分由每周总耗时、规则清晰度和数据变动程度共同决定每周耗时越长、规则越清晰、数据变动越小收益分越高。风险分由出错成本、数据变动程度和人工判断需求共同决定出错成本越高、数据变化越频繁、需要人工判断的地方越多风险分越高。最后根据两条分数的组合关系输出四类建议优先自动化、可自动化但需兜底、部分自动化、暂不建议自动化。下面用一个 Python 脚本实现这个模型。4.3 完整脚本代码创建scripts/evaluate_automation.py文件代码如下#!/usr/bin/env python3 # 文件路径scripts/evaluate_automation.py import json import sys REQUIRED_FIELDS [ task_name, frequency_per_week, time_per_execution_minutes, rule_clarity, data_variability, error_cost, manual_judgment ] def load_task(file_pathNone): 从文件或标准输入读取 JSON 任务描述 if file_path: with open(file_path, r, encodingutf-8) as f: return json.load(f) return json.load(sys.stdin) def evaluate(task): 根据任务特征计算自动化收益分、风险分和建议 for field in REQUIRED_FIELDS: if field not in task: raise ValueError(f缺少必要字段: {field}) task_name task[task_name] frequency task[frequency_per_week] time_per_execution task[time_per_execution_minutes] clarity task[rule_clarity] variability task[data_variability] error_cost task[error_cost] manual_judgment task[manual_judgment] weekly_time frequency * time_per_execution # 收益分频率高、单次耗时长、规则清晰、数据变化小 收益高 gain_score ( min(weekly_time / 60, 10) * 4.0 clarity * 12.0 - variability * 3.0 ) # 风险分出错成本高、数据变化大、人工判断多 风险高 risk_score ( error_cost * 15.0 variability * 12.0 manual_judgment * 18.0 ) # 分数控制在 0-100 之间 gain_score max(0, min(100, gain_score)) risk_score max(0, min(100, risk_score)) if gain_score 60 and risk_score 50: suggestion 优先自动化建议结合脚本或 AI Agent 一次性打通。 elif gain_score 60 and risk_score 50: suggestion 可自动化但需要人工审核兜底建议先小范围试点。 elif gain_score 40: suggestion 值得部分自动化可先抽取出规则清晰的子步骤落地。 else: suggestion 暂不建议自动化当前阶段人工处理更经济。 return { task_name: task_name, weekly_time_minutes: weekly_time, gain_score: round(gain_score, 1), risk_score: round(risk_score, 1), suggestion: suggestion } if __name__ __main__: file_path None if len(sys.argv) 1 and sys.argv[1] ! -: file_path sys.argv[1] try: task_data load_task(file_path) result evaluate(task_data) print(json.dumps(result, ensure_asciiFalse, indent2)) except Exception as e: print(json.dumps({error: str(e)}, ensure_asciiFalse)) sys.exit(1)这段脚本不依赖第三方库只需要 Python 标准库中的json和sys即可。核心逻辑都在evaluate函数中方便后续做单元测试。你可以直接运行脚本也可以把它作为子进程交给 AI 工具调用。4.4 运行与验证先用示例文件验证脚本是否正常工作。创建examples/task.example.json内容就是上面那段 JSON。然后在终端运行python3 scripts/evaluate_automation.py examples/task.example.json预期输出如下{ task_name: 每日整理销售数据并生成日报, weekly_time_minutes: 150, gain_score: 74.0, risk_score: 48.0, suggestion: 优先自动化建议结合脚本或 AI Agent 一次性打通。 }输出中的weekly_time_minutes表示该任务每周总耗时 150 分钟gain_score为 74 分risk_score为 48 分。由于收益分较高、风险分低于 50脚本建议优先自动化。如果你希望临时录入数据也可以把输入通过管道传给脚本例如echo {task_name:手工导出报表,frequency_per_week:20,time_per_execution_minutes:10,rule_clarity:4,data_variability:1,error_cost:2,manual_judgment:1} | python3 scripts/evaluate_automation.py -这种方式方便在 AI 工具中生成临时 JSON 后进行调用不需要手动创建文件。5. 让 AI 使用 Skill 分析任务5.1 手动触发方式在 AI 工具中如果你想立刻让某个 Skill 参与当前对话可以把 Skill 名称直接放入指令中。例如在 Claude Code 中你可以输入“使用 automation-audit 分析一下我每天整理测试报告的工作”。AI 会读取SKILL.md然后按照流程向你询问缺少的维度或基于描述估算参数最后调用脚本给出结果。手动触发适合你明确知道要用哪个 Skill 的场景排查问题也更方便。5.2 自动触发流程自动触发则完全依赖SKILL.md中的description。假设你在对话中写道“我发现每天下午都要手动对比不同环境的接口返回数据很浪费时间。”AI 看到“手动”“浪费时间”“每天”这些关键词再结合description中的触发条件就有可能会自动调用automation-audit。自动触发的好处是你不需要记得 Skill 名称但代价是对description的写作要求更高。建议用一两句话说明“什么时候用”同时限定范围减少误触发。5.3 输出建议的落地方法当脚本输出“优先自动化”时AI 还可以进一步补充落地建议。比如对于报表生成任务可以提示你用 Python 的pandas做数据清洗再用邮件库定时发送对于接口测试任务可以建议你评估pytest、requests或接口自动化测试框架对于重复性 UI 操作可以建议你研究 RPA 工具。Skill 输出的是决策参考真正的实现路径还需要结合你的技术栈、数据安全和维护成本来决定。判断接口自动化是否值得做同样可以套用这套评估逻辑。6. 常见问题与排查思路6.1 Skill 没有被 AI 自动识别如果你发现 AI 没有在你描述任务时自动使用这个 Skill可以从几个方面排查。首先检查 Skill 是否放到了工具要求的目录不同工具对目录的读取规则不同其次检查SKILL.md的description是否命中用户的表达如果用户没有提到“自动化”“重复任务”等关键词AI 可能不会触发最后检查 AI 工具版本是否支持自定义 Skill。你可以先在对话中手动指定“使用 automation-audit”如果手动可以而自动不行问题大概率出在description的触发词设计上。6.2 脚本执行失败脚本失败最常见的原因是 Python 环境问题例如在 Windows 中python3命令不存在需要换成python或者 JSON 文件中使用了中文标点导致解析失败。如果脚本无法执行AI 工具通常会把 stderr 信息反馈到会话中你可以直接根据报错信息定位。为了防止路径问题建议在SKILL.md中写明使用相对路径scripts/evaluate_automation.py并提示 AI 从项目根目录执行命令。还要注意给脚本增加可执行权限尤其是在 macOS 和 Linux 环境下chmod x scripts/evaluate_automation.py6.3 评分结果与直觉不符如果评分结果跟你的预期不一致先别急着怀疑脚本而是检查输入的参数是否准确。特别是“规则清晰度”和“人工判断需求”这类主观维度不同人的理解可能差很多。你可以针对自己的业务场景修改评分权重例如把“出错成本”的系数调高让高风险任务更容易被识别出来。更科学的方法是在SKILL.md中补充几个典型示例告诉 AI 什么样的任务应该打几分这样参数提取会更稳定。6.4 隐私与安全边界在真实业务场景中使用 Skill 时要注意隐私边界。如果任务描述包含客户信息、代码路径、业务数据等敏感内容不要让 AI 把这些内容写入临时 JSON 文件更不要提交到版本库。建议在SKILL.md的注意事项中明确提示只使用脱敏后的示例数据。同时评分脚本只做数学计算不需要访问内部系统这是比较好的边界设计。如果后续需要与其他系统联动应遵循最小权限原则只开放必要的接口和凭据。7. 最佳实践与工程建议7.1 评分模型要按业务调优本文给出的权重只是起点并不是标准答案。不同的业务场景对收益和风险的侧重完全不同在财务对账场景中出错成本可能极高建议调高风险分权重在客服工单分类场景中规则清晰度低反而是主要瓶颈应该更关注数据变动程度。你需要收集一批历史任务让团队共同给这些任务打分再对比脚本输出与人工判断是否一致。经过几轮调整后评分模型会更贴近你的真实业务。7.2 Skill 版本管理与团队复用Skill 本质上也是一份代码资产应该纳入版本管理。建议在项目仓库中单独建一个skills目录并给每个 Skill 维护一个CHANGELOG。当评分规则调整时记录清楚改动原因和影响范围。团队使用时可以约定主要负责人维护SKILL.md其他人以提 Issue 的方式建议增加新的触发词或调整权重。这样既能保持技能的社区化演进又不会出现“每个人手里的 Skill 都不一样”的混乱状态。7.3 用评估结果反推落地计划评估结果不只是用来决定“做不做自动化”还能指导“从哪里开始做”。对于“优先自动化”的任务可以进一步拆解成数据获取、数据处理、结果输出、异常告警四个环节逐个判断哪些可以先用脚本替代哪些需要保留人工确认。建议每次只自动化一个环节并设置一个观察期。例如先自动生成日报初稿人工只负责审核和修改稳定运行两周后再把审核环节也交给自动化。这种渐进式落地方式能有效降低风险。7.4 与自动化测试、RPA、AI Agent 的关系许多技术和工具都能实现自动化但它们的适用边界不一样。接口自动化、UI 自动化测试适合研发质量保障场景RPA 适合跨系统、无 API 的重复操作AI Agent 适合需要理解语义、动态决策的多步任务。自动化价值评估 Skill 不替代这些工具而是充当“入口决策器”先判断值不值得自动化、风险高不高再帮助团队选择合适的落地手段。这样做的好处是团队不会因为某个新技术流行就强行引入也不会因为缺乏判断标准而错过明显值得优化的重复劳动。8. 总结与下一步学习建议写到这里本文的核心内容已经完整呈现你学会了如何搭建一个“自动化机会评估” Skill理解了SKILL.md的配置方式并用 Python 实现了收益分和风险分的计算脚本。这套方案不仅适用于个人效率工具也可以推广到团队内部作为识别“高价值自动化场景”的标准化流程。你可以先拿自己手头最重复的一项工作做测试填写 JSON 并观察输出结果再根据实际感受调整权重。下一步可以从三个方向继续深入。第一学习如何编写更高质量的描述和 Prompt让 AI 提取任务参数时更准确第二研究任务链路中具体环节的自动化实现例如用 Python 处理报表、用接口测试框架做回归验证第三如果团队已经在使用 CI/CD、RPA 或 AI Agent可以把本 Skill 的评估结果接入到工单系统或决策看板中形成“评估、建议、落地、复盘”的完整闭环。最后留一道思考题如果一项任务每周只出现一次但每次需要一整天出错成本极高你会优先自动化它吗欢迎按照本文的模型算一算收益分和风险分再体会一下“值得自动化”和“适合自动化”之间的区别。