前言

假设你是一名前端工程师，产品经理丢过来一句话：做一个类似贝壳的地图找房页面，地图上能看房源，能筛选，点一下能看详情。

需求本身不难理解，难的是把它讲给 AI 听。地图初始化、点位渲染、筛选联动、列表与地图同步、加载和空状态……这些内容如果全塞进一段话，AI 很容易只做一半，或者做出一个“看起来能用、实际对不上”的页面。

同一个需求，其实有四种常见的提示词写法：普通自然语言、Markdown、结构化字段、XML 标签。它们不是四种不同的 AI 能力，而是四种组织信息的方式。选对了，沟通成本会低很多。

先看结论

• 需求一句话能说清：普通自然语言就够，先跑起来再说。
• 需求有多个模块：用 Markdown 分层，方便扫读和逐段修改。
• 约束多、还要验收：用结构化字段，把角色、任务、限制、验收分开写。
• 上下文长、资料多：用 XML 标签划清边界，避免 AI 把参考内容和必须执行的要求搞混。

四种写法可以混用，没必要死守一种。下面咱们用同一个地图找房需求，把四种写法都走一遍。

一、四种提示词类型，先认识一下

四种写法解决的是同一个问题：让 AI 清楚知道要做什么、基于什么做、做到什么程度、最后按什么标准交付。

二、统一示例：地图找房功能

为了对比公平，后面四种写法都用同一个需求。假设项目情况是这样：

• 技术栈：React + TypeScript，地图使用第三方地图 SDK。
• 页面结构：顶部筛选栏、中间地图区、底部房源列表。
• 已有基础：项目能跑起来，但还没有地图找房页面。

这一版要做的功能是：

1. 地图加载后，按当前视野拉取房源点位并渲染标记。
2. 提供区域、价格、户型三个筛选条件，切换后刷新点位和列表。
3. 点击地图标记，弹出对应房源卡片。
4. 点击列表项，地图定位到该房源并高亮标记。
5. 处理加载中、无结果、请求失败三种状态。
6. 移动端下，列表改为底部抽屉，避免遮挡地图。

这六条就是本次任务的“需求底稿”。接下来看看，同一份底稿用四种写法表达，会有什么差别。

三、第一种：普通自然语言提示词

最直接的方式，就是把需求当成一段话讲出来。适合第一次沟通，或者你自己还没想清楚怎么拆的时候。

你是一名有经验的前端工程师。

我正在做一个类似贝壳的地图找房页面，技术栈是 React + TypeScript，地图用第三方地图 SDK。

现在需要你帮我实现这个页面：地图上按当前视野展示房源点位，顶部有区域、价格、户型三个筛选，切换后点位和底部列表都要更新。点击地图上的标记要弹出房源卡片，点击列表项要定位到对应房源并高亮。

另外要处理加载中、没有结果和请求失败的状态，移动端把列表改成底部抽屉。

请沿用项目现有的目录结构和样式方案，改完告诉我改了哪些文件。

优点与局限

优点是快。想到哪写到哪，不用先设计结构，适合验证“AI 能不能理解这个需求”。

局限也很明显：六条需求挤在一段话里，改其中一条时不好定位；AI 漏掉一条，你也不容易一眼看出来。需求再长一点，就会变成一大坨文字。

四、第二种：Markdown 格式提示词

把同一段需求用标题和列表排一下，可读性立刻不一样。重点不是 Markdown 语法本身，而是用层级把信息分开。

## 角色
你是一名有经验的前端工程师，熟悉 React 与地图类交互开发。

## 项目背景
- 技术栈：React + TypeScript
- 页面：地图找房，包含顶部筛选、地图区、底部房源列表
- 现状：项目可运行，地图找房页面尚未开发

## 本次任务
1. 地图加载后，按当前视野拉取房源点位并渲染标记
2. 提供区域、价格、户型三个筛选条件
3. 切换筛选后，同步刷新地图点位与底部列表
4. 点击地图标记，弹出房源卡片
5. 点击列表项，地图定位并高亮该房源

## 状态处理
- 加载中：显示骨架屏
- 无结果：显示空状态与调整筛选的提示
- 请求失败：显示重试入口

## 约束
- 沿用现有目录结构与样式方案
- 移动端列表改为底部抽屉
- 不要改动其他页面

## 交付
说明修改了哪些文件，以及每项功能的验证方式。

什么时候适合用？

• 需求分成好几块，需要自己和 AI 都能快速扫一遍。
• 需要反复调整某一节，比如只想改“状态处理”。
• 提示词要存进文档、知识库，或者给团队复用。

Markdown 的好处是结构清楚、改动方便、方便版本管理。它不会让模型变聪明，但能让你少解释几遍。

五、第三种：结构化字段提示词

如果这个需求要交给 AI 一次做完，而且做完还得能验收，那就值得把字段写全。角色、背景、技术栈、任务、约束、验收，一块一块写清楚。

【角色】
你是一名有经验的前端工程师，负责地图类交互页面的开发。

【背景】
项目使用 React + TypeScript，地图基于第三方地图 SDK。
当前需要新增“地图找房”页面，页面由顶部筛选、地图区、底部房源列表组成。

【任务】
1. 地图初始化后，按当前视野范围请求房源数据并渲染点位
2. 实现区域、价格、户型三个筛选条件
3. 筛选变化时，同时更新地图点位与底部列表
4. 点击标记弹出房源卡片；点击列表项定位并高亮对应标记
5. 处理加载中、无结果、请求失败三种状态
6. 移动端将列表改为底部抽屉

【约束】
- 沿用现有目录结构、请求封装和样式方案
- 视野变化请求需做防抖，避免频繁触发
- 只新增本页面相关代码，不改动其他页面

【验收】
- 地图与列表数据一致，筛选后同步更新
- 标记与列表项可双向联动
- 三种状态均有可见反馈
- 移动端不遮挡地图操作区域

它解决了什么问题？

普通自然语言里，“处理好一点”“注意性能”这类话，AI 只能猜。结构化字段把这些隐含期待变成明确条目：防抖要写出来，不改其他页面要写出来，验收标准也要写出来。

对前端来说，约束和验收这两块最值钱。它们决定了 AI 交付的是“能跑”，还是“能合并”。

它和 Markdown 有什么区别？

两种写法看起来都在分块，差别不在 ## 还是 【】，而在每一块有没有固定职责。

Markdown 是一份方便阅读和修改的文档。## 角色、## 本次任务、## 状态处理 这些标题可以随手起，用来把内容分层。你想只改“状态处理”时很好找。模型读到的仍然是一篇排好版的说明，标题本身不强制它把某一段当成验收标准。

结构化字段是一张填好的任务单。【任务】里只放要做的事，【约束】里只放不能违反的限制，【验收】里只放做完后怎么判断对不对。字段名是固定的，漏了【验收】，你自己也能看出这份提示词还不能交付。

所以，需求还在整理、模块会经常改，用 Markdown。模块已经清楚，还要避免 AI 把限制和验收当成参考意见，用结构化字段。

Markdown 负责把文章写清楚，结构化字段负责把“做什么”和“怎样算做完”拆开。

六、第四种：XML 标签提示词

当上下文变长，比如同时要给 AI 设计稿说明、接口文档、现有组件代码，XML 标签的作用就出来了：用标签把不同性质的内容隔开，让 AI 分得清哪段是背景、哪段是必须执行的要求。

<role>
你是一名有经验的前端工程师，负责地图类交互页面开发。
</role>

<context>
项目使用 React + TypeScript，地图基于第三方地图 SDK。
需要新增“地图找房”页面，包含顶部筛选、地图区、底部房源列表。
</context>

<requirements>
  <item>地图初始化后，按当前视野范围请求房源并渲染点位</item>
  <item>实现区域、价格、户型三个筛选条件</item>
  <item>筛选变化时，同步更新地图点位与底部列表</item>
  <item>点击标记弹出房源卡片；点击列表项定位并高亮标记</item>
  <item>处理加载中、无结果、请求失败三种状态</item>
  <item>移动端将列表改为底部抽屉</item>
</requirements>

<constraints>
  <item>沿用现有目录结构、请求封装和样式方案</item>
  <item>视野变化请求需做防抖</item>
  <item>只新增本页面相关代码，不改动其他页面</item>
</constraints>

<acceptance>
  <item>地图与列表数据一致，筛选后同步更新</item>
  <item>标记与列表项可双向联动</item>
  <item>三种状态均有可见反馈</item>
  <item>移动端不遮挡地图操作区域</item>
</acceptance>

<output_format>
先给出实现步骤，再分文件给出改动，最后列出验收自查结果。
</output_format>

XML 的特点

标签名不是固定咒语，<requirements> 也可以叫 <tasks>，关键在语义清楚、成对闭合、层级不乱。它最适合这几种情况：

• 要同时塞进接口文档、设计说明、现有代码等多段资料。
• 需求要分几轮追加，不想让新旧指令混在一起。
• 团队要沉淀一套稳定的提示词模板。

缺点是写起来啰嗦。需求不长的时候，用它反而增加负担。

七、四种写法怎么选

实际使用时，可以按这个顺序来：

1. 先用普通自然语言把需求说出来，确认 AI 理解方向。
2. 需求变多就上 Markdown，把模块拆开。
3. 要交付、要验收就补字段，把约束和标准写死。
4. 资料变杂再上 XML，把不同来源的内容隔开。

这四种可以混着用。比如外层用 XML 区分背景和要求，里面的需求清单用 Markdown 列，验收部分再写成字段。形式是给自己看的，能维护就行。

八、实战：把提示词落到地图找房页面

真正开工时，我一般不会一次把六条需求全丢给 AI。地图找房这种页面，一次性生成看着爽，出问题很难查。更稳的做法是分几步走。

第一步：先让 AI 读项目

别急着让它写代码，先确认它看得懂现有结构。

先阅读当前项目，告诉我：
1. 使用的技术栈和主要依赖
2. 页面和组件的目录组织方式
3. 现有的请求封装在哪里、怎么调用
4. 样式方案是什么（CSS Modules / Tailwind / 其他）

暂时不要修改任何文件。

这一步能筛掉大部分“凭空假设项目结构”的问题。它说错了，你立刻就知道该补充什么背景。

第二步：先做地图和点位

先只做一件事：地图能出来，点位能渲染。

先只实现地图基础能力：
1. 初始化地图并设置默认中心和缩放级别
2. 按当前视野范围请求房源数据
3. 在地图上渲染房源标记，标记上显示总价

不要实现筛选、列表和详情卡片，这一步只验证地图与数据链路。

范围收窄之后，问题也好定位：地图不显示是 SDK 初始化问题，点位为空是请求参数问题，一眼能分清。

第三步：加筛选和联动

地图通了，再叠加筛选和双向联动。

在现有地图页面上继续：
1. 增加区域、价格、户型三个筛选条件
2. 筛选变化时重新请求数据，并同时更新点位和列表
3. 点击标记弹出房源卡片
4. 点击列表项，地图定位到该房源并高亮标记

注意：视野变化触发的请求要做防抖，避免拖动地图时疯狂发请求。

第四步：补状态和移动端

功能通了，再处理边界情况。这一步最容易被忽略，也最容易在上线后暴露。

继续完善：
1. 加载中显示骨架屏
2. 无结果时显示空状态，并提示调整筛选条件
3. 请求失败时显示重试按钮
4. 移动端将底部列表改为可收起的抽屉，不遮挡地图操作

第五步：按清单验收

AI 说“已完成”不等于真的完成。地图找房这类交互，至少过一遍下面这些点：

验收清单写进提示词，AI 交付时就会顺手自查一遍。这一步比事后返工省事得多。

九、可复用的提示词模板

普通版

你是一名【角色】。当前项目是【技术栈/背景】。
请实现【任务】，需要满足【约束】。
完成后说明修改了哪些文件，以及如何验证。

Markdown 版

标题按内容来起，方便分段阅读和修改。下面只是一种排法，不是必须照抄的字段。

## 角色
- 你的身份与经验

## 项目背景
- 技术栈
- 页面结构
- 当前进度

## 本次任务
1. 任务一
2. 任务二

## 状态处理
- 加载中怎么显示
- 无结果怎么显示
- 失败怎么显示

## 约束
- 不能改动的部分
- 性能或兼容性要求

## 交付
说明改了哪些文件，以及每项功能怎么验证。

结构化字段版

栏位是固定的。任务、约束、验收各写各的，不要因为都在分块，就把它写成另一份 Markdown。

【角色】
身份与经验。只写角色，不写具体功能。

【背景】
技术栈、页面结构和当前进度。只写现状，不写这次要做什么。

【任务】
1. 要完成的功能一
2. 要完成的功能二
只写要做的事，不把限制和验收混进来。

【约束】
- 不能改动的范围
- 必须遵守的性能或兼容性要求
这里写不能违反的限制，不是新功能。

【验收】
- 一个可以观察、能判断通过或失败的结果
- 再写一条同样可检查的结果
这里写怎样算做完，不要再追加需求。

XML 版

<role>AI 应扮演的角色</role>
<context>项目背景与技术栈</context>
<requirements>
  <item>需求一</item>
  <item>需求二</item>
</requirements>
<constraints>
  <item>约束一</item>
</constraints>
<acceptance>
  <item>验收标准一</item>
</acceptance>
<output_format>交付形式</output_format>

十、总结

同一个地图找房需求，四种写法各有各的用处：

• 普通自然语言适合开口，先把想法说出来。
• Markdown 适合把需求拆开，方便看也方便改。
• 结构化字段适合交付，把约束和验收写清楚。
• XML 标签适合复杂上下文，把不同来源的信息隔开。

提示词写得漂亮不是目的。真正的目的是让 AI 少猜、让你少改。对前端来说，把需求拆小、把约束写明、把验收标准列出来，这三件事比选哪种格式重要得多。

下次接到类似“做个地图找房”的需求，不妨先花五分钟把需求写成清单，再决定用哪种写法。省下来的返工时间，通常比写提示词的时间多。