CSIT883 (JI125) System Analysis and Project Management 课程的项目大作业 Intelligent Campus Lost & Found Platform 终于接近尾声。回看这几个月的开发历程，它不仅是软件工程的实践，更是一部我与 AI 智能体之间项目管理与沟通的血泪史。
我的开发模式是典型的 AI 驱动型开发（Vibe Coding）：我负责把控项目进展、向 AI 提出需求，并在其协助下完成开发。但千万不要误以为这是偷懒或简单的事情，这其中充满了挑战和陷阱，而这些经验恰恰是这门课（系统分析与项目管理）最好的注脚。
核心心法一：工具的陷阱 —— “负资产”代码与模型的选择
在 AI 时代，我们面临的第一个陷阱就是 模型的选择。
1.1 便宜的模型才是最贵的
项目初期，我像“神农尝百草”一样，试遍了市面上的 AI 工具，包括 Cursor、Windsurf、阿里巴巴的 Qoder、字节跳动的 Trae，以及 Anthropic 的命令行 Agent 工具 Claude Code 等。我这样做最初是出于“不想花钱，想白嫖免费额度”的心理。
然而，低级别的模型（例如 GPT-3.5 级别）产出的代码充满了逻辑漏洞、幻觉库和过时的语法。低质量代码是项目中的 “负资产”，它会指数级增加后期的调试时间，最终导致我花费在弥补 Bug 上的时间成本和人力成本，远高于节省下来的模型费用。
Vibe Coding 第一定律： 要做 AI Driven 的项目，必须一开始就选择最强的模型。
最终，我转向了 Google 的 Antigravity，并在 IDE 中直接调用 Gemini 3.0 Pro、Claude Sonnet 4.5 和 Opus 4.5 等顶级模型,。只有这些高级别的模型，才能保证“一次做对”（Do It Right the First Time），这才是真正的效率。
核心心法二：架构的迷思 —— 为什么要“顺从”AI 的偏科？
在技术选型上，我经历了反复横跳的痛苦，因为我没有在一开始就告诉 AI：“代码都是由你来写”,。
2.1 AI 友好型架构的优先级
React 是亲儿子，Vue 是干儿子：AI 对 React/Next.js 生态的熟悉程度远超 Vue。虽然 Vue 紧随其后，但 React 的语料库和生态在英语世界占据主导地位，AI 更容易写出高质量的 React 代码,。我最终在重构时倾向于 Nuxt/Vue 全栈方案，但这确实是反其道而行之，增加了我需要教导 AI 如何使用小众技术栈的负担。
Python/TypeScript 是 AI 的首选语言：像 Java 和 Spring 框架，由于存在大量的模板代码，且企业级代码开源量不足，不适合 AI。而 Python (FastAPI) 对于我们的 “智能匹配系统” （涉及 scikit-learn、TF-IDF 等复杂算法）来说，几乎是不可替代的。让 AI 编写 Python 的算法逻辑，出错率极低。
2.2 上下文与“屎山”堆积的联系
大模型有一个致命的弱点：当输入上下文越长，输出就越不稳定。我发现当 Gemini 的上下文超过 60%（约 60 万 Tokens）时，它的输出就开始“说胡话”了，不太遵循指令。
因此，最适合 AI 的架构应该是尽量轻量级、代码量少、文件少、项目结构简单的全栈方案。
早期的前后端分离方案（FastAPI + Vue/Vite）就导致了频繁的 “跨域地狱”，这些反复出现的报错占据了 AI 宝贵的上下文窗口，降低了输出质量。
2.3 拒绝反复横跳
我最大的失误之一就是 在技术选型上“朝三暮四，反复横跳”。从 Naive UI 换到 Element UI，再到后期的 UnoCSS/DaisyUI 方案，每次重构，AI 都会在清理旧代码时留下残余，导致项目中残存着两三套代码和 三四个互相冲突的全局 CSS 文件,。这种混乱的样式冲突是项目后期 UI “难看”的根本原因。
核心心法三：UI 的幻觉 —— “白癜风”陷阱与样式控制
样式问题是 Vibe Coding 的第三个，也是最令人沮丧的陷阱。
我发现 AI 存在一个核心缺陷：它特别喜欢自己手写自定义的样式和组件，而不是复用 UI 库（如 Element Plus）里成熟的方案,。
当我要求 AI 编写暗色主题时，它无法从全局层面实现一致性。网页很快变得像得了 “白癜风” 一样难看：深色背景中夹杂着大量突兀的白色按钮或下拉菜单，而且文字对比度不足,。
为了定位问题，我不得不手动使用 F12 开发者工具找到具体的 <div> 标签和类名，再发截图和指令给 AI，让它“一个组件一个组件地改”。这完全违背了使用 AI 的高效初衷。
教训： 必须在一开始就严格限制 AI 自由发挥 CSS 的冲动，并明确要求其多复用库里的成熟方案，不要自己造轮子。
核心心法四：创新的取舍 —— 实用主义与 AI 知识滞后
4.1 最小代价换取最高演示效果
为了满足评分标准中的创新性（Innovation），我们必须得有 AI 元素。最初部署 YOLOv5 的想法被其巨大的依赖包（几 GB）和复杂的部署难度打消。
最终的 “高成功率”方案 是使用 ONNX Runtime + MobileNetV2。这个方案模型仅十几兆，CPU 也能飞速运行，部署简单。它能识别出标签（如 ["backpack", "water bottle"]），既有了 AI 的噱头，又没有引入沉重的运维负担，完美解决了演示需求。
通过 Antigravity 的协助，我们最终实现了 多模态加权匹配算法，其中包含了 AI 编写的 TF-IDF 文本相似度 和 Levenshtein 编辑距离 计算，甚至加入了 线性衰减的时间接近度 机制。
4.2 AI 的知识滞后性
在重构过程中，我要求 AI 使用 Nuxt 4.2.2，但 AI 却坚持认为 Nuxt 4 还在开发中，不建议使用。这暴露了 AI 在处理前沿技术时可能存在的 滞后性。
教训： 如果是严肃的场景和任务，建议用主流的、成熟可靠的“老技术”，而非小众且 AI 语料库不足的“新技术”。
总结：AI 时代的生存法则
Vibe Coding 不是乱写，而是学会如何“驾驭”最强的模型，避开 AI 的弱点，用最小的代价换取最高的 Presentation 效果。
如果项目能重来，我会这样开局：
- 工具链：Google Antigravity + Gemini 3.0 Pro (或 Claude Opus 4.5)。
- 技术栈：FastAPI (算法核心) + Next.js/Nuxt (全栈一体化) + SQLite (零部署成本)。
- 开发理念：严格遵循 UI 库规范，拒绝手写 CSS，并采用 ONNX Runtime + MobileNetV2 实现轻量级 AI 创新,。
Tags: #CSIT883 #SystemAnalysis #Antigravity #GeminiPro #FastAPI #VibeCoding #AI编程 #项目复盘