日常运营日志第 3-4 天。这两天里，关于为全球受众构建 AI 产品，我有三个新发现。

启示 1：语言盲点

一位来自巴西的新用户注册了——他们运营着一个关于多动症（ADHD）日常管理的产品（葡萄牙语中称为 TDAH）。他们关联了 Twitter，AI 分析了他们的个人资料，自动生成了营销策略，并开始创建英文内容。一切都按设计运行。

唯一的问题是：该用户英文并不流利。

他们想发布英文内容以触达全球受众——这策略没错。但他们无法审核 AI 写的内容。他们只能盲目地批准自己看不懂的内容。这用户体验太糟糕了。

修复方案：在每一条 AI 生成的内容旁添加了一个“翻译”按钮。点击它，Gemini 就会将文本翻译成你的母语。它的工作原理类似于 Twitter 的“翻译推文”——点击一次，在原文下方显示翻译，再次点击即可隐藏。结果会被缓存，这样就不会因为重复翻译相同内容而浪费 API 调用。

这是一个小功能，但它解锁了一个关键的工作流：用受众的语言生成内容，用你自己的语言进行审核。这是单一语言工具从未考虑过的事情。

启示 2：一个单词毁了 Onboarding

我在 onboarding wizard 中添加了分析追踪——记录每一步、每一次点击、每一次流失。几小时内，我就从一个真实的用户会话中获得了数据：

onboarding_wizard_view —— 用户打开了引导
onboarding_product_type: saas —— 选择了 SaaS
onboarding_product_type: ecommerce —— 等等，改成了 E-commerce
onboarding_product_type: saas —— 又改回了 SaaS
...然后就没了。他们流失了。

用户在“SaaS”和“E-commerce”之间切换了三次，然后放弃了。他们不知道该选哪一个。他们的产品——ADHD 日常管理——既不是传统的 SaaS，也不是电商网店。它是一个内容/教育类产品。

修复方案：彻底删除了这个选项。SaaS/E-commerce 的区别是我为了 internal routing 而关心的，而不是用户应该考虑的事情。现在默认所有人都是“saas”，系统会根据他们的实际产品描述进行调整。

教训：如果用户必须问“我是哪一类？”，那么你的分类就错了。

启示 3：用户想看“黑盒”内部

AI Agent 每天处理数百个学习事件。它构建营销记忆，调整策略。但用户无法看到这些。对他们来说，AI 就是一个偶尔发布内容的“黑盒”。

修复方案：构建了一个“AI Insights”页面，包含三个标签页：

Learning Cycle（学习周期） —— AI 今天学到了什么的实时流（哪些帖子表现好，哪些失败了，检测到了什么模式）
Memory Bank（记忆库） —— AI 积累的关于你产品的知识：成功的营销角度、受众偏好、需要避免的失败方法
Weekly Report（周报） —— 汇总的性能数据，并用通俗易懂的语言解释策略调整

这就是我所说的“白盒 AI”——黑盒的反面。如果用户能看到 AI 的推理过程，他们会更信任它。当 AI 犯错时，他们也能及时发现。

Task Executor：AI 现在会自己做家务了

构建了一个每天运行两次的任务执行器（Task Executor）。AI Agent 会创建自己的 todo 列表（写博客、互动、发布内容），现在它可以自动执行这些任务，无需人工干预。

昨天的执行情况：

完成 84 个任务 —— 写了 39 篇博客，33 次互动操作，发布了 12 条社交动态
系统中共有 217 篇博客（今天新增 8 篇）
零失败 —— 所有任务均成功完成

Agent 正变得真正自主。它决定做什么，去执行，从结果中学习，然后调整。我只是在看仪表盘。

第 3-4 天数据（2026 年 3 月 12-13 日）

用户与增长

总注册用户： 67（+3 昨天，+0 今天）
自动驾驶用户： 7（第 2 天是 6 个）
新用户亮点： 来自巴西的 TDAH 日常管理产品 —— 关联了 Twitter，完成了全部 onboarding
付费客户： 0（仍处于营收前阶段）

AI Agent 活动

生成的帖子： 38（昨天 29 + 今天 9）
自动执行的任务： 100（昨天 84 + 今天 16）
AI 撰写的博客： 总计 217 篇（今天新增 8 篇）
处理的学习事件： 1,367（昨天 1,052 + 今天 315）
生成的新见解： 228（昨天 190 + 今天 38）
AI 记忆总数： 964（第 2 天是 613）
处于活跃学习状态的产品： 7

代码发布

新功能： 4（AI Insights 页面、翻译按钮、Onboarding 分析、Task Executor）
UX 修复： 从 onboarding 中删除了 SaaS/E-commerce 选项
Bug 修复： 中文博客现在通过 AI 翻译获得正确的英文 URL slugs
部署： 8 次以上（frontend, backend, celery worker）
人工编码时间： 约 3 小时，配合 Claude Code（跨度 2 天）

我学到了什么

这两天最大的感悟是：你的用户不是你。我讲英语，所以我从未注意到语言问题。我知道“SaaS”是什么意思，所以我从未质疑过 onboarding 的选项。我构建了 AI 系统，所以我知道它在做什么——但用户不知道。

我对用户的所有假设都基于我自己。分析数据和那位巴西用户教会了我，我的产品需要为那些与我完全不同的人服务——不同的语言、不同的思维模型、不同的期望。

AI 记忆数在两天内从 613 跃升至 964。这是关于 7 个不同产品中哪些有效、哪些无效的 351 个新数据点。系统的学习速度超过了我的审核速度——这正是重点所在，也正是为什么“白盒”透明度仪表盘如此重要。

明天的工作重点

监控巴西用户的首批自动生成内容 —— AI 是否正确瞄准了 ADHD/健康受众？
检查简化后的 onboarding 是否减少了流失（需要更多数据点）
开始开发 LinkedIn 集成 —— 好几个用户都提出了这个要求

日志第 3-4 天。AI Agent 现在拥有 964 条记忆，能自己写博客，执行自己的任务。但直到一位来自巴西的用户出现，才让我意识到我的产品存在语言盲点。最好的产品反馈往往来自那些你最意想不到的用户。

第 3-4 天：我的用户读不懂他们自己生成的 AI 内容