周末原本只打算翻两页放松一下结果从下午坐到深夜整个人越读越精神。市面上讲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设为normalconfidence设为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输出立刻稳定了很多。书里给了参数调优的基本原则我整理成了表格参数建议值区间适用场景踩坑提醒temperature0.1~0.3分类、抽取、格式化输出调太高会输出漂移该拒绝的不拒绝temperature0.7~1.0创意文案、头脑风暴、写作调太低会太平庸缺乏多样性top_p同temperature联动与temperature配套使用两个参数不要同时大幅度调会互相干扰max_tokens按输出预期设置所有场景设太短会被截断设太长会增加无谓成本参数之外模型版本对我这种没有固定GPU资源的人影响更大。我遇到过一次提示词“退化”同一套提示词在旧版本模型上运行稳定换成新版本后约束条件的遵守度明显下降——它开始偶尔在JSON后面补一句解释性文字。当时排查了很久最后才确认不是我的代码问题是模型行为变了。这本书提醒了一个关键习惯**提示词必须像代码一样纳入版本管理并且要记录它适配的模型版本。**模型一升级先跑一遍回归测试而不是直接切过去。现在我的项目里每个提示词模板都会写明“适配模型XXX版本日期XXXX-XX-XX”换模型先验证再发布这个习惯帮我省了太多麻烦。2.4 提示词的测试与回归让修改不再“拆东墙补西墙”提示词工程里最让人头疼的是“改一处崩一处”。你觉得新的表述能解决A问题结果上线后发现B问题的出现率变高了。这本书建议的做法很简单建立一组固定的测试集。我按它的思路给每个业务场景准备了一个测试集文件里面包含50条左右的输入样例并标注了每一条对应的期望输出类型。每次修改提示词之后批量跑一遍这个测试集统计通过率。通过率不低于上一次才能发布否则就说明这次修改得不划算。这个习惯往下深挖其实就是在给提示词工程引入“回归测试”概念。模型虽然不写代码但你的提示词就是代码测试就是测试。没有这层保障所有调优都是盲人摸象。这里有一个实际经验想分享测试集里一定要包含边界情况比如空输入、超长输入、乱码输入、恶意内容。因为正常输入大概率怎么调都不出错翻车往往就在这些刁钻的输入上。3. 规则设定才是AI应用能上线的底线工程3.1 为什么只有提示词远远不够看到这里你可能有个疑问提示词写好了格式稳定了是不是就够了还远远不够。因为提示词本质上是“建议”模型大概率会遵守但不是必然遵守。而在真实业务里有些底线不允许“大概率”。举个例子一个客服机器人提示词里写了“不得输出侮辱性内容”模型99%的情况下遵守了但剩下的1%怎么办对有真实用户的线上系统来说这1%就是事故。规则设定的意义就是把这1%用确定性手段兜住。这本书把规则设定定义为AI工程的底线工程我深以为然。回归本质LLM是概率系统同一个输入每次的输出都可能不同而业务要求的是确定性的结果。规则设定解决的就是这个矛盾模型负责“聪明的判断”规则负责“确定的兜底”。3.2 三层规则结构这本书里让我最受益的部分书里把规则设定分成了三层每一层的职责边界非常清晰规则层级所在位置典型用途实现方式业务规则层模型之前权限控制、业务开关、流程分支代码硬编码不走模型模型规则层模型前后均可敏感词过滤、正则匹配、关键词映射词表 正则 分类器约束规则层模型之后输出Schema校验、字段级校验、重试降级代码校验逻辑这三层规则的配合逻辑我花了一段时间才完全吃透。拿一个最常见的内容审核接口来说完整规则链是这样的用户提交评论后先走业务规则层——判断用户是否有发言权限再走模型规则层——用敏感词表和正则过滤明显违规的文本这两层都通过后才进入模型做语义判断判断它是否属于“言论不当”模型输出后再走约束规则层——校验输出格式是否正确字段值是否合法如果校验失败则重新请求或降级为人工。这套规则的妙处在于越接近模型越处理“模糊问题”越远离模型越处理“确定问题”。权限、词表、格式这些能确定判断的绝不交给模型因为模型会出错只有语义理解这种必须模糊判断的才交给模型。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生成原因CRUD接口非常适合模式固定边界清晰模板化程度高单元测试非常适合规则明确输入输出容易描述正则表达式非常适合需求描述清楚模型擅长模式匹配配置脚本非常适合结构固定样例丰富文档注释非常适合无逻辑风险错了影响小核心算法不太适合需要深度理解边界条件多放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条问题的评估集分为三类问题类型数量期望行为知识库内有明确依据30条正确回答并附准确出处完全超出知识库范围10条明确拒答不编造答案边界擦边问题10条能回答的部分给出答案超出部分如实说明评估指标我用了四个答案正确率人工判断是否准确、引用准确率引文是否对应答案、拒答率超出范围是否拒绝、胡编率无依据却强行回答的比例。每次修改提示词或规则后我会跑一遍这50条问题对比分数变化。迭代过程中有个特别典型的实例第一版运行时模型表现得很“聪明”面对边界擦边问题它会把文档里相关内容强行组合起来给一个看似合理但实际不受支持的答案。虽然内容看起来和知识库沾边但引用的出处并不能支撑结论。这就是典型的“过度联想”。解决方式是在提示词里加了一条约束——“推理链必须严格基于引用内容引用中的信息不充分时必须明确说明‘文档未涉及’”同时在规则层增加了“答案关键词必须能在引用段落中找到匹配”的校验。这么一封口胡编率立刻降了下来。5.4 部署与灰度离线实验和线上观测的配合项目部署上线不是把一个打包好的服务丢到服务器上就完事了。书里强调的一个理念我很早之前就认同但一直没形成体系线上系统必须有反馈闭环。我的做法是上线前先在本地跑完所有评估集通过标准达标才能进入灰度灰度阶段只在内部环境开放把日志完整记录下来稳定运行后再逐步放量到真实用户。线上日志要记录的信息包括用户输入、系统回复、引用的文档ID、检索到的文本块、相似度分数、规则命中情况、模型响应耗时。日志里还出现了意料之外的bug。灰度期间有用户问了这么一个问题“帮我看一下售后政策的第二条是什么”系统检索的时候把“第二条”识别成了向量相似度很低的关键词结果召回的结果里根本没有包含完整的第二条内容。排查后发现问题出在用户输入处理这层缺了“结构语义识别”规则——把“第X条”“第X节”这类结构导航词单独抽出来做精准定位。补上这条规则后这类问题就解决了。整个过程走下来我最深的体会是AI应用不是“开发完上线”就结束了它是一个持续收集反馈、持续补规则、持续优化提示词的循环。你建的评估集越贴近真实规则补得越及时系统就越可靠。说实话这几年技术书看了不少但让我心甘情愿跪着读完的这本是头一本。它没有高高在上地讲算法也没有敷衍地教几个接口调用而是用一套完整的工程方法论把AI应用的开发从“会写代码”提升到了“能对效果负责”。我自己读完后的做法是把每一章都压缩成了一页实践清单然后照着清单在一个又一个具体业务里落地验证。如果你也想系统掌握AI工程实践我建议你带着一个真实业务问题去读这本书——读到一半你会回来感谢我的。 
长河君 · 2026/10/6 10:50:06 · 阅读 1.2k AI应用工程实操：提示词工程、规则设定与AI写代码
周末原本只打算翻两页放松一下结果从下午坐到深夜整个人越读越精神。市面上讲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设为normalconfidence设为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输出立刻稳定了很多。书里给了参数调优的基本原则我整理成了表格参数建议值区间适用场景踩坑提醒temperature0.1~0.3分类、抽取、格式化输出调太高会输出漂移该拒绝的不拒绝temperature0.7~1.0创意文案、头脑风暴、写作调太低会太平庸缺乏多样性top_p同temperature联动与temperature配套使用两个参数不要同时大幅度调会互相干扰max_tokens按输出预期设置所有场景设太短会被截断设太长会增加无谓成本参数之外模型版本对我这种没有固定GPU资源的人影响更大。我遇到过一次提示词“退化”同一套提示词在旧版本模型上运行稳定换成新版本后约束条件的遵守度明显下降——它开始偶尔在JSON后面补一句解释性文字。当时排查了很久最后才确认不是我的代码问题是模型行为变了。这本书提醒了一个关键习惯**提示词必须像代码一样纳入版本管理并且要记录它适配的模型版本。**模型一升级先跑一遍回归测试而不是直接切过去。现在我的项目里每个提示词模板都会写明“适配模型XXX版本日期XXXX-XX-XX”换模型先验证再发布这个习惯帮我省了太多麻烦。2.4 提示词的测试与回归让修改不再“拆东墙补西墙”提示词工程里最让人头疼的是“改一处崩一处”。你觉得新的表述能解决A问题结果上线后发现B问题的出现率变高了。这本书建议的做法很简单建立一组固定的测试集。我按它的思路给每个业务场景准备了一个测试集文件里面包含50条左右的输入样例并标注了每一条对应的期望输出类型。每次修改提示词之后批量跑一遍这个测试集统计通过率。通过率不低于上一次才能发布否则就说明这次修改得不划算。这个习惯往下深挖其实就是在给提示词工程引入“回归测试”概念。模型虽然不写代码但你的提示词就是代码测试就是测试。没有这层保障所有调优都是盲人摸象。这里有一个实际经验想分享测试集里一定要包含边界情况比如空输入、超长输入、乱码输入、恶意内容。因为正常输入大概率怎么调都不出错翻车往往就在这些刁钻的输入上。3. 规则设定才是AI应用能上线的底线工程3.1 为什么只有提示词远远不够看到这里你可能有个疑问提示词写好了格式稳定了是不是就够了还远远不够。因为提示词本质上是“建议”模型大概率会遵守但不是必然遵守。而在真实业务里有些底线不允许“大概率”。举个例子一个客服机器人提示词里写了“不得输出侮辱性内容”模型99%的情况下遵守了但剩下的1%怎么办对有真实用户的线上系统来说这1%就是事故。规则设定的意义就是把这1%用确定性手段兜住。这本书把规则设定定义为AI工程的底线工程我深以为然。回归本质LLM是概率系统同一个输入每次的输出都可能不同而业务要求的是确定性的结果。规则设定解决的就是这个矛盾模型负责“聪明的判断”规则负责“确定的兜底”。3.2 三层规则结构这本书里让我最受益的部分书里把规则设定分成了三层每一层的职责边界非常清晰规则层级所在位置典型用途实现方式业务规则层模型之前权限控制、业务开关、流程分支代码硬编码不走模型模型规则层模型前后均可敏感词过滤、正则匹配、关键词映射词表 正则 分类器约束规则层模型之后输出Schema校验、字段级校验、重试降级代码校验逻辑这三层规则的配合逻辑我花了一段时间才完全吃透。拿一个最常见的内容审核接口来说完整规则链是这样的用户提交评论后先走业务规则层——判断用户是否有发言权限再走模型规则层——用敏感词表和正则过滤明显违规的文本这两层都通过后才进入模型做语义判断判断它是否属于“言论不当”模型输出后再走约束规则层——校验输出格式是否正确字段值是否合法如果校验失败则重新请求或降级为人工。这套规则的妙处在于越接近模型越处理“模糊问题”越远离模型越处理“确定问题”。权限、词表、格式这些能确定判断的绝不交给模型因为模型会出错只有语义理解这种必须模糊判断的才交给模型。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生成原因CRUD接口非常适合模式固定边界清晰模板化程度高单元测试非常适合规则明确输入输出容易描述正则表达式非常适合需求描述清楚模型擅长模式匹配配置脚本非常适合结构固定样例丰富文档注释非常适合无逻辑风险错了影响小核心算法不太适合需要深度理解边界条件多放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条问题的评估集分为三类问题类型数量期望行为知识库内有明确依据30条正确回答并附准确出处完全超出知识库范围10条明确拒答不编造答案边界擦边问题10条能回答的部分给出答案超出部分如实说明评估指标我用了四个答案正确率人工判断是否准确、引用准确率引文是否对应答案、拒答率超出范围是否拒绝、胡编率无依据却强行回答的比例。每次修改提示词或规则后我会跑一遍这50条问题对比分数变化。迭代过程中有个特别典型的实例第一版运行时模型表现得很“聪明”面对边界擦边问题它会把文档里相关内容强行组合起来给一个看似合理但实际不受支持的答案。虽然内容看起来和知识库沾边但引用的出处并不能支撑结论。这就是典型的“过度联想”。解决方式是在提示词里加了一条约束——“推理链必须严格基于引用内容引用中的信息不充分时必须明确说明‘文档未涉及’”同时在规则层增加了“答案关键词必须能在引用段落中找到匹配”的校验。这么一封口胡编率立刻降了下来。5.4 部署与灰度离线实验和线上观测的配合项目部署上线不是把一个打包好的服务丢到服务器上就完事了。书里强调的一个理念我很早之前就认同但一直没形成体系线上系统必须有反馈闭环。我的做法是上线前先在本地跑完所有评估集通过标准达标才能进入灰度灰度阶段只在内部环境开放把日志完整记录下来稳定运行后再逐步放量到真实用户。线上日志要记录的信息包括用户输入、系统回复、引用的文档ID、检索到的文本块、相似度分数、规则命中情况、模型响应耗时。日志里还出现了意料之外的bug。灰度期间有用户问了这么一个问题“帮我看一下售后政策的第二条是什么”系统检索的时候把“第二条”识别成了向量相似度很低的关键词结果召回的结果里根本没有包含完整的第二条内容。排查后发现问题出在用户输入处理这层缺了“结构语义识别”规则——把“第X条”“第X节”这类结构导航词单独抽出来做精准定位。补上这条规则后这类问题就解决了。整个过程走下来我最深的体会是AI应用不是“开发完上线”就结束了它是一个持续收集反馈、持续补规则、持续优化提示词的循环。你建的评估集越贴近真实规则补得越及时系统就越可靠。说实话这几年技术书看了不少但让我心甘情愿跪着读完的这本是头一本。它没有高高在上地讲算法也没有敷衍地教几个接口调用而是用一套完整的工程方法论把AI应用的开发从“会写代码”提升到了“能对效果负责”。我自己读完后的做法是把每一章都压缩成了一页实践清单然后照着清单在一个又一个具体业务里落地验证。如果你也想系统掌握AI工程实践我建议你带着一个真实业务问题去读这本书——读到一半你会回来感谢我的。