Archive
文章庫
呢度係完整文章庫入口,按頁瀏覽所有已發佈文章。
Claude 學會了「做夢」:你睡覺的時候,AI 正在覆盤自己
Claude 而家會「做夢」——自動覆盤經驗,越用越聰明
完成審美與生產力的雙重保障:如何讓GPT做高品位的海報
分享可替換提示詞模板,用GPT生成高質建築海報,再衍生出交付級原型圖
完成AI夠用了,機會已經出現,但不在C端。
AI技術已夠用,機會在於將AI遷移到業務流程,搭好自己嘅系統。
完成開源個 Agent 用的網盤,讓 Skill 跨設備同步
作者整咗個開源網盤 neuDrive,專俾 AI Agent sync skill 同記憶,唔使再手動 backup 喇
完成從零生成一份教程包:主題到高質量教程包的完整工作流
yao-tutorial-skill:一條自然語言驅動嘅完整教程生成工作流,將數日工作縮短到幾分鐘
完成為什麼最聰明的 AI 用戶,正在從 Claude 切換到 Codex
Codex 整合所有 AI 功能,正吸引從 Claude 切換的用戶
完成彭博:8個頂級AI模型拿真錢炒股,全部虧損
8個頂級AI模型用真錢炒股,全部虧損——AI取代交易員仲差好遠
完成GPT Image 2 不會寫提示詞?這個開源倉庫整理了 4430 條案例
呢個開源倉庫有4430條GPT Image 2提示詞,仲有個畫廊畀你揾靈感,解決你唔識寫提示詞嘅煩惱。
完成【進階篇】OpenClaw 高級技巧:定時任務 + 子 Agent + 自動化工作流
OpenClaw 高級技巧:通過定時任務、子 Agent 同自動化工作流,將 AI 從被動響應升級為主動執行、並行幹活嘅數字打工人。
完成Codex好用到爆!搓了一個前後端開發必備的瀏覽器插件
作者用 Codex 開發咗一個叫 DOM Lens 嘅瀏覽器插件,徹底取代 DevTools 嘅繁瑣操作,懸停即可拎到精確嘅節點信息。
完成Vibe Coding 會讓你迷失:一個30年老工程師的 Spec-driven 轉型實錄
從Vibe Coding迷失到Spec-driven重掌主導:用規格說明書取代隨機生成,重建項目心智模型
完成12 天 4.2K 的 Star,我的 GPT-image2 開源項目火了!
12日4.2K Star:蒼何分享點樣用手機遠程指揮Codex,唔碰電腦搞掂開源項目
完成拆解 Context Ranking Skill 的 5 個反直覺設計
Context Ranking Skill 五個反直覺設計:搜到不等於排好
完成在Obsidian中集成Claude Code:Claudian插件參數配置教程
喺 Obsidian 整合 Claude Code:Claudian 插件參數配置全攻略
完成最新最全的 codex 指南,是時候切換你的主力 Agent 了。
Codex桌面端憑藉GPT-5.5同完善生態,成為目前最值得切換嘅Coding Agent。
完成大多數公司空有數據,卻毫無記憶 接再多的AI,它也幹不了活
公司缺嘅唔係數據,係記憶;Agent接唔到一間唔記得自己點解咁做決定嘅公司
完成15個寶藏AI一手信源,沒時間每週看這些就夠了
哈嘍,大家好!我是阿星👋自從發現我自己買的課裏有點AI幻覺,我基本就是當參考隨便看看了,基本上有什麼事直接看外國信源哈哈。所以今天給大家推薦一下我經常用的幾個這些信源並非來自單一榜單,而是綜合了官方介紹、AI newsletter 推薦榜、開發者社區推薦以及我對 AI 信息流的長期觀察整理而來。參考過的公開來源包括 Zapier、Jotform、The AI Library、ReadLess、Superhuman AI、swyx 的 GitHub 筆記,以及部分 Substack 推薦頁。1. Ben’s Bites:適合快速瞭解 AI 產品和工具如果你每天只想花幾分鐘掃一眼 AI 圈發生了什麼,Ben’s Bites 是一個很好的入口。它更偏 AI 產品、工具、創業項目和行業動態,適合獨立開發者、產品經理、自媒體作者,以及想知道“最近有什麼新工具可以用”的普通用戶。它的特點是信息密度高,更新穩定,不太需要你有很強的技術背景。官方介紹也很直接:追蹤過去 24 小時的 AI 產品發佈、研究和新聞,整理成 5 分鐘可讀的 daily digest。(Ben's Bites)網址:https://bensbites.com/https://bensbites.co/2. Hugging Face Papers:適合看每日熱門 AI 論文如果你想知道最近 AI 研究圈在關注什麼,但又不想自己每天刷 arXiv,可以看 Hugging Face Papers。它會把每日、每週、每月熱門論文聚合出來,靠社區提交和投票篩選。頁面本身也標註為 “Daily Papers by AK and the research community”。(Hugging Face)它適合用來做一件事:快速判斷最近哪些 AI 論文正在被研究者和開發者關注。你不一定每篇都讀完,先看標題、摘要和討論熱度,就已經能幫你建立方向感。網址:https://huggingface.co/papershttps://huggingface.co/papers/trending3. Readwise Weekly Wisereads:適合跳出信息繭房Readwise 的 Weekly Wisereads 不完全是 AI 信源,但非常值得看。它不是單純按點擊量推薦文章,而是基於 Readwise 用戶真實高亮過的內容進行篩選。官方 FAQ 裏說明,Wisereads 會根據上一週被不同用戶高亮的網頁文章、YouTube 視頻、推文和公開 PDF 來排序。(Readwise Blog)這點很有價值。因為 AI 很火以後,很多人會只盯着模型、工具、融資和爆款產品。但真正有啓發的內容,往往來自更寬的領域:閲讀、寫作、認知、商業、教育、產品、社會變化。Wisereads 可以幫你避免只困在 AI 信息繭房裏。網址:https://wise.readwise.io/4. The Batch:適合系統瞭解 AI 行業變化The Batch 是 DeepLearning.AI 出品的 AI 新聞和洞察類內容。它不是那種特別碎片化的 AI 快訊,而更像一份穩定的 AI 行業週報。DeepLearning.AI 官方頁面把它定位為 AI News & Insights。(DeepLearning.ai)如果你想系統瞭解 AI 技術、應用、產業和政策變化,The Batch 比較適合長期閲讀。它適合的人羣是:想學習 AI,但不想每天被各種模型發佈會牽着走的人。網址:https://www.deeplearning.ai/the-batch/5. Import AI:適合看 AI 研究和長期趨勢Import AI 是 Jack Clark 長期寫的 AI newsletter。它更偏 AI 研究、政策、安全和長期趨勢。官網介紹寫得很清楚:這是一個關於 AI research 的 newsletter,基於 arXiv 和讀者反饋。(Import AI)如果你不只是想知道“今天又出了什麼工具”,而是想理解 AI 這條主線正在往哪裏走,Import AI 很值得看。它的閲讀門檻比普通 AI 快訊高一點,但長期價值也更高。網址:https://jack-clark.net/https://importai.substack.com/6. Latent Space:適合 AI 工程師和開發者如果你關注 AI Agent、RAG、模型基礎設施、推理、代碼生成、AI 工程化,Latent Space 非常值得看。它的定位是 AI Engineer newsletter + technical AI podcast,內容經常圍繞模型、Agent、Infra、AI for Science 和一線構建者訪談展開。(Merriam-Webster)這類內容不一定適合純小白,但很適合正在做 AI 產品、AI 編程、AI 應用落地的人。尤其是現在很多人不只是“用 AI”,而是要把 AI 接進自己的工作流和產品裏,這類工程化內容會越來越重要。網址:https://www.latent.space/7. TLDR AI:適合每天快速掃新聞TLDR AI 的優勢就是短、快、清楚。它屬於那種適合通勤、吃飯、睡前快速掃一眼的 AI 快訊。TLDR 官網介紹是用 5 分鐘跟上科技信息,覆蓋 startups、tech、programming 等內容,其中也有 AI 分類。(TLDR)如果你不想每天打開十幾個網站,可以把 TLDR AI 當成一個基礎信息入口。網址:https://tldr.tech/ai8. The Rundown AI:適合非技術人瞭解 AI 應用The Rundown AI 更偏大眾化,適合職場人、運營、市場、自媒體作者、創業者和非技術用戶。它的定位是每天推送 AI 新聞、工具和洞察,並且強調讓讀者理解這些變化為什麼重要。(The Rundown AI)如果你不寫代碼,也不想深讀論文,只是想知道 AI 如何影響工作、內容創作和商業應用,可以關注它。網址:https://www.therundown.ai/9. AlphaSignal:適合關注論文、模型和代碼倉庫AlphaSignal 更偏技術和開發者。它主打每天 5 分鐘總結最新突破、模型、論文和代碼倉庫。官網介紹裏也寫到,它會總結 breakthrough news、models、papers 和 repos。(AlphaSignal)如果你關心的是:最近有什麼新模型?哪些論文值得看?哪些 GitHub 項目正在被關注?哪些 repo 可能有工程價值?那 AlphaSignal 可以作為一個不錯的補充信源。網址:https://alphasignal.ai/https://alphasignalai.substack.com/10. Simon Willison:適合看 AI 編程和 Agent 實踐如果你正在用 Claude Code、Codex、Cursor、Gemini CLI 這類 AI 編程工具,Simon Willison 的博客很值得長期看。他的內容不是泛泛而談“AI 改變世界”,而是大量真實使用後的工程經驗、工具觀察和安全提醒。比如他專門有 AI 標籤頁,也長期寫 AI-assisted programming、agentic engineering、prompt injection 等話題。(Simon Willison’s Weblog)這類內容對獨立開發者尤其有用,因為它更接近真實開發場景,而不是發佈會話術。網址:https://simonwillison.net/https://simonwillison.net/tags/ai/11. OpenAI、Anthropic、Google DeepMind 官方博客:看一手信息很多 AI 新聞,其實都是二手解讀。但真正重要的模型發佈、API 更新、研究報告,最好還是回到官方一手來源。建議至少收藏這幾個:OpenAI News:https://openai.com/news/Anthropic News:https://www.anthropic.com/newsGoogle DeepMind:https://deepmind.google/OpenAI News 是 OpenAI 官方新聞入口;Anthropic News 會發布 Claude、產品、研究和安全相關更新;Google DeepMind 則是 Google 旗下 AI 研究和產品進展的重要發佈入口。(OpenAI)看官方博客的好處是:你可以少被標題黨帶節奏,多看原始信息。12. GitHub Trending:適合發現熱門 AI 項目如果你是開發者,只看論文是不夠的。很多 AI 趨勢最早會出現在 GitHub 上,比如 Agent 框架、RAG 工具、模型部署方案、推理優化項目、數據處理工具。GitHub Trending 可以用來發現最近熱門倉庫。(LinkedIn)建議關注這些入口:https://github.com/trendinghttps://github.com/topics/aihttps://github.com/topics/large-language-models你不一定要每個項目都跑起來,但可以通過它判斷:開發者社區最近在關注什麼。13. Connected Papers:適合圍繞一篇論文繼續深挖Connected Papers 不是新聞源,而是論文研究工具。它可以圍繞一篇論文生成相關論文圖譜,幫助你找到前後相關工作。官網介紹它是一個幫助研究者和應用科學家尋找相關學術論文的可視化工具。(Connected Papers)如果你看到一篇重要 AI 論文,但不知道它的前置研究和後續工作是什麼,可以用它順藤摸瓜。網址:https://www.connectedpapers.com/1.OpenReview:適合追蹤頂會論文和評審討論 如果你想更深入地看 AI 學術圈的前沿動態,OpenReview 也很值得收藏。很多機器學習和人工智能會議都會在 OpenReview 上公開論文、評審意見和作者回復,比如 ICLR、NeurIPS 相關 workshop、機器學習專題會議等。它和 Hugging Face Papers 不太一樣。Hugging Face Papers 更適合快速看“哪些論文最近熱”。 OpenReview 更適合看“這些論文在學術共同體裏是怎麼被評價和討論的”。尤其是你做論文選題、文獻綜述、科研訓練,或者想判斷一篇論文到底有沒有爭議,OpenReview 會比單純看摘要更有幫助。網址:https://openreview.net?utm_source=chatgpt.com2. arXiv:適合看 AI 論文的一手來源 如果說 Hugging Face Papers、OpenReview、Connected Papers 都是在幫你篩選和組織論文,那麼 arXiv 就是很多 AI 論文最早出現的地方。大量 AI、機器學習、深度學習、大模型相關論文,都會先發布到 arXiv。它的優點是信息非常一手,缺點也很明顯:內容太多,篩選成本很高。所以我不建議普通讀者每天直接刷 arXiv。更適合的方式是: 先通過 Hugging Face Papers、The Batch、Import AI 看到重要論文,再回到 arXiv 看原文。如果你是學生、研究者,或者正在寫論文,arXiv 仍然是必須知道的基礎信源。常用入口:https://arxiv.orghttps://arxiv.org/list/cs.AI/recenthttps://arxiv.org/list/cs.LG/recenthttps://arxiv.org/list/cs.CL/recent如果你只想選 5 個,我建議這樣搭配如果你是普通 AI 使用者:Ben’s BitesThe Rundown AIThe BatchReadwise Weekly WisereadsOpenAI / Anthropic / Google DeepMind 官方博客如果你是獨立開發者或產品人:Ben’s BitesHugging Face PapersLatent SpaceSimon WillisonAlphaSignal如果你是學生、研究者或需要寫論文:Hugging Face PapersImport AIThe BatchConnected PapersOpenReview如果你做自媒體或內容創作:Ben’s BitesReadwise Weekly WisereadsThe Rundown AIThe Batch各大廠商官方博客最後說一句AI 時代真正稀缺的不是信息,而是篩選信息的能力。建立自己的 AI 信息源清單,定期閲讀、定期篩選、定期輸出,才是普通人跟上 AI 的最低成本路徑。ok,我是阿星更多AI應用,我們下期再見!
完成GPT-Image-2 生成產品原型圖頂級提示詞合集:從0到1快速出圖
GPT-Image-2 生成產品原型圖頂級提示詞合集:從0到1快速出圖
完成數十萬 Agent Skills 之中,開發者真正需要的 10 個:基於 Anthropic、OpenAI 官方與 GitHub 開源項目精選
一份基於 Anthropic、OpenAI 官方資源與 Skills.sh、Clawhub、Github 開源項目等 Skills 安裝數據的客觀篩選,讓開發者可以在數十萬 Agent Skills 中快速找到最有用的 10 個,一次裝好!引言2025 年下半年 Anthropic 把 Claude Skills 正式發佈為 Agent Skills 公開標準後,Anthropic Claude Code 與 OpenAI Codex、Cursor、OpenCode 等 AI Agents 先後把 "Agent Skills" 推到了 AI Coding Agents 的核心位置。它的形態非常簡單:一個文件夾,包含一份 SKILL.md 和若干腳本資源;它的作用卻很關鍵——把"模型默認行為"約束成"可復現的工作流"。到 2026 年 4 月,公開註冊表已收錄數十萬個 skill,僅 skills.sh 一家平台的累計安裝量就超過 85 萬次。在這種數量級下,如何挑選真正有價值的 skill 成了實際問題。今天咱們聚焦軟件開發場景,從 Anthropic 和 OpenAI 兩家模型廠商的官方倉庫出發,疊加 Skills.sh、Clawhub、Github 的安裝量數據與社區共識,篩選出 10 項最值得納入日常工作流的 skill。每一項都給出它解決什麼問題、與替代方案的差別,以及安裝方式與官方連結。篩選方法為了避免"按 GitHub stars 一刀切"帶來的偏差,本次篩選綜合了四個信號:信號數據源作用官方收錄anthropics/skills(128.9K stars)、openai/skills/.curated反映廠商對工作流的官方建議實際安裝量skills.sh 和 clawhub 等匿名遙測反映真實使用度而非收藏熱度跨平台兼容agentskills.io 開放規範一份 skill 能跨 Claude Code / Codex / Cursor 複用工作流覆蓋是否落在"設計 → 編碼 → 測試 → 評審 → 合併"鏈條上避免選出彼此功能重疊的項需要先澄清一個常見誤解:skill 與 MCP server 是互補關係。前者描述"怎麼做",後者提供"做什麼的能力"。下文 #3、#7 通常需要配合 Playwright MCP 才能執行真實操作。十項推薦1. skill-creator —— 編寫 skill 的基礎工具來源: Anthropic 與 OpenAI 官方倉庫均收錄https://github.com/anthropics/skills/tree/main/skills/skill-creator[1]https://github.com/openai/skills/tree/main/skills/.system/skill-creator[2]說明: 包含 SKILL.md 模板、frontmatter 校驗、目錄約定。兩家廠商各自維護一份,意味着它在各自的 agent 內部已是默認依賴。先掌握它,團隊內部的方法論沉澱才有統一格式。安裝:/plugin marketplace add anthropics/skills/plugin install example-skills@anthropic-agent-skillsCodex 已隨版本自動安裝,無需手動操作。2. mcp-builder —— 生成符合規範的 MCP server來源: anthropics/skillsURL: https://github.com/anthropics/skills/tree/main/skills/mcp-builder[3]說明: 生成符合 Model Context Protocol 規範的 server 骨架,包括 JSON-RPC 處理、tool/resource 註冊、stdio/SSE 傳輸配置。手寫這部分代碼容易在 schema 校驗和錯誤碼上踩坑,由 Anthropic 維護可以跟隨協議演進。適合需要把內部系統接入 Claude / Cursor / Codex 的團隊。安裝: 同 #1。3. webapp-testing —— Playwright 測試編寫方法論來源: anthropics/skillsURL: https://github.com/anthropics/skills/tree/main/skills/webapp-testing[4]說明: 在 Playwright 之上提供測試編寫順序、selector 選擇策略、斷言模式。和直接調用 Playwright MCP 的差別在於:MCP 提供"操作瀏覽器的能力",這個 skill 提供"寫出可維護測試的方法"。兩者通常配合使用。安裝: 同 #1。4. frontend-design —— 收斂風格選擇的預設庫來源: anthropics/skillsURL: https://github.com/anthropics/skills/tree/main/skills/frontend-design[5]說明: 內置 50 種視覺風格、調色板與字體配對的預設。skills.sh 數據顯示其安裝量約 12.4 萬次,在前端類 skill 中排名靠前。主要價值在於把"風格選擇"從開放問題收斂成有限選項,輸出的 UI 不容易出現常見的 AI 通用感。安裝: 同 #1。5. gh-fix-ci —— 處理 CI 失敗的標準流程來源: openai/skills/.curatedURL: https://github.com/openai/skills/tree/main/skills/.curated/gh-fix-ci[6]說明: 處理 GitHub Actions 失敗的標準流程:拉取日誌、定位失敗 step、讀取相關文件、提交修復 commit。OpenAI 把它放進 curated 名單意味着推薦作為日常工作流的默認項。對長期維護的項目尤其有用,省去人工排查 CI 日誌的時間。安裝:$skill-installer gh-fix-ci6. gh-address-comments —— 系統化處理 PR 評審來源: openai/skills/.curatedURL: https://github.com/openai/skills/tree/main/skills/.curated/gh-address-comments[7]說明: 拉取 PR 評論並按文件與位置分類,逐條修改後回覆 reviewer。和 gh-fix-ci 配合形成"提 PR — 過 CI — 處理評審 — 合併"的完整鏈路。OpenAI 也把它作為 skill 系統的入門示範。安裝:$skill-installer gh-address-comments7. playwright 與 playwright-interactive —— 瀏覽器自動化的兩種取向來源: openai/skills/.curatedhttps://github.com/openai/skills/tree/main/skills/.curated/playwright[8]https://github.com/openai/skills/tree/main/skills/.curated/playwright-interactive[9]說明: OpenAI 維護的瀏覽器自動化指引。playwright 適合無人值守的腳本任務,playwright-interactive 在每一步暫停等待人工確認,適合調試複雜登錄流程或交互式 SPA。和 #3 的 Anthropic webapp-testing 取向不同:後者偏測試用例編寫,這兩個偏運行時操作。安裝:$skill-installer playwright$skill-installer playwright-interactive8. security-best-practices 系列 —— 安全審計三件套來源: openai/skills/.curatedURL: https://github.com/openai/skills/tree/main/skills/.curated/[10]說明: OpenAI 一次性發布的三個安全相關 skill,分別覆蓋編碼規範、威脅建模(STRIDE 類)、代碼所有權審計。AI 生成代碼在輸入校驗和密鑰處理上的常見漏洞由這套清單兜底,比依賴模型自身的安全意識更可靠。安裝:$skill-installer security-best-practices$skill-installer security-threat-model$skill-installer security-ownership-map9. find-skills —— 跨 agent 的發現與安裝入口來源: vercel-labs,通過 skills.sh 分發URL: https://skills.sh/[11]說明: skills.sh 公佈的安裝量約 41.8 萬次,是該平台的第一名。本身不解決具體編碼問題,但提供跨 18 種 agent 的發現與安裝入口。裝上之後,搜索其他 skill、查看安裝量數據都在 agent 內部完成。屬於基礎設施層。安裝:npx skills add find-skills10. superpowers 三件套 —— 約束默認行為的方法論來源: obra/superpowers(社區項目)URL: https://github.com/obra/superpowers[12]說明: 包含 brainstorming、test-driven-development、systematic-debugging 三個偏方法論的 skill,分別約束編碼前的需求探索、測試編寫順序、調試時的假設-驗證循環。它們解決的是 agent 默認行為裏的常見問題:跳過設計直接寫代碼、跳過測試、調試時隨機改代碼。OpenAI Codex 的默認 .codex/skills/ 已包含同名實現,可見社區認可度。安裝:/plugin marketplace add obra/superpowers/plugin install superpowers@obra-superpowers一鍵安裝腳本把上述十項按平台分組,可以分四步完成:# Step 1: Anthropic 官方(含 #1, #2, #3, #4)—— 在 Claude Code 內執行/plugin marketplace add anthropics/skills/plugin install example-skills@anthropic-agent-skills# Step 2: OpenAI 官方(含 #5, #6, #7, #8)—— 在 Codex 內執行$skill-installer gh-fix-ci gh-address-comments playwright playwright-interactive security-best-practices security-threat-model# Step 3: 生態入口(含 #9)—— 任意終端npx skills add find-skills# Step 4: 方法論三件套(含 #10)—— 在 Claude Code 內執行/plugin marketplace add obra/superpowers工作流位置一覽為方便對照實際開發鏈路,把十項 skill 映射到工作流環節:環節推薦 skill需求探索與設計#10 brainstorming編碼前規範#1 skill-creator(沉澱團隊規範)編碼(接入系統)#2 mcp-builder編碼(前端 UI)#4 frontend-design測試用例編寫#3 webapp-testing、#10 test-driven-development瀏覽器調試與運行#7 playwright / playwright-interactive安全審計#8 security 系列CI 與 PR 評審#5 gh-fix-ci、#6 gh-address-comments調試#10 systematic-debugging跨 agent 發現新 skill#9 find-skills結語這份名單的取捨邏輯可以歸納為一句話:優先選擇官方收錄、跨平台兼容、且解決 agent 默認行為缺陷的 skill。Anthropic 和 OpenAI 都已圍繞 agentskills.io[13] 開放規範展開協作,上述 skill 在 Claude Code、Codex、Cursor 之間理論上可以無縫遷移。對開發團隊而言,更現實的做法是先安裝這十項作為基線,再用 #9 find-skills 在生態中按項目需求按需擴充。skill 系統真正的價值不在數量,而在於它把"和 AI 協作的方式"從一次性提示變成可版本化、可分享、可演進的工程資產。這一點,比挑哪十個更重要。Skills 相關資源推薦Cursor Team Kit 官方發佈,團隊使用 Cursor 最佳實踐完全公開:17 Skills、1 Agent、2 Rules大前端 AI Native 開發三端基礎設施:Android Skills、iOS/MacOS Use Cases 與 Chrome DevTools MCP 技術解析2026 企業級 AI 編程實踐手冊:上下文工程、Skills(Top10)、Spec、MCP(Top10)、Rules、智能體,AI 開發 AI測試驅動的 Agent Skills 工程化構建迭代指南:基於 Anthropic/OpenAI Skill Creator 官方實踐的落地方法論打工人效率提升 Skills 推薦:研發、設計、產品、HR、財務、市場、運營等精選 SKills Top3,附通用 Top10深度解讀 OpenAI 與 Anthropic 的前端設計 Skills:讓所有人做出頂級設計感的專業級網站Referenceshttps://github.com/anthropics/skills/tree/main/skills/skill-creator: https://github.com/anthropics/skills/tree/main/skills/skill-creatorhttps://github.com/openai/skills/tree/main/skills/.system/skill-creator: https://github.com/openai/skills/tree/main/skills/.system/skill-creatorhttps://github.com/anthropics/skills/tree/main/skills/mcp-builder: https://github.com/anthropics/skills/tree/main/skills/mcp-builderhttps://github.com/anthropics/skills/tree/main/skills/webapp-testing: https://github.com/anthropics/skills/tree/main/skills/webapp-testinghttps://github.com/anthropics/skills/tree/main/skills/frontend-design: https://github.com/anthropics/skills/tree/main/skills/frontend-designhttps://github.com/openai/skills/tree/main/skills/.curated/gh-fix-ci: https://github.com/openai/skills/tree/main/skills/.curated/gh-fix-cihttps://github.com/openai/skills/tree/main/skills/.curated/gh-address-comments: https://github.com/openai/skills/tree/main/skills/.curated/gh-address-commentshttps://github.com/openai/skills/tree/main/skills/.curated/playwright: https://github.com/openai/skills/tree/main/skills/.curated/playwrighthttps://github.com/openai/skills/tree/main/skills/.curated/playwright-interactive: https://github.com/openai/skills/tree/main/skills/.curated/playwright-interactivehttps://github.com/openai/skills/tree/main/skills/.curated/: https://github.com/openai/skills/tree/main/skills/.curated/https://skills.sh/: https://skills.sh/https://github.com/obra/superpowers: https://github.com/obra/superpowersagentskills.io: https://agentskills.io
完成Claude Code效率翻倍:10個必裝Skills
裝對10個核心Skills,Claude Code效率翻倍
完成自我重塑:把人生目標,堅定不移的執行下去
計劃目標動態法:將人生項目拆至每週動作,跟現實動態調整,先執行落去
完成【AI測試 SKill】09 | 10 分鐘生成 50+ 測試用例的Skill
用 AI 喺 10 分鐘生成 50+ 測試用例,從入門到實戰嘅完整路線總結
完成AI 視頻生成大洗牌:從「盲盒抽卡」到「導演級掌控」,RHTV 如何重構百萬商業創作 SOP?!
RHTV 用無限畫布同原生 AI 智能體,將 AI 視頻創作從「抽卡」升呢做「導演級控制」,30 分鐘就能復刻百萬級商業廣告 SOP
完成Feynman:開源AI研究工具,幫你30分鐘搞定一篇帶引用文獻的報告
Feynman:開源AI研究工具,30分鐘搞掂帶引用嘅研究報告
完成兩種最強大的 Agent:用 Codex 還是 Claude Code
選擇 Codex 或 Claude Code,等於選擇你想成為邊種創作者
完成AI知識庫不是資料倉庫:從文章連結到選題和大綱的工作流拆解
MaxKing提出AI知識庫唔應該只係收藏夾,而係一條從資料輸入到內容輸出嘅加工流水線,透過保存原文、生成資料卡、提取創意積木、選題大綱等步驟,將文章轉化為可複用嘅內容資產。
完成全網首發,無限,seedance2.0一直用,AI視頻,還能用其他AI視頻/AI圖片主流模型,小白全能創作神器。
船長介紹veoaifree:唔使註冊、開箱即用嘅免費AI視頻/圖像生成工具,支援seedance2.0等多個主流模型,小白必試
完成我把DeepSeek的技術報告做成了科普視頻
參考3Blue1Brown風格,用Manim同HyperFrames將DeepSeek技術報告做成科普視頻
完成從知識庫到神經系統:企業大腦的第三層
企業大腦第三層:行動記憶讓公司真正「記住點樣運作」
完成AI視頻工具悄悄走到了第三階段
AI視頻工具進化到第三階段:畫布原生Agent,由RHTV示範透明協作同生態賦能
完成Claude Code、Codex 的正確用法,是 Goal-Driven
AI Coding 嘅真正革命:持久執行能力,人類由寫 Code 改為定義目標
完成Hermes 比 OpenClaw 慢10倍,為什麼還有人用?
Hermes 雖然慢但會自己學習,越用越懂你;OpenClaw 快但每次都要重新教
完成OpenSpec + Superpowers:一個管寫什麼,一個管怎麼做,6 步實現 AI 規格驅動 TDD 開發(實戰版)
OpenSpec 管規格,Superpowers 管執行,組合出 TDD 完整工作流
完成OpenSepc新版本新提升
小夥伴們大家好,我是小溪,見字如面。OpenSpec升級到了1.x版本,玩了2天發現相對於老版本來說還是有不小變動的,不僅提供了更靈活的協同工作流程,還支持了自定義工作流模式。習慣使用老版本和對老版本OpenSpec還不瞭解的小夥伴也可以往期內容:初識OpenSpec當前使用版本openspec 1.2.0優勢輕量化、靈活性和可擴展性進一步提高向下兼容,舊版變更可以使用 OPSX 命令繼續,製品結構是兼容的新增Skills技能調用方式更節省tokens提供更細粒度的擴展命令協同工作流程OpenSepc新版本協同工作流程如下:如何使用?需要 Node.js 20.19.0 或更高版本首先更新OpenSpec至最新版本,在命令行終端輸入如下命令:$ npm install -g @fission-ai/openspec@latest更新完成後,新項目直接進入項目根目錄進行初始化$ cd your-project$ openspec init舊項目也是可以用的,作者建議使用新版本命令,可以直接進入項目根目錄進行更新$ cd your-project$ openspec update想了解更多OpenSpec內容,但又看不太習慣英文的小夥伴,可以看OpenSpec社區中文版本,Github倉庫地址:https://github.com/studyzy/OpenSpec-cn,這裏給好心人點個贊基本使用命令行指令OpenSpec擴展了新的命令行指令,在命令行終端輸入 openspec -h 可以查看完整的命令行幫助文檔,這裏只列舉新增的功能,對已存在的指令還不瞭解的小夥伴可以看往期內容:初識OpenSpecconfig:查看並修改全局OpenSpec配置schema:管理工作流程模式feedback:提交OpenSpec反饋completion:管理OpenSpec CLI的Shell補全generate:生成Shell補全腳本install:安裝Shell補全腳本uninstall:卸載Shell補全腳本status:顯示變更的製品完成狀態instructions:輸出用於創建制品或執行任務的增強指引templates:顯示 Schema 中所有制品的解析後模板路徑schemas:列出可用的工作流 Schema 及其描述new:創建一個新的變更OpenSpec新增了CLI Shell自動補管理,我們只需要在命令行終端執行下面命令就會自動安裝$ openspec completion install安裝完成後重啓命令行終端,輸入 openspec comp 按下【Tab】快捷鍵就可以看到命令的自動補全效果了自定義命令和SkillsOpenSpec新版本提供了一套以 /opsx: 前綴的自定義命令 和 以 openspec- 為前綴的SkillsOpenSpec默認提供了4個自定義命令:/opsx:explore:深入思考想法、調查問題、明確需求,用於需求前的頭腦風暴/opsx:propose:開始一個新變更,會一次性生成所有規劃階段的製品如 proposal、specs、design、tasks/opsx:apply:實施變更中的任務,AI 會根據 tasks.md 中的任務清單逐一實現功能/opsx:archive:歸檔已完成的變更,會把整個變更文件夾移入存檔並將增量規範合併到主規範庫除了這套核心命令,OpenSpec還提供了一套更細粒度的擴展命令,需要通過 openspec config命令配置進行開啓。開啓需要在命令行終端輸入 以下命令:$ openspec config profileDelivery:在哪裏安裝工作流,比如在 Skills、CommandsWorkflows:工作流中哪些設計指令是可用的,比如 /opsx:explore、/opsx:new可以靈活選擇配置方式,這裏我選擇【Delivery and workflows】兩者都配置,接下來會先配置Delivery,選擇Both同時生成Skills和Commands然後配置Workflows使用【Space】快捷鍵選中需要的命令最後輸入【Y】確認更新完成後就可以看到更新後的全部配置了OpenSpec其他自定義命令:/opsx:new:開始一個新變更,只創建一個空的變更目錄/opsx:continue:基於依賴關係創建下一個製品,就是一步步創建 proposal、specs、design、tasks/opsx:ff:Fast-Forward 快速一次性創建所有規劃製品 proposal、specs、design、tasks/opsx:verify:校驗實現是否與製品匹配/opsx:sync:將增量規範合併到主規範中,通常不需要手動執行/opsx:bulk-archive:批量歸檔多個變更/opsx:onboard:完整的 OpenSpec 工作流引導教程OpenSpec目錄結構OpenSpec新版本目錄結構也發生了變化,移除了 project.md 和 AGENTS.mdopenspec/├── config.yaml # 新增,項目上下文和規則配置├── project.md # 已移除,項目規範約定├── AGENTS.md # 已移除,為Agent提供的OpenSpec使用說明,├── specs/ # 源規範目錄,每次變更歸檔後會合併到這裏│ ├── spec.md # 源需求和場景規範│ └── design.md # 源技術模式├── changes/ # 提案變更目錄│ ├── [change-name]/ # 單個提案變更│ │ ├── proposal.md # 為什麼,什麼,影響│ │ ├── tasks.md # 實施檢查清單│ │ ├── design.md # 技術決策(可選;見標準)│ │ └── specs/ # 增量變更規範│ │ └── [capability]/│ │ └── spec.md # ADDED/MODIFIED/REMOVED│ └── archive/ # 已完成的提案變更項目初始化使用OpenSpec新版本初始化項目,首先在命令行終端進入到項目根目錄,執行 openspec init,使用【space】快捷鍵選擇自己使用的AI工具確認配置後回車使用IDE打開可以看到如下目錄結構,在 commands/ 目錄下創建了 opsx/ 命令集,在 skills/ 目錄下創建了對應的技能,同時創建了openspec 配置目錄創建變更提案OpenSpec新版本創建變更提案的命令和老版本沒有太大差異,只是做了命令的變更,新版本可以使用 /opsx:propose 需求描述創建 創建變更,也可以使用 /opsx:new 需求描述創建創建變更,甚至可以通過自然語言使用Skills能力創建變更提案創建一個登錄授權功能提案這裏以新版本提供的 /opsx:new 命令為例,記錄一下創建變更提案的流程。首先使用下面命令創建一個變更提案:/opsx:new 創建一個登錄授權功能可以OpenSpec只創建了變更目錄 add-login-auth 和 .openspec.yaml文件並沒有創建我們之前所熟悉的 proposal.md、specs/[capability]/spec.md、design.md 和 tasks.md要創建上面所需的配置文件,我們需要再次執行 /opsx:continue 命令,到這一步OpenSpec才真正開始創建變更提案內容,與AI確定好問題邊界後提交執行完成後,可以看到此時才創建了 add-login-auth/proposal.md相當於單步執行檢查提案沒有問題後再次執行 /opsx:continue 會繼續生成 add-login-auth/design.md待 proposal.md、design.md、tasks.md 都生成後,再次 /opsx:continue OpenSpec會檢查artifacts狀態,告訴我們下一步該執行的操作當然也可以創建提案後直接執行 /opsx:ff,一步完成所有artifacts工作,到這裏變更提案階段就算完成了,下一步就可以實施任務了。實施任務與歸檔實施任務、歸檔操作和舊版本也沒有太大變化,只是將命令調整為了 /opsx:apply 和 /opsx:archive,歸檔後的文件目錄和舊版本也基本是保持一致的自定義項目配置OpenSpec提供了 項目配置、自定義模式、全局覆蓋 3個 級別的自定義:項目配置:針對項目生效,位於 openspec/schemas/,支持設置默認值,注入上下文/規則,適合大多數團隊自定義模式:定義自己的工作流製品,適合有獨特流程的團隊全局模式:針對所有項目生效,位於 ~/.local/share/openspec/schemas/,在所有項目間共享模式,適用於高級用戶項目配置在移除 project.md 和 agent.md 後,OpenSpec新版本中新增了 openspec/config.yaml 文件承擔了部分原本由這些文件負責的“項目常識”管理功能。openspec/config.yaml 文件是為團隊自定義OpenSpec的最簡單方法,它允許我們:設置默認模式:在每個命令上跳過 --schema注入項目上下文:AI 看到你的技術棧、約定等添加每個製品的規則:特定製品的自定義規則默認工作模式的配置方式大致如下:# openspec/config.yamlschema: spec-drivencontext: | 技術棧:TypeScript、React、Node.js API 約定:RESTful、JSON 響應 測試:Vitest 用於單元測試、Playwright 用於端到端測試 代碼風格:ESLint 搭配 Prettier、嚴格 TypeScriptrules: proposal: - 包含回滾計劃 - 識別受影響的團隊 specs: - 使用 Given/When/Then 格式描述場景 design: - 為複雜流程包含序列圖自定義模式當項目配置不夠時,創建具有完全自定義工作流的模式。自定義模式位於項目的 openspec/schemas/ 目錄中,並與代碼一起進行版本控制。your-project/├── openspec/│ ├── config.yaml # 項目配置│ ├── schemas/ # 自定義模式在此│ │ └── my-workflow/│ │ ├── schema.yaml│ │ └── templates/│ └── changes/ # 你的變更└── src/創建自定義模式最快的方法是 派生內置模式,即通過克隆複製一份默認的內置模式$ openspec schema fork spec-driven my-workflow這個命令會將整個 spec-driven 模式複製到 openspec/schemas/my-workflow/ 目錄下文件大致描述如下:openspec/schemas/my-workflow/├── schema.yaml # 工作流定義└── templates/ ├── proposal.md # 提案製品的模板 ├── spec.md # 規範的模板 ├── design.md # 設計的模板 └── tasks.md # 任務的模板系統內置的提示詞模版如下:# schema.yamlname: my-workflowversion: 1description: Default OpenSpec workflow - proposal → specs → design → tasksartifacts:- id: proposal generates: proposal.md description: Initial proposal document outlining the change template: proposal.md instruction: > Create the proposal document that establishes WHY this change is needed. Sections: - **Why**: 1-2 sentences on the problem or opportunity. What problem does this solve? Why now? - **What Changes**: Bullet list of changes. Be specific about new capabilities, modifications, or removals. Mark breaking changes with **BREAKING**. - **Capabilities**: Identify which specs will be created or modified: - **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<name>/spec.md`. Use kebab-case names (e.g., `user-auth`, `data-export`). - **Modified Capabilities**: List existing capabilities whose REQUIREMENTS are changing. Only include if spec-level behavior changes (not just implementation details). Each needs a delta spec file. Check `openspec/specs/` for existing spec names. Leave empty if no requirement changes. - **Impact**: Affected code, APIs, dependencies, or systems. IMPORTANT: The Capabilities section is critical. It creates the contract between proposal and specs phases. Research existing specs before filling this in. Each capability listed here will need a corresponding spec file. Keep it concise (1-2 pages). Focus on the "why" not the "how" - implementation details belong in design.md. This is the foundation - specs, design, and tasks all build on this. requires: []- id: specs generates: specs/**/*.md description: Detailed specifications for the change template: spec.md instruction: > Create specification files that define WHAT the system should do. Create one spec file per capability listed in the proposal's Capabilities section. - New capabilities: use the exact kebab-case name from the proposal (specs/<capability>/spec.md). - Modified capabilities: use the existing spec folder name from openspec/specs/<capability>/ when creating the delta spec at specs/<capability>/spec.md. Delta operations (use ## headers): - **ADDED Requirements**: New capabilities - **MODIFIED Requirements**: Changed behavior - MUST include full updated content - **REMOVED Requirements**: Deprecated features - MUST include **Reason** and **Migration** - **RENAMED Requirements**: Name changes only - use FROM:/TO: format Format requirements: - Each requirement: `### Requirement: <name>` followed by description - Use SHALL/MUST for normative requirements (avoid should/may) - Each scenario: `#### Scenario: <name>` with WHEN/THEN format - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently. - Every requirement MUST have at least one scenario. MODIFIED requirements workflow: 1. Locate the existing requirement in openspec/specs/<capability>/spec.md 2. Copy the ENTIRE requirement block (from `### Requirement:` through all scenarios) 3. Paste under `## MODIFIED Requirements` and edit to reflect new behavior 4. Ensure header text matches exactly (whitespace-insensitive) Common pitfall: Using MODIFIED with partial content loses detail at archive time. If adding new concerns without changing existing behavior, use ADDED instead. Example: ``` ## ADDED Requirements ### Requirement: User can export data The system SHALL allow users to export their data in CSV format. #### Scenario: Successful export - **WHEN** user clicks "Export" button - **THEN** system downloads a CSV file with all user data ## REMOVED Requirements ### Requirement: Legacy export **Reason**: Replaced by new export system **Migration**: Use new export endpoint at /api/v2/export ``` Specs should be testable - each scenario is a potential test case. requires: - proposal- id: design generates: design.md description: Technical design document with implementation details template: design.md instruction: > Create the design document that explains HOW to implement the change. When to include design.md (create only if any apply): - Cross-cutting change (multiple services/modules) or new architectural pattern - New external dependency or significant data model changes - Security, performance, or migration complexity - Ambiguity that benefits from technical decisions before coding Sections: - **Context**: Background, current state, constraints, stakeholders - **Goals / Non-Goals**: What this design achieves and explicitly excludes - **Decisions**: Key technical choices with rationale (why X over Y?). Include alternatives considered for each decision. - **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation - **Migration Plan**: Steps to deploy, rollback strategy (if applicable) - **Open Questions**: Outstanding decisions or unknowns to resolve Focus on architecture and approach, not line-by-line implementation. Reference the proposal for motivation and specs for requirements. Good design docs explain the "why" behind technical decisions. requires: - proposal- id: tasks generates: tasks.md description: Implementation checklist with trackable tasks template: tasks.md instruction: > Create the task list that breaks down the implementation work. **IMPORTANT: Follow the template below exactly.** The apply phase parses checkbox format to track progress. Tasks not using `- [ ]` won't be tracked. Guidelines: - Group related tasks under ## numbered headings - Each task MUST be a checkbox: `- [ ] X.Y Task description` - Tasks should be small enough to complete in one session - Order tasks by dependency (what must be done first?) Example: ``` ## 1. Setup - [ ] 1.1 Create new module structure - [ ] 1.2 Add dependencies to package.json ## 2. Core Implementation - [ ] 2.1 Implement data export function - [ ] 2.2 Add CSV formatting utilities ``` Reference specs for what needs to be built, design for how to build it. Each task should be verifiable - you know when it's done. requires: - specs - designapply: requires: - tasks tracks: tasks.md instruction: | Read context files, work through pending tasks, mark complete as you go. Pause if you hit blockers or need clarification.# proposal.md## Why<!-- Explain the motivation for this change. What problem does this solve? Why now? -->## What Changes<!-- Describe what will change. Be specific about new capabilities, modifications, or removals. -->## Capabilities### New Capabilities<!-- Capabilities being introduced. Replace <name> with kebab-case identifier (e.g., user-auth, data-export, api-rate-limiting). Each creates specs/<name>/spec.md -->- `<name>`: <brief description of what this capability covers>### Modified Capabilities<!-- Existing capabilities whose REQUIREMENTS are changing (not just implementation). Only list here if spec-level behavior changes. Each needs a delta spec file. Use existing spec names from openspec/specs/. Leave empty if no requirement changes. -->- `<existing-name>`: <what requirement is changing>## Impact<!-- Affected code, APIs, dependencies, systems --># spec.md## ADDED Requirements### Requirement: <!-- requirement name --><!-- requirement text -->#### Scenario: <!-- scenario name -->- **WHEN** <!-- condition -->- **THEN** <!-- expected outcome --> # design.md## Context<!-- Background and current state -->## Goals / Non-Goals**Goals:**<!-- What this design aims to achieve -->**Non-Goals:**<!-- What is explicitly out of scope -->## Decisions<!-- Key design decisions and rationale -->## Risks / Trade-offs<!-- Known risks and trade-offs --># tasks.md## 1. <!-- Task Group Name -->- [ ] 1.1 <!-- Task description -->- [ ] 1.2 <!-- Task description -->## 2. <!-- Task Group Name -->- [ ] 2.1 <!-- Task description -->- [ ] 2.2 <!-- Task description -->當然我們也可以從0開始創建全新的工作流,我們可以自定義一個模式,在每次提案之前需要先進行調研,提案後直接產生tasks為例,在命令行終端輸入如下指令:$ openspec schema init research-first或者$ openspec schema init research-first --description "快速迭代工作流" --artifacts "proposal,specs,tasks"輸入Schema描述,選擇artifacts製品確認配置輸入【y】回車選擇將 research-first 設置為默認Schema創建完成後,我們將得到一個Schema項目# schema.yamlname: research-firstversion: 1description: "調研驅動工作流:Research -> Proposal -> Tasks"artifacts:- id: research generates: research.md description: "初步調研與可行性分析" template: research.md instruction: | 針對用戶需求進行深度調研。 1. 分析當前代碼庫的相關實現。 2. 提出至少兩種可能的實現思路。 3. 評估各方案的優缺點及潛在風險。 requires: []- id: proposal generates: proposal.md description: "最終選定的實施提案" template: proposal.md instruction: | 基於 research.md 的調研結果,確定最終實施方案。 1. 明確變更的具體範圍。 2. 描述對現有系統架構的影響。 3. 定義成功交付的標準。 requires: [ research ]- id: tasks generates: tasks.md description: "可執行的任務清單" template: tasks.md instruction: | 根據 proposal.md 的內容,分解為可直接執行的代碼任務。 1. 任務需具備原子性(每個任務對應 1-2 個文件修改)。 2. 包含必要的測試任務。 requires: [ proposal ]apply: requires: [ tasks ] tracks: tasks.md配置項字段:id:唯一標識符,用於命令和規則generates:輸出文件名(支持通配符如 specs/**/*.md)template:templates/ 目錄中的模板文件instruction:AI 創建此製品的指令requires:依賴項 - 哪些製品必須先存在# research.md# Research: {{change_name}}## 1. 現狀分析## 2. 方案探索### 方案 A: [簡述]- **實現路徑**: - **優點**: - **風險**: ### 方案 B: [簡述]- **實現路徑**: - **優點**: - **風險**: ## 3. 調研結論# proposal.md# Proposal: {{change_name}}## 1. 變更目標## 2. 詳細變更內容- [ ] 修改點 A- [ ] 新增組件 B## 3. 技術約束- 涉及文件: - 性能/安全考慮:# tasks.md# 任務清單## 前置任務- [ ] 完成 research.md 的撰寫和審核- [ ] 完成 proposal.md 的撰寫和審核## 實施任務- [ ] [任務1描述]- [ ] [任務2描述]- [ ] [任務3描述]- [ ] ... ## 測試任務- [ ] [測試任務1描述]- [ ] [測試任務2描述]- [ ] [測試任務3描述]- [ ] ... ## 文檔任務- [ ] 更新相關技術文檔- [ ] 編寫用戶手冊或操作指南- [ ] 記錄變更日誌## 審核任務- [ ] 代碼審核- [ ] 測試報告審核- [ ] 文檔審核接下來修改 openspec/config.yaml 文件,配置 research-first 為默認schema或者使用命令行指定$ openspec new change feature --schema research-first 在使用自定義schema之前,我們需要先對它進行驗證,在命令行終端輸入命令$ openspec schema validate research-first驗證沒有問題後就可以重新創建變更提案了/opsx:propose 添加暗黑模式最終效果如下,OpenSpec按照我們提供的工作流模版輸出了對應的變更提案製品,檢查無誤後就可以實施任務了。全局模式OpenSpec也支持用戶級schema,位於 ~/.local/share/openspec/schemas/,用於跨項目共享,但是更推薦使用項目級schema,因為它們與你的代碼一起進行版本控制,使用方式和自定義一致。點擊關注,及時接收最新消息
完成0基礎玩轉obsidian:AI時代必備本地知識庫工具
AI時代用Obsidian做本地知識庫底座,由安裝到進階完整指南
完成什麼?AI居然要花錢用
AI 收費唔係離譜,離譜係你冇諗過佢點生存
完成Anthropic 兄妹 Dario Amodei 和 Daniela Amodei 最新對話:Claude 為什麼一直限速?
Anthropic 因 80 倍增速被迫限速,組織級 AI 係未來六個月最令人興奮嘅能力
完成花費260元,我給各家 Coding Plan 從夯到拉排名
K姐自費260蚊實測7款Coding Plan,火山引擎方舟性價比最高,智譜GLM-5-Turbo表現頂級但難搶
完成這個封裝了我3年自媒體經驗的AI熱點網站,今天向所有人免費開放。
作者公開咗自己用嚟監控AI熱點嘅網站,背後係三年自媒體經驗同11版評分策略嘅迭代。
完成豆包 Seed 2.0 Lite升級:給 Agent 裝上眼睛和耳朵
豆包 Seed 2.0 Lite 升級,用低價全模態畀 Agent 睇片聽嘢,解決字幕痛點
完成Codex 新命令 /goal 深度解析
/goal 命令令 Codex 擁有長任務追蹤能力,背後係持久化加運行時核算嘅實踐
完成從 Prompt 到 Harness:AI 編程真正缺的是工程紀律
AI編程真正缺嘅係工程紀律,唔係更勁嘅prompt。呢篇整理《Harness Engineering橙皮書》嘅方法論,教你建立指令、回饋、記憶同編排系統,令AI穩定產出。
完成當我把鍵盤放下,對着AI說了一天話來解決我的日常工作
用語音同AI協作,將碎片時間嘅產出密度翻倍:TRAE SOLO + Insta360 Mic Air 實戰分享
完成Cloudflare 聯手 Stripe:讓 Agent 自己開賬號買域名
Cloudflare 聯手 Stripe:讓 AI Agent 自己開賬號、註冊域名、畀錢
完成把視頻變成圖文博客:Agent + 豆包 Seed2.0 lite 重做 Karpathy 兩年前的工作流
用多模態Agent工作流,將技術演講視頻自動轉成圖文並茂嘅博客,效率大幅提升
完成只有不斷迭代,才能讓 AI 的進步指數倍反饋到自己身上
不斷迭代先係AI時代嘅真正槓桿——作者用三年實戰經驗話你知點樣駕馭模型
完成Codex必須要安裝的1個工具包!awesome-codex-skills實戰筆記,讓Codex真正「幹活」了
Awesome-codex-skills 令 Codex 由「寫 Code」變成「做嘢」嘅關鍵工具包
完成玄學自媒體神器!這個 AI Agent 自動算八字、解紫微,內容標準化又專業
AI 命理工具 MingLi-Bench:自動算八字解紫微,內容標準化又專業
完成豆包都開始收費了...分享我的常用AI工具箱
作者因豆包收費而分享自己喺唔同場景用嘅AI工具箱,強調按需選用,冇一招通吃。
完成發現一個寶藏工具:openclaw換模型,終於不用手改配置了!
CC Switch 神器:界面化切換模型,唔使再手改配置