- 博客(225)
- 收藏
- 关注
原创 大模型分类测评指标清单
【摘要】大模型评测体系包含五大维度:1.核心能力指标(准确率、流畅度、事实一致性等基础能力);2.专项能力指标(推理能力、可控性等关键能力);3.领域专属指标(金融合规、法律匹配、医疗诊断等垂直场景要求);4.生产环境指标(性能、安全、用户体验等落地要素);5.评测工具推荐(OpenCompass2.0等开源方案)。该体系覆盖从基础能力验证到产业落地的全链条评估,为不同领域提供模块化、标准化的评测框架,特别强调企业场景中的可控性、合规性与生产可用性。
2026-06-12 10:47:06
224
原创 解决vllm服务漏扫问题
在 vLLM 中屏蔽/docs(Swagger UI)和/redoc等自动生成的 API 文档页面,可以通过在启动命令中添加参数来实现。
2026-06-11 11:00:54
217
原创 【系统分析师】14.6 测试策略与过程
阶段 主要活动 输入 输出 测试计划 制定测试策略、资源安排、进度 需求文档、设计文档、项目计划 测试计划文档 测试设计 设计测试用例、测试数据 需求、设计规格 测试用例、测试数据 测试实现 编写测试脚本、准备测试环境 用例、设计 自动化脚本、环境配置 测试执行 运行测试、记录结果、报告缺陷 用例、脚本、被测版本 测试日志、缺陷报告 测试评估 分析结果、评估质量、生成报告 执行记录、缺陷数据 测试报告、质量评估 测试维护 更新用例、脚本以适应变更 需求变更、设计变更 更新的用例/脚本。
2026-05-12 19:06:07
236
原创 【系统分析师】14.5 测试用例设计
测试用例设计 = (黑盒:等价+边界+判定+因果+场景+正交) + (白盒:语句→判定→条件→组合→路径),是发现缺陷的“精准武器”,质量越高,缺陷越少。· 恒等:若c=1,则e=1 · 非:若c=1,则e=0 · 与:若c1=1且c2=1,则e=1 · 或:若c1=1或c2=1,则e=1。示例:判定 if (a>0 && b>0),要求 a>0 为真、a>0 为假、b>0 为真、b>0 为假各至少一次。示例:if (a>0 && b>0) 的4种组合:(真,真)、(真,假)、(假,真)、(假,假)。
2026-05-11 07:47:37
226
原创 【系统分析师】14.4 软件测试概述
类型 目标 典型方法 功能测试 验证功能是否符合需求 黑盒测试 性能测试 验证响应时间、吞吐量 负载测试、压力测试、稳定性测试 安全测试 发现安全漏洞 渗透测试、漏洞扫描、SAST/DAST 回归测试 确保修改未引入新缺陷 重复执行已有测试用例 冒烟测试 验证基本功能是否可测 主要流程检查 健全性测试 验证修改部分是否正常工作 针对变更内容的快速测试。可验证性能、安全性等。· 测试是为了发现错误而执行程序的过程 · 一个好的测试用例是能发现尚未发现的错误的用例 · 成功的测试是发现了尚未发现的错误的测试。
2026-05-07 07:28:15
285
原创 【系统分析师】14.3 程序设计风格与规范
4. 结构规范:单一职责、函数短小、避免深层嵌套、高内聚低耦合。``` com.company.project ├── controller // REST接口 ├── service // 业务逻辑接口 ├── service.impl // 业务逻辑实现 ├── repository // 数据访问 ├── domain // 实体/DTO ├── config // 配置类 └── util // 工具类 ```// 外部导入(按字母排序) import com.company.core.Util;
2026-05-03 12:08:35
240
原创 【系统分析师】14.2 编码与程序设计语言
维度 规范内容 示例 命名 类、变量、方法、常量的命名规则 类名大驼峰(UserService),变量小驼峰(userName),常量全大写下划线(MAX_SIZE) 注释 文件头、函数、复杂逻辑的注释要求 每个公共函数必须有Javadoc/文档注释 格式 缩进、空格、换行、括号位置 4空格缩进,行宽不超过120字符 结构 代码组织、包/模块划分 按功能分层,禁止跨层直接调用 异常处理 异常捕获和处理方式 不要吞掉异常,记录日志并上报 安全 输入验证、SQL注入防护等 使用参数化查询,禁用拼接SQL。
2026-05-02 13:15:58
383
原创 【系统分析师】14.1 软件实现概述
环境类型 作用 典型工具 集成开发环境 提供编码、调试、构建的一体化环境 IntelliJ IDEA、Eclipse、VS Code 版本控制系统 管理代码变更、分支、协作 Git、SVN 构建工具 自动化编译、打包、依赖管理 Maven、Gradle、Make 单元测试框架 编写和执行单元测试 JUnit、pytest、MSTest 持续集成 自动构建、测试、反馈 Jenkins、GitLab CI、GitHub Actions 缺陷跟踪系统 管理缺陷报告和修复过程 Jira、Bugzilla、禅道。
2026-04-28 07:12:16
212
原创 【论文】MemGPT: Towards LLMs as Operating Systems
它标志着AI智能体从“无状态的对话机器”向“拥有长期、可管理记忆的模拟实体”迈进的关键一步。在操作系统中,应用程序可以访问一个远大于物理内存的虚拟地址空间,操作系统通过“分页”技术,在物理内存和磁盘之间智能地交换数据页。:MemGPT的引入增加了系统的复杂性,并可能带来额外的延迟(由于频繁的函数调用和检索)。当需要从主上下文中移出信息时,MemGPT不是简单丢弃,而是基于当前的摘要和要移除的消息,生成一个新的、更凝练的摘要存入长期记忆,从而保留核心信息。:存储静态的系统提示词,定义智能体的角色和行为准则。
2026-04-22 11:16:01
433
原创 怎么看论文
用笔记工具(如Notion、飞书文档)对精读论文进行结构化记录,模板可包括:问题定义、核心思想、优缺点、适用场景、复现心得、业务联想。:不断积累,形成当你遇到某个业务问题时(如“数据不足”、“标注噪声大”),能快速联想到有哪些前沿论文方法可供参考的索引。:重点理解其动机和核心思想(如新提出的模块、损失函数),数学推导可略过,但需理解其物理或逻辑含义。:选择一个小型、低风险的项目模块,尝试应用论文中的思想或方法,进行A/B测试,验证其实际效果。:5分钟内明确论文要解决什么问题、核心创新点是什么、效果如何。
2026-04-22 09:50:22
246
原创 自然语言处理任务分类
总的来说,这些任务有些侧重理解(如分类、情感分析),有些侧重生成(如翻译、摘要),而很多实际应用(如智能助手)则同时依赖多种任务。· 关系抽取:从文本中抽取实体之间的语义关系,如从“比尔盖茨创立了微软”中抽取出(比尔盖茨,创始人,微软)。· 文本摘要:将长文本压缩成短摘要,分为抽取式(摘录原文句子)和生成式(自己组织语言重写)。· 信息抽取:从非结构化文本中抽取出结构化信息(如事件的时间、地点、人物等)。· 文本分类:将文本按主题、情感等类别归类,如新闻分类、垃圾邮件过滤。
2026-04-21 07:34:51
123
原创 【系统分析师】第14章 软件实现与测试
软件实现与测试是软件生命周期中将设计转化为可运行系统,并验证其正确性的阶段。分类维度 类型按阶段 单元测试、集成测试、系统测试、验收测试按方法 静态测试(评审、走查)、动态测试(运行程序)按技术 白盒测试(基于代码)、黑盒测试(基于需求)按目的 功能测试、性能测试、安全测试、兼容性测试、回归测试。· 目的:发现缺陷、分享知识、保证规范一致性· 形式:正式审查(走查、检视)、非正式(结对编程、Pull Request)· 检查清单:命名、注释、逻辑正确性、边界条件、异常处理、性能。
2026-04-15 07:36:01
411
原创 【系统分析师】13.3 详细设计的主要内容
章节 内容 引言 设计背景、目的、范围、术语 模块设计 每个模块的输入输出、算法描述、流程图/伪代码 数据库物理设计 表结构、索引、分区、存储分配 界面设计 界面布局、输入输出格式、交互流程 接口设计 模块接口、外部接口规范 代码设计 代码清单、编码规范 测试设计 单元测试用例建议。设计内容 要点 输入内容 哪些数据需要输入、哪些可以自动获取 输入方式 键盘、扫描、语音、文件导入、数据交换 输入格式 界面布局、字段顺序、默认值 输入校验 范围校验、格式校验、逻辑校验、平衡校验。
2026-04-14 07:34:21
359
原创 【系统分析师】13.2 概要设计的主要内容
章节 内容 引言 设计背景、目的、范围、术语、参考资料 总体设计 系统总体结构图、子系统划分、功能描述 模块结构设计 模块结构图、模块清单、模块功能说明、接口定义 系统平台设计 硬件配置、软件选型、网络拓扑 数据存储设计 存储方式、数据库选型、数据分布策略 接口设计 内部接口、外部接口(与其他系统) 安全与备份设计 安全策略、备份恢复方案 实施计划 开发阶段划分、资源需求、进度安排。容量、IOPS、带宽 网络设备 交换机(端口数、速率)、路由器、防火墙 终端设备 工作站、移动设备、打印机等。
2026-03-27 18:36:11
436
原创 【系统分析师】13.1 系统设计的两个层次
3. 详细设计的四大内容:代码设计、数据库物理设计、人机界面设计、处理过程设计。· 输出设计: · 输出内容确定(数据项、信息形式) · 输出方式选择(报表、图形、文件) · 输出格式设计(版面布局、字体字号) · 输入设计: · 输入内容确定(哪些数据需要输入) · 输入方式选择(键盘、扫描、语音、导入) · 输入格式设计(界面布局、数据校验规则) · 输入校验设计(范围校验、格式校验、平衡校验) · 人机对话设计: · 菜单设计 · 操作提示 · 错误处理 · 帮助系统。
2026-03-26 19:15:48
252
原创 【系统分析师】第13章 系统设计
对于系统分析师而言,系统设计是你从“需求分析师”向“系统架构师”角色转变的关键环节。系统设计的核心任务:从信息系统的总体目标出发,根据系统分析阶段对系统的逻辑功能的要求,并考虑到经济、技术条件、运行环境和进度要求等,确定系统的总体结构和系统各组成部分的技术方案,合理选择计算机和通信的软、硬件设备,制订系统的实施计划。系统设计是新系统的物理设计阶段,它是根据系统分析阶段所确定的新系统的逻辑模型、功能要求,在用户提供的环境条件下,设计出一个能在计算机网络环境上实施的方案,即建立新系统的物理模型的过程。
2026-03-25 18:34:32
468
原创 【系统分析师】12.5 软件架构评估
查询请求处理时间的要求会影响系统的数据传输协议和处理过程的设计 权衡点 指影响多个质量属性的特性,是多个质量属性的敏感点。阶段 活动内容 场景和需求收集 收集并定义系统的使用场景和需求,确保所有相关利益方的需求都被考虑 体系结构视图和场景实现 通过不同的架构视图展示系统的设计,并演示如何在这些视图中实现收集的场景 属性模型构造和分析 为每个质量属性构造模型,并进行分析以评估系统在这些属性上的表现 架构评审与折中 对架构进行评审,识别并讨论各质量属性之间的折中关系,以确定最优的架构设计方案。
2026-03-24 22:38:44
350
原创 【系统分析师】12.4 软件架构设计方法
阶段 主要活动 输入 产出 预备阶段 梳理业务需求,了解真实业务目标 需求规格说明书、业务战略 架构目标定义、质量属性场景 定义阶段 确定关键质量属性,识别约束条件 业务目标、技术现状 架构原则、约束清单 细化阶段 提出候选架构,评估权衡,做出决策 质量属性、约束 选定的架构方案 实现阶段 架构文档化,指导后续开发 架构决策 架构文档、技术选型清单。· 识别技术约束(现有技术栈、团队技能、预算) · 识别业务约束(上线时间、合规要求) · 制定架构设计原则(如“数据必须加密存储”、“服务必须无状态”)
2026-03-22 20:37:32
216
原创 如何安全地使用龙虾[特殊字符]
1. 《AI智能体运行安全测试标准》:全球首个单智能体安全测试标准。2. 《终端智能体安全2025》:上海人工智能实验室、信通院联合发布,针对手机、AR眼镜等端侧设备,首次提出涵盖单智能体安全、多智能体可信互连的防护体系。3. 《大模型安全白皮书(2025)》:360集团发布,提出“外挂式安全+平台原生安全”的双轨策略,在算力、数据、用户端等环节提供了纵深防御方案。· 关注国际规范:建议直接参考 WDTA的《运行安全测试标准》 或 CoSAI的《MCP安全白皮书》,它们代表了当前国际主流的技术思路。
2026-03-22 06:52:45
100
原创 【系统分析师】12.3 软件架构描述与表示
UML是当前最主流的架构建模语言,提供了丰富的图形化建模元素,能够表达系统的静态结构和动态行为。掌握12.3节,意味着你能够熟练运用4+1视图、C4模型等框架来描述和表达软件架构,让不同角色的干系人都能理解你的设计意图。软件架构描述与表示是指用特定的语言、图形或文档,将软件架构的设计结果显式地表达出来的过程。它将系统分解为一系列的关键抽象,表现为对象或对象类的形式,采用抽象、封装和继承的原理。图形化模型是最常用的形式,通过多个视图从不同角度建立系统的模型,分别刻画某一方面的性质。
2026-03-21 22:25:24
237
原创 【系统分析师】12.2 软件架构风格
正如建筑学中有哥特式、巴洛克式、现代主义等风格,软件架构也有各种风格,每种风格适用于不同类型的系统,体现了不同的设计哲学和质量属性权衡。事件驱动(隐式调用) 构件不直接调用,而是发布事件或订阅事件,事件触发时执行 高度松耦合、可扩展性强 全局控制流不清晰、调试困难 GUI系统、消息中间件、EDA。管道-过滤器 数据流式处理,每个过滤器有输入输出,通过管道连接 松耦合、高复用、支持并行 共享数据困难、性能开销大 Unix Shell、编译器、流处理。3. 调用/返回风格:主程序/子程序、面向对象、层次结构。
2026-03-19 21:15:48
354
原创 【系统分析师】12.1 软件架构的概念
软件架构是有关软件整体结构与组件的抽象描述,它定义了系统的高层组织,包括组成系统的构件、构件之间的交互关系,以及指导系统设计和演化的原则。软件架构 = (构件+连接件+约束) 定义系统的宏观结构,承载质量属性的权衡,是重大设计决策的记录,也是项目干系人沟通的媒介和系统演化的蓝图。5. 质量属性两大类别:运行期质量(性能、安全、可用、可靠、可伸缩、可观测)和开发期质量(可维护、可测试、可部署、可复用、可理解)。组件 可独立部署、复用的软件单元,比构件更具体 在基于组件的开发中,组件是实现构件的技术形式。
2026-03-18 19:05:04
315
原创 【系统分析师】第12章 软件架构设计
软件架构是系统的“骨架”和“蓝图”,决定了系统的质量属性(如性能、安全性、可维护性)和演进能力。软件架构设计 = (五大风格 + 4+1视图 + 三原则 + ATAM评估),是从需求到实现的“骨架搭建”,决定了系统的质量、成本和演进能力。更正式的定义:软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的外部可见属性及它们之间的关系组成。视图关系:逻辑视图和开发视图描述系统的静态结构,进程视图和物理视图描述系统的动态结构,场景则是驱动这些视图的核心需求抽象。
2026-03-17 19:06:44
400
原创 【系统分析师】11.7 软件需求管理
它的目标是确保需求的完整性、一致性、可追溯性,并在需求发生变化时,能够有效评估影响、控制变更、维护基线,从而保证项目始终在可控范围内交付正确的产品。如果把需求获取、分析、文档化比作“建房”,那么需求管理就是“房屋交付后的维护和改造管理”——确保房子在长期使用中,任何改动都有记录、有审批、不影响整体结构。软件需求管理 = (基线 + 变更 + 跟踪 + 状态 + 版本 + 沟通),是需求生命周期的“持续护航”,确保需求在变化中依然可控、可追、可交付。📌 速记口诀:“基线变更和状态,跟踪风险要通报;
2026-03-16 18:30:06
502
原创 【系统分析师】11.6 软件需求确认和验证
软件需求确认和软件需求验证是需求工程中确保需求质量的两个关键环节,它们共同构成了需求的“质检”体系。软件需求确认和验证 = (确认:正确性 + 验证:技术质量),是需求工程的“双重保险”,确保需求既“正确”又“清晰”,为后续开发奠定坚实质量基础。需求验证的目标:确保需求文档本身满足正确、完整、一致、无歧义、可验证等技术质量属性,并且需求之间、需求与模型之间保持一致。需求确认的目标:确保所定义的需求真实、准确地反映了用户的意图和期望,并且这些需求在业务上是可行的、有价值的。”——即需求的技术质量。
2026-03-14 17:43:44
338
原创 【系统分析师】11.5 软件需求文档化
软件需求文档化是指将需求分析阶段产生的需求模型和分析结果,以规范化的文档形式记录下来,形成软件需求规格说明书的过程。它是需求工程的关键产出环节,将隐性的、分散的需求转化为显性的、结构化的、可传递的文档资产。软件需求文档化 = (SRS结构 + 七大原则 + 六重作用 + 编写技巧),将需求分析成果固化为可传递、可追溯、可验证的“项目契约”,是需求工程从“分析”走向“应用”的桥梁。核心要点:需求文档化不是简单的“写文档”,而是将分析结果结构化、规范化、可追溯化的过程,是需求工程从“分析”走向“应用”的桥梁。
2026-03-13 18:24:40
235
原创 【系统分析师】11.4 软件需求分析
它的核心任务是从用户提供的模糊、零散、甚至相互冲突的需求描述中,提炼出清晰、完整、一致、可验证的系统需求,并建立相应的逻辑模型,为后续的系统设计提供精确输入。如果把需求获取比作“采矿”,那么需求分析就是“选矿、冶炼和锻造”——只有经过精心加工,原始的“矿石”(用户想法)才能变成可用的“钢材”(需求规格)。· 输出:需求分析模型(如数据流图、用例模型、类图等)、需求优先级列表、需求冲突解决方案、可行性分析结论。1. 需求分析的本质:将获取的原始需求加工为清晰、完整、一致、可验证的系统需求,并建立逻辑模型。
2026-03-12 18:59:11
206
原创 【系统分析师】11.3 软件需求获取
软件需求获取是需求工程的第一阶段,其核心任务是通过系统化的方法与用户、客户及其他利益相关者进行沟通,全面收集、理解并记录他们对目标系统的期望和约束。3. 十大获取方法:访谈、问卷、观察、文档分析、工作坊、原型、用户故事、头脑风暴、场景分析、现有系统分析。软件需求获取 = (识别干系人 + 十种方法 + 六步过程 + 八条实践),是挖掘用户真实需求的“探矿工程”,方法越得当,需求越精准。“访问卷观文,工原故头场”(访谈、问卷、观察、文档分析、工作坊、原型、用户故事、头脑风暴、场景分析、现有系统分析)
2026-03-11 19:01:44
433
原创 【系统分析师】11.2 软件需求工程
它的核心目标是获取高质量的软件需求,确保最终开发的系统真正满足用户的期望。软件需求工程 = (六大过程闭环 + 工程化方法 + 需求工程师多重角色),是从“需求分析”到“需求管理”的范式升级,确保软件从源头就走在正确的轨道上。需求分析 需求分类、冲突解决、优先级排序、建模 将原始需求转化为清晰、一致的分析模型 用例模型、数据模型、需求优先级列表 “这些需求意味着什么?需求管理 变更控制、需求跟踪、基线管理 在整个生命周期中维护需求的完整性和可追溯性 需求跟踪矩阵、变更记录、需求基线 “需求变了怎么办?
2026-03-10 18:57:51
243
原创 【系统分析师】11.1 软件需求
类型 定义 关注点 示例功能性需求 规定开发人员必须在系统中实现的软件功能 系统应该做什么 “系统支持微信支付”非功能性需求 系统必须具备的除功能需求外的特性 系统应该怎么样 性能、安全、可靠性、易用性设计约束 对系统的一些限制条件或补充说明 系统必须满足什么限制 “必须采用国产数据库”· 业务需求驱动用户需求:组织的高层目标决定了用户需要完成哪些任务· 用户需求驱动系统需求:用户任务决定了系统必须提供哪些功能· 系统需求中的功能需求和非功能需求共同确保业务目标和用户任务的实现。
2026-03-09 19:02:01
348
原创 【系统分析师】第11章 软件需求工程
与传统需求分析概念相比,软件需求工程突出了工程化的原则,强调以系统化、条理化和可重用的方法和技术进行软件需求相关活动,从而有利于提高与软件需求相关的一切活动及其过程的管理,降低了软件需求开发和管理的难度和成本。需求管理的定义与目的:需求管理是在整个项目生命周期中,对需求进行跟踪、控制变更、维护需求基线的一系列活动,确保需求始终与项目目标和交付成果保持一致。软件需求的本质:需求是连接用户期望与系统实现的桥梁。└──────────────────── [变更管理] ←──────────────────┘。
2026-03-07 23:23:00
498
原创 【系统分析师】10.9 系统方案建议
系统方案建议是系统规划与分析的收官之作,它将前面所有分析阶段的成果——问题分析、业务流程优化、数据需求、可行性评估、成本效益比较——整合为一个完整的、可实施的系统建设方案,并向决策层提交,以获得项目立项的最终批准。经济可行性 方案的总拥有成本、预期收益、投资回报率、净现值、回收期 成本估算是否合理?技术可行性 方案的技术路线、架构、开发平台、所需技能、技术风险 技术成熟度、团队能力、技术趋势、与现有系统的集成难度。“背、现、候、评、推、效、结、附”(背景、现状、候选、评估、推荐、效益、结论、附录)
2026-03-06 18:52:08
375
原创 【系统分析师】10.8 成本效益分析
成本效益分析是可行性分析中经济维度的量化核心,它通过识别、计量和比较信息系统项目的全部预期成本与全部预期效益,运用一系列财务指标来评估项目的经济合理性,为决策者提供“值不值得投”的科学依据。成本效益分析 = (全面识别成本收益 + 资金时间价值 + 五大核心指标计算 + 多方案比较),是经济可行性的量化核心,为项目决策提供“值不值得投”的财务依据。系统分析师视角:在跨年度的大型项目中,必须考虑资金的时间价值,使用动态指标(如NPV)而非静态指标(如静态回收期)。成本效益分析的核心是计算一系列评价指标。
2026-03-05 19:08:06
510
原创 【系统分析师】10.7 系统可行性分析
• 成本估算:开发成本、硬件采购、软件许可、运维成本 • 效益预测:直接收益(如成本节约、收入增加)、间接收益(如效率提升、客户满意度) • 投资回报指标:净现值(NPV)、投资回收期、内部收益率(IRR) • 成本是否在预算内?“引现方可,风推结”(引言、现有系统、候选方案、可行性评估、风险分析、推荐方案、实施建议、结论)联想:“引(引导)现(现实)可(可能)方(方案)风(风险)推(推荐)实(实施)结(结论)”4. 评估各方案可行性 对每个候选方案,从技术、经济、运营、法律、进度五个维度进行深入评估。
2026-03-04 22:18:13
271
原创 【系统分析师】10.6 数据流程分析
分析维度 内容 用途类型和长度 数据类型(字符、数值、时间、多媒体)、占用空间、整数/小数位数 数据库设计、处理逻辑取值范围 最大值、最小值、合法值域 数据输入、校对、审核业务量 发生频率、峰值数据量、峰值时间、存储周期 性能设计、容量规划使用情况 哪些业务使用这些数据(CU矩阵中的“U”) 功能设计、数据共享重要程度 重要程度(影响输入、校对、存储、复制、备份策略) 安全设计、备份策略保密程度 保密等级(影响网络设计、数据库设计、权限设置) 安全设计、访问控制。· 理清数据的来龙去脉:数据从哪里来?
2026-03-03 19:26:12
441
原创 【系统分析师】10.5 业务流程分析
通过对流程的深入分析,识别流程中的冗余、瓶颈、不一致和低效环节,为后续的系统需求定义和流程优化奠定基础。掌握10.5节,意味着你能够熟练运用流程图、活动图等工具,与业务用户共同梳理和优化业务流程,为后续的需求分析和系统设计提供精准的业务输入。业务流程是为达成特定业务目标而执行的一组逻辑相关的、结构化的活动集合,这些活动由特定的角色(人或系统)按照一定的规则和顺序执行,并可能涉及信息的传递和物理物品的流转。“识、绘、析、设、验、出”(识别流程、绘制AS-IS、分析问题、设计TO-BE、验证、输出模型)
2026-03-02 19:06:39
646
原创 【系统分析师】10.4 问题分析
它的核心任务是:在明确系统建设方向后,深入调研和理解现有系统或业务领域,识别存在的问题和潜在的改进机会,并追溯这些问题的根本原因,从而为新系统设定明确的改进目标。如果你不能准确把握问题的根源,后续所有的需求分析和系统设计都可能建立在错误的基础上,最终导致系统无法真正解决用户的痛点。掌握10.4节,意味着你能够像一个经验丰富的“系统医生”,透过现象看本质,为后续的需求分析和系统设计打下坚实的基础。系统有哪些已知缺陷?1. 问题分析的本质:从症状追溯到根本原因,为新系统设定改进目标,是系统分析的“诊断”阶段。
2026-03-01 18:44:29
403
原创 模型如何加载
机器根据旋钮设置和半成品状态(KV缓存),一步步计算,最终产出成品(答案)。当你启动一个训练好的大模型(比如用Hugging Face的Transformers库加载)时,操作系统的内存里主要会加载三类东西:模型参数、模型结构和运行时状态。在神经网络(大模型的基础架构,主要是Transformer架构)中,参数主要指神经元之间连接的权重(Weights)和偏置(Biases)。所以,当你加载模型时,主要就是把那份庞大的旋钮设置档案(模型参数)从硬盘搬运到内存中,并按照蓝图把机器组装起来,随时准备开工。
2026-02-28 22:25:39
301
原创 【系统分析师】10.3 系统分析概述
系统分析是指系统分析师在系统规划的基础上,对目标系统进行深入、全面的调查研究,通过识别用户需求、理解业务流程、分析数据流转,最终形成系统的逻辑模型,并明确系统“必须做什么”的阶段。你需要在充分理解业务的基础上,运用科学的分析方法和建模工具,将模糊、零散的用户需求转化为清晰、完整、无歧义的系统逻辑模型。掌握10.3节,意味着你全面理解了系统分析的定位、过程、工具和产出,为后续深入学习需求获取、需求建模、UML等具体技术奠定了坚实的认知基础。分析是设计的基础,设计是实现分析的方案。
2026-02-28 18:47:50
466
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅