Cisco AI 程式碼重寫：以無限 token 支撐 98% 目標
據報，Cisco 向一名 27 歲工程師提供無限 AI token，讓他在 24 個月內嘗試重寫公司 98% 的舊有程式碼。這項 Cisco AI 程式碼重寫計劃，將異常廣泛的目標交予一支規模很小的擬議團隊。其意義取決於 Cisco 打算改動甚麼，以及將如何證明改動確實有效。
根據 Tom’s Hardware 轉述 Fortune 的報道，總裁兼首席產品官 Jeetu Patel 在三藩市一次交談後，支持前創辦人 Padmanabhan Krishnamurthy。據報，這項任務包括首四星期的概念驗證期。這些細節描述的是一項實驗及抱負，而非經獨立核實的現代化成果。
核心張力在於不受限制的程式碼生成，與可問責的軟件交付之間的取捨。Amazon 已描述過 AI 輔助應用程式升級，提供了有用的比較。Cisco 據報的雄心引出一個更廣泛問題：當產生改動變得更容易時，一個小型工程團隊能承擔多少組織責任？
Cisco AI 程式碼重寫由目標開始，而非已完成的遷移
據報的任務顯示獲管理層支持；並不代表 Cisco 已完成軟件現代化。
Tom’s Hardware 對這項舊有程式碼任務的報道指出，綽號 Paddy 的 Krishnamurthy 是這項提案背後的工程師。據報，他提出由兩人組成的團隊。Patel 提供支持，包括不受限制的 token；token 是 AI 模型接收指令及生成回應時處理的文字單位。
報道稱，Krishnamurthy 早前的職級比 Patel 低五個組織層級。報道將此項目定位為責任分配的改變，而不只是工具的改變。一名前創辦人將獲得空間，挑戰既有工程假設。
這項關係背後有可獨立核實的收購紀錄。Cisco 的 EzDubs 收購公告表示，交易已於 2025 年 11 月 25 日完成。Cisco 形容 EzDubs 為專注即時語音翻譯的 AI 軟件公司，並稱收購理由包括擴展協作工程人才。
這段歷史支持被收購的初創公司加入 Cisco 的說法，但未能獨立驗證重寫提案或其可行性。收購公告談及協作能力，而非公開發布將 Cisco 舊有軟件轉型的計劃。
據報任務的措辭亦須審慎理解。重構是指在保留軟件可由外部觀察到的行為下，改變其內部結構。重寫則可涉及替換實作方式，並可能引入不同的設計選擇及相容性風險。
這些術語可以形容重疊的工作，但不能互換作為進度指標。自動化的內部整理，與替換客戶依賴的元件有重大分別。現代化計劃需要識別每項改動屬於哪一類。
公開報道未有提供支撐 98% 數字的詳細清單，也沒有說明「完成」是指已生成改動、已接受改動、已部署至生產環境，還是已淘汰舊實作。在缺乏這些定義下，這個百分比表達抱負的程度，較其營運範圍更清楚。
同樣的審慎態度亦適用於時間表。於 2026 年 10 月 30 日發表的報道，並不代表項目時鐘就在當天開始。讀者不應單憑發表日期推算確切完成日期。
因此，有用的起點相當有限。據報，Cisco 總裁已授權一項具明確標題目標的進取工程實驗。該實驗能否成為可重複採用的現代化計劃，仍是另一個問題。
無限 token 將壓力轉向審查及責任歸屬
移除生成限制只會改變工程工作累積的位置；並不會免除接受改動所需的工作。
無限 AI token 聽起來像無限工程能力，因為可見的產出是程式碼。然而，生成的修補程式，即對原始碼檔案的擬議改動，仍需要有其存在理由。必須有人確認它改變了甚麼、為何安全，以及由誰負責維護。
假設要將一個共用身份驗證元件現代化。AI 工具或會建議更清晰的程式碼、較新的相依套件及額外測試。然而，該提案仍須根據既有權限規則及受支援的客戶配置作出評估。
這個例子僅作說明，並非描述 Cisco 的項目。它顯示，生成看似合理的軟件，與為已部署行為承擔責任，是兩種不同活動。更快的起草速度，可能暴露審查人手不足，而非消除程式設計師不足的問題。
工程經理面對即時壓力。若擬議改動抵達的速度快於團隊評估速度，審查佇列便會增長。經理其後必須決定收窄工作範圍、增加審查能力，或改變每項提案所附證據的方式。
安全專家面對相關問題。他們需要了解流程是否保留存取邊界，以及有否恰當處理敏感資訊。一個看似更整潔的修補程式，仍可能改變以往透過間接方式執行的假設。
產品負責人必須區分內部改善與影響客戶的改動。替換一項相依套件，即外部軟件元件，可能引入 AI 工具直接編輯的檔案以外的行為。因此，是否接受改動取決於周邊系統，而非僅是替代方案是否吸引。
管理層支持相當重要，因為這些責任跨越匯報線。一支小型中央團隊可以制定方法，但受影響團隊仍需要機制批准改動。權限不清，會令每次成功示範都變成「誰承擔後果」的協商。
這正是 Cisco AI 程式碼重寫抱負的組織意義。這項實驗測試一支小型團隊能否建立其他團隊信任的流程。其產出需要包括可重現的證據、易於理解的改動邊界，以及清晰的故障處理途徑。
既有維護人員仍是流程核心。他們往往知道某個笨拙實作為何存在，或哪項客戶需求解釋了不尋常的分支。即使這些知識顯示現有實作應予改變，它們仍是有用證據。
文件紀錄成為工程能力問題的一部分。團隊在評估擬議替代方案前，需要取得設計決策、事故歷史及相容性要求。可搜尋的工程知識庫可在編程流程以外，同時處理這個資訊問題。
壓力因而落在實驗雙方。小型團隊必須令其工作可供審查，而既有團隊必須具體說明反對理由。無論是不受限制的生成能力，還是機構經驗，都不會自動提供答案。
Amazon 的應用程式升級提供較狹窄的比較
有明確界限的遷移，比涵蓋未定義軟件資產的百分比提供更清晰證據。
Amazon 為 AI 輔助現代化提供了業界先例。在其 2024 年 12 月的應用程式轉型公告中，公司描述了把內部應用程式升級至 Java 17。Java 是一種用於企業軟件的程式語言及執行環境。
Amazon 表示，該項工作涵蓋數以萬計的生產應用程式，並節省逾 4,500 個開發人員年度的工作量。這些是公司自行報告的結果，而非獨立評估。然而，它們描述的轉型，比泛稱重寫舊有程式碼的承諾更具體。
這種具體性很重要。版本升級提供可識別的起始狀態及目標狀態。審查者可檢驗應用程式能否建置、預期行為是否保持完整，以及新執行環境是否支援其要求。
更廣泛的重寫可結合許多不同目標，例如簡化架構、替換相依套件、改善可維護性，或移除過時功能。即使由相同 AI 工具協助產生改動，每個目標仍需各自的驗收標準。
AWS 的 Java 升級工作流程亦保留明確的人手驗收步驟。其文件描述建置原始程式碼、進行轉型，以及要求開發人員驗證並接受結果。文件亦區分語言相容性改動與額外的相依套件升級。
這項區分有用，因為現代化很少是單一操作。成功的語言升級不代表每個程式庫均為最新版本；建置成功亦不代表每個客戶工作流程都能正確運作。
因此，Amazon 的例子支持一個有限結論：AI 輔助轉型在企業環境中有具體而可描述界限的應用。它不代表 Cisco 據報的目標可實現，也不顯示一支極小的實作團隊能獨立完成所有相關驗收工作。
這亦帶來衡量方面的啟示。估算節省的開發人員時間，取決於假設的替代流程。若同時提供已部署應用程式、已接受改動及持續的營運表現，該估算便更具參考價值。
Cisco 的實驗若有同樣具體的報告，將會受益。對初始工作負載的描述，可揭示團隊是在測試可重複的轉型，還是在探索更廣泛的重新設計。兩者均可有價值，但不確定性不同。
對企業買家而言，這項區分影響如何解讀供應商聲稱。內部示範是某個特定環境中某個特定流程的證據；受支援的客戶功能則需要在維護、文件紀錄及故障處理方面作出額外承諾。
競爭壓力與證據同樣有關，而不只是速度。討論 AI 現代化的公司愈來愈需要說明轉型了甚麼，以及驗收如何進行。戲劇性的標題百分比，提供的資訊少於具清晰界限的結果。
這項比較亦令 Cisco 的故事保持務實。其意義在於測試進取的管理層支持能否擴展 AI 輔助工程的適用範圍。Amazon 的經驗提供背景，但不會預先為這項實驗下定論。
98% 這個數字需要定義，才能成為有用指標
現代化百分比只有在讀者知道哪些工作會計入完成度時，才有意義。
百分比需要有分母，即用作衡量進度的總量。就這項工作而言，該總量可能是原始碼行數、儲存庫、應用程式，或獲選的元件。報道未有說明採用哪一種解讀。
這些選擇可呈現截然不同的進度圖像。重新格式化檔案可以涉及大量原始碼行數，卻未必改變可維護性。替換一個雖小但處於核心位置的元件，則可能需要大規模驗證，即使影響的程式碼相對不多。
完成規則同樣重要。產生建議修改只是中間步驟。將其接受並納入原始碼儲存庫是另一個步驟，而部署及淘汰舊有實作則需要進一步工作。
這並不表示 98% 的目標本身不合理。它表示僅憑公開描述，這個目標難以評估。讀者在將其理解為工程預測前，需要知道範圍及驗收定義。
重構的措辭帶來另一項量度挑戰。保留行為是重構的核心，但現有測試只會檢驗其涵蓋的行為。成功完成測試，不能證明每一種未經測試的情況都保持不變。
這個落差說明審查及營運觀察為何重要。回歸問題，即原有行為出現非預期流失，可能在自動化測試未涵蓋的情境中出現。信心來自綜合各種證據，而非將任何單一檢查視為定論。
研究亦提醒我們，不應把速度感與經量度的生產力混為一談。METR 的開發者生產力實驗研究了 16 名具經驗開發者，在熟悉的開源專案中完成 246 項工作。允許使用 2025 年初期的 AI 工具，反而令完成時間增加 19%。
不過，參與者相信工具幫助他們更快完成工作。這一發現說明，感受到的便利與實際交付速度需要分開評估。它並不預測 Cisco 的結果，也不能證明後來的 AI 工具有相同限制。
METR 後來亦強調這個區別。其 2026 年 2 月的實驗設計更新指出，由於參與情況及工作選擇已有改變，較新量度結果難以詮釋。研究人員認為速度提升屬合理可能，但警告現有證據無法精確確定增幅。
綜合而言，這些發現支持審慎量度，而非對 AI 編程作出一概而論的判斷。工具能力不斷改變，不同工作亦會呈現不同限制。熟悉的開源維護工作所得結果，不能直接套用到大型公司的現代化計劃。
對 Cisco 而言，相關問題是整個流程是否有所改善。如果審查及修正耗用了節省下來的時間，更快產生內容的價值便有限。相反，即使刻意保留大量程式碼不變，只要流程可靠，仍可帶來價值。
因此，可信的評估應區分活動與成果。建議修補顯示活動；獲接受的轉換顯示已通過審查的進度。穩定部署及降低維護負擔，才是工作達成目的的更有力證據。
無限 token 消除了實驗的一項潛在限制，卻無法解決這些量度問題。當 Cisco 說明如何區分令人印象深刻的展示與持續的工程改進時，所報告的目標才會更具資訊價值。
小型團隊仍需要取得機構知識
這項實驗最理想的形式，是將重新設計的自由與理解既有軟件行為原因的能力結合起來。
人手配置的說法容易引出簡單的世代解讀。一位年輕創辦人挑戰大型機構長期接受的假設。這種框架捕捉了報道所述的機會轉變，但無法證明哪些工程判斷正確。
年輕並不必然帶來健全架構，年資亦不必然足以支持保留某項實作。有用的區別在於，建議能否經得起檢驗。小型團隊需要足夠自由去測試想法，也需要足夠背景去解讀結果。
Krishnamurthy 據報的創辦人背景，與這項組織問題有關。創業經驗可以促使人關注整體問題，而非一項被狹隘指派的工作。但這仍不能取代理解受改動影響的系統。
機構知識可以解釋表面上的低效率。某個不尋常的重試順序，可能是為配合特定營運條件。某項看似冗餘的檢查，可能是在保護較舊的整合。這些是假設例子，而非 Cisco 軟件中已確認的功能。
在可行情況下，這類解釋應轉化為可測試的要求。否則，現代化便要依賴找出仍記得舊有決定的人。記錄背後原因，可讓新實作保留必要行為，同時挑戰原有設計。
反向的責任同樣重要。既有團隊應區分已有文件記錄的要求，以及未經檢視卻一直延續的習慣。當反對意見指出故障情況或驗收準則時，才會變得可採取行動。
這正是行政支持能夠幫忙而不能取代工程判斷的地方。管理層可授權存取、解決權責爭議，並保障評估所需時間。但它不能靠熱情確立正確性，也不能令期限取代證據。
因此，小型團隊最有價值的貢獻，可能是可重複使用的流程，而非大量替代程式碼。該流程會將建議轉換連結至相關要求及清晰的批准路徑。其他團隊便可評估相近工作，而毋須重新建立整套程序。
這種可能性改變了我們對建議人手規模的理解。精簡團隊或可發展轉換方法並協調採用，而不是聲稱這些人能獨自承擔所有測試、安全、支援及維護責任。
它亦限制了這個故事對初級職位的啟示。給予一位被收購公司的創辦人特殊責任，並不能證明存在普遍招聘模式。這個個案提供的是特定管理決定的證據，而非勞動市場結果。
對開發者而言，實際啟示涉及生成程式碼以外的工作。當起草工作變得更容易，理解要求、說明取捨及建立證據仍屬必要。當專案嘗試跨越組織邊界作出改動時，這些責任會更為明顯。
對更廣泛的知識工作者而言，對應之處是取得背景資訊。AI 系統可以產生看似合理的答案，卻錯過先前決定之所以重要的原因。有用的自動化需要能夠檢索這些原因，並呈現不確定性。
因此，Cisco 的實驗也是對組織學習的測試。如果小型團隊能將零散知識轉化為可重用的驗收證據，其前景便會改善。若專案只把具經驗的維護人員視為阻礙更快產出的障礙，前景便會削弱。
留意試點證據、生產驗收及維護負擔
下一次有用的更新，應說明哪些內容通過評估、由誰接受，以及之後發生甚麼事。
未來數月，透過具體證據將更容易評估 Cisco 的 AI 程式碼重寫計劃。據報為期四周的驗證期，為讀者提供了短期參考點。然而，報道並未確定其確切開始日期，亦未承諾會公開發布。
第一個訊號是對試點範圍及結果的說明。讀者應留意可識別的工作負載、明確的轉換目標及驗收準則。這些細節可顯示團隊有否測試能代表更廣泛目標的內容。
若成功展示同時呈現成就與限制，便會加強論據。例如，說明哪些改動需要人手修正，有助釐清流程的實際要求。這是證據標準，而非對 Cisco 會披露甚麼的預測。
只展示新生成程式碼的示範，支持力度會較弱。它可證明產出，卻不能說明相容性或驗收情況。這個差異重要，因為長期目標涉及修改既有軟件，而非製作一個獨立範例。
第二個訊號是獲接納進入生產交付流程。讀者應留意是否確認由承擔責任的團隊批准了一項範圍受限的轉換並完成部署。回滾程序，即一種還原至較早版本的既定方法，將進一步說明計劃如何處理失敗。
這個訊號會加強現代化的論據，因為它將實驗與營運責任連結起來。它可顯示受影響團隊能夠評估工作，而非只是欣賞成果。不過，批准仍須按該次部署的範圍作出解讀。
相反，若重複示範卻沒有部署，一個核心問題便仍未解決。流程可能產生有用建議，但難以符合驗收要求。這種結果會識別出交付限制，而非證明每項轉換都毫無價值。
第三個訊號是部署後的維護負擔。讀者應留意後續修正、支援需求，以及能否淘汰舊有實作的證據。這些結果揭示現代化是否減少工作，抑或只是將工作轉移至別處。
一項改動若保持穩定並簡化日後維護，將支持計劃的前提。若改動需要大量持續介入，則會削弱該前提。兩種結論都不應只建基於首次替換出現得有多快。
這些訊號亦為評估 AI 現代化主張的企業買家提供更佳框架。要求供應商區分建議改動與已部署改動，以及已部署改動與持久改善。要求足夠細節，以理解哪些工作負載產生所報告的結果。
對工程主管而言，當前行動是檢視自己機構內一項範圍受限的維護問題。確立既有驗收標準，找出理解其限制的人員，並量度通往部署的完整路徑。將審查及修正工作量與生成速度一併比較。記錄會限制在其他地方重複結果的假設。Cisco 的 AI 程式碼重寫值得關注，因為它測試行政支持及不受限制的實驗能將軟件現代化推進多遠。其最終重要性將取決於最初熱潮過後，甚麼仍然可靠。下一次更新到來時，請提出一個具體問題：哪一項獲接受的改動令軟件更易維護，而有甚麼證據支持這項判斷？
