Work Summary
本周期（2月18日）集中在「分数录录」（fenshululu）项目的语音录分功能调试上。这是一个教育类 Web 应用，核心功能是通过语音识别技术快速录入学生考试成绩。
主要工作围绕三个方面展开：一是语音识别结果无法正确映射到学生成绩单的问题排查，发现根因是测试班级缺少学生种子数据导致匹配失败；二是多租户数据隔离问题，明确要求用户之间数据严格隔离，即使同校教师也不能互相访问；三是为语音录分流程补充 BDD 测试覆盖。
整体来看，这是一个典型的功能联调阶段，涉及前后端数据流打通、边界条件处理和测试补全。
Improvement Areas
1. 种子数据管理策略
现象：语音识别成功但成绩单无数据，排查后发现是测试班级没有关联学生数据。多次在界面上确认"学生数量都是0"。
根因：缺乏系统化的种子数据管理。测试数据与功能开发脱节，导致联调时频繁遇到数据缺失问题。
行动项：
- 建立标准化的 seed data 脚本，确保每次
make dev或make test自动填充完整测试数据 - 种子数据应覆盖所有核心实体关系（教师→班级→学生→考试）
- 在 CI 中加入种子数据完整性检查
2. 多租户隔离的系统性保障
现象：发现种子数据创建时未正确关联到当前用户，导致跨租户数据泄露风险。需要手动指出"用户之间是隔离的，禁止出现这种"。
根因：多租户隔离逻辑可能散落在业务代码中，缺乏统一的隔离层。
行动项：
- 在数据访问层（Repository/DAO）统一注入租户过滤条件，避免业务代码遗漏
- 添加集成测试：用不同用户身份访问同一资源，断言返回 403 或空结果
- 考虑使用 PostgreSQL RLS（Row Level Security）作为兜底防线
3. 语音识别结果解析的鲁棒性
现象：语音识别返回"张3123"、"张326547"等非标准格式，系统未能正确解析为"张三 123分"。
根因：语音识别 ASR 输出不稳定，当前解析逻辑对噪声输入容错不足。
行动项：
- 增加模糊匹配能力：支持同音字、数字混合（"张3" → "张三"）
- 对无法解析的输入给出明确错误提示，而非静默忽略
- 补充边界 case 的单元测试（纯数字、无姓名、多学生混合输入等）
Strengths
- 产品思维敏锐：能从用户视角发现"未匹配学生是否需要合理化添加"这类产品级问题，而非仅关注技术实现
- 安全意识强：第一时间发现并强调多租户隔离问题，零容忍态度正确
- 测试驱动意识：主动要求 BDD 测试覆盖核心流程，而非手动验证后就放过
Action Items
- P0 - 建立 fenshululu 项目的标准种子数据脚本 → 消除联调阶段的数据缺失问题
- P0 - 添加多租户隔离的集成测试套件 → 防止跨用户数据泄露
- P1 - 优化语音识别结果解析器，增加模糊匹配和错误提示 → 提升录分成功率
- P1 - 完成语音录分流程的 BDD 测试覆盖 → 建立回归防护网
Tech Trends
今日 HackerNews 热门技术话题精选。
1. Don't Trust the Salt: AI Summarization, Multilingual Safety, and LLM Guardrails
Points: 178 | Comments: 76
研究发现，LLM 安全护栏在多语言场景下存在严重漏洞。切换系统提示的语言可导致 36-53% 的行为差异，非英语输入往往能绕过安全机制。这揭示了一个关键问题：安全策略并非语言无关的，训练数据的语言分布直接影响模型行为。
作者提出从静态策略过滤转向可组合的决策层架构，并强调跨语言可观测性的重要性。对于构建多语言 AI 应用的开发者，这意味着必须在每种目标语言上独立测试安全机制。
Key Takeaways:
- LLM 护栏在非英语语言上的有效性显著下降，需要语言感知的安全设计
- "一刀切"的安全策略在生产环境中会产生可利用的漏洞
2. AI Makes You Boring
Points: 534 | Comments: 299
HN 热门讨论：将思考外包给 AI 是否会产生浅层、缺乏深度的工作成果。核心论点是原创想法来自长时间的问题沉浸，而 AI 代劳认知工作会跳过这个过程。反方认为 AI 更像橡皮鸭调试的升级版，懒惰的创作者在 LLM 之前就存在。
开发者社区的共识偏向务实：AI 擅长处理样板代码和基础设施任务，释放时间用于高层设计决策。但领域专业知识仍然关键——Vibe-coded 方案经常重新发明已有工具或忽略维护阶段的架构考量。
Key Takeaways:
- 用 AI 加速重复劳动，但在新颖问题和架构决策上投入自己的思考
- 领域专业知识是 AI 无法替代的核心竞争力
3. AI Is Not a Coworker, It's an Exoskeleton
Points: 145 | Comments: 166
将 AI 定位为"外骨骼"而非"同事"的框架引发广泛讨论。核心观点：AI 处理规模化和模式匹配，人类提供判断力和方向感。有趣的转变是，个人开发者配合 AI 现在可以完成以前需要团队才能做的事。
技术层面的关键洞察：AI 在干净的代码库、完善的测试覆盖和清晰的反馈循环下效果最好——本质上，良好的工程实践成为有效使用 AI 的前提条件。
Key Takeaways:
- AI 放大能力而非替代能力，前提是你本身有能力可被放大
- 干净代码库 + 完善测试 = AI 辅助效果最大化
4. Zero Downtime Migrations at Petabyte Scale
Points: 84 | Comments: 17
PlanetScale 分享了 PB 级数据库零停机迁移的实践。技术基础是 Vitess 的 VReplication 框架，采用多阶段流程：一致性快照 + 持续复制 + VDiff 数据校验 + 查询缓冲切换（停顿不到 1 秒）+ 反向复制作为安全阀。
核心架构思想：将迁移过程解耦为独立阶段，每个阶段不阻塞生产流量。使用只读副本作为迁移源避免影响线上系统，反向切换能力消除了不可逆决策的压力。
Key Takeaways:
- 迁移策略应优先考虑可观测性检查点、渐进式流量切换和回滚能力
- 避免单体式切换，将迁移分解为可独立验证的阶段
5. Measuring AI Agent Autonomy in Practice
Points: 80 | Comments: 36
Anthropic 发布关于 AI Agent 自主性度量的研究。社区讨论聚焦于：任务持续时间是否是衡量自主性的有效指标、数据隐私影响、以及授权范围与原始能力的区别。
评论者指出关注 99.9 百分位持续时间的方法论问题，以及在实际部署中如何平衡 Agent 的自主性与安全边界。对于正在构建 AI Agent 的开发者，这提供了一个思考框架：自主性不仅是能力问题，更是信任和授权的设计问题。
Key Takeaways:
- AI Agent 自主性需要明确的授权边界，而非无限制的能力释放
- 度量框架应关注任务完成质量而非仅仅是持续时间
Learning Resources
多租户数据隔离
- Multi-tenant data isolation with PostgreSQL Row Level Security
- Launch HN: Fortress (YC S24) - Database platform for multi-tenant SaaS
- Show HN: Go and Next B2B SaaS Starter with multi-tenancy