企业官网建设流程全解析

1. 从书名说起：为什么这本手册让我读到"跪着"

先交代一下背景。我做了十来年业务系统，从单体架构一路摸到微服务，自认为对"工程化"这三个字有点发言权。但翻开这本《AI工程自学手册》的前两章，我整个人是懵的——它讲的不是"怎么调API"，而是"怎么用工程手段把AI塞进真实业务里，并且让它稳定、可控、可度量"。那种感觉就像你一直以为自己会游泳，结果被人一脚踹进深水区，才发现自己连换气都没练利索。

这本书解决的是我最近两年最焦虑的一个问题：AI技术迭代太快，今天学的框架明天就过时，到底什么是不变的东西？它的答案是——工程方法。模型会换、框架会换、API会换，但需求拆解、数据准备、评估体系、灰度发布、回归测试、监控告警这一整套思路不会换。你掌握的是"驾驭AI"的能力，而不是"某个AI"的用法。

这本书适合谁？三类人：一是被领导安排"搞个AI功能"但完全没头绪的后端工程师；二是会写点Python、调过几个开源模型但一上生产就翻车的算法初学者；三是想从"用AI写代码"升级到"用工程方法管好AI代码"的团队技术负责人。如果你只是好奇AI能干什么，这本书会把你劝退——因为它默认你已经有工程基础，默认你是来干活的，不是来观光的。

最让我服气的地方在于，它没有停留在概念层面。每个章节都有可运行的示例、可对比的评估数据、可落地的决策清单。我是一边读一边打开电脑照着敲，读完第三章的时候，我手上已经多了一个完整的AI问答系统的骨架。这种"读得进去、拿得出来"的体验，在技术书里真的不多见。

2. AI工程的核心技术栈：不是学个Python就完事了

2.1 模型选型：不要把API当黑盒

这本书开篇就干了一件事，把所有模型API的底层差异摊开来讲。很多人觉得模型选型就是看排行榜，谁分高用谁，但工程视角完全不是这么玩的。

工程视角看模型，第一眼看的是约束条件：延迟要求多少、并发量多大、单次调用的成本上限多少、数据能不能出域。这本书给了一个很实在的决策框架——先把非功能需求列清楚，再去看模型，而不是反过来被模型带着走。比如说，一个客服机器人的实时响应要求可能是2秒以内，这个约束直接排除了某些大模型，因为它们推理延迟轻松超过5秒；但如果做的是离线文档分析，延迟又不是问题了，这时候精度就是第一优先级。

我照着这个思路重构了自己手头的一个小项目，把之前盲目追求"最强模型"的习惯改掉了。原来用的是参数量最大的那个模型，单次调用贵且慢，换成中等规模的模型之后，因为提示词和规则做了针对性优化，效果反而更好，成本降了将近70%。

模型选型还要考虑生态。这本书反复强调一个词：可替代性。你今天选的模型，明天可能涨价、可能限流、可能干脆下架，如果你的代码和模型强耦合，到时候就是灾难。所以它建议在上层抽象一层接口，让模型变成可插拔的组件。我在实践里也是这样做的，只留了一个几十行的适配层，后面换模型基本没动业务代码。

2.2 规则设定：让AI干活之前先把边界画好

这本书最硬核的部分，是它花了大量篇幅讲"规则设定"。你可能觉得规则有什么好讲的，写if-else谁不会？但AI场景下的规则，和你平时写的业务规则完全是两码事。

核心矛盾在于：AI天生是概率性的，同一个输入今天给这个答案明天给那个答案，但业务系统要求确定性。怎么调和？这本书给了三个层次的思路。第一层是输入侧的硬规则，比如格式校验、内容过滤、敏感信息脱敏，这些必须在进模型之前做掉，不能指望AI自己守规矩。第二层是输出侧的兜底规则，比如字段格式强制转换、结果合法性校验、超时和重试策略。第三层才是AI自己柔性处理的部分，包括意图分类、情感判断这类模糊问题。

我在实操中最大的体会是，规则设定不是限制AI，反而是给AI减负。你想想，如果所有边界情况都放进提示词里让AI自己判断，它光记住规则就耗费了大量上下文额度，真正用来理解用户问题的资源就少了。把能确定的事情都用代码写死，AI只需要专注做那件"模糊决策"的事，效果和稳定性都会明显提升。

书里有个例子我印象特别深。一个文档分类系统，一开始把分类标准全写在提示词里，结果AI频繁在两个相近类别之间摇摆。后来用代码预先把文档格式、关键词特征、来源渠道这些硬特征清洗分类好，AI只需要在剩下的小范围内做判断，准确率从78%直接拉到93%。这个提升不是模型带来的，是规则设定带来的。

2.3 提示词工程：被严重低估的"代码"

以前我总觉得提示词就是"好好说话"，让AI听懂你要什么就行。这本书劈头盖脸给我纠正了：提示词就是代码，而且是运行在别人机器上的代码，你得带着工程思维去写它，而不是带着聊天思维去写它。

工程思维的提示词，第一要求是可版本化。你有没有这种经历：提示词改了一句话，效果突然好了，但没人说得清到底哪句话起了作用。这本书建议把提示词拆成模块：角色设定、任务描述、输入格式、输出约束、示例参考，每个模块独立维护、独立测试。这样每次改动都能精确定位到某个模块，而不是一锅粥地乱调。

第二要求是可测试。写普通代码有单元测试，写提示词也得有。这本书提供了一个非常实用的做法：建一个固定的评测集，几十条典型的输入输出对，每次改提示词都拿这个评测集跑一遍，统计准确率变化。如果没有评估集，你对提示词的所有修改都是拍脑袋。

我按照这个方法，给我自己的一个信息抽取项目建了一套评测集，之后每次调整提示词都能看到量化结果。有一次我加了一段"输出要遵循JSON格式"的描述，结果准确率反而下降了，原因是AI为了凑格式反而忽略了内容理解。如果没有评测集，这种细微的退化根本发现不了。有了它，我就能把提示词调优变成数据驱动的过程。所有提示词都要写清输出格式，包括字段名、数据类型、是否必填、示例值，然后用代码校验。一开始觉得麻烦，后来发现这比在提示词里反复强调格式管用得多。

2.4 AI写代码：从玩具到生产力的距离

热词里提到"AI写代码"，这本书也有专门章节讲这个，而且视角很清醒——它不吹AI能取代程序员，而是讲AI如何成为程序员的杠杆。

书中把AI辅助编程分成了三个层级。第一层是AI当作补全工具，你主导思路，它负责帮你写模板代码、胶水代码。这一层现在已经很成熟了，几乎每个编辑器都有这类能力。第二层是AI当协作编码者，你给它一个明确的任务描述，它生成完整的函数或模块，你来做审查和集成。这一层对任务拆解能力和代码审查能力要求比较高。第三层是AI自主完成整个需求，目前在实际工程里基本还做不到，因为需求理解、环境适配、回归测试这些环节仍然需要人来把控。

我的实操经验是，第二层是目前性价比最高的用法。关键在于两点。一是任务描述要足够细，细到什么程度？输入数据的格式、边界条件的处理方式、异常情况的返回值、性能要求，全部写清楚，AI生成的代码才靠谱。二是必须建立代码审查清单，不能因为AI写的代码跑通了就放松警惕。

书里有一个例子，AI生成了一段分页查询代码，单测和集成测试都过了，但压测一上就崩了——因为AI在循环里反复查询数据库，没做批处理优化。这个故事我太有共鸣了。我遇到过类似的情况，AI生成的正则表达式在处理常规输入时没问题，遇到特殊字符就挂了。所以我把"AI写代码"这件事定位成：让AI帮你加速打字，而不是替你思考。

3. 实操：从零搭一个AI工程的最小闭环

3.1 选一个真实的小场景

理论说再多，不动手都是白搭。这本书在第三章给了一个完整的实战项目，我试着把它压缩成一个最小闭环，给大家一个可以直接抄作业的路径。

选场景有个原则：不要贪大。我当时选的是"从产品评论中自动提取用户反馈关键词"这个任务。为什么选这个？因为它足够小，一个小模型就能跑；它也足够真实，有明确的结构化输出需求；同时它方便评估，我可以人工标注一批数据来做验证。

项目目标定义得很窄：输入一段评论，输出三个字段，分别是产品名、问题类别、情感倾向。就这三个字段，别的什么都不做。这个窄目标非常关键，因为AI在目标模糊的时候最容易放飞自我，你给它划一个极小的跑道，它就能跑得很稳。

3.2 规则引擎与提示词的协同设计

这个项目让我真正理解了"规则"和"模型"的边界在哪。我先是把整个流程拆成了三段：预处理、核心抽取、后处理。

预处理阶段，代码负责清理评论中的HTML标签、表情符号、无意义字符，同时利用正则把手机型号、价格数字这些明显特征提前提取出来。核心抽取阶段，提示词只需要关注"这段话里用户最不满意的是什么"这个语义问题。后处理阶段，代码负责把AI输出的文本解析成结构化JSON，做字段完整性校验，缺字段就走重试逻辑。

这三段的分工逻辑是这样的：能确凿判断的事情绝不让AI做，能代码校验的绝不让AI自由发挥。比如"评论里是否包含价格信息"这件事，用正则一行就搞定，就不值得消耗AI的上下文；而"用户是在吐槽还是表扬"这种语义判断，才是AI该干的活。

规则和提示词还会互相校准。我发现有时候AI抽取的产品名和规则抽取的产品名不一致，这种冲突本身就是一种信号——要么规则写得有歧义，要么提示词没说明清楚。我在调试时会把这类冲突单独列出来，一条条看原因，比闷头调提示词高效得多。

3.3 评估与回归：AI工程的"单元测试"

这一节是全书的精华，也是我觉得最应该被更多人知道的部分。作者反复强调AI工程必须有评估体系，就像传统工程必须有单元测试一样，否则你根本无法判断一个改动是在变好还是变坏。

具体做法是这样。先准备一个标注好的评测集，不用太大，一两百条就够，关键是覆盖面要广，各种边界情况都得有。然后定义评估指标，对于信息抽取类任务，我用的是精确匹配率和字段级别容错率。精确匹配要求三个字段全部正确才算对，字段级容错允许部分字段正确也计入得分。

有了这套评估体系，我就能做回归测试了。每次调整提示词或规则，都先跑一遍评测集，对比得分变化。有一次我觉得加了"注意礼貌表达"这几个字能让输出更友好，结果评测集得分从0.89跌到了0.85，因为AI开始在字段值里加"抱歉""希望"这类废话，破坏了字段的纯净性。这种改动要是没有评估体系，光靠肉眼根本看不出来，上线后就是事故。

评估体系还帮我定位了一个诡异的问题。有一段时间，部分评论的抽取结果时好时坏，评测集分数忽高忽低。我把输入数据仔细排查了一遍，发现是某些评论里包含全角引号，预处理没处理干净，导致AI输出格式混乱。这个问题的根子不在模型，在数据清洗环节。这也是这本书反复强调的理念：AI应用出问题，第一嫌疑人是数据，不是模型。

3.4 上线之后：日志、监控、兜底策略

项目跑通只是第一步，真正让它变成可运维的系统，我还做了一系列工程化改造，这些细节书上都有提到，但实践中往往被忽视。

日志设计是个大学问。不同于普通应用只需要记录请求参数和返回结果，AI应用必须额外记录提示词版本、模型名称、温度参数、输入token数、输出token数这些信息。为什么要记这些？因为你翻历史日志的时候，必须能精确还原"当时这条结果是用什么模型、什么提示词跑出来的"。没有这些信息，出了问题你都不知道从哪儿开始定位。

监控指标上，除了常规的延迟和错误率，我还加了一个"重试率"指标。AI服务的输出不是百分百合法的，特别是要求结构化输出时，经常会有字段缺失或格式非法的情况。重试率突然升高，往往预示着上游数据出现了新的模式，而AI处理不了。这个指标比错误率更敏感，因为它发生得更早。

兜底策略是最后一道防线。我的设计很简单：AI服务失败或者超时时，系统自动切换到一个基于规则的简易抽取器，虽然覆盖面窄很多，但至少能给用户返回一个结果。这个兜底逻辑让系统的可用性从98%提升到了99.5%以上。很多AI项目挂在生产环境，不是因为模型不好，而是因为没人想过"AI不可用的时候怎么办"。

4. 我在实操中踩过的坑

4.1 提示词"看着对"和"真的对"是两回事

我在调提示词的时候犯过一个大错：我觉得提示词写得挺明白的，测试了几条也都能跑通，就以为万事大吉了。结果一上真实数据，各种意外情况全冒出来了。

问题出在哪？我的测试输入太"乖"了。真实用户的输入五花八门：有错别字、有中英文混杂、有分段不明的长文本、甚至有无意义的乱码。我后来学到的做法是，在评测集里故意放一批"脏数据"，测试AI在异常输入下的表现。这本书里有个说法我很赞同：提示词要写的不是"理想的指令"，而是"在噪声中仍然能保持正确性的指令"。

具体怎么应对脏数据？我的做法是在提示词里增加一条"如果输入内容无法理解或信息不足，请返回固定格式的默认值"。这看起来是退了一步，实际上反而提升了系统的可用性——AI不再编造答案，而是诚实地说"我不知道"，然后由后端的兜底逻辑来处理。诚实地说"不知道"，比自信地给错误答案要安全得多。

4.2 规则设定太死，反而把AI锁死

规则的另一面我也踩过坑。一开始我写的规则恨不得把所有可能性都覆盖到，正则写了几十个，分支条件层层嵌套。结果发现规则本身越复杂，出错的概率越大，而且规则和AI之间还会产生冲突。

有一个例子。我写了一条规则，如果评论中出现某个特定词，就强制把问题类别定为"功能异常"。后来发现AI的语义分析更准确，它判断出那个词在特定语境下是正面评价，但我的规则先执行了，直接把AI的判断给覆盖掉。如果这些逻辑是在规则阶段被处理掉了，那么AI模型实际上受到的"训练"并不完整——它没有学会如何识别这些特定词在特定语境下的含义，自然无法在推理阶段做出准确判断。

事后反思，规则的价值在于处理"百分之百确定的事"，比如敏感词过滤、格式校验、非法字符清理。对于"需要在语境中判断"的事，应该放手让AI去做，规则做的是事后校验，而不是事前拦截。把规则写到AI前头，不是"帮AI减负"，是"帮AI变蠢"。

4.3 别信AI写的代码，别不信AI写的代码

这句话说起来像绕口令，但确实是血泪教训。AI生成的代码，有一种特殊的"迷惑性"——它看起来非常规范，变量命名合理，注释齐全，结构清晰，于是你容易放松警惕。

但AI代码有几个典型的隐患。第一个是边界条件处理想当然，比如数组最后一个元素的特殊情况、空字符串的默认值，AI经常想当然地处理掉。第二个是API调用参数被"猜"出来，AI经常会使用一个看起来合理但并不存在的方法签名，在真实的运行环境中直接报错。第三个是性能意识薄弱，AI生成的代码满足功能需求，但复杂度可能高得离谱，数据量一大就崩。

我的做法是给AI生成的代码建立一套"强制审查清单"，核心是三个问题：数据从哪来、挂在哪、量多大。数据从哪来决定了它的格式和完整性假设；挂在哪决定了错误处理的策略；量多大决定了性能和安全要求。这三个问题答清楚了，AI代码才能放心用。还有个技巧，让AI自己给自己的代码写边界测试用例，然后你拿着这些用例去测试它的代码——这个"AI自证"的过程能暴露很多隐藏问题。

5. 从入门到落地：一条可以复制的学习路径

5.1 书里没写的两件事：算力预算和数据飞轮

读到第五章，我发现这本书也各有侧重，有些内容没有展开，但这些恰恰是AI工程落地时决定成败的细节。第一是算力预算，第二是数据飞轮。

算力预算这块，书里讲了模型选型和成本控制，但没有细讲怎么做一个可预测的预算模型。我自己的做法是，先按单次请求的token数估算出平均成本，再乘预估的日活量，最后乘以两倍的峰值系数。这个两倍系数是经验值，因为用户的调用模式从来不是均匀分布的，高峰时段的并发往往让你措手不及。然后我把它除以2，作为需要人工兜底的比例——也就是说，至少有50%的请求不可能完全自动处理，剩下的部分AI服务走全自动通道，这样预算才可持续。

数据飞轮书里有提，但没展开。我的理解是，AI系统上线只是开始，真正的价值在于持续收集"模型判断错误"的样本，经过人工修正后重新加入评测集，然后迭代提示词或重新微调模型。这个闭环跑起来之后，系统每隔一段时间就会明显变强。我见过太多团队，AI系统上线就躺平，结果模型半年不更新，效果越用越差，用户反馈越来越差。保持数据飞轮的转动，才是AI工程长期竞争力的来源。

5.2 下一站：多租户、权限体系与流程集成

手册写到这里基本已经把我带到了"能在生产环境干活"的水平。但工程化的路没有尽头，我还想提三个方向供大家继续深入。

第一个是消息队列解耦。AI处理通常很慢，同步调用很容易超时，我的方案是把请求丢进消息队列，后台异步处理，前端轮询拿结果。这个模式特别适合文档分析、批量归类这类不需要实时响应的场景。第二个是灵活的基础授权。让不同业务线的人用同一套AI能力，但参数配置不同，需要一个灵活的授权体系。我的做法是参考云服务的做法，为每一条规则设置范围和优先级，让AI能力既能统一共享，又能按需隔离。第三个是流程引擎集成。AI提取出的结构化数据，不能只停留在展示层面，最好是直接驱动后续的工单系统、审批流程，这个集成工作虽然不酷，但是价值很大。

这三个方向我都还在摸索中，但大方向是很清楚的：AI工程的重心，会从"让AI跑起来"逐步转向"让AI能管得住"。不管模型怎么变，这个趋势不会变。这本手册最聪明的地方就在于它看准了这个趋势，并且把每一步都铺扎实了，让后来者可以沿着这条路少摔几个跟头。