当下反向海淘赛道的核心用户群体,除了海外本土消费者,还有庞大的海外华人、留学生群体,而语言障碍、货币结算繁琐,成为很多华人代购系统、海外代购小程序落地的最大阻碍。很多创业者在搭建代购网站、开发代购APP时,都会纠结“如何实现多语言适配”“怎样支持多币种支付”,今天就结合taocarts跨境独立站系统的实战经验,从技术开发角度拆解多语言、多货币的实现逻辑,分享通用代码,帮跨境创业者、技术开发者快速落地适合海外华人的代购系统。 首先明确核心痛点:海外华人代购系统,需要适配不同国家的语言(英语、西班牙语、阿拉伯语等),同时支持多货币结算(美元、欧元、日元等),还要实现货币实时汇率转换、语言自动切换,否则会严重影响用户体验,导致客户流失。而市面上很多代购系统源码、现成代购商城系统,要么只支持单一语言,要么多货币结算存在汇率延迟,无法满足海外华人代购的实际需求。 taocarts跨境独立站系统基于React+Vue.js技术框架,专门针对海外华人代购、反向海淘业务,打造了多语言、多货币适配模块,支持10+主流语言自动切换,覆盖全球主要华人聚集区,同时对接实时汇率API,实现多货币自动换算,搭配多币种支付接口,彻底解决语言和支付壁垒,这也是taocarts作为多语言代购系统、多货币代购商城系统的核心竞争力。 下面分享两个核心功能的通用开发代码(简化版),分别是多语言适配和多货币汇率转换,适合代购网站开发、海外代购小程序开发参考,技术人员可直接复用适配:

  1. 多语言适配核心代码(React框架)
// 多语言配置文件(i18n.js)
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';

// 语言包(可扩展更多语言,如西班牙语、阿拉伯语)
const resources = {
  zh: {
    translation: {
      "home": "首页",
      "product": "商品",
      "cart": "购物车",
      "checkout": "结算",
      "logistics": "物流追踪",
      "customerService": "客服中心"
    }
  },
  en: {
    translation: {
      "home": "Home",
      "product": "Product",
      "cart": "Shopping Cart",
      "checkout": "Checkout",
      "logistics": "Logistics Tracking",
      "customerService": "Customer Service"
    }
  },
  ja: {
    translation: {
      "home": "ホーム",
      "product": "制品",
      "cart": "ショッピングカート",
      "checkout": "チェックアウト",
      "logistics": "物流追迹",
      "customerService": "カスタマーサービス"
    }
  }
};

// 初始化多语言配置
i18n
  .use(initReactI18next)
  .init({
    resources,
    lng: "en", // 默认语言(可根据用户IP自动识别)
    fallbackLng: "en", // 兜底语言
    interpolation: {
      escapeValue: false // 关闭转义,避免中文乱码
    },
    detection: {
      order: ['querystring', 'cookie', 'localStorage', 'navigator', 'htmlTag'],
      caches: ['localStorage', 'cookie'] // 缓存语言选择
    }
  });

export default i18n;
  1. 多货币汇率转换核心代码(Express.js框架)
// 多货币汇率转换接口(Express.js)
const express = require('express');
const router = express.Router();
const axios = require('axios');

// 实时汇率API(可对接第三方正规汇率接口)
const EXCHANGE_RATE_API = 'https://api.exchangerate.host/latest';

// 货币转换方法
router.get('/convertCurrency', async (req, res) => {
  try {
    const { amount, from = 'CNY', to = 'USD' } = req.query;
    // 请求实时汇率数据
    const response = await axios.get(EXCHANGE_RATE_API, {
      params: {
        base: from,
        symbols: to
      }
    });
    const rate = response.data.rates[to];
    if (!rate) {
      return res.status(400).json({ code: 400, msg: '不支持该货币转换' });
    }
    // 计算转换后金额(保留2位小数)
    const convertedAmount = (amount * rate).toFixed(2);
    // 返回结果(同步taocarts系统订单结算模块)
    res.json({
      code: 200,
      msg: '货币转换成功',
      data: {
        fromCurrency: from,
        toCurrency: to,
        exchangeRate: rate,
        originalAmount: amount,
        convertedAmount: convertedAmount,
        updateTime: new Date().toLocaleString()
      }
    });
  } catch (error) {
    res.status(500).json({ code: 500, msg: '汇率转换失败', error: error.message });
  }
});

module.exports = router;

以上两段代码,是taocarts系统多语言、多货币模块的核心简化版,实际开发中,还会加入用户IP自动识别语言、货币偏好记忆、多币种支付接口对接(如PayPal、Stripe)等功能,确保海外用户使用时,无需手动切换语言和货币,就能流畅完成代购、结算操作。
对于跨境创业者来说,无需自己投入技术团队开发这些模块,taocarts跨境独立站系统已经实现现成的多语言、多货币适配,无论是搭建华人代购商城系统、海外代买网站系统,还是开发支持多语言的海外代购网站,都能直接复用,大幅降低开发成本和落地周期。对于技术开发者来说,这些代码可以作为多语言代购系统开发、代购支付接口开发的参考,避免重复造轮子。
此外,taocarts的多语言模块还支持自定义语言包,创业者可根据目标市场(如东南亚、欧美华人区),添加对应语言,搭配代购自动翻译系统,实现商品描述、订单信息的自动翻译,进一步降低语言壁垒。后续会分享taocarts多币种支付接口的对接细节,欢迎技术同行和跨境创业者交流。

在 SEO 业务中,无论是关键词排名监控、竞品分析、还是搜索引擎结果页面(SERP)采集,都离不开代理 IP 的支持。搜索引擎普遍存在反爬机制,使用代理 IP 可以规避 IP 级别的限制。

但 SEO 场景繁多,不同类型的任务对代理 IP 的要求差异很大。本文将从技术角度分析 SEO 业务中代理 IP 的选型要点,并提供代码示例供参考。

一、SEO 业务中的典型代理使用场景

二、代理 IP 的核心选型维度

2.1 IP 类型

结论:对于搜索引擎类任务,优先选择住宅 IP。

2.2 IP 覆盖范围

2.3 IP 轮换方式

2.4 协议支持

三、不同 SEO 场景的代理选型建议

场景一:关键词排名监控
需求:模拟特定地区用户搜索,获取准确排名。
选型要点:

  • 需要支持国家/城市级别的地理定位
  • 使用静态住宅 IP(每次查询保持同一 IP,模拟真实用户)
  • 协议:HTTPS

代码示例:

import requests

# 配置支持地理定位的代理
proxies = {
    'http': 'http://user:pass@gateway.service.com:8080',
    'https': 'http://user:pass@gateway.service.com:8080'
}

# 设置搜索参数(示例:Google 搜索)
params = {
    'q': 'SEO 教程',
    'gl': 'us',      # 国家:美国
    'hl': 'en'       # 语言:英语
}

response = requests.get(
    'https://www.google.com/search',
    params=params,
    proxies=proxies,
    headers={'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'}
)

print(response.status_code)
# 解析排名逻辑...

场景二:大规模 SERP 采集

需求:批量获取搜索结果,请求量大,需要高成功率。
选型要点:

  • 使用住宅 IP 池(轮换使用)
  • 每次请求换 IP 或小范围轮换
  • 需要高并发支持
  • 协议:HTTP/HTTPS

代码示例:

import asyncio
import aiohttp
from itertools import cycle

# 代理列表(示例)
PROXY_LIST = [
    'http://proxy1:8080',
    'http://proxy2:8080',
    'http://proxy3:8080',
]

async def fetch_serp(session, keyword, proxy):
    """异步获取 SERP 数据"""
    url = f'https://www.google.com/search?q={keyword}'
    try:
        async with session.get(url, proxy=proxy, timeout=10) as resp:
            return await resp.text()
    except Exception as e:
        return None

async def batch_search(keywords: list, concurrency: int = 10):
    """批量搜索,自动轮换代理"""
    proxy_cycle = cycle(PROXY_LIST)
    connector = aiohttp.TCPConnector(limit=concurrency)
    
    async with aiohttp.ClientSession(connector=connector) as session:
        tasks = []
        for kw in keywords:
            proxy = next(proxy_cycle)
            tasks.append(fetch_serp(session, kw, proxy))
        
        results = await asyncio.gather(*tasks)
        return results

# 使用示例
keywords = ['SEO', 'SEM', '内容营销', '外链建设'] * 100
results = asyncio.run(batch_search(keywords))
success_count = sum(1 for r in results if r)
print(f"成功率: {success_count}/{len(results)}")

场景三:竞品网站爬取

需求:爬取竞品网站结构、内容,可能遇到反爬。
选型要点:

  • 使用动态轮换 IP
  • 配合指纹浏览器或请求头轮换
  • 设置合理请求间隔
  • 协议:HTTPS(大多数现代网站)

代码示例:

import requests
import time
import random

PROXY_LIST = [...]  # 代理列表

def crawl_competitor(url: str, max_retries: int = 3):
    """爬取竞品页面,失败自动切换代理"""
    for attempt in range(max_retries):
        proxy = random.choice(PROXY_LIST)
        proxies = {'http': proxy, 'https': proxy}
        
        headers = {
            'User-Agent': random.choice(USER_AGENTS),
            'Accept-Language': 'en-US,en;q=0.9',
        }
        
        try:
            response = requests.get(url, proxies=proxies, headers=headers, timeout=10)
            response.raise_for_status()
            
            # 随机延迟,模拟人类行为
            time.sleep(random.uniform(1, 3))
            return response.text
            
        except requests.exceptions.RequestException:
            print(f"代理 {proxy} 失败,重试 {attempt + 1}/{max_retries}")
            continue
    
    raise Exception(f"爬取 {url} 失败,已重试 {max_retries} 次")

四、代理 IP 选型决策框架

# 伪代码:SEO 代理选型决策
def select_proxy_for_seo(scene: str, budget: str, volume: int):
    
    if scene == "keyword_ranking":
        return {
            "type": "static_residential",
            "geo": "city_level",
            "rotation": "session_based",
            "protocol": "HTTPS"
        }
    
    elif scene == "serp_scraping":
        return {
            "type": "residential_pool",
            "geo": "country_level",
            "rotation": "per_request",
            "protocol": "HTTP/HTTPS",
            "concurrency": "high"
        }
    
    elif scene == "competitor_analysis":
        return {
            "type": "rotating_residential",
            "geo": "any",
            "rotation": "per_request_with_retry",
            "protocol": "HTTPS"
        }
    
    elif scene == "index_check":
        return {
            "type": "residential_or_datacenter",
            "geo": "any",
            "rotation": "low_frequency",
            "protocol": "HTTP"
        }
    
    else:
        return {"default": "residential_proxy"}

五、选型对比总结

六、常见误区与注意事项

误区一:数据中心 IP 足够用
搜索引擎对数据中心 IP 段的识别能力很强,使用此类 IP 会导致请求被频繁拦截或返回错误数据。
误区二:代理越多越好
过多的代理轮换反而可能导致 IP 质量下降。建议维护一个小而精的代理池,定期检测剔除失效 IP。
误区三:忽略地域匹配
排名监控必须使用目标地区的 IP,否则获取的排名数据不准确。
注意事项

  • 遵守 robots.txt:爬取前检查目标网站的 robots.txt 文件
  • 控制请求频率:合理设置间隔,避免对目标服务器造成压力
  • 使用 HTTPS:涉及搜索词等敏感数据时使用加密传输
  • 定期验证代理质量:剔除失效或响应慢的代理

七、总结

SEO 业务中选择代理 IP 的核心原则:

  1. 搜索引擎类任务优先选住宅 IP,数据中心 IP 容易被封
  2. 按场景决定轮换策略:排名监控用静态 IP,SERP 采集用轮换 IP
  3. 地理位置要匹配:关键词排名必须使用目标地区的 IP
  4. 配合合理的请求频率:代理 IP 是工具,行为模式同样重要

希望本文能帮助你在 SEO 业务中做出合适的代理 IP 选型决策。

HarmonyOS 智能填充(AutoFill)深度解析:从原理到鸿蒙6实战适配

每次面对应用里那堆繁琐的登录页、注册表单或是收货地址填写,作为开发者的我们总是带着一种矛盾的复杂心态。一方面,深知这些是业务中不可或缺的关键转化节点;另一方面,又无奈于繁琐的输入体验往往会让用户半途而废。好消息是,HarmonyOS 提供了一套极为优雅的解决方案——智能填充(AutoFill)框架

今天,我们不谈干瘪的官方文档释义,以一个“踩过无数坑”的同行身份,带你深入拆解鸿蒙智能填充的底层逻辑。我们会从核心原理出发,一路走到代码实战,并着重聊聊在最新的生态下,如何丝滑地完成高级适配。


一、 智能填充是如何“猜”中用户心思的?

很多开发者会误以为 AutoFill 仅仅是一个简单的“历史输入记录回填”。坦白讲,这远远低估了鸿蒙系统的野心。

智能填充的本质,是一个系统级的上下文感知与数据安全调度框架。它的工作流可以精炼为三个核心阶段:语义识别 $\rightarrow$ 安全检索 $\rightarrow$ 场景化注入

  1. 语义识别(Semantic Recognition)
    框架并不会去读取你的页面布局文件,它关注的是组件的“身份证”。当你给 TextInput 设定了特定的 InputType(比如 USER_NAMEPASSWORD)或者更细粒度的 contentType(如 AddressPostalCode),系统底层就会将这些组件打上特定的语义标签。
  2. 安全检索(Secure Retrieval)
    一旦输入框获焦,系统会基于当前应用的包名(Bundle Name)和用户身份,在沙盒隔离的密码保险箱(Password Vault)关键资产存储(Asset Store)中查询匹配的数据。这里的数据全是经过 TEE(可信执行环境)加密的,安全性拉满。
  3. 场景化注入(Contextual Injection)
    系统将匹配到的数据通过 Binder 机制跨进程传递给输入法框架(IME),最终由输入法在上层以“候选视图”的形式呈现给用户,用户点击后直接注入到相应组件。

为了更直观地理解这个过程,我们特意将下面的流程图进行了彩色美化与视觉分区。你可以把它想象成一条精密的流水线:

flowchart TD
    %% 定义样式:不同阶段的节点使用不同的柔和配色
    classDef userAction fill:#E3F2FD,stroke:#2196F3,stroke-width:2px,color:#0D47A1;
    classDef systemCore fill:#F3E5F5,stroke:#9C27B0,stroke-width:2px,color:#4A148C;
    classDef security fill:#E8F5E9,stroke:#4CAF50,stroke-width:2px,color:#1B5E20;
    classDef uiLayer fill:#FFF3E0,stroke:#FF9800,stroke-width:2px,color:#E65100;

    A[用户点击<br>TextInput 输入框]:::userAction
    
    subgraph System_Process [系统核心处理层]
        B{检测组件类型<br>USER_NAME / PASSWORD}:::systemCore
        C{检测组件类型<br>ADDRESS / EMAIL}:::systemCore
    end

    D[触发 AutoFill 框架<br>语义匹配开始]:::systemCore
    E[在 TEE 加密沙盒中<br>查询匹配数据]:::security
    F{用户是否开启<br>智能填充服务?}:::security
    G[通过 Binder 跨进程通信<br>发送数据至输入法]:::uiLayer
    H[输入法上方展示<br>智能填充候选条]:::uiLayer
    I[用户点击候选词<br>完成注入]:::userAction

    %% 流程连线
    A --> B & C
    B & C -->|识别成功| D
    D --> E
    E --> F
    F -- 是 --> G
    F -- 否 --> J[仅显示普通键盘]:::uiLayer
    G --> H
    H --> I

    %% 美化连线样式
    linkStyle default stroke:#607D8B,stroke-width:2px,fill:none;

二、基础 AutoFill 的代码实战

理论说得再天花乱坠,终究要落到代码上。在传统的 ArkUI 开发中,接入基础的账号密码自动填充简直可以说是“零成本”。

举个最常见的登录页例子,我们只需要在 TextInput 中指定 type 属性即可:

// LoginPage.ets
import { BusinessError } from '@ohos.base';

@Entry
@Component
struct LoginPage {
  @State userName: string = '';
  @State password: string = '';

  build() {
    Column({ space: 20 }) {
      Text('欢迎回来').fontSize(28).fontWeight(FontWeight.Bold).margin({ bottom: 30 })

      // 1. 用户名输入框:指定类型为 USER_NAME
      TextInput({ placeholder: '请输入用户名/邮箱', text: this.userName })
        .type(InputType.USER_NAME) // 核心:告诉系统这是个用户名
        .width('80%')
        .height(50)
        .backgroundColor(Color.White)
        .borderRadius(8)
        .padding({ left: 15 })
        .onChange((value: string) => {
          this.userName = value;
        })

      // 2. 密码输入框:指定类型为 PASSWORD
      TextInput({ placeholder: '请输入密码', text: this.password })
        .type(InputType.PASSWORD) // 核心:告诉系统这是个密码
        .width('80%')
        .height(50)
        .backgroundColor(Color.White)
        .borderRadius(8)
        .padding({ left: 15 })
        .onChange((value: string) => {
          this.password = value;
        })

      Button('登录')
        .width('80%')
        .margin({ top: 40 })
        .onClick(() => {
          // 模拟登录逻辑
          console.info(`Logging in with: ${this.userName}`);
        })
    }
    .width('100%')
    .height('100%')
    .justifyContent(FlexAlign.Center)
    .backgroundColor('#F5F5F5')
  }
}

代码解析
注意到没有?我们甚至不需要额外导入任何 AutoFill 专属的库。只需一行 .type(InputType.USER_NAME),系统就会在编译期和处理事件时自动关联底层的密码保险箱服务。当用户此前在此应用保存过密码时,键盘上方会神奇地弹出对应的账号候选条。


三、复杂表单与主动触发保存

基础的账号密码太简单?那我们考虑一个电商应用常见的“添加收货地址”场景。这里涉及多个字段(姓名、电话、详细地址),不仅需要智能推荐,还需要在用户点击保存时,主动通知系统去记录这些信息以便下次填充。

这就用到了 @ohos.app.ability.autoFillManager 了。来看核心代码片段:

// AddressPage.ets
import { autoFillManager } from '@kit.AbilityKit';
import { BusinessError } from '@ohos.base';

@Entry
@Component
struct AddressPage {
  @State name: string = '';
  @State phone: string = '';
  @State address: string = '';
  @State isClicked: boolean = false;

  // 主动触发保存逻辑
  saveAddress() {
    if (this.isClicked) return; // 防抖处理
    
    try {
      // 核心 API:请求系统保存当前上下文中的表单数据
      autoFillManager.requestAutoSave(this.getUIContext());
      this.isClicked = true;
      
      setTimeout(() => { this.isClicked = false; }, 1000);
      promptAction.showToast({ message: '地址保存成功,下次可智能填充!' });
    } catch (error) {
      const err: BusinessError = error as BusinessError;
      console.error(`AutoSave failed, code: ${err.code}, message: ${err.message}`);
    }
  }

  build() {
    Column({ space: 15 }) {
      Text('新建收货地址').fontSize(22).fontWeight(FontWeight.Bold).margin({ bottom: 20 })

      TextInput({ text: this.name, placeholder: '请输入姓名' })
        .width('90%')
        .height(45)
        .backgroundColor(Color.White)
        .borderRadius(6)
        .padding({ left: 10 })
        // 关键:指定内容类型为全名,有助于系统识别
        .contentType(ContentType.FULL_NAME) 
        .onChange(v => this.name = v)

      TextInput({ text: this.phone, placeholder: '请输入手机号' })
        .width('90%')
        .height(45)
        .backgroundColor(Color.White)
        .borderRadius(6)
        .padding({ left: 10 })
        .type(InputType.PHONE_NUMBER) // 指定为电话号码
        .onChange(v => this.phone = v)

      TextInput({ text: this.address, placeholder: '请输入详细地址' })
        .width('90%')
        .height(45)
        .backgroundColor(Color.White)
        .borderRadius(6)
        .padding({ left: 10 })
        .contentType(ContentType.FULL_ADDRESS) // 指定为完整地址
        .onChange(v => this.address = v)

      Button('保存地址')
        .width('90%')
        .margin({ top: 30 })
        .onClick(() => this.saveAddress())
    }
    .width('100%')
    .padding({ top: 20 })
    .backgroundColor('#F0F0F0')
  }
}

(注意一下下:ContentType 是 ArkUI 提供的更细粒度的语义枚举,能极大提升系统识别表单的准确率)


四、 拥抱变化

随着 HarmonyOS6 的到来,智能填充服务迎来了真正的“史诗级加强”——场景化融合推荐(Scenario Fusion)

在早期的鸿蒙版本中,AutoFill 主要局限于账号密码和基础的文本匹配。但在鸿蒙6中,系统引入了更强大的端侧 AI 预测模型,能够深度理解业务场景

1. 表单场景的白名单赋能

最新的智能填充服务支持更多元化的场景(如日程信息、昵称推荐、历史表单输入记忆等)。不过,目前处于 Beta 强化期,部分高级场景化填充需要你在 module.json5 中声明权限,并向华为发送邮件申请加入到系统的白名单中(提供包名和 APPID 即可,审核通常在5个工作日内)。

2. 强密码生成与无缝衔接

在注册页面,如果你将新密码输入框指定为 InputType.NEW_PASSWORD,鸿蒙6的系统键盘不仅能触发自动填充,还能直接调用系统级的强密码生成器。用户点击“建议密码”,系统会在后台生成一个高强度的随机密码,并在用户点击注册的瞬间,静默保存到密码保险箱中。这一切,都不需要你写一行复杂的密码生成算法!

3. 多设备云空间同步填充

得益于鸿蒙生态的分布式软总线技术,用户在手机上保存的账号密码或地址信息,在经过用户授权后,可以通过云空间(HUAWEI Cloud)安全地同步到平板、PC等其他设备上。在鸿蒙6中,这种跨端填充的握手协议更加迅速,几乎做到了“无感切换”。


五、 避坑指南与终局思考

在做 AutoFill 适配时,老手们总会格外警惕以下几个容易翻车的地方:

  1. 页面跳转导致的误保存
    如果在登录失败时,你通过 router.pushUrl 跳转到错误处理页,且新页面也有输入框,务必将原来页面的 enableAutoFill 设为 false,否则系统可能会把错误的凭证当做新数据保存下来。
  2. 组件的唯一性标识:
    在复杂表单中,尽量给需要智能填充的 TextInput 设置一个稳定的 .id()。这有助于系统在页面重组或动态加载时,依然能准确地将历史数据映射回正确的输入框。
  3. 安全与便利的平衡:
    虽然系统提供了便捷,但对于极度敏感的应用(如银行类 App),你可能需要在密码输入框失去焦点时清空内存中的变量,仅依赖系统的 TEE 进行保管。

总结一下下

从早期单纯的 InputType 映射到如今鸿蒙6深度融合端侧 AI 的场景化感知,智能填充(AutoFill) 早已不是那个需要开发者“求着”系统去做的边缘功能,而是提升应用留存率和用户体验的核心利器

作为鸿蒙开发者,我们的目标不仅是让应用“能跑”,更是要让用户“用得爽”。花上不到半小时,给你的表单组件加上正确的语义类型,也许下一次用户下单时,那一秒的便捷体验,就会成为他们留下来的理由。

拒绝繁琐表单:HarmonyOS 华为账号一键登录与身份标识深度破局

做应用开发的朋友都心知肚明,登录注册页往往是用户流失的“重灾区”。每一次手动输入手机号、等待短信验证码的漫长过程,都在无声地消磨用户的耐心。有没有更优雅的解法?答案是肯定的。华为账号一键登录(One-Tap Login),就是那把帮你大幅拉升转化率的金钥匙。

今天,我们不照搬枯燥的官方手册,而是以一个“踩过坑”的同路人之姿,带你深挖如何在 HarmonyOS 应用中丝滑接入一键登录,一次性把 UnionIDOpenID 以及匿名手机号全部拿到手。顺便,我们还会把目光放长远一些,聊聊如果面对未来的 HarmonyOS 6 (API 22) 环境,我们的代码该如何未雨绸缪。


一、 拨开云雾:一键登录背后的“双轨制”逻辑

很多新手会困惑:为什么一键登录能同时给我匿名手机号和 UnionID?这其实涉及到华为账号体系的两条核心业务线的交汇。

简单来说,当用户点击那个带有华为Logo的按钮时,系统底层实际上在并行处理两件事:

  1. 匿名手机号预取(Pre-fetching):系统会在后台悄悄唤起华为账号的授权组件,通过系统级的安全通道,将当前登录华为账号绑定的手机号进行匿名化处理(通常是中间四位变成星号)并返回给应用。这证明了“这是一个真实的、拥有手机号的活人”。
  2. OAuth 2.0 授权与 ID 派发:同时,应用通过标准的授权流程,获取到一个 Authorization Code。拿着这个 code 去华为的后端服务器换取到该用户在当前开发者账号下的唯一标识——UnionIDOpenID

这两个通道的数据最终在应用前端汇合,你既可以拿匿名手机号作为展示和初步信任的基石,也可以用 UnionID/OpenID 去打通你自己的后端用户体系。

为了更直观地看清这套机制,我绘制了下方这份彩色分区的业务流程图:

flowchart TD
    classDef appLayer fill:#E3F2FD,stroke:#2196F3
    classDef systemLayer fill:#F3E5F5,stroke:#9C27B0
    classDef networkLayer fill:#E8F5E9,stroke:#4CAF50
    classDef userAction fill:#FFF3E0,stroke:#FF9800

    A([用户打开App]):::userAction --> B{检测登录态}:::appLayer
    B -- 未登录 --> C[展示华为一键登录按钮]:::appLayer
    B -- 已有Token --> D[直接进入主页]:::appLayer

    C --> E[用户点击一键登录]:::userAction
    E --> F{系统级授权弹窗}:::systemLayer

    F -- 同意 --> G[获取匿名手机号及临时Code]:::systemLayer
    F -- 拒绝 --> H[隐藏一键登录]:::appLayer

    G --> I[发送Code至服务器]:::networkLayer
    I --> J{向华为服务器换取ID}:::networkLayer

    J -- 成功 --> K[下发Session Token]:::networkLayer
    K --> L[登录成功]:::appLayer

    J -- 失败 --> M[提示异常]:::appLayer

二、 回到现实:基于当前主流 API (12) 的实战代码

虽然标题提到了 API 22,但立足当下才是最好的开始。目前 HarmonyOS NEXT (API 12) 提供了极其完善的 Account Kit 供我们使用。

核心思路分为三步:配置 ClientID $\rightarrow$ 构造授权请求 $\rightarrow$ 处理回调与后端联调

下面是一段精简但完整的 ArkTS 实战代码:

// LoginPage.ets
import { authentication } from '@kit.AccountKit';
import { BusinessError } from '@kit.BasicServicesKit';
import { hilog } from '@kit.PerformanceAnalysisKit';
import { util } from '@kit.ArkTS';

@Entry
@Component
struct LoginPage {
  @State anonymousPhone: string = '';
  @State logMsg: string = '等待一键登录...';

  // 核心:执行华为一键登录授权
  async handleQuickLogin() {
    // 1. 创建授权请求,指定我们需要的 scope
    // quickLoginAnonymousPhone 用于获取匿名手机号
    // openid 和 profile 用于获取 UnionID/OpenID 及基本资料
    const scopes = ['quickLoginAnonymousPhone', 'openid', 'profile'];
    const permissions: Array<authentication.Permission> = ['email'];
    
    const request = new authentication.HuaweiIDProvider().createAuthorizationWithHuaweiIDRequest();
    request.scopes = scopes;
    request.permissions = permissions;
    request.forceAuthorization = false; // 已有授权则静默,无则拉起弹窗
    request.state = util.generateRandomUUID(); // 防CSRF攻击的随机字符串

    try {
      this.logMsg = '正在拉起授权...';
      // 2. 执行授权操作
      const controller = new authentication.AuthenticationController();
      const response = await controller.executeRequest(request) as authentication.AuthorizationWithHuaweiIDResponse;
      
      // 3. 提取数据
      const code = response.data?.authorizationCode;
      const anonymousPhone = response.data?.anonymousPhoneNumber;
      const unionId = response.data?.unionId;
      const openId = response.data?.openId;

      this.anonymousPhone = anonymousPhone ?? '未获取到';
      this.logMsg = `授权成功!\n匿名手机号: ${this.anonymousPhone}\nUnionID: ${unionId?.substring(0, 5)}...`;
      
      hilog.info(0x0000, 'LoginPage', `Code: ${code}, UnionID: ${unionId}`);
      
      // TODO: 将 code 发送给你的后端服务器,换取用户的正式身份信息
      
    } catch (error) {
      const err = error as BusinessError;
      this.logMsg = `授权失败: ${err.message}`;
      hilog.error(0x0000, 'LoginPage', `Error code: ${err.code}, Msg: ${err.message}`);
    }
  }

  build() {
    Column({ space: 20 }) {
      Text('HarmonyOS 一键登录 Demo')
        .fontSize(24)
        .fontWeight(FontWeight.Bold)
        .margin({ bottom: 50 })

      // 使用官方提供的 HuaweiID Button 组件是最省事且符合 UX 规范的
      authentication.HuaweiIDButton({
        params: {
          style: authentication.ButtonStyle.BUTTON_RED,
          sizeMode: authentication.SizeMode.SIZE_MODE_DEFAULT
        },
        // 绑定点击事件
        onClick: () => this.handleQuickLogin()
      })
      .width('80%')
      .height(50)

      // 展示获取到的信息
      Column({ space: 10 }) {
        Text(this.logMsg)
          .fontSize(14)
          .fontColor(Color.Grey)
          .textAlign(TextAlign.Center)
          .margin({ top: 30 })
        
        if (this.anonymousPhone) {
          Text(`检测到您的手机号尾号为: ${this.anonymousPhone.slice(-4)}`)
            .fontSize(16)
            .fontColor(Color.Orange)
        }
      }
      .width('80%')
    }
    .width('100%')
    .height('100%')
    .justifyContent(FlexAlign.Center)
    .backgroundColor('#F5F5F5')
  }
}

代码关键解析:
留意 createAuthorizationWithHuaweiIDRequest 这个方法。我们将 scopes 设定为 ['quickLoginAnonymousPhone', 'openid', 'profile'],这是能够同时拿到匿名手机号和 ID 的核心秘诀。此外,强烈建议将 forceAuthorization 设为 false,这样在用户已经授权过的情况下,系统甚至会连弹窗都不拉起,直接给你返回数据,体验堪称极致。


三、 眺望未来:面向 HarmonyOS 6 (API 22) 的适配推演

这里要稍微停顿一下,说点掏心窝子的话。目前 HarmonyOS 的正式稳定版生态停留在 4.x / NEXT (API 11/12) 阶段。如果你正在筹备针对 HarmonyOS 6 (API 22) 的超前适配,虽然底层账号协议的兼容性极高,但作为老手,我们必须对几个潜在的“风暴点”保持敏感:

1. 权限管控的进一步收紧 (Scoped Storage & Privacy)

到了 API 22 这个跨越度极大的版本,系统对用户隐私的保护必然会上升至新台阶。

  • 差异预判quickLoginAnonymousPhone 这个 scope 可能需要你在 module.json5 中声明更明确的权限理由(Reason for Usage),甚至需要用户在系统设置中进行二次确认。
  • 适配对策:永远不要硬编码你的 Scope 数组。建议封装一个 getRequiredScopes() 方法,根据系统 API 版本动态返回权限列表,低版本给基础权限,高版本(API 22+)自动追加高阶隐私权限申请逻辑。
2. 返回数据结构的平滑演进

系统 API 升级,最怕的就是返回体字段的增减。

  • 差异预判:在 API 22 中,AuthorizationWithHuaweiIDResponse 极有可能被标记为废弃(Deprecated),华为可能会推出全新的 AuthorizationV2Response,将 unionIdopenId 放入更深一层的 identity 对象中。
  • 适配对策:千万别在业务代码里满屏写 response.data.unionId一定要做一个数据适配器(Adapter Pattern)!在适配层中统一处理新老 API 的数据清洗,确保上层业务逻辑拿到的永远是结构稳定的内部 DTO(Data Transfer Object)。
3. 后台常驻与冷启动的握手机制
  • 差异预判:高版本系统往往会限制后台服务的任意拉起。如果你的一键登录流程涉及跨应用跳转(比如从你的 App 跳转到华为账号中心再跳回来),在 API 22 上可能会因为任务栈断裂而导致登录回调丢失。
  • 适配对策:在 onNewWantonCreate 等入口方法中,加入对登录意图(Intent)的恢复处理逻辑。简单来说,就是哪怕 App 被杀后在重新创建,也能接续上之前未完成的登录流程。

四、 避坑指南:那些让我半夜爬起来的 Bug

  1. Client ID 配置错位
    这是最常犯的致命错误。一键登录强依赖你在 AppGallery Connect (AGC) 平台配置的 OAuth 2.0 客户端 ID。如果这个 ID 没有正确放置在 entry 模块的 module.json5metadata 中,或者包名与 AGC 的不一致,调用时会直接抛出 1001500001 之类的诡异错误码。相信我, double check 这一步能省下你三个小时的抓包时间。
  2. 匿名手机号为空的玄机
    并不是每次调用都能拿到匿名手机号。如果用户从未在华为账号绑定过手机号,或者当前设备处于纯离线状态,这个字段就会是空的。健壮的代码绝不能写 if (phone) 就万事大吉,必须要有降级方案(比如优雅地隐藏一键登录按钮,回退到传统的短信验证码登录)。
  3. State 参数的防重放攻击
    虽然是个小细节,但在生产环境中极其重要。每次请求前务必使用一个真正的随机数(如代码中的 util.generateRandomUUID())填充 request.state。这能有效防止恶意攻击者截获你的授权请求并进行重放攻击。

总结一下下

HarmonyOS 的账号体系设计,骨子里透着一种“用完即走,但随时能找回来”的从容。作为开发者,我们的职责就是利用好 UnionIDOpenID 这对黄金搭档,再辅以匿名手机号的信任背书,为用户搭建一座最短、最安全的登录桥梁。

无论你现在是 targeting API 12 还是已经在仰望 API 22,核心逻辑万变不离其宗:关注数据流向,敬畏用户隐私,做好兼容适配层。希望这篇实战解析能为你接下来的鸿蒙开发注入一点灵感。祝你编码愉快,上架顺利!

当文件体积超过邮件附件限制、社交软件传输卡顿、U盘拷贝效率低下时,团队很容易陷入“文件发不出去,工作就动不起来”的困境。本文将解答大文件传输用什么工具?深度剖析团队大文件共享与协作工具——坚果云。

一、生活中工作中经常需要大文件传输

在数字化办公时代,大文件传输早已不是特定行业的专属需求,而是渗透到每个行业的日常协作中。以下是三个最典型的痛点场景:

  1. 项目协作 当团队通过邮件、即时通讯工具多次传输同一设计稿或工程文件的不同版本时,最终每个人电脑里的文件可能都是“独家定制版”。频繁的大文件覆盖不仅浪费存储空间,更极易因用错版本导致重大工作失误或决策偏差。
  2. 远程办公 在混合办公模式或多地协同下,团队成员分散。当总部需要将包含大量素材素材、高达数GB的产品包同步给分支机构时,普通传输方式往往面临传输中断需重头再来、网络不稳定导致下载失败等问题,极大增加了沟通成本。
  3. 客户交付 针对设计院、影视制作或咨询机构,向客户交付数十GB成果文件时,安全性和交付体验至关重要。普通分发方式面临未经授权的访问风险,且客户下载时若遭受限速,会直接损害企业的专业形象。

二、如何高效率传输大文件?

针对以上场景,目前主流的解决方案主要有三种:

  1. 企业同步盘:团队协作的“数字高速公路” 专业的企业同步盘不仅是存储工具,更是数字生产力的“中枢”。其优势在于:
  • 传输层:针对复杂网络环境专门优化,可实现海量小文件和GB级大文件的稳定传输。
  • 安全层:采用金融级加解密技术支撑,构筑坚固的数据护城河。
  • 协作层:文件可实现无缝同步、历史溯源以及精确授权,将单一传输升级为动态协同管理。
  1. 物理介质:极端场景下的“备胎方案” 通过移动硬盘或U盘进行物理拷贝。虽在无网环境下可用,但硬件采购及物流成本高昂,且难以满足现代办公对于实时同步修改的刚性需求;同时存在硬件损坏导致数据丢失的不可逆风险。
  2. 企业专线:大企业的“重型基建” 通过拉设跨国或跨地域专属光纤专线,彻底消除公网波动。但这种方案往往伴随着极高的部署与年费成本,对绝大多数企业和团队而言并不具备实操性。

三、大文件传输用什么工具?团队大文件传输工具推荐

在众多协作工具中,自2011年上线、已稳定运营超过15年的坚果云,凭借深厚的技术壁垒和合规认证成为了企业网盘的标杆。目前已被中国石油、中银证券、清华大学等10万家知名企业及机构广泛采用。以下是其应对大文件传输的核心能力:

坚果云官网

  1. 安全:构建不可逾越的“合规护城河”
  • 硬性资质:坚果云拥有公安部信息系统安全等级保护三级备案(非银行机构最高级别安全认证),并获得ISO27001、ISO27701认证,从根本构建了信任基石。
  • 加密技术:采用AES-256金融级加密算法及SSL/TLS全链路加密,辅以单向哈希计算密钥,保障数据在传输与云端存储过程中的绝对安全。
  • 精细管控:提供多维度的权限设定结构。文件流转中的上传、下载、预览皆可受控,防止内部资料不慎越权外泄。
  1. 速度:专为复杂环境与大文件设计的技术壁垒
  • 极速同步能力:坚果云特别优化了针对GB级大文件和海量小文件的传输效率。即使是免费用户,也同样享受不限速的畅快体验。
  • 增量加速:内置智能增量同步技术,当大文件(如PSD、数据库文件)发生微小修改时,坚果云仅上传修改部分,显著缩短同步等待时间。
  • 无感同步体验:支持多终端设备无缝访问,并在内部办公网络中支持局域网同步加速,最大限度利用本地宽带。
  1. 协作:化被动接收为主动协同
  • 版本控制:独具特色的文件历史版本功能,系统会自动记录文档修改过程。面对误操作或文件损坏,可快速对比差异并一键恢复至正确版本。
  • 在线预览:原生支持超过100种文件格式(涵盖各类办公与工程专业格式)的在线预览,免除了接收方必须安装专业软件才能查看大体积文件的繁琐。
  • 协同生态:提供文件评论、文件锁定限制冲突,乃至多人同时在线编辑功能。

**现在坚果云团队版还有免费试用20天:坚果云团队版官网

坚果云与主流普通网盘核心维度的能力对比表

功能点坚果云 (企业级网盘)某主流普通网盘
大文件传输体验专为GB级大文件优化,免费用户亦不限速依据会员等级严格限速
同步核心技术智能增量同步、局域网加速、无感同步传统的全量上传覆盖
文件防勒索/防丢智能保留文件历史版本,随时恢复历史节点依赖回收站,难以追溯高频修改历史
数据安全资质公安部信息系统安全等级保护三级备案等认证常规商业标准认证
综合协作能力在线预览(100+格式)、精细权限管控、多人评论锁定以单向共享或下载为主

四、FAQs:大文件共享常见问题

Q1:市面免费网盘限速严重,企业版网盘投入预算怎么评估?

A:各类团队情况不同,可以选择提供免费试用的工具进行实际跑测。例如,坚果云向高效协作团队提供长达20天的团队版免费试用,不仅在试用期体验无阻碍的高速大文件分发,更能感受企业级的权限管控体验。

Q2:当多名设计师需反复修改同一个GB级大文件时,如何避免传输占尽宽带?

A:您可以利用坚果云的智能增量同步功能。当设计师对十几个GB的工程文件只改动了几个图层时,坚果云仅会自动检测并同步这几兆的改动部位,数秒即可让团队其他成员电脑上的文件更新到最新状态。

Q3:客户方没有账号,怎么便捷又安全地把大文件发给他们或者向他们收取文件?

A:一方面,坚果云可以通过带有访问密码和有效期限制的分享 链接 ,让客户免登录预览或下载文件;另一方面,若需大批量向多位客户收集大型资料,可调用“坚果云收件箱”功能——提交者无需登录,文件提交后自动重命名并归档至您的电脑同步文件夹中,大幅减轻人力整理成本。

Q4:公司涉及多个科研机构合作,对合规性和数据防泄漏要求极高,文件应该放在哪?

A:建议只选择具备国家级背书的方案。像 清华 大学等机构采用的坚果云,已获得公安部信息系统安全等级保护三级备案,并采用 分布式 存储架构和AES-256加密,是极为理想的解决方案。

Q5:团队成员经常手滑覆盖掉正确的文件版本,除了反复互相发文件保留底稿外,还有什么好办法?

A:坚果云的文件历史版本功能天然解决了这一痛点。它实时记录每次修改,无论经过多少次覆盖,管理员及协作者都可直接调出历史版本面板进行找回或对比,彻底摆脱“重命名式”的手工备份。

结束语

无论是高效协作团队、注重数据安全企业,还是灵活文件管理个人,选择一款不限速、高稳定且注重合规的同步盘,都是打破效率瓶颈的必然途径。

在机械装备制造领域,多品种、小批量、非标定制已成为主流生产模式。从工程机械、自动化设备到精密传动装置,组装环节往往涉及成百上千种零部件,工序长、协同环节多、对精度与追溯要求严苛,传统管理模式很容易陷入效率瓶颈。
不少机械组装企业仍在依赖Excel排产、纸质流转卡、人工报工、事后补录数据。看似低成本的操作,背后隐藏着大量隐性成本:计划频繁变动导致插单混乱、物料齐套性差停工待料、装配错漏装反复返工、质量问题无法快速追溯、工时与成本核算不准、交期难以保障
想要打破这种局面,万界星空MES系统核心是打通生产全流程数据,实现计划、物料、工序、质量、设备的一体化协同。面向机械组装的生产执行管理方案,正是围绕离散装配场景设计,把车间管理从经验驱动转向数据驱动。

一、精准排产与进度透明,告别盲目赶工
机械组装订单交期紧、变更多,人工排产很难兼顾产能、物料、工装夹具等约束。通过数字化排产逻辑,可按订单优先级、工序工时、设备负荷自动生成最优方案,紧急插单也能快速重排。
工序进度通过终端实时上报,车间大屏与管理后台同步呈现每个工单的完成状态、在制品位置、异常节点。不用反复打电话、跑车间核对,计划调整更及时,交期达成率明显提升。
二、装配防错与物料齐套,减少返工损耗
精密机械组装最怕错装、漏装、混料。关键工位实行物料扫码校验,系统自动匹配型号与批次,不符合则无法进入下一工序;电子作业指导书同步推送图纸、扭矩参数、装配要点,降低对熟练工依赖。
物料齐套性提前预判,缺料、错料在开工前预警,减少线边停工等待。一次装配合格率提升后,返工成本、售后索赔与品牌风险同步下降。
三、全链路质量追溯,应对合规与售后核查
机械装备对安全与可靠性要求高,出现质量问题必须快速定位原因。从零部件入库、装配工序、检验数据到设备参数,全部与产品序列号绑定,形成完整追溯链条。
客户审核、售后溯源、批次召回都能一键查询,既满足行业合规要求,也降低质量事故带来的损失。
四、设备互联与工时自动核算,管理更精细
与拧紧枪、压装机、检测设备联动,实时采集工艺参数,异常自动预警;人员工时、设备稼动率自动统计,替代人工填报,数据更真实准确。
管理者可清晰看到瓶颈工序与低效环节,持续优化工艺与排班,实现降本增效。
五、落地思路:从小范围试点到全面覆盖
机械组装企业推进数字化不必一步到位,建议先选择一条核心产线试点,聚焦排产、报工、追溯等高频痛点,验证效果后再逐步扩展。重点做好流程梳理、岗位培训与数据标准化,让系统贴合现场实际,而非简单套用模板。

随着制造业竞争加剧,交期、质量、成本成为机械组装企业的核心竞争力。数字化生产管理不是可选升级,而是应对订单碎片化、利润趋薄的必要支撑。把车间“黑箱”打开,让数据流转起来,才能在稳定品质的同时提升效率,守住订单与市场。

城市GEO优化:从流量到留量的实战技巧
在本地生活服务竞争白热化的今天,单纯的线上曝光已远远不够。商家面临的真正挑战,是如何将平台上的“流量”转化为自己门店的“留量”——即能持续消费的忠实顾客。城市GEO优化服务正是解决这一痛点的核心策略。它通过对特定城市乃至商圈的地理位置进行精细化运营,实现流量精准触达与高效转化,最终提升门店的复购率与品牌忠诚度。

一、什么是城市GEO优化?为何它是胜负手?
城市GEO优化,简而言之,就是基于地理位置(Geography)的精细化内容运营与广告投放策略。在抖音和美团这类高度依赖LBS(基于位置的服务)的平台上,系统会优先将内容推送给附近的潜在用户。优化意味着:

更精准的曝光:你的内容或店铺信息,优先展示给同一城市、目标商圈的潜在客群。
更高的转化率:看到你信息的用户,本身就具有地理位置上的消费便利性,到店转化意愿更强。
强化本地品牌认知:持续深耕本地流量池,能在特定区域内建立起强大的品牌心智,成为“区域首选”。
从“流量”到“留量”的转变,核心就在于通过GEO优化,抓住那些“看得见、摸得着、来得快”的本地客户,并利用优质体验将他们沉淀下来。

二、抖音城市GEO优化实战技巧
抖音不仅是内容场,更是强大的本地生活兴趣转化场。

  1. 内容植入“地理基因”:
    在视频文案、口播、字幕中,多次强调城市、商圈、地标名称(如“北京三里屯必吃”、“南京新街口隐藏小店”)。
    积极使用和创建本地相关话题,如#北京吃喝玩乐#、#深圳周末去哪儿。
    发布内容时,务必定位到门店精确地址,并关联门店POI(兴趣点)。
  2. 善用本地推与DOU+:投放DOU+或本地推时,选择“自定义推广”,将投放范围精准限定在门店所在城市及周边,甚至可进一步筛选年龄、兴趣标签,让每一分钱都花在刀刃上。
  3. 打造“本地化”人设与互动:在直播或视频中,用方言问候、聊本地天气、近期本地热点事件,快速拉近与同城用户的心理距离。积极回复本地用户的评论,邀请他们“打卡”。
    三、美团城市GEO优化实战技巧
    美团是用户的主动消费决策平台,GEO优化直接关系到搜索排名和交易转化。
  4. 店铺信息完整与精准:确保门店地址、电话、营业时间100%准确。完善“门店招牌”、“环境”、“商品”等图片,并打上本地化标签(如“望京韩餐天花板”)。
  5. 关键词优化:在店铺名称、推荐菜名、商品标题及描述中,自然融入城市、区域、商圈名及核心品类词(例如:“【天河城】招牌酸菜鱼双人餐”)。
  6. 积极管理评价与问答:鼓励到店顾客撰写带图好评,尤其是提及地理位置便利性的好评。及时、专业地回复用户在大众点评/美团问答区提出的问题,建立专业可靠的形象。
  7. 活用平台营销工具:针对本地用户推出专属团购、限时秒杀、代金券,并利用平台的“附近发券”等功能,直接刺激周边用户的购买决策。
    四、从流量到留量:构建长效运营闭环
    优化曝光只是第一步,将顾客留下来才是终极目标。

线上引流,线下承接:通过抖音团购券、美团套餐吸引到店后,用出色的产品、服务与环境创造超预期体验。
构建私域流量池:引导顾客添加企业微信、进入社群,通过发放本地专属福利、活动预告,将一次性顾客转化为可重复触达的资产。
数据分析,持续迭代:定期分析抖音“本地数据中心”和美团的“经营数据”,了解客流来源、热门商品、用户画像,据此调整内容策略与产品组合。
总而言之,有效的城市GEO优化服务是一个系统工程。它要求商家深度理解平台本地流量的分发逻辑,并通过内容、数据、运营的精细组合拳,实现从广泛曝光到精准获客,再到顾客留存与复购的完整闭环。在本地生活赛道,谁先掌握“从流量到留量”的实战技巧,谁就能在城市的竞争中抢占先机,立于不败之地。

这篇文章是从 0 到 1 使用 AI 开发完整项目的第 5 篇文章,也是讲解用 AI 开发后端 API 接口的第一篇文章。

关于用 AI 来开发 API 接口的文章不会讲太多,因为其实大部分的框架部分最好还是自己写,用 AI 来辅助为好,当你把项目框架写清楚之后,简单的业务逻辑部分就可以直接交给 AI,让 AI 在你限定的框架之下去编程,这样不仅可以高效率的写代码而且还可以很好的保证代码风格的一致性。

好了,废话就不多说了。

直接拿我最近刚刚撸完的一个开源项目——Momento(时光账记) 后端 API 为例,手把手教大家如何利用 AI(Claude 3.5 Sonnet / Gemini Pro 等模型)从 0 到 1 构建一个高性能的 Go 微服务后端。

在讲解之前,先简单介绍一下时光账记小程序:

时光账记

时光账记是一款基于 Uni-app + Vue 3 开发的个人记账微信小程序,后端接口基于 go-zero 微服务框架构建。

这是一款专注于个人财务管理与生活记录的应用。它不仅支持非常简洁的方式来管理基础的收支记录,还提供了多账本管理、周期性自动记账、预算控制以及节日倒计时等贴心功能,帮助用户更好地管理个人及家庭财务。

现在我已将代码都开源了,感兴趣的朋友可以去观摩观摩,也请帮忙点个 Star 支持一下,谢谢!

小程序端(Uni-app + Vue3): https://github.com/pudongping/momento-miniapp
API 接口(Go + go-zero): https://github.com/pudongping/momento-api

前端部分 AI 占比 100%(自己一行代码都没写),接口部分 AI 占比 80%
这也是一套非常不错的 AI 练手项目,如果对你有帮助,希望帮忙点个 Star 支持一下,谢谢!

homepage.png

login.png

profile.png

recurring.png

transaction.png

项目背景与技术选型

我们要做的项目是一个记账小程序后端,核心功能包括:记账、多账本管理、多人协作、报表统计等。

技术栈:

  • 语言:Go 1.25+
  • 框架:go-zero(高性能微服务框架,自带代码生成神器 goctl)
  • 数据库:MySQL 5.7+
  • 缓存:Redis
  • 工具库:Squirrel (SQL 构建), Cast (类型转换)等

💡 第一步:架构设计与数据库建模

看过我这个系列文章的同学应该都知道,当时我写这个小程序的时候,我是先写的小程序端,然后才写的 API 接口。这么做的好处就是:

  • 整个项目本来就只有我一个人开发,先写页面,我完全可以确定好哪些功能需要,哪些功能可以后面再加
  • 用 AI 写的这个项目能不能符合我的设定,如果不能符合,可能我放弃的也可以早一点儿,就不那么折腾了

当我把页面确定好了之后,所有的数据,我都让 AI 帮我填充了 mock 数据,并且是模拟的接口数据,这样当我觉得功能上没有什么大的问题的时候,我就直接让 ai 以 mock 数据为基础,帮我写好接口文档,并备注清楚特殊逻辑。

有了这份接口文档,我就可以让 ai 根据接口文档帮我设计数据库和开发真实的接口了。

🤖 提示词 (Prompt) 1:数据库设计

我正在开发一个基于微信小程序的家庭记账应用“时光账记”。请根据我提供的接口文档帮我设计 MySQL 数据库 Schema。

核心需求:

  1. 用户体系:支持微信 OpenID 登录,记录昵称、头像。
  2. 账本 (AccountBooks):一个用户可以创建多个账本,支持多人协作(多对多关系)。
  3. 交易记录 (Transactions):核心表,记录金额、类型(收入/支出)、分类标签、备注、时间、图片凭证等。
  4. 标签体系 (Tags):支持系统默认标签和用户自定义标签。
  5. 周期性账单 (Recurring):支持每天/每周/每月自动记账。

技术要求:

  • 使用 MySQL 5.7 语法。
  • 所有表包含 created_at, updated_at 字段,类型为 int(11) (存秒级时间戳)。
  • 字段要有详细注释。
  • 使用 snake_case 命名规范。
  • 考虑到查询性能,请适当添加索引。

当然了,你也可以更加详细的给 AI 提要求,比如:

-- =============================================
-- 「时光账记」数据库建表语句
-- 数据库版本: MySQL 5.7
-- 字符集: utf8mb4
-- 排序规则: utf8mb4_unicode_ci

-- 规范如下:
-- 1. 时间戳: 所有时间戳字段均为秒级时间戳(INT(11) UNSIGNED)
-- 2. 每张表都会有创建时间(created_at)和更新时间(updated_at)字段,类型均为 INT(11) UNSIGNED NOT NULL DEFAULT 0
-- 3. 每张表除了特殊说明,均会有自增主键 id 字段,并且类型为 BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT
-- 主键命名规范为 “表名单数_id” 比如用户表 表名为 users 主键则为 user_id
-- 4. 如果表中需要自定义排序字段时,统一使用 sort_num 字段,类型为 INT(11) UNSIGNED NOT NULL DEFAULT 0
-- 5. 如果表中需要自定义状态字段时,统一使用 status 字段,类型为 TINYINT(1) NOT NULL DEFAULT 0
-- 6. 如果表中需要用到枚举类型时,统一使用 smallint(1) NOT NULL DEFAULT 0 并且一般起始值不为 0,比如 1-未支付 2-已支付
-- 7. 如果表中需要用到金额类型时,统一使用 decimal(10,2) NOT NULL DEFAULT 0
-- 8. 如果表中需要用到时间、日期类型时,统一使用 int(11) unsigned NOT NULL DEFAULT 0
-- 9. 如果表中需要用到布尔类型时,统一使用 tinyint(1) NOT NULL DEFAULT 1 一般使用 1-是 2-否
-- 10. 软删除时,统一使用 deleted_at 字段,类型为 INT(11) UNSIGNED NOT NULL DEFAULT 0
-- 11. 表字段一般不用 not null,需要设置默认值
-- =============================================

-- =============================================
-- 索引优化说明

-- 1. 所有外键字段都建立了索引
-- 2. 常用查询条件字段建立了索引
-- 3. 时间字段建立了索引,便于按时间范围查询
-- 4. 组合索引遵循最左前缀原则
-- 5. 唯一索引用于保证数据唯一性
-- =============================================

AI 会直接给你一套完整的 sql/momento.sql 文件,包含 users, account_books, account_book_members, transactions, tags 等表的建表语句,甚至连索引都帮你建好了。

然后你就可以根据自己的实际情况,将 AI 帮你生成的 sql 文件修修改改调整成符合自己设想的。

下一步,就结合 sql 文件以及接口文档去定义 go-zero 框架的 api 文件

第二步:API 接口定义 (DSL) —— 让 AI 帮你“写契约”

go-zero 的核心优势是 Design First(设计优先)。我们需要先写 .api 文件,然后自动生成代码。

🤖 提示词 (Prompt) 2:API DSL 生成

基于你刚刚设计的数据库 Schema 和我提供的接口文档,请帮我编写 go-zero 框架的 .api DSL 文件。

项目结构要求:

  • 主文件 miniapp.api 直接放在项目根目录下的 dsl 目录下,模块文件需要根据模块进行划分,放在 dsl/ 模块目录下(如 dsl/user/user.api, dsl/transaction/transaction.api)。
  • 遵循 RESTful 风格。

规范要求:

  • 每个接口都要有 Request 和 Response 结构体定义。
  • 使用 @doc 注解添加接口文档说明。
  • 列表接口需要包含分页参数 (page, per_page)。
  • 所有的 ID 字段在 JSON 中使用 string 类型(防止前端精度丢失),在 Go 结构体中使用 int64。

但是你会发现 AI 生成的 .api 文件也并不能百分百符合自己的要求,那么,此时就需要给 AI 更多的限定了。

我的做法是,直接在 dsl 目录下创建了一个 API_STYLE_GUIDE.md 文件,在这个文件中写清楚了我的各种要求。感兴趣的童鞋可以把项目拉下来之后进行查看。

API_STYLE_GUIDE.md

写业务代码

准备工作都已经做好了,那么如何让 AI 开始写符合自己代码风格的业务代码呢?

我的方法是,自己先写好“模版”代码。

  1. 首先,我自己简单封装了一些适合 go-zero 框架的基础方法,可以见 https://github.com/pudongping/momento-api/tree/master/coreKit 统一了相应数据格式、错误处理、参数验证等(但是,没有过度的封装)
  2. 自己去写一些基础的接口,比如登录、登出接口
  3. 然后直接让 AI 根据我的代码风格写出接口文档中的其他接口即可
  4. 当然了,还是得自定义 CLAUDE.md 文件,否则 AI 还是会“乱写”(下一篇文章就介绍写接口的 CLAUDE.md)

总结

通过上面这个项目的实战,我们可以总结出用 AI 编程的三个核心秘诀:

  1. Context is King(上下文为王):不要上来就让 AI 写代码。先给它数据库 Schema,先给它项目结构介绍。AI 懂你的项目越多,写的代码越准。
  2. Step by Step(分步执行):不要试图用一个 Prompt 生成整个项目。拆解任务:数据库 -> API 定义 -> 核心逻辑 -> 优化。
  3. Review & Refine(审核与微调):AI 也会犯错(比如类型转换错误、包引用错误)。你需要扮演 Tech Lead 的角色,Review 它的代码,并指出错误让它修正。

在 AI 时代,编程的门槛确实已经降低了不少,但架构设计能力将业务转化为技术需求的能力反而变得更重要了。掌握了这套方法论,你一个人就是一个开发团队!

🚀 关注我,下期教大家如何用 AI 写接口的 CLAUDE.md,敬请期待~

本文基于真实项目 Momento API 编写,项目已开源,欢迎 Star!

Pulumi宣布,Bun 现在已经成为 Pulumi 完全支持的运行时环境,不再像之前那样只是作为包管理器的角色。随着Pulumi 3.227.0的发布,开发人员可以在Pulumi.yaml文件中设置runtime: bun,然后由 Bun 执行整个基础设施程序,而不需要安装 Node.js。

 

在 2022 年首次发布时,Bun的核心理念很简单:基于 JavaScriptCore 而非 V8 打造一个更快的 JavaScript 运行时。此后,该项目的规模和目标都做了大幅的扩展。Bun 由 Jarred Sumner 开发,于 2021 年 5 月首次预览,并于 2023 年 9 月发布了 1.0 版本。该运行时的独特之处在于将包管理器、打包工具和测试运行器整合到了一个二进制文件中,所有组件均采用 Zig 编程语言构建,以 Apple 的 WebKit 引擎 JavaScriptCore 为基础。这与 Node.js 和 Deno 所使用的 V8 引擎完全不同。

 

该项目在被 Anthropic 收购后获得了重要的机构支持。此前,Anthropic 已经将该产品用于部署 Claude Code。Anthropic 表示,Bun “将继续开源并遵循 MIT 许可”,并且他们会继续推进开发,供广大 JavaScript 和 TypeScript 开发者使用。性能指标一直是其核心卖点:与 Node.js 相比,Bun 的启动速度快 4 倍(5–15 毫秒 vs 60–120 毫秒),包的安装速度快 6–35 倍。

 

自 Bun 1.0 发布以来,该集成一直是Pulumi GitHub 问题跟踪系统中需求最高的功能之一。有三个特性使 Bun 对 Pulumi 用户特别具有吸引力。首先是 TypeScript 的原生执行:Bun 可直接运行 TypeScript 文件,无需 ts-node 或单独的编译步骤,而这些步骤过去曾给 Pulumi TypeScript 工作流带来诸多不便。其次是更快的依赖项安装速度,这加速了 CI/CD 管道中基础设施程序的初始化过程。第三,Bun 致力于实现 100% 兼容 Node.js ,因此 Pulumi 现有的 npm 包应该能开箱即用。

 

当配置了runtime: bun时,Pulumi 会使用 Bun 来运行程序及管理包,不再需要单独配置包管理器选项。新项目模板可以通过pulumi new bun获取。

 

其中有一项值得注意的人机工程学改进涉及到了异步代码。在 CommonJS 格式的 Pulumi 程序中,如果要等待数据源加载,就需要在声明所需资源之前将程序封装在一个异步入口函数中。而得益于 Bun 对 ESM 的全面支持,顶层 await 可以在模块层面直接使用,不需要任何封装,这大大简化了程序结构。

 

如果团队有基于 Node.js 的 Pulumi 项目,可以通过更新Pulumi.yaml中的runtime字段进行迁移,同时调整tsconfig.json,使用 Bun 推荐的编译器选项(包括module: "Preserve"moduleResolution: "bundler"),并在package.json中添加"type": "module"来启用 ESM。

 

该版本存在两项值得注意的限制。Pulumi 的回调函数(有时被称为“魔法 lambda”)在 Bun 运行时下不被支持,因为它们依赖于函数序列化,而该功能又依赖于 Node.jsv8inspector模块(在 Bun 中尚未完全提供)。出于同样的原因,动态提供程序也不支持。依赖上述任一功能的团队应继续使用runtime: nodejs,但仍然可以通过在 Node.js 运行时配置中设置packagemanager: bun来使用 Bun 提供的更快的包管理功能。

 

Bun 运行时支持需要 Bun 1.3 或更高版本以及 Pulumi 3.227.0 或更高版本。

 

声明:本文为 InfoQ 翻译,未经许可禁止转载。

 

原文链接:https://www.infoq.com/news/2026/04/pulumi-bun-support/

整理 | 华卫

 

“SpaceXAI 与 Cursor 现已展开紧密合作,旨在打造全球顶尖的代码与知识工作类 AI。”

 

近日,SpaceX 突然宣布,已敲定一项协议:可在今年晚些时候以 600 亿美元收购代码生成初创公司 Cursor,或为双方新建立的合作关系支付 100 亿美元。作为一家销售编程 AI 模型的初创公司,Cursor 开发的工具可帮助软件开发者测试代码修改内容,并通过视频、日志与截图记录操作过程。与 OpenAI、Anthropic 一样,Cursor 是硅谷多家利用 AI 实现代码自动化的初创企业之一,吸引了大量开发者,AI 企业在这一领域已取得早期商业突破。

 

SpaceX 在 X 平台发文称,“Cursor 面向顶尖软件工程师的领先产品与分发能力,搭配 SpaceX 拥有百万片 H100 等效算力的 Colossus 训练超级计算机,将让我们打造出全球最具实用价值的模型。”Colossus 是 xAI 位于孟菲斯的超级计算机集群,该公司曾宣称其为全球规模最大。SpaceX 已在 AI 基础设施上投入数十亿美元。

挖角 Cursor 两月后,拿下全公司

值得一提的是,尽管 SpaceX 创始人兼首席执行官埃隆・马斯克旗下包括特斯拉在内的多家公司常有内部整合,但极少对外收购其他企业。Cursor 作为一家代码生成初创企业,看似与 SpaceX 的核心业务火箭发射和卫星互联网服务亦关联不大。

 

然而,对 xAI 来说,这笔交易将为其带来更强的 AI 代码市场立足点。xAI 是 Grok 聊天机器人的开发公司,今年 2 月 SpaceX 通过全股票交易收购了 xAI,将其结构化为全资子公司,合并后公司估值达 1.25 万亿美元。

 

AI 编程工具如今愈发火热,此前 xAI 一直在尝试开发编程工具,但该项目遭遇核心员工流失,一直落后于 OpenAI 与 Anthropic。旧金山初创企业 Anthropic 旗下编程产品 Claude Code 面向企业销售,收入大幅增长。OpenAI 也重金投入自研编程工具 Codex,并积极开拓企业市场。马斯克也曾公开承认,xAI 在代码生成能力上落后于竞争对手。在作出这一表态后,他下令在 xAI 进行了一轮裁员,并启动了激进的招聘计划,从全行业挖角工程技术人才。

 

今年 3 月,xAI 聘请了 Cursor 的两位产品工程核心负责人 Andrew Milich 和 Jason Ginsberg,来参与公司月球项目及马斯克旗下 AI 公司 xAI 的相关工作,以重新聚焦相关研发,两人均直接向 Musk 汇报。在此次人事任命公布后,马斯克发文称,“xAI 最初的搭建并不完善,因此正在从头开始重构。”同时,马斯克对这两位工程师 Andrew Milich 和 Jason Ginsberg 表示欢迎,并说道:“月球上的轨道航天中心与质量投射器将会无比震撼。”

 

这次通过与 SpaceX 达成的协议,Cursor 既可获得 100 亿美元的注资,也可在被这家火箭公司收购时拿到 600 亿美元的收购对价。也有据了解该交易的人士称,这 100 亿美元是交易未能达成时的“分手费”。

 

另外,一位知情人士透露,近几周这家初创公司本已在洽谈新一轮融资。据外媒上周末证实,Cursor 计划以超过 500 亿美元的估值筹集约 20 亿美元的新资金,本轮融资原定由 Andreessen Horowitz 联合领投,Nvidia 与 Thrive Capital 也预计参与。值得注意的是,Andreessen Horowitz 与 Nvidia 同样也是 xAI 的投资方。

Cursor 喜极:算力不愁,模型智能水平提升有望

总部位于旧金山的 Cursor 于 2022 年由 Truell、Sualeh Asif、Aman Sanger 和 Arvid Lunnemark 共同创立,几人曾在麻省理工学院相识。随着科技企业纷纷采用其开发的工具,这家初创公司迅速声名鹊起。成立不到两年,Cursor 的年度经常性收入(按月度收入推算至全年)便突破 1 亿美元。该公司也很快成为风投追捧的对象,从 Thrive Capital、Andreessen Horowitz 及 Accel 等顶级投资机构累计融资 34 亿美元。去年 11 月,Cursor 估值达到 290 亿美元。

 

但如今, Anthropic 与 OpenAI 推出的同类编程工具,给这家规模小得多的企业带来了巨大的竞争压力。并且,尽管 Claude 和 GPT 所属公司均已推出自研编程工具,Cursor 仍在使用并对外提供这两家模型的调用服务。这种处境颇为尴尬,而此次与 SpaceX 达成的新合作,或许正是为了最终摆脱这一局面。

 

对于这次合作,Cursor 联合创始人兼首席执行官 Michael Truell 在 X 上表态道,“很高兴能与 SpaceX 团队合作,推进 Composer 的规模化发展。这是我们致力于打造最佳 AI 编程平台道路上的重要一步。”

 

六个月前,Cursor 发布了智能体编程模型 Composer。此后,Composer 1.5 将强化学习规模扩大了 20 多倍。随后,Composer 2 又添加了持续预训练,仅以其他模型一小部分的成本,就达到了前沿级性能。

 

“算力每上一个台阶,都会切实转化为能力更强的模型。我们一直想把训练工作再向前推进很多,但始终受制于算力瓶颈。”Cursor 在发布的一篇博客中称,此前缺乏用于训练 AI 模型的算力,已成为其发展的瓶颈。与 SpaceX 的交易将使其能够使用 xAI 的 Colossus 基础设施,其中包含一台可用于训练 AI 模型的超级计算机,从而大幅提升其模型的智能水平。

 

上周就有外媒报道称,xAI 将开始将计算能力从数据中心租借给 Cursor,这家编程初创公司使用数万颗 xAI 芯片来训练其最新的 AI 模型。

 

“搭载百万片 H100 等效算力的 Colossus 超算,全力投入一个代码模型训练,再以 Cursor 的使用数据作为训练信号,这正是 SpaceX 今日宣布的核心布局。而这笔 100 亿美元的合作对价才是真正值得关注的数字。”有网友分析,它绝非一笔安慰金,而是 xAI 将面向专业软件工程师的分发渠道视作了堪比中型并购标的的战略资产,无论最终是否完成收购均是如此。IDE 领域的格局已基本定型:Anthropic 推出了 Claude Code,OpenAI 收购了 Windsurf,如今 xAI 也将 Cursor 纳入掌控,此前认为中立、不绑定单一模型的 IDE 能作为独立赛道占据开发者入口的前沿观点已然失效。对私募机构尽调开发者工具而言,核心护城河问题已经转变:不再是哪家 IDE 胜出,关键在于哪条分发渠道仍然可以独立拥有。

 

从商业层面看,Colossus 超算搭配 Cursor 数据是个明确的赌注,本质是赌代码生成的瓶颈仍受限于训练规模,而非模型架构或评估方式。Anthropic 基于完全相反的假设获得了很大的收益。18 个月内,这两种判断中必有一个会被证明明显正确,站错方向的资本方将为此付出代价。

 

“作为独立产品,Cursor 将面临更难的问题。它此前的核心价值是一流的用户体验以及对各模型无偏向的公平调用。一旦背靠前沿 AI 实验室,无论当前公告如何强调开放,长期来看,维持这种公平性的动力都会逐步减弱。依赖 Cursor 的开发者应提前做好准备,未来它很可能默认成为 Grok 的编程入口,并据此评估自身选择空间。”

IPO 前公开交易,为抬高估值铺路?

自去年起,马斯克便推动 SpaceX 布局 AI 项目,包括计划部署绕地运行的 AI 数据中心以及建设 AI 芯片工厂。今年,他又将 xAI 和 Cursor 都“收入” SpaceX 麾下。

 

现年 54 岁的马斯克表示,他认为太空探索与 AI 的目标密不可分。在致 SpaceX 员工、宣布收购 xAI 的一封信中,他写道,人类只有在太空部署数据中心、更高效利用太阳能后,才能成为多行星物种。“从长远来看,基于太空的 AI 显然是实现规模化发展的唯一途径。” 马斯克写道。

 

达成此项交易之际,SpaceX 正筹备公开上市,此次 IPO 有望成为史上规模最大的首次公开募股之一,目标估值接近 1.75 万亿美元,并计划融资 750 亿美元。目前尚不清楚其计划在最早可能于 6 月进行的上市之前,还是之后完成与 Cursor 的交易。这笔交易在此时公开或已对 SpaceX 的 IPO 计划带来影响,通过增强其在人工智能领域的实力,该公司可能寻求获得更高的估值,从而吸引那些热切布局人工智能下一阶段增长的投资者。

 

据外媒此前报道,SpaceX 董事会当前专门批给马斯克两项奖励计划。一是如果公司市值从 1.1 万亿美元攀升至 6.6 万亿美元,并且完成在太空建设数据中心的计划,马斯克将获得额外 6000 万股股票。随着市值每增加 5000 亿美元,这些股票就会分批归属。二是,如果公司达到股价目标并建立一个至少有 100 万居民的火星殖民地,马斯克将额外获得最多 2 亿股股票。

 

不过,据一位要求匿名的知情人士透露,SpaceX 并未立即收购 Cursor,原因就是这家火箭公司即将进行首次公开募股。一笔重大并购交易将要求该公司更新申报文件与财务细节,可能导致 IPO 推迟。

 

值得注意的是,在此前收购 xAI 与社交平台 X 之后,SpaceX 被广泛认为处于亏损状态,同时还在规划大规模的资本投入。该公司与 Cursor 的交易计划中也并未说明,这一交易是否会像收购 xAI 一样以 SpaceX 股票进行支付。

 

参考链接:

https://x.com/spacex/status/2046713419978453374

https://cursor.com/cn/blog/spacex-model-training

https://www.nytimes.com/2026/04/21/business/spacex-cursor-deal.html

 

整理 | 华卫

 

今天,谷歌正在对 AI 押下其史上规模最大的赌注之一。

 

在美国拉斯维加斯刚刚举办的 Google Cloud Next 大会上,谷歌云正式宣告 “智能体时代”来临。谷歌 CEO Sundar Pichai 宣布,公司今年计划投入 1750 亿至 1850 亿美元用于资本支出,远高于 2022 年的 310 亿美元,以搭建他口中 AI“智能体时代”所需的基础设施。

 

“随着我们步入智能体时代,我们正将相关布局推向新高度,我们正在为当下与未来进行大规模投资。”Pichai 表示。这场年度大会上,这家巨头展示了其在云计算、AI、安全与数据分析领域的最新创新成果,并发布一整套软硬件产品,核心亮点包括一个用于构建自主 AI 智能体的全新综合性平台以及谷歌第八代张量处理器(TPU)。

75%新代码由 AI 生成,全面转向智能体工作流

“我们在谷歌内部已经使用 AI 生成代码有一段时间了。如今,谷歌近 75%的新增代码由 AI 生成并由人类工程师审核通过。”据 Pichai 称,谷歌内部应用 AI 的比例近年来不断攀升。截至 2024 年 10 月,公司约四分之一的代码由 AI 生成。到去年秋季,这一比例已升至 50%。

 

据悉,谷歌工程师正使用 Gemini 模型生成代码,部分员工还被设定了具体的 AI 使用目标,这些目标将纳入今年的绩效考核。据外媒此前报道,近几个月来,部分 Google DeepMind 员工已被允许使用 Anthropic 的 Claude Code,这在员工内部引发了一些矛盾。

 

并且,Pichai 在昨日的一篇博客文章中表示,谷歌正全面转向真正的智能体工作流,让工程师执行更多自主化任务。Pichai 称,“近期,一项由智能体与工程师协作完成的高复杂度代码迁移任务,完成速度比一年前仅由工程师人工操作快了六倍。”

 

Gemini Enterprise 是被提及的重要角色,这是一套面向智能体时代的端到端系统,专为能够执行复杂多步骤工作流程的智能体打造。Pichai 强调,谷歌正将自身的工程部门当作实验室,充当 Gemini Enterprise 智能体平台的“首个试用客户”。“要成为最优秀的合作伙伴,我们始终希望成为自身技术的首个试用客户,”Pichai 表示。其目标是在谷歌级规模下对这些 AI 智能体进行实战检验,之后再将同款基础设施提供给全球云服务客户。

 

据 Pichai 介绍,该产品的付费月活跃用户数环比增长达 40%。Pichai 表示,“借助这一迅猛增长,我们看到,每家企业里的每一位员工都能成为创造者。这是一场意义非凡的转变,但也伴随着复杂性。有一点非常明确:我们已然坚定地迈入 Gemini 智能体时代。行业讨论的焦点已经从‘我们能否打造一个智能体?’转向了‘我们该如何管理成千上万个智能体?’”

 

为此,谷歌在大会上推出了面向开发者的 Gemini Enterprise Agent Platform,旨在为数据、人员与业务目标之间搭建安全、全栈式的 “连接纽带”,从而实现对智能体的优化调度。据介绍,Agent Platform 从 Vertex AI 开发者平台升级扩展而来,“整合了客户喜爱的 Vertex AI 模型选择、模型构建和调优服务,以及代理集成、安全、DevOps、编排等新功能”。该平台对现有 Gemini Enterprise 体验进行了全面升级,并提供超过 200 种模型,其中包括 Gemini 3.1 Pro、Nano Banana 2、Gemma 开源模型以及来自 Anthropic 的竞品模型,例如其刚刚发布的 Opus 4.7。

 

谷歌也正在自身生态体系内部构建这一“连接纽带”。运行在 macOS 上的 Gemini 应用,正是通过谷歌自研的 Antigravity 平台开发而成,这是谷歌内部一款 “以智能体为核心” 的开发平台,自主 AI 智能体可在浏览器中完成规划、编写代码与应用测试,仅需极少的人工干预。

 

“今年,我们将见证 AI 技术迈向新一轮发展阶段。”谷歌云 CEO Thomas Kurian 表示,“早期的 AI 模型主要侧重于回答用户问题、辅助完成创意类工作。而随着模型不断发展,现在人们希望把任务乃至一系列工作流程交给智能体去执行。这些智能体进而能够自主操作计算机,把整个谷歌云平台和 Workspace 当作工具来使用。”

 

不过,尽管大力推进智能体 AI,Pichai 强调,尽管 AI 参与比例很高,人类工程师仍然是最终的守门人,“代码的每一行都经过工程师审核和批准”。他表示,谷歌还将 AI 用于网络安全运营的部分自动化工作,帮助团队更快处理海量威胁情报、更迅速应对风险。 “每月,我们的团队会收到海量非结构化威胁报告,若人工审阅需耗费数千小时,几乎是不可能完成的任务,如今,我们安全运营中心的智能体每月自动对数万份非结构化威胁报告进行分类,快速提取关键情报并过滤无效信息,将威胁处置时间缩短了 90%以上;我们的安全防御比以往任何时候都更具主动性。”

 

值得注意的是,谷歌绝非唯一一家在代码编写上更多依赖 AI 的科技巨头。去年 4 月,微软 CEO Satya Nadella 表示,公司部分项目中 20% 至 30% 的代码由 AI 编写。同月,其 CTO Kevin Scott 称,他认为五年内 95% 的代码都将由 AI 生成。Meta 也在大力朝这一方向推进。截至 2025 年第四季度,该公司已设定目标:部分部门软件工程师的代码变更中,55% 需为智能体辅助完成。文件称,2026 年上半年,其创意部门预计有 65% 的工程师所提交的代码中,超过 75% 由 AI 编写。本月早些时候,Snap 表示,按照其新运营模式,至少 65% 的新代码由 AI 生成。

第八代 TPU 登场,专为“智能体时代”设计

这场“智能体 AI 革命” 的核心,是谷歌全新的 AI 超级计算机基础设施。大多数全力投入 AI 模型研发的公司,都在疯狂抢购英伟达的 AI 加速芯片,但谷歌选择了一条截然不同的道路,其云端 AI 基础设施大部分基于自研的张量处理器(TPU)系列。

 

谷歌提出,“智能体时代” 与以往的 AI 系统有着本质区别,因此需要全新的硬件设计思路。继 2025 年发布第七代 Ironwood TPU 后,谷歌在此次大会上推出两款专用第八代芯片,以满足自主智能体的海量算力需求。其中,TPU 8t(训练型)专为高速模型训练设计,可在单个超算集群中扩展至 9600 块 TPU;TPU 8i(推理型)专为 “近零延迟” 设计,确保 AI 智能体能够即时响应并执行任务。

 

在 AI 模型能够用于数据分析或生成趣味内容之前,必须先经过训练。TPU 8t 正是专为 AI 生命周期中的这一环节设计,旨在将前沿 AI 模型的训练周期从数月缩短至数周。谷歌将更新后的 Tensor 8t 服务器集群称为 “超算集群(pods)”,单个集群可搭载 9600 颗芯片,并配备 2PB 共享高带宽内存。谷歌称,TPU 8t 甚至支持线性扩展,单个逻辑集群可扩展至百万颗芯片。正是这类创新让超大规模 AI 模型的训练速度大幅提升,同时也推高了市场上的内存价格。

 

但对于参与构建巨型 AI 模型的机构而言,这套硬件能显著节省时间,单个集群算力达到 121 FP4 EFlops,几乎是上一代 Ironwood 训练算力上限的三倍。因此,新款芯片不仅训练速度更快,谷歌还表示 TPU 8t 的每瓦有效算力更高。该公司称其有效算力利用率达 97%,意味着更少的等待与算力浪费。凭借对非连续内存访问的优化、硬件故障自动处理,以及所有互联芯片的实时遥测监控,TPU 8t 能将更多时间用于高效推进模型训练。

 

训练完成后,AI 模型会以推理模式运行并生成 token,这是向模型下达指令时后台执行的过程。该环节无需同等算力,因此在 AI 生命周期的两个阶段使用同款硬件效率极低。这也是推理任务由 TPU 8i 负责的原因,它专为高效运行多个专业化智能体设计,延迟更低。相比上一代 Ironwood 推理集群仅 256 颗芯片的规模,TPU 8i 集群规模扩大至 1152 颗。单个集群算力为 11.6 EFlops,远低于 TPU 8t 集群。

 

谷歌将每颗 TPU 8i 的片上 SRAM 容量提升三倍,达到 384MB。这使得新款芯片可在片上存储更大的键值缓存,加快长上下文窗口模型的运行速度。第八代 AI 加速芯片也是谷歌首款完全采用自研 Axion ARM 架构 CPU 主控的产品,每两颗 TPU 搭配一颗 CPU。而在 Ironwood 时代,每颗 x86 CPU 需为四颗 TPU 提供服务。谷歌表示,这种基于 ARM 的 “全栈式” 方案能实现更高的运行效率。

 

据介绍,这两款芯片都将在今年晚些时候正式上市。未来,TPU 8t 与 TPU 8i 将支撑谷歌基于 Gemini 的智能体运行,同时也面向第三方开发者设计。两款全新 TPU 均兼容开发者现有使用的框架,包括 JAX、MaxText、PyTorch、SGLang 与 vLLM。同时,谷歌也宣布,将成为首批提供英伟达 Vera Rubin NVL72 系统的厂商之一,让客户可根据自身需求灵活选择最优架构。

数千亿美元的巨额 AI 投入,怎么赚回来?

在此次大会上,谷歌还展示了如何将巨额的 AI 支出转化为收入。这家科技巨头宣布设立 7.5 亿美元基金,助力其拥有 12 万名成员的谷歌云合作伙伴生态体系开发并落地智能体 AI 产品。该计划将提供工程支持、Gemini 模型抢先体验权限,以及面向埃森哲、德勤、麦肯锡等企业的激励政策。

 

展示 AI 投入变现路径的同时,花旗、前 OpenAI 高管 Mira Murati 创立的 Thinking Machines Lab 等企业也披露了如何借助谷歌的基础设施与 AI 工具推出新产品、训练前沿模型。花旗发布了“Citi Sky”,一款面向美国客户的 AI 驱动财富管理助手。与此同时,Thinking Machines Lab 宣布扩大对谷歌云 AI 超级计算机的使用,以加快 AI 研究与模型训练速度。

 

据一位知情人士透露,Thinking Machines Lab 已签署一份数十亿美元的新协议,扩大使用谷歌云的 AI 基础设施,合作内容涵盖使用基于英伟达全新 GB300 芯片搭建的谷歌最新 AI 系统,以及用于支持模型训练与部署的基础设施服务。据介绍,Thinking Machines 是首批使用其搭载 GB300 芯片系统的谷歌云客户之一,该系统在模型训练与推理服务速度上相较上一代 GPU 提升一倍。

 

今年早些时候,Thinking Machines 曾与英伟达达成合作,其中包括来自这家芯片厂商的投资。而本次是该实验室首次与云服务提供商签约。这笔合作并非独家协议,因此 Thinking Machines 未来可能会同时使用多家云厂商的服务,但这一动作依然表明,谷歌正试图提前锁定高速成长的前沿 AI 实验室。此前,Thinking Machines 推出了首款产品,这款名为 Tinker 的工具,可自动化创建定制化前沿 AI 模型。

 

谷歌在新闻稿中提到,其基础设施可支撑这家初创公司的强化学习算力负载,而 Tinker 的架构正是基于强化学习技术。强化学习这一训练方式,是 DeepMind、OpenAI 等实验室近年取得技术突破的核心支撑,而谷歌云这笔合作的规模,也反映出相关研究对算力的消耗极为巨大。

 

此外,谷歌一直在积极与 AI 开发者达成多项云服务合作,希望将自身 AI 算力服务与存储、Kubernetes 引擎、数据库产品 Spanner 等其他云服务打包整合。本月早些时候,Anthropic 与谷歌及博通签署协议,锁定数吉瓦的张量处理器(TPU)算力。但行业竞争十分激烈。就在本周,Anthropic 还与亚马逊签署新协议,获取最高 5 吉瓦的算力用于 Claude 模型的训练与部署。

 

一位 DA Davidson 分析师曾估计,谷歌的 TPU 业务加上 Google DeepMind AI 团队,将达到约 9000 亿美元的价值。

 

参考链接:

https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/cloud-next-2026-sundar-pichai/

https://www.businessinsider.com/google-ai-generated-code-75-gemini-agents-software-2026-4

https://techcrunch.com/2026/04/22/exclusive-google-deepens-thinking-machines-lab-ties-with-new-multi-billion-dollar-deal/

1. 现在后封机(换屏机,就是商家换成国产 FOG 精仿屏,移植屏幕绑定的芯片,然后把后盖、数据线换成精仿的)很泛滥,我看 PDD 和某宝、某 D 的百亿补贴的货都是从华强北发货的,这个有没有风险?而且看 DY 、XHS 、B 战等平台很多都中招了,普通人基本无法分辨;各位巨佬怎么看?
2. 考虑到后封机的问题,目前只想在官方渠道买( TB 的 APPLE SOTRE 官旗、官网、和直营店)
3. 厦门这边的线上国补券基本上是抢不到的,线下直营店我问了可以用补贴,不用抢
4. 重点来了,现在线下结合补贴是 5499 元,以现在这个时间点,巨佬们分析一下 618 期间官方会不会降价?大概能降多少幅度?

最近 AI 生图的能力强到可怕。

危险不在于“它能画得多好”,
而在于——普通人越来越难一眼分辨真假。

所以我做了一个很直接的小工具:《求真》

你上传一张图,
它会尽量从几个角度帮你做快速判断:

  • 来源痕迹
  • 元数据
  • 可疑生成/编辑信号
  • 风险等级,而不是装作全知的“最终判决”
  • AI 辅助分析

在假图满天飞的时代,给普通人一个低门槛的第一道筛子。

先放出来,边跑边改。

GitHub: https://github.com/sinyu1012/relly-web

地址: https://really-web-seven.vercel.app/

欢迎体验。

求真产品界面

公司让搞一个 AI 生成标书,没弄过标书,现在不知道如何下手,求大神给点思路或者有没有开源好用或者已经做过的使用比较好的 AI 标书系统

做了一款成语填字 APP ,名字叫做《多福单词》,对学习英语有诉求的,可以下载看看,送 50 个终生会员给各位大佬。

希望大佬们兑换了,能够顺手给个好评,独立开发不易,再次祝各位大佬,早日财富自由,早日赢取白富美。

========================

背单词是不是总让你昏昏欲睡?来试试用玩游戏的方式把单词刻进脑子里!

📱 多福单词 · 背单词猜字游戏

一款专为英语学习者打造的益智单词 App ,把枯燥的背单词变成每天最期待的事!

✨ 核心玩法
🔤 猜单词 — 字母连线、填字闯关,在游戏中自然记住拼写和释义

🔗 连线拼字 — 拖动字母连成正确单词,强化拼写记忆,简单上手

⚡ 单词接龙 — 根据上一个单词末字母快速接龙,越玩越上瘾

📅 每日一词 — 每天精选词汇配例句,坚持一年积累 365 个新单词

🏆 单词闯关 — 从基础词汇到四六级常考词,循序渐进解锁新挑战

👥 适合人群
无论你是备考四六级、考研的学生,还是想利用碎片时间充电的上班族,每天 10 分钟就有效!

fdff986d430ced6ff28d6fe8c76f773b.jpg

wei-xin-tu-pian-20260424095306-262-40-fu-ben.jpg

========================

3ARJKET8F63PEY44EE
4E4WKPXJMK84TTWN3H
6LNYLP6RHYA6H7MAFW
44MEWA4PNA8TMHA4J8
Y83TEFL6Y68A8PYW7T
TYNHMFHPELN8YXA4FK
YWYW4ERY7FEA3AH66K
TKT7PPXKH8XP877YRY
Y6ANMF3ERHAL8KPHXR
LNF3EWWMXWK6L4YXH7
NJ4FEY8NPXLW4L3AH8
YYRKXFN74FJXJ7JT77
TRTYALHLAAH8ALTFT6
R786YK8MN4WK4JL6TM
EXLX7P8MFPAHJFPRFE
MAFY3LY6RNXMK8KHPY
87WNANMAJWLATF374A
4PLRXHPFWXJXFHKRH3
APKNFTTP6YL43ANK7W
PKWJ7MAW3AFJ4R86P4
86YYPW7KEJLLK4RWXN
MRYRXTAWXT8EATY6JY
38JLHXH8XXLPAH6RYH
AXNKN87MWTFF3MTJAX
RF8J76TWKL6HFXWHTF
M6A3MWXNL4XTNLK87L
T3MH3YJMHJW7P4AK7F
MLN7RKXNX3HL7JR387
RYWLMFRJHN67JNHWTP
WFXAWKYXWNXH8RR64Y
T74FJM8LA638RR7XWL
EEEPHYKY6TN8LAFYYM
J8HRTJ3YWW8P3YA6F7
F4W3Y4NJA8KJAAPR8A
77FELPYTXWW7AA8WMR
R38A4TYJEHHXTRH4JP
6PX8AX8NEFT8F4HHPX
XK47XPYE3TKMJKMPEP
737RERKKANHWLFRMPE
YFJYWELENTRFJ47P3R
KR6LT6EYKWWWENPRX8
6FWPNN3PRENHJ4Y3L8
FJRJ7TE3JAJXMYL88E
8WPT7EHWH8THX3PFTF
4WKHMMNW6HKERMXNMR
EJTNYT3FM4R36E47HK
MRFT7TJE43HELLR38J
TRFMNMKHYF68TK48KL
NYE6TNL4YN847ARFMJ
6ENN6PFFEFN8HF73Y6
3E8FRWRE7JYXYJKWMH
HHF47TWKPXT7PPA68N
AKEE6EEEJRE37AERMA
F3ALP8LYJLANTA8HNX
6RJ6HWPKMYF4LMNTFL
NL4ELR6A38N44TP7R6
PH6FHW63JMW3W46KJ8
XHWE6HXA647AX87X6X
KL4TMYX44NNEWXTPH7
HWRLT4PMKYAF6H8K44
74E84WKMWYYMY4TX3X
XX8RAF33EKLL3L68EY
WWXHTHXJ38P6YMPWWW
XKFE3XJJ6AXW3E7T6P
J6EM487ERTM643N3HT
A8M67NTFJKKTPAF43X
4PJEXTHXWRHF7MLFTK
LXJFM78RTLN48JRR8J
RRPLYARL666X44LKJJ
N34RWRYPARWLEYTTLL
MH847NLRXYYYWX6ARR
TR8PFK6NXMAEEYXKHJ
6PY488MT6RXTN4RMW4
4FATXMN4TXEEHYANXP
84JFWL6ERLK8XHHKFY
HE786EYEJYMN6F7M3R
LHJKJRLA8JKTAWE6FT
X6XYLAT6N8TF3RJ8X8
HP6WJXJJTLHXF4W3RF
FN644MHMW37E7Y8KMA
PLE3TJLLNX7PYX4L3K
E76KHNRXN6MYF7XPN8
R34EXJX334YTERA7P4
EM4YJ483XX8NJJJJN8
7PH6YHLW8LH346E6XX
EHRJL3YJ4PK3LPMNLM
RNJPTNWHTJNH7EAXWF
K4YXE6JLP74H4X8KNH
A7R774WKE6LPHXFR43
LK8T4E8WYRXLFAFHWK
APYYPN6ATAXFAKF778
8X8A3JFTHFA4T8LNLM
EPJN6KTFATYTXK3EME
3PT7JHLPATRWAN8K3F
JR8X6XT7YY3WT74XM7
HYRJXLHXW4NL44H6HN
HHXKLPFKY4KM4X8FHE
RKY467T64WXN4MHT4L
YJHFYT3HPFHPY8H6MH
FEWYTARRRLW3438KRP

上班公司内网连百度都访问不了,遂用自己的手机流量来上班。

我的是移动的电话卡,梯子使用的节点是自己搭建的。

访问 google 的时候每隔十几分钟,就有卡顿,现象是访问 google 的时候,一直转圈圈,页面白屏;但是访问国内网站都是很流畅的。

可能原因:1. 手机发热导致网络卡顿,这个卡顿应该会对访问国内网站也造成影响;真实情况是访问国内网站很流畅。
2. 节点:使用自建的美国服务器节点,加上 cloudflare 优选 ip ,我认为应该没啥问题。
3. 移动公司:移动公司加大了监管,把我的境外数据先抓起来分析了一波,觉得没啥问题,才放行造成了卡顿(我瞎猜的)

对于规模在5人以内的产品设计团队来说,"设计完成"往往只是挑战的开始。设计稿如何准确传达给开发?标注是否与实现效果一致?代码交付后的细节调整由谁负责?这些问题在大厂有专职分工,但在中小团队里,设计师往往需要独自面对从需求拆解到前端代码落地的完整链条。
AI工具的出现正在重构这套流程。本文梳理了四款覆盖"原型-视觉-交付-代码"各阶段的工具,帮助设计师在不依赖额外人力的前提下,独立完成从产品原型到可交付代码的全流程。
关键要素:
中小团队设计师覆盖全流程的核心是选对工具组合,而非逐步习得所有技能。以 UXbot 处理从需求到原型再到代码的一体化生成,以 Figma 完成精细化视觉设计,以 Zeplin 规范设计交付文档,以 Cursor 辅助代码微调,可以在不扩充团队的前提下完成一套完整的交付流程。

一、为什么设计师需要覆盖代码交付环节

根据 Nielsen Norman Group 2024 年的研究,设计与开发之间的沟通摩擦平均占据项目总工时的 18% 到 25%。对于中小团队,这个比例往往更高——一名开发人员需要独立消化设计意图、处理标注缺失、反复对齐细节,每次迭代都在消耗宝贵的时间窗口。
当设计师能够直接输出可执行的前端代码,或至少提供可读性强的代码框架,这种摩擦会大幅降低。AI 工具的加入让这个路径变得可行,而不再需要设计师花费数月学习编程。

二、四款工具覆盖全流程

1. UXbot

UXbot 是目前少数能够将需求描述直接转化为多页面可交互原型、并同步生成可交付前端代码的 AI 工具。对中小团队的设计师来说,它把通常需要三个角色协作完成的工作压缩到一个人的单一工作流中。
整个流程分为五个步骤。第一步以自然语言输入产品需求,不需要结构化文档,一段描述即可启动;第二步进入流程画布,确认并调整整个产品的页面结构和用户旅程,这一步决定了后续生成内容的准确性;第三步系统生成完整多页面界面,内置模拟器支持在 Web 端和移动端直接验证交互流程,设计师可以检查页面跳转是否符合预期;第四步使用精准局部编辑功能,在不重新生成全部内容的前提下定点修改细节;第五步导出代码,支持 HTML、Vue.js、Kotlin(Android)和 Swift(iOS)等格式,导出后可直接在云端运行。
这套流程的关键在于原型与代码始终保持一致——设计师在原型阶段确认的效果,就是代码导出后运行的效果,不存在设计稿与实现之间的"翻译误差"。
image1.png

2. Figma

Figma 依然是中小团队视觉设计阶段的核心工具,尤其适合需要多人实时协作的场景。在 AI 工具生成初步原型后,设计师可以将视觉规范、品牌色彩、组件库等精细化工作在 Figma 中完成。
Figma 的组件化设计体系对中小团队尤其友好——一次定义全局样式,后续所有页面自动同步,避免了因人员变动导致的设计风格漂移。Dev Mode 功能可以将设计稿自动转换为 CSS 属性标注,减少设计师向开发说明参数的沟通成本。根据 Figma 官方数据,使用 Dev Mode 的设计团队平均减少了约 30% 的设计开发沟通往返次数。
image2.png

3. Zeplin

Zeplin 专注于设计交付的最后一公里:将设计稿转化为开发可直接使用的规范文档。对于设计师和开发分属不同职责的中小团队,Zeplin 提供了一个中立的交付平台,让开发人员可以自助查看间距、字体、颜色等参数,而不必反复打扰设计师。
Zeplin 支持与 Figma 的直接同步,设计师在 Figma 更新后可以一键推送到 Zeplin,开发侧自动获得最新规范。对于需要维护多个平台(Web、iOS、Android)设计规范的团队,Zeplin 的多平台组件管理功能能够显著减少重复工作。
image3.png

4. Cursor

Cursor 是一款基于 AI 的代码编辑器,对设计师同样实用——尤其是那些需要微调 AI 生成代码的人。当 UXbot 导出的前端代码需要进一步适配特定业务逻辑时,Cursor 的 AI 对话功能可以帮助设计师用自然语言描述修改意图,由 AI 完成代码调整,无需自行编写。
Cursor 支持对代码库进行全局搜索和语义理解,设计师可以描述"将所有按钮的圆角从 8px 改为 12px",Cursor 会在整个项目中定位并执行修改,而不是逐文件手动处理。
image4.png

三、四款工具的协作方式

这四款工具并不是相互独立的,在实际工作流中可以按阶段串联使用。需求输入与结构规划阶段使用 UXbot,通过流程画布确认产品架构,生成可交互的多页面原型并导出初版代码;视觉细化阶段切换到 Figma,将品牌规范和精细化设计落地,形成最终设计稿;交付阶段通过 Zeplin 生成标注文档,开发团队依据规范实现细节;代码调试与优化阶段借助 Cursor,处理 AI 生成代码与业务需求之间的差异。
这套工具链的核心逻辑是:每个工具专注于自己最擅长的环节,减少任何单一工具承担过多职责带来的局限性。

四、常见问题解答

Q1. 中小团队的设计师需要具备编程基础才能使用这套工具链吗?

不需要编程基础来启动这套流程。UXbot 和 Cursor 均支持自然语言操作,设计师可以描述意图而非编写代码。Figma 和 Zeplin 本身也是设计侧工具。唯一需要积累的是如何阅读 AI 生成的代码输出,以便判断是否符合交付要求,这对大多数设计师来说是可以在实践中快速上手的能力。

Q2. 这套工具链适合完全没有开发人员的团队吗?

部分适合。UXbot 可以直接生成可运行的前端代码,Android 项目还支持导出 APK,能够满足原型演示和早期产品验证的需求。但在面向真实用户的生产环境中,仍然建议至少配置一名能够处理服务端逻辑和数据接口的开发人员。这套工具链的目标是减少开发依赖,而不是完全替代开发。

五、开始你的第一个全流程项目

工具链的价值不在于同时掌握所有工具,而在于先用一套流程跑通一个真实项目,再根据短板调整工具组合。如果你还没有尝试过 AI 辅助的设计到代码流程,不妨从 UXbot 的需求输入开始——输入一段产品描述,看看 AI 生成的多页面原型与你预期的产品结构有多接近,这个过程本身往往就是重新审视产品需求的最好方式。

各位道友,你们认为能够写在简历上的 Java Agent 有哪些?本人苦于一个 Java Agent 项目,准备用于实习。thanks