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