7.0 KiB
title, slug, description, date, draft, comments, tags
| title | slug | description | date | draft | comments | tags | |||
|---|---|---|---|---|---|---|---|---|---|
| 19天上线网站，插件，桌面应用全家桶，一份非主流AI Coding实战报告 | ai-coding-development-workflow-case-study | 一份关于 AI 编程的实战报告。记录了19天内使用 AI 辅助开发网站、插件和桌面应用的完整流程。文章总结了一套将 AI 作为“领域专家团队”的实用工作流，并指出了 AI 在技术决策和复杂调试中的局限。适合希望在实际项目中高效使用 AI 编程的程序员。 | 2025-10-08 06:06:00 | false | true |
|
还记得我之前发起的AI Coding邀请吗？这些天过去，项目上线了，脑子也清醒了。今天不扯情怀，不聊心路历程，咱们开诚布公，就硬核地聊聊这19天里，我用AI当“结对编程”的“队友”，是怎么把 PromptHub 这个项目从一个想法，变成一堆能跑的代码的。
这份报告，可能跟你想的**“Vibe Coding”**不太一样。这里没有魔法，全是工程、取舍，还有一堆踩坑之后才搞明白的“原来如此”。
架构选型：AI当“脚手架”，我当“决策者”
一开始，我就给 PromptHub 定了个挺变态的目标：Web、Chrome插件、Electron桌面端，三端同步开发。后端用Next.js的API Route，数据库从SQLite起步，随时准备切生产环境。
这套技术栈，换以前，光是把package.json配平、各个环境的tsconfig.json搞定，就够我喝一壶的。
我的做法是，把AI当成一个超高级的脚手架生成器。我不是问它“我该用什么技术”，而是直接下命令：
“我要一个Next.js项目，用TypeScript。集成Drizzle ORM，数据库用SQLite。给我加上JWT认证，实现Google和GitHub的OAuth登录。再把Stripe的计费框架搭起来，给我留好接口。”
9月17号，AI花了大概一个下午，基于简易的多语言模板项目，给我吐出了一个基本可用的后端框架。这不是简单的代码片段，这是架构的实例化。它把那些最繁琐、最重复的“胶水代码”给干完了，让我能直接开始写核心业务。
第一个感悟：在项目启动阶段，AI最大的价值是消除“启动摩擦力”。
开发方法论：告别“Vibe Coding”，拥抱“原子任务”
网上那种“Vibe Coding”（一句话开发）的视频，看看就行了，谁信谁天真。企业级的项目开发，靠的是严谨的工程学。我摸索出的模式，我称之为**“原子任务”或者说“搭积木”**。
开发一个功能，我会把流程拆解到极致，然后开好几个AI对话窗口，并行推进：
-
• 窗口A（数据库专家）：“根据我的需求，设计
prompts表结构，用Drizzle ORM的语法写出来。” -
• 窗口B（后端专家）：“这是表结构，给我写出对应的增删改查API，用Next.js的API Route实现，做好权限校验。”
-
• 窗口C（前端专家）：“这是API接口，用React和Tailwind给我写一个能调用这些接口的管理页面组件。”
这种模式的好处是：
-
1. 上下文隔离：每个窗口的AI都只专注于一件事，不会因为上下文过长而“精神错乱”。
-
2. 职责单一：代码解耦做得特别好，AI很少会写出前后端混杂的意大利面条代码。
-
3. 并行效率：我在等后端API写好的时候，已经可以开始构思前端组件了。
第二个感悟：别把AI当成一个无所不能的大神，把它当成一个由多个“领域专家”组成的小团队。
硬核踩坑：那些AI也救不了我的瞬间
AI Coding不是银弹。在某些领域，特别是底层和配置相关的，它犯的错比我还离谱。
1. 数据库选型：Turso vs Supabase
我一开始为了尝鲜，用了分布式的 Turso 数据库。听起来很酷，对吧？结果数据同步延迟高到离谱，用户创建一个提示词，刷新好几次都出不来。我尝试加了consistency=strong参数，屁用没有。
最后果断弃坑，换回了基于PostgreSQL的 Supabase。这个决策，AI给不了你。你必须懂数据库的一致性模型，才能明白Turso的异步特性跟我的业务场景是根本冲突的。
2. Next.js的useEffect死循环
这是个经典问题。在管理页面，接口被无限循环调用。我把代码丢给Qwen3，它给我改了半天，还是没解决。
最后还是得靠自己。我分析了useEffect的依赖项，发现里面混入了太多动态的状态，导致了连锁反应。我手动重构了它，只保留了最核心的user?.personalSpaceId作为依赖。问题解决。
然后，我把正确的解决方案喂给AI，告诉它：“以后遇到类似问题，要这样改。” 这其实是在反向训练AI，让它学习我的最佳实践。
3. Chrome插件的权限黑洞
插件开发，AI基本就是个小白。content.js死活不加载、localStorage数据不通……这些问题，AI给的答案全是错的。
最后还是老老实实去翻Chrome开发者文档，搞明白了host_permissions和scripting权限的区别，才把问题解决。
第三个感悟：AI擅长“实现”，但不擅长“决策”和“调试”。特别是在涉及底层原理、平台特性和性能瓶颈的地方，最终拍板和debug的还得是你自己。
我的模型“工具箱”
我从不迷信任何一个模型。我的策略是动态切换，把合适的工具用在合适的地方。
-
• 架构设计 & 复杂Bug修复：首选 Gemini 2.5 Flash。免费，而且在解决像Next.js水合错误这种疑难杂症时有奇效。
-
• UI/UX代码实现：Claude 4.1 是不二之选。它的CSS审美和代码实现能力是最好的，但也是最贵的，我只在关键页面用它。
-
• 日常CRUD和组件开发：Qwen3 Coder Plus 性价比最高，干体力活儿任劳任怨。
-
• 数据处理和脚本生成：在逆向Google AI Studio的API，做数据迁移时，我用了 Kilo 配合Gemini，让它分析JSON结构，自动生成Python脚本，效率极高。
总而言之，这19天的开发，与其说是“AI编程”，不如说是一场“人机协同的极限编程”。AI是那个敲代码飞快的实习生，而我，是那个需要时刻把控方向、做出关键决策、并在他搞砸时能出手救场的架构师。
这种模式下，开发者的核心价值，从“写代码”，转向了**“提问题”、“做决策”和“系统设计”**。
这可能，就是我们开发者未来的样子吧。
这是网站链接，有兴趣的可以去试试: https://prompt.hubtoday.app/
也可加我微信进群交流：justlikemaki