企业官网建设流程全解析

1. 项目概述：为什么一个“零基础Python AI Coding教程”要绑定Trae、Gitee和Ubuntu三件套？

你点开这个标题，第一反应可能是：“Trae？没听过。”“Gitee不是写Java的才用吗？”“Ubuntu跑AI？我Windows上装个PyCharm不香吗？”——这恰恰是我要先说清楚的。这不是又一个“Python从print开始”的入门课，而是一条专为中文开发者设计的、绕过海外云服务依赖、本地可控、可复现、能真正落地AI编码实践的最小可行路径。核心关键词——Python、AI、Coding、Trae、Gitee、Ubuntu、Windows——每一个都不是随意堆砌：Python是语言底座，AI是目标场景，Coding是行为本质，Trae是当前国内少有的、真正把AI编程体验做进IDE内核的轻量级工具（注意，不是插件，是原生集成），Gitee是国产代码托管+CI/CD+Pages三位一体的闭环平台，Ubuntu是绝大多数AI模型推理、Docker容器化部署、以及Trae底层运行环境的事实标准载体，而Windows，则是你此刻正用着的开发主战场。这组组合的本质，是解决一个现实矛盾：想学AI编程，但不想被OpenAI API调用限制卡脖子，不想被GitHub私有仓库收费劝退，不想在WSL里反复折腾CUDA驱动，更不想花三天配环境却连第一个pip install都报错。我带过37个零基础转行的学员，其中29人卡在“环境装好了，但不知道下一步该敲什么命令”，剩下8人卡在“代码跑通了，但换台电脑就废”。这个教程，就是把那29人的坑，一次性填平。

它适合谁？第一类，完全没写过代码、但听说“AI能写代码”后跃跃欲试的职场人，比如HR、运营、财务，你们不需要懂神经网络，但需要知道怎么让AI帮你自动生成周报分析脚本、自动清洗Excel数据、甚至一键生成PPT大纲；第二类，有Python基础、会写爬虫和简单Web应用，但对AI模型调用、向量数据库、RAG流程毫无概念的开发者，你们缺的不是语法，而是把AI能力“拧进”日常开发流的那根螺丝；第三类，技术管理者或教学者，需要一套不依赖境外服务、可内部部署、能快速验证AI编程价值的沙盒方案。它不承诺让你三个月成为AI算法工程师，但它能保证：48小时内，你在自己Windows电脑上，用Trae写一个能联网搜索、读取本地PDF、并生成结构化摘要的Python脚本，并通过Gitee自动部署到Ubuntu服务器上持续运行。这不是Demo，是生产就绪的最小原型。下面所有内容，都围绕这个目标展开，没有一句废话，没有一个步骤是“为了教而教”。

2. 整体架构设计与核心选型逻辑：为什么是Trae而不是VS Code + Cursor？为什么是Gitee而不是GitHub？为什么Ubuntu必须上？

2.1 Trae：国产AI IDE的“去插件化”设计哲学

先破除一个误区：Trae不是“又一个AI插件”。市面上90%的AI编程工具，本质是给现有IDE（如VS Code）加一层对话框外壳，背后调用的是远程大模型API。这带来三个硬伤：响应延迟不可控（尤其在国内）、上下文长度受限（通常<8K token）、代码安全无法保障（你的业务逻辑全传到别人服务器）。Trae的突破点在于“本地化智能体编排”。它内置了一个轻量级的本地推理引擎（基于GGUF量化格式），能直接加载Qwen2.5-Coder-1.5B、DeepSeek-Coder-V2-Lite等开源小模型，在你本地CPU上完成变量推断、函数补全、错误诊断。更重要的是，它的“AI Agent”不是单点功能，而是一套可配置的工作流：你可以定义一个Agent专门处理“从Excel读取销售数据→清洗异常值→按区域聚合→生成Markdown报告”，另一个Agent负责“监听Gitee Webhook→拉取新提交→运行pytest→将覆盖率报告推送到企业微信”。这种设计，让AI从“打字员”升级为“自动化协作者”。我实测过，在一台i5-1135G7 + 16GB内存的笔记本上，Trae加载Qwen2.5-Coder-1.5B后，函数补全平均响应时间是320ms，比调用云端API快4.7倍，且全程离线。选择Trae，核心逻辑就一条：把AI能力锚定在本地开发机上，确保每一次代码生成、每一次调试建议，都在你的掌控之中，不经过任何第三方服务器。这不是技术洁癖，而是企业级开发的基本安全底线。

2.2 Gitee：不止是代码托管，更是国产AI工作流的“中枢神经”

很多人把Gitee等同于“国内版GitHub”，这是巨大误解。Gitee Pages、Gitee Actions、Gitee Package、Gitee CI，这四者组合起来，构成了一套完整的、无需翻墙即可使用的DevOps闭环。举个具体例子：你想让AI生成的代码自动测试、自动部署、自动生成文档。在GitHub上，你需要配置Actions YAML，调用第三方Docker Hub镜像，再手动配置Pages域名；在Gitee上，你只需在仓库设置里勾选“启用Gitee Pages”，选择“从master分支/docs目录构建”，然后在.gitee/workflow/ci.yml里写三行：

- name: Run pytest run: pip install -r requirements.txt && pytest tests/ - name: Build docs run: sphinx-build -b html docs/ docs/_build/html - name: Deploy to Pages uses: gitee-pages-action@v1

Gitee会自动拉取代码、启动Ubuntu 22.04容器、执行命令、将docs/_build/html推送到Pages站点。整个过程，所有日志、产物、环境变量，全部在Gitee后台可查，无需配置SSH密钥、无需管理个人Token。更关键的是，Gitee Actions的免费额度远超GitHub：每月2000分钟构建时长，且支持GPU节点（需申请）。这意味着，你可以把Trae生成的、需要GPU加速的模型微调脚本，直接丢进Gitee Actions里跑，结果自动回传。选择Gitee，核心逻辑是：用一套平台、一个账号、一次登录，打通从AI代码生成（Trae）→版本控制（Git）→自动化测试（CI）→文档发布（Pages）→私有包管理（Package）的全链路，彻底摆脱对境外生态的路径依赖。这不是情怀，是降低团队协作成本的硬需求。

2.3 Ubuntu：AI工程化的“事实标准操作系统”

为什么不能直接在Windows上跑通所有环节？因为AI工程的底层依赖，天然偏向Linux。CUDA驱动、NVIDIA Container Toolkit、Docker Desktop的WSL2后端、PyTorch的源码编译、Hugging Face Transformers的C++扩展……这些组件的官方文档、社区支持、预编译二进制包，95%以上默认以Ubuntu LTS（20.04/22.04）为基准。我曾尝试在纯Windows环境下部署一个基于Llama-3-8B的RAG服务，光是解决llama-cpp-python的编译问题就花了17小时，最终发现是MSVC版本与CUDA Toolkit的ABI不兼容。而在Ubuntu 22.04上，一行pip install llama-cpp-python --no-cache-dir --force-reinstall，配合CMAKE_ARGS="-DLLAMA_CUBLAS=on"环境变量，12分钟搞定。Trae的官方Docker镜像、Gitee Actions的默认运行环境、绝大多数AI模型的Dockerfile，全部基于Ubuntu。所以，我们的架构不是“Windows开发，Ubuntu部署”，而是“Windows作为开发终端，Ubuntu作为可信执行环境”。具体实现上，我们采用WSL2（Windows Subsystem for Linux），而非VMware或VirtualBox。原因很实在：WSL2的I/O性能接近原生，内存动态分配，与Windows文件系统无缝互通（/mnt/c/Users/xxx），且能直接调用Windows的GPU（需安装NVIDIA CUDA on WSL驱动）。这意味着，你在Windows的VS Code里编辑代码，Trae在WSL2的Ubuntu里运行模型，Gitee Actions在云端Ubuntu里执行CI，三者数据同源、环境一致、行为可复现。选择Ubuntu，核心逻辑是：承认技术生态的客观规律，不硬刚，用最省力的方式，把AI工程的复杂性，收敛到一个被全球开发者充分验证的操作系统上。

3. 核心细节解析与实操要点：Trae安装、Gitee仓库初始化、Ubuntu环境搭建的避坑指南

3.1 Trae安装：绕过官网下载陷阱，直取稳定版二进制包

Trae官网（trae.cn）目前提供两种安装方式：网页版（Web App）和桌面版（Desktop App）。新手最容易踩的坑，就是直接点击官网首页的“立即下载”按钮。那个按钮默认指向的是trae-solo-v0.8.2-beta-win-x64.exe，这是一个测试版（beta），存在两个致命问题：一是对Windows 11 22H2之后的系统兼容性差，安装后图标不显示；二是内置的模型下载器会因DNS污染，卡死在downloading qwen2.5-coder-1.5b.Q4_K_M.gguf这一步，进度条永远停在99%。正确做法是放弃官网下载页，直接访问Trae的GitHub Release页面（https://github.com/trae-ai/trae/releases），找到最新稳定版（Stable）的Assets列表，下载trae-desktop-v0.7.5-win-x64-setup.exe（注意版本号是v0.7.5，不是v0.8.x）。安装时，务必取消勾选“Add Trae to PATH”和“Run Trae after installation”两个选项。前者会导致Windows环境变量混乱，与已有的Python环境冲突；后者会强制启动一个未配置好的实例，浪费你第一次宝贵的调试时间。安装完成后，不要急着双击图标，先打开Windows PowerShell（以管理员身份），执行：

# 创建Trae专用配置目录 mkdir "$env:USERPROFILE\.trae" # 复制一份干净的配置模板 curl -o "$env:USERPROFILE\.trae\config.yaml" https://raw.githubusercontent.com/trae-ai/trae/main/config.example.yaml

这一步至关重要。config.yaml是Trae的“大脑”，它决定了AI Agent用哪个模型、从哪里加载知识库、如何连接外部API。默认配置是空的，Trae会用内置的fallback模型，效果极差。我们后续会基于这个模板，填入本地模型路径和Gitee Token。经验之谈：Trae的首次启动，一定要在PowerShell里用命令行方式启动，这样能看到实时日志。进入安装目录（通常是C:\Program Files\Trae），执行：

.\trae.exe --config "$env:USERPROFILE\.trae\config.yaml" --log-level debug

如果看到INFO trae::app: Starting Trae server on http://127.0.0.1:3000，说明核心服务已启动。此时再用浏览器打开http://127.0.0.1:3000，才能看到一个真正可用的界面。很多新手卡在这里，就是因为双击图标启动，看不到任何错误提示，以为软件坏了。

3.2 Gitee仓库初始化：创建“AI Coding”专属组织，配置SSH密钥与Token

Gitee的坑，不在功能，而在权限设计。如果你用个人账号创建仓库，后续想让Trae自动推送代码、让Gitee Actions自动拉取，会陷入无限循环的权限认证。正确姿势是：创建一个独立的“机器人账号”（Bot Account），并将其加入一个新创建的组织（Organization）。具体步骤：首先，注册一个新邮箱（如trae-bot@yourcompany.com），用它注册Gitee账号。登录后，点击右上角头像 → “我的组织” → “创建组织”，组织名就叫ai-coding。创建成功后，把你自己的主账号（拥有真实姓名的那个）添加为该组织的“Owner”。这样，主账号拥有所有权限，而机器人账号只用于自动化任务，权限可控。接下来是密钥配置。Trae和Gitee Actions都需要SSH密钥来免密操作。在Windows上，打开PowerShell，执行：

# 生成ED25519密钥对（比RSA更安全、更快） ssh-keygen -t ed25519 -C "trae-bot@yourcompany.com" -f "$env:USERPROFILE\.ssh\gitee-trae-bot" # 启动ssh-agent并添加密钥 Get-Service ssh-agent | Set-Service -StartupType Automatic Start-Service ssh-agent ssh-add "$env:USERPROFILE\.ssh\gitee-trae-bot"

然后，复制公钥内容：

Get-Content "$env:USERPROFILE\.ssh\gitee-trae-bot.pub" | Set-Clipboard

粘贴到Gitee的“设置” → “SSH公钥”里，标题写Trae-Bot-Windows-WSL2。但这还不够。Gitee Actions需要一个Personal Access Token（PAT）来触发工作流。在Gitee上，进入“设置” → “私人令牌” → “生成新令牌”，名称填trae-ci-token，勾选repo（读写仓库）、workflow（管理工作流）、packages（读写包）三个权限，其他全不勾。生成后，立刻复制Token字符串，并存到一个安全的地方（如Windows凭据管理器），因为Gitee只显示一次！这个Token，后续要填入Trae的config.yaml和Gitee仓库的Secrets里。经验之谈：Gitee的Token权限粒度很粗，repo权限意味着它可以读写你组织下所有仓库。所以，务必为这个Token创建一个专用的、权限最小化的机器人账号，而不是用你的主账号生成。这是保障代码安全的第一道防火墙。

3.3 Ubuntu环境搭建：WSL2安装、CUDA驱动配置、Docker与Trae服务容器化

WSL2的安装，微软官方文档写得足够清楚，但有两个隐藏雷区。第一，必须关闭Windows的“虚拟机平台”（Virtual Machine Platform）和“Windows Subsystem for Linux”两个可选功能，然后再重新启用，否则后续安装Ubuntu会失败。第二，安装完Ubuntu后，不要急着sudo apt update。因为Ubuntu官方源在国内访问极慢，直接更新会卡住。正确做法是，先修改/etc/apt/sources.list，替换为清华源：

# 备份原文件 sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # 替换为清华源（针对Ubuntu 22.04） sudo sed -i 's/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list sudo sed -i 's/security.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list

然后执行sudo apt update && sudo apt upgrade -y，速度会提升10倍。接下来是CUDA。NVIDIA官方明确支持WSL2的CUDA版本是11.8及以上。在Windows上，先去NVIDIA官网下载并安装CUDA Toolkit 11.8（注意，不是12.x，WSL2对12.x支持不稳定）。安装完成后，在WSL2的Ubuntu里，执行：

# 验证CUDA是否识别 nvidia-smi # 如果显示“NVIDIA-SMI has failed”，说明驱动没装好，回到Windows重装CUDA Toolkit # 安装CUDA运行时库 sudo apt install -y nvidia-cuda-toolkit # 验证nvcc nvcc --version

最后是Docker。Gitee Actions和Trae的生产部署，都依赖Docker容器。在WSL2里安装Docker，不能用apt install docker.io（那是旧版），必须用官方脚本：

# 卸载旧版 sudo apt remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt install -y ca-certificates curl gnupg lsb-release # 添加Docker官方GPG密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加Docker仓库 echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装Docker Engine sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 将当前用户加入docker组，避免每次都要sudo sudo usermod -aG docker $USER # 重启WSL2使组生效 exit

然后在Windows PowerShell里执行wsl --shutdown，再重新打开Ubuntu终端。此时，docker run hello-world应该能成功输出。经验之谈：Trae本身可以不依赖Docker运行，但为了环境一致性，我强烈建议把Trae的服务也容器化。我们后续会构建一个Dockerfile，把Trae二进制、本地模型、config.yaml全部打包进去，用docker run -p 3000:3000 -v /path/to/models:/models -v /path/to/config:/config trae-ai:latest一键启动。这样，无论是在你的Windows WSL2里，还是在Gitee Actions的Ubuntu容器里，运行的都是完全相同的环境。这是保证“所见即所得”的终极方案。

4. 实操过程与核心环节实现：从Trae写第一个AI脚本，到Gitee自动部署Ubuntu服务

4.1 Trae中创建第一个AI Agent：自动解析会议纪要并生成待办清单

现在，我们进入真正的编码环节。打开Trae（通过PowerShell命令行启动），在左侧导航栏点击“Agents”，然后点击右上角的“+ New Agent”。Agent名称填meeting-minutes-parser，描述写“Parse meeting transcript PDF and extract action items”。关键在“Prompt Template”部分。这里不是让你写一段模糊的自然语言指令，而是要构造一个结构化、可验证的提示词（Prompt）。我推荐使用“Role-Task-Format-Example”四段式模板：

Role: You are a senior project manager at a tech company, specialized in agile workflow. Task: Extract all action items from the provided meeting transcript. An action item must have: (1) an owner (a person's name or role), (2) a clear verb (e.g., "create", "review", "send"), (3) a specific deliverable (e.g., "API spec", "test report"), and (4) a deadline (e.g., "by Friday", "next sprint"). Format: Return ONLY a valid JSON array. Each object must have keys: "owner", "verb", "deliverable", "deadline". Do NOT include any other text, markdown, or explanation. Example: [{"owner": "Alice", "verb": "review", "deliverable": "UI mockups", "deadline": "by EOD Thursday"}]

保存后，点击“Test Agent”，在输入框里粘贴一段真实的会议纪要文本（可以从公司邮件里复制一段）。如果返回的是格式正确的JSON，说明Agent工作正常。接下来，我们要把这个Agent“变成代码”。点击Agent右侧的“Code”按钮，Trae会自动生成一个Python函数：

def parse_meeting_minutes(transcript: str) -> list[dict]: """ Parse meeting transcript and extract action items. Args: transcript: The raw text of the meeting minutes. Returns: A list of action items, each as a dict with keys: owner, verb, deliverable, deadline. """ # This is a placeholder. In real use, you would call the Trae Agent API here. pass

这个pass就是我们要填的坑。Trae提供了本地HTTP API，地址是http://127.0.0.1:3000/api/agents/meeting-minutes-parser/run。我们需要用requests库调用它。在Trae的“Workspace”里，新建一个Python文件meeting_parser.py，写入：

import requests import json def parse_meeting_minutes(transcript: str) -> list[dict]: """Call the Trae Agent to parse meeting minutes.""" url = "http://127.0.0.1:3000/api/agents/meeting-minutes-parser/run" payload = {"input": transcript} headers = {"Content-Type": "application/json"} try: response = requests.post(url, json=payload, headers=headers, timeout=60) response.raise_for_status() result = response.json() # Trae API返回的是{"output": "..."}，我们需要解析output字段 return json.loads(result["output"]) except Exception as e: print(f"Error calling Trae Agent: {e}") return [] # 测试代码 if __name__ == "__main__": sample_transcript = """ Alice: We need to finalize the API spec by Friday. Bob: I'll review the UI mockups and send feedback. Charlie: Let's schedule the security audit for next sprint. """ items = parse_meeting_minutes(sample_transcript) print(json.dumps(items, indent=2))

保存后，点击右上角的“Run”按钮。如果终端输出了格式化的JSON，恭喜，你的第一个AI编码闭环完成了。经验之谈：Trae的Agent API默认是同步阻塞的，超时时间是30秒。对于复杂的PDF解析任务，30秒可能不够。你可以在config.yaml里增加agent_timeout: 120来延长。另外，requests库在WSL2里默认不信任Windows的证书，如果遇到SSL错误，需要在代码开头加上：

import ssl ssl._create_default_https_context = ssl._create_unverified_context

4.2 Gitee仓库创建与代码推送：配置.gitignore、.gitee/workflow、自动部署脚本

现在，把meeting_parser.py推送到Gitee。在WSL2的Ubuntu终端里，进入你的项目目录，执行：

git init git add . git commit -m "feat: add first AI agent for meeting parsing"

然后，去Gitee的ai-coding组织下，创建一个新仓库，名字叫ai-meeting-parser，务必勾选“初始化README.md”和“添加.gitignore”（选择Python）。创建后，复制仓库的SSH地址（形如git@gitee.com:ai-coding/ai-meeting-parser.git），执行：

git remote add origin git@gitee.com:ai-coding/ai-meeting-parser.git git branch -M main git push -u origin main

推送成功后，去Gitee仓库页面，点击“Actions” → “新建工作流”，选择“空白工作流”，命名为ci-cd.yml。这个YAML文件，就是你的自动化流水线。完整内容如下：

name: CI/CD Pipeline for AI Meeting Parser on: push: branches: [ main ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-22.04 steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.10' - name: Install dependencies run: | pip install -r requirements.txt - name: Run tests run: python -m pytest tests/ -v deploy-to-ubuntu: needs: test runs-on: ubuntu-22.04 steps: - uses: actions/checkout@v3 - name: Set up Docker uses: docker-practice/actions-setup-docker@v1 - name: Build and push Docker image run: | echo "${{ secrets.GITEE_TOKEN }}" | docker login gitee.com -u ${{ secrets.GITEE_USERNAME }} --password-stdin docker build -t gitee.com/ai-coding/ai-meeting-parser:latest . docker push gitee.com/ai-coding/ai-meeting-parser:latest - name: Deploy to Ubuntu server uses: appleboy/scp-action@master with: host: ${{ secrets.UBUNTU_HOST }} username: ${{ secrets.UBUNTU_USER }} key: ${{ secrets.UBUNTU_SSH_KEY }} source: "docker-compose.yml" target: "/home/${{ secrets.UBUNTU_USER }}/ai-meeting-parser/" - name: Run docker-compose uses: appleboy/ssh-action@master with: host: ${{ secrets.UBUNTU_HOST }} username: ${{ secrets.UBUNTU_USER }} key: ${{ secrets.UBUNTU_SSH_KEY }} script: | cd /home/${{ secrets.UBUNTU_USER }}/ai-meeting-parser docker-compose down docker-compose up -d

这个YAML做了三件事：第一，testjob在Gitee的Ubuntu环境里运行单元测试；第二，deploy-to-ubuntujob构建Docker镜像并推送到Gitee Package Registry；第三，用SCP和SSH，把docker-compose.yml文件传到你的Ubuntu服务器上，并执行docker-compose up -d启动服务。注意，secrets里的UBUNTU_HOST、UBUNTU_USER、UBUNTU_SSH_KEY，需要你提前在Gitee仓库的“Settings” → “Secrets and variables” → “Actions”里配置。UBUNTU_SSH_KEY的内容，就是你之前生成的gitee-trae-bot私钥的全文（记得用cat ~/.ssh/gitee-trae-bot | tr '\n' '\r'转换成一行）。经验之谈：Gitee Actions的runs-on只能指定ubuntu-20.04或ubuntu-22.04，不能指定windows-latest。所以，所有测试和构建，都必须在Linux环境下完成。这也是我们坚持用Ubuntu作为标准环境的根本原因——保证本地开发、CI构建、线上部署，三者环境100%一致。

4.3 Ubuntu服务器上的Docker Compose部署：Trae服务容器化与反向代理配置

最后一步，是在你的Ubuntu服务器上，让这个AI服务真正跑起来。首先，确保服务器已安装Docker和Docker Compose。然后，创建项目目录：

mkdir -p ~/ai-meeting-parser/{data,logs} cd ~/ai-meeting-parser

创建docker-compose.yml：

version: '3.8' services: trae-ai: image: gitee.com/ai-coding/ai-meeting-parser:latest container_name: trae-ai restart: unless-stopped ports: - "3000:3000" volumes: - ./data:/app/data - ./logs:/app/logs environment: - TRAE_CONFIG_PATH=/config/config.yaml - TRAE_MODEL_PATH=/models/qwen2.5-coder-1.5b.Q4_K_M.gguf # 挂载本地模型和配置 volumes: - /path/to/your/models:/models - /path/to/your/config.yaml:/config/config.yaml nginx: image: nginx:alpine container_name: nginx-proxy restart: unless-stopped ports: - "80:80" - "443:443" volumes: - ./nginx.conf:/etc/nginx/nginx.conf - ./ssl:/etc/nginx/ssl depends_on: - trae-ai

这个Compose文件定义了两个服务：trae-ai是你的核心AI服务，nginx是反向代理，用来处理HTTPS和域名。nginx.conf的内容很简单：

events { worker_connections 1024; } http { upstream trae_backend { server trae-ai:3000; } server { listen 80; server_name your-domain.com; location / { proxy_pass http://trae_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } }

把your-domain.com换成你实际的域名。如果你没有域名，可以用localhost，或者申请一个免费的xxx.gitee.io二级域名（通过Gitee Pages）。然后，执行：

docker-compose up -d

稍等片刻，访问http://your-domain.com，你应该能看到Trae的Web界面。此时，你的AI服务已经脱离了Windows开发机，完全运行在Ubuntu服务器上，通过Gitee Actions自动构建、自动部署、自动更新。经验之谈：Trae的Docker镜像，官方并未提供。我们必须自己构建。在项目根目录下，创建Dockerfile：

FROM python:3.10-slim WORKDIR /app # 复制依赖 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 复制应用代码 COPY . . # 复制Trae二进制（需提前下载） COPY trae-linux-amd64 /usr/local/bin/trae # 暴露端口 EXPOSE 3000 CMD ["trae", "--config", "/config/config.yaml", "--port", "3000"]

requirements.txt里只需要写requests和pydantic。构建命令是docker build -t gitee.com/ai-coding/ai-meeting-parser:latest .。这个镜像，就是你交付给生产环境的“软件包”，它包含了所有依赖、所有配置、所有模型，是一个真正意义上的、可审计、可回滚、可迁移的AI应用单元。

5. 常见问题与排查技巧实录：从“Trae打不开”到“Gitee Actions卡在Cloning”

5.1 Trae常见问题速查表

5.2 Gitee Actions故障排查三板斧

Gitee Actions的问题，90%都出在环境隔离和权限上。第一板斧：看日志，不猜。每次Action失败，Gitee都会生成详细的日志。点击失败的Job，展开每一步骤，重点看Run commands和Run setup-python这两步的日志。如果setup-python失败，大概率是网络问题，把actions/setup-python@v4换成actions/setup-python@v3（v4依赖GitHub的CDN，国内不稳定）。第二板斧：用run: ls -la探路。在YAML里任意一步骤前，加一行run: ls -la，看看当前工作目录下有什么文件。很多问题是因为git checkout没拉到代码，或者requirements.txt路径写错了。第三板斧：本地模拟。Gitee Actions的ubuntu-22.04环境，其实就是一台干净的Ubuntu 22.04虚拟机。你可以在WSL2里，用docker run -it --rm ubuntu:22.04 /bin/bash启动一个临时容器，然后手动执行YAML里的每一条命令，看哪一步会失败。这比在Gitee上反复提交、等待、失败、再提交，效率高10倍。经验之谈：Gitee Actions的secrets，在Pull Request来自Fork仓库时，默认是不可见的（出于安全考虑）。这意味着，如果你让同事fork你的仓库并提PR，他的PR将无法访问UBUNTU_SSH_KEY，导致部署失败。解决方案是，在YAML里加一个条件判断：

- name: Deploy to Ubuntu server if: github.event_name == 'push' && github.repository == 'ai-coding/ai-meeting-parser' uses: appleboy/scp-action@master with: # ... rest of config

这样，只有主仓库的push事件才会触发部署，Fork的PR只会跑测试，既安全又高效。

5.3 Ubuntu服务器部署终极检查清单

当你的服务在Ubuntu上跑不起来，按这个清单逐项检查，99%的问题都能定位：

1. Docker服务状态：sudo systemctl status docker，确保是active (running)。如果不是，执行sudo systemctl start docker。
2. Docker镜像是否存在：docker images | grep ai-meeting-parser，确认镜像已拉取。如果没有，执行`docker pull