今天才开始写，抱歉让大家久等了。

2023 对我，对各位简友，包括整个简书生态，都是不平凡的一年。

我们走过 2022 落格计划，经历 2.28 至暗时刻，简书小工具集 v3 从内测到上线，再到不断迭代完善。

简书社区宣布治理 AI 内容，积分兑换平台历经多次价格调整宣布放开，一贝商城上线，JKit 开发者预览版发布。

那就按照时间线顺序说一下吧。

关于年度总结

应该是第三次提到这个话题了，2023 不会有年度总结。

我个人的时间安排原因占一方面，我们其实不太喜欢回顾过去，每个人在简书的经历都是不断自我迭代，不断进步的过程。

所以，今年我们将重心放在技术升级上，致力于建设更坚实的基座，以便小工具集和其它产品可以持续为大家带来优质的体验。

我们将在近期测试一系列新技术：新版数据存储模型、数据采集工作流、日志平台等，这些技术会先在内部项目进行测试，然后推广给大家正在使用或间接使用的服务。

非常抱歉，2023 年度我们要缺席了，不过 2024 的美好正在赶来。

服务可用性报告

本年度，我们发生了一次服务中断，时间从 2023.02.28 13:05 - 18:58，共 6 小时 53 分钟（413 分钟）。

本年度的服务可用率为 99.92%，未达预期。

我们的可用性目标是 99.97%，2.28 事故发生后，我们也实行了一系列可用性方面的升级措施，包括引入每三小时的服务器增量备份，定期进行备份恢复演练，强化可观测性，规范部署流程等。

近期我们对部分服务应用了 GitHub Actions CI，后续将支持在发版时自动构建并上传镜像，配合脚本实现常规升级自动化。

小工具集捉虫计划也是我们寻找问题并改善用户体验的重要途径，我们将强化捉虫奖励机制，考虑在首页展示近期捉虫贡献信息，以激励更多简友参与到活动中。

关于 2.28 故障细节，详见： 2023.02.28 故障复盘 | 一条配置让我们崩了 7 小时？

简书小工具集

从 6.19 简书小工具集 v3 发布以来，简书小工具集的总访问量为 42200 次，页面平均停留时间为 40s。

访问量较高的小工具：

名称	访问量
上榜文章查询	15600
商城贝市分析	6540
LP 理事会推文检测	2690
会员收益计算	2360

87% 的用户使用手机访问小工具集，安卓用户占其中的 82%。

在使用电脑访问的用户中，Windows : MacOS : Linux 约为 5 : 2 : 1。

来自中国大陆的用户最多，占总用户量的 94%。

我们观察到使用 v2 链接的访问量从 8 月开始明显减少，目前每天约有 20 次访问来自 v2 链接。

v2 链接访问中，上榜文章查询工具的访问量最大。

后续，我们将对 v2 链接访问添加提示，并最终移除这项兼容逻辑。

主动切换颜色主题的用户极少，也少有用户会点击搜索按钮。

对于后者，简书小工具集的搜索功能未来将作为快捷操作中心，也是后续运营活动的入口之一，我们将不断添加更多功能。

小工具集 v3 共发布了 11 个版本（不含 Beta），以下是我们近期的迭代计划：

• 资产排行榜分析工具
• 发布基于 Query Args 的集成
• 增强搜索功能
• 新版 API 文档

关于 AI

2023 是 AI 元年，也有很多朋友在问小工具集是否会引入 AI 功能，刚好借这个机会向大家公开我们对这项技术的看法。

我个人认为 AI 现在的发展路线（大语言模型 + 微调）是存在较大问题的，这种形式对使用门槛的降低导致了巨大的监管风险，因此小工具集不会引入诸如 AI 大纲、文章续写、图片生成等「强创作性」AI 功能，我们也相信这是简书社区的重要治理方面。

但与此同时，我们看到了 AI 技术对创作、对我们日常生活的辅助作用，所以小工具集将会加入，并投入一定资源去宣发推广诸如文章情感分析、文章摘要、敏感词识别、自动纠错等偏辅助性的功能。

由于上述功能使用的第三方 API 成本问题，我们将对功能使用进行一定限制，这也可能成为小工具集的第一个付费点。

我们相信优质的产品需要用户的支持，作为简友独立开发运营的简书第三方生态平台，这是小工具集现在和未来全站无广告的原因，也是我们对社区的信任。

在上述各服务的开发过程中，我们从未使用，也承诺在 2024 年度不使用基于人工智能的代码、文案生成服务。

但我们会在诸如安全性检测、代码质量管理等流程中运用 GitHub CodeQL 等完善的人工智能技术提升我们的工作效率，并保证上述服务可以快速迭代，如期交付。

贝市

2023 上半年简书积分兑换平台经历了无数次价格调整，我 声讨 过一次，总之 7.24 宣布了不再干预贝价，不再调整价格限制。

这也是小工具集贝市分析工具获得高关注度的原因之一。

今年陆续有人问我有没有计划做自己的贝市场，我给出的都是否定答案。一方面是资质和监管问题，需要公司身份、备案、增值电信业务许可证等等一系列材料，另一方面贝市这个东西其实是烫手山芋，没人想碰。

简书官方的态度已经很明显了，不管什么原因，不会给第三方贝市平台放官方 API，所以贝岛-like 产品只能走两条线。

一条是小额大众化，走量，靠手续费和广告营收，积分兑换平台是这条赛道，缺点是审核必须人工进行，时效性不好并且管理者很累。

这种模式也是典型的 C 端产品（简书中散户算 C 端，贝商和频繁交易的合伙人算 B 端），用的人多问题也就多，加上积分兑换平台研发团队不太稳定，能维持正常运营已经很优秀了。

另一条路是专给大户服务，设置高准入门槛，依靠真金白银规范用户行为，一贝商城是这条路。

不过一贝只有商家端（卖侧挂单）有高准入门槛，相当于集中化、统一管理的菜市场而不是早市，买家几乎没有门槛。

优点是大户不会频繁提现，人工成本相对较低，缺点是客源不太稳定。

既然这两条路都有人走了，两者也没有非常大的过失，再入局就显得不合时宜了。

不过这两个平台并非十全十美，我还是有想吐槽的地方。

简书积分兑换平台，大转盘纯属多余，AI 研发了一直不用（据说也不怎么好用），浪费成本，商品市场一天天宣发也不见有什么效果，这几点有待加强。

一贝商城，重新思考准入门槛（押金和年费），平台体量太小，面对大户增减持调节力度不足。

至于这两个平台会不会有竞争，至少现在是稳定的，两者一个有手续费一个高准入门槛，贝商肯定是要琢磨的。

散户方面一贝商城的用户体验比较好，但积分兑换平台有一定存量用户，再加上他们的用户交流群更活跃一些，另外积分兑换平台的掌权人是开发公司高管，一贝商城则是合伙人找的外包，外包公司是个小微企业。

这些信息都好验证，看两个平台的「关于」页面，看对应公众号的认证主体，天眼查搜一下公司名即可。

JKit

首先是大家最关心的问题，什么时候发 Beta / 发正式版？

别急，现在 JKit Alpha 还缺少文集 / 连载和小岛方面的功能，我们希望做到和 v2 功能上保持一致。

v3 的主要亮点是全异步操作，数据模型和自动校验，配置流程，以及一些私有接口。

异步操作这块，社区大趋势，我们的服务后端也从 Sanic 换到了 Litestar，最近又要从 Motor 切换到 ODM 做数据库操作。

技术升级了一波，发现最后就基础库这块还是同步，于是新版就改成异步了呗，再加上 API 封装 SDK 这种场景本身就是 IO 密集型，用异步再合适不过了。

数据模型主要是为了编辑器自动补全 / 类型推断，自动校验是附加的功能，也能避免一些诸如简书抽风搞出的负粉丝数在后续分析中导致奇奇怪怪的问题。

我们的思路是「只要你在默认配置下使用 JKit，拿到的数据就一定是符合常理的」，不该负的不会负，不能空的不会空，文章链接不会变成用户链接。

配置流程方面，直接从 jkit.config 导入，然后修改对应的配置项即可。

关于数据校验的配置要注意下，校验开销真的小到可以忽略（<5ms），如果你的场景对时间要求苛刻到需要关校验换性能，那不如想想怎么优化自己的代码 / 做做缓存。

私有接口方面，未来有计划支持文章操作 API，做到自动发布 / 更新文章等操作，至于资产操作接口会不会做需要后续评估，这一块可能会在正式版发布后迭代更新，不会一步到位。

鉴权 Token，document.cookies 拿不到的，不用试了，remember_user_token 是 HttpOnly 的。

所以想拿到鉴权 Token 只能从浏览器开发者工具翻，或者抓包。

Alpha 阶段先自己用用就行，别让别人给你发 Token 采集别人数据，虽然理论上不会有问题，但是涉及到用户账号安全的问题还是谨慎一些好。

如果 Token 泄露，最简单的办法就是在拿 Token 的浏览器上退出简书账号让 Token 失效，未来 JKit 也会实现类似的功能。

再提醒一遍，掌握 Token 可以删掉你的所有文章（包括回收站）、把你的钻全转成贝让收益骤降，所以不要向不信任的人透露 Token。

当然，这些都是 JKit 开发者要在意的问题了。

后记

那就差不多写完了，我们一起，向未来出发吧。