Chris Parsons 已更新他關於使用 AI 撰寫程式碼的指南。這是他的第三次更新，我喜歡這篇文章的地方在於，他提供了許多關於自己如何使用 AI 的具體資訊，細節充分，讓我們能從中學習。他的建議也與我所見過更好的建議相呼應，因此這篇文章對 AI 用於軟體開發的現況，提供了很好的概述。

I wrote the previous version of this post in March 2025, updated it once in August, and it has been linked from almost everything I have written about AI engineering since. The fundamentals from that post still hold: keep changes small, build guardrails, document ruthlessly, and make sure every change gets verified before it ships. One thing has had to move with the volume. “Verified” used to mean “read by you”. With modern agent throughput, it has to mean “checked by tests, by type checkers, by automated gates, or by you where your judgement matters”. The check still happens; it just does not always happen in your head.

和 Simon Willison 一樣，他清楚區分了「氛圍編碼」（vibe coding）——也就是你不看也不在意程式碼——與「代理式工程」（agentic engineering）。他推薦使用 Claude Code 或 Codex CLI。他認為自己偏好工具所提供的內部 harness，是其優勢的關鍵部分。

他認為驗證是需要聚焦的重點：

A team that can generate five approaches and verify all five in an afternoon will outpace a team that generates one and waits a week for feedback. The game is not “how fast can we build” any more. It is “how fast can we tell whether this is right”. That shifts where to invest. Build better review surfaces, not better prompts. Make feedback unnecessary where you can by having the agent verify against a realistic environment before it asks a human, and make feedback instant where you cannot.

程式設計師的關鍵角色在於訓練 AI 撰寫軟體，而熟練的代理式程式設計師最重要的工作，就是將這項技能傳授給其他開發者。

And if you are a senior engineer worried that your job is quietly turning into approving diffs: it is. The way out is to train the AI so the diffs are right the first time, to make yourself the person on the team who shapes the harness, and to make that work the visible thing you are measured on. That role compounds in a way that reviewing never will.

 ❄                ❄                ❄                ❄                ❄

本月初，Birgitta Böckeler 撰寫了一篇出色的關於 Harness Engineering 的文章。（這不僅是我的看法，從它吸引到的驚人流量就能看出。）Birgitta 現在錄製了一段影片與 Chris Ford 討論 Harness Engineering，非常值得一看。

影片中他們聚焦討論 harness 中計算感測器（computational sensors）的角色，例如靜態分析與測試。

LLMs are great for exploratory and fuzzy rules, but once you have something that really is objective, converting it to a formal, unambiguous, deterministic format can give you more assurance

Birgitta 進行了一些實驗來探討加入感測器的效益，包括深入探討使用靜態分析。她發現這更有用，因為代理可以真正處理每一個警告，而不像人類那樣偷懶。

 ❄                ❄                ❄                ❄                ❄

Adam Tornhill 探討了一個老問題：函式應該有多長？這個問題在代理式程式設計的時代依然相關。

AI models do not “understand” code the way humans do. They infer meaning from patterns in tokens and depend heavily on what is explicitly expressed in the code.

Research shows that naming plays a critical role. When meaningful identifiers are replaced with arbitrary names, model performance drops significantly. Current models rely heavily on literal features—names, structure, and local context—rather than inferred semantics.

和他一樣，他認為答案不是去思考函式應該有多少行，而是提供更好的結構。他舉了一個很好的例子，說明一個選擇得當的函式如何定義有用的概念——一個函式包裝四行程式碼，回傳一個新概念，進入程式的詞彙。

Functions are the first unit of structure in a codebase. They define how logic is grouped, how intent is communicated, and how change is localized. If the function boundaries are wrong, everything built on top of them becomes harder to understand and harder to evolve.

這與我所寫的關於函式長度的關鍵在於意圖與實作之間的區隔相符：

If you have to spend effort into looking at a fragment of code to figure out what it’s doing, then you should extract it into a function and name the function after that “what”. That way when you read it again, the purpose of the function leaps right out at you, and most of the time you won’t need to care about how the function fulfills its purpose - which is the body of the function.

 ❄                ❄                ❄                ❄                ❄

我追蹤的許多人推薦 Nilay Patel 關於為什麼人們討厭 AI的文章。他認為軟體圈的許多人都有「軟體大腦」（software brain）：

The simplest definition I’ve come up with is that it’s when you see the whole world as a series of databases that can be controlled with the structured language of software code. Like I said, this is a powerful way of seeing things. So much of our lives run through databases, and a bunch of important companies have been built around maintaining those databases and providing access to them.

Zillow is a database of houses. Uber is a database of cars and riders. YouTube is a database of videos. The Verge’s website is a database of stories. You can go on and on and on. Once you start seeing the world as a bunch of databases, it’s a small jump to feeling like you can control everything if you can just control the data.

軟體大腦將人視為資料庫，而奇怪的是，很多人不喜歡這樣。這就是為什麼許多民調顯示人們對 AI 運動抱持負面感受。

Even taking the time to consider how much of your life is captured in databases makes people unhappy. No one wants to be surveilled constantly, and especially not in a way that makes tech companies even more powerful. But getting everything in a database so software can see it is a preoccupation of the AI industry. It’s why all the meeting systems have AI note takers in them now.

Patel 提出了我常做的類比——程式設計師與律師之間的相似性。律師起草合約是在為合約各方應如何行為建立協議。如 Patel 所說：

If the heart of software brain is the idea that thinking in the structured language of code can make things happen in the real world, well, the heart of lawyer brain is that thinking in the structured legal language of statutes and citations can also make things happen. Hell, it can give you power over society.

當然，差別在於法律是非確定性的。訴訟是解決當人們對合約應如何執行有不同看法時的問題。

 ❄                ❄                ❄                ❄                ❄

我最近與一家公司聊天，他們想使用 AI 來理解內部資料。潛力很大，但問題在於資料一團亂。人們把東西填到不合理的欄位，對重要實體的分類也缺乏一致性。正如有人評論：

the hardest problem with internal data is precise, consistent definitions

你可以想像我有多驚訝。（也就是說，一點也不驚訝——這是我數十年來使用電腦的常見主題。）取得這類定義的困難，削弱了軟體大腦的許多希望。

這與我們和 LLM 在程式設計上的關係產生共鳴。精確且一致的定義，對與 The Genie 有效溝通至關重要。這些定義需要在對話中成長，並隨著時間被維護。概念建模將是代理式程式設計及後續發展的關鍵技能。（至少我希望如此，因為這是我真正喜歡的程式設計部分。）

 ❄                ❄                ❄                ❄                ❄

Patel 的文章提到了 Ezra Klein 關於舊金山的新感覺的文章。

You might think that A.I. types in Silicon Valley, flush with cash, are on top of the world right now. I found them notably insecure. They think the A.I. age has arrived and its winners and losers will be determined, in part, by speed of adoption. The argument is simple enough: The advantages of working atop an army of A.I. assistants and coders will compound over time, and to begin that process now is to launch yourself far ahead of your competition later. And so they are racing one another to fully integrate A.I. into their lives and into their companies. But that doesn’t just mean using A.I. It means making themselves legible to the A.I.

這種可讀性正是 Patel 觀察的核心。這就是為什麼我看到許多同事把所有電子郵件、會議記錄、簡報等一切都傾倒到 AI 可以讀取和處理的檔案中。這符合 AI 的強項，我們知道 AI 非常擅長查詢非結構化資訊。因此我可以找出埋在筆記中的內容，這比希望自己輸入正確的搜尋 regex 有效得多。

我最近經常用 Gemini 做這件事，因為對它提出問題比向 Google 輸入搜尋詞更容易。Gemini 會保留我過去的請求記錄，並用來幫助調整我正在尋找的內容。正如 Klein 所觀察：

[The AI] is constantly referring back to other things it knows, or thinks it knows, about me. Sycophancy, in my experience, has given way to an occasionally unsettling attentiveness; a constant drawing of connections between my current concerns and my past queries, like a therapist desperate to prove he’s been paying close attention.

The result is a strange amalgam of feeling seen and feeling caricatured.

和我一樣，Klein 是一位作家，面臨著我思考 AI 與寫作時所面對的同樣誘惑。也許我應該請 LLM 建立一個 AGENTS.md 檔案來總結我的寫作風格，而不是辛苦撰寫文章，然後每隔幾天請它就某個主題撰寫一篇文章，閱讀、調整，然後發表我博學的見解。但這對我一點吸引力也沒有。我希望理解在我自己的大腦中成長，而不是在 LLM 短暫的會話中。寫作是為了向他人解釋我的想法，這也是我如何精煉思考的方式，「將想法雕琢成可發表的內容」，正如 Klein 所說。讓 AI 為我寫作，等於是殘害我自己的心智。