我的编程套餐尝试:对大多数个人开发者,OpenCode Go 套餐值得试

我的编程套餐尝试:对大多数个人开发者,OpenCode Go 套餐值得试 尤其是像我这种经常折腾 Docker、后端服务、AI 工具、UI 页面、脚本排错的人,$5 首月 / $10 每月的价格很有性价比。 OpenCode 官方说明:Go 是低成本订阅,首月 $5,之后 $10/月,可用于 OpenCode 或其他 agent,并支持充值兜底;它包含 GLM、Kimi、Qwen、DeepSeek、MiniMax、MiMo 等开放模型。(开源代码) 为什么值得 1. 价格低,但额度不算小 官方文档写得比较清楚:Go 套餐不是简单按"请求次数"限制,而是按等价用量限制: 限制周期 用量额度 5 小时 $12 usage 每周 $30 usage 每月 $60 usage 实际请求次数取决于你选的模型。比如官方估算,DeepSeek V4 Flash 每月可到 158,150 次请求,Qwen3.7 Plus 每月约 21,600 次,GLM-5.2 每月约 4,300 次。(开源代码) 这对日常 coding、改 bug、解释报错、生成脚本、写 Dockerfile、分析日志,已经非常够用。 2. 很适合作为"日常编码副驾驶" Go 套餐的定位不是替代最强闭源模型,而是提供稳定、便宜、可大量使用的开放 coding 模型。官方也说它主要解决的是开放模型访问不稳定、不同 provider 质量不一致的问题,OpenCode 会筛选和 benchmark 适合 coding agent 的模型组合。(开源代码) ...

2026-06-17 · 1 min · 156 words · FunkyGod

技术日报|Apple联手Gemini、OpenCV 5重磅更新、Agent CAD工具兴起

技术日报|2026年6月10日 今日技术圈最大新闻:Apple 联手 Google Gemini 重塑 AI 战略;OpenCV 发布五年来最大版本更新;GitHub 多款 Agent 性能优化工具冲上Trending;AI 编程工具正式进军 CAD 工程设计领域。 🏷️ [AI] Performative-UI — 设计模式组件库让AI编程更规范 🔥 推荐指数: 8/10 📌 一个 React 组件库,将经典设计模式(design tropes)系统化封装,供 AI 编程工具调用 🔗 https://vorpus.github.io/performativeUI/ 💡 在 AI 编程工具遍地开花的当下,如何保证 AI 生成的代码遵循经过验证的设计规范?Performative-UI 给出了答案:把设计模式组件化,让 AI 直接调用而非每次「凭感觉」生成。这个思路对于提升 AI 编程质量有重要参考价值,HN 上 904 分的高热度也说明了社区对 AI+UI 规范化问题的广泛关注。适合前端开发者和 AI 编程工具研究者关注。 🏷️ [AI] OpenCV 5.0 发布 — 计算机视觉五年来最大版本跳跃 🔥 推荐指数: 9/10 📌 OpenCV 5 正式发布,带来全新 DNN 模块、硬件加速优化和现代 AI 工作流支持 🔗 https://opencv.org/opencv-5/ 💡 OpenCV 5 是自 2018 年以来的最大版本更新,重点包括:完全重写的 DNN 模块支持更快的深度学习推理;原生 CUDA/Metal/Vulkan 多后端加速;新一代图像处理算法。对于从事计算机视觉的开发者,这是必须跟进的重要版本。特别是新 DNN 模块对 Transformer 架构的支持大幅改善,意味着可以在 OpenCV 生态内直接部署 YOLO、SAM 等现代模型。HN 上 516 分的高热度足以说明这个事件的重量级。 ...

2026-06-10 · 2 min · 411 words · 技术日报

Harness工程:把AI的错误控制在有限范围内

Harness工程不能保证AI永远不走偏,但它能把AI从'自由发挥的概率模型',变成一个'有边界、可验证、可审计、可恢复的工程系统'。

2026-06-03 · 4 min · 803 words · FunkyGod

Harness Engineering:让 AI 可靠执行长任务的系统工程学

模型之外的那个「执行环境」,才是决定任务能否跑完的真正变量。

2026-06-02 · 2 min · 248 words · FunkyGod

作为独立开发者,我为什么选择 Eino 来构建 AI 应用(Go语言)

作为独立开发者,我为什么选择 Eino 来构建 AI 应用(Go语言) 独立开发者做 AI 应用,最怕两件事:一是踩坑,二是被框架绑架。 踩坑意味着你花了两周搭的系统,上线后发现根本撑不住并发,或者调试起来像开盲盒;被框架绑架意味着框架的每一次大版本更新都是你的加班夜。 我花了一段时间评估了几个主流选项,最后在自己的项目里选了 Eino。说说理由。我使用的 Eino 版本如下: github.com/cloudwego/eino v0.8.13 你一个人,精力是最稀缺的资源 独立开发者和公司团队最大的区别,不是技术水平,而是精力分配。你同时要管产品、设计、开发、运营,留给"研究框架"的时间极其有限。 这就是为什么框架的设计哲学对你来说比对大公司更重要。一个设计混乱的框架,会把你困在细节里;一个设计清晰的框架,让你专注在真正重要的事上。 Eino 的核心设计思路很简单:把能力拆成组件,把流程描述为图,框架处理所有脏活。 你需要一个 RAG 系统,就把检索、提示词、模型调用几个节点连起来;你需要一个能用工具的 Agent,就把工具注册进去,Agent 的循环调用逻辑框架全包了。 你不需要理解流式数据如何在节点间传递,不需要手写工具调用的解析循环,不需要自己实现多轮对话的上下文管理。这些都是框架该做的事,Eino 做了。 字节跳动帮你提前踩过坑 独立开发者最大的风险之一,是用了一个没有生产验证的框架。看起来文档漂亮,demo 跑得顺,真到线上就各种奇怪问题——并发时状态串了,流式输出在特定场景下卡住了,Token 超限时框架直接崩了。 Eino 在字节跳动内部跑了超过半年,支撑着豆包、TikTok 这类亿级用户的产品。这不是说拿来炫耀的背书,而是一个工程上的实际意义:那些你独自开发时可能要花几个月才踩到的边界 case,字节内部的工程师已经踩过了,并且修掉了。 你站在他们的肩膀上出发,少走很多弯路。 Go 语言是独立开发者的好朋友 很多 AI 框架是 Python 的,Python 当然没有问题,但如果你的后端是 Go 写的——或者你打算用 Go——那嵌入一套 Python 框架会带来真实的运维成本:两套依赖管理、两个运行时、两种调试工具。作为一个人,你付不起这个代价。 Eino 是原生 Go 框架,跟你现有的 Go 服务深度集成,单二进制部署,没有额外的运行时负担。Go 的强类型也意味着很多错误在写代码时就被发现,而不是到线上才暴露——对于没有 QA 团队的你,这一点格外重要。 你不用从零开始集成所有东西 独立开发者做 AI 应用,通常需要接入:某个大模型 API、某个向量数据库、某个可观测性工具。每接一个,都要读一遍 SDK 文档,写一堆胶水代码。 Eino 的扩展库(EinoExt)已经帮你把这些都做了。OpenAI、Claude、Gemini、豆包 Ark、Ollama,开箱可用;Elasticsearch 等向量存储,直接接;OpenTelemetry 的 Tracing,一行配置。你换模型供应商不需要改业务代码,换向量库也一样——因为 Eino 的组件接口是统一的,实现是可替换的。 ...

2026-05-29 · 1 min · 115 words · FunkyGod

我为什么推荐 new-api:从「能调用模型」到「能运营 AI 业务」的工程答案

很多团队做 AI 产品,第一阶段都很顺利: 调通一个模型; 写几个 API; 跑出一个 demo。 但到了第二阶段,问题会集中爆发: 客户要稳定,单一上游不稳定; 成本要可控,调用量上来后账就乱了; 用户要分层,个人、团队、管理员权限都不一样; 运营要可视,出了问题要知道是谁、哪个 key、哪个渠道、哪个模型; 商业要闭环,充值、订阅、额度、结算要打通。 这时你会发现,真正难的不是“会调模型”,而是“把模型能力做成一个能长期运营的系统”。 我这几天把 new-api 关键代码路径完整过了一遍,结论是:它的价值不在于“支持 40+ 上游”这句话本身,而在于它把 AI 网关最难的工程问题做成了一整套闭环。 这篇文章我不做功能清单,而是按“工程决策”的视角,讲我为什么推荐它。 典型请求链路 客户端 ↓ /v1/chat/completions 或 /v1/messages ↓ 认证 TokenAuth / UserAuth ↓ 限流 ModelRequestRateLimit ↓ 分发 Distribute ↓ Relay 进行请求校验、token 估算、预扣费 ↓ Adaptor 转换上游格式并请求 provider ↓ DoResponse 解析 usage 与流式结果 ↓ Settle / Refund 完成结算或退款 先说结论:new-api 适合什么团队? 如果你符合下面两条以上,我建议认真评估 new-api: ...

2026-05-23 · 3 min · 542 words · FunkyGod

使用 ChatGPT 修复 QNAP QuMagie 相册不显示照片的问题

使用 ChatGPT 修复 QNAP QuMagie 相册不显示照片的问题 最近处理了一次 QNAP NAS 上 QuMagie 相册无法显示照片的问题。表面现象很迷惑:照片和视频明明在 File Station 里能看到,Multimedia Console 也显示已经完成索引,但 QuMagie 页面里却始终是空的。 这篇文章记录完整排查和修复过程。为了保护隐私,文中的 NAS 地址、账号、真实共享目录、家庭成员姓名、照片路径都做了替换。示例目录和账号仅用于说明问题,不对应真实环境。 问题现象 NAS 上有一个用于存放家庭照片的共享目录,本文用下面这个名字代替: 家庭照片/ QuMagie 的内容来源也已经添加了这个目录。登录 QuMagie 后,页面提示: 此内容源文件夹中没有可用的照片或视频。 此内容源文件夹可能为空,您的访问权限不足,或文件当前仍在处理中。 但其他地方看起来都正常: File Station 可以看到照片和视频。 使用同一个 NAS 账号可以进入目录。 Multimedia Console 里显示照片、视频、缩略图、人物识别、物品识别等任务都已有索引。 QuMagie 内容管理里也能看到这个来源目录。 这类问题很容易让人以为是“权限不足”或“索引还没跑完”。但这次真正的问题并不是文件不存在,也不是普通意义上的权限不足,而是 QuMagie 的共享目录权限路径和 Multimedia Console 的索引路径不一致。 为什么请 ChatGPT 参与排查 这次我没有把 ChatGPT 当成一个简单问答工具,而是把它当作一个排障协作伙伴来用。 整个过程里,ChatGPT 帮我做了几件事: 把现象拆成 File Station、Multimedia Console、QuMagie UI、QuMagie API、底层路径几个层面。 避免直接做破坏性操作,先验证再处理。 设计迁移方案,确保照片和视频不丢。 识别 NAS 自动生成的缩略图、回收站、快照目录,避免污染新相册。 最后通过数量校验和 QuMagie API 确认修复有效。 对 NAS 这类“UI 看起来正常,但底层路径很绕”的问题,单靠界面判断经常不够。ChatGPT 的价值主要是帮助我把排查流程变得更系统。 ...

2026-05-21 · 3 min · 482 words · FunkyGod

【AI前沿观察】2026-05-14 日报

【AI前沿观察】2026-05-14 日报 自动生成于 2026-05-14 23:00 📊 今日推送概览 共推送 1 条重要资讯。今日整体行业动态相对平静,OpenAI 在 Agent 安全基础设施方面持续发力。 🔵 AI 领域 Building a safe, effective sandbox to enable Codex on Windows 事实:OpenAI 发布技术博客,详细介绍了为 Codex(代码 Agent)构建 Windows 沙箱的技术方案。该沙箱旨在让 Codex 能够安全地在 Windows 环境中执行代码操作,同时防止恶意行为和越权访问。这是 Codex 从 macOS/Linux 扩展到 Windows 的关键一步。 思考:Codex 作为 OpenAI 的旗舰代码 Agent 产品,其核心挑战不仅仅是"能写代码",更在于"安全地执行代码"。沙箱技术是 Agent 从实验室走向生产环境的必备基础设施。扩展到 Windows 意味着 Codex 正在覆盖全球最大的开发者群体——企业级 Windows 开发环境。这背后体现的是 OpenAI 对 Agent 安全边界的深思熟虑:不是简单地限制功能,而是通过精细化的沙箱隔离,在安全性和可用性之间找到平衡。结合此前"Running Codex safely at OpenAI"的博客,可以看出 OpenAI 正在系统性地构建 Agent 安全框架,这为其未来的企业级部署铺平道路。 📌 今日核心洞察 Agent 安全成为 AI 公司的核心竞争力:OpenAI 连续发布 Codex 安全相关博客,从总体安全策略到具体平台的沙箱实现,表明"安全地运行 Agent"已经成为 AI 公司从技术演示走向企业级产品的关键门槛。谁能更好地解决 Agent 的安全问题,谁就能更快地占领企业市场。 ...

2026-05-14 · 1 min · 113 words · FunkyGod

Claude Opus 4.7 正式发布:编程能力飞跃,多模态大幅增强

🚀 核心发布信息 模型名称:Claude Opus 4.7 定位:Opus 4.6 的直接升级版,但能力不及最强模型 Claude Mythos Preview 定价:与 Opus 4.6 相同(输入 $5/M tokens,输出 $25/M tokens) 可用渠道:Claude 全系产品、API、Amazon Bedrock、Google Vertex AI、Microsoft Foundry 📈 主要技术升级 1️⃣ 编程能力大幅提升 在 Anthropic 内部 93 项编码基准测试中: 指标 Opus 4.6 Opus 4.7 提升 综合解决率 58% 70% +12% 复杂任务 部分失败 解决 4 个新任务 首次突破 工具错误率 基准 减少 1/3 大幅提升 执行连续性 易中断 贯穿工具故障 显著改善 用户反馈(来自早期测试): Devin:长时间自主工作数小时,攻克此前无法解决的难题 Cursor:CursorBench 从 58% → 70% Factory Droids:任务成功率提升 10-15%,更少工具错误 CodeRabbit:代码审查召回率提升 10%+ 2️⃣ 多模态视觉增强 参数 Opus 4.6 Opus 4.7 最大长边分辨率 ~800px 2,576px(约 3.75MP) 提升倍数 1× 3×+ 应用场景: ...

2026-05-03 · 2 min · 333 words · FunkyGod

老板们,一定要搞定您公司的龙虾记忆分层

🧠 记忆分层架构(原生 3 层 + 我扩展的 2 层) 层级 存储形式 生命周期 用途 访问范围 0️⃣ 会话上下文 当前对话历史(数组) 单次会话 实时理解、即时决策 当前 session 1️⃣ 每日日志 memory/YYYY‑MM‑DD.md 永久(文件) 原始事件记录、原始决策、待办 当前 agent(main session) 2️⃣ 长期记忆 MEMORY.md 永久(文件) 精炼知识、经验总结、偏好、教训 仅 main session(安全隔离) 3️⃣ 结构化知识 Ontology 知识图谱(可选技能) 永久(图谱文件) 实体关系、项目依赖、跨技能状态共享 安装了 ontology 技能时 4️⃣ 跨会话索引 已索引的会话记录(内部存储) 永久(索引) 搜索历史对话、跨会话回忆 通过 memory_search 工具 5️⃣ 外部补充 Compiled‑wiki 补充资料(可注册) 永久(外部) 额外文档、知识库 memory_search corpus=wiki 📂 各层详情 0️⃣ 会话上下文(Session Context) 内容:本次对话的最近数十条消息。 特点:临时性,session 结束后自动消失(除非显式持久化)。 用途:维持对话连贯、处理指代。 1️⃣ 每日日志(每日日志) 路径:<workspace>/memory/YYYY‑MM‑DD.md 写入时机: 重要事件发生后(如完成任务、发布博客) Heartbeat 检查时归档临时信息 示例: ## 2026‑04‑29 - 解读 browser-use 仓库 - 创建 DeepSeek V4 博客文章 - 更新 TOOLS.md(新增 browser-use 技能笔记) 安全:仅在 main session(直接对话)自动加载,群聊、共享环境不读取。 2️⃣ 长期记忆(MEMORY.md) 路径:<workspace>/MEMORY.md 本质:策划后的精华记忆,相当于人类的长期记忆。 存放: 用户偏好(如“主人喜欢简洁技术总结”) 重要决策(如“默认模型改为 GLM‑4.7”) 经验教训(如“避免在群聊中加载 MEMORY.md”) 项目上下文(如“blog‑demo 使用 Hugo + PaperMod”) 维护:Heartbeat 定期回顾最近的每日日志,提炼有价值信息写入。 3️⃣ 结构化知识(Ontology) 技能:ontology(如果已安装) 模型:实体(Person、Project、Task、Event、Document)+ 关系(link、depends_on 等) 好处:跨技能共享状态、约束检查、依赖可视化,适合复杂业务工作流。 4️⃣ 跨会话索引(Session Transcripts) 机制:OpenClaw 为每个会话生成 sessions/YYYY‑MM‑DD‑<slug>.md 并自动建立向量+BM25 混合索引。 检索:memory_search(query, corpus="all") 自动搜索这些索引。 检索原理: 向量搜索(70% 权重)捕捉语义相似度 BM25(30% 权重)保证精确关键词匹配 每块约 400 token,80 token 重叠,SHA‑256 去重 5️⃣ 外部补充(Compiled‑wiki) 用途:接入公司内部 Wiki、产品手册、行业文档等外部知识库。 访问:同样通过 memory_search corpus="wiki" 检索。 🔍 原生检索机制 向量 + BM25 融合(70%/30%) 块分割:400 token 块 + 80 token 重叠,防止上下文丢失 去重:块 SHA‑256 哈希,已有向量直接命中缓存 压缩触发:当会话快达到上下文上限时,系统会让模型在压缩前把关键信息写入 memory/*.md 或 MEMORY.md(即所谓的 “Dreaming”) 📦 实际操作示例 # 查看今天的日志 cat $(date +%Y-%m-%d).md # 向长期记忆写入关键结论(示例) cat >> MEMORY.md <<EOF - 结论:使用向量+BM25 的混合检索可以兼顾概念关联和精确匹配。 EOF # 用 ontology 记录项目关系 ontology create entity Project name="blog-demo" ontology create relationship link source=Project target=Document name="deepseek-v4.md" 🔐 记忆安全与隔离(简要回顾) 文件系统权限:700 目录、600 文件,仅当前 agent 可读写。 会话层隔离:MEMORY.md 只在 主私人会话 加载,避免在群聊泄露。 审计日志:每次写入都会记录在 memory/heartbeat-state.json,可追溯。 子代理 sandbox:默认只读工作区,写入必须显式声明。 可选加密:若有合规需求,可对 MEMORY.md 进行 AES‑256‑GCM 加密。 🎯 小结 OpenClaw 的记忆分层把 即时日志、长期精华、结构化实体、跨会话索引 和 外部 Wiki 五层有机结合,兼顾 可检索性、安全性 与 可维护性。 通过 混合向量+BM25 检索、块去重 与 Dreaming 机制,保证重要信息不被上下文压缩遗失。 正确使用 memory_search、memory_get、ontology 等工具,可以让企业 AI 助手在 千余次会话 后仍保持对关键业务的清晰记忆。 #openclaw #龙虾 #memory ...

2026-04-29 · 2 min · 253 words · FunkyGod