3. 常见错误类型：理解偏差、信息缺失、格式错误、逻辑混乱、过度约束等

初始提示词："帮我写一个登录功能的需求文档。"

模型输出：一份泛泛而谈的登录功能PRD，包含用户名密码输入框、验证码、记住我选项等通用内容，但未涉及任何具体业务场景。

问题诊断：提示词存在三重理解偏差——①"登录功能"未指明是Web端、移动端还是小程序；②未说明是内部系统还是面向C端用户；③未提及是否需要第三方登录（微信/OAuth/SSO）。模型只能基于最常见场景生成通用模板。

修正后提示词：

请为我们的B2B企业SaaS平台（面向中小型物流公司）编写一份登录功能需求文档。
具体要求：
- 平台类型：Web端（Chrome/Edge浏览器），响应式适配平板
- 登录方式：手机号+验证码（主）、账号+密码（备）、企业微信扫码（可选）
- 安全要求：登录失败5次锁定30分钟，支持IP异常检测
- 需包含：功能概述、用户故事、界面原型描述、异常处理流程、验收标准
- 文档风格：简洁务实，面向研发团队，避免冗余描述

结果对比：修正后模型生成了包含具体业务约束、异常流程和验收标准的PRD，可直接进入研发评审。

复盘经验：理解偏差的修复核心是具象化——将抽象概念转化为具体场景、明确参数和边界条件。当提示词中的每个关键名词都有清晰定义时，模型的误解空间就被大幅压缩。

初始提示词："写一篇社交媒体推广文案。"

模型输出：一篇通用风格的推广文案，使用了"创新""优质""领先"等空洞词汇，没有具体产品信息、目标受众或行动号召。

问题诊断：提示词缺失了五个关键信息维度——①产品是什么（品类/名称/核心卖点）；②目标受众是谁（年龄/职业/痛点）；③推广渠道（微博/微信/小红书）；④营销目标（品牌曝光/直接转化/用户教育）；⑤品牌调性（高端/亲民/科技感）。

修正后提示词：

为我们的智能保温杯（品牌名：温芯，售价299元）撰写一篇小红书推广文案。
目标受众：25-35岁注重健康生活的都市白领女性
核心卖点：APP温度实时监控、24小时保温、轻巧便携（仅280g）
营销目标：促进新品首发期的用户认知，引导点击商品链接
品牌调性：温暖、科技感、生活美学
文案要求：
- 字数300-400字，使用小红书风格（emoji、短句、分段）
- 开头用痛点切入（如"总喝不到适温水"）
- 包含3个使用场景描述（办公、通勤、健身）
- 结尾引导点击评论区链接
- 附5个相关话题标签

结果对比：修正后生成的文案精准触达目标用户，包含具体场景和情感共鸣点，发布后互动率提升3倍。

复盘经验：信息缺失的修复策略是清单化补充——在提示词中建立"5W1H"检查框架（What/Who/When/Where/Why/How），确保每个维度都有明确答案。当信息完整度超过80%时，输出质量会出现质的飞跃。

初始提示词："把这段会议录音转成纪要。"（附录音转文字稿）

模型输出：一段连续叙述性文字，将讨论过程按时间顺序平铺直叙，没有区分决议、待办、争议点，无法直接用于项目跟进。

问题诊断：提示词未定义纪要的格式规范。模型默认采用"叙述体"而非"结构化体"，导致关键信息淹没在流水账中。

修正后提示词：

请将以下会议文字稿整理为结构化会议纪要，严格遵循以下格式：

# [会议主题]
- 会议时间：YYYY-MM-DD HH:MM
- 参会人员：（列出所有提及人员）

## 一、核心决议（3-5条）
每条决议用一句话概括，标注决策人

## 二、待办事项（表格形式）
| 事项 | 负责人 | 截止日期 | 优先级 |

## 三、争议点与讨论摘要
每个争议点包含：分歧双方观点、最终结论（如有）

## 四、风险与依赖
列出所有被提及的风险项和外部依赖

要求：
- 只保留与项目推进相关的信息，过滤寒暄和无关讨论
- 语言精炼，每条决议不超过50字
- 如信息缺失，标注"待确认"

结果对比：修正后生成的纪要可直接导入项目管理工具，待办事项自动形成任务列表，会议效率显著提升。

复盘经验：格式错误的修复核心是模板化输出——在提示词中提供明确的格式模板或示例，让模型"照葫芦画瓢"。对于高频场景（周报、PRD、会议纪要），建议建立团队级提示词模板库。

初始提示词："写一份技术选型方案，要求：1. 对比MySQL和PostgreSQL；2. 推荐其中一个；3. 不要有主观倾向；4. 结论要明确。"

模型输出：一份摇摆不定的方案，先详细对比两者优劣，最后给出"两者各有千秋，建议根据实际需求选择"的模糊结论，既没有明确推荐，又显得缺乏专业判断。

问题诊断：提示词存在明显逻辑矛盾——"不要有主观倾向"与"推荐其中一个"直接冲突。模型无法同时满足"客观中立"和"明确推荐"两个要求，只能选择折中输出。

修正后提示词：

请完成一份数据库选型方案，结构如下：
1. 客观对比：从性能、扩展性、生态、运维成本四个维度对比MySQL和PostgreSQL（各维度用表格呈现）
2. 推荐结论：基于以下业务场景给出明确推荐——
   - 业务类型：SaaS多租户系统，读写比例7:3
   - 数据规模：预计3年达到10亿行
   - 团队能力：5人后端团队，熟悉MySQL
   - 部署环境：AWS云托管
3. 推荐理由：结合上述场景，说明推荐选型的3个关键依据
4. 风险提示：列出所选方案的2个潜在风险及应对措施

要求：对比部分保持客观，推荐部分基于场景明确表态。

结果对比：修正后模型先客观对比，再基于具体场景明确推荐PostgreSQL（因其JSONB支持和扩展性更适合SaaS多租户），并给出了风险应对方案。

复盘经验：逻辑混乱的修复核心是解耦矛盾——将冲突的要求拆分为不同层次或不同部分，让每个部分内部逻辑自洽。同时，为可能冲突的要求设定优先级或适用条件。

初始提示词："为我们的智能家居APP起名，要求：1. 必须两个字；2. 必须包含'智'字；3. 不能与任何已知品牌重名；4. 必须体现'温暖'感；5. 不能使用生僻字；6. 必须朗朗上口；7. 不能有英文；8. 必须适合女性用户；9. 不能太普通；10. 必须注册得了商标。"

模型输出：尝试生成"智暖""暖智""智家"等组合，但每个都显得生硬或已被使用，最终给出"建议您自行脑暴"的无奈回复。

问题诊断：10条约束中，第1条（两个字）与第4条（体现温暖）和第9条（不能太普通）存在隐性冲突——两个字且含"智"字的温暖感名称空间极其有限。第10条（商标注册）是模型无法验证的外部条件，属于"不可执行约束"。

修正后提示词：

请为我们的智能家居APP（核心功能：远程控制、场景联动、能耗管理）提供命名建议。

方向要求：
- 名称长度：2-4个字（中文）
- 风格：温暖、科技感、现代
- 目标用户：25-40岁城市家庭用户（男女不限）
- 可用性：避免与知名品牌重名（如"小米""华为"等）

请提供10个候选名称，每个名称附：
1. 字面含义解释
2. 品牌联想（用户看到名称的第一感受）
3. 潜在商标风险提示（基于您的知识，标注"需专业查询"）

最后推荐3个最优选项，并说明推荐理由。

结果对比：修正后模型提供了"暖居""智域""联享""家枢"等10个候选，每个都有详细解释和风险提示，其中"暖居"被团队选中并顺利通过商标初审。

复盘经验：过度约束的修复核心是弹性化限制——将刚性要求（必须/不能）转化为柔性要求（优先/倾向），将不可执行约束（如商标注册）转化为"提示+人工验证"模式。同时，为关键约束提供"可妥协空间"。

实战建议：在实际工作中，五类错误往往同时出现。建议建立"三层检查机制"——第一层检查意图清晰度（理解偏差），第二层检查信息完整度（信息缺失），第三层检查约束合理性（格式/逻辑/过度约束）。每次提示词修改后，先小范围测试再全面应用，形成"编写-测试-修正-沉淀"的闭环。