Principle 1: keep the shape in your head

An agent can fill in a lot of surface area. It cannot be responsible for the mental model you refuse to hold. Before letting a tool edit, I want to know the boundaries: what module owns this behavior, what data crosses the edge, what must not change, and what would count as a regression.

This is not nostalgia for hand-written code. It is basic control. If you cannot explain the shape, you cannot review the diff. If you cannot review the diff, you are not delegating; you are gambling.

Principle 2: ask for smaller moves

The worst AI-assisted changes are broad, confident, and hard to inspect. A better pattern is to ask for a small move with a clear stop: find the call sites, change this one branch, add one guard, rewrite this copy block, produce a test case but do not touch implementation yet.

Small moves are not slow. They preserve steering. They make it possible to catch a wrong assumption while it is still cheap.

Principle 3: make evidence part of the work

"Looks good" is not an engineering signal. A useful assistant should help produce evidence: a failing case, a before-and-after screenshot, a focused diff, a command output, a trace of why a branch is reachable. The more generation enters the process, the more explicit verification has to become.

• For UI, look at the actual viewport, not just the component tree.
• For logic, test the old failure path, not just the happy path.
• For content, read it as a human, not only as a sitemap entry.

Principle 4: protect taste from throughput

AI makes it easy to produce plausible work. Plausible work is dangerous because it passes the first glance. In code, it creates abstractions nobody asked for. In writing, it creates paragraphs that sound smooth and say nothing. In product, it creates features that mimic the category instead of solving the problem.

My read: taste is now partly a deletion skill. Delete the generic line. Delete the decorative state. Delete the extra setting. Delete the explanation that exists only because the interface is unclear.

Principle 5: stay close to operations

The farther a developer gets from real failures, the easier it is to confuse generation with progress. Logs, incidents, support questions, slow queries, broken deploys, confused users: these are not distractions from building. They are the source of judgment.

The developer I trust in an AI-heavy environment is not the one who prompts the fastest. It is the one who can still tell when the system is lying, drifting, overreaching, or quietly making future maintenance worse.

原則一：腦中要保留形狀

agent 可以補很多表面積，但它不能替你負責你自己不願意掌握的 mental model。在讓工具修改前，我至少想知道邊界：哪個模組擁有這個行為，資料從哪裡跨出去，什麼不能變，什麼算 regression。

這不是懷舊地堅持手寫程式，而是基本控制權。如果你說不出形狀，就 review 不了 diff；如果 review 不了 diff，那不是 delegation，是賭博。

原則二：要求更小的動作

最糟的 AI 輔助修改，通常是範圍很大、語氣很有信心、但很難檢查。比較好的模式是要求一個小動作，而且停點清楚：找 call sites、只改這個 branch、加一個 guard、重寫這段文案、先產生測試案例但不要動 implementation。

小動作不是慢，而是保留方向盤。它讓你能在錯誤假設還很便宜時就抓到。

原則三：把證據變成工作的一部分

「看起來可以」不是工程訊號。有用的助手應該幫你產生證據：一個會失敗的 case、一張前後對照截圖、一個聚焦 diff、一段 command output、一條為什麼這個 branch 會被走到的痕跡。越多生成進入流程，驗證就要越明確。

• UI 要看真 viewport，不只看 component tree。
• 邏輯要測舊的失敗路徑，不只測 happy path。
• 內容要當人來讀，不只是 sitemap 裡的一個 URL。

原則四：用刪除保護品味

AI 很容易產生「看起來合理」的東西，而這正危險，因為它能通過第一眼。在程式裡，它會做出沒人要求的 abstraction；在寫作裡，它會產生順但空的段落；在產品裡，它會模仿一個品類，而不是解決問題。

我的判斷是：品味現在很大一部分是刪除能力。刪掉泛泛而談的句子，刪掉裝飾性 state，刪掉多餘設定，刪掉那些只因為介面不清楚才需要存在的解釋。

原則五：不要離運行現場太遠

工程師離真實失敗越遠，就越容易把生成誤認成進度。log、incident、support 問題、慢查詢、壞掉的 deploy、看不懂的使用者，這些不是打斷建設的雜事，而是判斷力的來源。

在 AI 很重的環境裡，我信任的不是 prompt 最快的人，而是仍然看得出系統什麼時候在騙人、漂移、越界，或悄悄讓未來維護變糟的人。