AI 加速了產品開發的節奏，PO 可以快速產出可動原型。但在需求這一關，有一個比較少被討論的副作用：虛假共識——一群人對著同一個能跑的原型一起點頭，以為講的是同一件事，其實各自理解可能都還是有所差異，而一部份沒人拍板的決定，AI 卻默默的替我們決定了。
這場分享會以一份看起來夠完整、可以開工的真實需求為例，說明虛假共識在實務上如何發生；並提供一套可以獨立使用的自檢方法，讓個人在把需求交付出去之前，先做一輪初步篩選。
適合需要把需求交付給開發團隊、且關心「需求模糊導致返工」的 PM／PO／BA、QA 與 Scrum Master。
你會帶走什麼
除了觀念，這場會提供一套可以獨立操作的「自檢四步」，用來在交付前初步篩出藏在需求裡的虛假共識：
① 視角：問題多半不在單一規則裡，而在規則的交叉點與臨界線上；先知道往哪裡找，是第一步。
② 辨識（無尾熊）：逐條檢查規則有沒有寫出「需求方要的結果」；沒寫出來的地方，往往就是 AI 代為決定之處。
③ 檢查（邊界三點）：對任一有門檻的規則，用剛好踩線、線內一格、線外一格三點去測。多數規則只定義了門檻，卻沒交代臨界值本身算不算，而剛好踩線那一點，測的就是這件事。
④ 定案（從結果倒著寫）：把一個還沒人拍板的決定，用一條具體實例固定下來。
此外，這場也會把「虛假共識」講成一個能清楚說明的概念，包括它為什麼比一般的 bug 更難被發現。
形式：45 分鐘分享 + 15 分鐘 Q&A，含現場 AI 示範與現場互動。
分享大綱
- 虛假共識從何而來 — 當「看起來講清楚了」遇上一個不會主動提問的 AI
- 現場拆解 — 以一份「完整」的需求為例，看 AI 補上了哪些未定義的決定
- 可帶走的方法 — 無尾熊辨識、邊界三點、從結果倒著寫：一套需求邊界的自檢四步
- 真共識怎麼建立 — 不是對著畫面點頭，而是把分歧攤開、由需求方確認後決定
適合誰來？
- PM / PO / BA、QA、Scrum Master，以及任何需要把需求交給開發團隊的人
- 特別適合「需求寫得很細、卻仍經常返工」而感到困惑的資深工作者
- 用過 BDD / Gherkin、後來因維護成本而放棄的人
分享者 / 林承毅（Jed Lin）
ClearForge 躍準科技創辦人。 同時經歷軟體開發、技術管理與產品管理經驗，領域包括線上博奕、HR SaaS 與企業軟體。專長領域驅動設計（DDD）、遺留系統重構與高並發架構設計。 目前為獨立顧問，專注於提供產品思維的軟體客製服務，以及協助技團隊導入 AI 輔助開發流程（Agentic Coding）。
要收費嗎?
- 本次不收費，無收據/發票。
- 本活動現場無茶點提供，建議用過餐再來！
注意事項
- 報到時間是19:00，活動開始時間是19:30，大約有15分鐘時間讓大夥兒閒聊天交誼一下。
- 逸空間換地方囉！是信義安和站，不是中山國中站，不要走錯囉！
為何要填寫公司/職稱資訊?
填寫正確公司資訊可以讓講者對大家有所認識;填寫正確的職稱可以讓講者在分享前大致理解該講深入點還是笑話多一些？！ 所以請大家幫忙填寫正確的公司/職稱資訊。
關於主辦者
Agile.Taipei 是一群對敏捷思維與方法的推廣有熱情或是狂熱的人所組成，我們不隸屬於任何其他社群/組織/企業，我們期待藉由各種形式的經驗分享和技術交流，能讓在北北基地區工作生活的夥伴們能接觸新思維，工作能更快樂。
台北敏捷社群: agile.taipei
-
Facebook 粉絲專頁
https://fb.agile.taipe -
Instagram
https://ig.agile.taipei -
Threads
https://threads.agile.taipe -
Linkedin
https://linkedin.agile.taipei/