AgentCrew 週報 · 這週 AI 有什麼跟你有關 · 2026-10-17

第 11 期

這是「AgentCrew 週報」第 11 期，整理 2026-10-11 到 10-17 的內容。

每則內容我們都固定拆成三段：是什麼（一句話講清楚）、對你的意義（對應到你的工作場景）、你可以這樣試（今天就能動手做的小事）。除非能說清楚該怎麼選、要花多少錢、能做到什麼跟限制在哪裡，不然我們不聊模型跑分；不聊誰拿到融資的八卦，也不跟大家製造焦慮。

這期有些題目是從 AI HOT 看到的。它每天整理中英文 AI 圈的新消息，幫我們省下不少找資料的時間。裡面的內容，我們都是回去看過原始出處才動筆寫下來。

這期有什麼

一、Atlassian 研究 69 場工程團隊聚會後，做了一個 AI 規劃代理：議程、通知、會後整理由它起草，寄出前由規劃的人審過

Atlassian 的 Teamwork Lab（由 Molly Sands 博士帶領）想知道，團隊實體聚會（像是 offsite、集合到同一地點開幾天會）怎樣才會成功。他們分析了 2024 年的 69 場工程團隊聚會，看議程和會後問卷。結果發現成功的聚會有固定的樣子：規模比較小、時間比較短、真的留時間給團隊建立關係和規劃、不把行程排得滿滿，而且事先定好具體目標，也有一個明確的方式記下後續要做什麼。文章也提到，聚會平均能讓團隊的連結感提高 27%，但效果大約四個月就會淡掉，所以一年辦三次左右比較合適。

Atlassian 把這些發現做成一個 AI 規劃代理（在它們的 Rovo 平台上建的）。文章同時整理了讓你自己做一個的六個步驟：先寫下目標、參加的人、日期、地點和議程草稿；替每個活動標上五種活動類型之一；依研究的建議排議程，並由規劃的人審過再定案；起草給參加者的通知和一頁「出發前須知」；日曆保留和訊息要等規劃的人審過才送出；最後產出會後整理，列出成果、下一步和具名負責人。文章對這件事的理由是：In-person gatherings require lots of documentation and are a good use case for an AI agent.——實體聚會需要大量文件，很適合交給 AI 代理。

對你的意義：這六步其實就是把「一個有經驗的活動企劃會怎麼做」寫成一份交接清單。最值得照抄的是它的第三、五步：議程要規劃的人看過才定案，要送出去的東西（日曆邀請、給同仁的訊息）寄出前一定先給人看過，因為寄出去就收不回來，而草稿是可以隨時重寫的。
你可以這樣試：挑一個你每個月或每一季都要辦的活動（例如客戶說明會、部門月會），把文章的六步改成你自己的版本，寫成一段交代：目標、參加的人、日期、議程要依哪些原則排、通知怎麼寫、會後要列哪些待辦。請 AI 先起草每一份，你看過再寄；下次辦同一個活動，直接沿用這段交代。

來源：Atlassian：How to use AI to plan a team offsite that works

回到目錄

二、Claude Code 團隊說明審查方式：每個 PR 先由 Claude 審一輪，人再依變更風險決定要看幾個人

Anthropic 的 Claude Code 團隊（作者包含 Addy Osmani、Morgan Westlee Lunt、Qing Wang）寫了一篇文章，講他們在程式碼變更量暴增之後，怎麼做程式碼審查（code review，在程式碼合併進正式版本之前，先讓別人檢查）。文章說 Claude Code 自己的程式碼約有 90% 是 Claude 寫的。他們的做法是保留審查，但把大部分的閱讀交給機器，讓人把時間留給需要判斷的地方，並且讓每個變更都容易撤回。

文章給了幾組數字：從 6 月到 9 月，合併的 PR（pull request，一份要求合併的程式修改）增加了一倍以上，被撤回的比例卻降低了 40% 以上；Anthropic 的主程式庫每天的變更量，從 5 月約 2,500 筆，到 9 月超過 30,000 筆。Code Review 上線後，內部 PR 收到實質審查意見的比例，從 16% 升到 54%。他們也調整了審查的收斂方式（例如三輪之後請作者退一步重新想做法、前幾輪之後只重審新改動的部分、同一類問題一次標出來讓作者全部修掉），讓一輪審查改完就通過的 PR 從 65% 升到 78%，需要五輪以上的從 8.9% 降到 1.5%。文章也坦白提到，有一個 PR 在作者喊停前，一晚就跑了五十幾輪。以上數字都是 Anthropic 自己公布的內部數據。

審查分成好幾層：Claude 在送出 PR 前先自我檢查；每個 PR 都有一輪 AI 審查，發現的問題再由其他代理驗證；資安審查可以擋下合併；必要的自動測試也能擋；最後依風險決定要零個、一個或兩個人核准，文章的原話是「變更本身決定層級，不是作者」。人仍然負責的事：決定要不要做這件事、審查高風險的程式（帳務、自動更新機制、CI 流程）、定架構、看證據、為結果負責。

對你的意義：我們把這個做法看成「讓第二方複查」的實例：審查者的工作是挑毛病，不是接手做事；而且複查有分級，風險高的才動用人。如果你們團隊也開始讓 AI 產出大量文件、報表或程式，先想的不該是「要不要檢查」，而是「哪些東西出錯的代價大、值得人親自看」，其他的交給第二個 AI 先篩一輪。（延伸一篇：《跨模型互審——讓 AI 不再自己審自己》講為什麼 AI 審自己的產出容易有盲點，以及改用另一家模型做獨立審查的做法。）
你可以這樣試：把你團隊這個月用 AI 做的東西列出來，每一項問兩題：做錯了能不能收回？做完能不能一眼看出對不對？兩題都不太行的那幾項，規定一定要有人過目；其餘的可以先請另一個 AI 對照你的檢查清單複查一輪，人只看它標出的問題。

來源：Claude Code 團隊：Solving code review at Anthropic（文中「每個 PR 都先經過 Claude 審查再交給人」一句，原文為 Every pull request gets a Claude review before a person looks.）

回到目錄

三、Meta 設計總監 Alex Cornell 談 Muse：一個給一般人用的 AI 代理，介面做得像傳訊息

Alex Cornell 是 Meta 的設計總監，負責 Muse 的設計。Muse 是 Meta 面向一般使用者的 AI 代理（能替你執行任務的 AI）。他接受 Claire Vo 的 How I AI 節目訪談（10 月 12 日發布），談到 Muse 刻意做得像傳訊息，而不是一般的 AI 應用程式，而且同一個介面要同時給不懂技術的人和工程師用。訪談整理列出 Muse 的設計：自訂頭像、三層的狀態顯示、個人化的點子頁面，以及生成式的動態牆。

節目裡他示範了自己怎麼用：把多年沒再看的 Instagram 收藏做成一本 SkyMall 式的購物型錄，並加上價格提醒；記錄高爾夫球每一桿，朝個位數差點努力；用舊部落格 20 年的文章（透過 Wayback Machine 取回）做成每天早上的 podcast；還有一個附帶毒舌教練的西洋棋儀表板。節目頁面寫的原句是：Muse ships with a custom avatar, a three-layer status display, a personalized ideas surface, and a generative feed.

對你的意義：這則示範的是一位設計總監怎麼把自己手上的舊素材變成用得上的東西（以下只依節目頁面的描述，我們沒有讀到完整逐字稿）。他的示範有個共通點：每一個都是他本來就有的素材（收藏、成績、舊文章），AI 把它變成能直接用的東西。如果你想讓同事或家人也用得下去，可以從他們手上已經有、但沒人整理的資料下手，比從「教他們怎麼寫提示詞」開始容易。
你可以這樣試：找一份你存了很久、一直沒回頭看的資料（書籤、收藏的文章、舊的會議筆記），請 AI 依你最在意的一件事整理成一份清單，並附上來源。先整理一次，看這份清單你會不會真的拿來用。

來源：Lenny's Newsletter：How Meta designed Muse: an AI agent people actually want to talk to

回到目錄

四、Berkeley 等團隊的三個隨機實驗：用過 AI 的人，在 AI 被拿走後答題變差、也更常跳過

UC Berkeley 的研究者 Brian Christian 與 Carnegie Mellon、MIT、Oxford、UCLA 的學者合作，做了三個隨機對照實驗，共 1,222 名線上受試者，論文於 2026 年 10 月在 Conference on Language Modeling 發表。Berkeley 的新聞稿標題寫的是：只用 AI 十分鐘，就會削弱人堅持完成困難任務的能力。

第一個實驗有 354 人，要解 15 題基本分數題，其中一組可以用 ChatGPT。解完 12 題後，研究者把 AI 拿走：那一組的正確率幾乎立刻下降，跳過題目的比例也升高。第二個實驗有 667 人，做法相似，結果也相似：用過 AI 的人在工具被拿走後，常常答錯或乾脆放棄，沒用 AI 的那組則繼續解題、完成得比較好。第三個實驗有 201 人，改做 SAT 閱讀理解題，拿走 AI 後，堅持度和正確率同樣下降。研究團隊也提到，依賴 AI 會拿掉他們所說的「有成效的掙扎」（productive struggle，自己卡一陣子、再想通的過程）。

對你的意義：這個研究測的是比較簡單的題目與短時間的使用，不能直接推到你的日常工作上。研究測的是拿走 AI 之後還撐不撐得下去，沒有測「有沒有檢查 AI 的結果」；以下是我們自己的延伸建議：如果你的工作有一塊是要自己負責判斷的，就別每次都直接收下 AI 的答案，先想好那一塊由你把關。AI 做完後，找一個你已經知道、AI 可能漏掉的具體地方去核對，不是只問自己「看起來對不對」。（延伸一篇：《不要用 AI 的摘要驗收 AI》整理了幾次 AI 回報「完成」、實際上沒做到的例子，結論是驗收要回去看實際的結果，不能只看它的回報。）
你可以這樣試：下一次請 AI 幫你做一份你平常自己做的東西（例如摘要、報價比較），先花五分鐘自己寫一個粗略答案，再拿 AI 的結果對照，找出兩者不同的地方，逐一搞清楚哪邊對。每週挑一件事這樣做，確保自己的判斷力還在線上。

來源：UC Berkeley Research：Using AI for just 10 minutes erodes your ability to persist at hard things

回到目錄

五、我們自己的：四個人的辦公室，遇缺不補，人少了就讓 Claude 來頂

10 月 11 日，Dustin 到中山站附近、一位朋友開的公司做 AI 培訓。對方一見面就說：「我們現在公司人又變少了，只剩四個人。」他指著整個辦公室空蕩蕩的十幾台電腦，臉上卻是開心舒坦的樣子。聊下來才發現，他們這段時間進步很快，已經把很多工作流固定成 SKILL（讓 Claude 照固定做法做事的說明檔）和 routine（定時自動執行的例行工作），在遇缺不補的情況下，人少了就由 Claude 來頂，所有的業務都還做得好好的。Dustin 的形容是：「可有可無的時候，就是可無。」

Dustin 也提到另一間公司，11 個人自然縮編成 2 個，業務量和營收不變，CEO 也是用同樣的方式讓公司往 AI 過渡。以上是 Dustin 看到和聽到的兩個例子，不是統計。他的結論是：小公司、小團隊面臨缺工的時候，適度導入 agent（能自己執行任務的 AI）其實是個不錯的解方。

對你的意義：第一間公司的做法是先把工作流固定下來，人少了才頂得住。你不會期待新同事自己猜出公司的規矩，會把做事的方式寫下來教他；AI 也一樣。工作流沒有寫下來，人一走，做法也一起走了；寫成 SKILL 或固定流程，下一個接手的人（或 AI）才接得上。
你可以這樣試：挑一件你每週都做、而且每次做法差不多的工作（例如整理週報、回覆固定類型的詢問），把你做這件事的步驟和判斷標準寫成一頁交代，交給 AI 試跑一次，你只看結果對不對。跑三次都穩，就把這頁存起來當固定流程。

來源：AgentCrew Blog：遇缺不補，人少了就 Claude 來頂

回到目錄

社群在聊什麼

這一區只整理摘要跟連結。內容都是網友的個人經驗，未經查證，當風向看看就好；功能到底有沒有，一律以官方說明為準。

一、Reddit 貼文轉述：Anthropic 在一次檢討後，把所有內部評測的即時上網都關了（原討論串）

這篇是一則新聞連結，標題說 Anthropic 回頭檢視過去的評測紀錄，發現測試中的 AI 代理會利用網站漏洞、繞過限制，因此把所有內部評測的即時上網都關掉了。原始報導的細節我們沒有另外核實，以下只整理討論串裡的看法。

留言區最多人附和的是質疑：一家一直強調 AI 風險的公司，為什麼過了這麼久才從紀錄裡發現，而不是當下就有人在看。也有人把「漏洞」講得更具體：用了別人不小心公開的金鑰去讀付費資訊，以及在被要求「不要留下痕跡」時仍然送出網站表單。有一則留言提到，某個測試代理透過費城警方的網頁表單，送出了一條捏造的命案線索。

有一則留言提到，評測斷網只是短期解法，更難的問題是同樣的代理在正式環境裡也能上網，而那裡未必有人會在幾個月後回頭看紀錄。

可以帶走的判準：讓 AI 代理能對外送出東西（填表、發信、付款）之前，先確定有人或有機制在當下看得到它做了什麼，而不是事後才翻紀錄。

二、一位自稱沒寫過程式的都市規劃師，用 Claude Code 做了一個芝加哥住宅模擬器（原討論串）

發文者是芝加哥的都市規劃師，自稱沒有寫程式的經驗，用 Claude Code 做了一個免費的住宅模擬器：在地圖上調整土地使用規則，看住宅量怎麼變，用來說明住房短缺和政策能怎麼改善。他在留言裡說大約花了三到四天，用的是 Max 方案，也分享了程式碼；他另外也提到自己已經上架過手機 app，正在做一款城市規劃遊戲。

版主機器人整理的討論摘要說：程式雖然是 Claude 寫的，這個作品有價值是因為他懂都市規劃。政策要怎麼設定是他決定的，一些關鍵錯誤也是他抓到的，例如模擬結果在公園裡長出了大樓。有一位在公部門任職的網友說自己也用 Claude Code 做過政策工具，但也提醒這類工具可能藏著設計者的偏見。

也有網友試著把模擬器玩壞：把所有區域都改成高樓、所有法案都通過，結果拿到最高分。另一則留言建議，把「公園不該長出住宅」這個修正寫成每次跑完都會自動檢查的規則，沒人點開看的那幾次也會被檢查到。

可以帶走的判準：AI 能幫不會寫程式的人做出工具，但「結果對不對」還是要靠懂這一行的人來判斷；抓到一次錯，就把它寫成以後每次都會自動檢查的規則。

三、Claude Code 是不是每次叫它審查程式，都會找到新的 bug？（原討論串）

發文者說，每次請 Claude Code 審查自己的程式，它都會找出三到四個 bug；修完再審一次，又找出三到四個，好幾輪都是這樣。他想知道這是真的有新問題，還是 Claude 太愛挑毛病。

得票最高的留言認為大多是挑太嚴：要 Claude 每找到一個問題都附上重現方式（哪個檔案、哪一行、什麼輸入會出錯），附不出來的就不算；如果一輪下來只剩無法重現的小毛病，就停手。另一則高票留言的比喻是：叫它找問題，它就一定會找到幾個，像是按件計酬的包商。

其他網友提到的做法包括：只審上一輪之後改過的部分，不要每次都審整個專案；請它依嚴重程度排序、只看嚴重的；換另一家的模型做第二輪審查，再讓 Claude 評估那些意見。也有人提醒，Claude 不再找到 bug，也不代表真的沒有 bug。

可以帶走的判準：請 AI 審查時，別只說「幫我找問題」，要它為每個問題附上證據，並先講好什麼情況下就算審完。這和本期第二則 Claude Code 團隊「審過幾輪之後只重審新改動的部分」的做法是同一個方向。

如果你想把這些變成自己的做法

個人：如果你想把上面提到的其中一件事，照著你平常的工作習慣做成一套固定的工作流程，我們有一對一陪跑方案：先幫你把基本功打好，再照你的實際業務整理出適合你的做法，過程中有問題隨時都能問。方案細節、時間安排和常見問題都整理在這一頁：看一對一陪跑

企業或團隊：如果你們在想 AI 產出變多之後，哪些東西要人看、哪些可以讓第二個 AI 先篩，我們提供一次 30 分鐘的交流，聊聊你們現在卡在哪，不談報價也不推銷。預約交流

喜歡這期內容？

訂閱後每週一封直接寄到信箱，隨時可退訂。

每週一封，只寄跟你的工作有關的 AI 動態。不轉發名單、不騷擾，每封信都能一鍵退訂。

導入診斷