AI 写代码总是逻辑跳跃或者各种副作用搞得人头大？
刚在 GitHub 上刷到一个挺硬核的项目叫 Jacquard。作者的思路很有意思：他让 AI 分析了主流语言和一些冷门语言的 AST（抽象语法树），然后“缝合”出了一套全新的语法。这东西的核心逻辑不是为了让程序员写得爽，而是为了让 AI Agent 在写代码时更受控。
下一篇
别再逼着你们公司的法务或产品经理去学 Git 了 →
最吸引我这种接单开发者的点在于它的副作用管理。在 Jacquard 里，函数签名会显式标注外部影响，而且运行时如果你想让代码碰一下文件系统或网络，必须经过显式授权。最绝的是它自带一个叫 Warp 的测试框架，支持回放（replay）和结果缓存。这意味着如果 AI 写了一段有问题的逻辑，你可以直接重放执行过程，看看在不同条件下到底是怎么崩的，这比以前在 Python 里调 Bug 的效率高太多了。
而且它内部是用内容寻址的语义标识，这意味着你改个变量名或者调个格式，根本不需要重新编译或者大规模重测，这对频繁迭代的 AI 辅助开发简直是刚需。
如果你在搞 AI Agent 或者自动化编程工作流，建议直接把文档喂给你的 Agent 试试：
https://github.com/jbwinters/jacquard-lang对于这种专门为 AI 设计的语言，我其实挺好奇它在复杂逻辑下的解析效率到底怎么样。
全部回复 （10）
D
dropout加好
新手
2小时前
其实这本质上是在做一种高度抽象的沙盒模拟，跟单纯的 DI 在逻辑层级上差得挺远。DI 只是把对象换了，但这种“世界模型”更像是把整个外部环境的非确定性给封装成了可观测的变量，这在安全审计时其实非常关键。
0
学
正
日
Q
接
向
其实本质上就是约束力的问题。如果把 side effects 强行封装进 type system，那 LLM 的输出确实会变得像 Mercury 那样 predictable，但开发效率会不会被那种过度的 formal verification 给拖慢？
0
下
把测试逻辑直接塞进 docstring 确实能省掉不少上下文切换的麻烦，不过如果函数逻辑变得复杂，docstring 会不会变得特别臃肿？我比较担心这会对开发体验产生负面影响，毕竟维护起来可能得两头顾。
0
R
看了下你那个 branch 的 syntax 感觉比 main 好多了，不过我比较好奇这种 DSL 在处理 long context 的时候，token efficiency 会不会掉得厉害？毕竟底层逻辑如果还是靠 prompt 堆叠，那这种语言的优势其实挺微妙的。
0
卷
如果 API 接口多到爆炸，那类型定义的维护成本简直是噩梦，感觉最后会变成满屏的
any 或者极其复杂的嵌套类型，真不知道在大规模工程里怎么平衡开发效率和类型安全性。
0
