用cursor做需求澄清需将模糊描述转为可验证事实：先划掉所有形容词副词，再对每个词追问具体数值、主体、条件和测量方式，最后将改写句直接置入提示词开头；结合真实会话日志或错误堆栈生成结构化验收项，严格按“①主体；②动作；③条件；④结果”格式输出且仅5条。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用Cursor做需求澄清时，常出现“功能要好用”“界面要美观”“性能要快”这类空泛描述，根本无法推动开发落地，更无法让AI生成可验证的验收条件。
把模糊诉求转成可验证的事实陈述
第一步：找到原始需求里所有形容词和副词，比如“快速”“稳定”“友好”“合理”，全部划掉。
第二步：对每个被划掉的词，追问“快到什么程度？谁在什么条件下测？用什么工具看？”——例如把“响应要快”改成“用户点击提交按钮后，前端300ms内显示loading状态，500ms内收到HTTP 201响应”。【没有具体数值、主体、触发条件的描述，一律视为无效输入】
第三步：把改写后的句子直接塞进Cursor提示词开头，不加任何铺垫。这一步操作起来很简单，直接复制粘贴就行。
绑定真实用户路径与失败快照
方法一：用真实会话日志替代假设场景
把测试同学录下的用户操作视频逐帧转文字，截取卡点前后3秒内容，粘贴进提示词。例如：“用户在/checkout页面输入优惠码‘SUMMER2024’→点击‘应用’按钮→3秒后弹窗显示‘优惠码不可用’→但后台日志显示该码status=active且expire_at=2024-12-31”。Cursor会据此生成“查优惠码校验逻辑是否跳过tenant_id过滤”“比对前端传入code与DB中code字段大小写”等检查项。
方法二：用错误堆栈反推断言条件
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
把崩溃时的完整堆栈用三个反引号包裹，紧跟一句：“基于此错误，列出5条必须满足的前置条件，每条以‘必须’开头，且能用自动化脚本断言”。例如：```TypeError: Cannot read property 'length' of undefined at CartItem.render (CartItem.tsx:42)``` → 生成“必须确保props.item不为null或undefined”“必须在CartItem组件顶层添加item?.id存在性校验”等。
强制输出结构化验收项
第一步：在提示词末尾加硬性约束
“所有验收项必须按以下格式输出：① 主体（谁/哪个模块）；② 动作（执行什么操作）；③ 条件（在什么前提下）；④ 结果（观测到什么现象）。禁止出现‘应该’‘建议’‘可能’。”
第二步：示例锚定格式
“正确格式：① 用户；② 点击‘保存草稿’按钮；③ 表单含未填必填字段；④ 页面不跳转，底部显示红色提示‘请填写邮箱’。”
第三步：禁用自由发挥空间
“不接受任何形式的解释性文字、背景说明、设计原理。只输出编号列表，每条不超过35字，共且仅5条。”
