AI 应用生成器提示词怎么写？前后对照实例全解析
看两个人用同一个 AI 应用生成器各干一小时。一个人手里有了能用的应用；另一个手里是一团糟，外加一句「AI 编程言过其实」的评价。工具一模一样，提示词天差地别。
给应用生成器写提示词和跟聊天机器人对话是两种不同的技能。你不是在提问——你是在给一个 Agent 下工单，而它会基于你说了什么和没说什么做出几十个决定。下面是真正管用的方法，全程配前后对照示例。
第一条提示词：前置决策，跳过实现
开场提示词决定项目的地基。你留下的每个空白，Agent 都会用猜测来填补；好的 Agent 猜得合理，但每次猜测都是一枚硬币，正反面是「猜中你的意图」和「没猜中」。
之前：
给我做个健身应用。
之后：
为力量训练者做一个健身记录器。数据：训练有日期；每次训练包含若干条目，每条有动作名称、组数、次数和重量。页面：（1）今日记录页，支持快速录入；（2）按周分组的历史页；（3）按动作展示的进步曲线图。单用户，不需要登录。深色、极简设计。
「之后」版本敲定了受众、数据模型、页面、登录范围和视觉方向——这五个决定日后改起来最贵。注意它没有包含的东西：没有技术栈、没有数据库选型、没有组件库。好的平台在这些问题上比提示词做得更好，而在需求里塞进一知半解的技术名词反而有害（平台围绕 Postgres 构建时你写「用 MongoDB」，只会制造摩擦）。
一个屡试不爽的结构：
- 它是什么， 一句话，带上受众。
- 数据， 用大白话列出名词和字段。
- 页面， 逐条编号。
- 明确排除项——「不要登录」「不要支付」。排除项能防止 Agent 出于好心自作主张地扩大范围。
迭代提示词：一次一个改动，锚定到具体位置
首次构建之后，你的提示词要换一种性格：从盖楼变成动手术。两条规则能解决大部分问题。
一条消息只改一件事。 打包的请求会作为整体失败——五个改动里有一个落错了地方，你就得绕开另外四个重新描述。
每个改动都锚定到位置。
之前：
日期看起来不对。
之后：
在历史页上，周标题显示的是「Week 32」。请改成显示日期范围，比如「8月4日 – 8月10日」。
点名页面、引用错误的文本、描述正确的文本。Agent 直接定位到确切位置而不是到处翻找——猜错更少，积分更省。
描述结果，别描述实现
你会忍不住想像开发者那样说话。除非你真是开发者，否则请忍住。
之前：
加一个 useEffect 在挂载时重新拉取数据，并对列表渲染做 memoize。
之后：
我添加一笔支出后回到仪表盘，总额还显示旧的数字，要刷新才更新。它应该实时正确。
第一个版本把 Agent 绑死在你的诊断上，而你的诊断可能是错的。第二个版本给它的是实际缺陷——你唯一能确定的东西——让它自己找原因。用用户的笃定描述症状；把诊断留给那个能读代码的家伙。
用参照物——比形容词管用得多
「现代、简洁」等于什么都没说；2010 年以来的每个设计都这么自称。参照物携带的信息量高出几个数量级：
让定价区块有 Linear 定价页的感觉：大量留白、细边框、只用一种强调色。
更好的做法是直接附截图——你喜欢的某个应用、一张手绘草图、你正在描述的那个坏掉的布局本身。支持图片附件的平台（Massvai 支持）从一张图里化解视觉歧义的速度远超文字。一张 bug 截图配一行说明，是性价比最高的提示词格式，没有之一。
出问题时：别再挖了
代价最高的提示词错误不是某条写得差——而是对一个方向根本就错了的东西，连续第四次打补丁。
同一个修复尝试两次都没成功，就该换策略：
- 回滚。 恢复到出问题之前的检查点（Massvai 给每次生成都做快照），换一种描述重新切入。往回退感觉像认输，但通常是最快的前进路线。
- 拉远视角。 别再重新描述那个修复方案，改成描述目标：「忘掉之前关于筛选下拉框的所有指令。我真正想让用户做到的是：……」Agent 处理一个全新的目标，比处理一堆累积的补丁指令好得多。
速查表
| 场景 | 该做 | 别做 |
|---|---|---|
| 开新项目 | 受众 + 数据 + 页面 + 排除项 | 「给我做个 X 应用」 |
| 请求改动 | 一次一个改动、锚定到页面 | 一条消息塞五个改动 |
| 报告 bug | 症状、位置、期望行为 | 你对代码层面原因的猜测 |
| 设计方向 | 参照应用和截图 | 一锅形容词 |
| 尝试两次仍卡住 | 回滚、重新描述目标 | 第五次点「再试一次」 |
这些没有一条是什么秘技。这就是你欠一位人类承包商的那份清晰——只不过这位承包商读需求非常仔细、永远不嫌你啰嗦、几秒钟内就开工。给它一份配得上的需求说明吧。