用 AI 久了，你大概率会遇到这些东西：
AGENTS.md
config.yaml
data.json
records.jsonl
report.html第一次看到时，很容易把它们当成“程序员才需要懂的文件格式”。
其实没必要把它们想得那么技术。
了解 Markdown、YAML、JSON、JSONL 和 HTML，真正有价值的地方，不是为了学编程，而是为了知道：
什么样的信息，用什么方式交给 AI，后面最好用。
写一篇文章、填一张表、做一份配置、记录一批流水，本来就不会使用同一种表达方式。AI 也是一样。
所以这篇文章只想解决一个问题：
以后再看到这些格式，不需要记住所有语法，但至少知道它是什么、为什么存在、什么时候该用。
先记住一句话：
Markdown 管内容，YAML 管配置，JSON 管结构，JSONL 管批量记录，HTML 管呈现。
知道它们是什么，是了解 AI；知道什么时候该用哪个，才是在真正用好 AI。
一、为什么值得了解这些格式？
假设你手里有一份 Excel，里面有 3000 条用户反馈。
你当然可以直接把 Excel 扔给 AI：
帮我分析一下。
一次性分析没有问题。
但如果以后还要持续新增数据、自动分类、统计结果，甚至把处理结果继续交给其他 AI 或程序，事情就不一样了。
原始数据可能只是：
| 用户反馈 | 产品 |
|---|---|
| 搜索太慢了 | App |
| 希望增加导出功能 | Web |
经过 AI 分析后，可能变成：
| 用户反馈 | 类型 | 优先级 | 建议 |
|---|---|---|---|
| 搜索太慢了 | 性能 | 高 | 优化搜索 |
| 希望增加导出功能 | 功能建议 | 中 | 增加导出 |
真正发生的变化不是“多了几列”，而是：
原来给人看的信息，开始变成可以被 AI 和程序持续处理的数据。
这就是为什么我们会逐渐遇到 JSON、JSONL。
同样，写项目背景时 Markdown 很自然；配置 AI 工作流时 YAML 更合适；最后想把结果直接做成一个页面，又会碰到 HTML。
从传播的角度看，这其实是一个很朴素的问题：
同样的信息，换一种媒介和编码方式，传播和处理效率会完全不同。
所以真正值得建立的，不是“文件格式知识”，而是一种意识：
不要只考虑我现在怎么写，还要考虑这份信息下一步要去哪里。
二、五种格式，其实对应五种很常见的工作
Markdown：把事情讲清楚
Markdown 最接近我们平时写文章和笔记。
例如一个产品需求：
# AI 搜索功能
## 背景
用户查资料时，需要在多个系统之间切换。
## 核心需求
- 支持自然语言搜索
- 展示信息来源
- 支持继续追问它本质上还是自然语言，只是增加了标题、列表、层级这些简单结构。
所以 Markdown 很适合：
- 产品需求、PRD
- 项目说明
- 会议纪要
- 个人笔记
- Prompt
- 知识库
- README、AGENTS.md 等 AI 工作说明
它的优势很简单：
人看起来舒服，AI 读起来也清楚。
如果一份信息的核心目的是让人和 AI 理解，而不是让程序精确读取字段，Markdown 往往是最自然的选择。
YAML：把经常变化的设置单独保存
YAML 更像一张“设置页面”。
例如：
model: gpt
language: zh
output:
format: markdown
length: short
search:
enabled: true这和手机里的：
语言：中文
通知：开启
深色模式：关闭其实是一回事。
区别只是这些设置需要被程序读取。
所以 YAML 经常出现在 Agent、自动化工作流、模型配置、GitHub Actions 等场景中。
它特别适合：
有一套参数需要长期维护，人会经常修改，程序也需要稳定读取。
普通用户不需要专门去学 YAML，但当你开始搭自己的 Workflow、Agent 或 Skills 时，知道它是在“管配置”就足够了。
JSON：把 AI 的回答变成可以继续使用的数据
这是普通 AI 用户非常值得理解的一种格式。
假设让 AI 分析一个需求，它可能回答：
这是一个高优先级的性能问题，建议优先优化搜索速度。
给人看完全没问题。
但如果后面还要统计、排序、进入需求池或者交给程序继续处理，最好把它变成：
{
"type": "性能问题",
"priority": "高",
"suggestion": "优先优化搜索速度"
}区别就在于：
前者是一段回答，后者是一份数据。
比如做用户访谈，可以要求 AI 输出：
{
"pain_point": "找不到资料",
"frequency": "高",
"current_solution": "询问同事"
}后面就可以直接统计：
哪些痛点出现最多？
哪些需求优先级最高？
哪些问题集中在同一个场景？所以 JSON 真正重要的地方，不在于大括号怎么写，而在于它帮你完成了一次转换：
AI 回答
↓
结构化数据
↓
统计、自动化、继续处理这是从“聊天使用 AI”走向“工作流使用 AI”很关键的一步。
JSONL：当这样的数据越来越多
JSONL 可以理解成：
很多条 JSON，一行一条。
例如产品需求：
{"id":1,"request":"增加批量导出","priority":"中"}
{"id":2,"request":"搜索速度太慢","priority":"高"}
{"id":3,"request":"支持手机端","priority":"高"}它和 Excel 的思路其实很像：
一行就是一条记录。
Excel 很适合查看、筛选、计算和人工修改。
但如果有几千、几万条记录需要 AI：
逐条分析
→ 打标签
→ 保存结果
→ 下次继续JSONL 就会很好用。
例如：
- 产品需求池
- 用户反馈
- 用户访谈
- 竞品记录
- 客服记录
- 大规模 Excel 数据分析
假设你有 5000 条用户反馈，可以把 Excel 每一行转换成一条 JSONL，再让 AI 逐条分析。
处理到第 2680 条出了问题，前面的结果仍然完整保存；第二天又多了 100 条，也只需要继续追加。
所以可以这样理解：
少量结构化结果，用 JSON；大量一条一条的数据，用 JSONL。
它离普通人的工作，其实没有想象中那么远。
HTML：把 AI 的答案变成真正的成品
HTML 和前面几种格式不太一样。
Markdown、YAML、JSON、JSONL 更多是在解决：
信息怎么组织、怎么传递、怎么处理。
HTML 开始解决：
信息最后怎么呈现。
例如让 AI 做一次需求分析。
结果可以是一篇 Markdown，也可以直接变成一个包含标题、图表、数据卡片和交互的网页报告。
现在越来越多工作都可以从：
想法
↓
AI
↓
HTML直接得到一个可看的东西。
例如：
- 产品原型
- 数据报告
- Dashboard
- HTML Slides
- 项目看板
- 小工具
所以 HTML 对普通 AI 用户最大的意义是：
AI 不再只是给你一段答案，而是可以直接给你一个可以看的、甚至可以操作的成品。
三、真正使用时，只需要问一个问题
以后再遇到这些格式，其实不需要背定义。
只问一句：
这份信息下一步要干什么？
我要把事情讲清楚
→ Markdown
我要保存一套设置
→ YAML
我要把 AI 的回答变成数据
→ JSON
我要批量处理很多条数据
→ JSONL
我要把结果直接做成一个页面或成品
→ HTML比如一次完整的用户需求分析：
访谈记录
↓
Markdown
方便人和 AI 阅读
AI 提取需求
↓
JSON
得到结构化字段
几千条需求持续累积
↓
JSONL
方便批量处理
最终形成结论
↓
HTML
做成报告或 Dashboard这时候就会发现，这五种格式并不是五个孤立的知识点。
它们其实对应了一条完整的信息流：
内容 → 结构 → 批量处理 → 呈现
YAML 则在旁边负责：
告诉这套流程应该怎么运行。
最后：了解文件格式，其实是在了解 AI 怎么工作
很多人了解 AI，会先关注模型。
GPT、Claude、Gemini，谁更强，排行榜多少。
这些当然重要。
但真正开始大量使用 AI 后，会逐渐发现：
模型只是其中一部分，信息怎么进入模型、又怎么从模型流向下一步，同样重要。
你给 AI Markdown，它更容易理解内容结构。
你让它输出 JSON，答案就可以继续被程序处理。
你把大量记录保存成 JSONL，就可以持续批量分析。
你让它生成 HTML，它甚至可以直接把结果变成产品。
从传播的角度看，这就是一个不断“编码”和“再编码”的过程：
人的想法
↓
变成适合 AI 理解的信息
AI 的理解
↓
变成适合程序处理的信息
程序处理结果
↓
再变成人容易理解的呈现所以了解这些格式，并不是为了显得更懂技术。
而是为了开始建立一种更重要的意识：
同样一份信息，换一种合适的形态，AI 的使用方式可能完全不同。
以后遇到一个任务，可以多问自己一句：
这件事现在是内容，还是应该变成数据？是一次性的，还是以后还要继续处理？最终只是给 AI 看，还是要做成一个成品？
当你开始这样思考时，你已经不只是在“向 AI 提问”。
你开始在设计：
信息怎么进入 AI，又怎么从 AI 流向下一步。
最后再快速总结回顾下：
Markdown：把事情讲清楚。
YAML：把规则保存下来。
JSON：把回答变成数据。
JSONL：把大量数据一条条处理。
HTML：把结果直接变成成品。
知道这些格式是什么，是了解 AI。
知道什么时候该换一种信息形态，才是真正开始用好 AI。