假设你是一位拥有五年金融系统测试经验的资深QA工程师，当前任务是在弱网环境下模拟用户连续提交三次订单，验证支付状态同步的准确性——本教程的核心，便是为MarsCode打造一套可直接落地的测试计划提示词。别再使用“请写个测试计划”这类模糊指令，那只会得到空泛的回复，难以指导实际执行。

明确角色与目标再写提示词

第一步非常简单：先给MarsCode明确设定角色。直接告诉它“你是一位有五年金融系统测试经验的资深QA工程师”。这一步看似基础，但对最终输出质量的提升极为关键——身份若不确定，输出的专业颗粒度就难以达到要求。

接着，用一句毫无歧义的话锁定本次测试的核心目标。例如“验证用户在弱网环境下连续提交三次订单时，支付状态同步是否准确”，而不是“测试支付功能”这类笼统表述。目标一旦模糊，后续生成的测试点必然会零散、不聚焦。

最后，必须强制规定输出格式。要求以【测试维度】【具体用例】【验证方式】三列表格呈现。无论采用Markdown还是纯表格形式，核心是让结构化成为硬性约束。如果不加格式限制，MarsCode很可能输出大段描述文本，看似完整，实则难以直接执行。

注入四个关键角度的触发词

方法一：功能主干角度——利用“正向流程链路”触发。示例提示：“列出从登录→选品→下单→支付→结果页的完整正向链路，每一步标注需要校验的业务规则。”这条链路走通后，后续的边界条件和异常场景才有正确的参照基准。

方法二：边界与异常角度——通过“极端值+中断场景”组合触发。示例提示：“针对金额字段，生成包含0元、超长数字（18位）、负数、含字母的测试数据；并补充网络断开、token过期、并发重复提交三种中断场景的检查项。”请注意使用“列出”和“补充”，而不是“考虑一下”，后者几乎无效。

方法三：环境兼容角度——直接限定设备和协议。示例提示：“输出iOS 17/Android 14/鸿蒙NEXT三端在HTTP/2和QUIC协议下，对同一笔订单状态轮询接口的响应一致性检查点。”这一步是将兼容性从空话转化为可执行检查的关键。

方法四：数据流向角度——强调跨系统依赖。示例提示：“梳理订单创建后，资金系统、风控系统、物流系统各自接收的数据字段及校验逻辑，指出三个最容易出现数据延迟或错漏的交接节点。”这个角度最具价值，也最容易被忽略。许多人在支付状态测试中只关注前端，却忽略了后端系统间数据流动才是真正的风险所在。

禁用模糊词汇，替换为可执行指令

将“全面一点”替换为“覆盖前端展示、后端接口、数据库写入三层校验”。将“考虑下异常情况”替换为“至少列出五种服务端返回非200状态码时，前端toast提示、错误日志、重试机制的对应行为”。
绝对避免使用“尽量”“大概”“可能”这类模糊词，MarsCode无法执行模糊指令。如果你给出“可能”，它就会按概率采样几次，最终结果必然偏离实际需求。