LifeOS Fabric 模式实战用 create_loe_document 自动生成专业的 Level of EffortLOE工作量估算文档【免费下载链接】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在软件、云与网络安全项目中为任务或项目估算工作量Effort、资源与成本往往依赖资深架构师凭经验人工撰写格式不一、颗粒度粗糙、难以对齐干系人预期。LifeOS 的 Fabric 技能内置了 240 个可直接执行的提示词模式Prompt Pattern其中create_loe_document专门用于把一段任务描述转化为结构化、可评审、可复用的 LOELevel of Effort文档。本文将完整解析该模式的系统提示词system.md结构与九段式文档骨架并结合 LifeOS Fabric 技能的原生执行机制与配套工作流给出可直接落地的实战方案。读完本文你将掌握如何调用该模式、理解其九大章节的设计意图并能独立产出一份覆盖范围、业务影响、资源、工期、风险与假设的专业工作量估算文档。一、模式定位create_loe_document 在 Fabric 技能中的角色create_loe_document是 LifeOS 中 Fabric 技能 所管理的众多提示词模式之一。Fabric 技能的核心设计是让 240 个经过验证的专用提示词随手可得用户只需说出模式名称或意图LifeOS 就会直接读取对应模式目录下的system.md并将其作为系统提示词应用到输入内容上全程无需外部 CLI 往返Native Pattern Execution。模式的物理存储路径为 LifeOS/install/skills/Fabric/Patterns/create_loe_document/system.md。每个模式目录的结构约定如下Patterns/ ├── create_loe_document/ │ └── system.md # 该模式的完整提示词指令 ├── create_prd/ │ └── system.md ├── create_design_document/ │ └── system.md └── ...240 patterns从system.md的内容组织看每个模式的提示词通常包含四类要素身份IDENTITY我是谁、目标GOAL要达成什么、步骤STEPS如何处理输入以及输出指令OUTPUT INSTRUCTIONS以什么格式输出create_loe_document完全遵循这一范式。该模式在模式推荐目录中同时被归类为BUSINESS业务与DEVELOPMENT开发两类用途见 LifeOS/install/skills/Fabric/Patterns/suggest_pattern/system.md说明它既能服务于商务侧的立项评估也能支撑工程侧的交付排期。官方描述见 LifeOS/install/skills/Fabric/Patterns/pattern_explanations.mdCreates detailed Level of Effort documents for estimating work effort, resources, and costs for tasks or projects.为任务或项目创建工作量、资源和成本的详细估算文档。二、身份与目标模式期望模型以什么角色工作system.md开篇的Identity and Purpose定义了该模式激活时模型应代入的身份模型被设定为软件、云计算与网络安全架构专家expert in software, cloud, and cybersecurity architecture专长是创建清晰、结构良好的 LOE 文档用于估算给定任务或项目的工作量、资源与成本。Goal部分则规定了输出的总要求给定一个任务或系统的描述后产出覆盖以下维度的详细 LOE 文档范围Scope业务影响Business Impact资源需求Resource Requirements估算工作量Estimated Effort风险Risks依赖Dependencies假设Assumptions这一设定意味着调用该模式时你只需要提供任务描述见文末Input一节模式会自动以架构专家的视角补齐上述工程与业务维度而不是简单回复一段大概要 X 天。三、处理流程模式内部的三步加工逻辑system.md的Steps部分规定了模型处理输入时的顺序共四步彻底分析输入任务确保完全理解Analyze the input task thoroughly to ensure full comprehension梳理任务的全部关键组成部分综合考虑需求、依赖、风险与工作量估算因素Map out all key components…基于组织性质考虑业务优先级与风险偏好Consider business priorities and risk appetite based on the nature of the organization将 LOE 文档拆分为结构化章节以保证清晰与完整Break the LOE document into structured sections。从源码角度看这一处理流程与 ExecutePattern 工作流 的 Step 3Apply Pattern to Content完全对应LifeOS 读取system.md后将其中 IDENTITY / STEPS / OUTPUT INSTRUCTIONS 直接作为提示词应用不调用外部工具。也就是说你看到的三步/四步加工逻辑就是模型实际执行的推理链条——理解这一点有助于你喂养输入时更有针对性描述越完整含目标、约束、团队现状模式产出的 LOE 越贴合实际。四、九段式 LOE 文档骨架核心章节逐段解析这是system.md的主体部分也是你调用该模式后将会得到的文档结构。以下九节必须完整呈现模型需要逐节填写内容。Section 1: Task Overview任务概览对待估算的任务、项目或计划给出高层摘要定义目标与预期成果objectives and expected outcomes识别关键干系人与受益方key stakeholders and beneficiaries。实战提示调用时建议在输入里显式列出干系人如业务负责人、架构师、安全团队、项目经理模式会据此在概览中体现责任归属。Section 2: Business Impact业务影响定义该任务要解决的业务问题列出对组织的预期收益与价值突出业务风险或合规考量regulatory considerations。该节的价值在于把技术估算翻译成业务语言便于管理层决策是否立项。如果任务涉及金融、医疗等强监管场景合规考量应在此节显式标注。Section 3: Scope Deliverables范围与交付物界定范围内与范围外的工作in-scope / out-of-scope拆解主要交付物与里程碑deliverables and milestones明确成功验收标准acceptance criteria。范围描述得越精确后续工作量估算越可靠。模式要求显式列出不在范围内的内容这是防止范围蔓延scope creep的关键手段。Section 4: Resource Requirements资源需求识别所需技能集与角色例如软件工程师software engineers、安全分析师security analysts、云架构师cloud architects、Scrum Master、项目经理project manager等以表格形式估算所需人员数量列出所需的工具、基础设施或许可证tooling, infrastructure, or licenses。这是全文中第一个明确要求tabular format表格格式的章节模式规定人员估算必须用表格呈现。可参考的表格骨架角色Role所需技能集人员数量投入周期软件工程师后端 / 前端 / API26 周安全分析师威胁建模 / 渗透测试13 周云架构师AWS / 容器 / 网络14 周项目经理敏捷 / 沟通协调1全程Section 5: Estimated Effort工作量估算这是 LOE 文档的核心章节system.md要求同时做到五点将任务拆解为粒度化的单元granular units如设计design、开发development、测试testing、部署deployment以表格形式按小时、天或 Sprint 给出每个任务的时间估算汇总整个任务或项目的总工作量包含缓冲时间buffer time用于应对不可预见的故障与延误使用T-shirt 尺寸S/M/L/XL或工作量点数effort points对工作复杂度进行分类。一个符合模式要求的估算表示例工作项单元复杂度T-shirt估算人·天说明需求澄清与设计DesignM3含架构评审核心功能开发DevelopmentL10前后端联调单元/集成测试TestingM4含自动化脚本环境搭建与部署DeploymentS2CI/CD 流水线缓冲Buffer—4约 20% 冗余总计——23—从 LifeOS 的角度看T-shirt sizing 是业界通用的复杂度粗粒度分级方法S 对应低风险、单点改动XL 对应高风险、跨团队或未知技术债密集的工作。缓冲比例建议按项目不确定性在 10%25% 之间浮动模式要求显式列出避免看似精确实则无冗余的估算失真。Section 6: Dependencies依赖列出外部依赖例如 API、第三方供应商、内部团队指明可能影响工作量的硬件/软件需求。依赖是工作量超支的主要来源之一第三方 API 的 SLA、内部团队的排期窗口、许可证审批周期都应在此节显式记录。Section 7: Risks Mitigations风险与缓解识别可能影响工作量的技术、安全或运营风险提出缓解策略mitigation strategies明确指出风险是否可能导致工作量超支effort overruns。模式要求对每个风险都给出缓解方案并评估超支可能性这意味着风险表至少应包含风险描述、发生概率/影响、缓解措施、超支影响四列。Section 8: Assumptions Constraints假设与约束列出影响工作量估算的关键假设assumptions识别约束条件例如预算、团队可用性team availability或截止日期deadlines。假设应尽量显式化——例如假定第三方 API 在开发第 2 周即可访问假定团队全职投入——因为任何假设被推翻都会直接改变估算结果。Section 9: Questions Open Items问题与待办事项列出未决问题或需要澄清的事项用于进一步细化 LOE高亮需要干系人进一步输入的领域。这一节使 LOE 文档天然具备评审驱动属性它不是一个封闭结论而是一个待对齐的草案后续评审会议可以围绕 Open Items 展开。五、输出指令模式对产出格式的硬性约束system.md末尾的Output Instructions规定了输出纪律调用时必须遵守以合法 Markdown 格式输出 LOE 文档valid Markdown format不得使用加粗或斜体格式Do not use bold or italic formatting——即章节标题与内容一律使用纯文本 Markdown 结构如#、-、表格表达层级不使用**或*强调不提供评论或免责声明直接执行请求Do not provide commentary or disclaimers, just execute the request——即输出即交付不附带仅供参考以上内容由 AI 生成之类的附加说明。这一约束与 Fabric 模式下其他文档类模式如 create_prd 的 system.md一脉相承所有输出必须结构化、无冗余、可直接进入评审流程。LifeOS 在应用模式时强调Always preserve the patterns specified format for consistency见 ExecutePattern.md因此在 LifeOS 中运行该模式输出格式会被严格保持。六、Input 约定调用时如何提供任务描述system.md的最后一部分是Input占位符Input: [Provide the specific task or project for estimation here]模式要求的输入是一段具体的任务或项目描述。为提高产出质量建议在占位处提供任务背景与目标、涉及的系统/技术栈、约束条件预算、时间、已知依赖与风险、期望的交付形态。输入越结构化九段式文档的填充越贴合实际。在 LifeOS 中触发方式有两条路径原生模式执行推荐按 ExecutePattern 工作流 的 Step 1直接点名模式即可——用户说使用 create_loe_document 估算 XX 任务的工作量LifeOS 会读取Patterns/create_loe_document/system.md并原生应用无需 CLI。用户需求中包含 LOE、work effort、estimation 等意图时模式推荐系统会将该模式列为候选见 suggest_pattern。fabric CLI仅特殊场景只有 YouTube 转写-y与 URL 抓取兜底-u才需要 CLI例如fabric -u URL -p create_loe_document。七、实战扩展将该模式嵌入你的项目交付流程create_loe_document的九段式骨架与 LifeOS 中其他规划类模式可以组合使用构成一条完整的立项 → 估算 → 排期流水线阶段模式产出需求定义create_prd见 system.md产品需求文档明确目标、功能与验收架构设计create_design_document技术方案与 C4 架构工作量估算create_loe_document范围、资源、工期、风险、假设的九段式估算文档敏捷落地create_user_story可排入 Sprint 的用户故事实践建议在 Section 5 中统一口径全项目使用同一种估算单位人·天或 Story Point避免混合口径造成汇总失真缓冲单独成行按 Section 5 要求把 buffer 列为独立工作项而不是悄悄摊入各任务这样评审时超支风险一目了然Open Items 驱动评审把 Section 9 的未决问题作为立项评审Kickoff的必答题逐项关闭后再冻结估算版本化存档LOE 文档建议按版本号归档任何假设或范围变化都升版并重新运行模式保持估算可追溯。八、总结create_loe_document是 LifeOS Fabric 技能中面向工程与业务双场景的实用模式它以软件/云/安全架构专家的身份通过四步推理将一段任务描述加工为覆盖概览、业务影响、范围、资源、工作量、依赖、风险、假设与未决问题九大章节的 Markdown LOE 文档。其输出受三大约束约束——合法 Markdown、禁用加粗/斜体、无附加评论确保文档直接可评审、可引用。在 LifeOS 中原生执行读取 system.md 后直接应用即可获得结构化产出与create_prd、create_design_document等模式组合后可以系统性地覆盖从立项到交付估算的完整闭环。【免费下载链接】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_loe_document 自动生成专业的 Level of Effort（LOE）工作量估算文档
LifeOS Fabric 模式实战用 create_loe_document 自动生成专业的 Level of EffortLOE工作量估算文档【免费下载链接】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在软件、云与网络安全项目中为任务或项目估算工作量Effort、资源与成本往往依赖资深架构师凭经验人工撰写格式不一、颗粒度粗糙、难以对齐干系人预期。LifeOS 的 Fabric 技能内置了 240 个可直接执行的提示词模式Prompt Pattern其中create_loe_document专门用于把一段任务描述转化为结构化、可评审、可复用的 LOELevel of Effort文档。本文将完整解析该模式的系统提示词system.md结构与九段式文档骨架并结合 LifeOS Fabric 技能的原生执行机制与配套工作流给出可直接落地的实战方案。读完本文你将掌握如何调用该模式、理解其九大章节的设计意图并能独立产出一份覆盖范围、业务影响、资源、工期、风险与假设的专业工作量估算文档。一、模式定位create_loe_document 在 Fabric 技能中的角色create_loe_document是 LifeOS 中 Fabric 技能 所管理的众多提示词模式之一。Fabric 技能的核心设计是让 240 个经过验证的专用提示词随手可得用户只需说出模式名称或意图LifeOS 就会直接读取对应模式目录下的system.md并将其作为系统提示词应用到输入内容上全程无需外部 CLI 往返Native Pattern Execution。模式的物理存储路径为 LifeOS/install/skills/Fabric/Patterns/create_loe_document/system.md。每个模式目录的结构约定如下Patterns/ ├── create_loe_document/ │ └── system.md # 该模式的完整提示词指令 ├── create_prd/ │ └── system.md ├── create_design_document/ │ └── system.md └── ...240 patterns从system.md的内容组织看每个模式的提示词通常包含四类要素身份IDENTITY我是谁、目标GOAL要达成什么、步骤STEPS如何处理输入以及输出指令OUTPUT INSTRUCTIONS以什么格式输出create_loe_document完全遵循这一范式。该模式在模式推荐目录中同时被归类为BUSINESS业务与DEVELOPMENT开发两类用途见 LifeOS/install/skills/Fabric/Patterns/suggest_pattern/system.md说明它既能服务于商务侧的立项评估也能支撑工程侧的交付排期。官方描述见 LifeOS/install/skills/Fabric/Patterns/pattern_explanations.mdCreates detailed Level of Effort documents for estimating work effort, resources, and costs for tasks or projects.为任务或项目创建工作量、资源和成本的详细估算文档。二、身份与目标模式期望模型以什么角色工作system.md开篇的Identity and Purpose定义了该模式激活时模型应代入的身份模型被设定为软件、云计算与网络安全架构专家expert in software, cloud, and cybersecurity architecture专长是创建清晰、结构良好的 LOE 文档用于估算给定任务或项目的工作量、资源与成本。Goal部分则规定了输出的总要求给定一个任务或系统的描述后产出覆盖以下维度的详细 LOE 文档范围Scope业务影响Business Impact资源需求Resource Requirements估算工作量Estimated Effort风险Risks依赖Dependencies假设Assumptions这一设定意味着调用该模式时你只需要提供任务描述见文末Input一节模式会自动以架构专家的视角补齐上述工程与业务维度而不是简单回复一段大概要 X 天。三、处理流程模式内部的三步加工逻辑system.md的Steps部分规定了模型处理输入时的顺序共四步彻底分析输入任务确保完全理解Analyze the input task thoroughly to ensure full comprehension梳理任务的全部关键组成部分综合考虑需求、依赖、风险与工作量估算因素Map out all key components…基于组织性质考虑业务优先级与风险偏好Consider business priorities and risk appetite based on the nature of the organization将 LOE 文档拆分为结构化章节以保证清晰与完整Break the LOE document into structured sections。从源码角度看这一处理流程与 ExecutePattern 工作流 的 Step 3Apply Pattern to Content完全对应LifeOS 读取system.md后将其中 IDENTITY / STEPS / OUTPUT INSTRUCTIONS 直接作为提示词应用不调用外部工具。也就是说你看到的三步/四步加工逻辑就是模型实际执行的推理链条——理解这一点有助于你喂养输入时更有针对性描述越完整含目标、约束、团队现状模式产出的 LOE 越贴合实际。四、九段式 LOE 文档骨架核心章节逐段解析这是system.md的主体部分也是你调用该模式后将会得到的文档结构。以下九节必须完整呈现模型需要逐节填写内容。Section 1: Task Overview任务概览对待估算的任务、项目或计划给出高层摘要定义目标与预期成果objectives and expected outcomes识别关键干系人与受益方key stakeholders and beneficiaries。实战提示调用时建议在输入里显式列出干系人如业务负责人、架构师、安全团队、项目经理模式会据此在概览中体现责任归属。Section 2: Business Impact业务影响定义该任务要解决的业务问题列出对组织的预期收益与价值突出业务风险或合规考量regulatory considerations。该节的价值在于把技术估算翻译成业务语言便于管理层决策是否立项。如果任务涉及金融、医疗等强监管场景合规考量应在此节显式标注。Section 3: Scope Deliverables范围与交付物界定范围内与范围外的工作in-scope / out-of-scope拆解主要交付物与里程碑deliverables and milestones明确成功验收标准acceptance criteria。范围描述得越精确后续工作量估算越可靠。模式要求显式列出不在范围内的内容这是防止范围蔓延scope creep的关键手段。Section 4: Resource Requirements资源需求识别所需技能集与角色例如软件工程师software engineers、安全分析师security analysts、云架构师cloud architects、Scrum Master、项目经理project manager等以表格形式估算所需人员数量列出所需的工具、基础设施或许可证tooling, infrastructure, or licenses。这是全文中第一个明确要求tabular format表格格式的章节模式规定人员估算必须用表格呈现。可参考的表格骨架角色Role所需技能集人员数量投入周期软件工程师后端 / 前端 / API26 周安全分析师威胁建模 / 渗透测试13 周云架构师AWS / 容器 / 网络14 周项目经理敏捷 / 沟通协调1全程Section 5: Estimated Effort工作量估算这是 LOE 文档的核心章节system.md要求同时做到五点将任务拆解为粒度化的单元granular units如设计design、开发development、测试testing、部署deployment以表格形式按小时、天或 Sprint 给出每个任务的时间估算汇总整个任务或项目的总工作量包含缓冲时间buffer time用于应对不可预见的故障与延误使用T-shirt 尺寸S/M/L/XL或工作量点数effort points对工作复杂度进行分类。一个符合模式要求的估算表示例工作项单元复杂度T-shirt估算人·天说明需求澄清与设计DesignM3含架构评审核心功能开发DevelopmentL10前后端联调单元/集成测试TestingM4含自动化脚本环境搭建与部署DeploymentS2CI/CD 流水线缓冲Buffer—4约 20% 冗余总计——23—从 LifeOS 的角度看T-shirt sizing 是业界通用的复杂度粗粒度分级方法S 对应低风险、单点改动XL 对应高风险、跨团队或未知技术债密集的工作。缓冲比例建议按项目不确定性在 10%25% 之间浮动模式要求显式列出避免看似精确实则无冗余的估算失真。Section 6: Dependencies依赖列出外部依赖例如 API、第三方供应商、内部团队指明可能影响工作量的硬件/软件需求。依赖是工作量超支的主要来源之一第三方 API 的 SLA、内部团队的排期窗口、许可证审批周期都应在此节显式记录。Section 7: Risks Mitigations风险与缓解识别可能影响工作量的技术、安全或运营风险提出缓解策略mitigation strategies明确指出风险是否可能导致工作量超支effort overruns。模式要求对每个风险都给出缓解方案并评估超支可能性这意味着风险表至少应包含风险描述、发生概率/影响、缓解措施、超支影响四列。Section 8: Assumptions Constraints假设与约束列出影响工作量估算的关键假设assumptions识别约束条件例如预算、团队可用性team availability或截止日期deadlines。假设应尽量显式化——例如假定第三方 API 在开发第 2 周即可访问假定团队全职投入——因为任何假设被推翻都会直接改变估算结果。Section 9: Questions Open Items问题与待办事项列出未决问题或需要澄清的事项用于进一步细化 LOE高亮需要干系人进一步输入的领域。这一节使 LOE 文档天然具备评审驱动属性它不是一个封闭结论而是一个待对齐的草案后续评审会议可以围绕 Open Items 展开。五、输出指令模式对产出格式的硬性约束system.md末尾的Output Instructions规定了输出纪律调用时必须遵守以合法 Markdown 格式输出 LOE 文档valid Markdown format不得使用加粗或斜体格式Do not use bold or italic formatting——即章节标题与内容一律使用纯文本 Markdown 结构如#、-、表格表达层级不使用**或*强调不提供评论或免责声明直接执行请求Do not provide commentary or disclaimers, just execute the request——即输出即交付不附带仅供参考以上内容由 AI 生成之类的附加说明。这一约束与 Fabric 模式下其他文档类模式如 create_prd 的 system.md一脉相承所有输出必须结构化、无冗余、可直接进入评审流程。LifeOS 在应用模式时强调Always preserve the patterns specified format for consistency见 ExecutePattern.md因此在 LifeOS 中运行该模式输出格式会被严格保持。六、Input 约定调用时如何提供任务描述system.md的最后一部分是Input占位符Input: [Provide the specific task or project for estimation here]模式要求的输入是一段具体的任务或项目描述。为提高产出质量建议在占位处提供任务背景与目标、涉及的系统/技术栈、约束条件预算、时间、已知依赖与风险、期望的交付形态。输入越结构化九段式文档的填充越贴合实际。在 LifeOS 中触发方式有两条路径原生模式执行推荐按 ExecutePattern 工作流 的 Step 1直接点名模式即可——用户说使用 create_loe_document 估算 XX 任务的工作量LifeOS 会读取Patterns/create_loe_document/system.md并原生应用无需 CLI。用户需求中包含 LOE、work effort、estimation 等意图时模式推荐系统会将该模式列为候选见 suggest_pattern。fabric CLI仅特殊场景只有 YouTube 转写-y与 URL 抓取兜底-u才需要 CLI例如fabric -u URL -p create_loe_document。七、实战扩展将该模式嵌入你的项目交付流程create_loe_document的九段式骨架与 LifeOS 中其他规划类模式可以组合使用构成一条完整的立项 → 估算 → 排期流水线阶段模式产出需求定义create_prd见 system.md产品需求文档明确目标、功能与验收架构设计create_design_document技术方案与 C4 架构工作量估算create_loe_document范围、资源、工期、风险、假设的九段式估算文档敏捷落地create_user_story可排入 Sprint 的用户故事实践建议在 Section 5 中统一口径全项目使用同一种估算单位人·天或 Story Point避免混合口径造成汇总失真缓冲单独成行按 Section 5 要求把 buffer 列为独立工作项而不是悄悄摊入各任务这样评审时超支风险一目了然Open Items 驱动评审把 Section 9 的未决问题作为立项评审Kickoff的必答题逐项关闭后再冻结估算版本化存档LOE 文档建议按版本号归档任何假设或范围变化都升版并重新运行模式保持估算可追溯。八、总结create_loe_document是 LifeOS Fabric 技能中面向工程与业务双场景的实用模式它以软件/云/安全架构专家的身份通过四步推理将一段任务描述加工为覆盖概览、业务影响、范围、资源、工作量、依赖、风险、假设与未决问题九大章节的 Markdown LOE 文档。其输出受三大约束约束——合法 Markdown、禁用加粗/斜体、无附加评论确保文档直接可评审、可引用。在 LifeOS 中原生执行读取 system.md 后直接应用即可获得结构化产出与create_prd、create_design_document等模式组合后可以系统性地覆盖从立项到交付估算的完整闭环。【免费下载链接】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），仅供参考
