Mini Court 小法庭 MVP 开发手册：一个 LLM 场景化产品是怎么从 0 到 1 搭起来的

前段时间把一个一直想做的小产品落了地，名字叫 Mini Court 小法庭。

它不是一个特别宏大的项目，说白了就是围绕“生活纠纷裁决”这个场景，做一个能让用户发帖陈述、评论讨论，再由大模型给出初审和复审结果的 MVP。

这篇不准备写成宣传文，而是把当时做这个东西时比较关键的技术和产品决策整理下来，留作后面复盘，也方便以后做类似产品时少走弯路。

1. 先定义产品边界：MVP 到底要解决什么

我做这个产品时，给自己定的边界很明确：

要做的

• 用户发帖陈述纠纷
• 其他用户评论讨论
• 基于用户原帖做一次初审
• 融合评论区观点做一次复审
• 支持结果分享
• 留出后台治理能力

暂时不做的

• 复杂社交关系
• 长链路 IM
• 多模型路由编排
• 复杂推荐系统
• 付费系统

原因很简单：MVP 阶段最怕什么都想做，最后什么都做不完。

所以我一开始就把核心链路定成：

发帖陈述 → 评论讨论 → Bot1 初审 → Bot2 复审 → 分享传播

只要这条链路是通的，这个产品就算站住了。

2. 为什么这个场景适合 LLM

不是所有产品都应该硬套大模型。

我觉得这个场景适合的原因主要有三点：

1. 用户输入天然是开放文本

生活纠纷本来就很难结构化，适合让模型先做文本理解和归纳。

2. 结果不是唯一正确答案

裁决类场景更适合做“观点整理 + 规则化表达”，而不是追求绝对标准答案。

3. 评论区本身就是高价值上下文

用户评论能提供额外视角，这很适合做第二阶段裁决。

所以我最后设计成了一个双阶段工作流：

• Bot1：基于原始帖文生成初审结果；
• Bot2：吸收评论区观点后生成复审结果。

这样做的好处，是把“用户原始陈述”和“公共讨论补充”拆开处理，结果会更稳一些。

3. 技术栈为什么这么选

我最后选的是这套：

• 后端：NestJS
• ORM：Prisma
• 数据库：PostgreSQL
• 反向代理：Nginx
• 部署：Docker Compose
• LLM 接入：统一封装为服务层

选择逻辑其实很务实。

NestJS

适合快速把：

• 用户系统
• 帖子评论
• 后台管理
• 审计日志
• 权限控制

这几块都搭起来，模块化也比较清楚。

Prisma + PostgreSQL

一方面开发体验好，另一方面对这种关系明确的业务数据很合适。后面做迁移、种子数据、后台管理都顺手。

Docker Compose

MVP 阶段特别适合。服务不多，但需要稳定跑起来，Compose 管理就够了。

4. 我当时拆出来的核心模块

后端如果一开始不分模块，后面会越来越乱。

我最后大概拆成了下面几块：

src/
  auth/           # 登录、鉴权、JWT
  users/          # 用户信息
  posts/          # 发帖、详情、列表
  comments/       # 评论相关
  judgments/      # 初审/复审结果
  llm/            # 大模型调用封装
  admin/          # 后台治理
  rbac/           # 角色权限
  logs/           # 审计日志
  common/         # 公共响应、异常处理、工具函数

这样拆的目的不是为了“看起来高级”，而是为了后面两件事：

1. 改需求时不至于牵一发动全身；
2. 后台治理和用户主链路分离。

5. 数据模型我会怎么设计

MVP 阶段不需要过度抽象，但几个核心表一定要先想清楚。

我当时比较核心的实体大概有：

User

• id
• nickname
• avatar
• role
• status
• createdAt

Post

• id
• userId
• title
• content
• status
• viewCount
• createdAt

Comment

• id
• postId
• userId
• content
• status
• createdAt

Judgment

• id
• postId
• round（initial / final）
• inputSnapshot
• outputJson
• modelName
• createdAt

AdminLog

• id
• adminId
• action
• targetType
• targetId
• detail
• createdAt

这里我有一个明确要求：裁决结果尽量结构化。

也就是不要只存一整段自然语言，而是尽量让模型输出 JSON，再做展示层渲染。

比如可以要求输出：

{
  "summary": "纠纷摘要",
  "plaintiff_view": "甲方主要观点",
  "defendant_view": "乙方主要观点",
  "decision": "初步裁决",
  "reason": ["理由1", "理由2"],
  "risk_hint": "风险提示"
}

这样后面无论是前端展示、分享卡片、二次统计，都会方便很多。

6. 双阶段裁决工作流怎么落地

这部分是我自己觉得最关键的地方。

第一阶段：Bot1 初审

输入内容：

• 原帖标题
• 原帖正文
• 必要的用户补充信息

输出内容：

• 纠纷摘要
• 双方争议点
• 初步判断
• 理由说明

第二阶段：Bot2 复审

输入内容：

• Bot1 的初审结果
• 评论区若干高质量评论
• 原始帖文摘要

输出内容：

• 最终复审意见
• 是否采纳评论区新观点
• 最终理由列表
• 风险和建议

这里最容易出问题的是评论区太乱，所以我当时做了几件事情来控成本和提稳定性：

1. 截断

评论太长就截断，不然 token 直接爆。

2. 去重

类似表达只保留一份，减少模型重复读取。

3. 限条数

只取前 N 条有效评论，避免无意义堆料。

4. 结果缓存

同一帖子的相同阶段结果，优先走缓存，降低重复调用成本。

这一套做完以后，输出会稳定很多，费用也更可控。

7. 后台治理为什么必须早点做

做内容类产品，一个很常见的错误就是把后台治理放到最后。

但实际上只要有用户发言，就一定会遇到：

• 不当内容
• 恶意刷帖
• 重复评论
• 管理员操作留痕

所以我在 MVP 阶段就加了下面几项：

1. Admin 登录

后台和普通用户逻辑分开，不混用权限。

2. RBAC

至少区分超级管理员、内容管理员等角色。

3. 内容下架

帖子、评论都要支持状态切换。

4. 审计日志

谁在什么时候下架了什么内容，一定要有记录。

MVP 可以简，但不能没有治理。

8. API 设计上，我会坚持的几个原则

1. 前后端边界清楚

不要把一堆业务逻辑写进 controller。

2. LLM 服务统一封装

后面无论你换模型、换提示词、换重试逻辑，都不应该影响业务层。

3. 响应格式统一

成功和失败都走统一响应格式，前端处理会轻松很多。

4. 状态字段提前预留

像帖子状态、评论状态、裁决状态，别等以后再补。

9. 一个最小可运行的部署方式

MVP 阶段我更喜欢一台服务器先跑起来，再逐步优化。

docker-compose.yml 大致会包含

• app
• postgres
• nginx

基本流程

docker compose up -d
npx prisma migrate deploy
npx prisma db seed

Nginx 负责

• 反向代理
• 静态资源转发
• HTTPS 入口（如果后面加证书）

这套方案的好处是：简单、直观、便于迁移。对个人 MVP 足够用了。

10. 我做完以后最大的几个感受

第一，产品一定要先站在用户链路上看

不是你技术上能做什么，而是用户第一步进来到底会不会玩。

如果核心链路不顺，再好的模型都只是摆设。

第二，大模型输出一定要尽可能结构化

不然前端展示、缓存、二次处理都很麻烦。

第三，治理能力不是锦上添花

一旦有 UGC，治理就是基础设施。

第四，MVP 最怕过度设计

很多功能明明可以后面再做，但人就是忍不住想“一次做全”。

这对个人开发尤其危险。

11. 如果后面继续迭代，我会优先做什么

如果继续往下做，我大概率会优先补这几项：

• 更细的评论筛选和质量评分；
• 更可控的提示词和多轮重试机制；
• 分享页优化；
• 用户举报与审核流程；
• 数据统计看板；
• 更完善的异常监控。

这些比一开始就上复杂推荐系统更实际。

最后

我做 Mini Court 这个项目时，一个很深的感受是：

LLM 产品真正难的，往往不是把模型调起来，而是把“产品链路、数据结构、治理、成本、稳定性”这些工程问题一起压住。

如果只会调用接口，那最多算做了一个 demo；只有当整个链路真的跑通，用户能用，结果可控，后台能管，部署能稳，这个东西才算一个像样的产品。

这篇就先记到这里。后面如果把它继续迭代下去，再回来补更细的部分。