檔案編輯模式具備多檔案代碼修改的能力，當開發人員需要精準地修改代碼檔案時，能夠結合需求描述和當前工程環境進行多檔案修改，並且可以進行多次迭代、代碼審查，協助開發人員高效、可控地完成代碼修改任務。
該功能目前僅支援 Visual Studio Code，不適用於 Lingma IDE和JetBrains IDE 外掛程式。
檔案編輯模式為原 AI 程式員模組，可在 VS Code、JetBrains IDEs 中，將靈碼升級到 2.5.0 或以上版本後體驗。
檔案編輯模式具備以下核心能力：
工程級變更：可根據開發人員的任務描述，進行工程內多個代碼檔案修改，同時可通過多次對話進行逐步迭代或快照復原，開發人員與靈碼協同逐步完成編碼任務。
精確編輯：在開發人員提供的上下文範圍內完成代碼檔案修改，不會做出超出開發人員預期的修改。
快速執行：嚴格遵循開發人員的任務描述和提供的上下文，進行代碼檔案修改，無需進行額外的複雜任務計劃，相比智能體模式完成任務更加迅速。
工具使用：擁有檔案讀取、工程內語義檢索、檔案編輯等代碼修改相關工具使用能力，可協助開發人員快速完成代碼修改。
多檔案代碼修改
檔案編輯模式可以協助開發人員快速完成一個研發任務的多個檔案的代碼修改工作。在使用檔案模式時，可以遵循以下幾點建議：
清晰的需求描述：首先需要澄清我們需要修改哪些代碼和要求，建議包含一個明確的目標，並通過步驟式的結構化描述，詳細地描述您期望完成的編碼任務要求。
指定需要的上下文：選擇代碼檔案、圖片、codebase、codeChanges 等上下文，明確需要進行修改的範圍、要求、可參考的內容等，可以讓靈碼更加精準地瞭解您的意圖，產生最佳的方案和建議代碼。
明確產生要求：告訴靈碼在產生代碼修改建議時，您期望它遵循的要求，比如語言、規範、格式、變更目標等，如“產生變更時，同時為每個方法產生英文注釋”。工程級通用的要求也可以配置到 Lingma Rules 檔案中儲存，詳情可參考：規則設定。
善用快照功能：當 AI 產生內容不符合預期，或您的需求有變化時，可以通過快照功能回退到之前的對話輪次和代碼變更，繼續重新提問。
檔案級單元測試產生（UnitTest）
單元測試智能體是檔案編輯模式所具備的一種專項能力，可以針對代碼變更（#codeChanges）、單個或多個代碼檔案批量產生單元測試檔案。開發人員輸入被測內容、產生要求，即可自動產生測試計劃、測試案例、編譯、運行以及根據錯誤資訊進行自動修複，大幅提升測試案例覆蓋度和用例的產生品質，降低開發人員編寫單元測試用例的成本。
目前僅在 IntelliJ IDEA 中支援當前單元測試產生和互動方式。
選擇被測代碼並輸入要求
開啟智能會話視窗並切換到檔案編輯模式，在輸入框內單擊 ➕ 或者輸入 # 即可選擇需要的相關上下文，並輸入相關的指令要求（建議輸入和產生單元測試相關要求的內容），輸入完成後發送即可，靈碼會自動感知意圖，開始進入產生單元測試的流程。
選擇和確認環境資訊
收到測試要求後，靈碼會自動檢測本地環境 Java 版本、構建工具、測試架構、Mock 架構等資訊，如果檢測到多個版本，開發人員可主動選擇需要的版本；如果無法識別，將看到提示錯誤，單擊“如何修複”按鈕，開發人員可以進一步瞭解如何配置相關組件。
確定被測方法
環境資訊檢查通過後，靈碼將自動分析被測檔案，並產生測試計劃，開發人員可以主動選擇需要覆蓋的方法，選擇並確認完成後，單擊確定按鈕，即可開始為每個方法產生單元測試用例。
每次至少選擇 1 個方法為其產生測試案例，最多選擇 20 個方法；
選擇方法後，會提示整體產生過程預計需要的時間，以供參考。
查看產生進展
在確定被測方法後，靈碼將自動根據開發人員選擇的被測方法進行單測用例產生工作，並自動對產生的結果進行編譯、運行和自動修複。最終的結果會展示在介面中，狀態及釋義如下：
狀態 | 表徵圖含義 |
| 代表運行通過的用例 |
| 代表編譯通過但運行失敗的用例 |
| 代表編譯失敗的用例 |
當所有方法的用例產生完成後，靈碼自動將編譯通過和運行通過的用例合并成最終測試案例檔案，並根據被測檔案自動進行命名。對於編譯失敗的測試案例代碼，開發人員可自行選擇是否需要，所有用例代碼確認後，可單擊完成按鈕，測試案例檔案將自動與原測試案例檔案進行差異對比。
審查、接受測試案例檔案代碼
確認完成後，測試案例檔案會出現在工作區中，開發人員可單擊工作區的查看變更按鈕或單擊檔案清單中的某檔案，即可看到對應檔案的變更對比查看視圖（Diff View），開發人員可進行審查、局部修改、接受或拒絕部分代碼等。確認所有代碼變更後，單擊接受按鈕，測試案例檔案變更代碼將正式進入到當前代碼工程。
