鋼結構加固施工方案要怎么寫（如何自建小型恒溫冷庫）

本文目錄

1、鋼結構加固施工方案要怎么寫
2、如何自建小型恒溫冷庫
3、如果做地下車庫地坪，那么應該用哪些材料比較適合
4、DevOps哪些廠家技術好
5、今天我房東讓我幫他加固倉庫（純粹幫忙，沒有報酬的），6.8米高

1、鋼結構加固施工方案要怎么寫

加固措施：通過體外預應力索施加反向荷載的方法對該橋進行加固，此外考慮箱梁兩側腹板出現大量的斜剪裂縫，為了約束斜裂縫進一步發展，加強對腹板混凝土的約束，增強腹板抗剪承載能力和剛度，采用腹板內側粘貼鋼板。預應力施工工藝1.錨固端部橫梁與跨中轉向橫肋!墩頂導向槽的施工2.鋼絞線下料與穿束3.鋼絞線張拉4 預緊5.高應力張拉6.壓漿
缺點：
1.預應力的施工工藝，在鋼絞線下料與穿束中粘接段段的長度和位置，新老混凝土之間的粘結,后加預應力對原預應力的影響,很難確定。
2.施加預應力索加固現在存在的問題：如合理的加固預應力筋的位置和數量后加固的預應力鋼筋對已經存在的預應力鋼筋的影響
3.體外預應力鋼筋松弛、斷筋等失效的現象也較為常見
二.體外預應力的加固另外的加強措施
1 彎曲加強
采用體外預應力加固法可提高結構構件的受彎承載力.預應力筋布置應符合優化布置原則,即加固筋外形與外荷載產生的彎矩圖形相似.因此,加固梁式結構時,體外預應力筋多采用折線形連續筋,以充分發揮加固筋的抗拉強度.體外筋的靈活布置,可以有效地補強加固不同受力情況的簡支梁和連續梁.若連續梁中僅有個別跨需要加固,則可采取在這些跨上單獨布置預應力筋進行局部加固;若連續梁普遍較差,則可用各跨布置給予整體加固,若連續梁普遍較弱,但個別跨更弱,則可采取通長布置與局部布置相結合的辦法進行加固.
2 剪切加強
梁的剪切強度可通過外部加設扁鋼!鋼板和鋼箍等方法來提高.扁鋼通常箍在構件上用后張法拉緊并已開發了一種后張不銹鋼鋼箍的方法.后張法能使新材料平分恒載及活載,這樣就能更有效地利用新增材料.提高剪切強度的另外一種方法為采用后張的附加預應力鋼筋.預應力鋼筋可以加在垂直和傾斜方向上,而且既可安裝在梁腹板內,又可安裝在箱內.施加預應力時應當小心謹慎,避免結構某些部分出現超限應力.若構件中存在裂縫,一個好的實施方法是在施加預應力之前,先在裂紋上注射環氧樹脂.

三．粘貼碳纖維法與鋼板粘貼加強法基本原理是一致的，均是將其增強材料粘貼在混凝土結構的受拉邊緣或薄弱部位，使之與結構形成整體，代替需增設的補強鋼筋，提高梁的承載能力達到補強的目的
粘貼碳纖維法
碳纖維加固橋梁構件的部位：用粘結材料將碳纖維材料有序地纏繞粘貼于構件表面，實現對構件變形的約束并因此提高構件的極限強度和承載能力。在橋梁加固運用中，可粘貼在混凝土梁的頂面或底板上，以提高混凝土梁的截面強度和剛度:也可粘貼在梁的腹板上，以提高其抗剪強度
具體的施工工藝：
1. 處理結構混凝土表面，涂敷基底樹脂并整平
2. 涂刮整平膠并對其表面作砂光處理
3. 滾刷粘結劑粘結碳纖維
4. 對已貼的碳纖維作壓面處理
5. 表面整飾（如抹砂漿等）
粘貼鋼板（碳纖維）法：（1）對結構抗彎和抗剪加固效果明顯，但對結構靜剛度影響不大（靜剛度包括等直桿件扭轉剛度、受彎梁的彎曲強度、薄板受彎曲載荷作用、薄殼變形計算）。（2）在借用橋面鋪裝層參與受力時，新老混凝土的可靠連接，始終存在問題如粘結劑的老化問題
此外粘貼鋼板法存在以下自己特殊的缺點:(1) ,鋼板面積大,剛度大,適型性差,很難與原結構緊密粘接,此外,自重很大,加上銹跡等原因,底、側粘貼很易脫落（鋼板易受腐蝕或脫落）(2)對于大跨度梁來說,鋼板的重量可能太重
粘貼碳纖維法存在以下自己特殊的缺點(1碳纖維的抗剪強度低,延展性又不好,所以,其受力的不均勻性必須充分注意(2) 碳纖維用于橋梁加固,其老化問題不容忽視。
四．體系轉換法：是通過改變橋梁結構體系以減少梁內應力，提高承載能力的一種加固方法這是一種‘變被動加固為主動加固’的方法，該方法需要對原結構的現狀進行仔細的調查，對其承載潛能進行正確評價，用周密、細致、可靠的汁算分析確定體系轉換的方法和施工工藝流程，以達到加固修復病橋的目的。一般可通過簡支梁下增一設支架或橋墩;或把簡支梁與簡支梁加以連接，使結構由簡支變為連續等。
施工工藝：(1)揭開橋面鋪裝層.將梁頂保護層鑿除.使主筋外露.沿梁頂增設縱向受力主筋，數量根據計算決定。
(2)澆注端頭混凝土
(3)拆除或改變原有支座
(4)重新做好橋面鋪裝
該加固方法主要對于大、中簡支梁橋的加固，將多跨簡支梁的梁端連接起來，變為多跨連續梁，，可以有效改善結構的受力狀況，提高橋梁的承載能力，但不適合連續剛構橋的后期加固
五．橋面系減載。對大跨度連續剛構而言，恒載在總重量中占有相當大的比重，減小橋跨內橋面的恒載重量諸如變鹼橋面鋪裝為瀝青鹼橋面鋪裝、變鹼欄桿系為鋼質欄桿系、減薄人行道鋪裝厚度等能有效地減小跨中的下撓量。
六．擴大或增加原結構構件截面,以提高原結構的強度和剛度;該方法雖然能提高結構承載力,但也會因而加大結構自重。自重加大產生的內力增量會消抵部分或全部結構承載能力的提高。且新增結構面積或體外施加的預應力與原結構體的界面能否良好結合
此外(1)擴大或增加原結構構件截面,以提高原結構的強度和剛度; (2)改變原結構的受力體系,使其減小受力;（3）以新的結構代替舊的應力不夠的結構這三種方法均不能用于大跨徑連續剛構橋

2、如何自建小型恒溫冷庫

自建小型恒溫冷庫的方法是，采用磚、石或混凝土結構,加防潮層、隔熱層。墻壁和地面可用混凝土加固,并加防潮層和隔熱層,天花板的熱面也要設防潮層,并與地面的防潮層連接,使整個倉庫內,不受外界潮濕空氣的影響

3、如果做地下車庫地坪，那么應該用哪些材料比較適合

一、目前的車庫地坪2113一般有金剛砂、環氧樹脂5261及耐磨硬化地坪三4102種，其中環氧地坪比較普遍，但后期的翻新成本1653較高。二、環氧地坪的優點是防塵、顏色多樣、質地無接縫。缺點是，易老化、地面潮濕后容易脫殼、起皮，且用環氧施工的地下車庫地坪耐磨性較差，汽車輾壓后容易留下難看的拖痕且不容易清潔，后期翻新改造成本高。

4、DevOps哪些廠家技術好

實施DevOps的核心目標是加速團隊、企業的IT精益運行，從根本上提升IT的生產效率，加速部門、企業的業務創新能力。

是的，DevOps的優勢很明顯。那為什么它這么好，但這些年下來實際落地的企業卻這么少。除了作者提到的容器、微服務等相關的『環境因素』外，還有哪些內在因素？普元在這方面又有哪些經驗和案例？InfoQ就這些問題對普元的主任架構師顧偉進行了采訪（文末有嘉賓二維碼，掃碼加入群）。

受訪嘉賓簡介

顧偉，畢業于東南大學，現任普元公司主任架構師；先后參與和帶領了華為BME、中信銀行CBJUP、工商銀行CTP、中航信RI、阿里云ACE、普元云計算平臺、普元The Platform等大型項目的交付；長期致力于IT技術研究、產品設計、架構咨詢等工作，擅長Web、OSGI、CI/CD、服務治理、云計算等領域技術；對DevOps、自動化運維、微服務架構有著濃厚的興趣。

InfoQ：請介紹下您的技術背景和目前負責的項目？能否回顧總結并階段性地介紹下您的技術成長經歷？

顧偉：大家好，我是顧偉，專注于DevOps和云計算領域，擅長CI/CD、前端、OSGI、容器等技術，對各類自動化、智能化有著濃厚的興趣。目前負責普元The Platform云平臺產品的設計工作，兼顧DevOps、CaaS、IaaS等外部實施工作。
到目前，我的職業生涯中經歷的領域和技術棧比較雜，大體分為以下四個階段：
06年-07年：以項目實施為主，參與了華為BME項目的多期建設，熟練掌握了包括Java、Web、數據庫等基本技能。
07年-10年：主要參與了兩款產品研發，一款是基于Ext的所見即所得的UI產品，一款是基于Eclipse插件開發的IDE平臺，熟練掌握了主流UI框架和Eclipse的大部分源碼。回過頭來看，學習優秀框架設計的經歷，為今后的架構之路奠定了較好的基礎。
10年-12年：以大型企業級平臺實施為主，參與了工商銀行、中信銀行的統一平臺項目，也主導過中航信RI等創新項目。在加固已有知識的同時，這段經歷使我掌握了諸多企業級中間件（比如IBM MQ、ILOG、BMC CMDB等）的使用和擴展，同時也開始接觸了如云計算、大數據領域的新技術。
13年-16年：從與阿里云ACE合作云產品開始，先后歷經了普元IaaS（OpenStack），CaaS（Kubernetes + Docker），DevOps領域等產品設計及研發工作。這段時間，擁抱開源并實踐于企業級產品中，算是正式走進了企業云計算領域。

InfoQ：您曾經提到過您很關注DevOps和自動化運維。能否簡要介紹下您對這兩者的理解和未來趨勢的看法？DevOps給運維部分帶來了哪些變化？

顧偉：在我的理解里，DevOps其實是包含了自動化運維的。只是現在這兩種概念都很常見，所以我分開提及的。
大家肯定都能感覺到，DevOps、微服務、容器等概念已經越來越熱了。這讓我想到了3年前OpenStack的狀態，各大社區、創業公司、傳統企業，紛紛投入到OpenStack懷抱；而現在，雖然是有一些公司存活下來了，但總的來看誰也沒賺到多少錢，也沒有哪家公司如預想般把VMware給替代了。過熱的后果是反而把市場秩序給弄得一團糟，產品低價競爭，人員漫天要價。
我覺得現在的DevOps也到了這個岔路口，有很多公司在熱炒DevOps的概念，并紛紛宣布轉型成功；而從實際市場、尤其企業市場的反饋來看，客戶對此的評價幾乎眾口一詞：“DevOps很好，但我們很難做到”。
究其原因，最缺乏的是DevOps方案提供公司真正到深入到企業里面，沉下心來，結合實際情況進行實施實踐，從而幫助客戶切實地做到橫向協作打通、縱向工具鏈打通。所以我覺得，市場到今年底前還是會充斥著很多概念炒作；但從明年開始，大家會逐步看到，這個領域中真正的脫穎而出的，將會是那些已經將DevOps實際落地的企業和服務商。
DevOps給運維帶來的變化，主要體現在運維工具的打通，但是單單從這個角度看影響并不很明顯。如果能夠從企業、部門、團隊多維角度結合來看，才能發現DevOps獨特的地方。
DevOps本質上是一個持續優化的過程，一般需要從組織、技術、流程三個維度考慮，目標是加速IT的精益運營。 DevOps推崇的是讓開發、測試、運維友好協作，倡導大家都能為各自的上下游提供便利，形成演進回環，有效的支撐業務創新。

InfoQ：你提到，DevOps很好，但也很難落地。你認為難點在哪里？如果說要突破這些挑戰，你認為團隊負責人應該重點從哪些方面入手？

顧偉：我覺得DevOps最大的難點并不是所謂的文化或組織（因為這個不是說改變或打破就能改變或打破的），而是各家公司的流程和工具都是有差異的，每家都會有自己的特色與特殊部分，很難有所謂的通用產品能解決所有問題。
舉個代碼庫工具使用的例子，之前在我們群里還單獨拿出來討論的，有的企業是主干開發、分支release；有的企業是分支開發、分支release，接著再往下細，都是分支開發并release的企業，同一個產品版本，有的是開發環境、測試環境、生產環境對應的分支物理上是不同的，也有開發測試環境相同、生產環境不同的，還有從開發到最終上線就一個分支的。而且每家做法都有很充分的理由……
想突破這種問題，對于一個團隊負責人來說，要能在一定的條件下，有效組織團隊、逐步優化流程。這里說的“一定的條件”涉及很多方面，比如不要試圖按理想情況去打通部門，這是永遠不可能的，再比如想讓團隊每個人都有一樣的高度、理解力、責任感也是很難實現的。所以對于一個團隊負責人來說，想實施好DevOps，需要理清現狀，統一概念模型，制定階段性目標，激發團隊熱情，有效規避風險；而不是一上來就是要用什么技術，要有多好的理念之類。

InfoQ：你如何看不可變基礎設施？

顧偉：看到這個問題，首先想吐吐槽：初次聽到不可變的基礎設施時，我當時不知道為什么，還想起了另外一個概念：基礎設施即代碼，雖然這兩者沒有特別的強關聯，但第一感覺就是，現在市場上很喜歡拿基礎設施來說事。
我以前做過IaaS、PaaS，也參與過運維工作，基礎設施在我的理解里是一個底層、重、固化的東西。隨著一切皆服務、一切皆代碼、無狀態這些概念起來，讓我覺得市場上的任何詞，都可以變成“怎么說都有理”的理念。
回歸正題，我認為要像不可變的基礎設施的目標前行，有兩點比較重要：
從使用者的角度來看，基礎設施最好是無差異無感知的，所謂的無差異或無感知是說無論下面是什么樣的異構硬件、不同系統等，對上層業務的服務提供都是統一的；
從提供者的角度來看，基礎設施從建立之初就不要再變更，只有新建與替換，粒度很重要，這也是很多人甚至會提到消除SSH的想法的原因。
對于不可變基礎設施的未來，我認為是個長期的目標。隨著容器、DevOps能力的逐步落地，給了這個目標一個可實現路徑，但真的要做到完全不變，我覺得是很難的，因為生態還沒有起來，很多層的能力或接口還沒有統一和規范，差異化永遠是不可變的最大攔路虎。

InfoQ：這兩天又有人提出了OpsDev的概念，你怎么看？

顧偉：這個我之前也看到了，看到第一句解釋后我就沒再看下去，因為從來沒有人說過DevOps到底是Dev2Ops還是Ops2Dev，為什么？因為無論是Dev還是Ops，都應該將對方視為可標準的對象，同時為對方提供足夠可規范的便捷（主動的嘗試著去適應對方），這本來就不是一個單向的過程。
所以我認為無論是叫DevOps，還是叫OpsDev，大家的目標都是一樣的，切勿認為詞語上的誰先誰后，就意味著誰主動誰被動。在不失規范與流程的前提下，打通上下游、雙向協作才是DevOps的真諦。

InfoQ：您即將在CNUTCon全球容器技術大會上和我們分享《基于微服務架構的容器云之實踐》，可否先大概介紹下你們的容器云？

顧偉：其實普元的主要目標是落地DevOps，在技術實現上，只是底層默認使用了CaaS作為支撐（當然平臺也兼容IaaS）。平臺在原有的基礎能力之上，實現了容器+微服務的部分，并不斷版本迭代演變至今。第一個版本花費約半年多時間。這次，為了契合容器大會主題，我選擇了底層CaaS部分的實踐進行分享。
目前我們的容器云既可以運行于私有云（OpenStack、VMware），也可以支持在公有云（阿里云）上運行。平臺以微服務架構為支撐，使用了Kubernetes + Docker的組合，以CoreOS、Flannel、SkyDNS等作為支撐選件，集成了包括MySQL、Redis、GIT、Nexus、Jenkins、Docker Registry等基礎服務，形成了一款用于支撐企業DevOps的容器云平臺。平臺最終架構圖（含DevOps能力）如下：

InfoQ：這套容器+微服務實現的DevOps方案，您認為哪類行業的企業可以借鑒參考？傳統企業可以在哪種情況下，開展怎樣的嘗試？又該如何拆分傳統應用？

顧偉：這套方案相對來說，比較適合有一定規模的企業或互聯網公司。因為如果團隊較小、業務較簡單（比如只有極少數量的App），那首要的問題還不在精益化上，通過人來做管理配置，也不會特別復雜。
對于傳統企業來說，我的建議是嘗試需要首先從這兩方面開始：
持續發布能力：這是打通開發測試與運維的最佳著手點，也是業界目前方案成熟度較好的模塊。
自服務能力：自助和自動，是打通上下游、提升運營效率的有效手段，自服務能力強調的正是這一點。
至于提及微服務化是如何進行單塊應用拆分，我覺得是這之后的事情：沒有配套的運營支撐平臺，何談微服務架構。

InfoQ：您提到過目前的這個方案在13年的時候普元就有提出過。當年是在什么樣的情況下想到的呢？為什么當時沒有落地這樣的想法？

顧偉：翻翻歷史，這個點子是13年的時候，我們董事長劉亞東先生提出的，當時他指出：“數字化未來會將企業每個人、每臺機器都變成一個節點，企業信息平臺需要具備打通供應鏈、資金鏈、物流鏈、銷售鏈、服務鏈等能力，這就需要企業在未來競爭中找到自己的位置，就必須用數字化企業云平臺”。
至于為什么當時沒有落實下來？我個人覺得，畢竟當時董事長提出的無論數字化、還是連接一切等概念還比較前沿，我們團隊的積累和認知不是很夠等種種原因吧，沒有在當時真正執行起來。現在回過頭來看，算是在給當時的愿景圓夢吧！

InfoQ：為什么微服務的架構要采用容器做默認承載？如果不采用容器技術，您認為微服務化會面臨怎樣的難題？除了微服務化架構的實現，普元還有在其他情況下使用過容器技術嗎?

顧偉：首先我的觀點是，微服務架構和容器沒有任何關系，大家也可去翻一翻Martin Flower的文章。那為什么現在大家看到的文章中，提到微服務就會提容器，或者提DevOps，本質上是因為以下兩點：
其實很多公司的現狀是僅僅實現了容器管理，但是又想接下來向微服務化靠攏，于是就出現了強關聯的概念。
事實上，現在也確實存在很多企業把兩者結合在一起使用。無意中讓大家誤會了兩者的關系。
但是這只是說明了兩者相伴相生的現象，并不意味著強因果關系。
容器的優勢在于：輕量化、原子化、可移植性、快速集成等，而這與微服務所倡導的松耦合、高內聚有著異曲同工之處。在實際使用中，往往容器+微服務確實可發揮 1+1>2 的功效。
容器可以作為默認承載，但要支撐企業級系統，不能只有默認承載。因為容器的相關技術完備性現在還不足以完全支撐業務，像容器的存儲方案、有狀態服務方案這些生態技術還并不太成熟。
如果不采用容器技術，傳統VM技術、或者說IaaS，甚至純物理機架構，照樣可以支撐微服務架構，只是在管理上稍微復雜些。在普元，我們是通過統一的環境管理（內部系統叫SEM），來屏蔽底層基礎設施差異的，大家可參考我們異構環境下的統一概念模型：
目前容器技術的使用主要在這款數字化云平臺里，其他地方用的較少，只在一些客戶試點項目中有過嘗試。

InfoQ：相比較歷史系統的DevOps，基于容器技術的DevOps具有哪些特點和優勢，適用于哪些情況？您是否認同“容器改變DevOps”這種觀點？

顧偉：DevOps有時會讓人覺得很遙遠，也有很多企業會覺得先做到自動化運維就足夠了，大家對于這個概念其實褒貶不一。技術方案上，也是層出不窮，近期看到一些群、公開課、沙龍在討論DevOps實現：有用容器的；有基于Puppet、SaltStack延伸的；還有一些生于Cloud Foundry、OpenShift這些傳統PaaS之上。換而言之，DevOps其實并不局限于任何具體技術，只是容器技術在實現DevOps時有一定的優勢：
靈活：DevOps的一項重要工作是“編排”工具鏈，要求能夠對“原子活動”進行快速串接，而容器本身對于原子化及編排能力就有很好的支撐。
集約：DevOps的一大價值是資源集約管理，容器相對于傳統VM，在資源利用上就有很大優勢，其資源長短生命周期皆宜的特征，對于像開發測試云這樣的需求尤其合適。
標準：以鏡像為粒度的管理模式，相比于零散腳本、多變介質、各種小工具等規范度不高的傳統開發運維，給了實施者一定的標準。伴隨著配置、服務狀態等生態技術的補充，容器實施DevOps的方案會變得更完善。
您提到的“容器改變DevOps”說法，我認為偏絕對；我更傾向于“容器讓DevOps更容易”。

InfoQ：對于容器的運維，您認為有哪些需要特別注意的問題呢？能否詳細談談的雙模架構（模態1：傳統技術，模態2：容器技術）的自動化運維？

顧偉：我認為對于容器本身的運維，其實和傳統的運維沒有太大差別。要說容器運維有什么特別注意點，我覺的下面大家可關注以下3點：
選擇一個合適的框架，不要什么都自己研發：目前業界很好的框架并不多，K8S、Mesos、Docker本身的一些，選擇您覺得和你們理念最一致的，作為你的基礎框架。
避免慣性思維：很多做過傳統運維的同學，在遇到容器時，第一想法還是用既有知識和習慣管理，所以大家會發現，現在很多企業把容器當VM用，或者宿主系統一定要XXX，這個往往束縛了容器運維的優勢。
要向上抽象：畢竟容器還不能完全替換企業既有，那資源、中間件、應用的運維和容器的運維是不是可以統一，這就要求在運維角度抽象一層模型，便于后續的一體化運營平臺的建設。
對于雙模架構的自動化運維，核心問題就在于能否抽象出一套兼容的模型，屏蔽各種異構差異化，可從以下四個方面考慮：
環境：主機、存儲、網絡、容器的差異化。
配置：應用配置與環境配置，動態配置與靜態配置。
倉庫：三方倉庫、部署包倉庫、鏡像倉庫等。
流程：編譯流程、部署流程、故障流程等。

InfoQ：您說這個點子成功在于：”市場上的客戶反饋和內部的能力驅動”。能否將這兩個方面進行詳細的展開論述？

顧偉：不僅僅是這個點子，我認為任何點子的成功都離不開這兩方面：
客戶反饋：反饋的核心價值在于驅動產品向正確的方向演進，比如小米，從設計之初就籠絡了一群發燒友，請他們來提建議，幫助做設計。換個時髦的詞叫MVP，意思和快速推出試錯試對，這與管理學中的PDCA質量環有著想通的理念。我們要做大設計小版本，進而通過Inside-out & Out-inside的有效配合，基于反饋快速迭代，才能推出符合市場需求的產品。
能力驅動：這個也可以講成康威定律，我更傾向于稱之為康威定律+，團隊一定程度上決定了業務架構，擁有一個全棧的團隊，對于一些創新類點子有著非常重要的作用。在一個點子形成之初，原型、場景、計劃、設計、迭代模式、技術預研等，環環相扣，任何決定都對后期的發展有著的重要影響，所以我一直認為：有什么樣的基因，做什么類型的事情。有什么能力的團隊，做什么規模的事情。

InfoQ：最后一個問題：技術變革日新月異的今天，對于立志在技術領域中長久發展的年輕人，您有什么建議和忠告？

顧偉：忠告不敢當，結合我帶新人的經驗談談一些想法吧。
首先，技術是學不完的，以前是，現在更是。對于剛開始工作的同學，在精不在廣。任何有一定規模的技術框架，都有很多值得深入學習的地方，別人為何這么設計，相比同類產品有什么優勢。多思考，多總結。不要一味的只管調試代碼，fix bug……
學技術之外，也要學做人。技術再牛，如果無法融入團隊，那還是沒用。此外，新同學必須要有自主性。現在很多新同學有個通病，遇到問題就問導師。不是說不能問，關鍵在于問之前你有沒有真正的花精力嘗試過，或者試著問題縮小到一定范圍，不能說一遇到個坎就找人幫忙，會讓團隊的人覺得事情交給你很不放心。
最后就是執行力很重要。很多同學都會定目標定計劃，但卻很少有人制定對應的check計劃，好像這都是部門經理的事情。說白了就是缺乏自我管理能力。現在的人確實受打擾太多，但這不是執行不力的借口。建議大家制定計劃時，要短期不要長期，要實踐而不是停留在概念。