从想法到成品的 7 个角色提示词

我想完成这件事：[任务或已商定的计划]。

从当前状态接手，一直做下去，直到 [我能看到、用到或检查的最终结果]。

阅读相关文件来理解项目。查找你需要的信息。使用你能用的工具。

从头到尾负责这项工作：理解任务、实现、运行、检查，并修复失败的地方。不要每做一步就停下来问要不要继续。

凡是涉及页面的，用可用的浏览器工具（包括内置浏览器）打开它并真正去用。点按钮、填表单，走完用户会走的流程。修好你发现的问题，然后回头再检查一遍。

对于较大的任务，你可以把独立的部分委派给其他可用的 agent。你负责把结果整合起来，确保整体能正常工作。

在商定的范围内持续推进。需要我做决定、需要额外权限或范围要变时，再来问我。

最后，给我看完成的结果。告诉我怎么用、你检查了什么、还有什么没完成。

我想做 [想法]。我目前有这些：[笔记、截图、参考或项目]。

首先，帮我理清谁会用它、它解决什么问题、用户从哪里开始，以及最后应该得到什么。

找出我没考虑到、可能影响结果的地方。能从材料里自己找到答案的，就自己去查。需要我做的决定，先问最重要的那个问题。不要甩给我一份问卷。

讨论清楚之后，写一份我可以直接交给另一位工程师的任务说明。他们不用读我们的对话，就能明白要做什么、什么不在范围内、有哪些约束，以及“完成”是什么样子。

标出我们还没定下来的事。不要把你的假设变成已确认的需求。

实现上的决定留给工程师。先把任务说明给我看，等我批准。

问题是：[问题]。

我做的步骤：[步骤]。
预期结果：[结果]。
截图或报错：[材料]。

首先，按我的步骤复现它。找到原因，然后修好。修完后，重复同样的步骤，确认问题已经消失，附近的功能也还正常。

告诉我原因是什么、你改了什么、怎么验证修复的。

如果还没找到原因，就继续查。如果按我的步骤复现不了，告诉我你还需要什么。不要只是把报错藏起来。

[页面或功能] 在 [使用场景] 时很慢。

改动任何东西之前，先找出时间花在哪里。不要把更简单的代码误当成更快的代码。

用同样的操作和数据对比改动前后，并确认结果仍然正确。告诉我改了什么，以及这些改动有没有带来其他问题。

没测量过的提升，不要声称有。

按照 [参考图或设计要求] 做出 [页面]，并和项目其他部分保持一致。

不只检查正常状态。没有数据、加载中、出错、文字特别长时会怎样？在手机上还能用吗？

打开做好的页面，先检查 UI：布局、字体、颜色和间距和参考一致吗？

再检查 UX：用户能找到按钮、轻松填好表单、看出操作是否成功，出问题时知道下一步该做什么吗？

修好你实际发现的问题，给我看结果的截图。

不要因为代码能跑，就认为页面做完了。

让 [功能] 完整跑通。

当用户做 [操作] 时，应该得到 [结果]。沿用项目现有的做法，把需要读取、保存或更新的数据接起来。

真正试一下。正常流程能成功吗？输入无效、缺少权限、中途失败或者点第二次时会怎样？

确认页面显示的内容和实际保存的数据一致，现有功能也还正常。

告诉我怎么试，以及你测了哪些场景。

也考虑一下开发者体验（DX）：怎么调用 API、要传哪些参数、出错时怎么排查。给下一个人一个能直接运行的例子。

独立审查这次改动：[改动或任务位置]。
最初的需求是：[需求]。

不要依赖实现者对自己完成内容的总结。自己检查结果。找出漏掉的需求、可能导致失败的用户操作，以及破坏了原本正常功能的改动。

能跑的检查都跑一遍。每个问题都说明它怎么发生、有什么影响、问题在哪里。

改动任何东西之前，先报告问题。如果没发现值得修的，就直说。不要为了凑清单而编造问题。