毫無疑問，Marscode 能解決非常多基礎問題，特別對于編程新手而言，它能相對準確地生成各種代碼，完成編程任務，但其底層并不神秘，本質上就是在傳統 IDE 基礎上，搭配足夠好的交互與足夠好的 LLM，從而超越傳統 IDE。交互方面，它在 VS Code 基礎上，補充提供了：

• 提供了幾乎毫無門檻的代碼自動補全能力，并且支持多行編輯，這在一些場景，如修改變量名時，非常好用。
• 行內、獨立問答面板，可用于快速解答問題。

在此基礎上，配合豆包模型，算得上是國內最好的編程輔助工具了。但工具再好，錯誤的用法下生成效果很可能不能達到預期，因此，這里根據我個人的使用經驗，匯總一些最佳實踐技巧。

1.  頻繁提交代碼

切記，LLM 始終是隨機的，無法保證下次執行結果的正確性，在使用過程務必養成習慣頻繁提交代碼，方便出現問題時隨時回滾。我個人的操作習慣大致是：

• 使用 Marscode 各類面板生成代碼后，先做一遍簡單的代碼 Review，修改變量名、循環結構等基礎問題；
• 在軟件上下文中集成調試，初步驗證正確性后立即提交代碼；
• 審閱代碼設計，重點關注：函數輸入輸出結構、模塊導入導出內容、邏輯與循環分支處理等等，在這個節點通常會持續讓 LLM 按我的想法優化代碼，或者自己上手做些小修改，迭代多次持續提交代碼，這個過程通常耗時最多；
• 代碼初步穩定后，繼續讓 LLM 幫我生成單測代碼，這個階段通常需要迭代多次，提交多次，直至單測通過，覆蓋率達標為止；
• 功能代碼、測試代碼均準備就緒后，提交 PR 準備合碼；

這個過程中，每次調用 LLM 都可能得到不符合預期的結果，但只要基本達標我都會立即 Commit，后續遇到問題隨時 Revert 即可，雖然這會產生大量 Commit History ，但合碼前使用 Rebase 等操作調整歷史記錄即可。

2.  重視 Code Review

其次，建議將更多時間精力放在 Code Review 上，因為 Marscode 生成的代碼可能是局部最優，但可能因為缺失相對抽象的全局架構信息，而并不能做到全局最優，例如重復編寫組件，或破壞某些約定俗成的架構規則等，日積月累同類代碼可能最終導致可維護性、可讀性都逐步劣化到無法繼續迭代的程度(公正點說，人類智能也會導致這類問題)。

因此非常建議重視建立嚴謹的 Code Review 文化，理想情況應該是由 Marscode 生成盡可能多的代碼，盡可能代替人類完成編碼工作，再由人類智能負責驗證、審查這些代碼的合理性，保證結果正確且長期可維護。

3.  更好的工程化體系

如前所述，Marscode，或者說 LLM 生成的結果是隨機的，無法保證每次都得到正確的結果，每次變更都有可能影響存量代碼的穩定性，如果這些變更都必須由人類手動驗證，那么測試成本會搞起不下，測試環節會成為工程中新的效率卡點。

更好的方式，應該是投入更多精力建設更穩健的工程化體系(這部分需求也可由 Marscode 輔助實現)，使用自動化工具代替人力完成諸多基礎質檢任務，例如引入 UT/E2E 完成運行質量測試，CI/CD 中加入 TS 類型檢查、ESLint 風格檢查等保證代碼質量，等等。重點在于，使用更高效、成本更低的方式不斷驗證 AI 產物質量，更敏捷地應對變化。

此處不再贅述。

4.  使用 AI 友好的技術棧

在使用 Marscode 或其他同類輔助編程工具時，應盡可能選用各類 AI 友好的技術棧，以前端為例，如：Tailwind 優于原生 CSS/Less 等；Typescript 優于 JavaScript、CoffeeScript 等；React 或 Vue 等 MVVM 框架優于原生 JS + HTML + CSS；GraphQL 優于 Restful 等。

為什么技術棧之間會出現這種差異呢？關鍵在于 LLM 底層是基于概率推導實現內容生成的，結果好壞取決于模型質量、訓練語料、上下文完整度、Prompt 等諸多因素，單就輔助生產代碼這一任務而言，LLM 對技術棧的理解越充分必然效果越好；代碼結構越聚焦，推導時信息噪音越低，結果也會越好；業務實現中的特化場景越少，通用規則越多，LLM 需要理解的內容越少，效果通常也會越好；等等。

基于這些維度，我個人總結了幾類簡單規則可用于輔助評估某種技術棧是否更適用于 AIGC 場景，包括：

• 社區熱度：社區越繁榮，意味著使用者越多，相關的技術討論、技術資料也必然越豐富，LLM 訓練或執行時所能索引的信息就越完整，那么也就越容易推導出較好的結果。舉個例子，假設你工作中遇到了某個非常具體而棘手的問題，若剛好有人也遇到過，并將該問題形成的底層原因、解決方案整理成文章并發布到互聯網上，若 LLM 運行時能檢索到該文章，則可以基于文章內容推導給出最終解決方案；若網絡上沒有這類信息，考慮到 LLM 并不具備復雜邏輯推理能力，那么大概率無法給出有效的解決方案。
• 結構化：技術棧本身的結構化、模塊化水平越強，則其信息表現形式越是聚焦，越容易被 LLM 正確推導。比如，原子 CSS(如 Tailwind) 就是一個很好的例子，原生 CSS 是通過具體的屬性的鍵值對表達頁面元素的視覺效果，而原子化 CSS 則是通過原子類名表達某類樣式規則集，信息更聚焦更容易被 AI 理解；并且受層疊規則影響，使用原生 CSS 時，元素樣式可能受全局、祖先級元素、多種選擇器等層級的樣式規則影響，這對 LLM 而言意味著具體信息分散在項目的多個角落，需要消費、理解更多上下文才能推導出正確的結果，相對而言原子化 CSS 框架下，大部分樣式信息都聚焦在元素對應的 Class 列表上，信息高度聚焦，推理成本更低，結果也會更可靠。
• 通用規則優于特化設計：技術棧的設計規范越是通用，則越容易被 LLM 理解，也就越是適用于 AIGC 場景。例如，GraphQL 明顯優于 Restful，因為 GraphQL 提供了一套用于描述實體 + 實體關聯關系的通用語言規則，足夠用于表達絕大多數數據存、取、刪、改等常規業務操作，因而對 LLM 而言只需理解這套通用語言規則，配合具體業務領域中的實體與實體關系即可基于 GraphQL 靈活編寫出各類數據操作邏輯；而 Restfull 規范則更多聚焦在實體上，除幾種基礎的數據操作外，涉及復雜數據結構場景時，出于實用性、性能等角度考慮，通常不得不特化設計、特化開發，而這些特化處理對 LLM 而言會顯得過于具體，相應的上下文復雜度與噪音也會更高，也就更難以推導出正確的答案。
• 自動化質檢：技術棧的質檢工具越強大，則能夠越早、越全面地發現質量問題，進而更能低效 LLM 隨機性帶來的質量風險，也就更適用于 AIGC 場景了。例如，Typescript 之于 JavaScript，前者具有更強的類型聲明系統，因此在靜態代碼分析階段即可找出諸多類型不匹配問題，那么即使 LLM 生成了類型不匹配的代碼，也能夠在運行代碼之前發現問題，糾錯成本要低很多。

當然，上述規則僅僅是我的一家之言，隨著大模型的迭代發展，具體規則后續必然還會新增或刪改，這不重要，重要的是非常建議讀者后續在做技術選型時，不要只是基于個人 or 團隊喜好做決定，應該更多考慮技術棧對 AI 的適用性，甚至可以以此為首要原則，盡可能選用對 AI 友好的技術與工具，使得 LLM 更好、更準確地輔助完成各類開發任務，充分融入到日常工作中，提升個體與團隊的整體效率。

5. 降低預期

對，標題沒寫錯，你需要降低預期！前面也說過幾次，LLM 并不是魔法，它有幻覺，有知識漏洞，有隨機性，不擅長解決復雜問題，有各種各樣的缺點，從我的使用經驗來說，多數時候它還遠沒有達到我預期的狀態，需要我參與到各種代碼細節中。

例如，生成單測通常都跑不通，需要各種修改微調測試；生成的文檔可能也會缺失某些重要內容，需要調整 Prompt 后多次重試，才有可能達到預期效果；生成的代碼，即使在 Marscode 各種上下文引用能力的加持下，也經常會在細節處犯錯，導致執行失敗。以 LLM 的底層實現邏輯來說，這些結果都太正常不過了。

因此，建議降低對 Marscode 或者其他 LLM 工具的預期，它并不是魔法，無法完全代替人類智能，當下你還是需要認真做好導演角色，引導 Marscode 更準確更好地解決你的問題，認真研讀理解倉庫已有的代碼與 LLM 生成的代碼。更進一步的說，你自身還是需要有比較強的技術能力，理解各類技術底層細節，才能及時發現、修復問題。某種程度上，Marscode 就像一把刀，它的鋒利程度取決于你自身的功力。

總結

本文討論了 Marscode 作為編程輔助工具的優勢、使用中的最佳實踐技巧以及需要注意的問題。Marscode 在傳統 IDE 基礎上，搭配良好的交互與 LLM，能為編程新手準確生成代碼，但仍存在局限性。

關鍵要點包括：

• 頻繁提交代碼：使用 Marscode 生成代碼后，經過簡單 Review、調試、審閱設計等步驟，多次迭代并及時提交，方便回滾。
• 重視 Code Review：Marscode 生成的代碼可能局部最優但非全局最優，應重視人工審查以保證長期可維護性。
• 建立更好的工程化體系：投入精力建設穩健的工程化體系，用自動化工具代替人力完成基礎質檢任務。
• 使用 AI 友好的技術棧：選用社區熱度高、結構化強、通用規則優、自動化質檢好的技術棧，以提升 LLM 輔助效果。
• 降低預期：LLM 有諸多缺點，無法完全替代人類智能，使用者自身需具備較強技術能力。