飞书 OKR 草稿
目标與邊界
把多源工作事實整理成可討論、可衡量、可對齊的飛書 OKR，並在用戶明確授權後寫入草稿、艾特對應協作者。接口用於提速，飛書頁面、歷史文檔、截圖、用戶粘貼內容和工作總結同樣是有效輸入。默認先完成判斷和草稿，不創建、不發布、不修改現有 OKR。
遵守三條底線：
- 不憑空補目標值、基線、截止日期、負責人、業務結果或對齊對象；缺失信息寫成
[待確認]。 - 把草稿、寫入、保存、發布分開報告；沒有讀回證據就不宣稱完成。
- 涉及敏感收入、成本、客戶、人員或戰略數據時，優先使用經確認的比例、區間、完成率或脫敏表達，並標註需要單獨溝通的部分。
工作流
1. 判定任務模式
識別用戶要做的是：
- 從工作筆記生成新草稿；
- 改寫已有 O/KR；
- 審閱質量和對齊關係；
- 將草稿寫入飛書；
- 在週期中調整目標、KR、權重或截止時間。
沒有明確寫入意圖時，停留在只讀和草稿模式。
2. 建立上下文與資料路徑
先閱讀 lark-shared 和 lark-okr 的當前版本說明。需要讀飛書內容時，執行身份、租戶和權限核驗：
lark-cli auth status --json --verify
lark-cli contact +get-user --as user
支持 auth status --json --verify 的環境必須確認 identity=user、verified=true。當前 CLI 構建若沒有 auth 子命令，可退回 contact +get-user --as user 解析當前用戶；需要繼續草稿模式時，再用 task +get-my-tasks --as user 證明 user-context 可讀。真正寫入 OKR 或 @ 協作者前，仍要確認目標用戶和租戶。
按以下順序選擇可用資料路徑，不能把“接口不可用”當作任務終點：
- 接口/CLI 路徑：權限允許時，用接口批量讀取週期、O/KR、指標、進展和對齊關係。
- 飛書頁面路徑：接口缺失、scope 不足或需要確認頁面保存狀態時，使用
control-in-app-browser。優先接管用戶當前已打開的 OKR 頁面；沒有可用頁面時，只做一次明確的飛書 OKR 入口導航。依據可見頁面讀取，不猜測 URL、字段順序或按鈕含義。 - 用戶材料路徑：讀取用戶提供的文本、截圖、文檔、會議紀要、績效總結、H1 自評和工作復盤。
- 飛書文檔路徑：搜索並讀取當前租戶可訪問的 OKR 制定、撰寫、對齊、填寫助手和崗位示例文檔。
接口成功時也要結合頁面或原文核驗關鍵狀態；頁面成功時也要保留頁面事實，不因無法形成 API ID 就丟棄證據。
按需獲取：
- 當前用戶的目標週期：
okr +cycle-list； - 週期下的 O/KR：
okr +cycle-detail； - O 的指標、KR 的指標：
objective.indicators list、key_result.indicators list； - O 的對齊關係：
objective.alignments list； - 相關進展記錄：
okr +progress-list； - 相關飛書文檔：搜索
OKR、制定、撰寫、對齊、填寫助手，優先讀取當前租戶可訪問的規範與示例。
週期判斷以起止日期與當前日期的重疊為首要條件，再參考週期狀態；用戶沒有明確要求時，不把年度週期當作默認當前週期。
若 OKR 專用 scope 缺失，停止盲目重試，說明缺失的 scope 和影響。可繼續基於用戶提供的工作材料及有權限讀取的飛書文檔生成標註了上下文邊界的草稿。
2.1 使用歷史材料
歷史 OKR 是重點參考項。至少檢查最近一個已完成週期，條件允許時再看更早週期、進展記錄、評分、評論、績效總結和 H1 自評。
把歷史內容分成四類：
- 已完成事實：作為基線、能力證明或案例證據，不原樣抄成新 KR；
- 未完成或反覆出現的高優事項：作為本週期候選主線，重新定義階段結果；
- 上級或同事反覆提出的反饋：轉成質量、協作或機制類結果；
- 已經形成但尚未複製的能力：轉成規模化、標準化、他人可獨立運行或商業結果。
建立簡短的來源臺帳：事實 → 來源 → 時間 → 對新 O/KR 的作用 → 是否仍需確認。把過去的成績和未來的承諾分開。
2.2 讀取四類 OKR 關係上下文
寫當前週期 OKR 前，固定檢查以下四類關係；缺少接口時通過飛書 OKR 頁面、截圖、用戶粘貼內容或可訪問文檔補齊：
- 上週期本人完成情況：逐項對照 O/KR 的目標值、進度、評分、評論和實際結果。區分已完成、部分完成、未完成、目標變化和證據缺失；只把對本週期仍有意義的未閉環事項或新階段結果帶入。
- 本週期本人被 @ 的情況：收集在哪些 O/KR 被 @、來自誰、對應什麼協作期待、交付節點和責任邊界。把它們歸類為主責候選、協作者、需確認事項或信息性 @，不能把被 @ 自動理解為承諾。
- 上週期本人 @ 他人的情況：回看用戶曾 @ 的對象、對應 O/KR、協作內容和是否完成閉環。識別持續依賴、重複找人、協作失配和可以沉澱為機制的關係；本週期只保留仍然有效的協作關係。
- 直屬上級 OKR：確認直屬上級身份、當前週期、O/KR 順序、重點結果、指標口徑和協作邊界。判斷個人 O 是承接、支撐、橫向協作還是獨立主線；上級 OKR 缺失、週期不明或身份無法核驗時標註邊界，不自行推斷。
建立關係臺帳：關係類型 → 來源對象 → O/KR → 對方/協作者 → 事實或期待 → 本週期處理 → 是否已確認。四類信息分別作為“歷史結果”“協作輸入”“協作回溯”“縱向承接”使用，避免混成一張待辦清單。
3. 收集最小必要輸入
至少確認：週期、角色或責任範圍、要達成的業務結果、已知基線、目標值或判斷標準、主要協作方、約束和敏感信息。
已有上級或團隊 OKR 時，先識別：
- 哪些 O 需要承接；
- 哪些 KR 是同級協作；
- 哪些工作屬於用戶主責，哪些屬於協助；
- 用戶提出的工作是否與已有 O 重複或存在衝突。
若存在直屬上級，直屬上級當前週期 OKR 是縱向承接的首要參照；團隊 OKR、同級 OKR 和被 @ 內容用於補充承接範圍與協作邊界。被 @、@ 他人和“看起來相關”都只能形成候選關係，只有內容、主責、週期和雙方確認共同成立時，才報告為已對齊。
缺少關鍵輸入時，用最少的問題補齊；仍無法確認時繼續產出，但把不確定性顯式放入 [待確認]。
4. 生成草稿
O 的寫法
- 聚焦高優、高價值工作，排除日常職責堆砌；建議 3–5 個，工作範圍較窄時允許更少。
- 寫清方向、預期價值和時間範圍；保持顆粒度適中，避免口號化或任務清單化。
- 保留一定挑戰性，避免把“繼續做”當成目標。
- 對長期事項拆成當前週期的階段性結果。
- 使用讀者第一次閱讀就能理解的業務詞彙；沿用組織已確認的專有名詞。
當用戶一次列出多件項目或戰役時，先按業務結果聚類，再決定 O 的數量。項目名稱通常進入 KR、實現路徑或證據欄；只有代表獨立結果主線時才單獨成為 O。常見聚類方向包括客戶/商業結果、端到端流程效率、產品化與複製、組織機制與影響力。
KR 的寫法
- 每個 O 建議 3–5 條，分別覆蓋不同的關鍵支撐面。
- 先寫結果和狀態，再補充必要的實現路徑；避免只寫“完成、負責、推進、跟進”。
- 給出客觀可觀察的定性或定量判斷標準；“提升、優化、增強”後面補足起點、終點或驗收條件。
- 寫明週期內時間節點；目標值未知時保留
[目標值待確認]。 - 在需要協作時標明主責、協作者和責任邊界；主要協同人一般不超過 4 人。
- 如需解釋 KR 的方向，使用簡短小標題，例如
【客戶價值】、【流程提效】，避免把多條主線揉成一條。
優先按以下結構組織一條 KR：
【關鍵方面】通過[必要路徑]，於[時間節點]達到[可觀察結果/目標值]，由[主責]負責，@ [協作者]協同。
路徑過長時刪減；結果、時間和驗收標準必須保留。
5. 執行質量檢查
逐條檢查 O 和 KR，並把問題分成“阻塞發布”和“建議優化”。詳細規則見 references/okr-writing-principles.md。
重點檢查：
- O 是否高優、清楚、適度挑戰，是否對應當前週期；
- KR 是否直接支撐 O，是否描述結果，是否可衡量、可實現、有時間邊界；
- KR 之間是否重複、漏掉關鍵支撐面或互相衝突；
- 目標值、基線、日期和負責人是否有來源；
- 是否存在縱向承接、橫向協作、明確主責和實際對齊對象；
- 是否已核對上週期完成度、本週期被 @、上週期 @ 他人和直屬上級 OKR；
- 是否保持目標順序、專有名詞、隱私和敏感信息口徑一致；
- 是否把分數、進度、權重和目標值混為一談。
6. 輸出草稿
按以下順序交付：
週期與上下文：使用了哪些週期、上級 O、文檔和用戶輸入；說明讀取邊界。OKR 草稿：每個 O 下列出 KR、結果標準、時間、主責、協作方和證據來源。歷史承接：哪些歷史事實變成基線，哪些事項延續，哪些成果被提升為複製或規模化結果。關係與承接清單：上週期完成度、本週期被 @、上週期 @ 他人、直屬上級承接、建議 @ 的對象、衝突和待溝通事項。質量診斷：阻塞項、建議優化項、尚未驗證的假設。待確認：只列會改變目標含義、結果標準或系統寫入的事項。
禁止用一套看似完整的數字掩蓋不確定性。質量判斷應解釋“為什麼這條 KR 能證明 O 達成”。
7. 寫入飛書
只有用戶明確要求寫入或保存時才執行寫操作。寫入前：
- 再次確認當前用戶、租戶、週期、目標歸屬和完整草稿；
- 建立“寫入與 @ 清單”：每個 O/KR 對應的協作者、@ 原因、主責邊界、來源和核驗狀態；
- 對姓名或郵箱逐個使用
lark-cli contact +search-user解析為open_id。命中多個候選、跨租戶或身份信息不足時暫停該條 @，要求確認，不能猜選； - 先用
--dry-run檢查請求； - 普通文本和 @ 優先使用
simple風格；需要精確控制 @ 位置時使用richtext的mention元素； - 新建多個 O/KR 優先使用
okr +batch-create，單個 O 或 KR 使用okr +create；將mention寫在對應 O/KR 上，避免把所有人集中 @ 在一個目標裡； - 不因“草稿”自動設置分數；分數只在用戶明確要求評分時處理；
- 寫入後重新讀取週期詳情，核對 O/KR 數量、正文、順序、權重、截止時間、mention 和保存/發布狀態；
- 讀回不完整、mention 未落地或系統語義可能直接發布時，停止並向用戶說明，不繼續推進。
寫入與艾特的判定
- 用戶只說“起草、生成、優化”時，只輸出本地草稿和 @ 建議清單。
- 用戶明確說“寫入、保存到飛書、幫我填入”時，可以創建草稿；用戶同時明確“艾特某人”或關係臺帳已有核驗通過的協作者時，才寫入 mention。
mention是真實用戶 ID，不是正文中的@姓名字符串。接口路徑將mention: ["ou_xxx"]放入對應 O/KR；頁面路徑使用用戶選擇器，並回讀頁面中的真實用戶標籤。- @ 主責、協作者、直屬上級要分別說明原因；僅因“相關”或“被 @”形成的候選關係，先進入待確認清單。
- 寫入結果分開報告：
已創建/已保存、已艾特、未艾特及原因、未發布。任何一項沒有讀回證據，都保留為待核驗。
接口無法寫入時，可在已登錄的飛書 OKR 頁面使用“批量粘貼 OKR”或頁面編輯控件保存草稿。頁面路徑必須遵守以下順序：
- 先確認當前用戶、週期和頁面標題；
- 粘貼 O/KR 後檢查解析預覽，確認 O/KR 數量和層級；批量粘貼無法生成真實 @ 時，改用頁面編輯控件逐條選擇協作者；
- 對每個需要 @ 的 O/KR 使用頁面用戶選擇器，核對顯示姓名與部門，避免只輸入普通文本
@姓名； - 只執行保存確認，不點擊發布；
- 回到最終頁面核對“已保存”、O/KR 正文和真實用戶標籤，並確認每個目標仍保留“發布”按鈕；
- 頁面彈窗關閉、保存提示缺失、@ 標籤未出現或字段數量異常時，重新讀取頁面，不宣稱保存成功。
對齊關係只作用於 Objective。創建對齊前確認兩個目標屬於不同目標、週期存在時間重疊且確有承接或協作關係；不要把“相關”直接寫成“已對齊”。完整流程見 references/okr-alignment-review.md。
參考資料路由
- 寫作原則、O/KR 診斷和反例：讀 references/okr-writing-principles.md。
- 會前、會中、會後對齊與衝突處理：讀 references/okr-alignment-review.md。
- 飛書 OKR 實體、讀取、寫入、權限和讀回：讀 references/feishu-okr-operations.md。