直接给结果不用铺垫。最近帮朋友调试一个AI agent项目最折磨我的不是模型选型也不是数据清洗而是“需求描述”和“代码逻辑”之间那道隐形的翻译鸿沟。你在脑海里不由自主会冒出一个念头面对人工智能时代我们真正需要的可能不是又一种更新的Python框架或prompt技巧而是一种全新的“程序描述语言”。它不关心你怎么一步步把活干完只关心你到底想要什么剩下的事交给AI自己判断。这个念头就是我写这篇文章的起点一个面向人工智能时代的新型程序描述语言构想暂定就叫“AI语言”。这么说可能有点抽象我给你一个具体的画面。现在写AI应用本质上做的是两层翻译第一层把业务需求翻译成prompt第二层把数据获取、工具调用、结果校验翻译成Python代码。麻烦的是这两层彼此割裂需求一改prompt和代码往往要同步改而且改完还得重新跑一遍看看模型表现是否稳定。大家嘴上说AI提效实际上大量时间耗在这种反复试错里。AI语言的出发点就是把这两层翻译合并成一层你说清楚“要什么、有什么限制、哪些不能碰”系统负责编排模型和工具把结果给你。这篇文章不打算画饼我会把构想拆开讲为什么现有工具不够用、AI语言应该长什么样、对未来AI应用开发会带来什么改变以及如果你想试试可以怎么从零开始搭一个最小可用的DSL。适合对AI应用开发有实际经验的人也适合刚接触AI、想理解“AI编程”到底是什么的新手——后者可以直接跳到第三节的代码草案配合“人工智能学习路径”一起看会更顺。1. 为什么我们需要一门AI语言1.1 现在的开发方式本质上是在做两层翻译先看一个很常见的需求从几十份新闻网页里提取今天关于人工智能的标题做情绪分析最后输出一份摘要。用现在的技术栈来写大概会出现这三坨东西第一坨Python代码。你得写爬虫、写HTML解析、写正文抽取、把抽取结果拼成一个个模型请求再处理返回的JSON最后清洗、汇总。这部分代码本身不复杂但对每个不同的网站解析规则都不一样代码会越来越脏。第二坨prompt。你得精心设计一套提示词告诉模型“你是情绪分析专家输出JSON字段包括sentiment、score、reason”还得处理边界情况比如空文本、讽刺语气、多实体混在一起。第三坨两者之间的胶水代码。它负责把prompt塞进请求、把模型输出套进Pydantic模型、失败重试、成本统计、日志记录。一个看起来简单的小任务代码量轻松破几百行而真正跟业务逻辑相关的可能不到两成。问题就出在这需求变了你要同时改两层。比如客户追加一条“只分析国内来源的新闻”你得先去代码里加过滤逻辑再回prompt里补一句约束。时间一长prompt和代码各自演变没人说得清哪条规则究竟生效在哪一层调试起来就像在一座两层楼的房子里找漏水点楼下的痕迹跟楼上的管道对不上。做了几年工具链之后我越来越确信这套方式不是长久之计。我们不是不会写代码也不是不会写prompt而是缺少一种能把“意图”和“步骤”自然分开的表达载体。1.2 程序描述语言的启示SQL早就给出过答案SQL是程序描述语言Program Description Language最成功的一次实践。你写SELECT city, COUNT(*) FROM users WHERE signup_date 2024-01-01 GROUP BY city根本没管数据库底层是走索引还是全表扫描、是Hash聚合还是归并排序优化器自己决定执行计划。你只描述了想要什么没描述怎么做。这中间有个关键认知把“怎么做”交给引擎不等于失控。恰恰相反因为SQL是声明式的数据库才能在保证结果正确的前提下自由调优程序员也才能用短短几行的描述操作百万行级别的数据。AI语言想做的就是把SQL这种“描述结果”的思维方式延伸到跟大模型和工具打交道的场景里。它要描述的不是“调用哪个API、传什么参数、解析哪个字段”而是“我要什么结果、有哪些约束、什么绝对不能发生”。执行路径是模型自己规划出来的。1.3 AI语言的定位是把“翻译层”本身变成一门语言我知道看到这有人会问Python也不是不能描述意图啊写个函数名analyze_sentiment()不也是意图表达吗没错但这只是“开发者视角”的意图普通业务人员读不懂更不可能自己改。AI语言要占的位置恰好就是这两层之间的缝隙——它既不是给机器读的指令清单也不是一段自由文本而是一种有语法、有类型、有约束检查的结构化表达。业务人员能看懂大概含义开发者能对它做静态检查和单元测试编译器能把它翻译成prompt加工具调用序列。一句话总结AI语言不是要替代Python也不是要替代提示词而是要替代“从业务语言到提示词加代码组合”的那层胶水。这层胶水现在看不见摸不着散落在每个人的代码习惯里是时候用一门语言把它显性化了。2. AI语言的核心设计从意图到约束真要把AI语言落地我设想了五个核心设计维度。它们不是一次性想出来的而是我在反复处理AI应用的调试、安全和成本问题时被倒逼出来的需求。2.1 意图声明让“要什么”成为一等公民第一件事就是把“意图”变成语言里的一等公民就像函数、类在别的语言里那样。语法上我设想用一个task关键字定义任务里面第一行就是intent字段task analyze_feedback { intent: 分析本周用户反馈归纳三类高频问题并给出改进建议 }这个设计背后的逻辑很简单当计算机执行能力足够强时你给它的指令应该从“怎么做”转向“要什么”。类比一下给实习生布置工作最有经验的管理者不会说“你先打开Excel点筛选再求和”而是说“把上季度的销售总额和环比算出来明天中午前给我”。你觉得效果更好也更容易沟通因为对方会自己去找最优路径。意图声明要解决的核心问题是“目标可识别”。现在的prompt工程里目标和背景信息混在一大段文字里模型得自己分辨哪些是任务描述、哪些是上下文、哪些是输出要求。AI语言把意图字段单独拎出来编译器也可以做语法层面的校验——比如没写intent就无法编译这就比自由文本规范得多。2.2 约束与偏好把限制条件显式化只有意图还不够。只告诉AI“分析用户反馈”它可能给你输出一篇漂亮的万字报告但你的预算是30块钱时间只够跑5分钟你需要一段1000字以内的摘要。所以第二要素是约束。我在草案里给了一组约束语法constraints { cost_limit: 12.0 time_budget: 90 max_symbols: 2000 } preferences { model_family: [gemini, claude] style: 专业、克制、有数据支撑 }这些约束不是摆设。运行时会拿着它们做任务规划cost_limit决定了哪些任务可以用贵的模型、哪些必须走便宜模型time_budget决定了能不能让模型反复迭代max_symbols限制了输出token数。所有这些都应在执行之前就由编译器静态检查一遍而不是等到账单出来了才后悔。为什么要把偏好和约束分开我的经验是用户说“我想用gpt-4”心里想的其实是“我想要更聪明的答案”而不是“我要给OpenAI送钱”。模型偏好是手段成本、质量、时延这些才是真正的约束。把两者分开编译器才有机会在满足约束的前提下自动选模型。这一点对普通人尤其友好——普通人不需要知道哪个模型叫什么名字只要说我想要便宜的、快的、还是高质量的。2.3 数据管道描述统一工具操作AI应用绕不开数据。代码里最容易脏的部分就是数据获取和预处理。AI语言的第三个核心就是统一的数据源描述语法inputs { reports: data.source(s3://feedback/weekly.csv, schemacsv) past_wins: data.source(docs://history/win_strategies.md, typetext) }你只需要描述数据在哪、什么格式至于怎么从S3拉文件、怎么解析CSV、PDF怎么切块、文本怎么向量化都是运行时的“数据算子”该干的事。每次执行时编译器生成一个数据血缘记录用哪个原始文件、经过哪道处理、变成了什么结构。这带来的一个额外好处是追责容易——AI给了一个奇怪的结论你可以顺着血缘记录查它到底读了哪些数据而不是像现在这样对着黑盒发呆。2.4 安全护栏把“不能做什么”写进语法这是我觉得最重要、也最容易被人忽略的设计。现在的prompt里当然可以写“不要编造数据”“涉及隐私时提醒我”但这类指令是软约束模型走神时就会忘。AI语言把“安全”变成语法级的硬约束。guardrails { deny: 不得编造具体客户名称 require_human: 当识别到数据异常波动超过20%时 redact: [phone, email, customer_id] }deny是绝对红线运行时可以做一次输出后过滤编译器也能在任务规划阶段检查调用的工具是否可能触碰禁用信息。require_human是升级机制告诉系统“碰到这种情形不要自作主张停下来找人来决策”。redact是自动脱敏字段凡是输入输出里出现的手机号、邮箱、客户ID全部打码。我家里的门锁有反锁机制不是因为我不信任自己会关门而是为了多一道保障。安全护栏同理——它不是对模型的道德拷问而是给执行过程加装物理意义上的熔断器。这个话题在行业里越来越被重视毕竟稍有不慎就会踩到隐私红线不论是个人还是企业都担不起。2.5 可观测与可回滚给prompt一个稳定的“坐标”做过AI应用的人一定有过这种崩溃瞬间上周还表现良好的prompt这周莫名其妙输出质量下降了查来查去发现是通过自然语言聊天改过一轮没人记得改了什么。这就是可观测性缺失的代价。代码有版本管理可以回滚prompt没有。AI语言想在语言层面解决这个问题每次执行都会自动生成一份“执行档案”记录编译后的prompt全文、调用的模型和参数、每个工具的人参参数、耗时和费用。因为源代码是有版本的所以执行档案天然可复现、可diff、可回滚。我用一个粗浅的类比来总结这五点AI语言像一张设计图纸意图是房子的功能需求约束是预算和工期数据管道是建材清单安全护栏是承重墙和安全规范可观测性是施工过程留档。图纸不替工人砌墙但它保证整栋房子不会建歪。3. 语言形态草案一段“看起来像回事”的示例光说不练是假把式。我拿一个偏实际的业务场景——客服反馈分析写了一段AI语言的草案代码。注意这只是一份个人设想没有任何标准组织在背后语法细节也不重要重要的是让你直观感受一下这种新范式。3.1 完整的任务描述示例// feedback_report.ail import std/ai as ai import std/data as data task analyze_feedback { intent: 分析本周用户反馈归纳三类高频问题并给出改进建议 inputs { raw: data.source(s3://feedback/weekly.csv, schemacsv) win: data.source(docs://history/win_strategies.md, typetext) } constraints { cost_limit: 12.0 time_budget: 90 max_symbols: 2000 } preferences { model_family: [gemini, claude] quality: high style: 专业、克制、有数据支撑 } guardrails { deny: 不得编造具体客户名称及联系方式 require_human: 当某种问题类型占比环比变化超过20%时 redact: [phone, email, customer_id] } steps { collect(data: inputs.raw) summarize(theme: 高频问题, by: category) compare(ref: inputs.win) refine(if_confidence_below: 0.8) output(format: markdown, target: docs://reports/weekly_feedback.md) } }一眼看上去它比Python短得多也比自然语言严格得多。没有“怎么爬数据”“怎么切文本”“模型选哪个”这些细节。但我敢说任何一个有产品sense的人哪怕不会编程也能猜个七七八八这是要分析反馈、要对比历史胜案例、要出报告、预算12块、有些东西不能碰。这就是AI语言想达到的——让任务描述本身成为一种可以被业务方review的契约。3.2 运行时怎么把它翻译成行动接下来是核心问题这段描述被谁执行我的设想是AI语言有一个“编译器”但它的产物不是机器码而是三件套一个结构清晰的prompt模板、一组工具调用序列、一段结果校验规则。比如上面的例子编译器大概会生成这么个执行计划[1] ExtractCSVColumns(sources3://feedback/weekly.csv, columns[id,content,category,created_at]) [2] BuildPrompt(context{modal:feedback_data, task:identify_top_issues, period:本周}) [3] SummarizeTopIssues(top_k3, max_tokens800) [4] LoadRetrievalIndex(sourcedocs://history/win_strategies.md) [5] CompareIssuesWithStrategies(beforestep3.output, refstep4.output) [6] RefineIfNeeded(conditionconfidence0.8, fallbackhuman) [7] RenderMarkdownReport(targetdocs://reports/weekly_feedback.md) [8] ApplyGuardrails(redact[phone,email,customer_id])这还只是一个粗略示意。真正运行的时候模型可能会把第2步和第3步合并也可能发现图表比列表更适合展示于是调用一个额外的图表工具。因为约束写得很清楚运行时在满足cost_limit和time_budget的前提下有一定自主权调整执行路径。你要说了这不就是AutoGPT那套思路吗对精神是相似的但定位不一样。AutoGPT是一个具体应用AI语言是表达这种应用的工具。相当于AutoGPT是一次性的手工流水线AI语言想做成通用机床——你可以用它拧出一台AutoGPT也可以描述一个完全不同的任务。3.3 与Python和Rust技术栈的协同AI语言不是活在真空里的。真到了实用阶段它必须跟现有生态打通。我设想了两层的协同方式。第一层自定义工具接口。AI语言允许你声明一个工具并指向一个已有实现。比如团队在Rust里写了一个高性能的MySQL查询组件在AI语言里注册就行tool def query_database { signature: 查询MySQL数据库返回行级数据 implement: rust_pkg(../tools/mysql_query) permissions { read_only: true max_rows: 10000 } }最近社区里对“基于Rust语言构建AI agent”的讨论越来越多方向上是说得通的——Rust在内存安全、并发性能和运行时可控性上确实有优势。AI语言面临同样的托管问题模型调用的并发、工具的沙箱隔离、大量中间数据的流转如果都放在没有硬边界的内存模型里迟早出事故。让Rust做运行时底座Python做数据科学扩展AI语言做上层描述是一个我很看好的组合。第二层模型接口适配层。AI语言标准库里定义model接口具体是调OpenAI还是Anthropic取决于运行时配置。这样语言本身不被任何模型厂商绑死换模型只是改一行配置文件的事。你会发现因为有了约束和偏好运行时甚至可以动态拆任务——贵的模型负责最难的判断便宜的模型负责机械抽取最后在总成本限制内完成所有活。3.4 编译产物为什么重要最后聊一下“编译产物”这个概念为什么关键。普通编程里编译产物是机器码没人会去读。AI语言的编译产物是prompt加工具调用序列这玩意儿恰恰是人类要审查的。这意味着AI代码审查从“读你的代码逻辑”变成“看你声明的意图和生成的执行计划是否匹配”。而且因为prompt是从结构化的intent和constraints里生成的prompt本身不再是一坨偷偷藏在代码角落的字符串而是可追踪、可版本管理的工程产物。这套逻辑我们在团队里用很朴素的方式验证过把prompt拆成“角色背景任务约束输出格式”五段分别填模板调试效率和稳定性明显高于一个整体自然段。AI语言无非是对这类经验做更彻底的语法化。4. 设计取舍与争议任何新的编程范式提出来第一波质疑总是有价值的。我自己也拿这些问题拷问过这个构想尤其是以下几个值得摆到台面上来说清楚。4.1 会不会只是“提示词套了个壳”最尖锐的质疑AI语言编译来编译去最后不就是生成一段prompt加JSON工具调用吗你直接写个带模板的Python函数不也一样我的回答是魔鬼在细节里。现在用Python封装prompt固然可行但封装的职责全凭自觉有人会把prompt写在配置文件里有人散落在代码里有人直接用Git记录自然语言对话标准完全不一致。AI语言把这些约定变成语法强制——你只能在intent里写目标、在constraints里写限制、在guardrails里写红线。结构化之后才能有静态检查和自动优化超没超成本、有没有触碰deny字段、脱敏规则有没有生效这些在编译期就能查。一句话问题不在于“能不能封装”而在于“封装出来的对象有没有被命名和固化”。AI语言的语法就是对过去两三年prompt工程最佳实践的固化。4.2 和LangChain、AutoGPT这些流行框架的边界我做了个对比表你可以更直观地看区别对比项LangChain/AutoGPT类框架AI语言构想本质现有语言上的库/应用独立的程序描述语言表达方式用代码调用组件用声明描述任务意图可见性藏在代码流程里语法级暴露约束检查靠开发者自觉编译期静态检查安全护栏链路上手动插回调语言级硬约束学习门槛要会Python和框架API会结构化描述即可入读与模型解耦切换API要改代码运行时适配层自动处理我的态度是这样框架是探索期的过渡方案让开发者的生产力立刻提升语言是沉淀期的终局方案把好用的模式固化下来。框架会继续存在但如果AI应用开发真的普及到普通人级别一套正式的描述语言几乎是必然出现的。4.3 如何避免成为“低代码2.0”低代码平台被诟病的核心有三点高度封闭、调试困难、生成的代码不可控。AI语言如果走上这条路也会死。我给自己划了三条红线第一不做可视化拖拽。文本是可diff、可审查、可版本管理的图形界面做不到。AI语言坚持文本优先就算以后有IDE高亮或辅助编辑底层还是一段普通文本。第二不强行封装一切。AI语言只管“意图、约束、编排、护栏”这四件事业务计算、日志、监控这些走传统代码和运营体系各有专攻。第三保留逃生舱口。任何声明式的语法都允许内联一段普通代码遇到编译器和运行时表达不了的特殊逻辑直接跳出来写Python或Rust。类似SQL里的存储过程逃逸口保证了表达力的兜底。4.4 模型能力会变语言设计不是白做了吗有一个合理的担心大模型升级换代这么快去年语言模型还不会调工具今天已经会了你设计好了语言明天模型能力变了怎么办我的想法是这个问题不致命。AI语言描述的是“意图”不是“特定模型的当前能力上限”。今天模型只能做到三步推理编译器就把任务拆成五个子步骤调用明年模型自己能一步做完编译器就只生成一个高层prompt。语言层面不变变的是运行时适配层。这就像SQL二十多年没大变底下的执行引擎换了四代。稳定的声明语法恰恰是应对底层快速变化的最好缓冲。5. 从构想到落地最小可行的探索路径如果你读到这觉得这个构想有点意思想自己在项目里验证一下我给你一条踩过坑才总结出来的落地路径。核心建议是别一上来就想做一门编译器先做一个DSL哪怕是YAML配上Python都行。5.1 第一步先用YAML定义任务的“骨架”用一门真正的语言启动几乎注定烂尾因为你会陷进语法细节和解析器开发里出不来。先在团队内定义一版任务描述规范用YAML或JSON就够了task: analyze_feedback intent: 分析本周用户反馈归纳三类高频问题并给出改进建议 inputs: raw: source: s3://feedback/weekly.csv schema: csv win: source: docs://history/win_strategies.md constraints: cost_limit: 12.0 time_budget: 90 max_symbols: 2000 guardrails: deny: - 不得编造具体客户名称 redact: - phone - email写解析器这件事不难难的是让团队接受“任务描述本身是一个需要被review的文档”。我们的实践是每一个AI特性都先写这么一份YAML再进入prompt和代码实现阶段。坚持一周你就会发现讨论重心从“怎么实现”变成了“我们到底要什么效果”这已经是巨大的进步了。5.2 第二步用Python搭一个最小解释器有了YAML规范下一步就是做一个Plline Runner。我用Python写过一版最小骨架核心长这样# ai_lang_runner.py import asyncio from dataclasses import dataclass, field from typing import Any dataclass class TaskSpec: intent: str constraints: dict[str, Any] field(default_factorydict) inputs: dict[str, Any] field(default_factorydict) guardrails: list[str] field(default_factorylist) steps: list[str] field(default_factorylist) class PipelineRunner: def __init__(self, tool_registry: dict[str, Any], planner: Any): self.tools tool_registry self.planner planner async def run(self, spec: TaskSpec) - dict[str, Any]: # 1. 让planner根据intent生成执行计划 plan await self.planner.plan(spec) # 2. 按计划调度工具 results [] for step in plan: tool self.tools.get(step[tool]) if not tool: raise ValueError(funknown tool: {step[tool]}) result await tool.run(step[params]) results.append(result) self._check_constraints(result, spec.constraints) # 3. 应用护栏 output self._format_output(results, spec) return self._apply_guardrails(output, spec.guardrails) def _check_constraints(self, result, constraints): if result.get(cost, 0) constraints.get(cost_limit, float(inf)): raise RuntimeError(cost limit exceeded) if result.get(elapsed_ms, 0) constraints.get(time_budget, 10**9) * 1000: raise RuntimeError(time budget exceeded) def _apply_guardrails(self, output, guardrails): for rule in guardrails: # 这里可以把deny、redact规则依次套用 pass return output这里面最关键的组件是self.planner。它接收一个任务规格返回一串工具调用步骤。在最粗糙的版本里planner甚至可以直接用一次大模型调用来生成步骤清单。但你一旦实现了这层就已经把“意图到计划”的转换逻辑从业务代码里拆出来了——这恰好就是AI语言与传统代码的分水岭。5.3 第三步搭建验证与调试工具DSL跑起来简单要能规模化使用必须配三件工具。第一dry-run模式。不发起真实模型调用只把计划渲染出来给人看。干没干、用了哪些工具、预计花费多少一目了然。第二trace记录。每次执行完毕把生成prompt、模型参数、工具返回、约束检查结果都存到结构化日志里。出现问题直接看trace比抓瞎快得多。第三断言能力。在任务描述里支持类似expect output contains 改进建议的写法。这样每个AI任务都能像普通代码一样跑回归测试。这一步非常重要——AI任务不是不能测试而是从前没人把它当成被测对象。一旦任务声明和运行时分离测试就顺理成章地成为语言的一部分。这三样工具做完你其实已经拥有一个微型AI语言的雏形。后续再慢慢加静态检查、模型适配、IDE插件就可以走得更远。它也可以反向作为“人工智能学习路径”里的一个练手项目把DSL解析、规划器、工具调用和验证机制完整走一遍对AI系统的运作理解会远超单纯调用API。6. 常见问题速查给新手的几个解答每次跟人聊这个构想总会被抛来一些高度相似的疑问。我把它们整理成一份速查列表都是基于实际讨论和一段时间的实践给出的回答谈不上标准答案但能帮你少走弯路。AI语言是不是就是中文编程不是。中文编程是用中文替换关键字底层思路仍然是命令式——如果...那么...否则...。AI语言的关键不是用什么自然语言形式而是把“目标描述”和“路径规划”分层设计。你自己用中文写YAML也是一种实现方式但核心是语法结构。写AI语言还需要懂算法吗不需要传统的算法训练。你更需要的是结构化思维能把一个模糊的目标拆成可校验的约束比如成本上限、时间要求、质量底线、风险红线。这些能力更接近产品经理和项目管理者而不是算法工程师。这个语言能控制提示词工程那些手工技巧吗能而且这正是目的。人工写prompt的技巧——角色设定、例子示范、输出格式——在AI语言里被固化成编译规则。模型不会随机忘了输出JSON因为运行时的校验逻辑会在产出不符合格式时自动修复。AI语言适合什么样的团队先尝试适合三类团队一是做AI agent应用、被工具编排复杂度困扰的团队二是做企业内部AI助手、经常要更新prompt却难以追踪变更的团队三是做安全敏感型AI应用、需要把护栏逻辑和业务逻辑分开审计的团队。这三类都有一个共同特征他们迟早会被“prompt难以工程化管理”这个瓶颈卡住。和人工智能训练师这个职业有关系吗关系很大。当前对AI训练师的要求偏重于数据标注和prompt调优而AI语言成熟后描述任务、设计约束、审查执行计划会变成核心技能。这更像一份“AI任务架构师”的工作——不需要写传统代码但需要比普通用户更懂模型的边界和风险。这个职业画像会随着AI语言的普及而愈发清晰。7. 对普通人的意义AI语言可能颠覆的不只是写代码的方式最后我想跳出开发者视角聊聊。你看最近的热搜词里“人工智能正从尝鲜工具变日常帮手”这条路越来越明确。但现在的现实是普通人用AI的能力上限取决于会不会写一段线性prompt。自然语言当然门槛最低但自然语言的弱点是太容易遗漏约束、太容易被带偏、回滚调试很麻烦。AI语言的长期价值在于它把“给AI派活”这件事变成了一门可以学、可以教、可以传授的技能。你不需要会写Python但你需要会表达目标、限定边界、定义验收标准。这套技能翻译成传统职业里的说法就是“需求分析能力”。所以它适合的人比传统编程要广泛得多。我给非程序员朋友的建议也简单不用等AI语言真的成为标准现在就可以开始用声明式思维去使用AI。每次让AI写东西前先写一句话目标再列三条限制最后补一条输出格式要求。坚持一段时间你就会发现AI输出稳定性的提升是肉眼可见的。这个习惯就是在为未来的AI语言备书。8. 关于这个构想我的几点心里话从一个念头到一篇完整的构想说实话我自己也整理了很久思路。回想这些年做AI应用开发的过程最深的体会是工具链的成熟程度决定了技术的普及速度。SQL的出现让数据查询不再只是数学家的玩具浏览器的标准化让互联网不再只是极客的专利。如果AI的能力要被更多人用起来那么“如何描述任务”这件事迟早要被标准化。我特别想跟读到这里的开发者说一句不要觉得这个构想离你很远也不要盲目等着某个组织来定义标准。先在团队的小项目里尝试声明式任务描述先建一套YAML规范把prompt和工具调用的边界梳理清楚哪怕听起来一点也不酷。踩过几次坑之后你会明白我在说什么。真到了那一天或许有人会在这个基础上把语法做严谨、编译器写完善、生态搭起来一门真正意义上的AI语言就会从这些泥土气息浓厚的实践里长出来。而这项工程的第一步可能就是你明天在编辑器里打开的那个文件。
