Work Summary
本周期（2026-01-20 至 2026-01-21）主要工作集中在工具链整合与重构。核心任务是将 info2feishu 和 report-forge 两个项目合并，最终选择使用 Python 全栈重写方案，数据存储直接使用飞书多维表格，采用 Docker 部署。
在 Grafana Dashboard Generator 项目上投入了大量时间，主要解决了 SSE（Server-Sent Events）实时进度推送的技术选型和实现，以及将项目迁移到 EdgeOne Pages 进行静态部署。
另一个重要工作是飞书 API 权限配置，遇到了应用无法操作 Bitable 的权限问题，通过研究飞书开放平台文档，最终通过添加应用为协作者解决了权限问题。
Improvement Areas
1. 飞书 API 权限模型理解不足
现象：在配置飞书多维表格时，反复遇到"应用没有权限操作这个 Bitable"的错误，尝试了多种方式（创建新表格、切换文件夹、查询 user_access_token）才最终解决。
根因：对飞书开放平台的权限模型（应用权限 vs 用户权限 vs 资源权限）理解不够系统，导致排查路径不清晰。
行动项：
- 系统阅读飞书开放平台权限文档，整理权限模型笔记
- 创建飞书 API 集成的 checklist，包含权限配置步骤
2. 技术选型决策过程可优化
现象：在 info2feishu 重构时，先考虑 Go 实现，后又切换到 Python；在 Grafana Dashboard Generator 的进度推送方案上，需要通过 /cto-advisor 来辅助决策 SSE vs WebSocket vs 轮询。
根因：缺乏系统的技术选型框架，决策依赖临时分析而非预设的评估维度。
行动项：
- 建立技术选型决策模板（考虑维度：团队熟悉度、维护成本、部署复杂度、性能需求）
- 对于常见场景（实时推送、数据存储、部署方式）预设推荐方案
3. 项目部署流程碎片化
现象：在 Grafana Dashboard Generator 部署到 EdgeOne 时，执行了多次 make deploy 命令，且对项目结构（static-project 文件夹位置）不够清晰。
根因：多个项目的部署流程不统一，缺乏标准化的部署脚本和文档。
行动项：
- 统一所有静态项目的部署流程到 static-project 仓库
- 为每个可部署项目添加 make deploy 标准 target
Strengths
- 快速技术验证：能够快速在多个技术方案间切换并验证可行性
- 工具链整合意识：主动识别重复功能并推动合并，减少维护负担
- 善用 AI 辅助决策：合理使用 /software-architecture、/cto-advisor 等 skill 进行架构决策
Action Items
- P0 - 整理飞书 API 权限配置 checklist -> 减少后续集成时的排查时间
- P1 - 建立技术选型决策模板 -> 提升决策效率和一致性
- P1 - 统一 static-project 部署流程 -> 减少部署时的认知负担
- P2 - 完成 info2feishu + report-forge 合并重构 -> 简化工具链
Tech Trends
今日 HackerNews 热门技术话题精选。
1. Unconventional PostgreSQL Optimizations
Points: 264 | Comments: 44
这篇文章介绍了三种非常规的 PostgreSQL 优化技术：
- 基于 CHECK 约束消除全表扫描：通过设置
constraint_exclusion = 'on'，让 PostgreSQL 利用 CHECK 约束跳过不可能返回结果的查询。这在 BI/报表环境中特别有用，因为用户可能会写出查询不存在值的 ad-hoc 查询。
- 函数索引降低基数：当分析师只需要按天聚合数据时，不必索引完整的 timestamp，而是索引
date_trunc('day', sold_at)::date。这样索引从 214MB 降到 66MB，查询速度反而更快。文章还介绍了 PostgreSQL 17 的虚拟生成列特性，可以更优雅地实现这一点。
- 使用 Hash 索引强制唯一性：对于超长字符串（如 URL），B-Tree 唯一索引会非常大。可以使用 Hash 索引配合排除约束来实现唯一性检查，索引大小可以从 GB 级降到 MB 级。
Key Takeaways:
constraint_exclusion在报表环境中值得开启- 函数索引 + 虚拟生成列是优化时间序列查询的利器
- Hash 索引在特定场景下比 B-Tree 更高效
2. Running Claude Code dangerously (safely)
Points: 280 | Comments: 231
作者分享了如何安全地使用 Claude Code 的 --dangerously-skip-permissions 标志。核心方案是使用 Vagrant + VirtualBox 创建隔离的 VM 环境，而不是 Docker（因为需要 Docker-in-Docker 会破坏隔离性）。
关键配置：
- 使用
bento/ubuntu-24.04作为基础镜像 - 通过
synced_folder实现代码双向同步 - 在 VM 内给 Claude sudo 权限，让它可以自由安装包、运行 Docker、修改配置
作者指出这种方案的威胁模型是防止意外操作，而非防御恶意 AI。由于代码在 git 管理下，即使 Claude 搞乱了项目也可以恢复。
Key Takeaways:
- Vagrant 是 AI Agent 沙箱的好选择，比 Docker-in-Docker 更安全
- VirtualBox 7.2.4 有 CPU 空转 bug，需要降级或等待修复
- 让 Agent 有完整权限反而能提高效率，因为它可以自己验证结果
3. Electricity use of AI coding agents
Points: 61 | Comments: 44
作者深入分析了 Claude Code 等 AI 编程 Agent 的电力消耗。核心发现：一个典型的 Claude Code 会话消耗的电力是"中位数查询"的数百倍。
原因分析：
- Claude Code 的系统提示 + 工具描述就有近 20,000 tokens
- 每条用户消息会触发 5-10 次工具调用，每次调用都是一个完整的 API 请求
- 所有历史消息都会被包含在上下文中
作者通过 Anthropic 的定价比例（输出 token 是输入的 5 倍价格）来估算能耗比例，得出结论：重度 Claude Code 用户的 AI 相关电力消耗可能与日常家庭用电相当。
Key Takeaways:
- AI Agent 的能耗远超普通聊天，需要关注
- Token 缓存对降低能耗很重要
- 作为开发者，优化 prompt 长度和工具调用次数有实际意义
4. Mastra 1.0 - Open-source JavaScript agent framework
Points: 79 | Comments: 36
来自 Gatsby 团队的开源 AI Agent 框架，专为 TypeScript 生态设计。主要特性：
- 模型路由：统一接口连接 40+ 模型提供商（OpenAI、Anthropic、Gemini 等）
- Agent 系统：支持自主推理、工具调用、迭代执行
- 工作流引擎：图式工作流，支持
.then()、.branch()、.parallel()语法 - Human-in-the-loop：支持暂停等待人工审批，状态持久化
- MCP 服务器：可以将 Agent 暴露为 MCP 接口
与 LangChain 相比，Mastra 更专注于 TypeScript 生态，API 设计更现代。
Key Takeaways:
- TypeScript AI 开发有了更好的框架选择
- Human-in-the-loop 和状态持久化是生产级 Agent 的关键特性
- MCP 协议正在成为 Agent 互操作的标准
5. I'm addicted to being useful
Points: 490 | Comments: 246
一位 Staff Engineer 的自我剖析：他发现自己对"被需要"有近乎成瘾的依赖。看到问题不解决会感到身体上的不适，解决后则获得满足感。
作者将自己比作果戈理小说《外套》中的主角——一个热爱抄写工作的小职员。虽然工作客观上很糟糕，但因为与自己的"功能障碍"完美匹配，所以乐在其中。
作者的其他文章也围绕这个主题：如何保护自己不被"掠食者"榨干、如何确保对管理层有用而不是对工单队列有用、如何应对必须帮助不尊重的人的情况。
Key Takeaways:
- 认识自己的内在驱动力，比追求"应该"的动机更重要
- 对"被需要"的渴望需要被引导，否则容易被利用
- Staff Engineer 的价值在于解决问题，而非完成工单