Work Summary
本周期有效记录集中在认证链路与部署链路，主项目为 /home/yunpiao/data/fenshululu-auth，其次是 /home/yunpiao/data/fenshululu。工作重心从基础连通性逐步转向语义正确性：先处理 Supabase 实例识别、本地实例暴露、Cloudflare/Tailscale 联调，再进入扫码登录、注册跳转、跨域、Edge/Node 运行时分工、Docker 实际部署等真实链路问题。
在认证服务侧，问题表现出明显的跨层耦合特征。前端看到的是扫码失败、跨域报错、注册后状态异常；中间层涉及 EdgeOne/Node Functions 路由与响应头；后端则牵涉 Supabase、metrics、副作用写入、错误返回结构和运行容器版本。多轮排障后，主题逐渐收敛为两类：一类是“代码是否真正进入目标容器”，另一类是“请求是否在浏览器、网关、运行时、业务逻辑四层保持同一语义”。
到周期后段，问题从单点缺陷上升为数据模型问题。新注册用户看到既有学校、班级和学生数据，说明隔离边界并未成为系统不变量，而只是散落在应用逻辑中的约定。对应地，工作内容从补丁式修复转向整体治理：提出“每个用户自己的班级和学生完全独立”的目标，要求全面探索代码库、以团队并行方式制定计划，并继续修复 BDD 与回归链路，表明项目已进入从功能可用走向可验证、可部署、可隔离的稳定化阶段。
Improvement Areas
1. Docker 验更与部署可追溯性
现象：围绕“是否已经部署到最新镜像”“路径是不是错了”“直接更新 Docker”出现多轮反复确认，且一度把运行状态误判为代码已更新。
根因：代码版本、镜像版本、运行容器版本三者没有被同一套标识绑定；缺少面向运行态的验更手段，导致排障阶段持续在“代码改了”“容器跑着”“用户看到的还是旧行为”之间来回切换。
行动项：
- 为认证服务与主应用注入统一的 build metadata（git SHA、build time、image digest）
- 增加运行态版本接口或健康检查扩展字段，验更直接对照容器内版本
- 为
/home/yunpiao/data/fenshululu与/home/yunpiao/data/fenshululu-auth固化发布后 smoke checklist，先核对路径与容器，再看业务现象
2. 多租户隔离下沉为数据库级不变量
现象：新注册账号关联学校后即可看到其他数据，直接违背“每个用户自己的班级和学生完全独立”的目标。
根因：租户边界主要停留在应用层语义，未被数据库约束、查询默认条件和测试负例共同兜底；一旦遗漏过滤条件，跨租户读写就会发生。
行动项：
- 明确 tenant、school、class、student、user 之间的所有权模型，禁止隐式共享
- 在数据库层引入统一 tenant 过滤机制，优先采用 PostgreSQL RLS 或等价的强制策略
- 为“新用户不可见历史班级/学生”“跨租户读取为空”“跨租户写入失败”增加负向测试用例
3. CORS 与认证链路排障方法需要固定化
现象：同一问题先后表现为 418、204 后仍报 CORS、header 已携带 app_id、浏览器依旧阻断，期间还夹杂 Edge 与 Node 同名函数、响应体 JSON 解析异常等现象。
根因：排障过程多次被表层症状牵引，未把预检请求、正式请求、网关转发、运行时处理、业务鉴权拆开验证；同一接口在多个层面都有配置点，导致责任边界模糊。
行动项：
- 固化跨域排障矩阵：浏览器控制台 → OPTIONS 响应头 → 正式请求响应头 → 网关路由 → 业务处理
- 将 CORS 配置收敛到单一所有者，避免 Edge/Node 双处维护
- 为登录、状态轮询、注册跳转三条关键链路保存真实请求样本，作为回归基线
4. 认证流测试分层不足
现象：一方面出现“测试未写完就提交”的争议，另一方面又长期依赖浏览器安装、视觉测试、BDD 全量回归来证明关键认证流程是否正常，反馈成本高且经常被环境阻塞。
根因：关键业务流缺少中层保障。单元测试无法覆盖真实状态机，而全量 BDD 又过慢、过脆；缺少针对认证工作流的 API 级 E2E smoke 与契约测试，导致每次修复都要把大量验证压力推到最后。
行动项：
- 为二维码生成、状态轮询、确认登录、未注册跳转、班级列表获取建立 5-10 条 API 级 smoke 流程
- 为错误码、错误体、CORS 头、鉴权头建立契约测试，覆盖最容易回归的接口边界
- 将全量 BDD 放到较慢的稳定化阶段，PR 前保留关键链路 smoke 与集成测试
Strengths
- 语义导向很强：反复追问“容器里是不是最新代码”“为什么新用户会看到别人的数据”，关注点始终落在真实行为而非表面通过。
- 能压缩错误诊断空间：当排障被 418 或单一日志带偏时，会明确指出旧结论无效，迫使问题重新回到请求链路和运行事实。
- 跨层问题意识清晰：从浏览器、CORS、Node/Edge、Supabase、Docker 一路向下追，具备把症状映射到系统层级的能力。
- 愿意把单点缺陷升级为架构问题：从扫码异常继续追到注册流、数据隔离、团队并行改造，说明已具备从修 bug 走向改系统的判断力。
Action Items
- P0 - 为认证服务和主应用补齐运行态版本标识与验更接口 → 部署后可用 SHA/digest 直接核对容器版本
- P0 - 落地 tenant 级数据模型与数据库强制隔离 → 新用户绝不再读取到其他用户的班级和学生数据
- P1 - 建立认证链路 CORS 排障基线与单点配置源 → 预检和正式请求问题可快速定位到具体层级
- P1 - 建立认证工作流 smoke E2E + 契约测试组合 → BDD 压力下降，回归粒度前移
Tech Trends
今日 HackerNews 热门技术话题精选。
1. Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
Points: 486 | Comments: 372
LiteLLM 的 1.82.7 与 1.82.8 版本发生了典型的 PyPI 供应链投毒事件。公开讨论显示，1.82.8 带有 litellm_init.pth，会在安装阶段被 Python 自动加载；1.82.7 则把恶意载荷埋进了 proxy_server.py。这类攻击危险之处不在于“运行了某个入口脚本”，而在于开发者往往把 pip install 视为静态下载，实际上它已经是代码执行边界。
维护者随后隔离并删除了相关版本，轮换了发布与 CI/CD 凭据。对做 AI 基础设施的人，这个事件的意义非常直接：模型网关、代理层、SDK 聚合器通常天然接触大量密钥与上游凭证，任何一次包管理器投毒都会绕过应用层权限边界，直接命中开发、构建和发布链路。
Key Takeaways:
- 包安装本身就是执行面，LLM 基础设施依赖必须做版本钉死与来源审计
- 发布链路上的 PyPI token、CI token、Docker 凭据需要按“已泄露”模式设计轮换与隔离
2. Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon
Points: 191 | Comments: 75
Hypura 的核心思路不是继续压缩模型，而是把 Apple Silicon 上的统一内存与 NVMe 存储当作分层内存系统来调度。它尝试把超出内存容量的模型权重按需要从 GGUF 文件读入 RAM/GPU memory pools，在本地机器上换取“更大模型可运行”这一能力。讨论中也明确指出，这是一种读路径优化，而不是传统意义上的 swap thrash。
真正有意思的地方在于，它把本地推理问题重新定义成“容量、带宽、访问模式”之间的调度问题。对稀疏激活或 MoE 模型，这类方法比对致密大模型更有现实意义，因为不需要每步都触达全部权重。对做 Agent 或本地推理工具的人，这说明性能瓶颈正在从算子本身转向 memory hierarchy。
Key Takeaways:
- 本地 LLM 推理优化正在从“更强量化”走向“更聪明的分层内存调度”
- 稀疏模型更容易从存储层调度中获益，系统设计开始决定本地可用模型上限
3. Show HN: Gemini can now natively embed video, so I built sub-second video search
Points: 252 | Comments: 70
这条项目展示了一个非常实用的变化：Gemini Embedding 2 可以直接把原始视频投影到向量空间，而不必先做转录、抽帧描述或文本中间层。作者把视频片段索引进向量库后，用自然语言直接搜索匹配片段，并自动裁剪结果，形成“描述场景即可回放”的检索体验。公开讨论给出的成本估算大约为每小时视频 2.5 美元量级。
工程价值不在于“视频也能搜索”，而在于多模态检索管线被显著压缩了。过去常见方案是 ASR + OCR + caption + embedding 多段串联，现在可以先尝试直接向量化视频内容。对做监控、内容审核、媒体处理、交互式检索的人，这意味着很多原先依赖文本代理的流程可以重写，但本地化、隐私与成本仍是主要约束。
Key Takeaways:
- 原生视频向量化正在削弱“先转文本再检索”的传统多模态管线
- 真正落地时仍要同时评估成本、隐私和本地替代方案是否存在
4. In Edison’s Revenge, Data Centers Are Transitioning From AC to DC
Points: 37 | Comments: 18
AI 机架功耗快速逼近兆瓦级后，传统数据中心里多次 AC/DC 转换所带来的损耗、铜排体积和散热成本开始变得难以接受。文章讨论了把 13.8kV AC 在园区边界直接转换成 800V DC，再把中间转换层数尽量削掉的路线。这样做的收益不是单点效率数字，而是整条供电链路的复杂度、风扇数量、供电器件和铜材规模都会下降。
这说明基础设施优化的重心正在外移。过去做平台工程时，大家关注集群调度、容器密度、网络拓扑；现在如果目标是 AI 级高功率部署，电力架构本身已经成为系统设计的一部分。对于后端与平台工程师，这类变化虽然离业务代码很远，但会反向决定未来算力形态和成本边界。
Key Takeaways:
- AI 基础设施扩容正逐渐从软件调度问题外溢为供电架构问题
- 高压直流方案的价值在于减少转换层级与物理成本，而不只是追求单点效率
5. A Compiler Writing Journey
Points: 26 | Comments: 0
这个项目持续记录了一个“从词法分析一路写到自举编译器”的实践过程，覆盖解析、语义、代码生成、后端扩展等多个阶段。它的价值不在于某个特定实现技巧，而在于把复杂系统拆成大量可运行、可验证、可递进的小步骤，每一步都对应明确的能力边界。
对资深工程师而言，这类材料的重要性在于方法论。很多复杂重构或架构替换之所以高风险，往往不是技术点太难，而是缺乏“每一步都可落地且可回退”的演进方式。编译器项目恰好提供了一个非常纯粹的范本：从最小可工作子集出发，逐层扩大能力面，而不是一次性吞下全部复杂度。
Key Takeaways:
- 复杂系统最有效的推进方式仍然是小步可运行演进，而不是一次性全量设计
- 编译器实践对后端架构设计的借鉴价值，首先体现在演进方法，而不是语言理论本身
Learning Resources
多租户隔离与 PostgreSQL RLS
- Shipping Multi-Tenant SaaS Using Postgres Row-Level Security
- Realtime Postgres Row Level Security
- SaaS Tenant Isolation Strategies