一、開發痛點：為什麼我們需要AI編程輔助？

核心發現： AI編程工具正在重塑開發流程，但真正的價值不在於替代開發者，而在於構建人機協作的新型開發範式。Claude Code通過精準對話流設計、模塊化任務分解和專業化子代理協作，在提升開發效率的同時，也面臨着上下文管理、協作邊界和質量控制等實際挑戰。

作為一線開發者，我們每天都在與複雜的業務邏輯和不斷迭代的技術棧打交道。不知道你是否也遇到過這些場景：剛理清一個複雜業務流程，被打斷後又得重新梳理思路；接手一個老項目，花了半天還沒搞懂其中某個模塊的設計思路；或者在不同項目間切換時，總要重新適應不同的編碼規範和架構風格。

日常開發的三個"攔路虎"：

• 上下文切換成本高： 需求理解→技術選型→代碼實現→質量驗證的切換過程中，每次都要重新構建認知框架。
• 知識傳遞效率低： 項目規範、架構經驗分散在文檔和個人經驗中，新成員上手或跨模塊開發時處處碰壁。
• 開發流程割裂： 需求→設計→編碼→審查各環節串行傳遞，信息易失真且反饋滯後。

這些問題不是簡單的"加人"或"加班"能解決的。我們需要的是一種新的開發範式，而Claude Code這類AI編程工具正是在這樣的背景下進入了我們的視野。它的價值不在於替我們寫代碼，而在於成為我們的"認知放大器"和"流程協作者"。

二、Claude Code核心功能解析：從工具到方法論

Claude Code構建了一套完整的AI輔助開發方法論。接下來將結合團隊實際使用經驗，從功能特性、使用場景和設計初衷三個維度，詳細介紹其核心功能：

精準對話流設計：控制AI思考的藝術

第一次用Claude Code時，就像面對一個熱情但經驗不足的實習生------如果不明確告訴他要做什麼、怎麼做、有什麼要求，他很可能會給你一個"驚喜"。對話流設計就是解決這個問題的關鍵。

設計初衷： 對話流設計的本質是將人類的編程思維模式轉化為AI可理解的結構化交互方式，通過明確的上下文管理和約束條件設置，引導AI生成符合預期的代碼結果。

核心功能

對話流設計通過三個關鍵機制控制AI的思考過程：

• 上下文聚焦： 要求單次對話僅處理一個功能模塊，避免多任務混合導致的AI注意力分散。我們曾經試過在一個對話裏同時讓AI處理多個模塊，結果它把兩個模塊的錯誤處理邏輯混在了一起。
• 約束明確化： 通過具體指令減少AI的自由度，比如"僅修改X包下文件"、"必須複用Y工具類"。這些約束要儘可能具體，比如不説"遵循項目規範"，而是説"使用ResultDTO作為統一返回格式，錯誤碼規則參考ErrorCodeEnum"。
• 增量式提問： 採用"先框架後細節"的提問策略，先讓AI生成接口定義和整體框架，待確認後再逐步深入實現細節。這種方式很像我們帶新人時"先搭骨架再填肉"的指導方法。

使用心法

啓動新功能開發時，我們會創建專用對話線程，並在初始prompt中明確四件事：

1. 當前任務的功能邊界和目標（做什麼，不做什麼。）
2. 必須遵守的技術約束和規範（用什麼技術棧，遵循什麼標準。）
3. 期望的輸出格式和交付物（要代碼？要文檔？還是兩者都要？）
4. 分階段的實現計劃（先設計接口，再實現邏輯，最後寫測試。）

真實踩坑經驗

處理跨模塊依賴時，我們發現AI很容易"忘記"之前設定的約束。後來我們總結出一個技巧：每開始一個新的實現階段，就簡要回顧一下關鍵約束。比如："現在我們要處理任務交接流程，請記得：1. 使用Redis分佈式鎖；2. 需要修改商運關係和新商成長任務；3. 異常處理要符合規範。"

Plan模式：複雜任務的系統化分解

面對"實現一個完整的拜訪任務系統"這樣的複雜需求，直接讓AI生成代碼就像讓一個剛入行的開發者獨立負責整個項目------結果往往是邏輯混亂、漏洞百出。Plan模式就是解決這個問題的"項目管理工具"。

現狀與問題：我們早期使用Claude Code時，經常犯一個錯誤：把一個複雜需求一股腦丟給AI，然後期待它給出完美解決方案。結果通常是：

• 實現邏輯不完整，有些邊界情況根本沒考慮到。
• 模塊間接口設計不一致，調用起來磕磕絆絆。
• 技術選型不合理，用了個"看起來很酷但項目中並不適用"的方案。

這其實不能怪AI，人在面對過於複雜的問題時也會手足無措。我們需要一種方法把大問題拆分成小問題，而Plan模式正是借鑑了項目管理中的WBS（工作分解結構）思想。

我們的解決方案：Plan模式使用三步法分解需求：

1. 需求分析與模塊劃分：把整體需求分解為獨立的功能模塊。
2. 技術方案設計：為每個模塊確定實現思路和技術選型。
3. 任務優先級排序：根據依賴關係和重要性確定實現順序。

實際操作示例：拜訪任務需求

拜訪任務是一個簡單的企業內部任務需求，在實現"拜訪任務需求"時，我們通過Plan模式生成的任務清單是這樣的：

---
拜訪任務線上化 - 模塊清單
M1: 任務創建模塊
- 功能: 創建拜訪任務,包含基本信息、拜訪對象、參與人員
- 複雜度: Medium (需要處理多表關聯和事務)
M2: 任務審批模塊
- 功能: 飛書審批流程集成,支持任務提交、審批、駁回
- 複雜度: High (涉及飛書審批接口集成和狀態流轉)
M3: 日程同步模塊
- 功能: 將拜訪任務同步到飛書日曆
- 複雜度: Medium (飛書API調用和異常處理)
M4: 任務列表查詢模塊
- 功能: 分頁查詢任務列表,支持多維度篩選
- 複雜度: Medium (ES聚合查詢和數據轉換)
M5: 任務詳情查詢模塊
- 功能: 查詢任務詳情,包括拜訪對象、參與人員、商家信息
- 複雜度: Low (簡單的關聯查詢)
M6: 任務統計模塊
- 功能: 統計不同類型、不同狀態的任務數量
- 複雜度: Low (聚合統計)
M7: 拜訪結果提交模塊
- 功能: 提交拜訪記錄,上傳附件,記錄拜訪內容
- 複雜度: Medium (文件上傳和多表操作)
M8: 任務分配模塊
- 功能: 批量分配任務給運營人員
- 複雜度: High (涉及分配策略和定時任務)
M9: 任務觸達模塊
- 功能: 任務開始、結束、上傳提醒通知
- 複雜度: Medium (飛書消息卡片模板)
M10: ES數據同步模塊
- 功能: 將任務數據同步到ES,支持全文檢索
- 複雜度: Medium (事件驅動和ES批量操作)
M11: 任務導入模塊
- 功能: Excel批量導入拜訪任務
- 複雜度: High (Excel解析、數據校驗、批量插入)
M12: 任務狀態變更模塊
- 功能: 定時更新任務狀態(未開始→進行中→已結束)
- 複雜度: Low (定時任務和批量更新)
---
第二步:技術方案設計
| 模塊       | 數據存儲               | 查詢方案         | 外部集成          |
|------------|------------------------|------------------|-------------------|
| M1-任務創建  | MySQL (事務)           | -                | -                 |
| M2-任務審批  | MySQL + 審批記錄表      | -                | 飛書審批API       |
| M3-日程同步  | -                      | -                | 飛書日曆API       |
| M4-任務列表  | ES (主) + MySQL (輔)   | ES聚合查詢       | -                 |
| M5-任務詳情  | MySQL                  | 聯表查詢         | 商家信息API |
| M6-任務統計  | ES                     | ES聚合統計       | -                 |
| M7-結果提交  | MySQL + OSS            | -                | OSS文件上傳       |
| M8-任務分配  | MySQL                  | 分配算法         | -                 |
| M9-任務觸達  | -                      | -                | 飛書消息卡片      |
| M10-ES同步  | ES                     | Spring Event     | -                 |
| M11-任務導入 | MySQL                  | Excel 解析    | -                 |
| M12-狀態變更 | MySQL                  | JOB定時任務  | -                 |
---
第三步:任務優先級排序
P0 核心流程(必須先實現)
1. M1-任務創建 (基礎功能)
2. M5-任務詳情 (數據展示)
3. M4-任務列表 (核心查詢)
4. M7-結果提交 (閉環流程)
P1 審批與通知(核心功能增強)
5. M2-任務審批 (依賴M1)
6. M3-日程同步 (依賴M2審批通過)
7. M9-任務觸達 (依賴M1、M7)
P2 運營功能(效率提升)
8. M8-任務分配 (依賴M1)
9. M11-任務導入 (依賴M1)
10. M6-任務統計 (依賴M4)
P3 技術優化(性能優化)
11. M10-ES同步 (依賴M1、M4)
12. M12-狀態變更 (獨立模塊)
---
實現建議
階段一:基礎能力
- 先實現 M1、M5、M4,打通任務創建→查詢→詳情的基本鏈路
- 使用 MySQL 實現,暫不接入 ES
階段二:審批流程
- 實現 M2、M3,接入飛書審批和日曆
- 完成任務的完整生命週期管理
階段三:結果閉環
- 實現 M7,完成拜訪結果提交
- 實現 M9,添加任務觸達通知
階段四:運營優化
- 實現 M8、M11、M6
- 提升運營效率
階段五:性能優化(按需)
- 實現 M10,將查詢遷移到 ES
- 實現 M12,優化任務狀態管理

這種方式不僅讓AI能夠有序工作，也讓我們對整個開發進度有了更清晰的把控。

系統提示詞：給AI立"規矩"的藝術

如果把Claude Code比作一個新加入團隊的開發人員，系統提示詞（CLAUDE.md）就相當於給他的"入職手冊"，告訴他團隊的編碼規範、工作流程和注意事項。

新手常犯的錯誤： 把系統提示詞寫成"百科全書"，恨不得把所有項目知識都塞進去。結果AI要麼忽略大部分內容，要麼在生成代碼時顧此失彼。我們早期的系統提示詞長達5000字，包含了從架構設計到代碼規範的所有內容，效果反而不好。

實踐心得：有效的系統提示詞應該像"護欄"而非"詳盡手冊"。我們發現，針對AI常見錯誤模式設計的針對性提示，遠比全面但泛泛的規範更有效。現在我們的系統提示詞控制在200字以內，只包含最關鍵的約束和指引。

系統提示詞模板

經過多次迭代，我們總結出包含三個關鍵模塊的系統提示詞結構：

使用技巧

分享幾個在實踐中總結的系統提示詞編寫技巧：

• 避免信息過載： 不要試圖包含所有知識，而是指引AI在需要時查詢特定文檔。例如："遇到分佈式事務問題時，請參考/doc/分佈式事務最佳實踐.md文檔中的TCC模式實現方案"。
• 提供正向引導： 不僅説"不要做什麼"，更要明確"應該怎麼做"。例如，不説"不要使用過時的API"，而説"請使用OrderServiceV2替代OrderServiceV1。
• 動態調整策略： 我們每兩週會回顧一次系統提示詞的有效性，根據AI最近常犯的錯誤補充新的約束。比如發現AI經常忘記處理空指針，就新增一條："所有方法入參必須進行非空校驗，使用ValidateUtil.isEmpty()方法，異常時拋出IllegalArgumentException"。

SKILL與MCP：知識沉澱與外部能力擴展

在團隊協作中，我們經常説"不要重複造輪子"。同樣，在使用Claude Code時，我們也需要一種機制來沉澱和複用那些有效的Prompt和解決方案------這就是SKILL和MCP機制的價值所在。

SKILL機制： 把好經驗變成"可複用組件"

SKILL本質上是將單次生效的Prompt指令沉澱為可反覆調用的標準化複用資產。舉個例子，我們團隊處理"ES數據查詢"邏輯時，總結出了一個內部版本的SDK。我們把這個SDK的調用方式封裝成一個SKILL，以後遇到類似場景，只需調用這個SKILL，AI就能按照我們團隊的最佳實踐來實現。

MCP協議： 讓AI能"調用"外部工具

MCP（模型上下文協議）解決了AI與外部工具、數據源的連接問題。通過MCP，AI不再侷限於靜態知識，而是能夠動態訪問實時數據。我們集成了飛書MCP服務器，讓AI能夠直接操作飛書平台，如自動生成技術方案文檔、讀取PRD需求、同步數據到多維表格等。

最適合封裝為SKILL的場景

1.複雜工具使用指南： 如"ElasticSearch接入"、"Redis緩存更新策略"等需要特定知識的場景。

2.常見錯誤處理模板： 如"分佈式鎖衝突處理"、"數據庫樂觀鎖重試機制"等反覆出現的問題解決方案。

MCP協議的典型應用場景

• 場景1: 自動生成技術方案文檔

• AI分析需求後，通過飛書MCP調用feishu_create_doc；

• 直接在指定的知識庫目錄創建格式化的技術方案文檔；

• 省去手動複製粘貼的繁瑣步驟。

• 場景2: 讀取PRD需求

• 用户提供飛書文檔鏈接；

• AI通過feishu_get_doc_content獲取文檔內容；

• 基於完整需求信息生成技術方案和實現計劃。

• 場景3: 數據同步到多維表格

• 代碼生成後的統計數據(如代碼行數、涉及文件等)；

• 通過feishu_append_bitable_data自動追加到飛書多維表格；

• 便於團隊追蹤AI編程效率指標。

三、對話流設計方法論：讓AI"懂"你的真實需求

剛接觸Claude Code時，我們採用的是簡單直接的"需求-響應"模式：開發者描述需求，AI生成代碼，開發者修改調整。這種模式在處理簡單功能時還行，但遇到複雜場景就會出問題。

現狀分析：傳統對話模式的侷限性

我們早期在項目中踩過的三個坑：

三大典型問題：

• 需求表達不完整：

開發者説"實現一個商家信息查詢接口"，AI生成了基礎的CRUD代碼，但沒有考慮商家數據權限、數據脱敏、緩存策略等實際業務需求 ；

實現任務時，只描述了"需要任務分配功能"，結果AI生成的代碼沒有處理任務池、任務優先級、分配策略等核心邏輯。

• 上下文管理混亂：

一個對話持續了十幾輪後，AI開始忘記我們前面確定的"使用MyBatis-Plus + BaseMapper"的設計決策，擅自改成了JPA Repository模式；

在實現相關功能時，早期確定的DTO轉換規範在後續模塊中被遺忘，導致代碼風格不一致。

• 迭代反饋滯後：

等AI生成完整的Service + Controller + Repository代碼後才發現方向不對，比如數據庫表設計與現有架構衝突，不得不從頭再來，浪費了大量時間；

實現觸達功能時，生成的飛書消息發送代碼沒有考慮現有的FeishuClient封裝，重複造了輪子。

核心問題：為什麼AI總是"聽不懂"？

深入分析後，我們發現傳統對話模式失敗的根源在於三個核心矛盾：

語義鴻溝

自然語言描述的模糊性與代碼邏輯的精確性之間的差距。我們説"這個接口要安全"，AI可能理解為"需要登錄校驗"，而我們實際想要的是：

• 使用項目中的@Permission註解進行權限校驗。
• 參數需要使用ValidatorUtil進行校驗。
• 敏感操作需要記錄操作日誌。

約束衰減

隨着對話推進，早期設定的技術約束在AI理解中的權重逐漸降低。就像我們記筆記時，重要的事情要反覆強調。比如：

• 第1輪對話強調"必須繼承BaseServiceImpl"。
• 第5輪對話AI可能忘記這個約束，直接實現了一個獨立的Service類。
• 第10輪對話可能連項目的分層架構都混淆了。

目標偏移

在多輪對話中，AI容易過度關注當前細節而忽視整體目標。比如討論某個接口的參數設計時：

• AI可能會糾結於參數名稱是否優雅。
• 而忽略了這個接口的核心業務價值是"快速檢索符合條件的商家"。
• 結果生成的代碼參數命名很完美，但缺少了分頁、排序等實際必需的功能。

解決方案：結構化對話設計方法

針對這些問題，我們團隊總結出一套"三階段對話模型"，現在已經成為我們使用Claude Code的標準流程：

階段一：需求定義------把"要做什麼"説清楚

這個階段的目標是確保我們和AI對需求達成共識。我們會用"用户故事+驗收標準"的格式來描述需求：

示例1：新商户成長任務分配

【用户故事】
作為新商户運營，我需要一個任務分配功能，以便將成長任務高效分配給運營人員
【驗收標準】
 - 支持從任務池中按優先級(P0/P1/P2)篩選待分配任務
 - 支持指定運營人員進行任務分配，需校驗運營人員是否有權限
 - 分配時需檢查運營人員當前任務負載，超過上限時提示"當前任務數已達上限"
 - 分配成功後需發送飛書消息通知運營人員，消息內容包含任務詳情和截止時間
 - 操作需記錄到表，包含操作人、操作時間、任務ID、分配對象

示例2：商家數據權限查詢

【用户故事】
作為商家運營，我需要一個商家信息查詢接口，查詢結果需要根據我的數據權限進行過濾
【驗收標準】
 - 支持按商家ID、商家名稱、商家狀態進行查詢
 - 支持分頁查詢，默認每頁20條，最大100條
 - 查詢結果需要根據當前用户的數據範圍進行過濾
 - 商家敏感信息(手機號、身份證號)需脱敏處理
 - 接口需要權限校驗，至少具有"商家查看"權限
 - 查詢條件需記錄到操作日誌，便於審計

階段二：邊界明確------確定"怎麼做"的約束條件

在這個階段，我們會明確技術棧選擇、架構設計和各種約束條件。關鍵是要區分"必須遵守"和"建議參考"的約束：

示例1：新商户成長任務模塊

【技術約束】
必須遵守:
 - 使用SpringBoot標準分層架構,所有Service繼承OcsBaseServiceImpl
 - 數據庫操作使用MyBatis-Plus,實體類繼承BaseEntity,Mapper繼承BaseMapper
 - 接口返回統一使用Result<T>格式,錯誤碼使用ErrorCode
 - 權限校驗使用@Permission註解,參數校驗使用@Valid + ValidatorUtil
 - 飛書消息發送必須使用FeishuClient,不要重複實現
建議參考:
 - 任務狀態流轉參考TaskServiceImpl中的狀態機模式
 - 批量分配操作參考AssignImportHandler中的異步處理方式
 - 運營人員權限校驗參考OperatorRelationServiceImpl
 - 數據權限過濾參考ScopeServiceImpl中的範圍查詢邏輯
【數據庫約束】
 - 新增表必須包含created_at, updated_at, is_deleted字段
 - 表名使用ocs_前綴,字段名使用蛇形命名法
 - 索引設計需考慮查詢場景,高頻查詢字段必須建立索引
 - 外鍵約束通過代碼層面維護,不在數據庫層面創建

示例2：機器人問答功能

【技術約束】
必須遵守:
 - Controller層使用@RestController + @RequestMapping,路徑遵循/api/v1/{module}/{action}格式
 - Service層業務邏輯必須有事務控制,使用@Transactional(rollbackFor = Exception.class)
 - DTO轉換使用項目中的ConvertUtil,不要手動賦值
 - 第三方API調用(如Dify)必須有重試機制和降級策略
 - 敏感配置(API Key)必須從配置中心讀取,不要硬編碼
建議參考:
 - 對話上下文管理參考RobotServiceImpl中的會話ID生成邏輯
 - 消息發送失敗重試參考FeishuMessageHandler中的重試策略
 - 錯誤處理參考GlobalExceptionHandler中的統一異常處理
【集成約束】
 - Dify API調用統一通過DifyClient,響應格式需轉換為項目標準格式
 - 飛書機器人回調處理需實現簽名校驗,參考FeishuEventHandler
 - 所有外部API調用需記錄請求日誌到integration_log表 

階段三：迭代反饋------在"做的過程"中持續對齊

這個階段的核心是增量驗證，避免一次性生成大量代碼後才發現方向錯誤。

實踐要點：

1.分模塊實現，逐個驗證

• 先實現核心接口(如任務分配)，驗證通過後再實現輔助功能(如任務查詢)。
• 先實現Service層核心邏輯，驗證業務流程正確後再補充Controller和參數校驗。

2.關鍵節點主動暫停

• 數據庫表設計完成後，先讓開發者確認表結構再繼續。
• 核心業務邏輯實現完成後，先通過單元測試驗證再生成Controller。
• 集成第三方API前，先確認調用方式和參數映射。

3.持續同步技術方案

• 發現架構設計與現有代碼不一致時，立即更新tech-solution.json和tech-solution.md。
• 新增數據表、修改核心邏輯時，同步更新技術方案文檔。
• 每個模塊完成後，更新模塊狀態為implemented → reviewed → verified。

對話示例：

開發者: "實現新商户成長任務分配功能"
AI: "我將分三步實現:
1. 先設計數據庫表結構(ocs_task_assignment表)
2. 實現核心分配邏輯(NewMerchantTaskAssignService)
3. 實現Controller層接口
現在開始第一步,設計的表結構如下:
[展示表結構]
請確認表結構是否符合需求?"
開發者: "字段沒問題,但索引需要加上(operator_id, status)"
AI: "已更新索引設計,現在開始實現Service層核心邏輯...
[生成Service代碼]
核心邏輯已實現,包含:
- 任務池查詢(按優先級過濾)
- 運營人員負載檢查
- 任務分配和狀態更新
- 飛書消息發送
請驗證業務邏輯是否正確?"
開發者: "邏輯正確,繼續實現Controller"
AI: "開始實現Controller層...
[生成Controller代碼]
已完成模塊M1實現,更新技術方案狀態為implemented"

對話設計三原則與常見問題應對策略

為什麼這樣設計：背後的認知科學原理

這種結構化對話設計不是憑空想出來的，而是基於我們對人類認知過程的理解：

• 工作記憶限制理論： 就像我們一次只能記住7±2個信息塊一樣，AI的上下文理解能力也是有限的。通過分階段對話和單次聚焦單模塊，我們控制了每次交互的認知負荷。
• 漸進式知識構建： 學習和理解是一個漸進過程，先掌握整體框架再深入細節，符合認知規律。這和我們教新人時"先講架構圖，再講模塊間交互，最後講具體實現"的思路是一致的。

四、AI團隊協作模式：子代理系統的實踐與思考

隨着團隊使用Claude Code的深入，我們發現單個AI助手已經難以滿足複雜項目的開發需求------就像一個人再厲害也幹不了一個團隊的活。於是，我們開始探索讓多個AI"角色"協同工作的模式，這就是子代理（SubAgent）系統的由來。

團隊協作的現狀與挑戰

在傳統開發模式中，我們有需求分析師、架構師、開發工程師、測試工程師等不同角色，他們通過文檔、會議和代碼審查等方式協作。這種模式雖然成熟，但在快節奏的業務迭代中，我們發現了一些問題：

協作中的三大痛點：

• 信息傳遞損耗： 需求文檔從產品經理到開發再到測試，每經過一個環節就可能產生一些理解偏差。就像玩"電話遊戲"，信息傳到最後可能已經面目全非。
• 責任邊界模糊： 當出現問題時，有時會出現"這是架構設計問題"、"這是實現問題"、"這是測試不充分"的互相推諉。
• 反饋週期漫長： 從需求分析到代碼審查，整個流程走下來往往需要幾天時間，等發現問題時可能已經投入了大量開發資源。

這些問題促使我們思考：能不能在Claude Code中模擬團隊協作模式，讓不同的AI角色各司其職又協同工作？

Claude Code的子代理協作模式

借鑑了MetaGPT等框架的思想，我們在Claude Code中構建了由多個專業化子代理組成的AI團隊協作系統。每個子代理承擔特定角色，通過標準化中間產物協同工作。

核心工作機制：中間產物驅動

所有子代理通過共享"技術方案文檔"進行協作，這個文檔就像團隊的"共享白板"，包含需求分析、模塊劃分、實現狀態和接口設計等關鍵信息。每個子代理只負責修改文檔中與自己角色相關的部分，確保信息一致性。

四個核心子代理角色

技術方案架構師

負責需求分析、技術方案設計和模塊劃分。相當於團隊裏的架構師，輸出"技術方案文檔"這個"施工藍圖"。

核心職責：

• 需求拆解與模塊劃分
• 技術棧選型與架構設計
• 接口定義與數據模型設計
• 模塊間依賴關係梳理
• 技術方案文檔編寫與維護

代碼審查專家

負責代碼質量審查。扮演技術負責人的角色，從架構合規性、代碼規範和穩定性等角度挑毛病。

核心職責：

• 檢查代碼是否符合架構設計
• 驗證代碼規範和命名約定
• 識別潛在性能問題和bug
• 評估代碼可維護性和擴展性
• 提供具體修改建議

代碼實現專家

專注於代碼實現和單元測試編寫。就像主力開發工程師，按照架構師設計的藍圖一塊塊地實現功能。

核心職責：

• 根據技術方案實現代碼
• 編寫單元測試和集成測試
• 修復代碼審查中發現的問題
• 編寫API文檔和使用説明
• 同步更新技術方案實現狀態

前端頁面生成器

專門負責生成符合我們低代碼平台規範的前端頁面配置。這是針對我們商家域管理後台特點定製的角色。

核心職責：

• 根據接口定義生成前端頁面配置
• 實現表格、表單、詳情頁等標準組件
• 配置頁面權限和數據範圍過濾
• 優化前端交互體驗
• 確保符合設計規範和響應式要求

協作流程

我們採用"先整體規劃，再迭代實現"的工作方式，有點像敏捷開發中的Sprint規劃+Daily Scrum：

1. 整體規劃階段：

• 產品經理提供需求文檔。
• 協調者調用"技術方案架構師"子代理分析需求，生成技術方案文檔。
• 團隊評審技術方案，提出修改意見。
• 架構師子代理根據反饋修改方案，直到團隊確認。

2. 單模塊迭代階段：

• 協調者從技術方案文檔中選取一個模塊。
• 調用"代碼實現專家"生成代碼。
• 調用"代碼審查專家"審查代碼。
• 實現專家根據審查意見修改代碼。
• 重複"實現-審查-修改"直到通過。
• 更新技術方案文檔，標記該模塊為"已完成"。
• 進入下一個模塊。

子代理協作的價值與侷限

實踐中的三個顯著價值

• 專業化分工提升質量： 每個子代理專注於特定領域，就像專科醫院比綜合醫院在特定疾病上更專業一樣。我們發現，專門的代碼審查子代理比通用AI能發現更多潛在問題。
• 流程標準化降低風險： 通過技術方案文檔和明確的角色分工，開發流程被標準化和可視化。新人加入項目時，只要看技術方案文檔就能快速瞭解整體情況。
• 知識沉澱促進複用： 子代理的專業知識和決策邏輯被編碼為可複用的配置和規則，避免了"人走經驗丟"的問題。

遇到的四個實際挑戰

子代理協作的挑戰與應對：

• 上下文同步問題： 當技術方案文檔更新時，各子代理有時不能立即同步最新信息。解決辦法：每次修改文檔後，明確通知相關子代理"技術方案中XX部分已更新"。
• 協作邊界模糊： 在處理跨模塊功能時，出現"該由哪個子代理負責"的困惑。解決辦法：在技術方案文檔中添加"責任人"字段，明確每個模塊由哪個子代理負責。
• 靈活性與標準化的平衡： 高度標準化的流程有時會限制處理特殊情況的靈活性。解決原則：90%的常規情況嚴格遵循標準流程，10%的特殊情況由人工介入處理。
• 錯誤傳遞放大效應： 如果技術方案設計階段就有問題，這個問題會在後續實現和審查階段被放大。解決辦法：加強技術方案的人工評審環節，確保"地基"打牢。

子代理協作的設計思考

在設計這套協作模式時，我們有幾個關鍵思考：

• 為什麼選擇"中間產物驅動"而非"直接溝通"？
• 直接讓子代理之間對話可能更靈活，但會導致溝通成本指數級增加（n個代理就有n(n-1)/2種溝通渠道）。通過"技術方案文檔"這個單一事實來源，我們大大降低了協作複雜度，也便於追蹤變更歷史。
• 角色劃分的依據是什麼？
• 我們的角色劃分基於軟件開發的自然階段（設計→實現→審查）和專業領域（後端→前端），這符合軟件開發生命週期的自然規律。沒有盲目追求角色數量，而是根據實際需求逐步增加。
• 為什麼採用"增量迭代"而非"一次性開發"？
• 複雜系統的構建本質上是一個不斷學習和調整的過程。增量迭代讓我們能夠及早發現問題並調整方向，避免在錯誤的道路上走得太遠。這和我們常説的"小步快跑，快速迭代"理念一致。

五、實踐經驗與未來展望

經過幾個月的Claude Code實踐，從最初的"試試看"到現在成為離不開的開發工具，我們積累了一些經驗，也對AI編程的未來有了更清晰的認識。

實踐經驗總結

人機協作的最佳平衡點：

我們發現最有效的AI編程模式是"人類主導，AI輔助"，而不是反過來。我們將工作內容分為三類：

• AI主導： 標準化代碼生成（如基礎CRUD接口）、單元測試編寫、API文檔生成等重複性高、規則明確的任務。
• 人機協作： 技術方案設計、複雜邏輯實現、代碼審查等需要結合領域知識和創造性思維的任務。
• 人類主導： 需求分析、架構設計、質量決策等高風險、高創造性的任務。

上下文管理的實用技巧

管理好對話上下文是用好Claude Code的關鍵，分享幾個我們團隊總結的技巧：

• 對話線程化： 為不同功能模塊創建獨立對話線程。我們曾經在一個對話裏討論三個不同模塊，結果上下文混亂到不得不從頭開始。
• 關鍵信息錨定： 重要的技術決策和約束要在對話中反覆強調。就像寫文章時，核心觀點要多次出現。
• 文檔外化： 複雜設計和決策要記錄在外部文檔中，而不是僅依賴對話歷史。我們會在對話中引用這些文檔："數據庫設計詳見/doc/db_design.md，特別是索引設計部分"。
• 狀態可視化： 通過技術方案文檔中的進度標記（如[未開始]、[設計中]、[已實現]、[已審查]），直觀跟蹤開發狀態。

質量控制的三個關鍵策略

使用AI生成代碼後，質量控制變得更加重要。我們的做法是：

• 多層次驗證： 單元測試（AI生成）+ 集成測試（人工設計）+ 代碼審查（人機結合）的三層驗證體系。
• 漸進式信任： 從簡單、低風險模塊開始使用AI，建立信任後再逐步擴展。我們最先用AI生成內部工具，驗證沒問題後才用於核心業務系統。
• 錯誤模式學習： 記錄AI常犯的錯誤類型，針對性優化系統提示詞。我們有一個"AI錯誤案例庫"，記錄了"AI忘記處理分佈式鎖超時"、"日期格式轉換錯誤"等典型問題及解決方案。

AI編程的侷限性認知

在實踐過程中，我們也清醒地認識到AI編程並非萬能解決方案，它有幾個明顯的侷限性：

• 創造性思維不足： AI擅長在已有知識範圍內進行組合和優化，但在需要突破性創新的場景下表現有限。比如我們嘗試讓AI設計一個全新的商家結算模型時，它還是會傾向於參考現有模型進行修改，難以跳出固有思維框架。
• 上下文理解深度有限： 儘管Claude Code的上下文窗口已經很大，但對於我們系統中某些"牽一髮而動全身"的核心模塊，AI還是難以把握其深層設計意圖和與其他模塊的隱性依賴。
• 質量責任邊界模糊： 當AI生成的代碼出現質量問題時，責任界定變得複雜。我們的解決辦法是：開發者對AI生成的代碼負全部責任，就像我們對自己寫的代碼負責一樣。
• 領域知識滯後性： AI對我們公司內部系統的最新變更反應不夠及時。為此我們建立了"知識庫更新機制"，每月將最新的系統變更和業務規則整理成文檔，供AI參考。

未來發展方向思考

基於這些實踐經驗，我們對AI編程工具的未來發展有幾點思考：

• 更智能的上下文管理： 未來的AI編程工具應該能自動識別相關上下文、追蹤依賴關係，並在適當的時候提醒開發者潛在的上下文衝突。就像經驗豐富的團隊領導，能記住每個人負責的模塊和項目的整體情況。
• 多模態交互模式： 除了文本對話，未來可能引入圖表、流程圖等多種交互方式。有時畫一個簡單的流程圖(PlantUML)，比寫幾百字描述更能説明問題。
• 自適應學習機制： AI編程工具應該能從團隊的使用反饋中學習，適應特定團隊的編碼風格和業務領域。就像新加入團隊的開發者，會逐漸適應團隊的工作方式。

六、結語：人機協作的新型開發範式

回顧這幾個月使用Claude Code的經歷，我們最大的體會是：AI編程工具的價值不在於替代開發者，而在於構建人機協作的新型開發範式。在這種範式下，人類開發者從繁瑣的重複勞動中解放出來，更專注於需求分析、架構設計和質量把控等高價值創造性工作，而AI則承擔起代碼實現、文檔生成和基礎驗證等標準化工作。

Claude Code作為我們實踐的核心工具，通過精準對話流設計、模塊化任務分解和專業化子代理協作，展示了這種新型開發範式的潛力。但我們也認識到，成功的AI編程應用需要"工具+方法論+團隊協作"三位一體的系統性變革，其中人的角色從"代碼生產者"向"問題解決者"和"質量把控者"轉變。

作為開發者，我們需要保持開放學習的心態，積極探索和適應這種新範式。未來已來，與其恐懼被AI替代，不如學會與AI協作，在人機協作中實現更高的個人價值和團隊效能。畢竟，代碼只是解決問題的手段，而非目的；AI只是增強我們能力的工具，而真正的創新和價值，始終源於人的智慧和創造力。

實踐啓示： 在AI編程時代，最有價值的開發者不是"寫代碼最快的人"，而是"最會引導AI、最能把控質量、最能解決複雜問題的人"。掌握與AI協作的技巧，建立系統化的AI輔助開發流程，將成為未來開發者的核心競爭力。我們的經驗表明，通過合理設計對話流程、明確分工協作和嚴格質量控制，AI編程工具能夠顯著提升團隊效能，但這需要整個團隊在思維方式和工作流程上的共同轉變。

往期回顧

1.入選AAAI-PerFM｜得物社區推薦之基於大語言模型的新穎性推薦算法

2.Galaxy比數平台功能介紹及實現原理｜得物技術

3.得物App智能巡檢技術的探索與實踐

4.深度實踐：得物算法域全景可觀測性從 0 到 1 的演進之路

5.前端平台大倉應用穩定性治理之路｜得物技術

文 /稚歸

關注得物技術，每週更新技術乾貨

要是覺得文章對你有幫助的話，歡迎評論轉發點贊～

未經得物技術許可嚴禁轉載，否則依法追究法律責任。