一个英文文本文件，现在也能像脚本一样跑。

Simon Willison 最近演示了一个小技巧：文件第一行写 #!/usr/bin/env -S llm -f，后面直接跟英文提示词，比如 Generate an SVG of a pelican riding a bicycle。保存、加执行权限，再像运行 shell 脚本一样执行它，llm 会把文件内容交给模型，生成一张“鹈鹕骑自行车”的 SVG。

这不是 shebang 的新发明。shebang 本来就是 Unix 世界里指定解释器的机制。新意在于，这次解释器换成了 LLM CLI，自然语言被塞进了传统命令行入口。

发生了什么：提示词、工具和模板都能被脚本化

这套玩法的门槛不在语法，而在环境。要跑起来，本机需要有 llm CLI、可用模型配置，以及被明确暴露出来的工具或模板。它不是操作系统原生支持“英文脚本”，而是 shebang 把文件交给 llm 解释。

几个例子足够说明问题：

用法写法它实际做了什么
直接提示词#!/usr/bin/env -S llm -f把文件正文作为提示词交给模型，比如生成 SVG
工具调用llm -T llm_time -f让提示词调用 llm_time，拿到当前时间后再生成内容
YAML 模板llm -t在模板里定义模型、system prompt 和工具函数
调试输出--td打印模型调用了哪些工具、参数是什么、返回了什么

最值得看的，是 YAML 模板那段。

模板里可以指定模型，比如 gpt-5.4-mini；写 system prompt，例如 Use tools to run calculations；再暴露两个 Python 函数：add 和 multiply。

然后运行：

./calc.sh 'what is 2344 * 5252 + 134' --td

调试输出显示了两次工具调用：

  • 先调用 `multiply({'a'.2344, 'b': 5252})，得到 12310688`
  • 再调用 `add({'a'.12310688, 'b': 134})，得到 12310822`

这个细节很关键。

结果不是模型在“心算”，也不是模型能随便执行任意代码。它调用的是 llm 模板机制里暴露的受控函数。模型负责选择工具，工具负责返回确定结果。

Willison 还给了更复杂的方向：结合 Datasette SQL API，让脚本回答关于他博客内容的问题。也就是说，提示词文件不只生成文本，还能接数据源、调工具、组织答案。

为什么重要：自然语言成了自动化的软接口

我不太买账“LLM 要替代 shell”这种说法。证据不够，方向也不对。

shell、Python、Makefile 的核心价值，是确定性。输入一样，流程一样，输出应该可预期。LLM 提示词脚本的价值，恰好在另一边：它能处理含糊意图，能省掉一部分胶水代码，也能把工具调用包装成更像人话的入口。

所以它更像一种软接口。

下面还是确定性工具：函数、SQL、API、文件系统。上面多了一层自然语言：你告诉它要什么，它决定怎么调用工具。

这对两类读者影响最直接：

读者可以怎么用该避开什么
熟悉命令行和脚本自动化的开发者把一次性查询、文本生成、轻量数据处理封装成可执行提示词文件不要把它放进关键生产链路，尤其不要替代确定性脚本
关注 LLM tool use / agent 工作流的人用 shebang + template 快速验证工具调用路径、调试模型如何选工具不要把 demo 当成 agent 平台能力；权限、日志、回滚都还要自己设计

这就是它的现实位置：适合实验、个人自动化、内部小工具、低风险辅助任务。不适合账务计算、发布流程、权限敏感操作、不可回滚的数据修改。

“天下熙熙，皆为利来。”放在这里很贴。开发者会接受这种写法，不是因为它更优雅，而是因为它省事。省事会推动采用，也会制造偷懒。

历史上很多工具都是这么进工作流的。shell 管道、cron、Excel 宏、浏览器插件，都先从“方便一下”开始。后来真正决定命运的，不是方便本身，而是边界有没有补上。

LLM shebang 也一样。

接下来该看什么：不是模型多聪明，而是边界多硬

这件事目前只能说明一种实验性模式成立：自然语言可以被放进可执行文件，并通过 CLI 接上工具调用。

它还不能说明 LLM 脚本已经可靠替代传统脚本。更不能说明企业可以放心把它接进核心自动化。

真正要看的，是几个硬变量：

变量为什么要看
权限控制模型能调用哪些工具、读哪些数据、写哪些位置，必须可限制
调试日志出错时要知道模型调用了什么，而不是只看到一段漂亮回答
可复现性同一个提示词、同一组工具，结果能否稳定到可接受
回滚机制一旦工具改了真实数据，必须能撤回或隔离影响
模板治理system prompt、函数、模型版本变化，都应能追踪

这里最容易被低估的是责任链。

传统脚本错了，通常能追到代码、参数、环境。LLM 脚本错了，责任会分散到提示词、模型选择、工具描述、函数实现、权限配置、外部数据。每一层都可能说“我只是照着上一层做”。

这才是团队采用时最该谨慎的地方。

个人开发者可以先拿它做低风险任务：生成文件、查资料、调内部只读数据、封装常用问答。团队如果要试，最好从只读工具开始，打开 --td 这类调试输出，把日志留住，再谈写操作。

模型看起来越像脚本，越要记得它不是脚本。确定性工具负责干活，LLM 负责理解意图。两者一旦混在一起，省下的是输入成本，增加的是治理成本。

这就是这次演示真正有意思的地方。

不是英文文件突然变成了程序，而是命令行多了一个会猜意图的入口。它很好用，也很容易被用过头。边界补不上，它就是玩具；边界补上了，它才可能成为严肃自动化的一层薄壳。