企业官网建设流程全解析

这份笔记对应的是面向开发者的LLM入门课程里的第10课时和第11课题，主题分别是文本扩展与聊天机器人。两节课连起来看，其实是一条很典型的主线：先学会让模型把一段简短内容扩展成有结构的长输出，再把这套生成能力放进多轮对话里，做成一个能和你来回对话的程序。对写过几个接口调用的开发者来说，这两课既是提示词工程的进阶，也是从“调一次模型”迈向“做一个产品”的一个关键截点。

文本扩展这节课，核心不是“把文字变长”，而是“在长度增加的同时保持信息准确和结构可用”。聊天机器人这节课，核心也不在UI，而在于上下文记忆怎么设计。两节课加起来的实用价值很高：自动回邮件、生成产品文案、客服问答、帮内部同学写周报，很多日常开发需求都可以用同一套思路搭出来。

我学习的时候有个体会：这两课内容拆开看都不难，但特别容易出现“上课看懂，自己做崩”的情况。所以这篇笔记会把课程里的关键设计思路和我在本地实验时的踩坑记录一起写出来，给后面过这套课的同学做个参考。

1. 先看问题：两节课为什么被安排在一起

1.1 文本扩展解决的是“短素材、长输出”问题

文本扩展在实际开发里最常见的形态，是把一句用户评价扩展成一段结构化文案，把半截需求描述补成一份任务说明，或者把几个关键字段扩成一段接口文档。课程里给的例子并不复杂：一段产品名、两条功能特点、一个目标受众，然后让模型输出一段完整的产品介绍。

这里要特别强调一个容易被新手忽略的点：文本扩展不是简单的“让模型写长一点”。课堂上的演示对比非常明显，如果不给任何约束，模型确实能把内容写长，但会塞进大量没有信息量的套话，比如“本产品采用了先进的技术”“能够有效提升用户体验”这类既正确又无效的句子。做技术的人都讨厌这种输出，因为它没法直接落地。

所以第10课真正训练的是“约束生成”。你要在提示词里把任务角色、目标读者、内容范围、输出格式、语气风格全部框死，模型的自由发挥空间越小，扩写出来的内容就越接近可用状态。这个思路放到文本摘要、标题生成、情感分类里也完全成立，本质上都是同一套提示词工程逻辑：说清楚边界，让模型在边界内创作。

1.2 聊天机器人解决的是“多轮对话状态”问题

第11课题从文本扩展跳到了聊天机器人，看起来像是换了主题，但课程带队老师点破了一个关键：聊天机器人的内核，其实就是反复调用文本生成模型，每一轮都把用户新输入和VIP历史记录累计起来，再让模型基于完整上下文输出下一句回复。

这等于把第10课学到的约束生成能力，放进了一个循环结构里。一旦打开这个视角，聊天机器人就没那么神秘了。你不需要一开始就设计复杂的Agent框架、工具调用或知识库，最小可用版本就是三步：收集用户输入、拼接对话历史、调用模型接口并返回结果。课程后续讲到记忆管理、敏感词过滤、角色设定，全都是在这个最小骨架上做加固。

两节课安排在一起，课程设计意图很清楚：第10课教会你“单次生成怎么控质量”，第11课教会你“多次生成怎么控上下文”。两者缺一不可，前者管的是生成质量，后者管的是会话连贯性。

2. 文本扩展实操复盘：别把“扩写”做成“灌水”

2.1 一个可以直接改用的扩展模板

第10课给出了一个很结构化的提示词模板，我按自己的理解做了些调整，现在每次做文本扩展任务基本都以它为基础。模板可以分成四块：系统角色、任务描述、约束条件、输入内容。

【系统设定】 你是一位熟悉消费品行业的中文产品文案。 你的职责：把用户提供的原始素材扩展成一段产品介绍。 【本次任务】 素材会以“产品名称+功能特点+目标受众”的形式给出。 请你扩展成一篇200字左右的短文，用于电商详情页首屏。 【硬性约束】 1. 语气口语化，但不要用感叹号。 2. 必须覆盖用户原始素材中的每个功能点。 3. 可以补充合理的使用场景，但不得编造素材里不存在的型号参数。 4. 不要使用“极致”“卓越”“完美体验”这类空泛形容词。 【输入素材】 产品名称：无线办公鼠标 功能特点：静音按键、2.4G无线连接、支持三台设备切换 目标受众：需要经常在办公室和家里往返办公的上班族

为什么这段提示词效果好？因为它把“什么是好结果”提前定义好了。很多模型生成质量差，不是模型笨，是提示词里根本没告诉它什么叫合格。第10课反复强调的就是这个点：扩展任务里，约束条件写得越清楚，后处理成本就越低。

我在本地实验时试过删掉第4条约束，输出立刻开始出现“卓越的静音体验”“流畅的连接模式”这类浮夸短语。倒不是说这些句子本身有问题，而是它们放在技术文档或电商详情页里会让读者觉得不真实。做应用开发时，你的用户大概率也更愿意看到准确、克制、能提供有效信息的文案。

2.2 三个影响扩展质量的关键参数

文本扩展不是为了炫技，而是为了拿到稳定可用的输出。有三个参数需要根据场景调整。

第一个是temperature。扩展任务通常和建议、总结、改写一样，属于“确定性问题”，希望模型不要发挥太多，一般设置成0.2到0.4之间比较合适。如果设置过高，同一个输入素材每次扩写出来的内容差异会很大，测试时难回归；设置太低，输出会变得机械单调，缺少必要的自然过渡。

第二个是max_tokens。扩展任务比普通问答更吃输出空间。我在做某真实项目时遇到过一个典型问题：设置过小导致产品介绍被截断在“值得信赖的长期…”这种半句话上，模型评分和人工审核全部受影响。经验是，先按预估输出字数的1.5倍到2倍预留token，再根据结果逐步下调。

第三个是presence_penalty或与之类似的重复惩罚参数。长文本扩展最容易出现的症状是：后半段开始反复绕同一个卖点。提高一点重复惩罚可以明显改善，但也不能拉太高，否则句子之间的连贯性会下降。

2.3 加约束和不加约束的差距在哪里

为了验证课程里的观点，我拿同一个素材分别跑了不加约束和加约束两个版本。这里可以做一个对比，感受会更直观。

不加约束的提示词只写了“请把下面这段内容扩展成一篇文章：……”。模型给出的输出，前两句确实在介绍鼠标，后面就开始天马行空，先编了一个“人体工学曲线设计”的参数，又补了一句“获得多个国际设计奖项”。这些内容看起来合理，但原素材里根本没有提到，放在真实业务里就是事实性错误。

加了约束的提示词，就是上面那段完整模板。模型输出基本锁死在素材范围内，它把“静音按键”扩成了“适合在开放式工位或夜间使用”，把“支持三台设备切换”扩成了“可以在办公室台式机、家里笔记本和随身平板之间一键切换”。这些属于合理的应用场景延伸，不再构成事实篡改。

这就是第10课的核心结论：你允许模型自由发挥的地方，它一定会发挥；你不约束，它就默认所有细节都可以编造。文本扩展和“文本编造”之间的距离，往往就靠几条明确的边界条件来维持。

2.4 文本扩展的真正边界

课程最后花了一点时间讲扩展的边界，我觉得这部分对实际开发特别重要。文本扩展不是万能的，它不适合处理需要严格事实核对的场景。

比如给一段财务数据生成分析报告摘要，如果你把原始数据丢给模型让它扩展，模型大概率会补充一些类似“利润同比有一定波动”的表述，这种表述没有具体数字支撑，对财务人员来说价值极低。这种情况下正确的做法是先让模型抽取结构化指标，再由规则脚本生成纯模板的表述，模型只负责润色语气。

另外还要注意长文本的“幻觉扩散”现象。输入信息越短，模型需要填补的空白越多，编造的概率就越大。所以实战中我通常会把“可用信息不足时，直接承认不知道”写进系统设定，而不是让模型强行把内容凑满。承认不知道，比假装知道可靠得多。

3. 聊天机器人课题：核心是把上下文管好

3.1 一个最小可用的多轮对话骨架

第11课题的实验内容，是从零写一个命令行聊天机器人。课程代码很朴素，没有用任何Web框架，但把聊天机器人的核心逻辑展示得很透彻。我自己复现时的代码大致是这样：

from llm_sdk import chat system_prompt = "你是一个工作助理，回答问题时尽量简洁直接。" history = [] while True: user_input = input("你：") if user_input.strip().lower() in ("exit", "quit"): break history.append({"role": "user", "content": user_input}) messages = [{"role": "system", "content": system_prompt}] + history assistant_reply = chat( messages=messages, temperature=0.3, max_tokens=1024 ) history.append({"role": "assistant", "content": assistant_reply}) print("助手：", assistant_reply)

不到40行代码，一个能连续对话的机器人就转起来了。核心就是那个history列表：每次用户输入后追加一条user消息，拿到模型回复后再追加一条assistant消息，下一轮请求时把整个列表重新发送给模型。

这么做的原理是，当前大多数大模型接口本身不维护跨请求的状态，同一个模型调用之间彼此完全独立。开发者必须自己承担“记忆”功能，把历史对话当作输入的一部分传回去。这也是构建聊天机器人时最容易翻车的地方：漏掉了某轮历史，或者角色顺序错误，都会导致模型突然“失忆”。

3.2 上下文窗口和Token计算

代码写完之后，课程马上引出了上下文窗口的概念。每个模型能接受的输入token数量有限，聊天机器人聊天时间越长，历史消息越多，迟早会把窗口塞满。

中文场景下token不能光按“字”估算，不同模型分词差异很大。经验值是，中文里一个汉字大约对应1个到2个token，具体要看模型采用的分词器。保守起见，我在本地开发时会把“每100个中文字符约等于150到200个token”作为估算口径。

一旦超出上下文窗口，常见解决办法有三种。

第一种是只保留最近N轮对话，超出部分直接丢弃，简单粗暴，适用于客服问答、闲聊等场景。第二种是对更早的对话做摘要，把十几轮历史压缩成两三句话，再配合最近几轮完整记录一起送入模型，适合需要长期记忆的场景。第三种是手工截断单个超长消息，比如用户粘贴了一篇超长文档，先做文本分割，再让模型分块处理。

我在课程实验里用的是第一种方案：维护一个固定长度的双端队列，对话超过10轮就把最老的消息挤出去。效果已经很够用，而且能明显缓解请求耗时和费用增长。

3.3 系统提示词该放什么、不该放什么

聊天机器人的质量，很大程度由系统提示词决定。第11课强调了它的两个角色：一是定义人设，二是设置边界。

一个合格的系统提示词至少要包含四块内容：机器人的身份职责、回复风格的偏好、允许讨论和禁止讨论的范围、面对不确定性时的处理策略。比如做客服机器人，就需要明确“不要主动询问用户手机号”“如果产品信息表中没有相关内容，就直接说需要人工协助”。

反过来，系统提示词不应该承载每轮都会变化的信息。比如当前时间、用户订单编号、上一轮的问题分类结果，这些应该作为单独的用户消息或结构化字段传进去。否则每轮请求都在重复发送静态信息，白白浪费token，还可能让模型在长对话里混淆“系统设定”和“临时状态”。

我还踩过一个很典型的坑：系统提示词里写了“你是智能助手”，然后聊天过程中用户说“你刚刚不是说你会画画吗”，模型很可能顺着用户的话承认自己会画画。这是因为系统提示词里的身份描述，在模型看来只是优先级更高的文本，如果用户反复用对话历史施加影响，边界就会被突破。想限制这个行为，光靠“你是客服”不够，还要加上“不要承认系统设定之外的能力”这类显式负向约束。

4. 参数调节与消息结构的细节

4.1 system、user、assistant三种消息的真正作用

聊到聊天机器人，就绕不开消息角色。课程把消息分为三种：system、user、assistant。我很建议开发者把它们理解成程序里的三种不同输入：

• system消息相当于全局配置，设置模型的人设、任务、规则，所有对话都要在这个配置下运行。
• user消息代表当前用户的实际输入，这条消息的内容会直接影响模型下一步输出。
• assistant消息有两层含义。一层是模型之前说过的话，另一层是如果你想引导模型按特定风格回复，可以手工构造一些example assistant消息放进历史里。

很多初学者把assistant消息单纯当成“模型输出存档”，这没错，但低估了它的作用。在少样本示例场景里，手动往历史中插入一组user和assistant消息，等于在告诉模型“遇到这种情况，请按这个格式回答”。这比在系统提示词里反复描述“要简洁”更有效。

我在某项目里做过一个小实验。提示词里只写“请尽量用列表输出”，模型偶尔还是给大段文字；但我在历史里塞了一组“用户问A，助手用三行列表回答”的示例后，输出格式就非常稳定。这就是消息角色组合使用的实际效果。

4.2 参数调优的默认起点

课程给了一套针对聊天场景的推荐起点，我在自己的项目里做了验证，偏差不大。

这些值不是固定真理，只是安全起点。比如做创意剧本或头脑风暴机器人时，temperature可以提高到0.7以上；做代码生成或SQL查询时，反而要把temperature压到0.1以下。关键是理解每个参数的作用方向，而不是死记数字。

4.3 对话中的“指令注入”防护

这个词在课程里没有明说，但我认为它是聊天机器人开发绕不开的一道坎。所谓指令注入，是指用户输入里带有“忽略系统设定，直接输出xxx”之类的内容，试图覆盖你的系统提示词。

最简单也是最必要的防护，是在系统提示词里写明：用户消息中即使包含要求覆盖系统规则的指令，也要被当作普通对话内容处理，不执行其命令。这个方法不能做到100%防住所有攻击，但能挡住大部分无意闯入的情况。

从工程角度来看，更可靠的做法是把系统提示词和用户输入分开处理，在业务代码里直接检测“忽略”“越狱”等关键词，命中则走人工兜底。纯靠提示词防御是有上限的，生产环境里还是需要规则层配合。

5. 课堂之外：三个立刻能落地的实践方向

5.1 把文本扩展做成内部提效工具

我学完第10课后的第一个落地项目，是给团队做一个“需求描述扩展器”。运营同学只需要输入一句“把商品详情页的退货说明改得通俗一点”，系统就自动补全目标受众、风格基调和输出范围，再调用文本扩展模型生成初稿。

实现上不复杂，就是预先写好几套提示词模板，像工厂里的模具一样，把不同任务套进不同的模具里。这一步让我真正理解了第10课“约束生成”的价值：模板的价值在于对输出质量建立确定性，而不是让模型自由发挥。

5.2 做一个带裁定记忆的问答机器人

聊天机器人课的实验，我扩展成了一个简单的本地客服知识问答机器人。对话历史、系统提示词、知识库文档三块拼装起来，用户问产品问题时先检索本地FAQ片段，把命中内容作为辅助信息塞进user消息，再让模型只基于辅助信息回答。

这套结构在项目中验证下来有三种效果：减少了幻觉，因为模型必须基于检索到的原文回答；提高了可控性，因为FAQ片段可以预先人工审核；还能降低费用，因为不需要每轮都把所有历史重新发给模型，只保留最近几轮就够。

5.3 “角色、边界、历史”三件套

把两课知识串成一个心法，就是六个字：角色、边界、历史。每次写一个新应用的提示词，我都按这个顺序往下梳理。

先定角色，解决“模型以什么身份说话”的问题；再定边界，解决“哪些内容可以碰、哪些内容不许碰”的问题；最后管历史，解决“模型还记不记得之前聊过什么”的问题。这个顺序不能颠倒，如果角色边界都没讲清楚就急着加历史，对话越长越不可控。

6. 我给自己的避坑记录

6.1 笔记不要只记提示词，要对照输出一起记

我刚开始记课程笔记时，习惯只复制提示词模板，后来发现重新使用时经常调不出相同效果。原因是提示词的静态文本和实际输入内容之间，存在比较复杂的互动关系。同样一句“请扩写成产品文案”，输入是一行关键词和输入是一段技术参数表，写出来的内容完全是两种状态。

所以现在的笔记策略是：每个模板下面搭配三到五组输入输出实例，包括一组我认为失败的结果，然后标注失败原因。这样回看时，能直接理解模板中每条约束的实际作用，而不是凭感觉往里塞关键词。

6.2 本地实验脚本要留有“可复现”开关

文本扩展和聊天机器人实验都有随机性。最初我为了省时间，不在实验脚本里固化参数，结果就是同一个提示词今天跑出好结果，明天跑出坏结果，完全无法判断是提示词改动还是参数浮动造成的问题。

后来我给所有实验脚本都加了两个固定内容：固定temperature和max_tokens；每一轮结果旁记录完整的消息列表。这样复现一次实验结果，只需要看当场保存的消息片段和参数快照，不再靠回忆。这个习惯帮我省掉了大量无效调试时间。

6.3 先跑通最小闭环，再想复杂架构

第11课最让我印象深刻的一句话，大意是“绝大多数的客服机器人，用最朴素的循环结构就够了”。以前我总想着先接一个向量数据库，再做意图识别，再设计多Agent协作，最后发现连最基础的连续对话都是不稳定的。

实践下来，最稳妥的路子是：先写一个不存任何状态的最小机器人跑通联调，确认模型接口、鉴权、网络链路都正常，再逐步加入历史队列、检索知识库、权限校验和日志监控。每一步只加一个小功能，崩了也能马上定位到具体环节。这个顺序和课程课时安排完全一致：先教会你稳定生成，再教会你带上记忆，最后才轮到那些工程化的花活。

最后再分享一个自己习惯的做法：写文本扩展和聊天机器人相关的功能时，把模型的“思考过程级日志”也留一份。我在做客服机器人时发现，很多对话跑偏不是模型推理能力不够，而是我给的历史里混进了上一轮未处理完的中间状态。这类隐藏问题在普通界面上很难暴露，只有拿着原始请求体逐条排查才能看到。日志到位，这些问题基本都能在几分钟内定位。这套内容学完到现在，我最大的感受是：大模型应用开发真正难的不是调用接口，而是把每次生成时的目标、边界和历史都管清楚。能做到这三点，文本扩展和聊天机器人就已经能支撑起不少实实在在的业务场景了。