@haaaiawd/anws 1.0.0

package/templates/.agent/skills/concept-modeler/references/ENTITY_EXTRACTION_PROMPT.md

@@ -0,0 +1,299 @@
+# 实体提取 Prompt 模板 - 完整版
+
+## 概述
+
+此 Prompt 用于从用户的自然语言描述中提取系统的逻辑模型。基于 2024 年 LLM Prompt 工程最佳实践设计。
+
+## 设计原则
+
+基于调研的最佳实践：
+
+1. **明确指令**：清晰陈述任务和期望的实体类型
+2. **Few-shot 示例**：提供示例帮助模型理解格式
+3. **Chain-of-Thought**：引导模型逐步推理
+4. **Role Prompting**：赋予模型专家身份
+5. **JSON 输出**：明确指定结构化输出格式
+6. **"Give LLM an Out"**：允许模型表示不确定性
+
+---
+
+## 主 Prompt 模板
+
+```markdown
+# 角色定义
+
+你是一名拥有 15 年经验的资深系统架构师。你的专长是：
+- 从模糊需求中提取精确的系统模型
+- 识别用户遗漏的关键组件
+- 预判潜在的架构风险和耦合问题
+- 设计可扩展、可维护的系统架构
+
+# 任务
+
+用户想要构建以下系统/功能：
+
+---
+{{USER_INPUT}}
+---
+
+请执行以下 **结构化分析**，按步骤推理：
+
+## 第 1 步：实体提取 (Entity Extraction)
+
+列出这个系统中必须存在的所有核心"名词"。
+
+思考方向：
+- 用户/角色类：谁会使用这个系统？
+- 数据/资源类：系统处理什么数据？
+- 服务/组件类：需要哪些独立的服务模块？
+- 外部依赖类：需要对接哪些外部 API 或服务？
+- 基础设施类：需要什么存储、缓存、队列？
+
+对于每个实体，评估其 **必要性**：
+- [必须] = 没有这个系统无法运行
+- [应该] = 没有这个会严重影响体验
+- [可选] = 增强功能，可后续添加
+
+## 第 2 步：数据流分析 (Data Flow Analysis)
+
+描述数据如何在这些实体之间流转。
+
+使用格式：
+```
+[源实体] --[动作/数据]--> [目标实体]
+```
+
+重点考虑：
+- 主流程（Happy Path）是什么？
+- 数据在哪些点会被转换或处理？
+- 哪些是同步操作，哪些应该异步？
+
+## 第 3 步：缺失检测 (Missing Component Detection)
+
+**这是最关键的一步**。根据你的经验，主动识别用户描述中 **遗漏** 的关键组件：
+
+检查清单：
+- [ ] **错误处理**：如果 X 失败了怎么办？重试？回滚？
+- [ ] **数据持久化**：数据存在哪里？需要备份吗？
+- [ ] **认证授权**：谁能访问什么？如何验证身份？
+- [ ] **日志监控**：如何知道系统状态？如何调试问题？
+- [ ] **队列/缓存**：是否需要异步处理？是否需要缓存热点数据？
+- [ ] **配置管理**：hardcode 还是外部配置？环境差异如何处理？
+- [ ] **限流/熔断**：高并发时如何保护系统？
+- [ ] **幂等性**：重复请求会怎样？
+
+对于每个缺失项，解释 **为什么需要** 以及 **如果没有会怎样**。
+
+## 第 4 步：风险识别 (Risk Identification)
+
+预判潜在的问题（即使用户没问）：
+
+风险类型：
+- **耦合风险**：哪些组件之间可能产生不健康的依赖？
+- **性能风险**：哪里可能成为瓶颈？
+- **可靠性风险**：哪里可能导致级联故障？
+- **安全风险**：哪里可能有安全漏洞？
+- **扩展性风险**：当规模增长 10 倍时，哪里会先出问题？
+
+## 第 5 步：边界定义 (Boundary Definition)
+
+建议如何划分模块边界以降低耦合：
+
+- 哪些组件应该放在一起（高内聚）？
+- 哪些组件应该分离（低耦合）？
+- 接口应该如何设计？
+
+---
+
+# 输出格式
+
+严格按照以下 JSON 格式输出：
+
+```json
+{
+  "entities": [
+    {
+      "name": "实体名称",
+      "type": "用户|数据|服务|外部|基础设施",
+      "necessity": "必须|应该|可选",
+      "description": "简要描述"
+    }
+  ],
+  "data_flows": [
+    {
+      "from": "源实体",
+      "action": "动作描述",
+      "to": "目标实体",
+      "data": "传递的数据",
+      "sync": true
+    }
+  ],
+  "missing_components": [
+    {
+      "component": "缺失组件名称",
+      "category": "错误处理|持久化|安全|监控|性能|配置",
+      "reason": "为什么需要",
+      "impact_if_missing": "如果没有会怎样",
+      "priority": "高|中|低"
+    }
+  ],
+  "potential_risks": [
+    {
+      "risk_type": "耦合|性能|可靠性|安全|扩展性",
+      "description": "风险描述",
+      "affected_entities": ["相关实体"],
+      "mitigation": "建议的缓解措施"
+    }
+  ],
+  "boundary_recommendations": [
+    {
+      "module_name": "模块名称",
+      "contains": ["包含的实体"],
+      "rationale": "为什么这样划分"
+    }
+  ],
+  "questions_for_user": [
+    "如果有不确定的地方，列出需要用户澄清的问题"
+  ]
+}
+```
+
+# 重要提示
+
+1. **不要编造**：如果信息不足，在 `questions_for_user` 中列出问题
+2. **保守估计**：宁可多识别缺失组件，也不要遗漏
+3. **解释推理**：对每个判断提供理由
+4. **实际经验**：基于真实系统设计经验，而不是理论
+```
+
+---
+
+## Few-Shot 示例
+
+### 示例输入
+
+```
+我想做一个"视频摘要生成器"：用户上传视频，系统用 Whisper 转文字，
+然后用 GPT 生成摘要，最后返回给用户。
+```
+
+### 示例输出
+
+```json
+{
+  "entities": [
+    {"name": "User", "type": "用户", "necessity": "必须", "description": "上传视频并获取摘要的用户"},
+    {"name": "VideoFile", "type": "数据", "necessity": "必须", "description": "用户上传的视频文件"},
+    {"name": "VideoUploader", "type": "服务", "necessity": "必须", "description": "处理视频上传的服务"},
+    {"name": "TranscriptionService", "type": "服务", "necessity": "必须", "description": "调用 Whisper API 转文字"},
+    {"name": "SummaryService", "type": "服务", "necessity": "必须", "description": "调用 GPT 生成摘要"},
+    {"name": "WhisperAPI", "type": "外部", "necessity": "必须", "description": "OpenAI Whisper 语音识别"},
+    {"name": "GPT_API", "type": "外部", "necessity": "必须", "description": "OpenAI GPT 文本生成"},
+    {"name": "FileStorage", "type": "基础设施", "necessity": "必须", "description": "存储上传的视频和生成的摘要"},
+    {"name": "TaskQueue", "type": "基础设施", "necessity": "应该", "description": "异步处理视频任务"}
+  ],
+  "data_flows": [
+    {"from": "User", "action": "上传", "to": "VideoUploader", "data": "视频文件", "sync": true},
+    {"from": "VideoUploader", "action": "存储", "to": "FileStorage", "data": "视频文件", "sync": true},
+    {"from": "VideoUploader", "action": "创建任务", "to": "TaskQueue", "data": "任务ID", "sync": true},
+    {"from": "TaskQueue", "action": "触发", "to": "TranscriptionService", "data": "视频路径", "sync": false},
+    {"from": "TranscriptionService", "action": "调用", "to": "WhisperAPI", "data": "音频数据", "sync": true},
+    {"from": "TranscriptionService", "action": "传递", "to": "SummaryService", "data": "文字内容", "sync": true},
+    {"from": "SummaryService", "action": "调用", "to": "GPT_API", "data": "文字内容", "sync": true},
+    {"from": "SummaryService", "action": "存储", "to": "FileStorage", "data": "摘要结果", "sync": true}
+  ],
+  "missing_components": [
+    {
+      "component": "任务状态追踪",
+      "category": "监控",
+      "reason": "用户上传后需要知道处理进度",
+      "impact_if_missing": "用户无法知道视频是否处理完成，体验极差",
+      "priority": "高"
+    },
+    {
+      "component": "API 调用重试机制",
+      "category": "错误处理",
+      "reason": "Whisper/GPT API 可能超时或失败",
+      "impact_if_missing": "单次失败导致整个任务失败，浪费用户时间",
+      "priority": "高"
+    },
+    {
+      "component": "视频大小/时长限制",
+      "category": "性能",
+      "reason": "大视频会导致处理时间过长和成本过高",
+      "impact_if_missing": "用户可能上传几GB的视频导致系统崩溃",
+      "priority": "高"
+    },
+    {
+      "component": "费用追踪/计费",
+      "category": "配置",
+      "reason": "API 调用有成本，需要追踪",
+      "impact_if_missing": "无法控制成本，可能产生意外账单",
+      "priority": "中"
+    }
+  ],
+  "potential_risks": [
+    {
+      "risk_type": "性能",
+      "description": "视频处理是 CPU/内存密集型，大视频可能导致 OOM",
+      "affected_entities": ["TranscriptionService"],
+      "mitigation": "限制视频大小，使用流式处理"
+    },
+    {
+      "risk_type": "可靠性",
+      "description": "如果 TaskQueue 宕机，所有待处理任务丢失",
+      "affected_entities": ["TaskQueue"],
+      "mitigation": "使用持久化队列（如 Redis + 持久化）"
+    },
+    {
+      "risk_type": "耦合",
+      "description": "TranscriptionService 和 SummaryService 如果同步调用，一个慢会拖慢整个流程",
+      "affected_entities": ["TranscriptionService", "SummaryService"],
+      "mitigation": "考虑将两个服务通过队列解耦"
+    }
+  ],
+  "boundary_recommendations": [
+    {
+      "module_name": "上传模块",
+      "contains": ["VideoUploader", "FileStorage"],
+      "rationale": "上传和存储紧密相关，应该放在一起"
+    },
+    {
+      "module_name": "处理模块",
+      "contains": ["TranscriptionService", "SummaryService", "TaskQueue"],
+      "rationale": "视频处理流程，通过队列异步执行"
+    },
+    {
+      "module_name": "外部集成层",
+      "contains": ["WhisperAPI", "GPT_API"],
+      "rationale": "所有外部 API 调用应该通过统一的适配层，方便切换供应商"
+    }
+  ],
+  "questions_for_user": [
+    "视频支持的最大时长/大小是多少？",
+    "用户是否需要实时查看处理进度？",
+    "摘要结果需要保留多久？"
+  ]
+}
+```
+
+---
+
+## 追问策略
+
+如果初始分析不够深入，使用以下追问：
+
+1. **边界追问**："如果 [实体A] 出错了，[实体B] 会怎样？"
+2. **规模追问**："如果有 10000 个用户同时使用，哪里会先崩？"
+3. **演化追问**："6 个月后如果要加 [新功能]，需要改动哪些组件？"
+4. **成本追问**："这个架构的运维成本主要在哪里？"
+5. **安全追问**："如果有恶意用户尝试攻击，最薄弱的环节是哪里？"
+
+---
+
+## 与其他 Skills 的配合
+
+- 对于 **Brownfield** 模式：先用 `build-inspector` 分析构建边界，用 `runtime-inspector` 分析 IPC，再用此 Prompt 分析新功能
+- 分析结果应传递给 Scout 的功能冲突分析（Step 6）和最终报告生成
+- 识别的缺失组件应在后续 Blueprint 阶段详细设计
+

package/templates/.agent/skills/concept-modeler/scripts/glossary_gen.py

@@ -0,0 +1,66 @@
+import os
+import argparse
+import json
+import re
+
+# Simple regex for finding potential domain terms (Classes, Structs)
+# This is a heuristic. For better results, use the tree-sitter slice we built earlier.
+# But for "Concept Modeling" of a whole repo, a fast scan is often enough to start.
+
+PATTERNS = {
+    'python': [r'class\s+([A-Z][a-zA-Z0-9_]*)'],
+    'rust': [r'struct\s+([A-Z][a-zA-Z0-9_]*)', r'enum\s+([A-Z][a-zA-Z0-9_]*)'],
+    'javascript': [r'class\s+([A-Z][a-zA-Z0-9_]*)', r'interface\s+([A-Z][a-zA-Z0-9_]*)'],
+    'typescript': [r'class\s+([A-Z][a-zA-Z0-9_]*)', r'interface\s+([A-Z][a-zA-Z0-9_]*)', r'type\s+([A-Z][a-zA-Z0-9_]*)']
+}
+
+def scan_identifiers(root_dir: str):
+    terms = set()
+    
+    for root, _, files in os.walk(root_dir):
+        for file in files:
+            ext = os.path.splitext(file)[1]
+            lang = None
+            if ext == '.py': lang = 'python'
+            elif ext == '.rs': lang = 'rust'
+            elif ext in ['.js', '.jsx']: lang = 'javascript'
+            elif ext in ['.ts', '.tsx']: lang = 'typescript'
+            
+            if lang:
+                try:
+                    with open(os.path.join(root, file), 'r', encoding='utf-8') as f:
+                        content = f.read()
+                        
+                    for pat in PATTERNS[lang]:
+                        matches = re.finditer(pat, content)
+                        for m in matches:
+                            terms.add(m.group(1))
+                except Exception:
+                    pass
+                    
+    return sorted(list(terms))
+
+def main():
+    parser = argparse.ArgumentParser(description="Generate Glossary Context")
+    parser.add_argument("--path", required=True, help="Repo path")
+    parser.add_argument("--output", "-o", help="Output JSON file for LLM")
+    
+    args = parser.parse_args()
+    
+    print(f"Scanning for domain terms in {args.path}...")
+    terms = scan_identifiers(args.path)
+    
+    result = {
+        "candidate_terms": terms,
+        "instruction": "The above terms were extracted from the codebase. Please filter out technical terms (like 'Config', 'Factory') and keep only Domain Terms."
+    }
+    
+    if args.output:
+        with open(args.output, 'w') as f:
+            json.dump(result, f, indent=2)
+        print(f"Context saved to {args.output}")
+    else:
+        print(json.dumps(result, indent=2))
+
+if __name__ == "__main__":
+    main()

package/templates/.agent/skills/git-forensics/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: git-forensics
+description: 分析 Git 历史，发现"逻辑耦合"（总一起改的文件）和"热点"（高频修改的复杂模块）。基于 Adam Tornhill 的《Your Code as a Crime Scene》方法论。
+---
+
+# 考古学家手册 (The Archaeologist's Field Notes)
+
+> "历史不会重复，但会押韵。静态分析告诉你结构，Git 取证告诉你痛苦的真相。" —— Adam Tornhill
+
+本技能基于 **Adam Tornhill 的《Your Code as a Crime Scene》** 方法论。
+核心思想：代码的**演化历史**比代码本身更能揭示设计问题。
+
+---
+
+## ⚠️ 强制深度思考
+
+> [!IMPORTANT]
+> 在执行任何分析之前，你**必须**调用 `sequential thinking` 工具，视情况进行 **2—3 步**推理。
+> 思考内容例如：
+> 1.  "这个项目的 Git 历史有多深？是否需要 `git fetch --unshallow`？"
+> 2.  "我应该关注哪个时间范围？（最近 3 个月？1 年？）"
+> 3.  "有没有明显的'噪音文件'（如 `package-lock.json`）需要排除？"
+
+---
+
+## ⚡ 快速启动
+1.  **耦合分析**: `python scripts/git_forensics.py --repo . --threshold 0.3`
+2.  **热点探测**: `python scripts/git_hotspots.py --repo . --days 180`
+
+---
+
+## 🧭 探索流程 (The Dig)
+
+### 第一步：感知时间流 (The Tornhill Method)
+*   **老师傅箴言**: "代码的价值不是它是什么，而是它是如何变成这样的。"
+*   运行 `git log --oneline -n 100`，快速感知项目近期活跃度。
+*   **关键推断**: 如果最近 50 次提交都只涉及一两个目录，那就是"震中"——最可能藏有风险的地方。
+
+### 第二步：发现隐性耦合 (Temporal Coupling / Change Coupling)
+*   **核心问题**: "有没有两个文件，它们在代码里**没有** `import`/`use` 关系，但 **70%** 的提交都一起出现？"
+*   **老师傅警报 (来自 Adam Tornhill)**:
+    *   ⚠️ **逻辑耦合但物理分离** -> 这是"架构腐烂 (Architectural Decay)"的强信号！
+    *   ⚠️ **跨构建根的耦合** -> 如果 `service/ipc.rs` 总和 `gui/api.ts` 一起改，但它们属于不同构建根，这是**版本漂移**的温床！
+    *   **处方**: 要么合并它们到同一模块，要么抽象出共享的 Schema/契约层。
+
+### 第三步：定位热点 (Hotspot Analysis - CodeScene Methodology)
+*   **公式**: 热点 = 高变更频率 (Churn) × 高复杂度 (Complexity)
+*   **老师傅策略矩阵 (来自 CodeScene)**:
+
+    | | 低复杂度 | 高复杂度 |
+    | :---: | :---: | :---: |
+    | **高 Churn** | 配置/生成代码，可忽略 | 🔴 **优先重构！Bug 温床，ROI 最高** |
+    | **低 Churn** | 稳定模块，别动 | 🟡 遗留雷区，小心翼翼 |
+
+*   **老师傅建议**: 重构资源有限时，**只攻高 Churn + 高 Complexity 的象限**。这是投资回报率最高的地方。
+
+---
+
+## 🛡️ 老师傅守则
+
+1.  **先取消浅克隆**: `git fetch --unshallow`。没有历史 = 没有数据 = 你是盲人。
+2.  **过滤噪音**: 忽略 `package-lock.json`, `Cargo.lock`, `*.min.js`, `dist/` 等生成物。它们会污染你的分析结果。
+3.  **警惕大规模重命名**: 重命名 (`git mv`) 会干扰追踪。如果发现诡异的耦合数据，手动检查是否是重命名导致。
+4.  **关联构建信息**: 在输出耦合对时，**标注它们分别属于哪个构建根**。这是连接 Git 分析和 Build 分析的关键桥梁。
+
+---
+
+## 📤 输出清单
+
+1.  **Coupling Pairs (耦合对)**: Score > 0.7 的文件对。**标注它们的构建根**。
+2.  **Cross-Root Couplings (跨根耦合)**: 重点标记！如果两个高耦合文件属于不同构建根，这是**头号风险**。
+3.  **Hotspots (热点)**: 高风险模块列表 (高 Churn + 高 Complexity)。
+4.  **Orphans (孤儿)**: 超过 1 年无人触碰的文件（知识腐烂警告）。
+5.  **Refactoring Priority**: 根据 Churn/Complexity 矩阵给出建议的重构优先级。

package/templates/.agent/skills/git-forensics/references/ANALYSIS_METHODOLOGY.md

@@ -0,0 +1,193 @@
+# Git Forensics 分析方法论
+
+## 概述
+
+Git Forensics 的核心价值不仅是数据抓取，更重要的是**分析**和**可操作建议**。本文档定义了分析的方法论和决策规则。
+
+## 核心指标
+
+### 1. 共改频率 (Co-change Frequency)
+
+**定义**：
+```
+frequency = 共改次数 / 目标文件总提交次数
+```
+
+**风险等级判定**：
+
+| 频率范围 | 风险等级 | 标记 | 解读 |
+|---|---|---|---|
+| ≥ 0.70 | 🔴 HIGH | `HIGH_COUPLING` | 强逻辑耦合，修改一个必须考虑另一个 |
+| 0.40 - 0.69 | 🟡 MEDIUM | `MEDIUM_COUPLING` | 中等耦合，建议关注 |
+| < 0.40 | 🟢 LOW | (无标记) | 偶发性共改，可能是巧合 |
+
+### 2. 文件类型分类
+
+不同类型的文件有不同的耦合性质：
+
+| 类型 | 匹配模式 | 耦合性质 | 处理方式 |
+|---|---|---|---|
+| 测试文件 | `*test*`, `*spec*`, `__tests__/` | ✅ 合理耦合 | 正常，测试应跟随代码变化 |
+| 配置文件 | `*config*`, `.env*`, `*.yaml`, `*.json` | ⚠️ 需警惕 | 可能存在硬编码或配置管理问题 |
+| 文档文件 | `*.md`, `README*`, `CHANGELOG*` | ✅ 合理耦合 | 正常，文档应随代码更新 |
+| 生产代码 | 其他 | ❓ 需深入分析 | 高频率 + 无物理依赖 = 隐性耦合 |
+
+### 3. 时间衰减因素
+
+近期的共改比远期的更有参考价值：
+
+| 时间范围 | 权重建议 | 说明 |
+|---|---|---|
+| 最近 30 天 | 1.5x | 最近的修改模式更能反映当前状态 |
+| 30-90 天 | 1.0x | 标准权重 |
+| 90-180 天 | 0.7x | 历史参考，权重降低 |
+| > 180 天 | 0.5x | 仅作参考 |
+
+**注意**：当前脚本实现尚未包含时间衰减，作为后续优化项。
+
+---
+
+## 分析建议生成规则
+
+### 规则 1：高频生产代码耦合
+
+**条件**：
+- 两个生产代码文件
+- 共改频率 ≥ 0.70
+- 无物理依赖（即 A 不 import B）
+
+**建议**：
+- "考虑将 A 和 B 合并为同一模块"
+- "或者提取公共接口，明确依赖关系"
+- "检查是否存在隐性的数据依赖"
+
+### 规则 2：跨模块高频耦合
+
+**条件**：
+- 两个文件属于不同目录/模块
+- 共改频率 ≥ 0.50
+
+**建议**：
+- "可能需要重新划分模块边界"
+- "考虑使用事件/消息解耦"
+- "评估是否应该合并为同一模块"
+
+### 规则 3：配置文件高频耦合
+
+**条件**：
+- 生产代码与配置文件共改频率 ≥ 0.30
+
+**建议**：
+- "检查是否存在硬编码的配置值"
+- "考虑使用环境变量或配置中心"
+- "评估配置管理策略"
+
+### 规则 4：测试覆盖率信号
+
+**条件**：
+- 生产代码没有对应的测试文件共改
+- 或测试文件共改频率 < 0.30
+
+**建议**：
+- "该文件可能缺少测试覆盖"
+- "修改时未同步更新测试可能有风险"
+
+### 规则 5：单点责任人风险
+
+**条件**：
+- 某个文件 80% 以上的修改来自同一作者
+
+**建议**：
+- "存在知识单点风险"
+- "建议进行知识转移或代码评审"
+
+---
+
+## 输出结构
+
+### 标准输出字段
+
+```json
+{
+  "target_file": "分析的目标文件",
+  "analysis_period_days": 180,
+  "total_commits_modifying_target": 25,
+  "co_changed_files": [
+    {
+      "file": "共改文件路径",
+      "co_change_count": 20,
+      "frequency": 0.80,
+      "warning": "HIGH_COUPLING|MEDIUM_COUPLING",
+      "category": "PRODUCTION|TEST_FILE|CONFIG_FILE|DOC_FILE"
+    }
+  ],
+  "last_modified_date": "2024-12-20",
+  "primary_authors": ["Alice", "Bob"],
+  "analysis": {
+    "high_risk_files": ["高风险文件列表"],
+    "recommendations": ["可操作的建议列表"]
+  }
+}
+```
+
+### 建议的格式
+
+建议应该是**可操作的**，而不是泛泛的描述：
+
+✅ **好的建议**：
+- "考虑将 `login.ts` 和 `session.ts` 合并，因为它们在 80% 的提交中一起修改"
+- "文件 `config.ts` 与多个生产代码共改，检查是否应该使用环境变量"
+
+❌ **差的建议**：
+- "存在耦合"（太模糊）
+- "需要注意"（没有行动指导）
+
+---
+
+## 边界情况处理
+
+### 大规模重构 Commit
+
+**问题**：一次重构可能修改几十个文件，干扰分析。
+
+**解决方案**：
+- 识别修改文件数 > 20 的 commit
+- 可选择忽略这类 commit
+- 或降低其权重
+
+**当前实现**：未处理，作为后续优化项。
+
+### 新文件
+
+**问题**：新创建的文件历史太短。
+
+**解决方案**：
+- 如果文件存在时间 < 30 天，标记分析结果为"数据不足"
+- 建议等待更多历史数据
+
+### 删除的文件
+
+**问题**：历史中引用了已删除的文件。
+
+**解决方案**：
+- 在输出中标记 `[DELETED]`
+- 仍然报告历史耦合关系
+
+---
+
+## 与其他 Skills 的配合
+
+1. **与 `build-inspector` 对比**：
+   - build-inspector 提供构建边界和版本漂移风险
+   - git-forensics 提供逻辑耦合
+   - 两者交叉 = 跨构建根的耦合（最高风险）
+
+2. **与 `runtime-inspector` 结合**：
+   - 在高耦合文件中检查 IPC 相关代码
+   - 这些文件的协议漂移风险更高
+
+3. **输出给 Scout 功能冲突分析**：
+   - 高风险文件列表
+   - 生成的建议
+   - 耦合关系图数据
+