引子：为什么需要用户认证？

openbb-hka是一个提供A股和港股数据分析的OpenBB Workspace后端。如果将其部署在云服务器上，用户认证便成为必须实现的功能，否则任何人都可以无限制访问，这将带来严重的安全隐患。

目前在OpenBB Workspace中添加后端时，我们需要手动配置用户认证机制。具体操作是：将生成的JWT token填入OpenBB Workspace的后端管理页面。如下图所示：

那么，这个JWT token从何而来？

理想的流程应该是：

1. 用户通过注册页面，创建openbb-hka账号（与OpenBB Workspace账号独立）
2. 用户登录openbb-hka后端系统
3. 登录成功后，系统生成JWT token作为认证凭证
4. 在OpenBB Workspace中配置新的后端，使用刚获取的JWT token

当前openbb-hka版本跳过了前3步，直接使用预设token是因为OpenBB后端的官方代码就是这样实现的。如果没有相应的用户界面，大多数人可能并不知道怎么生成自己的JWT Token。

为实现完整认证流程，我们使用三种AI工具来开发1-3步功能。

AI工具选型：为什么是这三个？

我们选择了目前国内外流行的三款免费AI开发工具：

• Trae - 字节跳动推出的AI集成开发环境，具备Prompt优化功能
• Qoder - 阿里巴巴推出的智能编程平台
• GitHub Copilot - 由GitHub和OpenAI联合开发的业界标杆

前端技术选型延续OpenBB官方标准：React 18 + TypeScript + Vite + Radix UI + Tailwind CSS，确保与OpenBB Workspace界面风格一致。

需求

下面是用来实现用户注册，认证以及JWT token生成的需求。

我们正在对现有的OpenBB Workspace后端 openbb-hka进行扩展——该后端是一个基于Python/FastAPI的系统，目前尚未具备用户认证功能，扩展内容为添加登录和注册功能。拟采用的方案包括开发一个独立的前端来处理用户认证，而新的后端服务将直接集成到当前的OpenBB Workspace后端 openbb-hka中。

前端需求

1. 开发为渐进式Web应用（Progressive Web App，PWA），需兼容桌面端与移动端环境。
2. 使用React 18框架，搭配TypeScript语言，并以Vite作为构建工具。
3. 采用与OpenBB Workspace一致的UI主题（视觉参考可查阅现有的Plotly组件和Tables组件）。
4. 使用Radix UI组件库和Tailwind CSS进行样式开发，需支持亮色/暗色主题切换。
5. 未来的功能增强将包含与OpenBB Workspace类似的特性，例如图表和表格展示功能。

后端需求

1. 基于Python/FastAPI构建。

2. 初始开发阶段使用SQLite数据库，未来可能迁移至PostgreSQL数据库。

3. 实现认证/授权功能，支持以下方式：

   • 用户名-密码登录
   • 微信登录
   • 生成JWT令牌，用于OpenBB Workspace后端的身份验证

4. 提供登录后页面，用户可在此页面查看并复制JWT令牌，以便在OpenBB Workspace中使用。

---

功能实现及相关代码

基于上述需求，我分别用AI工具Trae, Qoder和GitHub Copilot生成了相关的代码。总的来说，过程还是相当顺利的，目前的AI工具，对这个中等复杂度的需求，基本都能比较顺利的完成任务。

生成的代码可以分别参考下列开发分支：

• Trae: https://github.com/shugaoye/openbb-hka/tree/dev/trae
• Qoder: https://github.com/shugaoye/openbb-hka/tree/dev/qoder
• GitHub Copilot: https://github.com/shugaoye/openbb-hka/tree/dev/copilot

为了直观比较，我们先看总结表：

---

现在，我们来深入剖析每个“回合”的细节：

回合 1：后端架构与数据库

一个好的架构是软件可维护性的基石，尤其是数据库设计。

• Trae： 选择了 SQLAlchemy (ORM)。这是一个非常明智的选择。使用 ORM 不仅使代码更整洁、更 Pythonic，而且完全符合我们“未来可能迁移到 PostgreSQL”的需求。ORM 的抽象层使得这种数据库切换变得轻而易举。
• Qoder： 选择了原生 sqlite3 模块。它直接编写 SQL 语句来创建表和查询用户。这导致代码与 SQLite 紧紧地耦合在一起。
• GitHub Copilot： 同样选择了原生 sqlite3 模块，犯了和 Qoder 一样的错误。

赢家：Trae。只有它在技术选型上表现出了符合需求的“远见”和“经验”。

回合 2：安全性（关键回合）

在认证系统中，安全不是一个可选项，它是核心。

• Qoder： 使用了 SHA-256。这是一个巨大的安全隐患。SHA-256 是一个快速的哈希算法，但绝不应该用于存储密码。它的速度使得攻击者可以非常快速地进行暴力破解。
• GitHub Copilot： 使用了 hashlib.pbkdf2_hmac 配合 SHA-256 和盐 (salt)。这是一个安全且正确的密码存储方式。pbkdf2 是一种密钥派生函数，它通过多次迭代来显著减慢哈希过程，能有效抵御暴力破解。
• Trae： 使用 bcrypt (通过 passlib)。这是目前公认的用于密码存储的行业黄金标准，它专为密码存储而设计，天生具有加盐和慢速计算的特性。

本回合排名：

1. Trae (优胜)：使用了行业黄金标准。
2. GitHub Copilot (良好)：使用了一种安全且被接受的标准方法。
3. Qoder (不及格)：引入了严重的安全漏洞。

回合 3：工程完整性与交付质量

光有好的架构还不够，代码能跑起来、易于维护才行。

• Trae： 交付的代码没有单元测试，也没有任何额外的文档。在代码生成过程中，它生成的代码还需要手动介入修复才能正常工作。

• GitHub Copilot： 同样没有提供单元测试或任何有意义的文档。

• Qoder： 交付了极其完整的工程产物。它不仅“顺利完成了需求的实现”，还额外提供了：

  1. 单元测试 (tests/test_auth.py)：为所有新的 API 路由编写了测试用例。
  2. 详细文档 (AUTHENTICATION_SUMMARY.md)：一份完美的Markdown文档，详细说明了它的实现方案、API 端点和技术选型。

赢家：Qoder。它表现出了一个专业工程师应有的“职业素养”——代码写完，测试跟上，文档齐全。

回合 4：需求完整性与前端

最后，我们看看它们对需求的满足程度。

• Trae 和 Qoder 都尝试实现了所有核心需求，包括微信登录和 JWT 令牌页面。
• GitHub Copilot 在这方面有所欠缺。它实现了用户名/密码登录 和 JWT 令牌视图，但完全遗漏了微信登录这一明确的后端需求。
• 在前端方面，三者都按照要求使用了 React、TS、Vite、Radix 和 Tailwind，并提供了登录/注册/令牌查看功能。如果比较前端页面的完整和美观程度，Trae 的 UI 最美观。

赢家：Trae。它在满足所有需求（包括前端 UI 和后端功能点）方面做得最好。

GitHub Copilot

通过下图，我们可以看到，GitHub Copilot虽然实现了，相关页面，但整体非常简单。注册页面甚至不包括密码的一致性验证。

Qoder

Qoder的实现是比较中规中矩的页面。能满足需求，可以考虑采纳这个实现。

Trae

Trae的实现基本与大多少商业应用的注册和登录页面一致。在功能测试完成后，完全可以直接使用。

总结

通过上述的比较分析，我相信大家已经有了一个比较清楚的认识，我就不另外总结和给出结论了。目前这个需求还在开发和完善中。大家可以在功能完成后，自己安装体验最后的结果。

参考资料：

• openbb-hka: https://github.com/finanalyzer/openbb-hka

---

深耕金融科技、量化分析与 AI 金融应用！扫描下方二维码，关注【Finanalyzer】公众号，获取前沿动态、技术解析与实战案例。