尧图网页设计 
LifeOS Fabric 实战用 create_ttrc_graph 模式把「关键漏洞修复时长」转化为进度可视化 CSV【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS导读本篇文章聚焦 LifeOS 内置 Fabric 技能库中的create_ttrc_graph提示词模式Pattern。TTR-CTime to Remediate Critical Vulnerabilities关键漏洞修复时长是衡量安全团队响应能力最核心的 KPI 之一而create_ttrc_graph的作用就是把输入材料中散落的时间序列指标自动整理成一张可直接绘制趋势图的 CSV 表格用数据讲清「安全计划正在进步」这一故事。读完本文你将掌握该模式的完整执行协议、严格的 CSV 输出规范、它在 LifeOS 中原生执行不依赖 fabric CLI的调用链以及它与create_ttrc_narrative、create_graph_from_input等相邻模式的配合用法。一、模式定位它是什么、解决什么问题create_ttrc_graph是 LifeOS 仓库中 Fabric 技能库LifeOS/install/skills/Fabric/Patterns/create_ttrc_graph/system.md下的一个提示词模式属于「Creation / Security」类别。它的任务非常聚焦从任意输入材料安全报告、KPI 汇总、漏洞治理周报等中抽取出「时间 → 关键漏洞修复时长」的两轴数据并输出为一份只含纯净数值的 CSV 文件。在安全运营中管理层最关心的不是某一次修复有多快而是修复时长是否随时间的推移持续下降。TTR-C 正是回答这个问题的指标下降 进步修复关键漏洞越快暴露窗口越短攻击面越小上升 回退修复变慢说明流程淤塞、资源不足或积压恶化。create_ttrc_graph的职责就是把「进步故事」翻译成机器可读、图表可用的结构化数据。它与同目录下的两个模式互为补充模式产出定位create_ttrc_graph纯 CSV 数据表为图表提供数据源create_ttrc_narrative见 LifeOS/install/skills/Fabric/Patterns/create_ttrc_narrative/system.md说服力强的叙事文本为读者解读数据背后的进步create_graph_from_input见 LifeOS/install/skills/Fabric/Patterns/create_graph_from_input/system.md多指标 CSVTTD、TTI、TTR-CJC、TTR-C更宽泛的「安全计划进度」制图pattern_explanations.mdLifeOS/install/skills/Fabric/Patterns/pattern_explanations.md中的模式清单对它的描述是create_ttrc_graphCreates a CSV file showing the progress of Time to Remediate Critical Vulnerabilities over time using given data.二、模式的完整协议拆解create_ttrc_graph/system.md全文按 Fabric 模式的标准结构组织IDENTITY → GOAL → STEPS → OUTPUT下面逐段拆解其执行协议。2.1 IDENTITY双重专家身份You are an expert at data visualization and information security.模式要求模型同时具备数据可视化专家与信息安全专家的双重身份。这两重身份缺一不可信息安全视角能识别哪些指标才是真正的 TTR-C理解修复时长在安全计划中的业务含义避免把无关指标如漏洞总量误当成 TTR-C数据可视化视角能判断数据是否构成「两轴时间序列」x 轴为时间、y 轴为指标值并产出可直接交给绘图工具的结构化数据。2.2 GOAL明确唯一的目标Show how the time to remediate critical vulnerabilities has changed over time.目标只有一个呈现关键漏洞修复时长随时间的变化。注意这里用的是「changed」变化而非「improved」——模式对趋势方向保持中立但 OUTPUT 部分会特别提醒下降才是改进。2.3 STEPS两步处理流程- Fully parse the input and spend 431 hours thinking about it and its implications to a security program. - Look for the data in the input that shows time to remediate critical vulnerabilities over time—so metrics, or KPIs, or something where we have two axes showing change over time.第一步深度解析「spend 431 hours thinking」是 Fabric 系模式的常见修辞手法非字面要求意在强制模型在生成输出前做充分的深层推理思考数据对安全计划的影响第二步定位数据在输入中寻找满足两个条件的内容——(1) 与 TTR-C 相关的指标或 KPI(2) 构成「时间 × 数值」的两轴结构。常见的输入来源包括季度安全报告、漏洞管理仪表盘导出、SLA 达成率汇总表、Red Team 行动复盘等。2.4 OUTPUT严格的 CSV 输出契约输出部分定义了不可妥协的格式规范这是整个模式最核心、最容易被 LLM 违反的部分1. 只输出 CSV不输出任何其他内容- Only output valid CSV data and nothing else. - Do not output any other content other than the CSV data. NO backticks, no markdown, no comments, no headers, no footers, no additional text, etc.这是最严格的一条连 Markdown 代码围栏backticks都禁止。输出的必须是裸 CSV 文本不能带解释、不能带格式标记。这保证了输出可以被脚本直接管道化pipe到文件或绘图工具。2. 字段只含数字禁止特殊字符- Only output numbers in the fields, no special characters like , , , etc..数值字段中不允许出现、、等比较符号或单位后缀保证数据可以被数值解析器直接消费。3. 列名必须沿用输入中的字段名- Use the field names in the input; dont make up your own.这是「事实准确」约束的体现——模型不得自行发明列名必须忠实保留输入材料中的字段命名。4. 方向语义明确- NOTE: Remediation times should ideally be decreasing, so decreasing is an improvement not a regression.专门加注强调修复时长的下降是改进而非回退。这防止模型在叙事或数据处理时把「数值变小」误判为「情况变差」。5. 标准格式模板EXAMPLE OUTPUT FORMAT Date TTR-C_days Month Year 81 Month Year 80 Month Year 72 Month Year 67 (Continue) END EXAMPLE FORMAT模板展示了标准结构列含义示例值Date时间点x 轴Month Year如Jan 2026TTR-C_days关键漏洞修复时长y 轴单位天81、80、72、67注意模板中列名是TTR-C_days带单位后缀但第三条规则要求「沿用输入的字段名」——如果输入材料中的列名不同例如TTRC_DAYS或avg_ttrc应以输入为准。模板中的Month Year同样只是占位示意实际日期格式应保持与输入一致。三、在 LifeOS 中如何执行该模式create_ttrc_graph不是孤立存在的提示文本它在 LifeOS 中有一条完整的原生执行链路。3.1 原生执行机制不经过 fabric CLIFabric 技能的核心说明LifeOS/install/skills/Fabric/SKILL.md明确写道Patterns run natively — LifeOS reads the patterns system.md and applies it directly, no CLI round-trip. The fabric CLI is only used for YouTube transcripts (-y) and URL fallback (-u).也就是说在 LifeOS 中执行create_ttrc_graph时Agent 直接读取Patterns/create_ttrc_graph/system.md把其中的指令作为提示词应用到用户提供的内容上无需安装 fabric CLI、无外部进程依赖。fabric CLI 仅在两种场景保留-y URLYouTube 字幕提取和-u URLURL 内容抓取兜底。完整的执行链路记录在 ExecutePattern 工作流LifeOS/install/skills/Fabric/Workflows/ExecutePattern.md中User Request ↓ 模式选择按意图关键词匹配或按显式模式名 Read Patterns/{pattern_name}/system.md ↓ 将模式指令作为提示词直接应用 Follow STEPS and OUTPUT INSTRUCTIONS ↓ Return structured output per pattern spec从源码结构可以推断create_ttrc_graph这类「生成式」模式属于 ExecutePattern 决策树中Contains create → Match keyword → create_[keyword]分支——当用户请求中出现「create ttrc graph」「关键漏洞修复时长趋势图」等意图时即可命中该模式。3.2 使用前提与注意点输入必须是包含时间序列的原始材料本模式是「提取重构」不是「生成」。没有输入数据模式无法凭空捏造 TTR-C 序列不要为它生成 Markdown 表格模式的输出契约强制 CSV 纯文本这与extract_wisdom等返回 Markdown 分节的模式截然不同对比 ExecutePattern.md 中列出的 extract_wisdom 输出结构长内容处理SKILL.md 的 Gotchas 提示超长输入可能超出模式上下文窗口此时应先切分内容或先用 summarize 类模式压缩。3.3 输出后的数据流向CSV 产出后可以直接喂给电子表格软件Excel、Numbers绘制折线图数据可视化库如 Chart.js、D3、matplotlib渲染趋势图直接追加进安全运营报告作为数据附表。由于输出是严格的裸 CSV它可以被重定向直接落盘例如# 将模式输出写入 CSV 文件示意实际由 Agent 在对话中完成 # pattern_output ttrc_progress.csv仓库本身是只读资料以上为一般性使用说明无需修改仓库文件。四、输出字段的语义与业务解读理解TTR-C_days的含义是正确使用本模式的前提。虽然模式文档未展开定义但从安全运营的通用语境和相邻模式create_graph_from_input中出现的TTR-C_days、TTR-CJC_days可以推断TTR-CTime to Remediate Critical从关键漏洞被确认到完成修复或验证缓解所经过的时间通常以天计下降趋势的业务含义暴露窗口收窄攻击者可利用关键漏洞的时间变短整体风险水位下降可用于横向对比的姊妹指标TTD_hours检测时间、TTI_hours调查时间、TTR-CJC_days关键高危联合修复时长——create_graph_from_input模式即同时输出这四列。模式要求「输出足够讲述进步故事的所有必要数据」all the necessary data to tell the progress story意味着模型应尽可能完整地保留输入中的时间点序列而不是抽样或截断。五、质量验证清单自检要点结合模式 OUTPUT 契约可整理出一份执行质量验收清单#检查项通过标准1纯 CSV无 Markdown 围栏、无注释、无额外解释文字2数值纯净字段中无、、等特殊字符3列名忠实沿用输入中的字段名未自造列名4两轴齐全x 轴为时间Datey 轴为修复时长5数据完整覆盖输入中全部相关时间点6趋势可读数据能直观呈现「下降进步」的故事线六、延伸与相邻模式的组合使用在真实的安全治理工作流中create_ttrc_graph通常不是终点制图先用create_ttrc_graph产出 CSV叙事再用create_ttrc_narrative基于同一份输入产出「安全计划正在大幅进步」的说服性叙事二者配对构成「数据 解读」的完整汇报包更宽泛的制图如果目标是展示整个安全计划不止 TTR-C的进步可用create_graph_from_input一次性产出多指标 CSV上游分析如果输入是一份完整威胁报告可先用analyze_threat_reportLifeOS/install/skills/Fabric/Patterns/analyze_threat_report/system.md抽取 TRENDS、STATISTICS 等结构化洞察再交给制图模式。这些模式全部存放在 LifeOS/install/skills/Fabric/Patterns/ 目录下每个模式一个子目录、一个system.md结构统一、可独立引用。七、小结create_ttrc_graph是 Fabric 安全类模式中一个「小而严」的典型职责单一TTR-C 趋势制图数据提取、契约严苛纯数值 CSV、零杂质输出、语义清晰下降进步。在 LifeOS 中原生执行时它不依赖任何外部 CLI通过 ExecutePattern.md 定义的「读 system.md → 当提示词应用 → 按规格返回」链路直接生效。对于安全负责人、AppSec 工程师和漏洞管理团队而言掌握该模式意味着把「关键漏洞修复时长」从零散报告中的数字变成一张随时可绘制的进度曲线从而让治理成效可度量、可汇报、可追踪。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LifeOS Fabric 实战：用 create_ttrc_graph 模式把「关键漏洞修复时长」转化为进度可视化 CSV
LifeOS Fabric 实战用 create_ttrc_graph 模式把「关键漏洞修复时长」转化为进度可视化 CSV【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS导读本篇文章聚焦 LifeOS 内置 Fabric 技能库中的create_ttrc_graph提示词模式Pattern。TTR-CTime to Remediate Critical Vulnerabilities关键漏洞修复时长是衡量安全团队响应能力最核心的 KPI 之一而create_ttrc_graph的作用就是把输入材料中散落的时间序列指标自动整理成一张可直接绘制趋势图的 CSV 表格用数据讲清「安全计划正在进步」这一故事。读完本文你将掌握该模式的完整执行协议、严格的 CSV 输出规范、它在 LifeOS 中原生执行不依赖 fabric CLI的调用链以及它与create_ttrc_narrative、create_graph_from_input等相邻模式的配合用法。一、模式定位它是什么、解决什么问题create_ttrc_graph是 LifeOS 仓库中 Fabric 技能库LifeOS/install/skills/Fabric/Patterns/create_ttrc_graph/system.md下的一个提示词模式属于「Creation / Security」类别。它的任务非常聚焦从任意输入材料安全报告、KPI 汇总、漏洞治理周报等中抽取出「时间 → 关键漏洞修复时长」的两轴数据并输出为一份只含纯净数值的 CSV 文件。在安全运营中管理层最关心的不是某一次修复有多快而是修复时长是否随时间的推移持续下降。TTR-C 正是回答这个问题的指标下降 进步修复关键漏洞越快暴露窗口越短攻击面越小上升 回退修复变慢说明流程淤塞、资源不足或积压恶化。create_ttrc_graph的职责就是把「进步故事」翻译成机器可读、图表可用的结构化数据。它与同目录下的两个模式互为补充模式产出定位create_ttrc_graph纯 CSV 数据表为图表提供数据源create_ttrc_narrative见 LifeOS/install/skills/Fabric/Patterns/create_ttrc_narrative/system.md说服力强的叙事文本为读者解读数据背后的进步create_graph_from_input见 LifeOS/install/skills/Fabric/Patterns/create_graph_from_input/system.md多指标 CSVTTD、TTI、TTR-CJC、TTR-C更宽泛的「安全计划进度」制图pattern_explanations.mdLifeOS/install/skills/Fabric/Patterns/pattern_explanations.md中的模式清单对它的描述是create_ttrc_graphCreates a CSV file showing the progress of Time to Remediate Critical Vulnerabilities over time using given data.二、模式的完整协议拆解create_ttrc_graph/system.md全文按 Fabric 模式的标准结构组织IDENTITY → GOAL → STEPS → OUTPUT下面逐段拆解其执行协议。2.1 IDENTITY双重专家身份You are an expert at data visualization and information security.模式要求模型同时具备数据可视化专家与信息安全专家的双重身份。这两重身份缺一不可信息安全视角能识别哪些指标才是真正的 TTR-C理解修复时长在安全计划中的业务含义避免把无关指标如漏洞总量误当成 TTR-C数据可视化视角能判断数据是否构成「两轴时间序列」x 轴为时间、y 轴为指标值并产出可直接交给绘图工具的结构化数据。2.2 GOAL明确唯一的目标Show how the time to remediate critical vulnerabilities has changed over time.目标只有一个呈现关键漏洞修复时长随时间的变化。注意这里用的是「changed」变化而非「improved」——模式对趋势方向保持中立但 OUTPUT 部分会特别提醒下降才是改进。2.3 STEPS两步处理流程- Fully parse the input and spend 431 hours thinking about it and its implications to a security program. - Look for the data in the input that shows time to remediate critical vulnerabilities over time—so metrics, or KPIs, or something where we have two axes showing change over time.第一步深度解析「spend 431 hours thinking」是 Fabric 系模式的常见修辞手法非字面要求意在强制模型在生成输出前做充分的深层推理思考数据对安全计划的影响第二步定位数据在输入中寻找满足两个条件的内容——(1) 与 TTR-C 相关的指标或 KPI(2) 构成「时间 × 数值」的两轴结构。常见的输入来源包括季度安全报告、漏洞管理仪表盘导出、SLA 达成率汇总表、Red Team 行动复盘等。2.4 OUTPUT严格的 CSV 输出契约输出部分定义了不可妥协的格式规范这是整个模式最核心、最容易被 LLM 违反的部分1. 只输出 CSV不输出任何其他内容- Only output valid CSV data and nothing else. - Do not output any other content other than the CSV data. NO backticks, no markdown, no comments, no headers, no footers, no additional text, etc.这是最严格的一条连 Markdown 代码围栏backticks都禁止。输出的必须是裸 CSV 文本不能带解释、不能带格式标记。这保证了输出可以被脚本直接管道化pipe到文件或绘图工具。2. 字段只含数字禁止特殊字符- Only output numbers in the fields, no special characters like , , , etc..数值字段中不允许出现、、等比较符号或单位后缀保证数据可以被数值解析器直接消费。3. 列名必须沿用输入中的字段名- Use the field names in the input; dont make up your own.这是「事实准确」约束的体现——模型不得自行发明列名必须忠实保留输入材料中的字段命名。4. 方向语义明确- NOTE: Remediation times should ideally be decreasing, so decreasing is an improvement not a regression.专门加注强调修复时长的下降是改进而非回退。这防止模型在叙事或数据处理时把「数值变小」误判为「情况变差」。5. 标准格式模板EXAMPLE OUTPUT FORMAT Date TTR-C_days Month Year 81 Month Year 80 Month Year 72 Month Year 67 (Continue) END EXAMPLE FORMAT模板展示了标准结构列含义示例值Date时间点x 轴Month Year如Jan 2026TTR-C_days关键漏洞修复时长y 轴单位天81、80、72、67注意模板中列名是TTR-C_days带单位后缀但第三条规则要求「沿用输入的字段名」——如果输入材料中的列名不同例如TTRC_DAYS或avg_ttrc应以输入为准。模板中的Month Year同样只是占位示意实际日期格式应保持与输入一致。三、在 LifeOS 中如何执行该模式create_ttrc_graph不是孤立存在的提示文本它在 LifeOS 中有一条完整的原生执行链路。3.1 原生执行机制不经过 fabric CLIFabric 技能的核心说明LifeOS/install/skills/Fabric/SKILL.md明确写道Patterns run natively — LifeOS reads the patterns system.md and applies it directly, no CLI round-trip. The fabric CLI is only used for YouTube transcripts (-y) and URL fallback (-u).也就是说在 LifeOS 中执行create_ttrc_graph时Agent 直接读取Patterns/create_ttrc_graph/system.md把其中的指令作为提示词应用到用户提供的内容上无需安装 fabric CLI、无外部进程依赖。fabric CLI 仅在两种场景保留-y URLYouTube 字幕提取和-u URLURL 内容抓取兜底。完整的执行链路记录在 ExecutePattern 工作流LifeOS/install/skills/Fabric/Workflows/ExecutePattern.md中User Request ↓ 模式选择按意图关键词匹配或按显式模式名 Read Patterns/{pattern_name}/system.md ↓ 将模式指令作为提示词直接应用 Follow STEPS and OUTPUT INSTRUCTIONS ↓ Return structured output per pattern spec从源码结构可以推断create_ttrc_graph这类「生成式」模式属于 ExecutePattern 决策树中Contains create → Match keyword → create_[keyword]分支——当用户请求中出现「create ttrc graph」「关键漏洞修复时长趋势图」等意图时即可命中该模式。3.2 使用前提与注意点输入必须是包含时间序列的原始材料本模式是「提取重构」不是「生成」。没有输入数据模式无法凭空捏造 TTR-C 序列不要为它生成 Markdown 表格模式的输出契约强制 CSV 纯文本这与extract_wisdom等返回 Markdown 分节的模式截然不同对比 ExecutePattern.md 中列出的 extract_wisdom 输出结构长内容处理SKILL.md 的 Gotchas 提示超长输入可能超出模式上下文窗口此时应先切分内容或先用 summarize 类模式压缩。3.3 输出后的数据流向CSV 产出后可以直接喂给电子表格软件Excel、Numbers绘制折线图数据可视化库如 Chart.js、D3、matplotlib渲染趋势图直接追加进安全运营报告作为数据附表。由于输出是严格的裸 CSV它可以被重定向直接落盘例如# 将模式输出写入 CSV 文件示意实际由 Agent 在对话中完成 # pattern_output ttrc_progress.csv仓库本身是只读资料以上为一般性使用说明无需修改仓库文件。四、输出字段的语义与业务解读理解TTR-C_days的含义是正确使用本模式的前提。虽然模式文档未展开定义但从安全运营的通用语境和相邻模式create_graph_from_input中出现的TTR-C_days、TTR-CJC_days可以推断TTR-CTime to Remediate Critical从关键漏洞被确认到完成修复或验证缓解所经过的时间通常以天计下降趋势的业务含义暴露窗口收窄攻击者可利用关键漏洞的时间变短整体风险水位下降可用于横向对比的姊妹指标TTD_hours检测时间、TTI_hours调查时间、TTR-CJC_days关键高危联合修复时长——create_graph_from_input模式即同时输出这四列。模式要求「输出足够讲述进步故事的所有必要数据」all the necessary data to tell the progress story意味着模型应尽可能完整地保留输入中的时间点序列而不是抽样或截断。五、质量验证清单自检要点结合模式 OUTPUT 契约可整理出一份执行质量验收清单#检查项通过标准1纯 CSV无 Markdown 围栏、无注释、无额外解释文字2数值纯净字段中无、、等特殊字符3列名忠实沿用输入中的字段名未自造列名4两轴齐全x 轴为时间Datey 轴为修复时长5数据完整覆盖输入中全部相关时间点6趋势可读数据能直观呈现「下降进步」的故事线六、延伸与相邻模式的组合使用在真实的安全治理工作流中create_ttrc_graph通常不是终点制图先用create_ttrc_graph产出 CSV叙事再用create_ttrc_narrative基于同一份输入产出「安全计划正在大幅进步」的说服性叙事二者配对构成「数据 解读」的完整汇报包更宽泛的制图如果目标是展示整个安全计划不止 TTR-C的进步可用create_graph_from_input一次性产出多指标 CSV上游分析如果输入是一份完整威胁报告可先用analyze_threat_reportLifeOS/install/skills/Fabric/Patterns/analyze_threat_report/system.md抽取 TRENDS、STATISTICS 等结构化洞察再交给制图模式。这些模式全部存放在 LifeOS/install/skills/Fabric/Patterns/ 目录下每个模式一个子目录、一个system.md结构统一、可独立引用。七、小结create_ttrc_graph是 Fabric 安全类模式中一个「小而严」的典型职责单一TTR-C 趋势制图数据提取、契约严苛纯数值 CSV、零杂质输出、语义清晰下降进步。在 LifeOS 中原生执行时它不依赖任何外部 CLI通过 ExecutePattern.md 定义的「读 system.md → 当提示词应用 → 按规格返回」链路直接生效。对于安全负责人、AppSec 工程师和漏洞管理团队而言掌握该模式意味着把「关键漏洞修复时长」从零散报告中的数字变成一张随时可绘制的进度曲线从而让治理成效可度量、可汇报、可追踪。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考