核心结论：Vibe Coding 真正有价值的地方，不是“让 AI 替你写代码”，而是把一个模糊想法快速推到可运行、可复现、可维护的状态。最近我借助这种方式连续做了四个开源项目：
daily-ai、term-cheat、html-ppt、claude-desktop-buddy-bridge。它们看起来方向不同，本质上都在解决同一个问题：把个人工作流里反复出现的痛点，沉淀成可以复用的工具。
为什么要把这四个项目放在一起讲
这四个项目不是一次性规划出来的“产品矩阵”，更像是连续几次真实需求驱动下的工程实验。
- daily-ai：每天自动抓 GitHub 热门 AI 项目，用本地 LLM 总结后推送到微信。
- term-cheat：把 Vim、tmux、kitty 的常用快捷键做成一个可搜索、可收藏、可复制的在线速查表。
- html-ppt：用纯 HTML/CSS/JavaScript 做技术培训课件，浏览器打开即可演示。
- claude-desktop-buddy-bridge：把 Claude Code CLI 的敏感操作审批接到 M5StickC Plus 实体设备上，用按键 approve / deny。
它们分别覆盖了信息获取、终端效率、知识表达、AI 安全控制四个场景。对我来说，这正好构成了个人 AI 工程化工作流的四个侧面：
| 项目 | 解决的问题 | 技术关键词 | 最适合借鉴的点 |
|---|---|---|---|
daily-ai |
每天跟踪开源动态太耗时间 | GitHub Actions、本地 LLM、Tailscale、PushPlus、uv | 自动化信息摄取与本地模型总结 |
term-cheat |
终端工具快捷键记不住、查找效率低 | 单页 HTML、localStorage、搜索过滤、复制 | 小工具产品化，离线可用 |
html-ppt |
技术培训课件制作成本高、复用性差 | HTML、CSS、JavaScript、GitHub Pages | 把课程变成可交互网页资产 |
claude-desktop-buddy-bridge |
CLI Agent 敏感操作审批体验割裂 | Claude Code Hook、BLE、M5StickC Plus、Python daemon | AI 权限控制的硬件化与 fail-open 设计 |
项目一：daily-ai，每天自动生成开源项目早报
daily-ai 的动机很直接：GitHub 上每天都有大量新项目，靠人工刷 Trending、搜索 topic、看 README，效率很低，而且容易遗漏。
这个项目做了一条自动化链路：
graph LR
GA[Actions 定时] --> GS[GitHub Search]
GS --> PY[筛选项目]
PY --> TS[Tailscale]
TS --> LLM[本地 LLM]
LLM --> SUM[中文摘要]
SUM --> PP[微信推送]
它的价值不只是“定时推送”，而是把三个关键点打通了：
- 信息源可配置：通过 GitHub Search 查询语法控制主题，例如
topic:ai、language:rust、created:>=2026-03-01。 - 总结在本地完成：模型跑在自己的机器上，GitHub Actions 只通过 Tailscale 访问本地服务。
- 交付到熟悉入口：PushPlus 直接推送到微信，不需要每天打开额外 dashboard。
我比较看重的是它的可调试性。项目里不只放了主脚本，还配了 debug_chat.py、debug_speed.py、debug_native.py 这类连接/API 调试脚本。很多自动化项目真正难的不是主流程，而是网络、token、模型服务、限流这些边缘问题。把调试工具也一起沉淀下来，后面复用成本会低很多。
适合扩展的方向：
- 增加多主题订阅，例如 AI Agent、Local LLM、DevOps、IoT。
- 对项目做去重和历史趋势统计，避免每天重复推送。
- 把摘要分成“值得关注”“可试用”“仅观察”三个等级。
- 接入 Notion，把高价值项目自动归档到知识库。
项目二：term-cheat，把终端快捷键变成可搜索工具
term-cheat 是一个典型的小而实用的 Vibe Coding 项目。需求很简单：做一个 Vim、tmux、kitty 快捷键速查表。
如果只是 Markdown 表格，当然也能用。但真正影响体验的是这些细节：
- 顶部 Tab 切换三类工具。
- 搜索框实时过滤快捷键和说明。
- 常用项可以点星收藏，并保存到
localStorage。 - 点击快捷键行即可复制。
- 分组可以折叠，搜索时自动展开。
- Vim 条目带模式标签，例如 Normal、Insert、Visual、Command。
flowchart LR
U[搜索过滤] --> TAB{Tab 切换}
TAB --> V[Vim 快捷键]
TAB --> TM[tmux 快捷键]
TAB --> KT[kitty 快捷键]
V --> COL[分组折叠/展开]
TM --> COL
KT --> COL
V --> CP[点击复制]
TM --> CP
KT --> CP
V --> FAV[星标收藏]
TM --> FAV
KT --> FAV
FAV --> LS[(localStorage 持久化)]
这个项目说明了一个很重要的点：很多个人工具不需要后端、不需要数据库、不需要复杂框架，单文件 HTML 就足够交付。
Vibe Coding 在这种场景下非常合适，因为 UI 结构、数据组织和交互逻辑都比较明确。人的重点应该放在“到底哪些快捷键值得收录”“分组是否符合使用习惯”“搜索结果是否足够快”这些产品判断上，而不是一行行写 DOM 操作。
我会把这类工具归为“个人工作台组件”。它们未必需要做大，但能不断降低日常操作摩擦。
项目三：html-ppt，用网页方式沉淀培训课件
html-ppt 的定位是“轻量级 HTML 幻灯片演示工具”，用于技术培训讲义和交互式课程。
它的核心思路是：课件不一定非要用 PowerPoint 或 Keynote。对技术内容来说，HTML 反而有几个明显优势：
- 代码、图表、交互演示可以直接放在页面里。
- 版本管理天然友好，Git diff 比二进制 PPT 更可控。
- 部署简单，GitHub Pages 或任何静态站点都能承载。
- 学员无需安装软件，浏览器打开即可。
- 同一份材料可以同时作为演示、讲义和归档。
项目目前已经有主页、课程卡片、ppts/ 目录和 htmlppt-prompt.md。更有意思的是，它不只是一个页面项目，也是一套”提示词模板”。也就是说，以后做新课件时，可以让 AI 根据这套规范生成统一风格的 HTML PPT。
flowchart LR
PM[htmlppt-prompt.md] --> AI[AI 按模板生成]
AI --> MC[主页 + 课程卡片]
MC --> PP[ppts/ 课件目录]
PP --> GH[GitHub Pages 部署]
GH --> STU[学员浏览器打开]
PP --> REUSE[模板复用]
这类项目的长期价值在于内容资产化。一次培训如果只留下一份 PPT，复用空间有限；如果沉淀成网页课件，后面就可以持续补充交互示例、链接、代码块、练习题，甚至接入在线测验。
适合的使用场景：
- 内部技术分享。
- AI 工具使用培训。
- 本地大模型部署实战课。
- DevOps、网络、IoT 这类需要图示和命令演示的课程。
项目四：claude-desktop-buddy-bridge，把 AI 审批搬到实体按钮
claude-desktop-buddy-bridge 是四个项目里工程味最重的一个。
Anthropic 官方的 claude-desktop-buddy 可以让 M5StickC Plus 变成 Claude 的物理审批按钮，但它主要面向桌面应用。CLI 用户的问题是：Claude Code 在终端里执行敏感操作时，审批仍然发生在命令行上下文里。
这个 bridge 做的事情是：
flowchart LR
CC[Claude Code] --> Hook[Permission Hook]
Hook --> Daemon[cdbb daemon]
Daemon --> BLE[BLE NUS]
BLE --> M5[M5StickC Plus]
M5 --> Btn[approve / deny]
Btn --> Daemon
Daemon --> CC
它真正体现工程质量的点在边界处理：
- 通过 Claude Code 原生 Hook 接入，不修改业务项目。
- daemon 不运行时 fail-open，回退到 Claude Code 自己的权限对话框。
- 自动扫描广播名以
Claude开头的 BLE 设备。 - 多个并发 hook 请求串行排队，避免抢设备。
- 处理中文和非 ASCII 字符，规避固件点阵字体导致的崩溃。
- 检测 EOF 竞争，Claude Code 提前终止 hook 时能清空设备显示。
- BLE 链路异常后退出，由 launchd/systemd 接管重启。
这不是一个“炫技硬件小玩具”。它解决的是 AI Agent 越来越常见的权限边界问题：当模型可以读文件、写文件、执行 shell、调用网络时，人类审批不能只停留在终端里一行 y/N。把审批动作放到实体按钮上，会让“我正在授权什么”这件事更有仪式感，也更不容易误触。
这四个项目背后的共同方法
复盘下来，我认为 Vibe Coding 要想真正落地，关键不是模型多强，而是人的工程约束是否明确。
1. 先把问题说窄
不要一开始就说“帮我做一个平台”。这四个项目的起点都很窄：
- 每天推送 GitHub AI 项目。
- 查 Vim/tmux/kitty 快捷键。
- 用网页做培训课件。
- 用 M5StickC Plus 审批 Claude Code 操作。
问题越窄，AI 越容易一次生成可运行原型；原型越早跑起来，后面调试和迭代越有抓手。
2. 明确运行环境
个人项目最容易翻车的地方是环境假设不清楚。比如：
daily-ai要考虑 GitHub Actions、Tailscale、本地 LLM 服务、PushPlus token。term-cheat要保证纯前端、离线可用、浏览器兼容。html-ppt要能直接部署到 GitHub Pages。claude-desktop-buddy-bridge要面对 macOS/Linux、BLE 权限、Claude Code Hook、launchd/systemd。
给 AI 的提示词里，如果不写这些边界，它会默认选择“看起来最顺手”的实现，而不是你真正能长期维护的实现。
3. 原型之后必须工程化
Vibe Coding 最容易造成一种错觉：页面出来了、脚本跑通了，就算完成了。实际不是。
一个项目真正可用，至少还要补上：
- README：别人能不能 10 分钟内跑起来。
- 配置：token、环境变量、端口、路径能不能清楚说明。
- 错误处理：网络失败、权限不足、服务未启动时怎么表现。
- 调试入口：出问题时有没有最小化排查命令。
- 部署方式：本地运行、GitHub Pages、GitHub Actions、launchd/systemd 是否清晰。
- 安全边界：涉及 token、文件写入、shell 执行、蓝牙权限时，默认行为是否保守。
这里 AI 可以帮你补很多样板，但判断是否足够可靠，仍然要靠工程经验。
4. 把提示词也当资产管理
html-ppt 里专门保留了 htmlppt-prompt.md，这件事值得长期坚持。
提示词不是一次性对话，它应该像脚本、配置和 README 一样被版本管理。因为真正可复用的不是某一次 AI 生成的代码，而是“以后如何稳定生成同类代码”的方法。
建议每个 Vibe Coding 项目都保留：
- 初始需求提示词。
- 关键约束提示词。
- 代码审查提示词。
- README 生成提示词。
- 发布检查提示词。
当这些内容沉淀下来，下一个项目会明显更快。
我的实践清单
以后继续用 Vibe Coding 做小工具，我会按这个顺序推进：
- 用 5 行话写清楚项目目标、用户、运行环境、不能做什么、完成标准。
- 先让 AI 生成最小可运行版本，不急着加复杂功能。
- 本地跑起来，记录所有报错，不凭感觉修改。
- 让 AI 根据报错做定点修复，而不是整段重写。
- 补 README、配置说明、调试命令和部署方式。
- 做一次“安全与失败路径”检查：token、权限、网络、超时、回退。
- 把提示词和经验沉淀到项目文档里。
结语
这四个项目给我的最大感受是：AI 编程真正提高效率的地方，不是把程序员变成旁观者，而是把很多“从 0 到 1 的摩擦”压低了。
以前一个想法可能会停在 Notion 里；现在可以在半天到几天内变成可运行的工具。只要选题足够具体、边界足够清楚、工程收口足够认真，Vibe Coding 就不是玩具，而是一种很适合个人开发者和技术管理者的生产方式。
更重要的是，这些小项目会反过来强化自己的工作流：daily-ai 帮我发现新项目，term-cheat 降低终端操作成本，html-ppt 提升知识输出效率，claude-desktop-buddy-bridge 让 AI Agent 的敏感操作更可控。
这就是我认为最值得投入的方向：不是追逐每一个新模型，而是持续把 AI 能力接到自己的真实工作系统里。