不知道什么情况 还是触发了什么 很正常的帖子要审核 @neo 2 个帖子 - 2 位参与者 阅读完整话题
有这样的工具吗？因为有时候想开发多给功能在不同的分支上。 4 个帖子 - 3 位参与者 阅读完整话题
比如 计算机视觉、图像处理与多模态感知、人工智能、大模型、机器学习与智能算法、物联网、边缘计算这些方向如果要选择该怎么选呢，有无这些方向毕业的研究生大哥。
比如 计算机视觉、图像处理与多模态感知、人工智能、大模型、机器学习与智能算法、物联网、边缘计算这些方向如果要选择该怎么选呢，有无这些方向毕业的研究生大哥。
前言+思路来源 昨天我看论文的时候，看到一个很有意思的概念：“元编程”。其含义大概就是opus等处理完全没见过的编码语言问题时，会先将问题转化成python等他熟悉的语言脚本编写问题。然后再用脚本输出答案，而不是直接去编码，大大提高了正确率。 我就在想，对于ai来说，复杂任务的分析，是不是可以参考“元编程”的概念，再结合残差的先做一个基线，再在此基础上慢慢调优的想法，做一个复杂任务分析流程。 整体思路与实现的一些关键 先让ai将复杂问题转化成已知领域的问题，然后做一个基线的版本，再在此基础上调优，最后达到可交付版本的水准。 这样的话，也可以大幅度减少复杂任务分析时token的用量，即仅在一些关键节点时使用高性能模型，其他时候可用低性能模型。 我写了执行分工和任务等级判定模块，各位佬可以根据需求来写，包括如何判断等。 我是用的deepseek-v4-pro，所以我写的是一般都用思考等级“high”正常处理，仅在关键时刻用QQ发信息给我说要调“max”来进行更为复杂的处理。各位佬可以用不同的模型，我也测了用deepseek-v4-flash来处理一般问题，在复杂的时候提醒我用/model来手动切，效果也不错（我主要是嫌麻烦再加上deepseek真的便宜吧） 整体优化与规范化我让gpt-5.5帮我做的，skill文件分享在这里，各位佬根据需要来取，我的Agent是hermes的Agent，各位佬如果用的是别的Agent还请优化一下做个适配以后再用。 我没什么工程的经验，所以可能还有很多可以优化的地方，还请各位佬看看以后觉得有问题或者有可以优化的点的话还请告诉我，我会尽快去改的。 complex-task-protocol-v5.0.0-final.zip (4.3 KB) 笔者碎碎念 哦我的上帝，这deepseek的api也太便宜了，真的还有更有性价比的模型吗 参考论文： Frontier Coding Agents Use Metaprogramming to Adapt to Unfamiliar Programming Languages （arXiv:2606.10933） Deep Residual Learning for Image Recognition （arXiv:1512.03385） 1 个帖子 - 1 位参与者 阅读完整话题
比如 计算机视觉、图像处理与多模态感知、人工智能、大模型、机器学习与智能算法、物联网、边缘计算这些方向如果要选择该怎么选呢，有无这些方向毕业的研究生大哥。
比如 计算机视觉、图像处理与多模态感知、人工智能、大模型、机器学习与智能算法、物联网、边缘计算这些方向如果要选择该怎么选呢，有无这些方向毕业的研究生大哥。
逆天不，任务管理器进程杀了，但是还是没有关掉……我第一次见 1 个帖子 - 1 位参与者 阅读完整话题
比如 计算机视觉、图像处理与多模态感知、人工智能、大模型、机器学习与智能算法、物联网、边缘计算这些方向如果要选择该怎么选呢，有无这些方向毕业的研究生大哥。
比如 计算机视觉、图像处理与多模态感知、人工智能、大模型、机器学习与智能算法、物联网、边缘计算这些方向如果要选择该怎么选呢，有无这些方向毕业的研究生大哥。
比如 计算机视觉、图像处理与多模态感知、人工智能、大模型、机器学习与智能算法、物联网、边缘计算这些方向如果要选择该怎么选呢，有无这些方向毕业的研究生大哥。
比如 计算机视觉、图像处理与多模态感知、人工智能、大模型、机器学习与智能算法、物联网、边缘计算这些方向如果要选择该怎么选呢，有无这些方向毕业的研究生大哥。
原本想着引入 AI 是减负提效，把重复机械的工作交给工具处理，基础代码都交给AI，能腾出时间休息一下摸摸鱼。结果实际用上之后完全反过来，做不完的需求，老板觉得现在做啥都简单了，刚给需求一会就来问好没有？怎么还没好啊？我都不知道怎么回答了，感觉好累… 3 个帖子 - 3 位参与者 阅读完整话题
有些接口只支持 V1completions，如何去适配message和response，我尝试用 CodeX 帮我进行适配，但是总会出现莫名其妙的问题，想知道有没有一种 skill 或者是一种可以参考的，或者是现成的方案 3 个帖子 - 3 位参与者 阅读完整话题
各位佬友好，用any接claude code桌面版提示以下问题： Configured model not available Your gateway couldn’t serve claude-opus-4-8 . This model may not be configured on your gateway, or access may be restricted. Details Your gateway couldn’t serve claude-opus-4-8 . This model may not be configured on your gateway, or access may be restricted. message: Gateway rejected model "claude-opus-4-8" (HTTP 400) httpStatus: 400 requestUrl: https://a-ocnfniawgw.cn-shanghai.fcapp.run/v1/messages probedModel: claude-opus-4-8 responseBody: {"error":"1m 上下文已经全量可用，请启用 1m 上下文后重试","type":"error"} endpoint: https://a-ocnfniawgw.cn-shanghai.fcapp.run/ checkedAt: 2026-06-10T08:05:31.245Z 下面是我的配置： { “env”: { “ANTHROPIC_AUTH_TOKEN”: “sk-”, “ANTHROPIC_BASE_URL”: “ https://a-ocnfniawgw.cn-shanghai.fcapp.run ”, “ANTHROPIC_DEFAULT_HAIKU_MODEL”: “claude-opus-4-8[1M]”, “ANTHROPIC_DEFAULT_OPUS_MODEL”: “claude-opus-4-8[1M]”, “ANTHROPIC_DEFAULT_SONNET_MODEL”: “claude-opus-4-8[1M]”, “ANTHROPIC_MODEL”: “claude-opus-4-8[1M]” }, “includeCoAuthoredBy”: false } 要怎么调整吗？ 或者有没有佬友发下可以用的配置？谢谢啦~ 5 个帖子 - 4 位参与者 阅读完整话题
近日，编号为 CVE-2025-10263 的严重安全漏洞正式对外披露，被确认影响多款 Arm 架构 CPU 内核，涉及范围涵盖最新与多代早期产品。该漏洞被评为“严重”等级，攻击者可利用特定内存权限变更过程中的时序条件，在受影响系统上实现本地权限提升。 根据公开信息，问题根源在于：在执行 TLB 失效（TLBI）操作时，相关内存访问的完成情况并不能由 TLBI 的完成所严格保证。 在某些场景下，这一行为可能导致对本应由更高异常级别（如更高特权级）拥有的资源进行非法写入，从而成为攻击者提升权限的手段。 该漏洞虽然在 2025 年就已分配编号，但直到 2026 年 6 月才正式公开披露。 Arm 在其安全公告中给出了受影响内核清单，范围相当广泛。 其中包括最新的 C1-Ultra 和 C1-Premium，以及此前面向服务器和数据中心的 Neoverse V3、V3AE、V2、V1、N2、N1 等系列内核。 同时，大量面向高性能移动和客户端设备的 Cortex 系列也在影响范围之内，包括 Cortex-X925、Cortex-X4、Cortex-X3、Cortex-X2、Cortex-X1 与 X1C，以及 Cortex-A710、Cortex-A78、A78AE、A78C、Cortex-A77、Cortex-A76 与 A76AE 等型号。 针对该问题，Arm 给出的软件层面缓解建议是：任何执行适用于一级或一级加二级页表信息的 TLB 失效操作的软件，都必须额外执行一次 TLBI 操作并配合 DSB（Data Synchronization Barrier，数据同步屏障），以确保相关内存访问在权限变更前被正确完成。 相应的技术细节及推荐缓解方案已记录在 Arm 公布的安全公告中。 Linux 社区已经在第一时间响应，并为内核提供了补丁实现上述缓解措施。 来自 Arm 的开发者今日向 Linux 内核邮件列表提交了补丁系列，通过对相关代码路径进行调整，确保在执行受影响场景下的 TLB 失效时增加必要的 TLBI 与 DSB，从而降低漏洞被利用的风险。 该补丁目前已面向主线内核进行提交，后续预期将通过各大发行版更新向用户下发。 除了 Arm 官方列出的处理器外，NVIDIA 也确认其最新的 Olympus 内核同样受到 CVE-2025-10263 的影响。 NVIDIA 在另一份提交给 Linux 内核的补丁中指出，其新一代 NVIDIA Vera CPU 所采用的 Olympus 内核存在相同问题，并通过后续补丁引入对应的缓解措施，以与上游通用修复保持一致。 在实际风险层面，由于该漏洞可在特定条件下实现向高特权级资源的写入操作，理论上能够为攻击者提供本地权限提升途径，因此被评为“严重”级别并不意外。 不过，目前并未有大规模实战利用案例被公开报道，业界主要聚焦在尽快完成内核和系统软件层面的修复，以防止后续可能出现的攻击场景。 对于 Linux 用户和服务器运营方而言，当前最关键的行动是关注各大发行版即将提供的内核更新，并尽快完成升级部署。 在此之前，云服务提供商、大型数据中心以及基于受影响 Arm 平台的设备厂商，也需要评估自身硬件所使用的处理器型号与工作负载场景，及时跟进 Arm 与 Linux 社区发布的缓解建议。 查看评论
临睡前一个 goal 干了 7h,感觉主动性好了很多,之前反复强调要看 ci 有没有失败,要处理 coplit comments,这次不说就默默干完了,质量感觉也高不少,至少 coplit 都挑不出来什么问题了 1 个帖子 - 1 位参与者 阅读完整话题
在处理任务的时候打断发送新消息改它的理解错误，不用等待发送。有这个功能吗，其他都有的 5 个帖子 - 2 位参与者 阅读完整话题
下午服务B里面有条告警提示处理超时（timeout），业务上是服务A去RPC【注意这个RPC是公司内部封的HTTP，后面可以用CURL测试】调用服务B 但是，是偶现的，一会又突然正常了 排查了服务B的接口代码发现除了数据库操作就没有高耗时情况，和ai也确认了下 排查sql执行计划，这条sql也没问题 CURL在k8集群上也可以正常跑通 后面找运维确认了异常时间的监控盘有吗cpu和内存，健康检查； 网络是否有超时、丢包、连接数异常； DB 连接池是否耗尽或等待严重 得到反馈都是正常的，但是ELK上还是隔一会就error下 目前拉高了数据库链接数，之前这个项目历史配2；还有什么思路呢 1 个帖子 - 1 位参与者 阅读完整话题
这是刚刚测试的天气卡片，佬友们有什么想法，我个人感觉这个太阳周围的光线处理好了一些 10 个帖子 - 10 位参与者 阅读完整话题