Prompt 是工程问题，不是用户问题
提示词决定模型输出质量，但把提示词暴露给用户，相当于把 SQL 暴露给业务人员。少数人喜欢，多数人困惑。
产品应该把提示词封装成业务控件：用户选择「写一封友好的催款邮件」，而不是输入「请以专业且友好的语气写一封邮件，包含……」。
表单式生成界面
用表单收集必要信息，再自动拼装提示词，是大多数场景的最优解。用户填字段、选选项、点生成，得到的是稳定、可预期的输出。
高级用户可以在表单旁边保留一个「专家模式」，但默认界面必须简单。
- 必要字段最少化：只问影响结果的问题
- 选项代替自由输入：提供语气、长度、风格选择
- 预览即反馈：修改参数后立即看到差异
保留一部分自由表达
完全表单化会扼杀探索。设计上可以给用户一个「补充描述」框，让有表达欲的用户自由补充，其他用户完全不需要碰它。
自由输入框要限制长度并做引导，避免用户把整段需求都塞进去。
让输出可编辑
提示词界面的终点不是生成，而是编辑。用户拿到结果后应该能直接改、重新生成、保存版本。产品把生成和编辑放在同一个画布，工作流才完整。
把 Prompt 藏起来的本质，是让用户只关注结果，不关注技术。
简单模式与专家模式的取舍
默认界面用表单和选项，把复杂指令留给系统；专家模式可以开放自由输入，但必须放在不打扰普通用户的位置。
判断标准是：一个第一次打开产品的用户，能不能不看帮助就完成生成。如果必须理解「参数」「风格权重」，说明界面仍然太技术。
提示词版本管理
提示词会频繁调整，没有版本管理就没法回滚。把提示词模板放在代码仓库里，和业务代码一起评审、一起发布，模型输出变化时能追溯到具体版本。
每个模板记录三个信息：用途、示例输出、已知限制。这样团队换人、换模型时，都能快速理解为什么要这样写。
提示词不是一次性文案，而是一套需要持续维护的产品资产。
提示词的评测绑定
每次修改提示词，都应该绑定一组评测用例：同一批输入跑修改前后两个版本，对比输出质量。没有评测的提示词修改，等于凭感觉改代码。
评测用例要覆盖典型场景、边界场景和失败场景，并定期用真实用户输入补充。
当提示词改动越来越频繁时，评测绑定会成为团队唯一的安全网。