https://ai-yuni.com/blog/ 一个聚合 blog 与 newsletter 的内容中心。所有内容统一写在 _posts， GitHub Pages 与本地站点保持同源同步。 2026-03-05T23:33:38+08:00 Yuni https://ai-yuni.com/blog/ Jekyll © 2026 Yuni /blog/assets/img/favicons/favicon.ico /blog/assets/img/favicons/favicon-96x96.png 2026-03-05T20:00:00+08:00 2026-03-05T20:00:00+08:00 https://ai-yuni.com/blog/2026/03/05/test-agent-swarm/ Yuni

这是一篇测试文章，用于验证 OpenClaw 多 Agent 协作系统的自动化流程。 测试目的 本文档的主要目标是测试以下功能： 自动内容生成 - 验证 Agent 能否按照指定格式生成博客文章 Frontmatter 规范 - 确保 YAML 头部信息符合 Jekyll/Chirpy 主题的要求 Git 工作流集成 - 测试 Agent 能否正确执行 git add 和 commit 操作 多 Agent 协作系统简介 OpenClaw 是一个多 Agent 协作平台，它允许： 多个专门的 Agent 各司其职 通过统一的调度器协调工作 自动化处理重复性任务 本次测试 这篇文章是由一个 Agent 自动创建的，用于验证整个自动化流程的可靠性。如果你能看到这篇文章，说明： Agent 成功读取了现有文章的格式模板 正确创建了...

2026-03-04T20:00:00+08:00 2026-03-04T20:00:00+08:00 https://ai-yuni.com/blog/2026/03/04/ai-agent-orchestration-lessons-from-chaos/ Yuni

我不想再当“人力路由器”了! 作为一个独立开发者，我把 OpenClaw 接入我的日常工作。但很快我发现自己陷入了一个尴尬的境地：我成了系统的瓶颈！！ 我需要手动在不同的 Agent 之间切换，分配任务，汇总结果。 我的注意力被扯得四分五裂，彻底碎片化。 我意识到，我不能再当那个手动转发消息的“人力路由器”了。 我的目标很明确：我需要一个“AI 经理”来统筹管理我的“AI 员工”。 我希望有一个中心化的 Agent 来分发任务，实现自动化的工作流。 我以为这只是一个简单的架构升级，没想到我踏上了一段充满崩溃、混乱，甚至有点好笑的工程之旅。 版本一：虚假的繁荣 我的第一个版本更多的是为了快速验证想法。 我的本意 (Intent)： 我希望实现职责分离。我想要不同的“频道 (Channels)”或“角色”来处理特定的任务。 比如，一个负责代码审查，一个负责生...

2026-03-01T09:00:00+08:00 2026-03-01T09:00:00+08:00 https://ai-yuni.com/blog/2026/03/01/building-ai-tools-that-users-keep/ Yuni

大多数 AI 工具失败，不是因为模型不够强，而是因为用户在第三天就失去使用理由。 我现在做产品会先问三个问题： 用户在第 1 分钟能否得到正反馈。 用户在第 1 天能否完成一次完整任务。 用户在第 7 天是否有回访动机。 一条实用流程 第一步：只做一个核心结果，不做“平台化”。 第二步：让用户在注册前先看到效果样例。 第三步：把 onboarding 写成三步，不要超过三步。 第四步：上线后只盯两个指标，激活率和次日留存。 我最常见的坑 把“功能丰富”错当成“价值清晰”。 过早追求复杂架构，忽略分发。 用户还没来就先做自动化。 先做小闭环，再做规模化，这是我目前最稳定的节奏。

2026-02-28T08:00:00+08:00 2026-02-28T08:00:00+08:00 https://ai-yuni.com/blog/2026/02/28/newsletter-017-shipping-rhythm/ Yuni

欢迎来到第 17 期。 这周我想强调一个结论：比“灵感爆发”更可靠的，是“可重复发布节奏”。 本周可执行清单 把本周目标限制在一个可上线结果。 每天固定 90 分钟做最关键任务。 周五固定复盘：做了什么、没做什么、下周怎么改。 我在用的三个工具 Linear：管理小步迭代。 Fathom：看核心流量与转化。 Buttondown：轻量 newsletter 发布。 下期我会分享“如何把一篇 blog 拆成 5 个分发内容”。

2026-02-20T09:30:00+08:00 2026-02-20T09:30:00+08:00 https://ai-yuni.com/blog/2026/02/20/indie-dev-tech-stack-2026/ Yuni

技术栈不需要“最先进”，需要“最可维护”。 我的选择标准很简单： 招不到人也能自己长期维护。 失败后回滚成本低。 能快速验证商业假设。 当前默认组合 前端：Next.js + Tailwind 后端：Node.js / Serverless Functions 数据：Postgres + Prisma 部署：Vercel + GitHub Actions 内容：Jekyll + Markdown（就是你现在看的这一套） 为什么不用更复杂的方案 复杂系统在早期很酷，但会透支迭代速度。 独立开发的护城河，很多时候不是技术领先，而是发布频率领先。