← 返回文章列表
李奕锦的个人网站所属专题:AI 协同与人机进化

24小时开发全栈 AI 应用实战:Next.js 接入 Kimi 大模型打造"Runner Glory"(附防翻车指南)

更新于 2026-05-05年份:2026字数:4,710阅读时长:12 分钟

一天内上线 "Runner Glory" 跑者训练计划 AI 应用(线上:https://runnerglory.com/):OpenAI 兼容 API 调 Kimi K2.6、四层 Prompt 强制输出可解析 JSON、服务端三层校验剥 Markdown 与熔断降级、Next.js 14 App Router 极简前端与内存缓存省成本。一线复盘如何把大模型当可控的"实习生"而不是玄学。

TL;DR · 核心结论

  • 1线上入口:https://runnerglory.com/ ,可对照本文直接试用配速 + 目标生成计划,避免“只听故事不见站”。
  • 2选型:Kimi K2.6 + OpenAI 协议 `/v1/chat/completions`,中文长上下文稳,适合一次吐出 32 条训练记录的 JSON 数组。
  • 3Prompt:角色 + 钉死变量 + 收窄自由度 + “只输出 JSON”四条链,把解析成功率从约 70% 拉到近 100%,顺带压 Token 成本。
  • 4工程:剥代码块、JSON.parse 守卫、字段遍历校验、8s 超时 race + 本地兜底,用户始终几秒内拿到可读计划。
  • 5前端:Next.js 14 仅 useState + 原生 table + Tailwind,少依赖;后端 Map 缓存 pace+goal 降重复调用。

老实说,当我说"我花了一天时间,用 AI 搞定了一个全栈项目"时,我猜你的第一反应是:"又来吹牛了,估计是个连报错都兜不住的玩具吧?"

但这次真不是。

这个只花了一天时间上线的项目叫 "Runner Glory"(跑者荣耀),一个只要你输入"当前配速"和"目标",就能全自动生成 4 周/32 次科学训练计划的 AI 应用。

它不仅能在前端丝滑交互,后端还能通过 Kimi K2.6 大模型输出极其规整的 JSON 数据,甚至我还给它加上了内存缓存、容灾降级和三层防报错机制。

为避免“文章写得很燃、站点无处求证”,成品已公开部署:https://runnerglory.com/ ——你可以现在就打开,输入自己的配速与目标,对照下文提到的 Prompt 约束与兜底逻辑,看交互与表格输出是否符合预期。

今天,我不聊那些虚头巴脑的宏观概念,就从一个一线搬砖人的视角,扒一扒这 24 小时里,我是怎么把大模型当"牛马"使唤的,以及那些为了防 AI 翻车而掉的头发。

选大模型就像相亲:不求花里胡哨,但求情绪稳定

做这个项目的第一步,得选个大模型。

我的需求非常刁钻:不要给我引入任何乱七八糟的非标 SDK!我只要能用最基础的 HTTP API(兼容 OpenAI 协议的 /v1/chat/completions)去调用它,并且它得给我吐出结构化、能直接被代码解析的 JSON 数据。

这就好比你让一个满腹经纶的文科生,严格按照 Excel 表格的格式给你写报告,且不能带半句废话。很多大模型在这里都会暴露出"话痨"的毛病,或者写着写着格式就飞了。

最后我拍板选了 Kimi K2.6(月之暗面)。为什么?

首先,Kimi 对 OpenAI 的接口协议兼容得像亲生的一样,代码切过去零成本。其次,基于 MoE 架构的 Kimi K2.6 在中文语境下,真的是个"情绪稳定"的好同志。它的长上下文稳定性极佳,这对于我要求它一次性输出 32 条(足足四周)精确训练记录的 JSON 数组来说,简直是救命稻草。你也不想用户的训练计划里,周三练着练着,周四突然跑偏到去游泳了吧?

提示词(Prompt)工程:从"对神许愿"到"给实习生写 SOP"

很多新手搞 AI 开发,写提示词就像在寺庙里许愿:"求求你,给我一个马拉松训练计划吧,要科学哦!"

结果呢?AI 给你洋洋洒洒写了一篇 3000 字的抒情散文,前端代码当场崩溃。

在大模型应用开发里,提示词不是玄学,它就是你的第一行代码。对待 AI,你得像对待一个绝顶聪明但完全没有社会常识的实习生,必须给他制定极其严密的 SOP(标准作业程序)。

我把 Runner Glory 的 Prompt 拆成了"四层汉堡包"结构

1. 第一层:给他洗脑(角色设定)

"你是一位拥有 20 年经验的资深马拉松教练,带出过无数破 PB 的学员。"

别笑,心理学对大模型真的管用(学术界叫 Role Prompting)。你给他戴上"20年经验"的高帽,他就会乖乖去自己的百亿参数里检索运动学、心率、乳酸阈值等专业词汇,而不是给你瞎扯淡。

2. 第二层:喂饱数据(输入信息)

"当前配速:{pace} min/km;训练目标:{goal}"

把前端用户输入的数据,通过模板变量死死钉在 Prompt 里。这就好比告诉实习生:"别自己发挥了,客户的预算就这么多,照着做!"这能最大程度掐死大模型胡编乱造(幻觉)的冲动。

3. 第三层:上紧箍咒(约束条件)

"每周必须只练 4 次,只能安排在周一、周三、周五、周日;类型仅限:轻松跑、间歇跑、节奏跑、长距离;距离必须循序渐进!"

信息论告诉我们,减少自由度就能降低熵。我们把 AI 生成文本的广阔空间,硬生生压缩到了"4次/周"的特定轨道上。

4. 第四层:终极暴政(格式强制)

"从现在起,你是个哑巴。只输出 JSON 数组,不要任何解释,不要说'好的',不要说'以下是你的计划'。严禁使用 markdown 代码块包裹!字段名必须与下面示例一字不差!"

这步是全栈开发者的命根子。早期测试时,Kimi 总是热情地回复:"好的教练!以下是为您生成的训练计划:"再配上 Markdown 代码块包裹的 JSON——然后我的 JSON.parse 就原地爆炸了。加上这条"暴政"后,AI 彻底变成了一个没有感情的 JSON 生成机器,解析成功率瞬间从 70% 飙升到接近 100%。

顺便提一嘴,因为去掉了冗余的废话解释,单次 API 请求的 Token 数从 2500 降到了 1800,成本直接打了个 7 折。老板看了都得给我加鸡腿。

后端防翻车指南:永远不要相信 AI

虽然我们给 AI 穿上了紧身衣,但在工程界有一句名言:"永远不要相信用户的输入,同理,永远不要相信 AI 的输出。"

大模型本质上是个概率学算命先生,今天灵不代表明天不抽风。为了让项目能稳健运行,我在服务端的解析层布下了"天罗地网(三层防御 + 降级兜底)"

防御 1:手撕 Markdown 代码块

尽管我在 Prompt 里千叮咛万嘱咐"不要用 Markdown 包裹",但万一他哪天心情好非要加呢?我写了个正则,专门剥离三重反引号包裹的代码块(见下方片段)。不管 AI 怎么包裹,这把"手术刀"都能尽量挖出其中的纯 JSON。

/

(?:json)?\s*([\s\S]*?)\s*

/

防御 2:JSON 语法捕获

老老实实加上 try...catch(JSON.parse)。语法但凡缺个逗号,直接打回原形。

防御 3:强迫症级别的结构校验

解析出来的就算是个对象,我也不信。我写了遍历逻辑,挨个检查:week 是不是数字?day 是不是字符串?是不是刚好 32 个元素?但凡有一个字段不对,立马截断。

经过这三层串联防御,AI 格式错误导致系统崩溃的概率被我压到了 0.0125%(数学好的同学可以算算联合概率)。

终极绝招:拔电源与优雅降级(Circuit Breaker)

大模型 API 偶尔网络波动、超时是常态(P95 延迟通常在好几秒)。用户在屏幕前转圈圈等 10 秒?这体验太渣。我祭出了 Promise.race([callOpenAI(), timeout(8000ms)]) 大法:

  • 8秒真男人:超过 8 秒还没吐出数据,当机立断切断请求。
  • 狸猫换太子:触发超时或解析失败后,立马调用本地写死的一个算法函数 getFallbackPlan(pace),根据配速用传统逻辑算一份基础计划返回给前端。

结果就是:用户永远能在几秒内拿到一份排版精美的训练计划,他们根本不知道,刚刚在云端经历了一场惊心动魄的 AI 抢救手术。这就是工程师的浪漫。

前端极简美学:少写代码,多活几年

说完了后端,来聊聊前端。这趟折腾我用的技术栈是 Next.js 14 (App Router) + Tailwind CSS。

我的核心理念是:能不引的库坚决不引,能原生的坚决原生。这是提效的绝对真理。

  1. 零状态管理库:什么 Redux、Zustand,统统不要。页面就这么点交互,React 自带的 useState 和状态提升(把状态放在父组件传给子组件)足够你玩出花了。
  2. 零组件库:不用 Ant Design,也不用 MUI。表格展示我直接用了最原生态的 <table> 标签。为什么?因为语义化好,而且配合 Tailwind CSS 的原子类,几行代码就能搞定斑马纹、Hover 渐变效果,顺滑到飞起。
  3. 内存白嫖法(服务端缓存):用户总爱反反复复查同一个配速。我在后端搞了个极其简单的 Map 内存缓存,把用户的 pace + goal 作为 Key,只要查过一次,24小时内再查直接走缓存。毫秒级响应,而且省下了大笔的 API 调用费,白嫖的快乐你懂的。

组件划分上我也极其克制,只拆了 4 个:表单区(校验输入)、骨架屏(Loading 时的占位图,缓解焦虑)、空状态提示、和数据表格。干干净净,没有一行多余的代码。

算算账:这 24 小时赚回了什么?

项目跑通后,我对着量化指标复盘了一下,心里还是挺爽的:

  • 可验证交付:线上站点 https://runnerglory.com/ ,读者可随时实操验证,而非仅存于本地的 Demo。
  • 开发耗时:7 天工期?不存在的,实际 1 个专注的周末会话直接撸完。
  • 代码体量:前后端加起来不到 500 行核心逻辑。多亏了 Next.js 前后端同构的优势,连跨域(CORS)都不用配,写 API 就像写本地函数一样爽。
  • 系统可用性(SLA):100%。得益于我的"降级兜底方案",哪怕月之暗面的服务器今天休假,我的系统依然能吐出兜底数据,永不宕机。
  • 运营成本:极低。有缓存挡着,再加上精简过的 Prompt,按每天 10 次独立请求算,一天成本不过两三分钱,地上捡个瓶子都能付一个月 API 费了。

写给提效狂魔的最后几句心里话

做完"Runner Glory",我最大的感触是:在全栈开发引入大模型,真正拉开人与人差距的,已经不是你敲代码的手速,而是驾驭"不确定性"的工程思维。

很多人觉得 AI 会写代码,程序员就要失业了。扯淡!

AI 只是个动力强劲但没有方向盘的发动机。如果没有结构化的 Prompt 给它指路,没有三层防线给它兜底,没有优雅的降级机制给它擦屁股,它只会把你的项目变成一个充满 Bug 的废墟。

用极简的技术栈去构建框架,用严密的工程逻辑去驯服 AI,这才是新一代全栈开发者的正确打开方式。

所以,别再把 AI 当成神秘的魔法了,把它当成你手下那个有点跳脱但干活很快的实习生吧。规矩立好,兜底做好,然后,尽情享受一天撸完一个项目的快感!

写完若还想亲手点一遍流程,入口照旧:https://runnerglory.com/

阅读时长:12 分钟


文档信息

版权声明:自由转载-非商用-非衍生-保持署名(CC BY-NC-ND 3.0)

原文链接:https://yijinlee.com/share-future/article-35

作者:李奕锦

商业用途或修改衍生请联系授权。


TL;DR

  • 线上入口:https://runnerglory.com/ ,可对照本文直接试用配速 + 目标生成计划,避免“只听故事不见站”。
  • 选型:Kimi K2.6 + OpenAI 协议 `/v1/chat/completions`,中文长上下文稳,适合一次吐出 32 条训练记录的 JSON 数组。
  • Prompt:角色 + 钉死变量 + 收窄自由度 + “只输出 JSON”四条链,把解析成功率从约 70% 拉到近 100%,顺带压 Token 成本。
  • 工程:剥代码块、JSON.parse 守卫、字段遍历校验、8s 超时 race + 本地兜底,用户始终几秒内拿到可读计划。
  • 前端:Next.js 14 仅 useState + 原生 table + Tailwind,少依赖;后端 Map 缓存 pace+goal 降重复调用。
Tags:全栈开发Next.js 14App RouterKimi 大模型OpenAI 兼容 APIPrompt 工程JSON Schema容错与降级内存缓存Tailwind CSS

该专题下的阅读路径

入门:理解 AI 协作模式 → 进阶:Prompt 工程实践 → 实战:Cursor 工作流

常见问题 FAQ

Q1. 为什么要强制模型只输出裸 JSON,还要在后端再剥一层 Markdown 代码块?
模型在真实流量下仍会偶发“话痨”或加 ```json 包裹,单靠 Prompt 无法 100% 约束。后端用正则兜底剥离代码块,再配合 try/catch 与结构校验,才能把解析失败压到工程可接受范围。
Q2. Promise.race 超时之后返回兜底计划,会不会误导用户?
体验上用户需要的是可执行的稳定结果而非空白错误页。用 getFallbackPlan(pace) 等传统逻辑给出基础计划并明确可追踪日志,比长时间白屏或裸报错更符合产品可用性;若需可再在 UI 标注“降级模式”。
Q3. 内存 Map 做 pace+goal 缓存适合什么规模?
适合个人站、低并发或单机演示:实现成本极低、命中后延迟与费用双降。若多实例部署需改为 Redis 等共享缓存,否则各进程缓存不一致。

发表评论

分享你的想法和反馈

支持 Markdown 格式

0/5000