企业官网建设流程全解析

后台隔三差五就有人问我一句话：完全没碰过代码、也没学过数学，现在开始学 AI 还来不来得及。我的回答一直是同一个——来得及，但你得先接受一件事：零基础入门 AI，前期真正卡住你的不是算法，而是环境和跑通第一段能出结果的代码。我见过太多人收藏了几十份"AI 学习路线图"，买了一堆课，最后还是停在"Python 装好了吗"这一步。这篇 AI 入门启蒙教程就是写给这部分人的，不讲大词，不摆公式，全程围绕"实操落地无压力"来设计：从环境准备、最小可运行脚本、参数怎么调，到做一个自己能天天用的本地小工具，最后把新手最容易踩的坑整理成速查表。你要是刚接触这个领域，或者之前试过几次都没跑通，按下面的顺序走一遍，一周之内你手上就会有一个真正能用的东西。

1. 先想清楚：零基础学 AI 到底该学什么

我特别不建议一上来就看课程目录里那些"深度学习数学基础""反向传播推导"。不是说没用，而是性价比极低——这些东西对做模型研究的人是刚需，对绝大多数想用 AI 解决问题的人不是。真正决定你能不能入门的分水岭，是你能不能独立完成一次"输入数据 → 得到结果 → 结果可用"的闭环。这个闭环跑通了，你后面学什么都快；跑不通，学再多概念也是空的。

1.1 三条常见入门路径，我为什么推荐第三条

我把身边人走过的路径归了三类，各自的代价差别非常大。

我推第三条，理由很实在：正反馈来得快。人学任何东西都需要正反馈撑着，尤其零基础。你花三天做出一个能把自己写的文案润色一遍的小工具，这个成就感会推着你往下走；你花三个月推导完一堆公式，还是不知道这些东西能干什么，热情大概率先死掉。

注意：调用优先不等于不学原理。我的做法是"先跑通，再回填"——遇到输出不稳定、结果乱飘的时候，自然会去问"为什么会这样"，这时候再去补概念，吸收效率比干看教材高好几倍。

1.2 我建议的最小闭环：四个环节缺一不可

所谓最小闭环，就是四个环节：数据进来、模型处理、结果出去、人能用。很多教程只讲前两个，讲完就没了，你跟着敲完代码，发现结果全在命令行里滚，用起来极其别扭。

所以我建议一开始就把"人能用"这一环纳进来。具体来说，一个完整的最小项目应该是这样的：

• 输入：一个文本框，让人能把要处理的内容贴进去
• 处理：把你写好的调用逻辑跑一遍
• 输出：结果展示在界面上，可复制、可保存
• 兜底：网络断了、返回为空、格式错了，界面得给出提示而不是直接崩

这四件事加起来，代码量其实不超过两百行，但它是"能用的工具"和"跑着玩的脚本"之间的分水岭。我自己的习惯是：任何一个新想法，先用两百行之内做出能点的版本，觉得有用了再往下加功能。这个习惯帮我省掉了大量"做了半个月发现有更好方案"的时间浪费。

1.3 环境和工具选型的判断依据

零基础最容易在这一步卡死。我给的判断标准就三条，非常朴素：

第一，装的时候不要编译。凡是需要你自己拉源码、装编译器、配环境变量的，一律先跳过。能在命令行敲一行命令装好的，才是你现阶段该用的。

第二，默认参数能跑起来。有些工具默认配置极其复杂，二十个参数你要理解一半才能出结果，这种先放着。

第三，报错信息你能看懂。这一条最容易被忽略。工具再好，报错全是内部堆栈，你对着一堆看不懂的东西排查，时间全耗在猜上。

依这三条筛下来，你会筛掉一大半"看起来很厉害"的重型框架。这不是能力问题，是阶段问题。我在带新人的时候反复强调：在你不具备排查能力之前，任何复杂度都是负债。等你能独立定位报错了，再去碰那些重家伙，那时候你会觉得顺手，而不是痛苦。

2. 打通基础认知：几个绕不开的核心概念

环境搞定之前，先把四五个词彻底搞明白，能省掉后面 80% 的困惑。我不讲定义，讲它们实际影响什么。

2.1 参数量、上下文、Token：三个最容易把人绕晕的词

参数量，通俗讲就是这个模型的"脑容量"。7B 指七十亿参数，32B 指三百二十亿。参数量决定它对复杂问题的处理能力和它吃多少硬件资源。我一般这么打比方：7B 像刚毕业的实习生，日常问答、改写、总结够用；32B 像有几年经验的熟手，能处理稍微绕一点的逻辑。但注意，参数量大不等于什么都好，速度和硬件要求也跟着上去了。

上下文，指模型一次能"看见"多少内容。你把一万字丢给它，如果上下文只有八千，它就只能看到前面一部分。这是新手最容易误解的地方——很多人以为自己贴的全文都被读了，其实早被截断了。判断办法很简单：在提示词里问它"我上面第一段最后一句话是什么"，看看它能不能答对。

Token，模型算账的最小单位。中文大概一个字对应 0.6 到 1 个 token，看具体的分词器。粗略估算：中文字符数乘以 0.7，差不多就是 token 数。这个数字很重要，因为它同时决定了两件事——你的上下文够不够用，以及你要花多少钱。

我习惯在做任何长文本任务前先算一笔账。举个例子：假设一次请求输入 3000 个中文字、要求输出 800 字，那输入大约 2100 token，输出大约 560 token。如果单价假设是每百万 token 输入 1 元、输出 3 元（仅为举例，你按实际单价替换），单次成本约等于 2100÷1000000×1 + 560÷1000000×3 ≈ 0.0038 元。看着微不足道，但你要是批量处理一万条，就是 38 元。这个账算清楚，你在设计流程的时候自然会去想"能不能先过滤再送模型"，而不是无脑全量丢进去。

2.2 训练和推理的区别，为什么零基础要跳过训练

训练是让模型从数据里学东西，推理是让学过的模型回答问题。绝大多数人的需求是后者。

为什么建议跳过训练？三个现实原因。

一是硬件成本。粗略估算显存的公式是：参数量 × 每参数字节数 × 1.2（额外开销系数）。7B 模型用半精度，每参数 2 字节，那就是 7×2×1.2 ≈ 16.8GB 显存；量化到 4 位，每参数 0.5 字节，就是 7×0.5×1.2 ≈ 4.2GB。这还只是推理。要训练，显存需求还得往上翻好几倍，普通笔记本根本扛不住。

二是数据质量门槛。微调不是喂几篇文档就行的，格式、配比、标注一致性都有讲究，做不好反而把原有能力搞坏。我见过有人拿几百条杂乱数据微调完，效果比原来还差，最后还得回退。

三是现有方案够用。大多数"让模型懂我的业务"的需求，靠提示词加上检索增强就能解决，成本是微调的零头。我一般的判断是：先试提示词，不行加检索，再不行才考虑微调。这个顺序能省掉 90% 的无用功。

2.3 提示词到底在做什么：把模型当成一个"只看你这段话的实习生"

提示词不是什么玄学。它本质上是你在给一个信息受限的执行者下指令。这个执行者能力很强，但只看得见你给它的内容，而且会努力"猜你想要的"。理解这一点，很多问题就解释得通了。

它为什么会瞎编？因为你没给它素材，它又必须给个答案，只能猜。解决办法是明确告诉它"只根据以下材料回答，材料里没有就说不知道"。它为什么输出格式老不对？因为你的要求太模糊。把"给我列一下"改成"用表格输出，三列分别是问题、原因、解决办法，不要输出其他内容"，成功率立刻上去。

我总结下来，一条能稳定工作的提示词，通常包含四个部分：角色（你是谁）、任务（做什么）、约束（不能做什么、边界在哪）、格式（怎么输出）。缺哪一块，就会在对应的地方出问题。后面第 5 章我会给一个填空式的模板，照着套就行。

提示：不要迷信网上那些"神级提示词"。同样的提示词在不同模型上表现差异很大，你自己测三遍，比抄十篇都管用。

3. 实操第一步：把一次调用彻底跑通

这一章是全篇最"硬"的部分，我会把完整代码和参数都摆出来。你把 URL 和密钥换成自己的就能跑。

3.1 环境准备与依赖安装

关于 Python 环境，我给零基础的建议是：别折腾多版本管理。直接装最新稳定版 Python，安装时勾上"加入 PATH"（Windows 上这个勾一定要打，不打后面命令行找不到 python，无数人卡在这）。

装完之后，在项目目录里建虚拟环境。这一步很多人跳过，然后过两个月发现各种包冲突，整个环境报废。虚拟环境就是给每个项目一个独立的"工具箱"，互不干扰。

# 创建并激活虚拟环境（Windows） python -m venv .venv .venv\Scripts\activate # macOS / Linux python3 -m venv .venv source .venv/bin/activate # 装依赖 pip install requests gradio python-dotenv

三个包的作用：requests负责发网络请求，gradio负责做界面，python-dotenv负责把密钥从代码里挪出去。最后这个包看着不起眼，但非常重要——密钥硬编码在代码里，一不小心截图发出去了，或者上传到公开仓库，就是给自己找麻烦。

3.2 最小可运行脚本：四十行完成一次完整调用

先建一个.env文件，把你的服务地址、密钥、模型名写进去（这三项从你所用的服务商后台拿）：

LLM_API_BASE=http://127.0.0.1:8000/v1 LLM_API_KEY=your-key-here LLM_MODEL=your-model-name

然后写主脚本app.py：

import os import time import requests from dotenv import load_dotenv load_dotenv() API_BASE = os.getenv("LLM_API_BASE", "").rstrip("/") API_KEY = os.getenv("LLM_API_KEY", "") MODEL = os.getenv("LLM_MODEL", "") def chat(messages, temperature=0.3, max_tokens=800, retries=3): """一次带重试的对话调用，返回纯文本""" url = f"{API_BASE}/chat/completions" headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", } payload = { "model": MODEL, "messages": messages, "temperature": temperature, "max_tokens": max_tokens, } last_err = None for i in range(retries): try: resp = requests.post(url, headers=headers, json=payload, timeout=60) if resp.status_code == 200: data = resp.json() return data["choices"][0]["message"]["content"] last_err = f"HTTP {resp.status_code}: {resp.text[:200]}" except requests.RequestException as e: last_err = f"请求异常: {e}" time.sleep(2 ** i) # 指数退避：1s, 2s, 4s raise RuntimeError(f"调用失败，最后一次错误：{last_err}") if __name__ == "__main__": msgs = [ {"role": "system", "content": "你是一个严谨的文字编辑，只做润色，不改变原意。"}, {"role": "user", "content": "把这句话改通顺：这个东西我觉得还行但是价格有点那个。"}, ] print(chat(msgs))

跑起来。如果这一步能出结果，恭喜你，最难的一关已经过了。

代码里几个细节值得说一下。timeout=60必须写，不写的话网络卡住你的程序会一直挂着，你会以为是代码有问题。2 ** i是指数退避，第一次失败等 1 秒、第二次等 2 秒、第三次等 4 秒，因为很多失败是瞬时限流，立刻重试反而更容易连续失败。rstrip("/")是防止你填的地址末尾带斜杠，导致拼接出两个斜杠的路径——这个坑我踩过，报错信息完全看不出原因。

3.3 参数怎么调：温度、最大长度、重试次数

温度这个参数被误解得最多。很多人以为调低就是"变聪明了"，其实调低只是让输出更集中、更保守。做信息抽取、格式转换这类任务，温度必须在 0.3 以下，不然同一个输入两次结果都不一样，你的下游代码没法处理。做头脑风暴、起名字这类任务，温度拉到 0.8 才有点意思。我一般不在代码里写死，而是给它留个界面上的滑块，方便现场试。

关于max_tokens，有个常见陷阱：很多人设得很小图省成本，结果输出到一半被硬切断，返回的 JSON 少了个右括号，解析直接报错。我的建议是宁可设高一点，然后自己检查返回内容里有没有"结束标记"，或者看看返回的结束原因字段是不是正常结束。被截断的输出看起来完整，实际上已经废了，这是最隐蔽的问题之一。

3.4 把输出变成结构化数据：解析与兜底

让模型直接输出 JSON 是最实用的技巧，也是新手最容易翻车的地方。原因有三：模型爱在 JSON 外面加"好的，以下是结果："这种废话；爱用中文全角引号；爱在末尾加注释。

我的处理办法是三层防护：

import json import re def parse_json_safely(text): # 第一层：直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 第二层：抠出最外层大括号之间的内容 m = re.search(r"\{.*\}", text, re.S) if m: try: return json.loads(m.group(0)) except json.JSONDecodeError: pass # 第三层：全角符号替换后再试 if m: fixed = m.group(0).replace("“", '"').replace("”", '"').replace("：", ":") try: return json.loads(fixed) except json.JSONDecodeError: pass return None # 返回 None，交给上层决定怎么兜底

配套的提示词也要写清楚，我一般这么写：

只输出 JSON，不要输出任何解释文字，不要用代码块包裹。字段：title（字符串）、tags（字符串数组）、score（0 到 100 的整数）。如果信息不足，对应字段填空字符串或空数组。

这里有个经验：在提示词里把"不要做什么"写具体，比写"要做什么"更有效。"只输出 JSON"这种约束，比"请以 JSON 格式返回"的成功率高不少。另外，返回None而不是抛异常，是刻意的设计——解析失败是常态，不是异常，上层拿到None想做重试还是返回默认值，由业务决定。

4. 实操第二步：做一个自己天天能用的小工具

能调通了，接下来把它变成"东西"。我给零基础的人的建议是：第一个工具一定要选你自己天天都要做的事，不要选"别人觉得有用"的事。因为只有你自己天天用，你才有动力去修那些别扭的地方，这个过程才是真正的学习。

4.1 需求收敛：从"做个 AI 应用"缩到"做一个能跑的小工具"

新手最大的问题不是不会写，是目标太大。"我要做一个 AI 写作助手"——这句话里藏着几十个决策：支持几种文体？要不要保存历史？要不要用户系统？要不要多轮对话？每一个都能拖你半个月。

我的收敛方法叫"一句话定义"。格式是：给谁、在什么场景下、把什么输入变成什么输出。比如："给我自己，在整理会议记录的时候，把口语化的原始记录变成带编号的待办事项清单。"这个定义清楚之后，所有不相关的东西都能砍掉——不用历史记录、不用多轮对话、不用用户系统，一个输入框、一个按钮、一块输出区，完事。

砍掉的东西越多，你做完的概率越大。我做过统计，身边能坚持下来的人，第一个项目基本都在三百行代码以内；做不下来的，基本都是第一版就规划了十几个功能。

4.2 界面层实现：五十行做出能点的界面

用gradio做界面，代码少到你会怀疑它是不是真的能跑。

import gradio as gr from app import chat SYSTEM_PROMPT = """你是会议记录整理助手。 任务：把用户给的口语化记录整理成待办清单。 约束： 1. 只提取明确的行动项，不臆造没有的内容。 2. 每条待办包含：事项、负责人（没说就写"待定"）、时间（没说就写"待定"）。 3. 用编号列表输出，不要输出其他内容。 """ def run(raw_text, temperature): if not raw_text.strip(): return "请先粘贴会议记录内容。" if len(raw_text) > 6000: return "内容太长，请分段处理（当前约 %d 字）。" % len(raw_text) msgs = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": raw_text}, ] try: return chat(msgs, temperature=temperature, max_tokens=1000) except Exception as e: return f"调用出错：{e}\n建议：检查服务是否在线、密钥是否有效。" demo = gr.Interface( fn=run, inputs=[ gr.Textbox(label="原始记录", lines=12, placeholder="把会议记录粘贴在这里"), gr.Slider(0.0, 1.0, value=0.3, step=0.1, label="随机度"), ], outputs=gr.Textbox(label="整理结果", lines=12), title="会议记录整理器", description="把口语化记录变成待办清单。", ) if __name__ == "__main__": demo.launch()

跑起来之后浏览器会自动打开一个本地页面，能输入、能点按钮、能看结果。这就是一个完整的产品雏形了。

注意run函数里的两个前置检查——空输入和超长输入。这两个检查看着简单，但它们是"玩具"和"工具"的区别。空输入直接送进去，模型会开始瞎编；超长输入送进去，会被静默截断，你拿到一个看起来正常但漏了后半段的结果，这是最坑的情况。所有检查都要在送进模型之前做，别指望模型帮你判断。

4.3 本地跑还是调接口：一笔实实在在的账

这是新人问得最多的问题。我给一个判断框架，你对着算就行。

我的实际选择是：开发阶段用在线接口，确定要长期高频用再考虑本地。原因很实际——开发阶段你会反复改提示词、反复试参数，这时候换模型像换衣服一样方便最重要。等你把逻辑磨稳定了，发现每天要调几百次，成本上来了，再迁到本地不迟。

如果你确实想本地跑，硬件估算按前面那个公式来。举个具体例子：想跑一个 7B 的模型，量化到 4 位，显存需求约 4.2GB，加上上下文缓存和系统开销，留 6GB 比较稳。8GB 显存的卡能跑，但上下文别开太大。想跑 14B 的 4 位量化，大约 14×0.5×1.2 ≈ 8.4GB，加开销要 10GB 以上，8GB 卡就不够了。这个账提前算，比装完了发现跑不动强。

4.4 提示词模板工程化：别每次都从零写

做到第三个工具的时候你会发现，提示词的结构高度重复。我的做法是把它抽成一个可复用的模板，四个空位填完就能用：

PROMPT_TEMPLATE = """# 角色 {role} # 任务 {task} # 约束 1. 只使用我提供的材料，材料没有的信息写"未提及"，不要推测。 2. {extra_constraint} 3. 输出语言为中文。 # 输出格式 {format_spec} """ def build_prompt(role, task, extra_constraint, format_spec): return PROMPT_TEMPLATE.format( role=role, task=task, extra_constraint=extra_constraint, format_spec=format_spec, )

这个模板里，我认为最关键的是第 1 条约束——"只使用我提供的材料"。加上这一句之后，模型瞎编的比例会明显下降。这不是什么高深技巧，就是把"没有依据时该说什么"明确告诉它，而不是留白让它自由发挥。

另一条经验是把提示词当成代码来管理：改一次，测一次，记一次。我建了个简单的表格，左边是版本号，中间是改动内容，右边是三条固定测试用例的通过情况。听起来很土，但它能防止你"改好了 A 结果弄坏了 B"这种反复横跳。提示词调优最怕的就是凭感觉改，改到最后自己都不知道哪版最好。

5. 常见问题与排查实录

这一章是我这些年被问得最多的问题汇总，按类型整理，遇到问题直接查表。

5.1 环境类问题速查表

这里我特别说一下"装到了另一个环境"这个坑。笔记本上装了两三个 Python 是很常见的事，你以为pip install装好了，其实装到了另一个解释器下面，然后运行时报找不到。排查顺序是：先python -V看版本，再pip -V看它指向哪个目录，两个路径对不上就是这个问题。这个排查动作我建议养成肌肉记忆，能省掉大量莫名其妙的折腾。

5.2 输出类问题：瞎编、截断、格式乱

瞎编。判断标准很简单：让它给你出处。如果它给不出，或者给的是模糊描述，那这段内容基本不可信。根治办法是在提示词里明确"材料里没有就说未提及"，并且在代码里做一次检查——返回内容里如果出现了"未提及"，说明材料确实不够，你该去补材料而不是去调模型。

截断。前面提过，max_tokens太小是最常见原因。但也有个隐蔽原因：上下文超限。你把两万字丢进去，模型只看了前面一部分，输出的内容看着完整，其实基于残缺信息。排查办法是主动测边界：在一个长文档的末尾埋一句特殊标记，然后问模型那句话是什么，答不上来就是被截断了。

格式乱。三个动作按顺序试：把格式要求写得更死（给出完整的示例输出）、把温度降到 0.1、加上"不要输出解释文字"。这三个动作能解决 95% 的格式问题。剩下的 5% 通常是模型能力本身不够，换个大一点的模型就好了，不用死磕。

5.3 分批处理与速率问题

当你从"处理一条"变成"处理一千条"，会遇到一批新问题。这部分内容大多数入门教程不讲，但它才是真正能用的关键。

第一是速率限制。别用多线程猛冲，先老老实实串行跑十条，看有没有失败。稳定了再考虑加并发，并发数从 2 开始加，别一上来就 20。我一般的做法是加一个固定间隔，比如每次请求之间停 0.3 秒，这个简单粗暴的办法能避免绝大多数限流。

第二是断点续跑。批量处理一定要把每一条的处理结果立刻落盘，而不是全跑完再统一保存。一千条跑到第 990 条崩了，前面全白干，这种经历一次就够了。做法很简单：逐行写 JSON 到文件，跑之前先读一遍已有的记录，跳过处理过的。二十行代码的事。

第三是失败隔离。单条失败不能让整批停掉。用异常捕获包住每条的处理逻辑，把失败的记录单独写到一个"待重跑"文件里，跑完再看。我的习惯是跑完之后统计三个数字：成功数、失败数、失败原因分布。这三个数字能告诉你问题出在限流、内容太长还是格式解析，对症下药比盲目重试有效得多。

注意：批量跑之前，先用十条数据试一遍，把失败率压到零再放量。放量之后发现系统性错误，返工成本是试跑阶段的几十倍。

6. 学习节奏与我踩过的坑

最后聊点不那么"技术"的东西，但对坚持下来影响很大。

6.1 我建议的四周节奏

第一周，只干一件事：把调用跑通，能稳定输出结果。不追求效果，能跑就行。这一周你会花大量时间在和环境搏斗，这是正常的，别怀疑自己。

第二周，做一个小工具，必须有界面。目标是自己能用起来，哪怕简陋。这一周的重点是理解"输入检查""异常兜底""结果落盘"这三件事。

第三周，开始调效果。准备二十条自己的真实数据，跑一遍，看哪些不行，然后改提示词、改参数，记录下来。这一周你会第一次体会到"提示词是有结构的东西"。

第四周，试着做一件超出当前能力的事，比如加检索、加多轮、加批量。这一周大概率会失败，没关系，失败的过程就是你在建自己的知识地图。

这个节奏我用了好几轮，最大的好处是每周都有交付物。看得见的东西是撑住热情的唯一办法。反过来，我见过最多的失败模式就是：前两周全在看书，第三周开始写代码发现啥都不会，然后就停了。

6.2 几个我实打实踩过的坑

第一个坑，过早追求"优雅"。我最早写的一个小工具，为了代码好看，把调用逻辑拆成了五个文件、七八个类。结果改一个小地方要跳五个文件，改完自己都忘了改的是哪。后来全部删掉写成两个文件，反而顺畅。结论：工具类项目，两百行以内就一个文件，别拆。

第二个坑，过度依赖模型判断。我做过一个分类小工具，让模型自己判断"这条是不是垃圾信息"。效果时好时坏。后来改成：先让模型输出一个 0 到 100 的分数，我自己在代码里定阈值，超过 80 才算垃圾。这么一改，可控性立刻上来了。教训是：能让代码判断的，别让模型判断。模型负责模糊的部分，确定的规则交给你自己的代码。

第三个坑，不留日志。早期我调效果全靠"感觉这次比上次好"，完全是玄学。后来加了一行日志，把每次的输入、参数、输出、耗时全记下来，问题定位速度翻了不止一倍。现在我的模板里，日志是默认配上的，不管多小的项目。

第四个坑，忘了算隐性成本。有段时间我拿模型处理长文档，单次看着不贵，跑了一批才发现总价不低。后来加了前置过滤——先用关键词筛掉明显无关的段落，只把相关部分送进去，成本直接降了大半，效果反而更好，因为上下文里的噪音少了。这个经验挺反直觉：少给模型一些内容，它往往表现更好，特别是在长文档场景下。

第五个坑，也是最容易犯的，拿单次结果当结论。模型输出有随机性，一次结果好不代表方案好，一次结果差也不代表方案差。我现在测任何改动，固定用同一组十条输入跑三遍，看稳定性。这个习惯建立起来之后，我调参的效率高了很多，也不再因为一次坏结果就推翻整个方案。

如果你现在还在犹豫要不要开始，我的建议就是别再做计划了，打开命令行，把第 3 章那段四十行的代码敲一遍。跑通的那一刻，你对这件事的所有想象都会落地成一个具体的东西，后面该学什么，自然就清楚了。