Banks：用编程语言的方式写 Prompt

痛点：为什么 f-strings 写 Prompt 会让人抓狂？

想象一下这个场景：你要给大模型发送一个复杂的提示词，里面有系统提示、几条用户消息、一些工具定义，还要根据上下文条件决定是否插入某段内容。用 f-string 写出来大概是这样的：

prompt = f"""
系统提示: 你是一个{role}助手
{"额外说明: 用户是VIP" if is_vip else ""}
对话历史:
{% raw %}{% for msg in history %}{% endraw %}
    {msg['role']}: {msg['content']}
{% raw %}{% endfor %}{% endraw %}
用户问题: {question}
"""

这还算简单的。一旦提示词变长、变量增多、条件嵌套，f-string 很快就变成一团乱麻——缩进混乱、调试困难、变量名冲突、无法复用。更要命的是：提示词是代码的一部分，却没有得到代码应有的待遇。

masci/banks 就是来解决这个问题的。

项目背景

Banks 的名字来自电影《降临》(Arrival) 中的语言学家 Louise Banks——作者以此暗示这是一个帮助人类与 AI "对话"的工具。项目由意大利开发者 Massimiliano Pippi 创建，2023 年 6 月发布，至今保持活跃维护（最近一次提交在 2026 年 7 月）。

作者的核心观点很清晰："如果你还在用 f-string 写 Prompt，继续读下去。"

项目使用 MIT 许可证，主要语言 Python，依赖 hatch 作为构建工具，整体工程化水平较高——有完整的 CI/CD (GitHub Actions)、测试覆盖率报告 (Coveralls)、类型检查 (mypy)、代码格式 (ruff)，文档托管在 GitHub Pages。

核心技术：基于 Jinja2 的 Prompt 模板语言

Banks 的本质是一个增强型 Jinja2 模板引擎，专为 LLM Prompt 场景定制。它保留了 Jinja2 的所有语法（变量 {{ }}、循环 {% for %}、条件 {% if %}、过滤器 |safe），同时添加了 Prompt 领域特有的扩展。

结构化消息：chat 扩展

最实用的扩展是 {% chat %} 标签，可以将模板内容渲染为结构化的 ChatMessage 对象：

{% chat role="system" %}
你是一个专业的{{profession}}助手。
{% endchat %}

{% chat role="user" %}
用户上传了一张图片，请分析: {{ image_url }}
{% endchat %}

渲染后得到标准的多模态消息格式，支持文本、图片 URL（本地路径自动转 base64）、音频和文档，可以直接传给 OpenAI/Anthropic API 的 messages 参数。

多模态内容：图片、音频、文档

Banks 提供了多个过滤器来处理不同类型的内容：

• {{ image_url | image }} — 自动识别 URL、本地路径或 base64，格式化为多模态消息块
• {{ audio_path | audio }} — 支持音频文件转 base64 并附带格式信息
• {{ doc_path | document }} — 支持 PDF/Word 等文档类型
• {{ text | cache_control("no-store") }} — 控制 LLM 的缓存策略（Anthropic 特有）

这些过滤器解决了多模态 Prompt 拼装中最繁琐的部分——文件路径转 API 格式。

工具调用：completion 扩展

{% completion %} 标签支持在模板中嵌入工具定义：

{% completion %}
{
  "name": "get_weather",
  "description": "获取城市天气",
  "parameters": {{ schema | tojson }}
}
{% endcompletion %}

配合 @tool 过滤器，可以直接从 Python 函数生成 JSON Schema，零样板代码。

Prompt 版本管理与注册表

Banks 提供了本地存储 Prompt 的机制，支持版本控制、参数验证、元数据管理，适合在大型项目中系统化管理大量 Prompt。

代码架构分析

架构类型: 事件驱动的函数式处理管线，核心模块分层清晰。

技术栈:

• 模板引擎: Jinja2 (SandboxedEnvironment，安全隔离)
• 数据验证: Pydantic v2 (类型安全)
• 异步支持: asyncio (AsyncPrompt)
• 构建工具: Hatch
• 测试: pytest + pytest-asyncio
• 代码质量: ruff + mypy + coveralls

源码结构:

src/banks/
  __init__.py          # 导出 Prompt, AsyncPrompt, config, env
  config.py            # 全局配置管理（平台目录、数据路径）
  cache.py             # 渲染缓存协议（可自定义 Redis 等）
  env.py               # Jinja2 环境初始化 + 扩展注册
  errors.py            # 自定义异常（MissingDependencyError、CanaryWordError 等）
  extensions/
    chat.py            # {% chat %} 结构化消息扩展
    completion.py      # {% completion %} 工具调用扩展
  filters/
    image.py           # 图片处理过滤器
    audio.py           # 音频处理过滤器
    document.py        # 文档处理过滤器
    tool.py            # @tool 过滤器（函数到 JSON Schema）
    lemmatize.py       # 词形还原过滤器
    cache_control.py   # 缓存控制过滤器
    xml.py             # XML 格式过滤器
    video.py           # 视频过滤器

代码质量评分: 85/100。项目有完善测试（asyncio 支持），类型注解覆盖较全，ruff/mypy 双工具检查。缺少复杂度指标报告和安全审计流程。

文档质量: 优秀。有 MkDocs 文档站，Cookbook 提供 Jupyter Notebook 示例（Prompt 缓存、多版本管理、上下文补全）。

局限性：不适合谁？

1. 简单的单次 Prompt — 如果只是偶尔发一条消息，f-string 足够，加 Banks 反而增加复杂度
2. 无 Python 环境 — 非 Python 项目（如 JS/Go）无法使用
3. 无运行时验证 — Jinja2 模板语法错误只在渲染时才报错，无 IDE 支持
4. Prompt 版本管理 — 依赖本地文件系统，无云端同步或协作功能

行业意义

Banks 代表了 Prompt 工程化的一个重要方向：把 Prompt 当代码对待。128 stars 虽不算高，但它解决的问题是真实且普遍的。随着 LLM 应用复杂度提升，这类工具的价值会愈发明显——不是替代提示词技巧，而是让复杂的提示词系统变得可维护。

当前 AI 编程助手赛道火热，Banks 填补了"生产级 Prompt 模板管理"这一细分空白，与 LangChain Prompt Template、PromptTools 等项目形成互补。相比之下，Banks 更轻量、更 Pythonic，不绑定特定 LLM 提供商。