OpenAI 親自教你如何建構可靠的 AI 程式碼，從老派程式設計轉向 Agnet 程式設計，或 PUA 你的 AI

========================================================

其實在不少 AI Coding 的內容下，一直有不少人說，AI 寫的程式碼不夠好用，甚至感覺很傻，是不是自己的大模型能力不行？為什麼感覺我的 AI 和別人的 AI 好像不是一個東西？這個效果怎麼可以上生產？

實際上還真不是，雖然說不同大模型的能力上限確實是一個原因，但是實際你對 AI 工程的管理方式，還有你使用的 Agent 工具，也是影響 AI 程式設計結果的核心因素，例如：

同樣是 Claude ，但是它在 Claude Code、Cursor、Antigravity、Copilot、OpenCode、Kiro 和 Junie 裡的表現可是天差地別，孰好孰壞就不用我多說了吧？

另外你是在單純 Prompt AI 還是管理 AI 工程，整個生產體驗也會不一樣，用 AI 不是說完幾句話就可以不管等結果，比如常見的 SDD（規格驅動開發，Spec-Driven Development）的開發管理方式，它就需要很多文件來進行迭代、記錄和索引：

當然，我們今天要說的是 OpenAI 的 AI 工程實務，講的是：

OpenAI 如何使用 Codex，在五個月內完全不使用任何人工程式碼來構建並發布一款產品。

首先 OpenAI 明確了一個核心觀點：軟體工程的核心正在從「寫程式碼」轉向「構建 AI 執行系統（harness）」，工程師不再是「寫程式碼的人」，而是設計 AI 工作環境的人。

他們主要是做了一個真實的生產實驗，透過 3 名工程師，在五個月的時間，完全透過 Codex 完成一個 100 萬行程式碼的專案，期間所有程式碼、測試、CI、文件都由 Codex agents 自動生成，而人主要負責定義規則、結構和流程。

OpenAI 在這裡用 Harness Engineering 來表示這個場景，可以簡單理解 Harness Engineering = 為 AI Agent 構建運行系統（harness），它負責控制 agent、提供工具、管理執行和校驗結果。

這裡需要五個月的時間，主要是因為專案早期進展太慢，瓶頸也不是出在 Codex 上，而是因為環境定義不夠完善，導致 Agent 缺乏實現高層目標所需的工具、抽象概念和內部結構，這就和我們之前說的一樣，我們沒給 AI 一個完善的 Agent 運行條件，所以很多不必要的人工介入和返工都是在這裡產生。

很多時候你的 token 就是這樣浪費的。

針對這個，OpenAI 提供了一個 Harness 的核心實務經驗：

1、 Context Engineering（上下文工程）

你需要給 AI 足夠的上下文，因為 agent 的能力高度依賴上下文，你給的需求描述，決定了每次 Token 消耗的有效性，例如常見有：

倉庫（repo）文件
API 文件
程式碼結構
設計規範

這裡有個最重要的是，不要設計一個大型的 AGENTS.md 檔案，這是很致命的一個問題，這個我們在《GENTS.md 真的對 AI Coding 有用嗎》聊過，冗長的文件反而會產生副作用，OpenAI 也是這樣，AGENTS.md 只是作為目錄，AGENTS.md 只保留了大約 100 行，主要用做映射，並提供指向其他更深層次的連結：

<div><div><div></div><span>sql</span></div><div><div> <span>體驗AI代碼助手</span></div><div> <span>代碼解讀</span></div><div>複製代碼</div></div></div>```
<span>AGENTS.md</span>
<span>ARCHITECTURE.md</span>
<span>docs<span>/</span></span>
<span>├── design<span>-</span>docs<span>/</span></span>
<span>│   ├── index.md</span>
<span>│   ├── core<span>-</span>beliefs.md</span>
<span>│   └── ...</span>
<span>├── <span>exec</span><span>-</span>plans<span>/</span></span>
<span>│   ├── active<span>/</span></span>
<span>│   ├── completed<span>/</span></span>
<span>│   └── tech<span>-</span>debt<span>-</span>tracker.md</span>
<span>├── generated<span>/</span></span>
<span>│   └── db<span>-</span>schema.md</span>
<span>├── product<span>-</span>specs<span>/</span></span>
<span>│   ├── index.md</span>
<span>│   ├── <span>new</span><span>-</span><span>user</span><span>-</span>onboarding.md</span>
<span>│   └── ...</span>
<span>├── <span>references</span><span>/</span></span>
<span>│   ├── design<span>-</span>system<span>-</span>reference<span>-</span>llms.txt</span>
<span>│   ├── nixpacks<span>-</span>llms.txt</span>
<span>│   ├── uv<span>-</span>llms.txt</span>
<span>│   └── ...</span>
<span>├── DESIGN.md</span>
<span>├── FRONTEND.md</span>
<span>├── PLANS.md</span>
<span>├── PRODUCT_SENSE.md</span>
<span>├── QUALITY_SCORE.md</span>
<span>├── RELIABILITY.md</span>
<span>└── SECURITY.md</span>


比如在這裡：

- 設計文件也是一個目錄，裡面包括驗證狀態和一套以 Agent 為主的運行原則定義
- 架構文件提供了領域與套件分層的頂層映射圖
- plan 有分形態，輕量級的臨時計畫用於小的變更，而複雜的工作則記錄在執行計畫中，並附帶進度和決策日誌，這些日誌會被提交到程式碼庫

> 這些檔案結構，可以有效讓 Agent 能夠循序漸進從一個較小的、穩定的切入點開始，並理解下一步該關注什麼，而不是一開始就被大量資訊淹沒上下文。

##### 2、 Tooling（工具）

讓 agent 能執行真實操作，不是每次都由人工來執行，例如：

- Git
- shell
- CI（持續整合）
- 測試執行器（test runner）
- 建置系統（build system）

因為 agent 不只是會生成程式碼，而是 `寫程式碼 → 執行 → 修復` 這樣的流程閉環，才是 Agent 完整的能力，例如：

> 讓 Codex 在本地審查自己的修改，同時請求本地和雲端的其他特定 Agent 進行審查，並回應任何反饋，循環迭代，直到所有 Agent 審查都滿意為止（實際上就是一個 Ralph Wiggum 迴圈）。

這個過程裡 Codex 直接使用標準開發工具（gh、本地腳本和嵌入在程式碼庫中的技能）來收集上下文資訊，不需要人工複製貼上到命令列介面。

> 這裡換個 agent 審核很重要，因為就算是同一模型，換個上下文視窗就很容易找到自己寫的 bug，因為乾淨的上下文可以脫離作者的思維慣性，所以在 AI 開發裡，code review 絕對不要在同一個視窗進行，用一個 subagent 或者新的視窗才會有真的審查效果。

OpenAI 還讓專案 App 能夠依據 Git worktree 單獨啟動，這樣 Codex 每次更改都可以啟動並執行一個實例，可以同時並行進行專案修改和驗證調整。

![](https://i.imgur.com/sucpDbg.jpeg)

##### 3、 Feedback loops（回饋迴路）

Agent 需要一個完整的自動回饋系統，例如：

- CI（持續整合）
- 單元測試
- linter（程式風格檢查）
- 靜態分析

只有這樣 Agent 才能實現自驅動，這也是很多 AI Coding 裡經常缺失的環節，因為只有明確的測試約束和驗收標準，才能讓 AI 實現自驗自測，減少人工介入：

<div><div><div></div><span></span></div><div><div> <span>體驗AI代碼助手</span></div><div> <span>代碼解讀</span></div><div>複製代碼</div></div></div>```
<span>agent 寫程式碼</span>
<span>→ 測試失敗</span>
<span>→ agent 修復</span>
<span>→ 再次執行</span>

在 OpenAI 這個專案裡，專案的日誌、指標和追蹤資訊透過一個本地可觀測性堆疊暴露給 Codex，這個堆疊對於任何給定的 Worktree 都是臨時場景。

Codex 運行在完全隔離的版本上，其中包括對應的日誌和指標，這些日誌和指標會在任務完成後被銷毀，而 Agent 可以使用 LogQL 查詢日誌，使用 PromQL 查詢指標，有了這些上下文資訊，諸如「確保服務啟動在 800 毫秒內完成」或「這四個關鍵使用者旅程中的任何跨度均不超過兩秒」之類的提示，對於 AI 就變得更好處理。

4、 Architectural Constraints（架構約束）

最後，限制 AI 的行為也很重要，例如：

程式碼結構
模組邊界
API 規則
lint 規則

這些規則讓 agent 不會寫出混亂的程式碼，並盡可能按照規範來輸出程式碼，這裡有一個比較有意思的是：最好的 Agent 管理就是讓 Agent 能夠直接從程式碼庫中推斷出完整的業務領域。

所以作為工程師，需要在程式碼裡逐步添加更多上下文資訊，比如「討論某些需求的結論」、「針對某個需求變更需要做什麼調整」，這些都是很重要的架構和約束資訊，Agent 才不會在某些修改中，把迭代了三次的按鍵又改回了第一版的 UI。

另外，Agent 在邊界清晰、結構可預測的環境裡最有效，所以一個層級分明、流向清晰的結構才是最利於 Agent 維護，例如：

在每個業務領域（例如應用設定）內，程式碼只能透過一組固定的層級（型別 → 設定 → repository → 服務 → 執行時 → 使用者介面）進行「前向」依賴，而橫切關注點（身份驗證、連接器、遙測、功能旗標）透過一個明確的介面 Providers 進入，任何其他方式都被禁止，並且會強制執行。

目的很簡單，就是：集中執行邊界，允許本地自治。在 OpenAI 的觀點裡，生成的程式碼不一定總是符合人類的風格偏好，但這沒關係，只要輸出正確、易於維護，並且便於後續代理運行，就達到了標準。

事實上如果一個管理得當的 Agent 工程，在後期可以實現非常高效的並行開發能力，例如多 Agent 多 Worktree：

<div><div><div></div><span>css</span></div><div><div> <span>體驗AI代碼助手</span></div><div> <span>代碼解讀</span></div><div>複製代碼</div></div></div>```
<span>                Planner Agent</span>
<span>                     │</span>
<span>     ┌───────────────┼───────────────┐</span>
<span>     │               │               │</span>
<span> <span>Code</span> Agent1    <span>Code</span> Agent2    <span>Code</span> Agent3</span>
<span>     │               │               │</span>
<span> Worktree1       Worktree2       Worktree3</span>
<span>     │               │               │</span>
<span>   Test            Test            Test</span>
<span>     │               │               │</span>
<span>        └────── Merge / PR ────────┘</span>


> 這時候每個 Agent 可以同步處理一個 Bug 或者一個 Feature，然後基於對應的 Git worktree 去驗證和實施，最終再合併提交結果。

所以，可以看到，在古法程式設計裡，傳統軟體開發是：

<div><div><div></div><span></span></div><div><div> <span>體驗AI代碼助手</span></div><div> <span>代碼解讀</span></div><div>複製代碼</div></div></div>```
<span>設計</span>
<span>→ 寫程式碼</span>
<span>→ 測試</span>
<span>→ 部署</span>

而在 Agent-first（以 Agent 為先）開發場景下，工程師的角色變成了：

<div><div><div></div><span></span></div><div><div> <span>體驗AI代碼助手</span></div><div> <span>代碼解讀</span></div><div>複製代碼</div></div></div>```
<span>設計 harness</span>
<span>→ agent 生成程式碼</span>
<span>→ agent 測試</span>
<span>→ agent 修復</span>
<span>→ agent 提交 PR</span>



而在這個場景裡，工程師主要負責 review、架構設計、資訊輸入和方向決策，同時 OpenAI 也在過程中提供了對應實驗經驗：

- 複雜技術對 AI 不友好，所以優先選擇：boring technologies、標準庫、明確 API，這些 AI 更好理解的技術方向
- 文件不是給人看的，而是給 agent，前面我們聊過，文件要編寫成「機器可讀的上下文」
- 小任務效果優於大任務，細分任務很重要
- 自動回饋很重要，就像前面提過的，盡可能讓 AI 自行測試、自己回饋，比如在 Flutter 場景，Agent 會自己修改後直接執行 `flutter run`，並透過終端即時取得日誌查看是否有問題

從這些可以看出，目前 AI 產品的競爭力不在模型，而在 harness。好的 harness（比如 Claude Code、Codex）能決定模型的上限，因為 harness 可以決定：

- AI 能存取哪些工具
- AI 能獲得多少上下文
- AI 是否能自我修復

所以，現在你明白了，為什麼 AI Coding 不是簡單的 Prompt Engineering，而應該是一個 Harness Engineering，因為你的專案需要持續迭代，也需要持續修改，AI 是健忘的，你的任務就是讓它可以在需要時輕鬆想到過去，再實現未來。

> 而開發者也正在從設計程式碼的角色，轉向設計 AI 和 Agent 運行環境的角色。

PUA
---

當然，如果前面的對你來說太難，你可以試試用這個 pua-skill.pages.dev 的 PUA Skills 來提升你的 AI 效果。

[https://pua-skill.pages.dev/](https://link.juejin.cn?target=https%3A%2F%2Fpua-skill.pages.dev%2F)

![](https://i.imgur.com/er1C1q2.jpeg)

要知道 AI 最擅長的就是最短路徑實現，說人話就是：AI 很擅長偷懶，而 AI 的每次「磨洋工」，都會給你帶來 Token 的浪費，所以這時 PUA 這個 Skill 就起到了意想不到的作用。

最主要這個 Skill 還透過不同大廠的 PUA 風格，並給出了對應的評分效果，比如：

- 阿里的聞味道 / 揪頭髮 / 照鏡子 方法論驅動，強制 5 步結構化思考，產出可追溯的除錯鏈路，適合複雜多層 bug：「你的方法論沉澱在哪？你的體系化思考能力呢？」
- ByteDance 的坦誠直接上強度，速度優先，直接指出問題，適合明確的單點 bug：「坦誠直接地說，你這個 debug 能力不行，Context, not control」

![](https://i.imgur.com/VD8G0Xx.jpeg)

另外，可以看到在作者提供的數據裡，PUA 對 AI 來說確實可以起到一定作用，特別是在出現錯誤場景時，不得不佩服這位作者的創意：

![](https://i.imgur.com/20ZPxUt.jpeg)

所以，如果你覺得 AI Harness 方法論太麻煩了，也可以體驗這個 Skill。

連結
--

---

原文出處：https://juejin.cn/post/7615455795723976739