脚本的下一站：让自然语言直接成为可执行入口

原文链接： AI 小老六

几十年来，脚本的基本假设都没有变过：你要先写代码，再让机器执行。

哪怕是 shell 脚本这种相对轻量的形式，本质上仍然是把一组固定指令按顺序交给解释器。脚本作者负责把逻辑写死，执行者只是在给定参数后触发运行。可当大模型进入命令行工具链后，这个边界开始被打破了。

现在，一个脚本文件里写的未必是命令，也可以是一段自然语言任务描述。

从解释器入口，切到模型入口

这件事之所以成立，关键在shebang。

在 Unix 世界里，shebang决定了一个可执行文件应该交给谁来解释。过去它指向bash、python、node这类传统解释器；而现在，它也可以指向llm这样的模型命令行工具。于是脚本文件本身不再一定是程序代码，它可以只是一个 prompt 片段，或者是一份带参数和工具定义的模板。

最简单的形式看起来甚至有点反直觉：

#!/usr/bin/env -S llm -f Generate an SVG of a pelican riding a bicycle

这个文件只要加上执行权限，就已经是一段可以运行的“脚本”了。它不是在告诉解释器“如何一步步生成 SVG”，而是在声明“我要什么结果”，剩下的过程交给模型完成。

*图：自然语言文本直接转化为代码或命令的魔法过程*

为什么这不是花哨演示，而是接口变化

很多人第一次看到这种写法，会把它当成一个新奇技巧。但如果再往下想一层，会发现它改动的其实是“脚本接口”的定义方式。

以前我们把脚本理解为：

• • 一组确定步骤
• • 一套显式分支
• • 一个固定输出

而在LLM 原生脚本里，脚本更像是：

• • 一个任务意图
• • 一组约束条件
• • 一套可调用能力
• • 一个由模型决定执行路径的运行时

也就是说，脚本正在从“程序说明书”转向“目标声明文件”。这种变化对自动化的意义很大，因为很多人想自动化的事情，本来就很难写成严谨代码，却很容易说清楚自己想要什么。

shebang + prompt + tools会变成一个新组合

更有意思的，不是把一句自然语言跑起来，而是给这种脚本加上工具能力。

例如，脚本可以声明允许模型调用时间工具、数学工具，甚至是自定义 Python 函数。再进一步，它还可以通过模板方式引入参数、系统提示词、外部 API 查询逻辑。此时，脚本已经不只是“把 prompt 发给模型”，而是在构造一个小型的任务执行环境。

下面这张图，比较适合理解它的运行路径：

*图：LLM 原生脚本的运行路径*

一旦工具可以被调用，很多原来看起来“不适合脚本”的事情就开始适合了。比如：

• • 查询知识库后回答问题
• • 调用时间或计算工具生成结果
• • 读取远程数据再生成摘要
• • 基于参数动态改写输出风格
• • 生成代码、图表、文案等内容型结果

这实际上把脚本从“机械执行器”扩展成了“任务编排器”。

模板化，是它真正走向实用的关键

如果只是把一句 prompt 放进文件里，这种能力确实还比较玩具化。但一旦支持模板，事情就不一样了。

模板意味着你可以在脚本中同时定义：

当这些要素被集中到一个文件中时，脚本就变成了一个“可分发的 LLM 能力单元”。你把文件发给别人，对方无需理解背后的实现细节，只要运行它，就能得到相同类型的能力入口。

这非常像我们过去分发 shell 工具、Makefile 或小型 CLI 的方式，只不过现在分发的是“任务定义 + 模型接口 + 工具权限”。

对个人效率工具意味着什么

这类脚本最先改变的，会是个人自动化场景。

过去很多人想做一点轻量自动化，往往会在“手动做算了”和“认真写个脚本”之间摇摆。因为真正阻碍大家的，不是没有想法，而是工程门槛太高。一个只想把文字整理成摘要、把数据查出来写成说明、把一个问题变成一段结构化输出的人，未必要先学会一整套编程控制流。

自然语言脚本的意义，就是把自动化门槛向“会描述问题”这一侧大幅拉低。

*图：通过简单的语言指挥复杂的自动化机器运转*

它特别适合那些满足以下条件的任务：

• • 输入相对开放，不容易写死规则
• • 输出更重表达和结构，而不是严格数值计算
• • 执行过程可能需要动态判断路径
• • 最终交付物是文本、代码草稿、图表或解释

在这些场景里，传统脚本不够灵活，完整应用又太重，而LLM 原生脚本刚好卡在中间。

对工程团队也有启发

这不只是个人效率技巧，对工程团队同样有启发。

因为它提示我们，未来很多内部工具不一定非要做成完整 UI，也不一定先做成复杂服务。某些轻量任务完全可以先沉淀为“可执行模板”：既能调用内部接口，又能接受自然语言输入，还保留脚本化分发和版本管理的优势。

这类工具一旦进入团队协作，就可能演化出新的工作流：

• • 用模板脚本生成周报、变更说明或事故复盘初稿
• • 用知识检索工具回答内部系统问题
• • 用参数化脚本为不同角色输出不同版本内容
• • 用统一模板封装一类反复出现的分析动作

说到底，这是一种比“聊天窗口问模型”更稳定、比“正式开发应用”更轻量的中间形态。

仍然要警惕什么

当然，这类脚本不是没有边界。

只要执行路径部分交给模型决定，就意味着结果存在波动；只要接入外部工具，就需要考虑权限、安全与可审计性；只要输出可以直接进入生产链路，就需要处理稳定性和校验问题。

所以它最适合的，不是那些对确定性极端敏感的底层流程，而是那些原本就需要人类判断、整理和润色的半自动化任务。在这些任务里，模型带来的“弹性”往往是优点，而不是缺点。

结语

从历史上看，脚本每一次变得更强大，都是因为它离人的意图更近了一步。命令行把我们从二进制程序里解放出来，shell 把多个工具连成流程，脚本语言把复杂逻辑写得更轻，而现在，大模型正把脚本继续往“直接表达目标”这个方向推进。

让自然语言成为可执行入口，未必会取代传统脚本，但它很可能会成为自动化体系里一个越来越重要的新层。它的意义不在于炫技，而在于让更多任务第一次拥有了“写得出来，也跑得起来”的可能。