Atoms 提示词指南
在输入前先想清楚,分块构建,使用真实内容,并把每个请求交给合适的智能体。这些习惯能把一句话的想法变成完整成果。
从项目聊天开始。 打开你想修改的项目聊天,然后选择或直接指派与该工作职责相符的智能体。如果你不确定哪个智能体合适,请先让团队说明清楚,再开始构建。
本指南汇总了那些能持续帮助你的智能体团队获得更好结果的技巧。它们都不需要特殊能力。关键在于你说什么,而不是你如何排版。无论你是在写第一条请求,还是在完善一个成熟项目,同样的原则都适用:输入清晰的思路,输出清晰的结果。
先让团队提问,再开始构建
想获得更好结果,最有效的方法之一是:当一个请求很大或很模糊时,主动邀请提问,而不是寄希望于团队猜对。先说明你想要什么,然后在结尾加上一句:
在开始之前,请向我提出任何你需要的问题,以便充分理解我的需求。
你通常会收到一些你自己未必会想到要回答的问题,无论是关于边界情况、目标受众,还是权衡取舍。提前把这些问题说清楚只需要一分钟;等构建完成后才发现,就意味着要返工。这样第一次产出的结果就会更接近你的真实意图。
第 1 步:输入前先做决定
明确你要构建什么
前期花几分钟思考,往往能省去后面大量反复写提示词的时间。开始之前,请确保你能回答四个简单问题:你要构建什么,它是给谁用的,他们为什么会使用它,以及你希望他们采取的主要操作是什么。
这个主要操作通常被称为 CTA,也就是 call to action(行动号召)的缩写。它指的是你最希望用户点击或选择的按钮、链接或下一步操作,例如 Sign Up、Book a Demo、Start Free 或 Buy Now。
你不需要写一份完整的规格说明。目标只是为项目提供一个清晰方向。你的起点越具体,就越容易生成符合你设想的结果。
为一款面向自由职业者的预算管理应用构建一个单页网站。主要 CTA 是“Start Saving Smarter”。使用大胆、有表现力的视觉风格,搭配大字号和鲜明配色。
勾勒用户路径,而不只是页面
优秀设计不仅存在于页面上,也存在于页面之间。沿着用户的路径去思考:他们首先会看到什么,什么能建立信任,什么能让他们更有信心采取行动,而这个行动又会把他们带向哪里?即使只是一个三段式草图——首屏、证明内容、行动号召——也能显著提升请求效果,因为现在每个部分都有了存在的理由,也有了引导到下一部分的理由。
尽早确定视觉方向
风格越早确定,越容易建立;事后补救会困难得多。先选定一个方向:平静优雅、大胆颠覆、高端流畅,然后在你的第一条请求中用团队可执行的语气词说明它:极简、俏皮、电影感、面向开发者。这些词不只是装饰,它们会从第一个组件开始就影响排版、间距、颜色、阴影和圆角半径。在后续请求中重复使用同一条风格描述,以保持整体一致性。
使用平静、受健康疗愈启发的设计:柔和渐变、低饱和大地色、圆角、充裕留白。整体语气温和且令人安心。
第 2 步:写出有效的请求
描述结果,而不是实现方式
描述你想要的结果,而不是构建步骤。例如,“添加一个包含三个选项的定价区块,并让中间那个更突出”比详细说明页面应如何搭建更有用。重点说明应该出现什么,以及它为什么重要;至于如何实现,团队可以自行决定。
按模块工作,而不是整页处理
将请求范围限定在单个组件——首屏、功能网格、推荐语行、价格表——能让你更清晰,也更可控。如果某个模块不符合预期,你只需要调整那个模块,而不是把周围所有内容都重新生成。先构建一个区块,审查它,优化它,再继续下一个。整页请求会产生噪音;组件请求会产生有效信号。
创建一个功能区块:居中标题,下方并排三个卡片,每个卡片包含一个图标、一个标题和一行描述。使用柔和阴影,悬停时轻微上浮。
使用真实文案
占位文本会掩盖问题;真实文案会暴露问题。真实标题可能需要两行;真实 CTA 可能作为动词更有效。写出用户实际会读到的内容,即使它还只是草稿——当内容是真实的,布局、间距和设计决策都会更好。
首屏标题:“Design Calmly.” 副文案:“Turn stress into structure.” CTA:“Start Building Free.” 采用以文案为中心的布局,并保留充裕的垂直间距。
明确写出真实元素
用清晰、具体的词来描述你希望页面上出现的内容。你不需要懂设计术语——只要说出用户应该看到或交互的元素,比如个人资料卡片、按钮或表单。
具体的请求比宽泛的请求更容易实现。先从你需要的基础元素开始,再逐步补充细节。
创建一个个人资料卡片,包含照片、姓名和关注按钮。在姓名旁边添加一个小的“Verified”标签,并在有人悬停其上时显示简短说明。
第 3 步:精准修改
为每次修改限定范围:哪些要变,哪些不变
在调整现有内容时,务必同时明确两件事:什么需要改,什么绝对不能改。使用“replace”“update”“adjust”这类方向明确的词,而不是“make this better”这种模糊表达,并把你喜欢的部分圈定保护起来。这里的精确性,决定了迭代是否会变成倒退。
将 CTA 文案改为“Get Started”,并增加其水平内边距。保持当前颜色、字体以及本区块中的其他所有内容不变。
一次只做一个有意义的改动
先更新文案,再更新布局,再更新交互,并在发出下一条请求前检查每次结果。小而明确的步骤会逐渐累积成一个精致产品;而在一条消息里塞入十项改动,只会累积歧义,一旦出错,你也无法判断究竟是哪项改动导致了问题。
任务进行中的修正应在聊天中完成。 当你的聊天中可使用 Prompt Queue 且智能体工作正在进行时,后续消息会排在当前运行任务之后。发送下一条副本前,请先确认你的消息已出现在队列中。如果看不到队列控制,请不要重复发送:等待当前任务完成,或者如果你的聊天提供中断控制,则使用它,然后在发送后续消息前确认任务状态。详情请参阅 项目聊天。
比 UI 多想一步
如果你的项目不仅要看起来精致,还需要具备实际行为,就要同时定义外观与行为。请明确用户在已登录和未登录状态下会看到什么,动态内容来自哪里,以及界面如何处理空状态、加载状态和错误状态。你不需要有一个可运行的后端才能围绕这些场景进行设计——尽早规划它们,有助于避免后期大规模 UI 返工。
如果用户已登录,在右上角显示他们的头像和姓名。如果未登录,则显示一个“Log In”按钮,并跳转到认证页面。
常见问题
我该如何为 AI 智能体编写有效的提示词?
请按以下关键要素组织你的提示词:
1. 背景 —— 说明当前场景。解释你正在构建什么,以及当前进展到哪里。
2. 目标 —— 明确说明你想要的具体结果或功能。
3. 需求 \& 限制 —— 清楚列出哪些内容需要更改,哪些必须保持不变。
4. 预期结果 —— 定义什么才算成功(例如 UI 行为、错误处理、状态持久化)。
5. 参考资料 —— 尽可能附上截图、链接、工作流步骤或代码示例。分享前请移除密码、验证码、API 密钥、cookies、个人数据和支付信息。
示例:"我正在构建一个带侧边栏的仪表盘。在侧边栏底部添加一个退出登录按钮。它应清除会话并重定向到 /login。不要更改侧边栏布局或导航链接。点击后,用户应在 1 秒内看到登录页面。"
我该如何处理涉及多个功能的复杂请求?
对于复杂请求,请将其拆分为更小的任务:
1. 说明当前问题和最终目标。
2. 分别列出每个子任务(任务 1、任务 2、任务 3)。
3. 在进入下一个任务前验证当前任务。
4. 最后测试完整流程。
这种方法可以减少因一次要求智能体做太多事情而产生的意外改动。每条提示词都应聚焦于一个单一且可验证的结果。
我该如何编写用于修复 bug 的提示词?
一条有用的 bug 修复提示词应包含:
- 页面、功能、环境以及受影响的用户
- 复现问题的准确步骤
- 实际行为与预期行为
- 完整的错误文本以及错误发生的时间点
- 相关截图或日志,并移除密码、Token、cookies、个人数据和支付信息
- 哪些内容必须保持不变
- 如何验证修复,以及需要执行哪些回归检查
示例:“在 Preview 的结账页面,选择 Submit 会返回 500 错误。预期:订单被确认,用户进入感谢页面。复现方式:[steps]。修复根因,但不要更改购物车总价或支付流程,然后验证一个支付成功案例和一个支付被拒案例。我已从附带日志中移除所有敏感值。”
我该如何编写用于修改页面布局或样式的提示词?
请求页面修改时,请包含:
1. 要修改的具体页面、模块和元素。
2. 当前状态和目标结果。
3. 参考链接或截图。
4. 必须保持不变的功能。
5. 验收标准(例如必须同时适用于桌面端和移动端)。
示例:"在 /pricing 页面上,将套餐卡片网格在桌面端从 2 列改为 3 列。移动端布局保持单列。参考这张截图 [attach]。不要更改卡片内容或按钮样式。"
如果智能体在我纠正后仍不断做出错误修改,我该怎么办?
当智能体反复偏离预期时,继续增加说明有时反而会造成更多混乱。此时请改用以下方式:
1. 保留当前状态 —— 停止发送相互重叠的修正。如果你的聊天中显示 Revert 控件,请在使用前阅读其确认文本,记下你需要保留的后续更改,并在之后验证项目。如果范围不清楚,请不要继续;请参考 Project chat 指引,或附上已脱敏的 Chat Link 和截图联系支持团队。
2. 清除噪音 —— 不要在原有说明上继续叠加额外指令,而是从头开始,清晰地重述核心问题。
3. 一次只处理一个任务 —— 先专注修复单个问题,再继续下一个。
退一步,以渐进方式逐项处理修改,通常会比试图在一条提示词中修复多个相互重叠的问题更快解决问题。