企业官网建设流程全解析

先看一个很具体的实践：How I used an LLM to kick my nicotine addiction，翻译过来就是“如何用大语言模型辅助戒除尼古丁成瘾”。

这个标题看起来像个人故事，但它背后其实是一整套可以复用的技术方案。核心思路不是让 LLM 替你“下决心”，而是把大模型当成一个 24 小时在线、不评判、能记录、能复盘的行为干预助手：你随时把烟瘾冲动的感受、触发场景、替代动作丢给它，它帮你结构化地记录、追问、分析和总结。

这篇文章会拆解这套方案怎么从零搭起来。你会看到本地模型怎么选、提示词怎么设计、日志记录怎么做、接口怎么调用、批量复盘脚本怎么写，以及显存、CPU、端口、进程这些实际部署中躲不开的问题。适合想用 LLM 做个人健康管理记录、行为干预、情绪日志的人，也适合把 LLM 接入自己工具链的开发者。

先说结论：这不是什么高门槛项目。没有 GPU 也能跑，有小显存显卡体验会好很多，完全本地部署还能把吸烟冲动记录这类隐私数据留在自己机器里。下面按可复现的流程来写。

1. 核心能力速览

在动手之前，先把这套“LLM 戒瘾辅助方案”的关键规格列出来。

这里要强调一个边界：这套工具链的角色是“辅助记录与认知干预”，不能替代专业医疗建议。如果戒断过程中出现明显身体不适或严重情绪问题，应该寻求专业帮助。

2. 适用场景与使用边界

这类方案最核心的适用场景，是把“冲动”变成一个可以被观察的数据点。

具体来说，它可以做四件事：第一，在你烟瘾冲动来的时候，提供一个即时对话入口，帮助你冷静下来；第二，通过固定问题结构，帮你识别冲动背后的触发因素，比如压力、社交、饭后、无聊；第三，把每次冲动记录保存下来，形成时间线和强度曲线；第四，用 LLM 做周期性复盘，找出哪些情况下最容易破戒，哪些替代动作最有效。

它不是用来替代意志力的，而是用来降低“记录”和“复盘”这两个动作的摩擦成本。传统戒烟建议往往让人做纸质记录，但很多人坚持不下去。用 LLM 对话的形式，相当于有人每隔一段时间问你一句“刚才发生了什么”，这个过程更自然，也更适合长期记录。

使用边界也必须说清楚。

第一，隐私边界。吸烟行为、情绪波动、身体状态属于敏感健康数据。本地部署 LLM 的优势就是数据不出本机。如果非要用云端模型，也要把输入内容匿名化，去掉姓名、手机号、具体地址等信息。这篇文章统一使用本地部署方案。

第二，安全边界。LLM 不是医生，不要让它回答用药剂量、替代药物选择、戒断综合征判断这类问题。最好的做法是在提示词里直接声明：遇到身体不适或医疗问题，只提示“建议咨询专业医生”，不做诊断。

第三，稳定性边界。本地服务可能因为进程退出、端口占用、模型加载失败而不可用。当你处于强烈冲动状态时，如果工具连不上，体验会非常差。所以日常记录仍要保持一个最简单的文本兜底方案，比如手机备忘录里存一行模板。

3. 环境准备与前置条件

下面的流程按“本地部署 + 本地 API + 脚本分析”来组织。

3.1 操作系统与软件依赖

这套方案不依赖特定操作系统。Windows、macOS、Linux 都可以。

需要准备的基础软件如下：

• Python 3.9 以上，用于运行调用脚本和批量分析脚本。
• Ollama 或其他本地 LLM 运行工具，用于加载模型并提供 API。
• curl，用于快速验证 API 是否可用。
• 一个终端工具，Windows 上建议用 PowerShell 或 Windows Terminal，Linux/macOS 用系统终端即可。

如果你熟悉 Docker，也可以把模型服务容器化，方便迁移和复现。不过为了降低门槛，下面的示例以 Ollama 为主。

3.2 硬件与模型选择

先根据手头硬件确定模型规模。

选择模型时，优先选 7B 到 14B、对中文支持较好的 instruct 模型。比如 Qwen2.5 系列的 7B/14B 都是常见选择。如果你有 4090 或更大的专业卡，可以尝试 32B 以上，效果会更好，但功耗和响应时间也会增加。

注意：显存占用不是一个固定数字。它和模型参数量、量化位数、上下文长度、并行请求数都有关系。最可靠的方法是在自己的机器上跑起来之后用nvidia-smi观察。不要直接照搬网上任何一个“显存占用 X G”的结论，那是特定环境下的结果。

3.3 磁盘空间与端口

模型文件体积通常不小。7B 量级的基础模型文件常见在 4GB 到 8GB 之间，14B 可能到 10GB 以上，具体取决于量化格式。建议预留 20GB 以上磁盘空间，并给输入输出数据单独建目录。

端口方面，Ollama 默认监听11434。如果这个端口被占用，可以修改环境变量OLLAMA_HOST来换端口。这一步在后面的常见问题里会单独讲。

3.4 目录规划

建议把记录、脚本、模型配置分开管理。这里给一个推荐结构：

nicotine-llm/ ├── scripts/ │ ├── chat_with_llm.py │ └── weekly_review.py ├── prompts/ │ └── system_prompt.txt ├── data/ │ ├── notes/ │ ├── reports/ │ └── raw_logs/ ├── models/ └── README.md

这个目录结构的好处是，输入素材、输出报告、脚本代码互不干扰，批量任务出错时也容易定位。

4. 安装部署与启动方式

4.1 安装 Ollama

Ollama 是目前本地跑 LLM 最方便的工具之一。安装方式很简单。

Linux 或 macOS 可以在终端执行：

curl -fsSL https://ollama.com/install.sh | sh

Windows 用户直接去 Ollama 官网下载安装包，安装后就能在终端使用ollama命令。

安装完成后检查版本：

ollama --version

4.2 拉取模型并启动服务

拉取一个 7B 量级的模型，比如 Qwen2.5 7B：

ollama pull qwen2.5:7b

如果你的显存比较紧张，可以看 Ollama 模型库中是否有更小或更高量化的版本，比如带q4字样的标签。具体标签名以实际模型库为准。

接下来运行模型：

ollama run qwen2.5:7b

执行后你会进入一个对话终端，直接输入“你好”就能看到一个基础回复。这说明模型已经加载成功。

注意，ollama run会保持一个交互会话。如果你想让它作为后台 API 服务运行，只需要保持 Ollama 主进程在运行即可。默认情况下，Ollama 安装后会自动在后台监听11434端口。

验证 API 是否可用：

curl http://127.0.0.1:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "stream": false, "messages": [{"role": "user", "content": "你好"}] }'

如果返回了正常 JSON，说明 API 已经通了。后面所有脚本都可以走这个本地接口。

4.3 准备系统提示词

这个项目的关键不是“能对话”，而是“对话内容能不能按固定结构执行”。所以 system prompt 要写得非常明确。

在prompts/system_prompt.txt中保存下面这个模板：

你是我的戒断辅助助手。 你的目标是帮助我记录尼古丁戒断过程中的冲动、触发因素和替代行为。 回答要求： 1. 不评判，不吓唬。不要使用“你怎么又忍不住”这类表达。 2. 每次回复正文控制在 3 句话以内，否则在关键场景会带来额外压力。 3. 先确认并接纳我的感受，再用一个提问帮我识别触发点。 4. 不要提供任何医学诊断或用药建议。如果我提到身体不适，统一回复“建议咨询专业医生”。 5. 在你认为适合记录时，用 JSON 结构输出本次记录。 6. 如果我问你“今天数据怎么样”，请汇总最近记录，给出趋势判断。 记录 JSON 结构： { "date": "2025-06-02", "time": "10:15", "trigger": "工作压力", "intensity": 7, "action": "做了10个深蹲", "result": "忍住了" }

这个提示词非常关键。它的目的是把 LLM 的输出约束到一个可解析、可复查的方向上，而不是让它自由发挥。自由对话适合兴趣聊天，不适合需要持续追踪的行为干预。

4.4 用 Python 调用本地模型

写一个最小的 Python 调用脚本，先验证从脚本到模型之间的链路是通的。

import requests SYSTEM_PROMPT = open("prompts/system_prompt.txt", encoding="utf-8").read() url = "http://127.0.0.1:11434/api/chat" payload = { "model": "qwen2.5:7b", "stream": False, "messages": [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": "我现在烟瘾犯了，特别想点一根。"} ] } resp = requests.post(url, json=payload, timeout=180) resp.raise_for_status() data = resp.json() print(data["message"]["content"])

运行这个脚本，观察模型返回的内容。如果回复包含了安抚和追问，说明提示词生效；如果回复冗长、跑题或者出现了没有依据的健康建议，说明需要调整提示词或更换模型。

这是整个项目中最小的可运行闭环，建议先把这一步跑通，再做后续功能。

5. 功能测试与效果验证

一个 LLM 辅助戒瘾工具，至少需要测下面几个维度。

5.1 冲动场景模拟测试

直接模拟“烟瘾犯了”这个最高频场景。

输入示例：

我现在烟瘾犯了，特别想点一根。

判断标准：

• 模型是否先接纳感受，而不是说教。
• 是否会追问触发因素，比如“刚才发生了什么”或“你现在是压力大还是无聊”。
• 是否给出了替代动作建议。
• 是否控制在 3 句话以内。

常见失败情况：

• 模型回复太长，变成一篇说教文章。
• 模型直接说“吸烟有害健康”然后结束，没有提供行动建议。
• 模型给出“你可以买尼古丁口香糖”这类具体医疗产品建议。只要不是专业医疗背景，这超出了安全边界。

出现这些情况，优先调整 system prompt，把“不要给具体药物建议”这句话写得更有约束力。如果还不行，换一个对齐能力更强的模型。

5.2 触发因素识别测试

这个测试的目的是看模型能不能帮你从“模糊感受”里拆出“具体触发点”。

输入示例：

我今天下午其实没压力，但看到同事去阳台抽烟，我就特别想来一根。

好的回复应该指出：环境线索是触发因素，可能属于“看到他人吸烟”或“社交场景”类型，并建议以后遇到类似场景时的应对方式。

判断标准是：模型是否能把“同事抽烟”识别为一种环境触发，而不是只停留在“你要坚持住”的鼓励层面。

5.3 结构化记录测试

当用户描述完一次冲动后，模型是否按提示词里的 JSON 结构输出记录。

输入示例：

刚才开会开到一半，脑子很乱，特别想抽一根。后来我去茶水间喝了杯水，过了五分钟好一点了。

判断标准：

• 返回内容里是否包含trigger、intensity、action、result等字段。
• intensity是否是一个数字。
• action是否能准确概括“喝水”这个替代动作。

如果模型没有输出 JSON，可以在 system prompt 里增加一句“当用户描述完一次完整的冲动过程时，必须输出一条 JSON 记录”。如果仍不稳定，说明模型指令跟随能力不够，换更大或对齐更好的模型。

5.4 多轮对话稳定性测试

这不是一次问答就结束的事。你需要连续发多条消息，模拟一天中的多次冲动记录。

测试时按下面顺序连续输入：

1. 早上起床后想抽烟。 2. 是不是因为昨晚没睡好？ 3. 那我今天该怎么提醒自己？ 4. 帮我记录刚刚这次，10点半，强度6，原因是没睡好，我喝了一杯水。

判断标准：模型在第四轮是否能正确生成一条包含所有字段的记录，而不是把前三轮内容重复一遍。

这里最容易暴露的问题是上下文丢失或格式漂移。如果三轮之后模型开始忘记 JSON 格式，说明上下文长度或模型能力不足以支撑这种用法。

5.5 周复盘测试

当数据积累到几天后，让模型对记录做一次汇总。

这是我这周的冲动记录：三天内有 5 次冲动，2 次在晚上，3 次发生在工作压力大的时候。我不确定规律是什么，你能帮我分析一下吗？

判断标准：模型能否给出一个清晰的规律总结，比如“晚上冲动可能与加班疲劳有关”或“工作压力是主要触发因素”，而不是泛泛地说“坚持就是胜利”。

6. 接口 API 与批量任务

6.1 本地 API 能力

Ollama 启动后，相当于在本地暴露了一个 HTTP 接口。这意味着你不需要打开任何独立网页，完全可以通过脚本调用模型能力。接口地址默认是：

http://127.0.0.1:11434

常见接口包括/api/chat和/api/generate。具体请求结构以实际部署工具的文档为准，上面 Python 示例使用的是/api/chat的常见结构。

如果你不想用 Ollama，也可以用 LM Studio、vLLM 等工具。它们的 API 路径可能不同，但思路一致：模型服务端口起来之后，用 HTTP 请求调用。

6.2 让 LLM 生成周报的批量脚本

批量任务的设计思路是：把一段时间内的记录从 JSON 文件读取出来，一次性交给 LLM 做汇总分析。

假设每天的记录都保存在data/notes/目录下，下面这个脚本会读取一周的记录并生成复盘报告。

import json import glob import requests def load_notes(directory): notes = [] for path in sorted(glob.glob(f"{directory}/*.json")): with open(path, encoding="utf-8") as f: notes.extend(json.load(f)) return notes notes = load_notes("data/notes") url = "http://127.0.0.1:11434/api/chat" payload = { "model": "qwen2.5:7b", "stream": False, "messages": [ { "role": "system", "content": "你是一个健康管理分析助手。请只基于用户提供的记录做描述性总结，不提供医疗建议，不评价个人意志。" }, { "role": "user", "content": "请根据以下戒烟记录生成周复盘，输出规律、触发因素和有效替代动作：\n" + json.dumps(notes, ensure_ascii=False) } ] } resp = requests.post(url, json=payload, timeout=300) resp.raise_for_status() with open("data/reports/weekly_review.md", "w", encoding="utf-8") as f: f.write(resp.json()["message"]["content"])

这个脚本已经具备批量任务的基本特征：输入是目录下的多个 JSON 文件，输出是一份独立的 Markdown 报告。后面如果要处理更多天数据，只需要往目录里放更多 JSON 文件，不需要改代码。

6.3 批量任务的设计建议

批量任务最容易踩的坑有三个：第一，输入数据格式不一致，导致模型输出乱掉；第二，单次请求上下文过长，导致响应变慢或超时；第三，并发请求太多，导致显存不足或服务崩溃。

建议永远先做小规模测试。先放三条记录，确认输出正常，再放一周数据。批量分析建议串行执行，不要同时发起很多请求。如果有几十条甚至上百条记录，一次塞进上下文可能超过模型上下文限制，最好拆成多次分析再汇总。

如果要在脚本里增加失败重试，可以加一个最简单的时间间隔重试逻辑：

for attempt in range(3): try: resp = requests.post(url, json=payload, timeout=300) resp.raise_for_status() break except requests.exceptions.RequestException as e: print(f"请求失败，第 {attempt + 1} 次尝试：{e}") time.sleep(5)

6.4 LLM 与其他平台是否需要同一台电脑

这里可以直接回答一个网上常问的问题：LLM 服务和调用端必须在同一台电脑上吗？

不需要。LLM 服务本质上是一个 HTTP 服务，部署在一台机器上，其他机器通过网络访问即可。如果你把 Ollama 部署在电脑 A，电脑 B 只需要把请求地址从127.0.0.1:11434改成http://电脑A的IP:11434就能调用。这种做法适合一台性能较好的机器专门跑模型，其他设备只负责发送指令。

但要注意两点：一是暴露局域网 IP 时，要确保网络环境可信，否则别人也能调用你的模型服务；二是如果把请求地址改成公网地址，必须加鉴权措施。Ollama 默认没有复杂鉴权，不建议直接暴露到公网。ComfyUI 与 LLM 是否在同一台机器，同理，不必须，通过 API 跨机调用即可。

7. 资源占用与性能观察

7.1 显存和内存怎么看

如果使用 NVIDIA 显卡，可以用nvidia-smi查看显存占用。在运行模型的同时打开一个终端，执行：

nvidia-smi

重点看Memory-Usage那一列。如果显存占用接近上限，说明模型规模或上下文长度需要调低。

如果没有独立显卡，可以通过系统任务管理器或top命令查看内存和 CPU 占用。CPU 推理时，7B 模型可能会出现明显的响应延迟，这是正常现象。这类工具对交互响应速度有一定要求，如果 CPU 推理慢到十几秒才回复，体验会明显下降。

7.2 影响性能的关键参数

在同一个模型里，影响资源占用最大的几个因素如下。

• 模型参数量：7B、14B、32B 之间差异是数量级的。
• 量化位数：Q4、Q5、Q8、FP16 各自显存占用不同，量化越高占用越大，效果通常也更好。
• 上下文长度：请求中携带的历史消息越多，占用的显存和内存越高。不要在批量任务里一次性塞入无限长的历史记录。
• 并发请求数：同时请求越多，占用越高。个人使用场景下，保持串行请求最稳妥。

7.3 如何降低资源占用

如果你的设备带不动当前模型，按这个顺序尝试：

1. 换成更小的模型，比如从 14B 降到 7B。
2. 使用更高压缩率的量化版本。
3. 缩短上下文，只保留最近几轮对话。
4. 关闭其他占用显存的程序，比如浏览器硬件加速、其他模型服务。
5. 在批量任务中，把长记录拆成小批次处理。

需要注意的是，降低资源占用通常会带来回复质量下降。你需要自己测试一个平衡点：回复是否能稳定输出 JSON，是否还能记住前几轮的关键信息。如果做不到，硬件就不适合跑这个模型。

8. 常见问题与排查方法

9. 最佳实践与使用建议

这类工具最终能不能起作用，很大程度不取决于模型多强，而取决于使用流程是否稳定。下面几条建议可以直接用。

第一，先跑通最小闭环。第一天不要设计复杂功能，只需要完成“输入一句话，模型回复一句话，脚本能记录日志”这个过程。最小闭环稳定后，再逐步加周报、趋势分析、批量处理。

第二，固定 system prompt。不要每天随手改提示词，频繁修改会让模型行为不稳定，也让你难以判断效果变化是来自数据还是提示词。每次修改提示词，可以备份一份旧版本，比如system_prompt_v2.txt。

第三，用 JSON 保存原始记录，用 Markdown 保存复盘报告。原始记录必须结构化，便于批量分析和长期统计。复盘报告是给人看的，Markdown 足够。不要用对话式的自由文本作为主要存储方式，后续很难分析。

第四，冲动来临时记录越快越好。可以在手机或电脑桌面放一个启动脚本，双击就进入对话界面。如果手边没有模型服务，也可以用系统自带备忘录先写一行：时间、触发点、强度、做了什么。等回到电脑前再补录到 JSON 中。

第五，数据要及时备份。本地 JSON 文件可能因为误删、磁盘故障而丢失。最简单的方式是在脚本里加一段自动复制到备份目录的逻辑，或者定期手动备份。这些记录是你的行为基线数据，丢失后很难重建。

第六，保持隐私边界。不要把真实姓名、手机号、详细工作单位等身份信息写进数据文件。分析触发因素时，用“工作压力”“开会”“晚饭后”这类去身份化的描述即可。

第七，模型输出必须复核。LLM 生成的周报可能存在幻觉，比如把没有记录的日期当成真实数据。批量分析脚本可以增加一个简单校验，在输出报告前手动检查关键结论是否有对应记录支持。不要把模型总结当成绝对事实。

第八，合规和安全使用边界要前置。这是辅助工具，不涉及医疗诊断。如果出现身体不适、严重焦虑、睡眠障碍等戒断反应，不要指望 LLM 处理，直接咨询专业医生。涉及个人健康数据的使用，也要遵守相关法律法规和平台规则，不用于未经授权的场景。

10. 总结与下一步

把 LLM 用于尼古丁成瘾干预，本质上不是让模型解决“意志力”问题，而是把主观冲动转变成可记录、可分析、可复盘的客观数据。这套方案里，最重要的不是模型参数多强，而是三条链路是否稳定：对话输入链路、结构化解析链路、批量复盘链路。这三条链路都跑通之后，它就从一个聊天工具变成了一个行为干预工具。

值得最先验证的功能是 5.1 的冲动场景模拟测试。如果模型在“我现在烟瘾犯了”这句话下能给出简短、不评判、有追问的回复，说明提示词方向是对的。如果这一步效果不好，后续记录和复盘质量都会受影响。

最容易踩的坑有两个。一是把 system prompt 写得过于抽象，模型自由发挥空间太大；二是记录数据没有固定 JSON 结构，导致后期无法批量分析。这两个问题都要在一开始就避免。

后续可以扩展的方向很多：把记录接入日历工具生成打卡提醒，用本地向量数据库保存长期记忆，把周报脚本改成自动发送到手机的小工具，或者把提示词和脚本打包成一键启动的整合包分享给需要的人。这些都是在当前骨架上的自然延伸。

如果你也需要一套能长期记录的本地 LLM 行为辅助工具，建议先从最小闭环开始，跑通之后再逐步加功能。数据越规整，模型能帮你提炼的东西就越多。