写投资、写 AI，也写那些值得长期复利的判断。

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

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

作为独立开发者，我为什么选择 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 的组件接口是统一的，实现是可替换的。 ...

受够了 OpenClaw 的失忆，我本周爱上了 Hermes Agent 大多数人以为 Hermes 只是一个 AI 聊天框架。但它实际上是一个可长期运行、多角色协作、多入口接入的 Agent Runtime，已经非常接近真正意义上的 AI Operating System。 Hermes Agent 在不到三个月内突破 14 万 GitHub Star，并根据 OpenRouter 的数据成为目前全球使用量最大的 Agent。在折腾了 2 个月，受够了 OpenClaw 的失忆后，我尝试用业界火热的 Hermes Agent，效果居然出奇的好，因此写下这篇安利文章。 关键词：#openclaw #Hermes 能力标签：多Agent协作 · 长期记忆隔离 · 子代理并行 · 多用户隔离 · 任务编排 · Agent Runtime 为什么这么火？三个根本原因 1. 解决了 Agent 领域最痛的问题——失忆 Hermes 要解决的正是这个问题，不是用 prompt 技巧，而是在架构层面内置了一个闭环学习机制——运行时间越长，它就越了解你。 2. 自我进化的技能系统 Hermes 有四个核心差异化能力，其中最突出的是"自进化技能"——它会自己编写并优化 skill 文档。每当 Hermes 解决一个困难问题，它就会写下一份可复用的 skill 文档，之后永远不会忘记这个解法。这些 skill 可搜索、可共享，并兼容 agentskills.io 开放标准。 ...

很多团队做 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： ...

在AIGC爆发之后，社会需要的不只是更强的生成模型，也需要更可靠的鉴伪系统。 过去两年，AI 生成内容从“新奇玩具”变成了基础能力，也开始从“效率工具”变成“风险放大器”。 它可以帮你生成海报、头像、视频、广告、PPT，也可以帮你生成谣言、诈骗、伪证、假合同、假客服、假高管发言，甚至直接攻击一个人的尊严和一个机构的信任。 这就是为什么我越来越相信一件事：AI 时代真正稀缺的，不只是生成能力，而是验证能力。 换句话说，未来的核心竞争力不只是“能不能做出内容”，而是“能不能证明内容是真的”。 一、两个事件，把“信任问题”讲得很清楚 最近我把两个新闻放在一起看，一个是意大利总理梅洛尼遭遇 AI 假照片事件，另一个是伯克希尔哈萨维公开提醒公众警惕冒充巴菲特的 AI 伪造视频。 这两个事件看起来分属不同领域，一个偏社会舆论，一个偏金融传播，但它们都指向同一个问题：AI 伪造正在攻击信任本身。 1. 梅洛尼假照片：伪造开始攻击个人尊严 梅洛尼事件提醒我们，AI 伪造不只是“看起来像不像”的娱乐问题，而是会实打实伤害一个人的人格、声誉和安全。 这类伪造有几个明显特征： 伪造门槛很低。 传播速度远高于澄清速度。 普通人比公众人物更难自证清白。 以前，合成一张假图需要技术、设备和时间。现在，只要有足够的公开照片、公开视频和生成工具，普通人就可能被伪造成不雅图、涉政图、诈骗头像或虚假证据。 更麻烦的是，伪造内容一旦进入社交平台，传播链条往往比事实链条快得多。等当事人澄清时，截图、转发和二次传播已经让伤害完成了。 2. 假巴菲特视频：伪造开始攻击金融信任 如果说梅洛尼事件攻击的是个人尊严，那么“假巴菲特”视频攻击的就是金融信任。 巴菲特不是普通名人，他的发言天然带有市场权威。一个“看起来像他、听起来像他、说话方式也像他”的 AI 视频，本质上是在借用权威身份做信任劫持。 这件事的危险不在于“有多像”，而在于“有多少人会信”。 在金融场景里，信任本身就是资产。伪造可能带来至少四类风险： 诱导投资者购买虚假产品。 制造市场情绪，让用户误判权威来源。 损害品牌和机构声誉，让辟谣成本激增。 让公众对真实信息也开始怀疑，形成“什么都可能是假的”的信任疲劳。 所以，AI 伪造不是单纯的内容问题，而是交易、传播和身份验证的底层问题。 二、为什么“信任基础设施”会变成新刚需 过去互联网最擅长解决的是“信息如何传播”。 现在 AI 时代最需要解决的是“信息如何被信任”。 这就是我理解的“信任基础设施”： 图片是否被篡改。 视频是否被合成。 文档是否被修改。 身份是否被冒充。 来源是否可追溯。 证据是否可审计。 如果没有这层基础设施，AI 只会把整个数字世界推向一种更低成本、更高频率、更难验证的混乱。 所以我越来越倾向于把鉴伪、溯源、身份验证、数字水印、可信认证、风控规则看作同一类能力：它们共同构成了 AI 时代的新底座。 三、C 端为什么需要鉴伪：每个人都需要“验真权” 对于普通用户来说，AI 最大的变化不是“模型更聪明了”，而是“你看到的东西未必可信了”。 我们过去默认“照片是证据”，现在这个默认前提正在失效。 C 端的典型场景 社交平台验图。 收到可疑图片时先检测，再决定是否转发。 被冒用头像、被合成不雅图、被伪造聊天记录时，能快速出具检测结果。 家庭反诈，尤其是老人、孩子面对“熟人照片 + 伪造语音 + 假视频”的组合欺骗。 内容创作者保护，避免被冒充、被造谣、被恶意拼接。 我把这种能力称为“验真权”，意思是普通人也应该拥有一个低成本、可理解、可分享的方式去判断： ...

使用 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 的价值主要是帮助我把排查流程变得更系统。 ...

数字生产实践Codex：AI 编程助手进化到桌面办公智能体 AI 编程工具正在从代码生成器，进化为能够操作环境、验证结果、持续协作的软件开发智能体。 在过去，很多人对 AI 编程工具的理解还停留在"帮我补全代码""生成一段函数""解释一段报错"。但 OpenAI 最新版 Codex 的能力已经不止于此。 根据 OpenAI 官方对新版 Codex 的介绍，Codex 正在从一个单纯的代码助手，升级为贯穿软件开发生命周期的智能协作伙伴。它不仅能写代码、理解代码库、处理 PR 评审，还开始具备两类更接近真实开发者工作方式的能力： Computer Use，也就是操作系统级控制能力； 内置浏览器，也就是在 Codex 应用中直接打开、观察和操作网页的能力。 这两项能力的出现，意味着 Codex 不再只是"回答怎么写代码"，而是开始进入真实开发环境，帮助开发者完成更完整的任务链路。 一、Codex 正在从代码助手变成开发智能体 传统 AI 编程工具的核心能力是生成代码。用户提出需求，AI 给出代码片段，开发者再自己复制、运行、调试和验证。 而新版 Codex 的方向更接近 开发智能体。 所谓开发智能体，不只是会生成代码，而是能够围绕一个开发目标，主动完成多个连续动作： 读取项目文件； 理解代码结构； 修改代码； 运行终端命令； 打开页面； 复现问题； 检查界面； 验证修复结果； 根据反馈继续调整。 也就是说，Codex 的价值正在从"生成代码"扩展为"完成开发任务"。 这背后最关键的变化，就是它开始具备 操作电脑 和 观察网页 的能力。 二、什么是 Computer Use？ Computer Use 可以理解为一种让 AI 像人一样使用电脑界面的技术。 它不是简单调用 API，也不是只在编辑器里生成文本，而是让模型通过屏幕画面理解当前环境，并通过鼠标、键盘等方式执行操作。 它的基本能力包括： 看屏幕：识别当前界面中的按钮、输入框、菜单、弹窗和错误提示； 理解任务：根据用户目标判断下一步应该做什么； 执行操作：点击、输入、滚动、切换窗口、打开应用； 观察反馈：根据界面变化判断任务是否完成； 持续迭代：如果没有完成，就继续调整下一步操作。 可以用一句话概括： ...

当写代码不再是瓶颈：AI 原生工程组织该如何运转？ AI团队实践的分水岭：谁更会提出问题，谁更会验证方向，谁更会设计系统，谁更能保持产品品味，谁更能在速度和责任之间找到平衡。 最近听到一期小宇宙播客《Anthropic 如何运营一个 AI 原生工程组织》，内容来自 Anthropic 内部分享的中文版复刻。主讲人 Fiona Fung 是 Claude Code 和 Cowork 的产品与工程负责人，她讨论的不是"AI 能不能帮程序员写代码"这种入门问题，而是一个更深层的问题：当 AI 真的把写代码这件事大幅加速之后，工程组织本身应该怎么变？ (小宇宙) 这其实是一个被很多团队低估的问题。 过去几十年，软件团队的组织方式、流程制度、管理方法，几乎都建立在一个默认前提上：工程师时间很贵，写代码是稀缺资源。 所以我们发明了需求评审、排期会、设计文档、技术方案评审、代码所有权、敏捷迭代、瀑布流程、代码审查、发布审批……这些机制的核心目的，都是为了避免把昂贵的工程时间浪费在错误方向上。 但如果 AI 让写代码变得便宜、快速，甚至可以同时生成多个可运行方案，那么原来的瓶颈就会转移。 真正稀缺的，可能不再是"谁来写代码"，而是： 谁能判断什么值得做；谁能定义好的产品体验；谁能做出架构取舍；谁能识别安全、法务和业务风险；谁能让团队持续保持高质量决策。 这意味着，AI 原生工程组织不是简单地"给每个工程师配一个 AI 工具"，而是要重新审视整个组织系统。 一、旧流程不是错了，而是它服务的假设变了 Fiona 提到一个非常关键的判断：随着 Claude 等 AI 工具把代码编写成本大幅拉低，过去围绕"工程带宽最贵"建立的一整套流程，都可能开始失效。播客简介里也直接点出，从敏捷到瀑布，从设计文档到代码所有权，都需要被重新审视。(小宇宙) 这句话值得每个技术团队反复咀嚼。 很多流程并不是天然低效。它们曾经是合理的，因为它们解决的是当时最重要的问题：如何避免昂贵的开发资源被浪费。 比如，在 AI 之前，一个复杂重构方案可能需要几名工程师投入数周才能验证。于是团队必须先写设计文档、开评审会、讨论边界条件、评估下游影响。因为一旦写错，返工成本很高。 但现在，如果 AI 可以在短时间内生成三种不同实现方案，甚至直接形成可运行 PR，那么"先写很长文档再决定是否动手"的价值就会下降。团队可以用更低成本直接看到代码、运行结果和影响范围。 这不是说设计文档会消失，而是说它的角色变了。 ...

Superpowers 14 个 Skills 全解读：AI 编程纪律框架的完整拆解 最核心的价值不是某个单独 skill，而是这条链路： 需求澄清 → 设计确认 → 计划拆解 → 隔离开发 → TDD → review → 验证 → 收尾 这条链路正好针对 AI coding 最常见的失败模式：过早实现、缺少测试、猜测修复、跳过验证、过早宣布成功。 注意：要经常更新 skills 的代码版本和自己结合实际使用，将自己的经验和要求增加到 skills，以便更好的编程和业务准确性，最好是将自身业务的要求单独作为 skills 引入到编程工具里。 Superpowers 是一个给 AI 编程 Agent 的完整软件开发方法论，由一组可组合 skills 和初始指令组成。它的基本工作流是：先澄清需求、写设计、写实施计划、TDD 实现、代码审查、验证、最后合并/PR/清理。 该不该装？三层判断 层面 判断 技术层面 不必须。没有它，AI coding agent 也能写代码。 工程质量层面 对复杂项目，强烈建议。它强制 TDD、审查、验证，能减少"AI 自信但没验证"的问题。 Superpowers 自身规则层面 一旦安装并启用，它的 using-superpowers 明确要求：只要有 1% 可能适用，就必须先调用相关 skill；README 也说这些是 mandatory workflows, not suggestions。 我的建议：重项目安装，轻任务选择性使用；团队协作/生产代码建议默认启用；纯探索、一次性原型可以不用或显式绕开。 1. using-superpowers — 入口规则 这个 skill 不是某个开发动作，而是**"调度所有 skills 的总开关"**。它要求 agent 在任何任务开始前先判断是否有相关 skill；只要有一点可能适用，就要先调用 skill，而不是凭经验直接干。它还规定了优先级：用户明确指令最高，Superpowers skills 其次，默认系统行为最低。 ...