重點摘要

AI 應用分三個層次　對內鼓勵大家先用 AI 處理手上能做的工作，對外把 AI 做進產品（例如客服 Chatbot），最後才是調整公司文化與工作方式，三者要同時推進才算真正做到 AI-native。

依採用速度分眾溝通　早期採用者放手讓他們自己摸索並分享心得，多數人靠共用的基礎設施與工具支援（去年多用 Cursor，今年轉向 Claude Code），抗拒的人則要先理解他們的顧慮，同時把公司方向講清楚。

招募與考核標準轉向　找人更看重是否真心對 AI 有興趣、能不能獨立解決問題，工程師與 PM 的界線也變得模糊，績效考核開始納入「有沒有用 AI 放大貢獻」這一項。

規劃週期縮短到兩到四週　因為 AI 模型進步太快，三到六個月的中期規劃反而很難做，團隊改成用短衝刺交付、需求文件只寫一到兩頁，方向錯了就快速調整。

Code Review 制度重新設計　AI 讓工程師寫程式的量暴增，逐行審查跟不上，於是限制單一 PR 不超過 500 行、用 stacked PR 拆分大功能，簡單的 PR 可以自行決定要不要找人審查但仍要負責，同時嚴防「rubber stamp」式的盲目通過。

用分級驗證與人工抽查控管風險　容錯度低的場景（例如理賠金額）會用不同模型交叉比對結果，兜不攏就轉真人處理；上線後靠自動評分系統加人工抽查持續檢視對話品質，新功能上線時抽查比例會拉高。

值得記的話

there's no predefined playbook you can just follow and bingo you become AI native.

：沒有現成的劇本可以照抄就變成 AI-native

01:49

What we really need to focus on is what we want to deliver in the next two to four weeks.

：真正該聚焦的是接下來兩到四週要交付什麼

08:11

each PR shouldn't have more than 500 lines of code because nobody can do a meaningful code review.

：單一 PR 不該超過 500 行，不然沒有人能真的做好 code review

11:58

But if we help a user to submit their reimbursement claim, we cannot tolerate a failure, because if people ask of $200, we issue them 50, or they ask 50, we give them 200.

：但如果是幫用戶送出理賠申請，就不能容許失誤，因為金額算錯的後果很嚴重

14:26

時間軸　11 段

名詞與人物　6 個

提到但沒有展開

• 自動評分系統的評分規則（rubric）具體怎麼定，演講中只提到有預先定義的 rubric，沒有展開說明。
• 讓 AI 自動監控上線後流量、即時抓到問題並自動修復，講者提到這是還在進行中、尚未做到的方向。