一个项目有 47 个开发依赖、七个配置文件和一个 Markdown 文件，向代理解释如何运行所有内容。凌晨 2 点，我正在调试本地检查与 CI 之间的差异。代码已经完成；周围的工具还没有。经过三周在四个项目中使用 Vite+，我对新的 Vite 应用程序有一个简单的规则：把它放在我给 AI 的第一个提示中。简言之，对于一个新的 Vite 应用，让代理使用 vp create 创建项目，然后用 vp check、vp test 和 vp build 验证其工作。速度很重要，但对我来说更大的收获是代理、我和 CI 之间的一条清晰工作流。对于现有项目，我将 vp migrate 视为迁移的开始。我仍然会审查 diff、测试和构建行为。一个慢的 linter 不是问题。我的命令分散在 ESLint、Prettier、TypeScript、测试运行器和 package.json 脚本中。当我让代理进入项目时，其第一项工作就是弄清楚哪个命令是正确的。我写了说明来解释这一点。现在我有了另一个需要维护的文件。真是一个优秀的节省时间的工具，对吧？这不仅仅是文件的数量。曾经，我的本地设置和 CI 对一个生成的文件的检查结果不同。代理看到一个结果；管道看到另一个。更快的组件生成并不能解决这个问题。Vite+ 将日常任务归纳到 vp 下：Vite 用于开发和构建，Vitest 用于测试，Oxlint 和 Oxfmt 用于检查，tsdown 用于库，Vite Task 用于任务。你可以将其配置保存在 vite.config.ts 中。你仍然有 package.json、tsconfig，以及根据项目不同的框架配置。“一个文件用于所有内容”在横幅上看起来不错，但在实际的代码库中看起来不太好。对于一个 React 应用，创建项目后，我需要以下命令：Shell 1 vp create vite -- --template react-ts 2 cd project-name 3 vp install 4 vp dev 5 vp check 6 vp test 7 vp build 上述命令假设 vp 在全局可用。全局安装是可选的；你也可以通过包管理器作为本地依赖运行 Vite+。vp install 使用为项目选择的包管理器，因此 Vite+ 并不替代 npm 或 pnpm。使用 vp create 创建项目。我不让代理猜测“完成”的含义。Vite+ 文档中包含了用于 AI 助手的提示。这是一个有用的起点，但我会根据项目进行调整。我的目标很明确：代理应该使用 Vite+ 设置应用，而不是在生成第一页后安静地放弃它。文本 创建一个新的 React + TypeScript 应用程序在 Vite 上使用 Vite+。首先阅读当前的 `vp create` 指南并运行 `vp help create`。检查目标目录，不要覆盖现有文件。选择当前稳定的 Vite+ 版本和一个包管理器。使用 React + TypeScript 模板通过 `vp create` 创建项目。保持其单个锁文件。除非有特定理由，否则不添加其他 linter 或 formatter。设置后，运行 `vp install`、`vp check` 和相关测试（使用 `vp test`），并运行生产 `vp build`。为你实现的行为添加测试。如果检查失败，修复原因并重新运行。在你的最终报告中，列出 Vite+ 版本、命令和实际结果。我不要求在每个项目中通过 curl 进行全局安装。对于一次性设置，像 npx --package=vite-plus@1.3.0 vp create 就足够了；在一个已有的项目中，代理可以通过选择的包管理器运行本地 CLI。我也不禁止 create-vite；vp create vite 使用该模板。重要的是代理遵循预期的设置并保持一致的工具链。当我给代理自由发挥时，我最终得到了 Prettier 和 Oxfmt，同时有三个锁文件和不可靠的 CI。禁止第二个 formatter 和要求一个锁文件并不是美学偏好。这是我不想再清理的两个错误。一个命令让我快速反馈。修改代码后，我运行 vp check。它检查格式和 lint；当配置中同时启用 typeAware 和 typeCheck 时，它还会检查 TypeScript。使用 vp create 创建的新项目默认启用它们。在现有项目中，我会验证该设置，而不是假设绿色结果也意味着类型是正确的。这是我旧工作流的不同之处：Shell 1 # 之前：依赖于每个项目的脚本。 2 npm run format:check 3 npm run lint 4 npm run typecheck 5 6 # 现在，在具有相应 Vite+ 配置的项目中。 7 vp check vp check --fix 可以自动修复一些发现。之后，我阅读 diff 并再次运行检查。一个绿色的 lint 结果仍然不能告诉我应用是否做对了事情。我需要 vp test 来验证行为，并用 vp build 验证应用的构建。我还将该规则写入代码库的代理说明中。当我一周后重新回到一个项目时，一个新的代理不会记得昨天的聊天。代码库仍然知道其命令。Markdown 1 ## 完成任务前的检查 2 3 - 改变代码后，运行 `vp check` 并修复任何错误。4 - 改变代码后