本页帮助决定要不要写脚本。完整 Skill 安装与脚本调用另见Skill教程。先拆清任务的判断性质，再选实现方式。
用同一篇文章的打包任务比较
| 子任务 | 建议方式 | 原因 |
|---|---|---|
| 检查正文文件是否存在且非空 | 脚本 | 输入和失败条件确定，可给明确错误 |
| 将Markdown转HTML | 已有解析器或脚本 | 同一语法有固定规则，不应每次凭语言描述重新转换 |
| 判断标题是否夸大正文 | 语义审读并给原句依据 | 关键词出现不能证明承诺已兑现 |
| 判断图片来源记录是否支持本次用途 | 人工核对记录，AI协助整理 | 文件存在并不回答许可范围 |
| 将已确认文件复制到新输出目录 | 脚本 | 路径和覆盖行为可明确定义 |
例如标题写“完整Excel对账脚本”，正文只有三条原则。长度检查会通过，但标题承诺仍失败；不能把“超过800字”写成可发布条件。
脚本必须交代失败怎样返回
一个检查工具可约定：输入为正文路径；成功返回 status=ok 与字节数；空文件返回 empty-body；无文件返回 not-found。调用者据此决定是否继续，而不是读一句“似乎不完整”。
text
输入：body.md，存在但0字节
预期：{"status":"blocked","reason":"empty-body"}
后续：停止打包，不让模型自动补一篇正文。
实现时应区分 UTF-8 文本、路径、输出覆盖和权限错误。同一脚本在自己的电脑能运行，不能自动推出在其他系统也已验证。
这两种情况暂时不要写脚本
规则每次都改：例如负责人尚未确定摘要是80字还是120字、哪些字段必填，先用具体样稿确认标准。只有一次的五行名单核对：人工逐行可复查且更省维护成本时，保留清楚的结果即可。
反过来，规则稳定、频繁重复、错误可观察的步骤值得提取成脚本。比较改造前后时使用同一输入和同一验收依据：不能拿“脚本更快”掩盖漏检，也不能用一次成功宣称所有输入都支持。
下一步
继续阅读与你当前问题相关的教程：
