企业官网建设流程全解析

周末原本只打算翻两页放松一下，结果从下午坐到深夜，整个人越读越精神。市面上讲AI工程实践的书不少，但大多数要么堆概念，要么只教你怎么调API，真正把“提示词工程”“规则设定”“AI写代码”这些环节串成一条能落地的工程链路，掰开揉碎讲清楚的书，太少见了。这本标着“入门”的自学手册，读完只想用四个字形容：硬核，服气。

它不是一本讲大模型原理的书，而是一本教你怎么把AI应用做成产品的操作手册。如果你已经会调用各种大模型接口，也会写几句提示词，但一碰到复杂业务就心里没底——不知道输出怎么稳定、边界怎么兜底、效果怎么评估、代码怎么让AI写得可控，那这本书就是给你准备的。下面我把读完以后最震撼的几个部分，结合自己复现项目时的实际经历，整理成一份带实操经验的拆解。

1. 这本书硬核在哪：一上来就拆穿了AI工程的“链路”

1.1 我以为的“入门手册”，第一页就开始讲脏活累活

先说个普遍现象。很多人学AI应用开发的路径是这样的：先花几个月啃模型架构，再学怎么调用API，然后跑通一个Demo就觉得自己会了。我也一样，最开始做AI应用的时候，觉得核心工作就是把提示词写好、把模型选好，其他都不重要。

结果第一次上线就翻了车：用户输入稍微换了个说法，输出格式就乱了；模型偶尔抽风，答非所问；最要命的是，它一本正经地编了一个根本不存在的统计口径。那一刻我才意识到，AI应用和传统软件的根本区别在于——模型只是返回一个“概率上最合理”的文本，而不是一个“确定正确”的结果。

这本书第一页就把这层窗户纸捅破了。它直接指出，所谓的AI工程，研究的核心命题只有一句话：怎么让一个概率性的系统，稳定地产出确定性可接受的结果。

这句话听起来简单，但真正做起来，涉及的环节多得惊人。书里给了一条完整链路：用户输入进来到结果返回，中间要经过意图识别、上下文管理、数据检索、规则前置校验、模型推理、输出解析、规则后置校验、日志记录、效果评估。每个环节都可能成为故障点，也都可以通过工程手段去加固。

1.2 链路思维：模型只负责“猜”，工程负责“把猜变成产品”

书里有一句我反复划线的话：模型只负责猜测，工程负责让猜测的结果变成产品。

为了说明这句话，它举了一个真实的翻车案例。某个客服机器人在线上跑了一个月，别的都挺好，但只要用户说“帮我查一下昨天的数据”，返回的永远是默认上一个自然日的数据。看起来没什么问题对吧？但细节经不起推敲——如果用户是在月初第一天问“昨天”，很多人想查的其实是上月最后一天的数据，但机器默认返回的是本月1号。这个问题的根子不在模型，而在链路里缺少一个时间语义解析规则模块。

这个案例让我意识到，AI工程的本质，是把“模型会猜错”当作默认前提，然后在链路里一层层加护栏。传统软件的错误是确定的、可复现的；AI应用的错误是分布的、概率性的。所以AI工程的第一课不是模型有多大，而是理解这条链路的每一环：输入侧要做什么清洗，模型侧要做什么约束，输出侧要做什么校验，事后要做什么观测。

书里把这条链路拆成了五个可以独立学习的板块：提示词工程、规则设定、数据接入、评估体系、部署运维。每个板块都给了可以直接照做的模板，而不是飘在天上的方法论。这也是我读完以后最大的感受：它不是在教你知识，是在教你干活。

1.3 学习地图重构：别再死磕模型原理才动手

以往的学习路线有个很大的问题：前置知识太多，导致绝大部分人死在半路。这本书直接建议，先别管Transformer怎么实现，先跑通一个最小闭环，然后再逐层加深。它的理由很朴素：工程能力是在反复动手和排错中长出来的，不是看出来的。

按照它给的学习地图，第一阶段是掌握提示词和输出校验，做一个能稳定回答问题的聊天机器人；第二阶段是加入规则和工具调用，做一个能执行特定任务的Agent；第三阶段是接入知识库和评估体系，做一个能对效果负责的产品。每一阶段都有明确的可交付物，学完就能在简历上写一笔的那种。

这个设计思路我特别认同。因为AI工程的门槛不在抽象理解，而在具体操作——你只有亲手被模型的“幻觉”坑过，才会理解为什么输出校验那么重要；只有亲手被线上用户的花式输入打懵过，才会理解为什么前置规则要那么密集。看书只能让你知道“有这么回事”，动手才能让你真正会做。

2. 提示词工程的地基：把提示词写成接口规格，而不是聊天话术

2.1 一句话说透提示词的本质

市面上大量教程把提示词工程讲得神乎其神，好像会写提示词就等于会“驯服”大模型。这本书直接泼了一盆冷水：提示词不是让AI听懂人话的魔法咒语，而是给模型递一份需求规格说明书。

这个类比太到位了。你让一个实习生干活，光说“帮我把文件处理一下”，他大概率不知道从哪下手；但如果你给他一份清楚的需求文档，里面有任务目标、输入样例、输出格式、禁止事项、验收标准，他就能稳定交付。模型本质上比实习生更需要规格，因为它没有行业常识，没有潜台词理解能力，所有规则你不写进提示词里，它就默认不存在。

书里给了一个我至今在用的判断标准：**一句话需求是聊天，三段以上的结构化描述才是提示词。**如果你发现自己写提示词从来不超过五行，说明你还在聊天阶段，还没进入工程阶段。

2.2 一套可以直接抄走的结构化模板

这套模板是全书含金量最高的部分之一，我复刻以后发现成功率确实有了质的提升。它把提示词拆成了七个必填模块：

• 角色定义：让模型知道“你是谁”，用于调整语言风格和回答视角
• 任务目标：一句话说清楚要做什么，动词要具体，对象要明确
• 输入说明：描述用户输入长什么样，最好给一个模拟样例
• 输出要求：明确输出格式、字段名、约束类型，多用JSON结构
• 约束条件：列禁止事项，例如“不要猜测”“不要编造数据”“不得超过200字”
• 边界处理：当模型不确定时应该怎么回应，比如拒答、转人工、给出默认方案
• 少样本示例：给两三个高质量的正例，比一百句描述都管用

我当时基于这个模板，给一个内容分类场景写的第一版提示词大概长这样：

角色：你是一名严谨的内容安全审核员，负责对用户评论进行分类。 任务目标：判断输入的评论内容属于哪一类，并输出分类结果、置信度、风险标签。 输入说明：用户提交的评论原文，可能有错别字或网络用语，请保留原意理解。 输出要求： - 以JSON格式输出，包含三个字段：category、confidence、risk_tags - category只能是：normal、spam、abuse、advertisement之一 - confidence必须是0到1之间的浮点数 - risk_tags是字符串数组，没有风险时为空数组 约束条件： 1. 不要自行扩大分类范围，只判断给定的四个类别 2. 不要输出任何解释性文字，只要JSON 3. 如果内容包含明显恶意攻击意图，category必须是abuse 边界处理： 如果输入内容本身无法理解（比如纯乱码），请把category设为normal，confidence设为0，并在risk_tags中标注“unreadable”。 少样本示例： 输入：这个牌子的耳机音质真棒，推荐大家买。 输出：{"category": "normal", "confidence": 0.95, "risk_tags": []} 输入：你们客服是吃白饭的吗，只会推卸责任，垃圾！ 输出：{"category": "abuse", "confidence": 0.98, "risk_tags": ["angry", "complaint"]}

这套模板用下来的感受是：模型输出乱格式的概率大幅下降，几乎不需要反复调试。原因很简单——你把“确定性”的期望具体到了字段级别，模型不需要猜你想要什么。

2.3 参数细节与模型版本：你以为调好了，换个版本就崩

提示词写得好不好只是第一步，参数和模型版本的影响书里也讲得很透。我踩过一个坑：在一个需要稳定风格输出的场景里，我把temperature设成了0.8，结果模型经常在边界情况里“发挥过度”，该拒答的时候不拒答，该收敛的时候发散。后来调整为0.2，输出立刻稳定了很多。

书里给了参数调优的基本原则，我整理成了表格：

参数之外，模型版本对我这种没有固定GPU资源的人影响更大。我遇到过一次提示词“退化”：同一套提示词，在旧版本模型上运行稳定，换成新版本后，约束条件的遵守度明显下降——它开始偶尔在JSON后面补一句解释性文字。当时排查了很久，最后才确认不是我的代码问题，是模型行为变了。

这本书提醒了一个关键习惯：**提示词必须像代码一样纳入版本管理，并且要记录它适配的模型版本。**模型一升级，先跑一遍回归测试，而不是直接切过去。现在我的项目里，每个提示词模板都会写明“适配模型：XXX，版本日期：XXXX-XX-XX”，换模型先验证再发布，这个习惯帮我省了太多麻烦。

2.4 提示词的测试与回归：让修改不再“拆东墙补西墙”

提示词工程里最让人头疼的是“改一处崩一处”。你觉得新的表述能解决A问题，结果上线后发现B问题的出现率变高了。这本书建议的做法很简单：建立一组固定的测试集。

我按它的思路，给每个业务场景准备了一个测试集文件，里面包含50条左右的输入样例，并标注了每一条对应的期望输出类型。每次修改提示词之后，批量跑一遍这个测试集，统计通过率。通过率不低于上一次才能发布，否则就说明这次修改得不划算。

这个习惯往下深挖，其实就是在给提示词工程引入“回归测试”概念。模型虽然不写代码，但你的提示词就是代码，测试就是测试。没有这层保障，所有调优都是盲人摸象。

这里有一个实际经验想分享：测试集里一定要包含边界情况，比如空输入、超长输入、乱码输入、恶意内容。因为正常输入大概率怎么调都不出错，翻车往往就在这些刁钻的输入上。

3. 规则设定才是AI应用能上线的底线工程

3.1 为什么只有提示词远远不够

看到这里你可能有个疑问：提示词写好了，格式稳定了，是不是就够了？还远远不够。因为提示词本质上是“建议”，模型大概率会遵守，但不是必然遵守。而在真实业务里，有些底线不允许“大概率”。

举个例子：一个客服机器人，提示词里写了“不得输出侮辱性内容”，模型99%的情况下遵守了，但剩下的1%怎么办？对有真实用户的线上系统来说，这1%就是事故。规则设定的意义，就是把这1%用确定性手段兜住。

这本书把规则设定定义为AI工程的底线工程，我深以为然。回归本质，LLM是概率系统，同一个输入每次的输出都可能不同，而业务要求的是确定性的结果。规则设定解决的就是这个矛盾：模型负责“聪明的判断”，规则负责“确定的兜底”。

3.2 三层规则结构：这本书里让我最受益的部分

书里把规则设定分成了三层，每一层的职责边界非常清晰：

这三层规则的配合逻辑我花了一段时间才完全吃透。拿一个最常见的内容审核接口来说，完整规则链是这样的：用户提交评论后，先走业务规则层——判断用户是否有发言权限；再走模型规则层——用敏感词表和正则过滤明显违规的文本；这两层都通过后，才进入模型做语义判断，判断它是否属于“言论不当”；模型输出后，再走约束规则层——校验输出格式是否正确，字段值是否合法，如果校验失败则重新请求或降级为人工。

这套规则的妙处在于：越接近模型，越处理“模糊问题”；越远离模型，越处理“确定问题”。权限、词表、格式这些能确定判断的，绝不交给模型，因为模型会出错；只有语义理解这种必须模糊判断的，才交给模型。

3.3 一个内容审核接口的规则设计实操

这部分是我复现全书时收获最大的环节。我照着它的设计，写了一个简化版的内容审核接口，流程是这样的：

1. 业务规则层：检查用户token，判断是否有评论权限；无权限直接返回拒绝 2. 模型规则层：跑敏感词表和正则，命中的直接标记为abuse，不进入模型 3. 模型推理：把剩余内容送入模型，让模型判断normal/spam/abuse/advertisement 4. 约束规则层：校验模型的JSON输出，字段不全则重试一次，仍失败则转入人工队列 5. 人工抽检：按5%比例抽检，用于后续优化敏感词表和提示词

实现过程中踩了一个印象很深的坑：规则设置得太严，导致大量正常内容被误杀。当时我在敏感词表里加了一个词，本意是拦截某种违规内容，结果这个词出现在很多正常评论里，误杀率高得惊人。后来看这本书反复强调“规则要有解释和复盘机制”，才意识到规则不是一劳永逸的——它需要定期根据误报数据调整，需要留出人工复核的通道，否则规则越加越多，系统的可用性反而越来越差。

还有一个容易忽略的细节：规则引擎的日志一定要完整记录。哪条规则命中了、哪个环节拦截了，都要有日志。没有日志的规则系统，出问题的时候只能干瞪眼。

4. AI写代码：从补全工具到按规矩开工的实操流水线

4.1 重新定义AI写代码：不是“AI写”，是“人定规矩、AI开工”

AI写代码是这两年最热的话题之一，但也是误解最深的话题。很多人以为AI写代码就是让AI一口气生成整个项目，然后人躺着验收。这本书毫不客气地指出：这么做出来的代码，基本等同于技术债制造机——能跑，但没人敢上线。

它给的定义我非常认同：AI写代码的正确姿势，是人定规矩，AI按规矩开工。模型负责高效地生成符合规范的代码片段，而人负责三件事：拆解需求、制定规则、验收结果。换句话说，AI不是替代程序员，而是替代程序员手里那些重复性的、规则明确的编码工作。

4.2 落地实操：给AI配一份“项目规矩文件”

书上建议的第一个动作，是给项目建立一份规则说明文件。别小看这个步骤，它在AI辅助开发里的作用相当于给新同事发员工手册。

我试下来，一份有效的项目规矩文件至少要包含这些内容：

• 项目目录结构：哪些目录放接口、哪些放服务、哪些放模型
• 命名规范：变量名、函数名、文件名的风格
• 禁止使用的API：哪些库不能引入，哪些函数必须自己封装
• 必须编写的测试：每个新函数至少一个单元测试
• 错误处理要求：不允许吞异常，不允许裸抛异常
• 日志规范：统一格式、统一级别、关键路径必须打日志
• 代码风格：缩进、注释语言、单函数最大行数

有了这份文件，再配合合适的AI编码工具，生成代码的指令就变成这样：

请阅读项目根目录下的 RULES.md 文件，严格遵循其中的规范和约定。 现在需要实现一个用户查询接口，要求如下： 1. 接口路径：GET /api/v1/users/{id} 2. 权限要求：仅管理员和用户本人可访问，未授权返回403 3. 数据来源：从users表查询，用户不存在时返回404 4. 限流要求：单IP每秒最多10次请求，超出返回429 5. 错误处理：数据库异常时记录日志并返回500，响应体为统一错误格式 6. 输出格式：符合项目统一响应体规范，data字段包含用户信息脱敏后的结果 7. 测试要求：为接口补充单元测试，覆盖正常、无权限、不存在、限流四个场景

让我形容一下这么做的效果：AI生成的代码严重跑偏的概率急剧下降。以前让它写接口，它会自己脑补一堆不存在的依赖；有了规矩文件，它就乖乖按你项目现有的模式来写。这个东西的价值，用过AI写代码的人应该都有深切体会。

4.3 哪些代码适合AI生成，哪些不适合

不是所有代码都适合让AI来写。这本书给了一个很务实的分类方式，我整理成了一张表：

我按这个表来分配工作后，一个很直观的感受是：把适合的交给AI，效率提升非常明显；把不合适的硬塞给AI，返工成本比手写还高。

4.4 我实测的翻车与心得：规则文件 + 测试先行

AI写代码最经典的翻车案例，是它“幻觉”出不存在的API。我在一个项目里让它写一段调用某个文件处理库的代码，它直接生成了一段看起来很像样、但那个版本的库根本不存在某个方法的调用。运行直接报错。后来我把“禁止调用未经现有依赖声明的API”写进了规则文件里，并让AI在生成代码前先列出它计划使用的依赖，这个问题就很少再出现了。

还有个翻车案例同样典型：生成代码时省略了所有错误处理路径。主流程跑得很顺，但只要数据库连不上，整个服务就炸了。后来我给规矩文件加了一条硬性规定——“所有涉及外部调用的代码，必须包含失败分支处理”，并在测试要求里补充了“每个外部调用必须至少有一个异常场景的测试”。从那以后，AI生成的代码规范了很多。

我的实测数据是：在没有任何规矩约束的情况下，AI生成的代码可以直接合入的不到两成；有了规矩文件+测试先行之后，这个比例能上升到六成以上。剩下的四成，大多是边界逻辑需要人脑补，或者业务语义理解偏差。这个效率提升，已经能让团队省出大量时间去做更有价值的设计和评审工作。

5. 照着手册跑一个文档问答Agent：评估集、迭代与避坑记录

5.1 项目定位与边界规则

读完前面几个章节，我最大的愿望是找个真实项目把里面的方法完整跑一遍。我选择做一个基于内部知识库的文档问答Agent，场景很典型：给它一堆产品文档，让用户用自然语言提问，它从文档里找到答案并回答。

做这类项目，最怕的不是模型找不到答案，而是它找不到答案的时候开始“编”。所以我在项目启动最初，就先定义了边界规则，这些规则同时写进了提示词和规则引擎：

• 只回答知识库内存在的内容，无依据时必须明确拒绝
• 所有回答必须标注信息来源（引用了哪篇文档、哪个段落）
• 不预测、不推算、不联想，文档没写的就是不知道
• 涉及实时数据类问题（比如价格、库存），一律转人工

边界规则先行这一步，帮我省了后面大量的排查时间。很多AI项目做到一半失控，根子都在启动时没把边界想清楚。

5.2 数据准备与检索链路

知识库问答的核心是数据接入质量。书里对这部分最强调的就是分块策略。我一开始用的是固定500字一刀切的分块，结果语义经常被切断——一个完整的技术方案被切成两半，检索时只召回了一半，答案自然残缺不全。后来改成按章节和语义边界分块，每块500到800字，相邻块之间重叠100字，效果马上好了不少。

检索这一层，我用的是“向量召回 + 规则过滤 + 重排”的组合。流程是：先根据用户问题向量召回最相似的20个文本块，然后用“业务规则过滤”排除掉与当前用户权限不匹配的内容，最后按相关度分数重排，取前3块作为模型的参考上下文。

这里有一个很重要的阈值调优心得：相似度阈值设得太高，答不上来的问题就会变多，拒答率飙升；设得太低，答非所问的情况就会出现。我在实测中花了大概一天的时间，把阈值定在了一个平衡点——既保证大多数有依据问题能通过召回，又把明显无关的内容挡在外面。

5.3 评估集设计：没有评估就没有迭代

这个项目给我最大的教训，就是评估集一定要在设计阶段就开始建，而不是等功能写完了才补。我按书里的思路，准备了一个50条问题的评估集，分为三类：

评估指标我用了四个：答案正确率（人工判断是否准确）、引用准确率（引文是否对应答案）、拒答率（超出范围是否拒绝）、胡编率（无依据却强行回答的比例）。每次修改提示词或规则后，我会跑一遍这50条问题，对比分数变化。

迭代过程中有个特别典型的实例：第一版运行时，模型表现得很“聪明”，面对边界擦边问题，它会把文档里相关内容强行组合起来，给一个看似合理但实际不受支持的答案。虽然内容看起来和知识库沾边，但引用的出处并不能支撑结论。这就是典型的“过度联想”。解决方式是在提示词里加了一条约束——“推理链必须严格基于引用内容，引用中的信息不充分时，必须明确说明‘文档未涉及’”，同时在规则层增加了“答案关键词必须能在引用段落中找到匹配”的校验。这么一封口，胡编率立刻降了下来。

5.4 部署与灰度：离线实验和线上观测的配合

项目部署上线，不是把一个打包好的服务丢到服务器上就完事了。书里强调的一个理念，我很早之前就认同但一直没形成体系：线上系统必须有反馈闭环。

我的做法是，上线前先在本地跑完所有评估集，通过标准达标才能进入灰度；灰度阶段只在内部环境开放，把日志完整记录下来；稳定运行后再逐步放量到真实用户。线上日志要记录的信息包括：用户输入、系统回复、引用的文档ID、检索到的文本块、相似度分数、规则命中情况、模型响应耗时。

日志里还出现了意料之外的bug。灰度期间，有用户问了这么一个问题：“帮我看一下售后政策的第二条是什么？”系统检索的时候，把“第二条”识别成了向量相似度很低的关键词，结果召回的结果里根本没有包含完整的第二条内容。排查后发现，问题出在用户输入处理这层缺了“结构语义识别”规则——把“第X条”“第X节”这类结构导航词单独抽出来做精准定位。补上这条规则后，这类问题就解决了。

整个过程走下来，我最深的体会是：AI应用不是“开发完上线”就结束了，它是一个持续收集反馈、持续补规则、持续优化提示词的循环。你建的评估集越贴近真实，规则补得越及时，系统就越可靠。

说实话，这几年技术书看了不少，但让我心甘情愿跪着读完的，这本是头一本。它没有高高在上地讲算法，也没有敷衍地教几个接口调用，而是用一套完整的工程方法论，把AI应用的开发从“会写代码”提升到了“能对效果负责”。我自己读完后的做法是：把每一章都压缩成了一页实践清单，然后照着清单在一个又一个具体业务里落地验证。如果你也想系统掌握AI工程实践，我建议你带着一个真实业务问题去读这本书——读到一半你会回来感谢我的。