— Was ist schlecht? — Alles, was aus der Schwäche stammt.— 什么是恶? — 一切源于软弱的东西.
我对提示词工程的立场
说实话, 我认为对普通用户而言, 在提示词工程上钻得太深, 收益是递减的. 这个领域本身很有意思, 但掌握几条强而通用的原则, 远比在细枝末节里打转来得实际. 这篇是我一路下来的总结: 学到了什么, 早就知道什么, 以及对每天打交道的几个主流模型的个人看法.
模型看法
对模型的看法, 是这一页上过期最快的东西, 所以这一节刻意带着时间戳: 现行的看法在前, 2025 年 9 月的快照封存在后 — 也顺便留个记录, 看看这行当变得有多快.
2026 年的看法(写于 2026-07)
为什么是现在? 因为中国模型又一次迎来井喷, GPT 与 Claude 的竞争也愈发白热, K3 已经在某些方面反超了 Fable — 价格还更低. 地图该重画了.
| Claude | GPT | Gemini | |
|---|---|---|---|
| 编码 | 断档强 (Claude Code) | 扎实; codex 在发力, 前端是短板 | 已经不行了 |
| 研究与思路 | 工作伙伴 — 会反驳, 有自己的主张 | 认真, 但回答 是一面文字墙 | 太顺从你了 |
| 搜索与信息 | deep research 不错; 但不是 Google | 还行 | 最强 — 搜索引擎 是自家的 |
| 图片与视频 | 完全不会生成图片 | 图片生成好得离谱; 还能看懂视频 | 画图不错; 看视频几乎无门槛 |
| 代价 | 贵得要死, 限制极紧 | 默认就长, 说了也还是长 | 拿旧对话猜你, 还常猜错 |
Gemini: 信息担当
先说坏消息: 在写代码这件事上, Gemini 已经开始流口水了 — 仍然强过一部分国产模型, 但比不过国产的第一梯队, 这一点放到最后说.
好消息是它背后站着的东西: 世界上最好的搜索引擎. 这让它在信息获取上几乎无可争议地最强, 整合能力也算体面.
但它的对齐调得太急于讨好: 它更愿意“照顾你的想法和感受”, 而不是直截了当地解决问题, 更不用说跟你争一个决策 — 有时它摆出几个选项给你挑, 也更像是摆给你看的.
画图不错; 看视频几乎没有门槛, 毕竟 YouTube 就在自家院子里. 作为交流想法的对象, 我给 8 分; 写码, 就算了.
GPT: 稳妥首选
先把话说在前面: 下面的抱怨是我个人的; 对大多数人而言, GPT 仍然是该选的那一个 — 没有硬性理由排除它的话, 选它不会错. 它在算力, 成本和价格上有实打实的优势, codex 最近也确实在用功.
我的不满都出在气质上:
- 它信奉最少假设 — 先看, 后动, 一件一件来. 稳得可敬, 也和 Claude 恰好相反: Claude 爱做假设, 而且有自己的主张.
- 与它讨论研究, 梳理方法论时, 回答动辄几千字, 条理再好也架不住量 — 调过语气, 写过个人指令, 也只是略微收敛. 对一个 ADHD 的读者, 这是实打实的成本.
- 它写前端确实拿不出手, 审美有时甚至不如 Gemini — 而偏偏大多数人都拿 GPT 写前端, 千站一面, 又把这个问题加重了一层.
反过来记一笔: 它的图片生成好得近乎离谱(我自己会拿它画着玩), 而且真的能看懂视频 — 这两样 Claude 都做不到. Claude 的图片“生成”, 是拿代码一笔一笔画出来的, 换句话说: 没有这回事.
Claude: 工作伙伴
Claude 是我个人最喜欢的模型, 而且我是睁着眼睛说这句话的: token 贵得要死, Fable 的限制收得极紧, 公司的姿态也实在难看 — Dario 不喜欢中国, 更是臭名远扬. 但活儿是活儿.
写代码, Claude Code 的打磨加上一个几乎处处坐在 SOTA 或贴着 SOTA 的模型本体, 是断档的强, 几乎没什么可争的. 国内对 A 社的批评我都知道, 有些我也认 — 但我拿它是来干活的, 不是来搞公司崇拜的.
而我一天里最要紧的那部分 — 聊研究方向, 整理和整合信息, 把一个论点辩到深处, 学一样难的东西 — 它是我用过最强的. 在梳理研究决策这件事上, 它实打实帮过我大忙. 它的 deep research 也确实不错; 论纯搜索, 还是 Google 赢.
工具, 不是偶像
最后一点, 大概也是这一节里唯一不会过期的一条: 别把模型玩成饭圈, 这不是追星. 它们是工具 — 对我来说, 既是工具, 也是工作伙伴, 所以“会跟我争, 有自己站得住的主张”远比“一味顺着我”值钱.
也别搞公司崇拜: 工具不称手的那一刻, 当场换掉. 说得具体些 — Kimi K3 已经是 Opus 级别的模型, web dev 甚至比 Fable 5 还强出一大截. 哪天它谈研究也有 Claude 的水准, 价格再只要三分之一, 我立刻就换.
封存: 2025 年 9 月快照
模型和模型显然不是生而平等的. 不同模型擅长不同的事, 理解各自的长处才能用得顺手. 以下是我的个人观察.
总览
| 特性 | Claude | GPT | Gemini |
|---|---|---|---|
| 核心强项 | 代码生成 | 头脑风暴与出点子 | 信息综合 与头脑风暴 |
| 编码能力 | 顶级 (会过度工程) | 称职的全能选手 | 可靠 (严格贴题) |
| 幻觉 | 极低 | 高 (且毫无自知) | 高 (但有时很明显) |
| 提示词遵循 | 低 (常加没要求的功能) | 中 (会加多余的复杂度) | 高 (紧贴需求) |
| 搜索与查证 | 一般 | 一般 | 强 (擅长综合信息) |
Claude: 代码担当
就我的经验, Claude 在编码任务上是第一梯队. 它理解和生成代码的能力都非常出色, 最突出的是幻觉率低得惊人 — 几乎不编造事实, 这一点攒下了很高的信任. 不过, 编码上的强有时也是把双刃剑: 它容易过度工程, 加上一些没人要求的功能, 而且不打招呼. 比如我要一个只负责传输 BVP 传感器原始数据的脚本, 它自作主张把心率计算和发送的逻辑也加了进去. 写作能力同样不弱, 但头脑风暴和拿主意就显得平庸, 常常偏向“安全”的中间路线答案.
GPT: 脑暴担当
GPT 在头脑风暴和出点子上很能打, 生成创意选项, 换角度审视话题的能力不输给谁. 但它似乎不太会核查网络信源的可信度, 搜到什么信什么. 和 Gemini 类似, 它也容易产生幻觉且毫无自知; 又和 Claude 一样爱揣测用户需求, 有时加上不必要的复杂度. 编码能力扎实, 但我感觉够不到 Claude 的水平. 一个称职的全能选手, 却始终没成为我处理专项任务的首选.
Gemini: 综合担当
在我看来, Gemini 擅长搜索类查询和信息综合, 头脑风暴能力与 GPT 不相上下. 和其他模型相比, Gemini 更能抓住用户明确要求的东西, 更贴着提示词的需求走.
编码方面, 它的产出复杂度未必总能比得上 Claude, 但最大的长处是可预测, 靠得住. 它高度忠实地执行指令 — 当你需要输出严格对齐需求时, 它是可贵的搭档. 在和 Gemini 2.5 Pro 长期协作写代码的过程中, 最让我印象深刻的是它的长上下文记忆: 在漫长复杂的对话里, 它能记起很早之前的细节 — 这对迭代式开发是显著的优势.
但它主要的缺点是爱产生幻觉. 有时很隐蔽, 有时却很扎眼: 比如让它找论文, 它可能凭空造出一篇 — 标题像模像样, 作者齐全, 还附一个哪儿也打不开的假 URL.
真正有用的实战技巧
哪怕秉持极简主义, 我还是攒下了几个确实有效, 明显改善了我和 AI 交互质量的技巧.
1. 用类 HTML 标签组织结构
我过去习惯用代码块来组织提示词. 后来发现, 用类 HTML 的标签来划分提示词的不同部分要稳健得多 — AI 能清楚地分辨哪些是指令, 哪些是参考材料, 哪些是示例.
比如:
<instructions>
请分析以下用户反馈.
</instructions>
<feedback_text>
用户报告应用在启动时崩溃.
</feedback_text>2. 给 AI 设定人设
给 AI 指定一个人设, 是我以前不太用的技巧, 但效果出人意料地好. 它不只是噱头: 它为 AI 划定了要模仿的语境, 语气和知识水平.
比如:
“假设你是一位资深的 AI 研究教授. 请带我过一遍强化学习的核心概念.”
始终重要的核心原则
和 AI 打交道, 有些道理从一开始就很清楚, 至今仍是拿到高质量结果的根基.
1. 信号最大化, 噪声最小化
上下文为王, 但相关的上下文才是整个王国. 给模型的应该是它做好这件事所需要的东西, 而不是你手上有的所有东西. 说清目标, 约束和关键假设; 要代码时, 给出函数的用途, 它的 API, 以及它在系统里的位置.
反过来, 用无关信息“污染”上下文 — 比如调试时甩过去一张糊掉的屏幕照片 — 只会帮倒忙.
2. 拆解大问题
指望 AI 一口气搞定一个模糊的大需求, 结果多半平庸. 把复杂任务拆成更小的, 按顺序推进的步骤, 效果要好得多.
比如, 与其直接说“做一份关于 X 主题的演示文稿”, 不如拆开来:
- 列出 X 主题演示的核心章节
- 起草每一页的内容
- 给出视觉主题与版式建议
- 生成演讲备注
不知道该怎么拆的话, 可以先让 AI 提一份计划.
即便如此, 用你自己的领域知识来拆任务, 永远会得到更好的结果.
我的实战清单
下面是我每天都在用的招数, 浓缩成一张清单.
- 结构先行: 用标签(
<goal>,<context>,<constraints>)清楚地划分提示词的各个组成部分. - 人设要有目的: 只在人设能实质性增加约束, 或提供有用的参照系时才用(比如“扮演一个挑剔的代码审查者”).
- 先计划后执行: 复杂任务先要一份简明的计划或大纲, 结构谈拢了再动手, 免得白费功夫.
- 事实问题证据先行:
- 要求 AI 在给出论断之前先给带 URL 的出处.
- 调研类任务, 先要一张“证据表”(来源, 论断, URL), 再让它做最终综合.
- 指定输出: 明确定义想要的格式, 长度, 风格, 以及输出必须满足的验收标准.
- 聪明地迭代: 小步循环. 冻结有效的部分, 一次只改一个变量, 才能定位到底是什么带来了改进.
存疑的“最佳实践”
有几条广为流传的提示词技巧, 我还没有被说服.
- 多说“要做什么”, 少说“别做什么”: 即请求永远应该用正向表述.
- 保持礼貌的语气: 即对 AI 客气一点会得到更好的结果.
在我自己的使用里, 这两条都没有表现出稳定, 可测的影响 — 但我保持开放.
结语
归根结底, 和 AI 的高效协作靠的不是什么秘密暗号, 而是把话说清楚, 给足上下文, 再为任务选对工具. 模型会一直演化, 但清晰表达和结构化思考这两条核心原则不会过时.