给阿嬤一封来自云端的信（上）

用 AI 替你写一封给阿嬤的家书。项目本身很简单，但从模型调用、云函数、数据库、静态托管到一键部署，全部基于云开发，AI 工具使用云开发提供的大模型完成。
本文不以功能为重点，而是以工程化思维为线索，拆解一个应用从构思到上线的完整链路。

一、爱在心口口难开

二刷《给阿嬤的情书》，依旧眼泪汪汪，推荐大家去看！

电影里，谢南枝替人写了一辈子侨批。那些来找她的同乡，并不是没有话说，只是不知道怎么把心里话落到纸上。

隔着山海，隔着谋生的日子，隔着一张薄薄的信纸，一句“我想你”常常要绕很远，才敢写出来。

云开发团队做了一个小应用，叫「给阿嬤的情书」。

由 AI 为你落笔家书，不编造虚假情节，只收拢你细碎零散的点滴倾诉，规整成一封完整可寄、适宜分享的家书。

二、产品闭环

产品流程：填称呼、选关系、填写内容、选风格，AI 生成后可分享或投递树洞。

用户输入往往只有几句零散的话：

阿嬤，我很久没回家了。小时候你总在巷口等我放学，给我做橄榄菜配白粥。我现在工作很忙，但很想你。

AI 生成的目标不是模板化地写一句“亲爱的阿嬤我非常想念您”，而是围绕用户提供的真实细节展开：

阿嬤，见字如面。

近来天热，不知你胃口可还好。

我常想起小时候放学，远远看见你站在巷口，手里像总有一碗白粥等我。那时候只觉得橄榄菜香，如今才知道，原来那是有人惦记的味道。

我在外头一切都好，只是忙起来时，总觉得日子过得太快，快到连一句想你都常常忘了说。

阿嬤，等我回去，再陪你吃一碗白粥。

写信完成之后，即可到分享页面，将信件分享给他人，或者投递到公共树洞。

三、工程链路才是真正的考验

「给阿嬤的情书」看起来只是一个超轻量级网页应用，但从产品搭建到产品上线，不可避免地面临以下工程问题：

• 模型调用
  前端不能直接暴露模型 Key，需要服务端代理。

• Prompt 编排
  不同关系、不同风格、不同输入内容，需要在服务端统一拼装请求。

• 结构化输出
  模型返回内容需要可解析，不能只返回一段自然语言。

• 数据持久化
  生成后的信件需要入库，才能被分享页和树洞再次读取。

• 访问链路
  分享链接需要根据id还原完整信件。

• 内容安全
  开放输入需要处理不合适的称呼和表达。

• 部署编排
  云函数、环境变量、前端构建、静态托管需要一次性部署到位。

如果拆分能力独立搭建，项目会离散为：模型 API、Node 服务、数据库、对象存储、静态托管、CI/CD、环境变量管理等多个模块，运维复杂。
本项目采用云开发一体化建设，全链路收口统一实现：

• 云函数
  负责服务端逻辑，包括模型调用、Prompt 编排和返回解析。

• 云开发 AI 网关
  负责接入大模型。

• NoSQL 数据库
  负责保存每一封生成后的信。

• 静态托管
  负责承载 React 前端。

• CodeBuddy
  负责把开发、调试、部署串起来。

它表面上是一个"写信"应用，实际跑通的是一个完整的 AI 应用工程闭环。

四、云开发：应用能调，AI 工具也能接

在 AI 应用开发里，云开发更关键的价值，是把模型能力也纳入同一个开发环境。

项目中，loveletter云函数通过云开发 AI 网关调用hy3-preview模型生成信件正文。

云开发 AI 网关兼容主流 AI 协议，调用方式接近常见的大模型 API：配置 Base URL、API Key、Model Name 即可请求。

云开发 AI 网关支持多种主流协议：

这意味着，除了应用里的云函数可以调模型，任何支持自定义模型端点的 AI 编程工具都可以通过云开发 AI 网关调用模型。

其中CodeBuddy 原生集成了云开发，开箱即用，可以直接部署云资源。

其他工具如
Cursor、Claude Code、Codex、Trae、Cline、GitHub Copilot 等，只需配置Base URL和API Key即可接入。

五、云函数：用服务端代理模型调用

项目核心云函数loveletter。它接收前端传来的to、relation、words、style，在服务端完成 Prompt 编排，然后请求云开发
AI 网关。

constENV_ID=process.env.TCB_ENV||process.env.SCF_NAMESPACE;constAI_ENV_ID=process.env.AI_ENV_ID||ENV_ID;constAI_BASE_URL=`https://${AI_ENV_ID}.api.tcloudbasegateway.com/v1/ai/cloudbase`;constAI_API_KEY=process.env.AI_API_KEY;constMODEL='hy3-preview';asyncfunctiongenerateLetter(messages){constresp=awaitfetch(`${AI_BASE_URL}/chat/completions`,{method:'POST',headers:{'Content-Type':'application/json',Authorization:`Bearer${AI_API_KEY}`,},body:JSON.stringify({model:MODEL,messages,temperature:0.8,max_tokens:2000,}),});if(!resp.ok){consttext=awaitresp.text();thrownewError(`AI 网关返回${resp.status}:${text}`);}constdata=awaitresp.json();returndata.choices?.[0]?.message?.content?.trim()||'';}

服务端代理带来的工程收益：

• AI_API_KEY放在云函数环境变量中，不暴露到浏览器侧。

• 前端只调用云函数，不直接请求模型网关。

• Prompt 编排、结构化输出解析、内容审核都可以在服务端统一处理。

• 模型生成结果可以直接写入云开发 NoSQL。

• 数据库返回的_id可以作为分享页和读信页的唯一入口。

前端调用保持轻量：

constres=awaitcloudbase.callFunction({name:'loveletter',data:{to,relation,words,style},});constresult=res.result;constcontent=typeofresult.body==='string'?JSON.parse(result.body):result;

用户看到的是一封信；技术实现上，是云函数、AI 网关、数据库和前端路由之间的一次完整协作。

六、上线流程编排化

AI 应用部署涉及多个步骤：云函数部署、环境变量注入、前端构建、静态托管上传。

CodeBuddy 和云开发集成后，可以把这些步骤编排起来。在 CodeBuddy 中直接说：

帮我部署本项目。

它会执行：检查云开发环境、部署云函数、注入环境变量、构建前端、上传静态托管、输出访问地址。

云开发把 AI 应用需要的后端能力收在一起，CodeBuddy 再把这些能力接入开发与部署流程。

七、Prompt 约束

模型、后端和部署跑通之后，信写得好不好，仍然取决于 Prompt 设计。

本项目不希望生成“标准、空泛、煽情”的 AI 作文，因此在loveletter中对风格做了明确约束：

constSTYLE_HINT={warm:'基调：温情家书。'+'语言质朴克制，不堆砌形容词，用具体的生活细节代替空泛抒情。'+'比如写"前日晚饭烤番薯，三个孩童吃得欢喜"，而不是"我非常想念你"。'+'句式偏短，口语化但不粗糙，带一点文言的温润感。'+'每段只写一件小事或一个牵挂，段与段之间留白。',};

这里最重要的不是“写得感人”，而是把产品希望呈现的内容质感拆成可执行规则：

• 忠于用户输入，不凭空编造。
• 用生活细节代替抽象抒情。
• 句子短一点，留白多一点。
• 可以润色，但不要把别人的回忆写假。
• 不让模型自由发挥到偏离产品定位。

Prompt 是产品规则的一部分。前端负责交互体验，云函数负责服务端编排，Prompt 则负责定义生成内容的边界。

小结

本项目功能明确：写一封家书。

但值得展开的不是"AI 可以写信"，而是这句话背后的工程链路：

• 云开发把模型接入、Serverless 运行时、数据存储、静态托管收敛到同一个环境，避免能力离散。

• 云开发 AI 网关同时服务应用端和开发端，模型、鉴权、额度可以统一管理。它既可以通过 SDK 在服务端调用，也支持接入各类 AI 编程工具（查看完整列表），配置 Base URL 和 API Key 即可使用。

• CodeBuddy把云资源部署编排进开发工作流，从"代码写好了"到"项目上线了"通过一条指令完成。

AI 应用开发多出的不只是一个模型接口，而是模型接入、后端、数据、托管和部署被重新放到了一条链路里。

下篇继续讲更细的工程问题：结构化输出如何保证稳定解析，如何把称呼规范和内容边界写进模型调用，以及 AI 工具通过一条指令完成部署背后的工程化流程。

在线体验

案例代码