1. 摘要
我用 TRAE SOLO 开发了一个轻量级的远程脚本执行管理平台 VibeRemote ，用来集中管理多台 Windows、macOS、Linux 主机，并批量下发脚本任务、查看执行状态和实时日志。
它解决的是日常开发/运维中“多台机器重复登录、重复执行命令、排查状态分散”的问题。现在可以通过 Web 控制台完成 Agent 管理、脚本管理、任务下发、日志查看、自动升级和安装包分发，形成了一个可实际部署使用的小型 DevOps 工具。
2. 背景
我平时会遇到多台服务器、测试机、客户端环境需要统一管理的场景，比如批量执行检查脚本、收集日志、验证 Agent 状态、远程排查问题等。
传统方式通常需要逐台 SSH、远程桌面或手动执行命令，流程重复、容易漏机器，也不方便沉淀执行记录。所以我希望用 SOLO 辅助完成一个“够轻、够直观、能真实落地”的工具：服务端负责统一调度，Agent 负责执行任务，Web 页面负责可视化管理。
3. 实践过程
这次我没有一开始就追求大而全，而是把任务拆成几个可以持续交付的小阶段：
第一阶段，先用 SOLO 帮我梳理需求和技术方案。
我给出的核心目标是：做一个类似轻量 DevOps 平台的工具，包含服务端、Agent 客户端和 Web 管理界面。SOLO 帮我把系统拆成了 Server-Agent 架构，并明确了后端 API、Agent 心跳、任务下发、日志上报、前端管理页面几个核心模块。
第二阶段，搭建基础闭环。
SOLO 辅助完成了 Spring Boot 服务端、Java Agent、前端管理页面的基础结构。最早的目标很简单：Agent 能注册到服务端，服务端能看到在线状态，Web 页面能创建任务，Agent 能拉取并执行脚本，再把结果和日志回传。
第三阶段，围绕真实使用场景不断补功能。
在基础功能跑通后，我继续让 SOLO 根据实际使用中的问题迭代，例如：
-
多 Agent 管理，支持 Windows / macOS / Linux
-
脚本管理，支持上传、编辑、下载和复用
-
批量任务，将一个脚本下发到多台 Agent
-
实时日志查看，方便定位执行过程
-
Agent 心跳检测和离线状态管理
-
用户、权限、分组能力
-
Agent 自动升级和版本管理
-
文件传输任务能力
-
一键安装脚本和部署包生成
-
本地测试环境启动脚本
-
E2E 测试脚本和部署验证脚本
第四阶段，重点处理“能不能真的部署”的问题。
这个阶段踩坑最多。比如安装脚本里服务端地址替换不完整、Windows/macOS 安装路径和权限差异、Agent 升级包下载失败、日志收集任务参数为空、前端部署后配置地址写死等问题。
这些问题不是单纯写代码能解决的，需要一边让 SOLO 分析日志和报错，一边调整脚本、后端配置、前端运行时配置和部署流程。最后项目里沉淀了多套脚本，包括本地启动、局域网测试、打包部署、Agent 安装、状态检查和回滚脚本。
我常用的 Prompt 大致是这种形式：
当前项目是一个 Server-Agent 架构的远程脚本执行平台。
请先阅读现有代码和文档，不要直接重构。
现在要实现/修复 xxx 功能：
1. 分析现有实现
2. 给出影响范围
3. 修改代码
4. 补充测试或验证脚本
5. 总结修改点和后续风险
这个 Prompt 模式对我很有帮助，因为它让 SOLO 不是只回答“怎么做”，而是能参与完整工程流程：读代码、定位问题、实现、验证、复盘。
4. 成果展示
项目最终形成了一个可运行的远程脚本执行管理平台，主要模块包括：
-
服务端：Spring Boot + JWT + MySQL，负责 Agent 注册、任务调度、日志接收、权限管理
-
Agent：Java 客户端，支持跨平台运行、心跳上报、脚本执行、日志回传、自动升级
-
Web 控制台：用于管理客户端、脚本、任务、用户、权限和系统状态
-
Portal 门户：提供安装说明和一键安装入口
-
部署脚本：支持本地环境启动、服务端部署包构建、Agent 安装包构建和部署验证
-
E2E 测试：覆盖用户管理、权限控制、文件管理、任务流程等核心场景
5. 效果与总结
这个项目最大的收获不是“AI 一次性生成了一个完整系统”，而是我真正体验到了一种新的开发方式：把 SOLO 当作持续协作的工程伙伴，而不是一次性问答工具。
如果完全手写，从需求分析、架构设计、后端接口、Agent、前端页面、安装脚本、部署验证到问题修复，可能需要比较长的连续开发时间。而使用 SOLO 后，我可以把精力更多放在判断需求是否合理、功能是否真实可用、部署链路是否闭环上。
这次对我最有价值的几点是：
-
SOLO 很适合做“已有项目上的连续迭代”，不是只能生成 Demo
-
真实项目一定要让 AI 参与调试和验证，否则很容易停留在代码看起来能跑
-
Prompt 要尽量贴近工程流程，比如“先读代码、再分析影响范围、最后验证”
-
小步迭代比一次性生成大系统更稳
-
发散需求可以交给 AI，最终取舍还是要回到真实使用场景
最后这个作品虽然不是复杂的大平台，但它解决了一个很真实的问题：让多台机器的脚本执行、状态管理、日志查看变得集中、可追踪、可复用。这也正好符合我对“AI 无限职场”的理解：不是炫技，而是把 AI 放进真实工作流里，让一个原本费时、重复、容易出错的流程变得更轻。