企业官网建设流程全解析

对于很多刚接触本地模型的开发者来说，最大的疑问往往不是“模型怎么部署”，而是“模型跑起来之后，怎么把它真正用起来”。本文从一个非常具体的场景出发：从 GitHub Issue 里选取一个真实需求，用本地运行的开放权重模型辅助完成功能拆解、代码生成，最终构建出一个可运行的 Web 应用，再用 UI 自动化录制生成脚本的方式对结果做验证。整个过程不依赖外部付费模型服务，适合想探索本地模型落地流程的开发者参考。

1. open-weight model 与 GitHub Issue 组合的落地链路

1.1 什么是 open-weight model

open-weight model 指“开放权重模型”，也就是模型训练完毕后的权重文件公开可下载。它和普通开源软件有一个关键区别：开放权重并不意味着训练数据、训练代码、推理代码全部开放，不同模型对应的许可证也不同。

常见的 Qwen 系列、Llama 系列、Mistral 系列等都属于开放权重模型。这类模型的优势在于：

• 可以部署在本地服务器或个人电脑上，数据不需要上传到第三方平台。
• 推理过程可控，适合对数据隐私要求较高的场景。
• 可以针对具体任务做微调或提示词优化。
• 离线也能使用，网络波动不影响开发调试。

当然，开放权重模型也有局限。同等参数规模下，它的能力通常弱于更大的在线商业模型，代码生成质量不稳定，上下文窗口也有限。因此，使用本地模型时需要调整预期，把它当作一个“能理解自然语言并产出初稿的辅助工具”，而不是一个输出即正确的生成器。

1.2 GitHub Issue 为什么适合作为需求来源

GitHub Issue 是软件开发过程中最常见的需求载体之一。它通常包含用户遇到什么问题、期望什么功能、复现步骤、环境信息等。这些内容有两个特点：

第一，它是真实需求。相比自己虚构的练习项目，Issue 里有明确的业务背景和痛点，可以让模型生成的结果更贴近实际。

第二，它是结构化的自然语言。Issue 的标题、描述、评论、标签，天然就是一种“需求说明书”。把 Issue 内容交给本地模型，让模型输出功能清单、接口设计、页面结构，是成本最低的 AI 辅助编程方式。

另外，GitHub 提供了公开 API，可以按仓库读取 Issue 列表。对公开仓库的访问通常不需要认证，请求也很简单。这意味着整个流程可以非常自动化：读取 Issue、拆解需求、生成代码、运行验证。

1.3 从 Issue 到 Web 应用的完整链路

可以把整条落地链路拆成六步：

GitHub Issue ↓ 需求拆解（人工 + 本地模型） ↓ 设计技术方案与技术栈 ↓ 生成前后端代码（本地模型 + 人工整理） ↓ 组装并运行本地 Web 应用 ↓ UI 自动化录制脚本验证

本文会逐步走通这条链路。你不需要一次跑通所有环节，可以先根据现有环境，把每一步对应的工具和代码准备好。

2. 环境准备与本地模型部署

2.1 本地环境建议

本文示例主要围绕 Python Web 开发和前端页面，涉及工具如下：

• 操作系统：Windows / macOS / Linux 均可，推荐 64 位系统。
• 内存：建议 16GB 以上，如果计划运行 13B 以上参数的模型，建议 32GB。
• 磁盘：模型文件通常从 4GB 到 20GB 不等，预留 20GB 以上空间更稳妥。
• Python：3.10 或更高版本。
• Git：用于拉取代码和与 GitHub 交互。

如果你的电脑配置不够，可以优先选择量化后的小参数模型，例如 3B、7B 级别的模型。量化技术会压缩模型体积，推理时内存占用也会明显下降。

2.2 选择适合本地运行的模型

对于“阅读 Issue 并生成代码”这类任务，建议选择代码能力相对较好的模型。目前社区里使用较多的有：

• Qwen 系列：中文支持好，代码能力稳定，社区资料多。
• Llama 系列：英文能力强，插件生态丰富。
• Mistral 系列：体积相对紧凑，推理速度快。

版本选择方面，7B 到 14B 级别的量化模型在消费级硬件上体验较好。本文示例使用 Ollama 工具来管理本地模型，具体模型名以你本地ollama list的输出为准。

2.3 用 Ollama 快速部署本地模型

Ollama 是一个开源工具，可以简化本地模型的下载、启动和调用。安装完成后，在命令行执行：

ollama pull qwen2.5:7b

这个命令会从模型仓库下载对应的模型文件。关于是否再加积，当然。下载时间取决于网络状况，耐心等待即可。

查看本地模型是否就绪：

ollama list

启动模型服务。Ollama 在 Windows 和 macOS 上通常安装后会自动常驻，Linux 环境下可能需要手动执行：

ollama serve

服务默认监听11434端口。验证服务是否正常，可以执行：

curl http://localhost:11434/api/generate \ -d '{"model":"qwen2.5:7b","prompt":"你好，请用一句话介绍自己","stream":false}'

正常响应会返回一段 JSON，其中response字段是模型生成的文本。到这里，本地模型的基础服务已经就绪。

3. 从 GitHub Issue 提取需求并拆解

3.1 读取 GitHub Issue

先看如何通过 GitHub API 获取 Issue。下面以 GitHub 官方的示例仓库octocat/Hello-World为例，读取公开的 Issue 列表。

fetch_issue.py：

import os import requests repo = "octocat/Hello-World" url = f"https://api.github.com/repos/{repo}/issues" headers = {} token = os.environ.get("GITHUB_TOKEN") if token: headers["Authorization"] = f"token {token}" resp = requests.get(url, headers=headers, timeout=30) if resp.status_code == 200: for issue in resp.json(): # GitHub 的 issues 接口会同时返回 pull request，这里排除 if "pull_request" in issue: continue print("编号:", issue["number"]) print("标题:", issue["title"]) print("内容:", issue.get("body", "")[:500]) print("---") else: print("请求失败，HTTP", resp.status_code) print(resp.text)

需要注意几个地方：

• 对公开仓库的 Issue 读取可以不携带 token，但请求频率有限制。
• 如果需要更高请求配额，可以使用 GitHub Token，但 token 必须通过环境变量注入，不要写死在代码里，更不要提交到 Git 仓库。
• 从安全角度，token 的权限应遵循最小化原则，只用只读权限即可。

3.2 如何把一个 Issue 拆解成开发任务

为了演示方便，这里给出一份结构化的 Issue 模板。本文后续生成的 Web 应用，就围绕这个假设性需求展开：

标题：增加一个本地待办事项管理页面 描述： 需要一个简单的待办事项管理 Web 应用，支持以下功能： 1. 用户可以新增待办事项。 2. 用户可以勾选完成待办事项。 3. 用户可以删除待办事项。 4. 数据保存在本地 SQLite 数据库中。 5. 提供 REST API，前端通过 API 获取数据。 验收标准： - 新增内容后刷新页面，数据仍然存在。 - 标记完成后，状态能够持久化。 - 删除操作后有成功提示。 - 页面无需登录即可使用。

这种描述在真实仓库中非常常见。我们可以把需求拆成几个维度：

• 功能点：新增、完成、删除、列表展示、持久化。
• 数据模型：待办事项的 id、标题、完成状态、创建时间。
• 接口设计：REST API 的路径和请求方法。
• 页面结构：输入框、按钮、列表区域。
• 验收标准：刷新后数据不丢失、状态可持久化。

拆解的结果可以用表格整理，也可以交给本地模型输出成结构化的 JSON，方便后续程序处理。

3.3 使用本地模型辅助拆解

在本地建一个scripts目录，把 Issue 文本保存为issue.md，然后编写下面这个脚本，让本地模型输出 JSON 格式的需求拆解结果。

# 文件路径：scripts/analyze_issue.py import json import requests issue_text = open("issue.md", encoding="utf-8").read() prompt = f""" 请把下面的 GitHub Issue 拆解成开发任务，输出 JSON。 字段包括：features, api, data_model, pages, acceptance_criteria。 只输出 JSON，不要输出额外解释。 Issue: {issue_text} """ resp = requests.post( "http://localhost:11434/api/generate", json={ "model": "qwen2.5:7b", # 以本地实际模型名为准 "prompt": prompt, "stream": False }, timeout=120 ) data = resp.json() print(data["response"])

本地模型的输出不一定总是合法 JSON，可能需要人工修正。这是正常现象，可以在提示词里强调“只输出 JSON”，并用正则截取大括号内容作为兜底方案。

4. 完整实战：生成一个待办事项 Web 应用

4.1 技术栈和项目结构

为了让本地模型更容易生成代码，示例采用最简单的技术栈：

• 后端：Python Flask，提供 REST API。
• 数据库：SQLite，Python 内置，零配置。
• 前端：原生 HTML + CSS + JavaScript，无构建步骤。

这样的组合适合起步，后续再根据实际项目替换为 Vue、React 或其他后端框架。

项目结构如下：

todo-app/ ├── backend/ │ └── app.py ├── static/ │ └── index.html ├── scripts/ │ ├── fetch_issue.py │ └── analyze_issue.py └── issue.md

请注意，Flask 默认会在static目录下寻找静态文件，所以前端文件放在项目根目录的static/index.html。

4.2 生成后端 API 代码

为了让本地模型理解需求，可以把需求描述和技术约束一起放进提示词。这里的关键是明确告诉模型：

• 项目路径和目录结构。
• 使用 Flask。
• 使用 SQLite。
• 接口路径。
• 必须使用参数化查询防止 SQL 注入。
• 输出完整可运行代码。

下面是一份整理后的后端代码，可以直接复制运行。

backend/app.py：

# 文件路径：backend/app.py from flask import Flask, jsonify, request, g import sqlite3 app = Flask(__name__) DB_PATH = "todos.db" def get_db(): if "db" not in g: g.db = sqlite3.connect(DB_PATH) g.db.row_factory = sqlite3.Row return g.db @app.teardown_appcontext def close_db(error): db = g.pop("db", None) if db is not None: db.close() def init_db(): conn = sqlite3.connect(DB_PATH) try: conn.execute( """ CREATE TABLE IF NOT EXISTS todos ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, completed INTEGER DEFAULT 0, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) """ ) conn.commit() finally: conn.close() @app.route("/api/todos", methods=["GET"]) def list_todos(): conn = get_db() rows = conn.execute("SELECT * FROM todos ORDER BY id DESC").fetchall() return jsonify([dict(row) for row in rows]) @app.route("/api/todos", methods=["POST"]) def add_todo(): data = request.get_json(force=True) title = data.get("title", "").strip() if not title: return jsonify({"error": "title is required"}), 400 conn = get_db() cur = conn.execute( "INSERT INTO todos (title) VALUES (?)", (title,) ) conn.commit() return jsonify({"id": cur.lastrowid, "title": title, "completed": 0}), 201 @app.route("/api/todos/<int:todo_id>", methods=["PUT"]) def update_todo(todo_id): data = request.get_json(force=True) completed = data.get("completed") if completed is None: return jsonify({"error": "completed is required"}), 400 conn = get_db() conn.execute( "UPDATE todos SET completed=? WHERE id=?", (1 if completed else 0, todo_id) ) conn.commit() row = conn.execute( "SELECT * FROM todos WHERE id=?", (todo_id,) ).fetchone() if row is None: return jsonify({"error": "todo not found"}), 404 return jsonify(dict(row)) @app.route("/api/todos/<int:todo_id>", methods=["DELETE"]) def delete_todo(todo_id): conn = get_db() cur = conn.execute("DELETE FROM todos WHERE id=?", (todo_id,)) conn.commit() if cur.rowcount == 0: return jsonify({"error": "todo not found"}), 404 return jsonify({"ok": True}) if __name__ == "__main__": init_db() app.run(host="0.0.0.0", port=5000, debug=True)

这段代码要注意几个点：

• SQL 都使用了?占位符，这是参数化查询，可以避免 SQL 注入。
• 数据库表结构使用CREATE TABLE IF NOT EXISTS，重复启动不会报错。
• 通过 Flask 的g对象管理连接，请求结束后自动关闭。
• 删除操作直接作用于数据库，请务必在测试环境运行，不要直接在包含重要数据的服务器上执行。

4.3 生成前端页面代码

前端页面需要完成三件事：加载待办列表、新增待办、标记完成和删除。将下面的 HTML 保存到static/index.html。

<!-- 文件路径：static/index.html --> <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>待办事项 Web App</title> <style> body { font-family: Arial, sans-serif; max-width: 600px; margin: 40px auto; } .todo-item { display: flex; align-items: center; padding: 8px 0; border-bottom: 1px solid #eee; } .todo-item.done .title { text-decoration: line-through; color: #999; } .todo-item .title { flex: 1; } button { margin-left: 8px; } </style> </head> <body> <h1>待办事项</h1> <div> <input id="todoInput" placeholder="输入新的待办事项"> <button id="addBtn">添加</button> </div> <ul id="todoList"></ul> <script> const API = '/api/todos'; async function loadTodos() { const resp = await fetch(API); const todos = await resp.json(); const ul = document.getElementById('todoList'); ul.innerHTML = todos.map(todo => ` <li class="todo-item ${todo.completed ? 'done' : ''}">cd todo-app/backend pip install flask

启动后端：

python app.py

启动成功后，浏览器访问：

http://localhost:5000

页面会显示一个空待办列表。通过在输入框输入内容并点击“添加”，可以把待办事项写入 SQLite 数据库。

4.5 用 curl 验证 API

除了浏览器页面，还可以用 curl 直接验证 API 是否正常。

查看列表：

curl -s http://localhost:5000/api/todos

新增一条待办：

curl -s -X POST http://localhost:5000/api/todos \ -H "Content-Type: application/json" \ -d '{"title":"阅读 GitHub Issue 并完成拆解"}'

再次查看列表：

curl -s http://localhost:5000/api/todos

预期会返回包含上一步新增数据的 JSON 数组。到这里，一个由本地模型辅助生成、人工整理后可运行的 Web 应用已经完成。

5. 用 UI 自动化录制工具验证 Web 应用

5.1 为什么需要 UI 自动化验证

模型生成的页面可能存在结构不稳定、缺少交互反馈、按钮定位模糊等问题。手工点击几遍能发现问题，但以后每次改动都要重测，成本很高。近两年出现了不少 UI 自动化录制生成脚本的开源项目，核心思路是一致的：录制用户操作轨迹，自动生成可回放的自动化脚本。这样的工具尤其适合验证 AI 生成的 Web 应用。

Web 端比较常见的录制方案是 Playwright codegen。它可以把浏览器操作转换为自动化脚本，生成 JavaScript、Python 等语言的代码。

5.2 Web 端使用 Playwright codegen

先在独立目录中准备 Playwright 环境。

mkdir e2e cd e2e npm init -y npm install -D @playwright/test npx playwright install chromium

然后启动录制模式，指向本地运行的应用：

npx playwright codegen --target javascript -o todo.spec.js http://localhost:5000

执行后，Playwright 会打开一个浏览器窗口，同时打开一个脚本录制预览。此时在页面上正常操作：

• 在输入框中输入一条待办。
• 点击“添加”。
• 点击“完成”。
• 点击“删除”。

操作结束后，停止录制，脚本会自动保存到todo.spec.js。

录制生成的脚本通常没有完整断言，为了让它更有验证作用，可以在此基础上补充关键检查。下面是一份整理后的脚本片段。

// 文件路径：e2e/todo.spec.js const { test, expect } = require('@playwright/test'); test('用户完成待办全流程', async ({ page }) => { await page.goto('http://localhost:5000'); await page.fill('#todoInput', '阅读 GitHub Issue'); await page.click('#addBtn'); const item = page.locator('.todo-item').filter({ hasText: '阅读 GitHub Issue' }); await expect(item).toBeVisible(); await item.locator('.toggle-btn').click(); await expect(item).toHaveClass(/done/); });

这样一个可复用的端到端测试就存在了。以后改动前端代码，只需要重新执行测试，就能快速发现回归问题。

Playwright 官方也支持生成 TypeScript、Python 等语言的脚本，如果你更熟悉 Python，可以把--target换成python，再结合 pytest 等框架组织测试。

5.3 App 端录制生成脚本的思路

针对 Android 和 iOS 的 UI 自动化录制，目前比较常用的思路是借助移动端自动化框架的录制能力。以 Appium 为例，基础流程是：

1. 启动 Appium Server。
2. 连接 Android 模拟器或 iOS 模拟器。
3. 配置 Desired Capabilities，指定平台、设备名称、App 路径等信息。
4. 启动录制会话。
5. 在模拟器中操作，Appium 会记录触摸事件和控件信息。
6. 停止录制后，生成脚本并回放验证。

移动端录制生成的脚本，往往比 Web 端更依赖设备和环境。换一台模拟器、换一个系统版本，都可能需要调整配置。因此，在 AI 生成的 App 项目中，录制脚本更多用于“快速采集用户操作路径”，而不是完全代替人工测试。

6. 常见问题与排查思路

本地模型 + AI 生成代码 + 自动化录制这条链路里，最容易遇到的问题主要集中在模型输出、运行环境和自动化脚本稳定性三个方面。

Issue 标签分类 ↓ 本地模型拆解需求 ↓ 创建功能分支 feat/issue-{编号} ↓ 模型生成代码初稿 ↓ 人工审查和补充测试 ↓ UI 自动化脚本回归 ↓ 提交 PR 并引用 Issue 编号