🔧 阿川の電商水電行
介紹
使用生成 AI 的開發方法不斷出現。
我平常多數是在做網頁應用程式（使用 TypeScript 的客戶端/伺服器）、雲端的 MCP Server、批次處理（使用 Python）等。目前我會分享我正在實行的「使用生成 AI 的開發方法」。最佳解因人而異，希望這能對你有所幫助。
※ 我想三個月後可能又會有不同的方法。
我的開發方法的演變
- 2025 年初：主要使用 Claude Code
- 2025 年 8 月左右：轉移到基於規範驅動 + SubAgent 的 Claude Code
- 2025 年 11 月左右：轉移到 OpenAI 的 Codex
這篇文章適合誰？
適合的人：
- 正在開發多層（客戶端-伺服器-資料庫等）應用程式的人
不太相關的人：
- 寫幾個檔案內就能完成的腳本的人（例如：1個檔案的 Python）
- 如果能流利使用日文或英文，不論怎麼做大致上都能順利進行
開發方法
概要
- macOS
- 使用 VSCode + Codex 擴展功能（基本模型是
GPT-5.2-Codex/ 推理：xhigh） - 首先在
docs/dev/{feature_name}/{requirements,design}.md寫下需求定義和設計，然後進行審核 - 實作，並通過 lint / build / test
- 準備一個名為
my-review的 shell 腳本，自動化代碼審核 (重要) - （附加）準備通知用的
slack腳本會稍微方便一些
重點是準備 my-review，並在「完全獨立的上下文中」進行代碼審核。
對於 VSCode，要加上 Agent (full access)，而對於 codex-cli，則需執行命令 --dangerously-bypass-approvals-and-sandbox。這在風險上有所提高，但在「重要數據始終放在雲端」的前提下我接受這個風險。假如出現極端情況像是 rm -rf <略>，若有能力在一天內恢復，一般風險就相對低。
詳細
提示
以下的提示可通過「片段管理工具」等管理，並根據需要進行複製和粘貼。這樣無論是 Claude Code 還是 Codex 都可以使用。
例如「我想要這次的審查次數是三次」、「希望設計本身也能用 my-review 審查」等調整也很靈活。
請按照以下步驟進行。
1. 確定功能名，創建 feature/{feature_name} 分支並切換至該分支
2. 創建 docs/dev/{feature_name}/{requirements,design}.md。如果有問題請詢問我，最終請得到我的批准
3. 實施開發
4. 通過 lint, build, test
5. Bash 中透過 "my-review" 命令標準輸入發送訊息以獲得審查。
請傳達 docs/dev/{feature_name}/{requirements,design}.md 和開發內容，並指出與主分支的差異品質、設計的合理性、潛在錯誤、不足的測試等。
由於審查會需要一些時間，請將超時設置為 900 秒後再執行
6. 若有合理的改進點，請執行，然後再次進行第 5 步。此過程最多可重複兩次
7. 可以用 "slack <message>" 命令發送訊息告訴我已完成在討論開發內容後粘貼上述內容，或是先寫下需求再在最後粘貼上述內容都可以。
my-review shell 腳本
在環境變數 PATH 中的某個位置準備以下 my-review 腳本。
#!/bin/bash
exec codex exec -c model_reasoning_effort=high 2>/dev/null "$@"這裡特意設計為 model_reasoning_effort=high。理由是，我認為審查不一定需要深入的思考。雖然設定為 xhigh 可能會更好，有時以 medium 應該也足夠，但我對 high 也不會不滿意。
slack shell 腳本（附加）
在環境變數 PATH 中的某個位置準備以下 slack 腳本。最後的 URL 請替換為你自己的 Slack Incoming Webhook。
#!/bin/bash
MSG=$(echo $@ | tr -d '"=')
exec curl -X POST --data-urlencode "payload={\"text\":\"message: ${MSG}\"}" https://hooks.slack.com/services/T00XXX00/BDXXXXXXXX/XXXXXXXXXXXXXXXXXXXX這個腳本是我很久之前隨便寫的，但基本通知都能正常發送。「審查結束時的提示聲不明顯」、「即使離席也能透過手機收到通知（讓家務進展順利）」等理由，我都準備了這個。
為什麼這是最強的
強大的代碼審查及反饋過程
我最喜歡的是通過 my-review 進行的代碼審查。通常會有重要的指摘回應。
「真正的問題」、「對邊緣情況的不考量」、「應該添加測試」等，都是讀起來讓人信服的指摘。
有趣的是，即使是用 Codex（gpt-5.2-codex）寫的代碼，或者 opus-4.5 寫的代碼，仍然會有不少「重要的指摘」被返回。即使是同一模型寫的代碼也會有不同的指摘，因此我感覺代碼審查更適合在獨立的上下文中進行。
就像人類一樣，昨日寫的代碼今天再看時可能會感覺「這一點有點問題……」，這可能在 AI 中也會發生。
當引入這一過程時，完成時間會延長至十幾分鐘，但不僅代碼品質提高，功能的疏漏也會減少，因此最終錯誤會減少，提交後的返工也會降低。從總體而言，開發速度會上升。
Codex 的特性
高效的編碼能力
Codex 具有非常高的代碼生成和理解能力。特別是 gpt-*-codex 系列，因為專注於代碼生成，所以寫代碼的能力很強。
在 sonnet/opus-4 到 4.5 的時候我注意到「不知不覺中代碼重複了」、「局部是正確的，但整體的一致性不足」等問題，但在 Codex 中卻很少感受到這些。它能夠生成較少重複且整體一致的代碼。
※ 在 Codex 中，如果不將 xhigh 設為標準，medium 時容易出現問題，因此在生成代碼時建議使用 xhigh。
簡練的溝通
當使用 opus-4.5 來撰寫需求/設計時，常出現多餘的日文或過度詳細化而最終崩潰的情況。
而 gpt-*-codex 則很少出現這些問題，能簡練地撰寫需求定義和設計。
最終使得審查變得輕鬆（雖然不是全寫，但錯誤也較少，這是合適的粒度）。
不迎合人類
當我說「這裡應該是這樣吧？」時，它會反駁說「那是錯的」，這是相當頗有力的反駁。opus-4.5 會比較迎合人類，通常會說「是的，正確」，而 gpt-*-codex 則會反駁，因此使設計和需求定義的精度提升。
這方面也涉及個人喜好，因為每次自我讚美或靜音說「這個主意真好！」的 opus 常常讓我覺得「這句話不需要……」，因此我不太喜歡這種迎合，但偶尔讚美我也並不討厭。
每週資源容量大
我的訂閱為 GPT Pro（$220?/月），因此 Codex 的使用量相當龐大。
每週大約使用了 30 至 50 小時的 Codex，但通常仍可保留 20-40% 的使用量。
常常有 1 到 2 個並行的作業，即便如此仍有相當的餘裕。
※ 這可能只是因為我沒有充分利用。
或許 opus-4.5 也能相同地保持少量的返工，但我印象中 opus-4.5 往往會需要大幅重寫，最終浪費了時間和資源。這完全取決於應用的性質以及我對其使用的掌握能力。
在 GPT Plus 也可以使用 Codex。如果不需要它寫代碼，只使用 my-review，用 Plus 也足夠，所以建議可以先試試 Plus。
略有不足之處
雖然我認為這是目前最強的，但還是有一些不足之處。
可能會忽視指示
尤其是在撰寫需求定義和設計時，經常會忘記「拿到我的批准」。雖然在順利進行的時候還行，但在複製和粘貼模板指示過後，跟幾次互動後容易忘記。在 opus-4.5 中則幾乎沒有這種情況。
雖說這也是個小瑕疵…但如果產生了誤解就會造成返工，因此在我認為「此次確認很重要」的時候，會避免多餘的互動直接開始，或是透過最初僅交付 "1, 2" 來進行一些調整。
時間成本
當然這也取決於規模，但我感覺每回合需要 10 到 40 分鐘（包含 2 次代碼審查）。
40 分鐘大致是在編寫較大功能（例如：創建一個類似文件系統的功能以作為內部工具）時的時間，而大約 10 分鐘則是在編寫小功能（例如：某個實體的 CRUD）時的時間。
就速度而言，opus 確實給人的印象似乎要快一些，但考慮到代碼的品質及其錯誤的少量，Codex 總體上應該要快一些。
參考
Codex 的設定
設定通知的音效可以在處理結束時更易於識別（以下示例為 Mac 用）。
通常的設定如 sandbox_mode, approval_policy, sandbox_workspace_write.network_access，我認為這些相對安全且易於使用。
詳細的內容請參見 這裡。
~/.codex/config.toml (截至 2025 年 12 月)
sandbox_mode = "workspace-write"
approval_policy = "on-failure"
notify = ["bash", "-lc", "afplay -v 20 /System/Library/Sounds/Blow.aiff"]
model = "gpt-5.2-codex"
model_reasoning_effort = "xhigh"
[features]
web_search_request = true
rmcp_client = true
[sandbox_workspace_write]
network_access = true最後
我漸漸覺得「只需思考就能寫出代碼 ≒ 自動化・標準化・應用程式化」已經變得可行。
原文出處：https://qiita.com/mokemokechicken/items/e63081de6a379905ecf5
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
