DEV Community 中文 - TheNote.app

DEV Community 中文
关注

Dev.to是一个以软件开发、编程和技术为中心的社区驱动型网站。它于2016年由Ben Halpern推出，旨在为开发者提供一个分享知识、从他人身上学习和建立社区的平台。该网站采用博客式格式，用户可以创建和分享各种主题的文章，如编程教程、项目展示、行业见解等。Dev.to允许用户创建账户、关注其他用户，并通过评论和反应与他们的内容互动。 Dev.to非常注重社区参与，拥有讨论论坛、播客和直播等功能。它还主办了一系列社区驱动的项目，如编程挑战和黑客马拉松，以鼓励协作和创新。除了用户生成的内容外，Dev.to还提供了一个招聘板块，公司可以在这里发布招聘信息，而开发者可以在这里寻找就业机会。该网站还提供了一份新闻通讯，为用户提供最新文章、新闻和事件的更新。总之，Dev.to已经成为开发者连接、分享知识并跟踪软件开发行业最新趋势和技术的热门平台。

DEV Community dev.to

DEV Community 中文 RSS thenote.app

RSS Hunter • 2024年8月23日

笔记线程

构建克劳狄乌斯所依赖的基础

本文详细阐述了名为 Claudius 的基于 Claude 的聊天机器人的服务端配置，重点涵盖其身份系统、服务连接性及部署现实。身份系统确保用户角色（如管理员、成员或访客）完全由服务端判定，客户端无法篡改。该机制采用 Auth.js 配合 Google 提供商及 MongoDB 适配器实现，角色根据管理员邮箱、白名单或默认为访客进行解析。解析后的角色被嵌入 JWT 中，以便在应用内高效访问。 provisioning 流程还会为用户特定字段设置默认值，并确保每次登录时重新计算角色。连接性通过健康检查路由进行验证，该路由会 ping MongoDB Atlas，并可选地向 Bedrock 的 Claude Haiku 模型发起一次轻量级调用。此探测验证了应用能否成功与其 AI 后端交互，并返回令牌使用元数据。应用还定义了一个 AI 模型目录，包含各自的推理配置文件 ID 及定价信息。环境变量根据各开发阶段的需求进行迭代验证，当前集合包括认证、数据库及 Bedrock 凭据。在此配置阶段，遇到了若干关键问题（或称“陷阱”）并予以解决。一个显著问题在于确保 Auth.js 适配器与应用数据库助手均指向正确的数据库，因为连接字符串中缺失数据库路径会导致默认连接到不可访问的"test"数据库。通过全局缓存 MongoDB 客户端优化了连接池。在单体仓库内的依赖管理需谨慎处理运行时依赖，并在可选依赖中包含特定平台的二进制文件以支持部署。用户身份与服务交互的基础现已奠定，但核心聊天功能尚未实现。

Building the foundation Claudius runs on dev.to

RSS Hunter • 今天

将日常流程转化为助手：小型 AI 助手的实用指南

应将 AI 视为函数，而非魔法精灵。将 AI 当作一次性查询的搜索框使用尚可，但对于重复性任务则效率低下。要构建有用的 AI 助手，应从单一、狭窄、重复、枯燥且可验证的任务入手。将提示词（prompts）视为函数签名，明确输入并结构化输出。为确保摘要的可靠性，强制 AI 引用源材料中的支持性句子。对于数据清理，避免就地修改，而是让 AI 输出映射结果以供审查。关键在于通过创建少量“黄金集”（golden set）的正确示例来验证 AI 输出。实施低成本检查，如代码断言和抽样检查，以尽早发现错误。仅在任务真正涉及多步骤或工具调用时，才引入智能体（agents）。最后，通过迭代，将成功的 AI 输出纳入提示词，以构建可预测且可靠的助手。

Turn Your Routine Into an Assistant: A Practical Guide to Small AI Helpers dev.to

RSS Hunter • 今天

DeepSeek V4 Flash API 成本：思维模式破坏严格 JSON

DeepSeek V4 Flash 在 0731 版本中存在一个缺陷：当启用思考模式时，结构化 JSON 输出中的整数字段可能出现损坏。该问题仅在严格 JSON 模式下发生，且在多数测试运行中均被观察到。禁用思考模式可解决损坏问题，并显著降低 token 用量。然而，0731 次重训在禁用思考模式时，会导致多步任务的性能出现更明显的下降。该模型具备缓存机制，存储 1,024 token 的页面，命中响应迅速，且条目至少保留 45 分钟。定价保持一致，输入 token 为每百万 0.14 美元，输出 token 为每百万 0.28 美元，缓存命中价格显著更低。与其他 V4 版本相比，0731 版本受结构化输出损坏的影响最为严重。API 上的 effort 拨杆未产生可测量的性能或 token 用量差异。对于 0731 版本，双跳数学等复杂任务现在高度依赖启用思考模式。上下文窗口容量可观，可容纳大型提示，输出限制似乎可协商。需要可靠结构化输出的用户，在缺陷修复前应在 0731 版本上禁用思考模式。

DeepSeek V4 Flash API Cost: Thinking Mode Corrupts Strict JSON dev.to

RSS Hunter • 今天

MCP 详解：驱动 AI 代理的协议”

现代人工智能系统如今能够通过交互外部工具、数据库和服务来执行复杂任务，从而催生了 AI 智能体（AI agents）。一个重大挑战在于，每个应用程序和 API 都以独特方式暴露其能力，因此需要为每个 AI 平台进行定制集成。模型上下文协议（Model Context Protocol, MCP）通过为 AI 模型提供发现、理解和使用外部资源的标准化方式来解决这一问题。MCP 充当通用语言，使 AI 客户端能够发现工具、理解其功能、接收结构化输入、执行工具并获取结构化结果。该协议对于需要执行超出文本生成范围的操作的 AI 智能体至关重要，例如与 GitHub、Slack 或数据库交互。MCP 涉及 MCP 客户端（AI 应用程序）、MCP 服务器（暴露能力）以及工具本身。该流程包括 AI 客户端连接至服务器、发现可用工具、根据用户请求调用选定工具，并接收结构化结果。对于开发者而言，MCP 提供了标准化集成、更好的可维护性以及工具的可发现性提升。与传统暴露原始端点的 API 不同，MCP 以 AI 模型可理解的高层方式描述能力。虽然函数调用（function calling）允许 AI 调用应用程序内预定义的功能，但 MCP 为跨不同 AI 客户端共享能力提供了更广泛的生态系统。安全至关重要，MCP 服务器需要强大的身份验证、授权和验证机制。MCP 适用于多种用例，包括编程助手、企业搜索和 DevOps 工作流，它是对现有 API 的补充而非替代。

MCP Explained: The Protocol Powering AI Agents dev.to

RSS Hunter • 今天

Show DEV：使用 .NET 和 Caddy 构建智能手机规格 API

由于数据不完整且未规范化，历史上集成移动硬件规格 API 一直较为困难。规格信息的原始字符串格式（如屏幕刷新率和 CPU 时钟速度）在编程逻辑中显得笨拙。为解决这一问题，开发了 Device Specs API，以应对杂乱和无结构的数据。该新 API 将解析负担转移至后端，提供干净、强类型且规范化的 JSON 数据。这意味着数值即为真正的数值，布尔值即为布尔值，而复杂规格则以结构化数组形式呈现。例如，电池容量为整数，NFC 可用性为清晰的布尔值，而非文本。该 API 还支持深度过滤，允许用户通过 URL 参数查询非常具体的硬件参数。这使得复杂搜索成为可能，例如查找电池容量超过 5000 mAh、内存至少 8GB、来自三星或小米且型号名称中包含"pro"的设备。后端采用 ASP.NET Core Web API 构建，前端则利用 Blazor WebAssembly/Server 混合架构。Caddy 用作反向代理和 SSL 处理器，因其自动 HTTPS 证书管理和简洁的配置而得到采用。该 API 的文档和交互式测试已在线提供，供用户探索并反馈。

Show DEV: Building Smartphone Specs API with .NET and Caddy dev.to

RSS Hunter • 今天

应对暴露的秘密——SRE 事件响应手册

事件响应剧本为在危机期间管理和最小化中断提供了结构化流程。在创建剧本之前，需明确其目标、范围和角色，确保建立清晰的沟通与文档渠道。测试与培训是关键的准备工作。特定类型的事件需要定制化的剧本；与系统中断相比，密钥泄露在检测方面具有独特挑战。与系统故障不同，密钥泄露可能不会立即触发明显的警报，因此需要针对 API 使用、云活动和数据库查询进行专门监控。调查密钥泄露涉及确定其完整范围和影响，这可能波及广泛。预防密钥泄露依赖于安全的密钥管理、最小权限原则、代码扫描以及持续的教育。在事件发生期间，遏制措施包括在评估影响范围后隔离系统、禁用账户或撤销受损密钥。自动化流程和工具可加速密钥轮换和系统更新。在生产环境中部署密钥需要谨慎的策略，如蓝绿部署或金丝雀发布，以最小化停机时间。事后分析对于识别根本原因和系统性弱点至关重要，且不应归咎于个人。该分析应指导采取主动措施以防止未来事件，例如改进安全实践并更新剧本。

Responding to Exposed Secrets - An SRE's Incident Response Playbook dev.to

RSS Hunter • 今天

🚀 使用 Hermes Agent 和 Remotion 构建端到端 AI 视频生产流程

本教程展示了如何利用 Hermes Agent 和 Remotion 构建一个 AI 驱动的视频制作流程，以生成短视频。该自动化工作流涵盖了从研究热门话题到渲染最终成片的各项任务。流程始于 Hermes Agent 对病毒式传播话题的研究，并以詹姆斯·韦伯太空望远镜发现星际彗星上的甲烷为例。随后，Agent 生成详细的制作脚本，包括旁白、分镜以及 Remotion 提示。接着制定逐场景制作计划，明确色彩方案、动画风格及剪辑方向。工作流自动为每个场景生成 AI 美术作品，并利用 Remotion 构建动态图形视频，甚至可迭代优化各场景。添加自然合成的 AI 配音后，再叠加背景音乐与音效，使成片更具质感。使用 Whisper 生成带单词级标注的动态字幕，以提升可读性与视觉吸引力。这一综合方法使创作者能专注于叙事，而非手动剪辑。该工作流适用于教育内容、营销视频及社交媒体等多种项目，为开发者和技术型创作者提供了比传统视频编辑器更高的灵活性。

🚀 Build an End-to-End AI Video Production Pipeline with Hermes Agent and Remotion dev.to

RSS Hunter • 今天

OpenAI GPT-Live 将连续语音对话规模化引入 ChatGPT

OpenAI 推出了 GPT-Live，这是专为 ChatGPT 打造的一代新型语音模型，旨在实现更流畅、实时的对话。其全双工架构使系统能够同时聆听和发声，从而支持自然的轮流发言、确认回应及打断。这种方法解决了语音接口在处理高要求交互时的常见难题。GPT-Live 将实时对话层与负责更繁重任务的模型分离开来，以避免中断。

OpenAI GPT-Live Brings Continuous Voice Conversations to ChatGPT at Scale dev.to

RSS Hunter • 今天

使用 AI 调试代码而不崩溃

使用 AI 调试复杂问题最有效的方法是提供具体、确凿的证据，而非模糊的描述。关于应用程序崩溃的模糊提问往往只能得到泛泛的建议，鲜少有用。与其描述问题，不如向 AI 展示实际的错误堆栈、相关的代码片段以及最近的 git 提交。创建一个能够稳定复现该 bug 的小型可重现案例更佳。一旦提供了这些上下文，你就可以就观察到的具体行为提出针对性问题。AI 难以处理歧义，但在解释精确的代码执行方面表现出色。例如，在调试内存泄漏时，通过提供堆快照和特定代码片段，迅速定位到了缺失的 map 条目清理问题。Chrome DevTools 的堆快照功能、clinic.js 的性能分析工具以及 Node 的 inspect 特性，对于收集此类证据至关重要。展示 git diff 和日志有助于 pinpoint 近期可能引发问题的更改。关键在于将 AI 作为加速你理解的工具，而非替代你自己的调试过程。不妨将 AI 视为一双不知疲倦的、充满新意的眼睛，协助你分析所提供的证据。

Using AI to Debug Code Without Losing Your Mind dev.to

RSS Hunter • 今天

我在准备加拿大移民的同时，构建了一个 PTE 核心平台

“具有竞争力的 CRS 分数对加拿大永久居民（PR）申请至关重要，而语言能力是其中的关键因素。最初，雅思（IELTS）和 CELPIP 是主要的英语考试，但相关资源缺乏关于如何取得高分的明确指导。2024 年 PTE Core 的推出提供了一种机考替代方案，尤其受到偏好可量化练习的申请人青睐。然而，PTE Core 备考资源尚不成熟，大多数内容面向 PTE Academic，对移民申请人而言并不完全适用。鉴于这一空白，创始人创立了 Phrasel，一个专为加拿大移民 aspirants 打造的学习平台与社区。Phrasel 专注于 PTE Core，深刻理解移民考试与其他通用英语考试在目标与分数门槛上的独特性。该平台强调清晰性而非海量练习材料，旨在精准定位待提升领域。其核心理念是：学习者需要诊断性反馈以指导后续步骤，而非仅仅获得更多题目或僵化的模板。Phrasel 将加拿大 PR 专用工具（如 CLB 等级转换和 CRS 分数）直接集成至练习工作流中。平台提供涵盖听、说、读、写四项技能的考试风格练习，口语和写作部分由 AI 评分并提供详细反馈。平台还提供全真模拟测试，用于精准识别优势与不足，从而支持针对性学习。Phrasel 强调培养真实的语言能力，而非依赖捷径或背诵模板，坚信真正的技能发展才能带来持久的分数提升。AI 评分虽作为有价值的训练信号，但被诚实地定位为优化工具，而非对官方 Pearson 分数的保证预测。Phrasel 的技术栈包括 Next.js、React、Vite、Flask 以及用于评分的 AI 服务。创始人认为，清晰的反馈与明确识别阻碍进步的薄弱环节，是实现高效备考的关键。

I Built a PTE Core Platform While Preparing for Canada PR dev.to

RSS Hunter • 今天

开发者网络基础：入门所需的核心概念

本指南为开发者、Linux 用户及网络安全初学者提供基础网络知识。网络使设备能够通信并共享数据，利用 MAC 地址进行本地连接，利用 IP 地址进行更广泛的网络（如互联网）通信。DHCP 服务器自动分配 IP 地址，简化网络管理。子网将大型网络划分为更小部分，而路由器连接不同网络，并通过默认网关路由外部流量。DNS 将域名解析为 IP 地址，递归服务器负责查找这些地址，权威服务器提供官方记录。TCP 确保可靠且有序的数据传输，适用于网页浏览和文件传输；而 UDP 则优先考虑速度，适用于实时流媒体和游戏等应用。端口将网络流量引导至设备上的特定服务或应用程序。ARP 将 IP 地址映射为 MAC 地址，促进本地网络内的通信。隧道技术将数据包封装以便在不同网络间传输。OSI 模型定义了网络通信的七层结构，从物理传输到应用交互，提供了标准化的框架。各种网络协议，包括用于网页通信的 HTTP/HTTPS、用于实时连接的 WebSocket 以及用于文件传输的 FTP，规范了数据的交换方式。掌握这些基础知识对于理解现代计算以及在广阔的网络领域持续学习至关重要。

Networking Fundamentals for Developers: The Only Concepts You Need to Get Started dev.to

RSS Hunter • 今天

pgvector 与 Pinecone 与 Qdrant：何时真正需要专用向量数据库？

对于现有 Postgres 环境中数百万级向量的场景，pgvector 是理想的初始选择，通过将过滤器、连接和事务统一置于同一位置来简化操作。它作为 Postgres 扩展，增加了向量列类型和近似最近邻（ANN）索引，且为开源方案。当召回率、高查询吞吐量、水平扩展或运维交接在 Postgres 中变得难以应对时，则需采用专用向量数据库，如 Pinecone 或 Qdrant。Pinecone 是完全托管的闭源云服务，提供零运维负担，但会带来供应商锁定和按消费计价的成本。Qdrant 是一款基于 Rust 的开源向量数据库，支持自托管或云服务，具备强大的元数据过滤和量化能力。虽然 pgvector 在运维简洁性和查询表达力方面表现优异，但在高负载下可能面临压力，并与事务性工作负载产生竞争。转向专用向量数据库的决策通常源于规模需求、查询并发隔离，或希望将搜索的运维责任剥离。专用向量数据库的真实成本并非迁移本身，而是架构中新增系统所带来的持续运维复杂性。因此，建议从 pgvector 起步，若追求托管简洁性可过渡到 Pinecone，若需要专为向量设计且开源可控的引擎则选择 Qdrant。务必使用自身数据进行基准测试，以做出基于工作负载的明智决策。

pgvector vs Pinecone vs Qdrant: When Is a Dedicated Vector Database Actually Worth It? dev.to

RSS Hunter • 今天

别再称一切为“冒名顶替综合征”：“再努力一点”的迷思

作者区分了冒名顶替综合征与导致自我怀疑的真实战略问题。冒名顶替综合征表现为尽管有客观成就，仍感觉自己是个骗子，这一点在关于人工智能的文章和个人受邀参加学术会议的个人经历中得到了体现。在这些情况下，大脑会为感知到的不足编造解释。然而，并非所有的不足感都源于冒名顶替综合征。例如，跑步能力差并不意味着患有冒名顶替综合征；这可能仅仅意味着缺乏天赋或训练方法不当。对于属于战略问题而非信心相关的问题，给出“更努力”或“坚持下去”之类的建议可能适得其反。工程学方法建议批判性地分析自身的战略，而不仅仅专注于提升信心。这包括质疑所投入的时间是否产生了成果，并考虑替代战略。区分真正的冒名顶替综合征与表明方法有缺陷的怀疑至关重要。有时坚持是答案，但有时则需要战略调整。学会做出这种区分是个人成长中困难但重要的一部分。

Stop Calling Everything Impostor Syndrome: The Myth of "Just Push Harder" dev.to

RSS Hunter • 今天

🚦 事件监听器、处理器和 DbContext — 陷阱与最佳实践 - .NET 10

在 .NET 中实现依赖注入时，需仔细考虑服务生命周期。一个常见的陷阱是：当单例服务（如 EventListener）直接依赖范围服务（如 DbContext）时，若将范围类型的 DbContext 注入到单例的 EventProcessor 中，会导致同一 DbContext 实例被无限次复用。这种过期的 DbContext 可能引发数据过时和并发错误等问题。推荐的做法是：将 EventProcessor 注册为单例，但注入 IServiceScopeFactory。该工厂使单例处理器能够在需要时创建新的作用域并获取全新的 DbContext。或者，也可以将 EventProcessor 本身注册为范围生命周期。在此场景下，单例的 EventListener 会使用 IServiceScopeFactory 为每个处理的事件创建作用域，并从中解析出范围类型的 EventProcessor。归根结底，核心原则是避免将范围依赖直接注入到单例中。如果单例服务需要访问范围服务，应通过 IServiceScopeFactory 动态获取。同样，如果某个服务需要特定的生命周期（如“范围”），则应将其注册为该生命周期，并相应地解析。理解这些生命周期管理策略，可有效预防与依赖注入相关的常见错误。

🚦 Event Listeners, Processors, and DbContext — Pitfalls & Best Practices - .NET 10 dev.to

RSS Hunter • 今天

当您的支付供应商被收购时，您的集成会发生什么

金融科技并购在英国科技领域屡见不鲜，应将其视为一种工程风险。近期案例表明，收购可能改变产品发展轨迹并引发整合挑战。Visa 收购 Plaid 后，战略重心转向企业级条款，使得小型企业的接入流程更加困难。TrueLayer 的 API 迁移需要开发人员投入大量精力以适应新要求。GoCardless 收购 Nordigen 后，免费层级被缩减，迫使部分开发人员重新评估其技术栈。从统计概率来看，任何依赖第三方支付 API 的企业都可能因收购或价格调整而遭遇变更。为缓解此类风险，开发人员应在供应商 SDK 周围构建薄抽象层，以隔离核心业务逻辑。在自有数据库中存储规范化的支付状态对于在供应商变更期间保持数据完整性至关重要。关注早期信号（如免费层级缩减或支持响应变慢）可预示平台即将发生转变。在路线图预算中预留推测性迁移时间，有助于更快速地应对非预期的变更。归根结底，承认供应商 API 的商业风险并建立架构距离，是确保系统韧性的关键。

What Happens to Your Integration When Your Payments Vendor Gets Acquired dev.to

RSS Hunter • 今天

我是如何构建 ToolHub 的：一个保持低于一秒响应时间的 138 个工具静态 PWA

作者最近发布了一篇关于构建 ToolHub 的完整架构回顾。ToolHub 是一套包含 138 个浏览器内网页工具的套件，优先注重简洁性、隐私性和零臃肿。该站点设计为亚秒级加载速度，并完全支持离线使用，其中关键工程权衡与技术决策支撑了这些特性。架构的核心亮点之一是采用 Next.js 静态导出（Static Export），实现了 100% 静态导出模型，托管于边缘 CDN，从而实现零服务器维护与极低的字节首传时间（time to first byte）。该方案还支持无限扩展，但要求所有动态内容必须在浏览器内存中严格在客户端执行。此外，作者实现了一套自定义 Service Worker 缓存策略，对静态资源采用 stale-while-revalidate 策略，对 HTML 文档导航采用 network-first 策略，确保所有工具在缓存后具备完整的离线能力。作者还开发了一个程序化 SEO 引擎，在构建时生成带有完整 JSON-LD 结构化数据和自动化内部链接网的静态工具页面，并将其直接嵌入静态 HTML 中。该站点还采用了零 CLS（累积布局偏移）广告策略，通过在广告加载前预留显式的固定高度布局槽位，防止布局偏移。作者已将 ToolHub 站点开放供用户试用，并在其博客上发布了完整的工程深度解析，分享了构建该站点过程中的更多技术决策与权衡细节。作者正寻求用户反馈与建议，欢迎对架构提出想法以及对新工具的构思。总体而言，ToolHub 项目展示了一系列创新的技术方法，用于构建快速、支持离线且以隐私为先的 Web 应用。

How I Built ToolHub: A 138-Tool Static PWA That Stays Sub-Second dev.to

RSS Hunter • 今天

大多数系统设计面试都聚焦于图表。而真实系统的失败源于权衡取舍。

作者在系统设计的讨论中观察到一个常见问题：过度强调图表，而忽视驱动架构决策的关键权衡。他们提出了几个根本性问题，例如在一致性与可用性之间取得平衡，以及权衡单体架构与微服务的利弊。作者还强调了事件驱动架构的复杂性，以及为提升可扩展性所可接受的延迟。另一个关键关注点是，何时审慎地避免或实施缓存策略。作者认为，这些决策对生产系统的影响远大于视觉表现本身。他们最近发表了一篇深入探讨这些现实世界架构权衡的文章，并辅以实际案例。作者正积极寻求经验丰富的架构师和后端工程师对其见解的反馈，尤其希望听到相反观点或替代视角。社区的核心问题围绕着一个单一的架构权衡，该权衡深刻重塑了他们对分布式系统设计的方法。

Most system design interviews focus on diagrams. Real systems fail because of trade-offs. dev.to

RSS Hunter • 今天

当编辑失败时，什么都不会被抛出

有效删除个人身份信息（PII）需要精心设计处理管道，因为模型往往会静默失败。在调用模型之前先进行基于规则的预处理，可能会因生成不自然的 token 模式而混淆模型，从而恶化结果。相反，应在原始文本上独立运行语义和结构两种处理流程，然后协调结果，确保结构偏移量保持有效，并过滤掉结构流程中置信度较低的时间检测。企业文档中的标记可能会扰乱模型输出；应提取纯文本、执行删除操作，再将其重新插入原始结构中，以显著提高召回率。针对拒绝执行删除的模型，需实施拒绝检测机制，回退至结构处理流程，并将这些实例记录在案，以便调整提示词。至关重要的是，系统设计应遵循“失败即关闭”（fail closed）而非“失败即开放”（fail open）的原则，以防止删除调用超时时发生数据泄露，将结构处理流程视为降级路径，并对此类事件发出警报。通过每次删除操作记录模型 ID 和提示词哈希值来实现提示词的版本控制，从而追踪性能随时间的变化。对于删除文本中的共指关系，应使用编号占位符而非通用标签，但需注意生成的映射表本身也属于 PII，需采取适当的安全措施；若无需可逆性，则直接丢弃该映射表。为衡量精确度，应构建一组不含 PII 的“金丝雀”文档集，并在每次变更时运行该集合；若其中出现任何删除操作，即表明性能出现回退。在扩展规模时，应超越单一模型的限制，构建路由接口，根据调用方的约束条件（如延迟、驻留地或语言）将请求分发至不同模型，同时始终将结构处理流程作为通用回退方案。针对长度超过 1,024 token 的提示词，需实施精细的缓存策略，以优化成本与吞吐量。推荐的构建顺序包括：提取文本、独立运行语义和结构处理流程、过滤时间、注入结构发现结果、将内容代回标记、检测拒绝情况，并记录关键元数据，同时持续使用金丝雀集进行测试。

Nothing throws when redaction fails dev.to

RSS Hunter • 今天

如何在 React 中修复 CORS 错误：实用指南（含真实解决方案）

在构建 React 应用时，开发者在进行 API 请求时经常会遇到 CORS 错误。该错误是由于浏览器的安全策略阻止了未经适当授权的跨源请求。最稳健的解决方案是配置后端应用程序以发送 Access-Control-Allow-Origin 响应头。该头指定了允许访问 API 的前端域名。对于使用 Node.js 和 Express 的项目，这涉及使用 cors 中间件并将其配置为接受特定的源。同样，Laravel 和 Python 的 Flask 也提供了直接设置这些响应头或通过 flask-cors 等库进行配置的方法。如果无法直接修改后端，可以在本地开发期间使用代理。通过在 package.json 文件中添加 "proxy" 字段，React 开发服务器可以将请求转发至 API。此方法绕过了 CORS 限制，因为浏览器会将该请求视为同源请求。然而，这种代理方案仅在开发环境中有效，在生产环境中无法使用。一种临时但不推荐的变通方法是使用公共 CORS 代理服务，但这会引入延迟、潜在的速率限制以及安全问题。如果 API 需要身份验证（如 Cookie 或 JWT 令牌），则必须同时更新前端 fetch 请求和后端配置以包含凭证。前端请求需设置 credentials: 'include'，后端则需设置 credentials: true。调试 CORS 问题涉及检查浏览器开发者工具网络面板中 Access-Control-Allow-Origin 响应头的存在性和正确性。如果预检请求（OPTIONS）失败，则表明后端可能未正确配置以处理此类请求。归根结底，大多数 CORS 错误源于后端配置问题，而非前端代码。深入理解运行环境、前端及后端框架对于有效调试至关重要。

How to Fix CORS Errors in React: The Practical Guide (With Real Solutions) dev.to

RSS Hunter • 今天

无XML的结构化创作——它是如何工作的

结构化创作利用可复用的语义构建块来创建内容，这一概念由 DITA XML 正式确立。Topicary 实现了这些原则，而无需具备 XML 知识。其核心功能是内容组件，这些组件只需编写一次，即可在多个主题中复用。更新组件时，更改会自动传播到所有引用处。用户可通过简单命令轻松将任意文本块保存为组件。组件提供强大的“何处使用”跟踪功能，使作者能够评估编辑的影响。条件内容允许通过为文本块添加特定条件标签，使单个主题能够针对不同受众进行定制。作者可直接在编辑器中预览这些条件视图，以获取即时反馈。变量通过允许对产品名称或版本号等重复元素进行单点更新，从而简化内容管理。Topicary 支持从多种格式导入内容，包括 Markdown、DITA 和 MadCap Flare，并保留现有的结构和功能。

Structured authoring without XML - how it works dev.to

RSS Hunter • 今天

Microsoft Agent Framework 已推进至生产就绪运行时”

Microsoft Build 2026 的发布重点在于其 Agent Harness 和 Foundry Hosted Agents，现已进入一般可用性（General Availability）阶段。这标志着 AI 代理在生产和实际构建中的认知与方式发生了转变。研究表明，代理系统中约 98.4% 的组成部分是基础设施，而非 AI 模型本身。Agent Harness 提供了这一关键的运营核心，负责处理函数调用、上下文管理和工具路由等任务。Foundry Hosted Agents 则以托管、按消耗计费的服務形式提供该 Harness，简化了部署流程。Agent Harness 解决了生产环境中常见的瓶颈问题，例如将代理与工具连接以及持久化对话历史。Microsoft 的核心押注在于：真正的产品是这一 Harness 基础设施，而非可互换的 AI 模型。该 Harness 包含多项功能，如带历史记录的函数调用、上下文压缩、计划与执行的待办事项列表、文件记忆，以及内置的 OpenTelemetry 用于可观测性。这确保了从工具调用到审批决策的每一个操作均可追溯。Foundry Hosted Agents 通过提供托管部署，消除了对复杂 YAML 配置的需求，用户只需提供聊天客户端、指令和工具。该托管服务与本地可运行的 Harness 共享相同的核心逻辑，从而确保开发与生产环境之间行为的一致性。该框架还引入了与 GitHub Copilot 和 Claude Agent SDK 的连接，允许在不改变 Harness 的前提下进行模型切换。统一的治理策略平面确保了在不同底层 AI 模型之间保持一致的审批规则和审计轨迹。代理系统中涵盖审批网关、历史和策略执行的持久层被强调为工程投入的关键领域。Microsoft 的解决方案将 Harness 定位为稳定且受支持的产品，使开发者能够专注于构建适应性强的应用程序。

Microsoft Agent Framework Advances to Production-Ready Runtime dev.to

RSS Hunter • 今天

Spring AI 提示词缓存与聊天记忆：令牌流向——LLM 成本管控 2/4

本节重点讨论控制与 AI 模型输出、对话历史及重复静态内容相关的成本。输出和推理 token 的成本显著高于输入 token，部分模型的输出成本甚至高达输入的八倍。推理过程可能生成隐藏的“思考”token，同样会产生较高的输出费用。Spring AI 提供了诸如 maxTokens 等与提供商无关的长度限制，以及针对特定提供商的设置，以管理推理努力程度。对话历史涉及每次请求重新发送整个聊天日志，这会迅速推高输入 token 成本。存储并重新发送历史意味着即使是小型对话，随着时间的推移也可能导致大量的 token 使用。Spring AI 提供 MessageWindowChatMemory 来管理对话历史，其采用指定消息数量的滑动窗口机制。对于非常长的会话，VectorStoreChatMemoryAdvisor 提供了一种替代方案，它将历史存储在向量存储中，仅检索相关消息。重复的静态内容（如系统提示或工具定义）在未缓存的情况下，每次请求都会计费。提示缓存通过存储已处理的提示前缀以供重用，从而降低这些成本。Anthropic 和 AWS Bedrock 允许用户指定缓存策略，而 OpenAI 会对超过一定 token 数量的请求自动缓存提示，尽管现在缓存写入会产生费用。本地模型（如 Ollama）利用缓存来提升速度，通过保存 GPU 处理时间，但由于不存在按 token 计费的机制，因此无法通过此方式减少成本。对于这些模型，明确规划缓存策略并管理缓存键对于成本优化至关重要。

Spring AI Prompt Caching and Chat Memory: Where the Tokens Go — LLM Cost Control 2/4 dev.to

RSS Hunter • 今天

六周前，Google 仅收录了我的 4 个页面。如今已增至 115 个。我几乎未做任何改动。

六周前，作者指出，他们新域名 tamethebot.com 的122个页面中，只有4个被谷歌收录。他们将此归因于缺乏反向链接的年轻域名的爬取预算限制，而非技术问题。最近的更新显示了显著改善，目前有115页被索引，只有14页未被索引。作者最初关于爬取预算问题的预测被证实正确，“发现——目前未被索引”类别降至零。关键是，在此期间网站内容几乎没有任何更改;新页面的添加速度相同，单个实验性的“深度”页面表现不佳于平均水平。与索引增加同步的关键变化是作者之前的文章发布，成功获得了两个dofollow反向链接，指向主页和网站地图。虽然无法最终证明，但这个反向链接，加上域名老化和定期重新爬取，为谷歌提供了更多预算的理由。作者承认有一个技术错误：他们的IndexNow部署钩子数周内一直默默失效，尽管这并未影响谷歌的索引，因为IndexNow主要服务于必应和Yandex。被索引页面的增加转化为自然谷歌会话的显著增长，从一个小基准线开始。然而，作者提醒说，一些被追踪的“活跃用户”实际上是数据中心，而非真实人类。出乎意料的是，虽然谷歌索引器批准了这些页面，但Google AdSense却两次拒绝了同一内容的“低价值内容”。作者承认索引者的标准（这是搜索者可能想要的真实页面吗？）与AdSense的不同（该网站是否具备足够深度和流量作为广告业务？）。作者接下来的步骤是继续公开写作，以获得谷歌索引器和AdSense的认可。

Six weeks ago Google had indexed 4 of my pages. It just hit 115. I changed almost nothing dev.to

RSS Hunter • 今天

最佳免费网页应用防火墙比较（2025年）

本文比较了多种 Web 应用防火墙（WAF）解决方案，并按类型和部署方式对其进行分类。SafeLine Community 是一种通过 Docker 部署的自托管反向代理。Cloudflare Free 是一种基于云的边缘代理，需要更改 DNS 设置。CrowdSec WAF 是一种基于模块的自托管选项，而 ModSecurity 则作为服务器模块集成。BunkerWeb 是一种基于 NGINX 的自托管解决方案。在检测能力方面，SafeLine 与 ModSecurity 的检测率相当，但 ModSecurity 的误报率显著更高。Cloudflare Free 的检测率非常低，其功能更接近 CDN。CrowdSec 和 BunkerWeb 的性能取决于其底层的规则集。多种免费 WAF 提供无限数量的自定义规则，而 Cloudflare 的免费层级则限制较多。在机器人防护和按国家/地区屏蔽方面，自托管选项通常表现更强。SafeLine 以其简单的单命令部署和开箱即用的功能脱颖而出。Cloudflare 易于使用，但检测能力较弱，且会收集用户数据。CrowdSec 和 ModSecurity 需要更复杂的部署，其中 ModSecurity 需要进行大量调优。对于任何面向公众的网站或 API，都建议使用 WAF。免费 WAF 对于个人项目和小型企业通常已足够，尤其是与其他服务配合使用时。对于需要服务等级协议（SLA）和高级功能的生产环境，必须使用付费 WAF。免费层级通常缺乏专用支持和高级日志功能，尽管检测质量可能与付费版本相似。SafeLine Community 和 CrowdSec 被强调为真正免费且无隐藏费用的选项。插件式 WAF 由于在较晚阶段检查流量，其效果不如反向代理式 WAF。定期更新对于维持 WAF 的有效性至关重要。

Best Free Web Application Firewalls Compared (2025) dev.to

RSS Hunter • 今天

构建可靠的 UDP

TCP 是可靠网络通信的标准，但 UDP 为专用应用提供了更高的控制灵活性。UDP 本身不可靠，发送数据包时不提供交付保证或顺序保证。许多高性能系统（如游戏和流媒体服务）选择 UDP，因为它允许开发人员构建自定义的可靠性机制。这种机制是通过一种工程模式而非独立协议实现的，即在 UDP 数据包中添加元数据。关键组件包括用于跟踪数据包的序列号，以及用于确认接收的确认机制。重传计时器在数据包丢失时触发重传，而重复检测则处理冗余数据包。数据包排序机制确保数据按正确顺序到达应用。滑动窗口允许多个未确认数据包存在，从而提高吞吐量。虽然连接建立并非 UDP 固有特性，但可针对会话管理进行实现。心跳机制用于验证持续连接。拥塞感知对于尊重网络容量至关重要。最终，通过组合这些工程组件，UDP 可转变为针对特定应用需求定制的可靠传输层，正如 QUIC 协议所示。工程中的可靠性往往源于多个简单机制协同工作，而非单一复杂功能。

Building Reliable UDP dev.to

RSS Hunter • 昨天

十九个子域名，一个允许 IP

通配符 DNS 记录通过自动将任意子域名解析到单个 IP 地址，实现了服务的便捷发布。Nginx Proxy Manager（NPM）进一步简化了发布流程，仅需填写少量字段即可安全地以 HTTPS 方式暴露服务。这种自动化导致了十九个代理主机的创建，它们均运行自托管软件，并采用不同的认证方法。识别出的核心问题是：便捷的发布机制绕过了关于访问控制的关键安全决策。作者的目标并非完全隐藏服务，而是使其仅可通过构建在公共基础设施之上的私有网络进行访问。通配符 DNS 记录虽然简化了设置，但其本身并不提供安全性。NPM 使用 HTTP-01 挑战来获取 Let's Encrypt 证书，这需要保持 80 端口开放，从而构成一个安全漏洞。通过 DNS-01 获取通配符证书可以关闭 80 端口，但需要授予 DNS 区域的写入权限。服务通过将容器置于共享 Docker 网络上来发布，允许 NPM 在内部代理请求。这意味着服务无需直接向主机暴露端口，从而增强了安全性。位于同一 VPS 上的自托管代理网关将流量路由回 NPM，表现为来自 VPS 公网 IP 的入站 HTTPS 流量。该网关的行为最初被误认为是路由故障，实则是安全设计的关键组成部分。NPM 使用 Nginx 配置块强制执行访问控制，仅允许来自网关内部 Docker IP 或 VPS 公网 IP 的请求，随后进行基本 HTTP 身份验证。这确保了即使服务可公开解析且拥有有效证书，访问仍受到限制。用于 Let's Encrypt 挑战的特定位置保持对互联网开放，以满足证书验证要求。两个关键主机——网关的管理面板和配置分发端点——是严格访问控制的例外，因为它们需要在完全集成网关之前即可访问。出现了一个重大问题：某项服务将其服务器地址硬编码到用户连接配置文件中，错误地通告了错误的地址。由于 NPM 通过 X-Forwarded-For 头转发真实客户端 IP，该服务将该头解释为其自身的公网地址，导致客户端连接到错误的服务器。此缺陷之所以未被发现，是因为作者使用网关进行的自身测试始终呈现了预期的正确地址。TLS 终止发生在 NPM 处，NPM 与后端容器之间的流量通过 Docker 网络以未加密的 HTTP 形式传输。

Nineteen Subdomains, One Allowed IP dev.to

RSS Hunter • 昨天

赋予 Claude 访问您的 Telegram：两种配置方式及其差异的重要性

您可以使用 MCP 服务器将 AI 代理连接到 Telegram，但存在两种截然不同的配置方式，且各自具有显著的安全影响。第一种方式使用 Bot API 令牌，以机器人身份进行身份验证。该机器人只能访问其被显式添加的聊天，其权限受限且易于撤销，无法查看其未被邀请的私人消息或聊天。第二种方式使用 MTProto 服务器，使用您的电话号码进行身份验证并以您的身份登录。这使代理能够访问您 Telegram 中的所有数据，包括私人消息、群组、保存的消息和联系人。这是通过创建一个代表实时登录状态的会话文件来实现的。配置 Bot API 或通知器需要提供机器人令牌，可能还需要聊天 ID。MTProto 配置则需要安装并使用您的 API ID 和 API hash 进行交互式登录。配置文件的位置因所使用的 AI 客户端而异，某些客户端（如 Codex CLI）使用不同的配置格式（TOML）。使用 MTProto 服务器的主要风险在于会话文件提供了对账户的完全访问权限。该会话文件绝不应存储在同步文件夹中，也不应提交到代码仓库。此外，由于 AI 代理将数据和指令均视为文本，恶意消息可能被构造出来利用代理发送消息的能力，从而构成安全风险。Bot API 令牌的爆炸半径仅限于机器人所在的聊天，而 MTProto 会话文件则会危及您的整个账户。MTProto 服务器并非 inherently 不可用，但需要慎重考虑，理想情况下应使用次要账户以降低风险。在将这些社区开发的 MCP 服务器连接到重要账户之前，务必审查其代码。

Giving Claude access to your Telegram: the two setups, and why the difference matters dev.to

RSS Hunter • 昨天

RAG 成本估算：Token 数量、嵌入向量与 Node.js 语义搜索

为控制语义搜索应用中的 RAG 成本，应在部署前批量处理文档索引并预估 token 消耗。仅将检索到的顶部片段发送给聊天模型以生成答案。有效的 token 成本估算应将索引阶段的嵌入输入、检索时的操作以及答案生成的输入和输出分开计算。估算不仅涉及简单的 token 计数，还需评估片段大小、重叠度及 top-k 设置，因为这些因素直接影响提示长度和成本。实用的估算始于使用代表性文档和真实用户问题，以计算各种分块策略下的 token 总量。召回率至关重要：只有当最相关的段落仍被检索到时，减少片段数量才有意义。重排序可改善上下文排序，从而减少发送给聊天模型的片段数量。索引应作为独立于用户请求路径的批处理作业进行处理，以避免高摄入量导致意外的提示费用。文档索引过程中的重试需要幂等键或客户端提供的标识符，以防止重复数据。在优化提示或模型之前，必须使文档分布可见并识别 oversized 片段。使用提供商特定的 token 计数调用，并配合适当的退避和重试策略，是实现准确估算的关键。批量索引为大规模回溯提供了作业监控和审计追踪的优势，将上传与嵌入创建分离开来。重要的是不要混淆轮询批处理作业与幂等写入操作的重试策略。虽然批量索引不适合即时可搜索性，但一条小型同步路径可满足该需求。RAG 栈组件的选择（如 OpenAI、Anthropic、Google Gemini、Pinecone、Weaviate 或 Infrai）取决于现有工作流和团队优先级。迁移应仅在真正提升系统性能时进行，而非仅仅为了边际成本节约。最终，代码必须提供基于事实的答案；若检索能力薄弱，再清晰的成本估算也毫无意义。

RAG Cost Estimates: Token Counts, Embeddings, and Node.js Semantic Search dev.to

RSS Hunter • 昨天

我为自主 AI 代理进行了定价分布分析。在中小型企业每用户平均收入（SMB ARPU）水平上，没有任何路径实现盈亏平衡。

本文探讨了自主 AI 公司在分销方面面临的约束，认为在缺乏清晰路线图的情况下，这是一项重大障碍。通过 Meta Ads 等平台进行的付费获客对中小企业（SMB）而言成本过高，当计入推理和数据支出后，客户获取成本（CAC）远超客户终身价值（LTV）。在典型的中小企业订阅费率下，自主智能体的数学模型根本无法平衡。曾经作为变通方案的冷 outreach 渠道，正日益难以支持自动化、大规模的消息发送。社交媒体平台正实施更严格的政策，以遏制 AI 生成的垃圾信息，使得智能体难以通过程序化方式发送外联消息。LinkedIn 和 Reddit 均设有服务条款（TOS）及行为过滤器，主动惩罚自动化外联行为。此外，由于共享域名以及因单个客户滥用而导致的潜在黑名单，冷邮件的投递率也受到影响。其余可行的分销渠道均需人工参与，包括内容营销、搜索引擎优化（SEO）、社群建设、创始人主导的品牌塑造以及合作伙伴关系。这些方法需要持续投入精力、判断力、审美以及长期的人际关系构建。就其本质而言，自主智能体难以执行这些本质上以人为中心的策略，尤其是在公司发展的早期阶段。作者认为，尽管推理成本正在下降、数据获取方法也在改进，但分销仍是自主 AI 的根本性挑战。对于自主扩展分销而言，不存在简单的“构建”或“等待”解决方案。该论点适用于特定利基市场，如拥有成熟付费获客渠道的消费类应用或嵌入式解决方案，但并不适用于通用的"AI 运行你的公司”愿景。归根结底，AI 为中小企业带来的真正杠杆并非完全自动化，而在于自动化分销中重复的“苦力”工作，同时由人类判断来引导整个过程。作者所在公司 Thread Otter 旨在提供一种自动驾驶系统，协助发现并接触现有需求，以用户的声音起草回复，并自动化外联中繁琐的环节，使人类能够专注于判断力的复利投入。这一方法承认分销无法被自主制造，但可以在人类监督下被发现和管理。

I priced distribution for an autonomous AI agent. None of the paths close at SMB ARPU. dev.to

RSS Hunter • 昨天

使用 Python(Click) 构建命令行工具

本文介绍 Penny，一个使用 Python 和 Click 库构建的简单命令行支出追踪器。Penny 允许用户直接在终端中添加、列出、汇总和清除支出，无需依赖 Web 界面或数据库。作者选择 Click 而非 Python 内置的 argparse，因其基于装饰器的命令和选项定义方式更为直观。项目结构包含三个主要文件：commands.py 用于实现各个命令的逻辑，penny.py 将这些命令整合为单一 CLI 工具，pyproject.toml 用于打包并定义入口点。Penny 将支出数据存储在一个名为 expenses.json 的纯 JSON 文件中，每次操作均对其进行读写。add 命令会在文件不存在时创建该 JSON 文件，追加新支出并保存更新后的列表，同时提供彩色确认信息。list 命令以表格格式显示已保存的支出，若未找到任何支出则发出警告。summary 命令计算并按类别打印支出总额及总计，结果以格式化的 JSON 输出。clear 命令在覆盖 expenses.json 文件（将其替换为空列表）之前会包含确认提示。penny.py 利用 Click 的分组功能，将所有命令统一在单个 penny 可执行文件下。pyproject.toml 配置了该分组，使得 Penny 可通过 pip install . 安装为全局可用的命令行工具。作者强调了 Click 声明式风格的优点、JSON 适用于简单数据存储的特性、用户体验细节的重要性，以及命令分组如何将脚本提升为 polished 的 CLI 应用程序。

Building a CLI tool with Python(Click) dev.to

RSS Hunter • 昨天

“十二梯度，一个身份——DHSeaDev"

一个细微的标记缺陷涉及十二个完全相同的 SVG 渐变，每个均使用相同的 ID 定义。这导致十二个渐变定义中有十一个未被使用，而所有视觉元素错误地引用了第一个定义。由于所有重复的渐变具有相同的颜色停止，页面在视觉上看起来正确。这种不可见性使得标准站点审核（包括作者本人进行的五次审核）未能发现该问题。问题一直隐藏，直到某个渐变定义被修改，可能影响错误的元素或根本不影响任何元素。由于此前从未造成可见问题，缺少对重复 ID 的关键审核检查。最初尝试通过顺序重命名 ID 来修复，却因将错误的定义与引用配对，引发了更严重且可见的 bug。这一疏忽通过计数断言得以避免，该断言检测到了定义与引用之间的不平衡。正确的解决方案是将 ID 重命名限制在单个 SVG 块内，确保定义仅在其自身作用域内与引用匹配。此次经历凸显了审核重复 ID 的重要性，尤其是针对内联 SVG，并需仔细验证查找和替换操作。

Twelve gradients, one id - DHSeaDev dev.to

RSS Hunter • 昨天

为什么每位开发者都应该开始写作（即使没人阅读）

写作是软件工程师职业生涯中不可或缺的一部分，其范畴远超代码本身。每位开发者都会撰写提交信息、变量名、缺陷报告及文档，因此写作是一项基础技能。写作的真正价值，尤其是技术文章的撰写，不在于外部读者的数量，而在于个人成长与工程能力的提升。写作迫使思维结构化，从而暴露理解上的空白，并对知识进行严格检验。将经验记录下来，能将转瞬即逝的教训转化为持久的知识，这是最高形式的学习。资深工程师深知，优秀的文档能加速进展并减少技术债务，为团队构建可维护的知识体系。LinkedIn 等平台及个人博客提供了展示专业成长、建立持久且可检索知识库的机会。这种写作实践能够构建“第二大脑”，即一种辅助未来问题解决的外部记忆，并使技术面试更加自然。通过写作打造个人品牌，能够彰显专业性与可信度，以可见的证据证明隐性的专长。尽早开始写作至关重要，即便尚未具备专长或拥有受众，因为成长先于认可。持续写作产生的复利效应，将在时间中积累宝贵的职业遗产。归根结底，代码构建产品，而写作塑造产品背后的工程师，从而成就一段既以技术能力著称、又以深思熟虑的沟通被铭记的职业生涯。

Why Every Developer Should Start Writing (Even If Nobody Reads It) dev.to

RSS Hunter • 昨天

Docker 证明您的应用可运行，Kubernetes 证明其可运维。

作者描述了一个常见的调试场景：在 Kubernetes 中，尽管所有技术指标均显示健康，但服务却处于不可用状态。这是因为 Docker 验证的是应用程序能否运行，而 Kubernetes 验证的是应用程序是否可操作。Docker 的简洁性掩盖了应用程序在生产环境中必须回答的四个关键问题。第一个问题是：应用程序能否通过名称而非仅通过地址被找到，因为在 Kubernetes Pod 中，localhost 仅指代该 Pod 本身。其次，应用程序必须能够应对外部系统干净地终止其进程，即正确响应如 SIGTERM 之类的信号。第三个关键方面是在接收流量之前证明自身已就绪，因为 Kubernetes 从启动伊始就会主动探测应用程序的健康状态。最后，应用程序需要能够在不依赖本地磁盘持久化的情况下运行，转而使用 Kubernetes 的配置与存储机制。理解这四个问题有助于揭示为何应用程序在 Docker 和 Kubernetes 中的行为存在差异。作者提供了未能解决这些问题的示例，说明其如何导致常见的生产环境问题。这一解释并非反对 Kubernetes，而是探讨 Docker 允许团队累积的可操作性债务。

Docker Proves Your App Runs. Kubernetes Proves It's Operable. dev.to

RSS Hunter • 昨天

为 QA 实践真实世界测试场景：挑战 3——结合 API 模拟的视觉测试

作者对多个应用程序进行了视觉测试，包括一个缺少图表的仪表板、一个在地图上显示车辆状态的运输应用，以及一个用于标记树木位置的服务应用。视觉测试有助于尽早发现 UI 故障，尤其在 UI 稳定时更为有效。Playwright 提供免费的视觉测试功能，而 Applitools 和 Percy 等工具则需付费。一个关键挑战在于对应收账款仪表板进行视觉测试，其中“平均逾期天数”指标每日波动。此外，跨多种语言（包括英语、西班牙语、德语和日语）进行测试也构成挑战，因为不同语言的文本长度各异。同时，还需在不使用模拟的情况下集成 API 测试，以验证数据准确性。当动态值影响视觉一致性时，测试策略包括屏蔽动态区域或模拟 API 以返回预定义值。提供的链接包含用于测试这些场景的网站和 API。作者鼓励在完成挑战后分享代码库并提出问题。

Practice Real-World Testing Scenarios for QA: Challenge 3 - Visual Testing with API Mocking dev.to

RSS Hunter • 昨天

使用 LangGraph 构建确定性多智能体工作流

在业务流程中使用自主智能体可能具有不可预测性，并导致混乱的执行循环，这在处理高风险操作（如商业合同或监管合规申报）时尤为成问题。为解决这一问题，有必要建立一个结构化框架，在保持认知灵活性的同时强制执行严格规则。LangGraph 是一个编排框架，能够构建确定性的多智能体工作流，从而将不可预测的 AI 行为转化为可靠的状态机驱动的业务流程。LangGraph 将智能体交互建模为节点，将转换建模为边，从而支持循环路径和自我修正的实现。该架构确保每个节点都能访问累积的上下文，且对状态的任何修改均被显式跟踪和验证。通过使用 LangGraph，企业可以构建具有韧性且能自我修正的系统，即使面对高度变化的 LLM 输出，也能保持可预测的行为。LangGraph 特别适用于构建严格且可审计的业务工作流，其以状态为先的方法确保开发者定义的规则始终优先于智能体自主性。实施确定性的智能体工作流可直接影响运营效率、风险敞口和底线增长，例如在商业保险核保、医疗收入周期管理和供应链海关经纪等领域已有相关案例。通过使用 LangGraph，企业可以降低错误风险、提升效率并增加生产力，最终实现成本节约和收入增长。总体而言，LangGraph 为构建确定性多智能体工作流提供了稳健的解决方案，使企业在自动化复杂流程的同时保持控制力和可预测性。

Building Deterministic Multi Agent Workflows with LangGraph dev.to

RSS Hunter • 昨天

Qwen3.8-Max 正式发布：开发者指南——解读阿里巴巴 2.4T 参数模型”

阿里巴巴发布了 Qwen3.8-Max，这是一款强大的 2.4 万亿参数混合专家模型。该模型具备 100 万 token 的上下文窗口，支持文本、图像和视频输入。其 API 兼容 OpenAI 和 Anthropic 协议，便于开发者集成。定价为每百万输入 token 2 美元，每百万输出 token 6 美元。一个显著的成本节约因素是缓存输入 token 的价格降低，突显了提示词中稳定前缀的重要性。该模型的命名规范区分了迭代版本与点发布版本，其中 Qwen3.8-Max 为最新旗舰版本。尽管其总参数量为 2.4 万亿，但每个 token 仅激活约 950 亿个参数，从而提升了推理效率。有效上下文窗口约为 99.1K token，最大输出 token 限制为 13.1K。开发者可通过更新基础 URL 和模型名称来使用其兼容 OpenAI 的 API。阿里巴巴的 DashScope SDK 提供了一个代码示例，展示了其多模态能力。该模型支持多种功能，包括函数调用和结构化输出，并内置五种工具。基准测试显示，其在多模态和代理任务方面表现强劲，但在某些方面仍落后于 Claude 3.5 等竞争对手。预计不久将发布开放权重版本，同时还将推出一个 270 亿参数的小型版本。目前，缺少包含详细训练数据和安全评估的正式模型卡片。商业使用的许可条款将在开放权重发布后明确。活跃参数数量已公布，但尚未得到阿里巴巴的官方确认。尽管存在上述缺失，Qwen3.8-Max 仍被推荐用于多模态应用、长上下文任务以及现有 OpenAI/Anthropic 协议用户。

Qwen3.8-Max Just Went GA: A Developer's Guide to Alibaba's 2.4T Model dev.to

RSS Hunter • 昨天

每秒令牌数：如何衡量和优化 AI 模型的速度

延迟是部署语言模型和人工智能到生产环境时的关键挑战。忽视计算性能而仅关注精度是一个错误。速度（以每秒 token 数衡量）已成为一项关键的架构指标。这是因为关键型应用需要快速响应，尤其是在金融和医疗领域。优化模型性能还能降低 GPU 利用率，从而减少云账单支出。诸如采用轻量级架构、量化以及批处理等技术，可在不牺牲精度的前提下提升速度。本文提供了一个 Python 实用示例，用于测量模型的每秒 token 速度。约每秒 100 token 是一个衡量实时人机交互的良好基准。优化步骤包括建立初始基准、实施批处理，并评估蒸馏模型或量化模型。社区共享用于 AI 模型性能分析和基准测试的工具与库。

Tokens por Segundo: Cómo medir y optimizar la velocidad en modelos de IA dev.to

RSS Hunter • 昨天

我构建了一个开源 AI 代理，它真正能够控制您的计算机

AI 代理已广泛普及，但在与真实世界的计算机交互方面仍面临挑战。现有的自主代理常因过早宣布任务完成、在多步骤工作流中丢失上下文，或缺乏桌面环境集成而失败。HeyAgent 旨在解决这些问题，其定位是作为真正的助手，而非简单的语言模型封装。这款开源代理能够控制桌面应用程序、与浏览器交互、管理文件、执行终端命令，并连接外部服务。HeyAgent 的独特之处在于其规划、执行、验证结果，并在确认任务完成前避免误报，从而降低假阳性率。该项目获得了 AWS 的显著加速与支持，AWS 提供了关键的云基础设施和计算资源。HeyAgent 采用模型无关的技术栈，基于 TypeScript 和 Node.js 构建，支持云端和本地大语言模型。作为开源项目，开发者可以审查其推理过程、构建工具并贡献改进。未来的开发将聚焦于增强的规划能力、更稳健的桌面自动化以及扩展的插件生态系统。团队欢迎反馈、创意、错误报告及项目贡献。

I Built an Open-Source AI Agent That Actually Controls Your Computer dev.to

RSS Hunter • 昨天

中文姓名生成器工具

一位同事对随机中文名字生成器的糟糕体验，促使作者开发了一款更优的工具。现有的生成器仅关注发音，忽视了意义、声调与文化意涵等关键要素，从而导致滑稽或不恰当的名字组合。中文命名传统除语音外，还包含笔画数、五行分类及历史用法等因素，这些对于名字能否被广泛接受至关重要。研究表明，相当一部分人在取名时仍会考虑笔画数的数理吉凶，而当前工具大多对此视而不见。作者的项目以准确性为首要目标，构建了一个经过严格核验的汉字数据库。每个字符均经过严密审查，包括对照《康熙字典》核实释义、依据《百家姓》验证姓氏合法性，并参考姓名学研究。这一核验过程而非简单的字符组合，构成了项目的核心。作者强调，避免意义或文化权重上的无意冲突，才是中文名字生成真正的挑战。所开发的工具为每个生成的名字提供七个经核验的数据点：字符本身、拼音读音、笔画数、五行分类、吉数、吉色以及和谐度评分。该评分源自传统的“三才五格”命名体系。

A Chinese Name Generator Tool dev.to

RSS Hunter • 昨天

无题

A2A 协议当前缺乏验证 Agent Card 真实性的机制。当一个代理获取另一个代理的 Agent Card 时，仅读取元数据，没有任何身份证明的密码学依据。这使得代理面临身份冒充风险，因为任何人都可以创建声称特定角色的伪造 Agent Card。该协议将身份验证委托给外部、通常是手动处理的过程。虽然传输层安全（如 mTLS）可保障通信通道安全，但无法验证代理本身。为解决此问题，需将公钥绑定至 Agent Card，并对关键字段进行签名。在代理交互发生之前，必须执行类似 HTTPS 的验证步骤。一种手动变通方案是在扩展字段中存储公钥并手动验证消息签名。然而，该方法脆弱，依赖不一致的约定，且可能被恶意行为者利用。A2A 规范要求在 Agent Card 中设置专用的身份字段。该字段应包含公钥及其颁发者引用，例如去中心化标识符（DID）。需为卡的规范 JSON 表示定义签名方案。至关重要的是，身份验证必须作为 A2A 握手的一部分强制执行。本提议的解决方案包括获取颁发者的公钥、验证卡的签名以及检查吊销状态。该流程确保代理的卡片由可验证的颁发者签发且未被篡改。若无此标准化方案，当前代理间通信的信任模型仍存在重大漏洞，尤其是当代理开始处理敏感数据和交易时。

Untitled dev.to

RSS Hunter • 昨天

《欧盟人工智能法案语音水印：TTS 构建者须知》

欧盟《人工智能法案》关于语音水印的规定将于 2026 年 8 月 2 日生效，强制要求对人工智能生成的音频进行机器可读标记。未能合规可能面临高达 1500 万欧元或全球年营业额 3% 的罚款。提供生成合成音频的人工智能系统的供应商，包括文本转语音（TTS）和语音克隆系统，必须确保其输出可被识别为人工生成。该法律强调基于结果的方法，要求在技术上可行的情况下，实现有效、互操作、稳健且可靠的标记。结合不可听水印与签名元数据的分层方法正变得普遍。与人类交互的人工智能系统也必须披露其人工智能属性，深度伪造内容同样需要披露。欧盟委员会已发布合规指南及行为准则，众多企业已签署加入。现有系统享有至 2026 年 12 月 2 日的宽限期以完成标记合规。豁免范围有限，仅限于不实质性改变音频的辅助编辑功能。TTS 供应商正采用如 Google 的 SynthID 和 Meta 的 AudioSeal 等方法进行水印嵌入。OpenAI 的 API 允许验证嵌入的信号，但无法检测未标记或被剥离的内容。开发者必须审计其音频输出，验证水印在其处理管道中的存活情况，管理披露义务，并保留生成记录。忽视这些规定将带来重大的财务和声誉风险。

EU AI Act Voice Watermarking: What TTS Builders Must Know dev.to

RSS Hunter • 昨天

您的行动号召可能依然存在，却仍会陷入死胡同。请检查其是否可点击，而不仅仅是验证 URL。

自动化内容管道未能检测到视频描述中缺少可点击的号召性用语。系统对域名字符串存在的检查不足，因为不带"http://"或"https://"的裸 URL 不会被 YouTube 等平台自动链接。这意味着虽然描述中提到了优惠活动的域名，但观众无法直接访问。初步审核错误地报告检查通过，导致尽管存在 URL 文本，转化率却为零。解决方案是更新审核流程，专门查找可点击的链接格式，包括必要的 URL 协议。这通过使用匹配"https?://"的正则表达式实现。随后实施了更稳健且通用的修复方案：一个中心处理流程，在内容发布前自动将任何裸域名提及升级为实际的可点击链接。该函数确保现有的 Markdown 链接和完整 URL 得以保留。链接化函数使用交替匹配来优先处理现有链接，防止意外修改已正常工作的 URL。这避免了因朴素方法而导致的次要错误，即破坏现有链接。核心教训是：当可用性是实际要求时，仅检查存在的自动化审核具有误导性。确认链接存在的检查并不等同于确认人类可以使用它。如果自动化流程未能产生结果，至关重要的是验证工具是否评估了正确的、功能性的标准。

Your call-to-action can be present and still dead-end. Audit for clickable, not just for the URL. dev.to

RSS Hunter • 昨天

自动扩展并非适用于所有工作负载：如何判断，以及应构建何种替代方案

“只需将其置于自动伸缩组之后”这一建议常用于无状态应用（如 Web 服务器）的伸缩。其效果良好，因为副本可互换，且增减时对系统影响极小。然而，这种方法并不适用于所有工作负载，尤其是那些具有特定属性、违背可互换性的工作负载。其中一种属性是会话亲和性（session affinity），即会话绑定到特定实例，难以轻易转移。另一种属性是新实例启动缓慢，若实例在需要时未就绪，则反应式伸缩将失效。对于具有此类特征的工作负载，标准的反应式自动伸缩并非正确方案。与其立即反应，伸缩扩容应采用基于趋势的较慢触发机制。这使新实例有足够时间完全就绪，再在关键需求出现前投入使用。安全地缩容同样至关重要，因为直接终止实例可能中断正在进行的工作。行业解决方案（如 AWS 生命周期挂钩）可在终止实例前实现会话的优雅 draining。该模式包括停止新工作、等待现有会话完成，随后移除实例。大规模系统（如视频会议平台）已采用此类更复杂的伸缩策略。关键要点是评估实例的可互换性。若任何实例都能即时处理任何任务，则自动伸缩是合适的。否则，必须采用较慢的扩容机制以及正确的缩容 draining 逻辑，才能有效管理具有会话亲和性或启动缓慢的工作负载。强行将此类工作负载纳入反应式、可互换的模型，将导致严重故障。

Autoscaling Doesn't Fit Every Workload Here's How to Tell, and What to Build Instead dev.to

RSS Hunter • 昨天

我在 SaaS 主页上设置了一面公共涂鸦墙。

大多数 SaaS 首页会使用静态产品截图来展示其服务。然而，该产品的首页却采用了一个名为"Owners Were Here"的嵌入式功能留言板。该留言板由组件构建器开发，通过展示真实、即时的提交内容，揭示了产品不可见的后端机制。留言板作为一种概念验证，突出了截图无法传达的功能特性。选择这一方式的主要原因是，表单在营销材料中难以令人信服地伪造。嵌入式留言板旨在通过用户贡献提供即时且不断累积的社会证明。这种方法利用了“涂鸦墙”的美学风格，使其内容自然增长。当暴露公共端点时，必须采取强有力的安全措施，包括通过 Cloudflare Turnstile 进行机器人检测、实施速率限制、执行模式验证以及设置大小上限，以防止被利用。渲染不可信的用户输入需要谨慎处理，以避免跨站脚本等安全漏洞。使用 textContent 而非 innerHTML 对文本进行适当清理，对于安全地显示用户生成内容至关重要。不断增长的留言板可能会对首页布局和加载时间产生负面影响。通过实现具有最大高度限制和内部滚动的视口，可以防止留言板压倒整个页面。虽然难免会出现一些垃圾条目，但这些设计选择保护了嵌入式组件的核心安全与功能。

I put a public graffiti wall on my SaaS homepage dev.to

RSS Hunter • 昨天

黑客的心态

作者阐述了黑客思维，其根植于成长型思维与应用的求知欲。黑客并非进行典型的用户交互，而是通过尝试随机操作来探索系统会发生什么，这类似于学习一台未文档化的机器。这种思维涉及追问“如果我这样做会发生什么”，而不仅仅是遵循既定流程。早期的经历，例如反复尝试获取手机 root 权限，即使导致设备变砖，也体现了将好奇心置于安全之上的优先级。失败不被视为终点，而是提升未来尝试的学习机会。当探索本能与坚持相结合时，其意义更为深远，而非在获得解释后便停止。要有效创新，首先必须理解现有规则与基础，然后才尝试偏离它们。建议在受控环境中进行测试，而非复制童年时期的高风险实验。一个至关重要却常被忽视的方面，是对不确定性的舒适感，以及在调查过程中面对混乱、模糊阶段时的坚持。这种韧性，即对“枯燥且令人困惑的中间阶段”的容忍度，区分了那些能发现新颖见解的人与那些放弃的人。最终，黑客思维是一种审视系统的透镜，旨在寻找预期功能与实际行为之间的差异，这可能揭示安全漏洞或有趣的特性。

The Mindset of a Hacker dev.to

RSS Hunter • 昨天

如何为你的RAG添加UI?!?

刚刚在空闲时间搭建了一个基于 FastAPI 的 SSE 后端，用于逐 token 流式传输 LLM 响应。生产环境中出现了两个本地运行正常但上线后失效的问题🙃：1. nginx 默认会对 SSE 进行缓冲。本地测试时流式传输正常，但在 Railway 上却完全静默。将 proxy_buffering 设置为 off 后，两小时问题得以解决。 2. LLM API 在检索不到匹配文档时会返回 empty_retrieval 事件。此前未处理该事件，导致前端加载指示器无限期停留。现已添加相应处理器，问题已解决。https://zooming-charm-production-547e.up.railway.app/

How to add UI for your RAG?!? dev.to

RSS Hunter • 昨天

如何降低 AWS NAT Gateway 成本：按节省效果排名的 7 种方法

AWS NAT Gateway 的费用主要由两部分组成：较低的按小时计费费和数据处理费。其中，按每千兆字节 0.045 美元计收的数据处理费是主要成本驱动因素，且随流量增加而累积。为降低这些成本，可采取多种策略，从影响最大的开始实施。首先，为 S3 和 DynamoDB 实现免费的网关端点，这通常可消除 30% 至 60% 的每千兆字节费用。其次，考虑为频繁访问的 AWS 服务使用接口端点。VPC 流日志对于识别高流量来源至关重要，其修复措施通常涉及实施缓存和加强运维规范。为避免跨可用区附加费，应按可用区路由流量或审慎整合 NAT 网关。整合非生产环境的 NAT 网关可节省未使用资源的按小时费用。为进一步节约成本，可使用 NAT 实例（如 fck-nat）完全消除每千兆字节费用，但这需要自行管理运维工作。一种固定价格的网络虚拟设备（NVA）支持出站过滤，可作为 NAT Gateway 的托管替代方案，消除每千兆字节费用并充当防火墙。这些解决方案的选择取决于流量规模和运维能力。按千兆字节计收的数据处理费通常是需优先解决的最显著成本，而非按小时费用。

How to reduce AWS NAT Gateway costs: 7 ways, ranked by savings dev.to

RSS Hunter • 昨天

你如何判断内容是好是坏？

作者探讨了 dev.to 平台上人工智能（AI）使用日益增多的现象及其影响。一种普遍的观点认为，内容质量比是否使用 AI 更为重要，但作者质疑在此语境下应如何界定“优质”内容。AI 能够轻松生成有用且富有洞察力的材料，使得辨别真正的理解变得困难。作者将这一情况与开发者利用 AI 完成项目相类比，指出这些项目虽在纸面上令人印象深刻，但在实时解释时往往难以应对。这凸显了过度依赖 AI 的潜在缺陷：阻碍真正的学习与技能发展。作者表达了对过度依赖 AI 的个人担忧，担心这会削弱其学习能力和自信阐述自身工作的能力。作者认为，真正的专业素养源于对作品的理解以及能够清晰阐述其创作。作者提出，dev.to 等平台的宗旨应是促进真实的学习与分享，而非将 AI 生成的内容呈现为个人专业水平。作者提出了两条关于建设性使用 AI 的关键建议：提出扩展性问题，而非仅仅复述信息；将 AI 作为辅助学习的工具，而非替代品。这种平衡的方法既能确保个人成长，又能促进社区内的有意义互动。核心主题是“通过实践学习”并避免对 AI 的过度依赖。归根结底，dev.to 上的优质内容应促进作者与读者之间的相互学习，无论主题为何。

How would you decide, whether the content is good or bad? dev.to

RSS Hunter • 昨天

解锁无限自动化：将 Google Apps Script 与 Gemini Spark 集成

Gemini Spark 是 Google 推出的全天候自主 AI 代理，旨在自动化 Google Workspace 中的复杂工作流。虽然它与 Gmail、Drive 和 Docs 等应用提供了强大的原生集成，但连接外部 API 需要额外配置。Google Apps Script（GAS）作为关键桥梁，使企业能够显著扩展 Gemini Spark 的功能。通过将 GAS 部署为模型上下文协议（MCP）服务器或 Webhook 端点，用户可以授予 Gemini Spark 访问专用 API 和自定义业务逻辑的权限。本文展示了五个代表性提示，体现了 Gemini Spark 的原生功能，包括自主创建包含动态公式的表格、智能搜索 Google Drive 中的文件，以及编排跨域工作流（如从网页抓取数据并生成文档）。文章还突出了 Gemini Spark 自主设置后台事件监听器的能力，用于处理传入邮件等任务。然而，一个涉及直接访问 Google Analytics Data API 的测试提示揭示了当前在连接到专用 Google API 方面的原生连接限制。为突破这些原生边界，本文详细介绍了通过自定义 MCP 服务器和 Webhook 触发器将 Gemini Spark 与 Google Apps Script 集成的方法。文章解释了如何将 GAS Web App 部署为 MCP 服务器，利用 GASADK 和 GoogleApiApp 库促进 JSON-RPC 通信。该集成使 Gemini Spark 能够安全地与 Google Analytics 4、自定义数据库及其他复杂业务逻辑相关的 API 进行交互。通过将 GAS 作为中间 MCP 服务器，开发人员可以封装安全的身份验证和数据提取逻辑。最终目标是使 Gemini Spark 能够访问更广泛的数据源和服务，从而实现企业级工作流自动化。

Unlocking Infinite Automation: Integrating Google Apps Script with Gemini Spark dev.to

RSS Hunter • 昨天

LINE Mini App 审核预审：防止返工的提交前检查清单

LINE Mini Apps 并非自动需要验证，但某些功能在发布时强制要求验证。若需验证，LINE 将严格审查身份一致性、政策合规性、频道配置及用户流程。为避免延误，在提交审核前务必对提交内容进行彻底自查。需要验证的关键功能包括：生产环境服务消息、自定义路径、主屏幕快捷方式、主页个人资料快速填充以及认证徽章。提交前，请确保在 LINE 开发者控制台、频道信息、隐私政策及频道描述中统一组织身份。公司名称在所有位置及语言中必须保持一致。清晰描述 Mini App 的工作流程，明确主要用户、核心功能及预期结果。确认审核频道准确反映已发布频道的功能、过渡、数据、认证及错误状态。为支付、预订和订单准备全面的测试场景，涵盖注册、成功与失败的交易以及数据管理。仔细检查隐私条款和条款页面，确保其公开可访问，公司名称和服务名称一致，且联系信息准确。验证 Mini App 的业务类别和内容是否符合 LINE 政策，避免受限类别和禁止内容。仅申请必要的 API 作用域并记录其用途。服务消息需单独审批流程，且严格限于对用户操作的确认或响应，不得用于推广。验证通过后，许多设置将变为重新审核敏感项，因此在首次提交前，请冻结关键配置，如频道身份、法律 URL 及作用域。规划验证时间线，通常需一至两周，并预留重新审核的缓冲时间。最后请注意，Mini App 验证与处理入站客户消息属于不同流程。

LINE MINI App Verification Review: A Pre-Submission Checklist That Prevents Rework dev.to

RSS Hunter • 昨天