[{"data":1,"prerenderedAt":1307},["ShallowReactive",2],{"post:\u002Fposts\u002Fswdesign\u002Fsw-design-notes-07":3,"posts:ordered":1005},{"id":4,"title":5,"body":6,"category":987,"cover":988,"date":989,"description":990,"extension":991,"featured":992,"meta":993,"navigation":994,"path":995,"seo":996,"series":997,"seriesOrder":998,"stem":999,"tags":1000,"__hash__":1004},"posts\u002Fposts\u002FswDesign\u002Fsw-design-notes-07.md","软件分析与设计笔记 07：用户故事：把需求写成可验收的一句话",{"type":7,"value":8,"toc":957},"minimark",[9,16,25,30,33,38,41,48,53,57,64,69,72,83,86,142,146,153,156,195,202,206,209,213,219,276,280,286,291,294,298,305,308,312,315,409,416,420,424,427,430,446,452,455,459,462,483,490,494,497,513,520,523,526,531,537,540,544,605,612,615,619,626,629,634,648,659,662,673,679,683,687,690,696,703,706,710,713,720,723,746,749,805,808],[10,11,12],"blockquote",{},[13,14,15],"p",{},"这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，示例与图示都是自己编、自己画的。理解有偏差的地方欢迎指出。",[10,17,18],{},[13,19,20,24],{},[21,22,23],"strong",{},"贯穿案例","：片区家电维修派单系统。04 预习、05 划范围、06 校验数据，这一篇把结论写成一条条可验收的用户故事 —— 它们是 08 篇用例图的原料。",[26,27,29],"h2",{"id":28},"_0-一条写了等于没写的需求","0 一条写了等于没写的需求",[13,31,32],{},"需求清单里经常出现这样的条目：",[10,34,35],{},[13,36,37],{},"「系统应该提供一个功能强大的管理后台，方便管理员管理各类数据。」",[13,39,40],{},"这句话不算错，但它没法用来做事。谁在管理？管理哪些数据？「强大」到什么程度算够？做完之后，怎么判断它达到了要求？",[13,42,43,44,47],{},"放到贯穿案例里，这类话通常是：「",[21,45,46],{},"要让派单更高效","。」 —— 更高效是几分？从几天到几小时？谁来算？",[13,49,50],{},[21,51,52],{},"用户故事（user story）就是给这类模糊需求套一个可验收的壳。",[26,54,56],{"id":55},"_1-三段结构","1 三段结构",[13,58,59],{},[60,61],"img",{"alt":62,"src":63},"用户故事的句式拆解与好坏对照：句式为 As a 角色、I want 目标、so that 价值；左侧是好的写法并附验收标准，右侧是需要改的写法并列出问题","\u002Fimages\u002Fsw-design-notes-07-user-story-anatomy.svg",[65,66,68],"h3",{"id":67},"_11-三段各自的作用","1.1 三段各自的作用",[13,70,71],{},"用户故事的标准句式是三段：",[73,74,79],"pre",{"className":75,"code":77,"language":78},[76],"language-text","As a 〈角色〉, I want 〈目标〉, so that 〈价值〉\n","text",[80,81,77],"code",{"__ignoreMap":82},"",[13,84,85],{},"三段各自的作用不一样：",[87,88,89,105],"table",{},[90,91,92],"thead",{},[93,94,95,99,102],"tr",{},[96,97,98],"th",{},"段落",[96,100,101],{},"回答的问题",[96,103,104],{},"写不好会怎样",[106,107,108,120,131],"tbody",{},[93,109,110,114,117],{},[111,112,113],"td",{},"角色",[111,115,116],{},"谁在操作",[111,118,119],{},"无法取样验证，也没法判断优先级",[93,121,122,125,128],{},[111,123,124],{},"目标",[111,126,127],{},"他要达成什么",[111,129,130],{},"不可验收，做完也不知道算不算完成",[93,132,133,136,139],{},[111,134,135],{},"价值",[111,137,138],{},"为什么想要",[111,140,141],{},"无法判断这条故事值不值得做",[65,143,145],{"id":144},"_12-第三段最容易被省掉","1.2 第三段最容易被省掉",[13,147,148,149,152],{},"第三段最容易被当成客套话省掉，但它其实是",[21,150,151],{},"唯一能用来做优先级排序的信息","。两条工作量相近的故事，价值说得清的那条明显更该先做。",[13,154,155],{},"拿本例对比一下：",[87,157,158,171],{},[90,159,160],{},[93,161,162,165,168],{},[96,163,164],{},"写法",[96,166,167],{},"价值段",[96,169,170],{},"能不能排序",[106,172,173,184],{},[93,174,175,178,181],{},[111,176,177],{},"A",[111,179,180],{},"「……这样系统功能更完整」",[111,182,183],{},"❌ 排不了",[93,185,186,189,192],{},[111,187,188],{},"B",[111,190,191],{},"「……这样我不用再逐个打电话，每天能省下两小时」",[111,193,194],{},"✅ 能，而且给出了度量口径",[13,196,197,198,201],{},"B 的写法还有个额外好处：它顺手把",[21,199,200],{},"验收指标","也给了 —— 上线后去看客服每天打电话的时长有没有真的降下来。",[26,203,205],{"id":204},"_2-从哪里提取故事","2 从哪里提取故事",[13,207,208],{},"用户故事不是凭空想出来的，它有两个主要来源。",[65,210,212],{"id":211},"_21-来源一用户画像","2.1 来源一：用户画像",[13,214,215,218],{},[21,216,217],{},"来源一：用户画像（persona）。"," 笔记 05 里那份画像的每一栏都能推出一批故事：",[87,220,221,231],{},[90,222,223],{},[93,224,225,228],{},[96,226,227],{},"画像的栏",[96,229,230],{},"推出的故事",[106,232,233,243,254,265],{},[93,234,235,240],{},[111,236,237,239],{},[21,238,124],{},"（一天结束不留下未派的单）",[111,241,242],{},"作为客服，我想看到所有待派单的清单，这样我不会漏单",[93,244,245,251],{},[111,246,247,250],{},[21,248,249],{},"行为","（翻便签本逐个打电话）",[111,252,253],{},"作为客服，我想一次看到所有工程师的当日空闲时段，这样我不用挨个问",[93,255,256,262],{},[111,257,258,261],{},[21,259,260],{},"痛点","（不知道谁有空）",[111,263,264],{},"作为客服，我想按「技能 + 时段」筛选工程师，这样我能快速匹配",[93,266,267,273],{},[111,268,269,272],{},[21,270,271],{},"限制","（不能排太满）",[111,274,275],{},"作为客服，我想在排单时看到某人当天已有几单，这样我不会压垮一个人",[65,277,279],{"id":278},"_22-来源二数据地图","2.2 来源二：数据地图",[13,281,282,285],{},[21,283,284],{},"来源二：数据地图（application map）。"," 笔记 06 里那些「需要新增采集的数据」，每一条都对应一个故事：",[10,287,288],{},[13,289,290],{},"作为片区经理，我想看到每个片区的缺料率，这样我知道该先改善哪个片区的备货。",[13,292,293],{},"这条故事的来源很明确 —— 06 篇应用地图里那一行「缺料率从 11% 降到 3%」。没有那一行，这条故事根本不会被想到。",[65,295,297],{"id":296},"_23-一条判断标准","2.3 一条判断标准",[13,299,300,301,304],{},"判断标准很简单：",[21,302,303],{},"每一条故事，都应该能指回画像的某一栏或数据地图的某一行","。指不回去的，多半是「我自己想做的功能」。",[13,306,307],{},"这条标准在考场上也管用。当你不确定某个用例该不该画进用例图时，回问一句「它对应谁的哪个痛点」—— 答不上来就删掉。",[65,309,311],{"id":310},"_24-本例的一组故事10-条","2.4 本例的一组故事（10 条）",[13,313,314],{},"把上面两个来源合起来，就是本例第一版的故事清单：",[87,316,317,327],{},[90,318,319],{},[93,320,321,324],{},[96,322,323],{},"#",[96,325,326],{},"故事",[106,328,329,337,345,353,361,369,377,385,393,401],{},[93,330,331,334],{},[111,332,333],{},"1",[111,335,336],{},"作为客户，我想在线上提交报修并看到预计上门时段，这样我不用请假干等",[93,338,339,342],{},[111,340,341],{},"2",[111,343,344],{},"作为客户，我想看到工程师已出发 \u002F 已到达，这样我知道还要等多久",[93,346,347,350],{},[111,348,349],{},"3",[111,351,352],{},"作为客服，我想一次看到所有工程师当日空闲时段，这样我不用逐个打电话",[93,354,355,358],{},[111,356,357],{},"4",[111,359,360],{},"作为客服，我想按技能与片区筛选工程师，这样我能找到能修这个型号的人",[93,362,363,366],{},[111,364,365],{},"5",[111,367,368],{},"作为客服，我想一键把工单派给某人并自动通知他，这样我不用再打电话",[93,370,371,374],{},[111,372,373],{},"6",[111,375,376],{},"作为工程师，我想在手机上看到今天的派单与地址，这样我不用回办公室拿单",[93,378,379,382],{},[111,380,381],{},"7",[111,383,384],{},"作为工程师，我想在出发前看到该型号常见的故障与所需配件，这样我少跑空趟",[93,386,387,390],{},[111,388,389],{},"8",[111,391,392],{},"作为工程师，我想现场申请配件并看到仓库有没有货，这样我不用白跑",[93,394,395,398],{},[111,396,397],{},"9",[111,399,400],{},"作为仓管，我想收到缺料预警并一键生成补货申请，这样我不会等工程师来了才发现没货",[93,402,403,406],{},[111,404,405],{},"10",[111,407,408],{},"作为片区经理，我想看到实时看板（完成率、缺料率、平均时长），这样我不用月底手工汇总",[13,410,411,412,415],{},"注意这 10 条正好是",[21,413,414],{},"按角色分的四组 + 一条经理的","。08 篇画用例图时，这个分组会原样保留 —— 因为每条故事的角色，基本就是一个 actor。",[26,417,419],{"id":418},"_3-一条故事多大算合适","3 一条故事多大算合适",[65,421,423],{"id":422},"_31-太大与太小","3.1 太大与太小",[13,425,426],{},"用户故事不是需求唯一的粒度。往上，多条相关的故事可以归成一个 theme（主题）；大到必须拆开的故事叫 epic（史诗）。往下，从系统角度描述的一块能力叫 feature（功能特性）—— 它和用户故事是两种视角，别混着写。",[13,428,429],{},"粒度（size）是用户故事最容易失控的地方。",[431,432,433,440],"ul",{},[434,435,436,439],"li",{},[21,437,438],{},"太大","（「作为客服，我想管理所有工单」）—— 一个迭代做不完，也没法验收；",[434,441,442,445],{},[21,443,444],{},"太小","（「作为客服，我想让按钮是蓝色的」）—— 这是实现细节，不该出现在需求里。",[13,447,448,449],{},"一个常用的判断尺度是：",[21,450,451],{},"一条故事应该能在一个迭代内完成，并且能由用户自己判断「做到了没有」。",[13,453,454],{},"上面第 5 条（一键派单并通知）是合适的粒度；第 3 条和第 4 条如果合成一条「帮我快速派单」，就太大了 —— 它其实包含「看空闲」「筛技能」「选人」三个动作。",[65,456,458],{"id":457},"_32-怎么拆三种依据","3.2 怎么拆：三种依据",[13,460,461],{},"story splitting（故事拆分）按什么切，有三种常见依据：",[463,464,465,471,477],"ol",{},[434,466,467,470],{},[21,468,469],{},"按流程步骤切"," —— 提交 \u002F 分派 \u002F 上门 \u002F 回填；",[434,472,473,476],{},[21,474,475],{},"按角色切"," —— 同一个功能，客户看到的和客服看到的拆开；",[434,478,479,482],{},[21,480,481],{},"按数据范围切"," —— 先支持空调，再支持冰箱洗衣机。",[13,484,485,486,489],{},"本例里第 7 条（出发前看故障与配件）很适合按",[21,487,488],{},"数据范围","拆：第一版只显示「该型号近 90 天最常见的三个故障」，第二版再做「所需配件库存查询」。",[26,491,493],{"id":492},"_4-时序也是需求的一部分","4 时序也是需求的一部分",[13,495,496],{},"这一条经常被漏掉。看这两条故事：",[431,498,499,502],{},[434,500,501],{},"「作为工程师，我想收到派单提醒。」",[434,503,504,505,508,509,512],{},"「作为工程师，我想在",[21,506,507],{},"派单后 1 分钟内","、且",[21,510,511],{},"距上门时间还有 2 小时以上","时收到提醒。」",[13,514,515,516,519],{},"第二条多了两个",[21,517,518],{},"触发条件","：时延和提前量。而正是这两个条件决定了整个实现的复杂度 —— 要不要实时推送？半夜派单要不要叫醒人？",[13,521,522],{},"所以「什么时候提醒」这个问题问的就是这件事。",[13,524,525],{},"还有一条更隐蔽的时序：",[431,527,528],{},[434,529,530],{},"「作为客户，我想看到工程师位置。」 —— 多久刷新一次？实时（每秒）还是每 5 分钟？",[13,532,533,536],{},[21,534,535],{},"实时和每 5 分钟的差别，可能是几万块的服务器成本","。如果不写进故事，开发要么按最省的做法（客户抱怨不实时），要么按最贵的做法（成本超预算）。两种都是失败。",[13,538,539],{},"所以写故事时，凡是带时间、频次、条件的，都要写进「目标」那一段，而不是留给开发自己猜。",[26,541,543],{"id":542},"_5-什么样的故事是坏的","5 什么样的故事是坏的",[87,545,546,559],{},[90,547,548],{},[93,549,550,553,556],{},[96,551,552],{},"坏法",[96,554,555],{},"例子",[96,557,558],{},"问题",[106,560,561,572,583,594],{},[93,562,563,566,569],{},[111,564,565],{},"角色是泛称",[111,567,568],{},"「作为用户…」",[111,570,571],{},"无法确定取样对象，需求可能谁都不满足",[93,573,574,577,580],{},[111,575,576],{},"目标不可验收",[111,578,579],{},"「…想要更好的体验」",[111,581,582],{},"无法写验收标准",[93,584,585,588,591],{},[111,586,587],{},"价值为空",[111,589,590],{},"「…这样系统更完善」",[111,592,593],{},"无法判断优先级",[93,595,596,599,602],{},[111,597,598],{},"混进实现细节",[111,600,601],{},"「…想要一个下拉框来选工程师」",[111,603,604],{},"把方案写成了需求，堵死了更好的做法",[13,606,607,608,611],{},"最后一条尤其值得警惕：它看起来最具体、最像需求，但它其实是你",[21,609,610],{},"提前替用户做了决定","。",[13,613,614],{},"本例里有个典型：如果有人把第 4 条写成「作为客服，我想有一个下拉框按技能筛选」，那就排除了「在地图上点选工程师」这类可能更好的做法 —— 而后者恰恰可能是客服真正想要的。",[26,616,618],{"id":617},"_6-验收标准","6 验收标准",[13,620,621,622,625],{},"一条故事只有配上",[21,623,624],{},"验收标准（acceptance criteria）","，才真正可验收。验收标准写的是「怎么算做到了」，通常 2–5 条。",[13,627,628],{},"拿本例第 3 条（看到所有工程师空闲时段）写一遍：",[10,630,631],{},[13,632,633],{},"作为客服，我想一次看到所有工程师当日空闲时段，这样我不用逐个打电话。",[431,635,636,639,642,645],{},[434,637,638],{},"一屏内显示所有在职工程师的当日时段，无需滚动超过一屏；",[434,640,641],{},"每个时段标注「空闲 \u002F 已排 \u002F 满档」三态；",[434,643,644],{},"数据延迟不超过 1 分钟；",[434,646,647],{},"无排班数据的工程师单独列出，不隐藏。",[13,649,650,651,654,655,658],{},"写验收标准有个副作用：",[21,652,653],{},"它会逼你发现故事里的漏洞","。比如第四条，就是因为写到「没有排班数据怎么办」才发现原来还有这种情况。这类非正常路径通常叫",[21,656,657],{},"负面场景（negative scenario）","；取值极端的情况则叫边界情况（edge case）。它们往往比主流程更值得写清楚。",[13,660,661],{},"本例里还有几个值得写进验收标准的负面场景：",[431,663,664,667,670],{},[434,665,666],{},"同一个工单被两个客服同时派给不同的人 —— 怎么处理？",[434,668,669],{},"工程师临时请假，已派的单怎么回退？",[434,671,672],{},"客户改约到工程师已满档的时段 —— 允许还是拒绝？",[13,674,675,676,611],{},"这三条不写清，开发上线后一定出问题。而它们",[21,677,678],{},"全都不是主流程",[26,680,682],{"id":681},"_7-lean-ux-与设计思维在这里的位置","7 Lean UX 与设计思维在这里的位置",[65,684,686],{"id":685},"_71-一场做量学的循环","7.1 一场「做—量—学」的循环",[13,688,689],{},"前面几篇的方法（设计思维、数据知情、用户画像、故事）在整体上是一套循环：",[13,691,692,695],{},[21,693,694],{},"Build → Measure → Learn（build-measure-learn，做出来 → 量一量 → 学到东西）","，这也是 Lean UX 的基本节奏。而被拿去测量的那个最小版本，就叫 MVP（最小可行产品）。用户故事是这套循环里最小的工作单元：它既是开发要做的条目，也是下一轮里要被验证的假设。",[13,697,698,699,702],{},"放到本例，MVP 的定义很具体：",[21,700,701],{},"只做第 3、5、8 三条","（看空闲、一键派单、申请配件）。这三条合起来就能验证核心假设 ——「把排期可见之后，客服的电话会减少」。其他七条都等这一轮验证完再说。",[13,704,705],{},"反过来看，如果没有这条循环，用户故事就退化成一张任务清单 —— 做完就打勾，没人回头看它有没有解决问题。",[65,707,709],{"id":708},"_72-一条合格故事的自查清单","7.2 一条合格故事的自查清单",[13,711,712],{},"顺带记一个自查清单：一条合格的故事通常满足 INVEST —— 独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimable）、小（Small）、可测试（Testable）。",[13,714,715,716,719],{},"用上面那张 10 条的表过一遍，最容易不达标的是",[21,717,718],{},"独立","：第 8 条（现场申请配件）依赖第 9 条（仓管看到缺料）。这种依赖不可怕，但要显式写出来，否则排期时会发现「做完 8 却用不了」。",[26,721,722],{"id":722},"本节自测",[463,724,725,728,731,734,737,740,743],{},[434,726,727],{},"用户故事的三段里，哪一段决定了优先级排序？为什么？",[434,729,730],{},"「作为用户，我想要一个下拉框」这条故事有哪两个问题？",[434,732,733],{},"把「作为工程师，我想收到派单提醒」补全成一条可验收的故事，需要加上什么？",[434,735,736],{},"验收标准通常写几条？它的副作用是什么？",[434,738,739],{},"用户故事在整个「做出来—量一量—学到东西」的循环里扮演什么角色？本例的 MVP 是哪几条？",[434,741,742],{},"本例中「客户想看到工程师位置」这条故事，为什么必须写明刷新频率？",[434,744,745],{},"举出本例中三个值得写进验收标准的负面场景。",[65,747,748],{"id":748},"参考答案",[463,750,751,757,767,774,785,792,799],{},[434,752,753,756],{},[21,754,755],{},"第三段（价值 so that）","。因为它是唯一能用来做优先级排序的信息 —— 两条工作量相近的故事，价值说得清的那条更该先做；它同时给出了验收指标（§1.2）。",[434,758,759,760,762,763,766],{},"①",[21,761,565],{},"「用户」，无法确定取样对象；②",[21,764,765],{},"混进了实现细节","「下拉框」，把方案写成需求，堵死了「地图点选」这类可能更好的做法（§5）。",[434,768,769,770,773],{},"要加上",[21,771,772],{},"时序条件","：例如「在派单后 1 分钟内、且距上门时间还有 2 小时以上时收到提醒」。这两个条件决定了实现复杂度（要不要实时推送、半夜要不要叫醒人）（§4）。",[434,775,776,777,780,781,784],{},"通常 ",[21,778,779],{},"2–5 条","。副作用是",[21,782,783],{},"会逼你发现故事里的漏洞"," —— 写到「数据不够时怎么办」这类情况，才发现原来还有负面场景没考虑（§6）。",[434,786,787,788,791],{},"用户故事是这套循环里",[21,789,790],{},"最小的工作单元","，既是开发条目，也是下一轮要验证的假设。本例 MVP 是第 3、5、8 三条（看空闲、一键派单、申请配件），用来验证「排期可见后客服电话会减少」（§7.1）。",[434,793,794,795,798],{},"因为",[21,796,797],{},"实时和每 5 分钟的差别可能是几万块的服务器成本","。不写清，开发要么按最省的做法（客户抱怨不实时），要么按最贵的做法（超预算），两种都是失败（§4）。",[434,800,801,802,804],{},"①同一工单被两个客服同时派给不同的人；②工程师临时请假，已派的单怎么回退；③客户改约到工程师已满档的时段。三条",[21,803,678],{},"（§6）。",[26,806,807],{"id":807},"术语表",[87,809,810,823],{},[90,811,812],{},[93,813,814,817,820],{},[96,815,816],{},"术语",[96,818,819],{},"中文",[96,821,822],{},"一句话解释",[106,824,825,836,847,858,869,880,891,902,913,924,935,946],{},[93,826,827,830,833],{},[111,828,829],{},"user story",[111,831,832],{},"用户故事",[111,834,835],{},"用「角色 \u002F 目标 \u002F 价值」三段描述一条需求",[93,837,838,841,844],{},[111,839,840],{},"epic",[111,842,843],{},"史诗",[111,845,846],{},"太大、需要拆分成多条用户故事的需求",[93,848,849,852,855],{},[111,850,851],{},"theme",[111,853,854],{},"主题",[111,856,857],{},"一组相关用户故事的集合，用于组织 backlog",[93,859,860,863,866],{},[111,861,862],{},"acceptance criteria",[111,864,865],{},"验收标准",[111,867,868],{},"判断一条故事「算不算做到」的检验条件",[93,870,871,874,877],{},[111,872,873],{},"feature",[111,875,876],{},"功能特性",[111,878,879],{},"从系统角度描述的一块能力",[93,881,882,885,888],{},[111,883,884],{},"story splitting",[111,886,887],{},"故事拆分",[111,889,890],{},"把过大的故事按流程、角色或数据范围切开",[93,892,893,896,899],{},[111,894,895],{},"negative scenario",[111,897,898],{},"负面场景",[111,900,901],{},"非正常路径下的情况，如失败、异常、数据缺失",[93,903,904,907,910],{},[111,905,906],{},"edge case",[111,908,909],{},"边界情况",[111,911,912],{},"极端取值下的情况，常在验收标准里补上",[93,914,915,918,921],{},[111,916,917],{},"Lean UX",[111,919,920],{},"精益用户体验",[111,922,923],{},"以「做—量—学」循环推进设计的做法",[93,925,926,929,932],{},[111,927,928],{},"build-measure-learn",[111,930,931],{},"做—量—学",[111,933,934],{},"先做出最小版本、再测量、再调整的循环",[93,936,937,940,943],{},[111,938,939],{},"MVP",[111,941,942],{},"最小可行产品",[111,944,945],{},"能验证核心假设的最小版本",[93,947,948,951,954],{},[111,949,950],{},"INVEST",[111,952,953],{},"INVEST 原则",[111,955,956],{},"判断故事质量的六条标准：独立、可协商、有价值、可估算、小、可测试",{"title":82,"searchDepth":958,"depth":958,"links":959},3,[960,962,966,972,976,977,978,979,983,986],{"id":28,"depth":961,"text":29},2,{"id":55,"depth":961,"text":56,"children":963},[964,965],{"id":67,"depth":958,"text":68},{"id":144,"depth":958,"text":145},{"id":204,"depth":961,"text":205,"children":967},[968,969,970,971],{"id":211,"depth":958,"text":212},{"id":278,"depth":958,"text":279},{"id":296,"depth":958,"text":297},{"id":310,"depth":958,"text":311},{"id":418,"depth":961,"text":419,"children":973},[974,975],{"id":422,"depth":958,"text":423},{"id":457,"depth":958,"text":458},{"id":492,"depth":961,"text":493},{"id":542,"depth":961,"text":543},{"id":617,"depth":961,"text":618},{"id":681,"depth":961,"text":682,"children":980},[981,982],{"id":685,"depth":958,"text":686},{"id":708,"depth":958,"text":709},{"id":722,"depth":961,"text":722,"children":984},[985],{"id":748,"depth":958,"text":748},{"id":807,"depth":961,"text":807},"学习",null,"2026-10-29","用户故事的三段结构，怎么从用户画像和数据地图里把它提取出来，一条故事多大算合适、时序为什么也是需求的一部分，以及验收标准怎么写才算真的可验收。","md",false,{},true,"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-07",{"title":5,"description":990},"软件分析与设计笔记",7,"posts\u002FswDesign\u002Fsw-design-notes-07",[1001,832,1002,1003],"需求分析","敏捷开发","学习笔记","-_RSFWNnWFWS6nC9UADGrI-X5jOfjNe0kyUENB29qE4",[1006,1012,1018,1024,1030,1036,1042,1048,1054,1060,1066,1072,1078,1084,1090,1096,1102,1108,1114,1120,1126,1132,1133,1139,1145,1151,1156,1161,1167,1173,1177,1181,1185,1189,1193,1197,1201,1205,1209,1213,1217,1223,1227,1233,1237,1241,1245,1249,1253,1257,1261,1266,1270,1274,1279,1284,1290,1294,1299,1303],{"path":1007,"title":1008,"description":1009,"date":1010,"series":997,"seriesOrder":1011},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-28","软件分析与设计笔记 28：draw.io 作图手册：五张图的符号位置、落笔顺序与自检","不模拟软件界面，只讲清三件事：每个 UML 符号在 draw.io 里搜什么词、一张图该按什么顺序落笔、画完拿什么标准自查。覆盖用例图、活动图、顺序图、类图、界面草图五种图纸，末尾附「最容易画反的十二笔」总检表。","2026-11-19",28,{"path":1013,"title":1014,"description":1015,"date":1016,"series":997,"seriesOrder":1017},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-27","软件分析与设计笔记 27：Paper 1 应试：从读案例到交卷的一次完整演算","拿一份完整的案例，从头到尾走一遍：怎么读案例列角色、怎么在四个小问之间分配时间、每一张图从哪一句话推出来、两张表怎么填、交卷前拿什么清单自查。附 C25 真题与样卷的题型分值对照。","2026-11-18",27,{"path":1019,"title":1020,"description":1021,"date":1022,"series":997,"seriesOrder":1023},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-26","软件分析与设计笔记 26：总结：把整条链路串起来","系列收尾：从需求到代码的完整链路回顾、每一环的产出与验收方式、六条贯穿全系列的原则，以及一份可以直接拿去做项目自查的清单。","2026-11-17",26,{"path":1025,"title":1026,"description":1027,"date":1028,"series":997,"seriesOrder":1029},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-25","软件分析与设计笔记 25：代码重构：坏味道与手法","重构不改变外部行为、只改善内部结构：四种常见坏味道与对应手法、为什么动手之前必须先有测试、什么时候该重构，以及重构和前面那些设计模型是什么关系。","2026-11-16",25,{"path":1031,"title":1032,"description":1033,"date":1034,"series":997,"seriesOrder":1035},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-24","软件分析与设计笔记 24：设计原则：内聚、耦合与多态","好设计怎么衡量：内聚与耦合分别在说什么、一次从「差设计」到「多态重设计」的完整对照、抽象类与接口的选择依据，以及复用为什么会从优势变成风险。","2026-11-15",24,{"path":1037,"title":1038,"description":1039,"date":1040,"series":997,"seriesOrder":1041},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-23","软件分析与设计笔记 23：设计建模：从对象模型到能实现的方案","分析模型能用但还不能直接开工：对象模型怎么映射到关系模型、继承映射的三种方案怎么选、数据访问层与 Data Broker 解决什么问题，以及三层架构与 MVC 的分工。","2026-11-14",23,{"path":1043,"title":1044,"description":1045,"date":1046,"series":997,"seriesOrder":1047},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-22","软件分析与设计笔记 22：分析建模：边界、实体与控制对象","不经过分析直接写代码会踩什么坑、三种分析对象各管一段、怎么用顺序图完成一次用例实现，以及从顺序图导出类的属性、操作与关系的方法。","2026-11-13",22,{"path":1049,"title":1050,"description":1051,"date":1052,"series":997,"seriesOrder":1053},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-21","软件分析与设计笔记 21：UML：类图与顺序图","为什么需要一种共同的画法：类符号三格怎么画、五种关系的符号与设计含义、每种关系落到 Java 是什么写法，顺序图的三要素怎么摆；以及这三种最容易找不到的符号在 draw.io 里各搜什么词。","2026-11-12",21,{"path":1055,"title":1056,"description":1057,"date":1058,"series":997,"seriesOrder":1059},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-20","软件分析与设计笔记 20：面向对象概念：对象、关系与多态","面向对象不是「用某个语言写代码」：对象与类的区别、封装真正在保护什么、五种关系（依赖、关联、聚合、组合、继承）各自何时用，以及多态为什么能减少条件判断。","2026-11-11",20,{"path":1061,"title":1062,"description":1063,"date":1064,"series":997,"seriesOrder":1065},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-19","软件分析与设计笔记 19：规范化与逻辑数据模型","一次改地址引发的数据不一致，讲清规范化的真正动机；UNF 到 3NF 每一步在解决什么问题，派生字段为什么不能存，优化为什么和规范化方向相反，以及逻辑数据模型在 3NF 之上补了什么。","2026-11-10",19,{"path":1067,"title":1068,"description":1069,"date":1070,"series":997,"seriesOrder":1071},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-18","软件分析与设计笔记 18：数据库分析：实体、关系与数据字典","为什么不能拿到需求就动手建表：实体与关系怎么判定、基数为什么必须由业务方确认、数据命名要遵守什么规则，以及数据字典四列里最容易被空着的那一列。","2026-11-09",18,{"path":1073,"title":1074,"description":1075,"date":1076,"series":997,"seriesOrder":1077},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-17","软件分析与设计笔记 17：用生成式 AI 做设计与开发：能用的场景与要防的坑","生成式 AI 在工作流里真正站得住的三个场景 —— 造示例数据、解释陌生代码、起草初稿；它为什么会复现社会偏见、为什么会编得像真的，以及哪些内容绝不能直接采用。","2026-11-08",17,{"path":1079,"title":1080,"description":1081,"date":1082,"series":997,"seriesOrder":1083},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-16","软件分析与设计笔记 16：从 persona 到 URS：一份交付物的完整骨架","把前面十几篇串成一份能交出去的东西：用户需求规格说明书的九个部分、每一章来自哪个环节、由谁确认，以及面向决策者的提案该讲清哪三件事。","2026-11-07",16,{"path":1085,"title":1086,"description":1087,"date":1088,"series":997,"seriesOrder":1089},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-15","软件分析与设计笔记 15：非功能需求：把「快、稳、安全」变成数字","为什么「系统要快」不是一条需求：非功能需求怎么量化，决定性能的用户量、交易量、数据量三张表怎么估，安全需求要写清什么，以及可靠性的「不可用」该怎么定义。","2026-11-06",15,{"path":1091,"title":1092,"description":1093,"date":1094,"series":997,"seriesOrder":1095},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-14","软件分析与设计笔记 14：软件测试：层级、方法与等价类划分","「我们测过了」这句话问题在哪：为什么静态评审和动态测试缺一不可，五个测试层级各自验证什么，白盒与黑盒的差别，以及用等价类划分和边界值把无限输入变成有限用例的方法。","2026-11-05",14,{"path":1097,"title":1098,"description":1099,"date":1100,"series":997,"seriesOrder":1101},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-13","软件分析与设计笔记 13：需求获取：五种调查方法与一场访谈","需求从哪里来：五种事实调查方法各自适合回答什么、代价是什么，访谈从准备到记录的全过程，问卷设计里最容易犯的错，以及访谈记录必须写下来的那几项信息。","2026-11-04",13,{"path":1103,"title":1104,"description":1105,"date":1106,"series":997,"seriesOrder":1107},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-12","软件分析与设计笔记 12：前端设计：把流程变成屏幕","界面设计不是「画得好看」：从活动图走到屏幕的三步，CRUD 任务流怎么当检查表，界面必须回答的三个问题，信息架构与五种导航类型，视觉一致性与留白，以及移动端与 Web 端的差别。","2026-11-03",12,{"path":1109,"title":1110,"description":1111,"date":1112,"series":997,"seriesOrder":1113},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-11","软件分析与设计笔记 11：Agentic AI 与业务流程自动化","AI agent 到底是什么：五项能力与四个核心组件，什么场景该用定时任务、什么该用程序、什么才值得用 agent，两种实现路径的差别，必须提前防住的四类失败模式，以及设计方法从提示词到编排的演进。","2026-11-02",11,{"path":1115,"title":1116,"description":1117,"date":1118,"series":997,"seriesOrder":1119},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-10","软件分析与设计笔记 10：精炼用例模型：include、extend 与泛化","三种精炼用例关系的判断标准：include 什么时候用、它和 extend 的区别到底在哪、参与者泛化与用例泛化各解决什么问题，以及精炼到什么程度就该停手。","2026-11-01",10,{"path":1121,"title":1122,"description":1123,"date":1124,"series":997,"seriesOrder":1125},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-09","软件分析与设计笔记 09：功能需求（二）：从流程到业务实体","活动图画完之后，怎么从流程里筛出真正的业务实体：三条判断标准、哪些名词其实不该建实体、属性从哪里来，以及领域模型和后面的数据模型分别负责什么。","2026-10-31",9,{"path":1127,"title":1128,"description":1129,"date":1130,"series":997,"seriesOrder":1131},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-08","软件分析与设计笔记 08：功能需求（一）：用例模型与活动图","从用户故事到用例的翻译过程：什么才算「好」的参与者，系统边界怎么划，用例描述必须写清哪四件事，活动图怎么把分支、并行与泳道画清楚，以及这两个图在 draw.io 里各用哪个形状、最容易画错哪一笔。","2026-10-30",8,{"path":995,"title":5,"description":990,"date":989,"series":997,"seriesOrder":998},{"path":1134,"title":1135,"description":1136,"date":1137,"series":997,"seriesOrder":1138},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-06","软件分析与设计笔记 06：范围界定（数据侧）：用数据校验你的判断","访谈结论和数字对不上时该怎么办：分析的四个层次分别在回答什么问题、为什么不能跳级、数据准备与搜集怎么做成一张应用地图，以及数据最容易在哪几个地方骗你。","2026-10-28",6,{"path":1140,"title":1141,"description":1142,"date":1143,"series":997,"seriesOrder":1144},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-05","软件分析与设计笔记 05：范围界定（用户侧）：用户画像与客户旅程图","为什么「所有用户」是一个陷阱，项目边界该怎么划，用户画像要写哪五个要素、最容易写成什么废纸，客户旅程图怎么把阶段、想法和情绪画在同一张纸上，以及怎么从这两样东西一步步推到可验证的需求。","2026-10-27",5,{"path":1146,"title":1147,"description":1148,"date":1149,"series":997,"seriesOrder":1150},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-04","软件分析与设计笔记 04：接手陌生案例的第一步：三问与一张表","拿到一个完全陌生的业务案例，怎么从零开始不跑偏：只问 Who、What、Why 三个问题，把「问题—事实—假设—理由」记成一张四列表，说清为什么假设必须写明理由，以及带着问题进访谈为什么比空手去有效得多。","2026-10-26",4,{"path":1152,"title":1153,"description":1154,"date":1155,"series":997,"seriesOrder":958},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-03","软件分析与设计笔记 03：Agile 与 Scrum：迭代、角色与产出物","从「三周做完交付，客户说这不是我要的」讲起，说清瀑布式与迭代式的根本差别，Scrum 的三个角色和三种产出物，一个 sprint 里四次固定活动各自在解决什么问题，以及敏捷里最常见的几个误解。","2026-10-25",{"path":1157,"title":1158,"description":1159,"date":1160,"series":997,"seriesOrder":961},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-02","软件分析与设计笔记 02：设计思维、用户驱动与数据驱动","从「客服要一个能一次看完所有排期的界面」这个翻车案例讲起，说清设计思维到底是什么、用户驱动与数据驱动各自能看见什么又看不见什么、为什么真正的落点是把两者合起来的 data-informed design，以及访谈中怎么问出有用的信息。","2026-10-24",{"path":1162,"title":1163,"description":1164,"date":1165,"series":997,"seriesOrder":1166},"\u002Fposts\u002Fswdesign\u002Fsw-design-notes-01","软件分析与设计笔记 01：课程地图与从需求到设计的主干","这一篇不写具体方法，先把整条链路铺开：软件分析与设计到底要解决什么问题，从需求到设计分成哪两段，中间有哪十几个环节，一份完整的交付物里应该有什么，以及后面 27 篇笔记怎么排、新人该按什么顺序读。","2026-10-23",1,{"path":1168,"title":1169,"description":1170,"date":1171,"series":1172,"seriesOrder":1166},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-01","Spring 学习笔记 01：IoC、依赖注入与第一个 Spring Boot 应用","从「手写 new 出来的三层结构」的痛点讲起，说清 IoC 容器、Bean 与依赖注入是怎么回事，再用 Maven 与 Spring Initializr 跑起第一个能返回 JSON 的应用。","2026-10-15","Spring 学习笔记",{"path":1174,"title":1175,"description":1176,"date":1171,"series":1172,"seriesOrder":961},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-02","Spring 学习笔记 02：Spring Data JPA 基础——实体映射与 Repository","用 ORM 把类映射到表：@Entity、@Id、@GeneratedValue 怎么用，CrudRepository 三层接口怎么选，H2 与 MySQL 怎么配，以及 ddl-auto 到底该写哪个值。",{"path":1178,"title":1179,"description":1180,"date":1171,"series":1172,"seriesOrder":958},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-03","Spring 学习笔记 03：JPA 查询——派生方法、JPQL 与分页排序","Repository 自带的方法只够按主键查，这篇讲三种自己造查询的方式：方法名派生、@Query 写 JPQL、原生 SQL，以及 Pageable 分页排序和投影返回。",{"path":1182,"title":1183,"description":1184,"date":1171,"series":1172,"seriesOrder":1150},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-04","Spring 学习笔记 04：JPA 关联映射与仓储测试","一对多、多对多怎么映射，谁负责维护外键，FetchType 与 CascadeType 该怎么选，顺带用 @DataJpaTest 与 AssertJ 把仓储层测起来。",{"path":1186,"title":1187,"description":1188,"date":1171,"series":1172,"seriesOrder":1144},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-05","Spring 学习笔记 05：Spring MVC 与 Thymeleaf 入门","一次页面请求在 Spring MVC 里走了哪几步，@Controller 怎么把数据交给模板，@PathVariable 与 @RequestParam 怎么取参数，以及控制器为什么必须是无状态的。",{"path":1190,"title":1191,"description":1192,"date":1171,"series":1172,"seriesOrder":1138},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-06","Spring 学习笔记 06：表单绑定与服务端校验","把表单字段绑到对象上，用 Bean Validation 注解做服务端校验，把错误信息显示回用户刚填的那一页，再补上自定义校验注解与全局异常处理。",{"path":1194,"title":1195,"description":1196,"date":1171,"series":1172,"seriesOrder":998},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-07","Spring 学习笔记 07：Thymeleaf 片段复用与国际化","用 th:fragment 与 th:insert\u002Fth:replace 把导航栏、页脚抽成片段，页面套用统一布局，再用 messages.properties 与 LocaleResolver 做中英文切换。",{"path":1198,"title":1199,"description":1200,"date":1171,"series":1172,"seriesOrder":1131},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-08","Spring 学习笔记 08：HTTP Session 与会话状态管理","HTTP 无状态带来的问题，Cookie 与 Session 怎么分工，Spring 里读写会话的几种方式，以及会话固定、超时、多实例共享这些必须想清楚的事。",{"path":1202,"title":1203,"description":1204,"date":1171,"series":1172,"seriesOrder":1125},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-09","Spring 学习笔记 09：拦截器 HandlerInterceptor","登录检查、权限判断、请求耗时统计这类横切逻辑该放哪：HandlerInterceptor 的三个回调各在什么时机执行，怎么注册与排除路径，以及它和过滤器的分工。",{"path":1206,"title":1207,"description":1208,"date":1171,"series":1172,"seriesOrder":1119},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-10","Spring 学习笔记 10：Service 层与事务","一组数据库操作要么全成功要么全失败，靠 @Transactional 怎么做到；传播行为、隔离级别、回滚规则怎么选，以及自调用失效、乐观锁悲观锁这些实战里的坑。",{"path":1210,"title":1211,"description":1212,"date":1171,"series":1172,"seriesOrder":1113},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-11","Spring 学习笔记 11：REST API 基础——把 Service 暴露成接口","同一套 Service 怎么同时服务页面和客户端：@RestController 的路由与方法语义、状态码怎么给、DTO 怎么定，以及 MockMvc 端到端和切片测试的两种写法与各自的坑。",{"path":1214,"title":1215,"description":1216,"date":1171,"series":1172,"seriesOrder":1107},"\u002Fposts\u002Fjavaspring\u002Fspring-notes-12","Spring 学习笔记 12：REST 进阶——版本、更新、跨域与文档化","接口能跑通之后要处理的几件事：URL 与响应结构怎么定、版本怎么演进、更新怎么做到可安全重试、CORS 怎么配、HATEOAS 与 Spring Data REST 该不该用。",{"path":1218,"title":1219,"description":1220,"date":1221,"series":1222,"seriesOrder":1150},"\u002Fposts\u002Fjava\u002Fjava-functionalprogramming-notes","Java 函数式编程笔记：Lambda、函数式接口与 Streams","学习 Java 函数式编程时的个人笔记：Lambda 表达式的五步简写与方法引用、常见函数式接口、Stream 流水线与惰性求值，以及创建流、中间操作、终止操作与收集器的用法。示例代码均为自写，运行结果来自本地实测。","2026-10-13","Java 学习笔记",{"path":1224,"title":1225,"description":1226,"date":1221,"series":1222,"seriesOrder":958},"\u002Fposts\u002Fjava\u002Fjava-generics-notes","Java 泛型笔记：泛型方法、有界类型与泛型类","学习 Java 泛型时的个人笔记：从重复的重载方法与多态尝试讲起，再到泛型方法与类型推断、有界泛型类型、Comparable 与 Number 边界，以及泛型类在集合中的用法。示例代码均为自写，运行结果来自本地实测。",{"path":1228,"title":1229,"description":1230,"date":1231,"series":1232,"seriesOrder":1150},"\u002Fposts\u002Fmysql\u002Fmysql-learning-04","MySQL 学习笔记 04：数据操纵（增删改）","MySQL 学习笔记第四篇：INSERT 插入（含批量插入与 INSERT ... SELECT）、UPDATE 更新、DELETE 删除，以及各自的坑。","2026-10-10","SQL 学习笔记",{"path":1234,"title":1235,"description":1236,"date":1231,"series":1232,"seriesOrder":1144},"\u002Fposts\u002Fmysql\u002Fmysql-learning-05","MySQL 学习笔记 05：DDL 概览","MySQL 学习笔记第五篇：数据定义语言概览——Schema、Table、View、Index、Constraints 这几类对象分别对应哪些 CREATE \u002F ALTER \u002F DROP 命令。",{"path":1238,"title":1239,"description":1240,"date":1231,"series":1232,"seriesOrder":1138},"\u002Fposts\u002Fmysql\u002Fmysql-learning-06","MySQL 学习笔记 06：CREATE TABLE 与数据类型","MySQL 学习笔记第六篇：CREATE TABLE 的完整语法、常用数据类型的选型建议，以及外键的两种定义方式。",{"path":1242,"title":1243,"description":1244,"date":1231,"series":1232,"seriesOrder":998},"\u002Fposts\u002Fmysql\u002Fmysql-learning-07","MySQL 学习笔记 07：索引","MySQL 学习笔记第七篇：索引的作用与 B+ 树结构、单列与复合索引的创建、索引的代价与适用场景。",{"path":1246,"title":1247,"description":1248,"date":1231,"series":1232,"seriesOrder":1131},"\u002Fposts\u002Fmysql\u002Fmysql-learning-08","MySQL 学习笔记 08：DROP 与 ALTER","MySQL 学习笔记第八篇：DROP 删除数据库对象、ALTER 修改表结构，以及常见的坑。",{"path":1250,"title":1251,"description":1252,"date":1231,"series":1232,"seriesOrder":1125},"\u002Fposts\u002Fmysql\u002Fmysql-learning-09","MySQL 学习笔记 09：约束与数据完整性","MySQL 学习笔记第九篇：SQL 约束——NOT NULL、CHECK、PRIMARY KEY、FOREIGN KEY 等如何保证数据完整性，以及它们的对比。",{"path":1254,"title":1255,"description":1256,"date":1231,"series":1232,"seriesOrder":1119},"\u002Fposts\u002Fmysql\u002Fmysql-learning-10","MySQL 学习笔记 10：视图","MySQL 学习笔记第十篇：视图（Views）的定义与特性、和表的对比、创建与使用，以及可更新视图的限制。",{"path":1258,"title":1259,"description":1260,"date":1231,"series":1232,"seriesOrder":1113},"\u002Fposts\u002Fmysql\u002Fmysql-learning-11","MySQL 学习笔记 11：存储过程","MySQL 学习笔记第十一篇：存储过程（Stored Procedures）的概念、创建与调用、带参数的写法，以及优缺点。",{"path":1262,"title":1263,"description":1264,"date":1265,"series":1232,"seriesOrder":1166},"\u002Fposts\u002Fmysql\u002Fmysql-learning-01","MySQL 学习笔记 01：MySQL 基础知识","MySQL 学习笔记第一篇：MySQL Server 与 Workbench 的安装，数据库与 DBMS 的基本概念，关系模型、ACID 事务、常见数据类型，以及后续的学习路线。","2026-10-09",{"path":1267,"title":1268,"description":1269,"date":1265,"series":1232,"seriesOrder":961},"\u002Fposts\u002Fmysql\u002Fmysql-learning-02","MySQL 学习笔记 02：SELECT 查询与过滤","MySQL 学习笔记第二篇：SELECT 的基本语法与逻辑执行顺序，WHERE 过滤（比较、LIKE、IN、BETWEEN、NULL）、各种 JOIN、UNION 与子查询。",{"path":1271,"title":1272,"description":1273,"date":1265,"series":1232,"seriesOrder":958},"\u002Fposts\u002Fmysql\u002Fmysql-learning-03","MySQL 学习笔记 03：聚合、分组与输出控制","MySQL 学习笔记第三篇：COUNT\u002FSUM\u002FAVG 等聚合函数、GROUP BY 分组、HAVING 过滤、ORDER BY 与 LIMIT，以及一条 SELECT 的完整逻辑执行顺序。",{"path":1275,"title":1276,"description":1277,"date":1278,"series":1222,"seriesOrder":961},"\u002Fposts\u002Fjava\u002Fjava-oop-notes","Java 面向对象笔记：类、继承、多态与异常","学习 Java 面向对象编程时的个人笔记：类与对象、封装与访问修饰符、继承与多态、集合、抽象类与接口、异常处理。示例代码均为自写，运行结果来自本地实测。","2026-10-06",{"path":1280,"title":1281,"description":1282,"date":1283,"series":1222,"seriesOrder":1166},"\u002Fposts\u002Fjava\u002Fjava-basics-notes","Java 基础语法笔记：从环境安装到方法与数组","学习 Java 基础语法时的个人笔记：JDK 安装、输入输出、变量与运算符、条件与循环、字符串、数组与方法。示例代码均为自写，运行结果来自本地实测。","2026-10-05",{"path":1285,"title":1286,"description":1287,"date":1288,"series":1289,"seriesOrder":1166},"\u002Fposts\u002Fgit\u002Fgit-install-and-basics","Git 安装与基本使用","从装好 Git 到跑通日常提交流程，把最常用的几条命令和它们背后的三个区域讲清楚。","2026-10-04","Git 入门",{"path":1291,"title":1292,"description":1293,"date":1288,"series":1289,"seriesOrder":961},"\u002Fposts\u002Fgit\u002Flocal-remote-repository","本地远程仓库的部署","用自己的机器当 Git 服务器：建一个裸仓库、走 SSH 连上去，把本地提交推上去。",{"path":1295,"title":1296,"description":1297,"date":1288,"series":1298,"seriesOrder":1166},"\u002Fposts\u002Fguide\u002Fguide-file-layout","文件都放在哪","文章、图片、封面分别放在仓库的什么位置，哪些目录可以放手改、哪些碰了会出问题。","博客使用指南",{"path":1300,"title":1301,"description":1302,"date":1288,"series":1298,"seriesOrder":961},"\u002Fposts\u002Fguide\u002Fguide-frontmatter","frontmatter 每个字段是什么意思","文章开头那段被横线包住的字段，逐个说明作用、默认行为和写错的后果。",{"path":1304,"title":1305,"description":1306,"date":1288,"series":1298,"seriesOrder":958},"\u002Fposts\u002Fguide\u002Fguide-markdown","正文怎么写 —— Markdown 与排版效果","标题、链接、图片、代码、表格分别怎么写，以及本站对它们做了哪些自定义处理。",1793268184996]