昨天，Codex 再一次重置了額度，我們的賬號從剩餘 10% 又回到了剩餘 87%。
Codex 負責人 Tibo 在 X 發文，
有些用戶注意到 Codex 中的緩存限制消耗得更快，我們發現根本原因是之前的一個優化措施，該措施在長時間運行的會話中進行壓縮時會影響緩存命中率，我們已將其回滾。
我們已修復此問題，並已重置所有賬戶的使用限制。祝您周末愉快。
於是又想著還可以用 Codex 來做點什麼，剛好就在 X 上刷到了「我用 Codex 提升了我的電腦網速，從 400Mbps 到 900Mbps。」
內容真的很有噱頭，用 Codex 竟然能優化本地的網路？網速不應該是受限於路由器，或者網路服務提供商 ISP 這些上層設備嗎？
這則推文的留言區也有不少網友提出了質疑，「所以 Codex 最終改變了電腦上的什麼配置？」、「鑑於如今 AI 的強大技術，我真的無法判斷這是否是誘餌。」
博主做出解釋，Codex 幫助他把電腦上的 auto tuning level 從關閉調回了 normal 正常。auto tuning level 是說系統會根據網路延遲、頻寬和擁塞情況，動態決定一次能接收多少數據，從而提高網路的速度。
他還給出了自己用的提示詞。
嘿，我朋友說他的網速提高了，情況是這樣的。你能幫我看看我們家的網路有什麼可以改進的地方嗎？我的網路供應商說他們提供的頻寬是 1.2k Gbps，而我實際的網速是硬體問題。我現在只有 55Mbps，請幫我解決這個問題，別出錯了。
我的目標很簡單，就是讓我的網際網路速度更快。
問題已診斷：首先運行了 speedtest-cli。
檢查了 DNS 解析時間，
檢查了 MTU、丟包率、Wi-Fi 信號/干擾情況。
發現 3 個問題。
已刪除過時的網路位置/配置文件。
終止或限制占用大量頻寬的後台進程。
優化 mDNS。
進行了測試前後的速度測試和延遲檢查。
這套提示詞來自另一個 X 推主@cjzafir，他分享了自己使用 Codex + GPT 5.5 的實際案例，裡面提到了 Codex 5.5 讓他的網速變快了，本地運行的 6B 小語言模型速度更快了，以及 Macbook Pro 運行速度也像新的一樣快等等。
Codex 5.5 use cases I found so far: > made my internet faster > made my local 6B SLM 3x faster > made my macbook pro faster like new > made a lightweight suite to write & test metal kernals > made a skill to communicate with claude code in realtime > made a pipeline to generate SFT dataset using Deepseek v4 > made a computer use workflow to fine tune models in Google Colab > made 4 routines to test workflows on autopilot 3 times/day
It was a simple /goal to make my internet network faster. > Diagnosed the issue: ran speedtest-cli first. > Checked DNS resolution times, > Checked MTU, packet loss, Wi-Fi signal/interference. > Found 3 issues. > Removed stale network locations/profiles. > Killed or throttled bandwidth-hogging background processes. > Optimized mDNS. > Ran before/after speed tests and latency checks.
我們也拿著這套提示詞發給 Codex，在要求 Codex 處理網速問題前，先用中國科學技術大學測速網站 https://test.ustc.edu.cn/ 看了一下大概的速度，基本上下載速度在 100Mbps 左右，上傳是在 200 Mbps 左右。
Codex 確實按照這些診斷，從 DNS 解析時間，數據包、網路配置等方面，檢測並修復了對應的問題，累計處理時間超過五分鐘。
最後 Codex 得出的結論是「我檢查並做了能安全完成的修復。」它找到了 3 個存在的問題，分別是 DNS/緩存異常、負載延遲很高，以及有線千兆網卡沒有在用，Wi-Fi 不能作為 1Gbps 的驗收依據。
再次測試，發現似乎並沒有很明顯的網速提升。
有人問那位博主，是不是使用的 Mac 電腦，他回覆說是 Windows，底下還有網友科普，Mac 的網路配置都是固定了，Codex 一般是無能為力。
我昨天花了一些时间尝试在我Windows去优化网络，又让我嫌弃Windows电脑了，限制太多了，我没敢过度给它权限去处理，不过也给我诊断出很多网络端问题，我猜 @giyu_codes 肯定是在Mac上优化的吧。
Wow, thank you so much for your reply. I'll go ahead and try it on my Windows computer.
所以這次輪到 Windows 用戶來享受 Codex 網速提升服務了？還有 Linux。
有評論說，「以為是用 Codex 入侵了網路服務提供商，然後提高了流量限制」，結果只是 Codex 幫忙清理了一下 DNS 緩存。
Honestly it changed one major thing, but I would imagine there are a good bit of people who don't know that setting was turned off. When I googled it, the feature is supposed to be enabled by default but somehow it was disabled for me.
但也有網友分享照著這個方法，成功復現了，Codex 確實讓它的網速變快。
大家要是感興趣也可以試試，不過 Codex 修改這些網路配置還是有一定的風險，留言區還有人提到 Codex 把他原有電腦的網路配置都刪掉了，然後 Codex 跟他說，刪掉它們是為了讓網速更快。
這些涉及到 Computer Use 的使用案例，大概都會有類似的問題，除了每一次更細心的看懂允許 Codex 執行的是什麼命令，還可以在提出任務時，就要求它解釋清楚它要做的每一步。
如果不做修改，只是讓 Codex 去診斷一些可能存在的網路配置問題，我想也比那個一直停留在進度條的自帶 Windows 診斷要強。
開始了，Codexmaxxing
當大家都在討論 Codex 是否能真的提升網速時，也有網友提到這種用法其實是一種啟發。
昨天在 X 的英推看到一个很爆火和具有启发性的Codex玩法，中推还没看到有人提。 有人用 Codex 5.5（支持操作电脑的 AI Agent）大幅优化了网络速度，并在帖子里晒出了前后对比。 随后下面这位 @giyu_codes 用户做了件特别聪明的事： 他把整个原帖直接复制粘贴给 Codex，并附上一段自己的提示词： 「Hey my friend says he improved his internet speed and here is what happened. Can you check if there are any improvements we can make for our internet? My provider says they're sending 1.2k gbps and anything I get is a result of hardware. I'm getting 55mbps right now pls fix make no mistakes.」 他把「别人成功优化的真实案例」当作上下文喂给 Codex，让 Codex 参考那个案例，给自己当前的烂网速做针对性诊断和修复。结果就是网速起飞了。 我觉得这种做法的核心价值在于：不是自己凭空写 Prompt，而是把真实世界里已经验证成功的案例作为上下文喂给 AI，让 AI 参考成功经验，针对自己的具体情况进行精准诊断和优化。 感觉这是一种非常高级的靠案例驱动的提示技巧，目前在
他說這種做法的核心價值在於靠案例驅動，讓 AI 直接參考成功的經驗，再針對自己的具體情況進行精準診斷和優化，而類似的提示詞技巧在 Agent 產品上將非常有效。
這很像 Codex 裡面的 /goal 命令，給他一個目標，這個目標可以是我們自己設置的，也可以是其他用戶已經有的成功案例，Codex 照著這個目標，自己去摸索可以實現的路徑。
在社交媒體上，也有很多人開始分享這些寫目標的模板，以及 OpenAI 的工程師也專門寫了一篇文章來講清楚什麼是目標，如何用好目標來發揮 Codex 的最大價值。
/goal ，通過 驗證，同時保留 。使用 。在各次疊代之間，如果受阻或沒有剩餘有效路徑。
也有人認為這只是 Codex 的早期階段，所以我們才需要學習這麼多的提示詞技巧，無論是使用案例驅動還是使用 /goal 命令，本質上都是為了讓 AI 能更好的理解人類的需求。
就像 Midjourney 、Nano Banana 剛推出時，我們都熱衷於找各種公開的提示詞；而現在使用 GPT Image 2 在大多數的生圖場景下，基本上都不需要專門的提示詞格式，就能得到不錯的效果。
等到 Codex 越來越好用，我們或許也不再需要這些官方使用模板。但從另一個角度來看，或許就是在這種模仿使用的過程中，我們才會更知道 AI 是如何提升我們的生活和工作效率。
因此，除了提升網速，我們還看到了一些 Codex 的其他玩法。像是使用 Codex 的定時任務，讓它每天早上自動產出一份對應行業的日報；還有讓 Codex 也能獲得自我進化，從過去的對話裡面提取出有用的技能；以及直接構建一個 macOS 應用；把 DeepSeek 接入 Codex 客戶端等。
我們也繼續嘗試了一下那套讓 Codex 自進化的提示詞，它花了 7 分鐘，幫我們創建了 3 個 Skills。
感覺這套提示詞不僅僅可以用在 Codex 裡面，幾乎所有的 Agent 產品，都可以用它總結出一些可復用的流程，以子 Agent、Skill，或者自動化的形式重新編排。
回顧我最近 30 天的工作，若歷史記錄不足則查看所有可用歷史，並識別值得打包的重複性手動工作流。
按以下順序使用可用證據：
- 最近的 Codex 會話和任務摘要。
- Codex Memories 和 rollout 摘要，用於尋找跨會話重複出現的模式。
- 如果啟用了 Chronicle，用它發現 Codex 之外的重複工作。Chronicle 僅用於發現；重要細節儘量回到相關源系統確認。
- 現有技能、自定義智能體和自動化，優先復用或擴展已有內容，避免重複建設。
廣泛尋找那些重複、耗時、容易出錯、依賴上下文，或適合標準化流程的工作。範圍包括編碼、研究、寫作、規劃、溝通、運營、分析，以及個人事務管理。
只有滿足以下條件時，才把候選項納入：
- 至少出現過兩次，或明顯會重複出現且重複成本高；
- 輸入穩定、步驟可重複，並且輸出或結束條件明確；
- 能明顯提升速度、質量、一致性或可靠性；
- 當前還沒有被充分覆蓋。
選擇最小且合適的形式：
- Skill：可復用的工作流或操作手冊。
- 自定義子智能體：適合委派的、有邊界的專項角色或調查任務。
- 自動化：定時或周期性的檢查、報告、提醒或監控。
- Skip：過於一次性、模糊、敏感，或證據不足，不適合打包。
先輸出一個簡潔候選清單，包含：
- 重複工作流
- 支持證據與日期
- 頻率 / 置信度
- 推薦形式：skill、subagent、automation、擴展已有內容，或 skip
- 為什麼值得或不值得創建
然後只創建高置信度且當前缺失的項目。保持範圍狹窄、實用、了解數據來源，並且容易驗證。不要創建猜測性的、重疊的，或過於寬泛的資產。
最後總結：
- 你創建或擴展了什麼
- 你刻意跳過了什麼
- 哪些內容還需要更多證據後才能打包」
我們還依照 Tibo 分享的使用 Codex 來取消我們不需要的付費訂閱服務，由於訂閱項目較少，但是有很多無意中訂閱的 newsletter，所以我們輸入「請查看我的電子郵件，列出我付費訂閱的所有服務，以及訂閱了哪些郵件通知，並和我確認哪些需要取消訂閱。」
Codex 很快就調用了瀏覽器使用的工具，打開 Gmail，檢查我的電子郵箱，發現付費訂閱的項目較少，著重為我列舉了一些「可退訂的郵件通知」。
新加入 OpenAI 的員工 Jason Liu 也分享了如何榨乾 Codex 的用法，他提到自己喜歡使用 Codex 的語音輸入功能，所有的對話線程不再一次性重置，而是跨對話保留上下文，以及使用 Obsidian 庫來作為 Codex 的持久記憶層。
前段時間，我們分享了一篇文章，是說幾乎所有模型公司，都要做自己的 Agent 產品，模型公司和產品公司之間的界線會越來越模糊。
OpenAI CEO Greg 在 X 發文也提到他認為僅憑模型本身已經不再是產品；Google AI Studio 負責人 Logan 在跟帖中回復，模型、工具和產品之間的共生關係如今已成為一種趨勢。
從目前來看，Codex 大概會是體現 OpenAI 模型能力最有力的一個產品。
Codex 負責人 Tibo 提到「總體規劃是發布更好、更高效的模型，並且每周都發布更好的產品。還要增加計算能力。」
能從龍蝦、Claude Code 這些先占領市場的 Agent 產品里脫穎而出，Codex 的進展確實讓人值得期待。不過， Tibo 還貼心地提醒我們，好用，也記得多出去走走，Codex 沒法替我們體驗真實的生活。
