本文的原标题是《为什么我要写一本有关 AI 开发的图书》
我编写的《零基础自学 AI 应用开发》已经上市发售，本文主要围绕这本书随便聊聊。第一部分是关于这本书编写的前前后后，纯粹有感而发。第二部分摘自本书的序，是关于书的内容介绍。这是一篇广告，但是一篇有诚意的广告。
如果你从来没有接触过技术出版，首先你要知道的是绝大部分作者都无法靠写技术图书来赚到钱。如果将作者的月收入换算成以小时为单位，那么通过图书出版得到的版税是无法覆盖写书付出的成本的——那如果不是为了钱，写书是为了什么？
前阵子我们找到了一些同事给播客“程序员新声”录制了一起关于技术翻译的新节目《 AI 来了，技术图书翻译还有价值吗？》，其中大家不约而同的对这样一个观点达成一致：技术写作/翻译的出发点仅仅是我想而已，而之所以想，不过是因为我对这门技术感兴趣，更常见的情况是，我想学习这一门技术。这听起来很反直觉是不是：翻译一本技术图书的人，不仅不熟悉这门技术，还对这门技术一窍不通。
《零基础自学 AI 应用开发》是我编写的第二本书，刚好在差不多十年前我写过另一本技术图书：《高性能响应式 Web 开发实战》（我还有几本样书，如果想要的话私我我送给你）。当时写这本书的起因不是因为我擅长前端响应式开发，恰恰相反我对前端响应式开发一窍不通——但我听说了另外一件事，学习一门知识的最好方式是尝试把这门知识转述给他人。恰好当时正处于智能手机快速普及的阶段，web 开发变得需要同时兼容移动端设备，学习响应式设计势在必行。既然我需要学，那么不如就采用上面所说的方式，采用“书”这种转述的形式来巩固我的学习。
不过学习这么技术的“结局”不算太好，我从来没有——记住，是从来没有——在工作中用到过这门技术。大部分公司采用了一些更简单粗暴的方式来解决移动端的问题：要么为站点单独开发一个移动端站点，要么阉割移动端网站功能迫使用户转向使用移动端应用。至少在我可见的范围内响应式开发变得不再被需要。
类似的“失败”经历我还能举出很多，Angular 、Unity3D 、RabbitMQ 、领域驱动设计等等——我想说的是如果总是从实用、性价比的角度来决策该不该学习一门技术，那么你得到的答案永远都会是否定的。在技术决策这件事上，除非你掌握充分的话语权，否则你是整个环节中最不重要的那一个：你既要让老板买单，也需要同事的配合。
那你应该怎么理解这件事：一个程序员，通过写书（这样一种需要花费大量精力的方式）来学习一门它不一定能够派得上用场技术，究竟是为了什么？写到这里让我想起了 Addy Osmani
2012 年当时《大话设计模式》已经赫赫有名，但是我当时苦于对 C#以及面向对象编程并不熟悉，我学习设计模式的教材其实是一本名为《 JavaScript 设计模式》（ JavaScript Design Patterns ）的图书，它的作者是Addy Osmani。他的博客在当年也是帮助我入门前端开发的很好阅读材料。
如今十多年已经过去了，Addy Osmani 依然在写博客，他还在 Google 。只不过阵地从他自己的博客换到了substack；他还是在写书，不过领域已经从前端转移到了 AI ，他最新的一本书为《 Beyond Vibe Coding 》。
这是这个行业的一个缩影：在这里唯一不变的是变化本身，你必须马不停蹄的跟上时代的步伐，无论是出于兴趣还是出于自愿。我甚至不用列举任何技术栈更迭的例子，因为这是我们工作在这个行业的体感事实。所以“学习”在我看来根本是这个行业“日常”的一部分，和每天都要进行的代码评审，例行站会无异。如果真要从性价比的角度去考虑投入产出，那么在 AI 出现之前，程序员做的绝大部分事情都是毫无性价比可言：我们需要花上几个小时时间去定位可能仅仅是一行配置导致的 bug ；可能 80%的代码为的只是处理 10%的边缘情况。
我有一个不成熟的想法，就是这种思维模式，或者说大部分编程里的思维摸是建立在你肉眼可见的 role model 之上的——只有你看见你身边真的有人在这么做，并且做成了你才会意识到它的存在并且认为它是可行的，此之前你可能会觉得傻子才会这么做。我记得我曾经告诉我的 lead 目前我们使用的某个类库并不支持我们想要实现的某个特性，它给我的建议是去修改类库的源代码；我还记得看到某个后端同事为了从 0 开始设计出一个 AB 测试方案，把 Google 以及 Meta 发布有关论文下载下来一篇篇阅读——在此之前我根本不会考虑修改源代码会是开发中的一个选项，以及应用侧的程序员会和论文学术圈有什么关系。
说回到 AI 开发以及这本书上来，我有没有可能重蹈类似于学习响应式开发的覆辙？当然有可能，虽然 AI 应用、Agent 开发是人们讨论最多的话题也是大部分程序员最想涉猎的领域，但能够上手机会至少目前看只能说凤毛麟角。但也正像我之前说的，别想太多，去做就好，习惯就好。
在我过往的经历中有两类技术的自学让我感到困难，一是 Unity3D ，二是 Hadoop 。前者的难点在于编程中涉及大量的向量和物理运算，我需要花时间将它们重新回忆并熟悉起来；而至于后者——我尝试读过不少 Hadoop 入门书籍，通常读完序章部分就已经头晕脑胀了：HBase 、Hive 、Pig 、YARN 、Spark ，它们似乎即相关（都离不开分布式、开源、数据、计算框架这几个关键词）又各不相同，学习 Hadoop 不是学习一门单一的技术而是学习而像是选修一门大学方向。
你以为我想说 AI 应用开发也会像学习上述两门技术那样的困难？恰恰相反，AI 应用开发和传统的应用开发无异——但我知道它表面上看上去并非如此，表面看上去和前两者非常相似。
科技行业有属于自己的时髦词汇（ buzzword ），有些是实打实来自于技术或者方法论的演进，例如“分布式”、”边缘计算“、“测试左移”等等；而有些可能是华而不实的词藻，例如所谓的“内容创业”不过是开微信公众号，所谓的“云技术”不过是租用了一台在亚马逊上的服务器而已。在 AI 爆发的这几年我相信我们每个人都已经对 AI 领域下的时髦词汇耳濡目染了：“神经网络”、“大模型”、“机器学习”，“agent”等等。遗憾的是它们都属于扎实技术术语。之所以称之为“遗憾”，是因为想要掌握它们没有捷径可以走，可能需要高等数学和矩阵计算的知识储备作为支撑。
但是对于一个想要踏入 AI 领域的开发者而言，所有这些都是不透明的。打一个不恰当的比喻：如果我想制作一款将音频转化为文字的 AI 应用，我怎么确认我要不要了解机器学习？这是每个人在跨入一个陌生领域时都会遇到的问题。
怎么解决的这个问题？“简单粗暴”可以是解决方式之一：如果我想知道“机器学习”对达成目标有没有影响，那我就去搜寻与机器学习有关的课程，在理解的过程中去感受去判断。听上去很理想很直接，但现实可能是：
这还仅仅是其中一个有待你确认的”时髦词汇“。
上面列举出来的各种狼狈不堪不是什么天方夜谭，而是发生在我身上的真实经历。在过去几年身边没有人可以给予明确指引的情况下，在学习 AI 开发的过程中我走了不少弯路。但现在我总是不禁会想，对于一个彻彻底底的门外汉来说，理想的学习路径应该是什么样的？这个问题的答案对我来说也已经没有意义了，可对于想踏入这个领域的人来说依然有价值，这也是编写本书最原始的出发点。
当我不得不承认同时探寻技术的深度与把握技术的广度是不可能完成的任务之后，我必须通过以下问题做出取舍：我究竟想要什么？我想要的是不是我力所能及范围内的？我为此的付出是否具有具有性价比？
也许我努努力可以把 Youtube 上由吴恩达主讲的全部机器学习斯坦福公开课程学习完，但这对于我借助 OpenAI 接口开发一个将音频转文字的应用的帮助有多大？甚至对于我的职业发展的帮助有多大？知识一定有益没错，但考虑到边际效用递减，在我看来想清楚不学什么比学什么更重要。上面所说的既不是什么新问题，也不是什么新思路：大部分工程师并不真的关心过 Docker 内部的实现，也无所谓 Vercel 平台的工作原理。如果我告诉你在 AI 应用开发中，我们可以把如 Gemini ，Claude 之类的模型当作是另一个如 Docker 般重要的支撑性服务，把 OpenAI 开发平台当做是当做是另一个 Vercel ，那听上去就一点也不难了。
这也回应了本小节开头的观点：AI 应用开发不仅不难，而且和传统开发无异——因为在应用开发领域，开发者更像是服务整合商，而不是垂直方向的科研人员。
本书提供的教程覆盖了当下绝大部分热门类型的 AI 应用，从文档检索到 agent ，从 OpenAI 接口的调用用到 MCP 服务器的开发应有尽有。在编写这些教程的过程中，我会尽可能采用常规前后端开发过中工程师熟悉的词汇与术语进行讲解，力求将学习成本以及读者学习 AI 应用开发所需预备知识降至最低。
我不仅试图再编写本书的叙述语言上做到深入浅出，在章节的编排上也试图想做到循序渐进。书的前半部分主题是“入门”，我试图通过复杂度的代码，以及尽可能少的技术栈来帮助读者熟悉 AI 开发过程中的概念与常见模式。例如我会使用 OpenAI 开发一些简易应用，并尝试使用 Haystack 框架对这些应用进行重构与扩展；而书的后半部分的主题自然是“进阶”，例如我会讲解如何基于 LangGraph 构建 agent 并为其添加前端界面。考虑到读者的技术背景不尽相同，本书会同时使用 Python 与 Node.js 来编写示例代码。如果它们对你来说还颇为陌生，没关系本书的第二章会手把手教你如何在本地配置 Python 与 Node.js 的开发环节并帮助你快速入门。
除了常规的开发教学以外，本书的另一个主题是实战。大部分教程类的书籍教会读者的仅仅可工作的代码，但在我看来这与将代码发布到生成环境中还相距甚远，将代码部署到生产环境的最佳实践是什么？在上线之后如何收集日志以及进行远端调试？如何增强它的健壮性？——缺少这些考量的代码在我看来不过仅仅是玩具。考虑到长远看维护代码才是开发工作的重心，解决应用的工程问题其实比解决应用的业务问题更重要。好消息是在开发 AI 应用的过程中传统的 DevOps 方法论并没有失效，你会看到它们是如何被应用在 AI 应用开发场景中的，这些内容也是本书的重点之一，会根据章节涉猎内容的不同穿插其中。
实战的另一层含义是与真实世界的第三方服务集成。当下云厂商或者由云厂商提供的云服务在早已成为了开发过程中的必选项。表面上看云服务服务于降低运维成本，但实际上它是在帮助开发者减少业务开发以外的噪音，确保我们专注于交付。广泛采用云服务是软件工业的必然趋势。也许在传统的前后端开发领域中我们还能咬咬牙选择自己维护手动完成一些运维工作，那么到了 AI 应用开发领域中这不会是一个好的策略，例如诸多的闭源模型与高昂的硬件成本会让我们步履维艰——如果说与云服务集成无可避免是我们未来的工作内容之一，那我们应该提前熟悉这部分工作是如何进行的。这也是为什么本书会涵盖这部分内容的原因。
以上所有即为本书的写作思路与目录编排， 希望能够帮助大家提前熟悉本书并形成一个关于本书的初步印象；也希望能够给提前给到大家带来一些关于阅读本书的指引。我期待本书带给读者的不仅仅是技术上的提升，更包括在面对未知的自信——原来 AI 开发也不过如此。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。