在線書店這個(gè)題目每年畢業(yè)季都會(huì)被大量同學(xué)選中但真正能把開題報(bào)告寫出“高質(zhì)量”三個(gè)字的并不多。我見過太多本子題目寫得挺大翻開一看全是“隨著互聯(lián)網(wǎng)的發(fā)展人們?cè)絹碓较矚g網(wǎng)上購(gòu)物”這類填充物評(píng)審老師掃兩眼就放下了。其實(shí)在線書店這個(gè)方向本身沒有問題它業(yè)務(wù)閉環(huán)完整、技術(shù)棧成熟、數(shù)據(jù)模型清晰特別適合用來展示一個(gè)學(xué)生對(duì)Spring Boot體系的實(shí)際掌握程度。問題出在大多數(shù)人把它當(dāng)成了“增刪改查練習(xí)”而沒有把它當(dāng)成一個(gè)需要論證的工程問題。開題報(bào)告的核心不是證明“我要做一個(gè)書店”而是證明“我知道這個(gè)書店難在哪、我打算怎么解決、我的方案為什么比別的方案更合適”。這篇內(nèi)容我就圍繞這個(gè)思路把在線書店開題報(bào)告從選題定位、技術(shù)選型、功能拆解、數(shù)據(jù)庫(kù)設(shè)計(jì)到進(jìn)度安排和風(fēng)險(xiǎn)預(yù)案完整地拆一遍把我自己帶項(xiàng)目和寫本子時(shí)踩過的坑、總結(jié)的技巧都放進(jìn)去讓不管是第一次寫開題的同學(xué)還是想把手頭本子改得更扎實(shí)的人都能直接拿去用。1. 選題定位與開題報(bào)告的核心邏輯1.1 為什么在線書店是個(gè)“看起來簡(jiǎn)單、寫起來有坑”的題目在線書店的業(yè)務(wù)表面上看就是“瀏覽商品、加購(gòu)物車、下單、付款、發(fā)貨”五步走完就結(jié)束了。但只要你稍微往深里想一層就會(huì)發(fā)現(xiàn)每一環(huán)背后都藏著一堆需要決策的問題。瀏覽商品涉及分類樹怎么設(shè)計(jì)、搜索怎么做、分頁(yè)和排序怎么處理加購(gòu)物車涉及庫(kù)存要不要鎖定、價(jià)格變動(dòng)怎么辦、未登錄用戶能不能加購(gòu)下單涉及訂單號(hào)生成策略、庫(kù)存扣減的時(shí)機(jī)和方式、事務(wù)邊界怎么劃付款涉及支付狀態(tài)回調(diào)和訂單狀態(tài)機(jī)發(fā)貨涉及后臺(tái)管理和物流信息。這些問題如果不在開題階段想清楚寫到實(shí)現(xiàn)階段就會(huì)變成“邊寫邊改”最后論文里的系統(tǒng)設(shè)計(jì)和實(shí)際代碼對(duì)不上答辯時(shí)被問一句“你的庫(kù)存是怎么扣的”就卡住了。所以我在看一份開題報(bào)告時(shí)最先看的就是它有沒有把業(yè)務(wù)邊界劃清楚。一個(gè)高質(zhì)量的在線書店開題應(yīng)該明確說明這個(gè)系統(tǒng)服務(wù)的是哪類用戶普通讀者、會(huì)員、管理員覆蓋的是哪條業(yè)務(wù)線只做自營(yíng)圖書還是允許第三方店鋪入駐以及哪些功能是核心必做、哪些是擴(kuò)展選做。這個(gè)邊界劃得越清楚后面的技術(shù)選型和功能拆解就越有依據(jù)。很多同學(xué)的本子寫得空根本原因不是文筆問題而是他自己也沒想明白這個(gè)系統(tǒng)到底要做多大。1.2 開題報(bào)告到底在評(píng)審什么開題報(bào)告的評(píng)審邏輯其實(shí)很樸素老師想確認(rèn)三件事。第一這個(gè)題目值不值得做也就是選題意義但注意這里的“意義”不是讓你喊口號(hào)而是要說明這個(gè)系統(tǒng)解決了什么具體問題比如傳統(tǒng)書店受限于物理空間和營(yíng)業(yè)時(shí)間而在線書店能讓讀者在任何時(shí)間檢索和購(gòu)買這就是一個(gè)具體的問題場(chǎng)景。第二你有沒有能力做出來也就是技術(shù)方案是否可行、你是否掌握了相關(guān)技術(shù)、工作量是否合理。第三你的計(jì)劃是否靠譜也就是進(jìn)度安排是否具體、風(fēng)險(xiǎn)有沒有預(yù)案。我見過不少本子把大量篇幅花在“國(guó)內(nèi)外研究現(xiàn)狀”上羅列一堆電商平臺(tái)的發(fā)展史但對(duì)自己的系統(tǒng)要怎么做卻一筆帶過。這是典型的用力用錯(cuò)了地方。研究現(xiàn)狀可以寫但它的作用是引出“現(xiàn)有方案有什么不足、我的系統(tǒng)在哪個(gè)點(diǎn)上做了針對(duì)性設(shè)計(jì)”而不是湊字?jǐn)?shù)。比如你可以說現(xiàn)有大型電商平臺(tái)功能龐雜、對(duì)小型書店場(chǎng)景來說過于笨重而基于Spring Boot的輕量級(jí)在線書店可以針對(duì)中小書店的運(yùn)營(yíng)需求做定制這樣就把現(xiàn)狀和你的選題接上了。1.3 選題定位的三條實(shí)操建議第一條題目不要貪大。叫“基于Spring Boot的在線書店設(shè)計(jì)與實(shí)現(xiàn)”就挺好不要改成“基于微服務(wù)架構(gòu)的智能推薦在線書店平臺(tái)”后者聽起來唬人但微服務(wù)和推薦算法任何一個(gè)展開都?jí)蛞粋€(gè)獨(dú)立課題你一個(gè)人在一個(gè)學(xué)期里做不完最后只能做成半成品。第二條功能范圍要能一句話說清。我通常建議學(xué)生用這樣一句話來定邊界“本系統(tǒng)面向中小型實(shí)體書店的線上銷售場(chǎng)景提供圖書檢索、購(gòu)物車、訂單管理、后臺(tái)圖書維護(hù)四類核心功能不涉及第三方商家入駐和復(fù)雜促銷規(guī)則?！边@句話一寫評(píng)審立刻知道你的系統(tǒng)長(zhǎng)什么樣。第三條把“設(shè)計(jì)與實(shí)現(xiàn)”的重心放在設(shè)計(jì)上。開題階段不需要你寫出完整代碼但你需要證明你的設(shè)計(jì)是經(jīng)過思考的包括架構(gòu)分層、模塊劃分、數(shù)據(jù)模型和關(guān)鍵流程這些才是開題報(bào)告真正要展示的東西。2. 技術(shù)選型背后的取舍邏輯2.1 為什么是Spring Boot而不是別的框架選Spring Boot做在線書店最直接的理由是它把Spring生態(tài)里那些繁瑣的配置做了自動(dòng)裝配讓你能把精力放在業(yè)務(wù)邏輯上。一個(gè)書店系統(tǒng)的核心復(fù)雜度在業(yè)務(wù)層比如訂單狀態(tài)流轉(zhuǎn)、庫(kù)存扣減、購(gòu)物車合并而不是在框架配置上。用Spring Boot你引入spring-boot-starter-web就能跑起一個(gè)Web服務(wù)引入spring-boot-starter-data-jpa或者M(jìn)yBatis就能接數(shù)據(jù)庫(kù)這種“開箱即用”的特性對(duì)課程設(shè)計(jì)級(jí)別的項(xiàng)目非常友好。但選型不能只說好處開題報(bào)告里最好體現(xiàn)出你考慮過替代方案。比如為什么不用原生Servlet加JDBC因?yàn)槟菢娱_發(fā)效率低事務(wù)管理和連接池都要自己處理容易出錯(cuò)。為什么不用Spring Cloud那一套因?yàn)闀晗到y(tǒng)的訪問量在課程設(shè)計(jì)場(chǎng)景下根本用不上服務(wù)拆分強(qiáng)行上微服務(wù)只會(huì)增加部署和調(diào)試成本。這種“排除法”的寫法能讓評(píng)審看到你的判斷過程而不是隨便挑了個(gè)熱門框架。2.2 持久層框架的選擇MyBatis與JPA的對(duì)比持久層這塊是很多同學(xué)糾結(jié)的地方。我把兩者的差異整理成一張表方便你根據(jù)自己的習(xí)慣來選。對(duì)比維度MyBatisSpring Data JPASQL控制力手寫SQL完全可控方法名派生或JPQL復(fù)雜查詢需自定義上手難度需要會(huì)寫SQL但邏輯直觀簡(jiǎn)單CRUD幾乎零SQL復(fù)雜關(guān)聯(lián)需要理解映射適合場(chǎng)景查詢條件多變、需要精細(xì)優(yōu)化實(shí)體關(guān)系清晰、以標(biāo)準(zhǔn)CRUD為主書店系統(tǒng)適配圖書多條件檢索、訂單統(tǒng)計(jì)報(bào)表更靈活用戶、分類等基礎(chǔ)表操作更省事我的實(shí)際經(jīng)驗(yàn)是書店系統(tǒng)里圖書檢索的條件組合比較多按分類、按價(jià)格區(qū)間、按關(guān)鍵字、按出版時(shí)間排序用MyBatis手寫動(dòng)態(tài)SQL會(huì)更順手而用戶和分類這類結(jié)構(gòu)穩(wěn)定的表用JPA能省不少代碼。當(dāng)然一個(gè)項(xiàng)目里混用兩套持久層會(huì)增加學(xué)習(xí)成本所以如果你對(duì)SQL比較熟統(tǒng)一用MyBatis是更穩(wěn)妥的選擇如果你更習(xí)慣面向?qū)ο笏季SJPA也完全夠用。開題報(bào)告里把選擇理由寫清楚比選哪個(gè)本身更重要。2.3 前端方案與整體架構(gòu)分層前端這塊課程設(shè)計(jì)場(chǎng)景下我一般建議用Thymeleaf做服務(wù)端渲染配合Bootstrap做樣式。原因很實(shí)際前后端分離需要你額外處理跨域、接口鑒權(quán)、前端路由工作量翻倍而書店系統(tǒng)的頁(yè)面交互并不復(fù)雜服務(wù)端渲染完全能撐住。如果你的課題要求體現(xiàn)前后端分離那用Vue加Axios也可以但要在開題里說明接口設(shè)計(jì)的大致思路比如統(tǒng)一返回結(jié)構(gòu)、統(tǒng)一異常處理。整體架構(gòu)上經(jīng)典的三層結(jié)構(gòu)控制層、業(yè)務(wù)層、持久層對(duì)書店系統(tǒng)來說足夠清晰?？刂茖迂?fù)責(zé)接收請(qǐng)求和參數(shù)校驗(yàn)業(yè)務(wù)層承載訂單、庫(kù)存這些核心邏輯持久層負(fù)責(zé)數(shù)據(jù)訪問。我特別想強(qiáng)調(diào)一點(diǎn)不要把業(yè)務(wù)邏輯寫到控制層里。我見過太多本子里的“系統(tǒng)設(shè)計(jì)”章節(jié)畫了個(gè)三層圖但實(shí)際描述的功能流程全是“Controller接收參數(shù)后直接調(diào)用Mapper”這就等于沒有業(yè)務(wù)層。訂單創(chuàng)建這種涉及多表寫入的操作必須放在業(yè)務(wù)層并用事務(wù)包起來這是設(shè)計(jì)是否到位的一個(gè)硬指標(biāo)。3. 功能模塊拆解與核心流程設(shè)計(jì)3.1 前臺(tái)功能模塊的劃分方式前臺(tái)面向普通讀者我通常把它拆成五個(gè)模塊用戶模塊、圖書瀏覽模塊、購(gòu)物車模塊、訂單模塊、個(gè)人中心模塊。用戶模塊包括注冊(cè)、登錄、個(gè)人信息維護(hù)這里要注意密碼必須加鹽哈希存儲(chǔ)不能明文入庫(kù)這一點(diǎn)在開題的安全設(shè)計(jì)部分要提到。圖書瀏覽模塊包括分類瀏覽、關(guān)鍵字搜索、圖書詳情查看其中搜索功能要說明是模糊匹配書名和作者還是引入分詞課程設(shè)計(jì)級(jí)別用數(shù)據(jù)庫(kù)的LIKE查詢就夠了但要在本子里說明這是基于成本的取舍。購(gòu)物車模塊是容易被低估的部分。它要處理已登錄用戶和未登錄用戶兩種情況未登錄時(shí)購(gòu)物車數(shù)據(jù)放哪通常放Session或本地存儲(chǔ)登錄后怎么合并把Session里的條目并入數(shù)據(jù)庫(kù)購(gòu)物車相同圖書數(shù)量累加。這個(gè)合并邏輯如果不提前設(shè)計(jì)實(shí)現(xiàn)時(shí)很容易出現(xiàn)重復(fù)條目或者數(shù)量覆蓋的問題。訂單模塊要覆蓋從購(gòu)物車結(jié)算、確認(rèn)訂單、生成訂單到查看訂單列表和詳情的完整鏈路。個(gè)人中心則包括收貨地址管理和訂單歷史。3.2 后臺(tái)管理模塊與權(quán)限設(shè)計(jì)后臺(tái)面向書店管理員核心是圖書管理、分類管理、訂單管理、用戶管理四塊。圖書管理包括圖書的增刪改查和上下架分類管理維護(hù)分類樹訂單管理負(fù)責(zé)查看訂單和處理發(fā)貨狀態(tài)用戶管理負(fù)責(zé)查看用戶列表和禁用異常賬號(hào)。這里的關(guān)鍵設(shè)計(jì)點(diǎn)是權(quán)限控制普通用戶不能訪問后臺(tái)接口管理員之間是否要區(qū)分角色比如超級(jí)管理員和普通運(yùn)營(yíng)取決于你的系統(tǒng)規(guī)模課程設(shè)計(jì)級(jí)別做一個(gè)簡(jiǎn)單的角色字段加攔截器校驗(yàn)就夠了。權(quán)限這塊我建議在開題里明確寫出方案基于Session的登錄態(tài)校驗(yàn)配合攔截器或者用Spring Security。前者簡(jiǎn)單直觀適合快速實(shí)現(xiàn)后者更規(guī)范但配置成本高。如果你選攔截器方案要說明攔截規(guī)則比如所有/admin/**路徑都要求登錄且角色為管理員未登錄跳轉(zhuǎn)登錄頁(yè)無權(quán)限返回403。把這些規(guī)則寫清楚評(píng)審就知道你考慮過安全問題而不是只做了個(gè)登錄頁(yè)面。3.3 訂單狀態(tài)機(jī)整個(gè)系統(tǒng)最需要想清楚的地方訂單是整個(gè)書店系統(tǒng)里狀態(tài)最多、流轉(zhuǎn)最復(fù)雜的實(shí)體也是開題報(bào)告最能體現(xiàn)設(shè)計(jì)深度的地方。我一般建議把訂單狀態(tài)定義成待支付、已支付、已發(fā)貨、已完成、已取消。狀態(tài)之間的流轉(zhuǎn)必須有明確規(guī)則待支付可以轉(zhuǎn)為已支付支付成功或已取消用戶取消或超時(shí)已支付可以轉(zhuǎn)為已發(fā)貨管理員操作已發(fā)貨可以轉(zhuǎn)為已完成用戶確認(rèn)收貨已支付狀態(tài)下如果用戶申請(qǐng)取消需要走退款流程課程設(shè)計(jì)里可以簡(jiǎn)化為管理員手動(dòng)處理。這里有個(gè)關(guān)鍵問題必須在開題里交代庫(kù)存什么時(shí)候扣。常見方案有兩種下單時(shí)扣減和支付時(shí)扣減。下單時(shí)扣減能防止超賣但用戶不付款就會(huì)占用庫(kù)存需要配合超時(shí)取消訂單來釋放支付時(shí)扣減實(shí)現(xiàn)簡(jiǎn)單但高并發(fā)下可能超賣。課程設(shè)計(jì)場(chǎng)景下我推薦下單時(shí)扣減加定時(shí)任務(wù)取消超時(shí)訂單這樣既體現(xiàn)了對(duì)庫(kù)存一致性的思考實(shí)現(xiàn)難度也可控。把這個(gè)決策和理由寫進(jìn)開題比單純列功能列表有價(jià)值得多。4. 數(shù)據(jù)庫(kù)設(shè)計(jì)與關(guān)鍵字段說明4.1 核心表結(jié)構(gòu)規(guī)劃書店系統(tǒng)的數(shù)據(jù)模型不算復(fù)雜但表之間的關(guān)系要理清楚。核心表包括用戶表、圖書表、分類表、購(gòu)物車表、訂單表、訂單明細(xì)表、收貨地址表。圖書和分類是多對(duì)一關(guān)系一個(gè)分類下有多本圖書訂單和訂單明細(xì)是一對(duì)多關(guān)系一個(gè)訂單包含多條明細(xì)購(gòu)物車表關(guān)聯(lián)用戶和圖書記錄數(shù)量。這里要特別注意訂單明細(xì)表不能只存圖書ID還要冗余存下單時(shí)的書名和單價(jià)因?yàn)閳D書價(jià)格可能變動(dòng)訂單必須保留下單時(shí)的快照否則歷史訂單金額會(huì)對(duì)不上。這個(gè)細(xì)節(jié)很多同學(xué)會(huì)忽略但在答辯時(shí)是個(gè)加分點(diǎn)。4.2 關(guān)鍵字段與索引設(shè)計(jì)以圖書表為例除了基本的書名、作者、出版社、價(jià)格、庫(kù)存、封面圖、簡(jiǎn)介、狀態(tài)上架/下架之外分類ID作為外鍵關(guān)聯(lián)分類表。索引方面書名和作者字段建議加索引因?yàn)樗阉鞴δ軙?huì)頻繁按這兩個(gè)字段做模糊查詢分類ID也建議加索引分類瀏覽是高頻操作。訂單表里用戶ID和訂單狀態(tài)都建議加索引前者用于查用戶訂單列表后者用于后臺(tái)按狀態(tài)篩選。這些索引設(shè)計(jì)不用在開題里寫得太細(xì)但提一句“針對(duì)高頻查詢字段建立索引”能體現(xiàn)你的工程意識(shí)。4.3 數(shù)據(jù)一致性的事務(wù)邊界前面提到訂單創(chuàng)建涉及訂單表寫入和訂單明細(xì)表批量寫入這兩個(gè)操作必須在同一個(gè)事務(wù)里否則可能出現(xiàn)訂單有記錄但明細(xì)缺失的情況。庫(kù)存扣減也一樣扣庫(kù)存和寫訂單要在同一個(gè)事務(wù)中或者采用先扣庫(kù)存再寫訂單、失敗則回滾的順序。開題報(bào)告里可以用一小段說明事務(wù)邊界訂單創(chuàng)建方法標(biāo)注事務(wù)注解方法內(nèi)完成庫(kù)存校驗(yàn)、庫(kù)存扣減、訂單寫入、明細(xì)寫入四步任何一步失敗整體回滾。這種描述不需要貼代碼但能讓評(píng)審看到你想過一致性問題。5. 實(shí)操層面的進(jìn)度安排與風(fēng)險(xiǎn)預(yù)案5.1 把開發(fā)任務(wù)拆到周的計(jì)劃寫法進(jìn)度安排最忌諱寫“第一個(gè)月完成需求分析第二個(gè)月完成開發(fā)第三個(gè)月寫論文”這種粗線條。我建議按周拆并且每個(gè)階段要有可交付物。比如第一到二周完成需求梳理和數(shù)據(jù)庫(kù)設(shè)計(jì)交付物是功能清單和ER圖第三到四周搭建項(xiàng)目骨架完成用戶模塊和圖書瀏覽模塊交付物是可運(yùn)行的登錄和列表頁(yè)面第五到六周完成購(gòu)物車和訂單模塊交付物是能走通下單流程第七周完成后臺(tái)管理模塊第八周做測(cè)試和修bug第九到十周寫論文和準(zhǔn)備答辯。這樣拆的好處是每個(gè)階段都有明確的完成標(biāo)準(zhǔn)你自己也能據(jù)此判斷進(jìn)度是否落后。5.2 常見風(fēng)險(xiǎn)與應(yīng)對(duì)措施開題報(bào)告里的風(fēng)險(xiǎn)分析不是走過場(chǎng)寫幾條真實(shí)的風(fēng)險(xiǎn)會(huì)讓本子顯得更可信。我通常建議寫這幾條一是技術(shù)風(fēng)險(xiǎn)比如對(duì)Spring Boot的事務(wù)管理不熟導(dǎo)致訂單數(shù)據(jù)不一致應(yīng)對(duì)措施是提前做小demo驗(yàn)證事務(wù)行為二是進(jìn)度風(fēng)險(xiǎn)比如某個(gè)模塊卡住影響整體應(yīng)對(duì)措施是核心功能優(yōu)先、擴(kuò)展功能延后三是數(shù)據(jù)風(fēng)險(xiǎn)比如測(cè)試數(shù)據(jù)不足導(dǎo)致功能驗(yàn)證不充分應(yīng)對(duì)措施是提前準(zhǔn)備一批圖書和用戶測(cè)試數(shù)據(jù)。每條風(fēng)險(xiǎn)配上具體應(yīng)對(duì)動(dòng)作比空泛地說“加強(qiáng)學(xué)習(xí)”有用得多。5.3 測(cè)試方案與驗(yàn)收標(biāo)準(zhǔn)測(cè)試部分在開題里不用寫太細(xì)但要說明測(cè)試策略功能測(cè)試覆蓋每個(gè)模塊的主流程和異常流程比如庫(kù)存不足時(shí)下單要給出提示接口測(cè)試用Postman驗(yàn)證關(guān)鍵接口的返回結(jié)構(gòu)數(shù)據(jù)測(cè)試檢查訂單金額和庫(kù)存數(shù)量在操作前后是否一致。驗(yàn)收標(biāo)準(zhǔn)可以定成“核心業(yè)務(wù)流程可完整走通、主要頁(yè)面無報(bào)錯(cuò)、關(guān)鍵數(shù)據(jù)操作前后一致”這樣答辯時(shí)你有明確的對(duì)照依據(jù)。6. 開題報(bào)告寫作中的避坑心得6.1 文獻(xiàn)綜述不要寫成流水賬很多本子的文獻(xiàn)綜述是從“上世紀(jì)九十年代電子商務(wù)興起”開始寫一路寫到今天跟自己的系統(tǒng)沒什么關(guān)系。正確的寫法是圍繞你的設(shè)計(jì)點(diǎn)來找文獻(xiàn)比如你要做庫(kù)存扣減就找討論電商庫(kù)存一致性的文章你要做搜索就找討論檢索優(yōu)化的文章。每篇文獻(xiàn)用一兩句話說明它解決了什么問題、對(duì)你的設(shè)計(jì)有什么啟發(fā)這樣綜述才有針對(duì)性。數(shù)量上不用貪多十篇左右能支撐你的論點(diǎn)就夠了。6.2 系統(tǒng)設(shè)計(jì)圖要能自圓其說開題里通常會(huì)放架構(gòu)圖、功能結(jié)構(gòu)圖、ER圖、流程圖。我見過不少圖是從網(wǎng)上找的模板圖上的模塊和正文描述對(duì)不上評(píng)審一眼就能看出來。我的建議是圖自己畫畫完對(duì)照正文檢查一遍圖上出現(xiàn)的每個(gè)模塊正文里都要有對(duì)應(yīng)說明正文里提到的每個(gè)流程圖上都要能體現(xiàn)。尤其是訂單流程圖狀態(tài)和箭頭必須和你的狀態(tài)機(jī)設(shè)計(jì)一致這是最容易被追問的地方。6.3 創(chuàng)新點(diǎn)要?jiǎng)?wù)實(shí)不要硬湊課程設(shè)計(jì)級(jí)別的項(xiàng)目很難有真正的技術(shù)創(chuàng)新所以創(chuàng)新點(diǎn)不要寫成“首次將Spring Boot應(yīng)用于書店系統(tǒng)”這種明顯不成立的話。務(wù)實(shí)的寫法是從場(chǎng)景和設(shè)計(jì)角度找差異比如“針對(duì)中小書店的運(yùn)營(yíng)特點(diǎn)設(shè)計(jì)了輕量化的庫(kù)存扣減與超時(shí)訂單釋放機(jī)制”“在購(gòu)物車設(shè)計(jì)中處理了未登錄與登錄狀態(tài)的數(shù)據(jù)合并問題”。這些點(diǎn)不大但都是你實(shí)際做了設(shè)計(jì)決策的地方答辯時(shí)也講得清楚。6.4 格式與篇幅的控制開題報(bào)告一般有字?jǐn)?shù)要求但不要為了湊字?jǐn)?shù)把一句話拆成三句說。評(píng)審看的是信息密度不是篇幅。我的經(jīng)驗(yàn)是把選題意義、技術(shù)方案、功能設(shè)計(jì)、進(jìn)度安排四塊寫扎實(shí)篇幅自然就夠了。另外格式上注意標(biāo)題層級(jí)統(tǒng)一、圖表編號(hào)連續(xù)、參考文獻(xiàn)格式規(guī)范這些細(xì)節(jié)不影響內(nèi)容質(zhì)量但會(huì)影響第一印象。最后分享一個(gè)我自己寫本子時(shí)的小習(xí)慣每寫完一個(gè)章節(jié)我會(huì)假裝自己是評(píng)審問一句“這一章如果刪掉本子會(huì)缺什么”。如果答不上來說明這章可能是湊數(shù)的需要重寫或者合并。這個(gè)方法幫我砍掉過不少水分也讓剩下的內(nèi)容更有分量。在線書店這個(gè)題目本身不新但只要你把設(shè)計(jì)決策的理由講透把業(yè)務(wù)細(xì)節(jié)摳到位它完全可以成為一份扎實(shí)的開題報(bào)告。