AI工程团队为何重拾"老派"纪律？

当你的模型能写诗却搞不定生产环境，问题出在哪？

这篇文章的标题让我愣了一下——「AI工程需要老派纪律」。不是更先进的算法，不是更大的算力，而是「老派」？这反差感像极了看到穿格子衫的程序员在会议室里掏出纸质笔记本。

但读完发现，作者不是在怀旧。他讲的是一件正在发生的事：AI工程团队正在把传统软件工程的那套「笨办法」捡回来。

「提示工程」的幻觉

作者先泼了盆冷水。他说很多人对AI工程的理解，本质上还是「提示工程」（Prompt Engineering，即通过设计输入文本来引导模型输出）——调调参数、试试不同的提问方式，看哪个结果顺眼。

这活儿不是不能做，但作者有个尖锐的判断：提示工程是「脆弱的捷径」。今天好用的提示词，明天模型一更新可能就废了。没有版本控制，没有回归测试，全靠人的记忆和运气。

「这就像用胶带粘漏水的水管，」他写道，「能撑一会儿，但别指望它撑过冬天。」

更麻烦的是，这种工作方式没法协作。张三调的提示词，李四看不懂为什么有效；王五想改一行，又怕把整个系统搞崩。代码 review？不存在的，因为提示词本身就不在代码库里。

老派纪律是什么？

作者列了几条「老派」做法，听起来都很基础：

——版本控制。不只是代码，还包括数据、模型权重、配置文件。作者强调，「可复现性」是工程纪律的底线。三个月前能跑通的实验，今天必须还能跑通。

——自动化测试。不是人工看输出对不对，而是写测试用例。输入X，期望输出包含Y，置信度大于Z。这些要写成代码，放进CI/CD流水线。

——模块化设计。别把提示词写成几百行的字符串塞在代码里。拆成可复用的组件，像搭积木一样组合。作者提到，有些团队已经开始用「函数调用」（Function Calling，即让模型决定调用外部工具的能力）来强制这种结构。

——监控和可观测性。模型在生产环境里漂移了怎么办？输出质量下降了怎么发现？作者说，很多团队上线后就是「盲人骑瞎马」，直到用户投诉才反应过来。

为什么是现在？

作者点出了一个时间窗口：AI工程正在从「Demo 阶段」进入「产品阶段」。Demo 可以靠运气和熬夜，产品不行。

他举了个例子。早期用大语言模型（Large Language Model，即基于海量文本训练的生成式AI模型）做客服机器人，团队可能花80%时间调提示词，20%时间写胶水代码。现在倒过来了——提示词只占20%，剩下80%是数据管道、评估框架、A/B测试平台、护栏系统（Guardrails，即限制模型输出范围的机制）。

「Prompt engineering is becoming a smaller and smaller piece of the pie，」作者写道。提示工程正在变成越来越小的一块拼图。

这不是说提示词不重要，而是说它的权重在下降。真正的工作量转移到了「让系统可靠运行」的基础设施上。

一个具体的转变

文章里有个细节很有意思。作者说，越来越多的团队开始用「类型系统」来约束模型输出。

什么意思？以前模型输出是自由文本，你让它总结一段文章，它可能返回一段流畅的废话。现在工程师会强制要求：输出必须是JSON格式，包含「关键结论」「支持证据」「置信度评分」三个字段，每个字段有明确的类型定义。

这看起来很「老派」——就像Java程序员写POJO。但它解决了一个真实问题：让下游系统能可靠地消费模型的输出，而不是每次都要写正则表达式去猜。

作者说，这种「结构化生成」（Structured Generation）正在成为标配。OpenAI、Anthropic 等模型厂商都在强化这方面的API支持。

背后的商业逻辑

读到这里，我意识到作者在讲一个更深层的变化：AI工程的成本结构正在重组。

提示工程是「人力密集型」——招几个聪明人去试，总能试出不错的结果。但老派纪律是「资本密集型」——要建测试平台、要攒评估数据集、要搭监控体系。

当AI从实验走向产品，企业不得不做选择：是继续堆人搞「 artisanal prompting」（手工提示词），还是投资基础设施让系统可扩展？

作者显然押注后者。他说，「The teams that treat AI engineering as 'real' engineering will win.」把AI工程当「真」工程做的团队会赢。

这句话的潜台词是：现在还有很多团队没这么干。他们还在用2022年的方法做2024年的产品。

给从业者的建议

文章结尾，作者给了几条实操建议，都很具体：

第一，从今天开始，把你的提示词放进版本控制。不是复制粘贴到文档里，是真正的.git管理。

第二，为模型输出写测试。哪怕只是检查格式合法性，也比没有强。

第三，建立「黄金数据集」——一组你信任的输入输出对，用来回归测试。模型升级前先跑一遍，看哪些case崩了。

第四，别只盯着准确率，要跟踪「下游影响」。模型改了一个小数点，推荐系统的点击率变了多少？这个闭环很多团队没有。

这些建议没有一条涉及前沿研究，全是软件工程的基本功。但作者说，正是这些基本功，区分了「能上线的AI」和「能用的AI」。

读完全文，我想起一个老梗：所有问题都可以通过增加一层抽象来解决，除了抽象层太多本身的问题。AI工程似乎正在经历类似的循环——先用提示工程快速验证，再用工程纪律加固，最后发现加固的过程才是主战场。

你的团队现在在哪个阶段？是还在调提示词，还是已经开始建测试流水线了？