[{"content":"","date":"2026 年 8 月 8日","externalUrl":null,"permalink":"/tags/blender/","section":"Tags","summary":"","title":"Blender","type":"tags"},{"content":" 01 Blender4.0后存在2个插件目录 # extensions/目录 # 说明：Blender4.0后通过获取拓展安装的插件存放目录\n功能：统一管理插件、资产库、预设、主题等所有扩展资源，自动处理依赖、版本更新、启用禁用，无需手动解压复制文件。\n子目录说明： blender_org/： 官方扩展源（blender.org 商店）安装的内容 user_default/：自定义/第三方扩展源安装的内容 注意：不建议手动修改里面的文件，更新、卸载都在 Blender 界面内的「扩展」面板操作\nscripts/addons/目录 # 说明：Blender 沿用十几年的传统插件目录，存放手动安装的第三方插件 —— 也就是我们下载 zip 压缩包后，通过「偏好设置 → 插件 → 安装」按钮选择安装，或者直接解压复制进去的插件。\n特点： 纯手动管理：安装、更新、卸载都需要手动替换文件夹，Blender 只负责加载，不做版本管理。 仅支持插件：只能放 Python 脚本格式的插件，不能放资产包、主题等其他资源。 无依赖自动处理：如果插件需要额外 Python 库，需要用户自己手动安装。 兼容性最强：所有 Blender 版本都支持，绝大多数老旧插件、国内汉化插件都采用这种格式发布。\n02 如何安装 # 看zip根目录下有没有blender_manifest.toml文件\n老式插件： # 核心标志是只有 __init__.py，没有 blender_manifest.toml 正确安装方式： graph LR 编辑 --\u003e 偏好设置 --\u003e 插件 --\u003e 从磁盘安装 新版扩展包： # 根目录一定存在 blender_manifest.toml 清单文件 正确安装方式： graph LR 编辑 --\u003e 偏好设置 --\u003e 扩展 --\u003e 从磁盘安装扩展包 通常情况可以互相兼容 安装时会自动匹配位置\n03 自定义的脚本目录 # 插件（旧版）： # graph LR 编辑 --\u003e 偏好设置 --\u003e 文件路径 --\u003e 脚本目录 要创建..\\scripts\\addons文件路径，插件文件解压到该目录或者在blender里安装时选择合适的目标路径\n拓展（新版） # graph LR 编辑 --\u003e 偏好设置 --\u003e 获取拓展 --\u003e 存储库 直接添加就行\n","date":"2026 年 8 月 8日","externalUrl":null,"permalink":"/posts/blender-%E6%8F%92%E4%BB%B6%E5%AE%89%E8%A3%85%E6%B3%A8%E6%84%8F%E4%BA%8B%E9%A1%B9/","section":"Posts","summary":"","title":"Blender 插件安装注意事项","type":"posts"},{"content":"","date":"2026 年 8 月 8日","externalUrl":null,"permalink":"/","section":"Foundation","summary":"","title":"Foundation","type":"page"},{"content":"","date":"2026 年 8 月 8日","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"2026 年 8 月 8日","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2026 年 8 月 8日","externalUrl":null,"permalink":"/tags/%E6%8F%92%E4%BB%B6/","section":"Tags","summary":"","title":"插件","type":"tags"},{"content":"","date":"2026 年 4 月 10日","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"AI","type":"tags"},{"content":"在AI时代，我们在或多或少的听过或者见过一些AI相关的词汇。刷AI资讯、用AI工具时，总被一堆专业术语绕晕，Transformer、LLM、RAG、Agent……明明每个字都认识，连起来却像看“天书”？本篇文章就来揭开这些术语的神秘面纱。\nTransformer # AI界的“底层建筑”，相当于所有现代大模型的“骨架”。最初由 Vaswani 等人在 2017 年的论文《Attention is All You Need》中提出。\n通俗说：就像盖房子的“钢筋水泥”，ChatGPT、文心一言、字节跳动豆包等所有主流大模型，都是在Transformer的基础上搭建起来的。它的核心优势是“并行计算”，能同时处理海量信息，还能通过自注意力机制，精准捕捉文本、图像中的上下文关联，让AI理解更全面、反应更快。\nTransformer 彻底改变了自然语言处理（NLP）领域，并逐渐扩展到计算机视觉（CV）等领域。\nTransformer 的核心思想是完全摒弃传统的循环神经网络（RNN）结构，仅依赖注意力机制来处理序列数据，从而实现更高的并行性和更快的训练速度。\nLLM（大语言模型） # 全称Large Language Model，直译就是“大语言模型”，也是我们最常接触的AI类型。\n通俗说：就是“会说话、会思考的AI大脑”，比如豆包、ChatGPT，核心能力是理解人类语言、生成文本、回答问题，还能完成代码、文案等创作。它的“大”，体现在训练数据海量、参数量庞大，能覆盖各行各业的知识，相当于一个“行走的百科全书”。\n大语言模型（LLM）通常指包含数百亿（或更多）参数的语言模型，它们往往在数万亿（T）token的语料上通过多卡分布式集群进行预训练。这些模型具备远超出传统预训练模型的文本理解与生成能力。广义上的LLM参数量可从十亿（如Qwen-1.5B）到千亿（如Grok-314B）不等，核心判断标准是模型是否展现出涌现能力。\nPrompt # 你和AI沟通的“指令”，也是AI干活的“说明书”，是人类与人工智能沟通的核心桥梁。通俗说：就像你给助理下达的工作要求， Prompt写得越清晰、越具体，AI的输出就越符合你的预期。\n在人工智能（AI）领域中，\u0026ldquo;prompt\u0026rdquo; 是指向模型提供输入以引导其生成特定输出的文本或指令。它是与模型进行交互时用户提供的文本段落，用于描述用户想要从模型获取的信息、回答、文本等内容。Prompt 的目的是引导模型产生所需的回应，以便更好地控制生成的输出。\n对于语言模型，prompt 可以是一个简短的问题、一个完整的段落，或者是一组指令，这取决于用户的需求和场景。在生成文本时，模型会试图理解 prompt 并根据其理解生成相应的响应。\nuser \u0026amp; system**（对话双角色）**，这两个是Prompt里的核心角色，尤其在多轮对话中至关重要，二者配合才能让AI精准输出：\nuser（用户）：就是你本人，是对话的发起者，负责提出需求、提问、反馈，比如“帮我写一首关于春天的诗”，这就是user的指令。\nsystem（系统）：隐藏的“规则制定者”，负责设定AI的行为模式、回答风格、边界限制，相当于给AI“定规矩”。比如设定“你是一位专业营养师，只回答与饮食健康相关的问题，语气简洁通俗”，这就是system指令，会全程约束AI的输出。\nToken # 大模型处理信息的最小信息单元，也是AI“计数”的方式，具有智能时代可计量、可定价、可交易的特征——不管是你输入的Prompt，还是AI输出的内容，都会被拆成一个个Token来处理。\n通俗说：就像我们说话的“字、词、标点”，但AI的拆分更细致，比如“我爱吃西瓜”，可能会被拆成“我/爱/吃/西瓜”4个Token，标点符号也会算作独立Token。很多AI工具的收费、输出限制，都是按Token来计算的。\n国家数据局明确将AI领域的Token定名为“词元”。词元可以是一个汉字、一个标点，亦或是一个词汇片段，用户向AI的每一次提问、AI生成的每一段内容、识别的每一幅图像，本质都是词元的调用与运算。\nContext/Context Window # Context是AI能“记住”的对话内容，Context Window就是AI的“记忆容量”，Context Window 组成部分是 历史会话+当前输入+模型输出。\n他们以Token为单位，决定了AI能处理的输入长度和对话连贯性。\n通俗说：就像人的“短期记忆”，上下文窗口越大，AI能记住的对话细节越多，越能理解长文本、多轮对话。比如上下文窗口小的AI，聊了10句话就会忘记前面的内容；而大窗口AI，能记住你半小时内的所有提问，甚至能一次性处理几万字的文档。\nTool # Tool即AI工具，是延伸AI模型能力、实现AI技术落地应用的核心载体，是连接AI模型与实际应用场景的关键桥梁。其并非单一的交互类工具，而是涵盖多专业领域、具备特定功能的模块化组件，每一款AI工具对应一项具体的功能，实现AI模型从“语言交互”到“实际应用”的落地。\nAI工具的核心价值在于拓展AI模型的应用边界，常见类型包括搜索工具、代码工具、绘图工具、表格工具等。搜索工具可帮助AI模型获取实时信息与权威数据；代码工具可实现代码生成、程序排查等功能；绘图工具可完成图像创作、视觉设计等任务。借助各类AI工具，AI模型能够突破单一交互功能的局限，广泛应用于职场办公、内容创作、数据分析等多个领域。\nRAG（检索增强生成） # RAG全称为Retrieval-Augmented Generation，即检索增强生成，是当前AI领域解决模型“幻觉问题”（虚假信息生成）的核心技术，其核心逻辑是将“信息检索”与“内容生成”两大功能深度融合，提升AI模型输出的准确性与专业性。\nRAG技术的核心流程的是：AI模型在生成输出内容前，先从预设的数据库、官方文档、权威数据源中检索与用户需求相关的真实信息，经过筛选、整理后，基于检索到的权威信息进行内容生成，从根源上避免虚假信息的产生。该技术在医疗、法律、金融等对信息准确性要求极高的领域应用广泛，可确保AI模型输出内容的权威性与严谨性，例如医疗领域可通过RAG技术检索最新医学指南，为临床咨询提供精准支撑。\nMCP（模型上下文协议） # MCP全称为Model Context Protocol，即模型上下文协议，是Anthropic公司于2024年11月发布的开放协议，是AI领域用于统一AI模型与工具连接标准的核心协议，可有效打破不同AI模型与工具之间的兼容性壁垒。\n在MCP协议出现之前，不同AI模型与同一工具的适配需单独开发适配代码，存在重复开发、效率低下的问题。MCP协议通过统一连接标准，实现了工具的一次开发、多模型适配，即工具开发者按照MCP协议完成开发后，所有支持该协议的AI模型（包括豆包、ChatGPT、Claude等）均可直接调用该工具，大幅提升了AI工具的适配效率与普及速度。\nAgent（智能体） # Agent即智能体，是当前AI领域的前沿方向，以大语言模型为核心，整合AI工具与Agent Skill（智能体技能），具备自主理解需求、拆解复杂任务、调度工具、执行落地、复盘优化的全流程能力，区别于普通AI模型的“被动应答”，实现了“主动执行”的核心突破。\nAgent的核心优势在于自主化与闭环化，用户仅需提出核心需求，Agent即可自主完成任务拆解、工具调度、结果优化等全流程操作。例如，用户提出“完成本周互联网运营周报并提交至领导”，Agent可自主调取工作数据、梳理工作成果与问题、规范排版，完成周报撰写与提交，无需人类额外干预，大幅提升工作效率。\nAgent Skill（智能体技能） # Agent Skill即智能体技能，是Agent实现任务落地的核心支撑，是区分Agent与普通AI模型、AI工具的关键要素。其与AI工具存在本质区别：AI工具是具备单一功能的模块化组件，而Agent Skill是“工具+使用逻辑+专业经验”的完整封装，是Agent执行具体任务的核心能力单元。\n每一项Agent Skill均聚焦于单一具体任务，具备可复用、可组合的特点。例如，“Excel数据汇总”“文案排版”均为独立的Agent Skill，Agent可通过组合不同的技能，完成复杂的全流程任务，如“数据汇总→文案撰写→排版→提交”，实现多任务的高效协同落地。\nMOE（混合专家模型） # MOE全称为Mixture of Experts，即混合专家模型，是一种高效节能的AI模型架构，核心逻辑是“分工协作、专人专岗”，可在控制算力与存储成本的同时，显著提升模型的能力上限，是当前大型AI模型突破性能瓶颈的核心技术之一。\nMOE模型由“专家子模型”与“门控网络”两部分组成：专家子模型专注于特定细分领域，每个子模型均具备该领域的专业处理能力；门控网络作为调度核心，负责分析用户需求类型，将需求分配给最适配的专家子模型进行处理，最终整合处理结果输出给用户。这种架构可避免单一模型“多领域兼顾但精度不足”的问题，在提升输出质量与效率的同时，大幅节省算力资源。\n模型参数 # 模型参数是AI模型的核心组成部分，是模型训练前未知、训练过程中通过学习海量数据逐步优化得到的可调节数值变量，是模型实现信息推理、内容生成的核心载体，直接决定了模型的能力强弱、泛化能力与输出精度。\n模型参数的数量与质量直接影响模型性能：百万级参数模型仅能完成简单的文本分类、基础问答等任务；千万级、亿级参数模型可实现文案创作、代码生成等中等难度任务；千亿级、万亿级参数的大型模型则具备复杂逻辑推理、多语言翻译、专业领域问答等高级能力。需注意的是，模型参数并非越多越好，需与训练数据量、应用场景相匹配，否则会造成算力浪费与参数冗余，影响模型输出效率。\n思维链长度 # 思维链长度是指AI模型解决复杂问题时的推理步骤数量，本质上是模型拆解问题、分析推理的完整流程，是衡量AI模型推理能力与严谨性的核心指标。\n思维链长度越长，表明AI模型对复杂问题的拆解越细致、推理越严谨，能够处理的问题难度越高，输出结果的准确性与逻辑性越强；反之，思维链长度较短时，AI模型易跳过关键推理步骤，导致输出结果出现偏差或不严谨。例如，在制定半年AI学习计划时，长思维链模型会拆解用户基础、学习目标、时间分配、资料筛选等关键步骤，输出可落地的完整计划；短思维链模型则可能仅罗列学习资料，缺乏系统性与可操作性。\n最大输出长度 # 最大输出长度是指AI模型一次可连续生成的内容容量上限，通常以Token为计量单位，是衡量AI模型输出能力的重要指标，与上下文窗口密切相关但存在明确区别：上下文窗口是AI模型可处理的“输入+输出”总容量，而最大输出长度仅针对AI模型的输出内容，不包含用户输入的Prompt。\n当AI模型生成内容达到最大输出长度时，会自动停止生成，用户需通过追加指令（如“继续补充”），方可引导模型在原有基础上继续生成内容。这也是部分AI工具生成长篇内容时，需分多次输出的核心原因。\n量化 # 量化是AI模型的核心压缩技术，其核心原理是将模型中高精度数值（如32位浮点数，精度高但占用空间大）转换为低精度数值（如8位整数、4位整数，精度略有损耗但占用空间大幅缩减），在最大限度保留模型核心能力的前提下，降低模型的算力消耗与存储成本。\n量化技术是AI工具普及至普通设备的关键，通过量化处理，原本需高端服务器支撑的大型AI模型，可在普通电脑、手机、平板等设备上流畅运行，无需依赖专业硬件设备。例如，手机端AI输入法、AI修图工具等，均通过量化技术实现轻量化部署，兼顾使用体验与设备兼容性。\n蒸馏 # 蒸馏即模型蒸馏，是AI模型的核心知识传递技术，核心目标是实现“降本增效”，通过技术手段将大型高性能“教师模型”的知识（推理逻辑、输出规律、专业经验等），传递给小型轻便的“学生模型”，使学生模型在低成本前提下，具备接近教师模型的核心能力。\n其中，教师模型通常为千亿级参数的大型模型，能力强但运行成本高、速度慢，适用于专业场景；学生模型为百万级、千万级参数的小型模型，成本低、速度快但能力有限。通过蒸馏技术，学生模型可快速复制教师模型的核心能力，无需从零开始训练，大幅降低AI模型的研发与部署成本，助力中小团队与普通用户获取高性能AI模型。\nRL（强化学习） # RL全称为Reinforcement Learning，即强化学习，是AI模型自主学习的核心方式之一，与监督学习（需人工标注数据）、无监督学习（无需人工标注）并列，核心逻辑是“试错学习、奖惩反馈”，通过不断尝试与反馈调整，优化模型行为，最终找到解决问题的最优方案。\n强化学习的核心流程为：AI模型自主尝试处理特定任务，若输出结果符合预期，则获得正向奖励；若结果不符合预期，则受到负向惩罚。通过无数次“尝试-反馈-调整”的循环，模型不断优化行为模式，逐步掌握解决问题的最优方法。目前，AI下棋、自动驾驶、AI游戏角色等场景，均采用强化学习技术完成模型训练。\n具身智能 # 具身智能全称为Embodied Artificial Intelligence（EAI），是AI技术与机器人学、传感器技术的交叉前沿领域，与虚拟AI（仅具备语言交互能力，无物理载体）存在本质区别，核心是让智能具备物理身体，通过身体与现实环境的实时交互、感知与学习，形成智能行为与环境适应能力。\n具身智能的核心特征是具备物理交互能力，其物理载体包括人形机器人、工业机械臂、智能宠物机器人等，通过摄像头（视觉感知）、声音传感器（听觉感知）、机械臂（动作执行）等组件，实现与现实环境的交互。例如，工业机械臂可完成零件组装，人形机器人可完成家务、老人照料等任务，且能够通过交互不断学习优化行为模式，提升适应能力。\n","date":"2026 年 4 月 10日","externalUrl":null,"permalink":"/posts/ai%E5%B8%B8%E8%A7%81%E6%9C%AF%E8%AF%AD/","section":"Posts","summary":"","title":"AI常见术语","type":"posts"},{"content":"","date":"2026 年 4 月 10日","externalUrl":null,"permalink":"/tags/%E5%AD%A6%E4%B9%A0/","section":"Tags","summary":"","title":"学习","type":"tags"},{"content":" 一、互补松弛性的数学证明 # 线性规划标准形式原问题(LP)与对偶问题(DP)定义如下:\n原问题(LP): $$LP: max z=C X$$ $$s.t. \\begin{cases}A X+X_{s}=b \\\\ X \\geq 0, X_{s} \\geq 0\\end{cases} (X_{s} 为松弛变量 )$$对偶问题(DP): $$DP: min w=Y^{T} b$$ $$s.t. \\begin{cases}A^{T} Y-Y_{s}=C^{T} \\\\ Y \\geq 0, Y_{s} \\geq 0\\end{cases} ( Y_{s} 为剩余变量 )$$互补松驰性:设 \\(\\hat{X}\\) (LP 可行解)、\\(\\hat{Y}\\) (DP 可行解),则两者为最优解的充要条件为: $$Y_{s}^{T} \\hat{X}=0$$ 且 $$\\hat{Y}^{T} X_{s}=0$$等价表述: \\(\\hat{x}_{j} \\hat{y}_{m+j}=0(j=1, \\cdots, n)\\) 且 \\(\\hat{x}_{n+i} \\hat{y}_{i}=0(i=1, \\cdots, m)\\) ,即对应变量互补为零。\n下面对定理进行证明:\n必要性: 若 \\(\\hat{X}\\) 、\\(\\hat{Y}\\) 为最优解,由强对偶性得 \\(C \\hat{X}=\\hat{Y}^{T} b\\)\n由DP 约束得 \\(C=\\hat{Y}^{T} A-Y_{s}^{T}\\) ,\n代入 \\(LP\\) 目标函数得 \\(C \\hat{X}=\\hat{Y}^{T} A \\hat{X}-Y_{s}^{T} \\hat{X}\\)\n由LP 约束得 \\(b=A \\hat{X}+X_{s}\\) ,\n代入DP 目标函数得 \\(\\hat{Y}^{T} b=\\hat{Y}^{T} A \\hat{X}+\\hat{Y}^{T} X_{s}\\)\n联立消去公共项得 \\(-Y_{s}^{T} \\hat{X}=\\hat{Y}^{T} X_{s}\\) ,因变量非负,\n故 \\(Y_{s}^{T} \\hat{X}=0\\) 且 \\(\\hat{Y}^{T} X_{s}=0\\) ,必要性得证。\n充分性: 设 \\(Y_{S}^{T} \\hat{X}=0\\) 且 \\(\\hat{Y}^{T} X_{s}=0\\) ,结合目标函数变形推导。\n代入变形公式得 \\(C \\hat{X}=\\hat{Y}^{T} A \\hat{X}\\) 且 \\(\\hat{Y}^{T} b=\\hat{Y}^{T} A \\hat{X}\\) ,\n故 \\(C \\hat{X}=\\hat{Y}^{T} b\\) 由最优性判定定理, \\(\\hat{X}\\) 、\\(\\hat{Y}\\) 分别为两问题最优解,充分性得证\n二、影子价格的定义 # 影子价格,又称边际价值,是指在线性规划问题的最优解状态下,某一约束条件所对应资源的单位增量对目标函数最优值产生的增量。其数学载体为线性规划对偶问题的最优解 \\(\\hat{Y}\\)。\n结合前文对偶问题的定义 $$DP: min w=Y^{T}b$$ 约束 $$s.t. \\begin{cases}A^{T} Y-Y_{s}=C^{T} \\\\ Y \\geq 0, Y_{s} \\geq 0\\end{cases}$$及互补松弛性质核心结论( \\(\\hat{Y}^{T} X_{s}=0\\) ),\n影子价格的内涵可进一步明晰:\n若原问题最优基为 B ,则影子价格向量可表示为 \\(\\hat{Y}^{T}=C_{B} B^{-1}\\) (其中 \\(C_{B}\\) 为最优基对应的目标函数系数向量)。\n从数学逻辑推导,原问题最优目标函数值 $$z^{*}=C_{B} B^{-1} b=\\hat{Y}^{T} b$$ 对资源总量 \\(b_{i}\\) 求偏导可得 $$\\frac{\\partial z^{*}}{\\partial b_{i}}=\\hat{y}_{i}^{*}$$ 这一结果恰好印证了影子价格的定义,即第 i 种资源(对应 \\(b_{i}\\) )每增加一个单位,目标函数最优值(如最大利润、最小成本)的增量。\n在对偶问题的经济背景,影子价格可理解为企业对资源的“内部估价”: 若企业将资源对外租赁,影子价格即为保证租赁收益不低于生产收益的最低租赁单价,且在该定价下总租赁费用最低。\n从互补松弛性质视角,影子价格与原问题松弛变量满足 \\(\\hat{Y}^{T} X_{s}=0\\) ,其直观对应关系如下:\n若某资源影子价格 \\(\\hat{y}_{i}\u003e0\\) ,则对应松弛变量 \\(\\hat{x}_{n+i}=0\\) ,表明该资源已被完全利用(紧约束),是生产瓶颈,增加该资源可提升最优收益; 若某资源存在剩余( \\(\\hat{x}_{n+i}\u003e0\\) ),则其影子价格 \\(\\hat{y}_{i}=0\\) ,表明增加该资源无法改变最优收益,此时减少资源投入或对外出售资源可能更有利。 影子价格具有针对性,随企业生产产品、工艺及资源约束的不同而变化,其经济意义需结合具体线性规划问题的背景确定。 三、在实际例子中的分析 # 3.1 问题描述\n某企业计划生产甲、乙两种产品,需在A、B、C三种设备上加工,核心约束与收益参数如下:\n设备工时约束:设备A计划期工时限额6小时,甲、乙产品单位加工工时均为1小时;设备B计划期工时限额8小时,甲、乙产品单位加工工时均为2小时;设备C计划期工时限额6小时,仅乙产品单位加工工时为2小时(甲产品不耗用);\n收益参数:甲产品单位利润3百元/件,乙产品单位利润4百元/件;\n决策目标:合理安排甲、乙产品产量,实现企业利润最大化;同时通过对偶问题求解影子价格,结合互补松弛性分析资源配置状态。\n3.2 模型建立\nLP 设甲产品产量为 \\(x_{1}\\) (件),乙产品产量为 \\(x_{2}\\) (件),引入松弛变量 \\(x_{s1}\\) , \\(x_{s2}\\) , \\(x_{s3}\\) (分别对应设备A、B、C的剩余工时),模型如下:\n$$LP: max z=3 x_{1}+4x_{2}$$ $$s.t. \\begin{cases}x_{1}+x_{2}+x_{s1}=6 (设备 A 工时约束) \\\\ 2 x_{1}+2 x_{2}+x_{s2}=8 (设备 B 工时约束) \\\\ 2 x_{2}+x_{s3}=6 (设备 C 工时约束) \\\\ x_{1}, x_{2}, x_{s1}, x_{s2}, x_{s3} \\geq 0\\end{cases}$$DP 设\\(y_1, y_2, y_3\\)分别为设备A、B、C的影子价格(即单位工时的“内部估价”),引入剩余变量 \\(y_{s1}\\) , \\(y_{s2}\\) ,结合材料1的对偶问题构建逻辑,模型如下:\n$$DP: min w=6 y_{1}+8 y_{2}+6 y_{3}$$ $$s.t. \\begin{cases}y_{1}+2 y_{2}-y_{s1}=3( 甲产品利润约束) \\\\ y_{1}+2 y_{2}+2 y_{3}-y_{s2}=4( 乙产品利润约束) \\\\ y_{1}, y_{2}, y_{3}, y_{s1}, y_{s2} \\geq 0\\end{cases}$$对偶问题的经济意义:在保证租赁设备的收益不低于生产产品收益的前提下,最小化总租赁费用,此时最优解\\(y_1^*、y_2^*、y_3^*\\)即为各设备工时的影子价格。\n3.3模型求解\n原问题最优解:\n\\(x_{1}^{*}=1\\) (件), \\(x_{2}^{*}=3\\) (件),\n松弛变量\n\\(x_{s1}^{*}=6-(1+3)=2\u003e0\\) , \\(x_{s2}^{*}=8-(2 ×1+2 ×3)=0\\) , \\(x_{s3}^{*}=6-(2 ×3)=0\\)\n最优利润\n\\(z^{*}=3 ×1+4 ×3=15\\) (百元);\n对偶问题最优解:\n\\(y_{1}^{*}=0\\) , \\(y_{2}^{*}=1.5\\) , \\(y_{3}^{*}=0.5\\) ,\n剩余变量\n\\(y_{s1}^{*}=0\\) , \\(y_{s2}^{*}=0\\) ;\n最优目标值\n\\(w^{*}=6 ×0+8 ×1.5+6 ×0.5=15\\) (百元),满足 \\(z^{*}=w^{*}\\) (强对偶性成立)。\n设备A影子价格 \\(y_{1}^{*}=0\\) :\n表明在最优生产方案下,设备A的工时存在剩余 (\\(x_{s1}^{*}=2\u003e0\\) ),每增加1小时设备A工时,企业最大利润无增量。\n从决策角度,设备A并非生产瓶颈,无需追加该设备资源投入,甚至可考虑闲置工时对外租赁(租赁单价低于市场同类价格即可);\n设备B影子价格 \\(y_{2}^{*}=1.5\\) :\n表明设备B工时已完全耗用( \\(x_{s2}^{*}=0\\) ),每增加1小时设备B工时,企业最大利润将增加1.5百元(150元)。\n设备B是核心瓶颈资源,若市场上该类设备租赁单价低于150元/小时,追加租赁投入可提升企业收益;\n设备C影子价格 \\(y_{3}^{*}=0.5\\) :\n表明设备C工时已完全耗用( \\(x_{s3}^{*}=0\\) ),每增加1小时设备C工时,企业最大利润将增加0.5百元(50元)。\n设备C是次瓶颈资源,追加投入的性价比低于设备B。\n综上,影子价格本质是资源的“边际贡献价值”,其数值大小直接反映了资源的稀缺程度,为企业资源配置决策提供了量化依据。\n","date":"2026 年 1 月 8日","externalUrl":null,"permalink":"/posts/%E4%BA%92%E8%A1%A5%E6%9D%BE%E5%BC%9B%E6%80%A7%E4%B8%8E%E5%BD%B1%E5%AD%90%E4%BB%B7%E6%A0%BC%E7%9A%84%E6%80%9D%E8%80%83/","section":"Posts","summary":"","title":"互补松弛性与影子价格的思考","type":"posts"},{"content":"","date":"2026 年 1 月 8日","externalUrl":null,"permalink":"/tags/%E8%BF%90%E7%AD%B9%E5%AD%A6/","section":"Tags","summary":"","title":"运筹学","type":"tags"},{"content":"","date":"2025 年 11 月 1日","externalUrl":null,"permalink":"/tags/git/","section":"Tags","summary":"","title":"Git","type":"tags"},{"content":" 什么是GitFlow? # 为了更好的团队协作和版本管理，程序员们发明了一种工作流程——GitFlow工作流。GitFlow 是一种 Git 工作流，这个工作流程围绕着项目的发布(release)定义了一个严格的如何建立分支的模型。它是团队成员遵守的一种代码管理方案 。\nGit Flow 由 Vincent Driessen 在 2010 年提出，并通过一套标准的分支命名和工作流程，使开发、测试和发布过程更加有序和高效。Git Flow 主要由以下几类分支组成：hotfix、master、develop、feature、release。\n本文主要简单的介绍GitFlow的大致的框架，同时GitFlow只是一个指导方针，而非铁律，在必要情况下可以自行的组合和修改。\nGitFlow规定的主要分支 # 分支的种类和功能 # 分支名称格式 分支说明 main/master 生产环境主分支，存放可直接上线的稳定代码，仅通过合并更新，不直接开发 develop 开发主分支，承载日常功能开发，集成已完成的功能分支，是开发阶段的核心分支 feature 功能开发分支，从develop创建，完成后合并回develop，用于隔离单个功能开发 hotfix/ 紧急修复分支，从main创建，修复生产 bug 后合并回main和develop，临时存在 release 发布准备分支，从develop创建，用于发布前的小修复和版本调整，完成后合并到main和develop Hotfix分支 # hotfix分支也叫作热修改分支，用于解决线上的问题，修改完成后合并回master分支和develop分支。当生产环境中的代码遇到严重到必须立即修复的缺陷时，从主分支中拉取hotfix分支\u0026ndash;\u0026gt;修改bug\u0026ndash;\u0026gt;验证修复完成后\u0026ndash;\u0026gt;合并到master分支（tag更新为x.x.1）和develop分支\u0026ndash;\u0026gt;删除hotfix分支。hotxfixd的命名规则：hotfix/[问题类型]-[核心描述]-[可选版本号]。\n一个项目发布后或多或少肯定会有一些bug存在，而bug的修复工作并不适合在develop上做，而在hotfix上做，这是因为：\ndevelop分支上包含还未验证过的feature\n用户未必需要develop上的feature\ndevelop还不能马上发布，而客户急需这个bug的修复\nMaster分支 # 也称主线分支或者基线分支，是核心的分支。它包含项目的核心稳定版本（正式版本），同时要保证主线分支的代码是可以随时发布的，也要保证代码可以随时在生产环境中使用。\n主线分支不被允许直接修改，只能通过合并分支的方式修改，每一次合并分支都建议生成一个新的版本号（tag），主线分支接受来自release和hotfix的合并请求。\n常见的版本号命名规则：\n主版本：主要功能变化或者重大更新。 次版本：一些新的功能、改进、更新，通常不影响现有功能。 修订版本：一些小的bug修复，安全漏洞补丁等。通常不会更改现有功能和接口 Develop分支 # Develop分支即开发分支。从主线分支上拉取上来，包含了项目的最新开发版本的代码，用于开发和测试，其上更新的代码为下一个发布版本要交互的新功能。当开发完成或者到达目标阶段时，应该从改点拉取一个预发分支并附上发布版本号，开发分支会接受其他辅助分支的合并，但合入的分支不能影响开发分支的正常运行。\nFeature分支 # Feature分支即功能分支。一般包含项目某个新功能的代码，用于开发新功能。功能分支从开发分支中拉取，当功能分支稳定后，合并到开发分支。这个分支一般在开发人员的本地库，这个分支一般不提交到远程代码库里。Feature分支的命名规则：Feature/xxx。\nRelease分支 # Release 分支是专门用于版本发布前准备工作的临时分支，核心作用是在开发完成后、正式发布到生产环境前，隔离并处理发布相关的最终调整，确保生产环境代码的稳定性。\n简单说，它就像 “发布前的缓冲带”—— 当开发分支（develop）上的功能都已完成，就从 develop 创建 Release 分支，允许做小量级的Bug修复和准备发布版本的元数据信息（版本号、编译时间等）文档更新等发布前的收尾工作不允许新增功能。\n通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入。完成后，这个分支会同时合并到生产分支（main）和开发分支（develop）。这样既能既保证了发布版本的纯净性，又不影响 develop 分支继续开发新功能，是连接开发与生产的关键过渡环节。Release分支命名规则：Release/版本号。\n","date":"2025 年 11 月 1日","externalUrl":null,"permalink":"/posts/%E5%A6%82%E4%BD%95%E8%A7%84%E8%8C%83%E4%BD%BF%E7%94%A8gitgitflow/","section":"Posts","summary":"","title":"如何规范使用Git——GitFlow","type":"posts"},{"content":" 什么是Unicode？ # Unicode在中文里叫做万国码，国际码。顾名思义，Unicode对全世界的文字系统进行了整理、编码，使得全球的计算机在文字编码上有了统一的标准。\n我们知道，世界上不同的国家语言不同，因而组成文字的字符也不同，为了将自己的语言存入计算机里面，就有了五花八门的编码方式，而Unicode为了统一全世界的编码方式，将全世界的语言系统进行了整理编码。\nUnicode开始制定的时候，计算机的存储容量大大的发展了，于是ISO便规定用2个字节也就是16位来表示一个字符，同样的Unicode任然保持ASCII里面的那些字符，只是将8位扩充为了16位。\nUTF # Unicode只是规定了字符的编号，如汉字\u0026quot;一\u0026quot;的编号是\u0026quot;4E00\u0026quot;,如果用每个字符的编号对应的二进制进行储存，那就比较浪费空间了（并不是所以字符都要16位表示）出于节省空间的目的，对 Unicode编码的实现方式有所不同。Unicode的实现方式称为Unicod转换格式（Unicode Transformation Format，简称为UTF）。\nUTF-8 # 本文使用UTF-8为例子\nUTF-8（8位元，Universal Character Set/Unicode Transformation Format）是针对Unicode的一种可变长度字符编码。它可以用来表示Unicode标准中的任何字符，而且其编码中的第一个字节仍与ASCII相容，使得原来处理ASCII字符的软件无需或只进行少部分修改后，便可继续使用。因此，它逐渐成为电子邮件、网页及其他存储或传送文字的应用中，优先采用的编码。摘自百度百科\n前缀码 # UTF-8一种针对Unicode的可变长度符编码，可以用一至四个字节对Unicode字符集中的所有有效编码点进行编码，属于Unicode标准的一部分。而实现这一效果的主要是依靠前缀码这种编码要求。\n前缀码是什么呢？前缀码是指任何一个编码都不能作为另一个编码的前缀（开头部分），能确保解码时无歧义、无需分隔符。这样说比较难理解，举个例子：\n给 3 个东西编编号，要满足 “没人的编号是别人的开头”：\n猫 → 编号 “1” 狗 → 编号 “22” 兔 → 编号 “31” 这就是前缀码 —— 不管按什么顺序读，看到 “1” 就知道是猫，看到 “22” 就知道是狗，绝不会混淆。\n再看反例（不是前缀码）：\n猫 → “1” 狗 → “12” 这就不行！看到 “1”，根本不知道是单独的猫，还是狗的开头部分。\nUTF-8的具体实现 # 我们已经了解的前缀码的规则和作用了，那么UTF-8如何实现呢？\nUTF-8的编码规则就两条：\n1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的 Unicode 码。因此对于英语字母，UTF-8 编码和 ASCII 码是相同的。\n2）对于n字节的符号（n \u0026gt; 1），第一个字节的前n位都设为1，第n + 1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的 Unicode 码。\nUnicode符号范围 | UTF-8编码方式 (十六进制) | （二进制） -------------------+--------------------------------------------- 0000 0000-0000 007F | 0xxxxxxx 0000 0080-0000 07FF | 110xxxxx 10xxxxxx 0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx 0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 目前看上去这个规则很难理解，现在让我们对照规则通俗的解释一下。\n单字节的字符：字符的第一位为0，当计算机读取到第一位为0的就直接读取后面7位确定是哪个字符了，如果第一位不是0，计算机就开始计数，看有多少个1可以读取到0，例如11110xxx，计算机就知道除了这个在读的字节后面还有3个字节（10xxxxxx 10xxxxxx 10xxxxxx）\nPS: 现在还有一个小疑问，就是为什么后面字节的前两位一律设为10，“10” 是后续字节的 “身份标识”，计算机读取时会双重校验：若后续字节不以 “10” 开头，比如混入一个以 “0” 或 “110” 开头的字节，一旦数据传输中出现错位（比如少读 / 多读 1 个字节），计算机就会彻底混乱。所以既看首字节的 “1 的个数” 确定总长度，又会检查后续字节是否都以 “10” 开头。\n","date":"2025 年 10 月 25日","externalUrl":null,"permalink":"/posts/unicode%E7%BC%96%E7%A0%81%E7%9A%84%E7%BB%93%E6%9E%84%E5%92%8C%E5%8E%9F%E7%90%86/","section":"Posts","summary":"","title":"Unicode编码的结构和原理","type":"posts"},{"content":"","date":"2025 年 10 月 25日","externalUrl":null,"permalink":"/tags/%E7%BC%96%E7%A0%81/","section":"Tags","summary":"","title":"编码","type":"tags"},{"content":"","date":"2025 年 3 月 27日","externalUrl":null,"permalink":"/tags/%E5%86%99%E4%BD%9C/","section":"Tags","summary":"","title":"写作","type":"tags"},{"content":"准备工作：写下关于这本书的所有想法\n1、一句话概括：找到目标读者群体和故事类别，写出50个字的大纲，包含主角和她的目标\n2、故事摘要：利用三幕式结构添加3个关键节点写一个五句式摘要。重点关注危机事件和主人公所做的决定。\n3、创建人物介绍\n4、完成故事梗概（一千字左右）\n5、回顾并修改人物简介，花一两天时间完善人物\n6、写出故事大纲（三千字），返回前面修改故事漏洞。\n7、创建人物图表：为每一个人物写一个背景故事，详细描写每个人物的过去经历。\n8、写出所有的故事场景在卡片上，并排列场景，优化每个故事中的危机情节点并为场景分配情节。\n9、章节描述：为每个场景写下叙述性描述。\n10、初稿\n","date":"2025 年 3 月 27日","externalUrl":null,"permalink":"/posts/%E9%9B%AA%E8%8A%B1%E5%86%99%E4%BD%9C%E6%B3%95/","section":"Posts","summary":"","title":"雪花写作法","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]