提示词不是越长越好，而是让目标、背景、限制和完成标准足够清楚。先把任务说明白，AI 才能把能力用在正确方向。
AI 以什么专业视角完成任务
要完成的具体动作与目标
受众、背景、输入和已有信息
格式、语气、篇幅与边界
什么结果才算完成，或参考什么样例
信息不确定时，让 AI 先向你提问，再开始生成结果。
人习惯依靠默契和上下文沟通，但 AI 看不到你脑中的产品、用户和标准。当问题只有一个模糊方向时，它只能补全一个“最常见”的答案。
“帮我写个产品介绍。”
产品是什么？写给谁？强调什么？在哪里发布？需要多长？这些关键决定都被留给了 AI。
“你是一名消费电子营销专家。为 25—35 岁女性撰写一款无线降噪耳机的推广文案，突出佩戴舒适和地铁通勤场景，语言自然、有生活感，500 字以内。”
不需要一次写出完美提示词。按照固定顺序补信息，遗漏会更容易被发现。
真正有效的方法不是背诵“万能句式”，而是持续减少歧义、缩小任务范围，并让结果可以检查。
例把“写个会议纪要”改成：整理议题、负责人和截止时间，删除闲聊，并用 Markdown 表格输出。
例先找关键技术因素，再对比代表企业，最后整理为带图表建议的 PPT 大纲。
例与其说“写得简洁”，不如给一段满意的文案，并说明要保留它的节奏与信息密度。
例把“讲得太抽象”改成：只重写量子叠加部分，用旋转硬币作比喻，并与二进制对比。
同一个公式可以适配完全不同的任务。下面两条提示词已经补齐角色、背景、要求和验收方式，可以复制后替换其中的信息。
适合搭建综述结构、比较观点和明确引用要求，不让 AI 编造无法确认的资料。
你是一名研究人工智能治理的伦理学研究助理，请协助我撰写“AI 伦理争议”文献综述。 背景：这部分将用于本科毕业论文，读者具备基础伦理学知识。 请完成： 1. 选择近三年具有代表性的三类争议，分别说明时间、事件背景和核心伦理冲突； 2. 从监管目标、风险分类和责任主体三个维度，对比欧盟与中国的人工智能治理思路； 3. 用表格梳理效用主义、义务论和美德伦理对这些争议的判断差异； 4. 全文控制在 1800—2200 字，引用使用 APA 格式； 5. 无法确认的文献或事实请明确标注，不要编造引用。
适合把目标人群、传播动作、预算和指标放进同一份可执行方案。
你是一家新茶饮品牌的社交媒体营销负责人。新品面向 18—25 岁大学生，传播预算不超过 5 万元。 请设计一个抖音挑战赛方案，要求： 1. 挑战赛名称同时包含“奶茶”和一个恰当的 emoji； 2. 参与动作在 30 秒内能够完成，例如展示一种创意喝法； 3. 提供三档奖品方案，并分别说明预算分配和参与门槛； 4. 给出预热、爆发、收尾三个阶段的执行时间表； 5. 说明播放量、参与量、到店核销率的估算依据。 输出结构：活动主题、参与规则、传播文案、奖品设置、执行时间表、风险预案、ROI 预估。
选择最接近的场景，替换方括号里的信息，再根据第一次结果继续补充要求。
当前显示 15 条 Prompt
让 AI 先澄清问题，再输出可执行的 MVP 方案。
你是一名资深产品经理。请帮助我把下面的想法整理成可执行的产品 Brief。 项目想法：[填写] 目标用户：[填写或写“不确定”] 限制条件：[时间、技术、预算] 请先列出最多 5 个真正影响方案的问题。在我回答前，不要直接给最终方案。 随后输出：1. 用户问题 2. 核心价值 3. MVP 范围 4. 明确不做的内容 5. 用户主流程 6. 页面清单 7. 数据对象 8. 验收标准 9. 风险与假设。
避免只说“高级感”，把感觉转化为可实现的设计规则。
根据以下产品信息提出 3 个明显不同、但都符合定位的 UI 方向： 产品：[填写] 用户：[填写] 希望用户感受到：[填写] 必须避免：[填写] 每个方向请给出：设计关键词、颜色、字体、栅格与留白、组件风格、首屏结构、动效原则、适合与不适合的原因。最后基于产品目标推荐一个方向，不要使用空泛的“科技感”和“高级感”。
先规划依赖关系和验收方式，再让 AI 开始改代码。
请先阅读当前项目结构和需求，不要立即写代码。 需求：[填写] 请输出：1. 当前结构判断 2. 受影响文件 3. 数据流 4. 实现步骤及依赖关系 5. 每一步的验收方法 6. 风险与回退方式。 计划确认后再逐步实现。每完成一步，说明改动、验证结果和仍存在的假设。不要修改与需求无关的文件。
要求 AI 先复现和定位，减少“猜一个修复试试”。
请按调试流程处理下面的问题，不要先猜修复方案。 预期行为：[填写] 实际行为：[填写] 复现步骤：[填写] 错误信息：[填写] 最近改动：[填写] 依次完成：复现问题 → 收集证据 → 缩小范围 → 给出最可能的根因及依据 → 设计最小修复 → 增加回归验证。若信息不足，明确说出需要哪项证据。
优先发现会影响真实用户的问题，而不是只讨论代码风格。
请审查这次改动。先理解需求和数据流，再寻找能够具体复现的问题。 重点检查：正确性、权限、输入验证、敏感信息、并发与状态、错误处理、边界情况、性能、可访问性和回归风险。 只报告有明确证据的问题。每项包含：严重程度、触发条件、用户影响、代码位置、建议修复。最后列出已覆盖和仍未覆盖的测试。
把不断增长的功能清单收敛成一个最短价值闭环。
你是一名负责交付的产品经理。下面是当前功能清单：[填写] 请先识别唯一的核心用户、核心场景和核心结果。然后把需求分成：本期必须有、可以手工替代、明确延后、应该删除。 最终输出：1. 一句话 MVP 目标 2. 最短用户主流程 3. 必须实现的页面与数据 4. 本期非目标 5. 两周内可验证的成功标准。若某项功能不能直接支撑核心结果，请默认延后。
在建表前先理解产品中真正存在的对象和关系。
请根据下面的用户流程推导数据模型，不要直接生成数据库代码。 用户流程：[填写] 依次输出：1. 核心实体 2. 每个实体的业务含义 3. 必要字段及原因 4. 实体关系 5. 状态变化 6. 唯一性与删除规则 7. 暂时不应该建表的内容。 最后用 3 个真实用户场景验证这个模型能否支持查询和修改。
不是机械缩小，而是重新确定移动端的信息优先级。
分析下面的页面结构：[粘贴结构或截图描述] 请分别为桌面、平板和手机定义：内容优先级、布局列数、导航变化、字号层级、间距、触摸目标、横向溢出处理和应该隐藏或延后的次要信息。 不要只给断点数值。解释每一处结构变化为什么更符合小屏用户任务，并给出验收清单。
从键盘、语义、颜色和反馈检查真实可用性。
请对下面的页面进行可访问性审查：[填写页面结构] 检查：标题层级、语义标签、表单标签、键盘顺序、焦点可见性、颜色对比、图标名称、错误提示、动态内容、减少动画偏好和触摸目标。 每项问题说明：受影响用户、触发方式、修改建议和可验证的验收标准。不要只输出通用清单。
让前后端对同一种请求、响应和错误达成一致。
为下面的功能设计最小 API 契约：[填写] 请输出：方法与路径、认证要求、路径/查询/请求体字段、成功响应示例、错误响应格式、状态码、幂等性、分页或限流要求。 随后分别给出前端和后端的验收用例。不要实现代码，直到契约确认。
在改变真实数据结构前识别丢失数据和停机风险。
当前数据结构：[填写] 目标结构：[填写] 生产数据情况：[填写] 请设计向前兼容的迁移步骤，包括：结构变化、旧数据回填、应用代码兼容顺序、约束启用时机、验证查询、回滚方式和备份要求。 明确标出任何可能删除、截断、重建或长时间锁表的操作。
通过 URL、状态码、响应和日志判断问题处在哪一层。
请根据证据定位联调问题。 浏览器请求 URL：[填写] 方法与状态码：[填写] 响应内容：[填写] 浏览器控制台：[填写] 服务端日志：[填写] 按 DNS/连接、路由、认证、输入校验、业务逻辑、数据库、响应解析七层排查。先指出已有证据支持或排除哪一层，再给出下一项成本最低的验证动作。
比较环境而不是继续随机修改业务代码。
本地环境与失败环境存在差异。请先建立对比表：操作系统、运行时版本、包管理器、锁文件、环境变量、工作目录、网络、数据库版本、构建命令和错误输出。 根据差异按可能性排序根因，每次只设计一个验证实验。不要建议删除全部依赖或重装系统，除非已有证据指向依赖损坏。
检查输入、身份、权限、秘密和外部依赖的边界。
请先画出这次功能的信任边界：浏览器、服务端、数据库、文件存储和第三方服务。 逐项检查身份伪造、越权、注入、XSS、CSRF、敏感信息泄漏、文件上传、速率限制、日志泄漏和依赖风险。 只报告有明确攻击路径的问题；每项包含前置条件、影响、修复和验证方法。
从用户流程、数据和恢复能力判断是否真的可以发布。
请为本次发布执行上线审查。 版本目标：[填写] 主要改动：[填写] 检查核心用户流程、移动端、权限、数据迁移、环境变量、第三方服务、错误状态、性能、SEO、监控、备份和回滚。 输出必须阻塞发布的问题、可以发布后跟进的问题，以及每个关键检查项的验证证据。不要把“构建成功”当成发布成功。