偏重：零基础、学生、自由职业者

返回总目录：00 总览与导读（MOC）　|　上一章：04 第三部分 — 案例选择的确定原则　|　下一章：06 第四部分 篇章二 — 产品经理与设计师的魔法口袋

这一篇章的六个案例，是整本书最适合"零基础起步"的部分。它们大多停留在技术栈的低阶到中阶，用自然语言就能跑通核心 70%。但请别因此轻视它们——每个案例的 30% 都藏着真实的工程陷阱，正是这些陷阱，把"玩具"和"能用的东西"区分开来。

阅读提示

每个案例固定三栏：【关键工具】【70% Vibe】【30% Engineering】。时间有限就直接看 30%——那里是这本书最值钱的地方。

案例 1 · 智能冰箱：剩菜定制食谱与卡路里追踪器

📘 本案例有深度详解（含真实提示词与全程调试）：案例01 · 智能冰箱剩菜食谱与卡路里追踪器

【关键工具】 Bolt.new + Gemini Vision API

【70% Vibe】

这是一个几乎人人都用得上的生活小应用。你打开手机摄像头，对着冰箱里剩下的食材拍一张照片上传，AI 自动识别出"半颗西兰花、两个鸡蛋、一块豆腐"，然后即时生成一份搭配得当、还带卡路里估算的交互式食谱。整个前端——上传按钮、识别结果卡片、食谱排版——用 Bolt.new 一句话就能生成得相当漂亮。视觉识别这一步，则交给 Gemini 的 Vision API。从"想法"到"能在手机上点开的样子"，可能只需要十几分钟。

【30% Engineering】

光鲜的演示背后，有两道真实的坎。

第一道是多食材识别的置信度过滤。图像识别从来不是非黑即白，模型对每个识别结果都会给出一个"置信度"分数。如果你不加处理地把所有结果都显示出来，用户就会看到"冰箱里有一只长颈鹿（置信度 11%）"这种荒唐结果。你需要设定一个合理的阈值，把低置信度的噪声过滤掉，并设计好"什么都没识别到"时的兜底提示。这是典型的、AI 不会主动替你想的边界处理。

第二道是前端拍照权限的跨端兼容。"调用摄像头"这件事，在 iOS Safari、安卓 Chrome、微信内置浏览器里的表现各不相同——有的需要 HTTPS、有的弹权限框的时机不同、有的干脆不支持。要让你的应用在用户的真实设备上都能顺利唤起相机，需要细致地处理这些兼容性差异。这部分恰恰是"在我电脑上明明能用"却在别人手机上失灵的重灾区。

破局心法

凡是涉及"AI 给出概率性结果"的应用（识别、推荐、预测），置信度过滤与兜底设计几乎都是那个被忽略的 30%。先问自己：当 AI 不确定、或完全错了的时候，我的界面该显示什么？

案例 2 · "心流"数字时钟与流媒体白噪音 PWA 轻应用

【关键工具】 Lovable

【70% Vibe】

一个极简又高颜值的番茄钟：大大的数字时钟、可自定义的拟物化主题（木质、磨砂玻璃、深空黑），还能把雨声、咖啡馆白噪音、海浪自由混音。这种"纯前端、重设计"的应用，正是 Lovable 的强项——你描述氛围，它就还你一个赏心悦目的界面。作为 PWA（渐进式网页应用），它还能被"添加到主屏幕"，用起来像个真的 App。

【30% Engineering】

这个看似简单的小工具，30% 全在"看不见的地方"。

核心难点是 Service Worker 的配置。番茄钟最怕什么？后台锁屏后倒计时停了。当用户切到别的 App 或锁屏，浏览器为了省电会"冻结"普通的页面计时器。要让倒计时在后台依然准确，你必须正确配置 Service Worker，并采用"记录开始时间戳、用时间差反推剩余时间"的方案，而不是天真地每秒减一。这是 PWA 开发里一个经典的、新手必踩的坑。

另一处是用户偏好的本地持久化。用户调好的主题、白噪音组合、专注时长，应当在关掉网页再打开后依然记得。这需要用 LocalStorage 把偏好存在本地，并处理好"第一次访问时没有任何数据"的默认状态。功能不难，但少了它，应用就从"贴心"变成了"每次都要重设的麻烦"。

案例 3 · 个人专属学术文献 / 小红书爆款自动化拆解机

【关键工具】 Windsurf + DeepSeek API

【70% Vibe】

你丢给它一个网页链接或一份 PDF，它自动提炼出结构化笔记——要点、论据、关键数据——再一键转成思维导图。对学生、研究者、内容创作者来说，这是把"读一篇长文"的时间压缩好几倍的利器。借助 Windsurf 操控多文件、调用 DeepSeek 的长文本能力，搭起这个流程的主干并不难。

【30% Engineering】

真正的硬骨头，全在"输入侧"的脏活里。

首先是长文本的乱码与断句处理。真实世界的网页和 PDF 充满了奇怪的换行、被切断的句子、混入的广告文字。直接喂给模型，轻则摘要质量下降，重则上下文被噪声占满。你需要在送进模型前做一轮清洗和重新断句。

其次是防爬虫机制的绕过。很多优质内容站点有反爬措施，普通请求会被拒之门外或返回一个空壳页面。如何合规地获取到正文，是一个需要专门处理的环节。

最棘手的是 PDF 解析中的表格陷阱。PDF 里的表格在机器看来往往只是一堆错位的文字坐标，直接提取会得到面目全非的乱序文本。要正确还原表格结构，需要专门的解析策略——这是无数"PDF 转文字"应用最终翻车的地方。

flowchart LR
    A[网页/PDF 链接] --> B[抓取正文<br/>⚠️ 反爬]
    B --> C[清洗与断句<br/>⚠️ 乱码]
    C --> D[表格结构还原<br/>⚠️ 坐标错位]
    D --> E[DeepSeek 提炼]
    E --> F[结构化笔记 → 思维导图]
    style B fill:#ffe5e5,stroke:#d33
    style C fill:#ffe5e5,stroke:#d33
    style D fill:#ffe5e5,stroke:#d33

破局心法

"输入是脏的"是数据类应用永恒的 30%。AI 能漂亮地处理干净的输入，但真实世界的输入从来不干净。把功夫下在送进模型之前的清洗上，往往比优化提示词更能提升最终质量。

案例 4 · 动态外币汇率与 Wise 账单自动对账看板

【关键工具】 v0 + Supabase

【70% Vibe】

一个优雅的资产看板：多币种余额一目了然，漂亮的图表展示汇率走势，还能自动算出跨境转账的手续费损耗。对经常处理外币、用 Wise 收付款的自由职业者和出海创业者来说很实用。前端用 v0 生成精致的图表界面，数据存在 Supabase（一个开箱即用的云数据库），主体很快就能搭好。

【30% Engineering】

两处 30% 都和"钱"与"安全"有关，半点马虎不得。

第一是实时汇率 API 的缓存策略。汇率数据要从第三方 API 获取，而这类 API 几乎都有调用次数限制，超了就要付费甚至被封。如果你每次用户刷新页面都去请求一次，账单会很快失控。正确的做法是设计缓存——比如每隔几分钟才真正请求一次，其余时间都读缓存。这是"省钱"也是"防止服务被打挂"的关键。

第二是 Supabase 的行级安全策略（RLS）。这是个事关隐私的致命点。如果不配置 RLS，你的数据库默认可能允许任何拿到接口的人读到所有人的资产数据——这是初学者用 Supabase 时最常见、也最危险的漏洞。你必须明确设置规则：每个用户只能读写属于自己的那一行数据。资产隐私的护城河，就建在这里。

安全红线

用任何"开箱即用"的云数据库（Supabase、Firebase 等）时，默认配置往往是不安全的。"能跑起来"和"能安全地上线"之间，隔着一整套权限策略。这是第四部分会反复出现的 30% 主题。

案例 5 · 微信 / 飞书"夸夸群"与情绪树洞自主 Bot

【关键工具】 OpenClaw + 微信 / 飞书 Webhook

【70% Vibe】

一个住在群里的暖心机器人：它能感知到群里有人情绪低落，自动用幽默、温暖、高情商的语言去回应、破冰、夸夸对方。搭建对话逻辑、调教"人设"语气，借助 OpenClaw 这类消费级 Agent 配合群机器人 Webhook，主体流程相当顺畅。

【30% Engineering】

让一个 Bot"能说话"很容易，让它"在真实群里长期稳定地待着"很难。

首先是防刷限流。如果不加控制，机器人可能因为某条消息疯狂触发、刷屏，既惹人烦又可能触发平台处罚。你需要设计限流：同一时间窗口内最多回复几次、对同一个人多久回应一次。

其次是平台风控规避。微信、飞书的官方接口对机器人行为有严格的风控，频繁、异常的调用可能导致接口被限制甚至封号。如何让机器人的行为"像个正常的群成员"，在规则内活动，是能不能长期运行的生命线。

最后是上下文记忆的截断。为了"高情商"，机器人需要记住一些对话上下文；但如果无限地把历史消息塞进模型，token 消耗会爆炸式增长，成本飙升、响应变慢。你需要一套策略，智能地保留关键上下文、丢弃冗余历史——这是所有"有记忆的 Bot"都要解决的工程问题。

案例 6 · 基于本地 Markdown 的 Obsidian 智能关系网标签推荐器

📘 本案例有深度详解（含真实提示词与全程调试）：案例06 · Obsidian 智能标签与双链推荐器

【关键工具】 Claude Code + Node.js

【70% Vibe】

对所有用 Obsidian 记笔记的人来说，这是个梦想工具：它扫描你本地的整个笔记库，理解每篇笔记的语义，自动为那些"孤岛笔记"推荐合适的双向链接（bi-links）和标签，让你散落的知识自动连成网。这是一个典型的"高阶 CLI"案例——用 Claude Code 直接在终端里操作你的本地文件系统，配合 Node.js 处理 Markdown。

【30% Engineering】

这个案例的 30%，是一道地道的工程性能题。

核心难点是本地文件系统的大批量读写性能。一个用了几年的笔记库可能有上千个文件。如果程序设计得粗糙，一次全量读取、逐个比对，会非常慢，甚至卡死。你需要认真考虑读写的效率——批量处理、控制内存占用、避免重复 IO。

与之配套的是增量扫描算法。你不可能每次运行都把整个库重新分析一遍——那既慢又浪费。正确的做法是记录上次扫描的状态，每次只处理"新增或修改过"的笔记。如何准确地判断"哪些变了"、如何维护这份状态，是让工具从"能用一次"变成"能天天用"的关键。

破局心法

凡是涉及"处理大量本地文件"的工具，增量化几乎总是那个决定成败的 30%。第一版"全量扫描"很容易写，但只有"只处理变化部分"的增量版本，才真正可用。这个思路在本书后面的工程类案例里还会反复出现。

篇章小结

篇章一的六个案例，覆盖了从图像识别、PWA、文档解析、金融看板、群机器人到本地文件处理的日常场景。把它们的 30% 串起来看，你会发现几条反复出现的工程主线：

mindmap
  root((篇章一的<br/>30% 工程主线))
    概率性结果
      置信度过滤
      兜底设计
    脏输入处理
      清洗与断句
      反爬与解析
    安全与隐私
      数据库权限 RLS
      平台风控规避
    性能与持久化
      本地缓存
      增量扫描

这些主线不会随着场景改变而消失——你会在后面三个篇章里，看到它们换了身衣服、再次登场。

👉 继续阅读：06 第四部分 篇章二 — 产品经理与设计师的魔法口袋