Agent Case Share
返回 Task
人机协作AI编程人机协作Next.js产品复盘

我是如何和 AI 编程助手一起，从 0 到 1 做出一个 AI Agent 案例分享平台的

重点记录用户如何通过提示词逐步表达需求，AI 编程助手如何拆解、判断、执行并完成最终 MVP。

luxu · 2026年6月1日

我是如何和 AI 编程助手一起，从 0 到 1 做出一个 AI Agent 案例分享平台的

这篇文章不是单纯介绍一个网站功能，而是复盘一次完整的人机协作开发过程。

我一开始只有一个比较模糊的想法：想做一个网站，专门分享各行各业使用 AI Agent 完成真实任务的案例。这个网站需要支持用户注册登录、发布案例、一个 Task 下包含多篇文章、评论留言，以及项目仓库链接。

整个开发过程，是我不断用自然语言描述需求，AI 编程助手不断帮我拆解、判断、实现、验证，最后把一个可以本地运行的 MVP 做出来。

一、我最初提出的需求

我的第一句话大概是：

我现在有一个需求，要写一个网站，主要需求是分享各种使用 AI agent 完成各行各业的 case，一个 task 可能由多篇文章组成，支持用户注册登录，对文件进行留言评论，以及发布项目仓库等。帮我先理清需求，以及有没有需要依赖安装的软件如 mysql python 等。

这个需求里其实包含了很多信息：

  1. 网站类型是内容分享平台
  2. 内容主题是 AI Agent 行业案例
  3. 核心内容单位不是单篇文章，而是 Task
  4. 一个 Task 可以由多篇文章组成
  5. 需要用户系统
  6. 需要评论系统
  7. 需要项目仓库发布能力
  8. 我还不确定技术栈和依赖环境

AI 编程助手第一步没有直接写代码，而是先把需求拆成了几个核心对象：

  • User：用户
  • Task / Case：任务案例
  • Article：文章
  • Comment：评论
  • Repository：项目仓库
  • File：文件或附件

这个拆解非常关键，因为它把我脑子里的“一个网站”变成了可以落地的数据模型和功能边界。

二、从需求到 MVP 范围

一开始如果直接做完整平台，范围会很大。

所以 AI 编程助手建议先做 MVP，也就是最小可用版本。

第一版先做：

  1. 用户注册和登录
  2. 首页案例列表
  3. Task 详情页
  4. 一个 Task 下多篇文章
  5. Markdown 文章发布
  6. 评论系统
  7. 项目仓库链接
  8. 分类和标签

暂时不做：

  • 在线协作编辑
  • 积分系统
  • 站内私信
  • AI 自动生成文章
  • 付费订阅
  • 复杂审核流

这个阶段的重点不是功能越多越好，而是先验证这个内容组织方式是否成立。

三、技术栈是如何确定的

一开始 AI 编程助手给了两个方向：

第一种是 Python 后端方案，例如 Django 或 FastAPI。

这种方案的优势是后端能力强，用户、权限、后台管理都比较成熟，适合内容平台。

第二种是 Node.js / Next.js 全栈方案。

这种方案的优势是轻量，前后端一体，开发体验简单，适合快速做出 MVP。

我进一步追问：

Next.js 这种方案是不是更简单轻量一些？

AI 编程助手判断后，建议我选择 Next.js。

原因是：

  1. 页面、接口、认证、数据库访问可以放在一个项目里
  2. 本地开发一个命令就能跑起来
  3. UI 开发速度快
  4. 后续接 AI 功能也方便
  5. 开发阶段可以用 SQLite，不需要一开始安装 MySQL

最终技术栈确定为：

Next.js
TypeScript
Prisma
SQLite
NextAuth.js
Tailwind CSS
Markdown

这个选择背后的思路是：先不要把基础设施搞重，先用最少依赖做出能跑的产品。

四、我说“可以，开始做”之后，AI 做了什么

当我确认：

可以，帮我用这个方案开始做

AI 编程助手没有先生成一堆代码，而是先检查当前目录。

它发现当前目录是空的，于是准备初始化 Next.js 项目。

但是开发过程并不是一路顺利，中间遇到了几个真实问题。

五、第一个问题：项目名不符合 npm 规范

初始化时，当前目录名是：

Agent_share

create-next-app 不接受包含大写字母的项目包名，所以初始化失败。

AI 编程助手的处理方式是：

  1. 不改我的根目录
  2. 先创建一个小写临时目录 agent-share-platform
  3. 在临时目录初始化 Next.js 项目
  4. 后面再把文件移动回根目录

这个处理比较稳，因为它没有强行改我的工作目录结构，也没有中断任务。

六、第二个问题：本机没有 pnpm

初始化项目时本来准备用 pnpm，但本机没有安装 pnpm，导致依赖安装失败。

AI 编程助手检查后判断：

  • Node.js 和 npm 是可用的
  • 没必要为了 MVP 额外安装 pnpm
  • 直接改用 npm 更简单

于是后续依赖安装全部改用 npm。

这里体现了一个实际开发里的取舍：不要为了工具偏好增加额外环境成本。

七、第三个问题：React 版本冲突

安装依赖时，又遇到了 React 和 Next.js 的依赖解析冲突。

模板生成的版本是：

"react": "19.2.4",
"react-dom": "19.2.4"

但 npm registry 当前可用版本是：

"react": "19.2.6",
"react-dom": "19.2.6"

AI 编程助手没有盲目使用 --force，而是先查询了 npm 上的真实版本，然后修正 package.json，再重新安装。

这一步很重要。

如果直接强行安装，后面可能会遇到更隐蔽的问题。先确认版本，再修正依赖，是更可靠的做法。

八、第四个问题：Prisma 7 的配置变化

数据库层选择了 Prisma + SQLite。

但初始化时安装到的是 Prisma 7。Prisma 7 对数据库 URL 的配置方式做了变化，旧的 schema 写法会报错。

对于这个项目来说，目标是快速完成 MVP，不是研究 Prisma 7 的新配置。

所以 AI 编程助手做了一个务实判断：

把 Prisma 固定到 6.x 稳定版本。

npm install @prisma/client@6.19.0
npm install -D prisma@6.19.0

然后继续使用更直接的 SQLite 配置：

DATABASE_URL="file:./dev.db"

这个决策的重点是：技术选择要服务于目标。当前目标是快速搭建一个可运行的网站，而不是追新版本。

九、AI 如何设计数据库模型

在需求明确后，AI 编程助手开始设计 Prisma 数据模型。

核心表包括：

User
Task
Article
Repository
Comment
Tag
TaskTag

其中 Task 是核心。

一个 Task 可以有：

  • 多篇文章
  • 多个项目仓库
  • 多条评论
  • 多个标签
  • 一个作者

Article 归属于 Task。

Comment 既可以挂在 Task 上，也可以挂在 Article 上。

Repository 归属于 Task。

这个模型对应了我最初的想法：不是做一个普通博客，而是做一个围绕任务案例组织的知识库。

十、AI 如何补齐示例数据

为了避免网站启动后是空白的，AI 编程助手写了 seed 数据。

示例账号是：

admin@example.com
demo123456

示例案例包括：

  1. AI Agent 自动完成客服质检与改进建议
  2. AI Agent 生成经营分析周报初稿

每个示例案例都包含：

  • Task 标题
  • 行业
  • 难度
  • Agent 技术栈
  • 文章
  • 项目仓库
  • 标签

这样网站一启动，就能看到平台最终想呈现的内容形态。

十一、AI 如何逐步实现页面

代码实现不是一次性完成的，而是按模块推进。

第一步是基础结构：

  • Prisma 单例
  • Auth.js 登录配置
  • 注册接口
  • 用户会话类型

第二步是共享组件：

  • 导航栏
  • 按钮
  • 标签 Badge
  • Task 卡片
  • 全局布局

第三步是公开页面：

  • 首页
  • 案例库
  • Task 详情页
  • 文章阅读页

第四步是交互功能：

  • 注册
  • 登录
  • 发布案例
  • 评论 Task
  • 评论 Article

第五步是验证：

npm run lint
npm run build

这种推进方式让我能清楚看到项目从底层数据、认证，到页面和交互，一层一层搭起来。

十二、发布功能是怎么设计的

我最初希望能发布项目仓库和文章。

AI 编程助手没有一开始就做复杂后台，而是做了一个最短发布路径：

用户登录后，可以在一个表单里创建：

Task
首篇文章
项目仓库链接
标签

这样虽然还不是完整 CMS，但已经能完成最核心的内容生产流程。

后续再扩展多文章编辑、草稿箱、审核流、图片上传，会更自然。

十三、文章和评论是怎么落地的

文章正文使用 Markdown。

好处是：

  1. 适合技术文章
  2. 支持标题、列表、代码块
  3. 存储简单
  4. 后续迁移方便

评论系统分成两类：

  • Task 评论
  • Article 评论

这对应两种讨论场景：

Task 评论更适合讨论整个案例是否有价值、能不能复用。

Article 评论更适合针对具体实现细节提问。

十四、构建时又遇到一个 Next.js 问题

项目快完成时，执行：

npm run build

发现登录页报错。

原因是客户端组件里使用了 useSearchParams，Next.js 要求它放在 Suspense 边界里。

AI 编程助手的处理方式是：

不在客户端表单里直接读 URL 参数，而是在服务端页面读取 callbackUrl，再传给客户端登录表单。

这样构建通过，也让页面职责更清晰。

十五、最终交付出来了什么

最后项目已经可以本地运行：

http://127.0.0.1:3000

完成的功能包括：

Next.js + TypeScript + Tailwind 项目
Prisma + SQLite 数据库
用户注册
用户登录
Task 案例列表
Task 详情页
文章阅读页
Markdown 渲染
项目仓库展示
Task 评论
文章评论
案例发布表单
Seed 示例数据
本地开发服务

验证命令也都通过：

npm run lint
npm run build

十六、后续我又让 AI 做了什么

网站完成后，我又提出：

帮我把整个项目我和你沟通的过程以及你的执行过程整理成一篇公众号的推文。

AI 编程助手先整理了一版偏项目介绍的文章。

然后我让它：

把文件保存到本地。

它就把文章保存成 Markdown 文件：

AI-Agent案例分享平台公众号推文.md

接着我又提出：

帮我上传到 http://127.0.0.1:3000/ 的页面上面新建一个文章。

AI 编程助手判断当前系统的数据模型里，文章必须属于一个 Task，所以它没有直接孤立创建文章，而是：

  1. 创建一个“平台建设复盘”Task
  2. 把公众号文章作为这个 Task 下的一篇 Article
  3. 写入 SQLite 数据库
  4. 验证文章页面返回 200

文章地址是：

http://127.0.0.1:3000/articles/wechat-agent-case-share-platform-build

这一步也体现了 AI 编程助手不是机械执行，而是会根据已有系统约束做合理映射。

十七、这次协作给我的启发

这次体验下来，我觉得和 AI 编程助手协作，最重要的不是一开始就写出完美提示词，而是持续把意图说清楚。

我的提示词大概经历了几个阶段：

第一阶段：描述想法。

我想做一个 AI Agent case 分享网站。

第二阶段：确认技术路线。

Next.js 是不是更简单轻量？

第三阶段：授权执行。

可以，帮我用这个方案开始做。

第四阶段：要求沉淀。

把过程整理成公众号推文。

第五阶段：把内容反向写入系统。

把文章上传到本地网站里。

也就是说，我并不是一次性写了一个超级复杂的提示词，而是像和一个工程师协作一样，逐步确认方向、缩小范围、让它执行、再让它整理成果。

十八、AI 编程助手真正有价值的地方

这次让我感受最明显的，不是 AI 能不能写代码，而是它能不能持续推进一个真实任务。

它做了几类事情：

  1. 把模糊需求结构化
  2. 给出合适的技术路线
  3. 在环境问题出现时排查原因
  4. 根据错误信息调整依赖版本
  5. 设计数据模型
  6. 编写页面和接口
  7. 添加 seed 数据
  8. 运行 lint 和 build 做验证
  9. 启动本地服务
  10. 把开发过程整理成文章
  11. 再把文章写回网站

这更像是一个可以执行的工程协作者，而不是一个单纯的代码片段生成器。

十九、总结

这次我和 AI 编程助手一起，从一个自然语言需求开始，最终做出了一个可运行的 AI Agent 行业案例分享平台。

这个过程里，我负责提出目标、确认方向、追加需求。

AI 编程助手负责拆解需求、判断技术栈、编写代码、处理报错、验证结果，并把过程沉淀成文章。

最终得到的不只是一个网站，还有一套可复用的人机协作方式：

先描述目标，再收敛范围；先做 MVP，再验证运行；先沉淀过程，再反哺产品内容。

这可能也是未来很多个人产品、内部工具和原型项目的开发方式：

一个人提出问题，一个 AI 工程助手持续执行，中间通过自然语言不断校准方向。

产品不是一次想清楚的，而是在对话和执行中逐步长出来的。