Automate

Automate：从重复劳动中回收Token与时间的工程化技能

核心用法

Automate是一套任务自动化决策与执行框架，核心目标是用确定性脚本替代LLM的重复调用。其使用流程分为四个阶段：

1. 自动化检测（Automation Test）
面对任何任务前，通过三问判断自动化可行性：

• 是否确定性（相同输入=相同输出）？
• 是否重复发生？
• 是否规则驱动（可精确描述步骤）？

三问皆"是"则必须脚本化，而非反复调用LLM。

2. 脚本vs LLM决策矩阵
文档提供了明确的工具选择指南：格式转换、正则文本处理、文件操作、数据验证、固定逻辑API调用、Git工作流等任务优先脚本化；而判断决策、创意内容、模糊输入处理、一次性独特任务保留给LLM。

3. 触发识别与提案
识别自动化机会的五种典型信号：重复执行相同任务、编写相似提示词、统一格式化输出、重复数据验证规则、可预测逻辑的API调用。发现机会后，需按标准格式提交自动化提案，包含任务描述、频率、当前成本、脚本规格（语言/输入/输出/位置）及预估节省收益。

4. 脚本标准化与资产追踪
脚本需遵循六大标准：单一职责、幂等性、头部文档注释、执行日志、显式错误处理、密钥外置。同时建立Active Scripts与Candidates清单，量化记录token与时间节省。

显著优点

• 成本削减直接可量化：每次脚本替代LLM调用，都是永久性token节省，形成复利效应
• 速度数量级提升：毫秒级脚本执行 vs 秒级甚至分钟级LLM响应
• 可靠性根本改善：脚本确定性失败（可预测、可调试）vs LLM概率性幻觉与随机失败
• 工程规范完备：提供从识别到提案、从编写到追踪的全流程方法论，而非零散技巧
• 决策框架清晰："3x规则"（第3次重复必须脚本化）和"决策矩阵"大幅降低判断成本

局限性与风险

• upfront 投入门槛：首次编写脚本需要投入时间与技能，对于低频任务可能ROI不足
• 维护成本隐性：API变更、依赖升级、环境迁移可能导致脚本失效，需持续维护
• 判断依赖经验边界："规则驱动"与"判断决策"的边界有时模糊，错误归类可能导致过度工程化或错失自动化机会
• 非技术用户适用性有限：需要具备bash/python/node等脚本编写能力，纯业务用户难以直接应用

适合人群

• 高频使用LLM的开发者/工程师：每天进行大量重复性数据处理、格式转换、代码生成任务的开发者
• DevOps/SRE团队：需要标准化部署、环境同步、日志处理等流程的运维人员
• AI应用架构师：负责设计人机协作流程、控制token预算的系统设计者
• 技术团队Lead：需要建立团队效率规范、量化自动化收益的工程管理者

常规风险

• 过度自动化：对不够稳定的流程或变更频繁的业务逻辑过早脚本化，导致维护负担超过收益
• 密钥泄露：脚本中硬编码API密钥、数据库密码等敏感信息，造成安全漏洞
• 环境依赖脆弱：脚本依赖特定本地环境配置，跨机器迁移时失效
• 幂等性缺陷：非幂等脚本被重复执行导致数据重复、状态错乱
• 文档衰减：脚本头部注释未及时更新，后续使用者难以理解用途与用法

本技能来源可信度较高（T2级），基于工程实践最佳实践与成本效益分析原则，具备逻辑自洽性与可执行性，但非学术认证方法论，实际效果取决于执行者的技术判断力。

核心用法

Automate 是一套面向 Agent 用户的成本优化决策框架，核心目标是识别并消除对 LLM 的"浪费性调用"。其使用逻辑围绕 "Automation Test"三问法则 展开：在每次调用 LLM 前，用户需自检任务是否满足（1）确定性——相同输入恒得相同输出；（2）重复性——未来会再次发生；（3）规则化——可写下精确执行步骤。三者皆满足时，必须转为脚本实现而非继续消耗 token。

Skill 提供了完整的决策矩阵（Script vs LLM）、自动化触发信号清单、以及标准化的提案格式，指导用户将高频任务（格式转换、文件操作、数据验证、Git 工作流等）固化为脚本。配套 "3x Rule" 强制机制：同一任务执行到第3次时，必须先写脚本再运行。

显著优点

经济性革命：将按次计费的 LLM 调用转化为一次性投入的脚本开发，边际成本归零，实现"永久复利式"节省。据示例估算，单个 JSON 格式化脚本即可周省 2000 tokens。

方法论完整性：并非零散技巧，而是覆盖识别（signals.md）→ 决策（三问/矩阵）→ 实施（提案格式/脚本标准）→ 追踪（Active Scripts 清单）的完整闭环，具备极强的可执行性。

工程规范性：强制要求脚本满足单一职责、幂等性、文档注释、日志输出、显式错误码、密钥外置等六条标准，直接提升团队代码质量基线。

心智负担转移：将"该不该用 LLM"的纠结转化为可量化的自动化机会成本计算，降低决策疲劳。

潜在缺点与局限

场景边界模糊："判断型任务"（Judgement calls）与"规则型任务"的区分依赖主观经验，新手易误判。例如，复杂的数据清洗规则可能看似确定，实则需频繁人工调整，过早脚本化反而增加维护成本。

隐性成本低估：脚本开发、测试、文档、跨环境部署本身消耗时间，对"一年只用5次"的任务，3x Rule 可能过度工程化。

技术门槛前置：要求用户具备 Bash/Python/Node 等脚本编写能力，对纯业务型 Agent 用户形成使用障碍——他们可能更依赖 LLM 正是因缺乏编码能力。

LLM 价值窄化风险：过度强调"确定性脚本"可能忽视 LLM 在模糊需求探索、快速原型验证阶段的独特价值，形成另一种效率迷信。

适合的目标群体

• 高频重复型知识工作者：数据分析师、DevOps 工程师、运营人员，日常涉及大量格式转换、报表生成、环境配置
• Agent/LLM 重度用户：月消耗 token 量超百万、对 API 账单敏感的个人或团队
• 技术团队效率负责人：寻求标准化内部工具链、减少"用 LLM 写重复代码"反模式的技术管理者
• 具备基础脚本能力的开发者：能理解并实施 Bash/Python 自动化，但缺乏系统化方法论指导

常规使用风险

性能与维护债务：快速积累的脚本若未纳入版本控制（Git）和 CI/CD 流程，将成为散落各处的"技术债"，后期检索和更新成本高昂。

环境依赖漂移：脚本依赖本地工具链（jq、prettier、git hooks），团队环境不一致时可能出现"在我机器上能跑"的协作摩擦。

权限与安全隐患：脚本化过程中若不慎将敏感操作（rm -rf、数据库写操作）固化，缺乏 LLM 的"二次确认"机制，可能放大误操作风险。用户需对 Skill 提供的模板保持审查，避免直接用于生产环境。

方法论僵化：3x Rule 的刚性执行可能抑制对"半自动化"（如 LLM 生成初版脚本+人工调整）等混合模式的探索，需结合实际灵活调整。