什么是 INTENT.md — AI 原生 SDLC 的第一个文件

INTENT.md 里写什么

INTENT.md 是一个 Markdown 文件，用提出想法的人自己的话记录想做的东西。Markdown 是一种只有标题和列表等轻量格式的纯文本，扩展名为 .md。关键在于它和代码放在同一个仓库里，而不是放在文档软件或知识库中。

在 2026 年 8 月 21 日发布的《AI 原生 SDLC 手册》中，Anthropic 列出了这个文件包含的六项内容：问题是什么、解决之后会是什么状态、哪些用户和系统受影响、有哪些约束、还有哪些未决问题，以及作者与当前状态。

这六项不是为了凑齐模板。它们恰好是下一阶段生成设计文档所需要的原料。缺了约束，就会得到无法落地的设计；缺了未决问题，就会把猜测当成已定事实写进设计。

为什么先写意图而不是先写代码

SDLC 指软件开发生命周期，也就是规划、设计、构建、测试、部署、维护这一圈。团队每交付一个功能就要走一遍的循环，就是 SDLC。

这六段里，长期以来耗时最久、成本最高的是构建阶段，所以工具和招聘都集中在那里。编码智能体进入实务后，改变的正是这一点。构建时间缩短之后，其余五段在日程中的占比反而更显眼了。

收集需求的会议、等人整理文档的时间、排队等测试的几天、积压待评审的 PR，这些都没有变。代码变快了，但一个功能真正送到用户手上的时间并没有等比缩短。瓶颈从代码转移到了流程。

手册的问题意识就在这里。不要只在构建阶段用智能体，前后各段也要用；而要做到这一点，每一段交给下一段的必须是文件而不是对话。INTENT.md 就是那第一个文件。

现在就动手写一个

需要的只是一个文件夹。在仓库根目录建一个名为 intent 的文件夹。手册指出，对只有一个产品的团队来说，把 intent 文件夹放在该产品仓库里是最简单的做法。

接下来让智能体来采访你。这里的顺序很重要。不是你整理好需求交出去，而是让智能体不断追问，把你脑子里的东西掏出来。你在整理时漏掉的，之后永远不会再出现。

假设你想加深色模式。让它不断追问：为什么需要、涉及哪些界面、用户的选择存在哪里、图片和标识怎么办、什么时候要上线、可以放弃什么。一直问到你没有可答的为止，再让它保存成文件。

如果用的是能直接写文件的工具，比如 Claude Code 或 Cursor，在对话结束时让它保存即可；如果用网页对话，就把结果复制粘贴成文件。文件名要能看出是哪个功能，例如 intent/dark-mode.md，也可以在前面加日期便于排序。

现在开始就我想做的功能向我提问。
一次问一个，直到我说没有可补充的为止。

要问的内容：为什么需要这个功能、现在哪里不方便、
受影响的用户和界面、关联的其他系统、预算与期限与技术约束、
以及我还没有决定的事。

我说"可以了"之后，把对话整理并保存为 intent/<功能名>.md
格式：问题 / 目标状态 / 影响范围 / 约束 / 未决问题 / 作者与状态

# 深色模式

## 问题
夜间使用应用的用户在过去三个月里反复反馈屏幕太亮、刺眼。

## 目标状态
用户可以在设置中选择浅色或深色界面，另有一个跟随设备系统设置的选项。

## 影响范围
应用全部界面。设置页新增一项。标识与插画是按浅色背景做的，需要重新审视。

## 约束
必须进入下个季度的定期发布。没有余力新建设计系统色彩令牌，需在复用现有令牌的范围内解决。

## 未决问题
用户的选择只存在设备上，还是存到账号以便多设备同步，尚未决定。
是否覆盖邮件模板，尚未决定。

## 作者与状态
申丞浩 撰写 · 2026-09-05 · 待审阅

不能省略作者复读这一步

智能体写出文件并不是终点。手册要求提出想法的人重新读一遍、修正之后再提交。这一步最容易被省略，而省略后损失也最大。

原因在于后面的结构。这个文件会变成设计文档，设计文档会变成工作计划，计划会变成代码。每一阶段只读前一阶段的文件。所以最初写错的一句话，会安静地穿过三个阶段直达代码。

常见的偏差有两处。智能体倾向于把你在对话中顺口提到的内容写成已确定的需求；反过来，你觉得理所当然而没说出口的约束，它会当成不存在。复读时先看这两点。

修正时看的是事实关系，而不是润色文句。你没有决定的事被写成已定，就把它降级为未决问题；你认为在范围之外的东西出现在影响范围里，就删掉。审阅完成后提交，手册要求把这一批准本身记录为文档的合并或已关闭的评审。

作者不必是开发者

手册把写这个文件的人称为发起人。这个词的要点是，组织中任何有想法的人都可以成为发起人。

遇到缺陷的客户可以是发起人，有功能想法的产品经理、想消除重复手工作业的运营负责人也是。以往这类请求以一行工单的形式进来，还得有人回头追问并整理；现在整理由智能体代劳，亲历的人就能用自己的话原样留下。

但这并不意味着全部直接进入开发。汇集起来的文件由产品负责人过目并排定优先级。文件夹里的 Markdown 文件列表本身就是待办清单，有些团队会把它转移到 Notion 或 Linear 之类的工具中管理。也可以先让智能体给出分类和优先级草案，再由人确认。

INTENT.md 之后 — 产物链

这个文件并不孤立存在。手册给出了一条把各阶段产物串起来的链条，INTENT.md 是这条链的第一环。

意图提交之后，以它为原料生成包含需求与设计的 spec.md。手册给出了这一阶段可用的指令示例：读取所附的 intent.md 并产出需求与设计文档，同时运用可用的技能，使其符合品牌规范、安全策略与 UX 标准。

设计确定后，工程师把意图和设计一并输入，生成工作计划 plan.md。要改哪些文件、按什么顺序、有什么风险、用什么确认完成，都写在这里。判断计划好坏的一个标准是：只拿到这份文档的人，能否不看前两份文档就动手。

这个标准看似苛刻，但有其理由。六个阶段不会由同一个智能体从头做到尾。每个阶段都有不同的对话、不同的智能体和子智能体，它们并不知道之前说过什么。交接的是文件而不是对话，在这里就成了实际要求而非偏好。

在团队推行前先定好这几件事

从一个文件夹开始就够了，但要在团队里扎根，最好先定几件事：文件放在哪里、怎么命名、谁来审阅、用什么标记批准。频繁更改的话，人和智能体每次遇到的规则都不一样，好处也就没了。

规则可以不只是写在文档里，还能变成会执行的东西。可以用钩子在意图合并后自动生成设计文档，也可以把团队的文档格式做成技能，这样就不必每次重写指令。手册所说的"把治理写成代码"指的就是这个。

如果已有一套跑得通的做法，没必要全盘推翻。每个团队本来就有自己的计划文档和评审流程，这份手册也只是其中一种做法。重叠的部分对齐名称，先把目前空着的那一格填上。

最小的起步方式，是挑一个本周要上线的功能，在 intent 文件夹里写一个文件。看看只凭这个文件，下一个人能不能着手设计，就能一次看清团队是否需要这套做法。