企业官网建设流程全解析

最近“加入 OpenAI 前后对比照”这个话题在开发者圈子里被反复讨论。抛开网络上的娱乐化表达，我看到的更多是技术人工作流被重构的现实:照片里那种“状态变化”背后的真正变量，不仅是薪资和平台，而是从“一个人对着编辑器硬扛”变成“带着一整套 AI 原生工具链在战斗”。对一个长期写代码、带项目、排故障的开发者来说，这个“前后对比”背后真正值得研究的，是 OpenAI 的模型能力如何通过 API、Codex CLI、Agent 执行框架和本地化部署协议渗透进日常开发。

这篇文章我不想聊照片本身，而是想围绕话题背后真正可迁移的技术底座，拆出一套完整的 AI 原生开发环境搭建与实战方案。包含 Python 调用 OpenAI API、Codex CLI 安装与使用、VS Code 配置、基于 OpenAI 兼容协议接入 vLLM / Ollama 本地模型、LangChain 编排，以及高频问题排查和工程安全建议。不管你是零基础入门，还是想在业务项目里落地 AI 能力，都能从中找到可复制的操作路径。

1. 从“加入 OpenAI 前后对比照”聊起：AI 原生工作流正在重塑开发方式

1.1 热议背后的真实信号

“加入 OpenAI 前后对比照”之所以能引发热议，表面上是大家对一家明星 AI 公司内部工作状态的好奇，深层原因则是很多人已经隐隐意识到：OpenAI 代表的不仅仅是一家公司，更是一套全新的开发范式。

在老式开发流程里，一个功能从想法到上线，大致要经历需求分析、接口设计、数据库设计、编码、测试、部署、监控等环节。这个链条里最容易成为瓶颈的是“编码”环节，因为人的精力有限，一天能稳定输出的有效代码量是有上限的。而在 OpenAI 这类 AI 原生环境里，大量重复性编码工作被模型和 Agent 承担，工程师的核心职责从“写每一行代码”变成了“定义输入、约束输出、审查结果”。

这种变化带来的直接结果，是同一个开发者在不同工作流里的产出效率可能差出一个数量级。所以“前后对比照”在技术层面可以解读成：一个普通开发者进入 AI 原生工具链之后，工作状态和交付能力发生了显著变化。

1.2 本文要解决什么问题

这篇教程要做的，是把这个“前后变化”背后的技术底座拆开，让你在自己的电脑上也能搭出一套可用的 AI 原生开发环境。具体会覆盖四层内容：

• 如何用 Python 调用 OpenAI 的 Chat Completions 接口，完成对话、流式输出、工具调用。
• 如何安装并配置 OpenAI Codex CLI，把它接入终端和 VS Code 工作流。
• 如何通过 OpenAI 兼容协议接入本地模型服务，比如 vLLM、Ollama。
• 如何在 LangChain 里统一管理和调用不同来源的模型服务。

学完之后，你至少能回答这几个问题：我的项目该以什么方式接入 OpenAI 能力；Codex CLI 能帮我做什么；如果数据不能出内网，本地模型的兼容方案怎么搭；遇到 401、429、超时这类报错怎么排查。

2. 先把概念理清楚：传统开发、AI 辅助开发与 AI 原生开发

2.1 传统开发流程的瓶颈

传统开发流程的核心是人。需求文档流转到开发手里，开发根据经验写出代码，然后测试人员验证，最后上线。整个过程是串行的，任何一环的人力不足都会拖慢项目进度。更麻烦的是，一个中大型系统的代码量可能达到几十万行，新成员光阅读现有代码就需要数周，而编写新功能时又不得不处理大量模板代码、重复逻辑和跨模块对接。

这套流程本身没有错，但效率上限很明显：人的注意力有限，编码速度有限，代码审查和联调的沟通成本也很高。因此，开发者的时间其实大量消耗在“机械性编码”和“上下文切换”上，真正用于创造性设计的精力被挤压。

2.2 AI 原生开发的“原生”在哪里

很多人以为 AI 辅助开发就是在 IDE 里装一个代码补全插件，其实这只是最浅的一层。所谓 AI 原生开发，是指整个开发流程从工具链层面就以模型能力为核心来设计。比如：

• 需求描述直接变成 Prompt 和任务定义。
• 代码生成交给模型完成，开发者负责提供上下文和验收标准。
• Agent 可以自主执行多步操作：读取文件、搜索代码、运行命令、修改代码、运行测试。
• 测试用例、文档、迁移脚本等辅助工作也由模型生成，人工做最终审核。

在这种范式里，上下文的组织和约束变得比语法本身更重要。你能不能让模型准确理解仓库结构、业务语义和编码规范，直接决定了生成结果的质量。这也是为什么 OpenAI 会把 Codex 这类 Agent 工具作为重点方向：它们解决的不是“单个代码补全”，而是“多文件、多步骤的工程任务”。

2.3 OpenAI Codex、Harness 与 Agent 的关系

围绕 OpenAI 的热搜词里，Codex、Harness 出现频率很高。这里需要区分三个概念：

• Codex：OpenAI 推出的编程智能体产品形态，可以通过自然语言指令完成代码编写、文件修改、命令执行等任务。它可以运行在云端，也可以通过 CLI 方式在本地环境中工作。
• Harness：可以理解成承载 Agent 执行流程的沙箱和工具集，负责给模型提供可用的工具、上下文和反馈循环。
• Agent：指具备感知、决策、行动和观察循环的智能体。在开发场景里，Agent 会读取仓库文件、执行命令、查看测试结果，然后决定下一步做什么。

对大多数开发者来说，现阶段最值得先掌握的还是 API 调用和 Codex CLI 这种能直接落地的工具，而不是去复刻 Harness 内部实现。下面我们就从环境准备开始，一步步搭建。

3. 环境准备与账号配置

3.1 运行环境说明

本文示例以常见开发环境为准，重点演示配置思路。建议环境如下：

• 操作系统：Windows 10/11（建议开启 WSL2）、macOS 或主流 Linux 发行版。
• Python 3.10 或更高版本。
• Node.js 18 或更高版本（安装 Codex CLI 时需要）。
• 包管理工具：pip、npm。
• IDE：VS Code 最新稳定版。
• 版本管理：Git。

不同版本之间可能存在差异，但整体流程是一致的。如果你使用的是 Python 3.8 或 Node 16 这类较老版本，建议先升级，否则部分依赖可能无法安装。

3.2 OpenAI API Key 的获取与安全存放

调用 OpenAI API 需要在官方平台注册账号并创建 API Key。这里我们只讨论正常、合规的开发流程。创建 Key 之后，不要把它硬编码在源码里，更不要提交到 Git 仓库，否则一旦代码泄露，Key 就可能被他人盗用，产生费用和安全风险。

推荐使用.env文件配合python-dotenv管理本地环境变量。

pip install python-dotenv

在项目根目录创建一个.env文件：

OPENAI_API_KEY=你的_API_Key

然后在代码中加载：

import os from dotenv import load_dotenv load_dotenv() api_key = os.getenv("OPENAI_API_KEY")

如果你的项目中已经存在.gitignore，记得把.env加进去：

.env

3.3 示例项目结构

为了后面实战案例不混乱，先约定一个统一的项目目录结构：

ai-dev-workflow/ ├── .env ├── .gitignore ├── requirements.txt ├── 01_basic_chat.py ├── 02_stream_chat.py ├── 03_tool_calling.py ├── 04_local_model_ollama.py └── 05_langchain_router.py

这样的结构足够简单，方便你逐个文件运行。后面所有代码都会标注文件路径，你直接复制到对应文件里即可。

4. 实战入门：Python 调用 OpenAI API

4.1 安装依赖

在项目虚拟环境中安装 OpenAI Python SDK：

pip install openai

如果你需要统一依赖管理，可以把以下内容写进requirements.txt：

openai python-dotenv langchain-openai ollama

然后一次性安装：

pip install -r requirements.txt

注意，包的版本会持续升级，建议以当前时间实际安装到的版本为准。本文代码基于 OpenAI Python SDK 1.x 版本的接口写法。

4.2 基础对话补全

先写一个最简单的对话调用。文件路径：01_basic_chat.py

import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), ) response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一名资深 Python 开发工程师。"}, {"role": "user", "content": "请用一句话解释什么是闭包。"}, ], temperature=0.7, ) print(response.choices[0].message.content)

这段代码做了几件事：

• 从.env加载 API Key。
• 用OpenAI客户端对象封装请求。
• 调用chat.completions.create发起对话补全。
• 从返回结果中取出第一个回复内容并打印。

其中messages是一个消息列表，每条消息包含role和content两个字段。role有三种常见取值：system用来设定系统行为，user表示用户输入，assistant表示模型的历史回复。model指定模型名称，不同模型的成本、速度和能力有差异，生产环境需要根据场景选择。

运行结果类似：

闭包是函数与其定义时所在词法作用域的组合，即使外部函数已经执行完毕，内部函数仍然可以访问外部函数的变量。

4.3 流式输出

当模型生成内容很长时，一次性等待完整响应会让用户觉得卡顿。更好的方案是开启流式输出，让内容像打字机一样逐字显示。文件路径：02_stream_chat.py

import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) stream = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "user", "content": "列出 Python 中 5 个常用的内置高阶函数，并简述用途。"} ], stream=True, ) for chunk in stream: if chunk.choices[0].delta.content is not None: print(chunk.choices[0].delta.content, end="", flush=True)

这里的核心区别是stream=True。当设置为流式时，接口返回的不是一个完整对象，而是一个迭代器。我们需要遍历每一个chunk，从delta.content中取出增量文本。flush=True的作用是让内容立即输出到控制台，避免被缓冲。

流式输出在构建聊天机器人、AI 写作助手时非常实用，能显著提升用户体验。

4.4 函数调用（Tool Calling）

真实业务里，模型并不总是直接返回文本，经常需要调用外部工具来获取实时数据或执行操作。OpenAI 提供了工具调用能力：开发者把可用函数以 JSON Schema 的形式告诉模型，模型根据用户提问决定是否调用工具以及传什么参数，然后由我们的代码真正执行函数。

文件路径：03_tool_calling.py

import json import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) def get_weather(city: str) -> str: """模拟获取城市天气。实际项目中可以替换为真实天气 API。""" data = { "北京": "晴，25°C", "上海": "多云，28°C", "广州": "雷阵雨，30°C", } return data.get(city, "暂无数据") tools = [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的当前天气情况", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，例如北京、上海" } }, "required": ["city"] } } } ] messages = [ {"role": "user", "content": "北京今天天气怎么样？"} ] response = client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=tools, ) assistant_message = response.choices[0].message # 判断模型是否请求调用工具 if assistant_message.tool_calls: # 把模型回复追加到上下文 messages.append(assistant_message) for tool_call in assistant_message.tool_calls: function_name = tool_call.function.name arguments = json.loads(tool_call.function.arguments) if function_name == "get_weather": result = get_weather(city=arguments["city"]) else: result = "未知工具" messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result, }) second_response = client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=tools, ) print(second_response.choices[0].message.content) else: print(assistant_message.content)

这段代码需要特别注意消息协议的顺序：

1. 先发送用户消息。
2. 模型返回一个tool_calls，表示它想调用某个函数，此时assistant_message.content通常为空。
3. 我们把 assistant 消息追加到messages。
4. 代码执行真实函数，然后把结果以role: "tool"的方式追加进去。
5. 再次调用模型，让模型基于工具结果生成最终回复。

工具调用是把大模型接入业务系统的关键桥梁，比如查询订单状态、调用搜索引擎、操作数据库等。生产环境里，函数执行部分一定要加权限校验、参数校验和异常处理，避免模型可控参数引发安全问题。

5. 实战进阶：把 Codex CLI 接入日常开发

5.1 Codex CLI 是什么

Codex CLI 是 OpenAI 开源的命令行编程智能体工具，相关代码和文档可以在 GitHub 仓库openai/codex中找到。它可以在本地终端中运行，通过自然语言指令执行多步开发任务，比如“分析当前项目的 TODO 并实现其中第一个功能”，或者“帮我把这个 Python 脚本改造成异步版本”。

和单纯调用 API 不同，Codex CLI 更像一个本地开发助手，它可以读写文件、执行命令、查看终端输出，并根据这些反馈持续调整自己的操作。安装和使用方式可能随版本变化，建议以官方仓库 README 的最新说明为准。

5.2 安装与配置

在终端中通过 npm 全局安装：

npm install -g @openai/codex

安装完成后，先确认版本：

codex --version

如果提示找不到命令，说明 npm 全局目录没有加入系统的 PATH，需要根据实际环境配置。

然后设置 API Key 环境变量。Linux / macOS 可以执行：

export OPENAI_API_KEY="你的_API_Key"

Windows PowerShell 执行：

$env:OPENAI_API_KEY="你的_API_Key"

为避免每次重启终端都要重新设置，建议把环境变量写入 shell 配置文件，比如~/.bashrc或~/.zshrc。

首次使用可以运行初始化命令，Codex 会引导你完成基本配置，包括选择模型等选项。具体交互以你安装版本的提示为准。

5.3 在终端中使用 Codex

在任意项目目录下，直接以自然语言描述任务。例如：

codex "查看当前目录下的项目结构，并帮我补一个 README.md，内容包含项目简介和启动方式"

Codex 会先分析目录结构和已有代码，然后生成 README 文件。执行过程中，它会展示将要执行的操作，部分操作可能需要你确认。

再举一个更偏向实战的例子。假设你的项目里有一个main.py，你想让它读取一个 JSON 文件并输出统计结果，可以输入：

codex "阅读 main.py，理解现有逻辑，然后增加一个函数：从 data.json 中读取数据，统计每个分类的数量，并把结果打印出来。修改后运行测试确保没有语法错误"

这种交互方式非常适合做一些跨文件的改动任务，它省去了我们自己定位文件、理解上下文、编写模板代码的时间。但要注意，Codex 生成的结果仍然需要人工审查，尤其是在涉及删除文件、修改数据库、操作对象存储等高风险动作时。

5.4 在 VS Code 中配置 Codex

VS Code 配置 Codex 有两种常见思路。

第一种是集成终端。VS Code 底部自带终端，直接在其中使用codex命令即可，无需额外配置。推荐把终端改成默认 shell，例如在 Windows 下使用 WSL 的 bash 或在 macOS 下使用 zsh，这样环境变量更容易统一。

第二种是使用官方或第三方扩展。你可以在 VS Code 扩展市场搜索 “Codex” 或相关 OpenAI 扩展，安装后根据扩展说明配置 API Key 和模型。这里不推荐在代码仓库里保存 Key，更稳妥的方式是让扩展读取环境变量或本机钥匙串。

如果你希望把 Codex 的思维链和文件改动过程展示在编辑器里，可以关注官方对 VS Code 集成方案的支持动态。功能细节变化较快，以扩展市场实际安装到的版本说明为准。

6. 实战扩展：通过 OpenAI 兼容协议接入本地模型

6.1 为什么需要 OpenAI 兼容协议

OpenAI 的 API 格式已经成了事实上的行业标准。很多本地推理框架，比如 vLLM、Ollama、LM Studio，都提供了 OpenAI 兼容的接口。这意味着你不需要改业务代码，只需要把base_url指向本地服务，就能在数据不出内网的前提下使用开源模型。

这对很多企业场景非常重要：业务数据有合规要求，不能发送到外部模型服务；或者线上成本压力大，希望用开源模型承担一部分高并发低复杂度任务；再或者需要对推理性能和延迟做完全自主控制。兼容协议的价值在于，上层 API 调用逻辑不需要推倒重来，只切换模型服务地址即可。

6.2 使用 Ollama 启动本地模型

Ollama 是一个对新手非常友好的本地模型管理工具。先安装 Ollama，然后拉取模型：

ollama pull qwen2.5:7b

模型大小约 4 到 5 GB，具体取决于你选择的版本。拉取完成后启动服务：

ollama serve

默认情况下，Ollama 会在http://localhost:11434提供服务，其接口兼容 OpenAI 格式，路径为/v1。

现在写一个 Python 示例连接到 Ollama。文件路径：04_local_model_ollama.py

import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() # 本地 Ollama 服务地址 client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", # 本地服务不需要真实 Key，但接口要求有这个字段 ) response = client.chat.completions.create( model="qwen2.5:7b", messages=[ {"role": "user", "content": "用一句话解释什么是反向代理。"} ], ) print(response.choices[0].message.content)

注意这里不需要在.env中配置真实 OpenAI Key，因为请求根本没有发送到 OpenAI 服务器。api_key只是满足客户端参数要求，本地服务一般不校验。

如果 Ollama 服务没启动，你会看到类似Connection refused的报错。这时先确认服务是否在运行，以及11434端口是否被占用。

6.3 使用 vLLM 部署与调用

vLLM 更适合有一定 GPU 资源、追求高吞吐的团队。它支持 OpenAI 兼容的 API Server 模式。以常见的 Llama 3.1 8B 模型为例，启动命令大致如下：

vllm serve meta-llama/Llama-3.1-8B-Instruct --api-key token-abc123 --port 8000

其中--api-key是给服务设置一个自定义密钥，防止未授权访问。模型名称路径需要根据你实际使用的模型仓库调整，部分模型还需要提前登录 Hugging Face 或配置镜像源。

服务启动后，代码里这样切换：

from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="token-abc123", ) response = client.chat.completions.create( model="meta-llama/Llama-3.1-8B-Instruct", messages=[ {"role": "user", "content": "介绍一下什么是 RAG？"} ], max_tokens=500, ) print(response.choices[0].message.content)

vLLM 的版本和启动方式迭代很快，老版本可能使用python -m vllm.entrypoints.openai.api_server --model ...这种方式。如果你安装的是新版 vLLM，优先查看官方文档，以当前版本的 CLI 说明为准。

在 GPU 资源有限的个人电脑上，vLLM 可能跑不动大模型，优先推荐 Ollama。在团队服务器上，vLLM 则更适合承载在线推理服务。

6.4 在 LangChain 中统一调用

如果你的项目已经使用了 LangChain，可以通过ChatOpenAI组件切换不同的模型服务。文件路径：05_langchain_router.py

import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI load_dotenv() # 使用 OpenAI 官方服务 openai_llm = ChatOpenAI( model="gpt-4o-mini", api_key=os.getenv("OPENAI_API_KEY"), ) # 使用本地 Ollama 兼容服务 ollama_llm = ChatOpenAI( model="qwen2.5:7b", base_url="http://localhost:11434/v1", api_key="ollama", ) def chat(llm, question: str) -> str: response = llm.invoke(question) return response.content if __name__ == "__main__": print("OpenAI 回复:", chat(openai_llm, "用一句话解释微服务架构")) print("本地模型回复:", chat(ollama_llm, "用一句话解释微服务架构"))

这个例子演示了同一个ChatOpenAI类如何通过base_url在远程模型和本地模型之间切换。LangChain 的真正优势在于，你可以把不同模型包装成统一的调用入口，再配合检索、工具、记忆等组件搭建完整的 AI 应用，而不需要关心底层请求细节。

7. 常见问题与排查清单

在实际操作中，最容易踩坑的地方集中在认证、网络、限流、上下文长度和服务地址这些环节。下面整理一份排查速查表，遇到问题时可以对照处理。

除了表格里的内容，再强调一个高频问题：如果你改了.env文件但代码里读到的还是旧值，通常是因为 Python 进程在修改前就已经启动。解决方法是重启终端或重新运行脚本，确保load_dotenv()在进程启动早期执行。

另外，OpenAI API 的超时参数在生产环境值得专门配置。比如设置连接超时、读取超时和最大重试次数，避免某个请求长时间卡住业务线程。

from openai import OpenAI import os client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), timeout=30.0, max_retries=2, )

timeout控制单次请求的最大等待时间，max_retries控制在遇到网络错误时自动重试的次数。合理设置这两个参数，能明显提升服务稳定性。

8. 工程实践与安全建议

8.1 API Key 管理与最小权限

OpenAI API Key 本质上等同于资金账户的访问凭证，一旦泄露，可能被他人恶意调用造成损失。生产环境需要做到：

• Key 只存放在服务端环境变量或密钥管理服务中，禁止出现在前端代码和 Git 历史里。
• 为不同环境使用不同 Key，比如开发环境、测试环境、生产环境隔离。
• 定期轮换 Key，发现异常访问立即吊销并重新生成。
• 根据团队角色设置最小权限，限制 Key 可访问的模型和额度。

如果你用的是云厂商部署，优先使用平台的密钥管理服务，避免把明文 Key 写在配置文件里。

8.2 上下文管理与令牌消耗

聊天接口的费用和上下文长度直接相关。每次请求都会把messages列表全部发送给模型，消息越长，token 消耗越大，响应速度也会变慢。实际项目中应做到：

• 历史消息按窗口保留，超过阈值的旧消息不再发送。
• 对长对话做定期摘要，用摘要替代原始历史。
• 检索增强生成（RAG）场景里，只把与当前问题相关的检索结果拼入 Prompt。
• 合理设置max_tokens，避免模型生成长篇大论导致成本失控。

上下文管理不是简单地把 Prompt 写长，而是要让“信息密度”和“相关性”达到平衡。这决定了你的 AI 应用在真实业务中的成本和效果。

8.3 限流、退避与缓存

在线服务通常会有限流策略。客户端代码要处理可能的 429 错误，使用指数退避算法控制重试频率。高并发场景下，可以为重复请求增加缓存，比如相同用户输入在短时间内返回缓存结果，避免重复调用模型接口。

如果团队里同时有远程模型和本地模型，可以通过流量路由把简单任务引流到本地模型，只有复杂推理才调用远程高能力模型，这样能够显著降低成本。

8.4 结果审查与安全边界

AI 生成的代码本质上仍然是“建议代码”，使用前必须经过人工审查。以下几点需要特别注意：

• 模型生成的 SQL、删除命令、权限变更等高风险操作，必须经过确认和测试。
• 不要直接把模型输出拼接到系统命令中，防止提示注入导致命令执行。
• 涉及用户隐私和敏感数据时，不能未经脱敏就发送给外部模型服务。
• 生成内容如果在生产环境使用，需要建立对应的测试用例和回归验证机制。

无论使用 OpenAI 官方服务还是本地模型，都需要把 AI 能力当成一个普通组件来对待：有鉴权、有日志、有监控、有降级方案。

9. 总结与下一步学习路线

“加入 OpenAI 前后对比照”引热议的背后，是整个开发行业对 AI 原生工作流的关注度到达了临界点。这篇文章带你走通了最核心的一条路径：先学会用代码调用 OpenAI API，再熟悉 Codex CLI 这类 Agent 工具，接着通过兼容协议接入本地模型，最后用 LangChain 统一编排。

如果你是从零开始，建议按照这个顺序学习：先运行 4.2 的基础对话代码，确保接口能通；然后尝试修改messages和temperature，感受不同参数对结果的影响；接着把 5.3 的 Codex 命令在自己的项目里跑一遍，体会多步骤任务是怎么被自动处理掉的；等你对模型能力有体感后，再考虑接入 Ollama 或 vLLM，思考哪些业务场景适合本地部署，哪些场景需要远程高能力模型。

下一步可以继续研究的方向包括：提示词工程中的少样本设计和输出约束；RAG 的完整落地流程，包括文档切分、向量化和检索重排；Agent 的多工具协同模式，让模型在信息检索、代码执行、外部服务调用之间自主决策；以及对开源模型的评测和微调，找到成本和效果最优的组合。

技术在快速演进，工具链可能半年就更新一轮，但底层的能力模型是通用的：理解上下文、管理风险、设计交互边界。把这套能力打牢，无论接下来出现新的 API 还是新的 Agent 框架，你都能快速上手。如果这篇教程帮你跑通了第一个程序，或者解决了安装配置时的某个报错，不妨收藏备用，也欢迎在评论区留下你在实际环境中遇到的问题。