Work Summary
本周期主要围绕三条主线展开：fenshululu 成绩录入系统的认证模块从零到上线、Cloudflare 内网穿透的稳定性攻坚、以及多个工具项目（any2text、rsspulse、static-project）的并行推进。
fenshululu-auth 项目经历了完整的从架构设计到生产部署的周期。核心挑战是 EdgeOne Edge Function 的调试困境——边缘函数日志不可见，导致排查 CORS 和 418 状态码问题时严重依赖猜测。最终决策是将有问题的接口全量迁移到 Node Functions，获得了可观测性，同时性能也有显著提升（异步化 metrics 写入后延迟明显下降）。
Cloudflare 隧道稳定性问题贯穿整个周期，多次出现 edge 节点掉线、DNS 解析异常、代理链路中断。最终方向是 VPS + Tailscale + CF Tunnel 的混合架构，但尚未完全收敛。磁盘告警（85%+）也在此期间触发，根因是 Docker 容器日志无限增长，通过配置日志轮转解决。
Improvement Areas
1. 可观测性前置，而非事后补救
现象：EdgeOne Edge Function 出问题后无法看日志，花了大量时间在 CORS、418、JSON parse error 等问题上反复猜测，最终不得不整体迁移到 Node Functions。
根因：部署前没有验证日志可达性，把"能部署"等同于"能调试"。
行动项：
- 任何新部署环境，第一步先验证日志链路（
console.log→ 可见），不通则不上线 - Edge Function 只放无状态、无外部依赖的纯计算逻辑；有 I/O 的一律用 Node/Cloud Functions
2. 基础设施变更要有回滚路径
现象：Cloudflare 隧道多次出现连接故障，每次都是紧急排查，没有预案。Docker 日志磁盘打满也是被告警触发后才处理。
根因：基础设施配置缺乏"防御性设置"——日志没有 max-size、隧道没有健康检查和自动重启策略。
行动项：
- Docker Compose 模板加入
logging.options.max-size和max-file作为默认配置 - Cloudflare 隧道部署时配置多实例 +
--reconnect-timeout，Prometheus 加入 tunnel 连接数告警
3. 多任务并行时上下文切换成本过高
现象：同一时间段内在 fenshululu-auth、rsspulse、any2text、static-project 之间频繁切换，导致每个项目都有"继续"、"现在完成了吗"、"你提交了吗"这类碎片化跟进。
根因：没有明确的任务边界，每个会话都在多个项目间跳跃，AI 上下文丢失后需要重新同步。
行动项：
- 每次会话聚焦单一项目，完成到一个可验证的里程碑再切换
- 用 dida365 记录每个项目的当前状态和下一步，避免靠记忆跟踪
4. 数据隔离要在设计阶段确定，不能靠事后修补
现象：fenshululu 新注册用户能看到其他用户的班级和学生数据，发现时已经有多个 API 写入了数据，需要大范围重构。
根因：初期设计时没有明确 tenant 隔离边界，user_id 过滤条件在部分查询中缺失。
行动项：
- 多租户系统在第一个 API 写完后立即做隔离审计，不等到功能完整再查
- 数据库查询层加 Row Level Security（Supabase RLS）作为兜底，而不只靠应用层过滤
Strengths
- 快速定位根因：面对 418、CORS、JSON parse error 等多层叠加问题，能系统性地逐层排除，最终找到真正的根因
- 果断架构决策：Edge Function 调试困境出现后，没有继续在原路上死磕，果断迁移到 Node Functions
- 持续集成意识：fenshululu-auth 项目坚持 BDD 测试、回归验证后再提交
Action Items
- P0 - Docker Compose 模板加入日志轮转默认配置 → 防止下次磁盘告警
- P0 - Cloudflare 隧道加入 Prometheus 连接数监控 → 故障前预警
- P1 - fenshululu 全量 API 做 RLS 审计 → 确认数据隔离无遗漏
- P1 - 建立"新部署环境检查清单"（日志可见、健康检查、回滚方案）
Tech Trends
今日 HackerNews 热门技术话题精选。
1. What are skiplists good for?
Points: 262 | Comments: 64
跳表（skiplist）是一种随机化数据结构，通过多层链表实现 O(log n) 的查找效率，可替代二叉搜索树。Antithesis 将跳表推广到树结构，发明了"skiptree"——每层维护一张 SQL 表，从而将递归的祖先遍历转化为固定数量的 JOIN 操作（约40个），在 BigQuery 等分析型数据库中大幅降低树形数据查询成本。
Key Takeaways:
- 当标准数据库操作模式与实际查询模式不匹配时，换一种数据结构的视角往往能打开新思路
- 跳表的价值不在于性能极致，而在于结构简单、易于在受限环境（如纯 SQL）中实现
2. Show HN: A working reference implementation of context engineering
Points: 22 | Comments: 9
Context Engineering 将上下文视为"first-class engineering artifact"——可版本控制、可检索、可执行。它由五个组件构成：语料库、检索、注入、输出、执行。基于 Amazon Bedrock 实现全流程，检索层使用 FAISS，执行层采用 LLM-as-judge 模式，以 ADR 和代码标准作为检索语料。
Key Takeaways:
- CE 的核心差异在于执行层：验证输出确实引用了注入的上下文，而非只是生成了"看起来合理"的代码
- 对于维护大型代码库的团队，将 ADR 纳入 AI 上下文检索是提升代码一致性的实用路径
3. Prove you are a robot: CAPTCHAs for agents
Points: 43 | Comments: 28
Browser Use 推出"反向验证码"机制——不需要邮箱或 OAuth，只需让 Agent 解决一道经过混淆处理的数学题（随机符号插入、多语言数字拼写）即可获得 API Key。人类看到乱码会放弃，而 Agent 能在单次推理中完成解析。
Key Takeaways:
- Agent-first 产品设计：为 AI Agent 设计专属的身份验证入口，而非把人类流程强加给 Agent
- 对于构建 AI Agent 工具链的开发者，"机器友好"的 API 设计模式值得借鉴