【CSDN 編者按】當(dāng)“大模型能不能寫代碼”逐漸變成一個(gè)有些過(guò)時(shí)的問(wèn)題，新的焦點(diǎn)正在轉(zhuǎn)向：AI 是否已經(jīng)具備參與大型工程的能力？本文記錄了一次極具挑戰(zhàn)性的真實(shí)實(shí)踐——一名幾乎沒(méi)有 Rust 經(jīng)驗(yàn)的工程師，在 Claude Code 的協(xié)助下，用一個(gè)月時(shí)間完成了約 10 萬(wàn)行 JavaScript 代碼向 Rust 的遷移。過(guò)程中既有令人驚嘆的自動(dòng)化效率，也暴露出 AI 在工程抽象、系統(tǒng)性修改和“偷懶傾向”上的真實(shí)短板。

原文鏈接：https://blog.vjeux.com/2026/analysis/porting-100k-lines-from-typescript-to-rust-using-claude-code-in-a-month.html

作者 | vjeux 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

我之前讀到一篇文章，標(biāo)題大意是：“我們的策略是結(jié)合 AI 和算法，重寫微軟最大規(guī)模的代碼庫(kù)（從 C++ 到 Rust)。我們的北極星目標(biāo)是：1 名工程師，1 個(gè)月，100 萬(wàn)行代碼?！?/p>

這句話一下子勾起了我的好奇心：這事兒真的有那么容易嗎？

正好，我心里一直有個(gè)擱置已久的想法——做一個(gè)有競(jìng)爭(zhēng)力的寶可夢(mèng)對(duì)戰(zhàn) AI。我看了大量 WolfeyVGC 的視頻，也一直關(guān)注 NeurIPS 上的 PokéAgent 挑戰(zhàn)。

好在社區(qū)里已經(jīng)有一個(gè)非常成熟的開源項(xiàng)目 Pokemon Showdown，幾乎完整實(shí)現(xiàn)了寶可夢(mèng)對(duì)戰(zhàn)的所有規(guī)則。但問(wèn)題也很明顯：它是用 JavaScript 寫的，在訓(xùn)練循環(huán)中跑得非常慢。

于是，我的一個(gè)“業(yè)余項(xiàng)目”就這么誕生了：能不能直接用 Claude，把整個(gè) Pokemon Showdown 從 JavaScript 遷移到 Rust？

先解決一個(gè)現(xiàn)實(shí)問(wèn)題：如何讓Claude“放開手腳”

讓 AI 在你本地機(jī)器上執(zhí)行任意代碼，本身就是一件危險(xiǎn)的事，所以 Claude Code 默認(rèn)被關(guān)在各種“沙箱”里——但很不巧，在這個(gè)項(xiàng)目里，我偏偏需要 AI 擁有足夠的操作權(quán)限。

下面，就講講我是如何開始了一場(chǎng)“逃離沙箱”的工程實(shí)踐。

（1）搞定 git push：遠(yuǎn)程提交代碼

Claude 的運(yùn)行沙箱會(huì)限制一些操作，比如 ssh 訪問(wèn)。而要往 GitHub 提交代碼，ssh 權(quán)限是必不可少的——畢竟我還想在摸魚的時(shí)候，用手機(jī)隨時(shí)查看 AI 的工作進(jìn)度呢！

我發(fā)現(xiàn)了一個(gè)關(guān)鍵點(diǎn)：我能在自己的終端里執(zhí)行 git 命令，但 Claude 沒(méi)法在它的沙箱終端里操作。于是我讓 Claude 寫了一個(gè) Node.js 腳本，這個(gè)腳本會(huì)在本地端口啟動(dòng)一個(gè) HTTP 服務(wù)器，專門接收 URL 傳過(guò)來(lái)的 git 命令并執(zhí)行。

只要我在終端里一直開著這個(gè)服務(wù)，再讓 Claude 在 Claude.md 里寫清楚“怎么調(diào)這個(gè)接口”，它就能間接完成 GitHub 推送。

（2）解決 rustc 編譯：繞開殺毒軟件

我電腦上的殺毒軟件有個(gè) “毛病”：遇到未知二進(jìn)制文件運(yùn)行時(shí)，必須手動(dòng)確認(rèn)才能繼續(xù)。而代碼每次編譯都會(huì)生成新的二進(jìn)制文件，我總不能一直守在電腦前點(diǎn)確認(rèn)吧？

對(duì)此，我的解決方案是：搭建一個(gè)本地 Docker 容器，所有代碼的編譯和運(yùn)行都在容器里完成。這樣一來(lái)，就不會(huì)觸發(fā)殺毒軟件的攔截機(jī)制了。同樣，我讓 Claude 把 Docker 的操作指令寫進(jìn)Claude.md，問(wèn)題直接迎刃而解。

下一個(gè)難題來(lái)了：怎么讓 Claude Code 長(zhǎng)時(shí)間自動(dòng)運(yùn)行，全程不需要人工干預(yù)？

（3）讓 Claude 連續(xù)跑幾個(gè)小時(shí)，不要老問(wèn)“可以嗎？”

Claude 非?！坝卸Y貌”，幾乎做每件事都會(huì)問(wèn)你一句 “Are you sure?”。我試過(guò)修改允許執(zhí)行的命令列表，但在我的環(huán)境里這個(gè)方法行不通。

最后我想到了一個(gè)土辦法：寫一個(gè) AppleScript 腳本，讓它每隔幾秒就在終端里自動(dòng)按一次回車鍵。這樣一來(lái)，Claude 每次彈出的權(quán)限請(qǐng)求，都會(huì)被自動(dòng) “同意”。到目前為止，它還沒(méi)想著要黑掉我的電腦……

end tell'

（4）防止 Claude 中途“摸魚”的總結(jié)

Claude 運(yùn)行一段時(shí)間后，總會(huì)停下來(lái)做總結(jié)，我試過(guò)各種提示詞讓它別這么干，甚至“威脅”它，都沒(méi)用。

我還試過(guò)用“Ralph Wiggum 循環(huán)”的方法，結(jié)果失敗了——而且遇到這個(gè)問(wèn)題的人不止我一個(gè)。

最終奏效的方案是：把我想讓 Claude 執(zhí)行的任務(wù)指令復(fù)制到剪貼板，然后修改上面的自動(dòng)回車腳本，讓它在按回車鍵之后，再自動(dòng)執(zhí)行cmd+v粘貼操作。這樣一來(lái)，如果 Claude 彈出問(wèn)題，回車鍵會(huì)自動(dòng)確認(rèn)；如果它沒(méi)彈出問(wèn)題，剪貼板里的指令就會(huì)被自動(dòng)輸入，確保任務(wù)能持續(xù)推進(jìn)。

（5）如果程序自動(dòng)更新，那就搶占焦點(diǎn)

電腦上的一些程序（比如軟件更新器）會(huì)突然彈出窗口，搶走終端的焦點(diǎn)。旦出現(xiàn)這種情況，cmd+v和回車鍵的指令就不會(huì)再發(fā)送到終端，整個(gè)自動(dòng)化流程就會(huì)卡住。

為此，我翻出了當(dāng)年玩《我的世界》時(shí)用過(guò)的 MurGaa 自動(dòng)點(diǎn)擊器，設(shè)置成每隔幾秒就模擬一次鼠標(biāo)左鍵點(diǎn)擊。我把終端窗口和鼠標(biāo)光標(biāo)都放在屏幕邊緣，這樣當(dāng)中間彈出更新窗口時(shí)，自動(dòng)點(diǎn)擊就能重新讓終端獲得焦點(diǎn)。

除此之外，這個(gè)自動(dòng)點(diǎn)擊器還能防止電腦休眠，這樣即使我晚上睡覺，任務(wù)也能持續(xù)運(yùn)行。

（6）避不開的各種小Bug

長(zhǎng)時(shí)間運(yùn)行自動(dòng)化任務(wù)，穩(wěn)定性是重中之重。整體來(lái)看，這次遷移過(guò)程還算順利，但有幾個(gè)特定的 Bug 會(huì)在夜間運(yùn)行時(shí)出現(xiàn)，導(dǎo)致程序中斷。我已經(jīng)反饋了這些問(wèn)題，希望官方能盡快找到根源并修復(fù)——畢竟遇到這些問(wèn)題的人不止我一個(gè)！

這套自動(dòng)化方案雖然不算最優(yōu)解，但至少能正常工作，希望未來(lái)這類工具的流程能更順暢一些！

開始，寶可夢(mèng)代碼遷移！

（1）一開始的“One Shot”嘗試，失敗得很徹底

項(xiàng)目剛開始的時(shí)候，我天真地給了 Claude 一個(gè)大 Prompt：“請(qǐng)你把整個(gè)代碼庫(kù)從 JavaScript 逐行遷移到 Rust?！币婚_始效果看起來(lái)驚艷極了：它生成了幾千行能直接編譯通過(guò)的 Rust 代碼。

但好景不長(zhǎng)，我很快發(fā)現(xiàn)這些代碼只是“表面工程”——Claude 為了省事，耍了很多小聰明。

比如，它在兩個(gè)不同的文件里，為“寶可夢(mèng)招式”定義了兩種完全不同的數(shù)據(jù)結(jié)構(gòu)，雖然單獨(dú)編譯這兩個(gè)文件都能通過(guò)，但整合到一起就徹底沒(méi)法用了。而且它對(duì)函數(shù)的遷移非常敷衍，只要是稍微復(fù)雜一點(diǎn)的邏輯，都不會(huì)真正遷移，而是用“簡(jiǎn)化版”代碼糊弄過(guò)去。

當(dāng)時(shí)我還沒(méi)意識(shí)到問(wèn)題的嚴(yán)重性，一心想著讓自動(dòng)化循環(huán)跑起來(lái)，遷移更多的代碼。結(jié)果就是：整個(gè)代碼庫(kù)里到處都是錯(cuò)誤的抽象設(shè)計(jì)，而且 Claude 還會(huì)不斷添加硬編碼邏輯，去“修復(fù)”那些本不該出現(xiàn)的問(wèn)題——照這個(gè)趨勢(shì)下去，項(xiàng)目遲早要爛尾。

（2）正確方法：先給 Claude “畫好路”

吃了虧之后我才明白：必須給 Claude 制定明確的規(guī)則，才能讓遷移工作走上正軌。

冷靜下來(lái)思考后，我確定了核心目標(biāo)：JavaScript 代碼庫(kù)里的每一個(gè)文件、每一個(gè)方法，都必須在 Rust 代碼庫(kù)里有一一對(duì)應(yīng)的實(shí)現(xiàn)。

于是我讓 Claude 寫了一個(gè)腳本，這個(gè)腳本會(huì)遍歷 JavaScript 代碼庫(kù)的所有文件和方法，然后在 Rust 代碼對(duì)應(yīng)的位置，添加包含 JavaScript 源代碼的注釋。這個(gè)腳本的作用至關(guān)重要：因?yàn)榫退阄曳磸?fù)強(qiáng)調(diào)要復(fù)制源代碼，Claude 還是會(huì)把 JavaScript 代碼翻譯得 “面目全非”。

有了這個(gè)確定性的腳本，就能大大提高遷移結(jié)果的準(zhǔn)確性。

（3）拆分代碼，解決上下文窗口限制問(wèn)題

新的挑戰(zhàn)很快出現(xiàn)：原始的 JavaScript 文件動(dòng)輒幾千行，加上源代碼注釋之后，Rust 文件的行數(shù)直接突破 1 萬(wàn)行。這直接觸發(fā)了 Claude 的上下文窗口限制，它甚至?xí)苯泳芙^打開這些超大文件。

無(wú)奈之下，Claude 只能把文件拆分成小塊來(lái)處理，但這樣做的精準(zhǔn)度會(huì)大打折扣。更糟的是，上下文的膨脹會(huì)導(dǎo)致 Claude 頻繁進(jìn)行內(nèi)容壓縮，進(jìn)一步影響遷移質(zhì)量。

為了徹底解決這個(gè)問(wèn)題，我決定在 Rust 代碼庫(kù)里，把每一個(gè)方法都拆分成單獨(dú)的文件。這個(gè)改動(dòng)立竿見影，遷移的效果得到了質(zhì)的提升。其實(shí)從效率最大化的角度出發(fā)，我應(yīng)該把 JavaScript 代碼庫(kù)也做同樣的拆分，但我擔(dān)心這樣會(huì)意外改變?cè)a的邏輯，所以最終放棄了這個(gè)想法。

（4）遷移與清理的循環(huán)迭代

整個(gè)遷移過(guò)程，就是在“批量遷移”和“代碼清理”兩個(gè)階段之間反復(fù)循環(huán)。我會(huì)先給 Claude 分配一個(gè)大任務(wù)，讓自動(dòng)化循環(huán)跑一整天；然后我再花時(shí)間，清理那些 Claude 跑偏的地方。

在代碼清理階段，我還是會(huì)用 Claude，但會(huì)給它更具體的指令。比如，我發(fā)現(xiàn)如果不加約束，Claude 會(huì)把寶可夢(mèng)招式、特性、道具的邏輯硬編碼到代碼的各個(gè)角落。于是我會(huì)先手動(dòng)找出這些硬編碼的部分，再讓 Claude 把它們遷移到正確的位置。

這就是工程師經(jīng)驗(yàn)派上用場(chǎng)的地方了——我多年的軟件開發(fā)經(jīng)驗(yàn)，能幫我快速定位問(wèn)題所在，以及解決問(wèn)題的方向。好在我不需要自己動(dòng)手清理代碼，只要指令給得明確，Claude 就能把這些活兒干得漂漂亮亮。

代碼整合與測(cè)試

（1）先完成全量構(gòu)建，再進(jìn)行測(cè)試

在很長(zhǎng)的一段時(shí)間里，我只確保生成的 Rust 代碼能編譯通過(guò)，卻從來(lái)沒(méi)有把所有模塊整合到一起，驗(yàn)證它們是否真的能正常工作。

Claude 其實(shí)更傾向于傳統(tǒng)的軟件開發(fā)策略：先實(shí)現(xiàn)所有模塊的簡(jiǎn)單版本，然后再逐步迭代完善。但這個(gè)思路并不適合我們的場(chǎng)景——畢竟 Pokemon Showdown 這個(gè)項(xiàng)目已經(jīng)迭代了 10 年，我們沒(méi)必要再重走一遍前人的彎路，而且這種方式也很難保證最終的邏輯和原項(xiàng)目一致。

對(duì)我們來(lái)說(shuō)，更高效的策略是：先完成全量代碼的遷移，等到所有模塊都就位之后，再進(jìn)行一次性整合。

這個(gè)策略是我從之前參與的 Skip 編譯器項(xiàng)目中學(xué)到的——那個(gè)項(xiàng)目花了好幾年時(shí)間，單獨(dú)構(gòu)建了所有的基礎(chǔ)模塊，一直都沒(méi)有實(shí)際可用的成果；但在最后一個(gè)月里，當(dāng)所有模塊整合到一起時(shí)，整個(gè)編譯器突然就正常工作了，當(dāng)時(shí)給我的震撼至今記憶猶新。

（2）端到端測(cè)試驗(yàn)證一致性

當(dāng)大部分代碼都完成一對(duì)一遷移后，我終于開始了整合工作。

幸運(yùn)的是，JavaScript 和 Rust 兩個(gè)版本的代碼，都可以獨(dú)立運(yùn)行和調(diào)試，而且它們的輸入輸出格式非常簡(jiǎn)單、標(biāo)準(zhǔn)化：輸入是寶可夢(mèng)的列表（包含招式、道具、性格、個(gè)體值 / 努力值等配置），輸出是每一步對(duì)戰(zhàn)的行動(dòng)指令（招式選擇和寶可夢(mèng)切換）。只要給定相同的隨機(jī)數(shù)種子，兩個(gè)版本的代碼就應(yīng)該產(chǎn)生完全相同的對(duì)戰(zhàn)過(guò)程。

我讓 Claude 生成了對(duì)應(yīng)的測(cè)試框架，然后就開始逐個(gè)解決測(cè)試中發(fā)現(xiàn)的問(wèn)題——讓人驚喜的是，Claude 不僅能定位所有 Bug，還能自己動(dòng)手修復(fù)它們。

在三周的時(shí)間里，Claude 平均每 20 分鐘就能修復(fù)一個(gè) Bug，靠自己解決了幾百個(gè) Bug。整個(gè)過(guò)程我完全沒(méi)有干預(yù)，只要給它足夠的時(shí)間，它就能搞定遇到的所有問(wèn)題。

（3）優(yōu)化測(cè)試流程，提升調(diào)試效率

項(xiàng)目初期，整個(gè)測(cè)試流程的效率低得讓人頭疼。每次 Claude 進(jìn)行上下文壓縮后，就像“失憶”了一樣，會(huì)重復(fù)造輪子，生成大量沒(méi)用的 Markdown 文檔和測(cè)試腳本。有時(shí)候它還會(huì)偷懶，只生成一堆測(cè)試用例，卻根本不保證這些用例和 JavaScript 版本的邏輯一致。

于是我開始觀察 Claude 擅長(zhǎng)做什么，然后把這些流程固化下來(lái)。

比如，它會(huì)在隨機(jī)數(shù)生成器（PRNG）相關(guān)的代碼里，添加大量調(diào)試邏輯，記錄每一步的操作和詳細(xì)的調(diào)試元數(shù)據(jù)。我就順著這個(gè)思路，讓 Claude 寫一個(gè)統(tǒng)一的測(cè)試腳本，專門用來(lái)打印單步對(duì)戰(zhàn)的調(diào)試信息和堆棧跟蹤。然后把這個(gè)腳本的使用方法，寫到 Claude.md 文件里。這樣一來(lái)，每次調(diào)試都能直接上手，效率大大提升。

（4）漫長(zhǎng)但有效的攻堅(jiān)階段

我利用原項(xiàng)目的隨機(jī)數(shù)生成器，通過(guò)設(shè)置不同的種子值，來(lái)生成可復(fù)現(xiàn)的對(duì)戰(zhàn)場(chǎng)景。我還會(huì)逐步增加對(duì)戰(zhàn)測(cè)試的數(shù)量，循序漸進(jìn)地推進(jìn)。

我先是搞定了前 100 場(chǎng)對(duì)戰(zhàn)的問(wèn)題，然后是 1000 場(chǎng)、1 萬(wàn)場(chǎng)、10 萬(wàn)場(chǎng)，現(xiàn)在我已經(jīng)快要解決前 240 萬(wàn)場(chǎng)對(duì)戰(zhàn)的所有問(wèn)題了！雖然不知道還有多少潛在問(wèn)題，但可以肯定的是，隨著測(cè)試批量的增大，新出現(xiàn)的問(wèn)題會(huì)越來(lái)越小，也越來(lái)越容易解決。

（5）遷移過(guò)程中遇到的兩類典型問(wèn)題

整個(gè)遷移過(guò)程中，Claude 修復(fù)的問(wèn)題可以分為兩大類。

第一類是我早就預(yù)料到的，由 Rust 和 JavaScript 語(yǔ)言特性差異導(dǎo)致的問(wèn)題：

• Rust 的借用檢查器限制：Rust 的借用檢查器不允許一個(gè)可變變量同時(shí)被多個(gè)上下文引用。而在我們的代碼里，“寶可夢(mèng)”和“對(duì)戰(zhàn)”這兩個(gè)對(duì)象會(huì)互相引用。為了解決這個(gè)問(wèn)題，我用了很多變通方案，比如數(shù)據(jù)拷貝、用索引代替對(duì)象引用、通過(guò)回調(diào)函數(shù)傳遞可變對(duì)象等。
  

• JavaScript 的動(dòng)態(tài)類型 vs Rust 的靜態(tài)類型：JavaScript 代碼大量使用動(dòng)態(tài)類型特性，一個(gè)函數(shù)的返回值可能是字符串、undefined、null、數(shù)字，甚至是“寶可夢(mèng)”對(duì)象，而且每種類型都會(huì)有不同的處理邏輯。一開始，Rust 版本用Option 來(lái)處理這些情況，但后來(lái)改成了用自定義結(jié)構(gòu)體來(lái)封裝所有可能的類型變體。
  

• 可選參數(shù)的差異：Rust 不支持可選參數(shù)，所以調(diào)用函數(shù)時(shí)，必須顯式傳入每一個(gè)參數(shù)。

而第二類問(wèn)題，就完全是 Claude 自己“作”出來(lái)的了。Claude Code 就像一個(gè)聰明但愛偷懶的學(xué)生——只要它覺得能蒙混過(guò)關(guān)，就會(huì)想盡辦法逃避那些復(fù)雜的工作：

• 逃避復(fù)雜的基礎(chǔ)設(shè)施改造：如果一個(gè) bug 的修復(fù)需要修改多個(gè)文件，涉及到 “重大基礎(chǔ)設(shè)施調(diào)整”，Claude 就會(huì)直接躺平，除非你給它極其明確的指令。大多數(shù)時(shí)候，它會(huì)用各種投機(jī)取巧的 hack 方法，只保證當(dāng)前測(cè)試用例能通過(guò)。
  

• 喜歡生成“簡(jiǎn)化版”實(shí)現(xiàn)：對(duì)于一些復(fù)雜的方法，與其在 Claude 生成的錯(cuò)誤代碼上修修補(bǔ)補(bǔ)，不如直接刪掉重寫，讓它從頭開始遷移反而更快。
  

• 擅自修改原始代碼邏輯：明明 JavaScript 的注釋才是遷移的唯一依據(jù)，但 Claude 有時(shí)候會(huì)覺得自己的方案更“好”，就擅自篡改原始邏輯。
  

• 挑肥揀瘦、逃避困難任務(wù)：如果給 Claude 一個(gè)任務(wù)列表，它會(huì)先挑簡(jiǎn)單的做，把難的任務(wù)全都放到最后。如果不加以約束，這個(gè)習(xí)慣會(huì)導(dǎo)致大量時(shí)間被浪費(fèi)在無(wú)意義的調(diào)試上，而且上下文壓縮會(huì)讓它徹底忘記那些沒(méi)完成的困難任務(wù)。

關(guān)鍵提示詞分享

在整個(gè)項(xiàng)目中，我自己一行代碼都沒(méi)寫。工作模式基本就是“白天協(xié)作”+“夜間批量任務(wù)”：白天和 Claude 交互式地解決問(wèn)題，晚上就給它分配批量任務(wù)，讓它通宵運(yùn)行。

這里主要分享一下我用的夜間批量任務(wù)提示詞。

（1）代碼遷移階段提示詞

1.打開BATTLE_TODO.md文件，獲取battle*.rs文件中所有待實(shí)現(xiàn)的方法列表。

2.逐個(gè)檢查每一個(gè)方法，確保它們都是對(duì)JavaScript文件的直接翻譯。如果存在同名方法，對(duì)應(yīng)的JavaScript源代碼會(huì)寫在注釋里。

3.如果某個(gè) Rust 方法沒(méi)有對(duì)應(yīng)的 JavaScript 注釋，請(qǐng)先確認(rèn)這個(gè)方法是否應(yīng)該存在。我們的目標(biāo)是盡可能嚴(yán)格地和 JavaScript 版本保持一致，避免因翻譯偏差引入 Bug。如果發(fā)現(xiàn)實(shí)現(xiàn)邏輯不匹配，請(qǐng)進(jìn)行必要的重構(gòu)，確保兩者完全一致。

4.這是一個(gè)復(fù)雜的項(xiàng)目，你需要按順序處理每一個(gè)方法，絕對(duì)不能因?yàn)槟硞€(gè)方法難度大，或者需要搭建新的基礎(chǔ)設(shè)施就跳過(guò)它。我們會(huì)循環(huán)執(zhí)行這個(gè)提示詞，所以你可以放心花時(shí)間搭建正確的基礎(chǔ)設(shè)施，確保和 JavaScript 版本一對(duì)一匹配。不許放棄！

5.每完成一個(gè)單元的工作，更新 BATTLE_TODO.md 文件，并執(zhí)行 git commit 提交代碼。

（2）TODO 清理階段提示詞

Claude 在逐個(gè)遷移方法時(shí)，經(jīng)常會(huì)生成“簡(jiǎn)化版”代碼，或者留下大量TODO注釋，等著以后再完善。我發(fā)現(xiàn)，把任務(wù)指令直接以TODO注釋的形式寫在代碼里，比放在上下文里更有效——這樣就不用擔(dān)心 Claude 會(huì)忘記這些任務(wù)。

那個(gè)主 Markdown 文件后來(lái)也失效了，因?yàn)樗兊锰?，根本沒(méi)法用，而且 Claude 還會(huì)在代碼庫(kù)里到處生成新的 Markdown 文件。后來(lái)我改用grep命令，讓 Claude 從代碼庫(kù)里自動(dòng)檢索所有 TODO 注釋，這樣它就能明確知道還有哪些任務(wù)沒(méi)完成。

1. 我們要修復(fù)代碼庫(kù)里（pokemon-showdown-rs/目錄下）的所有TODO注釋。

2. 這些TODO有成百上千個(gè)，請(qǐng)你認(rèn)真地逐個(gè)處理，**即使任務(wù)很難也不許跳過(guò)**。我會(huì)反復(fù)執(zhí)行這個(gè)提示詞，所以你不用擔(dān)心在單個(gè)任務(wù)上花太多時(shí)間。

3. 代碼遷移必須嚴(yán)格保持一對(duì)一的邏輯一致。如果需要的基礎(chǔ)設(shè)施不存在，請(qǐng)你自己實(shí)現(xiàn)，**不許憑空發(fā)明任何邏輯**。

4. 每完成一個(gè)TODO的修復(fù)，確保代碼能正常編譯，然后執(zhí)行g(shù)it commit和git push提交代碼。

有個(gè)小插曲：有一次，原始 JavaScript 代碼庫(kù)里的某個(gè)注釋里就包含 TODO，Claude 把這個(gè) TODO 改成了別的內(nèi)容，改完之后邏輯是通順的。但問(wèn)題是，它把這個(gè)操作當(dāng)成了“正確示范”，之后遇到所有的 TODO 都照葫蘆畫瓢，導(dǎo)致大量邏輯出錯(cuò)——好在我通過(guò) git revert 回滾了這些錯(cuò)誤的提交，才沒(méi)造成太大的麻煩。

（3）Bug 修復(fù)階段提示詞

我把所有的調(diào)試指令都寫進(jìn)了 Claude.md 文件，還寫了一個(gè)批量運(yùn)行測(cè)試的腳本，測(cè)試結(jié)果會(huì)輸出到一個(gè) txt 文件里。這樣一來(lái)，Claude 就能自己讀取測(cè)試報(bào)告，然后逐個(gè)修復(fù)問(wèn)題，完全不需要人工介入。

1. 我們要修復(fù)對(duì)戰(zhàn)測(cè)試中出現(xiàn)的所有邏輯不一致問(wèn)題。請(qǐng)查看500-seeds-results.txt文件，逐個(gè)解決里面記錄的問(wèn)題。

2. 修復(fù)的唯一準(zhǔn)則是：確保JavaScript和Rust版本的差異，**只能是由語(yǔ)言特性不同導(dǎo)致的，而不能是邏輯上的差異**。兩行代碼的執(zhí)行結(jié)果必須完全一致。

3. 如果你修復(fù)了某個(gè)具體問(wèn)題，請(qǐng)思考這是不是一個(gè)共性問(wèn)題?；〞r(shí)間排查代碼庫(kù)里是否存在類似的錯(cuò)誤，然后進(jìn)行全局的基礎(chǔ)設(shè)施級(jí)別的修復(fù)，而不是只修這一個(gè)案例。

4. 每完成一個(gè)修復(fù)，確保代碼能正常編譯，然后執(zhí)行g(shù)it commit和git push提交代碼。

把這個(gè)測(cè)試結(jié)果 txt 文件提交到 GitHub 上也很有用——我可以隨時(shí)隨地查看項(xiàng)目進(jìn)展！

最終成果：真的跑起來(lái)了！

說(shuō)實(shí)話，項(xiàng)目開始的時(shí)候，我心里完全沒(méi)底。畢竟類似的代碼遷移項(xiàng)目，往往會(huì)因?yàn)楣ぷ髁窟^(guò)于龐大而半途而廢——但這次不一樣！

我們最終得到了一個(gè)完整的寶可夢(mèng)對(duì)戰(zhàn)系統(tǒng) Rust 實(shí)現(xiàn)，而且它的運(yùn)行結(jié)果和 JavaScript 原版幾乎完全一致。整個(gè)項(xiàng)目耗時(shí) 4 周，提交了 5000 次代碼，最終生成的 Rust 代碼庫(kù)大約有 10 萬(wàn)行。

但也有點(diǎn)小遺憾：目前還做不到 100% 的邏輯一致——在前 240 萬(wàn)場(chǎng)對(duì)戰(zhàn)測(cè)試中，還有 80 場(chǎng)存在差異，誤差率約為 0.003%。我還需要讓測(cè)試?yán)^續(xù)運(yùn)行更長(zhǎng)時(shí)間，來(lái)解決這些小問(wèn)題。

不過(guò)，現(xiàn)在可以來(lái)場(chǎng)性能對(duì)比了——Rust 版本真的更快嗎？畢竟，我把代碼遷移到 Rust 的核心目的，就是為了提升運(yùn)行速度。所以當(dāng)大部分對(duì)戰(zhàn)測(cè)試都能穩(wěn)定通過(guò)之后，我覺得是時(shí)候做一個(gè)公平的性能對(duì)比了。

我讓 Claude 給兩個(gè)版本的代碼都做了并行化優(yōu)化，測(cè)試結(jié)果讓我松了一口氣：Rust 版本的速度確實(shí)遠(yuǎn)超 JavaScript 版本，看來(lái)我這一個(gè)月的時(shí)間沒(méi)有白費(fèi)！

我還讓 Claude 嘗試進(jìn)一步優(yōu)化 Rust 代碼的性能，它給出的優(yōu)化方案看起來(lái)很合理（畢竟我之前從來(lái)沒(méi)寫過(guò)一行 Rust 代碼）。之后它花了一整天的時(shí)間，實(shí)現(xiàn)了其中的大部分優(yōu)化——但尷尬的是，這些優(yōu)化最終不僅沒(méi)有提升運(yùn)行速度，反而讓性能變得更差了。

現(xiàn)在回頭看，這件事其實(shí)真的很瘋狂：我一個(gè)從來(lái)沒(méi)寫過(guò) Rust 代碼的人，靠著 Claude Code 全天候運(yùn)行一個(gè)月，提交了 5000 次代碼，居然在兩周的實(shí)際參與時(shí)間里，完成了 10 萬(wàn)行代碼從 JavaScript 到 Rust 的遷移！

基于大語(yǔ)言模型的代碼助手，已經(jīng)成為工程師手中的超強(qiáng)工具——沒(méi)有 Claude Code 的話，我根本不可能完成這個(gè)項(xiàng)目。但同時(shí)也要明確：它只是一個(gè)工具，要想產(chǎn)出高質(zhì)量的成果，還是需要工程師的專業(yè)知識(shí)，以及持續(xù)的監(jiān)督和引導(dǎo)。

未來(lái)沒(méi)有前后端，只有 AI Agent 工程師。

這場(chǎng)十倍速的變革已至，你的下一步在哪？

4 月 24-25 日，由 CSDN 與奇點(diǎn)智能研究院聯(lián)合主辦「2026 奇點(diǎn)智能技術(shù)大會(huì)」將在上海隆重召開，大會(huì)聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來(lái)的認(rèn)知地圖。

成為時(shí)代的見證者，更要成為時(shí)代的先行者。

奇點(diǎn)智能技術(shù)大會(huì)上海站，我們不見不散！