Function Decomposition Methods

导言

功能分解的目标，是把“提升训练问题定位效率”这类高层目标，逐层转成可以独立实现、独立验证、能够追溯业务价值的子功能。真正困难的不是把一个大框画成很多小框，而是保持三种关系清楚：功能树表达“由什么组成”，依赖图表达“先有谁、后有谁”，验收契约表达“怎样证明做到了”。

本文用同一条训练诊断链路比较五种常用方法：功能树、WBS、FAST 功能分析、能力地图和 Feature Breakdown Structure。核心原则是：先按用户能力和业务价值拆“做什么”，再按架构与代码模块分配“由谁实现”。

先把目标改写成能力

NASA 将功能分解定义为：检查一个功能，识别完成它所必需的子功能，以及这些功能之间的关系与接口。其逻辑分解过程首先识别系统在每一层“应该实现什么”，再把父级需求下推成更详细的功能要求。[^nasa-logical][^nasa-handbook]

因此，“提升训练问题定位效率”仍然是结果目标，不是叶子功能。它至少还缺少用户、触发条件、输入、行为、输出和验收证据。功能分解就是把这块难以直接交付的目标，切成团队可以拿起来实现和验证的能力块。

{ width=96% }

自绘认知锚点：拆分的终点不是“文件更小”，而是每一块能力都有明确边界，并能用证据判断是否完成。

用户给出的链路可以先改写成两张不同的图。第一张是包含关系：

目标：提升训练问题定位效率
├── 证据获取能力
│   ├── 完整采集各 Rank 日志
│   ├── 保存训练配置快照
│   └── 关联关键监控指标
├── 证据标准化能力
│   ├── 聚合多 Rank 日志
│   └── 对齐异常时间线
├── 问题诊断能力
│   ├── 识别首错
│   ├── 区分首错与连锁报错
│   └── 分类候选根因
└── 诊断交付能力
    ├── 生成诊断报告
    └── 提供证据链接与处置建议

第二张才是依赖关系：

完整采集 -> 多 Rank 聚合 -> 时间线对齐 -> 首错识别 -> 根因分类 -> 诊断报告

两张图可以包含相同节点，但不能混为一谈。树回答“整体由哪些能力组成”；箭头链回答“一个功能依赖哪个上游产物”。如果把所有父子边都画成先后箭头，读者会误以为“采集、聚合、报告”只是顺序步骤，看不到配置快照、指标关联、异常分支等并列能力。

一个可交付的叶子功能，至少应写成下面的契约：

字段	示例
用户与场景	训练工程师在分布式作业失败后发起诊断
输入	job_id、Rank 列表、日志 URI、时钟偏移元数据
行为	采集所有可达 Rank 的 stdout、stderr 与结构化事件
输出	带 Rank、节点、时间戳和来源的标准日志记录集
验收	所有存活 Rank 均有日志；缺失 Rank 被显式列出；重复上传可幂等处理
异常	日志源不可达时返回来源、重试次数和最终状态
依赖	作业元数据服务、对象存储、身份认证
Owner	可观测性团队负责能力契约，采集代理只是一个实现分配

代码结构不是第一分解轴

按 collector/、aggregator/、timeline/、reporter/ 拆代码，最多说明实现被放在哪里，不能证明用户已经获得完整诊断能力。一个用户功能可能跨多个服务，一个服务也可能支撑多个功能。正确顺序是目标 -> 能力 -> 功能 -> 特性 -> 工作包 -> 模块分配。

功能树

机制与对象

问题快照：目标只有一句话，团队便直接开始列服务、页面和算法，导致同级节点混入“能力、组件、动作、团队和里程碑”，既无法检查漏项，也无法向上解释价值。

一句话直觉：功能树像一张“做什么”的目录，把父功能递归分成同一抽象层级的子功能，直到叶子能够写出独立验收契约。

本文所说的功能树，是 NASA 式功能分解的树形表达，不是声称存在一套独立且统一的国际图形标准。三层边界如下：

• 概念：为完成父目标，系统必须具备哪些功能？
• 可复用机制：建立父子包含关系，保持兄弟节点同一分解口径，并另行记录接口与依赖。
• 本文落地：把训练诊断分成证据获取、标准化、诊断和交付四个能力域，再继续分到可验证叶子。

对象	标识	生产者	结构	消费者	生命周期
结果目标	goal	Stakeholder	Goal[metric, target, timebox]	根功能、追溯矩阵	随目标版本存在
父功能	parent_function	功能分析	Function[verb, object, purpose]	子功能分解	设计基线
子功能	child_functions	递归分解	Set[Function]	覆盖检查、叶子契约	设计基线
功能接口	interfaces	兄弟关系分析	Set[producer, artifact, consumer]	依赖图、集成测试	随接口版本存在
叶子契约	leaf_contract	产品、研发、测试	Contract[input, behavior, output, acceptance]	实现与验收	发布基线
追溯关系	traceability	对账步骤	goal -> function -> test	变更影响分析	持续维护

伪代码与五视图

下面的伪代码是建模过程，不是运行时代码。decompose_by_user_outcome 必须使用用户结果作为主轴；代码模块只能在叶子功能稳定后进入 allocate_implementation。

function build_function_tree(goal, scenarios, constraints):
    root = Function(verb="提供", object=goal.user_outcome, trace_to=goal)
    queue = [root]
    tree = Tree(root)
    dependency_edges = Set()

    while queue is not empty:
        parent_function = queue.pop_front()
        child_functions = decompose_by_user_outcome(
            parent_function,
            scenarios,
            constraints
        )

        assert same_abstraction_axis(child_functions)
        assert each_child_contributes_to(child_functions, parent_function)
        assert combined_children_cover_parent(child_functions, parent_function)

        for child_function in child_functions:
            tree.add_child(parent_function, child_function)
            interfaces = identify_inputs_outputs_and_exceptions(child_function)
            dependency_edges.add_all(derive_dependencies(interfaces))

            if can_define_independent_acceptance(child_function, interfaces):
                leaf_contract = attach_leaf_contract(
                    function=child_function,
                    interfaces=interfaces,
                    acceptance=derive_acceptance_from_scenario(child_function, scenarios),
                    owner=assign_capability_owner(child_function)
                )
                tree.attach(child_function, leaf_contract)
            else:
                queue.push_back(child_function)

    assert no_code_module_is_primary_function(tree)
    assert every_leaf_traces_to_goal(tree, goal)
    assert every_dependency_has_named_artifact(dependency_edges)
    return tree, dependency_edges

{ width=96% }

自绘五视图：重点看 A 中混杂列表如何变成同口径父子功能，C 中何时停止递归，D 中谁确认边界，以及 E 中目标如何流向可验证叶子契约。

适用性与边界

• 适合：系统功能架构、需求分解、复杂产品范围梳理、测试覆盖设计。
• 优势：向上能解释业务价值，向下能连接接口、特性、工作包和测试。
• 劣势：树只能自然表达一个主包含轴；跨分支依赖、时序和共享能力必须另建关系图。
• 实现归属：产品或系统分析 Owner 维护父子语义，能力 Owner 维护叶子契约，架构师再把功能分配给组件。
• 迁移成本：换技术栈时功能树通常可以保留，但组件分配、接口约束和非功能指标需要重新校验。
• 效果契约：它减少的是功能范围与验收歧义，新增成本是模型、追溯和变更同步；应以漏项率、返工原因和验收争议衡量，不应直接声称缩短训练时间。

WBS

机制与对象

问题快照：功能已经明确，但项目仍以零散任务清单管理。设计、开发、测试、文档和上线工作互相重叠，成本、进度和责任无法汇总到一个稳定交付物。

一句话直觉：WBS（Work Breakdown Structure，工作分解结构）把已批准的总范围按产品和交付物逐层拆成可计划、可授权、可跟踪的工作包。

美国能源部 WBS 手册明确采用产品导向结构来组织和细分项目总范围；不同层级应汇总回项目总范围，并用 WBS Dictionary 说明每个元素的范围。手册还把“按职能经理、专业或跨多个产品的活动建立 WBS 元素”列为常见错误。[^doe-wbs]

这意味着 WBS 与功能树不是竞争关系：

• 功能树先回答“系统必须做什么”。
• WBS再回答“为了交付这些能力，完整项目范围包含哪些交付物和工作包”。
• “日志聚合能力”可以映射到采集代理、聚合服务、契约测试、迁移文档和上线演练等多个 WBS 元素。

对象	标识	生产者	结构	消费者	生命周期
授权范围	authorized_scope	项目章程、功能基线	Scope[deliverables, exclusions]	顶层 WBS	项目基线
交付物	deliverable	产品与工程规划	Deliverable[outcome, acceptance]	子元素分解	项目阶段
WBS 元素	wbs_element	交付物分解	Element[id, parent, scope]	计划、成本、进度	项目生命周期
工作包	work_package	控制粒度判断	Package[owner, output, estimate]	执行与跟踪	执行周期
WBS 字典	dictionary_entry	范围定义	Entry[content, boundary, acceptance]	授权、变更控制	持续更新
范围校验	coverage_check	WBS 评审	Set[missing, overlap, orphan]	基线决策	评审周期

伪代码与五视图

function build_wbs(authorized_scope, deliverables, reporting_constraints):
    root = WbsElement(id="1", scope=authorized_scope)
    queue = [root]
    dictionary = Map()

    while queue is not empty:
        parent = queue.pop_front()
        children = decompose_by_product_or_deliverable(parent, deliverables)

        assert children_are_product_or_deliverable_oriented(children)
        assert children_sum_to_parent_scope(children, parent)
        assert no_child_is_only_department_or_cost_category(children)

        for child in children:
            root.attach(parent, child)
            dictionary[child.id] = define_scope_entry(
                content=child.scope,
                exclusions=derive_exclusions(child, authorized_scope),
                acceptance=derive_deliverable_acceptance(child),
                trace_to=map_to_functions(child, deliverables)
            )

            if requires_lower_control_level(child, reporting_constraints):
                queue.push_back(child)
            else:
                work_package = assign_work_package(
                    element=child,
                    owner=single_accountable_owner(child),
                    estimate=estimate_cost_and_schedule(child),
                    risks=identify_delivery_risks(child)
                )
                dictionary[child.id].attach(work_package)

    assert covers_authorized_scope(root, authorized_scope)
    assert no_scope_overlap_without_explicit_allocation(root)
    return root, dictionary

{ width=96% }

自绘五视图：A 与 E 展示总范围如何变成工作包和 WBS 字典；D 强调 Sponsor、计划者和交付团队围绕范围、基线、成本与变更协作。

适用性与边界

• 适合：范围基线、成本与进度控制、采购交付、跨团队大型项目。
• 优势：容易连接预算、进度、责任和风险，能检查授权范围是否完整落地。
• 劣势：如果在理解用户能力之前使用，团队很容易得到一棵“开发活动树”，却交付不了完整用户结果。
• 实现归属：项目经理维护 WBS 与字典，产品/系统 Owner 确认其与功能和交付物的映射。
• 迁移成本：范围或采购边界改变会重构 WBS；单纯更换内部算法未必改变顶层交付物。
• 效果契约：它减少的是范围、责任、成本和进度的失配；新增成本是控制粒度、字典和变更审批。效果应由范围漏项、计划偏差和未授权工作衡量。

FAST 功能分析

机制与对象

问题快照：团队把“ELK 日志平台”“时间线数据库”“LLM 根因模型”写成功能，讨论很快被当前方案锁死；当方案变化时，整个功能结构也随之失效。

一句话直觉：FAST（Function Analysis System Technique）先用简洁的“动词—名词”描述功能，再持续追问“怎样做到”和“为什么需要”，把方案名还原成功能逻辑。

SAVE International 将功能描述为项目、产品或过程为了满足客户需要必须做的事，强调“做什么”独立于“它是什么”和“如何实现”；FAST 则用 HOW-WHY 逻辑组织功能的依赖关系。[^save-guide][^save-glossary]

在训练诊断案例中，可以把方案词改写成功能词：

不推荐	推荐	原因
ELK 平台	聚合日志	平台只是候选实现
时间线数据库	对齐事件	数据库不能说明用户获得什么结果
LLM 诊断	分类根因	算法类型不等于功能边界
提升效率	缩短定位时间	前者是笼统目标，后者才可连接度量

FAST 横向链可以这样读：

WHY <----------------------------------------------------------> HOW
缩短定位时间 <- 识别首个因果信号 <- 对齐异常时间线 <- 聚合多 Rank 日志

从右向左问“为什么聚合日志”，答案是为了对齐异常时间线；从左向右问“怎样缩短定位时间”，答案之一是识别首个因果信号。这是一条功能逻辑，不是运行时序保证；并行、等待、异常和循环仍应由流程图、状态机或时序图表达。

对象	标识	生产者	结构	消费者	生命周期
研究边界	study_scope	客户与引导师	Scope[object, start, end]	功能发现	研讨基线
功能语句	function_statement	跨职能团队	Function[active_verb, measurable_noun]	分类与连接	随图版本存在
基本功能	basic_function	价值判断	Function	价值改进重点	研究周期
次级功能	secondary_function	功能发现	Function[classification]	HOW-WHY 图	研究周期
HOW-WHY 边	how_why_edge	追问与验证	Edge[source, relation, target]	逻辑走查	随图版本存在
评价指标	function_measure	客户与团队	Measure[cost, performance]	方案比较	决策周期

伪代码与五视图

function build_fast(study_scope, customer_needs, candidate_elements):
    function_statements = Set()

    for element in candidate_elements:
        statement = rewrite_as_active_verb_and_measurable_noun(
            element,
            independent_of_current_solution=true
        )
        assert statement.verb_is_active
        assert statement.noun_can_receive_a_measure
        function_statements.add(statement)

    basic_function = select_basic_function(
        function_statements,
        customer_needs,
        study_scope
    )
    classified_functions = classify_functions(
        function_statements,
        basic_function,
        study_scope
    )

    graph = DirectedGraph()
    for function in classified_functions:
        how_answers = ask_how_is_this_function_achieved(function, classified_functions)
        for how_function in how_answers:
            graph.add_edge(function, relation="HOW", target=how_function)

        why_answers = ask_why_is_this_function_needed(function, classified_functions)
        for why_function in why_answers:
            graph.add_edge(function, relation="WHY", target=why_function)

    assert every_how_edge_has_consistent_inverse_why(graph)
    assert boundary_functions_match_study_scope(graph, study_scope)
    assert no_solution_name_is_unexamined_function(graph)
    return graph, attach_cost_and_performance_measures(graph)

{ width=96% }

自绘五视图：B 展示“方案限制创新”如何通过动词—名词和 HOW-WHY 逻辑被解除；E 展示从需求与对象到经验证 FAST 逻辑的制品路径。

适用性与边界

• 适合：方案替代、价值工程、成本优化、复杂系统功能关系梳理、跨专业研讨。
• 优势：迫使团队暂时放下当前组件和技术名，暴露真正功能、缺失关系与替代实现空间。
• 劣势：依赖高质量引导和跨职能知识；大图容易出现一词多义、循环和伪因果。
• 实现归属：FAST 引导师维护规则，客户确认基本功能与边界，跨职能团队共同验证 HOW-WHY 关系。
• 迁移成本：实现方案改变时功能逻辑可以保留，但函数度量、成本分配和边界条件需要重评。
• 效果契约：它减少的是方案锁定和功能逻辑歧义，代价是研讨与模型校验；价值提升必须用受控方案比较证明，不能从图本身推导。

能力地图

机制与对象

问题快照：路线图按项目、团队和系统列清单。同一种日志诊断能力在多个平台重复建设，另一些战略能力却没有任何项目支撑。

一句话直觉：能力地图先稳定描述“组织或产品必须有能力做什么”，再把当前系统、流程、人员和投资映射到这些能力上。

The Open Group 的架构工具箱把业务能力描述为执行某项业务功能的能力，强调用“必须做什么”命名，并记录层级、定义、责任和上级对象。[^open-group-capability] 能力地图通常比项目和系统稳定，因为项目会结束、系统会替换，而“训练证据管理”“异常诊断”“诊断交付”等能力仍然存在。

三层边界如下：

• 概念：一个组织或产品必须稳定具备哪些能力？
• 可复用机制：建立能力域和层级，去重命名，评估当前/目标成熟度，再映射系统、Owner 与投资。
• 本文落地：用证据获取、证据标准化、问题诊断、诊断交付覆盖训练问题定位，而不是先列日志服务和报告页面。

对象	标识	生产者	结构	消费者	生命周期
战略结果	strategic_outcomes	业务负责人	Set[Outcome, Measure]	能力识别	战略周期
能力	capability	业务架构/产品	Capability[name, definition, level]	能力地图	稳定版本化
支撑关系	support_map	架构与组织盘点	Map[capability -> people/process/system]	差距分析	盘点周期
当前成熟度	current_level	证据评估	Assessment[level, evidence]	差距计算	评估窗口
目标成熟度	target_level	战略决策	Target[level, deadline]	投资规划	规划周期
能力差距	capability_gap	当前/目标对比	Gap[delta, evidence, risk]	优先级决策	规划周期

伪代码与五视图

function build_capability_map(strategic_outcomes, scenarios, current_landscape):
    capability_candidates = Set()

    for scenario in scenarios:
        required_abilities = extract_stable_abilities(
            actor=scenario.actor,
            outcome=scenario.outcome,
            independent_of=scenario.current_system
        )
        capability_candidates.add_all(required_abilities)

    capabilities = normalize_names_and_remove_duplicates(capability_candidates)
    hierarchy = group_by_stable_business_meaning(capabilities)

    for capability in hierarchy:
        capability.definition = define_without_project_or_system_name(capability)
        capability.owner = assign_business_or_product_owner(capability)
        capability.support = map_people_process_information_and_systems(
            capability,
            current_landscape
        )
        capability.current_level = assess_current_level(capability.support)
        capability.target_level = derive_target_level(capability, strategic_outcomes)
        capability.gap = compare_with_evidence(
            capability.current_level,
            capability.target_level
        )

    assert sibling_capabilities_use_same_granularity(hierarchy)
    assert every_strategic_outcome_has_capability_support(hierarchy, strategic_outcomes)
    return hierarchy, prioritize_gaps_by_value_risk_and_evidence(hierarchy)

{ width=96% }

自绘五视图：A 展示项目/系统清单如何转成稳定能力版图；D 与 E 展示业务、架构、投资和交付如何围绕能力差距形成闭环。

适用性与边界

• 适合：战略到技术对齐、产品线规划、重复建设识别、能力成熟度与投资组合讨论。
• 优势：对组织调整和技术替换不敏感，适合建立长期导航入口。
• 劣势：过度抽象后会停留在“具备某能力”的名词墙，无法直接指导接口、异常处理和验收。
• 实现归属：业务或产品 Owner 负责定义能力价值，架构团队维护支撑关系，投资与交付负责人维护差距证据。
• 迁移成本：系统更换主要改变支撑映射；战略结果变化才更可能改变顶层能力边界。
• 效果契约：它减少的是战略、投资与系统之间的错位，代价是统一词汇、成熟度证据和治理；应以重复投资、未支撑能力和差距关闭情况衡量。

Feature Breakdown Structure

机制与对象

问题快照：能力地图已经指出“需要训练问题诊断能力”，但这仍然无法直接进入迭代。若 Backlog 继续按后端、前端、数据库和算法组件堆放，用户价值与验收会再次断开。

一句话直觉：FBS（Feature Breakdown Structure，特性分解结构）把产品能力拆成用户可感知、可独立验收、可进入发布计划的特性和子特性。

Highsmith 在 Agile Project Management 中用 FBS 表达软硬件产品架构，强调它在客户和开发团队之间沟通，并形成用于发布与迭代计划的特性 Backlog。[^highsmith-fbs] 例如训练诊断产品可以拆成：

训练诊断工作台
├── 全 Rank 日志视图
│   ├── 缺失 Rank 提示
│   └── 按 Rank/节点筛选
├── 异常时间线
│   ├── 跨节点时钟校正
│   └── 异常区间折叠
├── 首错面板
│   ├── 首错与连锁错误区分
│   └── 原始证据跳转
├── 根因建议
│   ├── 分类与置信边界
│   └── 处置建议链接
└── 诊断报告
    ├── 一键生成
    └── 导出与分享

FBS 的证据边界

FBS 的行业层级命名并不统一。本文采用 Highsmith 的“产品架构 + 特性待办”含义，不把 FBS 宣称为 Scrum 的正式工件，也不要求所有团队固定使用 Epic -> Feature -> Story -> Task。真正需要稳定的是用户、行为、价值和验收条件。

对象	标识	生产者	结构	消费者	生命周期
用户结果	user_outcome	用户研究、能力地图	Outcome[user, context, value]	顶层特性	产品周期
特性	feature	产品分解	Feature[user, behavior, value]	子特性、发布规划	Backlog 生命周期
子特性	subfeature	行为切片	Feature[bounded behavior]	验收与实现	迭代周期
验收条件	acceptance	Product、QA、研发	Set[precondition, action, result]	测试与发布门禁	随特性版本存在
依赖	dependency	跨特性分析	Edge[predecessor, artifact, successor]	排序、风险	持续维护
发布候选	release_candidate	优先级与可行性决策	Set[Feature]	迭代计划	发布周期

伪代码与五视图

function build_fbs(user_outcomes, capability_map, constraints):
    root_features = derive_user_visible_features(user_outcomes, capability_map)
    fbs = Forest(root_features)
    dependencies = Set()

    for root_feature in root_features:
        queue = [root_feature]

        while queue is not empty:
            feature = queue.pop_front()
            slices = split_by_user_behavior_and_independent_value(feature, constraints)

            if slices is empty:
                acceptance = define_acceptance(
                    user=feature.user,
                    preconditions=feature.preconditions,
                    behavior=feature.behavior,
                    observable_result=feature.user_value,
                    exceptions=feature.exceptions
                )
                feature.attach(acceptance)
                dependencies.add_all(derive_feature_dependencies(feature))
            else:
                assert every_slice_preserves_user_value(slices, feature)
                assert sibling_slices_use_same_behavior_axis(slices)
                for slice in slices:
                    fbs.add_child(feature, slice)
                    queue.push_back(slice)

    assert every_leaf_has_acceptance(fbs)
    assert no_leaf_is_only_component_or_team_name(fbs)
    release_candidates = prioritize_by_value_risk_dependency_and_effort(
        fbs,
        dependencies
    )
    return fbs, dependencies, release_candidates

{ width=96% }

自绘五视图：C 展示从用户结果到发布候选的分解步骤；D 强调用户、Product、开发与 QA 之间围绕价值、验收、依赖和结果反复校准。

适用性与边界

• 适合：产品特性架构、Backlog 整理、发布切片、客户—研发沟通。
• 优势：把抽象能力变成用户能看见、能使用、能验收的增量，便于排序与发布。
• 劣势：若特性只按界面页面或组件命名，仍会失去跨端到端行为；依赖过多时树结构也会失真。
• 实现归属：Product Owner 维护用户价值和特性层级，研发与 QA 共同确认可行性、依赖和验收条件。
• 迁移成本：后端替换通常不应改写用户特性；交互、能力边界或发布策略改变时需要重新切片。
• 效果契约：它减少的是 Backlog 与用户价值、验收之间的断裂，代价是持续切片和依赖维护；应以特性验收通过率、跨迭代返工和价值交付周期衡量。

五种方法如何选择

五种方法都可以画成树，但被分解的对象不同。先问当前最缺哪一种确定性，再选工具：

方法	核心问题	主分解轴	主要产物	合适的停止点	最常见误用
功能树	系统必须做什么	父功能 -> 子功能	功能层级、接口、叶子契约	叶子可独立实现和验证	用代码目录当功能树
WBS	完整项目范围怎样交付与控制	交付物 -> 工作包	WBS、WBS 字典	可授权、估算和跟踪	在需求未清时先列开发任务
FAST	功能之间怎样/为什么关联	HOW-WHY 逻辑	功能语句、逻辑图、度量	逻辑边界可双向走查	把 HOW-WHY 当运行时序
能力地图	长期需要具备什么能力	能力域 -> 能力层级	能力版图、成熟度、差距	能支持战略与投资决策	只做稳定名词墙，不落支撑证据
FBS	哪些用户特性进入产品和发布	产品特性 -> 子特性	特性树、验收、发布候选	叶子能独立验收和排序	固定套 Epic/Story 层级或按组件拆

它们最常见的组合不是“五选一”，而是：

结果目标
-> 能力地图：确认长期能力范围与差距
-> 功能树：定义系统必须做什么
-> FAST：检查关键功能的 HOW-WHY 关系与替代空间
-> FBS：转成用户可感知、可验收的产品特性
-> WBS：转成完整交付物、工作包、成本与进度控制

同一节点允许出现在多张图

“首错识别”可以同时是能力地图中的能力、功能树中的子功能、FAST 中的功能语句、FBS 中的用户特性，也可以映射到 WBS 的多个交付物。关键不是强迫每张图节点唯一，而是为每个节点注明它此刻扮演的模型角色，并维护可追溯关系。

从目标到可验证子功能

一套可执行的功能分解流程可以按下面七步进行。

1. 定义结果而不是方案。 写清用户、问题、基线、目标值和时间窗。例如把“提升定位效率”改成“将 P50 可用诊断结论时间从 45 分钟缩短到 10 分钟以内”，同时保留 P95 和误诊率约束。
2. 固定场景与边界。 列出触发、输入、期望结果、异常和不做事项。区分训练失败、性能劣化、精度异常和基础设施告警，避免一个目标吞掉所有诊断场景。
3. 画能力地图。 先识别证据获取、标准化、诊断、交付等稳定能力域，并标记当前/目标差距和 Owner。
4. 建立功能树。 对每个能力域按用户结果向下拆，保持兄弟节点同一抽象层级；把包含关系放进树，把先后依赖放进单独的依赖图。
5. 用 FAST 追问关键链。 对方案味很重或关系含糊的节点改写“动词—名词”，用 HOW-WHY 双向检查是否缺功能、伪因果或过早绑定实现。
6. 生成 FBS 与 WBS。 把功能映射成用户可感知特性和验收条件，再把已批准范围映射成交付物、工作包、成本、进度和责任。
7. 建立追溯并反向走查。 从每个测试向上找到特性、功能、能力和结果目标；再从目标向下检查是否存在没有实现、没有测试或没有 Owner 的孤儿节点。

训练诊断案例的最小追溯表可以是：

目标	能力	功能	特性	工作包	验收证据
G-01 缩短可用诊断时间	C-02 证据标准化	F-07 对齐异常时间线	FE-04 跨节点时间线	WP-12 时钟校正与排序交付	受控时钟漂移数据集上的顺序正确率
G-01	C-03 问题诊断	F-09 识别首错	FE-06 首错面板	WP-16 规则/模型与证据跳转	标注故障集上的首错命中率、误报率
G-01	C-04 诊断交付	F-12 生成报告	FE-10 一键诊断报告	WP-21 报告模板、导出与权限	报告完整性、生成时延、权限测试

依赖图必须为箭头命名。例如 F-07 -> F-09 的边不是模糊的“依赖”，而是“输出经校正的事件序列，供首错识别消费”。只有命名了中间产物，接口测试和失败定位才有落点。

可复用分解提示词

你是一名产品与系统分析师。请把下面的高层目标分解为可实现、可验证的子功能。

输入：
- 高层目标：<目标>
- 用户与场景：<用户、触发、期望结果>
- 约束：<范围、性能、合规、资源、不做事项>

要求：
1. 先判断输入是结果目标、能力、功能、特性、工作包还是代码模块。
2. 先按用户能力和业务价值画能力地图，再画功能树；不要按服务、包、类或团队拆分。
3. 功能树只表达包含关系；另列依赖边，并为每条边命名传递的产物。
4. 对关键链使用 FAST 的 HOW-WHY 追问，并把方案名改写为“动词 + 名词”的功能语句。
5. 为每个叶子功能写明：用户、触发、输入、行为、输出、异常、验收、依赖、Owner。
6. 把叶子功能映射成 FBS 特性与验收，再映射成 WBS 交付物和工作包。
7. 输出目标 -> 能力 -> 功能 -> 特性 -> 工作包 -> 测试的追溯表。
8. 标出漏项、重叠、抽象层级混杂、代码模块化拆分和不可独立验证的节点。

输出顺序：结论、能力地图、功能树、FAST 关键链、依赖图、叶子契约、FBS、WBS、追溯表、风险与待确认项。

拆到什么粒度

功能分解不是越细越好。拆得太粗，叶子仍不可实现；拆得太细，树会退化成函数调用和工单列表。合适的停止点，是团队能在不猜业务含义的情况下给出实现方案，并由测试或运营证据独立判断是否满足契约。

叶子功能通过下面七项检查时，通常可以停止：

1. 单一结果：它只承诺一个明确用户或系统结果，而不是“采集、分析并展示一切”。
2. 输入输出明确：关键对象、来源、格式和消费者可以命名。
3. 异常可描述：缺失、重复、乱序、超时、权限失败等边界有明确行为。
4. 验收可观察：成功、失败和质量阈值都有证据，不依赖“感觉可用”。
5. 主责唯一：允许多人参与，但只有一个能力契约 Owner。
6. 依赖显式：上游功能、传递产物和阻塞条件可追踪。
7. 实现中立：替换数据库、模型或服务时，用户结果与验收通常仍然成立。

一个典型的伪叶子

“实现日志聚合服务”看起来已经很具体，实际上只写了技术方案。它没有说明支持哪些日志源、如何处理缺失 Rank、时间戳冲突怎样解决、输出由谁消费、怎样验收。更好的叶子是“在一个 job_id 下输出所有可达 Rank 的标准事件流，并显式报告缺失来源、重复记录和时钟校正状态”。

功能不要求都能独立部署，但必须能独立说明和验证。如果一个叶子只能通过另一个叶子的私有实现细节才能解释，说明边界或接口仍需调整。

质量检查

提交功能分解结果前，可以做七类走查：

• 价值检查：每个节点能否向上回答“它为哪个用户结果服务”？
• 同层检查：兄弟节点是否混入能力、组件、活动、角色和里程碑？
• 覆盖检查：所有场景、异常、数据入口、输出和运营动作是否都有归属？
• 重叠检查：两个节点是否承诺同一行为，却没有主从或共享能力关系？
• 依赖检查：树外依赖是否单独记录，并为箭头命名了传递产物？
• 验收检查：每个叶子是否存在可执行测试、审计记录、监控指标或人工评审证据？
• 变更检查：目标、能力、功能、特性、工作包和测试之间是否能双向追溯？

衡量功能分解效果时，应观察它直接改变的工作结果：

• 需求评审发现的漏项数与抽象层级错误数；
• 叶子功能具备完整验收契约的比例；
• 变更影响分析中漏报的下游特性、工作包和测试数；
• 因范围或接口歧义造成的返工次数；
• 从提出目标到形成可批准功能基线的周期；
• 训练诊断产品上线后的 P50/P95 可用诊断时间、首错命中率和报告完整率。

前五项主要评价分解质量，最后一组才评价产品效果。二者相关，但不能用“图画得完整”直接推导“定位效率一定提高”。

总结

功能分解的本质，是在高层目标和工程实现之间建立一条可验证的语义链。能力地图定范围，功能树定组成，FAST 查逻辑，FBS 定用户特性，WBS 定交付控制；依赖图和追溯表把这些视图连接起来。

最重要的纪律只有两条：第一，先按用户能力和业务价值拆“做什么”，不要先照着代码目录拆；第二，只有当叶子功能的输入、行为、输出、异常、验收、依赖和 Owner 都清楚时，才算真正拆到了可以实现和验证的粒度。

参考资料

• NASA, Logical Decomposition.
• NASA, Systems Engineering Handbook, Revision 2, Section 4.3.
• U.S. Department of Energy, Work Breakdown Structure Handbook, 2012.
• SAVE International, Function Analysis Guide.
• SAVE International, Value Methodology Glossary.
• The Open Group, Toolbox for Architecture Framework, p.95.
• Jim Highsmith, Agile Project Management sample chapter, printed p.102.

[^nasa-logical]: NASA 的在线《Systems Engineering Handbook》4.3 节说明，逻辑分解用于识别各层级“应该实现什么”，并把父级需求分解、分配到更低层级。
[^nasa-handbook]: NASA Systems Engineering Handbook, Rev 2, Section 4.3 与术语表 “Functional Decomposition”。
[^doe-wbs]: U.S. Department of Energy, Work Breakdown Structure Handbook, 2012，尤其是 pp.1, 7-15；其中将按组织职能建立 WBS 列为常见错误。
[^save-guide]: SAVE International, Function Analysis Guide，公开介绍页说明该指南覆盖功能识别、分类、FAST 图和逻辑验证。
[^save-glossary]: SAVE International, Value Methodology Glossary，词条 “Function” 与 “Function Analysis System Technique (FAST)”。
[^open-group-capability]: The Open Group, Toolbox for Architecture Framework, p.95。该材料是架构实践工具箱，不应被扩大解释为全部 TOGAF 标准的强制元模型。
[^highsmith-fbs]: Jim Highsmith, Agile Project Management, Pearson sample, printed p.102。本文采用其产品架构与特性 Backlog 语义，并明确不把 FBS 表述为 Scrum 官方工件。