在小团队协作里，需求澄清往往是整个开发流程中最容易出问题的一环。稍有疏忽，写出来的接口字段就和脑子里的预期对不上——你明明暗地里设定的是“用户注销后30分钟内禁止重新注册”，开发却只问了句“注销逻辑怎么处理”，然后就按最肤浅的理解去实现了。

要想让MarsCode生成的澄清问题不丢关键参数、不漏边界条件、不模糊业务动作，有四个步骤是绕不开的。顺序别乱，缺一不可。

第一步：用原始对话截取真实语境锚点

直接去需求群里找到产品经理发的那条原始消息——记住，必须包含截图里的整段文字。用鼠标选中完整内容（表情、换行、括号里的批注统统别漏），右键复制，粘贴到MarsCode搜索框最开头。

这一步最怕图省事。只复制“登录页要加手机号校验”这种干瘪句子，等于让模型凭空猜背景。正确做法是把上下文里的【时间戳+人名+括号说明】一并带走。举个例子：“@张伟 6月23日15:28发：登录页加手机号校验（对接信息平台v3.2，失败返回code=40302）”。【MarsCode会自己把括号里的v3.2和40302当作不可删改的技术锚点】，这就锁死了最基本的边界。

第二步：绑定具体执行角色与权限限制

在粘贴的内容后面另起一行，写清楚你能做什么、不能做什么。比如：“你是前端开发，无权修改后端校验逻辑，但需确认该字段是否参与JWT token生成。”

千万别写“请从前端视角提问”——“视角”这种抽象词模型听了只会懵圈。只有具体到“你调用的是/api/v2/auth/login，但不能改这个接口的入参结构”，MarsCode才会自动过滤掉所有“建议后端加字段”之类的无效问题。限制越具体，出来的问题越靠谱。

第三步：强制嵌入三个硬性细节项

① 第一个问题必须锁定字段名。比如：“手机号字段是叫phone_number还是mobile？”

② 第二个问题必须暴露校验时机。比如：“校验发生在点击登录按钮后，还是输入框失焦时？”

③ 第三个问题必须封死兜底行为。比如：“若信息平台超时，前端是显示‘网络错误’还是‘发送失败，请重试’？”

这三个问题缺一个就会出纰漏。漏掉①，字段名被随意映射，联调时哭都来不及；漏掉②，交互节奏全乱，用户体验无从谈起；漏掉③，错误提示文案永远对不上PRD。每一条都得是能直接复制粘贴进Jira评论区的真问题，不是泛泛而谈的“注意一下”。

第四步：禁用所有泛化提问句式

在提示词末尾加上一句硬性规则：“不出现‘还有哪些需要注意的？’‘是否还有其他要求？’这类开放式结尾；所有问题必须以‘是否’‘叫什么’‘发生在…时’‘显示为…’开头。”

开放式问题会让MarsCode进入“补充常识”模式，开始编造“建议增加loading状态”“考虑兼容iOS16”这类从来没人提过的需求。【一旦输出里出现‘建议’两个字，整个提示词就失效了】。把门关死，模型才会专注于你给的真实上下文，而不是天马行空地做补充。