- 博客(1055)
- 收藏
- 关注
RSS订阅原创 ESP32 唤醒成功，离线命令为什么没有执行？
本文剖析ESP32唤醒后离线命令未执行的根源，指出“唤醒成功”不等于“命令执行”。通过追踪WakeNet、AFE、MultiNet链路，强调需验证命令窗口开启、音频帧合规传递、活动词表生效及状态序列完整。关键在于区分唤醒事件与命令检测启动、核对输入格式与帧序、确认模型实际加载词表，并以最小输入序列复现问题，定位交接断点。
2026-10-15 11:34:55
4
原创 用户说“算了”，设备指令真的取消了吗？
用户说“算了”后，语音Agent虽停止播报并显示“已取消”，但设备仍可能执行原指令。本文指出，仅凭云端任务标记为CANCELED无法证明动作未发生，因设备执行状态需独立验证。撤回成功依赖四个关键节点：命令是否发送、是否领取、是否执行、能否补偿。平台取消不等于物理停止，设备需在执行点原子化判断终止，且需保留完整状态记录。消息过期可防迟到执行，但不能撤销已生效动作。反向操作也不等于回滚，必须区分“请求”与“结果”。最终，系统应基于command_id追踪全生命周期状态，确保反馈真实可信。
2026-10-15 09:42:14
5
原创 PUBACK 已到，灯还没亮：Agent 设备指令何时算完成？
当设备指令发出后，仅收到MQTT的PUBACK并不等于任务完成。协议层面的“接受”不等同于设备执行或状态变更。真正的成功需依赖设备报告的状态与命令身份的关联验证，并结合新鲜度判断。建议引入command_id、report_version_before等字段构建可审计的证据链，区分“已发送”“已执行”“状态确认”等阶段，避免误判。超时后应诚实回应“未知”，而非强行判定成功。最终目标是：以可追溯的证据链，实现从“工具调用”到“用户感知”的可信闭环。
2026-10-14 09:59:50
562
原创 ESP32 唤醒词标称 98%，为什么还要自己做验收？
ESP32-S3 唤醒率98%仅为官方开发板在特定条件下的基准值，不可直接套用于实际产品。因外壳、麦克风位置、唤醒词及播放状态等差异，真实唤醒表现可能显著下降。验收需区分正确唤醒、误唤醒与播放中响应三类指标，分别统计有效试次与分母，避免虚构通过率。测试应保留完整录音与日志，明确无效试次原因，杜绝数据“消失”。使用构造标注脚本可验证统计口径，确保结果可信。
2026-10-14 09:21:09
207
1
原创 H3-World 的动作控制，为什么不能只靠一句提示词？
H3-World 的动作控制不能仅靠一句提示词，因其核心挑战在于动作时序与视频时间槽的精确绑定。单纯语言描述（如“先左后右”）无法确保模型在生成时将“左”动作对应至前段、“右”动作对应至后段。论文通过实验证明，全局提示虽能触发运动，却无法保证时序准确性；而H3-World通过为每个视频latent区间独立分配动作句、利用位置编码与分段掩码（block mask）实现动作与视频段的显式对齐，确保“左句属左段、右句属右段”。此外，静态语义与动作句在Refiner层被分隔，防止信息混杂，再通过路由掩码限制读取范围
2026-10-13 14:22:20
375
1
原创 语音评测显示 Passed，为什么工具调用只有 1/2？
本文解析了语音评测中“Passed”与工具调用仅1/2的矛盾：尽管任务状态为通过，但工具准确度仅50%，实际调用次数少于预期。原因在于评测标准未将关键流程设为必经步骤，导致过程缺陷不影响最终结果判定。文章强调，需明确区分“结果正确”与“过程合规”，通过定义关键步骤（critical: true）、依赖关系及可观测证据，才能有效防止遗漏操作被忽略。同时提醒，仅凭文本评测无法覆盖真实音频链路表现，必须结合设备实测。
2026-10-13 10:28:22
293
原创 单卡 24GB 做首帧视频：Wan 与 Hunyuan 怎么筛？
本文针对24GB显存单卡生成720P首帧视频，对Wan2.2与HunyuanVideo-1.5进行官方路径初筛。重点区分“24GB”“14GB”等数字的适用条件，强调需结合具体命令、卸载策略与完整任务链验证。仅保留具备单卡I2V入口且在预算内的路径（Wan TI2V-5B、Hunyuan I2V），排除高显存需求项。提出容量探针四要素：加载、采样、解码、编码全流程记录，明确失败阶段与资源峰值，避免以“可运行”误判“可用”。最终目标是将“可试”转化为可复现的本机实验记录，为后续画质与效率对比奠定基础。
2026-10-13 09:56:53
217
原创 VAD 明明触发了，语音 Agent 为什么丢掉第一个字？
语音助手丢字问题常因VAD触发与音频起点不一致所致。尽管日志显示VAD已触发，但首字可能已被截断，因触发前的音频需通过VAD cache补全。乐鑫ESP-SR/AFE支持缓存机制，应用应将缓存前缀拼接至处理后音频再送ASR，否则首字丢失。排障需在三处留样：原始采集、AFE输出、ASR输入，对比波形与转写结果，定位缺失环节。仅调低检测门槛无法解决根本问题，必须确保缓存正确接入并记录完整传输路径。本文提供可验证的排查方法，但需实机测试确认。
2026-10-12 16:44:15
105
5
原创 LingBot-World 能连续生成一小时，为什么回到原地仍可能变样？
LingBot-World-Infinity虽能连续生成超一小时视频，但其世界状态并非持久记忆。论文指出，离开上下文后重访区域可能被重新生成，对象身份与事件结果未必保留。动态KV Cache仅支持短期上下文，不等同于可查询的世界存档。公开代码仅支持离线生成，无法验证事件持续性或回访一致性。因此，“持续生成”不等于“世界持久”，回访实验需独立设计并逐项验证锚点、事件与控制分叉，方能评估真实世界状态保持能力。
2026-10-12 11:23:29
338
原创 ESP32 语音设备开了 AEC，为什么仍会听到自己？
ESP32启用AEC后仍自听，可能因参考音频（R通道）未正确接入或与播放不同步。需核对AFE输入格式与数据交织顺序，确保R来自当前实际播放流。建议在固定条件下录制三组同步音频：仅播放、仅人声、双讲，对比R、M与AEC输出，验证参考有效性与算法表现。避免盲目调高抑制强度，应先排查硬件录放失真、参考缺失或延迟问题。最终确认回声消除有效后，再检查VAD、ASR及Agent打断逻辑，确保完整语音交互链路正常。
2026-10-10 11:08:12
257
1
原创 两台 A6000，LingBot 应该先验哪条路径？
基于官方性能报告，两台A6000设备应优先验证：单卡机先复现LingBot-VA 1.0（i2av约18GB）与Video Dense（27.10GiB），记录实测峰值；八卡机则从MoE无Refiner的CP8+DiT FSDP8路径（37.61GiB/GPU）入手，避免盲目使用未实测的完整路径。所有结论需绑定具体输入、拓扑与配置，禁止将“可运行”等同于“兼容”。
2026-10-10 10:05:54
340
1
原创 LingBot-VA 2.0 深度解析：为什么要同时预测未来世界与机器人动作
LingBot-VA 2.0 是一套面向机器人控制的 Video-Action Foundation Model。它不是 LingBot-VLA 2.0 的改名版本，也不是一个把视频生成模型接上动作头的简单组合。VLA 的典型目标是：即根据观测和语言直接输出动作。VA 的目标更接近：其中 (z) 是视觉状态的 latent。这种建模方式把动作放在世界变化中理解。动作不是一个孤立控制量，而是当前状态到未来状态之间的因果桥梁。
2026-10-09 14:02:45
676
2
原创 Cosmos Curator 只跑一条视频，为什么还会加载一串模型？
Cosmos Curator 即使仅处理一条视频，仍会加载多个模型（如 TransNetV2 切分、InternVideo2 向量、Qwen 描述），因 --limit 1 仅限输入数量，不关闭默认启用的处理阶段。需显式关闭 --no-generate-embeddings 与 --no-generate-captions 才能缩减模型依赖。运行环境需确认宿主机与容器入口差异、路径映射正确性、资源可用性，并建议以 fixed-stride 切分 + 关闭模型生成的方式，先验证读入、切分与写出流程，实现快速归
2026-10-09 10:30:20
321
原创 LingBot-Video 怎么选推理路径？8 步 DMD 不等于小显存
选LingBot-Video推理路径需警惕“8步DMD=小显存”误区。DMD是经蒸馏的学生模型，非参数量缩减；其8步采样需搭配专用调度器与引导设置，否则无法复现。MoE-A3B仅激活3B参数，但整体权重仍占显存；FP8加速却可能因缓存共存而增显存。性能受模型身份、采样配方、运行拓扑三者协同影响，须建立“模型-采样-拓扑”核对表，分段定位加载、去噪、落盘问题，避免误判。多卡分片需明确组件与并行策略，单卡验证应优先选小模型。
2026-10-08 15:40:04
373
4
原创 Cosmos Curator 视频还没处理完，GPU 为什么先闲了？
当视频处理任务未完成而GPU利用率下降时，问题可能并非模型性能瓶颈，而是上游供料不足、数据传输延迟或下游积压导致的背压。需结合输入队列、处理状态与输出积压综合判断，避免误判为“模型慢”。尤其在尾段，自动缩容若未开启积压感知保护（如enable_backlog_aware_scaledown=False），可能导致资源过早释放，拖慢整体完成时间。应以任务完成时效为核心目标，而非单纯追求GPU高利用率。
2026-10-08 11:29:17
310
原创 Cosmos Curator 清洗视频时，哪些片段应该留下？
在使用NVIDIA Cosmos Curator清洗巡检视频时，应保留看似“静止”的片段，因其可能包含关键行为（如机器人停顿等待）。运动过滤应前置，但需区分“低运动”与“无运动数据”——负分可能源于解码失败而非真实静止。建议启用score-only模式以保留所有片段供人工核对，避免过早丢弃潜在重要样本。验收时应追溯片段来源、检查元数据完整性，并建立可复核的记录，确保筛选逻辑透明可解释。
2026-09-28 12:23:27
353
4
原创 Agent 能接进 IDE，为什么还不能随意互换？
Agent 虽可接入 IDE，却难以随意互换。因不同 Agent 对任务定义、输入格式、输出结构及执行状态的理解各异，仅接口连通不足以保证功能等价。例如“审查”任务中，普通审查与反方审查在请求路径、上下文构造、结果解析上差异显著。替换需适配输入含义、运行归属与结果解释，确保关键信息不丢失。工作台应通过映射记录明确各环节约束，保留真实语义，而非盲目统一界面。真正的互换，依赖对任务本质的清晰认知，而非表面兼容。
2026-09-27 10:51:52
366
1
原创 ESP32-S3 Mini 和 C3 Mini 怎么买？从 PSRAM、USB 到一张可核对的采购单
选购ESP32-S3/C3 Mini开发板需明确三层配置：芯片、模组（如S3-MINI-1-N8/N4R2）、开发板。关键在内存分配：彩屏+音频需约331 KiB RAM，C3仅400 KB SRAM不足，应选带PSRAM的S3-N4R2；但需注意PSRAM不替代内部RAM，DMA与任务栈仍占内核空间。USB功能也需深究：C3仅支持串口/调试，S3可实现HID键盘，但须确认引脚连接至原生USB（GPIO19/20），而非串口桥。采购时务必核对完整型号、原理图与官方资料，避免因名称混淆导致选型失误。
2026-09-27 09:25:28
473
原创 Codex 只读审查的权限边界：任务文件是谁写的？
本文分析 Codex 只读审查中任务文件更新的权限边界问题，指出模型沙箱的“只读”约束不等于插件整体无写入能力。关键在于区分操作主体：审查线程受限于 read-only 沙箱，但插件宿主可通过 Node.js 文件接口自主保存任务状态（如 writeJobFile）。权限需逐层核对——从线程参数、本地配置、外部工具到服务端凭据，缺一不可。建议通过排查记录明确写入者与路径，避免将“未修改代码”误判为“沙箱失效”。最终结论：只读仅约束特定任务，整个接入链仍需综合评估。
2026-09-26 13:47:29
254
2
原创 权重装进了 24 GiB，四路 32K 上下文还装得下吗？
在24 GiB显存下，加载Qwen2.5-7B-Instruct模型后，扣除15 GiB权重与2 GiB非KV开销，仅剩4.6 GiB可用于KV缓存。四路32K上下文需缓存131,072个token，按BF16精度计算需约7 GiB KV空间，超出预算。因此，该配置无法同时维持四路32K长上下文请求。结论依赖于具体部署参数，需结合实际测量与引擎调度策略评估可行性。
2026-09-26 13:16:58
462
原创 Claude Code + Codex 怎么分工？别把“允许结束”当成“可以提交”
在 Claude Code 与 Codex 协作中，“允许结束”（ALLOW）不等于“问题已解决”。停止审查机制仅判断本轮是否产生有效代码改动，无法确认问题是否真正修复。若上一轮仅为状态说明（如“接下来处理”），即使返回 ALLOW，仍需人工核验修改是否完成。审查者负责发现问题，实现者负责修复并验证，二者职责不可混淆。任务交接应明确：问题是否成立、由谁修复、如何验证。避免将 ALLOW 误读为交付信号，关键在于对具体变更的验收，而非流程提示。
2026-09-24 10:47:20
277
1
原创 Ray 的 remote 调用之后：任务怎样衔接，状态留在哪里?
Ray 的远程调用中，任务衔接与状态管理关键在于解耦提交与等待。原循环因 ray.get 阻塞导致无法并行；改用批量提交 ray.get(refs) 可开启重叠执行。通过 ObjectRef 传递依赖，可实现链式任务调度，但需明确引用与值的区别。若需复用状态（如模型），应使用 Actor，其状态驻留于单个进程，但不自动持久化或跨实例共享。为避免积压，可用 ray.wait 控制并发窗口，实现有界流程。最终，任务依赖、状态位置与资源调度共同决定分布式效率。
2026-09-24 09:39:09
595
原创 让 Codex 当反方：把重试风险问到可验证
在写入接口中加入超时重试时，需警惕“响应丢失但操作已执行”的风险。仅通过测试覆盖“首次超时、二次成功”不足以验证幂等性，关键在于确认业务标识是否跨重试保持一致，服务端能否正确识别重复请求。反方审查应聚焦具体失败路径，基于代码证据推导因果链，而非泛化建议。官方提示词强调“强发现优先”，要求每条意见有文件、行号与置信度支撑，避免无根据推断。使用 /codex:adversarial-review 时，应明确 scope 与 focus，确保问题可验证。最终发现须经实验反证：在模拟响应丢失场景下，观察是否产生重复
2026-09-23 14:58:42
195
1
原创 Kubernetes、Ray、vLLM 都在调度，它们各自决定了什么？
Kubernetes、Ray与vLLM分别决定不同层级的调度：Kubernetes负责将Pod分配至含GPU的节点，确保资源可见；Ray管理Actor运行权限，控制进程启动与资源申请，但不保证显存或模型并行配置；vLLM则在引擎层调度请求，决定是否可执行及内存分配。三者各司其职，需通过请求链路追踪（如req-101）将用户请求、服务副本、Worker进程与底层资源对应，才能精准定位排队根因，避免误判为单一系统故障。
2026-09-23 09:42:57
720
1
原创 自己做一个 Mini Reviewer：让 AI 审到本次准备提交的代码
本文提出一个轻量级 Mini Reviewer 工具，通过精准采集暂存区代码补丁，确保 AI 审查对象与实际提交内容一致。针对常见误读工作区修改的问题，脚本仅收集 git diff --cached 的内容，避免审查未提交或已暂存的变更。通过本地 JSON 快照冻结输入、校验 SHA 与大小，保障审查可靠性。不依赖 SDK，无后台任务，强调“先确认再提交”的安全流程，实现可复现、可验证的代码审查闭环。
2026-09-22 10:31:24
405
2
原创 GPU Pod 已经 Running，为什么扩容还没变成推理容量？
GPU Pod Running 不代表扩容生效，因“Running”仅表示容器启动，未验证模型初始化、通信链路、路由可达及真实请求接入。需追踪从副本创建到首请求成功完成的完整路径，确认新副本通过真实入口持续处理请求。仅依赖探针或日志片段易误判，应以实际请求命中新副本为扩容成功的唯一标准。
2026-09-22 09:37:09
253
原创 CLAUDE.md 越写越长，哪些规则该放到子目录？
本文探讨如何合理组织 Claude Code 项目中的规则文件，避免因文件过长导致上下文冗余。核心原则是：按任务边界而非文件数量拆分规则，通过路径条件精准控制规则加载时机，将发布手册等过程性文档设为按需读取，而非全局加载。强调根目录保留跨模块共识，子目录仅补充局部差异，避免规则冲突。最终以三个具体任务验证规则迁移效果，而非单纯追求文件精简。
2026-09-21 10:51:04
323
2
原创 两台机器跑 vLLM，什么时候才值得引入 Ray？
当两台机器部署vLLM时，是否引入Ray需基于资源分配模式判断：若GPU固定专用，多节点multiprocessing已足够，无需过度依赖Ray；若资源动态共享，Ray的placement group可实现整组资源原子预留，避免部分就绪导致的部署失败。但Ray不自动解决显存隔离、通信路径或服务恢复问题，其价值在于替代自建调度逻辑。决策应以实际运维责任和收益为准，而非“多机必用Ray”。
2026-09-21 09:39:05
397
原创 Codex 后台任务结束了，为什么还不能直接接着用？
Codex后台任务结束后，不能直接使用/codex:result的结果，因返回的可能是失败或取消的任务。需核对任务ID、状态（仅completed有效）及当前代码版本。不同会话间任务不互通，跨窗口需用完整ID查询。取消任务不自动回滚文件，须手动检查git状态。继续调查应使用--resume，转移对话则用transfer，但两者均不迁移工作区状态，仍需人工验证代码一致性与文件变更。
2026-09-20 16:06:10
130
1
原创 vLLM 的 token 预算还有余量，为什么请求仍被抢占？
vLLM 中即使 token 预算仍有余量，请求仍可能因 KV Cache 空间不足被抢占。调度器先判断计算预算，再分配状态空间，二者独立。若新块无法分配（如长输入需124块但仅100可用），即便预算充足，也会触发抢占。被抢占请求状态重置为 PREEMPTED，但已生成输出保留；恢复时需重新计算历史位置，导致延迟增加。因此，预算未耗尽 ≠ 请求可继续执行，核心瓶颈在于 KV Cache 资源而非计算配额。
2026-09-20 10:44:06
506
1
原创 CLAUDE.md 引用 AGENTS.md 后，两边真的读到同一套规则吗？
Claude Code 支持 CLAUDE.md 导入 AGENTS.md,Codex 在同一目录最多选一份指令文件,优先 AGENTS.override.md、其次 AGENTS.md、最后备用名,不是追加清单。两者结合的结论:项目事实可以只存一份,但加载器仍要分别验证。Codex 不解析 CLAUDE.md,Claude Code 也不展开 Codex 的语法,共用文字不等于共用解释器。迁移先合并事实差异再移除副本:区分共同事实、客户端入口、待裁决冲突;确认仍有效的共同要求进 AGENTS.md,过期的
2026-09-19 17:14:46
842
原创 TP、PP、DP、EP 如何组合：八张卡，怎样淘汰不合适的配置
围绕 vLLM stable 文档（页眉 v0.28.0）核验，本文给出一个虚构 Dense 场景（两节点 × 四卡、每卡 48 GiB、权重 120 GiB），把"8 张卡"从乘积等于 8 收敛到 3 个明确候选：A（TP=4/PP=1/DP=2，每节点完整副本 × 2）、B（TP=8/PP=1/DP=1，单副本跨节点）、C（TP=4/PP=2/DP=1，节点间流水线阶段）。三个候选 GPU 数都等于 8，但通信路径与故障域完全不同：A 的请求只进入一个节点；B 的层内通信跨节点；C 把跨节点边界放在阶段
2026-09-19 14:44:17
243
原创 小智断网后还能做什么？沿一次唤醒看清设备与服务端的分工
围绕小智官方客户端 `78/xiaozhi-esp32` 与第三方服务端 `xinnan-tech/xiaozhi-esp32-server` 2026 年的核验版本，本文把一次唤醒拆成三个分界点。在官方固件 `Application::HandleWakeWordDetectedEvent()` → `BeginWakeWordInvoke()` → `ContinueWakeWordInvoke()` 的链路里，唤醒事件命中只是本地触发；`ContinueWakeWordInvoke()` 紧接着检查
2026-09-18 23:12:14
130
2
原创 Expert Parallel 深入解析：专家分得均匀，负载为什么仍不均
Expert Parallel 把逻辑专家热度与物理 rank 工作分成两张表。在 Top-2 稀疏 MoE 下，1000 个唯一 Token 会产生 2000 次专家分配（同一 Token 被两个专家选用各计一次），2000 不能被读成"输入了 2000 个 Token"。vLLM stable 文档的 `Layer Behavior` 表格（页眉 v0.28.0）写明 Expert (MoE) Layers `Sharded across all EP ranks`、并行方式 `Expert Paral
2026-09-18 14:30:44
142
原创 小智首批设备怎样放量？从接入名单到故障后的恢复决定
围绕小智服务端第三方开源实现 `xinnan-tech/xiaozhi-esp32-server` 与官方客户端 `78/xiaozhi-esp32` 2026 年的核验版本，本文拆解首批设备放量时容易把字段语义看反的几处。服务端 `_handle_connection()` 在创建 `ConnectionHandler` 前调用 `_handle_auth()`，启用认证后命中 `allowed_devices` 跳过 token 校验；不在免校验名单内的设备仍走 `Authorization: Bear
2026-09-17 11:11:34
260
5
原创 Data Parallel 深入解析：把请求分给真正有余量的副本
Data Parallel 在在线推理里的价值，是让不同请求进入不同模型副本。本文固定同一 Dense 模型的独立副本为讨论对象，覆盖 2026 年主流推理服务在路由侧的实际做法：vLLM stable 文档把正在调度的请求、等待请求、每个引擎的 KV 状态列为负载均衡可考虑的信息，明确 Dense 模型外部副本方式是启动独立实例、由外部路由器分发 HTTP 请求，无需 `--data-parallel-*` 参数；PyTorch DistributedDataParallel 2.14 文档强调训练 DD
2026-09-17 09:09:43
286
2
原创 小智服务端怎样组织 ASR、LLM、TTS？先追本次连接实际使用的对象
`xinnan-tech/xiaozhi-esp32-server` 固定提交 `6afc54a17def47578a4b3efc4680873689d3168b`（核验 2026-09-12）是第三方开源后端项目，与虾哥官方托管服务不同。`load_config()` 先查 `main_config` 缓存，命中即返回；未命中则读默认 `config.yaml` 与 `data/.config.yaml`。自定义配置含有效 `manager-api.url` 时，代码转去 `get_config_from
2026-09-16 16:39:17
432
1
原创 Pipeline Parallel 深入解析：模型装下了，为什么 GPU 还在等
Pipeline Parallel（流水线并行，PP）按模型层把参数切到多个阶段（Stage），每个阶段主要持有自己负责的模型部分，阶段边界传递后续计算需要的中间张量。vLLM `main` 分支的 `LlamaModel.forward` 在非末阶段返回 `IntermediateTensors`，包含 `hidden_states` 与 `residual`，某些路径还打包辅助状态（`vllm/model_executor/models/llama.py`，页面 d87a440，检查 2026-09-
2026-09-16 10:03:12
587
原创 同一套小智源码，换块 ESP32 开发板为何还要重新适配？
`78/xiaozhi-esp32` 固定提交 `6240b777...`（核验 2026-09-12）的板级适配设计：小智同一份源码支持多种开发板，并不是因为上层有运行时板型识别——`main/CMakeLists.txt` 根据 `CONFIG_BOARD_TYPE_*` 选择 `BOARD_DIR`（L94-95 贴图），再用该目录收集板级 `.cc/.c` 源文件；`main/boards/common/board.h` 的 `DECLARE_BOARD` 工厂宏（L87-90 贴图）由各板文件末尾
2026-09-15 10:51:16
373
5
原创 Tensor Parallel 深入解析：多加 GPU，推理为什么可能更慢
Tensor Parallel（张量并行，TP）让多张 GPU 共同执行同一层线性变换，按输出特征切分得到 Column Parallel、按输入特征切分得到 Row Parallel，两种切分通过 AllReduce 求和把结果合回，避免中间一次不必要聚合；经典结构每个 Transformer 层前向包含两次 AllReduce，本文沿 Megatron-LM 论文 Figure 3(a) MLP 摘录这一配对布局（NCCL 集合通信定义：https://docs.nvidia.com/deeplear
2026-09-15 09:37:25
228
1
neo4j-community-3.5.17-unix.tar.gz 是 Neo4j 官方发布的 社区版
2025-10-14
Git的基本内容介绍
2024-10-08
大模型对生活和工作的改变
2024-09-28
人工智能时代，程序员如何保持核心竞争力？
2024-09-25
关于#Spark# #Flink#的问题，如何解决？
2024-09-24
TA创建的收藏夹 TA关注的收藏夹
TA关注的人