前言

最近在调研测试用例的写法，想找一种对人和AI都友好的格式，然后发现了Gherkin。它是一种用Given/When/Then三段式来描述软件行为的纯文本语言，比如"Given用户已登录，When点击下单，Then订单创建成功"。2008年随Cucumber框架一起诞生，原本是为了让业务人员和开发者用同一种语言写验收条件。

调研的过程中我越来越有一个感觉：Markdown、PlantUML、Mermaid、Gherkin这些诞生了十几二十年的纯文本格式，正在AI时代集体翻红。它们当初为人类可读性做的设计，恰好也是LLM需要的。

一、Markdown、Gherkin、Mermaid，正在焕发新的生机

先说一个容易混淆的事。我一开始把Markdown、YAML、Gherkin、Mermaid、Cron表达式这些东西都叫"语言"，但严格说它们不是一回事。比如，常见的几种不同的分类模式

分类不重要，它们真正重要的共同点是：纯文本、有结构、人机双方都能处理。叫它语言、格式、还是notation，不影响它在AI场景下好用这个事实。

二、为什么Markdown比Word对AI更友好

很多人以为Word对AI不友好是因为它是二进制格式。其实不是。.docx本质上是一堆XML打包成的zip，技术上是纯文本。

问题在两个地方。

第一，信噪比太低。你在Word里写一行"Hello"，对应的XML可能是十几行标签，内容被样式信息淹没了。Markdown里就是Hello，一个token。同样的内容，Markdown消耗的token可能是WordXML的十分之一。

第二，语义不清晰。Word里你想表达"这是一个章节标题"，可能有好几种方式：用内置的"标题1"样式、手动把字体调成24px加粗、用一个自定义样式叫"我的标题"。这三种视觉上可能一模一样，但在XML里表达完全不同。AI拿到第二种，它只知道"这段文字比较大比较粗"，得自己猜这是不是标题。

Markdown没有这个歧义。##就是二级标题，没有第二种理解。

信噪比和语义清晰度不只是"体验好不好"的问题，是直接影响AI输出质量的。

LLM的注意力机制有个特点：context越长，模型对每个token的关注度越分散。塞进去一堆<w:rFontsw:ascii="Calibri"/>这种噪音，不只是浪费token额度，是实打实地稀释了模型对有效内容的注意力。

所以这类纯文本格式对AI友好，本质上是因为它们跟LLM的工作方式恰好匹配：

• • Token效率高—同样的内容消耗更少的token
• • 语义密度高—每个token都在传递有效信息，注意力不会浪费
• • 模式稳定—##永远是标题，Given/When/Then永远是测试场景的前置条件/操作/预期结果，模型识别模式的置信度很高

三、用AI-Friendly的思路改造研发工作流

我最近在尝试用这个思路改造需求交付的工具，为了更好落地，计划先从自己能控制的环节入手，用效果说话

第一步：测试用例→Gherkin

这是最容易落地的，切换到Gherkin之后，AI可以从需求描述自动生成测试场景初稿、检查覆盖度、甚至直接生成自动化测试代码

第二步：技术方案→Markdown+Mermaid

技术方案本来就是程序员写给程序员看的，切换成本最低。Markdown写正文、Mermaid画流程图和时序图，存到Git仓库里。方案跟代码放在一起能做版本管理，PR里能直接review技术方案

第三步：需求描述→加一层转换

建议不要让产品经理改格式，而是在中间加一层：产品经理继续用富文本写需求，开发接需求的时候用AI把富文本转成结构化的Markdown模板加Gherkin验收条件，转完拿给产品确认。

四、AI-Friendly，不是AI-Ready

我一开始把这个思路叫"AI-Ready"，后来觉得不对，改成了AI-Friendly。

这两个词差别挺大。AI-Ready暗示"为了AI而做准备"，有种刻意改造的意思。AI-Friendly更准确：这个东西本身对人就是好的，同时恰好对AI也友好。

Gherkin2008年就有了，设计初衷是让业务人员和开发者能用同一种语言描述需求，跟AI没半点关系。Markdown2004年发明的时候，目标就是"写起来舒服、读起来清楚"。十几年后发现它们刚好是LLM最容易处理的格式，纯属副产品。

所以做技术选型时有个实用的判断标准，不仅要看对人类是否友好，更要看对AI是否友好。除了测试用例，链路图是不是也能用文本描述出来？这样让AI来做企业级微服务架构下的技术方案，好像也更容易了