廣東
本來想簡單寫寫，一不小心寫了 1.2 萬字。既是 skill 設計開發的教程，更是對“認知產品化”這個 AI 時代的核心命題的展開論述。
推薦產品經理閱讀，如果你只想學習如何使用 skill，可以退出了。
TL;DR：
1. AI 技術給產品設計帶來的革命性改變到底是什么？
2. Skill 的概念定義，看完能上手設計那種
3. Skill 的類型，如何封裝認知？
4. 使用 IPO 思維拆解和設計 skill
5. 極簡的 skill 設計流程：8 步
當我們聊“產品sense”時，具體在聊什么？
同樣一份需求，落到不同產品經理手里，最后很可能長成兩個東西。
新人讀完需求，開始畫流程。
資深產品經理會多停一會兒：用戶為什么要做這件事？現有方案卡在哪里？成功口徑是誰定的？數據從哪里來？出了問題誰兜底？
老板/用戶只說了一句話，他腦子里已經拉出一串待確認的問題。
這串問題很少完整地寫在崗位說明里。
它來自跑過的項目，是在一次次評審被追問之后慢慢積累起來的，我們管它叫“產品 sense”。
過去，我們轉移這類經驗的手段很有限。
你可以寫文檔“教學”，但讀者看懂以后，還得自己判斷何時使用。
你可以做培訓“分享”，課上聽得明白，換個項目又要重新消化。
核心是，如果學習的那個人沒有足夠的積累，摘到果子也沒法消化。
于是，認知長期依附在人身上。一個人帶著它開會、做判斷、改方案；這個人換崗，能力也跟著離開。公司留下幾十頁復盤，下一撥人繼續踩相似的坑。
AI 改變了這件事。
我們開始有機會把一套判斷方式交給機器：收到任務先收集哪些信息，遇到沖突按什么原則取舍，走到哪一步該找人確認，交付前用什么標準檢查。
Agent 可以讀取這些“判斷方式”，調用工具，操作文件，在過程中繼續向用戶提問。
它承接的已經不只是一條命令，還包括一個人完成任務時用到的經驗、流程與邊界。
簡單來說，認知和經驗可以被產品化了。
此刻，一套認知可以有清楚的適用場景，可以被安裝、調用和更新；能接受輸入，完成處理，產出結果；過去躺在某個人腦子里的方法，現在可以成為一份能運行的能力。
這是今天產品經理最應該關注的事情。
過去我們靠規則和流程把最佳實踐標準化成產品，但必須是可遍歷、有邊界、可以最終轉化成是否判斷的規則，因為程序直接收結構化的輸入。
今天，我們可以讓 AI 寫“魯迅風格”的文章、可以讓 Agent“看看還缺少哪些信息跟用戶澄清”、可以指定一個“爆款方法論”讓 AI 無限連復制流量、可以把專家對邊界的判斷寫成SKILL.md讓 Agent 一步一步驗證。
某Agent里內置的專家團 把方法論一點點搬進 AI
從大模型出現以來我們其實一直把“認知”塞給 AI，從提示詞到 Workflow 到 skills。
1. Prompt：先搬過去一段方法
最早大家到處收集的提示詞，最常見是帶有創作者思考框架的那種：
“你是一名資深產品經理。請從用戶價值、商業價值、實現成本、數據指標幾個維度分析以下需求……”
它輕、快、便宜，復制到對話框就能用。一個寫得好的 Prompt，確實能把方法論遷移一部分。
麻煩也很快出現。提示詞散落在聊天記錄、收藏夾和團隊文檔里；同事拿到后會刪幾句、添幾句，版本漸漸分叉；用戶還得知道什么時候貼哪一段，以及要補充哪些背景。
任務一長，模型會漏掉前面的要求。換個場景，原來的提示詞還得手工改。
某提示詞社區
Prompt 像一張寫給 AI 的操作便簽。它適合單次、邊界清晰的任務，卻很難獨自承載一套持續維護的能力。
確切講，它沒法被產品化。
2. Workflow：塞一條流程給 AI
后來，大家把模型接進工作流：第一步分類，第二步檢索資料，第三步生成內容，第四步寫入系統。
節點、條件和數據流都畫在畫布上，模型在指定位置完成指定動作。
Dify工作流
Workflow 解決了不少穩定性問題。業務人員不用反復復制提示詞，團隊也能看見任務走到了哪里。報表生成、客服分流、內容審核這類步驟清楚的任務，很適合用它。
但是，真實工作經常臨時拐彎：資料缺失時要先找人，發現數據口徑沖突時要回到上一步，用戶改了目標后還要重新規劃。
為了覆蓋這些變化，流程圖會不斷長出分支。
搭建者得提前想到許多情況，還要維護節點之間的數據格式。
在 Workflow 里，被產品化的“認知”是由“流程編排”和“LLM節點提示詞”組成的，需要調來調去的“編排”那部分，明明也可以讓 LLM 來決策。
3. Skill：把一整套認知交給 Agent
Agent 出現后，模型可以在一個循環里觀察環境、制定下一步、調用工具，再根據結果繼續行動。我們也有了新的封裝方式：
? 把專家經驗寫成參考資料；
? 把可靠步驟寫成執行指引；
? 把必須穩定的操作固化成腳本；
? 把交付格式做成模板；
? 把質量要求做成檢查清單；
? 再告訴 Agent，什么場景該啟用這套能力。
這組文件就是 Skill。
Agent 保留了處理開放問題的空間，Skill 為它提供任務所需的專業知識和行動邊界。
流程清楚的部分可以繼續使用 Workflow 或腳本，臨場判斷交給模型，需要拍板的地方留給人。
Prompt 和 Workflow 會繼續留在 Skill 里。Prompt 成為指令的一部分，Workflow 成為標準流程或腳本；Skill 把它們連同資料、模板、工具和驗收標準一起收攏，變成一套可發現、可復用、可迭代的能力。
自此，一套認知可以完整復制給 AI，實現真正意義上的產品化了。
從 Prompt、Workflow 到 Skill 的能力封裝演進 有效定義 skill
很多介紹會把 Skill 說成“標準化封裝的能力”。
這種概念沒啥用處，聽完只知道是個啥，但很難動手做一個出來。
進到 Agent 的運行過程里看 Skill，會清晰很多。
它從一個文件夾開始。
以 Codex、Claude Code、WorkBuddy 這類 Agent 產品為例，應用會約定一個存放 Skill 的位置。
你把文件夾復制進去，安裝就完成了。
放在電腦根目錄里，多個項目都能發現它；放在某個項目的目錄里，它只服務這個項目。
一個最小 Skill，甚至可以只有一份SKILL.md：
my-skill/
└── SKILL.md
復雜一點的 Skill 會多出幾類材料：
my-skill/
├── SKILL.md # 入口：何時使用、怎樣執行
├── references/ # 領域知識、規則、案例
├── templates/ # 交付模板、示例結構
├── scripts/ # 需要穩定執行的程序
└── assets/ # 圖片、字體等素材
文件放進去之后，Agent 怎樣知道它存在？
SKILL.md開頭通常有一小段元數據，其中最關鍵的是name和description。Agent 啟動會話時，會掃描安裝 Skill 的那個skills文件夾，把里面所有文件夾里的SKILL.md的名稱和描述提取出來，加上這個文檔所在的路徑放進上下文。
模型先看到一張“能力目錄”，知道每個 Skill 大概負責什么。
用戶發來任務后，模型根據描述判斷是否需要某個 Skill。需要時，它會去指定路徑讀取對應的SKILL.md，獲得完整指引。
執行到具體步驟，它再去讀某份參考資料、套用模板，或運行腳本。
Agent 發現并調用 Skill 的運行過程
這套機制常被稱為漸進式披露。
你去一家大圖書館，不會進門就把所有書攤開。目錄先告訴你有哪些書，選中一本再看章節，需要證據時繼續翻參考資料。
Skill 用相似的方式管理上下文：先給模型少量索引，任務命中后再加載細節。
它解決了一個很現實的問題。系統提示詞的空間和模型的注意力都有限。把公司全部制度、幾十套模板、所有操作步驟一次塞進去，費用會上升，干擾也會變多。Agent 還可能在錯誤場景調用一段正確規則。
漸進式披露讓信息在需要時出現，也讓每份資料的用途更清楚。
這里有一個容易被忽略的前提：Agent 得擁有文件系統或類似的沙盒環境，也得能讀取文件、執行腳本。一個只支持對話、無法訪問任何工作空間的 Chatbot，即使收到一份SKILL.md，也很難跑出完整的 Skill 機制。
理解這一點，你就能分辨市面上的很多“Skill”。有些只是把 Prompt 換了個名字；有些已經具備文件、工具與按需讀取能力；還有些做成了平臺自己的插件系統。
名稱可以相同，運行基礎差別很大。
產品經理做方案時，要先問清 Agent 能訪問什么、能執行什么、怎樣發現能力。
Skill 的類型
文件夾只是外殼，里面的內容決定 Agent 會獲得什么能力。
從產品設計的角度看，常見 Skill 可以沿著三個方向來做。這三個方向會互相組合，很少涇渭分明。
1. 復制經驗，讓 Agent 更懂行
大模型學過許多知識，調用哪一套知識卻帶著概率。
它可能知道需求評審，也可能給你一份放在哪個項目都成立的通用建議。公司內部的術語、業務規則、歷史決策，它更無從得知。
經驗復制類 Skill 會把可靠材料放到模型手邊。例如：
? 一位增長產品經理總結的實驗設計方法；
? 一套小紅書選題與文案經驗；
? 一家公司對活躍、留存、轉化的指標口徑；
? 某個行業的合規檢查規則。
這些內容幫助 Agent 在任務中調用指定認知，也方便團隊更新。業務口徑調整后，你改參考資料、重新測試，下一次執行就能使用新版本。無需等待模型廠商重新訓練。
2. 封裝流程，讓 Agent 做得穩
Agent 可以自己規劃步驟，這給了它處理開放任務的能力，也帶來順序漂移、漏步驟和工具誤用。
流程封裝類 Skill 會明確任務怎樣推進：
1. 先查哪些材料，再做哪項分析；
2. 哪些工具有前置條件；
3. 缺信息時向用戶問什么；
4. 哪一步完成后必須保存中間結果；
5. ……
模型能判斷的部分，可以用文字指引。
格式嚴格、計算明確、批量重復的部分，更適合寫進腳本。
腳本執行同一份代碼會得到可預期的過程，模型負責準備輸入、調用程序和解釋結果。
人機協作節點很考驗產品設計。
有些 Skill 可以一路跑完，比如把一批圖片統一改名。有些任務需要 Agent 干一段就停下來：
? 需求邊界尚未確認，用戶得做選擇；
? 生產環境即將發生變更，負責人得批準；
? 文章提綱已經形成，作者想先調整方向。
? ……
Skill 可以把這些暫停點寫進流程，讓 Agent 學會在合適的時候找人。
3. 場景定制化，讓 Agent 進入具體業務
公司數據庫的表結構、內部系統的接口、部門審批規則、固定報告格式，通常同時包含專有知識和固定流程。
例如，一個經營分析 Skill 可能要求 Agent：
1. 只使用經過批準的數據表和字段；
2. 按公司口徑計算收入與留存；
3. 遇到缺失數據時標記問題，禁止補造數字；
4. 把結果填入管理層一直使用的 Excel 模板；
5. 輸出前運行檢查腳本，核對公式與匯總值。
知識、流程、環境和交付格式在這里合成了一套專屬能力。通用 Agent 借助它，才能在某家公司的具體場景里可靠工作。
總結下來，我們得到了一個本該放在上一版塊的 Skill 的定義：
Skill 是把 Agent 在一個場景中需要的知識經驗、執行流程、環境約束和驗收標準，封裝成可復用的文件化能力單元。
使用 IPO 設計 Skill
看懂文件結構以后，具體設計就很簡單了。
翻來覆去說過幾百遍的 IPO —— 輸入、處理、輸出 —— 仍然是一把好用的拆解刀。
Input：先讓任務有一個靠譜的起點
許多 Agent 任務失敗，在第一步就埋下了種子。
用戶說“幫我分析一下這個需求”，沒給業務目標、用戶反饋和數據口徑，Agent 只好從常識出發。后面寫得越多，離真實項目可能越遠。
設計 skill 時，除了場景認知的產品化，其實還包含了使用 LLM 的常識。
是的，這些常識，99%的普通用戶不知道。
在為 skill 設計輸入時，可以分三層問：
?用戶必須提供什么？比如目標、原始材料、交付時間、使用對象。缺少這些信息，任務無法開始。
?Agent 可以自己獲得什么？比如讀取當前項目的 PRD、查詢數據庫結構、搜索指定資料庫。用戶不用重復搬運 Agent 已經能訪問的信息。
?產品經理要替用戶補什么？用戶未必知道該提供競品范圍、歷史決策或審批人。Skill 可以通過一組問題引導他，也可以在工作空間里主動查找。
輸入設計的成果，未必是一張長表單。它也可以是一段漸進對話：先確認目標，再根據答案追問；信息夠用時開始執行，關鍵項缺失時暫停。
好的 Skill 會降低用戶描述任務的門檻，同時守住啟動條件。
Process：在模型判斷、明確流程和腳本之間分工
處理層決定 Agent 怎樣干活。你可以把步驟分成三種：
?需要理解和判斷的步驟，交給模型。比如從訪談里歸納需求、比較多個方案、根據上下文選擇評審維度。
?需要順序和協作的步驟，寫成流程。比如先讀背景，再檢查信息缺口；形成提綱后請用戶確認；收到反饋再進入成稿。
?需要確定性的步驟，交給腳本。比如解析固定格式文件、批量改名、計算指標、校驗 JSON、檢查文檔是否缺少指定章節。
全部交給模型，過程容易漂。全部寫成腳本，開放任務又裝不進去。
Skill 設計的手藝，就體現在這條分界線上。
你還要標出中間狀態放在哪里。
長任務可以把階段產物保存成文件：資料摘要、待確認問題、當前提綱、檢查報告。
Agent 下一輪能接著做，用戶也能查看過程。任務中斷后，這些文件還能幫它恢復。
Output：交付物要能被下一步直接使用
“輸出一份高質量報告”給不了 Agent 足夠的信息。
高質量要落到看得見的標準：結構有哪些章節，數字附什么來源，結論對應哪些證據，文件用什么格式，誰會拿它做下一步。
用戶對交付物有兩種常見狀態：
一種是用戶只知道目標。比如他想寫一篇能帶來報名的課程文章，卻說不清文章該有哪些部分。Skill 需要提供一套經過驗證的內容結構和寫作標準。
另一種是用戶已經拿著固定載體。老板給了一張 Excel 模板，團隊沿用一份評審表，系統只接受指定 Schema。Skill 要讀取這個載體，反推加工方式，并把結果準確填回去。
交付結束前，還要安排自檢。檢查可以來自清單、腳本、樣例對照或二次核驗。
Agent 應該知道“生成完了”和“可以交付”之間還有一道門。
Harness：讓 Agent 知道哪里該停
萬事皆可 Harness，skill 同樣。（這里其實多少有點濫用這個詞了，Guardrails 似乎更合適一些）
skill 不能只有對 Agent 的“鼓動”，還要有“勸解” —— 哪些事不能做、別亂做 —— 一個合格的 Skill 還應該包括：
? 哪些操作可以直接做，哪些只能預覽；
? 哪些動作必須獲得用戶確認；
? 數據不足時如何報告，禁止用什么內容補空白；
? 工具失敗后重試幾次，失敗到什么程度要停；
? 修改前怎樣備份，出錯后怎樣恢復；
? 哪些信息可以進入外部服務，哪些只能留在本地。
這部分很像產品中的權限、異常流和風控設計。
過去畫業務流程時容易把它們塞進角落，Agent 會把這些角落放大，因為它會自己規劃下一步，也可能連續執行很久。
用 IPO 與 Guardrails 設計一個 Skill 另一個思路：skill 是來填坑的
IPO 幫你正向設計一套 Skill。還有一條反向路徑也很實用：觀察模型會在哪里出錯，再給對應位置加約束。
這項工作很像做產品復盤。模型每次把活干砸，都在告訴你能力單元里少了什么。
大模型的核心缺陷其實就兩個：
1. 知識非常多，多到了我們不知道它具體有哪些知識，也因此不知道它會使用什么知識幫我解決問題
2. 生成 Token 很隨意， 每一次不確定性都在長程任務中被持續疊加
由此，可以展開非常多會搞砸任務的問題：
LLM的部分缺陷vs補救skill策略
比如其中的“信息不夠時自行假設”：
在長任務里，一處假設會一路傳下去。Agent 先編了一個市場數據，后面的策略、預算和目標都建立在它上面。
就 LLM 的這個“臭毛病”，Skill 可以規定：外部事實必須給出來源；無法核實時標為未知；關鍵輸入缺失就向用戶提問。
這個約束短短幾行，能救下后面幾十步。
Skill 的第一版通常來自經驗，后續版本則來自失敗。每次大崩潰，可能正好就是一個可以獨立封裝的 skill。
開發一個 Skill 的極簡流程
Skill 開發很像做一款小產品：先找場景，理解熟手的工作方式，做出最小閉環，再用真實任務把問題跑出來，然后迭代、迭代、迭代……
不著急非得上 scripts，代碼會擴大 skill 的范圍、提升流程的穩定性，但最好先把場景和流程捋出來。
SKill 的核心之核心，是把隱性的判斷還原成清楚的輸入、步驟、邊界和標準。
第一步：選一個值得封裝的任務
適合做成第一只 Skill 的任務，通常有幾個特征：
? 團隊反復在做，頻率足以支撐維護成本；
? 熟手和新手的結果差異明顯，經驗有遷移價值；
? 任務需要多步完成，單段 Prompt 已經顯得吃力；
? 輸入和交付物大致可描述，能判斷是否完成；
? Agent 能訪問任務需要的材料和工具。
需求評審、用戶訪談整理、周報生成、運營文案檢查、數據口徑核對，都適合作為起點。
“幫公司做好所有產品工作”這個范圍太大。第一版最好切成一個清楚的任務，比如“評審進入研發前的功能 PRD，并輸出待澄清問題與風險清單”。
場景越具體，Skill 越容易獲得清晰邊界。
第二步：先找 cases，再寫 md
找三到五個過去做過的案例，至少覆蓋一次順利完成、一次信息不足、一次中途出錯。
把當時的輸入、過程、最終交付和反饋放在一起看一遍，邊界先界定出來。
接著訪談“熟手”，也就是最佳實踐萃取。
少問“你有什么方法論”，多追具體動作：
? 你拿到材料先看哪里？
? 哪種信號會讓你停下來追問？
? 哪些錯誤新人經常犯？
? 你怎么判斷結果可以交出去？
? 遇到例外時，你會改走哪條路？
? ……
人很難一次說清自己的全部經驗，前面找的真實案例能把肌肉記憶拉回現場。
第三步：列出 IPO 和失敗點
用一頁紙列出：
輸入：用戶提供什么？Agent 主動讀取什么？缺什么就不能開始？
處理：熟手按什么順序做？哪里需要判斷？哪里適合用腳本？
輸出：交付給誰？用什么格式？怎樣驗收？
邊界：哪些動作要確認？哪里容易出錯？失敗后怎么辦？
再把 LLM 缺陷的問題表拿過來逐項看：模型會不會混淆術語？會不會漏檢查？會不會在數據缺失時猜一個？
這些潛在的問題，決定需要準備什么資料、模板和校驗規則。
第四步：拆分文件，構建上下文結構
SKILL.md的大忌：洋洋灑灑幾千字的流程、規則、代碼。
切記：SKILL.md是INDEX，即放路由和行動指引：適用場景、執行順序、協作節點、邊界與驗收。
要短到模型讀完注意力完全不會有任何變化，但也要完整到模型知道下一步去哪找。
大段領域知識放進references/。
固定交付結構放進templates/。
需要精確執行或反復運行的動作放進scripts/。
樣例可以單獨保存，供模型理解標準，也供你做回歸測試。
入口文件越長，模型越難抓住行動主線。把資料拆開，并在入口里寫清讀取條件，漸進式披露才會發揮作用。
整體結構捋完，可以開始著手寫 skill 了。
第五步：Agent 友好的名稱和描述
名稱方便人識別，描述幫助模型決定是否選用。描述里要出現用戶可能提出的任務、適用條件和能力邊界。
下一步營銷的必爭之地：面向 Agent 的工程優化，Agent Engine Optimisation
例如：
---
name:prd-review
description:"評審進入研發前的功能 PRD。用于檢查需求背景、用戶價值、業務規則、數據指標、異常流程與上線風險，并輸出待澄清問題和風險清單。當用戶要做需求評審、PRD 評審或上線前產品檢查時使用。"
---
“一個很好用的產品經理技能”很難觸發，因為它沒說要解決哪類任務?！皩懳臋n”又太寬，容易在不相關的寫作任務里被誤用。
第六步：寫執行流程，把分叉點交代清楚
流程要使用動詞，明確動作和產物：
1. 讀取 PRD 與項目背景材料。
2. 檢查啟動條件；缺少業務目標、目標用戶或核心流程時，列出問題并等待用戶補充。
3. 按用戶、業務、數據、交互與風險幾個視角評審。
4. 對高影響且證據不足的判斷標記“待確認”，禁止補造事實。
5. 生成評審報告初稿，請用戶確認優先級與爭議項。
6. 根據反饋整理終稿，并運行交付檢查。
其中，第 2 步和第 5 步是人機協作節點。
你還可以寫明不同分支：用戶暫時拿不到數據怎么辦，PRD 只有原型沒有文字怎么辦，評審對象只是一個輕量實驗時要跳過哪些重型檢查……
Skill 無需把每一次模型思考都規定死。穩定主干、關鍵分叉和危險邊界寫清楚，普通判斷留給 Agent，流程才有彈性。
Skill 相比于 Workflow 的優勢就是這里：把編排也交給 LLM，以換取更廣泛的適用性。
第七步：寫驗收標準
大部分 Skill 的問題，是 SOP 跑完就完了，Agent 只參與了“生產”，但產出物質量如何又丟給用戶了。
負責人的收尾是驗收標準，能逐項回答的驗收標準。
例如產出需求評審報告這種 Skill，可以檢查：
? 每個重大風險都引用了 PRD 原文或項目材料；
? 待澄清問題說明了缺失信息會影響哪個決策；
? 嚴重程度使用統一分級；
? 沒有把個人偏好寫成用戶事實；
? 報告包含結論、問題、風險和建議動作；
? 所有引用鏈接或文件路徑可訪問。
其中一部分由模型對照清單檢查，格式、鏈接、字段完整性則可以交給腳本。也可以準備一份合格樣例，讓 Agent 在交付前比較結構和信息密度。
第八步：測試觸發、執行和交付
Skill 測試要看三層：
?觸發測試檢查 Agent 是否在合適的請求里啟用它，也檢查無關請求會不會誤觸發。
?過程測試檢查它有沒有讀對資料、按順序調用工具、在缺信息時停下、在高風險動作前確認。
?結果測試檢查交付物是否滿足標準，換一個案例后還能否保持質量。
測試部分，強烈推薦仔細閱讀 A\ 發布的最新版的 skill-creator，里面包含了非常高質量的 skill 測評策略。
第一版 Skill 很難覆蓋所有情況。上線后的維護方式和產品迭代相似：記錄問題，判斷問題來自知識、流程、工具還是驗收，再修改對應文件。
模型讀錯資料，就改入口里的讀取條件。
用戶總在同一個問題上答不出來，就調整提問方式或提供示例。
腳本頻繁遇到某類錯誤，就補異常處理。
交付看著完整卻不能用，就收緊驗收標準。
認知產品化的優勢在這里顯出來：團隊不必依靠某個人下次記住，一次問題可以變成下一版能力的一部分。
一個 Skill 從經驗到測試迭代的開發循環 認知離開人的腦袋之后
再回到開頭的“產品 Sense”。
資深產品經理聽完一句需求，腦子里浮現的那些問題，如今可以被整理、封裝、測試，再交給整個團隊使用。新人不會因此一夜之間擁有十年經驗，但他可以借用熟手的提問順序、檢查維度和判斷標準，完成一份更接近專業水位的工作。
對個人來說，Skill 是認知杠桿。你趟過的坑可以繼續替你工作，同一套方法不必在每個對話里重新解釋。
對團隊來說，Skill 是能力基礎設施。業務規則、工作流程和質量標準有了共同載體。規范更新時，團隊維護一處；任務執行后，大家還能觀察效果、繼續迭代。
對產品經理來說，它也帶來一塊新的設計空間。你除了設計頁面、流程和規則，還要設計 Agent 的上下文與行為：
? 它先了解哪些信息；
? 它可以自行決定什么；
? 它在哪些節點找人；
? 它怎樣調用工具；
? 它如何證明任務已經完成。
這些問題都很產品。區別只在于，你設計的用戶旅程里多了一位會思考、會行動、偶爾也會犯迷糊的參與者。
Skill 也不會自動把一份普通方法變成專家能力。
文件化只能放大已有認知。
你對任務理解得越深，越能劃清模型判斷、腳本執行與人工決策的邊界；你積累的案例越多，Skill 的分支和驗收就越貼近現場。
學 Skill 的過程也會反過來訓練產品經理。為了教會 Agent，你得把一句“憑經驗判斷”拆開，說明自己看了什么、比較了什么、在哪個信號出現時改變決定。那些原來靠感覺完成的動作，第一次變得可以檢查、討論和復用。
第一只 Skill 跑通以后，你會開始用另一種眼光看工作。重復流程里藏著可以封裝的能力，評審意見里藏著驗收標準，項目事故里藏著下一版的邊界條件。
產品經理思維的全面重構
產品經理學習 AI，到底應該學什么？
提示詞工程、上下文工程、Harness 工程固然都得學，但那些都是“技”，更底層的“道”是“認知產品化”這個大趨勢。
把認知封裝成產品，離不開 LLM。
過去設計產品要理解人性，現在設計產品要理解 LLM —— 它的缺陷、邊界、一定會搞砸的問題。
我最近在做一門面向產品經理的 AI 轉型線下課，用兩天的時間，把這套新的思維方式和必須掌握的 LLM 特性幫你全面構建起來。
兩天里，我會通過一系列實操項目，完成四次進階：
1. 把 AI 用進需求梳理、市場調研、PRD 和原型等日常工作，以理解大模型的底層原理；
2. 把 AI 接進現有產品與流程，提升業務效率，以拿到利用AI 技術的門票；
3. 構建模型本位的產品設計視角，真正理解 Agent 原理并動手開發 Agent 和 Skill；
4. 通過三個項目練習 Vibe Coding，做出可以直接交互的 AI 產品。
課程采用小班制，兩天都從任務入手，邊做邊講。
Skill 會作為原生 AI 產品經理能力的一部分進入實操，你會從原理、場景設計一路做到開發與測試。
第一期已經在過去的 1 個月完成交付：
北京場的部分學員反饋
第二期開始招募，安排如下：
城市
時間
狀態
北京-2期
8月1-2日
招募中
深圳-2期
8月15-16日
招募中
上海-2期
8月22-23日
招募中
課程原價 3999 元，限時早鳥價 2999 元將在二期開營前結束。
掃碼可以查看課程詳細內容、上課方式與詳細安排。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
