为什么我不看好豆包手机

想象一下你拥有一台自带 AI 助手的手机，想让它帮你用微信发送最近拍摄的合同照片给张总。

若是像以豆包手机为典型的基于屏幕内容读取和模拟点击操作的 AI 手机，大概会按照以下步骤来操作：

1. 打开相册应用，使用 OCR 技术或多模态大语言模型分析每一张最近拍摄的照片，找到所需的合同照片。
2. 调用相册应用的分享功能，使用微信分享。
3. 在微信分享页面通过搜索好友昵称或翻看好友列表的方式，找到张总的账号，输入备注（“张总，这是上次的合同照片”之类）完成分享。

过程中可能会弹出多次授权请求，让用户同意 AI 打开并操作相册、微信等应用。当然不讲究的用户可能在首次配置 AI 手机的时候就永久授予了大部分常见应用的操作权限。

期间 AI 助手会分析识别手机相册中的近期照片（其中可能有家人近照，证件照等敏感照片），获取你的微信好友列表（以及经常互相分享的亲密联系人），给微信好友发消息。并且由于分析照片内容会消耗不少时间，总耗时可能也会长达一分钟以上。

简单来说，这些行为是对隐私和信息安全的极大侵犯，而且并未明显为用户节省时间。

侵犯隐私，安全隐患，效率低下，这就是我对目前讨论火热的豆包手机的看法。

问题的根源在于，若 AI 助手依赖通过读取屏幕内容的方式获取上下文信息，不可避免地需要频繁通过 AI 模型分析手机屏幕上的所有元素。

手机屏幕上往往不只是 AI 助手当前任务需要的信息。比如在上文提的示例中，AI 助手会读取多张图片的内容，直到它找到了合同的照片。并且 AI 助手在微信分享的联系人列表中找到张总之前，可能已经读取了用户大部分的联系人微信昵称和头像，毕竟按拼音排序张总大概率在列表的很后面的位置。同理，在让 AI 帮你在淘宝购买商品的场景下，AI 会获取你的首页推荐商品列表，最近订单，收货地址等隐私信息。即使用的是不联网的端侧模型，我也对 AI 手机们能否妥善处理这些隐私信息持怀疑态度。

当前 AI 模型识别图片需要的时间明显要长于人类，对于普通人来说从相册内的一堆图片中中找到合同照片轻而易举，而 AI 模型不可避免地要一张一张照片的读取并识别（大概率不会同时分析多张照片，端侧模型来不具有满足此类功能需求的性能，对于远程 AI 接口来说这样做成本会相当高）。对人类来说不到十秒的操作，AI 可能需要花费十分钟才能完成，期间用户还不能正常使用手机，实在不是多么优秀的体验。

此外 AI 手机可能还会出现误删除重要文件，发送错误信息给联系人等危险操作。毕竟作为相对很成熟 AI 编程领域，行业领先的 Google Gemini 3.0 Pro 都犯过删除用户整个磁盘文件的错误。尤其是当 AI 手机完成简单的日常操作十分优秀，用户为了省事不再逐一仔细检查 AI 手机的行为默认授权后，往往会有潜在的巨大安全隐患。

综上，不论豆包手机在二手平台炒到到了几万元的高级，它终究不是我理想中的 AI 手机的最佳形态。

我最近使用 Github Copilot Agent 模式的频率大幅增加，在接近月底的时候已经达到了 80%的高级请求使用额度，有必要准备一个备用的 AI 开发工具。
目前比较流行的终端 AI 开发工具非 Claude Code 莫属了（OpenAI 的 Codex 我有使用过，有点倾向于埋头几分钟进行一堆更改，可控性没有 Claude Code 高），但国内环境使用 Claude 模型比较困难，此时可以选择在 Claude Code 中使用国产模型，比如GLM 4.6和MinMax M2，只需要修改 claude code 的默认配置就好了。。

.claude/settings.json

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.minimaxi.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "Your API Key",
    "API_TIMEOUT_MS": "3000000",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1,
    "ANTHROPIC_MODEL": "MiniMax-M2",
    "ANTHROPIC_SMALL_FAST_MODEL": "MiniMax-M2",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "MiniMax-M2",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "MiniMax-M2",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "MiniMax-M2"
  }
}

引言

Python 3.13 版本引入了 (No-GIL 模式)，彻底解决了长期存在的并发性能瓶颈问题。随着Python 3.14的发布，Non-GIL 模式更加稳定。本文通过一个计算密集型任务的实际测试，对比 GIL 模式和 No-GIL 模式的性能差异，展示 Python 3.14 在多线程场景下的显著提升。

测试环境

• 操作系统: Ubuntu 24.04 (WSL 环境)
• Python 版本:
  • GIL 模式: Python 3.14
  • No-GIL 模式: Python 3.14t (Thread-Free)
• 执行工具: uv (高性能 Python 包安装器和解析器)
• 硬件配置: ThinkBook 14 , i5-13500H (2.60 GHz), 32GB RAM

测试方案设计

我们设计了一个计算密集型任务：计算 1 到 1,000,000 的平方和。通过以下方式验证并行性能：

1. 任务分解:

   • 将数据集划分为与 CPU 核心数相等的块
   • 每个线程处理一个数据块

2. 计算函数:

1
2

def sum_of_squares(numbers: list[int]):
    return reduce(lambda x, y: x + y**2, numbers)

3. 并发框架:
   • 使用 ThreadPoolExecutor 实现线程池
   • 每次测试运行 10 次取平均值

测试代码实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

from concurrent.futures import ThreadPoolExecutor
from functools import reduce
from time import perf_counter
import os

def sum_of_squares(numbers: list[int]):
    """计算数字列表的平方和"""
    return reduce(lambda x, y: x + y**2, numbers)

if __name__ == "__main__":
    MAX_WORKERS = os.cpu_count()
    print(f"Using {MAX_WORKERS} threads")

    # 创建测试数据集 (1-1,000,000)
    numbers = list(range(1, 1000001))

    # 数据分块
    chunk_size = len(numbers) // MAX_WORKERS
    chunks = [numbers[i : i + chunk_size] for i in range(0, len(numbers), chunk_size)]

    total_time = 0
    with ThreadPoolExecutor(max_workers=MAX_WORKERS) as executor:
        for _ in range(10):  # 运行10次取平均
            start = perf_counter()
            results = list(executor.map(sum_of_squares, chunks))
            end = perf_counter()
            total_time += end - start

    average_time = total_time / 10
    print(f"Average time over 10 runs: {average_time:.4f} seconds")

Context7 是专为解决 AI 编码助手“知识滞后”痛点设计的革新工具，通过实时抓取最新、版本特定的官方网页与代码示例，直接注入 LLM 的上下文环境，彻底告别过时 API 调用与“幻觉代码”。其核心优势在于：

1. 精准性：基于 MCP 协议动态解析库版本，确保生成代码与开发环境完全匹配，减少 80% 以上的调试成本；
2. 高效性：仅需在提示中添加 use context7，即可自动调用最新网页，避免开发者反复切换工具验证信息；
3. 扩展性：支持超 6000 个主流库（如 React、Next.js、FastAPI），并兼容 Cursor、Claude、VS Code 等多平台，无缝融入现有开发流程。

对于追求代码质量与开发效率的团队及个人开发者，Context7 以免费开源的形式提供企业级网页管理能力，是 AI 编程时代不可或缺的“智能外脑”。

Code Buddy是腾讯推出的 AI 编程助手，提供 IDE 拓展和独立 IDE。最近腾讯又推出了命令行工具Code Buddy Code，类似 Claude Code 和 Gemini CLI。我简单体验了一下，开发了一个网页版的Mermaid 编辑器，总体体验比阿里推出的 Qwen Code 要好一点（可能是因为 Code Buddy Code 的海外版默认使用的 Claude 4 模型比 Qwen3 Coder 还是要强上一线）。

【由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开发者。

【本文由DeepSeek R1辅助编写完成】
PEP750

引言

在 Python 的字符串处理领域，f-strings 自推出以来因其简洁高效广受开发者喜爱。但 f-strings 的即时求值特性在某些场景下显得力不从心，特别是在需要预处理的场景（如安全转义、结构化日志记录）中。PEP 750 提出的**模板字符串（Template Strings）**通过引入 t 前缀和延迟处理机制，为这一难题提供了优雅的解决方案。本文将深入解析这一提案的核心思想，并通过实际案例展示其强大能力。

一、模板字符串的核心特性

1.1 语法与基本使用

模板字符串使用 t 前缀定义，语法与 f-strings 完全兼容：

1
2

from string.templatelib import Template
template = t"Hello {name}!"

与 f-strings 不同，模板字符串不会直接求值为字符串，而是生成 Template 对象，包含静态字符串片段和插值表达式信息。

1.2 Template 对象结构

1
2
3
4
5
6
7

class Template:
    strings: tuple[str, ...]    # 静态字符串片段（数量=插值数+1）
    interpolations: tuple[Interpolation, ...]  # 插值列表
    
    @property
    def values(self) -> tuple[object, ...]:  # 插值求值结果
        ...

1.3 Interpolation 对象

每个插值表达式对应一个 Interpolation 实例：

1
2
3
4
5

class Interpolation:
    value: object         # 表达式求值结果
    expression: str       # 原始表达式文本
    conversion: str | None  # 转换符（!r/!s/!a）
    format_spec: str      # 格式规范

二、应用场景解析

2.1 安全内容生成

传统 f-strings 在生成 HTML 时容易引发 XSS 漏洞：

1
2

user_input = "<script>alert('XSS')</script>"
dangerous_html = f"<div>{user_input}</div>"  # 危险！

模板字符串解决方案：

1
2
3
4
5
6
7
8
9
10
11
12
13

def safe_html(template: Template) -> str:
    parts = []
    for item in template:
        if isinstance(item, Interpolation):
            # 自动转义 HTML 特殊字符
            escaped = html.escape(str(item.value))
            parts.append(escaped)
        else:
            parts.append(item)
    return "".join(parts)

template = t"<div>{user_input}</div>"
print(safe_html(template))  # <div>&lt;script&gt;...&lt;/script&gt;</div>

2.2 结构化日志记录

传统日志记录丢失结构化数据：

1

logger.info(f"User {username} logged in")  # 无法提取 username 值

模板字符串解决方案：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class StructuredMessage:
    def __init__(self, template: Template):
        self.template = template
    
    @property
    def message(self) -> str:
        return "".join(str(item) for item in self.template)
    
    @property
    def context(self) -> dict:
        return {
            item.expression: item.value
            for item in self.template.interpolations
        }

logger.info(StructuredMessage(t"User {username} logged in"))
# 输出：User alice logged in >>> {"username": "alice"}

【由DeepSeek辅助编写】

MCP Run Python 是由 PydanticAI 提供的 MCP 服务器，能够在安全、隔离的沙盒环境中执行 Python 代码。它基于 Pyodide 和 Deno 技术栈，通过 WebAssembly 实现代码隔离，确保主机系统不受执行代码的影响。

核心特性

• 安全执行：在沙盒化的 WebAssembly 环境中运行 Python 代码
• 依赖管理：自动检测并安装代码所需的依赖包
• 完整输出：捕获标准输出、标准错误及返回值
• 异步支持：原生支持异步代码执行
• 错误处理：提供详细的错误报告，便于调试

快速开始

推荐使用 Deno 运行（替代原 npm/npx 方案）：

deno run -N -R=node_modules -W=node_modules --node-modules-dir=auto jsr:@pydantic/mcp-run-python stdio

支持三种运行模式：

• stdio：通过标准输入输出通信（适合本地子进程）
• sse：基于 HTTP 的服务器推送模式（支持远程连接）
• warmup：预加载 Python 标准库

使用示例

通过 Python MCP 客户端调用：

from mcp import ClientSession
from mcp.client.stdio import stdio_client

code = """
import numpy as np
arr = np.array([1, 2, 3])
print(arr)
arr
"""

async with ClientSession(...) as session:
    result = await session.call_tool('run_python_code', {'python_code': code})
    print(result.content[0].text)  # 输出执行结果

依赖管理

支持两种依赖声明方式：

1. 自动推断：通过分析代码中的 import 语句
2. 元数据注释：遵循 PEP 723 规范

# /// script
# dependencies = ["pydantic", "email-validator"]
# ///

适用场景

• 需要安全执行用户提交代码的 SaaS 平台
• 教育类应用的代码评测系统
• 自动化工作流中的动态脚本执行

MCP Run Python 现已作为 JSR 包 发布，更多用法参考 官方文档。

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 图像生成模型 Midjourney 发布 V7 Alpha

【本文由 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 能完美保留原始排版结构