叙事角度
先判断这周适合讲阶段、假设、实验、信号还是不确定，避免把早期学习包装成成功故事。
工具任务
Build-in-Public Story Generator
把 Tomako 的真实 GTM 进展转成社区能接受的公开叙事：阶段、假设、动作、信号、不确定和反馈问题，而不是营销稿。
生成透明、有数据、有疑问的公开进展帖
输入产品阶段、本周进展、Tomako 生成的 GTM 假设、已有信号和想请社区反馈的问题。结果会给出多平台草案和真实性检查。
Review 原型
你可以得到什么
四个平台草案
同一素材分别生成 Indie Hackers 长帖、Reddit 讨论帖、X thread 和 LinkedIn 进展帖。
真实性检查
标出营销味、证据缺口、过度公开和社区契约风险，提醒你发之前改掉。
反馈问题
把“大家怎么看”改成更具体的判断问题，让社区有空间给出有用反馈。
适合公开学习记录，而不是普通社媒发帖
适合独立开发者、早期 SaaS、开发者工具、AI 产品和正在验证 GTM 渠道的小团队。
尤其适合已经用 Tomako 生成过渠道选择、发布计划或增长假设，但不知道怎么把它讲给社区听的时候。
输入可以很粗糙，但必须包含真实进展和一个想请教的问题；否则结果会像普通宣传稿。
输出定位为草案和复核材料，不是自动发布、获客保证或社区运营替代品。
同一素材，不同社区契约
Indie Hackers 适合完整讲背景、假设、数字、学习和请教点。
Reddit 需要先降低宣传感，把问题放在前面，并说明你不是来硬推产品。
X thread 要把每条拆成阶段、行动、信号和不确定，不要只有口号。
LinkedIn 可以强调决策质量和学习过程，但不能写成公司新闻稿。
公开之前，先检查哪些内容不该公开
不要公开客户姓名、敏感收入、未发布路线图、私密社区截图或可识别用户反馈。
指标可以写成区间、相对变化或样本数；没有数据时要承认是定性信号。
Tomako 的 GTM 策略只能作为假设来源，不应被写成已经验证的市场结论。
如果帖子最后只有注册链接或强 CTA，就不再是 build-in-public，而是广告。
为什么这个工具属于 Tomako，而不是普通发帖生成器
从 GTM 假设出发
普通工具先问平台和语气；这里先问阶段、渠道假设、信号和不确定。
保留疑问
好的 build-in-public 不是把一切写得很顺，而是让读者看到你正在验证什么。
按社区改表达
Reddit、Indie Hackers、X 和 LinkedIn 的可接受表达不一样，不能只换长短。
先复核再发布
结果会提醒哪些句子太像营销、哪些结论没有证据、哪些信息不适合公开。
把结果当成发布前复核单
发布前删掉没有证据支撑的绝对结论。
至少保留一个失败、犹豫或待验证问题。
把指标、用户反馈和 Tomako 假设分开写，避免混成一段宣传。
对 Reddit 版本尤其要检查是否像自我推广。
复制前确认公开边界：哪些数字、客户、路线图和内部决策不能发。
好的 build-in-public 工具应该具体，也应该克制
质量：输出应有真实结构，而不是把产品卖点换成社媒语气。
可信：必须区分事实、假设、指标、定性观察和未确认问题。
易用：第一版只需要产品阶段、本周进展和反馈问题，不要求完整增长报告。
平台匹配：不同平台的草案应改变社交契约，而不只是改变字数。
安全：要提醒过度公开、客户隐私、路线图和社区自我推广风险。
常见问题
这个工具会自动发到 X、Reddit 或 LinkedIn 吗？
不会。它只生成草案和复核清单。你需要人工编辑，并按各社区规则手动发布。
没有真实数据可以用吗？
可以，但帖子应该明确说这是定性观察或待验证假设。没有数据时不要伪造增长感。
它和普通 AI 发帖生成器有什么区别？
普通工具通常从平台和语气开始。这个工具从阶段、GTM 假设、证据、有效/不确定和社区反馈问题开始。
这个 review 版本是否接入了真实 Agent？
还没有。当前是前端确定性原型，用于验证交互和输出结构；转 published 前应确认是否升级为 Agent/Skill Result。