AI 寫的 code 已到 production ready，公司導入的條件才剛到位

從 2021 年開始接觸這一波 AI，幾年下來，最近才覺得 AI 足夠聰明。過去拿到產出後，還要花很多時間重寫，現在已經能把力氣放在檢查和交付。

現在用 AI 寫 code，已經能做到下面四件事：

1. code 的品質已經達到 production ready 的程度，可以接著測試、部署，不必先整段重寫。
2. context 的數量夠長，不會一直忘東忘西，長任務也不用反覆補回同一份背景。
3. 在不同的情境能準確使用對應的 skill，大幅增加 AI 產出的精確度。
4. 因為品質好，因此不用進行太多的 code review，工程師可以把時間留給必要的風險檢查。

code 能進 production，才算真的省下 review 時間

早期用 AI 寫 code 時，問題很容易在接手後出現，函式看起來完整，放回原本的專案卻接不起來；需求稍微拉長，前面談好的限制又被忘掉。工程師名義上在 review，實際工作更接近重寫。

production ready 帶來的差別，就在 code review 的內容。現在檢查的是測試有沒有覆蓋、邊界有沒有處理、改動會不會影響既有流程。review 仍然要做，但不用把命名、結構與錯誤處理全部重來。

四個條件也不能拆開看，code 寫得好，context 太短，長任務仍會中斷；context 留得夠多，skill 選錯，結果還是會偏離公司的做法，品質、記憶、規則與檢查同時到位，AI 才能接進日常開發。

context 變長之後，公司還要補上自己的規則

模型記得住需求和程式時，也只解決了忘記事情的問題，公司每天處理的工作，還有自己的步驟、限制、資料來源與完成標準。這些內容沒有整理好，AI 只能每次重新猜。

公司專用 skill 會把做事方法寫清楚，包含什麼情境要走哪些步驟、哪些限制不能碰、要做哪些檢查，以及看到什麼結果才算完成。任務進來後，只要能找到正確的 skill，產出就會靠近團隊原本的標準。

接到任務時，MCP 負責把外部工具與資料接進來。harness 再把模型、skill、MCP 和工作流程放在一起，決定先讀什麼、何時呼叫工具、失敗後怎麼處理。三者各自處理一段工作，員工不用在每個步驟中間複製資料。

導入時，公司先整理常做的工作，再把規則寫成 skill，會比要求每位員工各自研究 prompt 更穩定。流程有修改時，也只要更新同一份規則，不必逐一通知大家改問法。

Hermes 減少調教，Codex 訂閱壓低使用成本

工具夠不夠聰明，最後會反映在每天花多少時間照顧它。Hermes 比起 OpenClaw 聰明很多，不需要花太多時間調教，也能自我優化。工作方法改變後，不必一直從頭教它如何處理同一類任務。

另一個差別是費用，Hermes 可以搭配 Codex 訂閱方案，先用固定方案承接日常工作。若所有任務都按呼叫量計費，用 API 太貴了；流程跑得越頻繁，成本也會跟著增加。

導入 AI 時，不只看模型回答得好不好，還要算維護和使用的總成本。每週花多少時間修 prompt、同一個流程要跑幾次、失敗後要不要有人接手，最後都會變成公司的支出。調教時間下降，費用可以預估，AI 才適合長期放在工作裡。

domain knowledge 不夠，token 只會花在錯的方向

其實沒有不好的時機，更早開始，可以更早知道哪些工作適合交給 AI。現在開始，則能直接使用比較成熟的模型和工具，遇到錯誤答案時，團隊有沒有人看得出來，才會拉開差距。

只看文字表面，AI 很會把答案寫得像真的。被 AI 唬爛時，缺少 domain knowledge，就很難知道哪個前提有問題、哪個數字需要重查、哪段內容應該整段退回。文字愈完整，錯誤有時反而藏得愈深。

domain knowledge 讓人知道合理答案的範圍，也知道要補哪些資料，才能引導 AI 往正確的方向。這份判斷可以來自公司內部，也可以由外部協助補上；重點是不能把模型的流暢當成正確。

沒有專業顧問可以處理，團隊往往要花很多時間踩坑。第一步的方向錯了，後面的 skill、MCP 和自動化流程仍會照著錯誤前提往下跑，產出愈多，回頭修正的範圍愈大。

這時候繼續加 prompt，不會自然得到正確答案。它只會白白消耗 token，把錯誤做得更完整，最後永遠無法解決問題。公司需要能在一開始把問題帶回正確方向的人，不需要更多文字。

以上是我自己的經驗和看法，僅供參考。

• 原始素材：Peter 的 AI 導入 handover 與逐輪回饋；本文沒有新增 Peter 未提供的案例或經驗。
• 寫作研究：逐篇分析 20 篇《天下雜誌》熱門文章的用字、句型與段落節奏，再依歸納結果從零重寫 v10。
• 封面概念：四條線代表 code、context、skill 與 review，匯入同一台 production 機器；畫面唯一英文為 READY。
• 內文圖 1：code 品質、context、skill 與 review 四個條件同時到位，AI 才適合接進公司的 production 流程。內文圖 2：MODEL、SKILL 與 MCP 匯入 HARNESS，再把 TASK 轉成 DELIVERY。
• de-AI 驗證：1719 字、最長語段 60 字、分號 5 個、第一人稱 2 個、22 個 Peter beats、deai_scan 綠帶；Peter 於 2026-07-14 通過 v10 人工驗收。
• Pipeline：目前為待審，不填實際發布日、不標 Published，也不在這個階段 @mention Peter。

[heading_4 block — not yet supported]

• Phase 2 內部一致性：「四件事／四個條件」全篇出現 3 次（開場列點、中段「四個條件也不能拆開看」、圖說），指涉對象一致（code 品質、context、skill、review），計數正確。字數 1719 與 properties「字數」欄一致。全文無表格、無算術可覆算。全文無 (參N) 引用標記——本文屬 §5.6 個人心得文，結尾已有「以上是我自己的經驗和看法，僅供參考」豁免外部 reference，符合 §3-B（因果鏈顯式：從 2021 年接觸到現在的對比；沒有需要外部佐證的統計 / 百分比 / 具名機構斷言）。未發現數量、單位、日期前後不一致，未發現低級 typo。
• Phase 3 外部覆查：本文無外部引用可查證（純第一人稱經驗談），略過 WebSearch 覆查；「Hermes」「OpenClaw」「Codex」為工具比較，屬主觀經驗評價非查證性事實斷言。
• Phase 5 防掉字自檢：top-level block 數、清單項數（4 件事）、H2 數（4）、圖片＋圖說（1 則）皆與原稿一致，本次未做任何結構調動、未修改任何字。
• 判定：無嚴重問題、無 flag 需要 Peter 拍板 → 狀態 待審 → 待潤（交 style-reviewer）。