开源项目或开发者工具要做可持续…

适用于开源项目或开发者工具维护者想持续公开构建过程、选择披露层级、节奏、平台与边界，并避免过度披露或实践停滞时。

适用场景

解决思路

1. 先确认要设计的是 build in public，而不是 release early, release often 或 learning in public；如果用户要工程发布流程，转向发布流程；如果用户要个人职业品牌，转向个人品牌并避免公开项目数字。
2. 访谈用户时一次只问一个问题，尽量给多选项；一旦能说出目标、受众、截止期限和真实产能就停止，其余稍后确认。
3. 问清楚项目是什么、谁维护：一个人、小团队还是 funded company。
4. 问清楚想从公开中获得什么结果：contributors、users、sponsors/funding、招聘或可信度信号、商业 funnel；让用户排前两名。
5. 问清楚受众：是个人开发者自己选工具，还是必须在公司内部推动审批的工程师；两者都选也可以。
6. 问清楚今天已经在发布什么：releases、changelog、blog、social posts，还是什么都没有。
7. 问清楚每月能投入多少小时，要按坏月份而不是好月份诚实回答；这个数字是后续所有建议的上限。
8. 问清楚必须在什么日期前显示成果：fundraise、launch、conference、job search，还是时间线开放。
9. 问清楚想要围绕某个时刻爆发，还是想要两年后仍在添加的 archive。
10. 问清楚发布数字前需要谁的同意：co-founders、investors、employer、customers。
11. 问清楚是否附带商业关系：paid tiers、sponsorship、建立在项目上的公司、正在进行的 acquisition 或 fundraise。
12. 问清楚在任何情况下都拒绝发布什么。
13. 问清楚之前尝试是否停滞过，是什么阻止了继续。
14. 问清楚希望读者关注六个月后对项目相信什么。
15. 把第 5、6、7 个问题带入 Step 2 排序；近期截止日期会提升 shipping log，两年 archive 会提升 decisions-and-failures essays，单 digit 小时数每月会删除 open-startup dashboard。
16. 记录答案；如果工具支持持久记忆，把生成的 charter 存进去，后续 content、launch 和 sponsorship 工作都从中读取，避免每次 session 重新推导出不同实践。
17. Step 1 中先定下第 2 问的首要结果，后续每个决策都对照它；被看见不是结果，contributors、sponsors、enterprise credibility 才是。
18. 判断谁对数字有权利：funded company 通常不能发布 revenue，投资人权利协议对财务报表施加保密义务，披露首先是法律问题而不是营销问题。
19. 判断谁对数字有权利：bootstrapped company 可以把 revenue 当作 channel。
20. 判断谁对数字有权利：solo maintainer 不受这些约束，但有另一种成本，公开收入会招致未付费用户的 entitlement。
21. 参考 references/context-variants.md 获取完整比较和例外。
22. 判断读者是谁：company adoption/B2B 的读者是必须说服审批者的评估者，公开 release cadence、response times、security handling 和 maintenance capacity 的证据最有用。
23. 判断读者是谁：company adoption/B2B 中 revenue disclosure 可能反噬，小但诚实的数字放在 incumbent 旁边会引发 vendor-risk objection。
24. 判断读者是谁：individual adoption/B2C 或开发者自己选工具时，读者独自基于好奇和信任采用；personal narrative、decisions 和 failures 比任何 metric 更有分量，maintainer 自己的 voice 是 differentiator。
25. 告诉用户两种读者下哪些部分相同：security boundary、consent rules 和 cadence math。
26. Step 2 中头脑风暴三种实践，按每单位维持成本买到的读者信任排序；成本包括 maintainer 每周期固定小时数、发布不光彩内容的名誉暴露和可逆性。
27. 说明 open-startup dashboard 一旦读者依赖就很难停止；postmortem 是否出现没人审计。
28. 向用户展示前两种实践及权衡，推荐一种，并说明另一种为什么输。
29. 使用排序：efficiency 为 shipping log > decisions-and-failures essays > open-startup dashboard。
30. 使用排序：value 为 decisions-and-failures essays > open-startup dashboard > shipping log。
31. 使用排序：effort 为 open-startup dashboard > decisions-and-failures essays > shipping log。
32. 使用排序：compliance cost 为 open-startup dashboard > decisions-and-failures essays == shipping log。
33. 描述 release-anchored shipping log（rungs 1-2）：发布 releases、merged work 及其背后决策；买到 proof of life 和 adoption confidence；义务是继续 shipping，因为沉默会变得可见；它效率最高，因为 artefact 已存在，只需一个 link 和一段文字。
34. 描述 decisions-and-failures essays（rungs 2-3）：写 architecture choices、rejected options、outages、wrong bets；买到最高的 trust-per-word；义务是也要发布不舒服的内容，成本是 reputational exposure 而非小时数；每篇约一天，且常在最不想花时间时到期。
35. 描述 open-startup dashboard（rungs 4-5）：公开 operational metrics，有时包括 revenue，是最不可逆的一种；买到最大 attention 加 sponsorship 和 hiring pull；义务是永久被比较的 baseline、坏季度也发布、legal review 和改变后的 negotiation position；它是三者中唯一 standing obligation 而非 per-post。
36. 解释 compliance cost 为何打平：shipping log 和 failure essay 都只发布自己的工作，不需要他人同意，并通过 Step 4 同一套四问 pre-publish check；dashboard 涉及 investor confidentiality、co-founder 和 customer consent，且第一帖前就要 legal review，而不是第一次投诉后。
37. 注意该排序会饿死 decisions-and-failures essays：它是三者中价值最高、但按比例永远不会被选的一种，因为成本是 reputational exposure 而非小时数。
38. 在以下情况提升 decisions-and-failures essays：第 2 问结果是 contributors 或 personal credibility；项目已经发生过受众看到的公开失败；第 7 问回答是两年 archive。
39. 如果用户是 funded company，或第 10 问回答 revenue，就直接删除 open-startup dashboard，而不是把它排最后；说明删了哪一个及为什么，否则它会作为 scope 重新出现。
40. 把该排序当默认而非法律；根据已有情况重新排序：维护者已经写得很好且公开、已有 metrics page、当前没人链接的 changelog，各自会把某个实践提前。
41. 应用两条覆盖排序的规则：只发布你愿意在其下降时也发布的 metric。
42. 应用两条覆盖排序的规则：选择坏年份也能维持的 rung；向下爬，例如删除 revenue page 或砍 salaries，比从未爬过更损 credibility。
43. 查看 references/disclosure-ladder.md 获取完整五级披露阶梯以及 Buffer、Ghost、Plausible 的定位；如果能够浏览网页，引用前确认其中一个仍然 live。
44. 进入下一步前展示推荐并取得明确同意；2022-2024 回撤潮很大程度上是热情中选 rung 的记录。
45. Step 3 中现在就写 stop condition；使用 Damon Chen 的停止测试，满足以下任一即停止分享某个数字：大公司看到你的小数字后轻视你。
46. 使用 Damon Chen 的停止测试：披露正在提高 copy 和 clone risk。
47. 使用 Damon Chen 的停止测试：超过某个体量后，数字不再激励任何人，而开始被读成炫耀。
48. 使用 Damon Chen 的停止测试：数字不再是你个人的 milestone，因为团队里现在有其他人。
49. 把停止测试当作 pre-commitment 而不是诊断；第一帖前让用户写下每个披露结束的条件，以及结束后继续发布什么。
50. 从比感觉自然更窄的范围开始，而不是计划以后扩大。
51. Step 4 中在第一帖前画 boundary，从 references/boundary-rules.md 工作，并把结果记录进 charter。
52. 硬性不可谈判项：unpatched vulnerabilities 不能公开；采用 coordinated disclosure，修复版本存在前不公开，之后说明 release 包含 security fix，以便下游用户升级。
53. 硬性不可谈判项：未经同意的 third-party data 和 names 不发布。
54. 硬性不可谈判项：employee data 不发布。
55. 硬性不可谈判项：涉及 investors 或有 public-company parent 时，material non-public information 不发布。
56. 硬性不可谈判项：事实未确立前的 live incidents 不发布。
57. 硬性不可谈判项：internal conflict 不发布。
58. 灰色地带需要记录决定而不是条件反射：roadmap dates 有 Osborne effect；发布方向和顺序，只有已经在 shipping 的工作才给日期。
59. 灰色地带：solo-maintainer income。
60. 灰色地带：competitive strategy。
61. 灰色地带：hiring 或 departures。
62. 给用户四问 pre-publish check，对每篇帖子包括匆忙写出的回复都运行；任何一个是就重写或延迟；免责声明不能抵消问题。
63. Step 5 中诚实回答 copying objection；不要只用经典反驳，给出当前有日期和署名的分歧。
64. 引用 Arvid Kahl 2026 重评：agentic coding tools 能把公开描述的 architecture 和 feature set 在几天内变成可工作竞品，旧的 $20-30K MRR 安全阈值已降到零。
65. 引用 VC Corner 反分析：克隆障碍一直是让陌生人信任它，因此 distribution 和 trust，也就是原始产品仍持有的东西，仍是 moat；分歧未决，不要假装某方赢了。
66. 把工作规则写入 charter：分享 journey 和 reasoning。
67. 把工作规则写入 charter：把 operational playbook、exact architecture 和 specific growth levers 排除在外。
68. 如果发布数字，就从可验证来源发布；screenshot-faking tools 在流通，revenue-verification services 是市场反制；不可验证的图表会招致怀疑而不是掌声。
69. Step 6 中从 references/cadence-patterns.md 选择 cadence pattern：release spine、weekly log、batched event、periodic report、daily micro-log，并用其中 capacity math 定尺寸。
70. 预算 reply load，而不只是写作；回答一个 thread 通常比产出一篇 post 更贵。
71. 按最差月份能维持的频率设定，而不是这个月能 manage 的频率；先降低频率再降低深度；每月一篇实质 post 胜过每周四篇薄 post。
72. 作为自设工作基线，把整个实践控制在可用项目时间的约十分之一以内；超过这个比例，它就会与它所叙述的工作直接竞争。
73. 现在就写 pause rule 进 charter：什么触发降到更低 cadence，以及宣布它的那句话；已宣布的空档无成本，未宣布的空档会被读成 abandonment。
74. Step 7 中指定一个项目拥有的 anchor surface：changelog、blog 或 newsletter；把每个 social channel 当作指回它的 amplifier。
75. 使用 owned surfaces，以便平台衰退或账号丢失时仍保留 archive。
76. 按目标受众已经在哪里评估工具来选择 amplifiers，并且只选维护者自己真正阅读的渠道。
77. 让每个平台匹配其接受的格式；milestone post 和 candid post-mortem 是不同 genre，不是同一个 asset 重塑。
78. 参考 references/platform-norms.md 的 per-platform table。
79. 保持 loop 便宜：repository artifact，例如 release notes、decision record、postmortem，是 source of truth；公开帖子链接到它而不是复制它。
80. Step 8 中计划 downside。支持负载超过项目时，在到达读者能看到的地方发布 availability 和 scope，例如 README、community health files。
81. 把 feature requests 路由到 public channel 而不是 DMs，让每个回答可复用；通过指向写好的 scope 来拒绝 out-of-scope 工作。
82. 观察 issue volume 是否比 contributor count 增长更快；这是暂停发帖并修复 artifact 的信号。
83. 一篇帖子翻车时，公开回答最强 objection 一次，并按与原主张同等显著度修正错误；不要在许多 threads 里争论同一点。
84. 必须发布坏消息时，先按自己的方式发布：先讲对读者的 impact，再讲 cause，再讲 systemic changes；同样的消息被别人挖出来代价高得多。
85. 参考 references/post-examples.md 的 worked examples。
86. Step 9 中从诚实 baseline 测量：这里的归因是 narrative 而不是 instrumented；Alex Turnbull 承认自己 NEVER looked at a metric for 3 years，只是注意到分享越多 trial 越多；承诺 signals 而不是 proof。
87. 从第一天就仪表化：给每个 link 打 tag，使用 privacy-friendly analytics，跟踪每渠道到 signup 或 waitlist 的 click-through，绝不跟踪 followers。
88. 防止 named failure：大 audience 从不转化，Jason Leow 将其归因于缺少 channel-offer fit 而非努力不足；如果 engagement-to-signup 连续两到三个月接近零，就把实践当作 community 和 accountability tool 而不是 distribution strategy，并重新分配时间。
89. 按季度对照 Step 1 outcome 判断；实践复利太慢，不能按周读。
90. 测量 contributors 时看 first-time contributors per quarter、PRs from people who cite a post；忽略 stars、followers。
91. 测量 sponsors/funding 时看 new sponsors、recurring amount、inbound funding conversations；忽略 impressions。
92. 测量 company adoption 时看 inbound evaluations、security 或 compliance questions、named deployments；忽略 reach。
93. 测量 personal credibility 时看 speaking、podcast 和 job inbound 是否引用具体 posts；忽略 follower count。
94. 通过条件要自设而非用行业基准：每季度至少一个 named outcome 移动、cadence 达成、没有 boundary rule 被破坏。
95. 如果 cadence 达成但连续两个季度没有任何移动，改变 rung 或 surface，而不是发更多。
96. 如果 cadence 没达成，先削减 cadence，再改其他东西。
97. 交付物是 charter，逐节产出，每节取得同意后再进入下一节。
98. Charter 模板包含 Goal primary and secondary outcome。
99. Charter 模板包含 Context solo / bootstrapped / funded，以及需要谁的同意。
100. Charter 模板包含 Audience individual / company adoption，以及各自需要看到什么。
101. Charter 模板包含 Rung 发布什么，以及明确排除什么。
102. Charter 模板包含 Stop condition 每个披露何时结束，以及结束后继续发布什么。
103. Charter 模板包含 Boundaries hard blocks、grey-zone decisions、pre-publish check。
104. Charter 模板包含 Cadence pattern、frequency、per-post time budget。
105. Charter 模板包含 Surfaces anchor + amplifiers，以及 repurposing loop。
106. Charter 模板包含 Support plan published availability、scope、routing of requests。
107. Charter 模板包含 Measurement instrumentation、quarterly signals、review date。
108. Charter 模板包含 Pause rule trigger，以及宣布它的句子。
109. 参考 references/post-examples.md 的 filled example。
110. 避免 failure mode：不要为了 attention 从 rung 5 开始；先在 rungs 1-3 养成习惯。
111. 避免 failure mode：不要在好的一周设定 cadence；sabbatical 期间承诺 weekly 会在第九周崩溃，并留下 visibly dead feed。
112. 避免 failure mode：不要为未发布工作宣布日期；错过日期比功能收益更损 credibility，过早公告会抑制已发布功能的使用。
113. 避免 failure mode：不要 all posts, no shipping；一个季度内关于项目的 posts 超过项目 releases，说明实践替代了它本应叙述的工作。
114. 避免 failure mode：不要只发布 wins；只有 milestones 没有 failures 的 feed 会被读成 marketing 并被整体打折，包括真实部分。
115. 避免 failure mode：不要发布不可验证数字；没有可验证来源的 revenue screenshot 会招致怀疑。
116. 避免 failure mode：不要完全活在单一 social platform；没有 archive、没有 search surface，一次账号停用就可能失去整个实践。
117. 避免 failure mode：不要淡出；披露后沉默会被读成坏消息，而且通常比真相更糟；宣布暂停。
118. 避免 failure mode：不要 vanity dashboards；star charts 不能证明 adoption；任何增长数字都要配 contributor、download 或 retention 移动，否则删掉。
119. 发布前把草稿跑过你偏好的 humanizer skill；读起来像 press release 的 build-in-public post 会破坏整个实践。

适用边界 · 注意事项

• 不适用于一次性 launch；一次性发布应使用 samber/developer-relations-skills@oss-launch。
• 不适用于用户实际想要的是 release early, release often 的工程发布流程，或 learning in public 的个人职业品牌，而不是为项目吸引用户、贡献者或赞助的持续营销实践。
• 当共同所有者、投资人、雇主或客户不同意披露数字，或所在公司禁止公开财务和运营数据时，不应做指标或收入披露；先解决同意与法律问题。