提示工程
针对大语言模型的提示工程引发了争论：用户是否应该需要专门技巧，才能从 ChatGPT 之类的工具中获得好结果。评论者分享资源和策略——例如详细的系统提示、结构化输出，以及把任务拆成步骤——同时质疑这到底算不算“工程”，还是只是试错式沟通。许多人预计，随着模型和界面改进，这些怪癖会逐渐消失，但也指出，学习如何编写更清晰的提示，已经揭示了关于人类沟通、歧义和用户界面设计的更广泛教训。
OpenAI 指南的现状与替代资源
- 很多人指出 OpenAI 指南并不新；它只是第一次出现在 HN 上。
- 几位评论者表示有更好或更完整的资源（其他指南、课程、GitHub 仓库）。
- 有些人认为这份指南是一个不错、简洁的入门；也有人说它只涵盖“基础演示”，遗漏了复杂系统提示和结构化输出等强大模式。
提示工程是否必要？
- 一派认为它不该存在：如果语言模型真正理解自然语言，那么直接说人话加上好的 UX 就该足够。
- 另一些人回应说，当前的 LLM 并不完美，而量身定制的提示确实能显著改善结果。
- 还有人将其与人类也需要训练才能清晰沟通作比较；含糊不清和缺少上下文，是人类和 LLM 都常见的失败模式。
- 一些人预计，随着模型和界面改进，提示工程会逐渐淡出，类似计算中底层硬件约束变得不那么显眼。
它真的算“工程”吗？
- 一段很长的子讨论争论这个术语：有人把它称为试错式的“手艺”，而不是工程。
- 另一些人说，在约束下进行迭代调优，正是许多工程学科的真实面貌。
- 有人建议其他叫法：“提示制作”、“上下文组合”。
- 潜在的张力在于：需要达到怎样的理论/严谨程度，某件事才配得上“工程”这一标签。
讨论的技巧与实践
- 常见建议：明确、提供上下文和参考文本、拆分复杂任务，并允许“思考”步骤。
- 大量使用冗长、精确的系统提示；每一种不想要的行为都会引出另一条规则或示例。
- 通过 JSON schema、函数调用和外部工具实现结构化输出，被认为很强大但也很复杂。
- 语气和框定方式很重要：严格命令、情绪化语言（“享受”、“感到尴尬”），甚至威胁，都能改变行为，这让一些评论者感到不安。
UX、界面与未来演进
- 与 Google 搜索相比：提示工程被类比为高级搜索运算符。
- 有些人预计会转向结构化或混合式查询语言（类似 SQL、类似 CLI），以及带有更多过滤器和选项的更丰富 GUI。
- 另一些人预测，随着语音转文字和 LLM 融合，口语化、对话式界面将占主导。
评估、可靠性与安全性担忧
- 一些人批评忽略提示工程的评估，认为这低估了模型能力。
- 反驳观点是：针对每个示例手动调优提示属于“作弊”，在真实系统中并不可行。
- 提示注入，以及“指令”和“数据”之间缺乏清晰边界，被视为影响可靠性和形式化推理的根本问题。