28 lakh误写28万：数量级修正

28 lakh误写28万：数量级修正

凌晨两点，印度一家医院的血液科柜台前，值班人员拿起电话，拨给街对面的血库，没人接。再拨下一家，还是没人接。接着翻出一份献血者名单，一个一个打过去——有人不接，有人不符合条件，有人住得太远。

印度政府 e-RaktKosh 平台上登记了超过 28 lakh（即超过 280 万）献血者，但在这样的深夜，几乎没有一个能通过这种方式被找到。这就是 RaktSetu 想解决的问题：把那条靠电话串起来的链条，换成一套能自动派发的系统。

护士只需要共享患者所在位置，再回答四个问题：需要什么成分（全血、红细胞、血小板还是血浆）、血型、几个单位、有多紧急。或者干脆用平时说话的方式打一句：“O+ 血，2 个单位，Andheri，紧急车祸。”

接下来系统会做四件事：

• 先从附近血库的现有库存里预留，由近及远；
• 只针对缺口招募献血者，分批进行，优先最近且符合条件的人，没人回应就扩大范围；
• 告诉每位献血者具体去哪：医院、地图链接、联系电话，外加一个私人页面，可以在上面答应、拒绝，或者用自己的话回复；
• 需求一旦被满足，立刻通知其余所有人不用再来了。

谁付钱？医院和血库，按月订阅。他们买的是员工在别人一天中最糟糕的那十分钟里的时间。献血者和患者永远不付费——印度的献血依法属于自愿行为，产品就是围绕这一点设计的。

这个项目的起点是另一场黑客松。一个叫 RaktKhoj 的提案（团队 Blood Boys，赛事 Build What Moves India）把这个问题原样摆了出来，其中提到一个数字：印度有 12% 的区，距离最近的血库超过 100 公里。RaktSetu 是在这个命题上独立做出来的东西，有自己的名字、代码和架构。

作者给自己定了一条设计规则：语言的事交给开放模型，所有医疗和安全判断留在朴素、可测试的代码里。

Gemma 3（4B，通过 Ollama 本地部署）承担三件涉及杂乱人类语言的工作，每一件的输出都要先过一道确定性校验，才能被系统采信。

第一件是读懂匆忙中打出的请求。模型把“critical: B+ x3 units, near Powai”转成结构化字段，然后代码会核对血型、单位数和地点是否真的出现在护士输入的文字里。早期版本里，一条写着“in Delhi”的请求会被悄悄匹配到孟买列表里最近的地点。现在这种情况会被直接拒绝，并提示工作人员需要改什么。在这个领域，一个“好心”帮你补全空白的模型，是最危险的一类错误。

第二件是写给献血者的消息。模型负责写开头那段有人情味的话，后面的事实部分——需要什么、哪家医院、地图链接、联系电话——全部从数据库记录里拼装。任何包含数字或链接的草稿都会被丢弃，这样模型永远没有机会编出一个地址或电话号码，把献血者引到错误的地方。

第三件是理解回复。献血者怎么回都行。“haan aa raha hoon, 20 min mein pahunch jaunga”会被读成接受，预计 20 分钟到达；“Sorry, I had fever last week”会被读成拒绝，并附一条备注给工作人员。测试期间，模型把“Can I come after 6pm instead?”读成了同意。所以现在只要回复里出现否定或条件（问号、“after”、“instead”、“maybe”、“kal”），就会否决“接受”的判定，把这条回复归入“需要打电话”，献血者的号码一键可拨。把不会来的人标成会来，是代价高昂的错误；多打一个电话，很便宜。

如果模型响应慢或连不上，措辞会退回固定文本。派发流程从不等模型。

这个产品真正难的部分是时间。你给十个人发消息，然后等。有人一分钟就回，有人永远不回，而服务器应该能在中途崩溃，且不会有人被重复通知或被遗忘。

EmergencyRequestWorkflow 是一个 Temporal 工作流：先预留血库库存，如果血库能全覆盖就立即结束；发一批最近的合格献血者，然后挂在一个持久化计时器上等；每位献血者的回复被当作一个信号，目标一达成立刻停止；如果一批人全部回复完毕（比如全部拒绝），就提前唤醒，而不是干等计时器走完；在一个半径内把所有合格献血者走完，才扩大到下一个半径（5、10、25、50 公里）；结束时，通知所有仍在等待的献血者他们不再被需要。

活动是重试安全的：每条消息以请求和献血者为键做 upsert，重试的活动不会给同一个人发两次。这在实践中很重要。作者开发时用的网络会时不时断开数据库连接，他亲眼看着活动在请求中途失败、退避重试、然后从断点继续，而医院那一侧的界面毫无察觉。

地理和医学规则被放进同一次查询。献血者和血库存在 MongoDB Atlas 里，带 2dsphere 索引。找下一批人是一条 $geoNear 查询，同时套用医学规则，所以批次上限只统计真正能献血的人：

• 资格，依据印度 NBTC 指南：年龄 18 至 65 岁，体重至少 45 公斤，男性距上次献血 90 天、女性 120 天；
• 按成分的相容性。红细胞遵循大家熟悉的献血表；血浆方向相反，AB 是通用血浆献血者，Rh 不重要；血小板遵循血浆规则，且 Rh 阴性患者只接受 Rh 阴性献血者。

血库库存用原子条件递减来预留，两家医院同一时刻发起请求，也绝不会被承诺同一袋血。

信任方面：工作人员接口按医院访问码隔离（公开演示中关闭，因为数据全是合成的）；每位献血者的链接在 URL 片段里带一个随机 ID，因此不会出现在服务器日志中；工作人员只有在献血者答应或要求回电之后，才能看到其电话号码；页面运行在严格的内容安全策略下，不允许内联脚本和样式。33 个测试覆盖医学规则、模型护栏和工作流。

哪些是模拟的？作者没有 e-RaktKosh 的访问权限，所以献血者和血库都是合成的：孟买 460 名献血者、13 家血库，外加浦那和纳西克附近一个完全没有血库的集群——那 12% 远离血库的区就是这个样子。消息显示在献血者模拟器和献血者页面上，而不是通过 WhatsApp 发出。发送逻辑藏在一个 NotificationProvider 接口后面，接入 WhatsApp Cloud API 只需要改一个文件，匹配和工作流都不用动。

那个启发了这个项目的提案，最终没能走出演示阶段。这是好的公益想法常见的命运：真要把它做出来，需要团队、预算，以及一条随每条消息增长的 API 账单。

开放工具改变了这笔账。Gemma 跑在医院自己的机器上，患者的血型和位置从不离开这栋楼，读一条献血者回复也不按条计费。对一个最忙的夜晚恰好是高速连环车祸或登革热暴发的产品来说，这一点很关键——那正是按请求计费的账单会飙升的时刻。Temporal 的开源服务器让一个独立开发者在笔记本上就拿到了生产级的持久化工作流，和大公司跑的是同一个引擎，没有许可证挡在个人开发者和可靠性之间。而因为这些都是开放的，一个邦的卫生部门或一家 NGO 可以逐行检查献血者是怎么被选出来的，自己部署，自己修改。对一个决定“该请谁去献血”的系统来说，这种透明度本身就是产品的一部分。