AI工具实战复盘：从ChatGPT到Tauri，Mindory项目避坑与生产级性能优化指南

Mindory 这个项目有些特殊，它不是一个纯粹由人敲出来的代码，而是人与多个AI系统协同工作的产物。

这篇文章想跟你聊聊，在 Mindory 的研发过程中，我们用到了哪些 AI 工具，以及如何将那些 AI 生成的内容——无论是原型设计、代码还是文档——一步步打磨成真正能上线的生产级软件。

整个过程的核心体会，可以浓缩为一句话：

AI 能快速搭出框架，但正确性、架构与性能，依然要靠人来把控。

一、ChatGPT：产品级战略搭档

主要作用

在 Mindory 的开发中，ChatGPT 扮演的更多是战略与产品层角色，而不仅仅是写代码的助手：

• 产品定义与方向梳理
• 关键决策：定价策略、App 视觉风格、官网风格
• 为其他 AI 工具编写高质量提示词
• 产品文案，及中英互译
• 商业模式验证
• 系统架构讨论与方案梳理

实际体验下来，感觉它更像一位联合创始人，而不只是个编码助理。

使用感受

• 整体表现符合预期。
• 对话过长时，输入框会出现卡顿。
• 上下文太重时，只能新开对话继续。

有个有意思的细节：当你尝试把上下文迁移到新对话时，AI 似乎能智能地过滤掉那些简单的一次性问题，让上下文切换得更流畅。

局限

超长的对话会明显拖慢 UI 的响应速度，很多时候需要你手动去重置上下文、管理对话历史。另外，如果用的是免费版本，一旦超出使用量，ChatGPT 会自动切换到低阶模型，那种“降智”的感觉会非常明显。

二、Manus：视觉输出强，架构需清理

主要用途

我们主要用它来生成 Mindory 的官方网站。它的亮点很突出：

• 能快速生成网站的基础结构。
• 所见即所得的设计流程，效率很高。
• 产出的 UI 布局与配色比较成熟。
• 生成的代码符合 Next.js 的设计范式（Mindory 官网正是基于 Next.js 实现的）。

优点在于视觉风格统一、排版舒服，组件结构也干净，默认的审美是在线的。

局限

但问题也有：

• 其 CSS 基于 Tailwind CSS 生成，虽然会产出 global.css，但实际并未被使用。
• 部分布局数值被直接硬编码在 TSX 文件中。

这带来的直接后果就是：初始生成的代码，必须经过重构才能用于生产。

结论就是：Manus 的视觉输出能力极强，但上线前必须做架构清理。

三、百度秒嗒：快速搭骨架，上线要解耦

主要用途

我们用秒嗒生成了 Mindory 最初的应用框架。项目的技术栈是：

• 基于 Rust
• 基于 Tauri 构建

秒嗒提供了所见即所得的生成能力和强大的 Mock 功能，这对于快速原型验证非常有用。

Mock 设计观察

不过，它的 Mock 功能仍有优化空间。我们建议：

• 面向接口编程。
• 明确标注哪些部分是 Mock 实现。
• 清晰标记哪些组件必须被替换为真实服务。

否则，团队很容易踩坑，比如把 Mock 逻辑直接上线，或者忽略了那些临时的脚手架代码。

局限

• 初始生成的代码，同样需要重构才能用于生产。
• 不支持 Next.js 技术栈。
• 会自动引入百度云服务。
• 会注入秒嗒自己的专属插件。

这带来了厂商绑定、架构污染和可移植性下降的风险。

结论与 Manus 类似：做原型很强（可以替代 Axure 这类工具），但上线前必须仔细解耦。

四、主力大模型：豆包

我们实际使用的豆包模型是 doubao-seed-1-6-flash-250828。观察下来：

• 推理质量稳定且优秀。
• 性价比极高。
• 非常适合在生产环境中高频使用。

相比同类模型，它的长上下文表现更稳定，响应也更流畅。在高频推理的场景中，实用性非常突出。

五、Trae：不错的 Copilot，但生成代码必须严格 review

优点

• 免费使用。
• 适合快速生成一些代码片段。

局限

• 必须人工仔细 Code Review。
• 容易抓错上下文的重点。
• 可能会引入意料之外的 Bug。
• 偶尔会丢失之前已做的修改。

核心问题在于上下文对齐偏差。AI 有时会卡在旧的假设上，从而生成逻辑不一致的代码修改。因此，每一次 AI 提出的改动，都必须经过人工复审和回归测试。

六、整体研发体验：AI 是加速器，不是替代者

AI 工具极大地提速了以下环节：

• 框架脚手架搭建
• UI 生成
• 业务建模
• 文案撰写
• 结构原型搭建

它们尤其擅长：

• 快速产出第一版可运行代码。
• 探索多种架构方案。
• 生成重复的样板代码。

但我们必须保持清醒：

AI 生成的代码，默认不具备直接上线的条件。加速 ≠ 优化。

七、关键工程实践：AI 生成，人工把关

要让 AI 生成的系统真正可用，必须配上严格的工程纪律。

7.1 永远 Code Review 生成的代码

不要盲目信任 AI 的输出。重点检查：

• 硬编码的常量
• 隐藏的依赖
• 错误的导入
• 过度的数据拉取
• 冗余的抽象
• 架构上的“捷径”

记住，AI 的优化目标是生成“能跑的代码”，而不是“最优的代码”。

7.2 性能意识是必修课

AI 生成的实现通常功能正确、Mock 友好、可读性也不错，但普遍没有做性能优化。在以下场景中，这个问题尤其致命：

• 跨语言调用
• 重数据库系统
• 聚合逻辑
• 高频操作

7.3 跨语言优化（以 Tauri 为例）

典型的 Tauri 架构涉及 TypeScript ↔ Rust ↔ 数据库的多层调用。

AI 早期生成代码的常见问题是：

• 一次只查询一条记录。
• 产生多次来回的跨语言调用。
• 在应用层内存中进行数据过滤和聚合。
• 反复跨越语言边界。

这样写虽然能用，但性能极差。

更优的方案是：

• 使用单条 SQL 进行联表查询。
• 在数据库层面直接完成数据过滤。
• 用 SQL 函数进行聚合计算。
• 一次请求就返回结构化的最终结果。

核心原则是：最小化跨语言通信。数据在哪，计算就在哪。

7.4 把计算逻辑下沉到数据库

一个常见的反面模式是：

1. 查询原始数据。
2. 把大量数据加载到应用内存中。
3. 在应用代码里进行过滤、聚合。

后果就是内存暴涨、CPU 占用高、延迟增加、带宽浪费。

正确的做法是：

• 多用 SQL 的 JOIN / GROUP BY。
• 多用 COUNT / SUM / AVG 等聚合函数。
• 合理添加索引，用好 WHERE 条件。
• 深度优化查询语句。

数据库天生就擅长集合运算，而应用内存不是。 原则就是：在成本最低的地方做计算。

7.5 Mock 代码 ≠ 生产代码

AI 生成的脚手架通常使用简化的内存数据，会忽略索引、跳过查询规划，也没有批量逻辑。

上线前必须：

• 替换掉所有的 Mock 逻辑。
• 为查询字段加上合理的索引。
• 审查 SQL 执行计划。
• 对关键业务路径做基准测试。

7.6 测试是硬性要求

单元测试必须覆盖：

• 核心业务逻辑
• 价格计算
• 分析统计系统
• 边界和异常场景

只保证功能正确还不够，关键路径还要进行：

• 性能基准测试
• 压力测试
• 查询分析

7.7 交互改动必须做回归测试

AI 在修改代码时，可能会无意识地：

• 删除原有逻辑。
• 打断事件链。
• 错误地重置状态。
• 引入隐蔽的竞态条件。

因此，但凡涉及交互逻辑的代码更新，都要做完整的回归测试。

八、最终思考：与 AI 协同，而非被 AI 主导

总结来说，AI 工具是极强的加速器：

• 缩短第一版上线时间。
• 支持更快速的迭代。
• 降低编写样板代码的成本。
• 辅助进行产品战略思考。

但它们目前还做不到：

• 自动保证架构的完整性。
• 自动进行性能优化。
• 取代严谨的工程把控能力。

正确的心态应该是：

AI 负责加速迭代，人类负责把控正确性、可扩展性与性能。

所以，Mindory 并非由 AI 生成，而是在人类工程师持续监督下，与 AI 协同开发的产物。这种协作模式，或许正是未来高效开发的新范式。欢迎在 云栈社区 分享你的 AI 开发实战经验。