「项目实战」我用 Codex + GPT-5.5 + Trellis "氛围编程"，独立做了一个情侣厨房小程序

把家常饭，留给偏爱的人。

这是一篇 Vibe Coding 全栈实战复盘：我用 Codex + GPT-5.5 + Trellis，独立做完了「偏爱厨房」------一个面向情侣的微信小程序，前端 uni-app + Vue 3，后端 NestJS + Prisma + MySQL + Redis。AI 负责写代码，我负责设计需求和把关质量，每个需求跑完都亲自 Review 一遍才提交 Git。这套流程踩过的坑和总结的方法论，全在这里。

写在前面：Vibe Coding 到底靠不靠谱？

大家好，我是elk，「Vibe Coding（氛围编程）」这个词最近很热：你不再逐行敲代码，而是描述意图，让 AI Agent 把活干完。但凡真上手过的人都知道，纯靠「感觉」聊几十轮，项目很快就会失控------上下文丢失、需求漂移、改 A 坏 B、提交记录一团乱麻，最后你自己都说不清这堆代码是怎么长出来的。

所以与其再写一篇「AI 真香」的安利，我更想用一个跑通并上线的真实全栈项目回答一个实际问题：

当 AI 真能写大段代码时，「人」该站在哪个位置，才能让项目既跑得快、又不塌房？

我的答案是一套组合拳：Codex + GPT-5.5 负责写，Trellis 负责管，我自己负责 Review 和拍板。 下面用「偏爱厨房」这个前后端分离的全栈项目，把整套流程讲透。

先放一组真实统计，让你对规模有概念：

text 复制代码

前端 elk-order             后端 elk-order-service-nest
─────────────────────      ─────────────────────────────
uni-app + Vue 3            NestJS 10 + TypeScript
54 个 .vue / 33 个 .js     74 个 .ts 文件
~18,000 行业务代码          ~4,200 行 + 19 张数据表
82 次提交                   10 次提交

合计：≈ 2.2 万行代码 · 92 次提交 · 全程 AI 编码 + 人工 Review

一、项目是什么：偏爱厨房 🍓

「偏爱厨房」是一款面向情侣和亲密关系的互动厨房小程序。它把「今天想吃什么」这件很日常的小事，做成了两个人可以一起参与的流程：

一个人维护菜谱、接单做饭 ------ 饲养员 （userType = 0）
另一个人浏览菜单、下单点餐 ------ 吃货（userType = 1）
两人通过邀请码绑定 后，菜谱汇成同一个共享厨房，签到、订单、饭点记忆都被认真记录下来

它不是个玩具 demo，而是一条完整的全栈业务链路：从微信登录、情侣绑定，到菜谱管理、加购物车、下单、接单、烹饪中、完成订单，再到签到积分、烹饪日历、订阅消息提醒、首页皮肤切换------前端能点的每一步，后端都有真实的接口和数据表在支撑。

二、整体架构：一个全栈项目的全景

两个仓库同级放置，职责清晰：

text 复制代码

H-K-T/
├── hkt-applet                 # uni-app 微信小程序前端
└── hkt-applet-service-nest    # NestJS 后端服务
        │
        ▼
   MySQL（业务数据） + Redis（Token / 缓存） + 又拍云（图片视频）

数据流是典型的小程序全栈形态：

text 复制代码

微信小程序 ──HTTP──> NestJS 接口 ──Prisma──> MySQL
    │                   │
    │                   ├──> Redis（登录 Token、无 JWT）
    │                   └──> 微信开放接口（登录 / 订阅消息）
    └──直传──> 又拍云（头像、菜谱封面、视频皮肤）

前端结构（uni-app + Vue 3）

text 复制代码

hkt-applet/
├── api/ apis/      # 按业务模块切分的接口封装
├── components/     # 通用组件（Upload / Tabbar / CateList / Love ...）
├── hooks/          # 组合式逻辑（useAuthGuard / useHomeSkin ...）
├── config/         # 接口地址、主题色、订单状态、订阅模板
├── pages/          # 首页 / 登录 / 菜单 / 菜谱 / 购物车 / 订单 / 我的
├── stores/         # Pinia（user / order / recipe），本地持久化
└── utils/          # 请求封装、登录、邀请、微信授权、又拍云上传

技术选型：uni-app + Vue 3 Composition API + Pinia + uview-plus，样式用 SCSS + rpx，做了小程序自定义导航和安全区适配。

后端结构（NestJS 模块化）

后端是非常标准的 NestJS 分层，15 个业务模块各管一摊，互不打架：

text 复制代码

hkt-applet-service-nest/src/
├── common/         # 全局能力：响应拦截器 / 异常过滤器 / 守卫 / 装饰器
├── modules/
│   ├── auth/           # 微信登录、Redis Token
│   ├── users/          # 资料、角色切换、头像
│   ├── couples/        # 情侣绑定 / 解绑
│   ├── recipes/        # 分类、菜谱、食材、步骤
│   ├── cart/           # 购物车
│   ├── orders/         # 下单、状态流转、再来一单
│   ├── points/         # 积分账户、流水、每日签到
│   ├── cooking/        # 烹饪日历
│   ├── wallpapers/     # 首页皮肤、图片/视频
│   ├── notifications/  # 站内通知、订阅消息
│   ├── feedback/       # 意见反馈
│   ├── storage/        # 又拍云直传签名
│   ├── prisma/         # 数据库
│   └── redis/          # 缓存 / Token
└── prisma/schema.prisma  # 19 张数据表，363 行

技术选型：NestJS 10 + Prisma + MySQL + Redis（ioredis）+ class-validator，语言全程 TypeScript，文件走又拍云前端直传。

值得一提的两个工程化细节：

统一响应结构 ------全局 ResponseInterceptor 把所有返回都包成 { code, data, message }，前端请求层只认这一种格式，联调心智极低。
认证不用 JWT ------登录 Token 是随机 UUID 存 Redis，通过全局 DevAuthGuard 守卫拦截，简单可控，方便本地 mock 登录调试。

这套前后端结构不是我手动「整理」出来的，而是靠 Trellis 的编码规范（spec）约束，让 AI 每次写代码前都「先读家规再动手」自然长出来的。这正是下面要讲的重点。

三、重头戏：我的 Vibe Coding 全栈工作流

下面是这篇文章真正想分享的东西，我把它叫做 「PRD 驱动 + 自审提交」 的 Agent 开发流。

3.1 角色分工：谁干什么

text 复制代码

┌─────────────┐     ┌──────────────┐     ┌──────────────┐
│   GPT-5.5    │     │   Trellis    │     │      我       │
│  （大脑/写） │ ←→  │ （流程/记忆）│ ←→  │ （决策/Review）│
└─────────────┘     └──────────────┘     └──────────────┘
   Codex 作为                上下文注入              每个需求
   Agent 执行层              而非靠记忆            过一遍才提交

Codex + GPT-5.5：理解需求、写代码、改代码。前端 Vue 组件、后端 NestJS 接口、Prisma 表结构，都是它写的。
Trellis ：一套「项目操作系统」，负责把规范、任务、上下文注入给 Agent，而不是指望模型「记得住」。
我：设计需求（PRD）、做关键技术决策，以及最关键的------每个需求跑完，亲自 Review 一遍才提交 Git。

3.2 为什么必须有 Trellis：因为「记忆」是 AI 最不可靠的东西

Vibe Coding 最大的敌人不是「AI 写得烂」，而是上下文窗口有限 + 对话会被压缩。聊到第 30 轮，模型早忘了你第 3 轮定下的接口约定。前后端分离项目尤其致命------前端调的字段和后端返回的字段一旦对不上，就是无尽的联调地狱。

Trellis 的核心理念正好对症：

text 复制代码

1. Plan before code          ------ 先想清楚再写
2. Specs injected, not remembered  ------ 规范靠注入，不靠记忆
3. Persist everything        ------ 调研、决策、教训全部落盘成文件
4. Incremental development   ------ 一次只做一个任务
5. Capture learnings         ------ 每个任务做完，把新知识写回 spec

它在项目里就是这样一套目录：

text 复制代码

.trellis/
├── workflow.md     # 开发阶段、任务创建时机、技能路由
├── spec/           # 按「包 + 层级」划分的编码规范（前端/后端各一套）
├── tasks/          # 每个需求一个任务目录
└── workspace/      # 开发日志和会话轨迹

关键点：规范不是写在 README 里等人看，而是在 AI 写代码前，自动注入到它的上下文里。 每一次编码，AI 都「先读家规再动手」，于是 39 个任务下来，目录结构、命名、响应格式、错误处理，始终是同一套规则------这种一致性，靠人肉记忆根本做不到。

3.3 一个需求的完整生命周期

每个需求在 Trellis 里都是一个 task，流程固定：

text 复制代码

①  task create  →  创建任务，进入 planning
②  brainstorm   →  和 AI 反复讨论需求，迭代 prd.md
③  task start   →  PRD 定稿，进入 in_progress，开始写代码
④  implement    →  Agent 读 spec + PRD，产出前/后端实现
⑤  自审 Review  →  我亲自过一遍 diff
⑥  commit       →  确认无误才提交 Git
⑦  capture      →  把这次学到的新约定写回 spec

第 ⑤ 步是整套流程的灵魂。 AI 写得快，但它会自信地犯错------接口字段拼错、边界没覆盖、把不相关的调试代码也带上。我的铁律是：没有 Review 过的代码，绝不进 Git。 这也是为什么 92 次提交里，每条 commit message 都干净到能直接当 changelog 用（feat：【菜单】适配共享厨房菜谱权限 就是典型粒度）。

3.4 PRD 不是「写个标题」，而是把决策固化下来

一个需求做得好不好，80% 由 PRD 决定。我的 PRD 不只写「要做什么」，更重要的是这几块：

What I already know ：把已有的前后端现状交代清楚，AI 才不会重复造轮子、不会瞎猜接口。比如做「情侣绑定」时，我会明确写出「后端 /couples/bind 已实现，会校验不能绑自己/已绑定/对方已绑定」，AI 就不会去重写一遍校验。
Decision (ADR-lite) ：每个关键决策都写明 Context / Decision / Consequences（轻量级架构决策记录）。例如「微信小程序无法主动调起通讯录，只能用 <button open-type="share"> 触发转发」------把约束和取舍写下来，AI 的方案才不会跑偏。
Acceptance Criteria：可勾选的验收清单，Review 时逐条对照。
Out of Scope ：显式声明不做什么。这是控制 AI「热情过头」最有效的一招------它特别喜欢顺手帮你多写一堆你没要的功能。

心得：PRD 写得有多清楚，AI 就有多靠谱。你在 PRD 上偷的懒，最后都会变成 Review 时的债。

3.5 全栈联调：让前后端「说同一种语言」

前后端分离最怕「契约对不上」。我的做法是把接口契约直接写进 spec 和 PRD，让前后端两端的 AI 都被注入同一份约定：

后端统一响应 { code: 200, data, message }，由全局拦截器兜底；
前端请求层只认这一种结构，401 统一触发 Token 刷新；
共享厨房的权限（canManage 标记、订单必须由后端校验菜谱归属）写成成文规范，前后端共用。

于是即使前端任务和后端任务是分开两次跑的，字段也能对上------因为它们读的是同一份契约，而不是各自的「记忆」。

四、那些业务约定，全都沉淀成了规范

因为每个任务做完都会「把学到的写回 spec」，项目里的核心约定不是散落在某人脑子里，而是成文、可注入的。举几个真实例子：

共享厨房的权限模型：

text 复制代码

- 未绑定时，用户只能看到自己创建的菜谱和分类
- 绑定后，双方菜谱合并展示为共享厨房，但仍保留创建者归属
- 后端返回 canManage 标记，前端只展示可管理内容的编辑/删除入口
- 购物车和订单提交，必须由后端校验菜谱是否属于当前共享厨房

微信订阅消息的硬约束：

text 复制代码

- 必须由用户点击触发授权，不能后台静默授权
- 模板 ID 集中维护，前后端共用一份配置

这些约定一旦写进 spec，后续每个任务的 AI 都会被注入。结果就是：第 1 个任务和第 39 个任务，遵循的是同一套规则。

五、Vibe Coding 实战心得总结

做完一个前后端 2 万行的全栈项目，如果只留几条最有价值的经验，是这些：

1. AI 是「放大器」，不是「替代品」

它会把你的清晰放大成高质量代码，也会把你的含糊放大成一堆要返工的烂摊子。决策权必须握在自己手里。

2. 「规范靠注入，不靠记忆」是 Agent 工程的核心

别期待模型记得住 50 轮对话前的话。把规范、现状、决策写成文件，每次编码前注入。文件不会被压缩，对话会。

3. 每个需求自审后再提交，是质量的最后一道闸

AI 写得越快，Review 越重要。未经 Review 的 AI 代码不进主干。 这条纪律让提交历史干净、可追溯、可回滚。

4. PRD 里的 `Out of Scope` 比 `Requirements` 更重要

明确「不做什么」，能挡掉 AI 80% 的过度发挥。范围失控是 Vibe Coding 烂尾的头号原因。

5. 全栈项目，要把「接口契约」当一等公民

前后端分离最大的坑是字段对不上。把契约写进规范、双端注入，比任何「联调技巧」都管用。

6. 小步快跑，一次只做一个任务

39 个任务而不是 4 个大需求。任务越小，PRD 越好写，Review 越轻松，出错越好定位。

7. 把「教训」写回规范，让项目自己变聪明

每修一个 bug、每定一个新约定，都回写 spec。项目越往后做，AI 犯重复错误的概率越低------因为它「学过了」。

六、写在最后

Vibe Coding 不是「躺着让 AI 把活干了」，而是一次角色的重新分工：

重复的、机械的、翻译意图的体力活，交给 AI；设计需求、做技术决策、把关质量这些需要「判断力」的事，留给人。

「偏爱厨房」对我而言，既是给在乎的人做的一个小礼物，也是一次完整的方法论验证------当工具足够强，工程纪律反而变得更重要，而不是更不重要。 一个人能独立扛下前后端 2 万行的全栈项目，靠的不是 AI 多神，而是「人 + AI + 流程」这三者咬合得够紧。

如果你也准备用 AI Agent 认真做一个项目，希望这套 「Codex + GPT-5.5 写、Trellis 管、自己 Review」 的全栈流程能给你一点参考。

把家常饭，留给偏爱的人；把判断力，留给自己。🍓

项目：偏爱厨房｜前端 uni-app + Vue 3 + Pinia ｜后端 NestJS + Prisma + MySQL + Redis 工具链：Codex · GPT-5.5 · Trellis 如果这篇对你有帮助，欢迎点赞收藏，也欢迎在评论区聊聊你的 Vibe Coding 实践。

「项目实战」我用 Codex + GPT-5.5 + Trellis "氛围编程"，独立做了一个情侣厨房小程序

写在前面：Vibe Coding 到底靠不靠谱？

一、项目是什么：偏爱厨房 🍓

二、整体架构：一个全栈项目的全景

前端结构（uni-app + Vue 3）

后端结构（NestJS 模块化）

三、重头戏：我的 Vibe Coding 全栈工作流

3.1 角色分工：谁干什么

3.2 为什么必须有 Trellis：因为「记忆」是 AI 最不可靠的东西

3.3 一个需求的完整生命周期

3.4 PRD 不是「写个标题」，而是把决策固化下来

3.5 全栈联调：让前后端「说同一种语言」

四、那些业务约定，全都沉淀成了规范

五、Vibe Coding 实战心得总结

1. AI 是「放大器」，不是「替代品」

2. 「规范靠注入，不靠记忆」是 Agent 工程的核心

3. 每个需求自审后再提交，是质量的最后一道闸

4. PRD 里的 Out of Scope 比 Requirements 更重要

5. 全栈项目，要把「接口契约」当一等公民

6. 小步快跑，一次只做一个任务

7. 把「教训」写回规范，让项目自己变聪明

六、写在最后

4. PRD 里的 `Out of Scope` 比 `Requirements` 更重要