Work Summary
本周期工作集中在基础设施优化和问题排查。主要处理了 Cloudflare Tunnel 稳定性问题，探索 Tailscale + VPS 的内网穿透替代方案；优化 Prometheus 监控配置，将 5 个 Cloudflare Edge 实例接入监控并测试 HTTP/2 协议性能；排查成长报告定时任务失败问题，发现 Telegram 通知未发送的根因；参与算法题讨论，涉及剪枝优化的正确性验证。
工作特点是问题驱动，从实际痛点出发（CF 不稳定、告警缺失）快速定位方案，但缺少系统性规划和验证闭环。
Improvement Areas
1. 基础设施决策缺少量化验证
现象：Cloudflare Tunnel 不稳定时，直接询问"还有什么其他更好的方法"，未先量化问题（丢包率、延迟、故障频率）。
根因：习惯性跳到解决方案，忽略问题定义阶段。没有建立"测量 → 分析 → 决策"的闭环。
行动项：
- 遇到性能/稳定性问题时，先用 Prometheus/Grafana 导出 7 天数据，生成故障时间线
- 建立决策模板：当前指标 → 目标阈值 → 方案对比（成本/复杂度/风险）
- 对于网络类问题，至少跑 24 小时 A/B 测试再下结论
2. 监控告警配置滞后于系统变更
现象：部署了 4 个 Cloudflare Edge 容器，但未同步更新 Prometheus 抓取配置和 Grafana 面板，导致监控盲区。
根因：监控配置不在 IaC 流程中，依赖人工记忆。缺少"部署 checklist"。
行动项：
- 在
docker-compose.yml同目录创建monitoring.md，记录需同步更新的监控项 - 容器启动后自动执行健康检查脚本，验证 Prometheus targets 是否全部 UP
- Grafana 面板用 Terraform/Jsonnet 管理，避免手动点击配置
3. 定时任务失败缺少主动告警
现象：成长报告定时任务多次失败未发送 Telegram 通知，直到手动检查才发现。
根因：Cron 任务只记录日志，没有失败告警机制。依赖人工巡检。
行动项：
- 所有 Cron 任务包装为脚本，exit code 非 0 时发送告警到 Telegram
- 关键任务（如成长报告）增加"心跳检测"：超过预期时间未执行则告警
- 用 Healthchecks.io 或自建 Dead Man's Switch 监控定时任务
Strengths
- 快速定位问题根因：Cloudflare Edge 协议问题、Telegram 通知失败，都能快速缩小排查范围
- 工具链熟练度高：Docker、Prometheus、Grafana、Tailscale 等工具使用流畅，能快速搭建验证环境
- 安全意识强：讨论内网穿透方案时，主动考虑 Tailscale ACL、VPS 防火墙等安全边界
Action Items
- P0 - 为所有 Cron 任务增加失败告警 → 24 小时内完成，避免再次漏检
- P1 - 建立监控配置 checklist → 下次部署新服务时验证
- P1 - Cloudflare Edge 跑 48 小时 HTTP/2 vs QUIC 对比测试 → 量化协议选择依据
Tech Trends
今日 HackerNews 热门技术话题精选。
1. //go:fix inline and the source-level inliner
Points: 147 | Comments: 65
Go 1.26 引入 //go:fix inline 指令和源码级内联器，用于自动化 API 迁移。核心机制是将函数调用替换为函数体，直接修改源码。主要用于废弃 API 迁移（如 ioutil.ReadFile → os.ReadFile）、修复 API 设计缺陷（参数顺序错误）、类型和常量转发。
内联器处理参数消除、副作用、变量遮蔽等正确性问题，保证行为不变。开发者可通过 go fix 自动更新代码，减少手动重构工作。gopls 也集成了该算法，支持交互式"Inline call"重构。
Key Takeaways:
- 包作者可声明式定义 API 迁移路径，用户自助升级
- 自动化处理大规模代码库的 API 演进，降低维护成本
- 可能产生过于保守的结果，需人工优化代码风格
2. Chrome DevTools MCP
Points: 465 | Comments: 196
Chrome DevTools 支持 Model Context Protocol (MCP)，允许 AI Agent 直接连接活跃的浏览器会话。通过启用远程调试并配置 MCP Server 的 --autoConnect 选项，Agent 可复用现有浏览器会话，访问 DevTools 调试上下文。
这使得手动调试和 AI 辅助调试无缝切换，Agent 可在用户当前会话中直接修复问题。对于浏览器自动化、CDP 调试场景特别有用，降低了 Agent 接入门槛。
Key Takeaways:
- MCP 标准化 AI Agent 与浏览器的交互协议
- 适合 CDP 自动化、E2E 测试调试等场景
- 需要远程调试端口暴露，注意安全边界
3. Glassworm: Invisible Unicode Attacks on GitHub/npm/VSCode
Points: 259 | Comments: 161
Glassworm 利用不可见 Unicode 字符在代码中嵌入恶意载荷，通过 eval() 执行。攻击目标是 GitHub 开源仓库、npm 包、VSCode 扩展。2026 年 3 月新一轮攻击已感染超 150 个仓库（包括 Wasmer、Reworm 等知名项目）。
攻击者伪装成常规提交（文档更新、bug 修复），使用 AI 生成可信的 commit message。标准代码审查和 linting 无法检测，因为恶意字符在编辑器中不可见。
防御建议：集成主动恶意代码扫描到 CI/CD 流程，使用 Aikido Safe Chain 等工具实时检测供应链恶意软件，避免依赖视觉审查。
Key Takeaways:
- Unicode 隐写攻击已成供应链安全新威胁
- 代码审查需工具化，不能只靠人眼
- 开源依赖需在安装前扫描，而非安装后
4. How I Write Software with LLMs
Points: 171 | Comments: 110
作者使用多 Agent LLM 工作流：架构师（Opus）、开发者（Sonnet）、审查员（Codex、Gemini、Opus）。核心思路是优先系统架构和高层设计，而非底层代码编写。
关键洞察：多模型交叉审查提升质量，Agent 间通信需要 harness 支持。文章展示了为 Stavrobot 添加邮件支持的完整会话，演示人类与 LLM 的迭代细化过程。目标是通过 LLM 处理任务，人类保留架构决策权，实现可靠的高质量软件开发。
Key Takeaways:
- 多 Agent 分工比单一 Agent 更可靠
- 架构设计仍需人类主导，LLM 负责实现细节
- Agent 间通信协议是工作流的关键基础设施
5. LLM Architecture Gallery
Points: 388 | Comments: 30
LLM 架构演进画廊，展示密集和稀疏 MoE（Mixture-of-Experts）模型。关键趋势包括注意力机制变体（GQA、MLA、SWA）、归一化技术（QK-Norm、pre-norm/post-norm）、Transformer 与状态空间模型的混合架构。
ML 工程师可从中了解模型规模扩展和效率优化的最新实践。对于理解 Claude、GPT-4、Gemini 等模型的架构选择有参考价值。
Key Takeaways:
- MoE 是大模型扩展的主流方向
- 注意力机制优化（如 GQA）平衡性能和成本
- 混合架构（Transformer + SSM）探索新的效率边界
Learning Resources
内网穿透与自托管
- Pangolin – Open source alternative to Cloudflare Tunnels
- Gonc – Serverless P2P dual reverse proxy with NAT traversal