[分享创造] 花了两周做了个 bra size 计算器，纯静态 + Cloudflare Pages，聊聊选词和计算逻辑
最近花了两周时间，做了一个面向美国用户的 bra size 计算器： https://brascale.com/
整个站是纯静态的，没有后端、没有数据库，部署在 Cloudflare Pages 上。目前做了四个页面，核心功能就是根据用户输入的身体围度，计算一个参考内衣尺码。
做这个项目的初衷很简单：想试试用一个足够轻量的工具站，从关键词研究、页面设计到计算逻辑，再到 SEO 部署，完整跑一遍流程。
记录一下过程中比较值得分享的几个地方。
一、为什么选这个方向？
一开始并没有直接写代码，而是先看关键词。
美国用户搜索内衣尺码相关问题时，会涉及很多不同的搜索意图，比如：
● bra size calculator
● band size calculator
● sister size calculator
● bra size conversion
这些词看起来都和同一个需求有关，但用户真正想解决的问题不完全一样。
主词的竞争通常比较激烈，成熟的大站已经有相对完善的页面、外链和品牌积累。新站如果一上来就想竞争最宽泛的关键词，可能很长时间都没有什么结果。
所以我选择先从细分需求入手。
比如，有的人只想知道自己的下胸围应该对应什么 band size；有的人已经知道自己的尺码，只是想找姊妹码；还有的人想弄明白英寸和厘米之间的换算。
这些需求虽然相关，但完全可以分别设计页面，让每个页面尽量解决一个明确的问题。
这里也不是说长尾关键词一定比主词容易做，而是对于一个没有太多资源的新站，先把具体需求研究清楚，比直接冲最热门的词更有操作性。
关键词研究最后还是要回到搜索结果本身：看看现有页面解决了什么问题、有没有信息缺口，以及自己能不能做出更清晰、更方便使用的工具。
二、尺码计算逻辑，比写页面麻烦多了
这是整个项目里我觉得最值得花时间研究的部分。
内衣尺码计算并不是简单地把两个数字相减，再查一张表就完事了。不同品牌、国家和计算体系可能存在差异，如果直接照搬网上的一张旧表，很容易出现结果看起来合理、实际上却不太对的情况。
我在实现时，主要处理了下面几个问题。
1. 统一计算单位
内部计算以英寸为基准。
如果用户输入的是厘米，先转换成英寸：
inches = cm / 2.54
这样后续的 band、bust 和 cup 计算都使用同一套单位，避免在不同单位之间反复计算造成误差。
显示结果时再根据用户选择的单位进行转换。
2. Band size 怎么取？
这里采用下胸围取最近偶数的规则。
例如，下胸围测量值是 31 英寸，按最近偶数取值会得到 32 band。
这个步骤看起来简单，但需要注意测量值处于两个偶数中间时的处理方式，以及输入精度和四舍五入规则，否则不同页面可能算出不同结果。
3. Cup size 怎么算？
基本思路是用上胸围与下胸围之间的差值作为参考：
差值 = 上胸围 − 下胸围
然后根据差值映射到对应的罩杯。
我采用的映射规则中，差值小于 1 英寸时对应 AA，后续再按照设定的区间映射到其他罩杯。
这里需要强调一点：这是一套明确的计算规则，不代表所有品牌都使用完全相同的尺码体系。实际穿着效果还会受到品牌版型、胸型和测量方式的影响。
4. 姊妹码怎么换算？
姊妹码（Sister Sizes）的基本规律是：
● Band 增加 2，Cup 字母通常向下调整一级。
● Band 减少 2，Cup 字母通常向上调整一级。
例如，34C 的姊妹码通常包括 32D 和 36B。
原理是通过调整下胸围，同时调整罩杯容积，使不同尺码之间尽量保持接近的罩杯容量。
实现时不能只做字符串替换，还要处理罩杯字母的顺序、边界情况，以及不同尺码体系的差异。
5. 最麻烦的是 plus-four 算法
我在研究旧尺码表时，发现一个很容易造成误判的问题：plus-four 算法。
一些传统计算方法会先根据下胸围增加 4 英寸，再推算 band size。
这会产生一个很明显的差异：29–30 英寸的下胸围，经过某些旧式规则处理后，可能会被归到 34 band。
如果用户习惯的是不额外加 4 英寸的现代测量方式，这个结果就可能让人困惑。
因此，我没有直接把网上找到的旧 chart 当成唯一标准，而是明确采用自己的计算规则，并尽量让输入、换算和结果展示遵循同一套逻辑。
这也是我觉得工具站开发中很容易被低估的一件事：代码本身可能只需要几十行，但你得先搞清楚自己到底在实现哪一种规则。
三、为什么选纯静态 + Cloudflare Pages？
目前整个网站使用纯静态页面，没有专门的后端服务，也没有数据库。
选择这套方案，主要有几个原因：
1. 计算可以在浏览器本地完成。 用户输入围度后，直接通过 JavaScript 计算结果，不需要把数据发送到服务器。
2. 部署简单。 页面构建完成后直接部署到 Cloudflare Pages，不需要维护服务器、数据库和 API。
3. 访问速度和维护成本比较友好。 对于计算逻辑简单、数据量不大的工具站，没有必要为了技术架构而增加复杂度。
另外，页面里的图形尽量使用内联 SVG，而不是随便找一些模特照片或者商品图片。
一方面是版权问题，另一方面是工具本身也不需要大量照片才能完成任务。
如果以后考虑接入 AdSense，图片版权和页面内容质量也值得提前考虑。不过，使用 SVG 并不意味着自动符合 AdSense 政策，最终还是要看整个网站的内容质量、实用性和政策合规情况。
对这种小型工具站来说，我更倾向于先把核心功能和页面体验做好，而不是先堆很多视觉元素。
四、部署和 SEO 过程中踩过的坑
纯静态站不代表上线就万事大吉，域名和搜索引擎相关的细节也需要处理。
1. www 和裸域的统一
例如：
● brascale.com
● www.brascale.com
如果两个地址都能正常访问，却没有统一的规范域名，可能会给网站的索引和维护带来不必要的复杂性。
所以需要明确一个主域名，并将另一个域名通过 301 重定向过去。
这里要注意，不只是首页，其他页面的路径也应该正确保留，避免所有地址都被错误地重定向到首页。
2. Sitemap 和规范 URL
Sitemap 需要列出希望搜索引擎发现的规范页面地址，并且确保这些地址实际可以正常访问。
我在处理 URL 时也特别关注了尾斜杠的一致性。
严格来说，sitemap 并不是必须全部带尾斜杠，而是要和网站实际使用的规范 URL 保持一致。如果
因此，最好提前确定 URL 规则，再统一处理页面内部链接、canonical 标签和 sitemap。
3. 纯静态网站也需要考虑 SEO
工具站很容易出现一种情况：功能确实能用，但搜索引擎看到的页面内容非常少。
所以每个页面除了计算器本身，还需要清楚地解释：
● 这个工具解决什么问题；
● 输入的数据应该如何测量；
● 计算结果是怎么得出的；
● 结果有哪些局限；
● 用户接下来可以做什么。
这些内容不只是为了 SEO，也是为了让用户真正理解计算结果。
五、接下来准备观察什么？
网站上线只是第一步，接下来更值得关注的是实际数据。
我比较关心几个问题：
● 细分关键词能不能带来真实的搜索流量；
● 用户更常使用主计算器，还是某个具体的细分工具；
● 搜索用户进入页面后，是否真的完成计算；
● 哪些页面值得继续投入时间优化。
对小工具站来说，开发完成并不意味着项目验证成功。真正重要的是能不能找到明确的用户需求，并通过搜索流量持续获得用户。
如果最后发现某些关键词没有流量，或者用户需求和预期不一致，也需要根据数据调整，而不是不断增加功能。
目前先把第一版跑起来，后续再根据真实反馈迭代。
网站放这里： https://brascale.com/
如果大家也做过面向海外用户的纯静态工具站，尤其是通过 SEO 获取自然流量的，欢迎交流一下：你们通常会先做一个覆盖面比较广的主工具，还是先从几个具体的长尾需求切入？
via V2EX (author: sobinyuan)
最近花了两周时间，做了一个面向美国用户的 bra size 计算器： https://brascale.com/
整个站是纯静态的，没有后端、没有数据库，部署在 Cloudflare Pages 上。目前做了四个页面，核心功能就是根据用户输入的身体围度，计算一个参考内衣尺码。
做这个项目的初衷很简单：想试试用一个足够轻量的工具站，从关键词研究、页面设计到计算逻辑，再到 SEO 部署，完整跑一遍流程。
记录一下过程中比较值得分享的几个地方。
一、为什么选这个方向？
一开始并没有直接写代码，而是先看关键词。
美国用户搜索内衣尺码相关问题时，会涉及很多不同的搜索意图，比如：
● bra size calculator
● band size calculator
● sister size calculator
● bra size conversion
这些词看起来都和同一个需求有关，但用户真正想解决的问题不完全一样。
主词的竞争通常比较激烈，成熟的大站已经有相对完善的页面、外链和品牌积累。新站如果一上来就想竞争最宽泛的关键词，可能很长时间都没有什么结果。
所以我选择先从细分需求入手。
比如，有的人只想知道自己的下胸围应该对应什么 band size；有的人已经知道自己的尺码，只是想找姊妹码；还有的人想弄明白英寸和厘米之间的换算。
这些需求虽然相关，但完全可以分别设计页面，让每个页面尽量解决一个明确的问题。
这里也不是说长尾关键词一定比主词容易做，而是对于一个没有太多资源的新站，先把具体需求研究清楚，比直接冲最热门的词更有操作性。
关键词研究最后还是要回到搜索结果本身：看看现有页面解决了什么问题、有没有信息缺口，以及自己能不能做出更清晰、更方便使用的工具。
二、尺码计算逻辑，比写页面麻烦多了
这是整个项目里我觉得最值得花时间研究的部分。
内衣尺码计算并不是简单地把两个数字相减，再查一张表就完事了。不同品牌、国家和计算体系可能存在差异，如果直接照搬网上的一张旧表，很容易出现结果看起来合理、实际上却不太对的情况。
我在实现时，主要处理了下面几个问题。
1. 统一计算单位
内部计算以英寸为基准。
如果用户输入的是厘米，先转换成英寸：
inches = cm / 2.54
这样后续的 band、bust 和 cup 计算都使用同一套单位，避免在不同单位之间反复计算造成误差。
显示结果时再根据用户选择的单位进行转换。
2. Band size 怎么取？
这里采用下胸围取最近偶数的规则。
例如，下胸围测量值是 31 英寸，按最近偶数取值会得到 32 band。
这个步骤看起来简单，但需要注意测量值处于两个偶数中间时的处理方式，以及输入精度和四舍五入规则，否则不同页面可能算出不同结果。
3. Cup size 怎么算？
基本思路是用上胸围与下胸围之间的差值作为参考：
差值 = 上胸围 − 下胸围
然后根据差值映射到对应的罩杯。
我采用的映射规则中，差值小于 1 英寸时对应 AA，后续再按照设定的区间映射到其他罩杯。
这里需要强调一点：这是一套明确的计算规则，不代表所有品牌都使用完全相同的尺码体系。实际穿着效果还会受到品牌版型、胸型和测量方式的影响。
4. 姊妹码怎么换算？
姊妹码（Sister Sizes）的基本规律是：
● Band 增加 2，Cup 字母通常向下调整一级。
● Band 减少 2，Cup 字母通常向上调整一级。
例如，34C 的姊妹码通常包括 32D 和 36B。
原理是通过调整下胸围，同时调整罩杯容积，使不同尺码之间尽量保持接近的罩杯容量。
实现时不能只做字符串替换，还要处理罩杯字母的顺序、边界情况，以及不同尺码体系的差异。
5. 最麻烦的是 plus-four 算法
我在研究旧尺码表时，发现一个很容易造成误判的问题：plus-four 算法。
一些传统计算方法会先根据下胸围增加 4 英寸，再推算 band size。
这会产生一个很明显的差异：29–30 英寸的下胸围，经过某些旧式规则处理后，可能会被归到 34 band。
如果用户习惯的是不额外加 4 英寸的现代测量方式，这个结果就可能让人困惑。
因此，我没有直接把网上找到的旧 chart 当成唯一标准，而是明确采用自己的计算规则，并尽量让输入、换算和结果展示遵循同一套逻辑。
这也是我觉得工具站开发中很容易被低估的一件事：代码本身可能只需要几十行，但你得先搞清楚自己到底在实现哪一种规则。
三、为什么选纯静态 + Cloudflare Pages？
目前整个网站使用纯静态页面，没有专门的后端服务，也没有数据库。
选择这套方案，主要有几个原因：
1. 计算可以在浏览器本地完成。 用户输入围度后，直接通过 JavaScript 计算结果，不需要把数据发送到服务器。
2. 部署简单。 页面构建完成后直接部署到 Cloudflare Pages，不需要维护服务器、数据库和 API。
3. 访问速度和维护成本比较友好。 对于计算逻辑简单、数据量不大的工具站，没有必要为了技术架构而增加复杂度。
另外，页面里的图形尽量使用内联 SVG，而不是随便找一些模特照片或者商品图片。
一方面是版权问题，另一方面是工具本身也不需要大量照片才能完成任务。
如果以后考虑接入 AdSense，图片版权和页面内容质量也值得提前考虑。不过，使用 SVG 并不意味着自动符合 AdSense 政策，最终还是要看整个网站的内容质量、实用性和政策合规情况。
对这种小型工具站来说，我更倾向于先把核心功能和页面体验做好，而不是先堆很多视觉元素。
四、部署和 SEO 过程中踩过的坑
纯静态站不代表上线就万事大吉，域名和搜索引擎相关的细节也需要处理。
1. www 和裸域的统一
例如：
● brascale.com
● www.brascale.com
如果两个地址都能正常访问，却没有统一的规范域名，可能会给网站的索引和维护带来不必要的复杂性。
所以需要明确一个主域名，并将另一个域名通过 301 重定向过去。
这里要注意，不只是首页，其他页面的路径也应该正确保留，避免所有地址都被错误地重定向到首页。
2. Sitemap 和规范 URL
Sitemap 需要列出希望搜索引擎发现的规范页面地址，并且确保这些地址实际可以正常访问。
我在处理 URL 时也特别关注了尾斜杠的一致性。
严格来说，sitemap 并不是必须全部带尾斜杠，而是要和网站实际使用的规范 URL 保持一致。如果
/page 和 /page/ 的处理不统一，就可能出现重复 URL、重定向链或者错误的规范地址。因此，最好提前确定 URL 规则，再统一处理页面内部链接、canonical 标签和 sitemap。
3. 纯静态网站也需要考虑 SEO
工具站很容易出现一种情况：功能确实能用，但搜索引擎看到的页面内容非常少。
所以每个页面除了计算器本身，还需要清楚地解释：
● 这个工具解决什么问题；
● 输入的数据应该如何测量；
● 计算结果是怎么得出的；
● 结果有哪些局限；
● 用户接下来可以做什么。
这些内容不只是为了 SEO，也是为了让用户真正理解计算结果。
五、接下来准备观察什么？
网站上线只是第一步，接下来更值得关注的是实际数据。
我比较关心几个问题：
● 细分关键词能不能带来真实的搜索流量；
● 用户更常使用主计算器，还是某个具体的细分工具；
● 搜索用户进入页面后，是否真的完成计算；
● 哪些页面值得继续投入时间优化。
对小工具站来说，开发完成并不意味着项目验证成功。真正重要的是能不能找到明确的用户需求，并通过搜索流量持续获得用户。
如果最后发现某些关键词没有流量，或者用户需求和预期不一致，也需要根据数据调整，而不是不断增加功能。
目前先把第一版跑起来，后续再根据真实反馈迭代。
网站放这里： https://brascale.com/
如果大家也做过面向海外用户的纯静态工具站，尤其是通过 SEO 获取自然流量的，欢迎交流一下：你们通常会先做一个覆盖面比较广的主工具，还是先从几个具体的长尾需求切入？
via V2EX (author: sobinyuan)
[问与答] 如果，我是说如果，谈婚论嫁时，女方父母提出让男方婚后工资给女方管理，怎么破局。
女方家经济情况不差，女方不是那种以父母为首的人，女方父母接触下来也不是那种不讲道理的人。
彩礼三金之前和女朋友沟通过，都是正常范围，大概是 8-10 区间，给到女朋友，女方父母同样给这么多给女朋友。
女方年收入 14w 左右
男方年收入 30w 左右，房贷剩 50 w
如果，我是说如果，万一谈结婚时女方父母为了给女方争取到最大的利益，问出了这个话，在不破坏关系的前提下怎么破局。
比较明确的是不可能给女方管理，最多共同账户，当然用随便用。
问这个是因为女朋友说她妈妈私下问过她这个问题说婚后双方资金怎么管理。
via V2EX (author: PoorGuy188)
女方家经济情况不差，女方不是那种以父母为首的人，女方父母接触下来也不是那种不讲道理的人。
彩礼三金之前和女朋友沟通过，都是正常范围，大概是 8-10 区间，给到女朋友，女方父母同样给这么多给女朋友。
女方年收入 14w 左右
男方年收入 30w 左右，房贷剩 50 w
如果，我是说如果，万一谈结婚时女方父母为了给女方争取到最大的利益，问出了这个话，在不破坏关系的前提下怎么破局。
比较明确的是不可能给女方管理，最多共同账户，当然用随便用。
问这个是因为女朋友说她妈妈私下问过她这个问题说婚后双方资金怎么管理。
via V2EX (author: PoorGuy188)
[问与答] 理性讨论，是平台激发了人性的恶还是人性本来的恶找到了展现的平台
前几天 Pdd 下单了几个小工具，由于是用的多选模式，下单后订单显示一个店四个订单，然后昨天一大早突然给我发了四张无门槛券，原因是发货超时，然后我发现这个无门槛券总价值超过订单总价了，等于我没啥损失还赚了，然后昨天商家还是没发货，我晚上的时候就退货了，下单了另外一家，事后我想如果我不退货是不是商家要亏钱做这笔生意，我甚至还幻想过要是一直不发货会不会平台还会继续给我赔偿券，联想到这几年那么多离谱的仅退款事件，放以前谁会想到退货退款可以不给商家把货退回去，到底是平台在培养人性的恶还是人性的恶找到了发挥的平台。（已经给那个商家发了红包，退回了无门槛券的等值金额）
via V2EX (author: Atlas058)
前几天 Pdd 下单了几个小工具，由于是用的多选模式，下单后订单显示一个店四个订单，然后昨天一大早突然给我发了四张无门槛券，原因是发货超时，然后我发现这个无门槛券总价值超过订单总价了，等于我没啥损失还赚了，然后昨天商家还是没发货，我晚上的时候就退货了，下单了另外一家，事后我想如果我不退货是不是商家要亏钱做这笔生意，我甚至还幻想过要是一直不发货会不会平台还会继续给我赔偿券，联想到这几年那么多离谱的仅退款事件，放以前谁会想到退货退款可以不给商家把货退回去，到底是平台在培养人性的恶还是人性的恶找到了发挥的平台。（已经给那个商家发了红包，退回了无门槛券的等值金额）
via V2EX (author: Atlas058)
[酷工作] 字节 Data｜ 2027 届全职与实习岗位（个人内推）
字节跳动 Data ｜ 2027 届全职与实习岗位（个人内推）
对大模型、推荐、搜索、广告感兴趣的同学看过来。字节 Data 团队开放 2027 届全职和实习岗位，方向包括：电商推荐 × LLM 、国际电商大模型应用、搜索 / 广告 / 推荐、数据知识系统。地点：新加坡、西雅图、圣何塞。
岗位一览（个人整理，非官方）： https://datajobs-refer.xyz
内推码：41KCZBD
评论或私信「内推」
个人内推、非官方，岗位信息以官方招聘页为准。
English:
ByteDance Data | 2027 Full-Time and Internship Roles (personal referral)
Roles: https://datajobs-refer.xyz | Referral code: 41KCZBD | Comment/DM 「内推」. Personal referral, not official.
via V2EX (author: hitnutshell)
字节跳动 Data ｜ 2027 届全职与实习岗位（个人内推）
对大模型、推荐、搜索、广告感兴趣的同学看过来。字节 Data 团队开放 2027 届全职和实习岗位，方向包括：电商推荐 × LLM 、国际电商大模型应用、搜索 / 广告 / 推荐、数据知识系统。地点：新加坡、西雅图、圣何塞。
岗位一览（个人整理，非官方）： https://datajobs-refer.xyz
内推码：41KCZBD
评论或私信「内推」
个人内推、非官方，岗位信息以官方招聘页为准。
English:
ByteDance Data | 2027 Full-Time and Internship Roles (personal referral)
Roles: https://datajobs-refer.xyz | Referral code: 41KCZBD | Comment/DM 「内推」. Personal referral, not official.
via V2EX (author: hitnutshell)
[推广] [duomi-Api] 多米中转站， gpt 生图一分一张，支持模型 gpt-image-2/2.5
生图量大价格优，服务稳定，欢迎对接，欢迎对接！！！
站点： https://subapi.duomi.cloud （目前仅支持 QQ 邮箱注册登录）
gpt 生图
渠道：普号网页反代(主推)😍😍😍
● 质量：1k/2k/4k 超分
● 模型：gpt-image-2/2.5
● 价格：0.01 一张
渠道：adobe 渠道
● 质量：1k/2k/4k 原生
● 模型：gpt-image-2/2.5
● 价格：0.12 一张
gemini 香蕉生图
渠道：as
● 质量：1k/2k/4k 原生
● 模型：gemini-3-pro-image-preview 、gemini-3.1-flash-image-preview 、gemini-nano-banana-2.1
● 价格：0.12 一张
📞 问题随时反馈客服
● qq 群：801244559 ，点击链接加入群聊 [ [ duomiAPI ] GPT 中转①群] ： https://qm.qq.com/q/xJXAfThL9e
● 微信号：woaishiduomi
其他
gpt 性价 0.09
gpt 不降智 0.19
Claude （ Kiro ）- 0.18
via V2EX (author: xiao8276)
生图量大价格优，服务稳定，欢迎对接，欢迎对接！！！
站点： https://subapi.duomi.cloud （目前仅支持 QQ 邮箱注册登录）
gpt 生图
渠道：普号网页反代(主推)😍😍😍
● 质量：1k/2k/4k 超分
● 模型：gpt-image-2/2.5
● 价格：0.01 一张
渠道：adobe 渠道
● 质量：1k/2k/4k 原生
● 模型：gpt-image-2/2.5
● 价格：0.12 一张
gemini 香蕉生图
渠道：as
● 质量：1k/2k/4k 原生
● 模型：gemini-3-pro-image-preview 、gemini-3.1-flash-image-preview 、gemini-nano-banana-2.1
● 价格：0.12 一张
📞 问题随时反馈客服
● qq 群：801244559 ，点击链接加入群聊 [ [ duomiAPI ] GPT 中转①群] ： https://qm.qq.com/q/xJXAfThL9e
● 微信号：woaishiduomi
其他
gpt 性价 0.09
gpt 不降智 0.19
Claude （ Kiro ）- 0.18
via V2EX (author: xiao8276)
[推广] 智友社上新啦， Grok 新版订阅 Premium、Ultra 稳定特殊渠道独享成品号（支持 Grok Bot、Cursor），欢迎您的试用反馈！
智友社上新啦，Grok 新版订阅 Premium 、Ultra 稳定特殊渠道月卡独享成品号 1 （支持 Grok Bot 、Cursor ）
Grok Premium 商品购买链接： https://wzyp.cn/item/bztplw ，价格 128.88 ，官网 30 刀
Grok Ultra 商品购买链接： https://wzyp.cn/item/8unjy0 ，价格 468.88 ，官网 200 刀
欢迎您加入：
我们的官方 QQ 开放交流 3 群：27078264
我们的官方 TG 开放交流群： https://t.me/+fzIWsUSbcq1kMDYx
我们的官方 店铺地址： https://pay.ldxp.cn/shop/282D9KDL
via V2EX (author: Ai2You)
智友社上新啦，Grok 新版订阅 Premium 、Ultra 稳定特殊渠道月卡独享成品号 1 （支持 Grok Bot 、Cursor ）
Grok Premium 商品购买链接： https://wzyp.cn/item/bztplw ，价格 128.88 ，官网 30 刀
Grok Ultra 商品购买链接： https://wzyp.cn/item/8unjy0 ，价格 468.88 ，官网 200 刀
欢迎您加入：
我们的官方 QQ 开放交流 3 群：27078264
我们的官方 TG 开放交流群： https://t.me/+fzIWsUSbcq1kMDYx
我们的官方 店铺地址： https://pay.ldxp.cn/shop/282D9KDL
via V2EX (author: Ai2You)
[分享创造] 开源！公众号一键发布发布工具懒人版
接上一篇《开源！全套公众号写作、封面、发布自动化工具包》
把全部底层的插件都开源后，还是有不少人反应太麻烦。原因可能是没真的用 AI 把它们串起来，或者是我从技术角度考虑太多了，并且内容创作者本身也是少数。
所以又把所有包做了一次整合。（感谢 Opus5.5 和 miniMax3.1flash
虽然我认为 Agent 仅靠 zzhub-pipeline 和 bun-wx-server 已经可以完成自动化写作+发文了。
但最终的整合版本 wx-publish-studio ，可以直接 docker compose up 拉起全部服务，对于有点动手能力的小白也算是减小了一些阻力！
注意：文章渲染插件依赖 milkdown 这个包，且自定义了许多语法组件，但公众号贴图渲染插件暂时并不支持所有语法，所以在让 AI 写文章时要用 skill 区分文章和贴图，避免自动发到草稿箱发现有没识别出来的语法。
以下是我本地跑起来后的界面预览：
登录走口令 主界面 配置公众号，里面会一步步的教你如何配。 配完后，直接写文章+配置文章排版，我预设了几套，可以自由调整后保存 这一步支持自定义 css ，理论上你可以复刻见过的所有排版 然后配置封面模板
一次配置后对所有文章生效，以后写文章就不用管这些了！
如果对你有帮助的话，欢迎 Star ，提出需求～
via V2EX (author: gnakzz)
接上一篇《开源！全套公众号写作、封面、发布自动化工具包》
把全部底层的插件都开源后，还是有不少人反应太麻烦。原因可能是没真的用 AI 把它们串起来，或者是我从技术角度考虑太多了，并且内容创作者本身也是少数。
所以又把所有包做了一次整合。（感谢 Opus5.5 和 miniMax3.1flash
虽然我认为 Agent 仅靠 zzhub-pipeline 和 bun-wx-server 已经可以完成自动化写作+发文了。
但最终的整合版本 wx-publish-studio ，可以直接 docker compose up 拉起全部服务，对于有点动手能力的小白也算是减小了一些阻力！
注意：文章渲染插件依赖 milkdown 这个包，且自定义了许多语法组件，但公众号贴图渲染插件暂时并不支持所有语法，所以在让 AI 写文章时要用 skill 区分文章和贴图，避免自动发到草稿箱发现有没识别出来的语法。
以下是我本地跑起来后的界面预览：
登录走口令 主界面 配置公众号，里面会一步步的教你如何配。 配完后，直接写文章+配置文章排版，我预设了几套，可以自由调整后保存 这一步支持自定义 css ，理论上你可以复刻见过的所有排版 然后配置封面模板
一次配置后对所有文章生效，以后写文章就不用管这些了！
如果对你有帮助的话，欢迎 Star ，提出需求～
via V2EX (author: gnakzz)