Fabric 中的 LOE 工作量评估文档生成模式：使用 create_loe_document 从任务描述到可量化交付估算-迪斯科星球

Fabric 中的 LOE 工作量评估文档生成模式：使用 create_loe_document 从任务描述到可量化交付估算

【免费下载链接】FabricFabric is an open-source framework for augmenting humans using AI. It provides a modular system for solving specific problems using a crowdsourced set of AI prompts that can be used anywhere.项目地址: https://gitcode.com/GitHub_Trending/fa/Fabric

Fabric 提供了一套可复用的 AI 提示词（Pattern）体系。其中create_loe_document模式让软件、云与网络安全架构师能够基于一段任务或系统描述，自动生成结构化的 Level of Effort（LOE，工作量评估）文档，覆盖范围界定、业务影响、资源配置、工作量估算、风险依赖与假设约束等完整维度。读完本文，你将掌握该模式的文件结构、九段式文档骨架、CLI 调用方式与变量机制，并能直接用它产出一份可复制、可评审的 LOE 报告。

一、该模式在 Fabric 项目中的定位

create_loe_document是 Fabric 内置模式库中的一个提示词文件，正文位于 data/patterns/create_loe_document/system.md。在 Fabric 的模式分类体系中，它同时被归入BUSINESS（业务）与DEVELOPMENT（开发）两个语义标签域（见 data/patterns/suggest_pattern/system.md），并在模式说明文件中被概括为：

"Creates detailed Level of Effort documents for estimating work effort, resources, and costs for tasks or projects."（pattern_explanations.md 第 77 条）

在官方模式描述索引 scripts/pattern_descriptions/pattern_descriptions.json 中，其描述为 "Create detailed Level of Effort (LOE) estimation documents."。也就是说，这个模式的目的非常聚焦：接受一段对任务/系统的描述，输出一份覆盖范围、业务影响、资源需求、工作量估算、风险、依赖与假设的工作量评估文档。

为什么 LOE 文档需要模板化

在交付软件、上云改造、安全合规等售前或项目启动场景中，估算是高频且高度雷同的重复劳动：遗漏范围边界、忘记资源角色、忽视缓冲时间都会导致估算失真。该模式将估算专家的工作方法固化成可复现的提示词结构，保证每次产出都覆盖同样的关键维度，减少凭经验跳跃式估测造成的偏差。

二、模式文件与结构分析

从源码实现看，Fabric 的每个模式实际上就是一个以模式名命名的目录下的system.md文件。加载器在 internal/plugins/db/fsdb/patterns.go 中定义：读取路径为文件存储根目录/<模式名>/system.md，并优先检查用户自定义模式目录（CustomPatternsDir），若存在同名自定义模式则覆盖内置模式（见getFromDB，patterns.go#L124-L170）。因此create_loe_document的正文来源就是上面提到的 data/patterns/create_loe_document/system.md，共 76 行。

该文件的结构遵循 Fabric 模式的通用行文骨架：

Identity and Purpose（身份与目的）：将模型设定为软件、云与网络安全架构专家，专长是创建结构清晰的 LOE 文档，用于估算某个任务或项目所需的工作量、资源与成本。
Goal（目标）：给定一段任务或系统描述后，产出一份详尽的 LOE 文档，覆盖范围、业务影响、资源需求、工作量估算、风险、依赖与假设。
Steps（步骤）：规定四条前置动作——彻底分析输入任务；梳理任务的全部关键组成（需求、依赖、风险、工作量估算因子）；基于组织性质考虑业务优先级与风险偏好；将 LOE 文档切分为结构化章节。
LOE Document Structure（文档骨架）：给出九个标准章节。
Output Instructions（输出指令）：要求以合法 Markdown 输出，不使用加粗/斜体，不加评论或免责声明，直接执行请求。
Input（输入）：以[Provide the specific task or project for estimation here]占位，等待用户粘贴待估算的任务描述。

值得注意的是，该模式正文中并没有出现{{input}}模板占位符。从 Fabric 源码看这是被允许的：ensureInput（patterns.go）会在模式内容不含{{input}}时，自动在文末追加该占位符，随后由applyVariables/applyInput把用户输入替换进去。因此使用体验与其他模式一致——你给出的任务描述会被拼接到模式末尾的 Input 位置。

三、九段式 LOE 文档骨架详解

该模式的核心产出结构共九个章节。下面逐一说明每节应写什么，并给出可直接参考的撰写要点与示例片段（示例内容由模式引导产出，实际以你的任务输入为准）。

Section 1：Task Overview（任务总览）

对正在估算的任务、项目或计划做高层级总结：

一句话描述任务本身（是什么、在什么系统/平台上做）；
定义目标与预期产出（Objectives and expected outcomes）；
识别关键干系人与受益方（Key stakeholders and beneficiaries），例如业务方、IT 运维、最终用户、监管审查方。

这一节的价值在于让评审者不读详细分解也能快速对齐"我们要做什么"。

Section 2：Business Impact（业务影响）

把技术任务翻译成业务语言：

说明该任务要解决的业务问题；
列出对组织的预期收益与价值（如成本节省、合规达标、风险下降、新能力上线）；
高亮潜在的业务风险或合规考量（如数据驻留要求、行业监管、审计条款）。

Section 3：Scope & Deliverables（范围与交付物）

这是防止范围蔓延（scope creep）的关键章节：

分别列出 In-scope（范围内）与 Out-of-scope（范围外）的工作，范围外事项是评审讨论的焦点；
拆解主要交付物与里程碑（Deliverables and milestones）；
明确成功完成的验收标准（Acceptance criteria）。

Section 4：Resource Requirements（资源需求）

界定需要哪些角色与数量，以及配套工具：

列明所需技能与角色。模式原文档点名的角色包括：软件工程师（software engineers）、安全分析师（security analysts）、云架构师（cloud architects）、Scrum Master、项目经理（project manager），实际可按任务增删；
用表格估算所需人员数量（模式原文档明确要求in tabular format）；
列出所需的工具、基础设施或许可证（Tooling, infrastructure, or licenses）。

角色与数量的示例表格结构如下（数字仅为示意，需按任务输入填写）：

角色	职责简述	建议人数	参与阶段
云架构师	方案设计与架构评审	1	设计 / 评审
软件工程师	功能开发与集成	2–3	开发 / 测试
安全分析师	威胁建模与安全评审	1	全程
项目经理	排期、沟通与风险管理	1	全程

Section 5：Estimated Effort（工作量估算）

这是整个 LOE 文档的数据核心，也是评审者最先质疑的部分：

将任务分解为粒度更小的单元，例如设计、开发、测试、部署（Design / Development / Testing / Deployment）；
以小时、天或 Sprint 为单位给出每个任务的时间估算，模式原文档同样明确要求in tabular format；
汇总整个任务或项目的总工作量；
为不可预见的问题或延误加入缓冲时间（buffer time）；
使用 T 恤尺码 S/M/L/XL 或工作量点数（effort points）对工作复杂度分级。

每个工作项建议同时给出下限/上限/最可能三种估算并注明计量单位，例如：

工作项	复杂度	估算（人·天）	说明
需求澄清与方案设计	M	3	含与业务方对齐范围
开发实现	L	10	按模块拆分后汇总
测试与验收	M	4	含回归与 UAT 支持
部署与上线	S	2	含变更窗口与回滚预案
缓冲	—	3（约 16%）	应对人员请假/集成问题

Section 6：Dependencies（依赖）

识别会左右工期与方案的外部约束：

列出外部依赖：API、第三方厂商、内部团队、评审或审批流程；
指明可能影响工作量的硬件/软件需求，例如专有设备采购周期、目标平台版本、许可证申请时限。

Section 7：Risks & Mitigations（风险与缓解）

说明不确定性并给出预案：

识别可能影响工作量的技术、安全或运营风险；
为每个风险提出缓解策略；
明确指出哪些风险可能导致工作量超支（effort overruns），让管理层对不确定性有预期。

Section 8：Assumptions & Constraints（假设与约束）

任何估算都建立在假设之上，显式列出它们才能让估算可被审计：

列出影响估算的关键假设（如"假设关键人员全周期可用""假设第三方 API 文档完备"）；
识别约束：预算、团队可用性、截止日期、合规窗口等。

Section 9：Questions & Open Items（待办问题与未决事项）

让 LOE 保持"可推进"的状态：

列出为细化 LOE 仍需澄清的问题；
标出需要干系人进一步输入的区域，例如尚未确定的方案选项、等待供应商报价的环节。

输出格式约定

模式明确要求：以合法 Markdown 输出；不要使用加粗或斜体（这正是原文档全篇为纯文本列表的原因）；不要添加评论或免责声明，直接产出文档。若你期望标题层级加粗，可在产出后按团队规范手工调整，而模式本身倾向于中立、可机器解析的纯文本结构。

四、在 Fabric 中调用该模式

4.1 查看模式内容

在命令行直接打印该模式的完整提示词：

fabric --readpattern create_loe_document

源码中ReadPattern旗标即"打印指定模式的原始内容"（见 internal/cli/flags.go），其底层实现PrintPattern读取目录下的system.md并输出到终端（patterns.go）。

4.2 用 stdin 提供任务描述

cat task_description.txt | fabric --pattern create_loe_document

-p/--pattern旗标用于指定模式名（flags.go）。你输入的任务描述会由运行管线填入模式末尾的输入位置。若命令行未提供消息文本，Fabric 支持从 stdin 读取输入，便于与cat、管道或 CI 输出串联。

4.3 结合会话与上下文

--session <名称>：将产出存入会话，便于后续追问、修订某一节或与其他模式输出串联；
--context <文本>：附加上下文（如团队既有估算规范、过往项目数据），让估算口径更贴近组织实际；
通过-v/--variable传模板变量（如-v=#role:security_lead），Fabric 会先解析变量再做{{input}}替换（见applyVariables，patterns.go）。

4.4 管理自定义版本

如果你希望固化自己团队的估算模板，可在用户自定义模式目录下创建同名目录与system.md，例如~/.config/fabric/patterns/create_loe_document/system.md。由于加载器总是优先读自定义目录（getFromDB，patterns.go#L135-L145），你可以不改动仓库、直接覆盖内置版本，或用fabric --updatepatterns同步官方模式库后再叠加本地定制。

4.5 典型输入样例

把下面的任务描述（示例）喂给该模式，可得到一页完整的九节 LOE 文档：

"Design and implement single sign-on (SSO) integration with Azure AD for a 200-person SaaS platform, including session management, role mapping, audit logging, and a 2-week migration of existing users, within a 6-week budget."

模式会据此自动产出任务总览、业务影响、范围边界（含范围外项，如非 AzureAD 联邦）、角色表（云架构师/后端工程师/安全分析师/PM）、按设计—开发—测试—部署分解的估算表与缓冲、对身份提供方与审批的依赖清单、令牌/会话相关风险与缓解、假设约束及待澄清问题。

五、适用场景、注意点与延伸阅读

适用场景

项目立项前的初步估算，快速判断"值不值得做、大概要多少人/多久"；
售前 PoC 或交付报价前的内部工作量摸底；
将粗粒度需求翻译成可评审的交付范围与里程碑，支撑排期决策；
安全/上云改造等跨职能任务的多角色对齐。

使用注意点

该模式提供的是估算框架与行文规范，不是精确计算器；请以任务输入质量为先，输入越接近真实约束（团队规模、技术栈、合规要求），产出越可用；
原文档要求输出纯 Markdown、不使用粗斜体、不加评论，这有助于下游直接转存或二次处理，但也意味着表格与标题的排版可能需按团队文档规范微调；
把 5、7、9 节当作评审重点：总工作量、缓冲占比、风险是否导致超支、遗留问题清单，是管理层最关心的四个抓手。

企业官网建设流程全解析