★ FEATURED ARTICLE 写AI应用写了一年多我越来越觉得哪里不对。现在所谓的“AI编程”本质上不是编程而是——提需求。你把一段自然语言扔给模型模型吐出一段代码你拿去跑了跑能跑就谢天谢地不能跑就再喂一轮。我们管这个叫“开发”但开发过程里最核心的环节——描述清楚“程序到底要做什么、怎么算对、边界在哪里”——反而被丢给了自然语言。而自然语言这东西用于人类沟通还行用于描述一台机器必须执行的逻辑根本不够精确。这正是我想聊的面向人工智能时代的新型程序描述语言构想。既不是给大家画个“未来代码长这样”的饼也不是教大家怎么调Prompt。我想拆解的是如果我们要设计一门“给AI读、也给人审”的语言它应该长什么样语法核心是什么和传统语言、和自然语言的本质区别在哪里以及——这个构想里哪些已经能在今天用Rust手搓出来。1. 现在的AI开发断在哪一条线上1.1 我们其实在“求”模型不是在“编”程序先聊现状。现在写一个AI应用流程大概是这样的你写一段英文描述丢给模型它给你生成代码你复制、运行、报错、再粘贴错误信息回去让它改循环几轮终于跑通。这个流程表面上叫“AI辅助编程”本质上更像“结对编程里那个AI是实习生你是那个不断给实习生擦屁股的导师”。问题出在哪出在意图没有被结构化。你的所有需求都藏在自然语言的字缝里模型要猜猜错了你就得重新描述。你写的不是程序你写的是“彩票”——模型生成的代码质量取决于它当时的心情虽然技术上说是概率采样。特别是做Agent类应用的时候这个痛点被放大到极致。在上一个项目里我需要让AI Agent基于Rust的工具链去自主规划任务、调用工具、修正错误循环。结果代码逻辑不难写最难的是让模型稳定地理解“什么时候算成功、什么时候该放弃、什么错误可以重试、什么错误必须上报”。这些约束写成文档都容易被模型忽略更别说你根本没法把它们写进自然语言。1.2 急需被回答的三个问题总结下来当前AI应用开发有三大断层意图断层程序员脑子里清楚的功能逻辑没法被结构化表达给模型只能靠自然语言“翻译一遍”翻译必有损耗。验证断层模型生成的代码我们只能靠运行和试错来验证它是否正确缺少编译期构造期的语义检查。过程断层整个开发过程变成“猜—生成—运行—报错—再猜”的黑箱循环不可审计、不可拆分、不可复用。这三个断层我思来想去觉得缺的正是一层“语言”——一种既面向人类意图表达、又面向机器可执行验证的中间表达层。你可以叫它AI语言本质上它是一种“程序描述语言Program Description Language”。2. 破局思路把“意图”从自然语言里捞出来2.1 什么叫“程序描述语言”它和编程语言什么关系传统编程语言的核心是“How”——你怎么一步步做。自然语言的核心是“What”——你想达成什么效果。程序描述语言要坐落在中间它描述的不是“怎么做”而是“这个程序该具备什么行为、满足什么约束、接受什么输入、产出什么可接受结果”。打个比方。传统编程像是给施工队画施工图必须精确到每一根钢筋怎么放、每一块砖怎么砌。自然语言是你说一句“给我盖个能住的房子”施工队AI自己理解、自己发挥。程序描述语言呢它是设计任务书总面积、层数、朝向、采光要求、承重标准、验收条件全都写清楚至于用砖混还是框架、工期怎么排那是施工方AI的事。这就是它的核心价值把“程序员的判断力”沉淀成机器可读的规范把“模型生成能力”用规范的椭球体圈住不让它跑飞。2.2 一个关键转变代码生成从“生成代码”变成“生成实现”在“AI语言”的范式里程序员写的不再是代码写的是意图规范Intent Specification。举个例子传统写一个排序函数你写的是循环、比较、交换在AI语言里你写的是输入任意一个长度为N的数组元素类型为可比较输出一个数组且是输入数组的全排列约束输出数组任意相邻两个元素满足偏序关系验收执行结果不抛异常、复杂度期望在O(N log N)量级然后——这是最要命的区别——由AI去填充“实现”这层。模型自己选择是快排还是归并自己生成真正的可执行代码这里我们在原型里直接用Rust来生成。程序员只负责“程序应该长什么样”模型负责“程序到底长什么样”。好那么问题来了——你怎么保证模型生成的实现真的满足你的意图这就必须把“验证”装进语言本身而不是靠运行时人肉检查。2.3 “意图”不是一等公民的编程语言都不配叫AI语言传统编程语言里函数是组织单位对象是组织单位。AI语言里的组织单位应该叫意图Intent。一个意图由五部分组成输入域Input Domain这个模块能吃进来的数据范围是什么输出域Output Domain它吐出来的东西该长什么样类型、结构、边界约束条件Constraints必须满足的不变式比如排序后的长度不变、金额计算不能溢出资源预算Resource Budget期望的时间/空间复杂度、允许的工具调用次数、最大Token消耗验收准则Acceptance Criteria一组可自动检验的断言或测试用例以及允许的失败率把这个五元组装进语言语法里AI生成的代码就不是“凭空出现的黑盒子”而是“带合同边界的影子员工”。你还不完全清楚它的内部实现但你知道该怎么考核它。3. 关于语法设计如果让我从零开始我会这么设计3.1 从“可读性”转向“可验证性”很多人在讨论“未来编程语言长什么样”时第一反应是“更自然、更好读”——这是错的。未来编程语言的第一标准是“可验证”其次才是可读。可读是为了人做审查可验证是为了机器做确认两者缺一不可但可验证是底线。底层方案我们自然不可能从汇编赌起合适的基础设施是基于Rust来做语法解析、约束求解和代码生成管线。选Rust不是因为情怀而是因为AI Agent生态里Rust的位置内存安全、类型系统强、IO模型干净非常适合承载“语言解析语义验证生成脚本”这套重活。你不需要用Rust写你的业务逻辑但用Rust做AI语言的工具链底座是当下最顺手的选择。3.2 三个核心语法原语对于“AI语言”的骨架我目前最看好的三个语法原语是Intent声明块这是整个语言的心脏。一个Intent用来描述你需要AI替你完成的任务契约intent sort_array { input: VecT where T: Ord output: VecT guarantee: sorted(result) is_permutation(input, result) budget: { time: O(n log n), calls: 1 } acceptance: [ sort([3,1,2]) [1,2,3], sort([]) [] ] }注意这里的acceptance不是写给人看的注释是写在配置文件里可以直接自动跑起来的测试断言。看到没描述意图的过程本身就是半形式化的比纯自然语言精确得多又比直接写Rust实现抽象得多。Verification规则块每个Intent都可以挂一个或多个verification块它用来定义“AI生成的代码必须通过什么检查才算合格”verify sort_array { property: output.len input.len property: for_all i in 1..output.len output[i-1] output[i] strategy: unit_test property_based static_analysis }这里的strategy很有意思它告诉工具链你要用什么级别的验证单测断言过一遍、属性随机测试跑一遍、还是连静态分析器也要过一遍。等级越高越贵耗时、Token消耗你可以在开发期用低等级快速迭代、发布前切到高等级全面验证。Generation策略块这就是“让AI干活但不让它放飞”的缰绳generate sort_array with { strategy: rust_gpt4o_mini }一行接一行语言的边界就出来了程序员写清楚“干嘛、有啥边界、怎么算对”模型去写“怎么实现”工具链去检查“对不对”。程序员的注意力从抠实现细节转移到抠验收条件模型的自由度从瞎猜收敛到实现一个已被定义清楚的函数。3.3 对传统“编译-运行”模型的颠覆传统语言里代码写完编译器把它翻译成机器码运行。AI语言里代码写完“意图编译器”把这个五元组Intent打包成一个生成任务发送给代码生成模型然后它可能跑出好几个候选实现每个都拿verification规则去验验不过的丢弃验得过的挑一个最优的进入交付物。从“你写代码机器执行”变成了“你写契约模型写代码机器验证契约”。这才是名副其实的“AI语言”——用户关心的不是某段具体代码而是这个程序在全生命周期内始终保证所承诺的行为契约。4. 实操审视这个构想离落地还差多少东西4.1 今天能动手的部分别误会上面说的不是空中楼阁。恰恰相反因为工具链基础件已经成熟我目前手头已经用Rust搭了一个最小原型走通了一条“Intent契约 → 大模型生成 → Rust测试驱动验证”的流水线。有几个环节是完全可以今天就实现的语法解析器用chumsky这类Rust解析库解析Intent描述几百行代码就能做个靠谱的Demo。测试断言执行器把acceptance里的断言翻译成Rust测试用例cargo test直接跑。属性测试集成对接proptest库引入随机生成边界数据来测不变量。模型调用封装把Intent块序列化成Prompt模板发给模型约束它在规定的函数签名内生成实现。多候选淘汰制同一个请求调35次模型拿测试结果打分选最优容错率直线上升。这套东西只要工程上踏实不用等任何新理论。它本质上就是把你之前写Prompt的经验固化进编译器流程里——只是这次Prompt不是一段白话而是结构化的五元组。4.2 踩过的坑与发现的问题真动手做了才会碰到文档里不写的问题值得单独分享一下。最大的坑大模型经常“听懂人话但不读契约”。你把Intent描述得非常清楚边界、约束、验收全写了结果模型生成的代码里函数名改了、入参类型不对、断言比较逻辑整个写反。怎么解决不是靠“多写两句Prompt”——是靠在编译流程上做强制检查。我在原型里加了一步“生成后契约适配器”检查模型输出的函数签名是否与Intent描述对齐不对齐直接打回重生成。这让成功率提高了不少。任何时候都别指望模型“自觉遵守”工具链必须强制审查。第二个坑所谓“验证”不是只跑几个用例就完了。一开始我觉得能跑通单元测试就万事大吉结果有一次一个排序实现明明通过了所有固定用例但proptest随机数据一跑就露馅它复制了一个原数组的引用根本没排序。从此我学乖了——固定断言是开胃菜属性测试才是正餐。凡是声称要保证不变量的命题必须随机化大量验证。这也是我把verification块放在语言核心层的原因。第三个坑Token开销远大于写传统代码。生成一个几十行的函数你可能要消耗几万Token验不过再生成一次又是几万。这就要求语言层面把“资源预算”做成显式设计逼着开发者设上限而不是无脑重试。我见过同事做类似原型一个函数烧掉几百个API请求才通过验证——低效得令人心疼预算约束是真的能救命的。4.3 什么时候该把“AI语言”用在生产环境很多人看到这里会热血沸腾想在所有项目里推这套。我的看法是分阶段Stage 1现在就能做做“意图模板库”。把你的团队里最常写的那类模块参数清洗、数据转换、状态判定、异常兜底沉淀成Intent模板模型按模板生成测试验证。这个阶段不需要完整语言实现一张结构化的Prompt模板Cargo测试闭环就够。Stage 2半年到一年做特定领域的意图编译器。选定一个垂直场景比如数据处理管道、REST接口逻辑、Agent工具编排把这套意图五元组固化进一个小体积DSL内嵌各种属性测试策略。Stage 3更远形成通用的AI语言规范。多个领域DSL往上抽象共享语法、共享验证内核、共享生成后端这才是那个“完整意义上的AI语言”。5. 与之相关的几个大方向Agent、训练师与产品思维5.1 基于Rust的Agent工具链正好承接这层语言现在业界做AI Agent尤其在Rust生态里大家热衷的方向是搞记忆管理、工具注册、任务规划循环但说实话大多停在“运行时调度”层没碰“意图契约”层。我认为这里恰恰藏着更大的价值。Agent为什么总是失控因为它把意图和实现揉在最脆弱的自然语言里。如果你把Agent的子任务全部描述为Intent规划器只负责把大目标拆成若干Intent契约执行器负责逐条验证那么Agent的可靠性会明显上一个档次——它的每个动作都有验收标准不合格就不承认执行过。这不只是理论我实测下来的Mini原型里每次任务都跑“规划→生成→验证→重试”循环相比之前直接让模型回答的方式最终结果的质量稳定性强了很多。5.2 对“人工智能训练师”这个工种的新含义“人工智能训练师”现在越来越像职业正名但我观察的一个风向是未来训练师的核心能力可能不只是“喂数据调模型”而是把业务方模糊的需求翻译成结构化的意图契约——而这恰恰是AI语言最核心的人机接口。我特别喜欢一个类比传统电气工程里电气工程师不亲手扭螺丝但他必须能读懂电路图。未来以AI语言训练的“意图工程师”能读懂“意图五元组”能把老板一句“让系统更智能”翻译成Input、Output、Constraints、Budget、Acceptance——这才是人工智能时代真正抢手的人。你现在就可以开始刻意练习把任何随口说的需求三句话内改写成意图五元组。5.3 别把AI语言做成了“给模型舔脚”的玄幻设计还有一点必须提醒AI语言既然是语言就必须“固执”。不能因为大模型口语理解能力强就把语法设计得越来越像聊天软件。语言的作用是约束双方——既约束AI生成自由也约束人的表达随意。语法不够强大家又会退回“无限制聊天式写代码”。哪怕未来通用模型越来越强“让模型更自由”的边际收益一定会衰减“让意图更确定”的边际收益反而会持续上涨。这跟我们过去三十年软件工程干的事一脉相承我们对机器的要求越清晰机器交付的系统就越可靠。6. 几个具体的配置选项和实验参数可直接参考6.1 最小原型的目录结构与指令参考如果你想自己试试这是我在Rust原型里摸索出来的最小结构ai-lang-prototype/ ├── Cargo.toml ├── intents/ │ └── sort_array.intent # Intent描述文件 ├── generated/ │ └── sort_array.rs # 模型生成的实现 ├── verifications/ │ └── sort_array_tests.rs # 自动生成的验证测试 └── src/ ├── parser.rs # intent文件解析 ├── prompt_builder.rs # 把Intent序列化成模型Prompt ├── generator_client.rs # 调用大模型生成代码 └── verifier.rs # 运行cargo test proptest运行流程大致是三步# 1. 解析intent生成Prompt和初始验证骨架 cargo run -- parse intents/sort_array.intent # 2. 调用模型生成实现自动写入generated目录 cargo run -- generate intents/sort_array.intent --model gpt4o-mini --samples 3 # 3. 自动跑验证输出通过/失败报告 cargo run -- verify intents/sort_array.intent跑通了你就感受到那层窗户纸有多薄编译器只是一个Pipeline模型只是你的后端点验证器才是真正的裁判。6.2 参数选择和经验阈值如果你自己搓这些参数值得记下来参数作用我的经验值生成候选数--samples每次要模型生成几个实现35太少容易全废太多烧钱验证策略分级按关键程度分层开发期unit_test发布前property_basedproptest用例数属性随机测试轮数默认1001000关键路径拉满1万重试阈值同一Intent最多失败重试几次3次超过说明契约本身描述有问题有些开发者以为“验证失败就重试”无限重试总能过——不对。我反复强调过连续失败3次以上大概率是你的Intention描述跟模型的理解存在系统性错位这时候该调整的是契约本身不是继续压榨模型。这是很多人在这里烧钱烧时间才明白的道理。6.3 和大模型打交道的具体提示词模板设计把Intent转成Prompt时不能简单地把字段丢给模型。我打磨过相对稳定的模板结构核心顺序是先给身份和任务边界 → 再给契约五元组的格式化文本 → 然后给“绝对不做的事” → 最后给输出格式约束。一个简化版你是一个严格的Rust代码生成器。你将收到一份结构化任务契约。你必须严格依据契约生成实现。 【输入域】VecT where T: Ord 【输出域】VecT 【不可违背的不变式】排序后的长度等于输入长度结果升序结果必须是输入的全排列。 【验收示例】sort([3,1,2]) [1,2,3] 【资源预算】O(n log n) 时间O(log n) 额外空间 【禁止行为】不得修改输入数组不得返回原数组引用不得使用不安全的unsafe代码。 请只输出一个Rust函数包含完整实现和单元测试。不要输出任何解释性文字。这个模板里最关键的是“禁止行为”这一块。传统程序员写Prompt时很少写这条但模型最爱在这类地方放飞。把你在验证器里已经写好的不变式翻译成“禁止行为”整个生成质量直接上一个台阶。7. 别把这个构想神话它有一堆至今没解决的难题7.1 难题一契约本身也可能写错我最怕听到一种论调“有了AI语言大模型就可靠了。”可靠的前提是意图契约本身是对的。但现实里描述清楚一个模糊需求的边界本身就是最难的事。很多情况下程序员自己都没想清楚“成功到底长什么样”你让他写验收准则他写出来的也是错的。这是个认识论问题不是语法问题。我的建议是承认弱分工——契约写不准时先允许模型给出“假设性实现”程序员拿那个实现当引子反过来检视自己的契约理解。先有一坨能跑的代码再反推正确契约比空对空写契约更高效。7.2 难题二验证能力的天花板理论上说让AI生成代码后做验证需要对“程序行为正确”有一个数学般纯正的判定。可现实世界全是坑浮点数误差算不算错超时算不算错调外部API偶尔抖一下算不算错形式化验证在纯函数领域好使一进IO、并发、分布式就变成概率问题了。所以我始终不敢拍胸脯说AI语言能保证验证“绝对正确”。它实际能做的是把“大概率正确”的门槛拉高一截。在关键路径上你还得靠人肉走查、压测、线上监控兜底。7.3 难题三生成模型在变强AI语言会不会被绕过还有一个非常大的哲学问题如果未来的大模型足够强强到“你随便说一句白话它就全懂了根本不需要结构化契约”怎么办那AI语言还有存在意义吗我的意见很坚定模型越强越需要契约而不是反向。因为模型越强它的能力边界越大你越难靠直觉预测它会做什么它可能会用一个完全合法但极其诡异的实现满足你写的约束。你不把约束写得明明白白、可验证、可审计你根本没法知道它背着你干了什么。AI语言与其说是工具不如说是“照妖镜”——能力越大的模型越需要这面镜子把它的行为照得清清楚楚。未来大模型当然会更聪明但这个“更聪明”恰恰使得给行为定边界、让行为可验证这件事变得无比重要。8. 延伸去想AI语言背后的角色跃迁与生态想象8.1 开发者的角色从“作者”变成“验收官”如果按这套构想去推演未来AI应用的开发者日常会变成这样一半时间在写意图契约一半时间在看验证报告代码本身几乎不是人写的。我不少同行听了这描述挺恐慌觉得程序员要变成“写需求文档的”。但实际体验下来完全不是那个感觉写高质量契约的脑力消耗一点不比抠实现细节低而且更有创造性。你看一个函数实现你只能判断“好不好”很少能判断“该不该存在”。但在AI语言里你要判断的是“这个意图该不该存在、边界画在哪、什么该算成功”——这已经是产品和系统设计的活了。职级没降反而上探到系统设计与需求工程的交叉地带。8.2 训练师、产品经理、程序员会逐渐趋同顺着热词列表里“人工智能训练师职业画像”这个话题走我认为——再过几年“训练师”“Prompt工程师”“意图工程师”“AI产品经理”这几个角色的边界会越来越模糊。他们做的是同一件事用结构化的语言把人类需求翻译成机器和模型都能理解和验证的契约。这不只是职业叙事更是教育方向。高校里“人工智能导论”和“大数据人工智能时代”的课程都在普及基础知识但真正缺的一课是意图结构化表达——如何把模糊人类语言转译成精确、可验证、可追责的机器语义。这门技能大概率会成为人工智能时代的“写作能力”或“编程思维”那样的通识教育。8.3 最大的想象力意图市场的出现如果意图契约成为AI时代的“代码”那自然会产生一个交换意图的市场——就像今天GitHub交换代码一样。你的团队在排序、数据清洗、Agent编排上沉淀了一套验证严谨的Intent模板完全可以开源或出售。别人拿到这套模板不需要关心里面是怎么实现的插入自己的验证配置模型自动帮他们生成符合各自场景的实现。原创文章、开源代码的边界会被改写。真正值钱的不再是某段具体实现而是那个经过千锤百炼的意图五元组。它记录的是“一个可靠程序应该承担的所有承诺”。写到这里我其实已经把AI语言构想的骨架、语法核心、落地路径、已知问题都摊开了。再多说一句我自己的实践体会吧。过去半年里我在这个方向上踩过一个很深的坑——总是在追求“描述得更精确一点”结果意图文件越写越长验证规则越堆越多系统反而更难用。后来才想明白AI语言不是用来消灭不确定性的而是用来把不确定性压缩到可处理的范围内的。接受模型有时会给出你没想到的实现接受验证永远无法穷尽所有可能把这些都当作系统约束而不是Bug你的设计就顺了。真要有读者打算在这个方向做点什么我的建议很简单不要一开始就奔着“设计一门语言”去先从“给现有开发流程加一层契约和验证”开始把最常写的那类函数沉淀成模板用框架逼着自己和模型都守规矩。跑通一个闭环比纸上谈十个语法重要得多。
阅读完成 · 觉得有帮助？
