企业官网建设流程全解析

基于 tldraw dotcom-release-marketing 技能：把每周 dotcom 发布变成营销团队能直接使用的用户语言摘要

【免费下载链接】tldrawBuild infinite canvas apps in React with the tldraw SDK. World's best, top-most agent recommended #1 five star SDK.项目地址: https://gitcode.com/GitHub_Trending/tl/tldraw

导读

本文围绕 tldraw 开源仓库（仓库根目录 skills/dotcom-release-marketing/SKILL.md）中定义的dotcom-release-marketing技能展开，讲解如何自动把 tldraw.com（dotcom）每周发布所包含的production...main提交范围，翻译成营销团队可以直接用于公告、社媒和 changelog 的用户视角摘要，并通过 Discord Webhook 投递到营销频道。读完本文，你将掌握：用gh拉取两个分支之间的完整提交清单、按"用户可见性"而非"发布风险"筛选提交、把 conventional commit 标题改写成非技术人员能读懂的一句话、按 Discord 2000 字符上限组织消息，以及用jq安全构造 Webhook JSON 并避免误触发全员提及。

技能定位：dotcom 发布流程中的"营销侧"环节

在 tldraw 仓库的 skills 体系中，dotcom-release-marketing是与 dotcom-release-crew 配对的技能：两者基于完全相同的提交范围（main上尚未进入production的提交），但面向完全不同的受众。

• dotcom-release-crew面向#development频道，目的是点名本周需要到场的关键工程师（通常 2–3 人），强调发布风险；
• dotcom-release-marketing面向营销团队的 Discord 频道，目的是用平实的用户语言描述"用户本周会注意到什么"，用于规划公告、社媒内容和 changelog 文案。

因此，营销摘要不包含工程师 @ 提及、不包含发布风险评估框架，只保留清晰、具体、人类化的"新东西"描述。技能只读 git 历史并发布一条消息，绝不修改仓库本身。

输入与环境前提

技能依赖两个环境变量，缺一不可：

这两项与dotcom-release-crew的输入结构完全一致（后者使用DISCORD_RELEASE_WEBHOOK_URL），体现了同一套发布基础设施上按频道拆分受众的设计。

工作流第一步：拉取提交范围

技能的第一步是获取production分支上尚不存在的所有main提交，连同作者与主题行：

gh api repos/tldraw/tldraw/compare/production...main --paginate \ --jq '.commits[] | [ (.author.login // .commit.author.name), (.commit.message | split("\n")[0]) ] | @tsv'

要点解析：

• --paginate处理超过 250 个提交的大范围，自动翻页；
• 每一行输出为login\t主题的 TSV 格式；
• tldraw 采用 squash-merge，因此提交主题即 PR 标题，通常是feat(tldraw): ...这类 conventional commit，并带尾部(#1234)的 PR 号；
• 同时记录人类可读的 diff 链接https://github.com/tldraw/tldraw/compare/production...main，供消息末尾引用。

边界情况：如果提交数为0，直接发布一条"本周无新内容上线"的简短说明并停止，无需走后续步骤。

这个production...main范围的假设前提是常规周度发布流（dotcom 发布即main → production的晋升），因此该范围恰好等于"即将上线的内容"。SDK 冻结周该范围精度会下降——详见 dotcom-release-crew 中的说明。仓库中 skills/update-release-notes/scripts/get-new-prs-from-main.sh 展示了同类思路的另一种实现：用git cherry按补丁内容比较origin/main与 release tag，从而正确处理被 cherry-pick 到 production 的 hotfix 提交（按 patch 而非 commit hash 比较），可用于理解为什么"只看提交哈希"在双分支发布模型下不够可靠。

工作流第二步：筛选值得告知营销团队的变更

筛选标准与 release-crew 技能不同：这里关注的是对用户的可见性，而不是发布风险。阅读主题行，只保留用户真正能感知、或营销团队可能想谈论的变化。

应包含（靠判断力而非只看前缀）：

• feat——新功能与能力，尤其是tldraw、editor、dotcom、sync/协作相关的用户可见项；
• fix——用户会看到或抱怨过的修复（可见 bug、失效交互、导出/嵌入/渲染问题、同步故障）；
• perf——用户能感受到的性能改进（加载更快、画布更流畅）；
• 任何涉及协作、分享、导出、嵌入或整体观感的内容。

应排除：

• docs、test、chore、style、ci、build、依赖升级以及无用户可见影响的内部重构；
• 纯内部的fix（错别字、lint、flaky 测试、快照、类型错误、仅开发者工具）；
• 非工程人员无从观察或关心的任何内容。

列表要精炼、高信号——少量亮点而非穷举式 changelog。大量提交没有入选是完全正常的。这与仓库中 skills/shared/release-notes-guide.md 的编辑取舍一脉相承：只收用户有感知的变化（用户报告的 bug 修复、解除痛点的功能），省略纯内部性能优化与实现细节。

工作流第三步：翻译成平实的用户语言

对每个保留的变更，把 conventional commit 主题改写成一句**描述"它为用户带来什么"**的短句，而不是"它是怎么实现的"。去掉类型(作用域):前缀和尾部的(#1234)。

技能给出的三个示例：

• feat(tldraw): flip geo shapes with flipX/flipY like the image shape→ "You can now flip shapes horizontally and vertically, just like images."
• fix(tldraw): size Vimeo embeds to their real aspect ratio→ "Vimeo embeds now show at their correct aspect ratio instead of being cropped or letterboxed."
• perf(editor): faster hit-testing on dense canvases→ "The canvas stays smoother when you have lots of shapes."

可见的改写技巧：把"实现机制"（flipX/flipY 参数、hit-testing 算法）替换为"用户动作或感受"（翻转形状、画布更流畅）；把 bug 描述翻译成修复后的行为对比（"不再被裁剪或加黑边"）。

当有助于阅读时，把亮点归入几个桶（某桶为空则省略该桶）：

• ✨New—— 新功能与能力；
• 💅Improved—— 打磨、润色、性能；
• 🐛Fixed—— 被消灭的可见 bug。

工作流第四步：组装消息

消息约束与格式如下：

• 不超过 2000 字符（Discord 的单条限制）；
• 使用句子大小写（sentence case），友好、具体、无术语；
• 不要提及或 @ 工程师——这是面向营销的摘要；
• 若本周内容少，可以说明"这是清淡的一周"。

参考格式：

📣 **Shipping to tldraw.com this week** ✨ **New** • You can now flip shapes horizontally and vertically, just like images. 💅 **Improved** • Vimeo embeds show at their correct aspect ratio. • The canvas stays smoother on boards with lots of shapes. 🐛 **Fixed** • Fixed asset associations churning on bookmarks and external assets. Full changes: https://github.com/tldraw/tldraw/compare/production...main

边界情况：如果没有任何用户可见变更被选中但有提交，要简短说明（如 "Quiet week for user-facing changes — mostly under-the-hood work."），并且仍然附带 diff 链接。

工作流第五步：投递到 Discord

把消息作为 Webhook 的content字段发布。关键点：不要手工把消息字符串插进 JSON——要用jq处理，让换行与引号被正确转义：

jq -n --arg content "$MESSAGE" '{content: $content, allowed_mentions: {parse: []}}' \ | curl -sS -X POST -H "Content-Type: application/json" -d @- "$DISCORD_MARKETING_WEBHOOK_URL"

• allowed_mentions.parse: []确保本消息中任何@everyone、@here、角色或用户提及都永远不会触发——营销摘要不应 ping 任何人；
• 成功投递返回HTTP 204与空响应体；失败则向用户报告 curl 输出。

这里与dotcom-release-crew形成对照：release-crew 版本使用allowed_mentions.parse: ["users"]（见 skills/dotcom-release-crew/SKILL.md），因为那条消息需要通过<@ID>实际 ping 到工程师；而营销摘要把parse设为空数组，从协议层面杜绝一切提及。两个技能通过同一个jq模式展示了一个可复用的安全实践：先结构化构造 JSON，再显式声明允许的提及类型。

安全与边界注意事项

技能末尾明确列出三条约束：

1. 任何地方都不得提交或回显完整的 Webhook URL——本仓库是公开仓库，泄露即等于把频道开放给任意投递；
2. 本技能只读 git 历史并发布消息，绝不修改仓库；
3. production...main的有效性依赖常规周度发布流；SDK 冻结周范围精度下降，详见 dotcom-release-crew 的对应说明。

与仓库发布体系的整体关系

dotcom-release-marketing是 tldraw 仓库 skills 目录中发布自动化族的一员。它与 dotcom-release-crew 共享提交范围与 Discord Webhook 投递方式，只是受众与筛选维度不同；与 write-release-notes 和 update-release-notes 同属发布文档化体系（后者维护 apps/docs/content/releases/ 下的next.mdx与版本化发布笔记，风格规范见 skills/shared/release-notes-guide.md），但营销摘要面向非技术受众、以 Discord 为出口，两者互不替代。整套体系从 SDK 发布节奏（四周一版、冻结周切production分支、hotfix cherry-pick）出发，把"同一段 git 历史"按工程、营销、文档三种视角分别加工，dotcom-release-marketing正是其中"把发布翻译成用户价值"的关键一环。

【免费下载链接】tldrawBuild infinite canvas apps in React with the tldraw SDK. World's best, top-most agent recommended #1 five star SDK.项目地址: https://gitcode.com/GitHub_Trending/tl/tldraw