--- title: "從程式碼生成到意圖收斂：AI 軟體生產、Cost-to-Artifact 與 Make-or-Buy 重構" english_title: "From Code Generation to Intent Convergence: AI Software Production, Cost-to-Artifact, and the Reconstruction of Make-or-Buy" author: "Neo.K with Aletheia" institution: "EveMissLab / 一言諾科技有限公司" series: "AGI 普世化與智能基礎設施經濟學" series_position: "Paper 03 / 06" document_type: "Theoretical Paper / AI Software Economics / Intent Convergence Engineering" version: "v0.1" date: "2026-09-11" status: "Working Paper" canonical_source: "UTF-8 Markdown" canonical_math_delimiters: "inline $...$ ; display $$...$$" --- # 從程式碼生成到意圖收斂：AI 軟體生產、Cost-to-Artifact 與 Make-or-Buy 重構 ## From Code Generation to Intent Convergence: AI Software Production, Cost-to-Artifact, and the Reconstruction of Make-or-Buy **系列：**《AGI 普世化與智能基礎設施經濟學》 **系列位置：** Paper 03 / 06 **版本：** v0.1 **日期：** 2026-09-11 **作者：** Neo.K with Aletheia **機構：** EveMissLab／一言諾科技有限公司 **文件性質：** 理論論文／AI 軟體經濟學／Intent Convergence Engineering **狀態：** Working Paper **Canonical source：** UTF-8 Markdown **Canonical math delimiters：** inline ` $...$ `；display `$$...$$` --- ## 摘要 前兩篇分別提出： $$ AGI_{\mathrm{event}} \neq AGI_{\mathrm{infrastructure}}, $$ 以及： $$ F \rightarrow U \rightarrow M \rightarrow I, $$ 指出真正改變文明與市場的，不只是 frontier capability 的提高，而是其快速向工作馬能力、廉價能力與基礎設施能力擴散。 本文進一步處理一個已開始具有直接產業意義的問題： > 當 AI 不再只是補全程式碼，而能從自然語言意圖出發，生成、執行、觀察、修復、驗證並逐步逼近可用軟體時，軟體工程的基本經濟單位是否正在改變？ 本文提出： $$ \boxed{ \text{SoftwareEngineering} \rightarrow \text{IntentConvergenceEngineering} } $$ 傳統軟體生產主要把人類工程工時視為核心稀缺資源；AI-native 軟體生產則逐漸轉向一個新的收斂問題： $$ Intent_t \rightarrow Artifact_t \rightarrow Execution_t \rightarrow Observation_t \rightarrow Correction_t \rightarrow Intent_{t+1}. $$ 在此架構中，「一次生成」不再應被理解為一個單步事件。即使使用者只送出一次高階意圖，系統內部也可能經歷規劃、生成、工具調用、執行、測試、修復、重試與驗證。因此本文區分： $$ \boxed{ \text{UserVisibleRound} \neq \text{InternalConvergenceLoop}. } $$ 本文提出 **Intent-to-Reality Latency**： $$ L_{IR}, $$ 表示從初始意圖被提交，到現實中出現達到品質門檻之 artifact 所需的世界時間；提出 **Cost-to-Artifact**： $$ C_A(Q), $$ 表示把一個意圖收斂至品質 $Q$ 所需的總資源成本；並提出 **Intent Convergence Efficiency**： $$ \eta_{IR} = \frac{ \Delta \text{Match}(Intent,Reality) }{ \Delta Resource }, $$ 衡量每單位計算、時間、驗證與人類介入，能把 artifact 推近目標多少。 本文主張，AI 軟體生產的真正瓶頸正在從「能不能生成程式碼」逐漸轉向： $$ \boxed{ \text{IntentSpecification} + \text{EnvironmentObservability} + \text{VerifierQuality} + \text{ExecutionAccess} + \text{ConvergenceBudget}. } $$ 當生成能力足夠強時，驗證器、測試環境與現實回饋的品質將決定： $$ E[\Delta D_t] $$ 是否為負，其中 $D_t$ 表示 artifact 與目標狀態之距離。 本文進一步討論一個重要經濟結果：當內部生成某軟體的： $$ C_{\mathrm{generate}}(Q) $$ 低於購買、整合、維護既有 SaaS 的： $$ C_{\mathrm{buy}}(Q), $$ 企業的 Make-or-Buy 邊界將被重構。這不意味著 SaaS 消失，而意味著低差異、低網路效應、低法遵壁壘、低資料護城河的軟體更容易受到 **SaaS Demand Compression**。 本文最後提出：真正可怕的不是 AI 能寫更多程式碼，而是當智能成本足夠低時，軟體本身逐漸從「昂貴人工製造品」轉成「按意圖臨時生成、持續修正、可被反覆重建的計算狀態」。若此轉變持續，未來企業的核心問題將從： > 誰替我寫這套軟體？ 逐漸轉成： > 我的意圖、驗證標準、資料與制度邊界，能否被一個持續收斂的 AI 系統正確實現？ **關鍵詞：** Intent Convergence Engineering、Cost-to-Artifact、Intent-to-Reality Latency、AI Software Production、Verifier Bottleneck、MVP Generation、Make-or-Buy、SaaS Demand Compression、Cheap Intelligence、Software Economics --- # 1. 從 Coding Assistant 到 Artifact Producer 早期 AI coding 工具主要完成： $$ \text{CodeCompletion}. $$ 下一階段擴展為： $$ \text{CodeGeneration}. $$ 再下一階段則開始進入： $$ \boxed{ \text{ArtifactProduction}. } $$ 三者並不相同。 Code Completion 解決： > 下一行程式碼是什麼？ Code Generation 解決： > 這個功能應該怎麼實作？ Artifact Production 則必須回答： > 這個需求能不能變成真的可以執行、可以測試、可以交付的東西？ 因此： $$ \boxed{ \text{CodeCorrectness} \neq \text{ArtifactCompleteness}. } $$ --- # 2. 軟體工程真正的產物不是程式碼 傳統軟體工程很容易把： $$ \text{SourceCode} $$ 當成主要產物。 但真實產品需要： $$ \text{Artifact} = \text{Code} + \text{Assets} + \text{Configuration} + \text{Data} + \text{Dependencies} + \text{Tests} + \text{Packaging} + \text{RuntimeBehavior} + UX + \text{OperationalState}. $$ 因此 AI 是否會寫程式碼，不足以判斷 AI 是否能生產軟體。 真正問題是： $$ \boxed{ CanAIProduceAndConvergeTheArtifact? } $$ --- # 3. 意圖不是一次性完整規格 初始自然語言需求： $$ I_0 $$ 通常不是完整產品規格。 真正的可交付意圖： $$ I^\ast $$ 更接近： $$ I^\ast = I_0 + \Delta I_1 + \Delta I_2 +\cdots+ \Delta I_n. $$ 其中大量： $$ \Delta I_k $$ 不是使用者在開始時就知道的。 它們往往只有在 artifact 實際出現後才被發現。 例如： - UI 太小； - loading 太慢； - 操作不直覺； - 儲存失敗； - 遊戲手感錯誤； - 視覺資訊密度不足； - 安裝程序有問題； - 測試環境才出現 edge case。 因此： $$ \boxed{ \text{Reality} \rightarrow \text{NewIntent}. } $$ --- # 4. Intent Evolution Loop 本文將軟體意圖表示為： $$ I_t. $$ AI 在時間 $t$ 生成： $$ A_t. $$ 執行後產生： $$ R_t. $$ 觀察結果： $$ O_t. $$ 則下一輪意圖： $$ I_{t+1} = Update( I_t, O_t, HumanFeedback_t, Verifier_t ). $$ 因此： $$ \boxed{ \text{Intent} } $$ 不是靜態 prompt。 而是一個 runtime-evolving state。 --- # 5. 一輪不等於一步 在使用者介面上： $$ UserRound=1 $$ 完全可能包含： $$ InternalLoop\gg1. $$ 例如一個看似「一次完成」的 Agent 任務，內部可能進行： - plan； - generate； - run； - inspect； - test； - patch； - retry； - package； - verify。 因此： $$ \boxed{ \text{UserVisibleRound} \neq \text{InternalConvergenceLoop}. } $$ 這個區分非常重要。 因為未來使用者可能只看到： > 我說一次，它做完。 但經濟上真正消耗的是： $$ k = \text{internal loop count}. $$ --- # 6. 從 One-Shot 到 One-Cycle 本文建議把所謂「一輪生成」進一步區分。 ## One-Shot $$ \text{Intent} \rightarrow \text{Output}. $$ 沒有真實 execution feedback。 ## One-Cycle $$ \text{Intent} \rightarrow \text{Plan} \rightarrow \text{Generate} \rightarrow \text{Execute} \rightarrow \text{Repair} \rightarrow \text{Verify} \rightarrow \text{Artifact}. $$ 因此： $$ \boxed{ \text{OneCycle} \neq \text{OneShot}. } $$ 未來高階 AI 軟體生成真正有價值的「一輪」，更可能是： $$ \text{OneCycle}. $$ --- # 7. Artifact Distance 令： $$ D_t = Distance( A_t, A^\ast ), $$ 其中： $$ A^\ast $$ 表示滿足目標意圖與品質門檻的 artifact。 理想收斂要求： $$ D_{t+1} 這應該可以跑。 有 execution access： $$ AI $$ 可以知道： > 它真的跑不起來。 這是： $$ \boxed{ \text{SpeculativeProgramming} \rightarrow \text{EmpiricalProgramming}. } $$ 的重要分界。 --- # 14. Intent-to-Reality Latency 本文定義： $$ \boxed{ L_{IR} = t_{\mathrm{acceptable\ artifact}} - t_{\mathrm{initial\ intent}}. } $$ 它表示： > 從人類提出意圖，到現實中出現可接受 artifact 所需的世界時間。 這比： $$ \text{TokensPerSecond} $$ 更接近真實生產力。 --- # 15. Time Is Multi-Layered 一次 AI 軟體生產同時消耗： $$ \mathfrak T = ( t_W, t_H, k, \tau_M ), $$ 其中： - $t_W$：世界 wall-clock time； - $t_H$：人類投入時間； - $k$：AI internal loop count； - $\tau_M$：machine runtime。 因此： $$ \boxed{ \text{10MinutesOfWorldTime} \neq \text{10MinutesOfHumanLabor}. } $$ 如果： $$ t_H\ll t_W, $$ AI 可以在背景執行大量工作，而人類只在少數 gate 介入。 --- # 16. Cost-to-Artifact 本文定義： $$ \boxed{ C_A(Q) } $$ 為把意圖轉化為品質至少 $Q$ 的 artifact 所需總成本。 可以拆成： $$ C_A(Q) = C_M + C_T + C_V + C_H + C_F + C_O, $$ 其中： - $C_M$：model / token cost； - $C_T$：tool / compute cost； - $C_V$：verification cost； - $C_H$：human intervention cost； - $C_F$：failure / retry cost； - $C_O$：operational / deployment cost。 --- # 17. Cost-to-Artifact 比 Cost-to-Code 更重要 若： $$ \text{CodeCost}\downarrow $$ 但： $$ \text{DebugCost}\uparrow $$ 或： $$ \text{VerificationCost}\uparrow, $$ 則： $$ \text{ArtifactCost} $$ 未必下降。 因此： $$ \boxed{ \text{CostToCode} \neq \text{CostToArtifact}. } $$ AI 軟體經濟學真正應追蹤的是後者。 --- # 18. Intent Convergence Efficiency 定義： $$ M_t = \text{Match}( Intent_t, Artifact_t ). $$ 再定義： $$ \boxed{ \eta_{IR} = \frac{ \Delta M }{ \Delta C } } $$ 其中： $$ \Delta C $$ 可以是： - token； - 美元； - GPU 秒； - wall-clock time； - human minutes； - verification work。 此指標表示： > 每一單位資源究竟換來多少意圖實現程度。 --- # 19. 多維效率 更完整地： $$ \eta_{IR} = f( \eta_{\$}, \eta_{time}, \eta_{human}, \eta_{compute}, \eta_{verify} ). $$ 所以模型 A 可能： $$ \eta_{\$}\uparrow $$ 但： $$ \eta_{time}\downarrow. $$ 模型 B 則可能相反。 不同工作流可以選擇不同效用函數。 --- # 20. Human Intervention Density 定義： $$ \rho_H = \frac{ N_{\mathrm{human\ interventions}} }{ N_{\mathrm{agent\ transitions}}+\epsilon }. $$ 若： $$ \rho_H\downarrow, $$ 代表 Agent 可以完成更多內部 transition，而不需要人類逐步確認。 但： $$ \rho_H\downarrow $$ 不等於： $$ \text{GovernanceQuality}\uparrow. $$ 因為過低的人類介入也可能放大錯誤。 --- # 21. Human Gate Placement 真正的問題不是： > 人要不要介入？ 而是： $$ \boxed{ \text{WhereShouldHumansIntervene?} } $$ 理想上，人類應逐步從： $$ \text{RoutineTransitions} $$ 退出， 而集中於： $$ \text{HighRisk} + \text{Irreversible} + \text{Ambiguous} + \text{ValueSensitive} $$ 節點。 因此： $$ \boxed{ \text{HumanIntervention} \rightarrow \text{HumanGovernance}. } $$ --- # 22. MVP 的經濟意義 MVP 並不等於完整產品。 但 MVP 是一個非常重要的生產門檻。 因為它回答： > 從抽象意圖到可執行 artifact 的首次閉環需要多少成本？ 定義： $$ C_{\mathrm{MVP}} = C_A(Q_{\mathrm{MVP}}). $$ 如果： $$ C_{\mathrm{MVP}}\downarrow, $$ 則大量原本不值得嘗試的產品 idea 會變得值得嘗試。 --- # 23. Prototype Explosion 若： $$ C_{\mathrm{MVP}} \rightarrow0, $$ 那麼： $$ N_{\mathrm{prototypes}}\uparrow. $$ 這可能形成： $$ \boxed{ \text{PrototypeExplosion}. } $$ 人類不再只討論 idea。 而是： > 先做出來看看。 因此 product ideation 與 product execution 之間的距離快速縮短。 --- # 24. 失敗成本下降 傳統專案之所以保守，部分原因是： $$ \text{FailureCost} $$ 很高。 如果 prototype： $$ \$50,000 \rightarrow \$50, $$ 那麼： $$ \text{ExpectedExperimentCount}\uparrow. $$ 所以： $$ \boxed{ \text{CheaperFailure} \Rightarrow \text{MoreSearch}. } $$ AI 不只提高生產力。 它還改變 exploration economics。 --- # 25. 軟體產品空間搜尋 可將產品空間表示為： $$ \Omega_P. $$ 每次 prototype 是： $$ p_i\in\Omega_P. $$ 傳統人工成本高時，只能探索： $$ |\{p_i\}|\ll|\Omega_P|. $$ 當 AI 生成成本下降： $$ N_{\mathrm{explored}}\uparrow. $$ 所以真正提升的可能是： $$ \boxed{ \text{ProductSearchBandwidth}. } $$ --- # 26. 一次型意圖與現實修正 即使初始意圖非常清楚： $$ I_0, $$ 真實 execution 仍會暴露： $$ \text{UnknownUnknowns}. $$ 因此： $$ \boxed{ \text{IntentCompleteness} } $$ 通常只能在： $$ \text{Execution} $$ 之後逐步提高。 這也是為什麼： $$ \text{PromptQuality} $$ 不是完整答案。 真正需要的是： $$ \boxed{ \text{Prompt} + \text{RuntimeFeedback} + \text{Revision}. } $$ --- # 27. Make-or-Buy 的舊結構 傳統企業比較： $$ C_{\mathrm{build}} $$ 與： $$ C_{\mathrm{buy}}. $$ 其中： $$ C_{\mathrm{build}} $$ 通常包含： - hiring； - engineering time； - management； - maintenance； - opportunity cost。 因此很多企業選擇： $$ \text{BuySaaS}. $$ --- # 28. AI 改寫 Build Cost AI-native build cost 更接近： $$ C_{\mathrm{build}}^{AI} = C_A(Q) + C_{\mathrm{maintain}} + C_{\mathrm{governance}}. $$ 若： $$ C_{\mathrm{build}}^{AI} \downarrow, $$ Make-or-Buy 邊界會移動。 企業開始問： > 我真的需要買這個嗎？ --- # 29. Buy Cost 也不是訂閱費而已 完整購買成本： $$ C_{\mathrm{buy}} = \text{Subscription} + \text{Integration} + \text{Migration} + \text{Training} + \text{LockIn} + \text{Customization} + \text{Compliance}. $$ 所以即使 SaaS 月費很低： $$ C_{\mathrm{buy}} $$ 也可能不低。 --- # 30. Make-or-Buy Threshold 定義： $$ \Delta_{\mathrm{MB}} = C_{\mathrm{buy}} - C_{\mathrm{build}}^{AI}. $$ 若： $$ \Delta_{\mathrm{MB}}>0, $$ 則 internal generation 在經濟上更有吸引力。 因此： $$ \boxed{ AI \rightarrow \text{MakeBoundaryExpansion}. } $$ --- # 31. 不是所有 SaaS 都同樣脆弱 最容易受到生成替代的通常是： $$ \text{LowDifferentiation} + \text{LowNetworkEffect} + \text{LowComplianceBarrier} + \text{LowDataMoat} + \text{HighCustomizationPain}. $$ 最不容易被替代的可能是： $$ \text{Network} + \text{Data} + \text{Trust} + \text{LegalIntegration} + \text{Distribution} + \text{OperationalReliability}. $$ 所以： $$ \boxed{ \text{SoftwareGeneration} \not\Rightarrow \text{SaaSDeath}. } $$ --- # 32. SaaS Demand Compression 本文定義： $$ \boxed{ \text{SaaSDemandCompression} } $$ 為： > 因 internal generation 成本下降，使原本會購買第三方軟體的需求，轉向自建、臨時生成或組合能力。 因此： $$ \text{Demand}_{\mathrm{SaaS}} \downarrow $$ 可能不是因為： > 軟體不重要。 反而是因為： $$ \boxed{ \text{SoftwareBecomesTooEasyToProduce}. } $$ --- # 33. 從產品到能力單元 如果軟體可快速生成，企業未必需要購買完整產品。 可能只購買： - API； - verifier； - data； - model； - payment rail； - identity layer； - compliance module。 然後由 AI 動態組合。 因此： $$ \text{Product} \rightarrow \text{Capabilities}. $$ 這將接到： $$ \text{AI Native Market}. $$ --- # 34. 生成式軟體的生命周期 傳統軟體： $$ \text{Design} \rightarrow \text{Build} \rightarrow \text{Ship} \rightarrow \text{Maintain}. $$ 未來可能更像： $$ \text{Intent} \rightarrow \text{Generate} \rightarrow \text{Deploy} \rightarrow \text{Observe} \rightarrow \text{Regenerate}. $$ 因此： $$ \boxed{ \text{Maintenance} \rightarrow \text{ContinuousRegeneration}. } $$ --- # 35. 軟體是否仍需要固定版本？ 若： $$ \text{RegenerationCost}\downarrow, $$ 則未來部分軟體不必維持大量 legacy patch。 理論上可以： $$ \text{State}_t + \text{Intent}_{t+1} \rightarrow \text{Software}_{t+1}. $$ 這不表示版本控制消失。 而是： $$ \boxed{ \text{Version} } $$ 可能更接近： > 一個可重建狀態快照。 --- # 36. Specification 成為更高價值資產 當 code 便宜： $$ \text{CodeScarcity}\downarrow, $$ 價值可能轉向： $$ \text{Intent} + \text{Specification} + \text{Data} + \text{Verifier} + \text{Governance}. $$ 因此： $$ \boxed{ \text{CodeMoat}\downarrow \Rightarrow \text{SpecificationMoat}\uparrow. } $$ --- # 37. Verifier 可能成為下一代軟體護城河 如果任何人都能生成程式碼： $$ \text{Generation}\rightarrow \text{Commodity}. $$ 真正稀缺的可能是： > 誰能證明這個東西真的可靠？ 因此： $$ \boxed{ \text{Verification} } $$ 可能從開發流程中的成本中心，變成產品價值本身。 --- # 38. Domain Verifier 例如醫療、金融、法律、航太、會計等領域，生成容易不代表可部署。 需要： $$ V_{\mathrm{domain}} $$ 檢查： - 法規； - 風險； - 邏輯； - 證據； - 安全； - procedure。 因此高風險產業的護城河可能從： $$ \text{CanBuild} $$ 轉向： $$ \boxed{ \text{CanCertifyAndGovern}. } $$ --- # 39. Intent Compiler 若 AI 軟體生產持續成熟，未來可能出現： $$ \boxed{ \text{IntentCompiler} } $$ 其輸入： $$ \text{Intent} + \text{Constraints} + \text{Assets} + \text{Policies} + \text{QualityTarget}. $$ 輸出： $$ \text{ExecutableArtifact} + \text{Evidence} + \text{Tests} + \text{DeploymentPlan}. $$ 這比傳統 compiler 的 input 更高階。 --- # 40. 世界模型與軟體生成 真正強的 Intent Compiler 需要理解： $$ \text{CurrentSystemState}. $$ 因為同一句： > 幫我加入登入功能。 在不同 codebase、security policy、database、deployment environment 中，答案完全不同。 因此： $$ \boxed{ \text{IntentCompilation} \text{RequiresWorldState}. } $$ 這也開始與： $$ \text{HDUS} $$ 類 computational world 架構產生接口。 --- # 41. 一次性生成與長期系統的差異 一次性 MVP 可以容忍： $$ \text{TemporaryArchitecture}. $$ 長期系統需要： $$ \text{Maintainability} + \text{StateContinuity} + \text{Governance} + \text{Migration}. $$ 所以： $$ \boxed{ \text{MVPGenerationCapability} \neq \text{LongTermSystemCapability}. } $$ 這也是評估 AI 軟體能力時必須保留的限制。 --- # 42. Internal Observation Case 在 2026 年 9 月的內部探索中，作者使用高階 AI 系統測試多種遊戲 MVP 與軟體 MVP 生成。 在部分任務中，從高階自然語言意圖到第一個可執行 artifact 的可觀察 wall-clock time 約位於： $$ 10\text{--}50\ \text{minutes} $$ 量級。 此結果不能被外推為普遍 benchmark。 因為： - 任務複雜度不同； - 模型與工具不同； - hardware 不同； - 驗證標準不同； - 失敗專案未必具有相同樣本權重。 但它具有一個研究意義： $$ \boxed{ \text{IntentToExecutableArtifact} } $$ 已不再只是理論 pipeline，而開始成為可直接觀察的生產事件。 --- # 43. 從人工工程成本到智能時空成本 傳統專案可粗略表示： $$ C \approx \text{HumanHours} \times \text{Wage}. $$ AI-native 專案逐步轉成： $$ \boxed{ C = f( \text{Compute}, \text{Tokens}, \text{WorldTime}, \text{HumanGovernance}, \text{Verification}, \text{Failure} ). } $$ 這就是： $$ \boxed{ \text{IntelligentSpacetimeCost}. } $$ --- # 44. 智能時空不是純 token 同樣 token 數： $$ T_1=T_2 $$ 可能產生完全不同價值。 因為： $$ \text{ToolAccess}_1\neq \text{ToolAccess}_2, $$ $$ \text{Verifier}_1\neq \text{Verifier}_2, $$ $$ \text{Environment}_1\neq \text{Environment}_2. $$ 所以： $$ \boxed{ \text{TokenCount} \neq \text{EngineeringWork}. } $$ --- # 45. Productive Intelligence Density 定義： $$ \rho_{PI} = \frac{ V_{\mathrm{verified\ artifact}} }{ \Delta t_W }. $$ 它衡量： > 單位世界時間內產生多少經驗證 artifact value。 這比： $$ \text{TokensPerSecond} $$ 更接近經濟生產力。 --- # 46. Verification-Adjusted Throughput 再定義： $$ \rho_{VA} = \frac{ N_{\mathrm{verified\ acceptable\ outputs}} }{ \Delta t_W }. $$ 如果生成速度提高，但： $$ \text{AcceptanceRate}\downarrow, $$ 則： $$ \rho_{VA} $$ 未必提高。 --- # 47. Human Time Leverage 定義： $$ \Lambda_H = \frac{ V_{\mathrm{verified\ output}} }{ T_H+\epsilon }. $$ AI 軟體生產真正吸引人的地方，可能不是： > 機器做得比人快多少。 而是： $$ \boxed{ \text{HowMuchVerifiedOutput} \text{PerHumanMinute}? } $$ --- # 48. AI 工程的主要稀缺物將移動 早期： $$ \text{Scarcity} = \text{CodingSkill}. $$ 下一階段可能變成： $$ \text{Scarcity} = \text{ProblemDefinition}. $$ 再下一階段： $$ \text{Scarcity} = \text{Verification} + \text{Governance} + \text{WorldUnderstanding}. $$ 因此： $$ \boxed{ \text{AutomationMovesScarcityUpward}. } $$ --- # 49. 人類工程師不一定消失 AI 軟體生成成熟後，人類角色可能從： $$ \text{Implementer} $$ 轉向： $$ \text{Architect} + \text{Specifier} + \text{Verifier} + \text{Governor}. $$ 但這不代表總人力需求一定不下降。 如果： $$ \text{1Human}+\text{AI} $$ 可以完成過去： $$ \text{10Humans} $$ 的工作， 則： $$ \boxed{ \text{RoleUpgrade} } $$ 仍可同時伴隨： $$ \text{EmploymentCompression}. $$ --- # 50. Intent Convergence Engineering 本文最後正式定義： $$ \boxed{ \text{IntentConvergenceEngineering} } $$ 為： > 使用可執行 AI、工具、環境觀測、驗證器與人類治理，在有限智能時空資源下，使 artifact 狀態逐步收斂於目標意圖與品質約束的工程方法。 其核心不是： $$ \text{GenerateOnce}. $$ 而是： $$ \boxed{ \text{ConvergeReliably}. } $$ --- # 51. 最小條件 一個可靠 Intent Convergence System 至少需要： $$ \boxed{ \text{SufficientGenerator} + \text{ObservableEnvironment} + \text{ExecutableActions} + \text{ReliableVerifier} + \text{PersistentState} + \text{Budget} } $$ 其中任何一項缺失，都可能讓： $$ D_t $$ 無法穩定下降。 --- # 52. 核心經濟條件 若： $$ C_A(Q) < C_H(Q), $$ 其中： $$ C_H(Q) $$ 表示傳統人類工程達到品質 $Q$ 的成本， 則 AI-native 生產取得： $$ \text{EconomicAdvantage}. $$ 若同時： $$ L_{IR}^{AI} < L_{IR}^{Human}, $$ 則： $$ \boxed{ \text{CostAdvantage} + \text{LatencyAdvantage} } $$ 形成強替代壓力。 --- # 53. 五條核心命題 ## 命題一 $$ \boxed{ \text{SoftwareEngineering} \rightarrow \text{IntentConvergenceEngineering}. } $$ ## 命題二 $$ \boxed{ \text{UserVisibleRound} \neq \text{InternalConvergenceLoop}. } $$ ## 命題三 $$ \boxed{ \text{CostToCode} \neq \text{CostToArtifact}. } $$ ## 命題四 $$ \boxed{ \text{GenerationCapability} \uparrow \Rightarrow \text{VerifierImportance} \uparrow. } $$ ## 命題五 $$ \boxed{ \text{CostToArtifact}\downarrow \Rightarrow \text{MakeBoundaryExpansion}. } $$ --- # 54. 可反證條件 本文核心命題若要成立，未來應觀察到： 1. 固定品質軟體的 $C_A(Q)$ 長期下降； 2. $L_{IR}$ 在更多專案類別縮短； 3. Human Intervention Density 下降而 acceptance rate 不惡化； 4. AI 可在真實 runtime 中自動修復更多錯誤； 5. verifier 工具與自動測試的重要性持續上升； 6. 企業 internal generation 案例增加； 7. 低護城河 SaaS 面臨更多自建替代； 8. 軟體 prototype 數量增加； 9. 單位人類時間對應的 verified artifact value 提高。 若長期： $$ \text{GeneratorCapability}\uparrow $$ 但： $$ C_A(Q)\not\downarrow, $$ 或： $$ \text{VerificationBurden}\uparrow\uparrow, $$ 則本文強版本應被削弱。 --- # 55. 與前兩篇的關係 Paper 01： $$ \text{AGI} \rightarrow \text{Infrastructure}. $$ Paper 02： $$ \text{Frontier} \rightarrow \text{Commodity}. $$ 本篇： $$ \boxed{ \text{CheapIntelligence} \rightarrow \text{SoftwareProductionReconstruction}. } $$ 也就是： $$ \text{Paper01} \rightarrow \text{Paper02} \rightarrow \text{Paper03} $$ 分別處理： $$ \text{MacroTransition} \rightarrow \text{DiffusionMechanism} \rightarrow \text{ProductionMechanism}. $$ --- # 56. 結論 AI 軟體革命真正重要的問題，不是： > AI 可以寫多少程式碼？ 甚至也不是： > AI 能不能一輪做出 MVP？ 而是： $$ \boxed{ \text{HowMuchIntelligentSpacetime} \text{DoesAnIntentRequire} \text{BeforeItBecomesReality}? } $$ 當這個成本持續下降時： $$ \text{Idea} \rightarrow \text{Prototype} $$ 的距離縮短， $$ \text{Prototype} \rightarrow \text{Product} $$ 的距離也可能縮短。 軟體開始由： $$ \text{HumanCraftedArtifact} $$ 逐漸轉成： $$ \boxed{ \text{ContinuouslyConvergedComputationalState}. } $$ 到那時，真正稀缺的可能不再是程式碼。 而是： $$ \text{Intent} + \text{Specification} + \text{Verifier} + \text{Data} + \text{Governance}. $$ 這就是從「程式碼生成」走向「意圖收斂」的核心轉換。 --- ## 下一篇 **Paper 04：〈可複製智能與人類尾端分布：經濟替代門檻、任務束分解與就業壓縮〉** 核心問題： $$ \boxed{ \text{WhyDoesMassSubstitutionNotRequireAIToBeatTheBestHuman}? } $$ 下一篇將處理： - Human capability distribution； - tail capability； - replicable intelligence； - task-bundle decomposition； - partial substitution； - economic selection threshold； - employment compression； - human comparative advantage domain； - abundance of intelligence； - skill premium erosion。