软件工程师 vs 提示工程师：最好的AI建造者两者兼备

这个笑话之所以成立，是因为图中的两个人在做同一件事：试图向机器解释他们的意思，然后发现机器以最没用的方式逐字理解了他们的意思。

一个人称之为调试。另一个人称之为提示。两个人都在盯着某个本应有效但实际上不起作用的东西。

在Seahawk Media建网站十多年并通过它交付数千个网站后，我认为提示工程不会取代软件工程。我认为它正在成为软件工程的必需部分，就像云部署、可观测性和安全从专家关注的领域转变为日常工作的一部分一样。

• 提示工程是一项界面技能，而不是软件工程的替代品。
• 生产级AI需要确定性测试和概率评估兼备。
• 提示词、上下文、工具和模型设置应该与代码一起放在版本控制中。
• 如果你要选择首先学习什么，先学习软件基础知识，然后在其基础上加入提示词技能。

这个对比很有趣，因为双方都在调试

软件工程师编写代码，运行代码，读取错误，修改代码，然后再次运行。提示词工程师编写指令，读取输出，修改指令或上下文，然后再试一次。这个循环几乎是相同的。但失败的表面不同。

传统代码往往会大声失败。函数抛出异常，测试变红，类型检查器拒绝构建。而模型可能在看似完全镇定的情况下失败。它返回有效的文本、有效的JSON，或看起来有效但实际上错误的代码——而这种错误不会在成功路径中暴露。

这改变了调试方法。你不再只是问"计算机执行了什么指令？"你还要问"模型推断了什么上下文，它能看到什么工具，我留下了什么歧义，这个失败在具有代表性的输入集合中发生的频率有多高？"

关键要点：两个学科都是将意图转化为机器行为。软件工程控制该行为周围的系统；提示词工程控制其中一个概率层。

软件工程仍然拥有什么

软件工程拥有无法敷衍的部分：数据模型、身份验证、权限、状态、并发、重试、缓存、支付流程、迁移、性能、可访问性、安全边界、监控以及系统在凌晨2点失败时的恢复。

一个出色的提示词无法修复丢失的数据库约束。它不能使未授权的操作变得安全，不能阻止两个工作进程声明同一个任务，也不能保证支付webhooks是幂等的。它可以为这些事情建议代码。但系统仍然需要一个了解这些为什么重要以及如何证明它们有效的工程师。

这就是为什么"模型写了这个应用"这个说法通常做了太多工作。模型可能生成了大部分可见的代码。但产品是围绕它的无形决策：哪些数据是可信的、验证在哪里发生、记录了什么、什么可以重试、什么需要人工批准，以及当某个依赖消失时会发生什么。

这才是工程。代码生成速度越快，工作的重心就越多地转向那些决策。

提示词工程实际上是什么

提示词工程通常被描述为找到合适的措辞。当整个交互只是一个文本框时，这是个合理的描述。但对于当今的智能体系统来说太狭隘了。

真正的工作是设计模型的工作环境。指令很重要，但系统提示词、代码库上下文、检索到的文档、示例、工具描述、权限边界、输出架构、模型选择、令牌预算，以及用来判断结果的评估集也都很重要。

一个好的提示词工程师不是在打磨魔法短语。他们在决定模型需要知道什么、必须不能假设什么、可以采取什么行动，以及什么证据才能算作完成。

这更接近于界面设计和系统思维，而不是文案撰写。我的生产级Claude Code工作流之所以有效，是因为框架提供了上下文、约束、工具和验证。聪明的句子是最不重要的部分。

界线不在代码和英文之间

人们把这框架为一边是代码、另一边是自然语言。更有用的区分是确定性行为与概率性行为。

对于普通应用代码，相同的输入和状态通常应该产生相同的输出。测试断言精确的行为。对于模型，一个合理的指令可以产生一系列可接受和不可接受的输出。测试仍然重要，但你还需要评估：一个固定的现实任务集，反复评分，这样你可以看到一个提示词或模型变化是改进了整个系统，还是仅仅修复了你面前的例子。

这就是"提示就是和AI聊天"这种说法的问题所在。随意聊天优化当前答案。生产环境下的提示优化是在多个答案中实现可重复的行为。

两个学科的相似之处

词汇会改变，但学科本身不会。让输入明确清晰。保持改变最小。对照现实进行测试。记录足够的状态来重现故障。当新版本表现更差时就回滚。

为什么"重试一遍"不是一个工作流

提示工程中最危险的习惯是把重试当作证据。第二个答案更好，问题似乎就解决了。但这样做没有学到任何东西，比如第一个答案为什么失败了、改进是否会重复、或者哪个变量改变了。

一次有用的重试必须有意改变一个东西。添加缺失的约束。移除无关的上下文。精化输出架构。给工具更安全的权限。把失败案例加入评估集。然后再运行一次相同的评估。

软件工程师通过多年的不稳定测试和"在我的机器上能用"的bug学到了这一点。提示工程师正在通过"在前面的聊天中能用"这个教训学到同样的东西。在这两种情况下，未记录的状态都是敌人。

这也是为什么我更倾向于用一个模型来承担明确的角色，而不是用五个模型对同一个模糊的请求进行投票。我在《为什么打开更多AI模型会让输出更差》中写过这个。更多的尝试无法修复一个规范不明确的任务。

上下文是新的运行时

当AI生成的工作失败时，人们通常先责怪模型。在生产编码会议中，缺少的部分通常是上下文。

代理不知道版本库的约定。它没有看到数据库迁移。没有人告诉它API调用会改变外部状态。它找到了一个旧模式并复制了它。它在长会话的前半段拥有相关文件，之后当上下文填满时丢失了那个细节。

提示工程师将此视为上下文问题。软件工程师将其视为环境和依赖问题。综合构建者修复系统：将持久指令放在版本库中，让工具暴露正确的状态，对破坏性操作要求审批，并根据实际应用验证结果。

最好的提示往往不是更长的提示。它是更好的工具、更小的上下文，或者代理可以运行而不用猜测的测试。

结合两者的生产工作流

这是我信任的用于AI辅助软件工作的循环。它故意不如演示那么引人注目。

1. 在要求实现之前先写出验收标准。定义用户可见的成果、约束条件，以及必须保持不变的内容。
2. 检查真实系统。阅读相关的代码、模式、日志和当前状态。不要让模型针对想象中的版本库进行设计。
3. 给模型有界的上下文。包括重要的文件和规则，排除无关材料，并说明它必须在何处请求后再行动。
4. 生成最小的连贯变更。更小的差异更容易让人和模型理解。
5. 运行确定性检查。类型检查、测试、代码检查、构建、安全规则和数据库约束仍然保持硬性保证。
6. 运行概率评估，其中模型在产品中。测试常规输入、边界情况、对抗性输入、拒绝和工具故障，跨越重复样本。
7. 审查差异和行为。代码审查捕捉实现错误。产品审查捕捉技术上正确但解决错误问题的变更。
8. 对整个决策进行版本控制。提交代码、提示、工具契约、评估用例和重现所需的模型配置。

这就是代理工程的工作版本。模型加快执行速度。工程师保留对结果的所有权。如果你想要更长的实现细节，看看我如何在生产中实际使用Claude Code。

我在招聘AI构建者时寻找的东西

我不会因为某人能给我展示一个长提示就雇用他们从事生产AI角色。我会要求他们给我展示他们发布的一个系统，并逐步讲解一个失败。

模型哪里出了问题？他们是如何重现的？修复是在提示、上下文、工具、schema还是周围代码中？什么测试或评估防止失败再次出现？模型提供商超时时会发生什么？回滚方案是什么？

这些问题揭示了某人是在操作模型还是在设计产品。一个强大的候选人可以在两个层面之间移动。他们可以收紧一条指令，然后注意到实际的修复是一个幂等性密钥。他们可以添加一个评估，然后认识到输出在没有确定性验证的情况下永远不应该被信任。

这是我在AI工程师招聘页面上做出的区分。这个角色不是提示复制粘贴。它是软件工程加上模型行为、工具使用、评估和成本加入系统。

纯提示足够的地方

并非每项任务都需要生产级别的防护措施。当工作风险低、可逆转且在付诸行动前经过审查时，单纯使用提示就已足够。

• 探索定位、名称、大纲和替代方案。
• 总结可与源材料对比的内容。
• 起草由人工编辑的内部文档。
• 创建一次性原型来测试某个想法是否值得投入工程时间。

在这些情况下，提示充当思考界面。如果答案不理想，你可以舍弃它。没有客户状态被破坏的风险，没有资金转移，也没有在你关闭标签后继续运行的无声自动化。

软件工程不可或缺的场景

一旦输出影响他人或在无直接监督下继续运行，门槛就改变了。

• 身份验证、权限、支付、客户数据及任何不可逆的操作。
• 拥有可写入数据库、代码库、收件箱或外部服务工具的代理。
• 必须满足延迟、可靠性、可访问性或成本目标的AI功能。
• 一个看似合理的错误答案可能造成法律、财务、安全或声誉损害的工作流。

此时，提示词工程成为一个工程化系统的组成部分。你需要边界、验证、监测、后备方案，以及与风险相称的人工审批路径。

提示词工程师是一项技能，而不是最终职位。

我预计独立的提示词工程师职位的重要性会下降。这项技能本身是真实存在的。围绕它的边界还不够稳定，无法保持孤立。

设计师会用它来创建和批评。营销人员会用它来研究和制作。运营人员会用它来自动化流程。软件工程师会用它来规划、编码、测试和维护系统。有价值的人不是那些守护秘密短语的人。他们是那些深刻理解自己领域，能够给模型提供有用的上下文，并判断结果的人。

对于构建者来说，这意味着成为双语者。你需要有精确性向计算机说明什么必须为真，也需要有工程判断力知道哪些真理不能委托给语言模型。

未来不是软件工程师对比提示词工程师。而是会提示词工作的软件工程师、学会工程学的提示词专家，以及两者之间缩小的差距。

常见问题

提示词工程是真正的工作吗？

是的，但作为AI工程、产品、设计、研究或运营内部的一项能力，它的效力比作为一个独立的职位要强。生产提示词工作包括上下文设计、工具合约、评估、输出模式、安全边界、可观测性和版本控制。编写巧妙的指令只是其中的一部分。

提示词工程师会取代软件工程师吗？

不会。提示词可以加速代码生成并让更多人能够参与软件创建，但生产系统仍然需要架构、安全、状态管理、测试、部署、监控和恢复。当加入概率模型时，这些责任会变得更加重要。

软件工程师需要学习提示词工程吗？

需要。与编码代理合作或发布AI功能的工程师需要明确指定任务、控制上下文、设计工具权限和评估非确定性输出。提示词工程正在成为工程接口的一部分，就像编写一个好的issue、API合约或测试计划一样。

我应该先学什么：编码还是提示词工程？

如果你的目标是构建生产软件，先学习软件基础知识。编程、数据结构、数据库、HTTP、Git、测试和安全为你提供了评估生成代码所需的思维模型。将提示词和上下文工程作为加速层添加上去，而不是作为理解系统的替代品。

提示词工程师和AI工程师有什么区别？

提示词工程师专注于模型指令、上下文、工具和输出质量。AI工程师负责模型周围的完整生产系统，包括应用代码、数据、检索、权限、评估、监控、延迟、成本和部署。在小型团队中，一个人经常同时做这两项工作。

成为能够同时做这两项工作的人

这张图说得没错。两种角色都要花大量时间去弄清楚为什么原本应该能用的东西偏偏不工作。优势属于那些能够在两个层面都调试的人。

学会写精准的指令。学会塑造上下文。学会什么时候用工具，什么时候移除它们。然后保持那些在模型出现之前就让软件可靠的工程习惯：小步迭代、显式合约、可重复的测试、有用的日志、谨慎的权限管理，以及部署后的所有权。

更好的提示会产出更好的初稿。更好的工程会把这些初稿变成人们能信任的产品。

如果你在实际项目中需要这种结合的纪律，可以看看我们的智能体工程服务或者雇用一名Claude Code开发者。