SaaS 无产品 onboarding：从 0 开始先设计客户第一次成功体验
很多创业者以为 onboarding 是产品上线后的事情：注册、创建团队、邀请成员、配置字段、看新手引导。但从 0 开始做 SaaS 时，真正重要的不是界面步骤，而是客户第一次感到“这东西确实帮我解决了问题”的路径。如果这个路径没有被设计清楚，即使产品做出漂亮引导，客户也会在配置阶段流失。
posts
Posts
SaaS 第一位协作者：什么时候该找人，哪些事不能外包
开场：找人不是为了显得像公司 SaaS 项目刚有一点起色时，创始人很容易想找人：找前端、找运营、找销售、找客服、找外包团队。找人当然可能提高速度，但也可能让混乱更快扩散。如果问题还没验证、流程还没稳定、判断标准还没形成，新增协作者只会增加沟通成本。
SaaS 品类教育：从 0 开始时，客户还不知道该用什么名字描述你的产品
开场：把创业起点放回客户现场 很多早期 SaaS 不是输在功能，而是客户不知道该如何理解它。客户没有现成预算科目，没有成熟采购关键词，也不知道应该拿它和谁比较。品类教育的任务，不是创造一个很酷的新名词，而是帮客户把熟悉的问题、现有替代方案和新的结果连接起来。
SaaS ICP 收窄：从 0 开始不要服务所有人，要先锁定一种高频客户
很多 SaaS 项目从 0 开始时，最容易犯的错误不是产品做得太少，而是客户想得太宽。团队会说“中小企业都需要”“销售团队都能用”“老板都会关心效率”，这些说法听起来市场很大，实际执行时却没有任何指向。你不知道先找谁访谈，不知道页面写给谁看，也不知道第一版功能要优先满足哪一种工作流。
Steam 下载体积与补丁体验：个人游戏上架前要检查的不只是容量
体积不是只有硬盘大小 个人开发者常把下载体积当成技术细节：游戏几 GB 就几 GB，玩家下载就行。但在 Steam 发行里，体积会影响很多事情：Demo 是否有人愿意试、低网速地区是否能顺利下载、首日热修是否让玩家重复下载大包、主播是否愿意临时试玩、玩家是否因为更新频繁而烦躁。
SaaS 小团队扩张：在混乱前建立基本系统
开场：增长会放大所有早期临时方案 SaaS 早期为了验证速度，很多事情可以手工处理：手动开通账号、手动改套餐、手动导入数据、手动回复客户、手动检查服务是否正常。这些做法在 5 个客户时没问题，在 30 个客户时开始吃力，在 100 个客户时就会变成混乱。客户数增长不会自动让公司变成熟，它只会放大原本没有系统化的地方。
游戏服务器数据一致性架构设计
游戏服务器的数据一致性问题很少以教科书形式出现。玩家不会说“你们的分布式事务失败了”，他只会说“我扣了钻石但没拿到道具”“副本打完奖励没发”“排行榜显示的战力不对”。一致性架构要回答的核心问题是：哪些数据必须强一致，哪些可以最终一致，哪些必须可补偿，哪些宁可拒绝也不能错。
SaaS 行业观察：服务等级目标与错误预算管理
一个可靠性与速度的两难 2022 年 10 月，一家快速增长的 SaaS 公司陷入了工程团队的内部冲突。客户成功团队抱怨产品稳定性下降，过去 3 个月发生了 5 次影响客户的服务中断，客户投诉激增。产品团队则抱怨工程团队过于保守，新功能开发缓慢，竞争对手正在快速追赶。
游戏服务器社交动态流架构设计
游戏社交不只有好友关系，还有“发生了什么”。好友升到满级、公会赢下据点、队友抽到稀有角色、活动即将结束，这些都可能进入动态流。动态流看起来像信息流系统，但游戏里的权限和节奏更复杂：有些动态只给好友看，有些只给公会成员看，有些需要合并，有些过期后没有价值。社交动态流架构要在活跃气氛和消息打扰之间找到平衡。
Steam 首发客服与崩溃反馈入口：个人开发者如何把问题收集完整
支持入口不是发售后才补 个人开发者经常把客服当成发售后的被动工作。游戏上线后，有问题再回复邮件、论坛和评论。但首发当天最需要的是结构化反馈。玩家说“打不开”“卡了”“手柄不能用”，如果没有版本号、系统、日志和复现步骤，你很难快速定位。
Go 泛型切片工具入门：自己写 Filter、Map 和 Reduce
从切片工具函数学习泛型最自然 Go 1.18 有了泛型后，最容易上手的练习就是切片工具函数。因为切片处理在业务代码里非常常见：过滤活跃用户、提取 ID、计算总金额、把数据库结果转成响应结构体。过去这些函数要么针对具体类型写，要么使用 损失类型安全。泛型让它们变得更自然。
游戏服务器韧性架构模式
游戏服务器最怕的不是某个服务偶尔失败，而是一个小失败被放大成全服故障。聊天服务慢了，网关线程被占满；排行榜缓存抖动，战斗结算也跟着超时；活动配置错误，所有玩家同时重试领取奖励。韧性架构的目标不是保证每个功能永不失败，而是让失败停在合理范围内，让核心体验优先活下来，让系统有时间恢复。
SaaS 行业观察：客户顾问委员会与共创机制
一个产品方向的转折点 2022 年 9 月，一家 ARR 达到 2 亿美元的企业协作 SaaS 公司召开了年度客户顾问委员会（Customer Advisory Board，简称 CAB）会议。会上，一位来自金融行业的 CAB 成员直言不讳地说："你们的产品功能越来越多，但对我们来说真正重要的只有 20%。
SaaS 帮助文档：早期文档不是附属品，而是可复制交付
开场：文档不是等产品成熟后才写 很多 SaaS 团队觉得早期不用写文档，因为产品还在变，客户也不多。于是所有问题都靠创始人一对一解释。短期看，这样很快。长期看，团队会被同样的问题反复消耗：怎么导入数据、怎么邀请成员、为什么报表不对、权限怎么设置、通知为什么没收到。
游戏服务器市场价格索引架构设计
围绕交易行、拍卖、摆摊和装备估价，讲解游戏服务器市场价格索引架构，覆盖成交流水、滑动窗口、异常价格过滤、查询缓存与经济风控。
SaaS 行业观察：可组合架构与模块化产品设计
一个架构重构的决策 2022 年 8 月，一家 ARR 达到 1.2 亿美元的企业协作 SaaS 公司面临着严峻的技术挑战。他们的产品是一个"一体化"的解决方案，包含项目管理、文档协作、团队沟通、时间追踪、资源管理等功能。这个单一产品在早期帮助公司快速获得了市场份额，但随着业务增长，问题开始显现。
Steam 审核证据包怎么准备：让商店页和构建返工更少
审核不是把按钮点掉 Steam 上架需要商店页和构建通过审核。很多个人开发者会把审核理解成“后台检查完就提交”，然后等待结果。如果被退回，再临时修。这个流程能走，但效率低。因为退回意见往往会牵连多个地方：页面描述、截图、构建内容、语言栏、价格、平台支持、敏感内容说明。没有准备材料时，返工会变得混乱。
游戏服务器跨服务可观测性架构
游戏服务器出问题时，玩家描述往往很模糊：“我刚才卡了一下，奖励没到账”“匹配转圈很久”“进副本黑屏”。如果后端只有进程日志和 CPU 曲线，排查就会变成猜谜。跨服务可观测性架构要做的，是把一次玩家请求、一段战斗流程、一笔经济变更和一次系统发布串成证据链。这样团队才能知道问题发生在哪里、影响多少人、是否还在扩大。
SaaS 早期指标：别只看注册数和收入
开场：注册数会让人误判 早期 SaaS 最容易看的两个数字，是注册数和收入。注册数上涨让人兴奋，收入增长让人安心。但只看这两个数字，很容易误判产品状态。注册数高，可能只是渠道带来了一批低匹配用户。收入增长，可能只是几个早期客户一次性付款，还没有证明留存。
Go 1.19：稳定中求进步
Go 1.19：稳定中求进步 2022 年 8 月，Go 1.19 正式发布。虽然不像 1.18 那样引入了泛型这样的重大特性，但 1.19 在稳定性、性能和开发体验方面做了大量改进。这篇文章带你了解 Go 1.19 的重要变化。