上下文切换会破坏工作势头。当 AI 助手在项目进行中中断时，下一个会话会从零开始。它不记得代码库结构，不记得哪些端口处于活跃状态，也不记得 Monero RPC 昨天运行异常。Daniel Ioni 构建了一个直接且实用的工具：一份专门为 AI 系统编写的技术指南，以便它们可以在无需人工引导的情况下，继续在 MyZubster Gateway 上开展工作。它充当了持久化的合成记忆。它不是简单地倾倒原始源代码，而是教会机器如何操作系统、排除故障，并在进行破坏性更改之前尊重操作者的权限。

MyZubster 究竟构建了什么

MyZubster Gateway 是一个围绕现实世界资产代币化（real-world asset tokenization）构建的去中心化市场。简单来说，它是一种基础设施，允许物理资产或传统资产在带有定义明确的元数据和所有权规则的情况下在链上转移。该平台处理同质化资产代币化（fungible asset tokenization），这意味着资产可以被分割、交易和追踪，且每个单位都附带标准化的元数据。

隐私设计是其核心。交易在 Monero 中结算。可编程资产和 NFT 在 Tari 上运行。整个操作通过 Tor Onion Service 进行屏蔽，使网关能够抵御审查和地理封锁。安全层运行在 Kali Linux 上，并使用 DeepSeek AI 安全机器人，这暗示了它具备自动入侵检测或异常扫描功能，而非简单的日志轮转。托管和争议解决并非手动后台任务。它们是自动化的，当交易条件触发冲突时，由 AI 进行调解。

这只是表面。在底层，系统是由 RPC 端点、本地数据库和 Node.js 进程组成的网络，这些组件必须保持同步，否则市场将停止清算交易。

技术栈及其重要性

网关监听 3002 端口。那是入口。Monero 的钱包 RPC 位于 localhost:18083，负责处理私有钱包操作、余额查询和转账，而不会将用户数据暴露给公共链分析。Tari 的 RPC 在 localhost:12820 响应，管理可编程资产层。如果这些端点中的任何一个发生偏移或失效，市场就会陷入停滞。

MongoDB 在后台作为运行数据存储。Node.js 为网关服务本身提供动力。前端代码位于专用目录 ~/myzubster-frontend 中。这是一个经典的去中心化技术栈：用于结算的区块链节点、用于状态存储的本地数据库，以及用于交互的薄 Web 层，所有这些都封装在隐私工具中。这里的一切都不是装饰性的。每个端口和路径的选择都是为了保持系统的自给自足和可防御性。

运行系统

启动网关只需一条 systemd 命令：systemctl start myzubster-gateway。这听起来微不足道，直到服务在无人看管的重启后发生静默失败。届时，你需要使用 journalctl -u myzubster-gateway -n 50 --no-pager 来提取最后五十行日志，而不会产生分页噪音。这五十行通常包含答案。也许是 Monero RPC 拒绝了连接，也许是 MongoDB 在系统更新后未能重新上线。

安全机器人位于 /root/security_bot.py，并通过 python3 /root/security_bot.py 启动。在通用服务器上以 root 身份运行安全脚本并不是常规做法。在专门用于监控和自动响应的加固型 Kali 环境中，这符合其运行模型。DeepSeek AI 的集成意味着该机器人不仅仅是在扫描日志；它很可能正在评估网络行为或交易模式，以寻找被入侵的迹象。

对于前端工作，该指南完全消除了猜测。AI 知道确切的切入点：cd ~/myzubster-frontend。无需在 /var/www、/opt 或散乱的主目录中搜索。该指南通过精确固定这些路径来强制执行一致性，这在多个会话或不同的 AI 实例在数周内访问同一台服务器时显得尤为重要。

出错时

当网关停止响应时，第一步是进行进程侦察。运行 ps aux | grep node 查看 Node.js 进程是否仍在运行。如果它消失了，请检查日志。如果日志显示数据库连接错误，那么 MongoDB 就是罪魁祸首。使用 systemctl start mongod 将其启动。许多去中心化应用将区块链节点视为脆弱的组件，但在实践中，在非正常关机或常规软件包更新后，本地 MongoDB 实例往往是第一个出问题的。

Monero RPC 问题遵循不同的模式。如果余额停止更新或付款交易卡在待处理状态，指南指示检查 monero-wallet-rpc 状态。这通常意味着需要验证钱包 RPC 进程是否正在运行，确认它是否已同步到正确的守护进程 (daemon)，并确保身份验证标志与网关的预期相匹配。此处的排查逻辑很简单：首先是区块链结算层，其次是数据库，最后是应用程序。如果忽略这个顺序，当真正的故障是 RPC 端口失效时，你却会在 Node.js 日志中徒劳地寻找不存在的问题。

AI 应如何使用本手册

该指南为 AI 设定了四条行为规则，这些规则体现了对自动化助手在生产环境中如何失效的深刻理解。

第一，引用特定章节。如果用户正在排查支付失败问题，AI 应明确指出 Monero RPC 或托管 (escrow) 子系统，以便用户准确知道哪个环节出了问题。第二，提供准确的命令。不要转述标志 (flags) 或猜测路径。第三，建议下一个逻辑步骤。项目恢复是一个序列过程；在端口检查和安全机器人之间随机跳转会浪费时间，并可能导致问题恶化。第四，在重启服务或删除数据之前请求用户确认。自主性很有用，直到它意外抹除了钱包缓存，或在活跃交易期间导致网关宕机。

一份动态文档

本指南的设计初衷就是为了不断演进。随着 MyZubster 项目的成长，AI 会更新文档。这创造了一个反馈循环，使运维经验转化为组织记忆。在小团队或跨时区、跨作息周期的个人项目中，这取代了通常存在于资深工程师脑中的“茶水间知识”。文档会从每一次停机事故中学习。

核心启示

像这样的 AI 项目恢复指南解决了一个具体且令人头疼的问题。它们弥合了原始文档与上下文理解之间的鸿沟。对于 MyZubster 而言，这意味着市场可以应对上下文丢失、重启和团队更迭。每当新会话开始时，机器不需要从头开始重新学习技术栈。它只需要阅读手册，执行准确的命令，并知道何时停下来询问。

来源：AI Technical Guide: MyZubster Project Recovery，作者 Daniel Ioni

可选学习社区：GyaanSetu AI on Telegram