Work Summary
本期主要工作集中在 fenshululu-auth 项目的深度迭代。核心问题是多租户数据隔离缺失——新注册用户能看到其他用户的班级和学生数据，这是一个严重的数据安全漏洞。通过全面代码探索后制定修复计划，使用 TeamCreate 并行执行多文件改造，最终实现每个用户数据完全独立。
调试过程中遭遇了典型的 CORS 问题链：418 状态码 → CORS preflight 失败 → allowedOrigins 配置不当。问题根因是 Edge Function 和 Node 层存在同名函数导致路由混乱，修复后扫码登录流程恢复正常。BDD 测试稳定性问题也在本期得到修复，并将经验总结更新到 CLAUDE.md。
运维侧处理了服务器磁盘持续增长问题，通过 Grafana 定位到 Docker 镜像堆积和日志无轮转，清理后配置了日志轮转策略。
Improvement Areas
1. CORS 调试方法论不系统
现象：CORS 问题反复出现，每次都是逐步排查，从 418 → preflight → allowedOrigins 走了多轮来回，且中途出现"已经没有418了，不要再推到418的问题上了"这类信息丢失。
根因：缺乏 CORS 问题的系统化 checklist，每次从症状出发而非从协议层出发。CORS 错误链是确定性的：preflight → response headers → credentials → origin whitelist，顺序固定。
行动项：
- 建立 CORS 调试 SOP：先抓 preflight OPTIONS 请求的响应头，再看 actual request，不要从错误信息反推
- 在项目 CLAUDE.md 中记录 allowedOrigins 不支持
*的约束（已有 memory 记录，但需固化到项目级）
2. 多租户架构设计前置不足
现象：项目上线前才发现数据隔离缺失，需要大规模重构。"每个用户自己的班级和学生完全独立"这个需求本应在设计阶段确定。
根因：缺少数据模型设计阶段的租户隔离 checklist。Row-level security、tenant_id 外键约束、API 层的 ownership 校验这三层防护需要同时设计。
行动项：
- 新项目启动时，数据模型设计必须包含租户隔离方案（RLS / tenant_id / middleware ownership check 三选一或组合）
- 参考 PostgreSQL RLS 方案，在 DB 层强制隔离而非依赖应用层
3. Docker 运维缺乏主动监控
现象：磁盘增长是被动发现（Grafana 告警后才排查），而非主动预防。Docker 镜像堆积和日志无轮转是常见问题，应该在部署时就配置好。
根因：部署 checklist 缺少日志轮转和镜像清理策略。
行动项：
- 所有 docker-compose 部署默认加
logging.driver: json-file+max-size: 100m+max-file: 3 - 配置 cron 定期执行
docker image prune -f
4. BDD 测试稳定性意识薄弱
现象：BDD 测试出现不稳定（flaky）情况，需要多次修复才通过。"为什么不稳定呢" 说明对 flaky test 的根因分析不够主动。
根因：BDD 测试依赖外部状态（数据库、网络），没有做好测试隔离和幂等性保证。
行动项：
- 每个 BDD scenario 必须有独立的 setup/teardown，不依赖执行顺序
- 网络相关测试加 retry + timeout，而非依赖环境稳定性
Strengths
- 问题驱动的架构决策：发现数据隔离问题后，主动要求全面代码探索再制定计划，而非直接打补丁，体现了正确的工程直觉
- 工具链熟练度高：TeamCreate 并行执行、Grafana 监控定位、BDD 测试驱动开发，工具使用流畅
- 经验沉淀意识：主动要求将本次经验更新到 CLAUDE.md，形成知识积累闭环
- 安全敏感度：快速识别 CVE-2026-31431 并主动验证自身环境是否受影响
Action Items
- P0 - 在 fenshululu-auth 的 docker-compose 中补充日志轮转配置 → 防止磁盘再次爆满
- P1 - 整理 CORS 调试 SOP 到 CLAUDE.md → 下次遇到直接按流程走
- P1 - 为新项目建立多租户设计 checklist → 避免上线前大规模重构
- P2 - 审查所有 BDD 测试的 setup/teardown 完整性 → 消除 flaky test
Tech Trends
今日 HackerNews 热门技术话题精选。
1. Dirtyfrag: Universal Linux LPE
Points: 406 | Comments: ~80
Linux 内核新提权漏洞，影响范围广泛（"Universal"意味着跨发行版）。漏洞利用路径涉及内存碎片化（dirty fragmentation），攻击者可从普通用户权限提升到 root。
这类漏洞对运行 Docker 容器的服务器影响尤为严重——容器逃逸 + LPE 组合可完全控制宿主机。建议立即检查内核版本并关注发行版安全公告。
Key Takeaways:
- 检查服务器内核版本，关注 Ubuntu/Debian/RHEL 的安全更新
- 容器环境下 LPE 漏洞的威胁面比裸机更大，需优先修补
2. Agents need control flow, not more prompts
Points: 326 | Comments: ~120
作者论证 AI Agent 失败的根本原因不是 prompt 质量，而是缺乏显式的控制流设计。当 Agent 遇到分支决策时，依赖 LLM 自主判断会导致不可预测的行为；而将控制流显式编码（if/else、状态机、检查点）才能让 Agent 行为可靠可测。
这与后端系统设计的核心原则一致：显式优于隐式，状态机优于自由流。对于使用 Claude Code 构建自动化工作流的场景，这个视角很有价值。
Key Takeaways:
- Agent 编排应该像设计状态机，而不是写一个大 prompt
- 关键决策点用代码控制，LLM 只负责"叶子节点"的执行
3. Building for the Future (Cloudflare)
Points: 253 | Comments: ~60
Cloudflare 分享其基础设施演进路径，重点讲述如何在保持高可用的同时进行大规模架构迁移。涉及 Workers 平台的扩展、边缘计算的状态管理（Durable Objects）以及全球流量调度策略。
对于构建高性能网关（35万QPS级）的工程师，Cloudflare 的架构决策有直接参考价值，尤其是边缘节点的状态一致性处理方式。
Key Takeaways:
- 边缘计算的状态管理是核心难题，Durable Objects 是一种解法
- 大规模迁移的关键是渐进式切流，而非大爆炸式替换
4. Natural Language Autoencoders: Turning Claude's Thoughts into Text
Points: 195 | Comments: ~90
Anthropic 研究将 Claude 的内部激活状态（activation）转换为自然语言描述，实现对模型"思维过程"的可解释性。这是可解释 AI（XAI）领域的重要进展，意味着未来可以审计 LLM 的推理链路。
对于在安全领域使用 LLM 做恶意流量检测的场景，模型可解释性直接影响误报率的可信度和合规审计能力。
Key Takeaways:
- LLM 可解释性正在从学术走向工程实践
- 安全场景下的 AI 决策审计将成为合规要求
5. AI slop is killing online communities
Points: 448 | Comments: ~200
作者记录 AI 生成内容（"slop"）如何污染技术社区：Stack Overflow、GitHub Issues、论坛中充斥着 AI 生成的低质量回答，导致信噪比急剧下降，真实工程师逐渐退出。
这对依赖社区知识的工程师有直接影响——搜索引擎结果质量下降，需要更多时间甄别信息。同时也是对 AI 辅助开发工具（包括 Claude Code）的反思：工具的价值在于提升工程师能力，而非替代思考。
Key Takeaways:
- 技术信息检索需要更多依赖一手文档和源码，而非搜索引擎
- AI 工具的正确使用姿势是增强判断力，而非外包判断力