超越完美prompt。培养开发者，而非AI操作员
Source: Dev.to
大家好。
最近，社交媒体和 Prompt 平台充斥着一种 魔法市场。像 Promptfy 这样的网站承诺提供数百个“即用配方”，只需复制粘贴，就能解决复杂的 AI 问题。更别提 LinkedIn 或 X 了，一篇包含“万无一失的 Prompt”来生成 Python 代码的帖子，就能像 圣杯 一样收获大量点赞。我能理解这种吸引力。在一个越来越看重以更少时间产出更多成果的世界里，谁不想直接获得生产力的捷径呢？
但我在此表达我的担忧，这种担忧来源于多年观察工具如何融入开发流程的经验。如果这些捷径培养的是 AI 操作员 而不是真正的开发者怎么办？尤其是对那些刚入行的新人来说，他们带着闪亮的眼睛进入这个生态，却缺乏质疑的底层知识。复制一个 Prompt 可能是暂时的救命稻草；问题在于它会变成永久的拐杖。当遇到配方未覆盖的情况时，第一次跌倒就可能让你在职业上受到重创。
La habilidad que no se desarrolla
想象一下一个严格按照配方烹饪的厨师。使用新鲜的食材，烤箱温度恰到好处，便能做出一盘体面的菜肴。现在，把油换成发霉的黄油，或者烤箱在中途熄火。会怎样？如果他只会背诵步骤，那就完蛋了。这就像那种只会复制 prompts 的初级工程师：在理想条件下是个高效的厨师，却没有大厨即兴发挥的直觉。
问题在于，随着时间的推移，你停止训练真正重要的技能：
-
问题分解
有效的 prompt 并非凭空产生。它需要把现实世界中模糊的需求转化为精确的指令。直接复制跳过了这一步。初级工程师没有学会将问题分层：上下文、约束、期望输出。 -
对黑盒的批判性思考
大语言模型（LLM）很强大，但也会产生幻觉。复制的 prompt 可能生成看似完美的 SQL 代码……直到在生产环境中因遗漏的校验而失败。没有质疑的习惯——“模型为什么选择这个 JOIN？它对模式有什么假设？”——开发者会把输出当作绝对真理，无法培养拯救项目的直觉。 -
迭代式对话
创建 prompt 应该是与模型的迭代对话。先给出一个粗糙版本，观察回复，调整上下文并纠正偏差。真正的学习就在这里发生，你也会了解模型的怪癖。复制则是跳过试错过程；相当于在没有训练的情况下直接参加决赛。 -
LLM 的心智模型
最终，重点不只是 prompt 本身，而是映射模型行为背后的“为什么”，比如它在地理信息系统（GIS）中的数据偏差，或是它如何处理技术西班牙语中的歧义。没有这些认识，初级工程师容易停留在表面，看不到底层结构。
我以前也见过类似的情况。想想 C 到 Java 的跨越。垃圾回收器 抽象了内存管理。初级工程师可以快速写出代码而不必使用 malloc 或 free。但能够在拥有数百万对象的系统中诊断 OutOfMemoryError 的资深工程师知道，基础知识是无法被抽象掉的。prompt 的配方就像新的 GC：加速了 80% 的简单工作，但在那剩下的 20% 硬核部分，你仍然会暴露风险。
实际的 Prompt 工程
我并不是要求放弃配方。把它们当作起点，而不是终点。另一种做法是把提示视为工程：设计指令，而不仅仅是书写它们。我将详细说明我的过程。
步骤 1 – 元问题
在让 LLM 解决你的问题之前，先让它帮助你把问题表述清楚。
示例：
“帮助我构建一个清晰的请求，用于调试 gvSIG desktop 的 Java 插件中的 OutOfMemory。请包括堆的上下文、可能的内存泄漏以及用于自动化的 JSON 输出。”
这迫使你进行拆解：你知道什么？你假设了什么？你要验证什么？这就像与模型进行 pair programming，但由你来指挥。
步骤 2 – 交叉验证
草稿完成后，将其提交审查。把 Prompt 复制到另一个 LLM（Gemini、Claude、DeepSeek 等），并请求：
“分析这条指令。你看到哪些歧义？存在哪些偏见？请提出改进建议。”
这相当于 Prompt 的代码审查。能够及早发现错误，例如对瓦伦西亚 GIS 数据的文化假设，而这些可能会被全局模型忽视。
步骤 3 – 架构师的综合
拿到反馈后，由你来决定。整合、舍弃、调整。加入明确的规则：
- “始终将输出与 PostgreSQL 模式进行校验。”
- “仅以 JSON 形式回答，不要出现正文。”
此时人类的作用凸显。你是指挥者，组织输出以适配你的真实系统。
在一个小问题上尝试这些步骤。你会看到“舞蹈”过程揭示了配方忽略的层次，同时也构建了让你成为高级用户的思维地图。
培养架构师，而不是递送者
生产力并非来源于一堆复制的 prompts。它来源于构建适用于新问题的 prompt的能力。这就是证明你在 senior 桌上有席位的价值。
给导师和 senior
不要只给包装精美的 prompts 鱼。教会他们钓鱼。通过元提问、验证和综合，引导 junior 走向精通，而不是依赖。
给 junior
抵制捷径的诱惑。慢慢理解指令背后的“为什么”，才会让你成为能够应对任何挑战的专业人士，即使配方不复存在。
关于在建筑中使用大型语言模型的思考
它会让你们的价值无限提升，而不是仅仅复制粘贴的人。
提问、迭代、质疑。LLM 是工具。你们是建筑师。
最终，目标不是收集答案，而是掌握提问的艺术。
如果你们有共鸣，请在下一个挑战中尝试这种方法，并在评论中告诉我：
- 你们是否曾陷入配方的陷阱？
- 什么让你们走出了那种状态？
致意。
本文是我关于建筑与人工智能的个人研究的一部分。
你可以在我的个人网站上找到更多的思考和技术分析: jjdelcerro.github.io/es