翻译《AI工程：大模型应用开发实战》的实践经验，强调理解AI工程的本质与流程，而非仅追逐工具。书中涵盖AI应用开发的完整链路，特别关注评估环节。
原文标题：翻译一本 AI 工程的书，我把翻译本身也做成了 AI 工程
原文作者：图灵编辑部
冷月清谈：
怜星夜思：
2、文章提到“抽卡好过修改”的翻译经验，这个思路在AI应用开发中是否也适用？比如在生成式AI应用中，一次生成多个结果，然后选择最好的一个？
3、作者在翻译过程中使用了GPT-4.5和Gemini 2.5 Pro两款模型，并且认为流程比工具重要。那么在实际AI工程中，如何选择合适的模型，并建立起一套高效的开发流程？
原文内容
Chip Huyen 的新书 AI Engineering: Building Applications with Foundation Models 自今年 1 月出版以来，一直是 O’Reilly 平台上阅读量最高的书，亚马逊多个 AI 相关分类排名第一，目前正在被翻译成中文、法语、日语、韩语等多种语言。如果你读过她的上一本畅销书Designing Machine Learning Systems，会发现她延续了一贯的风格：不教你用某个具体工具，而是讲清楚底层的“为什么”。
我翻译了这本书的中文版 《AI 工程：大模型应用开发实战》，已经由人民邮电出版社图灵出版。
自家旗舰店发货比较早，大家可以优先选这个，年初四就开始发货
京东部分地区无货了，发货会等比较久的时间
这本书讲什么
一句话概括：怎么在基础模型之上构建应用。
Chip Huyen 把 AI 工程和传统机器学习工程做了清晰的区分。传统 ML 工程的核心是训练模型，AI 工程的核心是使用模型。 模型即服务的模式已经把 AI 从一个高门槛的学科变成了人人可用的开发工具，但“能用”和“用好”之间的距离，比大多数人想象得要远得多。
全书 10 章，覆盖了构建 AI 应用的完整链路：从规划应用、理解基础模型的工作原理，到评估方法论（占了两章）、提示工程、RAG 与 AI 智能体、微调、数据集工程、推理优化，最后是 AI 工程架构与用户反馈。
关于评估，多说几句。大多数教程把评估一笔带过，但 Chip 认为这是 AI 工程中最难也最被低估的环节。我专门问过她为什么给评估这么大的篇幅，她说如果再版可能还要加到三章。两个原因：
-
• 一是 AI 的输出本身带有不确定性，你必须靠评估来保证生成结果的稳定性；
-
• 二是 AI 一旦出错，后果可能比传统软件严重得多，评估没做好直接上线可能产生难以估量的负面影响。
书里详细讨论了 AI 当裁判（AI-as-a-judge） 这种快速增长的评估方式，也指出了它的局限。
做传统应用开发的人可能意识不到评估有多重要。传统软件的行为是确定性的，输入 A 一定得到输出 B，写几个单元测试就能覆盖。AI 应用不一样，同样的输入可能每次给出不同的结果，没法靠“跑一次看看”来判断质量。读完这两章之后，你会在开发 AI 应用时刻意去做评估。比如我自己写提示词，会维护一个测试集，每次换模型或者改了提示词，就跑一遍，看结果是更好了还是更差了。
书中还有大量来自 OpenAI、谷歌、Anthropic、LinkedIn 等公司的一手案例和访谈，不是概念性的引用，而是具体到工程决策和实际遇到的问题。比如 LinkedIn 花了 1 个月达到 80% 的效果，又花了 4 个月才超过 95%，初期的成功让他们严重低估了后续改进的难度。
对每个技术方案，书里都给出了“怎么做”和“如何权衡”。不只是告诉你 RAG 怎么实现，还会分析什么时候该用 RAG、什么时候该微调、什么时候两个都不需要。
适合谁读
如果你在做 AI 应用开发，这本书能帮你把零散的经验串成体系。技术负责人和工程经理想给团队定 AI 开发流程的，书里的框架可以直接参考。产品经理读完会更清楚 AI 能做什么、不能做什么，和工程师沟通也更有共同语言。
不需要有深厚的 ML 背景。Chip 的写作从第一性原理出发，逐层深入，遇到技术密集的部分会提前提醒，不感兴趣可以跳过。
为什么我要翻译这本书
我一直不太敢碰 AI 相关图书的翻译。原因很简单：这个领域变化太快了。 昨天你还在为某个大模型的能力赞叹，今天新的 SOTA 模型就发布了，明天可能一个新框架又宣称要颠覆一切。
具体工具的教程写出来就过时了，甚至一些曾经流行的技术架构也在被淘汰。我们需要的是那些不随时间快速变化、但又确实能用得上的知识。
这本书关注的恰好是这类知识。它不教你怎么用某个版本的 LangChain，而是让你理解 RAG 为什么有效；不展示最新的提示词技巧，而是解释提示工程背后的原理。用 Chip 自己的话说：
“工具更新换代很快，底层知识的生命力更为持久。”
理解问题的本质比追逐最新的工具有用得多，这是我选择翻译这本书的原因。
翻译中的 AI 工作流
翻译一本讲 AI 工程的书，不用 AI 来辅助说不过去。但 AI 辅助翻译不是把原文丢给大模型然后复制粘贴，它是一个完整的工程流程：
HTML 转 Markdown → 提取专业术语表 → GPT-4.5 翻译初稿 → Gemini 2.5 Pro 辅助校对 → 人工审校
HTML 转 Markdown 是出版社编辑部帮忙解决的。这一步很关键，PDF 的格式信息（分栏、脚注、代码块）如果处理不好，后续所有环节都会受影响。
提取专业术语，翻译之前先提取全书的专业术语，建立统一的术语表。这确保了 foundation model 在全书中始终翻译为“基础模型”，而不是某一章叫“基础模型”另一章变成“底座模型”。
GPT-4.5 翻译初稿，脚本自动化，按章节批量处理。选 GPT-4.5 是因为在当时它是综合质量最好的翻译模型，代价是贵。
Gemini 2.5 Pro 辅助校对。Gemini 的长上下文支持很好，可以一次放入一整个小节的内容，对照原文检查译文的准确性和流畅度。这一步更多是手动操作，因为校对需要精细的判断。
人工审校，最后也是最重要的一步。我和两位审校者何文斯、李瀚，以及图灵的编辑团队一起，逐字逐句地过了全书。方法是把自己当作读者，看不通顺的地方、有歧义的地方、术语不一致的地方，逐一标记修改。版本管理用 Git，每次修改都记录内容和原因，方便回溯和多人协作。
几个实用的翻译经验
抽卡好过修改。 这是我在整个过程中最深的体会。让 AI 一次生成多份翻译结果，从中选最好的那份，效率远高于在一份不够好的结果上反复微调。生成是廉价的，判断是昂贵的，但判断比修改便宜。
模型各有所长。 GPT-4.5 的翻译质量稳定，很少出现明显的硬伤；Gemini 2.5 Pro 的长上下文能力让它在校对环节表现突出，能同时看到足够多的前后文来发现一致性问题。两个模型配合使用，比只用一个效果好得多。
流程比工具重要。 AI 翻译最容易出问题的地方不是模型选错了，而是没有流程。术语表、版本管理、分步质检，这些工程化的做法决定了最终质量的下限。
如果现在重新来做这件事，我会用 Claude Opus 4.6 做翻译（它的中文表达质量很高），用 GPT-5.2 Pro 做校对，同时用 Claude Code 加上 Agent Skills 让更多步骤自动化。工具在进步，但流程的思路不会过时。Chip 在书里也反复说这一点。
感谢图灵出版社的刘美英编辑，从选题到出版全程推进，很多繁琐但关键的工作都是她在背后完成的。感谢两位审校者何文斯和李瀚，他们投入了大量时间逐章审读，纠正了许多我自己没有发现的问题。
感兴趣的读者可以去看看。翻译这本书的过程本身也印证了书中的一个观点：AI 工程不是一次性的调用，而是一个需要精心设计的系统。 翻译工作流如此，AI 应用亦如此。
宝玉
资深提示工程师，在大模型应用领域具备广泛影响力的 AI 专家。长期深耕前沿 AI 技术，致力于将尖端 AI 能力转化为可落地的生产力工具与标准化方法论。
知名 AI 博主、极客时间专栏《软件工程之美》作者，其影响力覆盖国内外技术圈层：微博粉丝量超百万，连续三年蝉联“微博年度科技行业影响力大 V”；长期活跃于国际平台，专业见解与实践经验收获全球 AI 从业者的一致认可。
关注@宝玉xp（微博）/宝玉AI（微信公众号），获取提示工程与 AI 工程的前沿洞见。
