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