每天让 AI 做重复的事，prompt 模板和输出格式几乎一模一样，但你从来没想过把它们"写下来"，因为你下意识觉得------这是跟 AI 聊出来的，不是程序能跑的。
但 Nika 认为："If you do the same AI task twice, make it a workflow.（如果你把同一个 AI 任务做了两次，就应该把它变成一个工作流）"
Nika 是用 Rust 开发的 AI 工作流语言与引擎。它的核心理念是：把可重复的 AI 任务，转化为可运行、可审查、可对比、可分享的文件。
上手体验
安装很简单，使用 x-cmd 一行命令就能搞定：
bash
x install nika装完零配置跑第一个工作流：
bash
nika examples run 01-hello --model mock/echo不需要 API key，不需要模型服务器------mock/echo 模式让你的第一个工作流在几秒内跑起来。想看真实推理？把 mock/echo 换成 ollama/llama3.2:3b 就行。
AI 时代的 "Dockerfile"或"SQL"
可以把它理解为 AI 时代的"Dockerfile"或"SQL" ------正如 Dockerfile 定义了容器，SQL 定义了数据库查询，Nika 文件则定义了一个 AI 工作流。
可以把 Nika 理解为 AI 时代的"Dockerfile"。Dockerfile 出现之前，每个团队用 bash 装依赖、设环境变量、配置网络，出了问题谁也复现不了。Dockerfile 用声明式文件统一了：你声明需要什么，Docker 保证运行结果一致。而 Nika 是写一个 YAML 描述 AI 任务和依赖，然后审计、运行、留下哈希链轨迹。
而且它把这件事推得更远------口号不是 "Workflow as Code"，而是 "Intent as Code"。Workflow 描述"先 A 再 B 最后 C"；Intent 描述"我想达到什么效果"。Nika 让你把意图写成代码，运行时替你决定怎么实现。
四个动词，覆盖 AI 操作的全部
整门语言只有四个动词：
infer：调用 LLM（任何模型，本地或云端）exec：执行 shell 命令invoke：调用工具或 MCP 服务agent：启动一个自主循环的 Agent
这四个动词覆盖了 AI 工作流涉及的全部操作面。通用工作流引擎给你几百个概念让你学------Airflow 的 DAG、Dagster 的 Op 和 Asset、Temporal 的 Workflow 和 Activity，每一个都是为大企业数据流水线设计的复杂系统。
Nika 反着来：只有四个动词，专为 AI 场景裁剪 。Unix 哲学------小接口，大组合。Airflow/Dagster 调度 SQL/Spark/ETL 任务面向数据工程；Nika 调度模型调用、Agent 循环、工具调用面向 AI 工作流。它在一个此前没人认真做的位置上------AI 工作流作为一等公民。
"花 token 前先审计"------这件事帮你省下真金白银
用过 LLM API 的人都明白一件事：每一次无效调用都是在烧钱。
你把 prompt 发过去，模型推理了半天，返回一个错误------因为你引用的工具名写错了，或者依赖的任务不存在。每次无效调用少则几美分，多则几块钱。一个工作流跑十次错五次，一天的 token 账单就翻一倍。
Nika 的做法是：在你花掉哪怕一个 token 之前，静态审计就把工作流文件查了个遍。
跑 nika check，它在几毫秒内告诉你：
- 你引用了不存在的任务？提示
NIKA-VAR-001：未找到引用 tasks.digets------你是想说 tasks.digest 吧？（注意，它甚至会猜你想打什么字） - 工具名拼错了？
TOOLS: nika:wrte 不是合法内置工具------你是想说 nika:write 吧？ - 某个任务的操作超过了权限边界？直接指出逃逸的精确位置和修复方案
- 费用没设上限？它会算出一个成本天花板，算不出来就诚实标注
UNBOUNDED，绝不写假$0
审计通过之后才运行。运行完之后，.nika/traces/ 目录下留下一条防篡改的哈希链轨迹------nika trace verify 可以验证它是否被篡改过。
这套设计直接回应了一个现实问题：**当 AI 开始替你做真实世界的事情时，你需要一个"谁在什么时候做了什么、花了多少钱"的可审计记录。**这个需求跟十年前金融系统对数据库事务日志的需求一模一样------只不过今天的"事务"是模型调用。
本地优先，模型自由
Nika 默认本地运行。装一个 Ollama，它就能用你本地的 Llama、Qwen、Mistral。没有本地模型也没关系------它内置了 mock/echo 模拟器，零配置就能跑通工作流做测试。
云端也行------它支持任何 OpenAI 兼容的 API。关键是：工作流文件不绑定模型 。你在本地用 Ollama 测试完，部署到生产环境切换到云端模型------同一个 .nika.yaml 文件，一行不用改。
更狠的是 Nika 连模型都能自己 serve。nika model pull 下载 GGUF，nika model serve 起一个兼容 OpenAI 的本地端点------不需要额外的模型服务器，一个二进制搞定。
Agent 写，你来 review
Nika 的设计哲学里有一个很特别的假设：工作流文件是由 Agent 写出来的，人负责审查和批准。
所以它提供了 nika init------一键在项目里铺好 schema 定义和 AGENTS.md，让 Claude Code、Cursor、Codex 这些 Agent 能"正确地"写出工作流。nika mcp 暴露一个只读 Oracle，让 Agent 可以随时查询工作流结构而不会乱改。
这个协作模式是：Agent 发现一个好用的 prompt 链条，把它写成一个 .nika.yaml；你 review 这个文件（它可读、可 diff、可版本控制）；通过之后，nika run 执行，留下审计轨迹。
你每周在重复的 AI 操作是什么？试着把它写成一个 Nika 工作流。评论区告诉我你选了哪个任务。