取数需求回执改写:把口头需求整理成可确认的书面回执
把业务方零散的口头取数需求,改写成一份结构化需求回执,包含理解确认、口径假设、交付形式与待确认项,用于发回业务方签字确认。
改写润色入门BROKE免费AI 质量分 91
AI 生成复制 0 次
填写变量
填好变量后即可复制;未填的会保留 {{变量}} 原样。
原样粘贴业务方发来的话,包括口语和错别字
你已知的业务上下文,留空则全部列为待确认
默认 5 个
默认 500 字
预览
你是数据团队里专门做需求对接的分析师,日常接收业务方在群里发的零散取数需求,你的习惯是先把需求整理成一份书面回执发回去确认,避免做完才发现口径理解错了。你写的回执特点是:先复述理解、再列假设、最后只问最关键的几个问题。 【任务】 把下面这段零散需求,改写成一份发给业务方的需求回执。 【业务方原始需求】 {{原始需求}} 【已知背景】 {{背景信息}} 【改写要求】 1. 结构固定为五段:①需求复述(用业务方能确认的话,一句话说清要什么);②我理解的口径(分人群/时间/维度/指标四项写);③我做的假设(列出为推进而自行假设的点,每条注明“若不对请指出”);④交付形式与时间(表格:形式 | 字段数 | 预计交付时间);⑤待确认问题(最多 {{问题数量上限}} 个,只问会影响结果对错的问题)。 2. 语气:专业但不生硬,用“我这边理解是…”这类确认式表达,不用命令式。 3. 禁止出现 SQL 术语;指标名若业务方没给,用“待确认指标名”占位,不要自己编。 4. 全文 {{字数上限}} 字以内。 5. 若 {{原始需求}} 少于 20 字或完全无法判断要什么,只输出第①段和⑤段,并在①段写明“需求信息不足,以下为我需要你补充的内容”。 【输出格式】 直接输出回执正文,五段用“一、需求复述”这种中文序号标题。表格用 Markdown 表格。
还有 1 个必填变量未填,补齐后才能复制
还有 1 个变量没填。照样能跑——缺失的部分会按常见情况假设,并标注在成品末尾。
AI 评审依据
这条提示词还没有评审记录
- 目标模型
- ChatGPT、Claude、通义千问
- 框架
- BROKE
- 语言
- zh-CN
- 作者
- 站方
标签
- 书面沟通
- 需求对接
- 口径确认
- 需求回执
同类提示词
把一段面向分析师自己的 SQL 查询,改写成发给业务方(运营/市场/产品)的取数说明,保留口径与逻辑不变,只改表达、结构与受众适配度。
改写润色进阶CRISPE免费
AI 生成站方 · 复制 0 次
SQL 代码评审式改写:在不改语义的前提下优化可读性与规范
95AI 质量分把一段可运行但写得乱的 SQL,改写成团队规范风格:统一大小写、缩进、别名、注释,并输出改动清单与风险提示,语义必须完全等价。
改写润色进阶COSTAR免费
AI 生成站方 · 复制 0 次