提示词技巧
要点说清楚应用是给谁用的、大家在里面做什么、接下来应该发生什么。第一个请求描述整个应用，之后每次只提一个修改。拿不准时用“规划”，只想问问不想改动时用“聊天”，想指明具体位置时用编辑模式或截取。出了问题，说清楚你做了什么、预期是什么、实际发生了什么，还可以用“版本”回退。
MonstarX 会按你说的去构建，所以怎么说很重要。你不需要什么特别的说法或技术术语，平常的话就是最好的。下面这些技巧能帮你用更少的请求得到想要的结果，也就意味着消耗更少的套餐用量。
什么样的请求是好请求？
Section titled “什么样的请求是好请求？”好请求会用你自己的话回答三个问题：
- 给谁用？ “我的瑜伽馆会员”“我们的客服团队”“给孩子预约家教的家长”。
- 他们在里面做什么？ “查看本周的课程并预约名额”“查询订单并办理退款”。
- 接下来应该发生什么？ “发送确认邮件”“在‘我的预约’页面显示这次预约”。
再写上你真正在意的东西：名称、外观、一条规则（例如“每节课最多 12 人”）、哪些不要做；不重要的就不用写。MonstarX 会用合理的选择补上空白，之后你都可以改。
好请求和弱请求对比
Section titled “好请求和弱请求对比”| 弱请求 | 更好的请求 | 为什么更好 |
|---|---|---|
| “一个预约应用” | “给我的瑜伽馆做一个预约网站：每周课程表、每节课的名额上限、会员登录，有人预约时发送确认邮件。” | 说清楚了给谁用、大家做什么，以及之后会发生什么。 |
| “让它好看一点” | “用沉静的绿色和米白色配色，标题用衬线字体，课程表的行与行之间留更多空间。” | 说明了具体改什么，不用猜。 |
| “修一下 bug” | “在预约页面上，选择已经满员的课程仍然可以预约。应该显示‘课程已满’和一个‘加入候补’按钮。” | 说清楚了在哪里、发生了什么、应该怎样。 |
| “加上付款、评价、博客、地图和订阅邮件” | “在每位老师的页面上加一个评价区：会员可以打 1–5 星并留言。”（然后再提下一个） | 一次一个功能，更容易检查，也更容易撤销。 |
| “改一下按钮” | 在 编辑 模式下点击那个按钮，然后写：“把文字改成‘首节课免费体验’。” | 直接指出来，就不会弄错是哪个按钮。 |
| “做成 Airbnb 那样” | “把课程显示成卡片，上面一张大图，下面是时间和老师，每张卡片上都有一个预约按钮。”并附上一张截图。 | 描述（并展示）你喜欢的那部分，而不是另一个完整的产品。 |
应该一次要整个应用，还是一次一个功能？
Section titled “应该一次要整个应用，还是一次一个功能？”两种都要，用在不同的时候：
- 第一个请求可以描述整个应用。 MonstarX 会把它变成一份功能计划（一份逐个功能完成的清单），所以第一个请求包含五六个功能完全没问题。见功能计划。
- 之后，每个请求只提一个修改或一个功能。 每次构建都会保存自己的版本，如果某次出了问题，可以只撤销那一次。也更容易看清改了什么。
心里有好几件事？一件接一件发就行：MonstarX 构建时，新的构建请求会在队列中等待，并自动开始。见队列。
什么时候用规划模式？
Section titled “什么时候用规划模式？”每个项目的输入框上方都有三种模式：构建 会修改应用，规划 先提问再构建，聊天 只回答、不做任何修改。对于新应用，项目页面上的 先规划 开关和规划模式作用一样。
如果你还没想好，或者某个功能有好几种合理的做法，就用 规划。MonstarX 会问你几个问题，一次一个，每个都附有可以直接选的建议答案（谁来用、叫什么名字、长什么样），你回答完后再开始构建。
这会稍微多花一点时间，但能省下你本来要花在“不是这样”上的请求。见先规划。
怎样只提问、不做任何修改？
Section titled “怎样只提问、不做任何修改？”切换到 聊天 模式。MonstarX 可以读代码、看数据、打开页面、读日志来回答你，但绝不会修改应用。适合这样的问题：
- “为什么课程表显示的是上周的课程？”
- “要加付款功能需要做些什么？”
- “哪些页面不登录也能看到？”
如果回答中提出了你喜欢的修改，点击下方的 构建这些内容：MonstarX 会切换到构建模式并完成它。即使正在构建，聊天中的问题也会立即得到回答。见模式。
怎样让 MonstarX 明白我的意思？
Section titled “怎样让 MonstarX 明白我的意思？”文字不一定是最快的方式。直接展示给它看：
-
编辑模式：点击预览上方的 编辑，点击一个元素或圈出一块区域，然后说那里要怎么改。最多可以标记 20 处修改，一起发送。见编辑模式。
-
截取：点击 截取，框选页面上的任何内容，框中部分的图片就会连同它所在的页面一起放进你的消息里。适合“这里看起来不对”或“让这里和那里一样”。见截取。
-
附加图片：你喜欢的应用的截图、草图、设计稿、你的标志。见附加文件。
-
附加文档：RFP、需求说明、会议记录、包含你数据的电子表格。MonstarX 会读取它们并据此构建。见从文档构建和从电子表格构建。
出了问题该怎么办？
Section titled “出了问题该怎么办？”-
准确描述你看到的情况。 说清楚是哪个页面、你做了什么、你预期是什么、实际发生了什么。如果有错误信息，一字不差地复制下来。
-
展示出来。 对出问题的地方使用 截取，或者附上一张截图。
-
拿不准的话，先问再修。 在 聊天 模式下问：“为什么满员的课程还能预约？”MonstarX 会查看并解释原因，然后点击 构建这些内容 就能修好。
-
如果某次修改让情况变糟了，就回退。 打开 版本，恢复 到它之前的版本，然后补充更多细节再问一次。应用的数据不受影响。见版本。
如果同一个修复一直不成功，换个角度试试：拆成更小的步骤，解释规则而不是描述症状，或者针对这一个请求，把模型选择器从 自动 换成更强的模型。见选择模型和故障排除。
- 用你客户的叫法来命名。 “课程”“会员”“瑜伽垫”：MonstarX 会在应用中使用你的说法。
- 说明哪些要保持不变。 “改一下页头的颜色，但标志和菜单保持原样。”
- 说清楚数量和金额。 “每节课 12 个名额”“价格用澳元”“每页显示 20 条”。
- 内容也可以让它写。 “为一家亲切的社区瑜伽馆写‘关于我们’页面”，你得到的就是真实的文字，而不是占位符。
- 像真实用户一样测试。 用 MonstarX 给你的 演示账户 登录，像你的客户那样试用应用，然后告诉 MonstarX 哪里感觉不对。
- 千万不要把密码或 API 密钥粘贴到聊天里。 应用需要某个服务的密钥时，MonstarX 会显示一张卡片让你安全地添加，你也可以在 后端 → 密钥 中添加。见密钥。
- 用什么语言都可以。 用你思考时的语言来写，并要求应用使用你客户说的语言。
一个请求最长可以写多少？
最多 100,000 个字符，最多附加 10 个文件。大多数好请求只有一到五句话。
需要用技术术语吗？
不需要。平常的话效果最好。说清楚大家应该能做什么，怎么构建交给 MonstarX 决定。
MonstarX 做了我没要求的事，怎么办？
在 版本 中恢复到它之前的版本，然后再问一次，并说明哪些不要改。你也可以在 聊天 模式下问它为什么这样做。
写一个长请求好，还是几个短请求好？
对于新应用，一个描述整个应用的请求就可以，MonstarX 会把它规划成一份清单。对于修改，几个短请求更好：每次构建都是一个独立的版本，容易检查，也容易撤销。
可以用其他语言写请求吗？
可以。用任何语言写都行，并要求应用使用你客户用的语言。MonstarX 本身可以显示为 16 种语言，从简体中文、英语到阿拉伯语、豪萨语，见语言。