氛围开发者提示指南
我试图分解一种结构化的方法来向 AI 应用构建器和编码 agent 提问，特别是针对设计和产品管理用例。我涵盖了节省时间和金钱的框架和心智模型，以及将模糊想法转化为可构建指令的工作流。
1、提示词到底是什么
当你为 AI 编码 agent 编写提示词时，你做的和把设计简报交给设计师或开发者时做的事情是一样的。你在传递意图。你在说：这是我想要的，这是上下文，这是重要的，这是不重要的。返回内容的质量完全取决于你输入的质量。
这就是为什么模糊的提示会产生通用的结果。如果你告诉 AI builder"给我做一个徒步应用"，它会给你一些东西。它会猜测布局，猜测功能，猜测风格。而且它每次都会做出不同的猜测，因为你没有给它任何锚定的依据。输出不好不是因为 AI 不好。而是因为输入是空的。
也没有所谓普遍"好"的提示词。正确的提示词取决于你处于什么阶段、你已经知道什么以及你想要实现什么。初始的应用脚手架提示词不同于中间的优化提示词，后者又与调试提示词完全不同。技巧在于为当前时刻选择正确的方法。
2、你的起点是什么
在写任何东西之前，问自己一个问题：我对什么已经很清楚了？
你的起点决定了你如何提问、你以什么模式工作以及你的提示词需要多少结构。
- 你可能从一个粗略的想法或问题陈述开始："我想要一个徒步者可以在附近找到活动的平台。"这是一个与 AI 合作探索解决方案空间的有效起点。- 你可能有一些线框图、用户流程、草图：餐巾纸上的涂鸦、Figma 线框图、展示结构但不精致的粗略布局。这些给了你更多可以使用的素材，你可以让你的想法有更多的深度和完善，同时仍然受益于 AI 的创造力和批判性思维来挑战你的粗略想法。- 你可能拥有中高保真原型：带有真实内容、真实样式、真实组件层次结构的精美 Figma 界面。这是提问的最强位置，因为你确切地知道你想要什么，你在要求 AI 执行，而不是创造。- 或者你可能有一个设计系统、组件或现有产品想要增强。你不是从零开始：你在扩展现有的东西并在其基础上构建。
这些起点中的每一个都导向不同的提问策略。
3、Vibe 构建模式：探索 vs. 规格说明
你的清晰度——我们刚刚评估过的——决定了你如何提问。使用 AI builder 有两种根本不同的模式。
3.1 共同创造者模式
当你处于探索模式时，将 AI 视为共同创造者。这是当你有一个想法但没有清晰的愿景时。你仍在发现这个事物应该是什么样。
在这种模式下，拥抱幻觉。AI 有时会发明你没有要求的元素，但不要将其视为 bug，而应将其视为创造力的火花。其中一些惊喜是无关的，但其他的可以激发你自己想不到的方向。
在这种模式下，用侧重于问题和目标的模糊提示开始，让 AI 建议你可能的选择。你不是在试图控制输出，你是在试图看到可能性并探索解决方案空间。
当你得到结果时，混搭和实验。挑选你喜欢的。"保留动画英雄区，但把图库替换成卡片列表。"
你仍然可以在不扼杀创造力的情况下引导创造力。添加参考资料、情绪板或截图来引导风格，而不过度约束它。上下文减少了废话，同时保留了有用的变化。
共同创造者模式不仅对创意构思和探索有用，也对快速找到基线解决方案和生成初稿有用。例如，提示"电商网站的标准支付流程"，然后获得整套步骤，而不是指定每个组件和输入字段。然后在其基础上构建，把它变成你自己的。
3.2 开发者模式
当你思路清晰时，将 AI 视为开发者。你知道你想要什么，你需要 AI 去执行，而不是创造。
在这种模式下，要详细和精确。指令要明确。将任务分解为小的、连续的步骤，或使用计划模式让 AI agent 为你分解。避免在一个提示中组合多个功能任务。定义明确的预期结果。
开发者模式最适合在清晰的愿景上执行、执行精确指令以及寻找有效的技术解决方案。
AI 很强大，但它不是魔法。 你的角色是引导、策划和决策。幻觉不总是错误。它们也可以是你不会考虑到的选项，但只有当你处于正确的接收模式时才有意义。
4、两个引擎：思考 vs. 构建
如果只从本文带走一件事，那就是这个： 你有两个（或更多）引擎可用，它们做的根本不同。学会何时使用哪一个将比任何提问技巧节省更多的时间和金钱。
4.1 引擎 1：外部 LLM
ChatGPT、Claude、Gemini 或任何通用 AI。 这是你的思考伙伴。这是你在接触 builder 之前规划、研究、探索、结构化和完善想法的地方。它看不到你的代码。它不知道你 builder 的约束。但它免费或便宜、速度快，而且非常擅长帮你思考。它不一定要是一个 LLM，它可以是一组多个工具；你可以将研究或视觉设计 AI 加入其中。
4.2 引擎 2：你的 AI builder
Lovable、Bolt、v0、Cursor、Claude Code 或任何你用来构建的工具。 这是你的执行引擎。它看到你的代码库、组件树、页面结构和历史记录。它理解工具特定和代码库的约束，包括支持哪些库以及路由和部署如何工作。但它消耗积分，你发送的每条消息都会使用它们。你也不希望用不相关的信息淹没你的编码 agent 的上下文窗口，因为这会混淆 agent 并损害性能。
经验法则：外部思考，内部构建。 使用 LLM 来确定你想要什么。使用 builder 来将其变为现实。先在外部 LLM 中起草和完善你的提示词，然后将精炼、清晰的指令发送给 builder。更少的轮次，更低的成本，更好的输出。
5、何时使用外部 LLM
当你仍在搞清楚状况、在准备好构建之前，使用你的外部 LLM。
规划和研究。 你有一个概念，但还没有将其分解为页面、流程或组件。你可能会说："我想为徒步者构建一个社区平台。帮我思考我需要哪些页面、核心用户流程是什么样的、以及我应该先构建什么。"LLM 将帮助你构建一些可能需要你对着空白文档盯一个小时才能想出来的东西。
当你无法表达你想要什么时。 你知道你想要的感觉，但找不到合适的词。这在设计领域经常发生。你可以描述这种氛围："我希望它感觉平静和高档，像一个健康品牌，但面向户外运动"，LLM 会将其转化为具体的设计方向：调色板、字体建议、布局模式、参考点。
当你需要词汇时。 你看到一个 UI 模式，但不知道它叫什么。是"侧边抽屉"？"面板"？你能描述你所看到的："当你点击列表项时，它会从右侧滑入并显示详情"，然后 LLM 会给它命名。这个名字会变成你 builder 提示词中的一个强大关键词，因为 builder 理解组件词汇。
当你想要将项目分解为片段时。 "帮我构建一个徒步社区应用"对任何一个提示词来说都太大了。问 LLM："帮我把它分解成可构建的块。我应该先构建什么、其次、再次？什么可以等待？"它会给你一个有序的计划：先主页，然后活动列表，然后活动详情页，然后用户个人资料。
当你想要描述或解构一个参考时。 在 Mobbin 或 Dribbble 上找到了你喜欢的布局？截图，粘贴到 ChatGPT 或 Claude，然后问："详细描述这个布局：每个部分、层次结构、组件、视觉风格。" 你会得到一个结构化的文字描述，可以直接适配为 builder 提示。这是最被低估的技巧之一——LLM 弥合了你能看到和你能描述之间的差距。它对竞品产品、你欣赏的应用或任何你想逆向工程为设计简报的内容同样有效。
当你想要综合多个参考时。 也许你喜欢一个应用的导航、另一个应用的卡片布局和第三个的配色方案。向 LLM 展示所有三个截图，问："从截图 1 取导航，截图 2 取卡片网格，截图 3 取色彩方案。为我写一个将它们连贯组合的单一设计简报。"输出是一个你在同样时间内根本无法从零写出的提示词。
6、设置你的思考伙伴
两个技巧可以让你的外部 LLM 随着时间的推移变得更有用。
使用 LLM 作为提示词写作助手。 告诉它你的项目：概念、受众、技术栈和视觉方向；然后让它使用我们稍后介绍的建筑块（目标、范围、上下文、约束、验收标准）起草一个完整的提示词。但这里重要的一点是：你审查和编辑输出。不要盲目地粘贴到 Lovable 中。你是策展人。LLM 速度快且结构化，但它不知道你的品味或优先级。你知道。
使用自定义 GPT、项目或系统提示预加载你的项目上下文。 不必每次开始新对话时都重新解释你的项目，设置持久上下文。在 ChatGPT 中，创建一个自定义 GPT。在 Claude 中，创建一个项目。每次对话都以你的上下文已经就位开始。
可选地，你可以使用带有预定义系统提示的自定义 GPT。但仔细审查输出，因为它们设置方式各不相同，可能包含与你的特定项目不相关的细节，同时忽略了你自己的上下文。这里有几个我用于 Lovable 的：
7、何时使用 Builder 的计划模式
当项目上下文重要时，当答案取决于你代码库中已存在的内容时，使用你的 builder 的内置聊天或计划模式。
它理解 builder 的约束。 Builder 知道支持哪些库、它的路由系统如何工作、部署流水线是什么样子的。外部 LLM 没有这些知识。如果你问 Claude"我应该在 Lovable 中如何实现暗黑模式？"它会给你通用的 React 建议。如果你问 Lovable 的计划模式，它会给你一个尊重你实际设置的答案。
它看到你的代码。 这是关键的差别。Builder 可以引用你现有的组件、页面结构、样式、数据模型。它不会建议创建一个已经以不同名称存在的组件。它不会提出与你已构建的内容冲突的路由结构。它拥有外部工具不可能拥有的上下文。
它看到你的历史。 它知道你尝试过什么、发送过哪些提示、什么有效以及什么被还原了。这防止了循环调试——你不断尝试相同的修复，因为你忘记了你三个提示前已经试过了。
它消耗积分，这就是代价。 每条消息都使用积分。当你需要只有 builder 才能提供的精度和项目感知时，这没问题。当你仍在头脑风暴或探索不需要代码上下文的想法时，这是浪费。
经验法则：
- 如果你问"我应该构建什么？"——使用外部 LLM
- 如果你问"鉴于我项目中已经存在的东西，我应该如何构建这个？"——使用 builder。
8、基于阶段的提示词分类
你在构建过程中会不断地在这些提示类型之间切换。它们不是顺序步骤，而是根据你当前需要切换的提问风格。
8.1 规划/讨论式提问
这是最被低估的提示类型，也可以说是最重要的。这些是产生零代码的提示。你明确要求 AI 和你一起思考，而不是为你构建。
"我想在我的应用中添加用户资料。帮我思考我需要什么数据、页面应该显示什么、以及最好的方法是什么"
"审查我当前的页面结构，并建议完成 MVP 还缺少什么。"
"我想添加一个暗黑模式切换。在我们实现任何东西之前，帮我思考考虑到我们当前的样式设置，最安全的方法是什么。"
这是 Lovable 和 Claude Code 的计划模式，Bolt 的讨论模式。现在每个主要的 builder 都有专门的空间来做这个，因为它们已经意识到你写的一些最重要的提示根本不产生任何代码。在构建之前使用它们来规划，可以显著提高结果质量并减少 token 使用。
8.2 视觉/UI 提问
附上视觉参考：一张图胜千言。一张带有一句上下文说明的截图（"使用这个卡片布局，但用我们的配色方案"）可能比单独一段描述文字更有力。
需要记住的几点：不要将多个设计合并到一个文件中，也不要把逻辑图与 UI 原型混在一起。始终告诉 AI 保留什么、忽略什么：
"只使用布局，不使用样式。" "保留卡片结构，替换图片和文案以适应我的应用。" "与截图相同的网格布局，但用徒步活动替代产品。"
忘掉像素完美。AI 会将你的附件作为一般风格、结构、布局和层次结构的灵感，但不会精确重现设计。这既是祝福也是诅咒，因为它允许你附上非常粗糙的草图，并在代码中完成打磨，而不是在 Figma 中仔细对齐所有内容（那可能需要更长时间！）。不过，如果你有精致的设设计，可以使用 Figma MCP 的插件之一将其导出为代码。
除了附上视觉素材，你可以引用熟悉的组件、行为和效果。对于创意视觉探索，描述情绪、基调和情感意图。流行词汇在这里压缩了含义："极简主义"、"编辑风格"、"粗野主义"、"玻璃拟态"、"温暖友好"。AI builder 理解它们。尝试混合意想不到的风格："用梵高的风格构建 Airbnb"
8.3 功能式提问
描述逻辑。定义用户流程和条件。当用户点击这个按钮时会发生什么？页面从什么状态开始？数据加载时会发生什么变化？出错时会发生什么？
将 UI 绑定到数据。连接到后端功能。但不要批量处理多个功能更改。每个功能应该有自己的提示词。将"添加筛选逻辑"、"添加表单验证"和"连接数据库"组合在一个提示词中，是产生无法调试的复合错误的配方。
8.4 优化/评估式提问
在已有一些东西之后使用。你不是在构建：你在改进、审查和修复。
让 AI 审查无障碍性： "检查这个页面的无障碍问题——对比度、键盘导航、屏幕阅读器兼容性。"
要求 QA 和边界情况分析： "如果用户提交了空的必填字段表单会发生什么？活动标题中的文本非常长呢？如果没有活动要显示呢？"
用于调试。 遇到错误时，先粘贴错误信息并请求解释，然后才是修复。不要只说*"修复这个。"* 要说*"解释导致这个错误的原因，然后建议最小的修改来解决它。"* 理解错误可以防止它再次发生。
用于本地化、性能审核和响应式设计检查。这些都是让 AI 审查现有代码而非生成新代码的评估任务。
一个值得强调的特定优化技术：反向元提示。 在解决了一个棘手问题后，问 AI："基于我们刚才做的，生成一个可复用的提示词，以便我下次遇到这类问题可以使用。"你正在随时间建立自己的经过测试的提示词库。
8.5 提示词构建块
每一个强大的提示词都由同一组构建块组装而成。你不需要总是使用所有它们——一个优化提示词可能只需要范围和约束，而第一个提示词则需要大部分。技巧在于知道有什么可用并选择适合的。
目标
你在构建什么以及为什么？保持在一句话以内。这锚定了整个提示词，防止 AI 偏离。示例："为徒步社区平台构建一个主页。"
范围
这个特定提示词包含什么和不包含什么。这是大多数人失败的地方。他们描述他们想要的，但不说他们不想要的。明确边界。示例："只构建：主页。不包含：活动页面、认证、数据库、后端逻辑。"
上下文
这是为谁做的？领域、语气、受众是什么？上下文给了 AI 一个参考框架，这样它就不必猜测。示例："目标受众：热爱户外、讲英语、20-50 岁的用户。语气：友好、非正式、包容。行业：户外休闲社区。"
约束
技术或设计边界。AI 不能做什么或不能改变什么。示例："此轮无需认证、数据库、外部 API。所有内容保持英文。不要修改现有导航。"
验收标准
你如何知道输出是正确的？定义预期的结果，以便你可以评估。示例："主页应有六个部分：带搜索栏的英雄区、水平滚动的活动标签、使命陈述、热门路线网格、社区网格和带占位链接的页脚。"
示例和参考
截图、URL、线框图、情绪板。告诉 AI 保留什么和忽略什么："使用这个卡片布局。忽略配色方案。"
代码作为参考
你的参考不一定是图片。AI builder 可以直接从其他来源采用代码，只要它在同一个前端框架内且不引入新的依赖。开源组件库、通过插件导出为代码的 Figma 资源、以及从 Framer、Paper 和 Webflow 等设计工具导出的内容都是有效输入。粘贴代码并告诉 AI 保留什么、适配什么、忽略什么，就像你用截图做的那样。
9、增量构建
第一个提示词很特别，因为它奠定了基础，但它并不像人们想的那么特别。它不需要完美。它需要足够清晰，让你有一些可以迭代的东西。
第一个提示词实际上定义的是基础前端技术栈：核心框架、样式方法、组件库和构建工具。然而，在 Lovable、v0、Figma Make、Magic Patterns 等工具中，这无法更改——它们总是设置 React、Vite、Tailwind 和 ShadCN。所以你不需要指定它。
但是，如果你使用像 Bolt、Replit、Google AI Studio、Cursor 或任何 agentic 编码工具，你可以在第一个提示词中定义前端技术栈。如果你不定义，它将默认为 React。这是你之后无法轻易更改的东西，除非从头重建。所以如果你开始构建一个 React 应用，后来决定发布到 App Store，你将需要在不同的技术栈中重建它（例如 React Native）。
以下是第一个提示词不需要定义的：
应用架构。 你不需要每个页面和模块的完整地图。应用是模块化系统。你可以迭代地添加路由、组件和关系。
样式变量。 先把结构和层次结构做对。样式——颜色、间距和字体调整——可以在之后优化，即使在 UI 存在之后也很容易更改（除非你硬编码了样式）。
后端、数据库和外部服务。 不要太早添加这些，除非那是你原型的目的。先构建足够的 UI 和流程。一旦数据库存在，UI 更改通常需要尊重数据结构，这会减慢迭代速度。这是你在需要之前不想要的约束。
从一个能独立看意义的页面或组件开始。你的第二个、第三个和第十个提示词和第一个同样重要。
每一个 AI builder 中最通用的最佳实践：不要试图在一个提示词中构建所有东西。
AI builder 擅长处理聚焦的、有范围的任务。它们难以处理广泛的、多关注点的提示。一个完整的页面提示词——"给我构建一个完整的事件页面，带筛选器、列表、详情面板、无限滚动和创建表单"——会产生噪音。AI 会尝试所有东西，大部分做得很差，并创建难以调试或优化的纠缠代码。
一个基于部分的提示词——"创建筛选栏，带位置和活动类型的下拉菜单"——会产生信号。干净、聚焦的输出，你可以评估、调整并在此基础上构建。
小型提示词也更容易调试。当某件事出问题时，你确切知道是哪个提示词引起的。当你发送一个巨大的提示词而出了问题时，你会在多个功能中搜索，试图找到问题。
迭代地构建组件。 没有黄金法则来规定如何分块工作——这取决于项目、复杂度以及你在每一步试图学习什么。重要的是让每个提示词专注于一个清晰的任务，而不是要求 AI 一次性构建整个页面。无论你是先做布局再添加行为，还是一次构建一个完整的组件，原理是一样的：小的、可评估的步骤。
一个确实重要的实用规则：告诉你的编码 agent 对所有样式使用主题变量——颜色、间距、字体、圆角——永远不要硬编码值。 如果你不早实施这一规则，最终会得到几十个分散的十六进制代码和像素值嵌入到各个组件中。更改主题、添加暗黑模式，甚至调整你的品牌颜色都会变成查找替换的噩梦，而不是单一的变量更改。
添加新页面时， 始终指定三件事：页面名称，它将成为 URL 路由（例如 /events）；如何访问它：它应该出现在主导航中、通过按钮或链接、还是仅通过 URL 直接访问？；以及页面上应该有什么内容——结构、功能和任何参考。
原文链接: The Vibe-Coder's Prompting Guide
汇智网翻译整理，转载请标明出处