企业官网建设流程全解析

1. 先扔掉那堆术语：LLM到底在帮你做什么

上个月有个刚入行的同学来找我，说想学大语言模型（LLM），结果B站收藏夹里存了三十多个视频，每一条开头都在讲Transformer、注意力机制、张量并行，他看了三天连"这个技术到底能干嘛"都没搞清楚。这大概是新手入门LLM时最典型的状态——不是不想学，是被术语淹没了。所以我这篇东西不打算从架构论文讲起，而是先回答一个更基础的问题：LLM放在你面前，它本质上是件什么工具。

1.1 预测下一个词：听说读写背后只有这一件事

你可以把大语言模型理解成一个极其擅长"接话"的系统。给它一段文字，它不断地猜测下一个最可能出现的词是什么，猜完一个再猜下一个，直到凑成完整回答。所谓"生成""续写""对话"，本质都是这个"预测下一个词"的过程在反复执行。

很多人觉得这个解释太简单了，配不上"大模型"三个字，但它恰恰是最准确的底层视角。无论是ChatGPT类的对话助手，还是文档摘要、代码补全、翻译润色，拆开看全是"给上文，补下文"。有个比喻我经常跟新人讲：它就像一个读了全世界几万亿文字、练出语感的超级"自动补全"。你去问它问题，它不是在"查答案"，而是在基于上下文计算一串概率最高的后续文字。

这个认知能帮你避免一个特别常见的误解——把模型当成搜索引擎或者数据库。搜搜索引擎是"找已有的东西"，LLM是"凭空猜最合理的表达"。

1.2 为什么"参数"越多的模型越聪明

参数这个词你肯定听过，比如"某模型有700亿参数"。参数可以粗浅理解为模型内部可调节的"旋钮"数量，训练过程就是不断旋转这些旋钮，让模型的预测越来越接近真实文本。

参数越多，模型能记住的模式就越细腻。但要注意，模型大小和效果不是简单正比关系。在实际项目里，参数少的模型（比如几十亿量级）照样能出色完成分类、抽取这类任务；参数多的模型（动辄上千亿）则在复杂推理、长文本理解上更有优势。新手选模型的时候，别盲目追大，先想清楚你的任务复杂度。

一个小经验：先用小模型跑通流程，再换大模型比较效果。我见过太多人一上来就调用最强模型，结果响应慢、成本高，而且根本用不到那个智力水平。先解决"有没有"，再优化"好不好"。

1.3 给新手的第一个类比：超级自动补全的放大版

如果你用过手机输入法，你已经在无意识中使用预测下一个词了。输入"今天天气真"，输入法会推荐"好""不错""热"——这就是最原始的预测式语言模型。大语言模型做的是把这个能力放大到极端：训练数据的规模、层数、自注意力机制的复杂程度都远超输入法，于是它从一个"记短语的小工具"进化成了"能聊天、能写代码、能做推理的通用系统"。

但切记，既然是"预测下一个词"，它就存在一个天然缺陷：为了让你满意，它会在不确定时编造看起来合理的答案。这个现象业内叫"幻觉"。这不是Bug，而是这个架构的内在属性。后面我会专门说怎么应对它。

2. 动手前的三道必答题：API、上下文窗口和温度

原理聊完，接下来是动手前的准备工作。新手真正需要先搞清楚的，不是模型内部的张量怎么流动，而是三个工程概念：用什么方式接入模型、模型的记忆上限是多少、怎么控制回答的"性格"。这三件事直接决定了你写的代码跑起来是顺畅还是翻车。

2.1 API是现在最务实的接入方式

对绝大多数新手程序员来说，第一只脚踩进来的方式是调用API，而不是自己训练模型。原因很现实：训练一个大模型需要的数据、算力和工程基建，个人和小团队根本负担不起。而通过API，你只需要几行代码就能把一个已经训练好的模型接到你的业务里。

现在的API服务商很多，有的大厂平台，也有开源自建方案。选哪家不是这里讨论的重点，但有两个通用建议：

• 优先选生态成熟、文档齐全、社区案例多的服务，能省你大量排查时间。
• 先看免费额度或者低价档位，把Demo跑通再升级，别一上来就把账单拉满。

代码层面，几乎所有主流服务都兼容类似OpenAI格式的接口，用Python的requests库就能直接调，不一定要装SDK。后面第三章我会给出完整的调用样例。

2.2 上下文窗口：记住什么、忘记什么由它决定

上下文窗口是LLM的"短时工作记忆"，单位是token。token可以粗略理解为"词片"——一个英文单词通常是一个token，一个中文字大约是0.5到1个token。模型的上下文窗口是固定的，比如8K、32K、128K。你的输入加上模型产生的输出，总token数不能超过这个上限。

新手最容易在这里踩坑。两个常见事故：

第一，把几千字的文档直接塞进提示词，结果还没等模型开始回答，输入就已经顶爆窗口了。第二，连续多轮对话后，前面说过的话被"挤"出窗口，模型突然失忆。解决办法后面实战章会演示：要么做文本截断/摘要压缩，要么用外挂记忆（也就是RAG的雏形）。

我的建议是，入门阶段先养成一个习惯：估算每次请求的token成本，养成读token用量统计的肌肉记忆。很多新手完全不知道自己一次请求花了多少钱，直到月底收到账单才傻眼。

2.3 温度参数：让AI"理性"还是"放飞"

温度（temperature）是控制模型随机性的参数，范围通常是0到2，值越大回答越发散，值越小越保守。可以这么理解：

• 温度接近0：模型几乎总是选概率最高的那个词，输出稳定、可复现，适合抽取结构化信息、代码生成。
• 温度比较低（0.3到0.7）：在确定性基础上加一些变化，适合写文案、广告创意、头脑风暴。
• 温度比较高（0.8以上）：放飞自我，同一个问题每次回答都不一样，适合灵感探索，但质量不稳定。

我个人的实践是：做工具类应用（信息抽取、格式化输出、代码解释）一律设0.2以下；做内容生产类应用设0.7左右；做创意类探索才会开到0.9以上。新手可以先只调温度这一个参数，其他保持默认，你会很快感受到模型"性格"的可控性。

顺便说一句，有些服务还提供top_p参数，作用类似但机制不同。入门阶段两者不用同时调，固定温度就够了，否则很难定位效果变化的原因。

3. 第一个落地Demo：抓会议记录里的Action Items

理论讲完了，来点能跑的东西。我建议新手做的第一个LLM项目不是聊天机器人，而是一个信息抽取任务。因为聊天机器人的评价标准模糊，容易让你沉迷"调戏AI"；而抽取任务目标明确、结果可验证，能帮你快速建立对模型能力的真实体感。

下面这个Demo是帮某个小团队做的会议纪要整理工具，需求很简单：给模型一段会议记录，让它输出每个成员的待办事项、负责人和截止日期。

3.1 场景拆解与Prompt设计

先看原始输入，大概是这个风格：

2024-11-02 项目周会 - 产品说下版本要加导出功能，后端评估工作量 - 前端反馈首页加载慢，建议做性能优化 - 测试问这周五能不能出测试用例 - 后端说导出功能得依赖新接口，大概三天 - 决定：导出功能由张三负责，11月10日前完成 - 决定：性能优化由李四排查，优先级高

目标输出是有结构的待办清单。第一版Prompt我这么写：

你是一个会议纪要整理助手。根据用户给出的会议记录，抽取所有待办事项/行动计划。 输出JSON格式，字段：task(事项描述), owner(负责人), due_date(截止日期, 如果原文没提到就填null)。 只输出JSON，不要任何多余文字。 会议记录： {会议记录内容}

很多人第一次写Prompt容易掉进"字典式要求"的坑——恨不得把每个字段的规矩都写一遍，结果模型反而抓不住重点。我的原则是：给角色、给任务、给输出格式、给反例说明，四件事说清楚就够了。

3.2 Python调用代码与参数配置

下面是完整的Python调用代码，用的是通用的requests方式，依赖最少：

import requests import json API_URL = "https://your-provider.example.com/v1/chat/completions" API_KEY = "sk-your-key" def extract_action_items(meeting_text: str) -> dict: prompt = f""" 你是一个会议纪要整理助手。根据用户给出的会议记录，抽取所有待办事项。 输出JSON格式，字段：task(事项描述), owner(负责人), due_date(截止日期, 没有就写null)。 只输出JSON，不要任何多余文字。 会议记录： {meeting_text} """ headers = { "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}", } payload = { "model": "gpt-4o-mini", # 换成你实际可用的模型名 "messages": [ {"role": "system", "content": "你是一个严格的结构化输出助手。"}, {"role": "user", "content": prompt}, ], "temperature": 0.1, "max_tokens": 1500, } resp = requests.post(API_URL, headers=headers, json=payload, timeout=60) data = resp.json() if resp.status_code != 200: raise RuntimeError(f"API error: {data}") content = data["choices"][0]["message"]["content"] # 防御：模型偶尔会在JSON外面包一层```json代码块 content = content.strip() if content.startswith("```"): content = content.split("\n", 1)[1].rsplit("```", 1)[0] return json.loads(content) if __name__ == "__main__": meeting_text = """ 2024-11-02 项目周会 - 产品说下版本要加导出功能，后端评估工作量 - 前端反馈首页加载慢，建议做性能优化 - 测试问这周五能不能出测试用例 - 后端说导出功能得依赖新接口，大概三天 - 决定：导出功能由张三负责，11月10日前完成 - 决定：性能优化由李四排查，优先级高 """ result = extract_action_items(meeting_text) print(json.dumps(result, ensure_ascii=False, indent=2))

几个细节说明一下：

• 我把temperature设成了0.1，结构化抽取任务要的是稳定，不是创意。
• 加了system消息来强化模型的行为约定，比只靠user消息更稳。
• 代码里做了代码块的剥离处理，因为模型偶尔会输出Markdown格式的JSON，不处理就会json.loads直接报错。
• max_tokens设1500，给足输出空间，但也不至于失控。

跑出来的结果大约是这样：

[ { "task": "下版本增加导出功能", "owner": "张三", "due_date": "2024-11-10" }, { "task": "首页性能优化排查", "owner": "李四", "due_date": null } ]

到这里，你的第一个LLM应用已经通了。它做的事情和那些"XX智能助手"本质没有差别：自然语言进，结构化JSON出。

3.3 输出结构化的两种做法

上面用的是Prompt约定输出JSON，这是最简单的方式，但稳定性一般，偶尔会出现字段缺失、JSON非法等问题。如果要做更工程化的方案，有两条进阶路径：

• 函数调用（Function Calling）：模型先输出一个结构化的函数调用指令，你校验参数后再执行本地代码。适合需要和系统联动（比如查数据库、发邮件）的场景。
• 结构化输出约束（Response Format）：一些新模型原生支持强制JSON Schema输出，直接把结构定义好交给模型，不符合格式的输出会被服务端拦下。

我的建议是，新手先用第一种把流程跑通，等体感建立后再迁移。别一开始就上重型机制，排查难度会成倍增长。

4. 提示词工程的核心心法：把模型当成一个聪明但健忘的实习生

标题里有个"奥秘"两个字，很多人的误区是觉得苹果藏在模型训练里。但作为一个程序员，你能直接影响的只有输入输出层——也就是提示词。提示词工程不是玄学，它有一套可以迁移的方法论，核心心法就一句话：把模型当成一个聪明、博学、但没有常识边界、容易紧张且完全不了解你业务背景的实习生。

你给实习生的指令越模糊，他交回来的东西就越离谱。你给的上下文越具体，输出越接近预期。

4.1 角色设定为什么管用

你肯定见过Prompt开头写"你现在是一个资深前端工程师"。很多人觉得这是心理暗示，其实它真正起作用的原因是：角色设定帮助模型锁定了语言风格和知识范围，减少了一些无关方向的展开。

我测试过同一道算法题，用"你是数据结构和算法专家"开场，和直接开问，前者的解答步骤明显更有条理。原因不难理解，模型训练数据里有大量按角色分类的文本，角色设定让它在概率分布上更倾向于"专家类文档"的表达方式。

但注意，角色设定不是万能的。如果你设定的角色对任务没有信息增益，相当于废话。比如做JSON抽取时写"你是一个专业的JSON工程师"，效果和"输出JSON"没有本质差别。角色设定的核心是：通过激活模型在训练中见过的高质量文本模式，来提升生成质量。

4.2 结构化Prompt的模板

我日常用的结构化Prompt模板是这样：

# 角色 你是【角色】 # 背景 【给模型足够的业务上下文，让它理解信息所处的环境】 # 任务 【一句话讲清楚你要模型做什么】 # 输入 【数据放在最底部，避免前置干扰】 # 输出格式 【明确的格式约束，最好带示例】 # 注意事项 【不要编造、不确定就写null、用中文回答等等，按需追加】

关键原则：越是重要的指令越要靠前放，底层语言模型对长文本前部的注意力权重更高。另外输入数据放在最底部，能减少Prompt前面的指令被长数据"稀释"。

4.3 少样本示例比讲道理更有效

如果发现模型总是理解不了你的格式要求，别在那里反复调整措辞，直接用少样本示例（Few-shot）砸过去。比如上面的会议抽取，你可以给一个输入输出对，让模型照着这个"榜样"来。

看这个对比：

• 只用文字描述："注意，如果会议记录中没有明确提到负责人，就填null。"
• 加示例：

  示例： 输入：决定：UI走查由王五负责，下周一前给出报告。 输出：{"task": "UI走查", "owner": "王五", "due_date": "2024-11-09"}

第二种方式的效果远好于第一种。原理上，模型在训练时见过海量"问题-答案"对，你给一个示例，相当于在原生的"补全链路"里提供了一段强锚定。这是提示词工程里投入产出比最高的一个技巧。

5. 进阶路线图：本地部署、RAG、微调，现在该碰哪个

写到这里，你已经具备了写第一个LLM应用的能力。但收藏党的老毛病这时候要犯了——开始收藏本地部署教程、微调教程、RAG教程。我劝你先冷静，因为这里坑最多，也是最容易让人半途而废的地方。

5.1 本地部署和微调，新手最容易掉进去的方向

先说本地部署。本地部署一个开源模型听起来很酷，但现实是：

• 一个7B参数级别的模型，量化后也需要至少6-8G显存才能跑得舒服。
• 70B级别模型，没有多张高端显卡根本跑不动，即使跑起来推理速度也是灾难。
• 你要处理的问题从"调API出结果"变成"环境配置、依赖冲突、推理性能优化"——这已经不是LLM入门，是运维入门。

我见过太多新同学花两周时间搞环境，最后模型确实加载出来了，但问他这个模型能拿来做啥，支支吾吾说不出来。方向完全反了。

再说微调。微调适合的场合是什么？是让模型学会某种固定的风格（比如模仿一个客服的话术格式）或掌握你业务里的大量私有领域知识。但问题是，绝大多数业务用提示词加上检索（RAG）就能解决，微调的成本和风险（训练数据泄露、过拟合、评估困难）反而更高。

5.2 什么时候才真的需要微调和RAG

我做过的实际判断标准：

需要上RAG（检索增强生成）的典型情况：模型的上下文窗口装不下你全部私有资料，或者希望回答能基于最新数据。做法是先检索相关资料，把相关片段塞进提示词，再让模型回答。这条路对程序员很友好，因为本质是写代码加向量数据库，不涉及模型训练。

需要微调的典型情况：任务的输入输出模式高度固定，提示词已经无法进一步约束（比如把自由文本转成特定领域的专业术语缩写）。又或者你发现每一次调用都要在提示词里塞一大堆背景说明，成本实在太高，这时候可以考虑用微调把风格"固话"进模型参数里。

对新手的一句话建议：先老老实实把API调用和提示词工程玩熟，再去碰RAG。微调建议至少在你做过三个月以上LLM项目之后再考虑。

5.3 一条三个月可走完的路线图

如果你想要一个可执行的进阶路径，我给一个版本参考：

• 第一个月：用API完成三个不同场景的小工具（信息抽取、文本分类、内容改写），彻底掌握调用、参数调节、错误处理。
• 第二个月：做一个小型RAG系统，把自己的一些文档丢进向量库，让模型基于这些文档回答。理解"来检索长文本切片、向量化、召回再输入Prompt"的链条。
• 第三个月：参加一些开源的Prompt评测活动或数据集，用系统化方法衡量你的Prompt在不同温度、不同模型上的表现差异，建立"工程化调优"的感觉。

三个月后你再回头看，大概率不再焦虑那些玄乎的术语，因为你已经能够判断"什么场景用什么工具"了。这才是程序员切入LLM领域最重要的能力。

6. 新手期最容易踩的坑，我替你们踩了一遍

最后这段是我积累的真实教训，每一件都对应过一个新同学来找我求助。写出来帮大家少花点冤枉时间。

6.1 token计费的隐形开销

我见过有人做批量文本分析，一次把十万字的文档全塞进Prompt，跑了几百次循环，月底账单一出来直接懵了。其实大多数API按token计费，你输入的每个字也在花钱。而且很多模型输入的计费单价和输出不一样，文档型任务大头往往在输入侧。

给新手的操作建议：

• 批量任务先拿几十条数据估算总token用量，再估算成本，再决定是否要压缩文本。
• 长文本场景优先用支持更大上下文但不能"无限塞"的模型，或者对原始文本做分段、摘要后再输入。
• 尽量用轻量级模型做预处理，把精贵的大模型调用留给最复杂的环节。

6.2 模型输出格式不稳定

结构化输出是新手项目里最烦人的问题。明明Prompt写清楚了"只输出JSON"，模型偶尔还是给你夹带几个解释性的句子。我的处理方式用了几层防御：

• 第一层，在Prompt里加"不要输出任何与JSON无关的文字"。
• 第二层，代码里对返回文本做清洗，去掉Markdown代码块标记。
• 第三层，如果解析失败，自动重试一次。重试时带着上次的错误信息，让模型自己意识到问题。
• 第四层，实在不行就降级到正则抽取兜底。

这套"从提示词到代码再到容错"的链路，本质上和你在后端写接口时"参数校验-异常重试-降级兜底"的思路完全一样。程序员做LLM应用的最大优势就在这里：你不是在跟模型聊天，你是在用工程手段驯服它。

6.3 把模型当数据库用

最后这个坑最隐蔽。很多人上手后第一反应是把所有业务数据都塞给模型，觉得它能理解一切。但LLM的记忆是易失的、有窗口限制的、还会编造。你的知识资产应该放在数据库和向量库里，模型只是"读阅者"和"表达者"，不是存储介质。

判断标准很简单：如果某个信息明天还要用、下次请求还要查，就不要依赖模型记住，把它落到你的业务系统里，该存数据库就存数据库。模型的任务是理解、推理、生成，持久化和一致性是程序员的老本行。

我刚入门那阵，所有项目都想着"丢给AI"，后来通过几次线上事故才彻底想明白这一点。把这句话留给你：LLM是推理引擎，不是存储引擎。想清楚这个问题，你的项目架构就不会歪。

最后说点个人感受。我见过很多新手在LLM面前要么畏难、觉得原理太深学不会，要么轻浮、觉得聊天能搞定一切。真实的姿态应该是中间那条：把它当成一个能力很强但脾气古怪的同事，先用简单项目建立信任，再逐步试探边界，最后用工程手段把它嵌进自己的系统里。这个过程会踩坑，但每踩一个坑，你对底层的理解就扎实一分。这大概是这一波新技术浪潮里，程序员最值得花时间掌握的技能之一了。