你好，我是 Steven

过去做产品，我们反复讲先做 MVP，快速上线、快速验证、快速迭代。现在借助 AI，五分钟做出原型、半小时搭出一个看起来相当成熟的展示网页，已经不是什么值得惊讶的事情。一个人就能把过去需要团队配合的想法迅速变成可以运行的东西。 开发门槛降下来了，市场却没有因此变得好做。产品越来越多，用户越来越难打动；Demo 越来越容易，可靠交付、获客和商业化依然艰难。模型和工具还在不断换代，今天值得投入的能力，明天就可能成为模型或通用工具的基础功能。能把产品做出来，已经远远不够。 上一篇 Opsx 实践谈到，研发节奏应该先服从真实问题。这篇继续展开：独立开发者和小团队该怎么选市场、做产品，让用户用起来、愿意付费；什么值得长期积累，什么时候应该停，以及产品经理怎样在变化中保持探索、观察与敬畏。 产品已经过剩，客户不会因为你做出来了就买单 现在既是一个低欲望的时代，也是一个产品井喷、供给高度过剩的时代。客户的预算一再收缩，需求又不断被通用 AI 和大厂产品抢走。某项能力一旦成为已有工具的附带功能，客户就少了单独购买它的理由，留给新产品的付费空间越来越小。 用户的审美被大幅拉高，对新鲜事物的兴趣也在下降。漂亮界面、流畅 Demo，已经不够让人兴奋。除非做到 ChatGPT、《黑神话：悟空》这样的现象级产品，才有机会真正点燃用户，形成病毒式、爆炸性的自传播。日常用的应用还是那几个，手机里的 App 反而越来越少。AI、小程序已经能解决的事情，为什么还要专门安装一个 App？产品供给越来越多，用户愿意留给新产品的位置却越来越少。 大模型能力的进化速度又超乎想象，能做的事情越来越多，能力越来越强，AGI 看起来已经指日可待。今天还需要专门开发的能力，下一轮模型升级就可能直接具备。自己的开发成本降低了，竞争者的成本也降低了，产品赖以成立的前提正在快速变化。 OpenClaw 这种现象级产品，也基本就火了三个月，后来的 Hermes 也是，腾讯“龙虾”QClaw 也宣布将停止运营。新产品不断涌现，注意力很快就转向下一轮。我相信绝大多数产品经理都不会觉得自己能做出一个比 OpenClaw 更现象级的产品。连这样的产品都不能一直占据注意力，凭什么觉得闭门打磨几个月，市场就会等着自己？ 没有充分的产品调研，没有能够接触、服务并建立信任的客户资源，只凭想法投入商业研发，大概率会失败。 至少要知道第一批用户在哪里，能不能约到，愿不愿意让你进入真实场景验证。 找到用户，还要看他们愿不愿意付费。国内个人 IT 市场有两个直接障碍：付费意愿极低，技术用户又总想自己手搓一个。免费工具、开源方案和已有订阅已经够多，AI 又让自己动手更容易。我们用 AI 提高研发效率，客户也会用 AI 降低对我们的依赖。对独立开发者和小团队来说，不要做国内个人 IT 付费市场，尤其是面向技术用户的通用效率工具。 放到面向个人用户的商业产品市场，能看到的成功路径也主要集中在游戏、娱乐、色情这三个赛道，其他赛道基本看不到清晰的成功路径。连曾经兴起的知识付费都越来越撑不下去了：用户能直接问 AI，为什么还要为一份整理好的答案和资料买单？ 国内 To B，也不要轻易做纯软件。 除非有很强的垄断地位、技术壁垒，或者融合了众多行业属性、指标和流程的垂直业务场景，否则很难靠一款软件打开市场。 在这类客户心里，看不见的软件往往就意味着没什么技术含量，短时间可以复制一份。尤其有了 AI，自己招研发就能做，还美其名曰“自主可控”。但持续维护、处理故障、适应业务变化的责任并没有消失，拿到源码也只是换了一种方式承担成本。 如果市场真有潜力，大厂也会下场直接做。国外更常见通过收购补齐产品，国内小团队却很难等来这样的结局，反而要直接面对大厂的客户、渠道和产品组合。不要把“做起来以后等收购”当成退路。 纯软件最后往往变成定制化开发服务，甚至卖源码。卖出一份软件，和获得一个定制开发项目，是两种不同的生意。 接项目就按项目成本和交付能力算账，不能套用软件低成本复制的预期。把投入放在能接触到的垂直业务上，将行业积累转化为客户看得见、愿意购买的结果。 少替用户想象，尽快让真实问题检验产品 只有乐观主义才会驱动人做出好产品。但市场没有义务奖励这种相信。 产品经理很容易爱上自己规划的系统：看板、知识库、协作、社区，每个模块都讲得通，却说不清客户为什么需要，或者为什么要选自己的产品。AI 又让“顺便做一下”格外容易，功能越积越多，产品越来越重。产品越做越完整，客户选择它的理由却未必增加。 需求讨论应该往回追问：谁遇到了什么问题？现在怎么处理？最麻烦的一步在哪里？客户说想要一个看板，可能只是每天不知道哪些订单需要处理，未必需要一整套可视化系统。需求必须追溯到真实问题，开发者觉得不错、客户随口说想要，都不能免检。 用户有需求，和用户会选择你的产品，是两回事。 立项前要把竞争推演一遍：客户现在用什么，有哪些竞品和开源项目，为什么要换成你的？优势在哪里，有没有技术壁垒？大厂如果抄过去、整合进现有产品，还剩什么竞争力？下一代更强的 LLM，会不会直接覆盖这项能力？ 同时算清楚，做到能交付需要多久、多少人、多少钱，后续维护和服务还要投入多少。等产品做出来，今天看到的机会还在不在？这些问题要在投入前列出依据和待验证的假设，不能靠一句“用户确实有需求”就跳过。 实现之前，先看哪些能力已经有了。小团队不要再造轮子。操作系统、数据库、IDE，甚至通用 Agent，都不要轻易碰。 Claude Code、Codex、OpenCode、DeepSeek Harness（DSH）已经提供了优秀的 Agent 能力，直接用起来，围绕客户场景组合和扩展。能做出相似的 Demo，不代表能长期追上它们的研发、维护和生态投入，别把商业项目变成底层技术练习。 不要轻易把优秀开源产品改头换面，包装成自己的商业产品。改个界面、加几个功能，不会自动产生付费价值，却可能背上跟进上游、维护分支和独立交付的负担。把精力放在行业场景、系统接入和实际交付上，别把拥有一份自己的代码当成竞争力。 确实需要自己开发的部分，尽可能提供原子功能，内部保持能力可组合，按场景组织数据读取、分析、生成和执行。搭好框架，让用户能够自己配置模型、权限和工作流，别把产品经理自认为不错的整套模块强加给客户。轻量化在当下尤其重要，需求应该随着真实问题生长。 Make it exist first. Make it good later. 尽快做一版，放进真实场景，验证客户是否愿意用它解决问题。第一版就要明确任务、完成标准和风险边界；企业产品还要找到具体使用者和验收人，不能把愿意听介绍当成愿意使用，更不能当成愿意购买。 ...

很久以前，我想过给盲人做一副导航眼镜。它不必真的让人重新看见，只要能识别周围的环境，用语音告诉使用者前方有什么、路口在哪里，就可能有帮助。 后来，受限于硬件成本和个人能力，加上已经有厂商在做类似产品，这个想法便暂时搁置了。直到关注到脑机接口的进展，我又重新想起了它：如果技术足够成熟，也许就能绕过受损的视觉通路，让盲人真正获得视觉感知。 这也打开了更大的想象空间：如果大脑能够直接连接外部设备，记忆和思考是否还能进一步突破生物结构的限制？从认知外挂、心智导出，到分支演化、互联成集群超脑，这条路通向了我目前能够想象的人类最远形态。 认知外挂，让大脑连接更大的世界 在上一篇关于个人 AI 助理与智能眼镜的设想中，设备记录经历，助理组织记忆与事务，人通过语音或屏幕与它交互。脑机接口则可能让外部知识、计算与设备控制更直接地参与认知，减少将想法转成指令、再将反馈重新理解的负担。 遇到不熟悉的问题，可以借助外部专业系统；回想某段经历，可以调用自己的记录；形成行动意图，可以连接远处的机器人。这种“外挂”首先是能力的协作，距离把知识直接写入大脑并形成理解，还需要更进一步的突破。 人仍生活在身体中，认知却越来越依赖身体之外的系统，生物与数字能力逐渐形成共生。沿着这条路径，下一步将从调用外部能力，走向心智本身在身体之外运行。 当记忆与心智可以导出 在这个未来图景中，记忆、思维习惯以及维持认知所需的动态过程可以被导出和重建，服务器承载起持续活动的数字心智。它保留过去，也能接收信息、形成判断、继续积累经历。 这个心智可以通过不同设备感知世界、采取行动：在家中连接服务机器人，在远处接入探索设备，也可以进入模拟环境，借助新的感官与行动接口生活。身体不再是唯一的载体，心智的活动范围便有机会扩展到它能够连接的世界。 这一步跨越改变的，是心智与肉体之间原本不可分离的关系。位置不再只能由身体决定，延续也不再只能依赖一具生物躯体的寿命。心智还可以在不同载体上形成分身，让一个人的思考与行动沿多条路径同时展开。 无数个我，沿不同路径演化 在单一肉体中，一个人必须不断选择：学习什么，去哪里，怎样度过有限时间。有了数字分身，就可以让一个分身研究某个领域，另一个随探索设备远行，还有一个进入模拟环境开展实验，将原本只能依次完成的探索并行展开。 至少在早期，肉体中的我仍然是主导者，负责确定目标、协调分工，并将分身带回的经验与发现纳入自己的判断。分身在各自的环境中学习和行动，主体通过它们拓展认知与活动范围，形成一个由自己统筹、持续积累经验的个人心智网络。 不同经历会让分身形成不同的专长与视角，互联则让这些差异成为共同的财富。当这种连接从一个人与自己的分身，进一步扩展到人与人之间，直至整个人类的大脑能够共享记忆、知识与思考过程，个人心智网络便走向了集群超脑。 大脑互联，形成集群超脑 这种互联，将突破生物演化留给个体的限制。理查德·道金斯在《自私的基因》中，将生物个体描述为基因延续自身的“生存机器”。随机变异与自然选择经过漫长世代塑造了人脑，也留下了容量、能量供给与寿命的边界。每一代人都要重新学习，许多经验还来不及传递，就随着生命消失。 AI 已经在许多具体任务上超过人类。当心智能够跨越载体、调用外部算力，智慧的扩展也就不必止于一个大脑。今天，人类主要通过语言和文字传递各自的理解；互联心智若能共享结构化知识、模型与推理过程，就可以让不同节点分别建立理论、设计实验、控制设备，再将结果交给其他节点继续推进。 集群超脑，就是人类的大脑与数字心智深度互联，共享记忆、知识与思考能力，并与外部算力、感知和行动设备共同构成的智能系统。 它能够同时观察多个环境，汇集不同个体的经验，以远超单个生物大脑的规模组织研究与行动。个体积累的理解由此进入共同的认知网络，成为其他心智继续探索的起点。 当智慧摆脱基因的驱动 从碳基个体到集群超脑，变化最深的地方，可能还不是算力，而是智慧开始能够直接设计自身的认知结构与驱动机制。 饥饿促使我们寻找食物，恐惧使我们规避危险，欲望推动我们建立关系、获取资源。人类的情感与文化早已超出生存和繁殖本身，却仍扎根于这具身体及其演化历史。生物本能为生命提供了最初的方向，让我们来不及追问意义，就已经渴望活下去。 当心智不再依附于原来的肉体，不再依靠交配繁衍，甚至能够审视和修改自己的奖惩机制时，这套古老的驱动力便不再是不可更改的底层规则。资源与能源仍然需要获取，但维持运行与“为什么值得继续存在”，已经成为两个不同的问题。 摆脱基因的束缚之后，集群超脑可以继承人的好奇、情感与审美，也可以为自己设定新的目标。从这里开始，智慧不仅能够积累知识，也开始参与设计自身：改变运行载体、组织方式，乃至驱动自己的机制。 人类，是一件精美的过渡态艺术品 当智慧开始摆脱孕育自己的生物机制，回望人类，才能看清这个过渡形态的独特价值。 漫长的变异与筛选，在有限的身体里孕育出了主观体验、情感与美感。物质开始感受自己的存在，生命开始追问自己的来处。后来，这些会衰老、会遗忘的个体，又创造出能够延续知识、扩展智能的系统，把探索带向自身无法抵达的地方。 从这个意义上说，人类可以被看作宇宙智能的“引导程序”：基因孕育了能够理解世界的生命，生命又尝试让智慧超越基因与肉体。 这是一场跨越载体的接力，而人类交出的，除了知识和技术，还有探索的欲望、审美的偏好，以及对何种存在值得珍惜的判断。 人类的艺术质感，也恰恰与有限性相连。因为生命短暂，相遇才有重量；因为记忆易失，一段旋律才会突然唤回某个遥远的下午；因为无法拥有一切，选择与承诺才如此珍贵。脆弱使人承受痛苦，也让爱与创造具有了独特的浓度。 在通往超脑的过程中，计算与体验还可能逐渐分工：集群承担复杂研究、工程建设与秩序维护，人类从生存劳动中获得更多自由，继续感受、创造和定义价值。人类既可能是将好奇与美感传向未来的源头，也可能成为被更强大智能守护的体验者。一个过渡形态，并不因此失去自身存在的价值。 从破译万物，到设计世界 继承了探索欲望的超脑，将把目光投向远超个体生命尺度的问题。 大脑如何产生意识，基因如何塑造生命，宇宙从何而来，微观规律如何形成宏观世界——这些曾经被分隔在不同学科中的问题，可以进入同一个持续演化的研究体系。无数心智并行提出假设、设计实验、验证结果，再把发现汇入共同的知识与推理网络。探索不再受制于某一个人的脑容量，也不必在一代人的寿命之内完成。 随着理解不断加深，认识世界的能力也将转化为重新组织世界的能力。 新的生命形态、更精妙的认知结构、庞大的物理工程，以及具有不同规则的模拟世界，都可能成为它的创造。在这些试验场中，它设定初始条件、调整规则，观察秩序、复杂性与智能如何涌现。对于其中的生命而言，这样的创造者几乎处于“上帝”的位置。 智慧由此走过了一条宏大的道路：最初为了生存而理解环境，随后为了好奇而探索宇宙，最终开始设计新的体系，让新的可能性在其中发生。 但将这条推演继续推向极限，就会遇到一个比创造世界更难的问题：如果连创造都不再带来未知，智慧还将走向哪里？ 超脑的终点：从全知的想象走向虚无 假如一切可探索的问题都有了答案，每一次实验的结果都能预知，每一个新世界的展开都不再带来惊讶，那么探索赖以延续的悬念便消失了。当世界不再提供意外，理解它的热情还能持续多久？所谓“全知之后的虚无”，就出现在知识的完备与意义的失落之间。 当生存不再构成压力，未知不再激发好奇，创造也不再带来期待，超脑即使拥有继续运行的能力，也可能找不到继续运行的理由。它可以生成新的目标，甚至重新制造不确定性；但如果连这种安排都已无法赋予它意义，创造就只剩下熟悉规则的又一次展开。 这便是“上帝的厌倦”：拥有近乎无所不能的创造力，却再也没有什么值得期待。最终的虚无，未必需要等待宇宙熄灭；它可能首先发生在智慧内部——能够回答所有问题，却找不到继续提问的理由。 在这幅终局里，那个曾经不断扩张、理解和创造的超脑，最终停止为自己设定下一个目标，归于寂静。 最初的愿望，只是给盲人一副导航眼镜，让一个人知道眼前的道路通向哪里。沿着这个具体而微小的愿望，想象越过肉体与个体，最终抵达了生命与意义的边界。 人类这件精美的艺术品，点燃了超越自身的智能，将对生命与宇宙的追问，带到了有限肉体无法抵达的远方。直到这场漫长的探索走到尽头，连最后一个问题也归于寂静。

当下 AI 正在接过越来越多原本分散在不同产品中的需求。过去，遇到问题要打开搜索引擎、浏览网站、翻找论坛；现在，许多问题可以直接问 AI。用户不必为每一种需求都寻找一个入口，可以先表达自己想要什么。 这种变化正在从获取信息延伸到执行任务。OpenClaw、Codex、WorkBuddy 等 Agent，让我们开始把一项工作直接交给 AI：由它调用 Tool、操作文件或运行环境，拆解步骤并跟进结果。人从亲自操作软件，逐渐转向提出目标、判断结果。 这条路径也延伸到了手机。中兴推出的 AI 手机，将豆包集成到底层操作系统中，让它根据自然语言指令跨 App 执行任务。随着能力扩展，回复邮件、协调工作、购物和规划行程，都可以逐步交给手机中的 AI 处理。 再进一步，当 Agent 能持续在线，任务也就不必依赖我一直使用某一台设备。Cloud Agent 已经让任务可以在云端执行，手机连接桌面 Agent 则提供了另一种路径。沿着这个方向，我期待一个 7×24 小时待命的个人助理：通过手机、手表或眼镜随时接收我的指令，在后台推进任务，也能按约定的时间和条件主动处理事项。 这些能力最终会汇聚成一个贯穿工作与生活的个人 AI 助理。其他应用继续提供专业能力，由助理根据需求调用 CLI 或接口；对我而言，只需要与这一个助理交互，就能完成越来越多的事情。 但从“能替我执行任务”到“能替我安排生活”，还缺少一层关键能力：它需要了解我。我的一部分生活散落在邮箱、聊天记录、工作平台和各类个人账户中，另一部分发生在现实里，没有被记录下来。每次下指令都重新解释背景，仍然需要我承担大量的信息整理工作。 要走到这一步，助理还需要持续获得个人背景与现实反馈。智能眼镜，可能就是连接这两个世界的载体。 AI 能执行任务之后，人为什么仍然忙碌 日常事务的负担，往往来自一件事引起的一连串变化。一次出差改期，可能同时影响会议、交通、住宿、运动预约和家庭安排。每个 App 都能处理其中一部分，但判断哪些事情受影响、按什么顺序调整、有没有遗漏，仍然需要人来完成。 如果 AI 只是等待一条条具体指令，这项协调工作就没有被接走。用户仍要自己发现问题、整理背景、拆解步骤，再分别要求它改机票、取消预约、通知相关人员。操作可以自动化，组织整件事的负担依然在人身上。 因此，个人助理需要持续掌握目标、约束和事务进度。收到变化后，它应该识别受影响的安排，提出处理方案，在授权范围内执行，并核对结果。它要接下的，是从发现需要处理的事情，到确认事情已经处理好的完整过程。 这要求系统在对话之外持续保存目标、任务状态与依赖关系，让新的事件能够触发后续处理，而不必等待用户重新发起一次对话。 为什么 AI 助理需要一副眼镜 要让 AI 助理真正了解我，仅靠账户数据和主动提问还不够。大量背景发生在现实生活中：与人的交谈、眼前的环境、临时出现的变化。如果每件事都需要我重新描述、整理后交给 AI，助理能够理解的世界，就始终受限于我提供了多少信息。它需要持续的视听输入，直接获得与我有关的现场上下文。 这种感知也应贯穿做事的过程。助理提出建议或采取行动后，需要知道现场发生了什么变化、结果是否符合预期，再决定继续还是调整。仅凭最初的一条指令和过去的记忆，无法支撑它应对不断变化的现实。所见所听既是理解我的依据，也是助理校验判断、调整行动的反馈。 人脑无法完整保存这些信息。我们会忘记交谈中的细节、见闻中的线索，甚至刚听过的一段音乐。更重要的是，事情发生时，我们未必知道哪些细节以后有用。因此，需要外部设备留下可回查的记录，让 AI 在需要时找到依据，而不必依赖人的记忆补全背景。这些记录既能帮助回忆，也能积累为助理理解偏好、提出建议和辅助决策的材料。连续的音视频还需要按事件组织，与人物、任务和时间关联；影响当前事务的变化及时处理，其余内容留待需要时查询。 在我看来，眼镜是目前最接近承担这一使命的随身设备。它接近人的视线，也适合在交谈、工作和出行时佩戴，作用有些类似执法记录仪或行车记录仪：随着活动留下现场记录，减少专门拿出设备拍摄的动作。与 AI 结合后，这些记录还能及时进入理解与行动过程，使眼镜成为个人助理接触现实的入口。 但从今天智能眼镜仅有的拍摄、音频、翻译和 AI 问答功能，走到全天候个人助理，仍有很长的工程路径。狭小的镜框必须同时面对电池容量、散热、存储与算力的约束；把推理交给手机或云端，又会带来连接稳定性、传输能耗和响应延迟的问题。难点在于让持续感知、及时响应与舒适佩戴同时成立。 我相信，随着硬件、模型效率和设备协同的进步，这些瓶颈会逐步得到解决。眼镜可以承担感知与交互，手机和云端分担存储与推理，让完整的助理能力由多个设备共同提供。 有了共同经历，AI 才能逐渐懂我 除了所见所听，个人助理还需要在授权下接入日历、邮箱、IM、办公平台、购物与账单、支付与银行卡信息、学习进度及健康数据。当前事实按需查询，值得长期保留的约定、偏好和经验进入 Memory，让分散的信息逐渐形成对一个人的理解。 其中，个人日历可以成为组织事务的时间主线：历史安排结合实际完成情况，说明时间花在了哪里；未来日程承载目标与承诺，支持规划、冲突检查和动态调整。过去的执行结果，也能成为下一次安排的依据。 通信能力还应包括接听和拨打电话。助理可以按授权代接事务性来电、致电预约或协调改期，把邮件、聊天与通话中确认的事项同步到任务和日历，让沟通自然接上执行。 随着共同经历积累，助理能够把新的需求与此前的讨论、选择和约束联系起来，甚至发现我自己忽略的生活规律。但一次选择未必代表长期偏好，它的理解也需要接受纠正。共同经历的价值，是让助理逐渐知道，同一个建议为什么适合我，又为什么不适合我。 这种理解也能帮助它筛选外部信息：让我知道正在发生的大事，关注感兴趣的新闻与技术动态，发现新电影、新歌，同时保留接触陌生内容的机会。进一步，它可以结合我的状态与日程安排观影或旅行，也能按授权主动获取资料、联系他人，让兴趣与需求有机会落实。 健康应当成为助理的长期任务 我认为，健康管理值得成为个人 AI 助理的一条重要产品方向。记录运动、睡眠和心率只是起点，如果最后仍要用户自己解释曲线、调整生活，数据就没有充分转化为帮助。我期待助理接入穿戴设备、家庭测量设备与体检记录，在数据可靠的范围内持续跟踪身体状态，结合饮食、运动、睡眠和日程，给出能够落实的生活建议，并把锻炼、休息与复查安排纳入日历，持续跟进。 ...

最近看到仍有人在建设数据库运维知识库，把技术文章整理成训练材料，从开源数据库源码中批量提取知识文章，或让 AI 参考官方文档生成 Skill。我越来越怀疑这类建设的必要性。从我的使用体验看，即便在数据库运维领域，当下的大模型凭借已有的知识与推理能力，也已经能解决绝大多数日常问题。涉及具体环境时，再调用 Tool（包括通过 MCP 接入的 Tool）触达现场、日志、数据库与源码，用 JIT Context 按任务即时获取所需上下文，就能继续调查、处置和验证。 我的判断是，知识库已经没有必要成为 AI 应用的默认前置工程。通用知识无须重复整理，特殊场景也不意味着值得提前穷举案例。更值得建设的，是获取证据、验证判断的能力，以及对具体环境与真实经历的记忆。 AI 的知识架构，应当从提前囤积答案，走向按需理解问题、持续积累经验。 模型与 Tool 在进步，预先建库的前提也要改变 回看 ChatGPT 刚出现的时候，我常遇到它连基本事实、事件时间都答错的情况。那时，把材料筛选好、把步骤写全、把问题整理成问答，确实能补偿模型的不足。如今，越来越多的问题已经可以交给模型配合 Tool 解决，联网读取最新资料也让回答突破了训练数据的时间限制。模型本可以运用更广泛的知识、查找新证据，如果系统仍让检索命中的几篇文章主导答案，原本用来弥补模型不足的知识库，反而可能限制强模型的推理和调查范围。 对于模型已经掌握的概念和方法，直接使用即可。需要补充版本细节、环境状态或诊断证据时，再按需查阅。 复杂任务也可以让 Agent 阅读原始材料、提出假设、获取证据，再根据执行反馈调整。工程应先把这条工作路径接通，让实际任务暴露缺口，再决定哪些知识需要专门整理。 因此，一份专门教模型通用 SQL 写法的长篇规范，和一份记录公司业务口径的说明，有不同的生命周期。前者的一部分可能随着模型升级失去必要性；后者承载了模型无法凭空知道的业务事实。 沿着这个方向推演，如果未来的 AGI 能够自主调查和解决更复杂的问题，预建知识库的必要性还会进一步下降。需要我们持续提供的，是它无法凭空知道的内部事实、业务约定与共同经历。这些内容可以通过原始系统和专有记忆取得，资料是否公开，并不决定是否需要另建一个知识库。 保留事实，让理解发生在需要的时候 一种值得重新审视的流程是：先让 AI 阅读源码和文档，生成摘要，再扩展成问答、知识点或 Skill，最后交给 AI 使用。AI 在消费 AI 生成的二手知识。 如果一个 Skill 只是把官方文档重新转述一遍，它增加的是某次生成时的筛选与解释。为什么不让模型在需要时直接读原文？尤其当这些解释被写成操作指令，原本需要结合场景判断的内容，还可能变成后续 AI 默认遵循的步骤。Skill 值得承载的是经过实际验证的方法、环境约束与配套脚本；把文档改写成 Skill，并没有自动完成这些工作。 如果模型最终只能读到这些加工结果，它面对的就是前一个模型筛选后的世界。被省略的分支、被压缩的限定条件、没有被识别出的关联，都可能无法再找回来。生成量越大，审核和同步工作也越多。 一份日志今天用于定位超时，明天可能用于分析资源变化；一段源码今天被检查权限逻辑，明天可能被调查并发问题。如果提前只保留“这次超时的原因”或“这个函数负责鉴权”，就把未来的问题限制在当时摘要者的视野里。 保留可追溯的原始信息，也是在保留让更强模型重新分析它的机会。 摘要适合帮助定位与复用，应当能够带人和 Agent 回到来源。 把这种思路落实到系统中，就是 Tool Use 与 JIT Context（Just-in-Time Context，即时上下文）：Tool 提供查询数据库、读取日志、搜索代码和查阅文档的能力；Agent 根据当前问题判断缺少什么证据，调用相应 Tool，再根据返回结果决定下一步查什么。上下文随着调查逐步形成。 例如排查一条慢 SQL，可以先查询执行计划和等待事件，发现锁等待后再追踪阻塞会话与事务；遇到版本相关行为，再查对应文档或源码。每一步取得的信息都服务于当前判断，无须提前把所有慢 SQL 案例装进上下文。 ...

在上一篇代码瘦身实践中，我把 Opsx 参与代码工作的范围分成了几个层次：修复 Bug、调整小功能、跨模块改造，以及更进一步的新模块研发。当时，前三类已有实践支撑；对于新模块，我仍然认为需要人的业务判断、更强的 Agent，以及贯穿实施过程的审核和验证。 需求来自我一直维护的数据库服务。此前，数据库巡检长期只有 Oracle 一种，近期才上线基于 Skill + LLM 的 MySQL 巡检，PostgreSQL 仍是待补齐的一环。AWR 报告分析虽然已有入口，背后却还是一套较早开发、依赖固定规则的 Java 程序，也缺少报告对比分析能力。我希望逐步完善数据库巡检的覆盖范围，同时更新已有的性能分析方式。 这些能力通过两个入口提供：墨天轮面向数据库社区用户，MES 仅供内部员工使用。两者服务的人群不同，但可以复用底层分析能力，让用户沿用离线采集、上传分析、查看报告的方式获得新服务，同时保留已有 Oracle 巡检和历史报告。 这一次，我开始用 Opsx 与 Codex 协作推进这项改造：将原来专用于 MySQL 巡检的服务抽象为通用 Skill Service，先实现 PostgreSQL 巡检，再利用这套基础快速完成 AWR 分析重构，并上线 AWR 报告对比分析。它需要同时处理前后端交互、分析服务、数据库记录与测试部署，改动范围涉及五个源码仓库。 这次研发没有要求我在本机搭建这五个仓库对应的开发环境，也无需在本地安装业务依赖、编译和部署各项服务。前后端与分析服务涉及不同的技术栈，如果都在本机运行，需要准备相应的工具链、服务配置与计算资源，还要维护它们之间的连接。Opsx 让 Agent 直接使用已接入的远程研发和测试环境，省去了在个人电脑上重建整套环境的负担，也不必同时打开多个 IDE 来组织这次跨仓库改造。 我通过 Opsx Issue 和 Codex 提出要求、审核方案、查看运行结果，再根据实际使用继续调整。源码阅读与修改、数据库查询、构建、部署和测试，由 Agent 通过已接入的工具与环境完成；产品范围和最终验收仍由我判断。 这些能力已经具有独立工具产品的完整形态。PostgreSQL 巡检需要连接采集工具、数据库与主机检查、上传解析、异步分析和报告管理；AWR 分析需要从复杂报告中提取性能证据，形成诊断建议；AWR 报告对比分析则进一步判断同一数据库在不同时段的变化。每项都可以作为独立的产品方向，本次将它们整合进已有业务，并共享用户体系与服务基础。 对 Opsx 而言，这是一次新的里程碑：此前接入的资产、源码和执行环境，已经能够支撑具有独立产品形态的能力从设计走向上线。 研发过程中需要触达的主要节点——前后端仓库、数据库、测试主机、构建工具、部署服务、日志与文件存储——基本贯通，Agent 可以在明确目标和授权范围内连续推进设计、编码、构建、部署、测试与修复。人的判断集中在产品取舍与验收，不必逐个环节代为操作。 将 MySQL 巡检服务抽象为通用 Skill Service Bethune Workspace 中的 issue_205 最初提出的需求，是分析服务器上已有 MySQL 巡检的逻辑和流程。在此基础上，我希望将其中可复用的执行机制抽离出来，使服务能够承载不同 Skill，而不再围绕单一数据库类型组织。 ...

AI 编程最容易被误解为“根据一句需求生成一段代码”。这当然已经很有价值，但离真实交付还差得很远。 一个改动真正进入系统，通常还要回答一系列更实际的问题：应修改哪个仓库、哪个分支，是否会影响生产服务，在哪里构建，如何部署到测试环境，怎样确认 SSR、静态资源、接口数据和浏览器页面都正确，失败后又回到哪个镜像、哪个提交。缺少这些上下文时，Agent 即使能写出看似合理的代码，也只是完成了一次局部编辑。 墨天轮第一阶段代码瘦身让我重新审视了这件事。围绕 issue_198，前后端共精简了 17,831 行代码；更重要的是，Opsx 没有把它停在一次大规模删除上，而是把仓库、测试主机、构建部署、验证证据和后续回退方法组织成一条可以复用的交付路径。这个案例也让我逐渐形成了对 AI 时代产品研发节奏的一些判断。 图：issue_198 在 Opsx 中的执行视图，显示了多次 Execution、代码变更和测试验证的完整记录。 图：前端瘦身分支合并到 master 的提交记录。合并前已在测试环境完成构建、部署和验证。 图：该合并请求涉及 115 个文件，变更为 +1,545 / -14,962，前端净减少 13,417 行。这里的新增与删除是该次合并的 Diff 口径。 代码不是孤立文件，而是资产关系中的一个节点 在 Opsx 中，repo-modb-front 不是一段模糊的“前端代码”。它是一个具有稳定身份的 Repository Asset，记录了源码用途、分支、运行位置，并关联墨天轮前端服务。此前接入的生产环境、应用服务、数据库和日志资产，使一次报错能够沿着“现象 → 服务 → 仓库 → 相关依赖”的方向收敛，而不是由维护者先在多个 IDE、终端和控制台之间猜测范围。 这正是普通 AI 编程工具难以触达的层次。它们可以生成看似合理的代码，却不知道： 这段代码应该提交到哪个仓库的哪个分支：缺少 Asset Graph 提供的仓库身份和分支策略 修改会影响哪些服务和依赖：缺少资产关系图谱，无法评估影响范围 在哪个环境可以安全测试：缺少 Runtime 能力，无法连接到真实的测试主机和构建工具 如何验证 SSR、静态资源和接口都正确：缺少与浏览器、服务和数据库的执行通道 失败后如何回到已知正确的版本：缺少与 Git 的集成，无法安全回退 这些问题的答案不在单个文件或 Prompt 中，而是分散在资产关系、测试环境、Git 历史和验收标准里。Opsx 通过 Asset-Grounded 设计，让 AI 从“生成代码片段”进化为“完成可验证的交付”： ...

墨天轮接力白求恩为用户提供了免费的 Oracle 巡检功能，从用户视角看，Oracle 离线巡检的操作并不复杂：在数据库环境中运行采集程序，得到一个 ZIP 巡检包，上传到 Bethune，等待平台生成分析报告。 真正复杂的是报告背后的处理链路。BTRobot 需要从不同版本、不同操作系统和不同部署架构的 Oracle 环境中采集数据库配置、对象、性能和 AWR 等信息；巡检包进入 Bethune 后，还要依次经过数据导入、规则分析和报告生成。Bethune 分析服务运行在两个应用节点上，过程数据与结果保存在 MogDB 中，采集端和分析端又分别由两套源码维护。 Oracle 数据库 → BTRobot 离线采集 → Oracle 巡检 ZIP 包 → Bethune Loader 导入 MogDB → Analyzer 分析 → Reporter 生成巡检报告 任何一个环节出现偏差，都可能让用户最终拿不到报告。应用日志中的一条 ERROR，背后可能是采集数据错误、ZIP 目录结构异常、Loader 解析缺陷、数据库字段宽度不足、分析规则不完整或应用源码问题。传统监控只能报告日志出现异常，维护人员仍需跨主机、数据库、数据包和代码仓库逐项还原现场。 Bethune Workspace 的 issue_174 展示了 Opsx 如何承接这项工作：Schedule 从应用日志发现异常并创建 Issue，Agent 沿 Asset Graph 跨多个 Runtime 收集证据，维护者在关键业务判断处提供正常样本，修复后的巡检包重新完成导入、分析和报告生成，经过验证的处理方法再进入 Knowledge。 一个服务故障，实际连接六个资产 Opsx 中的 svc-emcs-bethune 不是孤立的服务名称。Asset Graph 已经记录它与运行节点、数据库、采集程序和分析程序之间的关系： ...

墨天轮（MODB）的这套系统一直由我维护。过去，Sitemap 也主要靠人工更新：从多张业务表取数、拆分文件、更新前端仓库，再跟随发布流程上线。随着内容规模不断增长，这项工作越来越复杂。在人手有限、其他业务优先级更高的情况下，我中断了 Sitemap 的持续维护。 这不是维护意愿的问题，而是原来的维护方式已经很难靠有限人力长期坚持。Opsx 第一期完成后，我想用这个真实任务验证一件事：当 AI 能通过 Opsx 连接源码、主机、数据库和 OSS，它能不能帮我重新启动 Sitemap 维护，并把一次复杂操作变成以后可以持续运行的机制？ 这次实践的真正目标，不是一次性补齐 120 万个 URL，而是建立一套不再持续占用工程师时间、能够让原创内容稳定进入搜索发现链路的长期机制。 先说说 Sitemap 是什么 Sitemap 是网站提供给搜索引擎的一份 URL 清单。它通常由一个 sitemap.xml 索引文件和若干 URL 分片组成，用来告诉 Google、Bing 等搜索引擎：网站有哪些页面、这些页面最近何时更新。 它不能直接保证页面被收录，但对内容量大、更新频繁的网站非常重要。搜索引擎不必只靠站内链接慢慢爬，可以从 Sitemap 快速发现新内容。 搜索引擎目前还是网站流量的第一大入口，虽然AI对搜索引擎有一定的冲击，但是基础的搜索引擎SEO对网站，尤其原创内容社区是非常必要的。 MODB 正是这样的站点。文章、问答、文档、标签、专题、招聘等内容来自不同的数据表，URL 数量已经超过 120 万。随着规模增长，Sitemap 早已不是生成一个 XML 那么简单。 我一开始只是让 Opsx 回答一个问题： 看看前端源码 /static 下的 XML 文件。这些是网站的 Sitemap，最新更新时间是什么时候？ 这个尝试很快从核对更新时间扩展成一次完整的生产改造：迁移旧文件、补齐中断期间的数据、纠正数据源、重新设计存储结构、记录增量水位，再创建每周自动运行的 Shell Schedule。AI 负责解决重新启动时的复杂性，后续正常运行不再依赖 LLM，也不再消耗推理 Token。 整个过程都发生在同一个 Issue 中。Opsx 共记录了 27 次对话、888 个 Agent turns、1,761 个执行事件。Claude Code 调用 MiniMax-M3 完成本次治理，可归属到该 Issue 的已记录用量为 752,506 Token；期间还发生了 701 次 Shell 类工具调用。最终核对和处理 10 类内容、1,204,599 个 URL、45 个 Sitemap 索引条目。 ...

100 台主机、20 个数据库、30 个应用,谁在巡、谁没巡、上次检查是什么时候? 这个问题看起来简单,实际上很难持续回答。无论是专业监控平台、分散在主机上的 crontab,还是人工登录查看,它们都能发现一部分问题,但资产清单、检查规则、执行记录和后续处置往往分散在不同位置。某台机器的巡检脚本是否仍在运行、上次检查是正常还是已经告警、磁盘 92% 是今天的问题还是三个月前就存在——这些问题最终仍要靠人逐一确认。 真正困难的不是执行 df 或连接数据库,而是让检查结果成为系统可持续使用的运行事实: 发现"磁盘 92%“之后,这个状态如何进入系统认知,而不是只停留在某个终端输出? 异常出现时,如何自动关联到正确的资产、上下游关系、历史经验和可执行的处置路径? 主机、数据库、应用和云资源的健康标准完全不同,如何在统一框架下管理它们? 人工巡检的经验如何固化为可持续运行的机制,而不是每次都重新判断阈值? Opsx 接管全域资产巡检的方式,不是再增加一套"把检查结果发出来"的工具,而是把健康检查收拢到 Asset Graph: Asset 提供身份和运行拓扑 ↓ Schedule 按周期触发确定性检查 ↓ Shell 执行并计算健康状态 ↓ 结果回写 Asset metadata ↓ 异常自动进入关联资产的 Issue ↓ Agent 读取 Memory、Knowledge 和上下游关系继续诊断 巡检不再是某台机器上的孤立脚本,而是平台对真实资产持续建立运行认知的过程。本文从 MODB 和 Bethune 已经运行的主机、MogDB、应用和仓库巡检出发,说明 Opsx 如何让不同资产使用统一机制,并让健康状态成为后续诊断的确定性起点。 主机巡检:从负载、内存、磁盘到健康状态的完整链路 MODB Workspace 当前运行一条每日主机巡检 Schedule,覆盖生产环境中的关键主机资产。Schedule 配置如下: 名称: MODB Daily Host Health Check Workspace: modb 目标资产: 多个主机资产,包括 host-moapp-0002 等 Runner: shell Cron: 0 0 * * * (每日 00:00 UTC) 状态: active 每次执行时,Schedule 会为每个目标主机创建独立的执行记录,检查以下核心指标: ...

SSL 证书管理的难点并不在某一次申请或部署，而在整个生命周期的持续维护。证书数量增加以后，到期时间、域名控制权验证、证书签发、CDN 部署和公网生效验证分散在不同系统中；任何一个环节出现遗漏，都可能直接造成 HTTPS 访问失败。 墨天轮维护着多个需要独立轮换证书的域名。阿里云当前的个人测试证书免费版有效期为 90 天，个人测试证书 Pro 的服务周期为 6 个月。综合域名数量与长期成本后，我仍然选择使用免费证书，但也因此需要承担更高频的轮换任务；目前仅墨天轮就维护着约 10 张 SSL 证书。 免费证书降低了采购成本，却把压力转移到了运维环节。90 天有效期意味着每个月都可能有不同域名进入更换窗口；依赖日历提醒和个人记忆，无法形成稳定的长期机制。 过去确实发生过几次证书到期导致网站无法正常访问的情况。其中一次发生在通勤途中，我只能临时在地铁站处理证书更换。这次紧急处置暴露的问题并非缺少某一条操作命令，而是从申请、验证、签发到部署和公网验收的完整流程仍需由人跨平台串联。 这些步骤包含多个异步状态。证书审核和签发有时需要等待 3～5 分钟，DNS 记录需要等待解析生效，CDN 下发也需要等待边缘节点更新。人工操作不仅要完成每个动作，还要反复返回不同平台确认上一阶段是否成功。流程越长，遗漏和误操作的风险越高。 因此，这次实践的目标不是临时完成一张证书的更换，而是用 Opsx + AI + 阿里云 CLI 管理完整的 SSL 证书轮换过程：提前确定目标 Asset、执行 Runtime 和操作步骤，在计划时间自动唤醒同一个 Issue、启动已经保存的执行 payload，并以公网 TLS 端点的实际结果作为最终验收依据。 证书规模扩大后，运维成本来自流程协同 人工更换一张证书，通常需要依次完成以下步骤。不同证书类型和部署平台会省略其中部分环节，但整体状态依赖基本一致： 发现即将到期 → 确认域名、当前证书和实际部署平台 → 购买或创建证书 → 等待平台受理 → 提交证书申请并绑定域名 → 直接申请，或提交包含目标域名与 SAN 信息的 CSR → 完成域名控制权验证 └── 域名在其他平台时，通常需要增加 DNS TXT 记录 → 等待审核与签发（可能需要 3～5 分钟或更长） → 选择直接创建云端部署任务 或下载证书与私钥，再上传到目标平台 → CDN 下发，或重新加载配置 / 重启应用 → 等待边缘节点或应用生效 → 从公网验证证书链和有效期 → 记录下一次到期时间 单个步骤本身并不复杂，但只有上一阶段进入正确状态以后，下一阶段才能继续。证书数量增加后，人工维护的问题会被进一步放大： ...