TRIZ理论矛盾矩阵与发明原理：从工程参数到PPT落地

简介这份PPT系统梳理了以根里奇·阿奇舒勒研究成果为基础的技术创新方法TRIZ理论面向企业管理者、研发工程师、高校教师及需要提升创新思维的在校学生帮助读者跳出试错法、头脑风暴等经验型思路用可复用的原则与法则定位并化解技术矛盾。压缩包内含1个pptx文件约1.96MB页面围绕TRIZ的产生脉络、理论解释、应用领域、核心思想与国内发展现状展开并配有凿岩机演进、羽毛笔到圆珠笔、汽车刹车系统零件精简、非典型肺炎防治及总统竞选等案例便于直接用于课堂讲授或内部培训。内容重点落在40条发明创造原理、技术系统进化规律与用最少资源实现最多功能的理想化思路读者可据此搭建完整知识框架掌握从矛盾识别到方案生成的推演路径。目前已有87人学习适合作为创新方法入门与教学参考的成套课件。1. 当评审卡在「加缓存还是保一致」TRIZ理论 给的是一张可查的表技术评审最容易陷入的僵局不是方案太少而是两个指标互相拉扯订单服务要压 P99 延迟风控要求强一致读谁让步都有人反对。这类争执在 TRIZ理论 里有个准确的名字——技术矛盾某个工程参数被改善另一个参数必然恶化。它的价值不在于替你拍板而在于先钉死「我们吵的到底是哪两个参数」再给出一组跨行业反复被验证过的解法方向。这套方法由阿奇舒勒Genrich Altshuller从大量专利中归纳而来核心假设是不同行业的技术问题在抽象层面会重复出现所以解法可以迁移——机械领域的「预先作用」在软件里就是预热与预计算。《技术创新方法TRIZ理论概论.pptx》这类材料的读者通常是三类人组织内部培训的技术负责人、被临时指派讲一场创新方法的架构师、以及想把「拍脑袋选型」变成可复现流程的研发团队。它要讲清的不是哲学而是一条从问题描述到方案收敛的作业链参数化 → 查矩阵 → 挑原理 → 写理想解 → 回测。2. TRIZ理论 的三层骨架参数、矩阵与发明原理TRIZ 不是一套方法论口号而是三个可以拆开使用的零件39 个工程参数负责把自然语言问题转成结构化输入矛盾矩阵负责索引历史解法40 个发明原理负责给出可执行的动作方向。分成三层之后你就能判断自己的问题该走哪条路而不是拿到一张庞大的知识图谱无从下手。2.1 技术矛盾和物理矛盾先分清入口再决定用矩阵还是分离原理技术矛盾是「A 变好B 变差」典型形式是「提高吞吐 → 增加资源占用」。这类问题走 39×39 矛盾矩阵输入是一对参数编号输出是一组发明原理编号。物理矛盾是「同一个参数既要高又要低」比如「缓存要大以降低延迟又要小以节省内存」。这时矩阵帮不上忙要改用四大分离原理空间分离、时间分离、条件分离、整体与部分分离。缓存这条矛盾的解法往往落在空间分离热数据本地、冷数据远端或条件分离命中率低于阈值才回源。矛盾类型判定句式软件里的常见例子对应工具技术矛盾A 改善B 恶化吞吐上去一致性下降39×39 矛盾矩阵物理矛盾同一参数既要 X 又要非 X缓存既要大又要小四大分离原理物场问题两个元素作用不足或有害服务间耦合导致故障扩散76 标准解、物场分析分不清这两类最常见的结果是把物理矛盾硬塞进矩阵查出来的原理编号看着都对用起来全别扭。2.2 39 个工程参数怎么映射到软件指标矩阵的输入是编号不是文字。从业者最容易卡住的一步就是「我们的问题算第几号参数」。稳妥做法是先列指标再往最接近的参数上靠不要为了凑一个好看的编号去改问题描述。编号参数名软件场景里的常见说法9速度响应时间、吞吐、QPS10力资源投入、人力、算力预算23物质损失数据丢失、脏数据、重复计算24信息损失链路信息缺失、可观测性盲区25时间损失排队等待、构建与发布耗时27可靠性SLA、可用性、故障恢复能力36装置的复杂性架构复杂度、运维成本、依赖数量37监控与测试的困难可测试性、灰度验证成本38自动化程度自动化流水线覆盖度39生产率单位时间处理的业务量读矩阵的规则是固定的改善参数取行恶化参数取列格子里的数字就是推荐原理编号。实践中有两条硬约束——一次只放一对参数别把三四个指标一起塞进去改善与恶化不能对调对调后查到的是另一组原理。某些格子是空的这通常不是数据缺失而是提示你这更像物理矛盾。2.3 40 个发明原理按动作类型分组记别按编号背40 条原理硬背没有意义按「动作发生在什么维度」分组调用时才有反射速度。结构类管拆分与组合时间类管顺序与时机物场类管状态与材料替代。下面这段映射可以直接当团队内部的口诀用。# 按动作维度给 40 个发明原理分组方便现场挑选 PRINCIPLES_BY_DIMENSION { 结构: { 1: 分割把整体拆成可独立替换的部分对应微服务拆分, 3: 局部质量只在关键路径上做优化不做全局统一, 5: 合并把同类操作合并对应批处理与合并写, 7: 嵌套一层套一层对应多级缓存, 17: 维数变化从一维扩到多维对应多维索引与分区键, }, 时间: { 10: 预先作用预热、预计算、提前加载, 11: 预先应急措施熔断、降级、限流预案, 15: 动态化让原本固定的参数随负载变化对应动态超时, 19: 周期性作用定时任务改为周期性脉冲对应心跳与轮询, 20: 有效作用的连续性消除流水线空转, }, 物场与状态: { 22: 变害为利把失败请求转成重试样本, 23: 反馈把结果回灌上游做闭环对应幂等校验, 25: 自服务系统自愈对应自动扩缩容, 26: 复制用副本换可用性, 35: 参数变化改状态不改组件对应特性开关, }, }分组之后查矩阵拿到编号就能立刻说出「这条原理在我们系统里长什么样」。做不到这一步PPT 上写十条原理也只是名词表。2.4 IFR 与资源分析把理想解写成一句可证伪的话理想最终解IFR的句式很克制「某组件自己完成某功能同时不增加成本、不引入新的有害功能」。写成这样有两个好处——可以被证伪也可以被拆成任务。拿缓存举例IFR 不是「加一层 Redis」而是「数据在被读到时已经是最新的且不增加额外组件」。配套的是资源分析。软件系统里最容易被忽略的免费资源是已经在系统里的数据日志、埋点、用户历史行为、已经存在的空闲时间窗批处理窗口、发布间隙、已经部署的副本。先盘资源再谈新增组件方案成本通常能砍掉一半。3. 用 Python 把 TRIZ理论 的矛盾矩阵做成可查询工具把矩阵背下来不现实做成一个本地可查的小工具才是可持续的做法。数据量很小39 个参数、40 条原理、千级矩阵格子SQLite 单文件足够查询延迟可以忽略。这样做的另一个好处是矩阵数据可以按自己行业替换成内部版本而不必迁就公开资料。3.1 三张表参数、原理、矩阵怎么落库结构设计的要点是把「编号—名称」与「编号—动作」分开存矩阵只存编号避免同一份语义在多处重复。-- 参数表id 与矩阵行列号严格一致1..39 CREATE TABLE triz_parameter ( id INTEGER PRIMARY KEY, name TEXT NOT NULL, -- 中文名如“速度” alias TEXT -- 软件场景叫法如“响应时间/吞吐” ); -- 原理表action 写可落地的动作不要写名词解释 CREATE TABLE triz_principle ( id INTEGER PRIMARY KEY, name TEXT NOT NULL, action TEXT NOT NULL ); -- 矩阵表一格一行principles 用逗号分隔的原理编号 CREATE TABLE triz_matrix ( improve INTEGER NOT NULL, -- 改善参数行 worsen INTEGER NOT NULL, -- 恶化参数列 principles TEXT NOT NULL, -- 例1,10,35 PRIMARY KEY (improve, worsen) ); -- 反向查询先看恶化项时用得到 CREATE INDEX idx_matrix_reverse ON triz_matrix (worsen, improve);三张表加起来不到 1500 行数据用 CSV 导入即可。注意principles用逗号串而不是关联表是为了录入快如果后续要按原理做统计哪条原理被推荐次数最多再补一张matrix_principle关联表更合适。3.2 一次查询从参数对到候选原理查询函数要处理的最重要情况是「查不到」。查不到不该返回报错而应提示转向分离原理。import sqlite3 # 矩阵给的是编号编号要配上动作才有意义 PRINCIPLE_ACTION { 1: 分割拆成可独立替换的部分, 10: 预先作用把动作提到请求之前, 15: 动态化让固定参数随负载变化, 23: 反馈把结果回灌到上游做闭环, 35: 参数变化改状态而不是加组件, } def query_principles(conn, improve: int, worsen: int) - list[dict]: 输入改善参数编号与恶化参数编号返回候选原理列表。 cur conn.cursor() cur.execute( SELECT principles FROM triz_matrix WHERE improve ? AND worsen ?, (improve, worsen), ) row cur.fetchone() if row is None: # 空结果通常意味着该问题更接近物理矛盾 print(f矩阵无推荐({improve}, {worsen})转用四大分离原理) return [] ids [int(x) for x in row[0].split(,) if x.strip()] return [{id: i, action: PRINCIPLE_ACTION.get(i, 未收录)} for i in ids] if __name__ __main__: conn sqlite3.connect(triz.db) # 改善“速度(9)”恶化“可靠性(27)” for item in query_principles(conn, 9, 27): print(item[id], item[action])逻辑上分三步用参数对精确命中矩阵行把逗号串拆成整数列表再用动作字典补全语义。PRINCIPLE_ACTION只放团队常用的十几条剩余的原理按需补不必一次全量维护。参数说明improve与worsen必须是 139 的整数顺序不能颠倒对调后查到的是另一组编号在评审现场会造成误导。如果想让工具更耐用建议在query_principles外面再包一层校验参数越界直接抛异常而不是返回空列表——空列表有语义物理矛盾越界没有。3.3 参数怎么定、结果怎么筛四个容易踩的坑第一参数选最接近的不要选最顺眼的。有人习惯把架构问题一律映射到「36 装置的复杂性」结果所有问题查出来的原理都指向「简化架构」工具就失去了分辨力。第二一次只查一对参数多对参数的结果混在一起没法排序。第三改善与恶化别写反拿不准就先按一种顺序查再反过来查一次做对照。第四拿到五到八条原理后必须做收敛按「改动范围」和「可验证性」两列打分只保留前三名进方案设计否则会开成头脑风暴会。收敛维度打分方式15说明改动范围越小分越高只改配置优于改代码改代码优于改架构可验证性能灰度验证得高分无指标可观测的方案一律降权回退成本回退越容易分越高涉及数据迁移的要额外扣分4. 生成《技术创新方法TRIZ理论概论.pptx》从大纲到可讲的页面有了可查询的矩阵和 40 条原理的动作映射PPT 的定位就清晰了它不是知识搬运而是现场演示工具的说明书。这一章按「页序设计 → 骨架生成 → 排版参数」推进目标是拿到一份能直接讲的 16:9 文件。4.1 90 分钟讲稿的页序把 40 个原理砍到 8 个90 分钟的场次页数控制在 38 页左右页面密度不要满每页配 1.52 分钟讲解。40 条原理全讲一遍是新人最常犯的错正确的做法是挑 8 条与听众业务相关的讲透其余以索引表形式附在最后备查。模块页码时长现场动作开场一个真实僵局148 分钟抛问题请听众举手表态TRIZ 定位与三层骨架51215 分钟讲清参数、矩阵、原理的关系39 个工程参数131812 分钟现场把听众的指标映射成编号矛盾矩阵演示192420 分钟用工具现场查一对参数精选 8 条发明原理253220 分钟每条配一个团队内部案例理想解与回测333610 分钟现场写一句 IFR 句式落地建议与附录索引37385 分钟给一个可以本周试用的动作注意案例必须用听众熟悉的系统。拿别的行业的例子讲「嵌套」听众会当成故事拿自家多级缓存讲他们当场就能接话。4.2 用 python-pptx 生成骨架封面、目录、内容页页面多起来之后手工调格式的时间会超过写内容的时间。骨架化生成能把标题页、章节页、内容页的版式统一后面只在生成的 pptx 里改文字。from pptx import Presentation from pptx.util import Inches, Pt from pptx.oxml.ns import qn prs Presentation() prs.slide_width Inches(13.333) # 16:9默认 4:3 会挤掉表格最后一列 prs.slide_height Inches(7.5) TITLE_LAYOUT prs.slide_layouts[0] # 标题幻灯片 BODY_LAYOUT prs.slide_layouts[1] # 标题和内容 def set_cjk_font(run, name: str 思源黑体): python-pptx 只设 latin 字体中文要额外写 a:ea 才不会回退成宋体 run.font.name name run.font.element.rPr.rFonts.set(qn(a:ea), name) def add_title_slide(title: str, subtitle: str): slide prs.slides.add_slide(TITLE_LAYOUT) slide.shapes.title.text title slide.placeholders[1].text subtitle return slide def add_bullets(title: str, bullets: list[str], sizePt(20), spacing1.2): 一页最多 5 条每条不超过 40 字超了就拆页不要把字号调小 slide prs.slides.add_slide(BODY_LAYOUT) slide.shapes.title.text title tf slide.placeholders[1].text_frame tf.word_wrap True for i, text in enumerate(bullets): p tf.paragraphs[0] if i 0 else tf.add_paragraph() p.text text p.line_spacing spacing for run in p.runs: run.font.size size set_cjk_font(run) return slide add_title_slide(技术创新方法TRIZ理论概论, 从 39 个工程参数到 40 个发明原理) add_bullets(TRIZ 的三层骨架, [ 参数层把自然语言问题转成编号, 矩阵层一对参数换一组解法索引, 原理层把索引翻译成系统里的动作, ]) prs.save(triz_intro.pptx)这段代码的关键点有三处。slide_layouts的索引在不同模板下不一样先跑一次for i, l in enumerate(prs.slide_layouts): print(i, l.name)确认再写死。set_cjk_font处理的是中文回退问题只设font.name时中文常被打回默认字体。add_bullets里把字号和行距做成参数是为了让不同章节用同一套视觉规格而不是每页手动调。参数说明正文 20pt、行距 1.2 适合 30 人以上的会议室如果场地更小或要打印讲义正文提到 22pt、行距 1.35。标题层级建议固定为 32pt / 28pt / 24pt 三档超过三档会让页面看起来像文档。4.3 字号、行距与占位符几个固定的排版参数占位符的边界不要随意拖动改版式里的母版更省事。表格列宽建议用比例分配而不是固定值中文列容易撑开固定值在别的机器上会换行。页面底部留 1.2 厘米的安全区避免投影仪裁边吃掉最后一行。5. 进阶把 TRIZ 解出来的方案做一次理想度回测方案聊出来不等于可以开工。TRIZ 里衡量「好不好」的尺子是理想度有用功能总和除以成本与有害功能之和。这个比值不追求精确追求的是把几个方案拉到同一把尺子上比较。5.1 理想度打分把候选方案拉回同一把尺子打分粒度用 15 分即可超过这个精度讨论成本会超过收益。有用功能包含业务价值和可维护性成本包含开发、机器与运维投入有害功能包含新增故障面和一致性风险。def ideality(useful: float, cost: float, harm: float) - float: 理想度 有用功能 /成本 有害功能。 三项都是 1~5 分打分后的累加值分母加极小量避免除零。 return useful / (cost harm 1e-9) # 方案 A加本地缓存 动态 TTL # 方案 B改造为强一致读牺牲延迟 print(round(ideality(useful9, cost6, harm3), 2)) # A print(round(ideality(useful7, cost9, harm6), 2)) # B打分要由非方案提出者来做否则每一项都会往有利方向偏。同一组方案至少两个独立打分取平均后再比。5.2 一个完整走查缓存一致性矛盾的理想度回测回到第 1 章那个僵局。改善「速度9」恶化「可靠性27」查矩阵得到一组候选原理取其中四条10 预先作用、15 动态化、23 反馈、35 参数变化。翻译成动作就是热点数据在请求到达前预热TTL 按命中率和数据变更频率动态调整数据变更时通过消息回灌失效通知用特性开关控制开关范围而不是改代码。回测三步。第一步写 IFR 句式数据在被读到的时候已经是最新的且不新增独立组件。第二步按 5.1 打分热数据预热加动态 TTL 的组合在改动范围上明显优于改造强一致读。第三步设计验证口径缓存命中率、写后读延迟的 P99、失效通知的丢失率三个指标同时观察一周任一指标劣化超过阈值就回退开关。走完这一轮会发现TRIZ 提供的不是答案而是一条把争论压成参数的路径——参数选错后面全错参数选对方案往往落到团队已有的能力范围里不需要引入新组件。判断一个 TRIZ 分享做得好不好标准也很简单听众散场时手里能不能带走一对参数编号。本文还有配套的精品资源点击获取