智能體寫代碼就是香
有那么一個夜晚，我差點關掉編輯器，開始懷疑自己是否還屬于這個行業。
我做了所有“正確”的事。 多年經驗。整潔的提交。扎實的評審。
然而我眼看著更年輕的開發者交付功能的速度快出一倍，僅僅因為他們自帶一種 AI-first 的工作方式，而我還在把 AI 當成更聰明的搜索框。
他們在和 Agents 結對。 我在復制—粘貼答案。
那一刻，我決定不再假裝這只是個小趨勢，而是重塑自己的工作方式。
這篇文章講的是，我如何把 AI 從一個吵鬧的聊天窗口變成一支“小型代理小隊”，在不破壞代碼質量、也不損害作為工程師的自信的前提下，實際替代了我大約一半的編碼時間。
替代一半“編碼時間”到底意味著什么
先把話說清楚。
我仍然做系統設計。 我仍然做權衡。 我仍然在 pull request 上簽下自己的名字。
改變的是我的時間花在哪里。
在使用 Agents 之前，一個普通的后端（backend）特性開發通常是這樣的：
- 長時間閱讀舊代碼和注釋。
- 搜索某個行為究竟藏在哪里。
- 寫出第一個“丑陋”的實現。
- 逐步清理。
- 補上測試和日志。
- 修復那些我最初忘掉的情形。
當我終于不再憑感覺、而是實際記錄了一周時間后，我意識到一個不舒服的事實：
我的“大量編碼時間”并不在思考。 而是在搬運信息，小心翼翼、緩慢移動。
這部分，才是我決定要外包出去的。
現在，一天忙下來我依然會累。 但這種累來自“設計決策與取舍”，而不是在膠水活里泡上好幾個小時。
我如何把 AI 變成一支 Agents 小隊
如果你是負責人，你不會把一個完整項目丟給新同事然后消失。 你會把工作拆成角色。
我對 AI 做了同樣的事。
與其“一個萬能助理包打天下”，我把協作拆成四個清晰的角色，我稱之為 SCCR（Spec / Context / Code / Review）：
- Spec Agent（規格/需求代理） 這個代理像一個苛刻的產品經理。 它的工作是把我含糊的想法逼問成清晰的行為描述。
- Context Agent（上下文代理） 這個代理是 codebase 向導。 它會搜索文件、讀注釋，并指出對這個特性真正重要的部分。
- Code Agent（代碼代理） 這個代理像一個積極的初級工程師。 在我定義好的邊界內，為小而明確的變更寫出第一版草稿。
- Review Agent（評審代理） 這個代理像一個謹慎的同級評審者。 它會建議測試、高亮風險點，并指出令人困惑的命名。
這里沒有任何一步替代我的責任。 這只意味著，我不再親自完成每一個重復動作。
我變成了那個“分派、決策、糾錯”的人。
它第一次把我從麻煩里救出來
這個方案的第一次真正考驗，是一個可能悄悄“動到錢”的改動。
我們需要調整一個多年積累、愈發混亂的服務里，失敗支付的 retry 行為。
過去，這類任務能把我榨干一整天：
- 三個不同模塊里長時間的代碼閱讀。
- 追蹤 retry、日志和用戶消息到底由誰驅動。
- 一邊寫新邏輯，一邊祈禱別弄壞什么。
- 第一次評審之后再補測試與日志。
這種工作，打開第一個文件肩膀就會立刻沉下去。
這一次，我決定相信 SCCR。
先上場的是 Spec Agent。
我把自己對改動的粗略想法寫出來，并讓它把我當成一個討厭空話的產品經理來“盤問”。它的問題多少有點刺痛：
- 到底什么算永久失敗、什么算臨時失敗？
- 最多允許嘗試多少次才放棄？
- 每次嘗試后用戶應該看到什么？
- 之后我們要如何向支持和財務團隊解釋這個行為？
回答這些問題迫使我直面那些我通常會“寫著寫著再想”的細節。
等我答完，腦子里的特性已經更扎實了。
接著是 Context Agent。
我把與 payments、retries、notifications 相關的模塊指給它。 它返回了這些東西：
- 實際觸發支付嘗試的主方法。
- 一個被加上去后就被遺忘的歷史 workaround。
- 寫著“不要改動這些調用的順序”的注釋。
讀完這份總結，感覺就像有個隊友帶我繞著 codebase 轉了一圈，把所有重要內幕都悄悄告訴了我。
這才把 Code Agent 請進來。
我沒有讓它重寫服務。 我讓它修改一個具體函數：
- 加上 backoff 支持。
- 遵循最大嘗試次數的配置。
- 保持對外簽名不變。
它給出的第一稿不完美，但已經非常接近我會寫的樣子，而且更快。
最后由 Review Agent 過目。
我把修改后的函數和更新的規格交給它，并讓它幫我以“偏執評審者”的視角來思考。 它指出了：
- 外部網關返回奇怪狀態碼時的失敗模式。
- 配置可能被錯誤設置的情形。
- 日志不足以在將來定位問題的情況。
我還是自己過了一遍每一行。 我還是跑了測試、加了日志，并和另一個同事討論了這次改動。
但過程變了。
我不再是一個人和 codebase 硬碰硬，而像是在協調一支小而專注的團隊在背后托著我。
過去能吞掉一天的活，現在只需要幾個小時的高強度投入，且最終結果更“安全”，而不是更冒險。
讓這些 Agents 真有用的 Prompts
很多人會問，實際起作用的 prompt 到底長什么樣。
下面是我每天在用的范式。
Spec Agent：把粗想法錘成清晰行為
我先把腦子里的東西寫下來，然后讓代理對我“嚴格”一點：
“我是一個后端工程師，正在為 [system] 開發一個特性。 以下是我當前的描述。 你的角色是一個苛刻的產品經理。
- 指出任何含糊之處。
- 列出缺失的重要邊界情況（edge cases）。
- 提出直接的問題，直到這個描述變得可測試。
描述： [我的粗略筆記]”
這里的“魔法”不在于具體措辭。 而在于給代理“和我爭論”的權限，而不是讓它點頭附和。
Context Agent：替我走一遍 codebase
當規格落地后，我給代理一組文件，并讓它“畫地圖”：
“你是我在這個 codebase 里的向導。 我想修改 [behavior]。
從這些文件中： [文件與文件夾列表]
用簡單語言解釋：
- 這個行為目前從哪里來，
- 如果改動它，可能會弄壞什么，
- 任何我應該留意的警告性注釋。”
很多令人難堪的“驚喜”，往往會在這個時刻先暴露，而不是在生產上爆炸。
Code Agent：在“圍欄”內起草改動
輪到動代碼時，我把“圍欄”說得非常清楚：
“你是一名謹慎的高級工程師。 只修改我提供的函數。 不要引入新的依賴或模式。
目標：[小而具體的行為變更]
- 給出更新后的函數。
- 用簡單語言解釋變化。
- 建議我應該補充的若干測試。
當前函數： [粘貼代碼]”
如果答案讓人困惑，我就再問。 如果答案不對，我就丟棄。
重點不是服從 Agent。 重點是把它當作一個能在幾秒內響應的快速協作者。
我一周下來的真實基準
我對“隔夜提速十倍”這種說法保持懷疑。
所以我悄悄記錄了自己在一周內用 SCCR 風格協作時的時間開銷。
現實大概是這樣：
| Work Type |Old Hands-OnTime|New Hands-OnTime|
|---------------------------------- | ----------------- | ----------------- |
| Mid-Sized Feature Change |~7 hours |~3 hours |
| Bug Fix That Needed Investigation |~3 hours |~1.5 hours |
| Increasing Test Coverage |~5 hours |~2 hours |
| Cleaning Up Logs And Observability |~4 hours |~1.5 hours |這些數字不是實驗室里的對照實驗。 而是來自一個有會議、有干擾、有真實截止期的普通工作周。
也有一些任務里，Agents 并不太管用：
- 全新設計、連問題本身都尚未明確的時候。
- 由基礎設施不穩定或罕見競爭條件導致的問題。
但在日常后端工作里，規律是反復出現的：
我在鍵盤上的“手指時間”變少了。 我的“思考時間”保住了，甚至更鋒利了。
我這套 Agent 方案背后的架構
外面看起來這可能像個巨大而復雜的系統。 其實不是。
我想要的是足夠簡單到我每天都會真的用它。
大致工作示意是這樣的：
+-------------------------------+
| Developer |
| (Me) |
+--------------+----------------+
|
v
+-------------------------------+
| SCCR Orchestrator |
| (routes tasks toeach agent) |
+-----+-----------+------------+
| |
v v
+-----------+ +-----------+
| Spec || Context |
| Agent || Agent |
+-----------+ +-----------+
| |
v v
+-----------+ +-----------+
| Code || Review |
| Agent || Agent |
+-----------+ +-----------+
|
v
+-------------------+
| CI / Test Run |
+-------------------+“orchestrator”只是一個很樸素的腳本，做幾件事：
- 接收一個目標（goal）和一個角色（role）。
- 構造解釋該角色的 system message。
- 注入來自 repo、文檔或日志的相關上下文。
- 把請求發給 language model（LLM）。
- 返回一個建議的 diff 或摘要。
用 TypeScript 風格的偽代碼，大致像這樣：
type AgentRole = "spec" | "context" | "code" | "review";
interfaceAgentTask {
role: AgentRole;
goal: string;
context: string;
}
asyncfunctionrunAgent(task: AgentTask): Promise<string> {
const system = `You are my ${task.role} agent.
You help me ship safe production code.`;
const prompt = `${system}\n\nGoal:\n${task.goal}\n\nContext:\n${task.context}`;
const result = await llm.complete({ prompt });
return result.text;
}你可以用任何你熟悉的語言實現它。 結構遠比語法重要得多。
我與 AI 的“邊界線”畫在哪里
有些領域我讓 Agents 大膽幫忙。 也有些地方，我讓它們穩穩坐在副駕。
我不會外包的是：
- 會影響未來幾年 codebase 的最終系統設計決策。
- 與認證、加密或權限檢查相關的安全敏感邏輯。
- 任何帶有法律或合規風險的內容。
- 構建與團隊或利益相關者信任的那類對話。
Agents 可以提想法、指出擔憂、給出文檔線索。 但承擔這些決策責任的，不是它們。
把這條邊界畫清楚帶來了一個意外的副作用： 我對 AI 的威脅感更小了，對它的支持感更強了。
如何在不打亂現有工作流的前提下嘗試
如果整套 SCCR 看上去太大，那就小步開始。
挑出你日常工作里最“耗人”的一塊。 對很多人來說，那是讀遺留代碼或寫重復性的測試。
只為這個痛點創建一個 Agent：
- 清晰解釋它的角色。
- 給它正確的上下文。
- 讓它挑戰并輔助你，而不是接管你。
持續用上一周。 觀察它在哪里幫你省力，在哪里讓你煩躁。
只有當這一切變得自然，再加第二個角色。
以這種緩慢、謹慎的方式成長系統，你就不會把工作流變成一個會在復雜性下自我坍塌的實驗。
你怎么看
2025 年真正可怕的地方，不在于 AI 會寫代碼。
可怕的是，兩位經驗幾乎一致的開發者，如今會在完全不同的層級上運作——僅僅因為其中一位學會了如何與 Agents 協作，而另一位還停留在復制—粘貼的時代。
紙面上，他們看起來一樣。 實際中，一位總是被工作淹沒，另一位則有足夠的喘息空間去思考。
你已經知道自己想成為哪一個人。
如果這段經歷有任何一部分引起你的共鳴，我很愿意聽聽你的想法……
本文轉載自????PyTorch研習社????，作者：AI研究生
