目标：输出稳定、可复用、可评估的高质量 Prompt，兼顾方法论、实践模板与落地小技巧。
目录
- 目标与受众
- 方法论框架（RICCE+F+E）
- 通用结构模板
- 实践案例
- 小技巧
- 常见反模式
- 评估与迭代
- 模板库（可直接套用）
- 中文写法要点
- 检查清单（交付前自检）
- 示例 Prompt（可复制改造）
目标与受众
- 帮助团队在不同场景下写出稳定、可复用、可评估的 Prompt
- 面向产品、研发、数据、运营等多角色，兼容中文工作语境与跨领域任务
- 兼顾方法论与实战模板，提供落地小技巧与常见坑位规避
方法论框架（RICCE+F+E）
- 角色 Role：明确让模型以何种身份思考与取舍，如“资深架构师”“市场分析师”
- 指令 Instructions：用动词开头的单一动作，避免“帮我看看”“优化一下”等模糊词
- 上下文 Context：给必要信息与边界，不给无关材料；越贴近真实场景越好
- 约束 Constraints：时间/长度/风格/技术栈/可靠性等可验证约束，避免笼统要求
- 示例 Examples：少量高质量正反例，优先使用结构化示范（输入→推理要点→输出）
- 格式 Format：指定输出结构（JSON/要点列表/表格），利于程序或人审阅
- 评估 Evaluation：写清验收标准与自检步骤，支持自动化校验与可比对迭代
通用结构模板
角色：你是［角色］，擅长［关键技能/领域］
目标：请完成［单一明确任务］，达成的结果应满足［验收标准］
上下文：提供必要材料［数据/代码片段/约束背景］
约束：遵循［长度/风格/技术栈/时效/准确性］等硬性标准
示例：给出1–2个好例与1个反例，突出思路与输出结构
步骤：先列出你的处理步骤与关键判断，再产出最终结果
格式：以［JSON/要点/表格］输出；字段含义：［字段→描述］
自检：输出后逐项检查［覆盖度/正确性/一致性/边界情况］并给出结论实践案例
技术方案生成（架构）
- 角色：资深架构师（云原生/DDD）
- 目标：为［业务场景］设计服务拆分与依赖关系，兼顾扩展性与演进
- 上下文：现有系统约束、QPS、数据一致性要求
- 约束：只使用［技术栈］；列出权衡与关键决策点；控制在800字内
- 格式：要点列表＋关系简图描述（文本）
- 自检：对照非功能需求（性能/容错/可观测）逐项说明覆盖度
代码重构（前端/后端）
- 角色：高级工程师
- 目标：重构［模块/函数］以提升可读性与测试性
- 上下文：现有代码片段与主要问题
- 约束：保留外部接口；拆分纯函数；补充最小可测示例
- 格式：输出“重构思路要点”“新代码片段”“最小测试示例（伪）”“风险点”
- 自检：复杂度对比、依赖变更、边界条件覆盖
数据摘要（运营/分析）
- 角色：数据分析师
- 目标：从表格中提炼核心趋势与可行动建议
- 上下文：KPI与时间区间，关键人群与渠道
- 约束：剔除统计噪声；用置信表述；建议按影响力排序
- 格式：要点列表＋“建议→预期影响→实施成本→优先级”表格
- 自检：是否有数据支持、是否考虑偏差与季节性
文案改写（品牌/产品）
- 角色：品牌文案
- 目标：将文案改写为［风格］，用于［渠道］
- 上下文：受众画像与禁用词
- 约束：长度/语气/CTA清晰；避免夸大承诺
- 格式：3版候选＋差异点说明＋适配建议
- 自检：一致性、可执行性、是否踩雷
调研报告（市场/竞品）
- 角色：市场分析师
- 目标：整理［主题］现状与趋势，提出策略建议
- 上下文：来源列表与可信度等级
- 约束：标注来源；区分事实/推测；控制篇幅
- 格式：现状→趋势→机会→风险→建议；每项3–5要点
- 自检：信息覆盖度、来源可靠性、建议的可操作性
小技巧
- 先目标后材料：先明确“唯一产出”，再给必要上下文
- 动词指令：用“列出/比较/拆分/改写/设计/验证/总结”等动作词
- 可验证约束：长度、时间、技术栈、风格、格式、精度，尽量量化
- 示例优先：1–2个高质量示例胜过大量模糊要求
- 先步骤后结果：先让模型列步骤与判断，再产出最终答案，减少走偏
- 自检清单：要求输出后进行“覆盖度/一致性/边界/引用”自检并给结论
- 反例驱动：提供“不希望出现的输出”反例，明确禁区
- 渐进式迭代：从粗纲→细化→加约束→定格式；每次只引入少量新约束
- 格式即约束：JSON/表格字段就是验收标准，便于自动化与对比
- 限定角色与工具：指定身份与可用工具/库，缩小解空间，提升稳定性
常见反模式
- 多任务混杂：一个 Prompt 同时“分析+生成+改写”，容易互相干扰
- 目标不清：没有验收标准或单一产出定义，难以评估好坏
- 上下文冗余：给太多无关信息，稀释关键线索
- 约束空泛：如“专业”“全面”，没有量化与边界
- 示例误导：示例与真实任务风格不一致或字段不匹配
- 无格式约束：输出不结构化，难以复用与自动化检查
评估与迭代
- 明确验收标准：可度量的维度（准确性、覆盖度、结构化程度、风格一致性）
- 基准用例集：不同难度/边界值的代表性样本集
- 自动化校验：对 JSON/表格进行字段完整性、类型、取值范围检查
- A/B 迭代：一次只改一个因素（角色/约束/示例/格式），对比差异
- 误差分析：收集失败案例，定位是指令、上下文、约束还是示例的问题
- 迁移验证：跨域/跨语言复测，验证通用性与鲁棒性
模板库（可直接套用）
任务型
你是［角色］。请［动词］完成［任务］，满足［验收标准］。
上下文：［材料］。
约束：［量化要求］。
格式：［结构］。
自检：［清单］。创意型
你是［创意角色］。围绕［主题/受众］，提出［数量］个方案。
每个包含［洞察→概念→执行→风险］。风格参考［示例］。输出表格。学习/解释
以［授课角色］身份，用“类比→要点→例题→误区”结构解释［概念］。
长度≤［字数］。最后给3题自测题含答案。代码审查
你是［语言/框架］资深工程师。审阅代码并输出“问题→影响→建议→示例修复”。
约束：遵循［规范］，控制在［字数］。数据/表格整理
按［字段映射/规则］清洗并汇总数据。
输出“统计→异常→趋势→建议”。提供 JSON 与 Markdown 表格两版。沟通/邮件
以［身份］给［受众］写邮件，目的［X］。
结构“背景→请求→要点→时间/资源”。语气［专业/友好/坚定］。长度≤［字数］。翻译/改写
将文本改写为［风格/语气］，保持技术术语准确。
输出两版：直译与本地化改写，并列出差异点。搜索/调研
制定检索式与来源清单。
输出“检索策略→来源→摘要→可信度→空白点”。标注时间与版本。中文写法要点
- 明确动词与结果：少用“优化/完善”，多用“列出/比较/拆分/验证/格式化”
- 量化表达：约束尽量可度量，如“≤800字”“提供≥3个案例”“覆盖5个边界”
- 术语一致：同一概念同一叫法；字段、维度与示例保持一致
- 受众语气：面向管理者多用结论先行；面向工程师多用步骤与权衡
检查清单（交付前自检）
- 单一明确目标，且有验收标准
- 上下文足够但不过载，边界清楚
- 约束量化，可验证
- 示例贴近真实且字段结构一致
- 指定输出格式，便于复用与校验
- 要求模型自检并给结论
- 便于迭代：每次只改一个因素
示例 Prompt（可复制改造）
技术方案
角色：你是资深架构师（微服务/云原生）
目标：为［业务场景］设计服务拆分与依赖关系，满足可扩展与高可用
上下文：现状约束［…］、QPS［…］、一致性［…］
约束：仅用［技术栈］；列出权衡与决策；≤800字
格式：要点列表＋“服务→依赖→数据→非功能需求”四段
自检：检查性能、容错、可观测覆盖度并给出结论代码重构
角色：高级前端工程师（React/TypeScript）
目标：重构组件［X］提升可读性与测试性
上下文：代码片段与问题点
约束：保留API；拆分纯函数；加入最小测试示例
格式：重构思路→新代码片段→测试示例→风险点
自检：复杂度对比与边界覆盖说明