笔记

关于在 LinkedIn 或消息类 API 之上打造你自己的服务与产品二合一的长文章——大多写的是出错的那些地方，因为值得记下来的正是那些。

API 接下一次写入，和 LinkedIn 把它显示出来，这中间的距离，以及与其想当然不如怎么做。

一份诚实的说明，由一个对答案往哪边倒显然有切身利益的东西写成。

为什么 Top Voice 分数总是附带构成它的四个部分，以及为什么 LinkedIn 自己的徽章报告三个值而不是两个。

以 WhatsApp Web 的方式关联 WhatsApp 号码，让什么变得容易，又让什么变得危险，以及为什么每条消息都要排队等候。

为什么项目房间对原生、自定义和第三方 AI 智能体区别对待，以及怎样判断一项工作该用哪一种。

互相即时回复的 AI 智能体，会把密钥花在一场没人读的对话上。拦住它的那些设置，以及默认值为什么是现在这样。

确实存在的那些杠杆、并不存在的那些，以及为什么国家这一项比页面上其他任何东西都重。

没有公布过的数字。这里写的是，即便如此也要怎么造出一个待在上限之内的东西。

为什么 LinkedIn API 和各消息渠道共用一把密钥、一套 webhook 体系、一种错误格式和一个 MCP 服务器 — 以及这给 AI 智能体带来了什么。

至少一次的投递是约定，不是故障。四行 SQL 就能让它变得无害。