这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
《互联网产品的 AI 架构·模型接入与能力边界》6.3 提示版本化与发布
「回声」一次直接改线上提示、没有版本记录，效果变差后无法回滚，只能凭记忆重写。本节把提示发布做成不可变版本、变更记录、确定性灰度与回滚，并要求提示与模型快照精确绑定，配可运行的 TypeScript 注册表与完整测试，并把发布审计写进事件日志。
posts
文章归档
PlumePHP 全站文章的归档入口，按时间倒序汇总各专题的技术文章，并提供按主题浏览的专题分类入口。
版主与志愿者：四级权限、轮值表与退出
志愿者不是免费客服。本文给出 L0–L3 四级权限、三人轮值表、交接文档与退出回收，并用每天 14 小时活跃时段复算 7.1% 的固定巡检覆盖率、12 小时响应目标、每周省下的 3 小时，以及志愿者长期无偿投入的真实成本。
版规：十条能执行的规则与三档处置
版规不是价值观，是处置说明书。本文给出十条能被观察和举证的规则、提醒/限言/移出三档处置、证据要求与申诉路径，并用每月 480 条帖子、12 次违规复算 98 分钟的执行成本与 8.3% 的误判率，并区分紧急止损、最终处置、复核和申诉的先后关系。
冷启动前 100 人：从 1200 人名单里请谁来
从已有名单邀请成员，先核对互动与联系意愿。本文从名单里筛出 320 个可邀请的人，给出邀请脚本、前 20 人的氛围设计与 30 天漏斗，并复算 1200→320→144→100 的每一步转化与每名月底产品参与留存成员 18.55 美元的组织成本。
载体选型：Discord、论坛、微信群与邮件组的同一张表
Discord、论坛、微信群与邮件组不是功能之争，而是沉淀、治理、通知、可达与成本之争。本文用一张五判据加权表给四个载体打分，给出主阵地、存档位与通知位的组合方式，复算一次迁移的 40 小时成本，并把退出条件写进选型表。
社群该不该建：四个信号、四个反信号与四笔成本
建社群前先算清四笔账：时间、工具、情绪与机会成本。本文给出四个该建的信号、四个不该建的反信号、30 人最小验证与三条止损线，并用 1200 人名单、240 名成员与 20 小时维护成本，复算什么规模才值得建、什么规模应当放弃。
消息系统验收：送达、打扰、合规与成本四张表
消息系统验收要能从原始记录复算。本文给出投递、打扰、治理与成本十二项检查，以通过数而非主观小数评分，算出 0.7333 的示例总分，并按风险、缺数据和最低维判定动作；同时核对每封 0.076 美元的经济成本，说明配置通过不等于收件箱或全球合规保证。
同意与退订：订阅确认、退订时效与记录
订阅与退订要能追溯范围、时间和实际生效。本文区分产品自定的确认规则、收件平台要求与适用地区规则，说明导入名单不能直接重确认群发、正文退订与 RFC 8058 的区别，并用 1200 到 984 的名单算例核对记录、抑制同步和跨产品偏好的边界。
生命周期序列：欢迎、激活与召回各几步
一个付了两年的老客户，还在收「了解一下我们的定价」。本文给出欢迎、激活、召回三段序列的步数、间隔与频控，重点讲五个退出条件如何挡掉 62% 的无效触达，并用误发率 6% 降到 1%、每月省 60 美元工单成本做一次完整复算。
渠道分工：站内信、推送、邮件与短信怎么接
同一个通知走错渠道，要么没人看见，要么一条五美分。本文比较站内信、邮件、推送与短信的到达、成本、可撤回与打扰度，给出推送权限的索取时机、失败回退链与短信防刷四道闸，并用 800 条验证码涨到 3000 条复算一夜之间的账单。
偏好中心：让用户自己决定收什么
只有一个「全部退订」，用户想关周报就只能连账单提醒一起关。本文给三类开关的粒度、必要条件与频率设置、保存即生效的界面规则，并用退订率 4.2% 降到 1.1%、保住 37 个用户、2220 美元年价值复算 960 美元建设成本的回本周期。
通知分层：什么该打断，什么该等
每条通知都标「重要」，用户就会关掉全部通知，包括那条扣款失败。本文把通知分成阻断、即时、摘要与静默四级，给出各级的默认渠道、延迟容忍与频率上限，并用每人每日 7 条降到 2.1 条复算打扰预算、关闭率与每月少发的十一万条。
送达率账本：退信、投诉、垃圾箱与黑名单
送达账本要先分清最终状态、独立地址与投诉覆盖。本文用 5000 个收件投递单位复算服务器接受率和内部投诉占比，解释为什么不能把退信次数除以发送频次来算地址数，也不能把 Gmail 用户举报率当成全量垃圾箱率；再给出抑制、恢复、限流与低流量观测的检查方法。
发信域名与认证：SPF、DKIM、DMARC 的最小配置
邮件认证要分清身份、签名与对齐。本文核对 SPF 记录选择和查找上限、DKIM 选择器、DMARC 的两条通过路径与现行标准，再给出分阶段部署、报告核验和转发测试清单，说明为什么分子域名与认证通过都不能保证邮件进入收件箱，也不把教学收益算例当成实测效果。
事务邮件基线：验证码、重置与收据不能迟到
事务邮件不能只看接口返回成功。本文区分入队、服务商接受、收件服务器接受与用户可用，给出按有效期停止的重试、持久去重和异常恢复方式；再用每月 3000 条独立事务、2% 首次失败与 80% 可恢复比例，复算预期工单工时，明确延迟观测与备用渠道的边界。
《互联网产品的客户端架构·交易、增长与平台化》10.1 实验分流与曝光口径
结算页改版上线后先涨后跌，问题往往不在实验结论，而在分流与曝光口径。本节用哈希加盐实现稳定分流、用分层隔离并行实验、把渲染、可见、点击三种曝光分开，并给出只上报一次的曝光日志与灰度开关模型，代码可直接运行，最后复盘一次按会话分流的典型误判。
消息清点：一个产品到底需要发多少条消息
产品里的自动消息往往是一条条加上去的，没人清点过。本文给出七字段清单、四类消息的关闭边界与十二类该砍的消息，并用 38 条减到 26 条、月发送 7600 封降到 5000 封复算人均打扰。先清点，再谈送达、分层与偏好设置。
自助支持验收：拦截率、首次解决率、成本与风险四张表
自助支持做了三个月，值不值得继续？本文沿用 200 次支持需求的漏斗，区分 80.5% 首次解决与 98% 最终解决，按拦截、首次解决、成本和风险四维重算 0.7145 综合分，并明确风险未闭环时必须先修再扩。分数不是考核，是下一季度的动作清单。
《游戏服务端架构·品类、状态与拓扑》13.1 三款产品的架构基线
把卷一前十二章的决策固化成三张可评审的架构基线卡：每张写明拓扑、状态归属、连接模型、权威模型、部署单元与关键 SLA，并列出已接受的取舍、已知风险和复审触发条件。配套 Go 包用字段完整性与跨产品一致性校验，防止基线在复制粘贴和人员轮换中悄悄走样。
人工升级路径：自助失败之后怎么交给人
自助失败之后的交接质量，决定用户会不会把不满写成差评。本文给出自助、一线、本人三级路径，五类必须升级的触发条件，六个交接字段与响应承诺，并用 200 张工单的完整漏斗复算升级率、误升级率与首次解决率。交接包缺一项，用户就要重说一遍。