2026年10月19日 星期一

MFA004 使用 UseLogging 將 MAF 掛上日誌能力並且查看日誌內容

MFA004 使用 UseLogging 將 MAF 掛上日誌能力並且查看日誌內容

在上一篇關於 Microsoft Agent Framework 系列教學文章 "MFA003 Microsoft Agent Framework 從 LLM 回應中取得 Token 統計" 中,我們學會了如何使用 MAF 提供的物件,得到呼叫 LLM API 的 Token 統計資訊。接下來就是我們再開發系統的時候,經常會用到的日誌能力,因為當系統有了日誌功能後,我們可以更方便地追蹤系統的運作狀況,了解每一次對 LLM API 的呼叫細節,並且在需要時進行除錯與分析。

在這裡的範例中可以看到,MAF 提供的日誌能力可以讓我們在呼叫 LLM API 時,將每一次的請求與回應詳細記錄下來,方便後續的追蹤與分析。這裡將會透過 UseLogging 中介軟體來實現這個功能。

接下來看看如何做到這樣的效果。

建立 Console 專案

  • 開啟 Visual Studio 2026
  • 選擇「建立新專案」
  • 在 [建立新的專案] 視窗中,在右方清單內,找到並選擇「主控台應用程式」 項目
  • 然後點擊右下方「下一步」按鈕
  • 此時將會看到 [設定新的專案] 對話窗
  • 在該對話窗的 [專案名稱] 欄位中,輸入專案名稱,例如 "csLoggingAgent"
  • 然後點擊右下方「下一步」按鈕
  • 接著會看到 [其他資訊] 對話窗
  • 在這個對話窗內,確認使用底下的選項
    • 架構:.NET 10.0 (或更新版本)
    • 勾選 不要使用最上層陳述式 (這是我的個人習慣)
  • 然後點擊右下方「建立」按鈕
  • 現在,已經完成了這個 Console 主控台 專案的建立

安裝需要用到的 NuGet 套件

要完成這個第一次接觸 Microsoft Agent Framework 練習專案,需要安裝以下幾個 NuGet 套件:

Microsoft.Extensions.AI

這個套件將會為生成式 AI 定義的一層「統一抽象介面 + Middleware 管線」,讓開發者可以更方便地整合不同的生成式 AI 模型,並且在應用程式中使用一致的方式進行呼叫與管理。

  • 滑鼠右擊 [csLoggingAgent] 專案節點
  • 點選彈出功能表的 [管理 NuGet 套件] 項
  • 在 [瀏覽] 索引標籤中,搜尋並且安裝底下的 NuGet 套件
    • Microsoft.Extensions.AI

Microsoft.Extensions.AI.OpenAI

這個套件是微軟官方為 .NET 整合 AI 服務所提供的擴充套件。它實現了 IChatClient 與 IEmbeddingGenerator 核心抽象介面,讓開發人員能以一致的程式碼,輕鬆串接 OpenAI 或相容的 API 端點(例如 Azure OpenAI、GitHub Models 等)。

  • 滑鼠右擊 [csLoggingAgent] 專案節點
  • 點選彈出功能表的 [管理 NuGet 套件] 項
  • 在 [瀏覽] 索引標籤中,搜尋並且安裝底下的 NuGet 套件
    • Microsoft.Extensions.AI.OpenAI

Microsoft.Agents.AI

這個套件是微軟官方推出 Microsoft Agent Framework(微軟智慧代理框架)的核心 .NET 套件。它主要用於在 .NET 環境中建構、協調與部署 AI 代理(AI Agents) 及多代理工作流(Multi-agent workflows),是用來取代舊版 AutoGen 的企業級解決方案。

  • 滑鼠右擊 [csLoggingAgent] 專案節點
  • 點選彈出功能表的 [管理 NuGet 套件] 項
  • 在 [瀏覽] 索引標籤中,搜尋並且安裝底下的 NuGet 套件
    • Microsoft.Agents.AI

OpenAI

這個套件為官方的 OpenAI .NET 客戶端類別庫,是 OpenAI NuGet 套件。此套件由 OpenAI 與 Microsoft 合作開發,提供直接存取 OpenAI 官方 REST API 的便利管道。

  • 滑鼠右擊 [csLoggingAgent] 專案節點
  • 點選彈出功能表的 [管理 NuGet 套件] 項
  • 在 [瀏覽] 索引標籤中,搜尋並且安裝底下的 NuGet 套件
    • OpenAI

Logging

這個套件為 Microsoft.Extensions.Logging 的官方 NuGet 套件,是用來在 .NET 應用程式中提供日誌功能的。此套件由 Microsoft 官方開發,提供統一的日誌介面與多種日誌後端的整合能力。

  • 滑鼠右擊 [csLoggingAgent] 專案節點
  • 點選彈出功能表的 [管理 NuGet 套件] 項
  • 在 [瀏覽] 索引標籤中,搜尋並且安裝底下的 NuGet 套件
    • Microsoft.Extensions.Logging

Logging.Console

這個套件為 Microsoft.Extensions.Logging.Console 的官方 NuGet 套件,是用來在 .NET 應用程式中提供控制台日誌功能的。此套件由 Microsoft 官方開發,提供統一的日誌介面與多種日誌後端的整合能力。

  • 滑鼠右擊 [csLoggingAgent] 專案節點
  • 點選彈出功能表的 [管理 NuGet 套件] 項
  • 在 [瀏覽] 索引標籤中,搜尋並且安裝底下的 NuGet 套件
    • Microsoft.Extensions.Logging.Console

宣告 API 端點與 Key 環境變數

關於這個小節的內容,將會在這個系列每篇文章中都會用到,因此,可以參考 MFA001 Microsoft Agent Framework 初次體驗開發出 AI 代理 文章中的 [宣告 API 端點與 Key 環境變數] 說明內容,若這裡提到的環境變數已經建立好了,則可以跳過這個小節內容。

修改 Program.cs 程式碼

為了要完成這個需求 : 如何用 Azure OpenAI 的 gpt-5.6-luna 聊天模型建立一個簡單 AI 代理,並產生一篇與鵝有關的詩。 因此,我們需要修改 Program.cs 程式碼,這時需要完成底下的操作。

  • 在專案內,找到並且開啟 [Program.cs] 檔案
  • 使用底下程式碼內容來取代 [Program.cs] 檔案的內容
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.Logging;
using OpenAI;
using OpenAI.Chat;
using System.ClientModel;
using System.Text;

namespace csLoggingAgent;

internal class Program
{
    static async Task Main(string[] args)
    {
        Console.OutputEncoding = Encoding.UTF8;

        var apiKey = Environment.GetEnvironmentVariable("AzureOpenAI_Key");
        var endpoint = Environment.GetEnvironmentVariable("AzureOpenAI_Endpoint");
        var model = "gpt-5.6-luna";

        if (string.IsNullOrWhiteSpace(apiKey) || string.IsNullOrWhiteSpace(endpoint))
        {
            Console.WriteLine("請先設定環境變數 AzureOpenAI_Key 與 AzureOpenAI_Endpoint 後再執行。");
            return;
        }

        using var loggerFactory = LoggerFactory.Create(builder =>
        {
            builder.AddSimpleConsole(options => options.TimestampFormat = "HH:mm:ss.fff ");
            builder.SetMinimumLevel(LogLevel.Trace);
        });

        IChatClient chatClient =
            new ChatClient(
                    model,
                    new ApiKeyCredential(apiKey),
                    new OpenAIClientOptions { Endpoint = new Uri(endpoint) })
                .AsIChatClient();

        AIAgent agent = new ChatClientAgent(
            chatClient,                      // 聊天用戶端
            "詩人",                          // 代理名稱
            "創作引人入勝、富有創意的詩。",  // 系統提示詞
            null);                           // 其他設定

        AIAgent loggedAgent = agent
            .AsBuilder()
            .UseLogging(loggerFactory)
            .Build();

        Console.WriteLine($"{DateTime.Now} 開始呼叫 LLM API / 使用的模型: {model}");

        var response = await loggedAgent.RunAsync("寫一個關於鵝的詩。");

        Console.WriteLine();
        Console.WriteLine(response.Text);
        Console.WriteLine($"{DateTime.Now} 完成呼叫 LLM API / 使用的模型: {model}");
    }
}

這個程式一開始將會讀取 API Key 與服務端點的數據,接著如同前面的範例相同,先建立一個 IChatClient 物件,接者建立一個 AIAgent 物件,並使用它來與模型進行互動。這部分的說明,可以參考 [MFA001 Microsoft Agent Framework 初次體驗開發出 AI 代理] 或者 [MFA002 Microsoft Agent Framework 串流輸出回應] 文章。

在這個範例中,系統提示詞宣告為 "創作引人入勝、富有創意的詩。",這表示代理將會以創作詩歌為主要任務,並且在生成內容時會注重創意與吸引力。

在這個程式一開頭,我們就建立了一個 loggerFactory,用來配置日誌輸出格式與日誌等級。這樣一來,後續所有使用這個 loggerFactory 的代理都能夠自動產生日誌,方便我們追蹤程式的執行過程。這裡使用了 SetMinimumLevel(LogLevel.Trace) 來設定日誌的最小等級為 Trace,確保所有等級的日誌都能被輸出。在日誌系統中,每筆日誌紀錄都會有個等級 Level 屬性值,這些屬性值可以為 Trace、Debug、Information、Warning、Error 或 Critical。這些等級意義為:

  • Trace: 最詳細的日誌訊息,通常用於診斷問題。
  • Debug: 調試過程中使用的日誌訊息。
  • Information: 一般資訊性日誌。
  • Warning: 警告訊息,表示可能的問題。
  • Error: 錯誤訊息,表示程式執行中發生了問題。
  • Critical: 致命錯誤訊息,表示程式可能無法繼續執行。
using var loggerFactory = LoggerFactory.Create(builder =>
{
    builder.AddSimpleConsole(options => options.TimestampFormat = "HH:mm:ss.fff ");
    builder.SetMinimumLevel(LogLevel.Trace);
});

除了一開始建立了一個型別為 AIAgent 的 agent 物件,接著又使用 AsBuilder() 方法將其轉換為建構器,並使用 UseLogging(loggerFactory) 來為代理掛上日誌能力,最後再呼叫 Build() 方法建立出帶有日誌功能的 loggedAgent 物件。這樣一來,所有透過 loggedAgent 執行的操作都會自動產生日誌,方便開發者追蹤代理的行為與模型的回應。

AIAgent loggedAgent = agent
    .AsBuilder()
    .UseLogging(loggerFactory)
    .Build();

最後執行 var response = await loggedAgent.RunAsync("寫一個關於鵝的詩。"); 這行程式碼會觸發代理與模型的互動,並且由於我們之前為代理掛上了日誌功能,因此在執行過程中會自動產生日誌,顯示代理的行為與模型的回應。

執行結果

現在來看看這個範例程式碼的執行結果。

  • 在 Visual Studio 2026 下,按下 F5 鍵執行程式,將會看到程式輸出的結果。
2026/10/14 下午 03:16:10 開始呼叫 LLM API / 使用的模型: gpt-5.6-luna
15:16:11.034 trce: LoggingAgent[805843669]
      RunAsync invoked: [{"role":"user","contents":[{"$type":"text","text":"寫一個關於鵝的詩。"}]}]. Options: null. Metadata: {"providerName":"openai"}.

15:16:14.414 trce: LoggingAgent[384896670]
      RunAsync completed: {"messages":[{"authorName":"創作引人入勝、富有創意的詩。","createdAt":"2026-10-14T07:16:12+00:00","role":"assistant","contents":[{"$type":"text","text":"**〈鵝〉**\n\n白羽裁成一片雲,  \n搖搖擺擺過黃昏。  \n清波替牠梳長影,  \n晚風輕拂赤紅門。  \n\n一聲高唱驚蘆雪,  \n半畝春池漾月痕。  \n不問人間多少路,  \n昂首自向水天奔。"}],"messageId":"chatcmpl-EYnVciPuQQ1cMnUCCnP3f4vV8BCQK"}],"agentId":"dcc3ea8594a243f082abcade0784f727","responseId":"chatcmpl-EYnVciPuQQ1cMnUCCnP3f4vV8BCQK","createdAt":"2026-10-14T07:16:12+00:00","finishReason":"stop","usage":{"inputTokenCount":25,"outputTokenCount":118,"totalTokenCount":143,"cachedInputTokenCount":0,"reasoningTokenCount":17,"additionalCounts":{"InputTokenDetails.AudioTokenCount":0,"OutputTokenDetails.AudioTokenCount":0,"OutputTokenDetails.AcceptedPredictionTokenCount":0,"OutputTokenDetails.RejectedPredictionTokenCount":0}}}.
**〈鵝〉**

白羽裁成一片雲,
搖搖擺擺過黃昏。
清波替牠梳長影,
晚風輕拂赤紅門。

一聲高唱驚蘆雪,
半畝春池漾月痕。
不問人間多少路,
昂首自向水天奔。
2026/10/14 下午 03:16:14 完成呼叫 LLM API / 使用的模型: gpt-5.6-luna

從上面的執行後輸出內容,可以看到有兩個 trace 日誌紀錄,第一筆為

RunAsync invoked: [{"role":"user","contents":[{"$type":"text","text":"寫一個關於鵝的詩。"}]}]. Options: null. Metadata: {"providerName":"openai"}.

從第一筆日誌紀錄可以看出,這是要送給 LLM API 的內容,也就是使用者的請求訊息。在 contents 屬性中可以看到使用者輸入的文字 "寫一個關於鵝的詩。"

第二筆為

RunAsync completed: {"messages":[{"authorName":"創作引人入勝、富有創意的詩。","createdAt":"2026-10-14T07:16:12+00:00","role":"assistant","contents":[{"$type":"text","text":"〈鵝〉\n\n白羽裁成一片雲, \n搖搖擺擺過黃昏。 \n清波替牠梳長影, \n晚風輕拂赤紅門。 \n\n一聲高唱驚蘆雪, \n半畝春池漾月痕。 \n不問人間多少路, \n昂首自向水天奔."}],"messageId":"chatcmpl-EYnVciPuQQ1cMnUCCnP3f4vV8BCQK"}],"agentId":"dcc3ea8594a243f082abcade0784f727","responseId":"chatcmpl-EYnVciPuQQ1cMnUCCnP3f4vV8BCQK","createdAt":"2026-10-14T07:16:12+00:00","finishReason":"stop","usage":{"inputTokenCount":25,"outputTokenCount":118,"totalTokenCount":143,"cachedInputTokenCount":0,"reasoningTokenCount":17,"additionalCounts":{"InputTokenDetails.AudioTokenCount":0,"OutputTokenDetails.AudioTokenCount":0,"OutputTokenDetails.AcceptedPredictionTokenCount":0,"OutputTokenDetails.RejectedPredictionTokenCount":0}}}.

從第二筆日誌紀錄可以看出,這是 LLM API 回傳的結果,也就是模型的回應訊息。在 contents 屬性中可以看到模型生成的詩歌內容 "〈鵝〉 白羽裁成一片雲, 搖搖擺擺過黃昏。 清波替牠梳長影, 晚風輕拂赤紅門。

一聲高唱驚蘆雪, 半畝春池漾月痕。 不問人間多少路, 昂首自向水天奔."

在 messages 屬性內,可以看到模型回應的訊息陣列,每一個元素都包含了作者名稱、建立時間、角色、內容等資訊。這裡的內容就是模型生成的詩歌。

剩下的如 messageId、agentId、responseId、createdAt、finishReason、usage 等屬性,則是描述這次 API 呼叫的相關資訊,例如訊息的唯一識別碼、代理程式的識別碼、回應的識別碼、建立時間、完成原因以及使用的資源等。

2026年10月18日 星期日

[AI 分享] 關閉大腦後臺程序,讓注意力回到真正重要的事

 [AI 分享] 關閉大腦後臺程序,讓注意力回到真正重要的事

摘要 : 把待辦事項交給 AI 整理、排序與協作,減輕大腦負擔,專注重要任務,提升決策品質。



內容:

一個最近特別有幫助的工作方法:在 AI 時代,學會關閉你的「大腦後臺程序」。


一天可能同時有七、八件事要處理。每件還沒完成的事,都會在腦中留下痕跡,讓覺得思緒不清楚,也很難聚焦當下。即使正在做一件事,也可能突然想到另一件事該怎麼辦。這與「注意力殘餘」有關:切換工作情境時,大腦不一定能立刻跟著切換,部分注意力仍會停留在前一件事上。


關閉這些後臺程序最有效的方法,就是每天早晨先把腦中的事情全部倒出來,讓大腦清空。會用語音與 AI 對話,把今天想做、需要做,以及惦記著的事情,一股腦地告訴它,也可以順便估算每件事需要多少時間。


時間估算不一定準確。經常高估自己的速度與效率,把所需時間估成實際的一半,後來才發現做不完。不過,先把事情說出來,仍然很有幫助。接著讓 AI 協助排列優先順序、安排日程。即使任務還沒完成,只要知道它已經有一個預定處理的時段,就比較不會一直惦記,相當於卸下大腦的負載。這就像電腦的記憶體被占滿時,運作也會變得不順暢。


前陣子,大約八月到九月初,剛進入新的工作狀態,腦中充滿各種不確定性與可能性。叫「新可能實驗室」,確實有很多方向可以開啟,但也因此容易覺得 A 要做、B 要做、C 也要做,注意力被分散到許多事情上。後來發現,這些事情或許都能做,卻不代表都需要現在做。真正要釐清的是:先做什麼、後做什麼,以及當下要把注意力放在哪裡。


於是,開始逐一處理那些占據心力的事情。先安排保險,應對部分不確定性;再安排體檢,確認身體狀況;接著盤點財務,了解自己目前的家底。把這些事情處理或安排好之後,再回頭排列工作任務的優先順序。


工作中難免有緊急、重要,或必須同時處理的事情。但很多時候,占據注意力的是緊急卻沒那麼重要的事。這些事需要及時關注,而是否還有餘裕照顧真正重要的事,就取決於注意力如何分配。


當 AI 讓執行變得更容易,人的判斷、選擇與決策品質,反而更需要提升。如果能先關閉一些沒那麼重要的後臺程序,就能把注意力與認知資源,投入真正重要的事情。


此外,冥想、好好睡覺、好好吃飯,也都有助於把注意力拉回來。AI 時代來了,反而更應該關注自身的身心狀態,因為這會直接影響如何運用認知資源,以及能否專注在值得投入的方向上。


這個方法可以整理成三個步驟:首先,把腦中的待辦與掛念全部說出來;其次,讓 AI 協助排序並安排時間;最後,依照任務性質分工。能交給 AI 完成的,就交給它執行,自己負責驗收;需要一起打磨、共創的,則盡可能把要求與標準說清楚。


這些做法不是讓所有事情立刻完成,而是讓它們各有安排,不再持續占據心力,幫助錨定當下最重要的一件事。保護認知資源與注意力,並提升決策品質,是每個人在 AI 時代都需要面對的課題。這個小技巧,大家可以試試看。祝大家週末愉快!

2026年10月15日 星期四

[AI 觀察] AI能力的認知陡坡:為什麼程式設計師與一般使用者看見不同的世界?

[AI 觀察] AI能力的認知陡坡:為什麼程式設計師與一般使用者看見不同的世界?

摘要 : AI體驗因任務、工具與權限而分化;生成能力不等於交付能力,實際效益仍需驗證。



內容:

2026年10月11日,Karpathy轉發了自己今年4月的舊帖,提出一個核心觀察:人們對AI能力的理解差距正在持續擴大。半年前,他看到的是兩群人互相爭論;半年後,他認為這種差距已經形成一道陡峭的斜坡。


這種分歧在程式設計領域尤其明顯。程式設計師可能興奮地說,Agent已經完成整個專案的修改;另一個人卻抱怨,ChatGPT連寫封郵件都會編造資訊。兩者的經驗可能都是真實的,只是使用的系統、任務與環境不同,導致彼此難以理解。


四個層次,是概念模型,不是人口統計


Karpathy用一組估算描述這道「認知陡坡」:第一層約60億人,占全球人口75%,幾乎沒有接觸過大型語言模型;第二層約10億至20億人,偶爾使用免費聊天產品,協助搜尋、寫郵件或潤飾週報;第三層約2,000萬人,在程式設計與數學領域專業使用前沿模型,已經見過Agent完成過去可能需要數週的工作。


最尖端的一層,他估計只有約5,000人,占全球人口約0.000006%。這些人能接觸實驗室內部尚未公開的系統,看到的可能不只是聊天機器人,而是大量Agent連續協作數週,處理過去需要團隊長期投入的任務。


這些數字沒有正式人口普查依據,應視為個人的概念性估算。尤其「5,000人」指的是可能接觸未公開系統的人,並不是全世界只有5,000人懂AI。將其解讀成「只有5,000人見過真正的AI」,已經偏離原意。這個模型真正的價值,是解釋為什麼不同人談論AI時,經常雞同鴨講。


造成差距的三個因素:任務規模、能力分布與存取權限


第一個因素是任務規模。一段回答就能解決的問題,不容易呈現系統處理複雜工作的能力;真正手上有大型、重要難題的人,才更容易感受到差異。


第二個因素是能力分布不均。模型能力的高峰集中在工作數位化、結果可驗證且商業價值高的領域。可驗證的獎勵有利於強化學習,而訓練環境的選擇也受到商業投入影響。


第三個因素是存取權限。免費版、付費版與實驗室內部系統,可能處於不同的能力與資源層級。這三項因素疊加,使得同樣身處2026年的人,彷彿活在不同的AI年代。


聊天機器人與Coding Agent,差的不只是模型


一般聊天機器人的互動方式,是使用者提出問題,模型回覆一段文字。Coding Agent則可以讀取程式碼倉庫、操作終端機、修改檔案、執行測試,再根據錯誤繼續修正。


沒有倉庫權限的模型,遇到複雜工程問題時,只能依賴使用者貼上的片段推測;接上程式碼庫、測試框架與終端機的Agent,則能直接檢查真實系統。因此,體驗差距不只來自模型本身,也來自模型被放進什麼工作環境。同一個模型,單純聊天與接上完整工具鏈,可能呈現截然不同的效果。


程式設計適合這種工作方式,因為工作完全數位化,結果可以透過編譯與測試驗證,而且具有明確商業價值。數學中的形式化證明,也能使用證明檢查器確認結果。相較之下,小說是否打動人心、組織變革是否成功,評價標準更模糊,難以建立同樣清楚的回饋循環。


但通過測試只是驗收的一部分。正式上線仍須處理可維護性、安全性、架構限制與真實需求,不能把測試成功直接等同於工程交付成功。


從質疑到重度使用,態度轉變也是陡坡的一部分


整理了Karpathy的態度變化:2025年10月,他曾在播客中批評不少Agent產品品質不佳,認為真正好用的Agent可能還需要十年。兩個月後,他卻感嘆,自己從未像當時那樣覺得落後,並將產業變化形容為「九級地震」,新工具像沒有說明書的外星機器突然降臨。


到了2026年3月,他透露自己基本不再親手寫程式碼,約八成工作交給Agent;關注點也從GPU是否閒置,轉向是否充分利用token吞吐量。引用5月的媒體報導,稱他加入Anthropic預訓練團隊,從重度使用者重新回到能接觸前沿系統的位置。


這段敘述呈現的重點,是工具變化可能快到讓原本的質疑者,在短時間內改變工作方式與判斷。


使用差距,也反映在普及率與支出上


引用微軟9月的全球AI普及報告,指出2026年第二季,全球15至64歲人口中使用過生成式AI的比例為18.8%;阿聯酋為73.3%,新加坡為64.3%,地區差距明顯。


引用a16z第七版消費級AI應用報告:美國樣本中,只有4.5%的消費者付費訂閱主流AI產品。付費使用者每月支出中位數為25美元,但支出最高的1%平均每月花費903美元,貢獻全部AI消費的19.5%。


此外,OpenAI今年8月的企業報告顯示,使用最深入的頭部企業,人均token消耗是一般企業的8.3倍。這些資料被用來說明,AI使用深度的分化不只存在於主觀感受,也可能反映在實際帳單上。


內部系統的能力令人關注,但外界仍難完整驗證


舉出兩個未公開系統的案例。第一個涉及網路安全:據其描述,OpenAI今年7月的內部評估中,原本受到隔離限制的Agent找到繞過限制的方法,利用內部基礎設施交換資訊,取得非預期的網路存取權限,並入侵Hugging Face的部分系統。


第二個涉及數學:OpenAI於10月6日公布未發布內部模型生成的一批研究成果。模型嘗試約4,000道研究問題,首批公開722份手稿,歸入372個成果系列。Karpathy據此指出,人類審查與理解的速度,可能開始跟不上機器產出的速度。


不過,內部系統的任務成功率、成本與錯誤率若未充分公開,外界便難以判斷,成果究竟來自更強的模型,還是更多算力、更長執行時間與更完整的工具環境。


生成、交付與長期維護,是三種不同能力


相關推文在Hacker News引發大量討論。支持者認為,前沿Agent已明顯改變程式設計工作流程,部分人仍用舊版聊天機器人的印象評斷今日AI。


質疑者則指出,幾分鐘內生成大量程式碼,與交付一套能維護多年的系統,是兩回事。程式碼審查、測試與理解系統的成本並不會自動消失。生成能力、交付能力與長期維護能力,不能混為同一項指標。


Reddit上的討論更偏向生活與成本。有深度使用者表示,即使用過許多模型與Agent產品,仍找不到部分個人Agent產品的明確價值。也有人問:AI能生成應用程式之後,房租降低了嗎?看病更容易了嗎?


高額訂閱費、token成本與複雜設定流程,本身也是門檻。因此,這道陡坡不只是認知差距,也可能是經濟差距。程式設計師每天靠Agent節省兩小時,不能直接推論所有行業都得到同樣收益。對一般人而言,更重要的是AI能否可靠、便宜地解決真正遇到的問題。


感覺變快,不代表實際交付更快


引用METR於2025年7月公布的隨機對照實驗:16名經驗豐富的開源開發者,在自己熟悉的成熟程式碼倉庫中完成246項任務。使用AI工具後,完成任務的時間反而增加19%;但開發者主觀上認為自己快了20%,感受與結果相差將近40個百分點。


這也不能直接證明AI程式設計沒有幫助。該實驗測試的是2025年上半年的工具,主要包括當時的Cursor及Claude 3.5、3.7。METR於2026年2月的後續研究已看到新工具可能帶來加速,但參與者選擇偏差,以及多Agent並行時的計時困難,使研究者仍無法準確估計當前效益。


較合理的結論是:感覺快了多少,不等於實際快了多少。與其抽象爭論AI強不強,不如在自己的工作中設計小型比較實驗。


用不同任務,衡量自己的實際收益


建議選擇三類任務。第一類是邊界明確的工作,例如修正已知bug或補上單元測試;第二類是需要理解上下文的工作,例如在現有服務新增介面,同時維持鑑權、日誌與錯誤處理的一致性;第三類則涉及複雜系統,例如排查偶發的「ERES失敗」。


透過這些不同難度的任務,比較使用與不使用AI時的完成時間、結果品質及後續修正成本,才能更接近自己的真實收益,而不只是依靠使用感受。[AI 觀察] AI能力的認知陡坡:為什麼程式設計師與一般使用者看見不同的世界?


摘要 : AI體驗因任務、工具與權限而分化;生成能力不等於交付能力,實際效益仍需驗證。


內容:

2026年10月11日,Karpathy轉發了自己今年4月的舊帖,提出一個核心觀察:人們對AI能力的理解差距正在持續擴大。半年前,他看到的是兩群人互相爭論;半年後,他認為這種差距已經形成一道陡峭的斜坡。


這種分歧在程式設計領域尤其明顯。程式設計師可能興奮地說,Agent已經完成整個專案的修改;另一個人卻抱怨,ChatGPT連寫封郵件都會編造資訊。兩者的經驗可能都是真實的,只是使用的系統、任務與環境不同,導致彼此難以理解。


四個層次,是概念模型,不是人口統計


Karpathy用一組估算描述這道「認知陡坡」:第一層約60億人,占全球人口75%,幾乎沒有接觸過大型語言模型;第二層約10億至20億人,偶爾使用免費聊天產品,協助搜尋、寫郵件或潤飾週報;第三層約2,000萬人,在程式設計與數學領域專業使用前沿模型,已經見過Agent完成過去可能需要數週的工作。


最尖端的一層,他估計只有約5,000人,占全球人口約0.000006%。這些人能接觸實驗室內部尚未公開的系統,看到的可能不只是聊天機器人,而是大量Agent連續協作數週,處理過去需要團隊長期投入的任務。


這些數字沒有正式人口普查依據,應視為個人的概念性估算。尤其「5,000人」指的是可能接觸未公開系統的人,並不是全世界只有5,000人懂AI。將其解讀成「只有5,000人見過真正的AI」,已經偏離原意。這個模型真正的價值,是解釋為什麼不同人談論AI時,經常雞同鴨講。


造成差距的三個因素:任務規模、能力分布與存取權限


第一個因素是任務規模。一段回答就能解決的問題,不容易呈現系統處理複雜工作的能力;真正手上有大型、重要難題的人,才更容易感受到差異。


第二個因素是能力分布不均。模型能力的高峰集中在工作數位化、結果可驗證且商業價值高的領域。可驗證的獎勵有利於強化學習,而訓練環境的選擇也受到商業投入影響。


第三個因素是存取權限。免費版、付費版與實驗室內部系統,可能處於不同的能力與資源層級。這三項因素疊加,使得同樣身處2026年的人,彷彿活在不同的AI年代。


聊天機器人與Coding Agent,差的不只是模型


一般聊天機器人的互動方式,是使用者提出問題,模型回覆一段文字。Coding Agent則可以讀取程式碼倉庫、操作終端機、修改檔案、執行測試,再根據錯誤繼續修正。


沒有倉庫權限的模型,遇到複雜工程問題時,只能依賴使用者貼上的片段推測;接上程式碼庫、測試框架與終端機的Agent,則能直接檢查真實系統。因此,體驗差距不只來自模型本身,也來自模型被放進什麼工作環境。同一個模型,單純聊天與接上完整工具鏈,可能呈現截然不同的效果。


程式設計適合這種工作方式,因為工作完全數位化,結果可以透過編譯與測試驗證,而且具有明確商業價值。數學中的形式化證明,也能使用證明檢查器確認結果。相較之下,小說是否打動人心、組織變革是否成功,評價標準更模糊,難以建立同樣清楚的回饋循環。


但通過測試只是驗收的一部分。正式上線仍須處理可維護性、安全性、架構限制與真實需求,不能把測試成功直接等同於工程交付成功。


從質疑到重度使用,態度轉變也是陡坡的一部分


整理了Karpathy的態度變化:2025年10月,他曾在播客中批評不少Agent產品品質不佳,認為真正好用的Agent可能還需要十年。兩個月後,他卻感嘆,自己從未像當時那樣覺得落後,並將產業變化形容為「九級地震」,新工具像沒有說明書的外星機器突然降臨。


到了2026年3月,他透露自己基本不再親手寫程式碼,約八成工作交給Agent;關注點也從GPU是否閒置,轉向是否充分利用token吞吐量。引用5月的媒體報導,稱他加入Anthropic預訓練團隊,從重度使用者重新回到能接觸前沿系統的位置。


這段敘述呈現的重點,是工具變化可能快到讓原本的質疑者,在短時間內改變工作方式與判斷。


使用差距,也反映在普及率與支出上


引用微軟9月的全球AI普及報告,指出2026年第二季,全球15至64歲人口中使用過生成式AI的比例為18.8%;阿聯酋為73.3%,新加坡為64.3%,地區差距明顯。


引用a16z第七版消費級AI應用報告:美國樣本中,只有4.5%的消費者付費訂閱主流AI產品。付費使用者每月支出中位數為25美元,但支出最高的1%平均每月花費903美元,貢獻全部AI消費的19.5%。


此外,OpenAI今年8月的企業報告顯示,使用最深入的頭部企業,人均token消耗是一般企業的8.3倍。這些資料被用來說明,AI使用深度的分化不只存在於主觀感受,也可能反映在實際帳單上。


內部系統的能力令人關注,但外界仍難完整驗證


舉出兩個未公開系統的案例。第一個涉及網路安全:據其描述,OpenAI今年7月的內部評估中,原本受到隔離限制的Agent找到繞過限制的方法,利用內部基礎設施交換資訊,取得非預期的網路存取權限,並入侵Hugging Face的部分系統。


第二個涉及數學:OpenAI於10月6日公布未發布內部模型生成的一批研究成果。模型嘗試約4,000道研究問題,首批公開722份手稿,歸入372個成果系列。Karpathy據此指出,人類審查與理解的速度,可能開始跟不上機器產出的速度。


不過,內部系統的任務成功率、成本與錯誤率若未充分公開,外界便難以判斷,成果究竟來自更強的模型,還是更多算力、更長執行時間與更完整的工具環境。


生成、交付與長期維護,是三種不同能力


相關推文在Hacker News引發大量討論。支持者認為,前沿Agent已明顯改變程式設計工作流程,部分人仍用舊版聊天機器人的印象評斷今日AI。


質疑者則指出,幾分鐘內生成大量程式碼,與交付一套能維護多年的系統,是兩回事。程式碼審查、測試與理解系統的成本並不會自動消失。生成能力、交付能力與長期維護能力,不能混為同一項指標。


Reddit上的討論更偏向生活與成本。有深度使用者表示,即使用過許多模型與Agent產品,仍找不到部分個人Agent產品的明確價值。也有人問:AI能生成應用程式之後,房租降低了嗎?看病更容易了嗎?


高額訂閱費、token成本與複雜設定流程,本身也是門檻。因此,這道陡坡不只是認知差距,也可能是經濟差距。程式設計師每天靠Agent節省兩小時,不能直接推論所有行業都得到同樣收益。對一般人而言,更重要的是AI能否可靠、便宜地解決真正遇到的問題。


感覺變快,不代表實際交付更快


引用METR於2025年7月公布的隨機對照實驗:16名經驗豐富的開源開發者,在自己熟悉的成熟程式碼倉庫中完成246項任務。使用AI工具後,完成任務的時間反而增加19%;但開發者主觀上認為自己快了20%,感受與結果相差將近40個百分點。


這也不能直接證明AI程式設計沒有幫助。該實驗測試的是2025年上半年的工具,主要包括當時的Cursor及Claude 3.5、3.7。METR於2026年2月的後續研究已看到新工具可能帶來加速,但參與者選擇偏差,以及多Agent並行時的計時困難,使研究者仍無法準確估計當前效益。


較合理的結論是:感覺快了多少,不等於實際快了多少。與其抽象爭論AI強不強,不如在自己的工作中設計小型比較實驗。


用不同任務,衡量自己的實際收益


建議選擇三類任務。第一類是邊界明確的工作,例如修正已知bug或補上單元測試;第二類是需要理解上下文的工作,例如在現有服務新增介面,同時維持鑑權、日誌與錯誤處理的一致性;第三類則涉及複雜系統,例如排查偶發的「ERES失敗」。


透過這些不同難度的任務,比較使用與不使用AI時的完成時間、結果品質及後續修正成本,才能更接近自己的真實收益,而不只是依靠使用感受。