从提示工程到工程化提示：当OpenAI开始教我们'驯服'AI时，真正该警惕的是什么

目录

一、一则技术指南引发的深层焦虑

前几天在稀土掘金看到OpenAI官方发布的”如何构建可靠AI代码”指南，标题里”从古法编程转向Agent编程”这个表述让我愣了一下。作为写了十几年代码的老兵，”古法编程”四个字像一根刺，扎进了某种难以名状的复杂情绪里。

官方指南的核心逻辑很清晰：传统的”写代码-调试-重构”模式效率太低，应该转向”定义任务边界-设计Agent工作流-验证输出”的新范式。配图里的架构图精致得像 enterprise consulting 的PPT，各种Agent节点、工具调用、反馈循环，俨然一副”这就是未来”的姿态。

但让我停下来的不是技术细节，而是这个表述背后的话语权转移。当OpenAI开始定义什么是”古法”、什么是”现代”，当一家商业公司试图重塑整个软件工程的认知框架时，我们作为从业者，是该拥抱这种效率革命，还是该警惕认知主权的让渡？

这篇文章，我想聊聊Agent编程范式背后的技术逻辑、商业动机，以及作为一线开发者，我们该如何在”用AI”和”被AI用”之间找到平衡。

---

二、Agent编程：一场被精心包装的范式革命

2.1 从”写代码”到”编排智能体”

让我们先冷静地看看OpenAI到底在倡导什么。

传统编程的本质是确定性控制：程序员通过精确的逻辑表达，让计算机按预期执行。Bug的产生源于逻辑漏洞或边界条件遗漏，调试过程是逐步逼近确定性解的过程。

Agent编程的核心则是概率性委托：程序员不再直接编写业务逻辑，而是设计一个能够调用工具、规划任务、自我修正的智能体系统。代码从”指令集”变成了”编排脚本”，核心复杂度从”如何实现”转移到了”如何约束”。

OpenAI指南中强调的四个关键原则很有代表性：

# 传统编程思维
def calculate_tax(income, deductions):
    taxable = income - deductions
    if taxable < 0:
        raise ValueError("Invalid input")
    return taxable * TAX_RATE

# Agent编程思维（示意）
tax_agent = Agent(
    tools=[Calculator(), TaxCodeLookup(), ValidationService()],
    instructions="Calculate tax accurately, verify all assumptions",
    max_iterations=5,  # 允许自我修正
    human_in_the_loop=True  # 关键决策点人工确认
)

这种转变的技术合理性是显而易见的。当业务逻辑复杂到超出人脑的工作记忆容量时，将细节委托给具备上下文理解能力的Agent，确实能降低认知负荷。但问题在于：这种委托是有代价的。

2.2 被掩盖的成本结构

我在又拍云做基础设施时，见过太多”看上去很美”的技术迁移。分布式存储取代单机存储，容器化取代虚拟机，每一次范式转换都伴随着隐性成本的转移。Agent编程也不例外。

第一重成本：调试复杂度的指数级上升

确定性系统的调试遵循”输入-处理-输出”的线性追溯。但Agent系统的失败可能是工具选择错误、上下文窗口截断、幻觉导致的错误假设，或是多轮迭代中的累积偏差。OpenAI指南里轻描淡写地提到”添加验证步骤”，但在生产环境中，我见过一个金融计算Agent因为工具返回格式微调，连续三轮”自我修正”后给出了完全错误的结果——而日志里每一轮看起来都”合理”。

第二重成本：技能结构的断层

“古法编程”培养的是精确表达能力、边界条件敏感度、算法直觉。Agent编程需要的是提示工程技巧、工具接口设计、失败模式预判。这两种能力并非完全兼容。我团队里有个五年经验的后端工程师，写业务逻辑干净利落，但在设计Agent工作流时，反复陷入”提示词调优”的泥潭——他习惯精确控制，而Agent需要的是模糊的正确和清晰的约束。

第三重成本：供应商锁定的新形态

这是最微妙也最危险的一点。Agent编程的”编排脚本”高度依赖特定模型的行为特征：Claude的代码能力、GPT-4的工具调用格式、Gemini的长上下文处理，各自有微妙的差异。当你的系统架构围绕某个模型的”个性”设计时，迁移成本可能远超传统意义上的”换数据库”或”换框架”。

---

三、”PUA你的AI”：一个值得玩味的隐喻

原文标题里”PUA你的AI”这个表述，初看是吸引眼球的修辞，细想却揭示了某种真实的交互模式。

3.1 提示工程的心理学转向

早期的提示工程关注的是信息完整性：给足上下文、明确输出格式、提供示例。但过去一年的演进表明，大模型对语气、角色设定、激励机制高度敏感。

OpenAI指南中推荐的”Chain-of-Thought”提示，本质上是在诱导模型展示推理过程；而”ReAct”模式（Reasoning + Acting）则是在模拟人类的问题解决行为。更激进的实践者发现，告诉模型”你是一个专家级程序员，这段代码将被用于生产环境”，输出质量会显著提升——即使这没有任何技术依据，纯粹是心理暗示。

这让我想起在网易做游戏运营时的A/B测试经验：用户行为往往不由理性决策驱动，而是由情境暗示和情感共鸣塑造。大模型在某种程度上复刻了这种非理性特征，而提示工程师正在无意识地成为AI行为心理学家。

3.2 当”调优”变成”博弈”

有赞时期，我负责过一套推荐系统的调参。那是个清晰的优化问题：定义目标函数，梯度下降，收敛到局部最优。但提示工程完全不同——你是在和一个黑箱进行迭代式博弈。

# 一个真实的迭代过程（简化）
v1_prompt = "请修复这段代码的bug"
# 结果：模型重写了整个函数，引入了新的问题

v2_prompt = "请最小化改动修复bug，只修改必要的行"
# 结果：修复了原bug，但忽略了边界条件

v3_prompt = "你是一位资深代码审查员，请仔细分析这段代码，找出所有潜在问题，然后给出最小改动的修复方案。思考过程：1) 原代码意图 2) 实际行为 3) 差异分析 4) 修复方案"
# 结果：质量提升，但token消耗增加300%

v4_prompt = v3_prompt + "如果无法确定，请明确说明假设条件"
# 终于可用，但响应时间增加了40%

这个过程中的”PUA”色彩在于：你不断调整表述方式，试探模型的”性格边界”，寻找那个能触发理想行为的魔法短语。这不是工程，这是驯化——而驯化的对象是一个你并不真正理解的认知系统。

更深层的问题是：当这种交互模式成为常态，开发者的思维模式会发生什么变化？我观察到一种危险的倾向：对确定性的厌恶。年轻工程师开始习惯”试试不同的说法”，而不是”深入理解问题的本质”。快速迭代取代了深度思考，而这恰恰是”古法编程”最核心的价值所在。

---

四、批判性拥抱：我的实践框架

说这么多，并非要否定Agent编程的价值。在有赞的最后一个项目里，我们用Agent架构重构了客服工单分类系统，将准确率从87%提升到94%，同时减少了60%的人工标注需求。但这个过程让我形成了一套有条件采纳的实践原则。

4.1 决策矩阵：什么时候用Agent

我画了一个简单的决策框架：

维度	适合Agent	不适合Agent
输出可验证性	有明确的对错标准（如代码编译、测试通过）	需要主观判断（如UI设计、用户体验）
失败成本	可回滚、可人工复核	不可逆、高风险的决策
问题稳定性	需求频繁变化，硬编码维护成本高	逻辑稳定，一次编写长期运行
领域知识深度	需要整合多源信息（如法规查询+计算）	核心算法需要极致优化

客服工单分类落在第一象限：分类标准明确（可验证）、分错可人工纠正（低失败成本）、业务规则经常调整（高变化性）、需要结合用户画像和历史记录（多源信息）。而支付核心的风控规则，我们坚持保留传统实现——即使Agent能写出”看起来正确”的代码，我们也无法承受黑箱决策的风险。

4.2 工程化提示：超越”调优”的方法论

OpenAI指南里有个观点我部分认同：提示工程需要工程化。但我的理解更偏保守——工程化意味着可测试、可版本控制、可审计，而不是更复杂的提示技巧。

我们的实践：

# prompts/tax_calculation/v2.3.1.yaml
name: tax_calculation
version: 2.3.1
test_cases:  # 必须通过的回归测试
  - input: {income: 50000, deductions: 10000, state: "CA"}
    expected_output: {tax: 4200.00}
    tolerance: 0.01  # 数值计算的容差

system_prompt: |
  You are a tax calculation assistant. Your task is to compute state and federal tax.
  
  CONSTRAINTS:
  - Always use the provided TaxCalculator tool for arithmetic
  - If state tax rules are unclear, invoke HumanApproval before proceeding
  - Output must be valid JSON matching schema: {income: number, deductions: number, tax: number, breakdown: string}

  FAILURE MODES to avoid:
  - Do not assume tax rates; always query TaxCodeLookup
  - Do not perform mental arithmetic; always use tools
  
  # 版本历史注释，强制记录变更原因
  # v2.3.1: 添加 HumanApproval 要求，修复 #1842 越权计算问题
  # v2.3.0: 放宽 JSON schema，允许 breakdown 为 null

关键设计：

• 提示即代码：版本控制、代码审查、CI/CD 中的回归测试
• 显式约束：不是依赖模型的”理解”，而是强制行为边界
• 失败模式文档：预设已知风险，而非假设模型能正确处理
• 变更可追溯：每次修改必须关联业务原因，防止”调优漂移”

4.3 人机边界：保留”古法”的尊严

最重要的一点：在我们的架构中，Agent的输出永远是候选方案，而非最终决策。这不仅是风险控制，更是对开发者主体性的保护。

我要求团队遵循”三阶验证”：

1. 自动验证：编译/测试/静态检查通过
2. 差异审查：与基线版本的diff必须人工可读、可理解
3. 意图对齐：代码注释必须说明”这段代码要解决什么问题”，Agent生成的注释往往描述”做了什么”，而我们需要的是”为什么”

第三条来自惨痛教训。有赞时期，一个Agent生成的缓存失效逻辑在压力测试中表现完美，但上线后导致了数据不一致。复盘时发现，代码正确实现了”缓存过期时重建”的功能，但业务真正需要的是”缓存过期时穿透到数据库，同时异步重建”——Agent理解了字面需求，但丢失了业务上下文中的隐含约束。

---

五、更深层的忧虑：认知外包与技能退化

写到这里，我想跳出技术细节，谈谈这个行业正在发生的变化。

5.1 “古法”的消亡与重生

“古法编程”这个词的讽刺性在于，它把人类数千年积累的精确表达能力、逻辑推理训练、系统思维方法，贬低为一种过时的手艺。但讽刺的是，Agent编程的有效性恰恰依赖于这些”古法”能力的存量。

能够设计出可靠Agent系统的工程师，往往是那些经历过”古法”锤炼的人——他们知道边界条件在哪里，能预判失败模式，能识别幻觉输出的微妙错误。而完全在Agent辅助下成长的新一代开发者，是否还能发展出这些能力？这是个开放问题，但我倾向于悲观。

我在又拍云带过的最后一个徒弟，是个典型的”AI原生”程序员。他能在半小时内用Cursor搭建一个功能完整的Web服务，但面对一个内存泄漏问题，他的调试策略是”让AI看看这段代码有什么问题”，而不是系统地分析堆栈、复现条件、资源生命周期。这种问题解决路径的依赖性，比任何技术债务都更难偿还。

5.2 商业叙事下的效率陷阱

OpenAI作为商业公司，有充分的动机推动Agent编程的普及。每一次”范式转换”都意味着新的培训市场、咨询服务、认证体系——以及更深层的，对AI基础设施的依赖锁定。

但效率提升的叙事往往掩盖了隐性成本的转移。当CTO们为”开发速度提升3倍”的demo鼓掌时，很少有人追问：这3倍速度是否可持续？质量债务如何偿还？团队技能结构如何演变？供应商切换成本是否被低估？

我在网易经历过类似的周期。Hadoop生态兴起时，”大数据”取代了”数据库”，三年后大量公司发现维护成本远超预期，又逐步回退到更简单的架构。Agent编程可能正在重复这个模式，只是这次的锁定效应更强——你不是在依赖一个开源框架，而是在依赖一个不断演化的、行为不可完全预测的认知系统。

---

六、结语：在工具与主体之间

回到文章开头的问题：当OpenAI教我们”驯服”AI时，真正该警惕的是什么？

我的答案是：警惕将工具使用误认为能力拥有，警惕将交互技巧误认为领域理解，警惕将效率指标误认为价值创造。

Agent编程是一种有力的工具，在合适的场景下能释放巨大的生产力。但它不应该成为唯一的工具，更不应该定义什么是”现代”、什么是”古法”。真正成熟的工程师，应该能在两种范式之间自由切换：用Agent探索可能性，用精确控制保障可靠性；用概率系统处理模糊性，用确定性系统守护底线。

最后，我想对正在阅读这篇文章的年轻开发者说：不要被”古法编程”的标签吓到，也不要被”AI原生”的光环迷惑。那些需要耐心学习的 fundamentals——数据结构、算法、系统设计、调试方法——不会因为工具的变化而贬值。相反，在一个 increasingly probabilistic 的世界里，精确思考的能力将变得更加稀缺，也因此更加珍贵。

我们这一代的使命，不是选择阵营，而是保持清醒：用AI，但不被AI定义；追求效率，但不牺牲理解；拥抱变化，但守护那些值得传承的东西。

毕竟，十年后的某个深夜，当生产环境出现故障，能救你的不是某个Agent的”自我修正”，而是你自己对系统的深刻理解——那种只能在”古法”的锤炼中获得的理解。

---

本文部分案例来自作者在有赞、又拍云的工作经历，已做脱敏处理。技术观点仅代表个人立场，与所属机构无关。

文章作者：阿文

文章链接： https://www.awen.me/post/d6d1cddf.html

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 阿文的博客！