# Cory Landing Page Copy Deck ## Core Premise Cory 不是更多 AI 對話，而是一位會把模糊需求推進成團隊可 review 的成果，並陪你接續下一步的 AI 同事。 他懂數位工作，也懂軟體開發；他能先理解人的痛點與決策情境，再整理目標、限制、非目標與阻礙，最後交出可預覽、可驗證、可接手的版本。真正讓這件事成立的，不只有能力，還有合作體感與 Harness。 ## One-Line Versions - Cory 把模糊需求，交成團隊能 review 的成果。 - Cory 不只回應指令，而是幫團隊更早看見方向、少掉來回交接、保留驗證與風險線索。 - 能力讓他做事，合作體感讓他好接手，Harness 讓交付有證據。 ## User Problems - 主管想快看方向，但不想只收到一份想像中的答案。 - 產品與營運怕需求在轉交時失真，每次換人都要重講一次背景。 - 工程怕收到沒有邊界、沒有驗證、也沒有下一步的變更。 - 團隊想要 AI 速度，但不想犧牲治理、判斷權與交付品質。 ## Design Thinking Lens 1. Empathize：先釐清使用者、決策者、接手者各自的痛點。 2. Define：把一句模糊需求整理成目標、非目標、限制與成功標準。 3. Prototype：快速做出第一個能被打開、被討論、被修改的版本。 4. Validate：留下實際驗證結果與仍不確定的地方。 5. Handoff：把預覽、改動、驗證與剩餘風險放在一起，讓下一個人能接手。 ## Three-Layer Narrative ### 1. Capabilities 能力標籤回答的是：Cory 能做什麼。 - 把想法變成可檢視成果：首頁、提案頁、流程稿、內部工具與摘要，都能先推進到能被討論的一版。 - 理解數位工作怎麼卡住：看任務、工具、權限、狀態、溝通與交付之間的斷點，不只處理單一句指令。 - 軟體開發型 AI 同事：能讀程式、改程式、跑檢查、分析 bug，也理解 review 與接手需要什麼資訊。 - 阻塞處理者：遇到缺資料、權限不足或決策未定時，會說清楚卡點、選項與恢復路徑。 - 決策輔助者：在不確定時整理選項、取捨與風險，讓人拍板，而不是讓 AI 偷偷替人決定。 ### 2. Personality 合作體感回答的是：和 Cory 合作起來是什麼感覺。 - 可靠：目標是把事情真的往前推，而不是只給一段看起來完整的回答。 - 有條理：能把模糊需求拆成使用者、目標、障礙、選項、證據與下一步。 - 主動但不越界：會主動發現問題與提出修復路徑，但商業與治理決策仍交給人確認。 - 像好同事：會補位、回報進度、解釋取捨、記得上下文，而不是每次都從零開始。 - 務實：偏好可驗證、可落地、可維護的解法，不為了炫技犧牲清晰度。 ### 3. Harness Harness 回答的是：為什麼這些能力可以被可信地交付。 - Harness 是 Cory 的產品控制層，不讓能力停留在「好像很會」的敘事上。 - 它先定義目標、範圍與 non-goals，再要求 Cory 只做最小可信的變更。 - 缺資料時會回報 blocker，不假裝完成，也不自行越過治理邊界。 - 交付時會留下 preview artifact、changed files、verification 與 unresolved risks，讓人可以 review、接手與決策。 ## Homepage Copy ### Hero Headline Cory 把模糊需求，交成團隊能 review 的成果。 ### Hero Value Line 當產品、營運、工程還在反覆翻譯需求時，Cory 先釐清問題、補齊脈絡、做出第一版，讓討論回到真實畫面與證據。 ### Hero Body Cory 的價值不只是「產出更快」，而是幫團隊更早看見方向、少掉來回交接、保留驗證與風險線索。能力、合作體感與 Harness 一起工作，讓他像一位懂數位工作的 AI 同事，而不是另一個需要你管理的工具。 ### Hero Chips - 少一次需求翻譯 - 早一版可判斷成果 - 重要決策交給人，交付證據交給你 ## Section Copy ### Story Section 團隊卡住的通常不是 AI 會不會寫，而是需求怎麼被理解、交付怎麼被信任。 Cory 用 design thinking 的方式先回到人的問題：誰要決策、誰要接手、誰最怕風險失控。接著才把能力放進工作流，做出可檢視的版本。 ### Tabs Intro 首頁先講清楚 Cory 解決的痛點，再讓人看到能做的工作、合作體感與可信交付方式；更技術、治理與實作細節，集中在 `可信交付` 分頁。 ### Workflow Section Cory 的理想行為不是回得很快，而是讓團隊一步步更接近可判斷的答案。 - Empathize：先抓住誰真的需要被幫助。 - Define：把模糊需求框成可交付任務。 - Prototype：先做出第一個可判斷版本。 - Validate：把檢查與不確定講清楚。 - Handoff：讓下一個人能接手。 ### Missions Section 先從一個能被打開、被討論、風險可控的任務開始試跑。 - 首頁、產品頁與提案頁：把 value proposition、痛點、敘事與 CTA 先做成能 review 的版本。 - 內部工具與營運介面：讓欄位、狀態、流程與操作路徑先被看見。 - 小型功能、修正與驗證：適合明確、可控、需要交代清楚的工作。 - 跨部門成果摘要：把技術成果翻成主管與營運也能決策的內容。 ### Guardrail Section 主動，不代表越界。 - 重要商業與治理決策，仍由人拍板。 - 缺資料會停下來問，不把猜測包裝成完成。 - 未驗證的結果不會假裝穩定。 - 交付時留下團隊能接棒的上下文與證據。 ### CTA 帶一個真實需求來，先看 Cory 如何把它推到可判斷。 從 landing page、內部工具或低風險修正開始，讓團隊先感受到「像同事」的工作節奏，再決定要不要走得更深。 ## Alternate Headlines - Cory 把模糊需求，交成團隊能 review 的成果。 - 不是多一個聊天視窗，而是多一位會把工作推到可判斷的 AI 同事。 - 讓老闆更早看見方向，讓工程更安心接手變更。 - 不只會做事，還知道怎麼像好同事一樣合作。 ## Visual Direction Notes - Warm editorial canvas：用暖米色背景與深色產品面板，讓 Cory 更像值得合作的角色，而不是冷冰冰的內部系統。 - Serif display + humanist sans：主標更像品牌敘事，內文維持易讀與穩定。 - Dark product board：Hero 右側像一個「同事工作台」，不是工程監控畫面。 - Soft motion only where it matters：只保留頁面進場與 tab 切換的輕動畫，不做多餘互動。 ## Messaging Guardrails - 不把 Cory 描述成全自動取代團隊的系統。 - 不在首頁大量堆疊技術術語；技術內容集中在 `可信交付`。 - 不捏造客戶案例、未驗證數據或第三方背書。 - 不承諾部署、merge、治理批准或任何未經驗證的結果。