实战指南｜软件/工程执行自动化场景

本教程聚焦 TRAE Work 在软件与工程执行自动化中的落地方法：不教你从零写系统，而是教你把已有的脚本、命令、配置和产物检查，组织成一条 TRAE Work 能稳定跑完、还能自动验收的执行链路。

本文适合谁？

如果你经常要处理脚本、文件、日志、工具链、数据流、外部系统或长期项目状态，这篇指南会很适合你。

本教程覆盖 5 个高频场景，彼此独立，你可以直接跳到与自己最贴近的一节：

在正式进入场景之前，先记住一条贯穿全篇的原则：执行自动化的稳定性，取决于任务的输入、出口与失败口径是否清晰，而不取决于脚本本身有多复杂。

场景一：运行脚本/批量处理生成产物

这是软件/工程执行自动化里最常见的一类场景。对软件与工程自动化场景的使用者来说，很多需求并不是重新开发一个系统，而是把已有脚本、目录、配置和产物检查串成一条稳定流程。 真正耗时的往往不是“写脚本”，而是手动切目录、补依赖、确认参数、检查输出、回看日志、定位产物。只要流程相对固定、边界清晰，这些重复动作都可以交给 TRAE Work 组织成一条可复用的执行链路。

适合处理的任务类型

• 已经有现成脚本、命令、模板或配置文件。
• 执行顺序明确，通常是 2～5 个步骤。
• 任务结束后有可验证的产物，例如 Markdown、PDF、JSON、CSV、图片、构建目录或日志文件。
• 你希望 TRAE Work 不只是"把脚本跑完"，还要顺手做一次产物验收。

推荐Prompt写法

执行以下任务：
1. 进入工作目录：写清目录位置；
2. 如果缺少依赖，先检查并告诉我，不要擅自安装；
3. 运行主脚本或命令：写清命令；
4. 完成后检查产物是否存在：写清文件名、目录或判断标准；
5. 如果失败，返回错误信息和最后 30 行日志。

实战示例

示例1：周报或日报生成

进入 ~/my-project，
执行 uv run python scripts/generate_report.py，
完成后检查 reports/ 目录下今天的 Markdown 和 PDF 是否都生成成功。
如果失败，把错误和最后 30 行日志告诉我。

示例2：批量内容处理

运行 scripts/batch_resize.py 处理 assets/raw/ 下的全部图片，
输出到 assets/processed/。
处理完成后告诉我成功多少张、失败多少张，并列出失败文件名。

示例 3：构建导出

在项目根目录执行 npm run build，
完成后检查 dist/ 是否生成，
再确认首页入口文件是否存在。
如果有报错，不要重试，直接把错误原样返回。

进阶做法：把“跑脚本”升级成可长期运行的自动化配置

许多团队的自动化止步于"把脚本跑起来"。但真正能长期节省时间的，是让同一条脚本链路在换时间、换机器、换参数、换触发条件时依然稳定可用。如果一条链路需要每天、每周或在固定条件下重复执行，就可以把它升级为 TRAE Work 的定时自动化配置——你不必每次手动发起，只需提前写清触发时间、执行步骤、成功判定与失败通知方式。

适合升级为定时自动化的任务，通常同时具备三个特征：

• 重复发生：例如每天生成日报、每周导出数据、定期清理缓存。
• 边界清晰：输入在哪里、输出到哪里、什么算成功，都能明确说清。
• 失败可处理：失败时能返回日志、缺失文件、权限问题或明确的下一步建议。

自动化任务示例：GitHub 每日生成日报

第 1 步：进入「自动化」入口。 在 TRAE Work 左侧栏点击「自动化」，进入自动化任务管理页，可查看「已配置 / 执行历史 / 任务模板」。

第 2 步：新建自动化任务。 点击「新建」，填写任务名称（如 GitHub 信息每日抓取）、设置触发时间（例如每天 10:00），在「你希望 TRAE Work 做什么？」中粘贴下面这段 Prompt，选择 Work 模式后点击「创建」。

请执行 Github 每日生成日报任务，并按以下自动化配置处理：
1. 先读取仓库内 README 里的主命令和运行说明；
2. 再读取 config.json，确认抓取源、输出目录和日报格式配置；
3. 检查运行依赖、输入配置、输出目录是否齐全，不满足则停止并告诉我缺什么；
4. 按 README 的主命令执行 `python3 github_daily.py --config config.json`；
5. 根据 README 说明抓取当日 Github 数据，在 output/ 下生成 Markdown 日报和 JSON 结构化数据；
6. 如果今天的日报文件已经存在且大小大于 0，则跳过执行，避免重复生成；
7. 执行成功后检查 `github_digest_YYYY-MM-DD.md` 和对应 JSON 是否都生成成功；
8. 成功时仅记录执行结果并保留产物，不额外通知；失败时把报错和最后 30 行日志发给我。

第 3 步：查看执行历史。 任务可按计划触发，也可手动触发。在「执行历史」里能看到每次运行的状态、触发方式和时间。

第 4 步：验收执行详情与产物。 点开单次执行，可以看到任务耗时、执行说明，以及产物汇总（生成的 Markdown 日报、JSON 数据与文件/代码变更），右侧还能直接预览日报内容。到这一步，「跑完 + 验收 + 留档」就形成了闭环。

场景二： 长任务监控与进度检查

有些任务启动之后不会立刻结束，例如模型训练、依赖安装、爬虫抓取、音视频转录、实验批跑。它们的难点不在"怎么启动"，而在启动之后如何判断它的真实状态：正在正常推进、已经完成，还是已经卡死。

相比直接重启，更高频、更实际的需求是：先看清当前状态，再决定是否介入。此时可以让 TRAE Work 监控任务进程、解析日志、提取关键指标（如训练步数、loss、ETA、资源利用率等），快速判断任务是否正常推进或卡住，并给出明确的状态结论与下一步建议，免去手动排查。

适合处理的任务类型

• 任务执行时间长，无法一次性看到最终结果。
• 你更关心当前阶段、剩余时间、是否卡住，而不是立刻重跑。
• 存在日志、进程、文件数量、GPU 利用率、服务状态等可观测信号。
• 你希望 TRAE Work 先做判断，再由你决定是否继续、重启或收尾。

推荐Prompt写法

请检查这个任务的当前状态，只检查，不重启，不修改：
1. 看指定进程是否仍在运行；
2. 读取日志文件最后 50 行；
3. 检查输出目录的文件数量或最新更新时间；
4. 输出：当前阶段 / 是否卡住 / 预计剩余时间 / 是否需要下一步动作。

实战示例

示例 1：训练任务进度

请检查训练日志 logs/train.log，
解析最新 step、loss、eta。
如果训练已经结束，告诉我最终状态；
如果还在跑，告诉我当前阶段和预计剩余时间。
不要重启训练。

示例 2：爬虫任务进度

请帮我检查 crawler 是否卡住：
1. 看进程是否仍在运行；
2. 读取 logs/crawler.log 最后 50 行；
3. 统计 data/ 目录今天新增了多少文件；
4. 判断是正常进行、已完成还是卡住。

示例 3：GPU 任务守护

请检查转录任务当前状态：
1. 统计已生成的 srt 文件数量；
2. 检查 transcribe_progress.json；
3. 检查 python 进程数量；
4. 检查 GPU 利用率和显存使用。
如果 GPU 利用率持续过低，请告诉我是否建议重启，但先不要执行。

场景三： 结果同步与外部系统集成

当任务不再局限于本地执行，而是还要把结果发出去，或者需要从外部平台、接口、机器人、连接器里取回状态时，就进入了集成类场景。对软件与工程自动化场景的使用者来说，这通常意味着把原本 “只能自己看到” 的脚本结果，接到真正可用的协作链路里。 TRAE Work 可通过标准化的任务编排能力，帮你轻松实现本地脚本与飞书通知、Webhook、MCP 连接器等外部系统的对接，无需额外开发即可完成结果分发、状态回拉等集成操作，让脚本能力真正融入协作流程。

适合处理的任务类型

• 希望本地结果自动发送到飞书、邮件、Webhook 或其他系统。
• 已有 MCP 连接器、第三方平台、内部接口或任务队列文件。
• 任务的终点不是本地命令结束，而是结果被分发、回写或同步。
• 需要明确成功和失败时分别怎么通知、怎么记录。

推荐Prompt写法

请执行以下集成任务：
1. 运行本地脚本或读取任务队列；
2. 捕获输出结果；
3. 按指定格式组装消息或 JSON；
4. 推送到 Webhook / 飞书群 / 外部平台；
5. 如果失败，把失败信息也推送，或写回队列文件。

实战示例

示例 1：把脚本结果发到飞书群

请执行 quota_check.py，
把输出整理成一段文本，
再通过飞书 webhook 推送到“个人开发告警”群。
如果脚本报错，也把报错发过去。

示例 2：任务队列消费

请读取 .task_queue/task_queue.json，
找出第一个 pending 任务并执行，
执行完成后把状态更新为 completed 或 failed，
同时把执行结果写入 result 字段。

示例 3：连接外部平台

通过 MCP，列出我在某平台中的全部项目，
并按名称输出一个清单。
如果连接失败，请告诉我缺少什么权限或配置。

场景四：长期工作流编排与自治系统

如果目标不只是跑通一个任务，而是围绕状态机和规则持续推进一个长期项目，那么就进入了自治系统场景。

对软件与工程自动化场景的使用者来说，这一类最适合用在个人项目代理、知识库维护、自动复盘、任务池消费等长期机制上。 TRAE Work 可帮你搭建状态机管理任务流转，自动读取状态文件、识别待办任务、按规则执行并更新状态，还能每日生成项目推进总结，让长期项目无需人工干预即可持续运转。

适合处理的任务类型

• 任务不是一次性的，需要周期性唤醒、持续推进。
• 系统中已有状态文件、任务池、待办列表或项目日志。
• 你希望每次执行后都留下记录，供下一轮继续使用。
• 任务可拆成小步，每轮只执行一项或少量几项。

推荐Prompt写法

你是我的长期项目助手，请按以下规则运行：
1. 读取状态文件：...
2. 找出当前待处理任务：...
3. 每次只执行一项，完成后写回状态：...
4. 如果没有任务，静默结束；
5. 每天额外生成一份总结：完成了什么 / 卡在哪里 / 下一步是什么。

实战示例

示例 1：个人项目自治推进

你是我的项目自治助手。
每小时读取 tasks.json，
找到最高优先级的 pending 任务开始执行，
执行前改成 doing，执行后改成 completed，
并把结果写到 results/<task_id>.md。
如果没有 pending 任务，静默结束。

示例 2：知识库维护

请每天检查 memory.md 和 user.md 的容量，
如果超过阈值就做精炼和去重，
并把维护记录写到 maintenance-log.md。

示例 3：每日复盘

请每天 23:00 阅读今天生成的全部结果文件，
总结“完成情况 / 阻塞点 / 明日重点”，
输出到 daily/YYYY-MM-DD.md。

场景五：本机环境诊断与维护

个人开发的大量时间并不都花在业务代码上，机器与环境的琐事同样耗时：电脑卡顿、磁盘占满、依赖混乱、网络环境切换、开发环境损坏。只要边界与规则清晰，这些工作同样可以纳入自动化视角。

适合处理的任务类型

• 处理的是机器和环境健康，而不是业务逻辑。
• 你希望先诊断、列建议，再决定是否执行动作。
• 对「哪些能动、哪些不能动」有明确要求。
• 结果适合用「问题 → 影响 → 建议动作」的清单呈现。

推荐Prompt写法

请帮我做一次系统诊断：
1. 检查 CPU / 内存 / 磁盘 / 进程 / 网卡状态；
2. 告诉我哪些地方异常；
3. 先不要修改任何东西；
4. 输出“问题 → 影响 → 建议动作”清单，等确认后再执行。

实战示例

示例 1：电脑卡顿诊断

我电脑最近很卡，请帮我做一次只检查不改动的诊断：
1. 列出 CPU 和内存占用前 10 的进程；
2. 扫描磁盘占用前 20 的目录；
3. 看一下是否存在明显可清理缓存；
4. 输出“问题 → 影响 → 建议操作”的清单。

示例 2：网络环境切换

请帮我创建一个内外网切换方案：
按一下切到内网时启用以太网、禁用 WLAN；
按一下切到外网时启用 WLAN、禁用以太网。
先给我计划，不要直接执行。

示例 3：开发环境复位

请检查我的 Python 开发环境：
列出当前 Python、pip、node、git 版本，
检查常用依赖是否可用，
并告诉我哪些地方需要修复。
先不要自动安装。

附录：

如何写出稳定的执行型 Prompt？

无论具体属于哪一类场景，稳定的执行型 prompt 大多都符合相同骨架。 TRAE Work 基于工程化执行逻辑，提炼出「目标→环境 / 入口→执行步骤→成功判定→失败处理」的标准化骨架 ，同时支持通过「流程 + 边界 + 输出格式」三段式结构进一步强化执行稳定性，让 AI 代理能够精准理解任务意图并输出一致结果。

【目标】
这次要完成什么结果。

【环境 / 入口】
工作目录、脚本路径、配置文件、接口地址、依赖说明。

【执行步骤】
按顺序列出 2 到 5 步动作。

【成功判定】
做完后应该检查什么：文件、日志、接口返回、进程状态。

【失败处理】
如果失败，应该返回什么：报错、最后几行日志、当前状态、是否需要人工介入。

GitHub skills 实用功能

如果你的自动化场景与 GitHub 相关，可优先使用 TRAE Work 内置或可安装的 GitHub skills。它们让 TRAE Work 能在对话中直接处理仓库、Issue、PR、CI 等信息，减少在浏览器、终端与文档之间来回切换。安装方式：在 TRAE Work 左侧栏点击「技能」，搜索对应 skill 名称，一键安装；安装后 AI 在执行相关操作时会自动调用。