好的，以下是翻譯後的繁體中文版本：
好的限制塑造了軟體最輝煌的時代，也塑造了我的職業生涯。一些有主見的作法，例如 12-Factor App 原則或 MVC，為我們提供了共同的語言，用來建構可靠的服務以及設計關注點分離。這些都是簡單的規則，容易陳述，卻難以完美遵循。它們孕育了整個產業：SaaS、PaaS、雲端基礎設施。這一切都建立在深思熟慮的限制之上，這些限制告訴建構者：這裡是邊界，待在這個邊界範圍內，好事就會發生。我個人在一些最傑出的作品中，也因應用這些限制而受益匪淺。
我相信 AI 原生軟體需要它自己的限制。以下是我想到的。
你的程式碼庫有一個最大體積。這不是品味問題。這個限制是真實的、可衡量的，而且比你以為的還要小。
這個限制是：你的 Agent 用來建構和維護產品所使用的 AI 模型的上下文窗口的一半。這意味著，你的核心業務邏輯和系統上下文的大小，不應超過你所依賴的 LLM 上下文窗口的一半。
為什麼是一半？上下文窗口有兩個用途。前半部分容納你的程式碼。後半部分是 Agent 進行推理、規劃和生成的地方。把整個窗口都塞滿程式碼，你就沒有留下任何思考的空間。一半用於理解。一半用於認知。
軟體業務最困難的部分從來都不是建構功能。
每位有經驗的技術創始人都知道這一點。困難的部分是為足夠大的客戶群體找出最小實用的軟體，然後凝聚眾人，共同完成客戶獲取、客戶服務和留存這項艱鉅的工作。
過去，建構軟體的成本很高。工程師的薪資昂貴。這造成了摩擦，催生了迭代開發流程，但也帶來了紀律。你必須做出選擇：客戶最需要什麼？什麼是值得建構的最小功能？工程的人力成本讓團隊保持專注。限制創造了清晰度。矽谷最優秀的公司就是這樣成長起來的。
現在，AI Agent 幾乎可以建構你要求的任何東西。瓶頸消失了。紀律也隨之消失。
免費的生產導致了過度生產。過度生產是 AI 原生公司的預設失敗模式。
非技術背景的創始人和投資者需要理解這一點。更多的功能、更多的程式碼、以及更多的產品維護面積，不再是進步的跡象。它們標誌著一家公司缺乏高品質的限制，有時甚至代表著根本性的缺乏清晰度。
沒有可擴展的分發和消費的過度生產，會在價值獲取上造成巨大的洩漏。你推出了十個功能。其中兩個驅動了留存。另外八個增加了複雜性，拖慢了那兩個關鍵功能的腳步。每一行程式碼都變成了偽裝成資產的負債。
有經驗的建構者知道那個臨界點。程式碼從服務客戶轉變為服務自身。複雜性成為產品的敵人。團隊花更多時間管理軟體，而不是改善客戶體驗。系統開始感覺笨重，用戶開始流失，你的客戶面向團隊默默地感到沮喪。
在舊世界，你需要數年時間才能達到那個臨界點。在 AI 原生世界，你幾週內就會達到臨界點。Agent 從不感到疲倦，從不提出反對，也從不說「這太複雜了，我們應該停下來」。
你怎麼知道何時該停下來？當 AI 可以免費編寫無限的程式碼時，什麼信號能告訴你「夠了」？
那就是「半窗口法則」。
你的核心業務邏輯必須能容納在維護你程式碼庫的模型之上下文窗口的一半之內。以 token 來衡量你的程式碼庫。將它與一半的上下文窗口進行比較。如果超過了，你的 AI 勞動力就已經在退化——不是肉眼可見的，不是劇烈的，而是悄無聲息且持續不斷的。
危險在於：當你越過這條線時，沒有什麼東西會明顯地出錯。Agent 不會拒絕。程式碼看起來正確。測試通過。你回報的錯誤也被修復了。
但是，Agent 現在是在沒有完全理解你的系統的情況下運作。Agent 根據片段進行模式匹配，而不是對整體進行推理。微妙的迴歸問題會出現。邏輯在 Agent 無法看到的程式碼庫部分被重複。問題透過添加程式碼來「解決」，而本應修改現有程式碼。
你不會立即注意到。速度感仍然很高。拉取請求仍然在流動。但每一個都讓下一個稍微變得更糟。複合式退化對你不利。
當你問「為什麼我們的 Agent 一直在繞圈子？」的時候，你已經深陷問題之中了。
這條規則是披著技術外衣的商業紀律。
當生產成本趨近於零時，簡潔性就成為你的競爭優勢。建構能為客戶提供真實價值的最小程式碼庫。每一個不必要的功能、每一個不需要的抽象、每一行投機性的程式碼，都在消耗你 AI 勞動力的認知預算。最終，它們會吞噬你公司的行動能力。
最優秀的產品始終是那些能完全解決真正問題的最簡單的產品。違反這個原則的代價，現在來得更快，並且複合加劇。你的 AI Agent 不會像一位沮喪的高級工程師那樣提出反對。
這個規則會隨著架構而擴展。單一產品的新創公司：適用於整個程式碼庫。多服務的公司：分別適用於每個服務。你的系統中任何必須被整體理解的部份，都必須能容納在你的 Agent 能夠推理全貌的邊界之內。
無論你是否為此做了規劃，你的產品架構都將反映你 Agent 的認知邊界。那些刻意為此進行設計的創始人，將會超越那些透過痛苦來學習的人。
這不是關於完美。你不會總是保持在線以下。程式碼庫會增長。功能會增加。複雜性會累積。重點在於志向，而不是僵化的遵守。如果你記住這個規則並靠近邊界，你將能更好地決定要建構什麼、拆分什麼、以及刪除什麼。當其他一切都說「建構更多」時，這個限制為你提供了一個參考點。有時候，這意味著重新設計你的子 Agent 架構以符合這個規則——這與人類團隊在成長時劃分擁有權的方式非常相似。
我期望在自己的工作中遵循這個規則。不是因為違反規則意味著立即失敗，而是因為靠近這個限制能幫助我建構出隨著時間推移仍然保持有用、可維護且有價值的軟體。圍繞這個原則的創始人會走得更遠。那些完全無視限制的創始人則會透過痛苦來學習。
好的限制不能保證成功。它們透過移除最常見的失敗方式來增加成功的可能性。12-Factor App 是一組原則，它不會為你建構 SaaS 公司，但如果你遵循它們，你的基礎設施在你需要擴展時就能正常運作。「半窗口法則」的運作方式完全相同。遵循其精神。靠近邊界。建構能持久的有用軟體業務。
簡潔性總是勝利。現在，簡潔性勝利得更快。
關於作者：Abhishek Parolkar 是 https://brain.pe 的 CEO，該公司幫助私募股權公司為其自身公司或特定交易建立數位 AI 大腦。你可能已經採用了 AI，但 AI 是否已經採納了你？
