Nika：用代码表达“意图“——AI 工作流的语言层

Nika用代码表达意图——AI 工作流的语言层“Intent as Code”——把重复的 AI 任务变成可运行、可审查、可分享的文件。四个动词一个 Rust 二进制文件本地优先随意切换模型。设计思想是像 SQL 之于 PostgreSQL、Dockerfile 之于 Docker 那样Nika 是 AI 工作流的语言标准。一个真实的问题你的日常工作中有多少 AI 任务是重复做的每周五写周报。每次发版后整理 release notes。每天看竞品动态。每次 PR 合并前做代码审查风险评估。每周分析用户反馈。这些任务你做了一遍又一遍。每次开一个新的 ChatGPT 对话、重新描述一遍需求、把结果复制出来。然后下次再做一次。一模一样的事情。这不是 AI 的问题这是流程没有抽象化的问题。SQL 之所以有用不是因为你能用它查一次数据——而是因为你能把同样的查询存成文件、反复执行、交给不同的人运行。AI 领域还没有这样的语言层。Nika 想做这件事。Nika 是什么“Nika 是一个工作流语言”——这句话不够准确。更准确的表述是Nika 是一个意图表达语言它的一等公民是 AI 工作流。一个 Nika 工作流就是一个.nika.yaml文件。你可以把它放在 Git 仓库里、提交 PR review、加入 CI 流水线、交给同事运行。四个动词别无其他动词做什么infer调用 LLM——任意模型本地或云端exec执行 shell 命令invoke调用工具或 MCP 服务器agent运行一个自主循环直到任务完成一个文件、四个动词、一个 Rust 二进制文件。没有运行时没有云服务。你想用哪个模型就用哪个。没有密钥的时候内置的 mock/echo 模式也能离线运行。一个实际的例子假设你要在每次 PR 合入前做一次风险评估。手工做很麻烦但写成一个 Nika 工作流就很简单# review.nika.yamlnika:v1workflow:pr-risk-reviewmodel:ollama/qwen3.5:9btasks:-id:diffexec:command:git diff origin/main...HEADcapture:structured-id:assesswith:{patch:${{tasks.diff.output.stdout}}}infer:prompt:评估这个 diff 的风险机密信息、破坏性变更、缺少测试\n${{ with.patch }}schema:type:objectrequired:[risk]properties:risk:{type:string,enum:[low,medium,high]}-id:commentwhen:${{tasks.assess.output.risk high}}invoke:tool:mcp:github/pr-commentargs:{body:${{tasks.assess.output}}}这个工作流的执行逻辑很清晰diff读 git diff→ assessLLM 判断风险→ comment高风险才发 comment依赖关系让每个工作流自动形成一个有向无环图DAG独立的任务并行执行、agent 步骤扇出、join 等待所有分支完成。而整个执行计划在执行前就已经确定、计费和审计过了。检查先行这是 Nika 最巧妙的设计之一nika check——在消耗任何 token 之前先做一次全面的静态审计。$ nika check brief.nika.yaml ✔ PLAN 2 wave(s) · 2 task(s) · max parallelism 1 ✔ SECRETS 没有信息流泄露 ✔ TYPES 每个深度输出引用都匹配声明的类型 ✔ TOOLS 每个 nika: 工具都是规范的 ✔ ARGS 每个调用参数都已声明、每个必要参数都已提供 ✔ SCHEMA 每个自定义 schema 都是可满足的 ✔ clean — audit done before a single token was spent这意味着你在调用任何模型之前就能知道你的工作流是不是正确的。不存在跑了一半才发现有个参数没传这种情况。检查的内容包括静态计划依赖关系和并行度是否合理成本上限预估的 token 消耗和费用机密流机密信息会不会意外泄露类型匹配每个步骤的输出是否匹配下一步的输入类型工具检查每个工具是否可用、参数是否完整安全能力模型Nika 有一个叫作read-XOR-write读异或写的安全模型。这个设计很特别一个被标记为读的步骤不能偷偷写东西每个写操作都必须明确声明并经过授权工作流文件本身就是安全边界在permits:块里声明工作流可以做什么访问哪些主机读写哪些路径执行哪些程序调用哪些工具一旦声明默认就是拒绝所有未授权操作。一个步骤越过了permits:边界Nika 会在运行前静态捕获它并指出具体的修复方法。设计思想Nika 的开发团队在文档里写了一句话点明了产品的定位最接近的类比不是产品。是标准。SQL。Dockerfile。一个可移植的规范和一个参考引擎。语言本身就是贡献不是用来卖的产品。这句话很重要。SQL 之所以成功不是因为它的实现有多好而是因为语言本身是开放的。同样Nika 的引擎是 AGPL-3.0 的参考实现语言规范是 Apache-2.0 的开放标准。这和Nika 是工作流语言的定位是一致的——语言层的价值远远大于引擎本身。引擎是参考实现。当 AI 智能体开始在这上面行动时它们需要一个可验证的行动语言——AI 能写、人类能审、机器能跑。但目前现有的工作流工具都做不到这件事。Nika 做的事情本质上是提供一个可验证的行动语言。优点维度描述本地优先不依赖云端 API模型可以本地跑模型无关随时切换模型工作流不变静态审计在真正运行前做检查防止浪费双许可AGPL 商业许可Grafana 模式DAG 执行并行执行灵活可控4 个动词不多不少干净的设计单二进制再没有运行时可携带可追溯执行记录完整且规范——人机都能读可审可审的 verification planADC 法官会审推的代码审查后评分预期符合度ADC 再确认资产安全状况有两次除了确认资产其余推的 ADC 审查。免得证明资产可以审的 ADC 审查。推的 ADC 审查。纯净AGPL 授权服务商用户有权得源码没有更多商业限制不能接受 AGPL 的可以购买商业许可。AGPL 授权与商业许可并行溯源完整每一笔记录都完整包括释放均可追溯可重复每次运行都可以重复固定输出待改善之处维度描述YAML 可读复杂工作流 YAML 会很长语言本身及嵌套关系不易读功能缺失没有调度系统没有可视化终端优化LSP 体验尚可但还有改进空间生态较弱社区太小第三方工具和支持太少商业价值和前景竞争格局Nika 的竞争对手不是 ChatGPT、Claude 这些对话产品。它的竞争对手是 Airflow、Temporal、LangChain/LangGraph 这种工作流和编排工具。核心竞争力AI-native——从第一天就是为 AI 工作流设计的不像 Airflow 是为数据处理设计的本地优先——不像 Temporal 需要服务器集群一个二进制文件就能跑安全模型——read-XOR-write、permits 边界声明这些在传统工作流工具里几乎没有语言层定位——如果 Nika 成功成为一个标准它的价值会远超过一个产品商业模式参考引擎是 AGPL-3.0商业许可Grafana 模式给不能接受 AGPL 的组织与 SuperNovae 生态的其他产品协同现实挑战Nika 面临的最大挑战不是技术而是生态。一个新的语言标准需要足够的采用率才能生存。在工作流编排这个领域Airflow 几乎是事实标准Temporal 在微服务编排上也很强势。Nika 要在 AI 工作流这个细分领域打出口碑才能获得生存空间。写在最后Nika 是一件让人值得期待的产品。不是因为它已经有多好了——它才 v0.91问题很多——而是因为它的定位很精准。Intent as Code这个 slogan本身就是在说把意图写成代码来去可跟踪可审计。Nika 做的事情本质上是一个可验证的行动语言。当 AI 智能体开始在这上面行动时它们需要一个可验证的行动语言——AI 能写、人类能审、机器能跑。作者写了一篇文章来阐述这一思想。在文章里他提到了一句很熟悉的话一切都是模糊的直到你试图让它精确。这句话我在 Steve Krouse 的文章里也读到过。Steve 当时是在说AI 帮你把英语变成能运行的代码你不断地根据自己的感觉去调整那些精确的产物。在这个过程中你所谓的感觉被磨得更锋利了。Nika 的工作流语言也是在做同样的事——把模糊的意图翻译成精确的文件。如果你正在寻找把重复的 AI 任务代码化的方案Nika 值得你关注。项目地址github.com/supernovae-st/nika网站nika.sh语言规范supernovae-st/nika-specSources:Nika - GitHubNika Spec - GitHubLearning to code is still worthwhile - Steve Krouse