# Tags at 3.2.0, package version 0.0.1

> chatgpt-vue3-light-mvp is a Vue front-end template for a single-turn chat box, with streaming output, model adapters and math and diagram rendering. It is explicit about being a prototype that keeps no conversation history, and its deployment story depends entirely on the fact that the model keys are compiled into the browser bundle.

**pdsuwwz/chatgpt-vue3-light-mvp** — 💭 一个可二次开发 Chat Bot 单轮对话 Web 端 MVP 原型模板, 基于 Vue 3, Vite8, TypeScript, Naive UI, Pinia(v3), UnoCSS 等主流技术构建, 🧤简单集成大模型 API, 采用单轮 AI 问答对话模式, 每次提问独立响应, 无需上下文, 支持 SSE 打字机效果流式输出, 集成 markdown-it  Mermaid/KaTex/LaTex 公式高亮预览, 星火, 智谱, 硅基流动, Deepseek V4/V3/R1 深度思考推理模型预览, 兼容 <think> 标签, 包含蒸馏 skill 💼 易于定制和快速搭建 Chat 类大语言模型产品 (附示例截图)

- Repository: https://github.com/pdsuwwz/chatgpt-vue3-light-mvp
- Website: https://botkit.likemashang.com
- Stars: 578 · Forks: 90
- Language: Vue
- License: MIT
- Published: 2026-09-14 · Updated: 2026-09-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/pdsuwwz-chatgpt-vue3-light-mvp

## Tags at 3.2.0, package version 0.0.1

The release history is a clean minor-version sequence: a 3.0.0 in April, a 3.1.0 in June and a 3.2.0 at the end of July, the last of them on the same day as the final push.

The manifest says something different.

```text
"version": "0.0.1"
```

So the tags describe a project at version three while the package metadata has never left the starting line. Nobody has bumped it, and nothing in the documentation explains why a project with a public demo, a marketing site and a versioned skill set would leave it there.

There are three different home pages, too. The manifest's homepage field points at the repository, the repository's own metadata points at a separate product site, and the live demo runs from a project pages address. None of them is wrong, but a reader looking for the entry point has to pick one of three.

## Single-turn is the product, not a bug

The most important thing about this template is stated in a callout box above the feature list, in the position where a project would normally put its marketing.

It is a minimum viable product. It supports single-turn conversation only: every question is answered on its own, no context is carried between them. Multi-turn support may come in future, and there is no plan for it, with an invitation to extend it yourself.

That single decision explains most of the rest of the design. There is no conversation store to persist, no context window to assemble, and no summarisation to choose a strategy for. The state management layer holds a current message, a stream in progress and a set of configuration choices, which is why a project with math rendering, diagram support and five model backends fits in a small amount of code.

The repository name promises a light ChatGPT clone. The README is careful to say it is neither multi-turn nor finished, and the demo is what a reader should judge.

## Every model key is a build-time variable in a browser bundle

The architecture is pure front end. The documentation says so explicitly: there is no backend here, every service is external or running on your machine, and the only reason a proxy exists at all is to work around cross-origin requests during development.

The keys are configured by copying a template file to a dotenv file and filling in variables that are all build-time prefixed.

```sh
cp .env.template .env
```

Those variables are substituted into the client bundle when the app is built. That is what the prefix means in the tool this project uses, and the consequence is direct: any provider key you fill in is compiled into JavaScript that every visitor downloads.

The key formats differ by provider, and one of them is unusual. The Spark service takes a key and a secret joined by a colon in a single variable, while the other hosted providers take a single token that conventionally starts with a prefix.

The deployment section does not say any of this. It says to configure response headers, or put a reverse proxy in front, or unify domain and port.

## The development proxy does not exist in production

Four path prefixes are mapped to four provider endpoints in the development server configuration, and the file is linked by line number so you can read the exact block.

```ts
'/spark': {
  target: 'https://spark-api-open.xf-yun.com',
  changeOrigin: true,
  ws: true,
  rewrite: (path) => path.replace(/^\/spark/, '')
}
```

Each entry rewrites away its own prefix, which is what lets one request shape reach four different vendors. Websocket support is enabled on entries that are ordinary HTTPS endpoints, which costs nothing and does nothing.

The notes then say this configuration only takes effect in development, and that a production deployment has to arrange the equivalent on the server side. Combine that with the previous section and the picture is complete: in production the browser calls the providers directly, cross-origin, carrying a key that is inside the downloaded bundle.

The local development server is also started with a flag that binds to every network interface, so on a shared network anyone who can reach your machine can load the running app.

## Mock mode is switched by a router setting

There is a mode that simulates the model without calling a provider, and it is aimed at demo deployments where an API key should not be spent or embedded.

The switch is one line in a configuration file, and it is not a mock flag at all. It tests whether the router is running in hash mode, which the project uses for static hosting.

```ts
export const isGithubDeployed = process.env.VITE_ROUTER_MODE === 'hash'
```

The comment above it, still marked as a to-do, explains that in a project pages demo the model strategies should be simulated without calling an interface. And the build script for that hosting target sets exactly the same variable, so the deployment mode and the mocking mode are one switch.

That is tidy for a demo and fragile in production, because the only thing separating a live app from a mocked one is a router setting that a deployment can set by accident.

## A template that also ships an architecture reference

The repository carries something unusual for a UI starter: two copies of a written specification of its own architecture, one in English and one in Chinese, stored as agent skills inside the tree.

Each copy has a skill file, a small agent configuration, and a set of reference documents covering architecture, streaming, model adapters, Markdown rendering, and, in the English copy only, a migration checklist. The tree diagram in the README shows the two side by side, and the omission is visible there.

The README is explicit about what these are not: not runtime features and not packages. They exist so another project can borrow the design decisions rather than copy the files, and it names the equivalent artefact other teams write, like a playbook or architecture notes.

What is in them is the part worth reading. The streaming path is described from the fetch response body through a text decoder, a transform stream and a reader. The typewriter effect is explained as decoupling network read speed from display speed with a buffer. And the migration checklist is a list of things to check in another project, including security, proxying, keys, stopping generation, scrolling, empty and finished states.

## Prerequisites include a pre-release editor extension

The prerequisites list four things: the framework major version, a minimum Node version, a package manager major version, and a linter extension for the editor, with a minimum version and a note that it is a pre-release.

Requiring an editor plugin to be on a pre-release build to work on a template is an unusual dependency, and it is the kind of thing that quietly unpins over time.

The rendering side is more carefully pinned. The math renderer is held at a specific minor line to stay compatible with the plugin that drives it, and the note explains that the module's ESM entry is used explicitly so that a commonjs pre-bundling step cannot break formula parsing under the current bundler major version. That is a real, specific bug class being defended against rather than a general aspiration.

The generated type stubs from the auto-import plugin are committed to the repository, alongside a linter configuration for styles, a stylelint ignore file, and a Babel configuration left over from an earlier toolchain.

## Conclusion

Use it as a rendering and streaming reference rather than a product, because single-turn is the one design decision it refuses to revisit. Two things to settle before anything reaches a browser: every provider key is a build-time variable in a pure front-end bundle, so treat any key you compile as published, and remember the development proxy does not exist in production, which is why the deployment notes are about headers and reverse proxies rather than about the app.

## FAQ

### Does chatgpt-vue3-light-mvp keep conversation history?

No. The README states the project is a minimum viable product supporting single-turn conversation only, where each question is answered independently and no context is retained, and that multi-turn support has no concrete plan yet.

### Which models does chatgpt-vue3-light-mvp support?

A mock model used by default in development, a locally run Ollama model, and hosted models from DeepSeek including its reasoning variant, Spark, SiliconFlow and Kimi Moonshot, each configured through its own environment variable.

### Where are the API keys for chatgpt-vue3-light-mvp configured?

In a dotenv file created by copying a template file. The keys are build-time prefixed variables such as the DeepSeek, SiliconFlow and Moonshot ones, and the Spark key is a key and secret joined with a colon in a single value.

### How do I deploy chatgpt-vue3-light-mvp to production?

The project is a pure front-end build with no server of its own, so production needs response headers configured, a reverse proxy, or a unified domain and port. The bundler's proxy that maps paths to the four model providers applies only in development.

### Can I develop chatgpt-vue3-light-mvp without a model API key?

Yes. There is a mock mode that simulates the model response strategies instead of calling an interface, defined in a configuration file and keyed off a router mode variable that the GitHub Pages build script also sets.

## Sources

- [License: MIT](https://github.com/pdsuwwz/chatgpt-vue3-light-mvp/blob/main/LICENSE)
- [pdsuwwz/chatgpt-vue3-light-mvp on GitHub](https://github.com/pdsuwwz/chatgpt-vue3-light-mvp)
- [Project website](https://botkit.likemashang.com)
- [README](https://github.com/pdsuwwz/chatgpt-vue3-light-mvp/blob/main/README.md)
- [Releases](https://github.com/pdsuwwz/chatgpt-vue3-light-mvp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pdsuwwz-chatgpt-vue3-light-mvp