Work Summary
本周期（2026-05-01 至 2026-05-04）活跃度较低，仅有零星操作记录。结合近期完整历史来看，主要工作集中在 fenshululu 教育平台的认证模块开发（fenshululu-auth），涉及微信扫码登录、CORS 跨域调试、BDD 测试修复，以及 Docker 容器磁盘占用排查与日志轮转配置。
从整体历史模式看，你在多个项目间高频切换（fenshululu、tools、info2feishu、any2text），且大量时间花在调试和修复上，而非新功能推进。CORS 问题、Docker 部署不同步、多租户数据隔离 bug 是反复出现的主题，说明这些领域存在系统性知识盲区。
Improvement Areas
1. 多租户数据隔离设计缺失
现象：新注册用户能看到其他用户的班级和学生数据，发现时已进入开发中期。
根因：在设计阶段没有明确建立租户隔离模型（tenant_id 强制过滤），导致数据层查询默认全表扫描，隔离逻辑靠业务代码补丁而非数据库约束保障。
行动项：
- 所有涉及用户数据的表，在 schema 层加
tenant_id NOT NULL+ 外键约束 - 数据库查询层封装
WithTenant(ctx, tenantID)中间件，禁止裸查询 - 写一个集成测试：用户 A 的 token 无法读取用户 B 的任何资源
2. CORS 调试方法论缺失
现象：CORS 问题反复出现（至少 6 次相关提问），每次都是症状驱动的逐条排查，没有系统性解决。
根因：对 CORS preflight 流程、Access-Control-Allow-Origin 与 credentials 的交互规则理解不深，导致每次遇到都重新摸索。
行动项：
- 整理一份 CORS 排查 checklist 存入 CLAUDE.md：preflight 返回码、credentials 模式、wildcard 限制
- 在网关层统一处理 CORS，业务服务不再各自配置
3. Docker 部署状态感知不足
现象：多次出现"我更新了代码，但容器还是旧的"问题，需要反复确认容器是否已更新。
根因：缺少部署状态验证步骤，没有将"构建 → 推送 → 重启 → 验证"固化为可重复的流程。
行动项：
- Makefile 中加
deploytarget，包含docker build + push + compose up --force-recreate + health check - 部署后自动打印容器启动时间和镜像 digest，消除"是否已更新"的歧义
4. AI 辅助编码的依赖风险
现象：大量操作是直接指令 Claude 执行（"你更新呀"、"帮我查"），缺少自己先分析再验证的过程。
根因：AI 工具降低了主动思考的摩擦，容易形成"外包思维"，导致对自己系统的心智模型逐渐模糊。
行动项：
- 对不熟悉的模块，先自己读代码写出假设，再让 AI 验证
- 复杂 bug 修复后，自己写一句根因总结存入 CLAUDE.md，而不是直接接受 AI 的结论
Strengths
- BDD 测试意识：在 fenshululu-auth 中坚持用 BDD 驱动开发，遇到不稳定 case 选择修复而非跳过，测试哲学执行到位。
- 运维自动化：主动排查磁盘增长根因、配置日志轮转、清理 Docker 镜像，而不是等问题爆发。
- 安全意识：主动检查 CVE-2026-31431 漏洞，说明对安全动态保持关注。
Action Items
- P0 - 为 fenshululu 所有数据表添加 tenant_id 约束 + 查询层隔离中间件 → 消除跨租户数据泄露风险
- P0 - Makefile 加
deploytarget 含健康检查 → 消除部署状态歧义 - P1 - 整理 CORS 排查 checklist 存入 CLAUDE.md → 下次 30 秒定位问题
- P1 - 每次 AI 修复复杂 bug 后，自己写根因总结 → 防止心智模型空洞化
Tech Trends
今日 HackerNews 热门技术话题精选。
1. Agentic Coding Is a Trap
Points: 132 | Comments: 95
核心论点：把编码完全委托给 AI Agent 会形成危险的正反馈循环——监督 AI 生成代码需要编码能力，但过度依赖 AI 会侵蚀这种能力。Anthropic 自己的研究将此称为"监督悖论"，已有研究记录到重度 AI 用户的调试能力下降 47%。
作者指出这次"抽象层跃迁"与历史上汇编→编译器、C++→Python 的跃迁本质不同：后者是在积累了数十年专业知识后发生的，而 AI 导致的技能退化在数月内就可测量到。初级开发者失去了写代码的"生产性摩擦"，高级开发者则逐渐失去对自己系统的心智模型。
建议的替代方案：对不熟悉的内容亲自写代码，每次只生成能在一次 review 中看完的量，用 LLM 做规划和研究而非批量实现。
Key Takeaways:
- 监督 AI 代码需要的能力，正是 AI 使用在侵蚀的能力
- 对自己系统保持心智模型，是资深工程师不可外包的核心资产
2. Security Through Obscurity Is Not Bad
Points: 119 | Comments: 139
作者纠正了一个常见误解："安全靠混淆是坏的"这句话本身是错的，准确表述是"单独依赖混淆是坏的"（Kerckhoffs 原则）。当混淆叠加在正确的安全措施之上时，它增加了攻击者的时间和金钱成本，使其更可能放弃。
实际案例：WordPress 表前缀修改挡住了自动化 SQL 注入攻击；Valve 剥离 CS:GO 调试符号减缓了外挂开发；Google/Netflix 用 JS 混淆保护浏览器端敏感逻辑。每个案例中混淆都不是主防线，而是攻击成本的乘数。
对"AI 让混淆失效"的反驳：用 LLM 解一道 CTF 题花了 4.5 小时和约 300 美元 token 费用。混淆的价值在于提高攻击成本，而非不可攻破。
Key Takeaways:
- 混淆 = 攻击成本乘数，不是主防线，两者不矛盾
- 安全领域的绝对化表述往往是错的，需要结合上下文判断
3. DeepClaude – Claude Code Agent Loop with DeepSeek V4 Pro, 17x Cheaper
Points: 162 | Comments: 71
将 Claude Code 的 Agent 循环与 DeepSeek V4 Pro 结合，声称成本降低 17 倍。核心思路是用 DeepSeek 处理大量中间推理步骤，只在关键决策点调用 Claude，从而大幅降低 token 消耗。
对于高频使用 Claude Code 的场景（如定时任务、批量分析），这类混合架构值得关注。但需注意：DeepSeek 的代码能力和工具调用稳定性与 Claude 仍有差距，适合用于低风险的辅助任务。
Key Takeaways:
- 混合 LLM 架构可以在成本和能力间取得平衡
- 关键路径用强模型，辅助路径用廉价模型，是合理的工程权衡
Learning Resources
多租户隔离
- Launch HN: Fortress – Database platform for multi-tenant SaaS
- Go and Next B2B SaaS Starter with multi-tenant support