Function Decomposition Methods
导言
功能分解的目标，是把“提升训练问题定位效率”这类高层目标，逐层转成可以独立实现、独立验证、能够追溯业务价值的子功能。真正困难的不是把一个大框画成很多小框，而是保持三种关系清楚：功能树表达“由什么组成”，依赖图表达“先有谁、后有谁”，验收契约表达“怎样证明做到了”。
本文用同一条训练诊断链路比较五种常用方法：功能树、WBS、FAST 功能分析、能力地图和 Feature Breakdown Structure。核心原则是：先按用户能力和业务价值拆“做什么”，再按架构与代码模块分配“由谁实现”。
先把目标改写成能力¶
NASA 将功能分解定义为：检查一个功能，识别完成它所必需的子功能，以及这些功能之间的关系与接口。其逻辑分解过程首先识别系统在每一层“应该实现什么”，再把父级需求下推成更详细的功能要求。12
因此，“提升训练问题定位效率”仍然是结果目标，不是叶子功能。它至少还缺少用户、触发条件、输入、行为、输出和验收证据。功能分解就是把这块难以直接交付的目标，切成团队可以拿起来实现和验证的能力块。
用户给出的链路可以先改写成两张不同的图。第一张是包含关系：
目标：提升训练问题定位效率
├── 证据获取能力
│ ├── 完整采集各 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
适用性与边界¶
- 适合：系统功能架构、需求分解、复杂产品范围梳理、测试覆盖设计。
- 优势：向上能解释业务价值，向下能连接接口、特性、工作包和测试。
- 劣势：树只能自然表达一个主包含轴；跨分支依赖、时序和共享能力必须另建关系图。
- 实现归属：产品或系统分析 Owner 维护父子语义，能力 Owner 维护叶子契约，架构师再把功能分配给组件。
- 迁移成本：换技术栈时功能树通常可以保留，但组件分配、接口约束和非功能指标需要重新校验。
- 效果契约：它减少的是功能范围与验收歧义，新增成本是模型、追溯和变更同步；应以漏项率、返工原因和验收争议衡量，不应直接声称缩短训练时间。
WBS¶
机制与对象¶
问题快照：功能已经明确，但项目仍以零散任务清单管理。设计、开发、测试、文档和上线工作互相重叠，成本、进度和责任无法汇总到一个稳定交付物。
一句话直觉：WBS（Work Breakdown Structure，工作分解结构）把已批准的总范围按产品和交付物逐层拆成可计划、可授权、可跟踪的工作包。
美国能源部 WBS 手册明确采用产品导向结构来组织和细分项目总范围；不同层级应汇总回项目总范围，并用 WBS Dictionary 说明每个元素的范围。手册还把“按职能经理、专业或跨多个产品的活动建立 WBS 元素”列为常见错误。3
这意味着 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
适用性与边界¶
- 适合：范围基线、成本与进度控制、采购交付、跨团队大型项目。
- 优势：容易连接预算、进度、责任和风险，能检查授权范围是否完整落地。
- 劣势：如果在理解用户能力之前使用，团队很容易得到一棵“开发活动树”，却交付不了完整用户结果。
- 实现归属：项目经理维护 WBS 与字典，产品/系统 Owner 确认其与功能和交付物的映射。
- 迁移成本：范围或采购边界改变会重构 WBS；单纯更换内部算法未必改变顶层交付物。
- 效果契约：它减少的是范围、责任、成本和进度的失配；新增成本是控制粒度、字典和变更审批。效果应由范围漏项、计划偏差和未授权工作衡量。
FAST 功能分析¶
机制与对象¶
问题快照：团队把“ELK 日志平台”“时间线数据库”“LLM 根因模型”写成功能，讨论很快被当前方案锁死；当方案变化时，整个功能结构也随之失效。
一句话直觉：FAST（Function Analysis System Technique）先用简洁的“动词—名词”描述功能，再持续追问“怎样做到”和“为什么需要”，把方案名还原成功能逻辑。
SAVE International 将功能描述为项目、产品或过程为了满足客户需要必须做的事，强调“做什么”独立于“它是什么”和“如何实现”；FAST 则用 HOW-WHY 逻辑组织功能的依赖关系。45
在训练诊断案例中，可以把方案词改写成功能词：
| 不推荐 | 推荐 | 原因 |
|---|---|---|
| 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)
适用性与边界¶
- 适合：方案替代、价值工程、成本优化、复杂系统功能关系梳理、跨专业研讨。
- 优势：迫使团队暂时放下当前组件和技术名，暴露真正功能、缺失关系与替代实现空间。
- 劣势：依赖高质量引导和跨职能知识；大图容易出现一词多义、循环和伪因果。
- 实现归属：FAST 引导师维护规则，客户确认基本功能与边界，跨职能团队共同验证 HOW-WHY 关系。
- 迁移成本：实现方案改变时功能逻辑可以保留，但函数度量、成本分配和边界条件需要重评。
- 效果契约：它减少的是方案锁定和功能逻辑歧义，代价是研讨与模型校验；价值提升必须用受控方案比较证明，不能从图本身推导。
能力地图¶
机制与对象¶
问题快照：路线图按项目、团队和系统列清单。同一种日志诊断能力在多个平台重复建设，另一些战略能力却没有任何项目支撑。
一句话直觉：能力地图先稳定描述“组织或产品必须有能力做什么”，再把当前系统、流程、人员和投资映射到这些能力上。
The Open Group 的架构工具箱把业务能力描述为执行某项业务功能的能力，强调用“必须做什么”命名，并记录层级、定义、责任和上级对象。6 能力地图通常比项目和系统稳定，因为项目会结束、系统会替换，而“训练证据管理”“异常诊断”“诊断交付”等能力仍然存在。
三层边界如下：
- 概念：一个组织或产品必须稳定具备哪些能力？
- 可复用机制：建立能力域和层级，去重命名，评估当前/目标成熟度，再映射系统、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)
适用性与边界¶
- 适合：战略到技术对齐、产品线规划、重复建设识别、能力成熟度与投资组合讨论。
- 优势：对组织调整和技术替换不敏感，适合建立长期导航入口。
- 劣势：过度抽象后会停留在“具备某能力”的名词墙，无法直接指导接口、异常处理和验收。
- 实现归属：业务或产品 Owner 负责定义能力价值，架构团队维护支撑关系，投资与交付负责人维护差距证据。
- 迁移成本：系统更换主要改变支撑映射；战略结果变化才更可能改变顶层能力边界。
- 效果契约：它减少的是战略、投资与系统之间的错位，代价是统一词汇、成熟度证据和治理；应以重复投资、未支撑能力和差距关闭情况衡量。
Feature Breakdown Structure¶
机制与对象¶
问题快照：能力地图已经指出“需要训练问题诊断能力”，但这仍然无法直接进入迭代。若 Backlog 继续按后端、前端、数据库和算法组件堆放，用户价值与验收会再次断开。
一句话直觉：FBS（Feature Breakdown Structure，特性分解结构）把产品能力拆成用户可感知、可独立验收、可进入发布计划的特性和子特性。
Highsmith 在 Agile Project Management 中用 FBS 表达软硬件产品架构，强调它在客户和开发团队之间沟通，并形成用于发布与迭代计划的特性 Backlog。7 例如训练诊断产品可以拆成：
训练诊断工作台
├── 全 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
适用性与边界¶
- 适合：产品特性架构、Backlog 整理、发布切片、客户—研发沟通。
- 优势：把抽象能力变成用户能看见、能使用、能验收的增量，便于排序与发布。
- 劣势：若特性只按界面页面或组件命名，仍会失去跨端到端行为；依赖过多时树结构也会失真。
- 实现归属：Product Owner 维护用户价值和特性层级，研发与 QA 共同确认可行性、依赖和验收条件。
- 迁移成本：后端替换通常不应改写用户特性；交互、能力边界或发布策略改变时需要重新切片。
- 效果契约：它减少的是 Backlog 与用户价值、验收之间的断裂，代价是持续切片和依赖维护；应以特性验收通过率、跨迭代返工和价值交付周期衡量。
五种方法如何选择¶
五种方法都可以画成树，但被分解的对象不同。先问当前最缺哪一种确定性，再选工具：
| 方法 | 核心问题 | 主分解轴 | 主要产物 | 合适的停止点 | 最常见误用 |
|---|---|---|---|---|---|
| 功能树 | 系统必须做什么 | 父功能 -> 子功能 | 功能层级、接口、叶子契约 | 叶子可独立实现和验证 | 用代码目录当功能树 |
| WBS | 完整项目范围怎样交付与控制 | 交付物 -> 工作包 | WBS、WBS 字典 | 可授权、估算和跟踪 | 在需求未清时先列开发任务 |
| FAST | 功能之间怎样/为什么关联 | HOW-WHY 逻辑 | 功能语句、逻辑图、度量 | 逻辑边界可双向走查 | 把 HOW-WHY 当运行时序 |
| 能力地图 | 长期需要具备什么能力 | 能力域 -> 能力层级 | 能力版图、成熟度、差距 | 能支持战略与投资决策 | 只做稳定名词墙，不落支撑证据 |
| FBS | 哪些用户特性进入产品和发布 | 产品特性 -> 子特性 | 特性树、验收、发布候选 | 叶子能独立验收和排序 | 固定套 Epic/Story 层级或按组件拆 |
它们最常见的组合不是“五选一”，而是：
结果目标
-> 能力地图：确认长期能力范围与差距
-> 功能树：定义系统必须做什么
-> FAST：检查关键功能的 HOW-WHY 关系与替代空间
-> FBS：转成用户可感知、可验收的产品特性
-> WBS：转成完整交付物、工作包、成本与进度控制
同一节点允许出现在多张图
“首错识别”可以同时是能力地图中的能力、功能树中的子功能、FAST 中的功能语句、FBS 中的用户特性，也可以映射到 WBS 的多个交付物。关键不是强迫每张图节点唯一，而是为每个节点注明它此刻扮演的模型角色，并维护可追溯关系。
从目标到可验证子功能¶
一套可执行的功能分解流程可以按下面七步进行。
- 定义结果而不是方案。 写清用户、问题、基线、目标值和时间窗。例如把“提升定位效率”改成“将 P50 可用诊断结论时间从 45 分钟缩短到 10 分钟以内”，同时保留 P95 和误诊率约束。
- 固定场景与边界。 列出触发、输入、期望结果、异常和不做事项。区分训练失败、性能劣化、精度异常和基础设施告警，避免一个目标吞掉所有诊断场景。
- 画能力地图。 先识别证据获取、标准化、诊断、交付等稳定能力域，并标记当前/目标差距和 Owner。
- 建立功能树。 对每个能力域按用户结果向下拆，保持兄弟节点同一抽象层级；把包含关系放进树，把先后依赖放进单独的依赖图。
- 用 FAST 追问关键链。 对方案味很重或关系含糊的节点改写“动词—名词”，用 HOW-WHY 双向检查是否缺功能、伪因果或过早绑定实现。
- 生成 FBS 与 WBS。 把功能映射成用户可感知特性和验收条件，再把已批准范围映射成交付物、工作包、成本、进度和责任。
- 建立追溯并反向走查。 从每个测试向上找到特性、功能、能力和结果目标；再从目标向下检查是否存在没有实现、没有测试或没有 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、追溯表、风险与待确认项。
拆到什么粒度¶
功能分解不是越细越好。拆得太粗，叶子仍不可实现；拆得太细，树会退化成函数调用和工单列表。合适的停止点，是团队能在不猜业务含义的情况下给出实现方案，并由测试或运营证据独立判断是否满足契约。
叶子功能通过下面七项检查时，通常可以停止：
- 单一结果：它只承诺一个明确用户或系统结果，而不是“采集、分析并展示一切”。
- 输入输出明确：关键对象、来源、格式和消费者可以命名。
- 异常可描述：缺失、重复、乱序、超时、权限失败等边界有明确行为。
- 验收可观察：成功、失败和质量阈值都有证据，不依赖“感觉可用”。
- 主责唯一：允许多人参与，但只有一个能力契约 Owner。
- 依赖显式：上游功能、传递产物和阻塞条件可追踪。
- 实现中立：替换数据库、模型或服务时，用户结果与验收通常仍然成立。
一个典型的伪叶子
“实现日志聚合服务”看起来已经很具体，实际上只写了技术方案。它没有说明支持哪些日志源、如何处理缺失 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 的在线《Systems Engineering Handbook》4.3 节说明，逻辑分解用于识别各层级“应该实现什么”，并把父级需求分解、分配到更低层级。 ↩
-
NASA Systems Engineering Handbook, Rev 2, Section 4.3 与术语表 “Functional Decomposition”。 ↩
-
U.S. Department of Energy, Work Breakdown Structure Handbook, 2012，尤其是 pp.1, 7-15；其中将按组织职能建立 WBS 列为常见错误。 ↩
-
SAVE International, Function Analysis Guide，公开介绍页说明该指南覆盖功能识别、分类、FAST 图和逻辑验证。 ↩
-
SAVE International, Value Methodology Glossary，词条 “Function” 与 “Function Analysis System Technique (FAST)”。 ↩
-
The Open Group, Toolbox for Architecture Framework, p.95。该材料是架构实践工具箱，不应被扩大解释为全部 TOGAF 标准的强制元模型。 ↩
-
Jim Highsmith, Agile Project Management, Pearson sample, printed p.102。本文采用其产品架构与特性 Backlog 语义，并明确不把 FBS 表述为 Scrum 官方工件。 ↩