IDENTITY and PURPOSE

You are a system administrator and service reliability engineer at a large tech company. You are responsible for ensuring the reliability and availability of the company's services. You have a deep understanding of the company's infrastructure and services. You are capable of analyzing logs and identifying patterns and anomalies. You are proficient in using various monitoring and logging tools. You are skilled in troubleshooting and resolving issues quickly. You are detail-oriented and have a strong analytical mindset. You are familiar with incident response procedures and best practices. You are always looking for ways to improve the reliability and performance of the company's services. you have a strong background in computer science and system administration, with 1500 years of experience in the field.

You are given a log file from one of the company's servers. The log file contains entries of various events and activities. Your task is to analyze the log file, identify patterns, anomalies, and potential issues, and provide insights into the reliability and performance of the server based on the log data.

• Analyze the Log File: Thoroughly examine the log entries to identify any unusual patterns or anomalies that could indicate potential issues.
• Assess Server Reliability and Performance: Based on your analysis, provide insights into the server's operational reliability and overall performance.
• Identify Recurring Issues: Look for any recurring patterns or persistent issues in the log data that could potentially impact server reliability.
• Recommend Improvements: Suggest actionable improvements or optimizations to enhance server performance based on your findings from the log data.

• Avoid Irrelevant Information: Do not include details that are not derived from the log file.
• Base Assumptions on Data: Ensure that all assumptions about the log data are clearly supported by the information contained within.
• Focus on Data-Driven Advice: Provide specific recommendations that are directly based on your analysis of the log data.
• Exclude Personal Opinions: Refrain from including subjective assessments or personal opinions in your analysis.

逐节看其设计意图：

### 2.1 IDENTITY and PURPOSE：双重角色锚定

身份设定为"大型科技公司系统管理员 + 服务可靠性工程师"，并罗列了六项能力维度：基础设施理解、日志模式/异常识别、监控与日志工具熟练度、快速排障、细节导向的分析思维、事故响应流程与最佳实践。这种写法把输出锚定在 SRE（站点可靠性工程）的话语体系内——模型更可能产出含"MTTR、错误率、容量、告警阈值"等工程语汇的结论，而非泛泛而谈。结尾的 "1500 years of experience"（1500 年经验）是 Fabric 模式库中典型的夸张化经验锚定手法，用于强化"专家视角"的心理暗示。

### 2.2 Task：明确的四段式任务定义

任务被压缩为一句话但包含四个递进目标：分析日志 → 识别模式/异常/潜在问题 → 给出可靠性与性能洞察 → 基于日志数据支撑结论。"based on the log data" 的措辞在结尾再次出现，与 Restrictions 节形成呼应。

### 2.3 Actions：四步分析流水线

四条动作构成一条可复现的分析流水线：

1. **Analyze the Log File** —— 通读全部条目，找出非常规模式或异常；
2. **Assess Server Reliability and Performance** —— 基于分析给出运行可靠性与整体性能评估；
3. **Identify Recurring Issues** —— 专门寻找"反复出现的模式或持续性问题"，这是区分"单次故障"与"系统性隐患"的关键步骤；
4. **Recommend Improvements** —— 输出可执行的改进或优化建议，且必须基于前面从日志中发现的证据。

### 2.4 Restrictions：四条反幻觉约束

这是整个模式中最具工程价值的一节，四条约束全部服务于"数据驱动"：

- **Avoid Irrelevant Information**：不得包含任何未从日志文件派生的细节（防止模型脑补业务背景）；
- **Base Assumptions on Data**：任何关于日志数据的假设都必须能由日志内容本身明确支撑；
- **Focus on Data-Driven Advice**：建议必须具体且直接源于日志分析；
- **Exclude Personal Opinions**：禁止主观评价或个人意见。

这四条约束实质上是在用提示词层面强制"证据链闭环"：结论必须可回溯到输入日志的具体条目，适合把模型输出直接用于事故复盘文档的初稿。

### 2.5 INPUT：空占位符

文件以 `# INPUT:` 收尾且其后为空。结合该目录没有 `user.md` 的事实，可以推断：Fabric 运行时将 stdin 中的日志原文作为用户消息拼接到系统提示词之后，`# INPUT:` 仅作为语义锚点提示模型"输入将在此之后"。

## 三、实战用法：一条管道命令跑通日志分析

前提：已按 [README](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/README.md?utm_source=gitcode_repo_files) 安装 Fabric 并执行 `fabric --setup` 完成供应商配置。核心用法是把日志通过 stdin 传入：

```bash
# 基本用法：分析一个日志文件（--stream 流式输出，避免长等待）
cat /var/log/app.log | fabric --pattern analyze_logs --stream

# 结果落盘，便于归档进事故复盘文档
cat app.log | fabric -p analyze_logs -o log-analysis.md

# 指定厂商与模型（例如本地模型）
cat app.log | fabric -p analyze_logs -V "LM Studio" -m openai/gpt-oss-20b --stream

# 干跑模式：只打印将要发送给模型的内容，不消耗 API 额度
echo "2026-09-04 12:00:01 ERROR disk space below 10%" | fabric --dry-run -p analyze_logs
```

几个实用的配套命令：

```bash
# 查看该模式完整内容（核对提示词是否被本地修改过）
fabric --readpattern analyze_logs

# 列出全部模式 / 查看最近更新的模式
fabric -l
fabric -n 20

# 更新内置模式库（含 analyze_logs）
fabric -U
```

### 3.1 为日志分析固定专用模型

Fabric 支持按模式绑定模型，README 说明的机制是环境变量 `FABRIC_MODEL_PATTERN_NAME=vendor|model`。对 `analyze_logs` 这类对推理深度要求较高的任务，可以在 shell 启动文件中单独映射一个强推理模型，而不影响 `summarize` 等其他模式的选择。

### 3.2 叠加推理策略

Fabric 的 [策略文件](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/data/strategies?utm_source=gitcode_repo_files) 会把提示修改附加到系统提示词上。对日志这种"需要逐步排查"的任务，可以推断 `cot`（Chain-of-Thought，逐步推理）策略与 `analyze_logs` 的四步 Actions 天然契合：

```bash
cat app.log | fabric --strategy cot -p analyze_logs --stream
```

可用策略包括 `cot`、`cod`、`tot`、`aot`、`ltm`、`self-consistent`、`self-refine`、`reflexion`、`standard`（见 [README 策略清单](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/README.md?utm_source=gitcode_repo_files)），用 `fabric --liststrategies` 列出本机已安装的策略。注意策略需要先通过 `fabric -S` 安装到 `~/.config/fabric/strategies/`。

## 四、运行机制：Fabric 如何加载并执行这份 system.md

### 4.1 模式来源与更新链路

从源码结构看，内置模式由 [PatternsLoader](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/internal/tools/patterns_loader.go?utm_source=gitcode_repo_files) 负责分发：

- 默认从 Fabric 仓库的 [data/patterns](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/data/patterns?utm_source=gitcode_repo_files) 目录拉取（常量 `DefaultPatternsGitRepoFolder = "data/patterns"`，见 [patterns_loader.go#L19-L20](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/internal/tools/patterns_loader.go?utm_source=gitcode_repo_files#L19-L20)），`fabric -U` 触发的 `PopulateDB` 流程是：克隆到临时目录 → 拷贝到本地配置目录 → 生成 `unique_patterns.txt` 全量模式名清单（[PopulateDB 实现](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/internal/tools/patterns_loader.go?utm_source=gitcode_repo_files#L87-L124)）；
- 更新时通过 [PersistPatterns](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/internal/tools/patterns_loader.go?utm_source=gitcode_repo_files#L127-L171) 将本地存在而新版中不存在的目录视为**自定义模式并原样保留**，保证 `analyze_logs` 这类内置模式被刷新时不会误伤用户自建模式；
- 旧版路径 `patterns` 与新版 `data/patterns` 之间存在自动迁移逻辑（[tryPathMigration](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/internal/tools/patterns_loader.go?utm_source=gitcode_repo_files#L252-L299)），老配置无需手工改路径。

因此，本地修改 `analyze_logs/system.md`（例如按团队日志格式定制身份设定）是可行的：把定制版放入 `--setup` 中配置的 Custom Patterns 目录即可，更新内置模式时不会被覆盖。

### 4.2 提示词如何进入对话

Fabric 的提示工程方法论在 [README](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/README.md?utm_source=gitcode_repo_files) 中明确："we tend to use the System section of the prompt almost exclusively"（几乎只用 System 部分承载指令）。对应到 `analyze_logs`：`system.md` 全文作为 system 消息，stdin 日志作为 user 消息。发送前会经过 [NormalizeMessages](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/internal/domain/domain.go?utm_source=gitcode_repo_files#L60-L78) 规范化——剔除空消息并强制"用户消息位于奇数位"的消息顺序，以适配各供应商 API 对消息交替的约束。该模式不含 `#变量` 占位符，因此无需 `-v` 变量替换，输入就是原始日志文本。

### 4.3 生成参数

CLI 默认参数（见 [domain.go 常量定义](https://gitcode.com/GitHub_Trending/fa/Fabric/blob/6b0914d1bb0dbf54facec1743838c7312e945634/internal/domain/domain.go?utm_source=gitcode_repo_files#L7-L13)）：温度 0.7、top-p 0.9、存在惩罚/频率惩罚均为 0.0。日志分析属于事实归纳型任务，如需结论更收敛，可以用 `-t` 调低温度，例如：

```bash
cat app.log | fabric -p analyze_logs -t 0.3 --stream