8.0
热点
AI SCORE
编程提效2026-05-11 20:45
Prompt 工程缺失的一层：思考质量
DEV Community · Julien Avezou#Prompt#提示工程
Editor brief · 编辑速览
揭示大多数 prompt 优化忽视的核心——如何引导 AI 深度思考而非追求格式。实用性强，直接提升编程效率。
揭示大多数 prompt 优化忽视的核心——如何引导 AI 深度思考而非追求格式。实用性强，直接提升编程效率。
我见过无数的 prompt 趋势和 prompt 合集，但围绕 prompt engineering 的大多数讨论都聚焦于一件事：获得更好的输出。
优化更好的输出往往转化为：
但最近，我一直在想：
如果我们优化的是错误的层呢？
因为真正的问题不是：
"我怎样从 AI 获得更好的答案？"
而是：
"AI 实际上在改进我的思考方式吗？"
因为我注意到了一些微妙的事情：
我的输出在改进。
但我的理解并不总是在改进。
在多个团队和环境中工作后，我观察到：
优秀的工程师提出更好的问题。
最优秀的工程师质疑自己的思考。
我看到的大多数优化都针对：
输出质量
AI 不仅在改变我们如何构建。
它还在悄悄地重塑我们在构建时的思考方式。
那时我意识到我不需要更多的 prompt。
我需要一种方法来首先选择正确的思考类型。
不是问：
"最好的 prompt 是什么？"
而是问：
"我现在需要什么样的思考？"
这让我围绕 5 个简单的思维模式来构建我的 prompting：
Explore 模式 — 当我还没有完全理解问题时
Plan 模式 — 当我有计划…但它可能是错误的时
Judge 模式 — 当我需要在选项之间做出选择时
Verify 模式 — 当我需要验证质量或正确性时
Reflect 模式 — 当我想实际学习我做了什么时
这个简单的转变改变了一切。
我不再被动地使用 AI，而是根据思维任务有意地使用它。
这是一个简单的工作流框架，能带来巨大差异。
第一步：先写下你的想法。
第二步：用它来扩展或挑战你的思考。
第三步：评估。我只是接受它了吗？
我能不用 AI 解释它吗？
听起来很简单，但跳过它却出人意料地容易。
当你跳过它时，你开始注意到一些微妙的东西：
你的输出改进了。但你的理解并不总是跟上。
我在工作流中一直在改变的一件事：
我很少再依赖单个 prompt。
取而代之，我使用 prompt 配对：
1) 一个 prompt 来生成 2) 一个 prompt 来挑战
例如：
"为这个系统建议 3 种可能的架构。"
"现在挑战每个选项：隐藏的风险、失败模式和长期维护问题是什么？"
AI 非常擅长给出似乎合理的首要答案。但这些答案通常是：
Prompt 配对帮你避免：
它强制一个简单但强大的循环：
生成 → 批评 → 决策
而仅这个循环本身可能已经比任何单个"更好的 prompt"改进了我的决策质量。
我开始做的另一件事：
在重要的 prompt 之后，我问自己：
"AI 实际上在这里改进我的思考吗？"
我使用一个简单的思维评分（0–5）：
不是作为一个严格的系统。更像是一个信号。
因为有时模式是明显的：
你得到很好的输出。你移动得更快。但你实际上并不理解发生了什么。
随着时间推移，这会加重。
这是我经常使用的一个（Explore 模式）：
"I am working on a vague engineering problem. Before suggesting solutions, help me frame the problem. List the goal, constraints, stakeholders, unknowns, assumptions, edge cases, and the questions I should answer myself first."
然后我跟上：
"Now turn this into the 5 questions I should answer manually before asking for implementation help."
这样做：
我一直在更多使用的另一个（Challenge 模式）：
"Pressure-test this architecture proposal. Identify assumptions, weak points, hidden dependencies, and failure modes. For each, explain what evidence would confirm or disprove it."
跟上：
"Which of these should I verify first, and how?"
这个 prompt 救了我几个非常自信但有缺陷的方向。
Prompting 发展很快。
我看到的趋势：
我也看到了这样的模式：
Prompt 驱动开发（编码前探索）
Prompt 版本控制（像代码一样迭代 prompt）
共享团队 prompt（内部剧本）
但这些大多数仍然优化输出质量。不是思考质量。
我不需要更多的 prompt。
我需要一种方法来回答：
"AI 是在让我的思考更好，还是仅仅更快？"
所以我在重要的 prompt 之后开始使用一个简单的自检：
不是为了优化生产力。而是为了保护判断。
我最终将这结构化成一个我现在每天使用的 prompt 系统：
Before / During / After 工作流
Paired prompt（生成 → 挑战）
简单的思维质量评分
推荐循环：AI 前思考 - 核心 Prompt - 配对跟进 - 手动反思 - 思维评分。
所有组织围绕真实工程使用案例。
如果你感兴趣，我分享了完整的 prompt 系统作为免费 PDF（100 个按思维模式结构化的 prompt）。
很想听到你对我系统的反馈。
你今天如何处理 prompting？
你会反思你的 AI 使用吗？
团队是否开始在内部标准化 prompting？
我特别好奇这在团队/组织层面如何发展。
但随着时间推移，优秀工程师是那些保护他们思考方式的人。
一些评论可能只对已登录访客可见。登录以查看所有评论。
如需进一步操作，您可以考虑屏蔽此人和/或报告滥用。