Vite+ 优秀的AI代理开发工具链

Vite+ 改变了我使用 AI 代理构建应用程序的方式。一个项目有 47 个开发依赖项、七个配置文件和一个向代理解释如何运行所有内容的 Markdown 文件。凌晨 2 点，我正在调试本地检查和 CI 之间的差异。代码完成了；它周围的工具不是。在四个项目中使用 Vite+ 三周后，我对新的 Vite 应用程序有了一个简单的规则：将其放在我给 AI 的第一个提示中。简短版本对于新的 Vite 应用程序，我让代理使用 vp create 创建项目，然后使用 vp check 、 vp test 和 vp build 验证其工作。速度固然不错，但对我来说更大的胜利是为代理、我和 CI 提供一个清晰的工作流程。对于现有项目，我将 vp migrate 视为迁移的开始。我仍然会审查差异、测试和构建行为。缓慢的 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+来设置应用程序，而不是在生成第一页后就悄悄放弃它。文本 使用 Vite+ 在 Vite 上创建一个新的 React + TypeScript 应用程序。首先阅读当前的“vp create”指南并运行“vp help create”。检查目标目录，不要覆盖现有文件。选择当前稳定的 Vite+ 版本和一个包管理器。使用 React + TypeScript 模板通过“vp create”创建项目。保留其单个锁定文件。除非有特定原因，否则不要添加其他 linter 或格式化程序。设置完成后，运行“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。禁止第二个格式化程序并需要一个锁定文件并不是审美偏好。这是我不想再犯的两个错误。一个命令给我快速反馈更改代码后，我运行 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 可以自动修复一些发现的问题。之后，我读取差异并再次运行检查。绿色的棉绒结果仍然无法告诉我该应用程序是否做了正确的事情。我需要 vp 行为测试和 vp 构建来验证应用程序构建。我还将该规则放入存储库的代理指令中。当我一周后返回一个项目时，新代理将不记得昨天的聊天内容。存储库仍然知道它的命令。 Markdown 1 ## 完成任务前检查 2 3 - 更改代码后，