十年前，我们开始用 YAML 编排容器、声明服务、配置 CI/CD；十年后，我们开始用 Markdown 定义 AI 的行为、规则和协作方式。
从 Kubernetes 的 deployment.yaml 到 GitHub 的 .prompt.md、AGENTS.md、SpecKit，我们正经历一次新的"声明式革命"——从声明基础设施，到声明智能。
从云原生到 AI 原生：从 YAML 到 Markdown 的转折
在云原生时代，开发者的使命是"让机器理解我们的配置"。YAML 成为一种描述性编程语言——它不是程序，却能驱动一切。Kubernetes、Terraform、Helm、Ansible……我们把系统行为抽象成声明，把部署逻辑变成状态描述。
但进入 AI 原生时代，我们面临新的问题：我们不再需要告诉机器"怎么运行容器"，而要告诉机器"怎么思考与行动"。
于是 Markdown 成为新的规约语言（Specification Language）。开发者开始用 Markdown 规范 AI 的语气、步骤、协作方式，把 prompt、rules、skills、spec 当作可维护的"AI 说明书"。这正是规约驱动开发（Spec-Driven Development, SDD）的起点。
Markdown：AI 原生时代的"声明式语言"
过去我们写 deployment.yaml 告诉集群如何部署服务；现在我们写 .prompt.md 告诉 Copilot 如何理解我们的代码。
一个典型的 Copilot Prompt 文件：
# .github/prompts/docs.prompt.md
你是这个仓库的技术文档助手。
所有输出必须使用中文 Markdown。
保持简洁、使用标题、列表和表格。
这几行文字就能改变整个 IDE 的行为。在 GitHub Copilot、VS Code、Cursor 等环境中，这些 .prompt.md 文件被自动加载，构成了 AI IDE 的"语境层（context layer）"。
这意味着：AI 的行为，不再藏在隐形的 system prompt 里，而变成仓库的一部分。
从 .prompt.md 到 AGENTS.md，再到 Anthropic 的 SKILL.md、GitHub 的 SpecKit，Markdown 逐渐演化为一种新的编程语言——一种描述智能体"该怎么做事"的语言。
从 Prompt 到 Skill 到 Spec：AI 规约的演化路径
| 阶段 | 规约载体 | 核心目标 | 代表实践 |
|---|---|---|---|
| 云原生时代 | YAML | 声明基础设施 | Kubernetes、Terraform |
| Prompt 工程时代 | Markdown | 提示上下文 | Copilot .prompt.md、AGENTS.md |
| 技能模块时代 | Markdown + 脚本 | 封装能力 | Anthropic Agent Skills、Cursor Rules |
| 规约驱动时代 | Markdown + DSL | 规范协作 | GitHub SpecKit |
这种演化并非偶然。YAML 和 Markdown 其实解决了同一个问题：如何把人类意图结构化地传达给机器。
YAML 描述机器行为的"状态与配置"；Markdown 描述智能体行为的"语境与规则"。从 Cloud-Native 到 AI-Native，我们只是把声明对象从容器换成了智能体。
Anthropic Agent Skills：从"声明配置"到"声明能力"
Anthropic 的 Agent Skills 是这一趋势的典型代表。每个技能（Skill）是一个独立目录，核心文件是 SKILL.md：
---
name: pdf-processing
description: 提取并分析 PDF 表单内容
---
# PDF 处理技能
1. 读取文件。
2. 提取字段。
3. 检查表单一致性。
Claude 启动时只加载技能名称与描述（几十个 token），当任务触发时，再动态加载完整内容——这就是所谓的渐进披露（progressive disclosure）。
这与 Kubernetes 加载 CRD 的方式惊人地相似：控制平面不需要立即知道每个字段的细节，只要在执行时再解析即可。AI 的"知识面"也因此实现了动态扩展——用 Markdown 模块化知识，用执行环境激活技能。
Skill 不只是文档，还可以附带脚本。Claude 可以在安全沙箱中运行这些脚本，像执行容器一样调用外部逻辑。这让"读文档"和"执行任务"合二为一——AI 既能理解指令，也能自己完成操作。
Copilot Prompt、Cursor Rules 与 Skills：AI 规约的中层革命
这三种机制其实解决了相同的问题：如何在 AI IDE 中定义"上下文 + 规则 + 行为"。
| 层级 | 载体 | 定义内容 | 场景 |
|---|---|---|---|
| Prompt 层 | .github/prompts/*.prompt.md | 语气、上下文、风格 | Copilot、VS Code |
| Rule 层 | .cursor/rules/*.md | 项目规则、约束 | Cursor IDE |
| Skill 层 | skills/*/SKILL.md | 能力模块与脚本 | Claude Code |
- Copilot Prompt 定义"我是谁"；
- Cursor Rules 定义"我该怎么写"；
- Skills 定义"我能做什么"。
这是一种从上下文到能力的自然过渡。而下一阶段，就是从能力到治理——SpecKit。
GitHub SpecKit：让 AI 按规约开发
SpecKit 把"开发规约"升级为一整套治理体系。它以"Constitution（宪法）→ Spec（规范）→ Plan（计划）→ Task（任务）“为层次，让 AI 可以像项目经理一样遵循规则执行开发。
在 .specify/ 目录中，开发者定义：
# Constitution
AI 必须遵守：
- 所有代码遵循 PEP8
- 单元测试覆盖率 >= 90%
在 specs/ 中定义阶段任务，AI 按阶段执行、反馈、验证。这已经不仅是提示或风格指导，而是治理机制（governance layer）。
换句话说，SpecKit 是"AI 团队协作的 GitOps”。
从声明式到规约式：AI 编程的第二次范式转移
我们可以把这次变革看作云原生哲学的延续。
| 时代 | 驱动力 | 核心问题 | 解决方式 |
|---|---|---|---|
| 云原生 | 基础设施自动化 | 如何让机器执行配置？ | 声明式 YAML |
| AI 原生 | 知识与智能协作 | 如何让智能体执行规约？ | 规约式 Markdown |
Kubernetes 用 YAML 管理容器，SpecKit 用 Markdown 管理智能。我们正从"Infrastructure as Code"走向"Intelligence as Specification"。
这不是玩笑。YAML 地狱尚未远去，Markdown 地狱正在路上。
规约驱动开发（Spec-Driven Development, SDD）
SDD 让我们重新定义"开发"的意义：
- Prompt 是上下文配置文件（定义身份与风格）
- Skill 是能力模块（定义行为与工具）
- Spec 是项目宪法（定义规则与目标）
这三层共同构成了 AI IDE 的"规约体系结构"。未来的 IDE 不再是文本编辑器，而是一个"认知操作系统"——具备记忆、技能与规范。
实践建议：在你的仓库中启用规约层
以你的 website/ 仓库为例：
- 创建
.github/prompts/- 定义
.github/prompts/docs.prompt.md - 规定写作语气、风格、语言、格式。
- 定义
- 编写
AGENTS.md- 描述项目的开发流程、依赖、构建命令、测试方法。
- 让 Copilot 或 Cursor 在项目内拥有"本地规则感知"。
- 加入 SpecKit
- 在
.specify/目录定义项目宪法与阶段任务。 - 让 AI 以规范化的方式参与开发。
- 在
- 可选：引入 Skills 模块
- 把常用的内容生成、翻译、发布脚本封装成技能。
- 未来 Claude 或 Gemini 均可调用。
通过这几步，你的仓库就从传统仓库升级为 AI 协作就绪仓库（AI-Ready Repo）。
从 YAML DevOps 到 Markdown AIOps
云原生 DevOps 让我们学会：
“让配置可复现。”
AI 原生 AIOps 让我们学会：
“让智能可复现。”
YAML 定义了容器生命周期，Markdown 定义了智能体生命周期。
我们正在经历一个历史性转折——从编排基础设施，到编排智能。
从 DevOps 到 CollabOps：规约驱动开发的哲学转向
DevOps 的革命，让我们第一次相信——通过声明与自动化，机器可以可靠地与人协作。
十年后，我们正进入另一个协作范式——CollabOps（Collaborative Operations）：不仅是机器之间的协作，而是人、智能体、代码共同参与的自治网络。
在云原生时代，YAML 是信任的契约：我们把配置写进文件，让集群去实现；系统变成"听话的执行者"。
在 AI 原生时代，Markdown 成为新的契约：我们把规则写进文档，让智能体去遵守；系统变成"懂事的协作者"。
区别在于：
- DevOps 解决的是命令如何执行得更准确；
- CollabOps 解决的是意图如何被正确理解。
这就是规约驱动开发（Spec-Driven Development）的哲学基础：
用可阅读、可协作的方式描述智能行为，让机器理解人类的"为什么"，而不仅是"做什么"。
它继承了 YAML 的声明式精神，又吸收了 Markdown 的可解释特性。YAML 是机器能解析的最小真理，Markdown 是人类能阅读的最大模糊。而 AI，恰好生存在这两者之间。
未来的开发者，或许不再是"写代码的人"，而是"设计规约的人"——他们定义了 Agent 的角色、边界、合作方式；他们像 DevOps 写 CI/CD 一样写 Skills、Prompts、Specs；他们构建的，不再是程序，而是认知协作系统。
正如云原生让我们学会用 YAML 驯化复杂性，AI 原生将教会我们用 Markdown 驯化智能。这场转变，不只是工具的升级，而是开发哲学的延续。
从 Infrastructure as Code 到 Intelligence as Collaboration——这是我们时代新的编程宣言。
结语：AI-Native 的未来，是规约的未来
当 Prompt 成为配置文件、Skill 成为插件、Spec 成为治理机制，AI IDE 就不再是辅助工具，而是团队中的认知成员。
YAML 让我们声明了机器的状态；Markdown 让我们声明了智能的意图。
这场从 YAML 到 Markdown 的迁移，不仅是语法层的变化，更是开发哲学的更迭：
云原生让计算可编排，AI 原生让智能可编排。
总结
本文探讨了从 YAML 到 Markdown 的技术演变，揭示了 AI 原生时代规约驱动开发的兴起。通过对比云原生与 AI 原生的声明式范式，文章阐明了 Markdown 如何成为描述智能体行为的新语言，并通过 Prompt、Skill、Spec 的层级演化，展示了从基础设施自动化到智能协作的哲学转向。实践建议为开发者提供了启用规约层的具体路径，最终强调了 CollabOps 作为未来协作范式的意义。这一转变不仅改变了开发工具，更重塑了开发者与 AI 的协作方式。