Code Buddy是腾讯推出的 AI 编程助手,提供 IDE 拓展和独立 IDE。最近腾讯又推出了命令行工具Code Buddy Code,类似 Claude Code 和 Gemini CLI。我简单体验了一下,开发了一个网页版的Mermaid 编辑器,总体体验比阿里推出的 Qwen Code 要好一点(可能是因为 Code Buddy Code 的海外版默认使用的 Claude 4 模型比 Qwen3 Coder 还是要强上一线)。
【译】TypeScript转向Go:为何这是务实之选
【由DeepSeek辅助翻译】
原文链接:https://blog.logrocket.com/typescript-go-pragmatic-choice/
发布时间:2025年4月16日 14:51:38(UTC时间)
关于这次移植的技术细节已有大量报道,本文不再赘述。这里呈现的是TypeScript社区两位成员的思考:
- John Reilly是软件工程师,TypeScript早期采用者。他参与维护Definitely Typed——这个高质量类型定义库实现了TypeScript与JavaScript的集成。John撰写了Definitely Typed发展史,并出现在TypeScript纪录片中。他还开发维护了
ts-loader这个webpack的TypeScript加载器。目前他在南非Investec银行伦敦分部工作。在他看来,伦敦是地球上最伟大的城市 - Ashley Claymore是软件工程师,居住地距John不远,常与他晨间散步讨论TypeScript。他从TypeScript 1.8版本开始使用,深度参与了语言演进。曾为TypeScript贡献代码,现就职于彭博社JavaScript基础设施与工具团队。文中观点仅代表个人
本文将自由呈现我们的反应与期待。准备好迎接观点、思考和感受的碰撞吧。
移植是否必要?
难道之前不够好吗?是,但也不尽然。
近年来JavaScript/TypeScript生态中,越来越多支持JS开发的工具改用其他语言编写:esbuild(Go)、SWC(Rust)、Bun(Zig)、Deno(Rust)。这些工具都带来了显著的性能提升,而TypeScript始终用自身编写。虽然团队持续优化性能,但改进始终是渐进式的。
社区开始涌现自行实现TypeScript加速的尝试。最著名的是SWC作者DongYoon Kang,他先实现了TypeScript转译功能,又尝试构建类型检查器——最初用Rust,后改用Go,最终回归Rust。虽然项目未成功,但这些尝试印证了市场对性能的强烈需求。移植已成必然——若非官方出手,整个生态将陷入困境。而现在,我们迎来了Go版的TypeScript。
性能变革
Go移植对TypeScript意味着什么?根据Josh Goldberg的框架,TypeScript包含四个维度:
- 语言规范
- 类型检查器
- 编译器
- 语言服务
语言规范不受移植影响,语法保持不变。您仍可照常使用type和interface。类型检查规则也维持原样,原有错误提示依然有效:
const i: number = "非数字值";
// ts报错:类型'string'不能赋值给类型'number'
真正的变化始于类型检查器、编译器和语言服务——它们将获得数量级的提速。
谁不关心性能?显然没人。当工具卡顿打断工作流时,这种体验令人难以忽视。TypeScript团队始终重视性能,特别是开发工具响应速度。联合创始人Anders Hejlsberg多次强调语言服务器必须提供毫秒级反馈。
这将如何影响生态?简而言之:更快的VS Code和构建流程。
以John所在的Investec银行为例,众多使用VS Code的工程师将获得更流畅的开发体验:项目加载时语言服务启动更快、重构响应更迅捷、”红色波浪线”出现更及时。构建过程同样受益——无论是本地还是持续集成环境,TypeScript编译都将显著加速。这种提升将惠及全球所有TypeScript开发者。
Python PEP 750 解读:模板字符串开启安全灵活的字符串处理新时代
【本文由DeepSeek R1辅助编写完成】
PEP750
引言
在 Python 的字符串处理领域,f-strings 自推出以来因其简洁高效广受开发者喜爱。但 f-strings 的即时求值特性在某些场景下显得力不从心,特别是在需要预处理的场景(如安全转义、结构化日志记录)中。PEP 750 提出的**模板字符串(Template Strings)**通过引入 t 前缀和延迟处理机制,为这一难题提供了优雅的解决方案。本文将深入解析这一提案的核心思想,并通过实际案例展示其强大能力。
一、模板字符串的核心特性
1.1 语法与基本使用
模板字符串使用 t 前缀定义,语法与 f-strings 完全兼容:
1 | from string.templatelib import Template |
与 f-strings 不同,模板字符串不会直接求值为字符串,而是生成 Template 对象,包含静态字符串片段和插值表达式信息。
1.2 Template 对象结构
1 | class Template: |
1.3 Interpolation 对象
每个插值表达式对应一个 Interpolation 实例:
1 | class Interpolation: |
二、应用场景解析
2.1 安全内容生成
传统 f-strings 在生成 HTML 时容易引发 XSS 漏洞:
1 | user_input = "<script>alert('XSS')</script>" |
模板字符串解决方案:
1 | def safe_html(template: Template) -> str: |
2.2 结构化日志记录
传统日志记录丢失结构化数据:
1 | logger.info(f"User {username} logged in") # 无法提取 username 值 |
模板字符串解决方案:
1 | class StructuredMessage: |
MCP Run Python:安全的 Python 代码沙盒执行环境
【由DeepSeek辅助编写】
MCP Run Python 是由 PydanticAI 提供的 MCP 服务器,能够在安全、隔离的沙盒环境中执行 Python 代码。它基于 Pyodide 和 Deno 技术栈,通过 WebAssembly 实现代码隔离,确保主机系统不受执行代码的影响。
【2025-04-07】Github Copilot❤️MCP
GitHub Copilot 推出 Agent 模式,支持 MCP。
Introducing GitHub Copilot agent mode (preview)
Llama 4发布,但社区评价不是很高
[Llama 4]https://www.llama.com/docs/model-cards-and-prompt-formats/llama4_omni/)
Llama 4发布36小时差评如潮!匿名员工爆料拒绝署名技术报告
midjourney v7 发布
我是如何在日常工作生活中使用AI的
【本文由 DeepSeek 辅助完成】
在日常工作生活中,AI 已经成为我的得力助手。经过长期实践,我总结出一套高效使用 AI 的方法论,现在分享给大家。
开发场景的 AI 应用
对于开发者来说,AI 工具能显著提升工作效率。在遇到技术问题时,我会优先使用 Github Copilot Chat 这类专业工具来咨询问题,比如复杂的 SQL 查询语句或不熟悉的库的使用方法。相比通用聊天助手,这类针对开发场景优化的工具给出的建议更加精准。
代码补全方面,GitHub Copilot 是我的主力工具。我习惯将它的智能补全与 IDE 传统提示相结合,形成”AI+传统”的混合工作流,这样既能获得 AI 的创新建议,又能确保代码规范性。
当需要进行项目级别的修改时,比如实现新需求或重构代码,我会根据情况选择不同的工具。在 IDE 内进行多文件编辑时使用 Github Copilot Edit 功能,如果是在网页端修改 Github 项目,则会考虑是用 Copilot Workspace(示例 PR)。
通用场景的 AI 助手
处理日常信息时,我主要使用腾讯元宝和 Deepseek 这两个工具。腾讯元宝的特色在于可以检索公众号资源,并且支持在混元和 DeepSeek 模型间切换。需要注意的是,国内 AI 助手有时无法直接解析海外链接内容,这时我会先用 Jina AI Reader 将页面转为 Markdown 格式再处理。
内容创作方面,我采取多工具协同策略。通常会让腾讯元宝、ChatGPT 和 DeepSeek 分别生成内容,然后综合各家之长。这种”集思广益”的方式往往能产生更优质的内容。
垂直领域的专业工具
不同专业领域都有对应的 AI 工具利器:
- 翻译工作首选 DeepL,它在专业术语处理上表现突出
- 图片生成推荐即梦,支持对单张图片进行迭代编辑
- 办公场景下腾讯文档 AI 助手的思维导图和 PPT 生成功能很实用
- 浏览器插件 Monica 可以即时分析网页内容
- 需要制作手绘风格图表时,Excalidraw AI 是不二之选
- 将网页转为 Markdown 文档,Jina AI Reader 能完美保留原始排版结构
Model Context Protocol (MCP)与 AI 工具集成实践
使用 Deno 2.2 原生 OpenTelemetry 支持构建可观测的微服务
Deno 2.2 版本引入了原生的 OpenTelemetry 支持,使得在 Deno 应用中集成分布式追踪变得异常简单。本文将介绍如何使用 Deno 2.2 和 Hono 框架构建一个简单的微服务系统,并通过 OpenTelemetry 实现服务的可观测性。
项目概述
我们构建了一个包含两个服务的简单系统:
- API 网关服务 (
gateway.ts):负责接收客户端请求,并将其路由到相应的服务。 - 天气服务 (
weather.ts):提供天气信息查询功能。
此外,我们还实现了一个中间件 (TraceRoute.ts) 和一个模拟的第三方 API 调用 (thirdApi.ts),用于演示如何在服务中进行追踪。
代码实现
API 网关服务 (gateway.ts)
1 | import { Hono } from "@hono/hono"; |
天气服务 (weather.ts)
1 | import { Hono } from "@hono/hono"; |
【译】UV 的一年:优缺点以及你是否应该迁移
(由 DeepSeek 辅助翻译)
(警告,这是一篇长文。我有点写嗨了。)
经过一年时间,在许多客户项目中尝试使用 uv,这个由 Astral 推出的新 Python 项目管理工具,我看到了它的优点和不足。
我的结论是:如果你的情况允许,总是先尝试 uv。如果不行,再退回到其他工具。
它是帕累托解决方案,因为比起费劲去弄清楚该用什么工具,uv 更容易上手,而且你很少会后悔。实际上,迁移到 uv 和从 uv 迁移回来的成本都很低,但它带来的价值却相当高。
虽然这篇文章会深入探讨为什么如此,但我们也会专门讨论什么时候你不想使用 uv。
不过,这篇文章并不是关于如何使用 uv 的教程。后续会有一篇专门的文章。
尽管我对 uv 充满热情,但我坚持认为,在没有看到它在各种工作场景中的表现之前,我不能轻易推荐它。
这是因为 Python 社区庞大且多样化。有学生、数据科学家、AI 开发者、Web 开发者、系统管理员、生物学家、地理学家、插件作者……他们可能在大学、政府机构、初创公司、军队、实验室或大公司工作。
他们的技能水平、经验、环境和约束各不相同,而工具的普适性越强,我就越能推荐它。
这与 PHP、JS、Java 或 Ruby 的情况非常不同。相对来说,很少有人用 Java 开发 X-plane 插件,用 Ruby 编写 GIS 脚本,用 JS 编写银行定价引擎,或用 PHP 作为最新 LLM 模型的主包装。这些语言虽然也能做到,但我看到 Python 的应用范围更广。
因为我是一名自由职业开发者,同时也是一名培训师,我经常在这些领域游走,而且我见过其他工具在这些场景中惨败的情况。pyenv、poetry、pipenv、pdm、pyflow、pipx、anaconda……
事实上,我的博客之所以开始受欢迎,是因为一篇文章:为什么不告诉人们“简单”地使用 pyenv、poetry、pipx 或 anaconda
所以我不想给人们虚假的希望,推荐一些只在我的小圈子里有效的东西,不幸的是,大多数极客都会这么做。
现在,我已经看到了 uv 的使用方式和它可能遇到的问题,我不仅可以告诉你应该使用它,还可以告诉你为什么。
当然,我也会告诉你什么时候不要使用它。
我反复强调过,Python 的引导过程是所有问题的根源。所谓引导,指的是安装 Python 本身,以及配置一个新项目,以便后续安装依赖或构建包。你之后遇到的许多问题(例如打包问题)实际上都源于此。
这是因为:
- Python 有很多不同的安装方式,每种方式都有不同的默认设置和陷阱。而且这些还因操作系统而异。
- 光是安装 Python,就需要了解很多前置知识,而 Python 是一门特别适合初学者的语言,而初学者,顾名思义,并不具备这些知识。
- Python 的应用场景非常广泛,因此很难创建“一个教程适用所有情况”。在公司锁定的 Windows 机器上提供的 Python 体验,与在 Debian 爱好者笔记本电脑上的体验完全不同。
- 很少有人能给出关于这方面的好建议,但每个人和他们的猫都会以权威的语气谈论它。网上关于这方面的废话实在太多了。
- 有很多工具试图解决这个问题,因此我们现在面临着选择悖论。
PATH、PYTHONPATH、糟糕的命名约定、在同一台机器上安装多个 Python 版本、Linux 上的可选包,以及 Python 作为系统依赖项,这些都为你提供了无数种搬起石头砸自己脚的方式。-m和py在它们的使命中失败了。大多数人甚至不知道它们的存在。- 编译扩展的流行给这一切增加了不少乐趣。
- 人们会遇到直接与这些问题相关的问题,但完全不知道原因,因此他们会直接说“Python 打包太烂了”,因为他们会把问题归咎于他们正在使用的工具,而不是他们根本不知道的根源问题。
因此,一个好的 Python 项目管理工具应该具备以下特性:
- 独立于 Python 的引导过程,因此不会出现鸡生蛋蛋生鸡的问题,同时也能绕过
PATH和PYTHONPATH问题。 - 能够在所有平台和情况下以统一的方式安装和运行 Python。
- 在基础工具(
pip和venv)与自身之间提供桥梁。 - 拥有非常强大的依赖解析器。
- 让简单的事情变得简单(安装东西),让复杂的事情变得可能(在不同于开发环境的操作系统上安装锁定依赖)。
- 所有这些都要易于安装和使用,当然,还要足够可靠,让你放心地将它用于你技术栈中最重要的部分之一。
持久化 OpenAI API 流式响应的工程实践
(由DeepSeek R1辅助编写)
问题背景
挑战分析
在实现基于 OpenAI 流式 API 的对话系统时,面临两个核心挑战:
- 长时操作风险:openai接口生成长文本需要 10-30 秒,客户端网络波动可能导致连接中断
- 数据一致性要求:用户发送的消息与 AI 的完整响应必须保证原子性持久化
传统同步处理模式存在致命缺陷,在客户端连接中断时会导致消息丢失:
1 | sequenceDiagram |
架构设计
使用异步 Worker 执行实际请求并通过消息队列通信
方案描述
该方案通过异步任务和消息队列实现了 OpenAI API 流式响应的持久化和可靠传输。具体步骤如下:
- 客户端请求:客户端发送 POST 请求到 Web 服务器,创建对话任务。
- 异步任务:Web 服务器将任务委派给 异步 Worker,立即返回任务 ID 给客户端。
- 流式处理:Worker 向 OpenAI 发起流式请求,实时处理响应数据。
- 数据持久化:每个响应片段同时写入数据库和 Redis 消息队列,确保数据安全。
- 消息推送:Web 服务器通过 SSE 将消息队列中的数据推送给客户端,实现流式响应。
- 断连恢复:客户端可根据任务 ID 重新连接,获取未接收的历史消息。
该方案解决了长时操作风险和数据一致性问题,确保在客户端断连情况下数据不丢失,并支持断线重连和消息恢复。