[{"data":1,"prerenderedAt":1813},["ShallowReactive",2],{"post:\u002Fposts\u002Fswdesign\u002Fsw-design-notes-12":3,"posts:ordered":1511},{"id":4,"title":5,"body":6,"category":1493,"cover":1494,"date":1495,"description":1496,"extension":1497,"featured":1498,"meta":1499,"navigation":1500,"path":1501,"seo":1502,"series":1503,"seriesOrder":1504,"stem":1505,"tags":1506,"__hash__":1510},"posts\u002Fposts\u002FswDesign\u002Fsw-design-notes-12.md","软件分析与设计笔记 12：前端设计：把流程变成屏幕",{"type":7,"value":8,"toc":1446},"minimark",[9,16,25,30,33,40,45,48,55,59,64,67,127,134,138,141,152,155,159,165,172,179,183,187,194,197,258,265,269,276,279,325,332,336,340,343,365,368,389,396,400,410,417,421,425,431,445,448,458,462,469,472,533,539,543,550,553,598,605,609,613,685,689,696,703,706,712,716,720,726,729,749,753,759,785,792,796,800,806,809,850,855,859,869,872,933,936,940,944,950,968,975,979,985,996,1002,1006,1010,1013,1033,1040,1047,1050,1073,1076,1132,1135],[10,11,12],"blockquote",{},[13,14,15],"p",{},"这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，示例与图示都是自己编、自己画的。理解有偏差的地方欢迎指出。",[10,17,18],{},[13,19,20,24],{},[21,22,23],"strong",{},"贯穿案例","：片区家电维修派单系统。08 画了活动图，这一篇把流程落到屏幕上 —— 重点是客服的派单台和片区经理的看板。",[26,27,29],"h2",{"id":28},"_0-界面不是最后一步才画的","0 界面不是最后一步才画的",[13,31,32],{},"很多团队的做法是：需求写完、开发做完，最后找个人「做一下界面」。",[13,34,35,36,39],{},"问题在于，",[21,37,38],{},"画界面的时候一定会发现流程缺东西","。在本例里，给客服小林画派单界面时，第一个问题就会是：",[10,41,42],{},[13,43,44],{},"「一单要派多久？如果她同时开三个窗口找三张单，会不会派重？」",[13,46,47],{},"这个问题活动图里没写。它不是界面问题，是流程问题 —— 但它只有在画界面时才会被逼出来。",[13,49,50,51,54],{},"所以界面设计不是装饰环节，它是",[21,52,53],{},"需求的最后一次压力测试","。这一篇讲的顺序也是这个意思：先把流程映射到屏幕，再谈好不好看。",[26,56,58],{"id":57},"_1-从流程到屏幕三步","1 从流程到屏幕：三步",[60,61,63],"h3",{"id":62},"_11-把活动图的每一步映射到屏幕或操作","1.1 把活动图的每一步映射到屏幕或操作",[13,65,66],{},"08 篇那个「申请配件」活动图，逐步映射到屏幕是这样：",[68,69,70,83],"table",{},[71,72,73],"thead",{},[74,75,76,80],"tr",{},[77,78,79],"th",{},"活动图里的步骤",[77,81,82],{},"对应的屏幕或操作",[84,85,86,95,103,111,119],"tbody",{},[74,87,88,92],{},[89,90,91],"td",{},"提交备料申请",[89,93,94],{},"「申请配件」表单（配件编号 + 数量）",[74,96,97,100],{},[89,98,99],{},"校验工单状态",[89,101,102],{},"不需要屏幕 —— 系统内部校验，失败时在表单顶部显示红条",[74,104,105,108],{},[89,106,107],{},"查询供应商库存",[89,109,110],{},"不需要独立屏幕 —— 提交后在同一页显示库存结果",[74,112,113,116],{},[89,114,115],{},"库存充足 → 生成出库单",[89,117,118],{},"「提交成功」结果页（含出库单号与领取提示）",[74,120,121,124],{},[89,122,123],{},"库存不足 → 工单置为待件挂起",[89,125,126],{},"「库存不足」结果页（含「已通知仓管补货」与「预计到货」）",[13,128,129,130,133],{},"映射完常常会发现某些步骤没有屏幕可落 —— 那说明流程里漏了一步。本例映射时也发现了一个：",[21,131,132],{},"「工程师怎么知道配件到货了？」"," 活动图里没有这一步，但如果没有它，整个「待件挂起」的流程就断在这里。",[60,135,137],{"id":136},"_12-标出主路径和分支","1.2 标出主路径和分支",[13,139,140],{},"用户 80% 的时间走的是哪条路？那条路应该最短。分支（缺料、改约）可以深一层，但必须能到达。",[13,142,143,144,147,148,151],{},"本例里主路径明确：",[21,145,146],{},"客服派单","。她一天要派 80 单，每单背后都是一次完整的「看排期 → 筛技能 → 选人 → 通知」。这条路径必须能在",[21,149,150],{},"一屏内完成，不跳页","。",[13,153,154],{},"而分支路径（比如「工程师临时请假，要改派」）一天可能只有两三次，放在二级页面完全可接受。",[60,156,158],{"id":157},"_13-先画线框图wireframe再做视觉稿mock-up","1.3 先画线框图（wireframe），再做视觉稿（mock-up）",[13,160,161,162],{},"线框图只表达结构和位置关系（哪里是标题、哪里是列表、按钮在不在视线内），不带颜色和字体。这样讨论时才不会跑题到「这个蓝色不好看」——",[21,163,164],{},"结构没定之前，颜色讨论没有意义。",[13,166,167,168,171],{},"而且线框图在本例里有个额外的现实价值：",[21,169,170],{},"王姐和小林都不是设计专业出身，但她们能看懂方框和文字","。拿一张带颜色的稿子去给她们看，她们会不好意思说「不好看」；拿线框图去，她们会直接说「这里应该放客户电话，因为我派单时要打给他」。",[13,173,174],{},[175,176],"img",{"alt":177,"src":178},"界面设计与 CRUD 任务流：上方是工单在列表页、详情页、编辑页三个屏幕之间的跳转关系；下方是新建、查看、修改、删除四种操作分别对应哪个屏幕与关键设计点，每种都举了本例的具体遗漏","\u002Fimages\u002Fsw-design-notes-12-ui-crud-flow.svg",[26,180,182],{"id":181},"_2-crud-任务流一张万能的检查表","2 CRUD 任务流：一张万能的检查表",[60,184,186],{"id":185},"_21-四种操作与常见遗漏","2.1 四种操作与常见遗漏",[13,188,189,190,193],{},"任何一个业务实体，用户基本都会对它做四件事：新建、查看、修改、删除 —— 也就是 ",[21,191,192],{},"CRUD（Create \u002F Read \u002F Update \u002F Delete）","。把这四件事逐一对着屏幕过一遍，能快速发现缺失。",[13,195,196],{},"拿本例的「工单」过一遍：",[68,198,199,212],{},[71,200,201],{},[74,202,203,206,209],{},[77,204,205],{},"操作",[77,207,208],{},"对应屏幕",[77,210,211],{},"本例容易漏掉的地方",[84,213,214,225,236,247],{},[74,215,216,219,222],{},[89,217,218],{},"Create 新建",[89,220,221],{},"「提交报修」表单",[89,223,224],{},"必填项没标；客户填了三行地址，提交失败后全丢了",[74,226,227,230,233],{},[89,228,229],{},"Read 查看",[89,231,232],{},"客服的待派列表 + 工单详情",[89,234,235],{},"列表里没有「客户电话」，客服要一个个点进去才能打电话",[74,237,238,241,244],{},[89,239,240],{},"Update 修改",[89,242,243],{},"从详情页进入编辑",[89,245,246],{},"改完跳回列表，客服找不到自己刚改的那条（列表按创建时间排，刚改的沉到底）",[74,248,249,252,255],{},[89,250,251],{},"Delete 删除",[89,253,254],{},"二次确认",[89,256,257],{},"只说「确定删除吗」，不说明「关联的配件消耗记录会一起删」",[13,259,260,261,264],{},"第三个遗漏特别值得说：",[21,262,263],{},"「改完要回到哪」这件事，行内人从来不觉得是问题","，因为开发知道数据存哪了。但用户不知道 —— 她只知道自己刚改的那一单找不到了。",[60,266,268],{"id":267},"_22-列表页和详情页的分工","2.2 列表页和详情页的分工",[13,270,271,272,275],{},"「查看」这一行值得多说一句：列表页和详情页承担的任务不同 —— ",[21,273,274],{},"列表页负责让人做筛选和比较，详情页负责让人做决定","。列表里该出现的是能支持比较的字段（时间、价格、状态），而不是全部字段堆在一起。",[13,277,278],{},"本例的待派列表该放哪些字段，可以从「小林要做什么决定」倒推：",[68,280,281,291],{},[71,282,283],{},[74,284,285,288],{},[77,286,287],{},"她要知道",[77,289,290],{},"才放在列表里",[84,292,293,301,309,317],{},[74,294,295,298],{},[89,296,297],{},"这个人急不急？",[89,299,300],{},"报修时间、是否标记加急",[74,302,303,306],{},[89,304,305],{},"谁适合去？",[89,307,308],{},"片区、家电类型",[74,310,311,314],{},[89,312,313],{},"能不能联系上？",[89,315,316],{},"客户电话",[74,318,319,322],{},[89,320,321],{},"有没有历史？",[89,323,324],{},"该客户是否老客户（有无未闭环工单）",[13,326,327,328,331],{},"地址",[21,329,330],{},"不该","全放在列表里 —— 太占宽度，而且她在派单前不需要知道具体门牌号。地址放详情页。",[26,333,335],{"id":334},"_3-界面必须回答的三个问题","3 界面必须回答的三个问题",[60,337,339],{"id":338},"_31-三个问题","3.1 三个问题",[13,341,342],{},"不管什么界面，用户随时会问三件事：",[344,345,346,353,359],"ol",{},[347,348,349,352],"li",{},[21,350,351],{},"我在哪？"," —— 当前位置是否清楚（标题、面包屑、高亮）；",[347,354,355,358],{},[21,356,357],{},"我能去哪？"," —— 有哪些可选的下一步；",[347,360,361,364],{},[21,362,363],{},"我怎么回去？"," —— 返回路径是否存在。",[13,366,367],{},"三个问题在本例的派单台上分别对应：",[369,370,371,377,383],"ul",{},[347,372,373,376],{},[21,374,375],{},"我在哪"," —— 顶部显示「片区 A · 待派单（12）」；",[347,378,379,382],{},[21,380,381],{},"我能去哪"," —— 每一行右侧有「派单」「改约」两个明确按钮，而不是藏在「更多」菜单里；",[347,384,385,388],{},[21,386,387],{},"我怎么回去"," —— 派单成功后显示「已派给老陈 · 撤销」，「撤销」就是回去的路。",[13,390,391,392,395],{},"第三条尤其重要：",[21,393,394],{},"派错人这件事一定会发生","，所以「撤销」不是加分项，是必需项。",[60,397,399],{"id":398},"_32-寻路wayfinding","3.2 寻路（wayfinding）",[13,401,402,403,406,407,151],{},"这套东西有个专门说法叫",[21,404,405],{},"寻路（wayfinding）","，借自建筑与城市设计。人在建筑里迷路，和人在界面里迷路，原因是一样的：",[21,408,409],{},"缺少位置提示和可预期的路径",[13,411,412,413,416],{},"本例里最典型的寻路问题出现在",[21,414,415],{},"工程师的 App","：他一天要跑 4–5 单，如果他不知道「现在是第几单、还有几单」，就会一直心里没底。所以 App 首页必须有一行「今日 4 单 · 已完成 1 · 下一单 14:00」，这一行解决的就是寻路。",[26,418,420],{"id":419},"_4-信息架构","4 信息架构",[60,422,424],{"id":423},"_41-两种起点top-down-与-bottom-up","4.1 两种起点：top-down 与 bottom-up",[13,426,427,430],{},[21,428,429],{},"信息架构（information architecture）"," 要解决的是「内容怎么组织」。两种起点：",[369,432,433,439],{},[347,434,435,438],{},[21,436,437],{},"top-down（自顶向下）"," —— 先问「用户要完成什么任务」，再按任务组织内容；",[347,440,441,444],{},[21,442,443],{},"bottom-up（自底向上）"," —— 先把已有内容归类，再抽出上层结构。",[13,446,447],{},"实际项目通常是两者结合：新系统偏 top-down，改造老系统偏 bottom-up。",[13,449,450,451,454,455],{},"本例属于前者偏多 —— 因为是新建系统。但有一块必须 bottom-up：",[21,452,453],{},"配件分类","。仓管小周的台账上已经有几百个配件型号，那套分类方式（按家电类型 \u002F 按品牌 \u002F 按功能）虽然不完美，但硬改成新分类会导致历史数据对不上。",[21,456,457],{},"所以配件这块沿用旧分类，其他部分按新任务组织。",[60,459,461],{"id":460},"_42-组织原则","4.2 组织原则",[13,463,464,465,468],{},"组织内容时还需要一个",[21,466,467],{},"组织原则（organizing principle）"," —— 也就是「按什么分组」。常见的几种：按任务、按主题、按对象、按受众。选哪一种取决于用户脑子里是怎么找东西的。",[13,470,471],{},"本例里，四个角色的组织原则其实不一样：",[68,473,474,487],{},[71,475,476],{},[74,477,478,481,484],{},[77,479,480],{},"角色",[77,482,483],{},"他脑中的组织方式",[77,485,486],{},"界面上应该按什么分",[84,488,489,500,511,522],{},[74,490,491,494,497],{},[89,492,493],{},"客服",[89,495,496],{},"按「急不急」找",[89,498,499],{},"按时间\u002F加急排序",[74,501,502,505,508],{},[89,503,504],{},"工程师",[89,506,507],{},"按「今天去哪」找",[89,509,510],{},"按时间顺序的今日路线",[74,512,513,516,519],{},[89,514,515],{},"仓管",[89,517,518],{},"按「配件型号」找",[89,520,521],{},"按配件编号\u002F分类",[74,523,524,527,530],{},[89,525,526],{},"片区经理",[89,528,529],{},"按「哪个片区出问题」找",[89,531,532],{},"按片区汇总",[13,534,535,538],{},[21,536,537],{},"这一条直接否掉了「做一套通用界面给所有人」的想法","。四个角色的组织方式不同，硬合并只会让每个人都要在自己不需要的信息里找。",[60,540,542],{"id":541},"_43-受控词汇","4.3 受控词汇",[13,544,545,546,549],{},"最后是",[21,547,548],{},"受控词汇（controlled vocabulary）","：全站用统一的词表。同一个东西不能在列表页叫「订单」、在详情页叫「交易」、在报表里叫「单据」—— 用户会以为是三样东西。",[13,551,552],{},"本例的受控词表很短，但要一开始定死：",[68,554,555,565],{},[71,556,557],{},[74,558,559,562],{},[77,560,561],{},"统一用词",[77,563,564],{},"不要用",[84,566,567,575,582,590],{},[74,568,569,572],{},[89,570,571],{},"工单",[89,573,574],{},"订单、单子、派工单、报修单",[74,576,577,579],{},[89,578,504],{},[89,580,581],{},"师傅、维修员、技术员",[74,583,584,587],{},[89,585,586],{},"配件",[89,588,589],{},"零件、物料、备件",[74,591,592,595],{},[89,593,594],{},"片区",[89,596,597],{},"区域、网点、分部",[13,599,600,601,604],{},"这张表看着琐碎，但它是",[21,602,603],{},"客服和客户在电话里沟通的基础"," —— 如果客服说「您的派工单」，客户会问「什么是派工单」。",[26,606,608],{"id":607},"_5-导航设计navigation-design五种类型","5 导航设计（navigation design）：五种类型",[60,610,612],{"id":611},"_51-五种类型的分工","5.1 五种类型的分工",[68,614,615,628],{},[71,616,617],{},[74,618,619,622,625],{},[77,620,621],{},"类型",[77,623,624],{},"作用",[77,626,627],{},"本例的例子",[84,629,630,641,652,663,674],{},[74,631,632,635,638],{},[89,633,634],{},"global navigation（全局导航）",[89,636,637],{},"通向系统的主要分区，每页都有",[89,639,640],{},"客服端顶部：待派单 \u002F 已派单 \u002F 客户",[74,642,643,646,649],{},[89,644,645],{},"local navigation（局部导航）",[89,647,648],{},"当前分区内部的入口",[89,650,651],{},"待派单页左侧按片区筛选",[74,653,654,657,660],{},[89,655,656],{},"supplementary navigation（补充导航）",[89,658,659],{},"提供捷径，跨层直达",[89,661,662],{},"右上角搜工单号",[74,664,665,668,671],{},[89,666,667],{},"contextual navigation（上下文导航）",[89,669,670],{},"嵌在内容里的相关链接",[89,672,673],{},"工单详情里的「该客户历史工单」",[74,675,676,679,682],{},[89,677,678],{},"courtesy navigation（礼节性导航）",[89,680,681],{},"与主任务无关但用户偶需",[89,683,684],{},"帮助、快捷键说明",[60,686,688],{"id":687},"_52-上下文导航为什么最有用","5.2 上下文导航为什么最有用",[13,690,691,692,695],{},"其中",[21,693,694],{},"上下文导航最容易被忽略，但价值最高"," —— 它出现在用户刚好需要的那一刻。",[13,697,698,699,702],{},"本例里有个很强的例子：客服在派单前，最想知道的往往是「",[21,700,701],{},"这个客户以前是谁去的","」。如果是老客户，派给同一个工程师体验最好，而且那人熟悉这家的情况。",[13,704,705],{},"如果这个链接不存在，她要先复制客户名、切到客户页、搜索、找历史单 —— 四步，通常就放弃了。把它做成工单详情里的一行「上次由老陈维修 · 查看」，她一步就能看到。",[13,707,708,711],{},[21,709,710],{},"判断某个上下文导航值不值得做，问一句：不做的话，用户要绕几步","？绕四步以上的，基本都值得做。",[26,713,715],{"id":714},"_6-交互设计与视觉设计","6 交互设计与视觉设计",[60,717,719],{"id":718},"_61-交互设计管的是什么","6.1 交互设计管的是什么",[13,721,722,725],{},[21,723,724],{},"交互设计（interaction design）"," 管的是「操作的反馈」：点了有没有反应、要等多久、出错怎么提示。",[13,727,728],{},"本例里三个具体的交互决策：",[369,730,731,737,743],{},[347,732,733,736],{},[21,734,735],{},"派单按钮点击后立刻禁用"," —— 防止客服手快连点两次派出两单；",[347,738,739,742],{},[21,740,741],{},"查询外部库存时显示「正在查询供应商…」（带进度）"," —— 因为这个调用可能要 2–3 秒，没有反馈她会以为卡死了；",[347,744,745,748],{},[21,746,747],{},"表单校验在失焦时做，不在输入时做"," —— 输入时就报错会让人烦躁（「我刚打了个 1 你就说不行」）。",[60,750,752],{"id":751},"_62-视觉设计的四条规则","6.2 视觉设计的四条规则",[13,754,755,758],{},[21,756,757],{},"视觉设计（visual design）"," 管的是呈现。几条最实用的规则：",[369,760,761,767,773,779],{},[347,762,763,766],{},[21,764,765],{},"一致性（consistency）"," —— 同类元素用同样的样式和行为。内部不一致会让用户反复试探；",[347,768,769,772],{},[21,770,771],{},"留白（white space）"," —— 不是浪费空间。没有留白，信息密度过高，反而没人看得下去；",[347,774,775,778],{},[21,776,777],{},"字体排印（typography）"," —— 字号层级要能一眼分辨主次，正文字号不该小于舒适阅读的下限；",[347,780,781,784],{},[21,782,783],{},"响应时间（response time）"," —— 操作反馈的时间直接影响可用性（usability）。超过大约一秒没有反馈，用户就会怀疑是不是没点上。",[13,786,787,788,791],{},"第四条在本例里有个具体阈值：",[21,789,790],{},"外部库存查询一旦超过 1 秒，就必须有 loading 状态","。这不是「好看」，而是「让她知道系统没死」。",[26,793,795],{"id":794},"_7-两类特殊页面","7 两类特殊页面",[60,797,799],{"id":798},"_71-启动台","7.1 启动台",[13,801,802,805],{},[21,803,804],{},"启动台（launching pad）"," —— 系统的主入口页。它不该是功能的堆积，而应该回答「这个人现在最可能要做哪几件事」，把高频入口放在最显眼处。",[13,807,808],{},"本例的四个角色，启动台应该完全不同：",[68,810,811,820],{},[71,812,813],{},[74,814,815,817],{},[77,816,480],{},[77,818,819],{},"登录后第一眼该看到",[84,821,822,829,836,843],{},[74,823,824,826],{},[89,825,493],{},[89,827,828],{},"待派单列表（按加急 + 时间排序）",[74,830,831,833],{},[89,832,504],{},[89,834,835],{},"今日路线（下一单是哪个）",[74,837,838,840],{},[89,839,515],{},[89,841,842],{},"待出库 + 缺料预警",[74,844,845,847],{},[89,846,526],{},[89,848,849],{},"看板（完成率、缺料率、超时单）",[13,851,852],{},[21,853,854],{},"如果四个人看到的是同一个首页，那这个首页一定不是启动台，只是功能入口目录。",[60,856,858],{"id":857},"_72-仪表板","7.2 仪表板",[13,860,861,864,865,868],{},[21,862,863],{},"仪表板（dashboard）"," —— 面向管理者的一屏概览。它的难点不是把指标堆上去，而是选出",[21,866,867],{},"真正需要每天看的那几个","。这里会用到数据叙事（data storytelling）的思路：一屏讲清一件事，而不是把二十个图表摆满。",[13,870,871],{},"本例的经理看板只放四块，理由都很具体：",[68,873,874,887],{},[71,875,876],{},[74,877,878,881,884],{},[77,879,880],{},"区块",[77,882,883],{},"为什么放它",[77,885,886],{},"隐喻",[84,888,889,900,911,922],{},[74,890,891,894,897],{},[89,892,893],{},"排期周历",[89,895,896],{},"客服和她都要看谁有空",[89,898,899],{},"日历 = 排期",[74,901,902,905,908],{},[89,903,904],{},"待办请求（红黄绿灯）",[89,906,907],{},"一眼知道先催哪单",[89,909,910],{},"红绿灯 = 紧急度",[74,912,913,916,919],{},[89,914,915],{},"工单看板四列",[89,917,918],{},"状态流转一目了然",[89,920,921],{},"看板列 = 状态",[74,923,924,927,930],{},[89,925,926],{},"底部四个数字",[89,928,929],{},"完成率、上门时长、缺料率、满意度",[89,931,932],{},"数字 = 结果",[13,934,935],{},"27 篇里的那张仪表板成品图，就是照这张表画的。",[26,937,939],{"id":938},"_8-移动端与-web-端的差别","8 移动端与 Web 端的差别",[60,941,943],{"id":942},"_81-移动端的四点特殊性","8.1 移动端的四点特殊性",[13,945,946,949],{},[21,947,948],{},"移动端","的特殊性（本例里工程师用 App）：",[369,951,952,955,962,965],{},[347,953,954],{},"屏幕小 → 一屏只能做一件事，步骤必须分开。他填工单时不希望同时看到别的；",[347,956,957,958,961],{},"网络不稳 → 需要明确加载状态、断网处理、数据不丢。",[21,959,960],{},"他在客户家里，可能是地下车库没信号"," —— 填了一半的工单必须能暂存；",[347,963,964],{},"有系统级通知 → 可以主动触达，但也带来了打扰的风险。派单推送在晚上十点发出去会被骂；",[347,966,967],{},"有平台规范（human interface guidelines, HIG）→ 遵循它能让用户不需要重新学习。",[13,969,970,971,974],{},"第二条在本例里是硬需求：",[21,972,973],{},"工程师回填工单必须支持离线暂存","。这一条在 Web 端通常不需要考虑，但在移动端是「不做就没人用」的功能。",[60,976,978],{"id":977},"_82-web-端的特殊性","8.2 Web 端的特殊性",[13,980,981,984],{},[21,982,983],{},"Web 端","的特殊性（客服与经理用）：",[369,986,987,990,993],{},[347,988,989],{},"窗口尺寸不可控 → 需要响应式设计（responsive web design）；",[347,991,992],{},"层级深 → 面包屑（bread crumbs）和搜索变得重要；",[347,994,995],{},"用户来自不同地区 → 需要考虑国际化（internationalization）与本地化。",[13,997,998,999],{},"本例里第二条很实际：客服端三层（分区 → 列表 → 详情），她一天要在这三层之间来回几十次。",[21,1000,1001],{},"没有面包屑，她会迷路；没有全局搜索，她只能用浏览器后退。",[26,1003,1005],{"id":1004},"_9-界面设计会反过来改需求","9 界面设计会反过来改需求",[60,1007,1009],{"id":1008},"_91-三类会被暴露出来的问题","9.1 三类会被暴露出来的问题",[13,1011,1012],{},"回到开头的观点。画界面的过程会稳定地暴露三类问题：",[344,1014,1015,1021,1027],{},[347,1016,1017,1020],{},[21,1018,1019],{},"流程缺步骤"," —— 某个状态没有出口，用户卡在原地。本例：「工程师怎么知道配件到货了」这一步活动图里没有；",[347,1022,1023,1026],{},[21,1024,1025],{},"数据不够"," —— 界面上需要展示的信息，需求里没定义。本例：列表要显示「是否老客户」，但领域模型里没有这个字段；",[347,1028,1029,1032],{},[21,1030,1031],{},"规则没说清"," —— 「确定删除吗」之后到底删了什么，只有画界面时才会被迫回答。本例：删工单时，配件消耗记录跟不跟着删？",[13,1034,1035,1036,1039],{},"所以",[21,1037,1038],{},"界面设计最好在需求定稿之前做一轮","，这样它发现的漏洞还能低成本地补回去。",[13,1041,1042,1043,1046],{},"第 3 条在本例里还有个延伸：",[21,1044,1045],{},"工单能不能删","？讨论到的结论是「不能删，只能作废」—— 因为它是结算依据。这个决定如果在开发完成后才提出来，表结构就要大改。",[26,1048,1049],{"id":1049},"本节自测",[344,1051,1052,1055,1058,1061,1064,1067,1070],{},[347,1053,1054],{},"为什么先画线框图再讨论视觉？跳过这一步会出什么问题？",[347,1056,1057],{},"用 CRUD 检查一遍工单，四个操作里哪一个最容易漏掉后续状态？本例的具体表现是什么？",[347,1059,1060],{},"「我在哪 \u002F 我能去哪 \u002F 我怎么回去」三个问题，分别靠界面上的什么元素回答？本例中「撤销」为什么是必需项？",[347,1062,1063],{},"五种导航类型里，哪一种最容易被忽略、又最有用？用什么标准判断它值不值得做？",[347,1065,1066],{},"响应时间为什么属于界面设计问题，而不只是性能问题？",[347,1068,1069],{},"本例中配件分类为什么必须沿用旧分类（bottom-up），而其他部分可以按新任务组织？",[347,1071,1072],{},"移动端的「网络不稳」在本例里变成了哪一条硬需求？",[60,1074,1075],{"id":1075},"参考答案",[344,1077,1078,1081,1087,1102,1112,1119,1126],{},[347,1079,1080],{},"因为线框图只表达结构与位置，讨论才不会跑题到颜色。跳过它会让业务方不好意思说「不好看」，却说不出真正的结构问题。本例中画线框图是为了让王姐和小林能直接说「这里该放客户电话」（§1.3）。",[347,1082,1083,1086],{},[21,1084,1085],{},"Update（修改）","。本例表现：改完跳回列表后，因为列表按创建时间排序，刚改的那条沉到底，客服找不到自己刚改的单（§2.1）。",[347,1088,1089,1091,1092,1094,1095,1097,1098,1101],{},[21,1090,375],{},"靠标题与计数（「片区 A · 待派单 12」）；",[21,1093,381],{},"靠每行的明确按钮；",[21,1096,387],{},"靠返回路径与「撤销」。本例「撤销」是必需项，因为",[21,1099,1100],{},"派错人一定会发生","（§3.1）。",[347,1103,1104,1107,1108,1111],{},[21,1105,1106],{},"上下文导航","最有价值。判据是 ",[21,1109,1110],{},"「不做的话用户要绕几步」"," —— 绕四步以上的基本都值得做。本例「上次由老陈维修」不做要绕四步（§5.2）。",[347,1113,1114,1115,1118],{},"因为超过一秒没有反馈，用户会",[21,1116,1117],{},"怀疑是不是没点上","，这直接破坏可用性。本例给外部库存查询定了「超 1 秒必须有 loading」（§6.2）。",[347,1120,1121,1122,1125],{},"因为仓管台账上已有几百个配件型号，硬改成新分类会导致",[21,1123,1124],{},"历史数据对不上","。这属于改造既有内容的场景，适合 bottom-up（§4.1）。",[347,1127,1128,1129,1131],{},"变成「",[21,1130,973],{},"」。他在客户家里可能在地下车库没信号，填了一半的工单不能丢（§8.1）。",[26,1133,1134],{"id":1134},"术语表",[68,1136,1137,1150],{},[71,1138,1139],{},[74,1140,1141,1144,1147],{},[77,1142,1143],{},"术语",[77,1145,1146],{},"中文",[77,1148,1149],{},"一句话解释",[84,1151,1152,1163,1174,1185,1196,1207,1218,1229,1240,1250,1261,1270,1281,1292,1303,1314,1325,1336,1347,1358,1369,1380,1391,1402,1413,1424,1435],{},[74,1153,1154,1157,1160],{},[89,1155,1156],{},"interaction design",[89,1158,1159],{},"交互设计",[89,1161,1162],{},"设计操作的反馈与流程衔接",[74,1164,1165,1168,1171],{},[89,1166,1167],{},"information architecture",[89,1169,1170],{},"信息架构",[89,1172,1173],{},"内容的组织方式与层次结构",[74,1175,1176,1179,1182],{},[89,1177,1178],{},"top-down",[89,1180,1181],{},"自顶向下",[89,1183,1184],{},"从用户任务出发组织内容",[74,1186,1187,1190,1193],{},[89,1188,1189],{},"bottom-up",[89,1191,1192],{},"自底向上",[89,1194,1195],{},"从已有内容归类再抽上层结构",[74,1197,1198,1201,1204],{},[89,1199,1200],{},"organizing principle",[89,1202,1203],{},"组织原则",[89,1205,1206],{},"决定按什么维度分组内容",[74,1208,1209,1212,1215],{},[89,1210,1211],{},"controlled vocabulary",[89,1213,1214],{},"受控词汇",[89,1216,1217],{},"全站统一使用的术语表",[74,1219,1220,1223,1226],{},[89,1221,1222],{},"navigation design",[89,1224,1225],{},"导航设计",[89,1227,1228],{},"设计用户在各层级之间移动的方式",[74,1230,1231,1234,1237],{},[89,1232,1233],{},"global navigation",[89,1235,1236],{},"全局导航",[89,1238,1239],{},"通向系统主要分区的固定入口",[74,1241,1242,1245,1248],{},[89,1243,1244],{},"local navigation",[89,1246,1247],{},"局部导航",[89,1249,648],{},[74,1251,1252,1255,1258],{},[89,1253,1254],{},"supplementary navigation",[89,1256,1257],{},"补充导航",[89,1259,1260],{},"搜索、站点地图这类捷径",[74,1262,1263,1266,1268],{},[89,1264,1265],{},"contextual navigation",[89,1267,1106],{},[89,1269,670],{},[74,1271,1272,1275,1278],{},[89,1273,1274],{},"courtesy navigation",[89,1276,1277],{},"礼节性导航",[89,1279,1280],{},"帮助、联系方式这类辅助入口",[74,1282,1283,1286,1289],{},[89,1284,1285],{},"wayfinding",[89,1287,1288],{},"寻路",[89,1290,1291],{},"让用户随时知道自己在哪、能去哪",[74,1293,1294,1297,1300],{},[89,1295,1296],{},"wireframe",[89,1298,1299],{},"线框图",[89,1301,1302],{},"只表达结构与位置关系的草图",[74,1304,1305,1308,1311],{},[89,1306,1307],{},"mock-up",[89,1309,1310],{},"视觉稿",[89,1312,1313],{},"带颜色字体的高保真设计稿",[74,1315,1316,1319,1322],{},[89,1317,1318],{},"visual design",[89,1320,1321],{},"视觉设计",[89,1323,1324],{},"颜色、字体、层级等呈现层面的设计",[74,1326,1327,1330,1333],{},[89,1328,1329],{},"consistency",[89,1331,1332],{},"一致性",[89,1334,1335],{},"同类元素保持相同的样式与行为",[74,1337,1338,1341,1344],{},[89,1339,1340],{},"white space",[89,1342,1343],{},"留白",[89,1345,1346],{},"刻意留出的空白，用于降低信息密度",[74,1348,1349,1352,1355],{},[89,1350,1351],{},"typography",[89,1353,1354],{},"字体排印",[89,1356,1357],{},"字号、字重、行距等文字呈现方式",[74,1359,1360,1363,1366],{},[89,1361,1362],{},"usability",[89,1364,1365],{},"可用性",[89,1367,1368],{},"用户能不能顺利完成任务的衡量",[74,1370,1371,1374,1377],{},[89,1372,1373],{},"responsive web design",[89,1375,1376],{},"响应式设计",[89,1378,1379],{},"页面随屏幕宽度自适应布局",[74,1381,1382,1385,1388],{},[89,1383,1384],{},"human interface guidelines（HIG）",[89,1386,1387],{},"人机界面指南",[89,1389,1390],{},"平台官方给出的界面规范",[74,1392,1393,1396,1399],{},[89,1394,1395],{},"launching pad",[89,1397,1398],{},"启动台",[89,1400,1401],{},"系统主入口页，放高频功能入口",[74,1403,1404,1407,1410],{},[89,1405,1406],{},"dashboard",[89,1408,1409],{},"仪表板",[89,1411,1412],{},"一屏概览关键指标的页面",[74,1414,1415,1418,1421],{},[89,1416,1417],{},"data storytelling",[89,1419,1420],{},"数据叙事",[89,1422,1423],{},"用图表讲清一件事，而不是堆数据",[74,1425,1426,1429,1432],{},[89,1427,1428],{},"CRUD",[89,1430,1431],{},"增查改删",[89,1433,1434],{},"Create、Read、Update、Delete 四种基本操作",[74,1436,1437,1440,1443],{},[89,1438,1439],{},"internationalization",[89,1441,1442],{},"国际化",[89,1444,1445],{},"让产品能适配不同语言与地区",{"title":1447,"searchDepth":1448,"depth":1448,"links":1449},"",3,[1450,1452,1457,1461,1465,1470,1474,1478,1482,1486,1489,1492],{"id":28,"depth":1451,"text":29},2,{"id":57,"depth":1451,"text":58,"children":1453},[1454,1455,1456],{"id":62,"depth":1448,"text":63},{"id":136,"depth":1448,"text":137},{"id":157,"depth":1448,"text":158},{"id":181,"depth":1451,"text":182,"children":1458},[1459,1460],{"id":185,"depth":1448,"text":186},{"id":267,"depth":1448,"text":268},{"id":334,"depth":1451,"text":335,"children":1462},[1463,1464],{"id":338,"depth":1448,"text":339},{"id":398,"depth":1448,"text":399},{"id":419,"depth":1451,"text":420,"children":1466},[1467,1468,1469],{"id":423,"depth":1448,"text":424},{"id":460,"depth":1448,"text":461},{"id":541,"depth":1448,"text":542},{"id":607,"depth":1451,"text":608,"children":1471},[1472,1473],{"id":611,"depth":1448,"text":612},{"id":687,"depth":1448,"text":688},{"id":714,"depth":1451,"text":715,"children":1475},[1476,1477],{"id":718,"depth":1448,"text":719},{"id":751,"depth":1448,"text":752},{"id":794,"depth":1451,"text":795,"children":1479},[1480,1481],{"id":798,"depth":1448,"text":799},{"id":857,"depth":1448,"text":858},{"id":938,"depth":1451,"text":939,"children":1483},[1484,1485],{"id":942,"depth":1448,"text":943},{"id":977,"depth":1448,"text":978},{"id":1004,"depth":1451,"text":1005,"children":1487},[1488],{"id":1008,"depth":1448,"text":1009},{"id":1049,"depth":1451,"text":1049,"children":1490},[1491],{"id":1075,"depth":1448,"text":1075},{"id":1134,"depth":1451,"text":1134},"学习",null,"2026-11-03","界面设计不是「画得好看」：从活动图走到屏幕的三步，CRUD 任务流怎么当检查表，界面必须回答的三个问题，信息架构与五种导航类型，视觉一致性与留白，以及移动端与 Web 端的差别。","md",false,{},true,"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-12",{"title":5,"description":1496},"软件分析与设计笔记",12,"posts\u002FswDesign\u002Fsw-design-notes-12",[1507,1159,1508,1509],"界面设计","用户体验","学习笔记","3Wm5S1dupGRyE1Ci_E00Mu62jYvfrmRVRwC-04bENP8",[1512,1518,1524,1530,1536,1542,1548,1554,1560,1566,1572,1578,1584,1590,1596,1602,1608,1609,1615,1621,1627,1633,1639,1645,1651,1657,1662,1667,1673,1679,1683,1687,1691,1695,1699,1703,1707,1711,1715,1719,1723,1729,1733,1739,1743,1747,1751,1755,1759,1763,1767,1772,1776,1780,1785,1790,1796,1800,1805,1809],{"path":1513,"title":1514,"description":1515,"date":1516,"series":1503,"seriesOrder":1517},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-28","软件分析与设计笔记 28：draw.io 作图手册：五张图的符号位置、落笔顺序与自检","不模拟软件界面，只讲清三件事：每个 UML 符号在 draw.io 里搜什么词、一张图该按什么顺序落笔、画完拿什么标准自查。覆盖用例图、活动图、顺序图、类图、界面草图五种图纸，末尾附「最容易画反的十二笔」总检表。","2026-11-19",28,{"path":1519,"title":1520,"description":1521,"date":1522,"series":1503,"seriesOrder":1523},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-27","软件分析与设计笔记 27：Paper 1 应试：从读案例到交卷的一次完整演算","拿一份完整的案例，从头到尾走一遍：怎么读案例列角色、怎么在四个小问之间分配时间、每一张图从哪一句话推出来、两张表怎么填、交卷前拿什么清单自查。附 C25 真题与样卷的题型分值对照。","2026-11-18",27,{"path":1525,"title":1526,"description":1527,"date":1528,"series":1503,"seriesOrder":1529},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-26","软件分析与设计笔记 26：总结：把整条链路串起来","系列收尾：从需求到代码的完整链路回顾、每一环的产出与验收方式、六条贯穿全系列的原则，以及一份可以直接拿去做项目自查的清单。","2026-11-17",26,{"path":1531,"title":1532,"description":1533,"date":1534,"series":1503,"seriesOrder":1535},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-25","软件分析与设计笔记 25：代码重构：坏味道与手法","重构不改变外部行为、只改善内部结构：四种常见坏味道与对应手法、为什么动手之前必须先有测试、什么时候该重构，以及重构和前面那些设计模型是什么关系。","2026-11-16",25,{"path":1537,"title":1538,"description":1539,"date":1540,"series":1503,"seriesOrder":1541},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-24","软件分析与设计笔记 24：设计原则：内聚、耦合与多态","好设计怎么衡量：内聚与耦合分别在说什么、一次从「差设计」到「多态重设计」的完整对照、抽象类与接口的选择依据，以及复用为什么会从优势变成风险。","2026-11-15",24,{"path":1543,"title":1544,"description":1545,"date":1546,"series":1503,"seriesOrder":1547},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-23","软件分析与设计笔记 23：设计建模：从对象模型到能实现的方案","分析模型能用但还不能直接开工：对象模型怎么映射到关系模型、继承映射的三种方案怎么选、数据访问层与 Data Broker 解决什么问题，以及三层架构与 MVC 的分工。","2026-11-14",23,{"path":1549,"title":1550,"description":1551,"date":1552,"series":1503,"seriesOrder":1553},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-22","软件分析与设计笔记 22：分析建模：边界、实体与控制对象","不经过分析直接写代码会踩什么坑、三种分析对象各管一段、怎么用顺序图完成一次用例实现，以及从顺序图导出类的属性、操作与关系的方法。","2026-11-13",22,{"path":1555,"title":1556,"description":1557,"date":1558,"series":1503,"seriesOrder":1559},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-21","软件分析与设计笔记 21：UML：类图与顺序图","为什么需要一种共同的画法：类符号三格怎么画、五种关系的符号与设计含义、每种关系落到 Java 是什么写法，顺序图的三要素怎么摆；以及这三种最容易找不到的符号在 draw.io 里各搜什么词。","2026-11-12",21,{"path":1561,"title":1562,"description":1563,"date":1564,"series":1503,"seriesOrder":1565},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-20","软件分析与设计笔记 20：面向对象概念：对象、关系与多态","面向对象不是「用某个语言写代码」：对象与类的区别、封装真正在保护什么、五种关系（依赖、关联、聚合、组合、继承）各自何时用，以及多态为什么能减少条件判断。","2026-11-11",20,{"path":1567,"title":1568,"description":1569,"date":1570,"series":1503,"seriesOrder":1571},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-19","软件分析与设计笔记 19：规范化与逻辑数据模型","一次改地址引发的数据不一致，讲清规范化的真正动机；UNF 到 3NF 每一步在解决什么问题，派生字段为什么不能存，优化为什么和规范化方向相反，以及逻辑数据模型在 3NF 之上补了什么。","2026-11-10",19,{"path":1573,"title":1574,"description":1575,"date":1576,"series":1503,"seriesOrder":1577},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-18","软件分析与设计笔记 18：数据库分析：实体、关系与数据字典","为什么不能拿到需求就动手建表：实体与关系怎么判定、基数为什么必须由业务方确认、数据命名要遵守什么规则，以及数据字典四列里最容易被空着的那一列。","2026-11-09",18,{"path":1579,"title":1580,"description":1581,"date":1582,"series":1503,"seriesOrder":1583},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-17","软件分析与设计笔记 17：用生成式 AI 做设计与开发：能用的场景与要防的坑","生成式 AI 在工作流里真正站得住的三个场景 —— 造示例数据、解释陌生代码、起草初稿；它为什么会复现社会偏见、为什么会编得像真的，以及哪些内容绝不能直接采用。","2026-11-08",17,{"path":1585,"title":1586,"description":1587,"date":1588,"series":1503,"seriesOrder":1589},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-16","软件分析与设计笔记 16：从 persona 到 URS：一份交付物的完整骨架","把前面十几篇串成一份能交出去的东西：用户需求规格说明书的九个部分、每一章来自哪个环节、由谁确认，以及面向决策者的提案该讲清哪三件事。","2026-11-07",16,{"path":1591,"title":1592,"description":1593,"date":1594,"series":1503,"seriesOrder":1595},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-15","软件分析与设计笔记 15：非功能需求：把「快、稳、安全」变成数字","为什么「系统要快」不是一条需求：非功能需求怎么量化，决定性能的用户量、交易量、数据量三张表怎么估，安全需求要写清什么，以及可靠性的「不可用」该怎么定义。","2026-11-06",15,{"path":1597,"title":1598,"description":1599,"date":1600,"series":1503,"seriesOrder":1601},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-14","软件分析与设计笔记 14：软件测试：层级、方法与等价类划分","「我们测过了」这句话问题在哪：为什么静态评审和动态测试缺一不可，五个测试层级各自验证什么，白盒与黑盒的差别，以及用等价类划分和边界值把无限输入变成有限用例的方法。","2026-11-05",14,{"path":1603,"title":1604,"description":1605,"date":1606,"series":1503,"seriesOrder":1607},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-13","软件分析与设计笔记 13：需求获取：五种调查方法与一场访谈","需求从哪里来：五种事实调查方法各自适合回答什么、代价是什么，访谈从准备到记录的全过程，问卷设计里最容易犯的错，以及访谈记录必须写下来的那几项信息。","2026-11-04",13,{"path":1501,"title":5,"description":1496,"date":1495,"series":1503,"seriesOrder":1504},{"path":1610,"title":1611,"description":1612,"date":1613,"series":1503,"seriesOrder":1614},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-11","软件分析与设计笔记 11：Agentic AI 与业务流程自动化","AI agent 到底是什么：五项能力与四个核心组件，什么场景该用定时任务、什么该用程序、什么才值得用 agent，两种实现路径的差别，必须提前防住的四类失败模式，以及设计方法从提示词到编排的演进。","2026-11-02",11,{"path":1616,"title":1617,"description":1618,"date":1619,"series":1503,"seriesOrder":1620},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-10","软件分析与设计笔记 10：精炼用例模型：include、extend 与泛化","三种精炼用例关系的判断标准：include 什么时候用、它和 extend 的区别到底在哪、参与者泛化与用例泛化各解决什么问题，以及精炼到什么程度就该停手。","2026-11-01",10,{"path":1622,"title":1623,"description":1624,"date":1625,"series":1503,"seriesOrder":1626},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-09","软件分析与设计笔记 09：功能需求（二）：从流程到业务实体","活动图画完之后，怎么从流程里筛出真正的业务实体：三条判断标准、哪些名词其实不该建实体、属性从哪里来，以及领域模型和后面的数据模型分别负责什么。","2026-10-31",9,{"path":1628,"title":1629,"description":1630,"date":1631,"series":1503,"seriesOrder":1632},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-08","软件分析与设计笔记 08：功能需求（一）：用例模型与活动图","从用户故事到用例的翻译过程：什么才算「好」的参与者，系统边界怎么划，用例描述必须写清哪四件事，活动图怎么把分支、并行与泳道画清楚，以及这两个图在 draw.io 里各用哪个形状、最容易画错哪一笔。","2026-10-30",8,{"path":1634,"title":1635,"description":1636,"date":1637,"series":1503,"seriesOrder":1638},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-07","软件分析与设计笔记 07：用户故事：把需求写成可验收的一句话","用户故事的三段结构，怎么从用户画像和数据地图里把它提取出来，一条故事多大算合适、时序为什么也是需求的一部分，以及验收标准怎么写才算真的可验收。","2026-10-29",7,{"path":1640,"title":1641,"description":1642,"date":1643,"series":1503,"seriesOrder":1644},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-06","软件分析与设计笔记 06：范围界定（数据侧）：用数据校验你的判断","访谈结论和数字对不上时该怎么办：分析的四个层次分别在回答什么问题、为什么不能跳级、数据准备与搜集怎么做成一张应用地图，以及数据最容易在哪几个地方骗你。","2026-10-28",6,{"path":1646,"title":1647,"description":1648,"date":1649,"series":1503,"seriesOrder":1650},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-05","软件分析与设计笔记 05：范围界定（用户侧）：用户画像与客户旅程图","为什么「所有用户」是一个陷阱，项目边界该怎么划，用户画像要写哪五个要素、最容易写成什么废纸，客户旅程图怎么把阶段、想法和情绪画在同一张纸上，以及怎么从这两样东西一步步推到可验证的需求。","2026-10-27",5,{"path":1652,"title":1653,"description":1654,"date":1655,"series":1503,"seriesOrder":1656},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-04","软件分析与设计笔记 04：接手陌生案例的第一步：三问与一张表","拿到一个完全陌生的业务案例，怎么从零开始不跑偏：只问 Who、What、Why 三个问题，把「问题—事实—假设—理由」记成一张四列表，说清为什么假设必须写明理由，以及带着问题进访谈为什么比空手去有效得多。","2026-10-26",4,{"path":1658,"title":1659,"description":1660,"date":1661,"series":1503,"seriesOrder":1448},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-03","软件分析与设计笔记 03：Agile 与 Scrum：迭代、角色与产出物","从「三周做完交付，客户说这不是我要的」讲起，说清瀑布式与迭代式的根本差别，Scrum 的三个角色和三种产出物，一个 sprint 里四次固定活动各自在解决什么问题，以及敏捷里最常见的几个误解。","2026-10-25",{"path":1663,"title":1664,"description":1665,"date":1666,"series":1503,"seriesOrder":1451},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-02","软件分析与设计笔记 02：设计思维、用户驱动与数据驱动","从「客服要一个能一次看完所有排期的界面」这个翻车案例讲起，说清设计思维到底是什么、用户驱动与数据驱动各自能看见什么又看不见什么、为什么真正的落点是把两者合起来的 data-informed design，以及访谈中怎么问出有用的信息。","2026-10-24",{"path":1668,"title":1669,"description":1670,"date":1671,"series":1503,"seriesOrder":1672},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-01","软件分析与设计笔记 01：课程地图与从需求到设计的主干","这一篇不写具体方法，先把整条链路铺开：软件分析与设计到底要解决什么问题，从需求到设计分成哪两段，中间有哪十几个环节，一份完整的交付物里应该有什么，以及后面 27 篇笔记怎么排、新人该按什么顺序读。","2026-10-23",1,{"path":1674,"title":1675,"description":1676,"date":1677,"series":1678,"seriesOrder":1672},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-01","Spring 学习笔记 01：IoC、依赖注入与第一个 Spring Boot 应用","从「手写 new 出来的三层结构」的痛点讲起，说清 IoC 容器、Bean 与依赖注入是怎么回事，再用 Maven 与 Spring Initializr 跑起第一个能返回 JSON 的应用。","2026-10-15","Spring 学习笔记",{"path":1680,"title":1681,"description":1682,"date":1677,"series":1678,"seriesOrder":1451},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-02","Spring 学习笔记 02：Spring Data JPA 基础——实体映射与 Repository","用 ORM 把类映射到表：@Entity、@Id、@GeneratedValue 怎么用，CrudRepository 三层接口怎么选，H2 与 MySQL 怎么配，以及 ddl-auto 到底该写哪个值。",{"path":1684,"title":1685,"description":1686,"date":1677,"series":1678,"seriesOrder":1448},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-03","Spring 学习笔记 03：JPA 查询——派生方法、JPQL 与分页排序","Repository 自带的方法只够按主键查，这篇讲三种自己造查询的方式：方法名派生、@Query 写 JPQL、原生 SQL，以及 Pageable 分页排序和投影返回。",{"path":1688,"title":1689,"description":1690,"date":1677,"series":1678,"seriesOrder":1656},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-04","Spring 学习笔记 04：JPA 关联映射与仓储测试","一对多、多对多怎么映射，谁负责维护外键，FetchType 与 CascadeType 该怎么选，顺带用 @DataJpaTest 与 AssertJ 把仓储层测起来。",{"path":1692,"title":1693,"description":1694,"date":1677,"series":1678,"seriesOrder":1650},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-05","Spring 学习笔记 05：Spring MVC 与 Thymeleaf 入门","一次页面请求在 Spring MVC 里走了哪几步，@Controller 怎么把数据交给模板，@PathVariable 与 @RequestParam 怎么取参数，以及控制器为什么必须是无状态的。",{"path":1696,"title":1697,"description":1698,"date":1677,"series":1678,"seriesOrder":1644},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-06","Spring 学习笔记 06：表单绑定与服务端校验","把表单字段绑到对象上，用 Bean Validation 注解做服务端校验，把错误信息显示回用户刚填的那一页，再补上自定义校验注解与全局异常处理。",{"path":1700,"title":1701,"description":1702,"date":1677,"series":1678,"seriesOrder":1638},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-07","Spring 学习笔记 07：Thymeleaf 片段复用与国际化","用 th:fragment 与 th:insert\u002Fth:replace 把导航栏、页脚抽成片段，页面套用统一布局，再用 messages.properties 与 LocaleResolver 做中英文切换。",{"path":1704,"title":1705,"description":1706,"date":1677,"series":1678,"seriesOrder":1632},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-08","Spring 学习笔记 08：HTTP Session 与会话状态管理","HTTP 无状态带来的问题，Cookie 与 Session 怎么分工，Spring 里读写会话的几种方式，以及会话固定、超时、多实例共享这些必须想清楚的事。",{"path":1708,"title":1709,"description":1710,"date":1677,"series":1678,"seriesOrder":1626},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-09","Spring 学习笔记 09：拦截器 HandlerInterceptor","登录检查、权限判断、请求耗时统计这类横切逻辑该放哪：HandlerInterceptor 的三个回调各在什么时机执行，怎么注册与排除路径，以及它和过滤器的分工。",{"path":1712,"title":1713,"description":1714,"date":1677,"series":1678,"seriesOrder":1620},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-10","Spring 学习笔记 10：Service 层与事务","一组数据库操作要么全成功要么全失败，靠 @Transactional 怎么做到；传播行为、隔离级别、回滚规则怎么选，以及自调用失效、乐观锁悲观锁这些实战里的坑。",{"path":1716,"title":1717,"description":1718,"date":1677,"series":1678,"seriesOrder":1614},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-11","Spring 学习笔记 11：REST API 基础——把 Service 暴露成接口","同一套 Service 怎么同时服务页面和客户端：@RestController 的路由与方法语义、状态码怎么给、DTO 怎么定，以及 MockMvc 端到端和切片测试的两种写法与各自的坑。",{"path":1720,"title":1721,"description":1722,"date":1677,"series":1678,"seriesOrder":1504},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-12","Spring 学习笔记 12：REST 进阶——版本、更新、跨域与文档化","接口能跑通之后要处理的几件事：URL 与响应结构怎么定、版本怎么演进、更新怎么做到可安全重试、CORS 怎么配、HATEOAS 与 Spring Data REST 该不该用。",{"path":1724,"title":1725,"description":1726,"date":1727,"series":1728,"seriesOrder":1656},"\u002Fposts\u002Fjava\u002Fjava-functionalprogramming-notes","Java 函数式编程笔记：Lambda、函数式接口与 Streams","学习 Java 函数式编程时的个人笔记：Lambda 表达式的五步简写与方法引用、常见函数式接口、Stream 流水线与惰性求值，以及创建流、中间操作、终止操作与收集器的用法。示例代码均为自写，运行结果来自本地实测。","2026-10-13","Java 学习笔记",{"path":1730,"title":1731,"description":1732,"date":1727,"series":1728,"seriesOrder":1448},"\u002Fposts\u002Fjava\u002Fjava-generics-notes","Java 泛型笔记：泛型方法、有界类型与泛型类","学习 Java 泛型时的个人笔记：从重复的重载方法与多态尝试讲起，再到泛型方法与类型推断、有界泛型类型、Comparable 与 Number 边界，以及泛型类在集合中的用法。示例代码均为自写，运行结果来自本地实测。",{"path":1734,"title":1735,"description":1736,"date":1737,"series":1738,"seriesOrder":1656},"\u002Fposts\u002Fmysql\u002Fmysql-learning-04","MySQL 学习笔记 04：数据操纵（增删改）","MySQL 学习笔记第四篇：INSERT 插入（含批量插入与 INSERT ... SELECT）、UPDATE 更新、DELETE 删除，以及各自的坑。","2026-10-10","SQL 学习笔记",{"path":1740,"title":1741,"description":1742,"date":1737,"series":1738,"seriesOrder":1650},"\u002Fposts\u002Fmysql\u002Fmysql-learning-05","MySQL 学习笔记 05：DDL 概览","MySQL 学习笔记第五篇：数据定义语言概览——Schema、Table、View、Index、Constraints 这几类对象分别对应哪些 CREATE \u002F ALTER \u002F DROP 命令。",{"path":1744,"title":1745,"description":1746,"date":1737,"series":1738,"seriesOrder":1644},"\u002Fposts\u002Fmysql\u002Fmysql-learning-06","MySQL 学习笔记 06：CREATE TABLE 与数据类型","MySQL 学习笔记第六篇：CREATE TABLE 的完整语法、常用数据类型的选型建议，以及外键的两种定义方式。",{"path":1748,"title":1749,"description":1750,"date":1737,"series":1738,"seriesOrder":1638},"\u002Fposts\u002Fmysql\u002Fmysql-learning-07","MySQL 学习笔记 07：索引","MySQL 学习笔记第七篇：索引的作用与 B+ 树结构、单列与复合索引的创建、索引的代价与适用场景。",{"path":1752,"title":1753,"description":1754,"date":1737,"series":1738,"seriesOrder":1632},"\u002Fposts\u002Fmysql\u002Fmysql-learning-08","MySQL 学习笔记 08：DROP 与 ALTER","MySQL 学习笔记第八篇：DROP 删除数据库对象、ALTER 修改表结构，以及常见的坑。",{"path":1756,"title":1757,"description":1758,"date":1737,"series":1738,"seriesOrder":1626},"\u002Fposts\u002Fmysql\u002Fmysql-learning-09","MySQL 学习笔记 09：约束与数据完整性","MySQL 学习笔记第九篇：SQL 约束——NOT NULL、CHECK、PRIMARY KEY、FOREIGN KEY 等如何保证数据完整性，以及它们的对比。",{"path":1760,"title":1761,"description":1762,"date":1737,"series":1738,"seriesOrder":1620},"\u002Fposts\u002Fmysql\u002Fmysql-learning-10","MySQL 学习笔记 10：视图","MySQL 学习笔记第十篇：视图（Views）的定义与特性、和表的对比、创建与使用，以及可更新视图的限制。",{"path":1764,"title":1765,"description":1766,"date":1737,"series":1738,"seriesOrder":1614},"\u002Fposts\u002Fmysql\u002Fmysql-learning-11","MySQL 学习笔记 11：存储过程","MySQL 学习笔记第十一篇：存储过程（Stored Procedures）的概念、创建与调用、带参数的写法，以及优缺点。",{"path":1768,"title":1769,"description":1770,"date":1771,"series":1738,"seriesOrder":1672},"\u002Fposts\u002Fmysql\u002Fmysql-learning-01","MySQL 学习笔记 01：MySQL 基础知识","MySQL 学习笔记第一篇：MySQL Server 与 Workbench 的安装，数据库与 DBMS 的基本概念，关系模型、ACID 事务、常见数据类型，以及后续的学习路线。","2026-10-09",{"path":1773,"title":1774,"description":1775,"date":1771,"series":1738,"seriesOrder":1451},"\u002Fposts\u002Fmysql\u002Fmysql-learning-02","MySQL 学习笔记 02：SELECT 查询与过滤","MySQL 学习笔记第二篇：SELECT 的基本语法与逻辑执行顺序，WHERE 过滤（比较、LIKE、IN、BETWEEN、NULL）、各种 JOIN、UNION 与子查询。",{"path":1777,"title":1778,"description":1779,"date":1771,"series":1738,"seriesOrder":1448},"\u002Fposts\u002Fmysql\u002Fmysql-learning-03","MySQL 学习笔记 03：聚合、分组与输出控制","MySQL 学习笔记第三篇：COUNT\u002FSUM\u002FAVG 等聚合函数、GROUP BY 分组、HAVING 过滤、ORDER BY 与 LIMIT，以及一条 SELECT 的完整逻辑执行顺序。",{"path":1781,"title":1782,"description":1783,"date":1784,"series":1728,"seriesOrder":1451},"\u002Fposts\u002Fjava\u002Fjava-oop-notes","Java 面向对象笔记：类、继承、多态与异常","学习 Java 面向对象编程时的个人笔记：类与对象、封装与访问修饰符、继承与多态、集合、抽象类与接口、异常处理。示例代码均为自写，运行结果来自本地实测。","2026-10-06",{"path":1786,"title":1787,"description":1788,"date":1789,"series":1728,"seriesOrder":1672},"\u002Fposts\u002Fjava\u002Fjava-basics-notes","Java 基础语法笔记：从环境安装到方法与数组","学习 Java 基础语法时的个人笔记：JDK 安装、输入输出、变量与运算符、条件与循环、字符串、数组与方法。示例代码均为自写，运行结果来自本地实测。","2026-10-05",{"path":1791,"title":1792,"description":1793,"date":1794,"series":1795,"seriesOrder":1672},"\u002Fposts\u002Fgit\u002Fgit-install-and-basics","Git 安装与基本使用","从装好 Git 到跑通日常提交流程，把最常用的几条命令和它们背后的三个区域讲清楚。","2026-10-04","Git 入门",{"path":1797,"title":1798,"description":1799,"date":1794,"series":1795,"seriesOrder":1451},"\u002Fposts\u002Fgit\u002Flocal-remote-repository","本地远程仓库的部署","用自己的机器当 Git 服务器：建一个裸仓库、走 SSH 连上去，把本地提交推上去。",{"path":1801,"title":1802,"description":1803,"date":1794,"series":1804,"seriesOrder":1672},"\u002Fposts\u002Fguide\u002Fguide-file-layout","文件都放在哪","文章、图片、封面分别放在仓库的什么位置，哪些目录可以放手改、哪些碰了会出问题。","博客使用指南",{"path":1806,"title":1807,"description":1808,"date":1794,"series":1804,"seriesOrder":1451},"\u002Fposts\u002Fguide\u002Fguide-frontmatter","frontmatter 每个字段是什么意思","文章开头那段被横线包住的字段，逐个说明作用、默认行为和写错的后果。",{"path":1810,"title":1811,"description":1812,"date":1794,"series":1804,"seriesOrder":1448},"\u002Fposts\u002Fguide\u002Fguide-markdown","正文怎么写 —— Markdown 与排版效果","标题、链接、图片、代码、表格分别怎么写，以及本站对它们做了哪些自定义处理。",1793268185147]