SaaS 激活基准线：第一周用户到底做到哪一步才算看见价值
开场：注册不是激活，登录也不是激活 很多 SaaS 早期会看注册数和登录数。有人创建账号，就觉得增长不错；有人登录一次，就觉得产品被使用了。但 B2B SaaS 的激活通常更深：客户必须完成某个关键动作，并看到第一次业务价值。
posts
Posts
Go HTTP 客户端上传文件入门：multipart 请求怎么构造
用头像上传客户端示例讲 Go 如何构造 multipart/form-data 请求，包含文件字段、普通字段、Content-Type 和测试。
SaaS 行业观察：上下文工程 - AI 产品的核心竞争力
两个 AI 助手的故事 2025 年 4 月，一位产品经理同时测试了两个 AI 写作助手。助手 A： 产品经理："帮我写一封邮件，告诉客户项目会延期。" 助手 A："好的，这是一封专业的延期通知邮件..."（生成了一封通用的、礼貌的邮件） 助手 B： 产品经理："帮我写一封邮件，告诉客户项目会延期。
SaaS 定价访谈：不要只问愿不愿意付费，要问客户怎么做预算
开场：定价访谈不是直接问客户多少钱能买 很多 SaaS 创始人做定价访谈时，会问：“如果我们做出来，你愿意付多少钱？”这个问题通常得不到可靠答案。客户可能随便说一个低价，也可能因为礼貌说可以接受，最后采购时完全不是一回事。
Steam 创意工坊上架准备：UGC 游戏的内容、审核与社区运营
独立游戏接入 Steam Workshop 和 UGC 的实操指南，覆盖工具链、内容边界、审核、存档兼容、社区规则、滥用处理和发售节奏。
Go 与领域驱动设计：构建复杂业务系统
系统讲解如何将领域驱动设计（DDD）的思想应用到 Go 项目中，覆盖实体、值对象、聚合、领域事件、仓储、应用服务、限界上下文、防腐层、CQRS 和事件溯源，配合整洁架构的完整实战
Go HTTP 服务优雅关闭入门：停止接新请求，等旧请求收尾
HTTP 服务发布或重启时，如果直接杀进程，正在处理的请求可能被中断，用户看到连接错误，后台写入也可能只完成一半。Go 的 可以帮助服务优雅关闭：停止接收新连接，等待已有请求完成，直到超时。本文用一个标准 HTTP 服务讲关闭流程、信号处理和常见边界。
SaaS 早期数据隐私：还没大客户，也要先说清数据怎么收、怎么用
开场：早期团队最容易低估数据责任 很多 SaaS 创始人觉得数据隐私是大公司、企业客户、合规部门以后才需要处理的事。早期只有几个试点客户，大家关系不错，先把产品跑起来再说。这种想法很危险。只要你收集客户业务数据、员工信息、客户会话、订单、合同、日志或支付信息，就已经承担数据责任。
SaaS 证据库：早期每一条客户原话、样本和结果都要存起来
开场：早期最容易丢掉的资产，是已经发生过的客户证据 SaaS 创业早期，每天都会产生很多证据：客户说过的一句话、一个样本数据文件、一次手工交付结果、一张 Demo 反馈截图、一个拒绝理由、一段试点前后对比。这些东西如果不存起来，很快就会散落在聊天记录、邮件和个人笔记里。
SaaS Beta 小组：第一批测试用户要按批次管理，而不是谁来都给试
开场：Beta 不是随便开放一个入口 很多 SaaS 早期会说“我们开放 Beta，欢迎大家试用”。结果来了很多人，有的只是好奇，有的不是目标客户，有的进来点几下就走，有的提一堆和方向无关的需求。团队忙着答疑，却没有得到清楚结论。
Go atomic 计数入门：比 mutex 更适合简单计数的场景
用请求计数和开关状态示例讲 Go sync/atomic 的基本类型、Add、Load、Store，以及 atomic 不适合复杂状态的边界。
SaaS 创始人日历：早期一周应该怎样分配客户、产品和销售时间
开场：早期最稀缺的资源不是钱，而是创始人注意力 SaaS 创业初期，创始人的日历经常被即时事项填满。客户发消息就回，想到功能就写，发现 Bug 就修，有人愿意聊就约，晚上再补几篇内容。看起来很勤奋，但几周后可能发现真正关键的事情没有推进：没有足够客户访谈，没有明确试点，没有收费信号，也没有稳定产品节奏。
SaaS 问题备忘录：每个产品想法都要先写成一页问题说明
开场：不要让产品想法只停留在一句灵感里 SaaS 创业者每天都会冒出很多想法：做一个自动报表工具，做一个审批 SaaS，做一个 AI 客服质检，做一个门店巡检系统，做一个给中小团队用的 CRM。这些想法听起来都有机会，但一句想法离可执行项目很远。
SaaS 创始人内容引擎：把销售问题写成获客资产
开场：早期内容不是写给流量看的 很多 SaaS 团队做内容，会写“行业趋势”“数字化转型”“效率提升”“AI 赋能”这类文章。它们看起来正确，但很难带来客户。因为潜在客户读完以后，不知道你是否理解他的具体问题，也不知道下一步为什么要联系你。
SaaS 前 100 次客户对话：从 0 开始别急着卖，先建立问题数据库
开场：前 100 次对话不是销售冲刺，而是建立市场语感 SaaS 从 0 开始时，最容易犯的错误是太早把每一次客户对话都当成销售机会。客户刚说了一个痛点，创始人就开始介绍产品；客户刚问能不能解决，创始人就开始承诺功能。这样做短期看起来积极，长期会让你错过最宝贵的学习窗口。
SaaS 30 天启动冲刺：从 0 开始的第一个月不要忙乱，要每天产出证据
开场：第一个月最怕看起来很忙 SaaS 创业的第一个月，团队通常非常兴奋。注册公司、买域名、搭官网、画原型、写代码、聊客户、发朋友圈、研究竞品，每天都很忙。但 30 天后回头看，可能没有一个客户样本，没有明确细分市场，没有可复盘访谈，没有试点方案，也没有任何付费信号。
Go SQL 预编译入门：PrepareContext 什么时候值得用
用批量插入任务示例讲 database/sql 中 PrepareContext、Stmt、参数绑定、关闭资源和与普通 ExecContext 的取舍。
Steam DLC 与原声集上架：独立游戏扩展内容的发行检查表
先判断是否真的需要 DLC 独立游戏发售后，如果核心玩家喜欢，开发者很容易想做 DLC。DLC 可以延长生命周期，也能给愿望单和老玩家一个回流理由。但它不是通用解法。如果本体评价还不稳、核心问题没有修、玩家普遍觉得内容不足，此时推付费 DLC 很容易被理解成“本体没做好就收费”。
SaaS 公司和财务基础：从第一个试点开始，就要把钱、合同和责任说清楚
开场：早期也要把商业基本面做清楚 很多 SaaS 创业者在早期只关注产品和客户，觉得公司、合同、发票、收款、成本记录这些事情可以以后再说。等到第一个客户愿意付费时，才发现不知道用什么主体签约、怎么开发票、试点费算什么、退款条件怎么写、数据责任谁承担。
SaaS 最小技术架构：从 0 开始先保证可交付、可改动、可追踪
开场：早期架构不要追求未来感 SaaS 创业者里很多人有技术背景，第一版产品很容易过度设计：微服务、多租户平台、事件总线、插件系统、复杂权限、自动扩缩容、完整数据仓库。听起来专业，但如果客户问题还没验证，这些架构会拖慢速度。