1.3 问题定义与定性改变
1.3 问题定义与定性改变
本节摘要：ASIT 的两条操作主线——入口处写一份能开工的问题定义，出口处用"定性改变"验收方案。本节给出问题陈述的四要素模板与定性改变的判定方法，并合并讲解 ASIT 的定义与目的，让"是什么、为什么"落在可操作的格式上。
为什么问题定义值得单独一节
第 1.2 节画了封闭世界的边界，但边界圈的是什么？是一个被说清楚的问题。实践中，团队对问题的陈述往往是一句抱怨："包装太占货架。"这句话没法开工——没有对象清单的锚点，没有矛盾，也没有成功判据。ASIT 把问题定义前置为独立工序，因为它直接决定后面五个模板的输入质量。
一句可开工的问题陈述要包含四个要素：
四要素问题陈述模板： 1. 对象系统：谁的问题（产品/流程名 + 封闭世界清单） 2. 矛盾陈述：我们想要 X，但 X 导致 Y（两难结构） 3. 成功判据：什么现象消失/出现算解决 4. 约束声明：不增加新对象、成本上限、时间窗 示例改写： 抱怨版："包装太占货架。" 四要素版： 对象系统：1L 装饮料（盒体、内容液、标签；环境：货架层板、顾客视线） 矛盾：我们想加大盒体以提高存在感，但货架层板间距固定，加大即被下架。 成功判据：相同货架投影面积下，视觉存在感提升，不新增零件。 约束：不加新对象，模具改动成本不超预算两成。
注意矛盾陈述那一步。TRIZ 叫它技术矛盾，ASIT 不做矩阵查找，只要求把两难写出来，因为模板操作的靶子正是矛盾：五个模板本质上都是"重构系统结构使矛盾消解"的不同手法。
ASIT 的定义与目的：一次说清
既然本章合并讲基础概念，这里把 ASIT 的定义钉死：ASIT 是一套以封闭世界为边界、以五个结构模板为操作、以定性改变为验收标准的系统化方案生成方法。它的目的不是替代一切创新形式，而是补上组织里最缺的一环——把"发散讨论"变成"有边界的结构搜索"。头脑风暴擅长收集数量，ASIT 擅长在数量中植入结构新颖性。
定性改变：验收方案的那把尺
出口端的"定性改变原则"（Qualitative Change Principle）常被误解成"要改得大"。准确表述是：方案使得问题变量之间的关系发生方向性反转或结构重组，而不是同方向上的程度缓解。
判断办法是画一条简单的关系描述：
定性改变判定： 原关系：自变量 A 上升 -> 问题严重度 B 上升（正向） 方案后：A 上升 -> B 下降（反转），或 B 与新变量 C 挂钩（重组） 程度式改进（不算定性改变）： A 上升 -> B 上升但更缓 ← 这只是优化，任何调参都能做到
用第 1.1 节的薯片案例对照：破损率从 3% 降到 2.4% 属于程度缓解；堆叠方式重构后"高度增加反而更稳"才是定性改变——关系反转了。
图1.3-1 程度缓解与定性改变的对照
案例展开：一家软件公司的"发布太慢"
背景：某工具软件公司月度发布经常跳票，各方会议的结论永远是"再加一轮测试"。注意这个"再加"——典型的出圈冲动。
操作：按四要素重写问题。对象系统：代码主干、每日构建、测试套件、发布脚本；环境：开发者的本地环境、CI 机器。矛盾陈述：我们想缩短发布周期，但缩短周期减少了测试时间，缺陷风险上升。成功判据：发布周期不变的前提下缺陷逃逸率下降。约束：不加服务器、不加人头。
随后套模板（细节在第二章，这里只看定义端的价值）：用"分割"把测试套件按风险拆开挂到不同构建阶段，用"属性依赖"让测试深度依赖代码变更范围。定义写得清楚，模板几乎是自己滑进来的——因为矛盾里已经写明了两个变量：周期与测试时间。
结果：两周一个稳定发布，缺陷逃逸率未升。
解读：这个案例里问题定义占了八成功劳。四要素陈述像一份图纸，模板只是沿图纸施工的工具。
变式：把"再加一轮测试"换成任何行业的"再加一层审批""再加一次检查"，你会看到组织惯性里最普遍的出圈冲动。
💡 关键直觉：好的问题陈述写完时，往往已经能猜到哪一两个模板最对症——变量对冲型矛盾指向属性依赖，整体功能型矛盾指向分割。第 2.1 节会把这种直觉展开成选择逻辑。
本节要点回顾
- 四要素陈述：对象系统、矛盾、成功判据、约束声明，缺一不可开工；
- 矛盾是模板的靶子：无两难结构的问题不需要 ASIT，直接执行即可；
- ASIT 定义：封闭世界为界、五模板为操作、定性改变为验收的方案生成方法；
- 定性改变的判定：关系反转或结构重组，而非同向程度缓解；
- 程度缓解方案不必丢弃：降级为优化项管理，别占用创新评审资源。
延伸问答
四要素陈述一般要写多久
新手团队第一次写通常要四十分钟，熟悉后十分钟以内。慢是正常的——这四十分钟是在替代后期的返工，经验上定义环节省下的每一分钟都会在生成与评估环节加倍偿还。
定性改变会不会标准太高，把可用方案挡在门外
不会，因为被挡住的方案并没有被丢弃，只是降级为优化项管理。组织的改进预算应当同时容纳两类工作：结构性的创新项走 ASIT 流程，程度性的优化项走常规执行。混淆两者的代价才是真实的——要么优化项冒充创新浪费评审资源，要么创新项被按优化标准要求"稳妥"而磨平棱角。
矛盾写不出来是不是说明没有矛盾
多数情况说明问题还没被拆到两难结构，有两个排查方向：一是检查是否把解法写进了问题（"需要更好的杯套"是解法）；二是检查是否其实只是单变量优化（纯粹的成本削减），那类问题用常规项目管理即可，不必动用 ASIT。
顺手练一题
把本周会议上听到的一句抱怨（任何一句都行）抄下来，试着改写成四要素陈述。多数人的第一版会在矛盾陈述处卡住——因为抱怨里往往藏着的是解法而不是两难。改完之后自测两问：这个矛盾里有没有两个互相拉扯的变量？成功判据是不是可观察的现象而不是口号？两问都过，你就已经完成了 ASIT 流程里最有价值的二十分钟。