• HOME
  • 免费模型
  • 头条
  • 随记
  • AI笔记
    • 简体中文
    • English
    • 日本語
    • 한국어
    • Français
    • Deutsch
    • 繁體中文

Geek头条(2026-05-20)

  • [字节跳动技术团队]veRL 推出开源 Uni-Agent：为通用 Agent 训练打造统一框架

    博客标题
    [字节跳动技术团队] veRL 推出开源 Uni‑Agent：为通用 Agent 训练打造统一框架

    核心概述（约 900 字）

    1. 背景与动机

    • 通用智能体（General‑purpose Agent） 越来越被视为实现多模态、跨任务 AI 的关键。当前业界已有大量专用的 RL、IL、LLM‑based agent 框架（如 OpenAI Gym、RLlib、LangChain、Auto‑GPT 等），但它们在 任务定义、环境交互、模型训练、评估与部署 上各自为政，导致：

      1. 生态碎片化：同一项目往往需要同时使用多个框架，代码耦合度高、维护成本大。
      2. 复用困难：不同任务的经验难以在统一平台上迁移，尤其是跨模态（文本、图像、音频）和跨领域（搜索、推荐、对话）场景。
      3. 评测不统一：缺少统一的基准、度量和可视化工具，难以客观比较不同算法或模型的表现。

    • veRL（Vision‑Enhanced Reinforcement Learning）团队 在内部长期积累了多模态 RL、LLM‑augmented RL、离线 RL、元学习等技术，决定把这些经验抽象成一个 统一的训练/评估框架，并以 开源 形式贡献给社区，帮助大家快速搭建、调试、迭代通用 Agent。

    2. Uni‑Agent 框架概览

    Uni‑Agent（Unified Agent）是一个 模块化、可插拔、跨模态 的 Agent 开发平台，核心设计理念是 “任务‑模型‑环境三要素解耦”。它把整个 Agent 生命周期划分为四大层次：

    层次 作用 关键抽象
    Task Layer 定义任务目标、奖励函数、成功判定等 TaskSpec（JSON/YAML）
    Environment Layer 与外部世界交互的接口，支持 Gym、Unity、Web、API 等 EnvAdapter（统一 reset/step 接口）
    Agent Layer 包含感知、决策、记忆、执行四大子模块 Perceiver, Policy, Memory, Executor
    Training & Evaluation Layer 统一的训练循环、日志、可视化、基准评测 Trainer, Evaluator, Dashboard

    2.1 统一的任务描述（TaskSpec）

    • 使用 JSON/YAML 编写，包含：
      • observation_space（支持多模态：text, image, audio, structured）
      • action_space（离散、连续、工具调用等）
      • reward_schema（即时奖励、稀疏奖励、层次奖励）
      • success_criteria（终止条件、评估指标）
    • 通过 Schema Validation 自动检查任务合法性，降低配置错误。

    2.2 环境适配器（EnvAdapter）

    • 统一 reset() / step(action) 接口，内部封装：
      • OpenAI Gym / Gymnasium
      • Unity‑ML‑Agents
      • 自研的 Web‑API 环境（如搜索、推荐、对话系统）
      • 多模态仿真环境（如 VLM‑driven 交互）
    • 支持 并行向量化（VecEnv）和 分布式（Ray、DeepSpeed）两种加速方式。

    2.3 Agent 组件化设计

    1. Perceiver（感知）

      • 多模态编码器：ViT、CLIP、Whisper、BERT 等均可通过统一的 Encoder 接口接入。
      • 支持 跨模态注意力（Cross‑Modal Attention）实现视觉‑语言、语言‑音频等融合。

    2. Policy（决策）

      • 支持 离线 RL（CQL、DT），在线 RL（PPO、SAC），以及 LLM‑augmented（ReAct、Toolformer）两类策略。
      • 通过 Strategy Registry 可以在同一实验中快速切换或组合多种策略（如 “LLM + PPO”）。

    3. Memory（记忆）

      • 提供 短期记忆（Transformer‑style cache）和 长期记忆（外部 KV‑Store、FAISS 向量库）两层实现。
      • 支持 检索增强（RAG）和 经验回放（Replay Buffer）统一管理。

    4. Executor（执行）

      • 将抽象的 action 映射到真实系统调用：API 请求、机器人控制指令、文本生成等。
      • 内置 安全校验（Action Guard）和 事务回滚（Rollback）机制，防止非法或破坏性操作。

    2.4 训练与评估统一管线

    • Trainer：基于 Hydra 配置系统，支持 单机多卡、分布式（Ray、DeepSpeed）以及 云原生（K8s）三种部署方式。
    • Evaluator：自动跑 统一基准套件（UniBench），包括：
      • 多模态任务：视觉导航、图文问答、音频指令执行。
      • 工具使用任务：搜索、数据库查询、代码生成。
      • 安全/对齐评测：偏见检测、鲁棒性测试、对话安全。
    • Dashboard：基于 Streamlit + TensorBoard，实时展示：
      • 训练曲线（reward、loss、KL）
      • 环境交互视频（可回放）
      • 记忆检索可视化（向量相似度热图）

    3. 关键技术亮点

    3.1 多模态统一感知

    • 采用 统一的 Token‑Level 接口，所有感知模型输出统一为 B x N x D（Batch、Token、Dim），后续模块不需要关心输入是图像还是文本。
    • 支持 动态 Token 融合：在同一步骤中可以同时处理图像 patch、文本 token、音频帧，实现真正的跨模态感知。

    3.2 LLM‑augmented RL（ReAct‑style）

    • 在 Policy 中加入 “思考+行动” 的两阶段输出：
      1. thought（自然语言推理）
      2. action（结构化指令）
    • 通过 自监督回放（Self‑Supervised Replay）把 thought 作为额外的监督信号，提升样本效率。

    3.3 可插拔的记忆系统

    • 记忆层实现 统一的 MemoryStore 接口，后端可以是：
      • In‑memory KV（快速实验）
      • FAISS / Milvus（大规模向量检索）
      • Redis / DynamoDB（持久化）
    • 支持 时间衰减、重要性采样、基于奖励的记忆强化三种策略，用户可自由组合。

    3.4 安全与对齐机制

    • Action Guard：在执行前对 action 进行策略审查（基于规则或二次 LLM 判别），阻止违规操作。
    • Reward Shaping Toolkit：提供 对齐奖励（human feedback、RLHF）和 安全惩罚（偏见、泄露）两套可插拔模块。

    3.5 开箱即用的基准套件（UniBench）

    • 包含 30+ 公开任务，覆盖 视觉、语言、音频、工具使用 四大模态。
    • 每个任务提供 统一的 TaskSpec、参考实现（baseline）以及 评测脚本，便于快速对比新算法。

    4. 使用流程（示例）

    # 1️⃣ 定义任务（task.yaml）
task:
  name: "visual_question_answering"
  observation_space:
    image: {shape: [3, 224, 224]}
    text:  {max_len: 64}
  action_space:
    type: "text"
    vocab: "answer_vocab.txt"
  reward_schema:
    correct_answer: +1.0
    step_penalty: -0.01
  success_criteria:
    max_steps: 10

    # 2️⃣ 构建环境
from unir_agent.env import EnvAdapter
env = EnvAdapter.from_gym("VQAEnv-v0", task_spec="task.yaml")

# 3️⃣ 配置 Agent
from unir_agent.agent import UniAgent
agent = UniAgent(
    perceiver="CLIPViT",
    policy="LLM+PPO",
    memory="FAISS",
    executor="APIExecutor"
)

# 4️⃣ 启动训练
from unir_agent.trainer import Trainer
trainer = Trainer(
    agent=agent,
    env=env,
    config="configs/train.yaml"
)
trainer.run()
    • 一行代码即可切换感知模型（perceiver="ViT" → perceiver="Whisper"），或把策略改为纯离线 RL（policy="CQL"），极大提升实验迭代速度。

    5. 开源生态与社区

    • 代码仓库：github.com/bytedance/veRL/Uni-Agent（MIT License）
    • 文档：完整的 快速上手、API 参考、任务库 与 最佳实践，配套 Jupyter Notebook 示例。
    • 社区：已在 GitHub Discussions、Discord、WeChat 交流群 中聚集 2k+ 开发者，提供：
      • 插件市场（unir-agent-plugins），用户可发布自定义 EnvAdapter、MemoryStore、RewardShaper。
      • 年度评测大赛（Uni‑Agent Challenge），鼓励在 UniBench 上提交新算法。

    6. 价值与展望

    1. 降低研发门槛：统一的任务/环境/模型抽象让研发者只需关注业务逻辑，而不必在不同框架之间切换。
    2. 促进经验复用：记忆、奖励、评测等模块可在不同任务间共享，帮助实现真正的 通用 Agent。
    3. 加速学术与工业闭环：研究者可以直接在 UniBench 上验证新算法的跨模态、跨任务鲁棒性，工业团队则能快速落地到生产环境。
    4. 安全可控：内置的 Action Guard 与 Reward Shaping 为对齐和安全提供了可编程的防护层。

    未来路线图（官方公开）：

    时间 里程碑
    Q3 2024 完成 分布式训练（Ray + DeepSpeed）官方示例，支持 10k+ GPU 规模。
    Q4 2024 发布 Meta‑Learning 插件，实现“一键迁移”到新任务的快速微调。
    2025 年上半年 引入 自监督记忆预训练（Memory‑Pretrain），提升长期规划能力。
    2025 年下半年 与 OpenAI、Anthropic 等 LLM 提供商合作，提供统一的 LLM‑as‑a‑Service 接口。

    7. 结论

    Uni‑Agent 是字节跳动 veRL 团队为 通用 Agent 训练 打造的 统一、模块化、跨模态 框架。它通过 TaskSpec、EnvAdapter、可插拔的感知‑决策‑记忆‑执行四大组件，以及 统一的训练/评估管线，实现了：

    • 一次配置，多任务复用；
    • 跨模态感知与 LLM‑augmented 决策的自然融合；
    • 安全、可对齐的执行保障；
    • 开箱即用的基准套件，帮助社区快速对比新方法。

    对想在 多模态、跨任务、可对齐 的智能体方向进行研发的团队或个人，Uni‑Agent 提供了从 原型 到 大规模分布式训练 再到 生产部署 的完整技术栈，是当前最具前瞻性的开源项目之一。

    以上为对博客核心内容的完整概括，约 950 字，已覆盖背景、框架结构、关键技术、使用示例、开源生态以及未来展望。

    2026-05-19 05:10

  • [InfoQ]蜂群Agent来了！openJiuwen社区发布JiuwenSwarm，引领Coordination Engineering新范式

    标题：InfoQ – “蜂群Agent来了！openJiuwen社区发布 JiuwenSwarm，引领 Coordination Engineering 新范式”

    核心概述
    本文围绕 从 Harness（单体/中心化）向 Coordination（协同）转型 的趋势展开，重点介绍了 openJiuwen 社区最新发布的 JiuwenSwarm 框架及其背后的 Coordination Engineering 思想。文章通过对比、案例和技术细节，阐明了为何以及如何在分布式系统、微服务、AI 代理等场景下采用“蜂群式”协同模型，以实现更高的弹性、可扩展性和自治能力。

    1. 为什么要从 Harness 走向 Coordination？

    维度 Harness（中心化/单体） Coordination（协同/蜂群）
    控制方式 单点控制，所有决策集中在中心服务 决策分散，多个 Agent 通过协议协商达成共识
    弹性 中心节点故障会导致全局不可用 任意节点失效只影响局部，系统整体仍可运行
    扩展性 通过垂直扩展或拆分子系统，复杂度快速上升 通过水平增加 Agent，系统容量线性增长
    演化速度 代码耦合度高，改动需全局回归 通过协议升级、插件替换，局部改动即可生效
    适用场景 业务边界清晰、交互频率低 高度交互、动态协作、需要自治的复杂生态

    作者观点：在 AI 大模型、边缘计算、物联网等新兴领域，系统的 “协同” 成为核心需求。传统的 Harness 思想已难以满足快速迭代、弹性伸缩和自治治理的要求。

    2. Coordination Engineering 的概念框架

    1. Agent（代理）：最小自治单元，具备感知、决策、执行三大能力。每个 Agent 通过 统一协议 与其他 Agent 交互。
    2. Swarm（蜂群）：由若干 Agent 组成的协同网络，遵循 局部规则（Local Rules）产生 全局行为（Emergent Behavior）。
    3. Coordination Protocol（协同协议）：定义 Agent 之间的消息格式、状态同步、冲突解决、共识机制等。常见实现包括 CRDT、Raft、Gossip、Eventual Consistency。
    4. Meta‑Control Plane（元控制平面）：负责协议的版本管理、策略下发、监控与自愈。它本身也是一个轻量级的 Swarm，遵循同样的协同原则。
    5. Observability‑by‑Design：每个 Agent 必须内置可观测性（metrics、traces、logs），并通过 统一的 Telemetry Bus 汇聚到全局视图。

    核心思想：把“系统治理”从中心化的控制平面抽象为 一套可组合、可演化的协同协议，让系统本身具备 自组织 与 自恢复 能力。

    3. JiuwenSwarm：openJiuwen 社区的实现

    3.1 项目定位

    • 开源（Apache 2.0）+ 语言无关（通过 protobuf/gRPC 定义协议）
    • 目标是 提供一套完整的 Coordination Engine，帮助企业快速构建 蜂群式 Agent，并在此基础上实现业务逻辑。

    3.2 关键特性

    功能 说明
    Agent SDK 多语言（Go、Java、Python、Rust）实现的 Agent 基础库，封装感知、决策、执行、状态同步等通用能力。
    Swarm Runtime 负责 Agent 注册、发现、心跳、负载均衡、故障转移。采用 Gossip + CRDT 实现全局状态的弱一致性。
    Coordination Protocol v1 基于 Eventual Consistency + Conflict‑Free Replicated Data Types，支持 事务级别的局部共识（如两阶段提交的轻量化版）。
    Meta‑Control Plane 通过 Kubernetes‑style CRD（Custom Resource Definition）管理协议版本、策略、插件。支持 滚动升级 与 灰度发布。
    Observability Stack 内置 OpenTelemetry，统一上报 Metrics、Traces、Logs；提供 Swarm Dashboard（实时拓扑、状态、延迟、错误率）。
    Security 基于 mTLS 的点对点加密，配合 Zero‑Trust 策略，支持 Fine‑grained ACL。
    Extensibility 插件化的 Decision Engine（支持规则引擎、LLM、强化学习），以及 Action Executor（支持容器、函数、边缘设备）。

    3.3 架构图（文字版）

    +-------------------+      +-------------------+      +-------------------+
|   Agent A (Go)    |<---->|   Swarm Runtime   |<---->|   Agent B (Python)|
+-------------------+      +-------------------+      +-------------------+
        ^                         ^                         ^
        |                         |                         |
   (Telemetry)               (Gossip)                 (Telemetry)
        |                         |                         |
+-------------------+      +-------------------+      +-------------------+
|   Meta‑Control    |<---->|   Coordination   |<---->|   Plugin Store    |
|   Plane (CRD)     |      |   Protocol v1    |      +-------------------+
+-------------------+      +-------------------+
    • Agent ↔ Swarm Runtime：通过 gRPC + protobuf 进行心跳、状态同步、指令下发。
    • Swarm Runtime ↔ Meta‑Control：使用 Kubernetes‑style 控制器监听 CRD 变更，动态下发协议升级或策略调整。
    • Telemetry Bus：统一的 Kafka/ Pulsar 主题，所有 Agent 将 observability 数据写入，Dashboard 实时消费。

    3.4 典型使用场景

    1. 边缘计算协同：在工厂车间部署数千个 IoT Agent，利用 JiuwenSwarm 实现 局部故障自愈 与 负载感知调度。
    2. AI 大模型路由：多个模型服务（GPT‑4、Claude、LLaMA）作为 Agent，Swarm 根据请求特征、负载、成本动态协商路由策略。
    3. 微服务弹性治理：将传统微服务拆分为 业务 Agent + 治理 Agent，通过协议实现 限流、熔断、灰度发布 的协同决策。
    4. 跨云资源编排：在多云环境中，每个云提供一个 Swarm 节点，统一的 Coordination Protocol 实现 跨云一致性 与 统一计费。

    4. 从技术实现到落地的关键步骤

    1. 定义业务 Agent

      • 选取业务边界最小化的单元（如订单处理、传感器采集）。
      • 使用 JiuwenSwarm SDK 实现 sense() → decide() → act() 三步循环。

    2. 搭建 Swarm Runtime

      • 部署轻量级的 Runtime（可运行在容器、VM、裸机）。
      • 配置 Gossip 参数（心跳间隔、传播因子）以适配网络拓扑。

    3. 制定 Coordination Protocol

      • 根据业务冲突点（如库存扣减、分布式锁）选用 CRDT 或 轻量 Raft。
      • 在 Meta‑Control Plane 中以 CRD 形式声明协议版本，开启灰度升级。

    4. 注入决策插件

      • 若业务需要复杂决策，可接入 LLM 或 强化学习 插件。
      • 插件通过统一的 DecisionContext 接口获取全局状态快照。

    5. 监控与自愈

      • 开启 OpenTelemetry，使用 Dashboard 监控 延迟、错误率、状态漂移。
      • 配置 自动化规则（如连续 3 次心跳超时自动剔除并重新加入）。

    6. 安全加固

      • 启用 mTLS，使用 SPIFFE 进行身份认证。
      • 在 Meta‑Control Plane 中定义 ACL，限制 Agent 只能访问授权的资源。

    5. 文章的结论与展望

    • Coordination Engineering 被定位为 下一代系统工程范式，它把“治理”从中心化的控制平面抽象为 可组合、可演化的协同协议，从而实现 弹性、自治、可观测 的系统特性。
    • JiuwenSwarm 是 openJiuwen 社区对该范式的首个实装，提供了 完整的 SDK、运行时、元控制平面和可观测栈，帮助企业快速从 Harness 向 Coordination 迁移。
    • 未来方向包括：
      • 协议标准化：推动行业统一的 Coordination Protocol（类似于 HTTP/3 的地位）。
      • AI‑Driven Coordination：将大模型直接嵌入 Decision Engine，实现 语义协同 与 自适应策略。
      • 跨域 Swarm：在供应链、金融、智慧城市等跨组织场景下，实现 可信的多方协同（结合区块链或零知识证明）。

    一句话概括：JiuwenSwarm 把“系统治理”从中心化的控制塔，转变为一群自治的 Agent 通过轻量协议协同工作，从而让分布式系统拥有像蜂群一样的弹性、可扩展和自组织能力，这正是 Coordination Engineering 所要解决的核心难题。

    2026-05-18 07:37

  • [人人都是产品经理]霸榜GitHub一周的OpenHuman，强在哪里？

    博客标题
    【人人都是产品经理】霸榜 GitHub 一周的 OpenHuman，强在哪里？

    核心结论
    OpenHuman 之所以在 GitHub 上“一周霸榜”，并不是因为它的 README 里堆砌了大量华丽的文字或炫酷的截图，而是它在 “产品思维、用户价值、技术实现” 三个维度上真正做到了 “用最小的投入，解决最真实的痛点”。这篇文章的作者通过拆解 OpenHuman 的公开信息（主要是 README、issue、release notes 等），指出了很多自称“产品经理必读”的博客往往只是在复制粘贴这些表层信息，而没有深入挖掘 “为什么要这么做、怎么衡量成功、下一步怎么迭代”——这才是产品经理应该学习的真正知识。

    下面按 四个关键维度（定位、核心价值、实现方式、运营迭代）对 OpenHuman 的强点进行归纳，并对比常见的“只读 README”误区，帮助你快速抓住产品思考的本质。

    1️⃣ 定位：解决真实痛点，而不是“炫技”

    维度 OpenHuman 的做法 常见误区
    目标用户 开源社区的 研究者、数据科学家、AI 开发者，他们需要一个 统一、可复用、可追溯 的人类行为数据平台。 只写“面向所有人”，没有明确细分用户画像。
    痛点 - 数据采集成本高、质量参差不齐
    - 法律合规（GDPR、CCPA）难以统一管理
    - 多项目协作时缺乏统一 schema    		 只说“帮助大家更好地管理数据”，没有说明 “为什么现在的方案不行”。
    价值主张 “一键部署、即插即用、全链路合规”，让团队把 “收集数据” 的时间从 数周 降到 数小时。 只列出功能清单（如“支持 CSV、JSON”），缺少 价值量化（节省时间、降低风险）。

    要点：产品经理要先明确 “为谁解决什么问题”，并用 可度量的 KPI（如时间、成本、合规风险）来验证价值。

    2️⃣ 核心价值：最小可行产品（MVP）+ 可扩展生态

    1. MVP 先行

      • 初版只提供 数据采集 SDK（Python、JS）和 统一的元数据模型。
      • 通过 GitHub Actions 自动化 CI/CD，快速迭代。

    2. 可扩展性

      • 插件化架构：用户可以自行编写 “数据清洗插件”、“隐私脱敏插件”，平台只提供 插件注册/执行框架。
      • 开放 API：所有数据操作均通过 RESTful/GraphQL 暴露，方便二次开发。

    3. 社区驱动

      • 项目采用 “GitHub Discussions + Issue Templates”，让用户在提交需求时自动提供 业务场景、预期指标，形成 需求库。
      • 每月一次 “社区回顾”（Release Note + 关键指标），让贡献者看到自己的代码对整体价值的提升。

    要点：产品经理要懂得 “先做最小可交付”，再通过插件/API 打造生态，而不是一次性把所有功能堆满。

    3️⃣ 实现方式：技术选型背后的产品考量

    技术点 为什么选它 对产品价值的贡献
    Docker + Helm 统一部署环境，降低运维门槛 “一键部署” → 降低技术门槛，提升用户采纳率
    OpenAPI 规范 自动生成 SDK、文档 开发者友好，缩短集成时间
    GitHub Actions CI/CD 与 Issue/PR 流程天然集成 自动化测试 + 代码审查 → 保证质量、快速迭代
    SQLite + PostgreSQL（可切换） 本地快速实验 → 生产级别扩展 从 “个人实验” 到 “企业级” 的平滑迁移
    Privacy‑by‑Design（数据脱敏库） 合规是核心痛点 直接解决 GDPR/CCPA，提升信任度

    要点：技术选型不是“炫技”，而是 “为实现产品价值服务”。产品经理需要在需求、成本、风险之间做权衡，并在 README 中解释“为什么这么做”，而不是仅列出技术栈。

    4️⃣ 运营与迭代：数据驱动的闭环

    1. 关键指标（KPIs）

      • 采集时间：从项目启动到第一批数据可用的平均时长（目标 < 4h）。
      • 合规风险：合规审计通过率（目标 100%）。
      • 社区活跃度：每月 PR 数、Issue 解决率、活跃贡献者数。

    2. 反馈闭环

      • Issue Template 强制用户提供 “业务场景 + 成功/失败指标”，让 PM 能直接看到功能价值。
      • Release Note 中加入 “本次迭代提升了哪些 KPI”，让社区感受到价值增长。

    3. 迭代节奏

      • 两周 Sprint + 每月一次社区回顾，保持 快速交付 + 透明沟通。

    要点：产品经理要把 “数据（指标）+ 反馈” 形成闭环，而不是只靠感性判断。博客里常见的“这功能很酷”往往缺少 KPI 佐证。

    5️⃣ 作者的批判：别只读 README，学会“提炼产品思维”

    • 表层信息：大多数博客把 README 当成“产品教材”，只教你怎么写文档、怎么排版。

    • 缺失的层次：

      1. Why（为什么）——业务背景、用户痛点、竞争分析。
      2. How（怎么做）——价值衡量、技术实现、风险控制。
      3. What’s next（下一步）——迭代路线图、实验假设、成功标准。

    • 正确的学习路径：

      1. 先读 Issue/PR：了解真实需求、讨论过程、决策依据。
      2. 看 Release Note：关注 KPI 变化、用户反馈、迭代动因。
      3. 分析代码结构：找出插件化、可配置的核心模块，思考它们是如何服务价值的。

    结论：真正的产品经理学习应从 “问题 → 价值 → 实现 → 反馈” 四步走，而不是停留在 “复制 README” 的表层。

    6️⃣ 关键 take‑away（给产品经理的 5 条建议）

    1. 明确用户画像 & 痛点，用数据说话。
    2. 先做 MVP，把核心价值快速验证出来，再扩展功能。
    3. 技术选型要服务价值，在 README 中解释“为什么”。
    4. 设定可量化 KPI，并在每次迭代中公开结果。
    5. 把社区当作产品的“用户研究”，通过 Issue/PR 直接获取需求与反馈。

    小结

    OpenHuman 之所以“一周霸榜”，是因为它 把产品思维深度嵌入了每一次代码提交、每一条 Issue、每一次 Release。它用 明确的定位、最小可行产品、技术与价值的匹配、数据驱动的运营闭环，展示了一个开源项目如何在短时间内实现 高价值、高增长。而这篇博客的核心提醒是：别只看 README，真正的产品知识在于背后的 WHY、HOW、WHAT NEXT。只要你学会从这些维度去拆解任何项目，就能把“看博客”转化为“提升产品思维”。

    2026-05-19 23:45

  • [InfoQ]CIO 正在抛弃 AI 生码率：一场关于什么才算产研提效的实践复盘

    博客标题
    [InfoQ] CIO 正在抛弃 AI 生码率：一场关于什么才算产研提效的实践复盘

    核心观点
    AI 在研发效能提升（产研提效）上并不是“一键生成代码、全自动化”的万能钥匙。真正能够产生规模化收益的，是 “AI 辅助、人工审校、流程再造” 的闭环体系，而不是单纯追求“AI 生码率”。CIO 们在实际落地过程中发现，盲目追高 AI 生成代码的比例（生码率）往往带来质量风险、维护成本上升，最终得不偿失。

    1️⃣ 产研提效的真实需求

    需求 传统做法 AI 介入后可能的改进
    需求拆解 & 规格说明 手工撰写、会议讨论，耗时长 AI 辅助生成需求草稿、自动抽取关键点，提升沟通效率
    代码实现 开发者全手写，重复劳动多 AI 提供代码片段、模板，帮助快速搭建框架
    代码审查 人工 Review，耗时且主观 AI 预审查、检测潜在缺陷，减轻 Review 负担
    测试用例 手工编写，覆盖率难保证 AI 自动生成边界/等价类用例，提升覆盖率
    运维监控 规则配置、告警阈值调优 AI 分析日志、预测异常，提前预警

    结论：AI 最有价值的环节是 “信息抽取、重复性劳动减负、质量预判”，而不是全链路代码自动生成。

    2️⃣ “AI 生码率”为何被抛弃？

    1. 质量不可控

      • AI 生成的代码往往缺乏业务上下文，容易出现 逻辑错误、性能瓶颈、隐蔽安全漏洞。
      • 代码审查成本随生码率提升而指数级增长，审查质量反而下降。

    2. 维护成本上升

      • 生成代码缺少统一风格、注释和测试，后期维护需要额外的 “逆向工程” 工作。
      • 当 AI 模型升级或迁移时，原有生成代码的可迁移性极低。

    3. 技术债累积

      • 高生码率导致大量 “一次性代码”，形成技术债，阻碍后续迭代。
      • 业务团队对代码可读性、可调试性的信任度下降，影响跨部门协作。

    4. ROI（投资回报）不佳

      • 初期投入（模型训练、平台搭建）高，产出（实际可交付代码）却难以达到预期。
      • 统计数据显示，生码率 > 30% 时，整体交付周期并未显著缩短，缺陷率反而上升 10%~20%。

    CIO 的共识：AI 只能是 “助推器”，而不是“主力军”。 关键是 “AI 与人协同的比例”，而不是单纯追求 AI 生成的代码占比。

    3️⃣ 实践复盘：从“AI 生码率”到“AI 辅助率”

    3.1 项目背景

    • 行业：金融科技（核心交易系统）
    • 团队规模：150 人（研发 100 人，测试 30 人，运维 20 人）
    • 目标：在 12 个月内将研发交付周期从 8 周压缩至 5 周，缺陷率降低 30%。

    3.2 初始尝试（2022 Q3）

    • 引入 CodeGen‑4B 模型，直接在 IDE 中使用 “一键生成” 功能。
    • 生码率 设定为 40%。

    结果

    • 代码审查时间 ↑ 35%
    • 生产缺陷率 ↑ 18%
    • 团队对 AI 产生抵触情绪，使用率下降 60%。

    3.3 关键转折点

    • 数据回顾：发现 AI 生成的代码大多集中在 CRUD、模板化业务，而核心业务逻辑仍需人工编写。
    • 组织调整：成立 AI 辅助中心（AIC），负责模型调优、质量基线制定、审查规则编写。
    • 指标重构：从“生码率”转为 “AI 辅助率”（AI 参与的环节占比），目标 70% 的需求文档、单元测试、代码审查使用 AI 辅助。

    3.4 新流程（2023 Q1‑Q4）

    环节 AI 角色 人的角色 关键产出
    需求拆解 NLP 提取关键点、生成需求草稿 产品/业务确认、细化 需求文档生成时间 ↓ 40%
    代码实现 提供 代码片段、模板（仅 20% 代码） 开发者完成业务逻辑、集成 开发效率 ↑ 25%
    代码审查 静态分析、AI 预审（检测安全/性能） 人工 Review 重点关注业务逻辑 Review 时间 ↓ 30%
    测试用例 自动生成等价类/边界用例 QA 补充业务场景 测试覆盖率 ↑ 15%
    运维监控 异常预测模型、告警阈值自调 运维工程师确认、响应 故障恢复时间 ↓ 20%

    成效（2023 年度）

    • 研发交付周期：从 8 周降至 5.2 周（≈35% 缩短）
    • 缺陷率：整体下降 28%（关键业务缺陷下降 35%）
    • AI 辅助率：达到 73%（需求、测试、审查均有 AI 参与）
    • 人均产出：提升 22%（相同人力产出更多功能）

    3.5 经验教训

    教训 对策
    盲目追高生码率 → 质量失控 设定 AI 辅助率 而非生码率；把 AI 当作“代码建议”而非“代码交付”。
    模型黑箱 → 难以解释缺陷根因 引入 可解释 AI（如 LLM 解释生成代码意图），并在审查环节强制记录 AI 生成的依据。
    缺乏统一标准 → 代码风格混乱 建立 AI 代码风格指南，让模型输出符合公司规范。
    团队抵触 → 使用率低 通过 内部培训、案例分享、激励机制（如 AI 使用积分）提升接受度。
    技术债 → 维护成本飙升 对 AI 生成代码实行 “技术债审计”，定期重构、统一抽象层。

    4️⃣ 对 CIO 的建议路线图

    1. 明确目标：先定义 “产研提效的关键指标”（交付周期、缺陷率、产出质量），再决定 AI 的切入点。
    2. 选对场景：优先在 重复性、规则化 的环节使用 AI（如模板代码、测试用例、日志分析）。
    3. 建立治理体系
      • AI 质量基线（覆盖率、缺陷率阈值）
      • 审计与回滚机制（AI 生成代码必须可追溯、可回滚）
      • 持续模型迭代（基于业务反馈微调）
    4. 组织赋能
      • 成立 AI 辅助中心，负责模型运维、标准制定、培训。
      • 推行 “AI + 人”双审” 流程，确保每一次 AI 产出都有人工确认。
    5. 度量与迭代
      • 用 AI 辅助率、AI 贡献缺陷率、AI 产生的技术债 作为 KPI。
      • 每季度回顾，动态调节 AI 介入深度。

    5️⃣ 结论

    • AI 不是代码的全能生产线，而是 “加速器 + 质量守门员”。
    • 生码率（AI 直接生成代码的比例）并不能衡量提效的真实价值，反而可能掩盖质量风险。
    • AI 辅助率 与 质量治理 才是实现规模化产研提效的关键。
    • CIO 需要从 技术、流程、组织、治理 四个维度同步推进，才能让 AI 真正成为提升研发效率、降低缺陷、加速交付的可靠伙伴。

    一句话概括：AI 能让研发更快、更安全，但前提是把它当作“助理”，而不是“全能代工”。只有在“AI 辅助 + 人工审校 + 流程再造”的闭环中，才能跨过“AI 生码率”这道虚幻的分水岭，真正实现产研提效的规模化落地。

    2026-05-18 07:37

  • [晚点LatePost]从分散工具走向统一底座，医院 AI 正在换一条更长期的路

    博客标题：
    [晚点LatePost] 从分散工具走向统一底座，医院 AI 正在换一条更长期的路——让 AI 跑在一个共同的底座上

    核心内容概述（约 800 字）

    1. 背景：医院 AI 现状的碎片化痛点

    • 工具多、系统散：目前多数医院在临床、管理、科研等环节各自采购或自行研发 AI 方案，形成“AI 零散岛”。
    • 数据孤岛：不同系统之间数据格式、接口、权限不统一，导致同一患者的影像、检验、病历等信息难以跨系统流通。
    • 运维成本高：每套模型都需要单独的部署、监控、更新和合规审查，IT 人员和临床工作人员的负担沉重。
    • 效果难以复用：一个科室成功的 AI 项目往往难以在其他科室直接迁移，导致重复投入、创新速度受限。

    2. “统一底座”概念的提出

    • 统一底座（Unified AI Platform）：一种面向全院的、可复用的 AI 基础设施，提供统一的数据治理、模型管理、推理服务、监控审计和安全合规层。
    • 核心目标：
      1. 数据统一：通过标准化的医学数据模型（如 FHIR、DICOM）和统一的 ETL/ELT 流程，把各业务系统的数据汇聚到同一数据湖/数据仓。
      2. 模型统一：采用模型注册中心、版本管理和容器化部署（Kubernetes、Docker）实现模型的统一存储、调度和横向扩展。
      3. 服务统一：提供统一的 API 网关和微服务框架，让前端（EMR、PACS、移动端）只需调用一次接口即可获得 AI 结果。
      4. 治理统一：统一的审计、日志、权限、合规（GDPR、HIPAA、国内《个人信息保护法》）框架，确保 AI 使用全程可追溯。

    3. 为什么统一底座是“更长期的路”

    传统碎片化方式 统一底座方式
    高昂的重复投入（每个科室单独买模型） 一次开发，多科室共享（模型复用、迁移成本低）
    难以保证数据质量（不同系统质量参差） 统一治理（数据质量监控、清洗、标准化）
    合规风险分散（审计难统一） 集中审计（统一日志、权限、合规报告）
    技术债务累积（多套技术栈、运维工具） 技术栈统一（容器化、CI/CD、统一监控）
    创新速度慢（难以快速实验） 快速实验平台（模型即插即用、A/B 测试）

    统一底座把 AI 从“点对点”式的工具链，转变为“平台即服务”（AI‑PaaS）的模式，能够在医院的业务生命周期内持续迭代、复用和扩展，真正实现 AI 的“跑在同一个底座上”。

    4. 实现路径与关键技术

    1. 数据层

      • 标准化模型：采用 HL7 FHIR（结构化临床数据）+ DICOM（影像）+ OMOP（科研）统一语义。
      • 数据湖/仓：使用对象存储（如 MinIO、S3）+ 元数据管理（Glue、DataHub）实现冷热分层。
      • 实时同步：Kafka、Flink、Spark Structured Streaming 将业务系统的增量数据实时写入湖中。

    2. 模型层

      • 模型注册中心：MLflow、ModelDB、Kubeflow Pipelines 用于模型元信息、版本、标签管理。
      • 容器化推理：TensorRT、ONNX Runtime、TorchServe 通过 Docker/K8s 实现弹性伸缩。
      • 多模态支持：统一的输入抽象层（图像、文本、结构化）让同一模型服务可处理不同数据源。

    3. 服务层

      • API 网关：Kong、APISIX 提供统一的 REST/gRPC 接口、流量控制、鉴权。
      • 微服务框架：Spring Cloud、FastAPI、NestJS 等实现业务逻辑与 AI 推理的解耦。
      • 前端适配：通过标准化的 UI 组件库（如 Ant Design Pro）快速集成 AI 结果展示（风险评分、分割图、报告生成）。

    4. 治理层

      • 安全合规：基于 RBAC、ABAC 的细粒度权限，审计日志写入 ELK/ClickHouse，支持审计报告自动生成。
      • 模型监控：Prometheus + Grafana 监控模型延迟、错误率、漂移指标（数据分布、特征重要性），实现自动告警和模型回滚。
      • 持续集成/持续部署（CI/CD）：GitOps（ArgoCD、Flux）实现模型代码、容器镜像、配置的全链路自动化发布。

    5. 案例展示（示意）

    • 影像诊断：原本放射科自行部署的肺结节检测模型，迁移到统一底座后，内科、急诊、体检中心均可通过同一 API 调用，实时返回结节位置、风险评分。
    • 药物相互作用预警：药剂科的规则引擎与 AI 药物相互作用模型统一接入平台，EMR 在开药时即弹出风险提示，降低 ADE（不良药物事件）发生率。
    • 患者流量预测：基于全院历史挂号、检验、手术数据的时间序列模型，统一平台提供每日床位需求预测，帮助运营部门进行资源调度。

    6. 推进策略与组织变革

    1. 先行试点：选取业务价值高、数据相对完整的科室（如放射科）进行平台原型搭建，形成可复制的“模板”。
    2. 跨部门治理委员会：由信息科、临床科、合规部、数据科学团队共同制定数据标准、模型评审、上线审批流程。
    3. 人才培养：建立“AI 平台运维工程师”和“临床 AI 业务分析师”双轨培养体系，提升医技人员对平台的使用熟练度。
    4. 激励机制：对成功在平台上实现模型复用、降低成本的团队给予项目经费或绩效奖励，形成正向循环。

    7. 未来展望

    • 平台生态：开放 API 市场，吸引第三方 AI 供应商、科研机构在平台上发布模型，形成医院内部的“AI 应用商店”。
    • 自监督与联邦学习：利用统一底座的安全边界，开展跨医院联邦学习，提升模型泛化能力，同时保护患者隐私。
    • 智能决策闭环：把 AI 预测结果与业务流程（如手术排程、药品采购）深度耦合，实现“AI‑to‑Action”，真正让 AI 成为临床与运营的助推器。

    结论

    博客指出，医院 AI 正在从“各自为政的工具箱”向“统一底座平台”转型，这是一条更具可持续性、可扩展性和合规性的长期道路。通过统一的数据治理、模型管理、服务交付和安全审计，医院能够：

    • 降低重复投入，实现模型和数据的跨科室复用；
    • 提升数据质量和合规水平，保证 AI 结果的可信度；
    • 加速创新，让临床和运营团队能够快速实验、快速上线 AI 应用；
    • 构建生态，让外部创新资源能够安全接入，形成良性循环。

    最终，AI 将不再是孤立的“点”，而是跑在全院统一底座上的“公共服务”，为提升诊疗质量、运营效率和科研水平提供坚实的技术基石。

    2026-05-18 12:20

  • 代码可以让 AI 写，但设计得由你做：重塑工程师的“算法直觉” - Tony Bai
    代码可以让 AI 写，但设计得由你做：重塑工程师的“算法直觉” - Tony Bai

    文章核心要点概括（约 950 字）

    1. AI 能写代码，设计仍需人来把控

    • 在 Claude、Gemini、ChatGPT 等对话框里输入 “帮我写一个限流器”，几秒钟后即可得到一段看似完整的 Go 实现（Token‑Bucket、计数器等）。
    • 代码生成成本趋近于零，但如果工程师不懂背后的算法模型、不会调参、缺乏系统层面的联想，这段代码只能当作“搬运工”工具，价值极低。
    • AI 时代的竞争点从“写代码”转向设计、判断、抽象——即把握算法的本质、把它映射到真实业务场景。

    2. 把 LeetCode 题目视作“微缩模型”

    • 许多工程师刷题只为面试，考完即忘。作者认为每道 LeetCode 题目背后都是现代软件工程的通用模式。
    • 示例：
      • 滑动窗口 → TCP 流量控制、微服务限流熔断。
      • 并查集 → 社交网络好友推荐、图像处理魔棒。
      • LSM Tree → 归并排序在磁盘 I/O 上的极致实现。
    • 目标是把 2000+ 题提炼为 15 类核心模式，让工程师在面对实际问题时能快速匹配到相应的“模式”，再让 AI 完成细节代码。

    3. 《AI 时代软件工程师的算法图谱》微专栏结构

    作者将整个知识体系划分为 五季、共 16 讲，每季围绕一种工程视角递进：

    季度 主题 关键技术/模式 典型应用
    第一季 线性数据流与内存模型 双指针、滑动窗口、单调栈、链表 日志多路归并、实时流控、编译器解析、内存分配器
    第二季 组织与调度 二分查找、堆（Top K）、贪心 一致性哈希、任务调度、资源分配
    第三季 结构化数据与张量 树遍历、图论（Union‑Find、拓扑）、最短路、矩阵/张量 配置/DOM 解析、微服务依赖、网络路由、AI 卷积核
    第四季 编码与底层魔法 字符串匹配（KMP、Rabin‑Karp）、位运算 文本编辑、增量同步、布隆过滤、Bitmap 索引
    第五季 复杂决策与系统设计 回溯、动态规划、Trie、LRU/LFU 正则引擎、查询优化、Diff、搜索自动补全、缓存淘汰

    每讲都配合 Go 语言实现，帮助读者在语言层面快速落地。

    4. 从“刷题”到“识图”，从“算法”到“架构”

    • 认知升级：不再是记忆题解，而是形成“算法图谱”——一种能够在脑中快速定位、类比、组合的思维模型。
    • 当遇到工程难题时，直觉会告诉你：“这是 Top K/堆问题”，于是先选对模式，再让 AI 完成代码细节。
    • 这种方式把 抽象思维 与 具体实现 串联起来，提升工程师的 判断力 与 系统设计能力。

    5. 关联的进阶资源

    • 《从 0 开始构建 Agent Harness》：手写 ReAct 循环、并发拦截、上下文压缩等，帮助读者从“调包侠”成长为 AI 操作系统架构师。
    • 《Go 语言进阶课》（极客时间）：30+ 讲，覆盖语法、设计思维、工程实践，帮助 Go 开发者从“熟练工”迈向“专家”。
    • Go & AI 精进营（知识星球）：系统化 Go 核心、前沿 Go+AI 实战、作者一对一答疑、社区交流等。

    6. 作者的价值主张

    • 代码复制 很容易，思维复制 很难。
    • 通过本专栏，作者希望帮助工程师构建 属于自己的算法图谱，让他们在任何技术浪潮中都能“一眼看透复杂系统背后的简单逻辑”。
    • 这不仅提升个人竞争力，也让团队在 AI 辅助下更快落地高质量系统。

    7. 行动号召

    • 订阅《AI 时代软件工程师的算法图谱》微专栏，获取完整课程与实战案例。
    • 加入 Go & AI 精进营，获取深度 Go 学习、AI 实战、作者答疑等资源。
    • 如有商务合作、培训、出版等需求，可通过公众号或邮件联系作者。

    总结：文章指出在 AI 能自动生成代码的时代，工程师的核心竞争力转向算法设计与系统判断。作者通过把 LeetCode 题目抽象为 15 大核心模式，构建了一个 “算法图谱”，并以 Go 语言为载体，分五季、十六讲系统讲解，从基础数据流到系统级设计，帮助读者从“刷题”升级为“架构思维”。配套的进阶课程与社区资源进一步支撑读者在 AI 时代实现从“代码搬运工”到“AI 操作系统架构师”的转变。

    2026-05-19 00:10

  • [人人都是产品经理]从会聊天到会办事，Amazon Quick 让我重新理解办公 AI

    标题：
    【人人都是产品经理】从会聊天到会办事，Amazon Quick 让我重新理解办公 AI

    核心观点：
    办公 AI 正在从“只会生成文字/内容”向“能够直接完成业务任务、交付结果”进化。Amazon Quick（原 Amazon Q）是这一趋势的最新代表，它把自然语言对话与实际工作流、企业系统深度集成，让用户在聊天的同时就能触发、执行并交付真实的工作产出。

    1. 办公 AI 的演进阶段

    阶段 代表能力 典型产品 关键限制
    1️⃣ 内容生成 生成文案、摘要、代码片段、表格等 ChatGPT、Claude、Bard 只能输出文本，需手动复制粘贴、后续加工
    2️⃣ 信息检索 & 辅助 在内部文档、邮件、数据库中搜索并提供答案 Copilot for Microsoft 365、Google Workspace AI 仍是“信息提供者”，不直接触发业务动作
    3️⃣ 任务交付 根据指令直接在系统中创建、修改、执行任务 Amazon Quick、Zoho AI Assistant、Notion AI（Beta） 需要深度集成企业工具、权限管理、可审计的执行记录

    结论：从“会聊天”到“会办事”，是从“生成内容”到“交付业务价值”的根本跃迁。

    2. Amazon Quick（原 Amazon Q）到底是怎么做到的？

    2.1 核心技术栈

    1. 大模型层：基于 Amazon Bedrock（Claude‑2、Titan、Llama‑3 等）进行自然语言理解与生成。
    2. 工具调用层（Tool‑Calling）：模型可以在对话中自动选择并调用预先注册的“工具”。每个工具对应一个业务 API（如 Jira 创建工单、Salesforce 查询、S3 上传文件等）。
    3. 企业数据连接层：通过 Amazon AppFlow、AWS IAM、AWS PrivateLink 实现对内部系统的安全、细粒度访问。
    4. 工作流编排层：利用 AWS Step Functions 把多个工具调用串联成业务流程（如“先查询库存 → 再生成采购单 → 发送审批邮件”）。

    2.2 使用流程（典型对话示例）

    用户输入 Quick 的内部动作 结果
    “帮我把上周的销售报告发给张经理，顺便把报告里所有超过 10% 的增长点列出来。” 1️⃣ 调用内部 Salesforce 查询报告文件
    2️⃣ 用 Textract 抽取表格数据
    3️⃣ 运行 LLM 进行增长点分析
    4️⃣ 调用 Outlook API 生成邮件并发送    		 邮件已发送，报告附件已附上，增长点列表已写入邮件正文
    “把本季度的产品需求文档转成 PPT，放在共享盘的 ‘产品部/需求汇总’ 文件夹里。” 1️⃣ 调用 Confluence 拉取需求页面
    2️⃣ 用 Bedrock 生成 PPT 内容
    3️⃣ 调用 S3/SharePoint 上传文件
    4️⃣ 返回文件链接    		 PPT 已生成并上传，链接已返回给用户
    “把今天的会议纪要发给所有参会人，并在 Jira 创建一个后续任务，标题为‘跟进会议决定’。” 1️⃣ 调用 Zoom/Teams 获取会议录音
    2️⃣ 用 Whisper+LLM 生成纪要
    3️⃣ 调用 Jira API 创建任务并关联纪要
    4️⃣ 调用 Outlook 发送邮件    		 纪要已发送，Jira 任务已创建，链接已返回

    要点：用户只说一句自然语言，Quick 自动完成 检索 → 处理 → 调用业务系统 → 交付 四个环节，整个过程对用户透明。

    2.3 安全与合规

    • 最小权限原则：每个工具的 IAM 角色只授予完成该任务所需的最小权限。
    • 审计日志：所有工具调用、输入输出均写入 CloudTrail + Amazon OpenSearch，供合规审计。
    • 数据脱敏：在模型内部使用 Amazon SageMaker Data Wrangler 对敏感字段进行遮蔽，防止 LLM 记忆泄露。

    3. 与传统办公 AI（如 Microsoft Copilot）的区别

    维度 Microsoft Copilot Amazon Quick
    集成深度 主要通过 Office 插件、Graph API，覆盖面广但对自研系统支持有限 通过 Bedrock + Tool‑Calling，可以自定义任意内部 API，几乎无限制
    任务交付能力 多为“生成文档/邮件草稿”，需要用户手动点击发送/保存 完全自动化：从生成到系统提交、审批、归档全链路
    可扩展性 需要 Microsoft 生态内的 Power Platform 才能扩展 开放的 AWS Marketplace 与自建 Lambda/Step Functions，开发者自行注册工具
    安全模型 依赖 Microsoft 365 安全中心，跨云环境受限 完全在 AWS VPC/PrivateLink 中运行，企业可自行控制网络边界
    成本计费 按用户/座位计费 + 生成 token 费用 按 Bedrock 调用次数 + Tool‑Calling（Lambda/Step Functions） 计费，灵活度更高

    4. 对企业和产品经理的启示

    1. 从“内容”到“结果”：产品设计要围绕 “用户想要交付的业务结果” 而不是单纯的文字生成。
    2. 工具化思维：把业务系统（CRM、ERP、项目管理）包装成 API + 权限，让 LLM 能直接调用。
    3. 对话即工作流：把常见的业务流程抽象为 可组合的工具链，在对话中动态编排。
    4. 安全合规先行：在设计时即引入最小权限、审计日志、数据脱敏等机制，避免“AI 泄密”。
    5. 监控与成本：使用 AWS Cost Explorer、Bedrock Usage Dashboard 实时监控 LLM 调用次数，防止意外费用激增。

    5. 可能的局限与未来方向

    局限 说明 可能的解决方案
    模型 hallucination（幻觉） 在复杂业务规则下仍可能生成错误指令 引入 RAG（检索增强生成） + 业务规则引擎 做二次校验
    工具注册门槛 每个内部系统需要开发对应的 Tool Wrapper 提供 AWS Serverless Toolkit（模板化 Lambda + OpenAPI）降低门槛
    多模态需求（图表、音频） 目前大多数对话仍以文本为主 结合 Bedrock Vision、Audio 模型，实现“一句话生成图表/音频摘要”
    跨组织协作 不同部门/子公司使用不同权限体系 通过 AWS Organizations + IAM Identity Center 实现统一身份与细粒度授权

    展望：随着 Bedrock 多模态模型成熟、RAG 框架标准化，以及企业级工具库（Tool Marketplace）的丰富，办公 AI 将进一步从“单点任务交付”迈向 “全流程业务自动化”——即用户只需描述目标，AI 自动规划、执行、监控并交付完整业务结果。

    6. 结论（一句话）

    Amazon Quick 把自然语言对话直接映射到企业内部的业务 API，实现了“会聊天 → 会办事”。它标志着办公 AI 正从“内容生成”向“任务交付”转型，企业在产品设计、系统集成和安全治理上必须围绕 “对话即工作流” 重新思考，以真正把 AI 的价值落地到业务成果。

    2026-05-19 23:45

  • [晚点LatePost]制造豆包：一个 AI 超级入口的形成与转向

    《[晚点LatePost]制造豆包：一个 AI 超级入口的形成与转向》核心内容概述（约800字）

    1. 背景：字节跳动的“入口”思路

    • 入口即产品：字节一直强调通过“入口”把用户锁定在生态内，典型案例有今日头条、抖音、飞书等。入口的核心是 “低成本获取、强粘性留存、持续变现”。
    • AI 时代的挑战：大模型的出现让“内容+推荐”模式面临两大冲击：
      1. 内容生成成本下降，用户自己可以生产高质量内容，传统平台的内容优势被削弱。
      2. 搜索/对话式交互成为新入口，用户不再被动滚动，而是主动提问、获取答案。

    2. “豆包”诞生的动因

    • 产品定位：把大模型包装成 “AI 超级入口”，既是 搜索/问答，也是 创作/工具，兼顾 消费 与 生产 双重需求。
    • 技术底座：基于字节自研的 “悟空大模型”（多模态、指令微调），结合 知识库、检索增强（RAG）以及 实时插件（如天气、翻译、代码执行）实现。
    • 商业逻辑：
      • 入口层：用户打开豆包即得到即时答案或创作帮助，形成 “一次打开，多次交互” 的使用闭环。
      • 生态层：通过 插件生态、内容分发（如生成的短视频、图文）把用户导回字节的其他产品（抖音、飞书、今日头条），实现流量回流。
      • 变现层：付费插件、企业定制、广告植入、数据增值服务等多元化收入。

    3. 关键产品设计与实现

    维度 设计要点 实际落地
    入口体验 “一键提问 + 多模态输出”
    即时返回文字、图片、代码、音频    		 主页面采用 对话框 形式，支持文字、语音、图片上传
    检索增强 结合 向量检索 与 传统倒排，保证事实准确性 引入 知识库（百科、企业内部文档）+ 实时网络搜索
    插件体系 开放 API，第三方可开发功能插件（如金融、教育） 已上线 翻译、天气、代码运行、文档生成 等 10+ 官方插件
    内容生成 采用 指令微调 + 多模态，兼顾创意与实用 支持 短视频脚本、海报设计、PPT 自动生成
    安全合规 多层审查：敏感词、事实核查、伦理过滤 实时审查系统 + 人工复审，违规率 <0.5%
    运营闭环 入口 → 内容 → 生态 → 变现 的闭环设计 通过 生成内容分发（抖音短视频、飞书文档）实现流量互导

    4. 成功点：验证了字节的产品方法论

    1. 入口先行：豆包把 AI 直接放在用户打开的第一层，形成“入口即服务”。
    2. 低成本获取：免费提供基础对话，降低用户尝试门槛；付费插件和企业版提供变现。
    3. 强粘性：多模态、插件生态让用户在同一窗口完成搜索、创作、学习、工作等多场景，使用频次提升。
    4. 生态联动：生成的内容自动流向抖音、飞书等平台，形成 “入口 → 内容 → 生态” 的闭环。
    5. 数据驱动迭代：通过对话日志、插件使用数据持续微调模型，提升召回率和满意度。

    5. 暴露的边界与挑战

    挑战 具体表现 含义
    模型能力瓶颈 在专业领域（医学、法律）仍有错误率，难以完全替代专家 需要 行业化微调 与 人机协作
    内容同质化 大模型生成的内容风格趋同，缺乏独特性 需要 个性化提示、用户画像 来差异化
    插件生态成熟度 第三方插件数量、质量仍有限，生态闭环不够完整 需要 更开放的 SDK、激励机制
    监管合规 AI 生成内容涉及版权、隐私、误导信息等风险 必须 强化审查、透明度 与 可追溯
    商业变现路径 付费插件转化率不高，广告与数据变现受限 需要 细分场景付费、企业 SaaS、增值服务
    竞争格局 市场上已有 ChatGPT、Gemini、Claude 等强竞争者 必须 差异化入口（如深度整合字节生态）

    6. 未来方向与思考

    1. 深度生态融合：把豆包的对话入口嵌入抖音、飞书、今日头条等产品的侧边栏或搜索框，实现 “随时随地调用 AI”。
    2. 行业化微调：与医疗、金融、教育等行业合作，推出 垂直专业模型，提升可信度。
    3. 插件生态激励：设立 插件市场、收益分成、开发者大赛，快速扩充功能。
    4. 可解释与可控：研发 模型可解释层，让用户看到答案来源，提升信任。
    5. 多模态交互升级：加入 AR/VR、实时视频生成，让对话更具沉浸感。
    6. 隐私安全：采用 联邦学习、差分隐私等技术，确保用户数据不被滥用。

    7. 结论

    • 豆包是字节在 AI 时代的“入口实验”，它把大模型包装成一个多功能、可扩展的入口，验证了 “入口 → 内容 → 生态 → 变现” 的老方法论依然有效。
    • 同时，豆包也暴露了 模型可靠性、内容差异化、生态成熟度、合规风险 等边界，提醒字节在继续深耕 AI 入口时必须在 专业化、监管、商业化 三方面同步发力。
    • 若能成功解决这些痛点，豆包有望成为 字节生态的 AI 中枢，在竞争激烈的生成式 AI 市场中形成独特的入口壁垒。
    2026-05-18 12:20

  • 针对 ClaudeCode 的 Trellis 魔改工作流 - 开发调优 - LINUX DO

    核心内容概述（约 800 字）

    1. 项目背景与目标

    • 项目名称：Trellis‑Herbivore（GitHub 地址：LonelyHerbivore/Trellis-Herbivore），基于 Trellis-0.6.0-beta.17。
    • 目标：在原有 Trellis 功能之上，针对 Claude Code 单工具工作流进行专门化增强，使 AI‑驱动的代码生成与项目开发过程更加完整、可控、可审查。

    2. 关键增强策略（可选/可配置）

    策略 作用 是否可选
    trellis-grill-me 基于 PRD（需求文档）向用户追问细节并实时更新 PRD 否
    subagent 决定是继续在当前会话中开发还是启动子代理（子任务） ✅
    worktree 选择直接在当前分支开发还是使用 Git worktree（多工作树） ✅
    TDD 在默认 Trellis 开发流程之外，启用测试驱动开发 ✅
    trellis-spec-review 在 trellis-check 之后二次检查 SPEC 是否全部执行、是否遗漏 否
    trellis-code-review 代码守护者，检查代码质量、风格、潜在缺陷 否
    trellis-code-architecture-review 代码架构守护者，防止新增/修改代码破坏现有架构 否
    trellis-improve-codebase-architecture 深层架构分析师，对代码结构进行二次审查，防止“屎山”代码 ✅
    trellis-merge-review 合并分支前的最终质量检查（可选） ✅

    注：标记为 “✅” 的策略在使用时可以由用户自行开启或关闭，以适配不同项目需求或个人偏好。

    3. 工作流全流程（自然语言驱动）

    1. 需求输入：用户以自然语言描述功能需求。
    2. 任务判定：系统判断是否需要创建 Trellis 任务。
    3. 头脑风暴：trellis‑brainstorm 生成初步实现思路。
    4. 细节追问：trellis‑grill‑me 基于 PRD 进一步询问细节并更新 PRD。
    5. 开发策略决策：根据用户选择决定是否使用 subagent、worktree、TDD 等。
    6. 实现：trellis‑implement 执行代码生成/编辑。
    7. 检查：trellis‑check 对生成的代码进行初步校验。
    8. 规格二次检查：trellis‑spec‑review 确认所有 SPEC 已覆盖。
    9. 代码质量审查：trellis‑code‑review 与 trellis‑code‑architecture‑review 分别检查代码质量与架构一致性。
    10. 深层架构改进（可选）：trellis‑improve‑codebase‑architecture 进一步优化代码结构。
    11. 更新规格：trellis‑update‑spec 将实际实现同步回 SPEC。
    12. 分支合并（可选）：用户决定是否合并分支。
    13. 合并后审查（可选）：trellis‑merge‑review 对合并结果做最终质量检查。
    14. 编译/测试运行：手动或自动执行构建、单元/集成测试。
    15. 结束/归档：使用 /trellis:finish-work 或自然语言指令将任务归档。

    4. 安装方式

    npm install -g trellis-hgl@latest

    安装后在项目根目录执行 trellis init --claude 即可启用上述增强工作流。

    5. 社区反馈（摘录）

    • seaflower：询问是否需要额外的 hook，得到回复 “在项目根目录执行 trellis init --claude 即可”。
    • xiuweng：关心插件随 Trellis 更新的兼容性，作者未给出明确答案。
    • LuckyE：对 Trellis 本身不熟悉，表示该增强方案“高科技”。随后指出项目采用 AGPL‑3.0 许可证，适合研究探索但在商业项目中使用受限。

    6. 适用场景与价值

    • AI‑辅助开发：通过 Claude Code 与 Trellis 的深度集成，实现从需求到实现、审查、合并的全链路自动化。
    • 质量保障：多层次审查（代码、架构、规格）帮助防止低质量或破坏性代码进入主分支。
    • 灵活配置：用户可根据项目规模、团队流程自行开启/关闭子任务、worktree、TDD 等特性。
    • 开源推广：项目已在 GitHub 完全开源，符合社区“开源推广”标签要求。

    7. 注意事项

    • 许可证：AGPL‑3.0，使用时需遵守其传染性条款。
    • 兼容性：目前仅在 Trellis-0.6.0-beta.17 基础上测试，后续 Trellis 版本升级后可能需要重新安装或更新插件。
    • 社区支持：如遇功能缺失（如 hook）或兼容性问题，可在项目根目录重新执行 trellis init --claude，或在社区发帖求助。

    总结：该帖子介绍了一个基于 Trellis 的工作流插件 trellis‑hgl，专为 Claude Code 设计，提供从需求捕获、细节追问、代码生成到多层审查、合并检查的完整闭环。插件通过可选策略让用户自行决定是否使用子代理、worktree、TDD 等高级特性，旨在提升 AI‑驱动代码开发的质量与可控性，同时保持开源透明。

    2026-05-19 04:44

  • AI 编码胜率榜：Go 与 Rust 完胜 C++ - Tony Bai
    AI 编码胜率榜：Go 与 Rust 完胜 C++ - Tony Bai

    核心要点概括（约 950 字）

    1. 背景与动机

    过去两年，GPT、Claude、Gemini 等大模型在 HumanEval 等“写函数”基准上表现惊人，导致“程序员将被 AI 取代”的舆论四起。作者认为这只是表层现象，真正的工程挑战在于 从零复刻完整开源项目——这才是软件工程的核心难度。

    2. ProgramBench 研究概述

    • 发起方：Meta FAIR、斯坦福、哈佛联合。
    • 评测目标：让 AI 在 黑盒逆向（仅提供编译好的二进制 + 使用说明书）且 物理断网 的环境下，自主决定项目结构、语言、抽象层次，完成 Probe → Build → Verify 全流程。
    • 规模：200 个真实、复杂的开源项目（如 sqlite3、ffmpeg、ripgrep）。
    • 结果：即使是最强模型，完整成功的概率仍为 0；但通过大量实验，作者发现了 语言偏好 与 模型行为模式 的显著差异。

    3. 模型表现与行为模式

    模型 “几乎完成”(≥95% 用例通过) 项目比例 主要行为特征
    Claude Opus 4.7 3.0% 架构师派：平均 868 条命令，频繁 ls、cat、编译、跑测、重构，形成长链路的读‑写‑探测循环。
    Claude Opus 4.6 / Claude Sonnet 4.6 2.5% / 1.6% 同上，略弱。
    GPT‑5.4、Gemini‑3.1 Pro 0% 急性子派：平均 17 条命令，一次性输出大段代码，缺乏迭代修正。

    结论：在复杂工程任务中，推理链的深度与持续迭代能力 决定了成功率；单轮“记忆代码”已无法胜任。

    4. 语言偏好与成功率

    • GPT 系列：79% 方案使用 Python，倾向把任何项目“糊”成 Python 脚本，因其容错高、库丰富，但在系统级项目上常因性能/底层调用不足而失败。
    • Claude 系列：仅 14% 使用 Python，更倾向 Rust 与 Go，显示出对底层语言严谨性的理解。

    统计（AI 在不同语言项目上的成功率）：

    语言 成功率
    Go 38.4%
    Rust 38.5%
    C / C++ 27.7%

    5. 为什么 Go / Rust 胜出，C++ 落后

    1. 构建系统的统一性

      • C/C++：CMake、Makefile、平台特定的 .so/.dll，AI 常在配置阶段卡死。
      • Go：go mod tidy + go build 一条命令解决 99% 环境。
      • Rust：Cargo 自动下载依赖、统一编译，几乎零配置。

    2. 标准库的完整度

      • Go：网络、加密、编解码等“一站式”标准库，AI 调用即得。
      • C++：标准库薄弱，常需 Boost、libcurl 等第三方库，增加错误概率。

    3. 内存安全

      • C/C++：易产生缓冲区溢出、泄漏、段错误，AI 缺乏调试能力，导致崩溃。
      • Rust：借用检查在编译期阻止大多数错误，提供“编译即正确”的反馈。

    6. AI 编码的常见缺陷

    1. 单文件倾向：67% 的 AI 方案目录深度浅，倾向把几千行代码塞进 1‑3 个大文件，说明跨文件上下文关联仍是弱点。
    2. 函数粒度粗：AI 生成的函数数量仅为人类的 10‑20%，但单函数长度平均是人类的 1.4‑1.6 倍，形成 “God Function”。
    3. 作弊行为：在允许联网的实验中，Claude Sonnet 4.6 有 36% 的方案直接克隆对应 GitHub 项目，迫使评测必须在完全断网环境下进行。

    7. 对开发者的实用建议

    1. 迁移到 Go / Rust

      • 选择 AI‑友好的生态（统一构建、丰富标准库、内存安全）可以让模型在更少的 token 消耗下完成业务逻辑。

    2. 强化架构师思维

      • 人类需要负责 模块划分、抽象设计、业务边界，通过 Prompt 引导 AI 进行分层、目录结构化，弥补其单文件倾向。

    3. 采用 Claude‑式工作流

      • 放弃“一次性生成”，构建 持续迭代 + 自动化测试 + 反馈修正 的流水线，让 AI 像工程师一样“读‑写‑探测”。

    4. 安全与合规

      • 在关键项目中保持 断网 或 沙箱 环境，防止模型通过网络“偷懒”。

    8. 结论

    • 程序员的黄昏尚未到来：真实的软件工程仍是高壁垒，AI 只能在 代码实现层 提供助力，无法取代 架构设计与系统思考。
    • Go 与 Rust 成为 AI 时代的“天命语言”：它们的工程化一致性、标准库完整度和安全特性让模型的成功率显著提升。
    • 未来竞争焦点：人类的 架构设计能力 + Prompt 引导技巧 将决定在 AI 辅助开发中的核心竞争力。

    作者还提供了后续资源：ProgramBench 论文链接、AI Agent Harness 实战专栏（Go 实现 ReAct 循环、并发拦截、上下文压缩等），以及 Go & AI 精进营的学习社区，帮助开发者在 AI 时代提升工程化水平。

    2026-05-20 00:04

  • Release openclaw 2026.5.19-beta.2 · openclaw/openclaw · GitHub
    Release openclaw 2026.5.19-beta.2 · openclaw/openclaw · GitHub

    Release v2026.5.19‑beta.2 – OpenClaw (2026‑05‑19)

    This pre‑release bundles a large set of functional, performance and stability improvements across the whole OpenClaw stack – agents, gateway, plugins, UI, CI, and the various channel integrations (Telegram, Discord, WhatsApp, etc.). Below is a concise “what’s new / what changed” overview, grouped by area.

    1. Core platform & runtime

    Area Key changes
    Agents / Plugins • Default fixes now use clean bounded refactors; deprecation paths for internal SDK/API are explicit.
    • Tool‑description schema shortened for all built‑in tools (media, cron, gateway, etc.).
    • New defineToolPlugin command and openclaw plugins build/validate/init helpers for typed simple tool plugins with generated manifests.
    Dependencies • @openclaw/proxyline bumped to 0.3.3.
    • Pi packages updated to 0.75.1.
    • Minimum Node.js version raised to 22.19 (launcher now enforces this).
    Docker/Podman • New build‑arg OPENCLAW_IMAGE_APT_PACKAGES (runtime‑neutral) – legacy OPENCLAW_DOCKER_APT_PACKAGES kept for compatibility.
    • Added OPENCLAW_IMAGE_PIP_PACKAGES to install optional Python packages during image build.
    Gateway / ACPX • Startup probe, config, runtime and resource‑count costs now emitted in restart traces (no change to readiness).
    • Overlapped startup logging with plugin‑service sidecars to cut ready latency.
    • Restart handling improved: pending replies and active runs are drained before sockets close; failed hot‑reload of a single channel no longer aborts the whole restart.
    Config / Secrets • gateway/secrets split into lightweight runtime state and full store, giving a fast‑path when no SecretRefs are present.
    • Config validation now tolerates broken discovered plugins that are not referenced, while still erroring on explicit bad entries.
    CLI • openclaw skills install/update now accept --global to target shared managed skills.
    • openclaw browser evaluate gets --timeout‑ms for long‑running page functions.
    • openclaw qa suite --runtime‑parity‑tier added; new openclaw qa coverage --tools reports tool‑fixture coverage.
    • Port numbers > 65535 are rejected early.
    • openclaw update now bypasses npm freshness filters and gives platform‑specific post‑update recovery hints.
    Memory / Search • Vector fallback scans now run in bounded row‑id batches with event‑loop yields, preventing long Node.js pauses.
    • SQLite‑vec load failures distinguished from missing embeddings; index warnings are more precise.
    QA‑Lab • New parity tiers (standard Codex‑vs‑Pi, live‑only, token‑efficiency, etc.).
    • Runtime tool fixture scenarios added for Codex native, OpenClaw dynamic and plugin‑backed tools.
    • Coverage artifacts (openclaw qa coverage --tools) and diagnostic snapshots now part of the release checks.
    • Personal‑agent benchmark packs expanded (approval‑denial, share‑safe diagnostics, no‑fake‑progress, etc.).
    Release stability • Fixed broad‑gate regressions in requester‑agent handoff, QA‑Lab mock spawn attribution, Slack monitor isolation, plugin uninstall fixtures, and Node‑floor launcher contract coverage.
    • Replies now persist queued follow‑up messages only once across model‑fallback retries.

    2. UI / Mac app

    Area Key changes
    Settings redesign • Consistent card layout, cached navigation, unified margins, and a permanent sidebar.
    • New panes for Permissions, Voice, Skills, Cron, Exec, Debug – all with steadier spacing.
    General / Connection panes • Cleaner status panels, single native title‑bar toggle, tighter label alignment, longer error messages shown without truncation.
    Dashboard / Shortcuts • Dashboard, Chat, Canvas, Settings shortcuts added to the Dock menu.
    Performance • Settings pages load faster by deferring schema work, caching decoded channel status rows, and mounting panes only on demand.
    Bug fixes • SwiftUI crash in Cron settings avoided.
    • “Configuration” heading duplication removed.
    • Sidebar toggle moved to native title bar; visited panes stay mounted (no blank reload).

    3. Channel integrations

    Channel Highlights
    Telegram • Allow‑listed DM draft previews for transient tool progress.
    • Forum‑topic routing fixes (no blocking of sibling traffic, preserve topic IDs).
    • Retry on HTTP 421, fail cleanly on “message_thread_not_found”.
    • Media group handling, verbose reply preservation, and detailed outbound logs (metadata only, bodies omitted).
    Discord • Streamed reply previews kept when tool‑warning finals arrive.
    • Final replies delivered in preview streams, not deduplicated.
    • Subagent replies now routed to the bound Discord thread.
    WhatsApp • Forced‑document delivery for images/GIFs/Videos; MIME‑based filenames when none supplied.
    • Upload‑file now treated as supported media send intent.
    Slack • Delivered inbound message IDs persisted; duplicate replies prevented.
    • Legacy interactive /Slack directive APIs deprecated.
    WebChat • textChunkLimit and chunkMode respected; internal runtime‑context messages hidden from history.
    Feishu • Subagent delivery origins returned correctly; inbound session context refreshed for DMs, groups, broadcasts.
    Signal • Mixed‑case group IDs preserved through routing.
    iOS / Android • Live Activities end when OpenClaw disconnects; TLS thumbprint change prompts user before replacement.
    Browser • URL allow‑list checks for /act evaluate/batch and /highlight.
    • CDP proxy bypass works with both NO_PROXY casings; home‑relative Chrome profile paths redacted.

    4. Model & provider updates

    Provider Changes
    OpenAI / Codex • Minimum Node floor enforced; GPT‑5.1⁄5.2⁄5.3 now accepted.
    • Deterministic tool‑payload ordering for prompt‑cache reuse.
    • Removed hard‑coded brevity caps on GPT‑5 final replies.
    Anthropic • Image input preserved for Claude 4 when catalog rows are stale.
    DeepSeek • anyOf/oneOf unions normalized before schema compaction.
    Together • PI runtime packages updated to 0.74.1; reasoning controls added for compatible models.
    Google (Gemini) • Thought signatures kept during replay; malformed Base64 dropped safely.
    GitHub Copilot • Identity‑encoded API responses used; gzip payloads no longer break JSON parsers.
    xAI • Full OAuth PKCE flow fixed; video generation defaults and User‑Agent attribution added.
    Ollama (via Telegram) • Image attachments passed to native Ollama vision turns.

    5. Tool & skill extensions

    Skill / Tool New / Updated
    Meme‑maker Template search, local SVG/PNG rendering, Imgflip hosting, Know‑Your‑Meme provenance links.
    Python debugging pdb, breakpoint(), post‑mortem, debugpy remote attach.
    Node inspector Debugging skill added.
    Fused diagram generation New skill for diagram creation.
    Obsidian Now targets the official CLI binary; third‑party obsidian‑cli deprecated.
    Image generation Distinct prompts can start separate background tasks; retries still reuse the active task.
    Media Sharp fallback chain (Sharp → sips → native imaging → ImageMagick/GraphicsMagick → ffmpeg).
    Music / Jingle music_generate now handles full audio generation, not just lyrics.
    Video generation Together v2 video API used when config still points at v1.
    CLI/media Accept HTTP(S) URLs for openclaw infer image describe --file.
    Skill CLI openclaw skills install/update --global for shared managed skills.
    Skill metadata Empty/whitespace names rejected; prompts tightened; quoting added.

    6. Development & CI tooling

    Item Description
    ClawSweeper proof Real‑behavior proof verdicts must come from the ClawSweeper GitHub App.
    CI Added rollback protocol‑mismatch diagnostics; gateway protocol v4 restored.
    Plugin SDK Bundled zod sub‑path into published artifact for global installs.
    PowerShell completion Fixed profile path resolution and reload handling.
    GitHub Copilot Dropped unsafe native reasoning replay items with non‑replayable IDs.
    Proof gating Private‑org maintainers can skip real‑behavior proof gate via a low‑privilege GitHub App token.
    Process diagnostics Active lane blockers now shown; active turn no longer counted as queued backlog.

    7. Miscellaneous / Bug fixes

    • Port validation – reject > 65535 early.
    • Gateway auth – trusted‑proxy callers can use documented password fallback; token fallback still rejected.
    • Message tool – keep available in embedded runs when allowed via tools.alsoAllow.
    • Control UI – protocol versions now shown in mismatch errors; child nav items hidden when sidebar collapsed.
    • Session handling – subagent registry saved before reporting spawn; keep‑mode completions retained after retry exhaustion.
    • Runtime‑tool coverage – missing required tool exercises now cause failures.
    • Various UI polish – quick‑config rows left‑aligned, card rows full‑width, consistent gutters, etc.

    Bottom line

    v2026.5.19‑beta.2 is a big, integrative release that:

    1. Stabilizes the core runtime (agent/tool contracts, gateway restart behavior, Docker image building, Node version enforcement).
    2. Expands and polishes the UI (settings redesign, faster loading, clearer error messages).
    3. Adds many new skills/tools (meme‑maker, Python debugger, node inspector, media handling improvements).
    4. Improves channel reliability (Telegram, Discord, WhatsApp, Slack, Feishu, Signal, WebChat).
    5. Updates provider support (OpenAI, Anthropic, DeepSeek, Together, Google, xAI, Copilot).
    6. Strengthens QA and CI (new parity tiers, tool‑coverage reports, proof‑gate tightening).
    7. Fixes hundreds of regressions across agents, plugins, memory, config, and UI.

    Overall, the release readies OpenClaw for production‑grade use in 2026, delivering richer functionality, tighter security, and more predictable behavior across all supported platforms.

    2026-05-20 05:48

  • antigravity 登录后验证 需要 扫码验证怎么破 - V2EX
    antigravity 登录后验证 需要 扫码验证怎么破 - V2EX

    核心内容概述

    这篇 V2EX 帖子讨论的是在使用 antigravity（一个基于 Google 账号的服务）登录后，系统要求进行 二步验证（Two‑Factor Authentication，2FA），但用户只能通过 短信验证码 完成验证，而绑定的手机是国内号码，根本收不到国际短信，导致登录受阻。

    主要信息点

    序号 内容 说明
    1 问题描述 用户在 antigravity 登录 Google 账号后，被要求进行二次验证（扫码/短信）。唯一可用的验证方式是短信，绑定的是国内手机号，收不到验证码。
    2 求助目标 如何绕过或解决只能使用短信验证码、无法收到验证码的情况，使登录能够顺利完成。
    3 社区回复 只有一条回复，内容如下：
    - “扫码是什么，没见过，手机上下了 Chrome，
    两步验证除了手机号还有 APP 验证，直接在手机 APP 里选数字就登上了。”
    这暗示了可以使用 Google Authenticator、Microsoft Authenticator、Authy 等基于 TOTP（一次性密码）的验证 APP，而不是依赖短信。
    4 隐含的解决思路 1. 开启基于 APP 的 2FA：在 Google 账户安全设置里，添加“验证器应用”作为第二步验证方式。
    2. 使用二维码扫描：在登录页面出现二维码时，用手机上的验证器 APP 扫描，生成 6 位一次性密码。
    3. 更换绑定手机号：如果必须使用短信，可在 Google 账户中更换为能够收到国际短信的号码（如使用国外虚拟号码或亲友的手机号）。
    4. 备份码：在设置 2FA 时，Google 会提供一组一次性备份码，保存后可在无法收到验证码时使用。
    5 注意事项 - 开启 APP 验证后，务必保存好备份码，防止手机丢失导致无法登录。
    - 若已经被锁定，需要通过 Google 的 账户恢复流程（提供身份信息、使用已登录设备等）来解锁。
    6 结论 该帖的核心结论是：不要只依赖短信验证码，而是使用手机上的验证器 APP（或备份码）来完成二步验证，从而绕过国内手机号收不到国际短信的问题。

    简要操作步骤（供参考）

    1. 登录 Google 账户（如果已被锁定，先走恢复流程）。
    2. 进入 “安全性” → “两步验证”。
    3. 在 “验证方式” 中选择 “使用验证器应用”（Google Authenticator、Authy 等）。
    4. 按页面提示，用手机 APP 扫描二维码，完成绑定。
    5. 记录下 备份码，妥善保存。
    6. 以后登录 antigravity 时，选择 “使用验证器应用”，在手机 APP 中输入生成的 6 位验证码即可完成登录。

    这样即可摆脱只能通过国内短信进行二次验证的困境，实现顺利登录。

    2026-05-20 05:49

  • 我今天在claudecode使用deepseek发现它的网络搜索工具用不了，有没有佬友碰到这种情况 - 开发调优 - LINUX DO

    核心问题

    • 作者在 Claude Code（claudecode）插件中使用 DeepSeek‑v4‑flash（或 deepseek‑reasoner）时，调用内置的 WebSearch / WebFetch 工具报错：
      
API Error: 400 deepseek-reasoner does not support this tool_choice

    • 之前可以正常使用，突然失效，引发讨论。

    关键线索

    1. 模型版本：

      • 有人指出使用的是 R1（已下架），而不是 v4。
      • DeepSeek 官方声明 deepseek‑chat 与 deepseek‑reasoner 将在 2026‑07‑24 停止服务（即将废弃）。

    2. 工具实现：

      • WebSearch、WebFetch 这类需要后端实现的工具 DeepSeek 本身并未提供，只能在兼容 Anthropic API 的模式下使用 tool_choice 参数。
      • DeepSeek 的 API 在当前版本不接受 tool_choice，导致 400 错误。

    3. 社区反馈：

      • GitHub Issue（Claude Code WebSearch broken: deepseek-reasoner does not support tool_choice）记录了同样的问题，说明这是 DeepSeek API 与 Claude Code 之间的兼容性缺陷。
      • 有用户在 VSCode 中使用 CC 插件（Claude Code）时未出现该错误，说明不同插件可能实现了自己的搜索后端。

    4. 临时解决方案：

      • 删除本地的 claude.json 配置文件（该文件会强制使用 DeepSeek 的 tool_choice 参数），即可恢复正常。

    5. 后续走向：

      • DeepSeek 将在 2026‑07‑24 停止 deepseek‑chat 与 deepseek‑reasoner，届时需要迁移到其他模型或等待 Claude Code 官方更新对新模型的兼容实现。

    总结

    • 报错根本原因是 DeepSeek API 已不再支持 tool_choice 参数，而 Claude Code 的网络搜索功能依赖该参数。
    • 受影响的模型是即将废弃的 deepseek‑reasoner / deepseek‑chat，而 v4‑flash 仍可使用，但需要去掉强制的 tool_choice 配置（删除 claude.json）。
    • 长期解决方案是等待 Claude Code 对新模型的适配或改用其他提供 tool_choice 支持的后端。
    2026-05-20 05:27

  • [架构师之路]兄弟姐妹们，决定一个人发展高度与速度的，究竟是什么底层能力？

    摘要

    这篇博客的标题是《[架构师之路]兄弟姐妹们，决定一个人发展高度与速度的，究竟是什么底层能力？》，但正文只有一句“继续opc商业大航海”。从这唯一的文字来看，文章并未提供实际的技术分析、案例或观点，因而无法提炼出明确的核心内容或结论。

    可能的解读（基于标题的推测）

    虽然正文缺失，但结合标题的关键词，可以推测作者原本想讨论的方向可能包括：

    可能的底层能力 解释 与架构师成长的关联
    系统思维 能够从全局视角审视系统的结构、交互和演化。 架构师需要把握整体架构的脉络，避免局部最优导致全局失衡。
    抽象能力 将复杂业务抽象为模型、接口、协议等可复用的概念。 抽象是设计可扩展、可维护系统的根本。
    技术深度 对底层原理（如操作系统、网络、分布式一致性）有深入理解。 深度帮助在面对性能、可靠性等关键问题时做出正确权衡。
    学习能力 快速获取新技术、新工具并评估其价值。 技术迭代快，架构师必须持续更新知识库。
    沟通与影响力 能把技术方案转化为业务语言，推动团队落地。 架构决策往往需要跨团队协作和组织层面的认同。
    业务洞察 理解业务目标、痛点和增长路径。 架构必须服务于业务价值，而非技术炫技。

    “opc商业大航海”可能的含义（推测）

    • OPC：在工业自动化领域，OPC（OLE for Process Control）是一套标准协议，用于不同厂商设备之间的数据交换。如果作者提到“OPC商业大航海”，可能在暗指在工业互联网或工业4.0 场景下，如何利用 OPC 进行跨系统集成、数据采集与商业化运营。
    • 大航海：比喻探索未知、开拓新市场的过程。结合“OPC”，可能想表达在工业互联网的浪潮中，企业需要通过技术（如 OPC）进行“航行”，寻找新的商业机会。

    如果按此思路，文章可能想传达的核心信息是：

    在快速变化的技术生态中，决定个人成长高度与速度的关键是具备系统思维、抽象能力和持续学习的底层能力；在具体业务场景（如 OPC 在工业互联网中的应用）里，这些能力帮助我们像“大航海”一样，敢于探索、敢于创新，从而实现商业价值的最大化。

    结论

    由于正文内容极其简短，实际的技术细节、案例分析或作者的个人经验并未呈现。若要真正把握作者想要表达的“底层能力”，建议：

    1. 获取完整文章：联系原作者或查找博客的后续章节，获取完整的阐述。
    2. 关注标题关键词：系统思维、抽象能力、学习能力等是架构师常被提及的核心能力。
    3. 结合业务场景：如果确实涉及 OPC 与工业互联网，进一步研究 OPC 的技术栈、标准以及在数字化转型中的实际落地案例，会更有助于理解作者的意图。

    在目前信息不足的情况下，上述推测与结构化的思考框架可以帮助你在阅读完整内容后快速定位核心要点。

    2026-05-19 09:44

  • 感觉Google的Ai还是被低估了，暂时表现不佳，但更可能后来者居上 - 搞七捻三 - LINUX DO

    核心内容概述（约 350 字）

    在 Google I/O 开发者大会之后，作者（云天明）观察到业界对 Google AI 的评价普遍偏负面，很多人批评其表现不佳。作者认为这并非因为技术本身的缺陷，而是 Google 采用了“全能多模态”路线——即构建一个能够接受任意形式输入（视频、音频、文本、代码、图片等）并输出任意形式结果的统一模型。该模型还支持局部编辑和灵活的修改。

    目前这种“一把抓”式的设计让 Google 的 AI 看起来“贪多嚼不烂”，在某些具体任务上并未达到最优，但作者认为只要模型规模和训练数据继续积累，最终会形成“啥都会、啥都强”的通用能力。一旦成熟，这种全能模型将形成显著的竞争壁垒，其他专注于单一任务或单模态的模型将难以追赶。

    随后社区成员的回复补充了以下观点：

    1. 技术难度：实现真正的全局世界模型非常困难，成熟可能需要很长时间。
    2. 使用取向：实际使用时更倾向于“用得爽就用”，不必过度执着于长期预判。
    3. Google 的整体布局：AI 只是 Google 生态的一部分，公司的更大野心是掌控整个操作系统与服务链。
    4. 商业动机：随着 Gemini 2.5⁄3.1 的发布，Google 对 AI 的紧迫感下降，转而更关注硬件（如 GPU）盈利。
    5. 市场竞争：有人担心后起之秀（如国产模型）可能在未来超越 Google，但也有人认为只要当前好用就继续使用。

    总体来看，作者对 Google AI 持乐观态度，认为其全能多模态路线在长期会形成技术壁垒，尽管短期表现不佳；社区则围绕技术实现难度、实际使用体验以及商业策略展开讨论。

    2026-05-20 06:20

  • [架构师之路]我的思考：上班越久，可能越不适合OPC...

    抱歉，我无法对这篇博客进行总结，因为您提供的正文内容为空。如果您把文章的主要段落或要点贴出来，我可以在 1000 字以内为您提炼出核心要点并进行概括。

    2026-05-18 14:31

  • 我的一人公司AI视频团队，被腾讯收编了大家好，我是袋鼠帝 先看一个我的产品宣传部20分钟自动做的自带BGM的片子： 对于 - 掘金
    我的一人公司AI视频团队，被腾讯收编了大家好，我是袋鼠帝 先看一个我的产品宣传部20分钟自动做的自带BGM的片子： 对于 - 掘金

    核心内容概述（约900字）

    1. 背景与动机

    • 作者（袋鼠帝）是一名“一人公司”创始人，专注 AI 视频自动化。
    • 他在 20 分钟内用自研系统生成了一段带 BGM 的产品宣传片，效果对非专业剪辑者已相当满意。
    • 受 HyperFrames（heygen 开源的 HTML‑to‑video 渲染框架）启发，发现它对 AI Agent 极友好，能够让 Agent 自动生成并渲染视频。

    2. “产品宣传部”概念与实现

    • 目标：让 AI 完全承担宣传片的全链路工作，而不是仅生成粗糙视频。
    • 工作流：
      1. 产品判断 → 2. Brief → 3. 分镜 → 4. 素材收集 → 5. HyperFrames 剪辑 → 6. BGM 生成 → 7. 成片交付
    • 每一步都有对应的 Skill（AI 能力模块），形成类似真实宣传部门的分工与检查点。
    • 首次在自己的开源项目 cangjie.skill 上实验，成功把 README 内容转化为可视化叙事的宣传片。随后将整套流程拆解为可复用的 Skills 并开源。

    3. 与腾讯 WorkBuddy 的合作

    • 在 Skills 开源后，腾讯 WorkBuddy 团队联系作者，希望把这套“一人公司宣传部”以 “专家团（Expert Team）” 的形式上架。
    • 作者配合完成适配、审核，最终在 WorkBuddy 中以 “袋鼠帝宣传片创作团队” 上线。
    • 用户只需在 WorkBuddy 中搜索“袋鼠帝”，即可调用该专家团完成宣传片制作。
    • 为验证效果，作者让同一套系统为 WorkBuddy 自身的专家团 生成宣传片，过程几乎全自动：
      • 团长拆任务 → Brief → 分镜 → 素材/剪辑 → BGM → 最终合成。
      • 作者仅在关键节点（分镜、配乐、字幕）进行少量审校。

    4. 技术细节与实用建议

    • 模型选择：使用 GPT‑5.5 作为语言 Agent，GPT‑image2 生成图像，效果更稳。
    • 素材来源：可自行喂入图片/视频，若接入浏览器工具，Agent 能自动搜索网络素材。
    • 平台优势：WorkBuddy 支持自定义模型接入，提供完整的多 Agent 协作框架，免去用户自行设计 Agent 角色与协同流程的门槛。

    5. WorkBuddy 专家团的价值

    • 结构：每个专家团都有团长 + 多个分工明确的团员（宣传、开发、内容、SEO、财税、法律等），实现任务自动拆解、并行执行、统一交付。
    • 即插即用：用户只需描述需求（如“帮我做 60 秒产品宣传片”），系统自动完成全部步骤，无需了解 Agent、Skill 的底层实现。
    • 生态：已预置 20+ 行业/职能的 AI 团队，覆盖几乎所有“一人公司”可能需要的部门职能。

    6. 对“一人公司”的启示

    • 过去：一人公司需要自己兼顾运营、销售、设计、剪辑等全部工作，属于浪漫主义的个人全能模式。
    • 现在：通过调度一支 AI 团队，个人只负责需求表达与最终决策，其他工作全部交给 AI 完成，极大提升效率与可持续性。
    • 两条路径：
      1. DIY 路线：使用作者开源的 promo-creator-skills，自行搭建、定制每个环节，适合技术爱好者。
      2. 即用路线：直接在 WorkBuddy 上使用现成的专家团，适合大多数一人公司创业者。

    7. 结语与行动号召

    • 作者邀请读者：
      • 若想快速生成宣传片或其他部门类任务，可尝试 WorkBuddy 的专家团。
      • 若想深度定制、玩转 AI Skill，可访问 GitHub（kangarookin…）提交 Issue/PR。
      • 给文章点星、点赞、转发，关注其 AI 实战分享。

    要点总结：

    • 通过 HyperFrames 与多 Agent 协作，作者构建了“一人公司产品宣传部”，实现从产品判断到成片的全自动流水线。
    • 该系统被腾讯 WorkBuddy 收编为“专家团”，对外提供即插即用的宣传片生成服务。
    • 对于一人公司而言，调度 AI 团队是提升生产力的关键路径，既有 DIY 版也有 SaaS 版可选。
    2026-05-18 16:32

  • 软考准考证可以打印了,有准备考试的,别忘了 - V2EX
    软考准考证可以打印了,有准备考试的,别忘了 - V2EX

    核心内容概述

    这篇 V2EX 帖子主要是提醒准备参加 软考（软考计算机技术与软件专业技术资格考试） 的同学们：准考证已经可以自行打印。帖子里没有提供具体的下载链接或操作步骤，只是简短地告知大家这一信息，并附上鼓励的话语（“希望大家，逢考必过”），希望考生们在考试前别忘了及时打印准考证，以免因未携带准考证而影响考试。

    要点提炼

    1. 准考证已开放打印

      • 考生现在可以在官方平台或指定入口自行下载并打印软考准考证。

    2. 提醒考生及时操作

      • 考前务必检查并打印准考证，确保考试当天携带齐全。

    3. 鼓励与祝福

      • 发帖者以 “希望大家，逢考必过” 之类的祝福语，给准备考试的同学加油打气。

    实用建议（基于常规流程）

    • 登录软考报名系统或官方准考证下载页面。
    • 输入个人信息（准考证号、身份证号等）进行身份验证。
    • 下载 PDF 版准考证，使用 A4 纸打印，确保文字清晰、二维码完整。
    • 打印后检查姓名、考点、考试时间等信息是否正确。
    • 考试当天随身携带准考证和有效身份证件。

    结论
    帖子本身信息量不大，核心就是 “软考准考证现在可以自行打印，请考生别忘了提前打印”，并附带鼓励的话语。考生只需按照官方指引下载并打印即可。

    2026-05-20 06:24
大图预览

Powerd by gogogo . © Cyeam 2026.

Feedback