如何快速开发命令行自动化脚本——以 Linux 检查为例场景1. 从手工日志生成主线描述2. 自动化生成 → AI 测试 → AI 评估3. 输出脚本以及命令映射4. 客户端下载脚本上机联调5. AI 改进6. 标记脚本调试完成一次真实的 Linux 主机巡检脚本开发5 条命令从手工日志到可批量下发。项目地址https://qingxun.online场景需求看这台主机磁盘是否快满、满了被什么占、docker 里的服务是否正常。手工敲的是df-hdu-sh/*2/dev/nulldu-sh/var/lib/*2/dev/nulldockerpsdockerlogs--tail20qingxun这 5 条是一条递进证据链df看满不满 →du逐层定位到目录 →docker ps/logs看服务有没有被影响。只自动化前三条拿到的还是磁盘 21%没法直接行动。1. 从手工日志生成主线描述上面填一句目标下面原样粘贴刚手工执行的会话本次 5996 字符。提示符、Last login这类噪音不用清AI 生成框架时会剥掉。注意日志会随请求发给模型粘之前先删密码/IP。生成的框架按步骤整理成「命令 回显 处理逻辑 预期」。日志里只有事实、没有判据所以 AI 把推不出的口径丢进右侧「待确认」阈值取 80% 还是 90%、docker 日志出现 ERROR 算不算异常。点候选就地填进框架再点「应用到主线描述」。本次阈值取90%。2. 自动化生成 → AI 测试 → AI 评估一个按钮跑完三步生成按主线描述产出 Ruby 脚本和命令映射。测试沙箱加载脚本连模拟设备按命令映射回放报文——脚本下发df -h就返回需求里那段真实回显。映射里没有的命令会直接回not recognized。评估按需求拆出的条目逐条核对不通过就带原因重新生成最多 3 次。本次首轮通过评估通过结论 5 条 · 问题 2 条 · 建议 2 条3 个检查点全部通过共尝试 1 次。状态是「调试中」。人工审核主要看日志以及脚本结果3. 输出脚本以及命令映射脚本所有命令下发集中在run里解析拆成独立函数。命令映射脚本执行期间进行的交互报文4. 客户端下载脚本上机联调客户端「我的脚本」→「同步脚本」。设备密码和回显都留在本地不上云。执行后看日志检查点逐个落结论检查点检查根分区使用率 - [通过]真机回显与模拟环境基本一致——这就是前面回显原文照抄 命令映射两步的回报。本次真机根分区 21%远低于 90% 阈值判定通过。5. AI 改进图 7 右上角的**「云端改进」**如果脚本联机调试有问题或者需要改进把真机日志连同改进要求回传云端AI 反推需求描述该怎么改确认后再应用。于是形成闭环手工日志 → 需求描述 → 脚本 → 真机日志 → 改进描述 → 重新生成设备回显默认不出本机只有你点这个按钮时才送云端。6. 标记脚本调试完成回云端生成页点按钮条上的**「调试完成」**见图 3状态调试中 → 调试完成需要填写适配设备型号版本可回滚。到此脚本才成为团队资产——客户端同步一次就能批量下发给同型号的多台机器。几个真正省事的点痛点不是生成代码而是把需求说清楚。所以重心在需求描述上评估也按条目逐条核对。待确认项是刻意留的。阈值 80 还是 90、ERROR 算不算故障日志里没有这些判据只能由人定——比让模型猜一个数字、你再去代码里找要安全。命令映射是调试环境的契约。缺一条命令测试就回not recognized回显有出入测出来就和真机两回事。AI 通过 ≠ 免审核真机跑通 ≠ 结束。「评估通过」和「调试完成」是两个显式动作中间夹着人工审核。截图来自一次真实开发过程涉及的 5 条命令见开头。本轮脚本生成大概用时10分钟
如何快速开发命令行自动化脚本——以 Linux 检查为例场景1. 从手工日志生成主线描述2. 自动化生成 → AI 测试 → AI 评估3. 输出脚本以及命令映射4. 客户端下载脚本上机联调5. AI 改进6. 标记脚本调试完成一次真实的 Linux 主机巡检脚本开发5 条命令从手工日志到可批量下发。项目地址https://qingxun.online场景需求看这台主机磁盘是否快满、满了被什么占、docker 里的服务是否正常。手工敲的是df-hdu-sh/*2/dev/nulldu-sh/var/lib/*2/dev/nulldockerpsdockerlogs--tail20qingxun这 5 条是一条递进证据链df看满不满 →du逐层定位到目录 →docker ps/logs看服务有没有被影响。只自动化前三条拿到的还是磁盘 21%没法直接行动。1. 从手工日志生成主线描述上面填一句目标下面原样粘贴刚手工执行的会话本次 5996 字符。提示符、Last login这类噪音不用清AI 生成框架时会剥掉。注意日志会随请求发给模型粘之前先删密码/IP。生成的框架按步骤整理成「命令 回显 处理逻辑 预期」。日志里只有事实、没有判据所以 AI 把推不出的口径丢进右侧「待确认」阈值取 80% 还是 90%、docker 日志出现 ERROR 算不算异常。点候选就地填进框架再点「应用到主线描述」。本次阈值取90%。2. 自动化生成 → AI 测试 → AI 评估一个按钮跑完三步生成按主线描述产出 Ruby 脚本和命令映射。测试沙箱加载脚本连模拟设备按命令映射回放报文——脚本下发df -h就返回需求里那段真实回显。映射里没有的命令会直接回not recognized。评估按需求拆出的条目逐条核对不通过就带原因重新生成最多 3 次。本次首轮通过评估通过结论 5 条 · 问题 2 条 · 建议 2 条3 个检查点全部通过共尝试 1 次。状态是「调试中」。人工审核主要看日志以及脚本结果3. 输出脚本以及命令映射脚本所有命令下发集中在run里解析拆成独立函数。命令映射脚本执行期间进行的交互报文4. 客户端下载脚本上机联调客户端「我的脚本」→「同步脚本」。设备密码和回显都留在本地不上云。执行后看日志检查点逐个落结论检查点检查根分区使用率 - [通过]真机回显与模拟环境基本一致——这就是前面回显原文照抄 命令映射两步的回报。本次真机根分区 21%远低于 90% 阈值判定通过。5. AI 改进图 7 右上角的**「云端改进」**如果脚本联机调试有问题或者需要改进把真机日志连同改进要求回传云端AI 反推需求描述该怎么改确认后再应用。于是形成闭环手工日志 → 需求描述 → 脚本 → 真机日志 → 改进描述 → 重新生成设备回显默认不出本机只有你点这个按钮时才送云端。6. 标记脚本调试完成回云端生成页点按钮条上的**「调试完成」**见图 3状态调试中 → 调试完成需要填写适配设备型号版本可回滚。到此脚本才成为团队资产——客户端同步一次就能批量下发给同型号的多台机器。几个真正省事的点痛点不是生成代码而是把需求说清楚。所以重心在需求描述上评估也按条目逐条核对。待确认项是刻意留的。阈值 80 还是 90、ERROR 算不算故障日志里没有这些判据只能由人定——比让模型猜一个数字、你再去代码里找要安全。命令映射是调试环境的契约。缺一条命令测试就回not recognized回显有出入测出来就和真机两回事。AI 通过 ≠ 免审核真机跑通 ≠ 结束。「评估通过」和「调试完成」是两个显式动作中间夹着人工审核。截图来自一次真实开发过程涉及的 5 条命令见开头。本轮脚本生成大概用时10分钟
