Vite+ 改变了我用 AI Agent 构建应用的方式

我曾经有一个项目，里面包含 47 个开发依赖、7 个配置文件，外加一个专门写给 Agent 解释如何运行各种任务的 Markdown 文档。凌晨两点，我还在苦苦排查本地检查与 CI 流程之间的差异。业务代码早就写完了，但周边的工程化工具链却迟迟调不通。在四个项目中深度体验了三周 Vite+ 之后，我现在为所有新的 Vite 应用定下了一条简单的规则：把它写进我给 AI 的第一条 Prompt 中。

简而言之

• 对于新建的 Vite 应用，我让 Agent 使用 vp create 创建项目，随后通过 vp check、vp test 和 vp build 来校验其工作结果。
• 执行速度固然让人满意，但我认为最大的收获在于为 Agent、我自己以及 CI 流程确立了一套清晰且统一的工作流。
• 对于已有项目，我将 vp migrate 视为迁移的起点。我依然会逐一审查 diff、测试用例以及构建行为。

慢吞吞的 Linter 并不是症结所在

我过去的各项命令分散在 ESLint、Prettier、TypeScript、测试运行器以及 package.json 的各类脚本中。每当我让 Agent 介入项目时，它的第一项任务永远是搞清楚哪条命令才是正确的。为此我不得不撰写详尽的说明文档，结果手上又多了一个需要维护的文件。这能叫节省时间吗？

问题还不仅仅在于文件数量。有一次，我的本地环境和 CI 对某个生成文件的检查机制不一致。Agent 看到的是一种运行结果，流水线跑出来的却是另一种。光靠更快地生成组件根本解决不了这类痛点。

Vite+ 将日常任务统一归拢到了 vp 命令下：用 Vite 负责开发和构建、Vitest 负责测试、Oxlint 和 Oxfmt 负责代码检查、tsdown 负责库打包、Vite Task 负责任务调度。你可以将它们的配置统一保留在 vite.config.ts 中。当然，项目中依然保留了 package.json、tsconfig 以及对应的框架配置。“用一个文件搞定所有配置”作为宣传口号固然好听，但在真实的仓库里往往行不通。

对于一个 React 应用，创建项目后我只需要以下几条命令：

shell vp create vite -- --template react-ts cd project-name vp install vp dev vp check vp test vp build

上述命令假定 vp 已经全局安装。全局安装并非强制要求，你完全可以通过包管理器将 Vite+ 作为本地依赖引入。vp install 会自动调用项目所选用的包管理器，因此 Vite+ 并不是要替代 npm 或 pnpm。

使用 vp create 创建项目。

不让 Agent 随意猜测什么是“完成”

Vite+ 官方文档提供了一份针对 AI 助手的 Prompt。这是一个很好的起点，但我会根据具体项目进行调整。我的目标非常具体：Agent 必须使用 Vite+ 初始化应用，并且不能在生成第一个页面后就草草了事、甩手不管。

text Create a new React + TypeScript app on Vite using Vite+. First read the current vp create guide and run vp help create. Inspect the target directory and do not overwrite existing files. Choose the current stable Vite+ release and one package manager. Create the project with vp create using the React + TypeScript template. Keep its single lockfile. Do not add another linter or formatter unless there is a specific reason. After setup, run vp install, vp check, and relevant tests with vp test, and run a production vp build. Add a test for the behavior you implemented. If a check fails, fix the cause and rerun it. In your final report, list the Vite+ version, commands, and actual results.

我并不强求每个项目都通过 curl 进行全局安装。对于一次性搭建，使用类似 npx --package=vite-plus@1.3.0 vp create 即可；而在已建好的项目中，Agent 可以通过指定的包管理器运行本地 CLI。我也并不排斥 create-vite：vp create vite 调用的就是该模板。核心在于，Agent 必须遵循预设的规范，并保持单一且一致的工具链。

过去当我给 Agent 充分自由时，最终往往会同时引入 Prettier 和 Oxfmt、留下三个 lockfile，以及摇摇欲坠的 CI 流程。禁止引入第二套格式化工具、强制只保留一份 lockfile，这绝非审美偏好，而是我再也不想收拾的两次历史遗留灾难。

一条命令带来快速反馈

修改代码后，我会运行 vp check。它会同时执行格式化与 Lint 检查；当配置中开启了 typeAware 与 typeCheck 时，它还会进行 TypeScript 类型检查。通过 vp create 创建的新项目默认都会开启这些检查。而在已有项目中，我会主动核查该配置，绝不盲目假设“检查通过绿灯”就等同于“类型完全正确”。

这与我过去的旧工作流大不相同：

shell

过去：完全取决于各个项目各自配置的脚本

npm run format:check npm run lint npm run typecheck

现在：在配置了 Vite+ 的项目中只需一行

vp check

vp check --fix 可以自动修复部分发现的问题。在此之后，我会审查 diff 并再次运行检查。不过，Lint 检查通过依然不能说明应用逻辑是否正确。我仍需通过 vp test 验证业务行为，并通过 vp build 确保生产环境构建能够成功通过。

我也将这条规则写入了仓库的 Agent 指南中。哪怕一周之后我再回到项目中，新调用的 Agent 也不会保留昨天的对话记忆，但代码仓库自身永远清楚它的校验指令：

markdown

任务交付前的检查清单

• 修改代码后，运行 vp check 并修复所有错误。
• 变更功能行为后，使用 vp test 运行相关测试。
• 交付 Vite 应用前，运行 vp build。
• 自动修复后务必审查 diff。
• 汇报实际运行结果，切勿将运行失败的任务标记为已完成。

本地规范和 Git hooks 很有帮助，但它们可能会被绕过或禁用。因此我在 CI 中运行完全相同的检查。在一次让 Agent 无人值守独立工作的实验中，合并前的代码人工复核依然是我的底线责任。

我的实测数据

在修改工作流之后，某个 Monorepo 的 CI 构建时间从 4 分钟缩短到了 50 秒。预提交检查（pre-commit check）的时间从 11 秒降至 2 秒以内。需要说明的是，这只是来自我个人项目的实测结果，并非在严格同等受控条件下与其它工具链的标准基准测试。这部分性能提升主要归功于具体执行了哪些任务以及扫描了哪些文件；换作其他配置，你未必能直接获得相同的 CI 提速。

GitHub Actions：传统工具链基准测试耗时 10.441 秒。 GitHub Actions：Vite+ 基准测试仅耗时 1.356 秒。

为了快速检查暂存区的文件变更，我会使用 vp staged 以及由 vp hooks 管理的 Git hooks。当不同项目表现出行为差异时，vp toolchain 能直观展示当前生效的工具版本，而 vp toolchain --global 则能展示全局安装版本。在调试排错时，这比我以前纯靠主观记忆“我肯定升级过了”要管用得多。

使用 vp staged 检查暂存区文件。 vp toolchain 展示项目中处于活跃状态的工具版本。

在 Monorepo 中需要理清两点区别：vp run 可以执行 package.json 中的脚本或 vite.config.ts 中定义的任务，并且能够根据工作区依赖关系编排执行顺序。需要注意，package.json 脚本不会自动开启缓存机制。 你可以通过类似 vp run --cache build 显式启用缓存；而定义在 vite.config.ts 中的任务则是默认开启缓存的。我不会把自己的 CI 耗时表现夸大成一种承诺，吹嘘单靠 vp run 就能自动加快所有构建。

踩坑与需要注意的地方

在对一个老旧的 Monorepo 执行 vp migrate 时，迁移跑了大约 4 分钟。它顺利转换了我的 ESLint、Prettier 以及原有的 tsup 构建配置，就我的案例而言没有造成任何破坏。但这并不意味着每次迁移都能四分钟搞定。你必须拿生成的结果去仔细对比原有的 Lint、测试、hooks 以及构建输出产物。第三方插件和自定义规则可能依然需要人工介入调优。

另一个容易踩的坑是内置命令与项目脚本之间的界限。vp build 负责运行 Vite 应用的构建，而 vp run build 则是执行 package.json 里的 build 脚本或同名任务。在一个 Next.js 项目中，Agent 绝不能误以为 vp build 能直接取代 next build。同样的区别也适用于 vp dev 和 vp run dev。Vite+ 虽然可以兼容其他模板，但并不会改变这些命令本身的底层行为。

第三个需要留心的是版本管理。全局的 vp env 可以用来管理 Node.js 与包管理器版本。我手头有三个项目分别运行在三个不同的 Node 版本上，它确实帮我简化了版本切换；如果你不需要该功能，可以直接通过 vp env off 关闭。此外，vp upgrade 升级的是全局 CLI，并不会自动更新每个项目本地的 vite-plus 依赖包。我在 Agent 指南中特意强调了这一点，因为该命令的命名很容易让人产生相反的误解。

谁最适合在第一条 Prompt 中引入 Vite+

任何打算用 AI 辅助搭建全新 Vite 应用的人都应该尝试。此时推行标准化的成本极低：选定一套统一工具链，将检查命令固化到代码仓库与 CI 流程中，Agent 从修改代码到验证成果就有了一条清晰明确的闭环路径。在三周时间横跨四个项目的实践中，对我而言最大的收益就是：我再也不必一遍又一遍地向 AI 解释那些最基础的命令了。

但如果是一个正在稳定运行、拥有完善构建和测试套件的大型既有项目，我绝不会盲目执行迁移。对于那些自带专属构建体系的框架，我会在介入前先想清楚自己究竟需要使用 Vite+ 的哪些部分。而如果你手头已经有一套文档详尽、运行飞快且表现稳健的技术栈，单凭一句“一行命令包揽一切”的承诺，并不足以成为彻底替换它的理由。

下次启动新的 Vite 项目时，不妨在第一条 Prompt 中写上 vp create，并要求将 vp check、测试用例和构建输出作为完工交付标准的一部分。一张做好的应用截图固然养眼，但全绿的检查结果才能说明一切。

Vite+ changed how I build applications with AI agents

One project had 47 development dependencies, seven config files, and a Markdown file explaining to the agent how to run everything. At 2 a.m., I was debugging a difference between local checks and CI. The code was done; the tooling around it wasn't. After three weeks with Vite+ across four projects, I have a simple rule for new Vite apps: put it in the first prompt I give the AI.

The short version

• For a new Vite app, I have the agent create the project with vp create, then verify its work with vp check, vp test, and vp build.
• Speed is nice, but the bigger win for me is one clear workflow for the agent, me, and CI.
• For an existing project, I treat vp migrate as the start of a migration. I still review the diff, tests, and build behavior.

A slow linter wasn't the problem

My commands were spread across ESLint, Prettier, TypeScript, a test runner, and package.json scripts. When I let an agent into the project, its first job was figuring out which command was the right one. I wrote instructions to explain that. Now I had another file to maintain. Excellent time saver, right?

It wasn't just the number of files. Once, my local setup and CI checked a generated file differently. The agent saw one result; the pipeline saw another. Faster component generation doesn't fix that.

Vite+ brings everyday tasks under vp: Vite for development and builds, Vitest for tests, Oxlint and Oxfmt for checks, tsdown for libraries, and Vite Task for tasks. You can keep their configuration in vite.config.ts. You still have package.json, tsconfig, and, depending on the project, framework configuration. “One file for absolutely everything” would look good on a banner and bad in a real repo.

For a React app, these are the commands I need after creating the project:

Shell

1vp create vite -- --template react-ts 2cd project-name 3vp install 4vp dev 5vp check 6vp test 7vp build

The commands above assume vp is available globally. A global install is optional; you can also run Vite+ as a local dependency through a package manager. vp install uses the package manager selected for the project, so Vite+ doesn't replace npm or pnpm.

Creating a project with vp create.

I don't let the agent guess what “done” means

The Vite+ docs include a prompt for AI assistants. It's a useful starting point, but I adapt it to the project. My goal is concrete: the agent should use Vite+ to set up the app and not quietly abandon it after generating the first page.

Text

Create a new React + TypeScript app on Vite using Vite+. First read the current vp createguide and runvp help create. Inspect the target directory and do not overwrite existing files. Choose the current stable Vite+ release and one package manager. Create the project with vp createusing the React + TypeScript template. Keep its single lockfile. Do not add another linter or formatter unless there is a specific reason. After setup, runvp install, vp check, and relevant tests with vp test, and run a production vp build. Add a test for the behavior you implemented. If a check fails, fix the cause and rerun it. In your final report, list the Vite+ version, commands, and actual results.

I don't require a global install via curl in every project. For a one-off setup, something like npx --package=vite-plus@1.3.0 vp create is enough; in an established project, the agent can run the local CLI through the selected package manager. I don't ban create-vite, either: vp create vite uses that template. What matters is that the agent follows the intended setup and keeps one consistent toolchain.

When I gave an agent free rein, I ended up with both Prettier and Oxfmt, three lockfiles, and unreliable CI. Banning a second formatter and requiring one lockfile aren't aesthetic preferences. They're two mistakes I don't want to clean up again.

One command gives me fast feedback

After changing code, I run vp check. It checks formatting and lint; it checks TypeScript when both typeAware and typeCheck are enabled in the configuration. A new project created with vp create enables them by default. In an existing project, I verify that setting instead of assuming a green result also means the types are sound.

Here's the difference from my old workflow:

Shell

1# Before: it depended on each project's scripts. 2npm run format:check 3npm run lint 4npm run typecheck 5 6# Now, in a project with the corresponding Vite+ configuration. 7vp check

vp check --fix can repair some findings automatically. After that, I read the diff and run the check again. A green lint result still doesn't tell me whether the app does the right thing. I need vp test for behavior and vp build to verify the application builds.

I also put that rule in the repo's agent instructions. When I return to a project a week later, a new agent won't remember yesterday's chat. The repo still knows its commands.

Markdown

1## Checks before completing a task 2 3- After changing code, run vp checkand fix any errors. 4- After changing behavior, run the relevant tests withvp test. 5- Before handing off a Vite app, run vp build. 6- Review the diff after automatic fixes. 7- Report the actual results; don't call a failed run complete.

Local instructions and Git hooks help, but they can be bypassed or disabled. I run the same checks in CI. On an experiment where I let an agent work unattended, human review before merging was still my responsibility.

What I measured

In a monorepo, CI went from 4 minutes to 50 seconds after I changed the workflow. A pre-commit check dropped from 11 seconds to under 2. Those are results from my projects, not a benchmark comparing Vite+ with another toolchain under identical conditions. Part of the gain comes from what runs and which files it checks; you won't automatically get those CI times with a different configuration.

GitHub Actions: the classic toolchain benchmark took 10.441 s. GitHub Actions: the Vite+ benchmark took 1.356 s.

For quick checks of changed files, I use vp staged and Git hooks managed with vp hooks. When different projects behave differently, vp toolchain shows me their active versions. vp toolchain --global shows the global installation. That's more useful for debugging than my old method: “I definitely updated it.”

Checking the staged file with vp staged. vp toolchain shows the active tool versions in the project.

There are two things to distinguish in a monorepo. vp run executes a package.json script or a task defined in vite.config.ts, and it can order work according to workspace dependencies. Caching is not enabled automatically forpackage.json scripts. You can enable it with, for example, vp run --cache build. Tasks defined in vite.config.ts are cached by default. I won't turn my CI timing into a promise that vp run alone makes every build faster.

Where it got awkward

vp migrate ran on an older monorepo for about 4 minutes. It converted my ESLint, Prettier, and original tsup build setup, and nothing broke in my case. That doesn't mean every migration takes four minutes. You have to compare the result with the old lint, tests, hooks, and build output. Plugins and custom rules may still need manual work.

Another trap is the difference between a built-in command and a project script. vp build runs a Vite app build. vp run build runs the build script from package.json or a task with that name. In a Next.js project, the agent must not assume vp build replaces next build. The same distinction applies to vp dev and vp run dev. Vite+ can work with other templates, but that doesn't change what those commands do.

The third issue is version management. The global vp env can manage Node.js and package managers. I have three projects on three Node versions, and it made switching easier for me; if you don't want that, you can turn it off with vp env off. vp upgrade updates the global CLI, not the localvite-plus package in every project automatically. I wrote that explicitly in my agent instructions because the command name invites the opposite assumption.

Who gets Vite+ in my first prompt

Anyone starting a new Vite app with AI doing the setup. The cost of standardizing is small here: choose one toolchain, put the check commands in the repo and CI, and the agent has a clear path from a code change to verification. Across three weeks and four projects, the main benefit for me was that I stopped explaining the basic commands over and over.

I wouldn't blindly migrate a large existing app with a working build and test suite. For a framework with its own build, I'd first decide which parts of Vite+ I actually want to use. And if I already had a well documented, fast, stable stack, the promise of “one command” alone wouldn't convince me to replace it.

Next time you start a Vite project, put vp create in the first prompt and ask for the outputs of vp check, tests, and the build as part of the definition of done. A screenshot of the finished app is nice. Passing checks tell you more.