设计原则

设计原则、设计模式与设计规范（编程规范）处于不同的抽象层次：设计原则是对代码设计经验的总结，抽象程度最高；设计模式是针对软件开发中反复出现的设计问题给出的具体解决方案或设计思路，比设计原则更具体、更可执行；编程规范则主要解决代码可读性问题，比前两者更偏重代码细节、更易落地。^{66design_pattern.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计原则对设计模式的选择具有指导意义，例如开闭原则被视为策略模式、模板方法模式等多种设计模式的指导原则；而设计模式的主要目的是提高代码的可扩展性。^{66design_pattern.mdgithub.com前往参考资料 ↓在新标签页中打开}

在软件工程语境下，设计原则本身并不直接给出可复用的代码结构，它需要通过设计模式、编程规范与重构等更具体的实践来落地；重构作为保持代码质量不下降的手段，所依托的理论基础正是面向对象、设计原则、设计模式与编码规范。^{66design_pattern.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计规范与设计原则的区别在于约束力与颗粒度：规范通常给出可检查、可逐条对照的具体规则（如命名、格式、注释要求），而原则给出的是判断方向，需要设计者结合具体场景权衡，因此原则不能被机械地当作规则逐条执行。^{66design_pattern.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计模式与设计原则的另一处区别在于可复用性：模式可以被命名、被文档化并在不同项目中反复套用，而原则更多体现为一种评价与取舍的尺度，同一原则在不同项目中的具体体现可能完全不同。^{66design_pattern.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计原则在工程与产品语境中首先是一种决策工具：它把分散的价值判断压缩成少数可复用的判据，使团队在面对多个可行方案时能更快收敛，而不必每次从零开始论证。^{77Design Principlesinteraction-design.org前往参考资料 ↓在新标签页中打开}

设计原则之所以能充当决策工具，是因为它预先约定了「什么算好」，从而把讨论从个人偏好转向对共同标准的援引；这种约定在团队规模扩大、决策者增多时尤为关键。^{77Design Principlesinteraction-design.org前往参考资料 ↓在新标签页中打开}

迪特·拉姆斯提出的「好设计的十原则」本身即被表述为一组用于评估设计而非规定具体造型的判据，其第十条明确把「尽可能少的设计」作为取向，体现了原则作为取舍工具而非清单式规范的定位。^{88The Ten Principles for Good Designvitra.com前往参考资料 ↓在新标签页中打开}

在软件工程中，原则常以「权衡」形式出现：例如 SOLID 中的单一职责原则并不给出唯一正确的模块划分，而是提供一个判断职责是否过度集中的视角，最终边界仍由具体情境决定。^{99SOLID Principlesen.wikipedia.org前往参考资料 ↓在新标签页中打开}

设计原则作为决策工具的有效性依赖于其可操作性：过于抽象的原则（如「简洁」）难以在具体分歧中给出裁决，而带有明确取舍方向的原则（如「优先保证可读性而非最短代码」）更容易在评审中直接使用。^{77Design Principlesinteraction-design.org前往参考资料 ↓在新标签页中打开}

原则与规则的区别在于约束强度：规则可以被自动检查或强制阻断，原则则依赖使用者的判断与解释，因此原则更适合处理规则无法覆盖的模糊地带。^{77Design Principlesinteraction-design.org前往参考资料 ↓在新标签页中打开}

把设计原则当作决策工具使用时，需要配套的落地机制（如设计评审、原则对照检查、决策记录），否则原则容易停留在文档层面而无法影响实际选择。^{77Design Principlesinteraction-design.org前往参考资料 ↓在新标签页中打开}

「好设计的十原则」（Ten Principles for Good Design）由德国工业设计师迪特·拉姆斯（Dieter Rams）系统提出，包含创新性、实用性、审美性、易于理解、诚实、克制、耐用、细节周密、环保与极简等核心要素。^{1010优良设计baike.baidu.com前往参考资料 ↓在新标签页中打开|1111优良设计wapbaike.baidu.com前往参考资料 ↓在新标签页中打开}

拉姆斯用「少，却更好」（Weniger, aber besser / Less, but better）概括自己的设计理念，这一提法后来成为十原则的精神底色。^{1010优良设计baike.baidu.com前往参考资料 ↓在新标签页中打开|1111优良设计wapbaike.baidu.com前往参考资料 ↓在新标签页中打开}

十原则并非凭空产生，其思想根植于 1907 年成立的德意志制造联盟（Deutscher Werkbund）与 1919 年诞生的包豪斯所奠定的德国现代设计传统。^{1111优良设计wapbaike.baidu.com前往参考资料 ↓在新标签页中打开}

1954 年起，博朗与乌尔姆造型学院（Hochschule für Gestaltung Ulm）开展合作，确立了功能性与极简美学相统一的设计准则；1954 年至 1967 年间，博朗设计作为战后欧洲现代主义设计（第二现代性）的典范得到发展。^{1010优良设计baike.baidu.com前往参考资料 ↓在新标签页中打开|1111优良设计wapbaike.baidu.com前往参考资料 ↓在新标签页中打开}

博朗公司 1921 年由马克斯·布劳恩（Max Braun）在德国法兰克福创立，1956 年设立第一个设计部门，由弗里茨·艾希勒（Fritz Eichler）领军并与乌尔姆设计学院建立合作关系；1967 年公司被吉列收购后总部迁至克龙贝格。^{1111优良设计wapbaike.baidu.com前往参考资料 ↓在新标签页中打开}

合作期间博朗推出 SK4 电唱机、T3 收音机等经典产品，采用直线条造型、基础色系与功能编码系统（如红色表示关、绿色表示开），把「易于理解」这一原则落到了具体的操作界面上。^{1010优良设计baike.baidu.com前往参考资料 ↓在新标签页中打开|1111优良设计wapbaike.baidu.com前往参考资料 ↓在新标签页中打开}

乌尔姆学院把社会学等学科引入设计教学，推动博朗设计形成面向工业生产的服务模式，这为十原则中强调产品工具属性、反对装饰性元素与「资产阶级媚俗」的取向提供了制度与教育背景。^{1010优良设计baike.baidu.com前往参考资料 ↓在新标签页中打开|1111优良设计wapbaike.baidu.com前往参考资料 ↓在新标签页中打开}

20 世纪 60 年代，德国工业产品的设计造型被概括为克制的、功能的、朴素的、方正的、色彩中性的，这一时代风格与拉姆斯在博朗的实践相互印证。^{1111优良设计wapbaike.baidu.com前往参考资料 ↓在新标签页中打开}

迪特·拉姆斯（Dieter Rams）是德国工业设计师，长期领导博朗（Braun）的设计部门，直至 1998 年退休；他把「什么是好的设计」总结为十项原则，这十项原则被设计界广泛引用，常被称为「好设计的十原则」或「设计十诫」。^{1212IXDC | 引领设计变革ixdc.org前往参考资料 ↓在新标签页中打开|1313广东工业设计网gd-id.com前往参考资料 ↓在新标签页中打开}

十项原则的第一条是「好的设计是革新的」（Gutes Design ist innovativ）：创新的可能性远未被穷尽，技术发展不断为设计提供新的起点以提升产品可用性；但设计的革新应与技术的革新相连，不应为了革新而革新。^{1212IXDC | 引领设计变革ixdc.org前往参考资料 ↓在新标签页中打开}

第二条是「好的设计是实用的」（Gutes Design macht ein Produkt brauchbar）：产品是供人使用的，应履行主要功能以及额外的心理和审美功能；好的设计以提升产品可用性为目的，与此无关甚至相悖的因素都不应纳入考虑。^{1212IXDC | 引领设计变革ixdc.org前往参考资料 ↓在新标签页中打开}

第三条是「好的设计是美观的」（Gutes Design ist ästhetisch）：拉姆斯把审美品质视为产品有用性的组成部分，认为只有美观的产品才能在日常使用中持续令人愉悦。^{1212IXDC | 引领设计变革ixdc.org前往参考资料 ↓在新标签页中打开}

拉姆斯用「少，却更好」（Less, but better，德文 Weniger, aber besser）概括自己的设计立场，这一提法常被拿来与现代主义建筑大师密斯·凡·德·罗的「少即是多」（Less is more）相映照；苹果设计奠基人物乔纳森·伊夫（Jonathan Ive）在设计中一直遵循拉姆斯的十项原则。^{1313广东工业设计网gd-id.com前往参考资料 ↓在新标签页中打开}

拉姆斯对当时的设计状况持批评态度，他担心「真正的创新正变得越来越少，术语化的设计正在泛滥，设计好像已经变成了漂亮外观和时尚的代名词」，并忧虑在走未曾走过的道路时可能失去方向。^{1313广东工业设计网gd-id.com前往参考资料 ↓在新标签页中打开}

迪特·拉姆斯（Dieter Rams）在20世纪80年代提出的「好设计的十原则」（也译作「设计十诫」），被设计界奉为准则，其影响范围超出工业设计，延伸到互联网产品设计等领域。^{1414好设计的 10 个原则：影响着苹果、索尼的产品设计理念 – 人人都是产品经理woshipm.com前往参考资料 ↓在新标签页中打开}

拉姆斯为博朗（Braun）和维索（Vitsoe）设计的众多经典产品，在过去数十年间深刻影响了包括苹果（Apple）、索尼（Sony）在内的许多品牌的产品设计理念。^{1414好设计的 10 个原则：影响着苹果、索尼的产品设计理念 – 人人都是产品经理woshipm.com前往参考资料 ↓在新标签页中打开}

拉姆斯提出十原则的动因，是他对周遭世界「各种形状、颜色和噪音组成一片又一片混乱」的观察，并由此自问「我的设计，是好的设计吗」，把答案写进了十原则之中。^{1414好设计的 10 个原则：影响着苹果、索尼的产品设计理念 – 人人都是产品经理woshipm.com前往参考资料 ↓在新标签页中打开}

十原则中的第一条是「好的设计是创新的」：拉姆斯认为创新的可能性不会枯竭，技术发展会持续为设计创新带来新的可能，创新设计随之而来，不会停滞。^{1414好设计的 10 个原则：影响着苹果、索尼的产品设计理念 – 人人都是产品经理woshipm.com前往参考资料 ↓在新标签页中打开}

十原则中的第二条是「好的设计让产品实用」，强调功能与可用性在好设计中的基础地位。^{1414好设计的 10 个原则：影响着苹果、索尼的产品设计理念 – 人人都是产品经理woshipm.com前往参考资料 ↓在新标签页中打开}

拉姆斯1959年为博朗设计的TP3收音机/唱机组合，常被作为其设计理念的实例引用，也是后来者理解十原则形成背景的参照物。^{1414好设计的 10 个原则：影响着苹果、索尼的产品设计理念 – 人人都是产品经理woshipm.com前往参考资料 ↓在新标签页中打开}

一致性（consistency）是界面与交互设计中被反复强调的基础原则之一：它要求界面中相同或相似的要素在视觉与行为上保持统一，使用户能够把在一个位置学到的规则迁移到另一个位置，从而降低学习成本与误操作概率。Apple 在其人机界面设计传统中把一致性列为设计原则之一，并在 2017 年的设计原则演讲中专门讨论了这一问题。^{1515基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

Apple 设计推广团队的 Mike Stern 在 WWDC17 的「基本的设计原则」演讲中把一致性区分为两个层面：一是与平台惯例、用户既有预期保持一致，二是应用内部的一致性，即控件在视觉与感觉上彼此一致。他指出，在简单事物上（如图标与标签）的不一致很容易让人出错，因此除非有很坚定的理由，否则应保持一致。^{1515基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

按 Apple 的表述，内部一致性具体落实为可检查的约束：应用的字形要有统一的视觉风格，文本要限制字体数量、字号与颜色种类等。其目的是让应用产生连贯性与整体感，使用户在一切都能匹配时对产品的完整性产生更深刻的感受，并本能地认为这些设计是经过深思熟虑的选择。^{1515基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

一致性并不等于拒绝变化。同一场演讲同时承认，人总有一种想做点不一样的事情的冲动，这本身是创新的来源；一致性要求针对的是简单事物上的随意差异，而不是禁止有充分理由的刻意偏离。因此一致性原则在实践中通常被表述为「默认保持一致，偏离需要理由」，而非绝对规则。^{1515基本的设计原则 - WWDC17 - 视频 - Apple Developerdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

在学术文献中，一致性通常被放在基于用户体验的人机交互界面设计策略框架内讨论：设计策略从用户的感知、认知与情感能力出发，界面模型则要求在迭代过程中不断发现各阶段的问题并及时调整与再设计，一致性正是维持这种可预期性的手段之一。^{1616Establishment of Design Strategies and Design Models of Human Computer Interaction Interface Based on User Experiencerd.springer.com前往参考资料 ↓在新标签页中打开}

在交互设计中，反馈（feedback）指系统向用户传达其操作结果或当前状态的机制，是唐·诺曼在《设计心理学》中提出的可发现性、反馈、映射、约束等设计原则之一。^{1717The Design of Everyday Things: Revised and Expanded Editionbasicbooks.com前往参考资料 ↓在新标签页中打开}

尼尔森十大可用性原则中的第一条「系统状态可见性」要求系统应在合理时间内通过适当反馈让用户了解正在发生的事情，这是反馈原则在可用性工程中的经典表述。^{181810 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开}

反馈的及时性直接影响用户体验：系统响应时间在 0.1 秒以内时用户会感觉是即时响应，1 秒以内时用户的操作流不会被打断，10 秒以上则用户注意力会转移，因此需要提供进度指示等反馈。^{1919Response Times: The 3 Important Limitsnngroup.com前往参考资料 ↓在新标签页中打开}

ISO 9241-110 将「自描述性」（self-descriptiveness）和「反馈」相关要求列为对话原则之一，要求系统在合理时间内向用户提供关于操作结果和系统状态的反馈。^{2020ISO 9241-110:2020 Ergonomics of human-system interaction — Part 110: Dialogue principlesiso.org前往参考资料 ↓在新标签页中打开}

在图形用户界面中，反馈可分为视觉、听觉和触觉等模态；移动操作系统（如 iOS 和 Android）提供了触觉反馈 API，允许开发者为交互添加物理振动反馈。^{2121Human Interface Guidelines: Feedbackdeveloper.apple.com前往参考资料 ↓在新标签页中打开|2222Android Developers: Provide haptic feedbackdeveloper.android.com前往参考资料 ↓在新标签页中打开}

反馈过载或不当反馈（如频繁弹窗、冗余提示）会干扰用户，导致注意力分散和操作效率下降，因此反馈设计需在信息量与干扰之间取得平衡。^{2323Designing with the Mind in Mind: Simple Guide to Understanding User Interface Design Guidelineselsevier.com前往参考资料 ↓在新标签页中打开}

WCAG 2.1 成功标准 4.1.3「状态消息」要求状态消息能够被辅助技术感知而不获取焦点，这体现了无障碍设计中对反馈可访问性的要求。^{2424Web Content Accessibility Guidelines (WCAG) 2.1w3.org前往参考资料 ↓在新标签页中打开}

在界面与交互设计语境中，「效率」通常不是指机器运算速度，而是指用户达成目标所付出的认知与操作成本：让用户以更少的步骤、更少的记忆负担、更少的理解歧义完成同一任务。Element Plus 的设计原则把效率拆成三条可操作的要求——简化流程（设计简洁直观的操作流程）、清晰明确（语言表达清晰且表意明确，让用户快速理解进而作出决策）、帮助用户识别（界面简单直白，让用户快速识别而非回忆，减少用户记忆负担）。^{11设计 | Element Pluselement-plus.org前往参考资料 ↓在新标签页中打开}

「帮助用户识别而非回忆」是效率原则中最常被单独抽出来讨论的一条：它把效率的落点放在记忆负担上，主张把可选操作、当前状态与上下文直接呈现在界面上，而不是要求用户记住上一步做了什么、某个命令藏在哪一层菜单里。Element Plus 将其表述为「界面简单直白，让用户快速识别而非回忆，减少用户记忆负担」。^{11设计 | Element Pluselement-plus.org前往参考资料 ↓在新标签页中打开}

效率原则与「可控」原则在实践上存在张力，需要在具体设计中权衡：减少步骤往往意味着合并或省略确认环节，而可控性要求用户能够撤销、回退和终止当前操作。Element Plus 把二者列为并列原则，可控性一侧明确要求「用户可以自由的进行操作，包括撤销、回退和终止当前操作等」，这意味着追求流程简化时不能以牺牲可逆性为代价。^{11设计 | Element Pluselement-plus.org前往参考资料 ↓在新标签页中打开}

在组件库的设计原则文档中，效率通常与一致、反馈、可控并列出现，构成一组相互约束的原则集合，而不是单独一条可以孤立优化的指标。Element Plus 的设计原则章节即以「一致 Consistency / 反馈 Feedback / 效率 Efficiency / 可控 Controllability」四项并列组织。^{11设计 | Element Pluselement-plus.org前往参考资料 ↓在新标签页中打开}

可控性（Controllability）是界面与交互设计中的一项常见原则，其核心主张是：系统应让用户而非系统掌握操作的主导权——界面可以给出建议或提示，但不能代替用户做决定，并且用户应当能够撤销、回退或终止自己发起的操作。^{11设计 | Element Pluselement-plus.org前往参考资料 ↓在新标签页中打开}

在 Element Plus 的设计原则文档中，可控性被拆成两条具体要求：一是「用户决策」，即根据场景可给予用户操作建议或安全提示，但不能代替用户进行决策；二是「结果可控」，即用户可以自由进行操作，包括撤销、回退和终止当前操作等。^{11设计 | Element Pluselement-plus.org前往参考资料 ↓在新标签页中打开}

可控性原则与反馈原则互为条件：用户之所以能判断自己是否仍掌握控制权，依赖于界面通过样式与动效清晰呈现操作结果与当前状态；缺少可见的状态反馈，「结果可控」就无从验证。^{11设计 | Element Pluselement-plus.org前往参考资料 ↓在新标签页中打开}

可控性原则在工程上通常落实为可撤销机制（撤销/重做）、可中断的长时任务、操作前的二次确认与危险操作的安全提示，以及允许用户自由回退到先前状态的导航结构。^{11设计 | Element Pluselement-plus.org前往参考资料 ↓在新标签页中打开}

可控性并不等于把全部选项都交给用户：该原则同时承认界面可以给出操作建议与安全提示，其边界在于「建议而非代替」，即在保留用户最终决定权的前提下降低误操作风险。^{11设计 | Element Pluselement-plus.org前往参考资料 ↓在新标签页中打开}

可访问性设计（accessibility）指让残障人士——包括视觉、听觉、运动、认知与言语障碍者——能够感知、理解、操作并与界面交互；它通常被表述为一组可检验的要求，而非事后补救的附加功能。^{2525Design und User Experience | web.dev for Chinaweb.developers.google.cn前往参考资料 ↓在新标签页中打开}

为所有人设计（inclusive design，包容性设计）与可访问性密切相关但范围更宽：它主张在设计早期就把尽可能多样的人群身份与使用情境纳入考虑，包括临时性障碍（如手臂受伤）与情境性障碍（如强光下看屏幕），从而让最终产品对更多人可用。^{2525Design und User Experience | web.dev for Chinaweb.developers.google.cn前往参考资料 ↓在新标签页中打开}

web.dev 的可访问性课程指出，用户与设计的交互体验会随一天中的时段、所用设备类型、前一晚睡眠是否充足、身体不适、是否使用辅助技术等因素而变化，因此“残障”并非固定的少数群体标签，而是任何人都可能进入的状态。^{2525Design und User Experience | web.dev for Chinaweb.developers.google.cn前往参考资料 ↓在新标签页中打开}

一种常见的落地做法是构建包含残障人士在内的“用户身份”（user personas）：为不同障碍类型分别设定具体的使用者画像，用它们来检验设计决策是否覆盖了真实需求，而不是只服务于典型用户。^{2525Design und User Experience | web.dev for Chinaweb.developers.google.cn前往参考资料 ↓在新标签页中打开}

在界面与交互层面，可访问性通常落实为若干可操作的原则：足够的颜色对比度、不依赖单一感官通道传达信息（如为图像提供替代文本、为视频提供字幕）、完整的键盘可操作性、清晰的焦点指示、可缩放的文字，以及语义化的结构标记。^{2525Design und User Experience | web.dev for Chinaweb.developers.google.cn前往参考资料 ↓在新标签页中打开}

把可访问性当作设计原则而非合规清单，意味着在概念与原型阶段就引入多样化的用户身份与辅助技术场景；若等到开发末期再补，改动成本显著上升，且往往只能做到表面合规。^{2525Design und User Experience | web.dev for Chinaweb.developers.google.cn前往参考资料 ↓在新标签页中打开}

SOLID 是面向对象编程中五项设计原则的首字母缩略词，由单一职责原则（SRP）、开闭原则（OCP）、里氏替换原则（LSP）、接口隔离原则（ISP）和依赖反转原则（DIP）组成。^{2626检查接口设计 - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开|2727设计的五大原则-SOLID-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

单一职责原则（SRP）要求一个类应专注于一项明确的工作并完整处理它，因此类应当只因为一个特定原因而变更；在更严格的表述中，它被理解为每个软件模块只对某一类行为者负责，即只应有一个被更改的理由。^{2626检查接口设计 - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开|2727设计的五大原则-SOLID-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

开闭原则（OCP）主张软件实体应对扩展开放、对修改关闭，即应当能够在不改动现有代码的前提下为类添加新功能。^{2626检查接口设计 - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开|2727设计的五大原则-SOLID-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

里氏替换原则（LSP）要求子类型能够替换其基类型：如果程序是针对某种类型的对象编写的，那么该对象的任何子类型都应能替换它而不引发错误；换言之，凡是基类可以出现的地方，子类一定可以出现。^{2626检查接口设计 - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开|2727设计的五大原则-SOLID-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

接口隔离原则（ISP）要求不应强迫类依赖它们并不使用的接口，接口应被设计为只提供使用方所需的功能，从而在设计中避免不必要的依赖。^{2626检查接口设计 - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开|2727设计的五大原则-SOLID-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

依赖反转原则（DIP）主张高层策略性代码不应依赖底层细节代码，而应由底层细节代码依赖高层策略。^{2727设计的五大原则-SOLID-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

在 SOLID 的实践中，接口是关键元素：接口充当代码的契约，定义接口即声明使用该接口的任何类必须具备某些方法和属性，这有助于建立代码标准化并防止代码紧密耦合。^{2626检查接口设计 - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开}

SOLID 常被作为面向对象设计的基础性指导，其五项原则分别针对职责划分、可扩展性、子类型可替换性、接口粒度与依赖方向这五个不同的设计关注点，因而在实践中需要结合具体场景分别权衡，而非机械套用。^{2626检查接口设计 - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开|2727设计的五大原则-SOLID-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

开放-封闭原则（Open-Closed Principle，常缩写为 OCP）的经典表述是：一个软件实体应当对扩展开放，对修改关闭。也就是说，应当能够在不修改源代码的前提下改变模块的行为。^{2929设计模式之设计原则-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开|3030软件开发设计原则-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

该原则最早由伯特兰·迈耶（Bertrand Meyer）提出，通常追溯到其 1988 年的著作，英文原文为「Software entities should be open for extension, but closed for modification」。^{2929设计模式之设计原则-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

在中文技术社区的通行转述中，OCP 被列为面向对象可复用设计的第一块基石，与单一职责、里氏代换等原则并列，构成所谓「六大设计原则」体系的一部分。^{2929设计模式之设计原则-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开|3030软件开发设计原则-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

支持 OCP 的论证通常基于一个前提：软件系统的需求会随时间变化，因此设计必须保持稳定。满足 OCP 的设计被认为同时带来两方面好处——通过扩展提供新行为以获得适应性，以及保持核心抽象层不被修改以获得稳定性与延续性。^{2929设计模式之设计原则-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

微软开发者博客在回顾组件级设计原则时，把开放-封闭原则与另外几条原则一并列出，并注明其表述来自 Robert C. Martin（Martin R.），说明该原则在组件级设计语境中也被引用。^{2828SDLC – Software Development Lifecycle … flashback, component-level design principles (part 9 of many)learn.microsoft.com前往参考资料 ↓在新标签页中打开}

依赖倒置原则（Dependency Inversion Principle，DIP）的经典表述包含两条：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。^{3131设计模式之软件设计七大原则-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|3333设计模式之设计原则-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

依赖倒置原则在实践中的通俗表述是「针对接口编程，不要针对实现编程」，即高层模块只依赖接口或抽象父类，而不直接依赖具体的派生实现类。^{3131设计模式之软件设计七大原则-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

遵循依赖倒置原则的常见收益被归纳为：减少类间耦合、提高系统稳定性、提高代码可读性与可维护性，并降低修改程序所带来的风险。^{3131设计模式之软件设计七大原则-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|3333设计模式之设计原则-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

依赖倒置原则对并行开发有直接价值：当两个类通过抽象解耦后，原本必须等待对方编码完成才能开工的模块可以同时开发、互不影响；参与协作的人越多、项目越庞大，采用该原则的意义越明显。^{3232设计模式的分类和六大设计原则-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

依赖关系的传递在代码层面通常有三种方式：接口传递、构造方法传递和 setter 方法传递；以 Spring 为代表的依赖注入框架使构造方法与 setter 注入成为常见做法。^{3232设计模式的分类和六大设计原则-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

接口隔离原则（Interface Segregation Principle，ISP）要求使用多个专门的接口而不是单一的总接口，客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应当建立在最小的接口上。^{3131设计模式之软件设计七大原则-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

接口隔离原则的落地要点包括：建立单一接口而非庞大臃肿的接口、尽量细化接口并减少接口中的方法数量；其收益是符合高内聚低耦合的设计思想，使类具有更好的可读性、可扩展性和可维护性。^{3131设计模式之软件设计七大原则-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|3333设计模式之设计原则-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

接口隔离原则的细化存在适度问题：过度拆分接口会造成类数量膨胀（常被称为「类爆炸」），因此实践中需要把握适度原则，而不是无条件地把接口拆到最小。^{3131设计模式之软件设计七大原则-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

在中文技术社区的归纳中，依赖倒置原则与接口隔离原则常与开闭原则、单一职责原则、里氏替换原则、迪米特法则并列，作为面向对象设计的核心原则集合；不同文章对原则数量的说法不一（「六大原则」「七大原则」等），但依赖倒置与接口隔离均被列入其中。^{3131设计模式之软件设计七大原则-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开|3232设计模式的分类和六大设计原则-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开|3333设计模式之设计原则-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

设计原则在实践中并非要求所有代码都必须遵循，而需要综合考虑人力、时间、成本与质量，在适当场景下遵循，本质上是一种平衡取舍。^{3333设计模式之设计原则-云社区-华为云bbs.huaweicloud.com前往参考资料 ↓在新标签页中打开}

在安全关键系统（如航空、铁路、医疗设备、核工业）中，设计原则的优先级通常不是由美学或可用性主导，而是由危害分析与风险控制目标主导：先识别危害、评估风险，再据此确定必须满足的安全要求，设计原则的取舍服从这些要求。^{3434IEC 61508-1:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems — Part 1: General requirementswebstore.iec.ch前往参考资料 ↓在新标签页中打开|3535ISO 31000:2018 Risk management — Guidelinesiso.org前往参考资料 ↓在新标签页中打开}

IEC 61508 作为功能安全的基础标准，采用整体安全生命周期框架，要求在设计阶段就进行危害与风险分析，并据此分配安全完整性等级（SIL）；设计原则的选择与优先级排序被置于这一“先定安全要求、再定设计”的流程之下，而不是反过来。^{3636IEC 61508 — Functional Safetyiec.ch前往参考资料 ↓在新标签页中打开}

在安全关键系统的设计原则排序中，“避免危害优先于控制危害、控制危害优先于减轻危害”是一条被广泛采用的层级：优先通过设计消除危险源，其次才是加防护、报警或程序性措施。这一层级与职业安全领域的“危害控制层级”一致。^{3737Hierarchy of Controlscdc.gov前往参考资料 ↓在新标签页中打开|3838Hierarchy of hazard controlsen.wikipedia.org前往参考资料 ↓在新标签页中打开}

ISO 12100 对机械安全的设计顺序给出明确规定：先通过设计消除或减小风险，再在必要时加装安全防护，最后才以使用信息（警告、培训、说明书）作为补充；这体现了“本质安全设计优先于附加防护、附加防护优先于信息提示”的原则优先级。^{3939ISO 12100:2010 Safety of machinery — General principles for design — Risk assessment and risk reductioniso.org前往参考资料 ↓在新标签页中打开}

在软件层面，安全关键系统的设计原则优先级常表现为：简单性与可验证性优先于功能丰富性，确定性行为优先于灵活性，显式失败（fail-safe / fail-stop）优先于静默降级。这些取舍与通用界面设计原则中“以用户为中心、追求易用与美观”的排序明显不同。^{4040Software for Dependable Systems: Sufficient Evidence?nap.nationalacademies.org前往参考资料 ↓在新标签页中打开}

航空领域的 DO-178C 及其配套标准把“设计保证”与“验证独立性”放在很高优先级：设计决策必须可追溯到需求，且验证活动需与被验证的开发活动保持独立，这使“可追溯性”和“独立验证”在原则排序中高于开发效率。^{4141DO-178C Software Considerations in Airborne Systems and Equipment Certificationrtca.org前往参考资料 ↓在新标签页中打开}

医疗设备软件标准 IEC 62304 将软件安全分级（A/B/C）与设计控制绑定，级别越高，要求的设计验证与风险控制活动越严格；设计原则的优先级随安全级别变化，而不是对所有设备采用同一套排序。^{4242IEC 62304:2006 Medical device software — Software life cycle processeswebstore.iec.ch前往参考资料 ↓在新标签页中打开}

在安全关键系统的设计原则落地中，“原则优先级”通常需要被写成可审计的设计决策记录：每条设计取舍都要能追溯到对应的危害、风险控制措施或安全要求，否则优先级排序无法在评审和认证中被验证。^{3434IEC 61508-1:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems — Part 1: General requirementswebstore.iec.ch前往参考资料 ↓在新标签页中打开|4141DO-178C Software Considerations in Airborne Systems and Equipment Certificationrtca.org前往参考资料 ↓在新标签页中打开}

智能座舱中的驾驶安全优先原则，指在座舱功能设计与交互决策中，把驾驶任务的安全与驾驶员对车辆的控制权置于娱乐、信息、舒适等非驾驶功能之上；当资源、注意力或交互通道发生冲突时，优先保障驾驶相关信息的呈现与操作。^{4444Automotive User Interfaces: Creating Interactive Experiences in the Carlink.springer.com前往参考资料 ↓在新标签页中打开|4545Human Factors in Automotive Engineering and Technologytaylorfrancis.com前往参考资料 ↓在新标签页中打开}

国际标准化组织发布的 ISO 15008 针对车载视觉信息呈现系统（含导航、信息娱乐等）规定了可读性、布局与信息密度等要求，其基本取向是让信息在驾驶过程中可被快速、低负担地获取，从而服务于驾驶安全。^{4646ISO 15008:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Specifications and test procedures for in-vehicle visual presentationiso.org前往参考资料 ↓在新标签页中打开}

美国国家公路交通安全管理局（NHTSA）发布的《人类因素设计指南》提出，车载电子设备的设计应尽量减少驾驶员视线离开道路的时间与注意力分散，并建议单次视线离开道路的时间不宜过长，以降低碰撞风险。^{4747Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesfederalregister.gov前往参考资料 ↓在新标签页中打开}

联合国欧洲经济委员会（UNECE）的 R79 法规对转向系统（含自动转向功能）作出规定，要求车辆在自动转向介入时仍能保证驾驶员可随时接管，体现了在驾驶辅助功能设计中保留驾驶员控制权的取向。^{4848UN Regulation No. 79 — Steering equipmentunece.org前往参考资料 ↓在新标签页中打开}

ISO 26262 功能安全标准为道路车辆电子/电气系统的安全相关功能定义了从 A 到 D 的汽车安全完整性等级（ASIL），要求对可能造成危害的功能进行风险分级并采取相应安全措施；座舱中涉及驾驶信息呈现与告警的功能可据此进行安全论证。^{4949ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

在智能座舱交互设计中，将关键驾驶信息（如车速、告警、导航转向提示）置于视觉层级的高优先级位置，并限制非驾驶信息在行驶中的呈现强度，是落实驾驶安全优先的常见做法。^{4444Automotive User Interfaces: Creating Interactive Experiences in the Carlink.springer.com前往参考资料 ↓在新标签页中打开|4646ISO 15008:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Specifications and test procedures for in-vehicle visual presentationiso.org前往参考资料 ↓在新标签页中打开}

多模态交互（语音、触觉、听觉提示）被用于减少驾驶员视线离开道路的需求，但语音交互本身也可能带来认知负荷，因此设计上需权衡交互通道的分配，避免以“减少视觉分心”为名引入新的注意力负担。^{4747Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesfederalregister.gov前往参考资料 ↓在新标签页中打开|5050Driver Distraction and Inattention: Advances in Research and Countermeasurestaylorfrancis.com前往参考资料 ↓在新标签页中打开}

随着座舱内大屏、多屏与第三方应用的增加，功能丰富性与驾驶安全之间的张力成为设计原则需要明确处理的冲突点；业界普遍主张以驾驶场景为约束条件来裁剪非驾驶功能，而非在行驶中无条件开放全部功能。^{4545Human Factors in Automotive Engineering and Technologytaylorfrancis.com前往参考资料 ↓在新标签页中打开|4747Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesfederalregister.gov前往参考资料 ↓在新标签页中打开}

驾驶安全优先原则在落地时依赖可验证的指标，例如视线离开道路时间、任务完成时间、分心相关事件率等，这些指标被用于评估座舱交互设计是否满足安全目标。^{4747Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesfederalregister.gov前往参考资料 ↓在新标签页中打开|5050Driver Distraction and Inattention: Advances in Research and Countermeasurestaylorfrancis.com前往参考资料 ↓在新标签页中打开}

在自动驾驶或高级驾驶辅助场景下，驾驶安全优先原则还涉及接管请求与状态提示的设计：系统需在需要驾驶员接管时给出清晰、及时且不易被忽略的提示，以维持驾驶员对车辆状态的知情与控制。^{4848UN Regulation No. 79 — Steering equipmentunece.org前往参考资料 ↓在新标签页中打开|4949ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

可执行的设计原则应当写成对具体设计决策的约束或判据，而不是「简洁」「优雅」「以用户为中心」这类无法直接判定真假的形容词；判断标准是：拿到一个界面方案或一段代码，团队能据此说「这符合」或「这不符合」。^{5151Design Principlesprinciples.design前往参考资料 ↓在新标签页中打开}

尼尔森诺曼集团在讨论启发式评估时强调，可用性启发式必须表述为可被评估者直接对照检查的规则，否则不同评估者对同一界面会给出差异极大的判断，评估结果无法复现。^{181810 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开}

谷歌的 Material Design 把设计原则与具体的组件规格、间距刻度、动效时长绑定发布，使原则可以被直接映射到实现参数，这是「原则—规范—组件」三层落地结构的典型做法。^{5252Material Design 3m3.material.io前往参考资料 ↓在新标签页中打开}

苹果的人机界面指南同样采取「原则陈述 + 具体尺寸/控件行为规定」的写法，例如对点击目标尺寸给出明确下限，使原则具备可检验性。^{5353Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

在软件工程语境中，把设计原则写成可自动检查的规则（如架构约束、依赖方向检查、lint 规则）比写成文档更有效，因为自动化检查能在每次提交时强制执行，而文档会随时间失效。^{5454ArchUnit: Unit Tests for Architecturearchunit.org前往参考资料 ↓在新标签页中打开}

写可执行原则时，每条原则应包含三部分：原则陈述（要什么）、理由（为什么，关联到用户或业务后果）、以及可观察的检验方式（怎么判断做到了）；缺少理由的原则在团队遇到边界情况时无法被正确外推。^{5151Design Principlesprinciples.design前往参考资料 ↓在新标签页中打开|5555Design Principles: The Philosophy of UXnngroup.com前往参考资料 ↓在新标签页中打开}

原则数量需要克制：把原则压缩到少数几条、并给出优先级排序，比罗列几十条同等权重的原则更可执行，因为原则之间冲突时团队需要知道哪条优先。^{5555Design Principles: The Philosophy of UXnngroup.com前往参考资料 ↓在新标签页中打开}

可执行的原则需要配套反例：给出「违反这条原则长什么样」的具体例子，比只给正面描述更能减少解释分歧。^{181810 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开}

原则落地需要指定责任人与复核机制（设计评审、代码评审、定期审计），否则原则只停留在文档层面；把原则嵌入既有的评审流程比另建一套流程更容易持续。^{5454ArchUnit: Unit Tests for Architecturearchunit.org前往参考资料 ↓在新标签页中打开|5555Design Principles: The Philosophy of UXnngroup.com前往参考资料 ↓在新标签页中打开}

原则应当随实践反馈迭代：定期回顾哪些原则被频繁引用、哪些从未被使用，并据此删改，避免原则清单膨胀成无人阅读的装饰。^{5555Design Principles: The Philosophy of UXnngroup.com前往参考资料 ↓在新标签页中打开}

设计原则要真正影响产品，必须嵌入团队既有的评审流程，而不是作为独立文档存在；评审时把原则转成具体的检查问题（如「这个交互是否让用户始终知道系统状态」），才能让原则从抽象口号变成可执行的判断依据。^{5151Design Principlesprinciples.design前往参考资料 ↓在新标签页中打开}

尼尔森诺曼集团（Nielsen Norman Group）提出的启发式评估（heuristic evaluation）方法，把可用性原则转化为评审者逐条对照界面进行检查的流程：评审者独立走查界面，标记违反每条启发式原则的问题，再汇总严重度。这一方法说明原则落地依赖结构化的评审步骤，而非笼统的「凭感觉评审」。^{181810 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开}

在软件工程语境中，设计评审（design review）被定义为对设计文档或方案的系统性检查，目的是在编码前发现缺陷；IEEE 1028 标准把评审分为管理评审、技术评审、审查（inspection）、走查（walkthrough）和审计等类型，为「原则如何进入评审」提供了流程框架。^{5656IEEE Standard for Software Reviews and Audits (IEEE Std 1028)standards.ieee.org前往参考资料 ↓在新标签页中打开}

Google 的工程实践文档指出，代码评审（code review）的核心目的之一是让代码库随时间推移保持可维护性，并强调评审应聚焦设计、功能、复杂度和可读性等维度；这类评审清单把设计原则（如简洁、一致、可维护）转成评审者逐项核对的条目。^{5757Google Engineering Practices: Code Reviewgoogle.github.io前往参考资料 ↓在新标签页中打开}

设计原则的落地通常需要配套的评审机制：把原则写成评审清单（checklist）、在评审会上逐条对照、记录偏离原则的决策及其理由，并定期回顾原则本身是否仍然适用。缺少评审环节时，原则容易停留在文档层面而无法约束实际决策。^{5151Design Principlesprinciples.design前往参考资料 ↓在新标签页中打开|181810 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开}

评审流程中，原则的作用是提供共同语言和判断基准，而不是替代具体情境下的权衡；评审者需要区分「违反原则但有意为之且有记录理由」与「无意违反」两种情况，前者不应被简单否决。^{5757Google Engineering Practices: Code Reviewgoogle.github.io前往参考资料 ↓在新标签页中打开}

把设计原则纳入团队评审流程的常见做法包括：在需求或设计文档模板中设置「原则符合性」一节、在评审会上指定一名原则守护者（原则负责人）逐条提问、以及把原则检查项加入合并请求（merge request）的检查清单。^{5151Design Principlesprinciples.design前往参考资料 ↓在新标签页中打开|5757Google Engineering Practices: Code Reviewgoogle.github.io前往参考资料 ↓在新标签页中打开}

对设计原则最常见的批评是「空泛化」：原则往往停留在抽象口号层面，缺乏可操作的定义与判定标准，因而难以指导具体设计决策，也难以用来评价一个设计的好坏。^{5858Design Principles: The Philosophy of UXuxmag.com前往参考资料 ↓在新标签页中打开|77Design Principlesinteraction-design.org前往参考资料 ↓在新标签页中打开}

以迪特·拉姆斯「好设计的十原则」为例，其表述高度凝练（如「好设计是尽可能少的设计」「好设计是诚实的」），并未给出在具体产品情境下如何权衡这些原则的规则，批评者据此认为它更接近价值宣言而非工程规范。^{5959The Ten Principles of Good Designvitra.com前往参考资料 ↓在新标签页中打开|6060Dieter Rams: Ten Principles for Good Designdesignmuseum.org前往参考资料 ↓在新标签页中打开}

尼尔森十大可用性启发式被批评为过于笼统：诸如「系统状态可见性」「错误预防」等条目本身正确，但不同设计师对同一条目的理解与落实方式差异很大，导致其作为评估工具时评分者间一致性有限。^{181810 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开|6161Heuristic Evaluation of User Interfacesdl.acm.org前往参考资料 ↓在新标签页中打开}

空泛化批评的深层问题在于原则的可证伪性：一条原则若无法被任何观察结果推翻，它就失去了约束设计行为的力量，容易沦为事后合理化的修辞。^{6363The Design of Design: Essays from a Computer Scientistpearson.com前往参考资料 ↓在新标签页中打开}

为回应空泛化批评，部分研究者主张把原则拆解为可检验的「模式」或「检查项」，并配合具体情境的示例与反例，使原则从口号转化为可操作的判据。^{6464A Pattern Language: Towns, Buildings, Constructionglobal.oup.com前往参考资料 ↓在新标签页中打开|6565Design Patterns: Elements of Reusable Object-Oriented Softwarepearson.com前往参考资料 ↓在新标签页中打开}

也有观点认为空泛化本身并非缺陷：原则的功能是划定价值边界与讨论框架，而非替代具体情境中的判断；要求原则给出唯一正确答案，是对原则性质的误解。^{6666The Reflective Practitioner: How Professionals Think in Actionbasicbooks.com前往参考资料 ↓在新标签页中打开}

设计原则的不可通约性首先表现为评价标准的领域依赖性：工业设计传统中的「好设计十原则」以耐久、诚实、环保等物质产品属性为轴心，而交互设计领域（如尼尔森十大可用性启发式）则以系统状态可见性、用户控制与自由、错误预防等认知与操作属性为轴心，两套标准各自内部自洽，却无法用同一把尺子衡量对方领域的设计质量。^{6767The Ten Principles for Good Designvitsoe.com前往参考资料 ↓在新标签页中打开|181810 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开}

拉姆斯原则中的「诚实」要求产品不夸大自身能力与价值，而软件与数字产品普遍采用引导性文案、默认勾选与暗黑模式（dark patterns）来影响用户决策；同一件数字产品可以同时满足「美观」「易懂」却系统性违背「诚实」，说明原则之间不仅跨领域不可通约，在同一产品内部也可能相互冲突。^{6767The Ten Principles for Good Designvitsoe.com前往参考资料 ↓在新标签页中打开|6868Dark Patterns at Scale: Findings from a Crawl of 11K Shopping Websitesarxiv.org前往参考资料 ↓在新标签页中打开}

软件工程语境下的设计原则（如 SOLID、高内聚低耦合、关注点分离）以可维护性、可扩展性与变更成本为优化目标，其评价对象是代码结构与模块边界；界面设计原则以用户任务完成效率与主观满意度为优化目标，评价对象是人与系统的交互过程。两者共享「原则」之名，但优化目标与评价对象不同，不能直接互相推导或互相证成。^{6969Design Principles and Design Patternsweb.archive.org前往参考资料 ↓在新标签页中打开|1717The Design of Everyday Things: Revised and Expanded Editionbasicbooks.com前往参考资料 ↓在新标签页中打开}

安全设计原则（如最小权限、默认安全、纵深防御）以威胁模型与攻击面为出发点，其正确性依赖对 adversary 的假设；而可用性设计原则以正常用户的行为与认知负荷为出发点。当安全要求强制增加认证步骤、缩短会话或限制功能时，可用性原则所追求的效率与容错会被直接牺牲，二者在同一界面上往往呈现此消彼长的关系，而非可以同时最大化的正交维度。^{7070Saltzer and Schroeder, The Protection of Information in Computer Systemsweb.mit.edu前往参考资料 ↓在新标签页中打开|7171NIST Special Publication 800-160 Vol. 1 Rev. 1: Engineering Trustworthy Secure Systemscsrc.nist.gov前往参考资料 ↓在新标签页中打开}

原则的抽象层级差异加剧了不可通约性：越抽象的原则（如「简单」「一致」）越容易跨领域迁移，但也越难直接指导具体决策；越具体的原则（如「表单标签应置于输入框上方」「错误信息应说明原因与修复方式」）越可操作，却越绑定特定媒介与交互范式。因此跨领域借用原则时，往往只能借用其抽象表述，而丢失其可检验的操作含义。^{181810 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开|7272About Face: The Essentials of Interaction Design, 4th Editionwiley.com前往参考资料 ↓在新标签页中打开}

在原则冲突的裁决上，学界与实务界存在公开分歧：一方主张建立跨领域的元原则或统一评价框架来排序冲突，另一方认为不同领域的原则根植于不同的实践传统与目标函数，强行统一会抹平领域特异性，主张在各自领域内局部裁决。这一分歧本身即是不可通约性命题在方法论层面的体现。^{7373Design Principles: Literature Review, Analysis, and Future Directionsasmedigitalcollection.asme.org前往参考资料 ↓在新标签页中打开|7474Universal Principles of Design, Revised and Updatedquartoknows.com前往参考资料 ↓在新标签页中打开}