2.1 第一步问题定义：把抱怨钉成单一问题陈述
2.1 第一步问题定义：把抱怨钉成单一问题陈述
本节摘要：问题定义是五步流程的地基。USIT 用五个要素——对象、缺陷（不期望效应）、期望结果、发生场景、封闭世界——把一句模糊抱怨改写成单一问题陈述。完成判据：外行读完能在脑子里放一遍"故障电影"。
一句抱怨能有多贵
"户外电缆接头老是出问题，信号时好时坏，客户都快被我们搞疯了。"——这是运维例会上原样记录的一句话。直接拿去头脑风暴，会得到"换更好的接头""加密巡检""上监测系统"三件套。三个方案都对"老是出问题"负责，但没人知道问题到底是什么。
问题定义阶段的任务，就是把这种句子拆开重装。USIT 的经验法则：一句合格的问题陈述里藏不下两个问题。"接头进水"和"信号时断"是两个问题，混在一起会让后续分析反复横跳。先拆问题、再挑主问题，是本步的第一动作。
五要素拆解
对着运维抱怨逐项填写：
对象：户外电缆接头（护套、密封胶、内部导体）、雨水、信号电流。
不期望效应：雨水经护套接缝渗入接头腔体，导体接头氧化，信号电阻增大、传输劣化。
期望结果：接头腔体在任意气候下保持干燥，导体接触电阻稳定在设计范围内。
场景：梅雨季与昼夜温差大的山区，温差导致腔内呼吸效应换气，水汽凝结。
封闭世界：{接头护套, 密封胶, 导体接头, 雨水与水汽, 腔内空气, 温度变化}。注意"采购更贵的接头"不在世界里——那是外援。
五个要素合成单一问题陈述：在昼夜温差引起的呼吸效应下，水汽经护套接缝进入接头腔体并凝结，导致导体接头氧化、信号劣化；期望腔体保持干燥且不引入新部件。
对比原句，改写后的陈述有三个质变：有了机理假设（呼吸效应）、有了期望结果的量级（保持干燥）、有了边界（不引入新部件）。后续所有工具都挂在这句话上。
定义阶段的三个动作
动作一：拆问题簇。 把抱怨里所有潜伏的问题列成清单，用"因果关系"连线。信号劣化 ← 导体氧化 ← 腔体积水 ← 呼吸效应吸气。链条最上游的"呼吸效应吸气"是根问题方向，最下游的"客户投诉"是后果。USIT 优先攻链上最靠近根且可下手的一环。
动作二：单一化。 检查陈述里是否只有一个"期望结果"动词短语。出现"并且""同时"的陈述，几乎都是两个问题穿了件连体衣。
动作三：画封闭世界图。 把世界里的对象摆成两栏：造成不期望效应的对象一栏，被影响的对象一栏，用箭头标功能。这张图在 2.2 节会被反复标注。
# 问题定义五要素检查器：一行一个问题陈述，机器帮你查单一性 from dataclasses import dataclass, field @dataclass class ProblemDefinition: objects: list # 对象清单 effect: str # 不期望效应 desired: str # 期望结果 scenario: str # 发生场景 world: list # 封闭世界对象 statement: str = "" # 合成的问题陈述 def check(self): issues = [] # 检查1：期望结果里出现并列连词 说明藏了不止一个问题 for conj in ["并且", "同时", "以及", "还有"]: if conj in self.desired: issues.append(f"期望结果疑似包含多个问题：发现 {conj}") # 检查2：不期望效应必须能定位到封闭世界内的对象 if not self.objects or not self.world: issues.append("对象或封闭世界为空") # 检查3：封闭世界外的对象出现在效应描述里 属于外援混入 for o in self.objects: if o not in self.world: issues.append(f"对象 {o} 不在封闭世界内") return issues pd = ProblemDefinition( objects=["接头护套", "密封胶", "导体接头", "雨水与水汽"], effect="水汽渗入腔体凝结 导体氧化 信号劣化", desired="接头腔体在任意气候下保持干燥", scenario="山区昼夜温差 呼吸效应换气", world=["接头护套", "密封胶", "导体接头", "雨水与水汽", "腔内空气", "温度变化"], ) pd.statement = ("在昼夜温差引起的呼吸效应下 水汽经护套接缝进入接头腔体并凝结 " "导致导体接头氧化与信号劣化 期望腔体保持干燥且不引入新部件") for msg in pd.check(): print("待修正:", msg) print("问题陈述:", pd.statement)
运行输出为空提示加一句完整陈述，说明这份定义通过了单一性与封闭世界两项机器检查。检查器逻辑很朴素，但把它挂在团队模板里，能在会前就拦下八成的定义返工。
定义质量对比
常见坑
- 把方案写进定义："采用充气密封的接头进水问题"——定义里藏了方案，后面所有分析都会被它绑架。检查陈述里有没有动词属于某个具体技术。
- 封闭世界画太大：把整个供电网络圈进来。世界越大，分析焦点越散。经验值：封闭世界对象不超过七个。
- 期望结果写成指标堆：期望结果是状态描述，指标留到第四步评估时再定标。
关键直觉：定义阶段多花的四十分钟，通常能省掉生成阶段两个小时的无效发散。
本节要点回顾
- 五要素：对象、不期望效应、期望结果、场景、封闭世界——缺一项定义即不完整
- 单一问题原则：一句陈述一个期望结果，"并且"是拆分信号
- 攻链上游：因果链上靠根且可下手的一环优先
- 定义禁藏方案：任何具体技术动词混入定义都算污染
- 世界不过七物：封闭世界贵精不贵大
常见问答
问题陈述写多长合适
一到三句，五十个字以内为佳。超过五十字几乎必然藏了第二个问题或一个方案。有个检验技巧：把陈述读给完全不了解背景的同事听，对方能复述出"什么东西坏了、期望什么状态"，长度与清晰度就都合格了。
封闭世界里的"温度变化"这种抽象对象合法吗
合法，但归类要诚实——它是"场"类对象（环境条件），不是实体。把它画进世界的意义在于提醒团队：这个既不可见又改不了的对象，只能通过它作用的实体间接干预。把抽象条件误当实体去"改造"，是定义阶段最隐蔽的坑。
多个问题都重要时，先攻哪个
用两个维度排：因果上游度（它是不是别人的因）与可下手度（封闭世界内有没有把手）。双高的先攻；上游但难下手的，作为长期课题；下游又容易的，当快速止血措施并行处理，但别把它计入 USIT 分析的战果——那是症状管理，不是问题重构。