使用WorkBuddy生成tinyfrontend前端

故事从一个看似顺利的构建任务开始。我们利用WorkBuddy工具，成功生成了一个轻量级的前端项目结构。一切就绪，接下来自然是验证其基础稳定性。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

测试：

在项目目录下，我们运行了测试命令：c:\Users\Admin\WorkBuddy\20260330150804\tinyfrontend>npm run test。

结果令人满意，所有测试用例均顺利通过。控制台输出的绿色“PASS”字样，清晰地展示了项目的健康状态：

Test Suites: 10 passed, 10 total Tests: 144 passed, 144 total Snapshots: 0 total Time:23.837 s Ran all test suites.

测试环节的绿灯，通常意味着核心逻辑和工具函数没有问题。然而，前端开发中一个经典的情况是：测试能过，运行时却可能遇到意想不到的障碍。

运行

运行报错

果然，当我们尝试启动开发服务器时，问题出现了。执行 npm run dev 后，开发服务器虽然给出了访问地址（http://localhost:3000），但紧随其后的是一连串令人头疼的模块解析错误。

控制台抛出了一系列“Could not resolve”错误，核心问题指向了文件路径。例如，在 src/views/content/DashboardView.js 这个文件中，诸如 ‘../utils/hooks.js’、‘../stores/content.js’ 这样的相对路径导入语句全部失效了。这意味着构建工具（很可能是Vite或类似的打包器）无法根据这些相对路径找到对应的模块文件。

错误信息非常具体，直接列出了问题文件和行号，这为后续排查提供了精准的切入点。问题的根源很明确：项目的模块解析配置可能存在问题，导致相对路径引用失效。

让WorkBuddy解决问题

面对这个典型的工程化问题，我们首先向生成这个项目的WorkBuddy寻求帮助。我们提供了详细的项目上下文：项目根目录位于 c:\Users\Admin\WorkBuddy\20260330150804\，前端目录在其中的 tinyfrontend 文件夹下。同时，我们明确指出了矛盾点——测试全部通过，但开发服务器启动失败，并附上了完整的报错日志。

我们给WorkBuddy的指令很直接：“应该是相对路径有问题，请解决。” 期待它能自动调整项目配置，修复模块导入的路径问题。

WorkBuddy出500错误

然而，这次尝试遇到了阻碍。WorkBuddy的服务端返回了一个标准的HTTP 500内部服务器错误。错误页面显示是由OpenResty和APISIX提供，并附带了请求ID和时间戳等诊断信息。

Message:

Powered by APISIX.

这个错误表明，WorkBuddy在处理我们这个特定请求时，其后台服务出现了异常，无法完成我们期望的路径修复操作。

再次用新prompt

服务错误并没有让我们放弃。我们决定换一种更具体的思路，重新向WorkBuddy发起请求。这次，我们不仅重复了项目信息和报错现象，还主动提供了一个解决方案方向：使用别名路径（Path Alias）。

我们指出，类似 import { useStore } from ‘../utils/hooks.js’ 这样的引用方式可能存在问题，并建议在项目的构建配置（如vite.config.js或jsconfig.json）中设置路径别名，例如将 @ 指向 src 目录，从而将引用简化为 import { useStore } from ‘@/utils/hooks’。这种方式能极大提升代码的可维护性，并避免深层目录下的繁琐相对路径。

遗憾的是，这次尝试依然以相同的500错误告终。WorkBuddy的服务似乎暂时无法处理这类复杂的项目配置修改请求。

换用Trae解决问题

当一条路暂时走不通时，切换工具往往是高效的策略。我们使用了与之前相同的提示词（prompt），将问题抛给了另一个AI编程助手Trae。

这次尝试取得了成功！Trae准确地理解了问题，并帮助我们配置了路径别名。修改完成后，再次运行 npm run dev，开发服务器顺利启动，没有报错。更重要的是，浏览器访问 http://localhost:3000 后，前端首页成功渲染了出来！

不过，Trae的解决方案并非完美无缺。在首页登录功能的调试上，它遇到了瓶颈。页面显示出来了，但登录接口反复调用失败，无法完成认证流程。这并非偶然，因为回顾过去的开发经验，让Trae处理类似的登录鉴权逻辑时，它也常常需要花费很长时间调试，且不一定能彻底解决。正是为了规避这类问题，我们当初才选择使用WorkBuddy来构建Kotti Next项目的主体框架。

换回WorkBuddy来调登录问题

于是，我们决定让每个工具发挥其长处。既然WorkBuddy在构建项目框架上表现更佳，而Trae解决了路径配置问题，那么最后的登录难题，我们再次交回给WorkBuddy处理。

我们向WorkBuddy清晰地描述了当前状态：基于Kotti Next框架的前后端分离Web应用已经搭建完成。前端成功启动并打开了首页，但在使用默认用户名进行登录时，浏览器端收到了“401 Unauthorized”的错误。

我们提交的请求很明确：“请查找问题并解决。” 问题最终得到了解决。虽然过程可能涉及检查前端请求头、确认令牌（Token）发送方式、核对后端API鉴权接口或验证默认用户凭证等多个环节，但结果是积极的——登录障碍被扫清。

至此，通过结合不同AI助力的优势（Trae解决工程配置，WorkBuddy处理核心业务逻辑），我们成功完成了一个从生成、测试、解决构建错误到调试功能的全流程开发任务。