GA4 Email和SMS渠道判定规则
Google Analytics 4 默认渠道分组根据 utm_source 和 utm_medium 值将流量归类为23个渠道。官方规则不可覆盖，常见错误导致邮件/SMS流量错误分配至Referral或Unassigned。
- Email渠道：utm_medium=email（或 e-mail, e_mail, e mail）匹配即可；使用 newsletter、mail 等会导致分类失败
- SMS渠道：必须精确匹配“sms”，大小写敏感；LINE、WhatsApp、Messenger 不算SMS，会落入Referral或Organic Social
- Mobile Push：满足三个OR条件之一即可（utm_medium以push结尾、包含mobile/notification、或utm_source=firebase）
若渠道报告出现大量Unassigned/(other)区域，需检查UTM命名是否与官方规则一致。
原文链接：https://dev.to/toshihiro_shishido/what-channel-are-email-and-sms-in-ga4-googles-official-spec-has-the-answer-5d51
#开发者 #工具
📢 频道：@DevToolboxHub
Google Analytics 4 默认渠道分组根据 utm_source 和 utm_medium 值将流量归类为23个渠道。官方规则不可覆盖，常见错误导致邮件/SMS流量错误分配至Referral或Unassigned。
- Email渠道：utm_medium=email（或 e-mail, e_mail, e mail）匹配即可；使用 newsletter、mail 等会导致分类失败
- SMS渠道：必须精确匹配“sms”，大小写敏感；LINE、WhatsApp、Messenger 不算SMS，会落入Referral或Organic Social
- Mobile Push：满足三个OR条件之一即可（utm_medium以push结尾、包含mobile/notification、或utm_source=firebase）
若渠道报告出现大量Unassigned/(other)区域，需检查UTM命名是否与官方规则一致。
原文链接：https://dev.to/toshihiro_shishido/what-channel-are-email-and-sms-in-ga4-googles-official-spec-has-the-answer-5d51
#开发者 #工具
📢 频道：@DevToolboxHub
ONTAP文件事件实时入Datadog
通过 ECS Fargate 构建的 FPolicy 文件活动管道，将 FSx for ONTAP 的文件操作事件转发到 Datadog。使用轻量 Python TCP 服务器接收事件，经 SQS 缓冲后由 Lambda 推送至 Datadog。
- 采用 ECS Fargate 运行 TCP 监听器，解决 Lambda 无法维持持久 TCP 连接的缺陷
- 创建事件可在约 6 秒内到达 Datadog；异步模式下 rename/delete 事件不可靠，需配合审计日志
- 提供 CloudFormation 一键部署 Fargate 服务与 Datadog 配送 Lambda，并附 ONTAP 侧 CLI 配置示例
链接：
https://dev.to/aws-builders/fpolicy-file-activity-pipeline-ontap-to-datadog-via-ecs-fargate-2ing
https://github.com/Yoshiki0705/fsxn-observability-integrations
#开发者 #工具
📢 频道：@DevToolboxHub
通过 ECS Fargate 构建的 FPolicy 文件活动管道，将 FSx for ONTAP 的文件操作事件转发到 Datadog。使用轻量 Python TCP 服务器接收事件，经 SQS 缓冲后由 Lambda 推送至 Datadog。
- 采用 ECS Fargate 运行 TCP 监听器，解决 Lambda 无法维持持久 TCP 连接的缺陷
- 创建事件可在约 6 秒内到达 Datadog；异步模式下 rename/delete 事件不可靠，需配合审计日志
- 提供 CloudFormation 一键部署 Fargate 服务与 Datadog 配送 Lambda，并附 ONTAP 侧 CLI 配置示例
链接：
https://dev.to/aws-builders/fpolicy-file-activity-pipeline-ontap-to-datadog-via-ecs-fargate-2ing
https://github.com/Yoshiki0705/fsxn-observability-integrations
#开发者 #工具
📢 频道：@DevToolboxHub
CLI-Anything：让AI agent操控任意GUI软件
CLI-Anything 是一个开源框架，能将无API的桌面应用自动封装为结构化CLI，使AI agent像调用函数一样控制它们。它采用7阶段自动化流水线（分析→设计→实现→测试→文档→发布），生成确定性JSON输出、完整测试覆盖及专供AI agent读取的SKILL.md。目前已支持80+应用，包括GIMP、Blender、LibreOffice、Godot、FreeCAD等。项目通过CLI-Hub包管理器实现社区共享，一键安装已有封装。同一团队此前发布OpenHarness，两者可组合使用——OpenHarness提供运行时框架，CLI-Anything提供工具接口层。
GitHub：https://github.com/HKUDS/CLI-Anything
原文：https://dev.to/wonderlab/one-open-source-project-a-day-no-68-cli-anything-making-every-piece-of-software-agent-native-537b
#开发者 #工具
📢 频道：@DevToolboxHub
CLI-Anything 是一个开源框架，能将无API的桌面应用自动封装为结构化CLI，使AI agent像调用函数一样控制它们。它采用7阶段自动化流水线（分析→设计→实现→测试→文档→发布），生成确定性JSON输出、完整测试覆盖及专供AI agent读取的SKILL.md。目前已支持80+应用，包括GIMP、Blender、LibreOffice、Godot、FreeCAD等。项目通过CLI-Hub包管理器实现社区共享，一键安装已有封装。同一团队此前发布OpenHarness，两者可组合使用——OpenHarness提供运行时框架，CLI-Anything提供工具接口层。
GitHub：https://github.com/HKUDS/CLI-Anything
原文：https://dev.to/wonderlab/one-open-source-project-a-day-no-68-cli-anything-making-every-piece-of-software-agent-native-537b
#开发者 #工具
📢 频道：@DevToolboxHub
Spec2PR：智能SDLC编排工具
Spec2PR 是一个面向工程团队的 AI 驱动 SDLC 编排平台，核心目标是通过结构化工程上下文解决 AI 生成代码的“意图漂移”问题。
- 引入 RTCFR 框架（角色、任务、上下文、格式、报告），在代码生成前嵌入结构化工程意图，避免 AI 输出偏离团队标准
- 核心洞察：软件交付瓶颈不是编码速度，而是“意图保真度”——工程思维在需求、架构、实现、运维等环节逐级丢失
- 平台从 IDE 中心转向 SDLC 中心，实现系统级的上下文感知编排，而非局部代码优化
原文链接
#开发者 #工具
📢 频道：@DevToolboxHub
Spec2PR 是一个面向工程团队的 AI 驱动 SDLC 编排平台，核心目标是通过结构化工程上下文解决 AI 生成代码的“意图漂移”问题。
- 引入 RTCFR 框架（角色、任务、上下文、格式、报告），在代码生成前嵌入结构化工程意图，避免 AI 输出偏离团队标准
- 核心洞察：软件交付瓶颈不是编码速度，而是“意图保真度”——工程思维在需求、架构、实现、运维等环节逐级丢失
- 平台从 IDE 中心转向 SDLC 中心，实现系统级的上下文感知编排，而非局部代码优化
原文链接
#开发者 #工具
📢 频道：@DevToolboxHub
Rejourney: 移动端会话回放成本降至1/17
PostHog 对 25000 次会话收费约 $85/月，而 Rejourney 仅 $5/月；在 350000 次/月下，成本差距约 20 倍。以下为降低成本的工程决策：
- SDK 带宽与帧率优化：SDK 按 1.25× 比例捕获（约原始分辨率 80%），默认 1 FPS，滚动时自动暂停。相比 3× Retina 和 10 FPS，原始像素量减少约 5.8×。
- 压缩与设备端处理：帧打包为二进制归档并 gzip（level 9），上传前在设备端直接对敏感区域进行像素级黑化，避免服务端计算。有严格背压限制（最多 50 批/500 帧）。
- 架构成本控制：上传经 Redis 缓冲（30 分钟 TTL）后异步写入对象存储；使用 CloudNativePG 自建 Postgres（同步备用 + pgbouncer）；计算层采用 k3s 运行于欧洲 VPS（Hetzner），而非托管 Kubernetes。
原文链接
#开发者 #工具
📢 频道：@DevToolboxHub
PostHog 对 25000 次会话收费约 $85/月，而 Rejourney 仅 $5/月；在 350000 次/月下，成本差距约 20 倍。以下为降低成本的工程决策：
- SDK 带宽与帧率优化：SDK 按 1.25× 比例捕获（约原始分辨率 80%），默认 1 FPS，滚动时自动暂停。相比 3× Retina 和 10 FPS，原始像素量减少约 5.8×。
- 压缩与设备端处理：帧打包为二进制归档并 gzip（level 9），上传前在设备端直接对敏感区域进行像素级黑化，避免服务端计算。有严格背压限制（最多 50 批/500 帧）。
- 架构成本控制：上传经 Redis 缓冲（30 分钟 TTL）后异步写入对象存储；使用 CloudNativePG 自建 Postgres（同步备用 + pgbouncer）；计算层采用 k3s 运行于欧洲 VPS（Hetzner），而非托管 Kubernetes。
原文链接
#开发者 #工具
📢 频道：@DevToolboxHub
导师模型工作流：让 DeepSeek 更贴近 Claude Code
使用强模型做规划与审查，弱模型只执行边界明确的小任务，而非一个模型包办全部。
- 强模型先定义任务边界：拆分小单元、限定文件范围、设置验收条件
- 弱模型（DeepSeek）承担窄任务：检查日志、按大纲写段、转换平台版本、修模块不碰无关文件
- 强模型读过程而非只读结果：检查输出、日志、报错、测试失败，甚至视频分辨率、字幕、图片 alt 文本
- 失败教训变为可复用技能：记录触发失败的原因、后续检查节点、平台规则，形成项目笔记与交接文档
🔗 原文链接
#开发者 #工具
📢 频道：@DevToolboxHub
使用强模型做规划与审查，弱模型只执行边界明确的小任务，而非一个模型包办全部。
- 强模型先定义任务边界：拆分小单元、限定文件范围、设置验收条件
- 弱模型（DeepSeek）承担窄任务：检查日志、按大纲写段、转换平台版本、修模块不碰无关文件
- 强模型读过程而非只读结果：检查输出、日志、报错、测试失败，甚至视频分辨率、字幕、图片 alt 文本
- 失败教训变为可复用技能：记录触发失败的原因、后续检查节点、平台规则，形成项目笔记与交接文档
🔗 原文链接
#开发者 #工具
📢 频道：@DevToolboxHub