运行时日志阅读

解决「日志太多，结论太少」的问题

在前后端联调或功能测试完成后，运行日志往往散落在 Agent 终端、logs/ 目录、控制台输出以及浏览器 DevTools 中。人工翻阅这些输出来确认「哪些功能正常、哪些功能报错」不仅耗时，而且容易遗漏关键异常。

这个技能的目标是把碎片化的终端输出和日志文件，自动转化为一份面向人阅读的结构化测试结论（日志阅读.md），让你直接看到功能状态和错误堆栈。

核心工作流

技能按照固定的顺序定位并处理日志，无需手动整理：

1. 自动定位日志源：优先抓取当前测试会话的 Agent 终端输出（如 npm、vite、docker compose 等）；其次扫描项目中的常见日志路径（如 backend/logs/、.next/、*.log）；如果提供了浏览器控制台导出，也会一并纳入。
2. 收集与过滤上下文：保留完整的错误堆栈和关键时间戳。针对超大日志文件，自动 grep 出 error、Exception、FATAL 等关键字，过滤掉无关的运行噪音。
3. 功能映射与分类：将日志中的路由（如 POST /api/login）或组件名映射到具体业务功能。每个功能会被严格划分为三种状态：

- 正常：日志中无相关报错，或存在明确的成功信号。
- 异常：存在与该功能直接关联的错误或断言失败。
- 未验证：日志中既没有成功也没有失败的证据。

1. 输出阅读报告：在项目根目录生成 日志阅读.md，严格保留错误原文，对超长堆栈截断中间部分但保留首尾关键帧，并附带可能的推断原因。

适用边界与注意点

• 证据优先：报告只陈述日志中客观存在的事实，不会将未验证的猜测作为根因。所有的推测都会明确标注在「可能原因（推断）」下。
• 时间窗口：默认仅分析「当前测试会话」的日志。如果需要排查历史轮转日志，需在对话中明确指定。
• 覆盖范围：如果前后端同时运行，技能会同时审查两侧日志；若仅有一侧存在日志，报告中会在「覆盖范围」一节如实说明。