Day 8 的實戰測試發現了第一版 System Prompt 的不足之處。今天上半部，我們要針對測試中發現的問題進行分析，並制定解決策略。

一、測試發現的問題

問題分類與優先順序

根據測試結果，我們將問題分成三個層次：

影響開發品質

• 測試規範過於模糊，AI 無法產出完整測試
• 遇到規範衝突時，沒有明確的優先順序
• 新專案缺乏既定的程式碼模式

影響開發效率

• 不同 AI 工具生成的程式碼風格差異大
• 安全規範描述過於抽象，檢查不夠具體
• 錯誤處理缺乏統一的標準

影響開發體驗

• 程式碼註解不一致
• API 回應格式不統一

問題根因分析

測試規範過於模糊

原始規範只有一句「Write unit tests for all functions」。

AI 無法理解：

• 測試範圍：要涵蓋哪些情境？
• 測試深度：需要測到什麼程度？
• 測試格式：應該用哪種結構？

因此 AI 只能生成最基本的正常情境測試，邊界條件與錯誤情境完全缺失。

規範衝突導致判斷困難

例如在 PHP 中：

• 建構子屬性提升與傳統建構子寫法
• match 表達式與 switch 語句
• 嚴格型別與向下相容性

缺乏明確的優先規則，AI 無法做出一致判斷。

新專案缺乏模式定義

「Follow existing code patterns」在新專案完全無法使用，AI 需要清楚的初始模式範本。

二、提升開發品質的解決策略

1. 具體化測試要求

原始規範（過於抽象）：

Write unit tests for all functions

改進後：

TESTING_REQUIREMENTS:
- Write comprehensive unit tests covering success, failure, and edge cases
- Test scenarios must include:
  * Happy path: normal valid inputs
  * Validation errors: empty/null/invalid inputs  
  * Boundary conditions: min/max values, empty arrays
  * Error handling: network failures, database errors
- JavaScript: Use Jest syntax with describe/it blocks
- PHP: Use PHPUnit with meaningful test method names
- Minimum 80% code coverage for new functions
- Example test structure:
  ```php
  public function testCreateOrderWithValidDataReturnsSuccessResponse(): void
  public function testCreateOrderWithEmptyProductsThrowsValidationException(): void
  public function testCreateOrderWithInsufficientInventoryReturnsErrorResponse(): void

2. 建立規範優先順序制度

PRIORITY_SYSTEM:
P1_SECURITY: Input validation, SQL injection prevention (NEVER compromise)
P2_FUNCTIONALITY: Core business logic correctness
P3_CONSISTENCY: Naming conventions, code style
P4_OPTIMIZATION: Performance, code elegance

Decision Rules:
Security requirements override all other considerations
Functionality requirements override style preferences
Team consistency overrides personal preferences
Document any P1/P2 compromises with explicit comments

實際應用範例

// P1 Security vs P4 Optimization conflict
// Security wins: Use prepared statement even if slower
$stmt = $pdo->prepare("SELECT * FROM orders WHERE user_id = ?");
$stmt->execute([$userId]);

// P2 Functionality vs P3 Consistency conflict  
// Functionality wins: Use match() for complex business logic even if team prefers switch
$orderStatus = match($statusCode) {
    'pending' => OrderStatus::PENDING,
    'confirmed' => OrderStatus::CONFIRMED,
    default => throw new InvalidStatusException()
};

3. 新專案模式定義

PROJECT_INITIALIZATION:
For new projects without existing patterns:

PHP_PATTERNS:
- Use strict_types declaration
- Prefer dependency injection over static methods
- Return arrays with consistent structure: 
  ['success' => bool, 'data' => mixed, 'errors' => array]
- Class naming: {Entity}{Action} (OrderValidator, ProductService)

JAVASCRIPT_PATTERNS:
- Use ES6+ features (const/let, arrow functions, async/await)
- Prefer class-based architecture for complex logic
- Return Promise-based responses for async operations
- Module export: named exports for utilities, default export for main classes

DIRECTORY_STRUCTURE:
- Controllers/: HTTP request handling
- Services/: Business logic
- Validators/: Input validation
- Models/: Data structures
- tests/: Test files mirroring src structure

三、提升開發效率的策略

1. 收斂工具差異

Claude Code 偏好現代語法，Cursor 偏好傳統寫法。

FOR_CLAUDE_CODE:
- Leverage modern PHP 8+ features (match expressions, constructor promotion)
- Use typed properties and return types extensively
- Prefer composition over inheritance

FOR_CURSOR:
- Focus on backward compatibility (PHP 7.4+)
- Use traditional array syntax when in doubt
- Emphasize clear, readable code over advanced features

SHARED_REQUIREMENTS (Non-negotiable):
- PSR-12 formatting regardless of tool
- Security practices are identical across tools
- Test structure must be identical across tools
- Error response formats must be consistent

2. 安全規範檢查清單

SECURITY_CHECKLIST:

INPUT_VALIDATION:
- All user inputs must be validated before processing
- Use allow-lists rather than block-lists for validation
- Sanitize inputs for display (htmlspecialchars for HTML)
- Validate data types, ranges, and formats explicitly

DATABASE_SECURITY:
- Use prepared statements for ALL database queries
- Never concatenate user input directly into SQL
- Use parameterized queries even for internal functions
- Example pattern:
  
  // NEVER
  $sql = "SELECT * FROM users WHERE id = " . $userId;
  
  // ALWAYS  
  $stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
  $stmt->execute([$userId]);
  

ERROR_HANDLING:
- Never expose internal system details in error messages
- Log detailed errors internally, return generic messages to users
- Use consistent error response formats across all endpoints

3. 錯誤處理統一範本

PHP 範本

// 成功回應
return [
    'success' => true,
    'data' => $result,
    'message' => 'Operation completed successfully'
];

// 錯誤回應
return [
    'success' => false,
    'errors' => ['field' => 'Validation message'],
    'message' => 'User-friendly error description'
];

JavaScript 範本

async function submitOrder(orderData) {
    try {
        const response = await fetch('/api/orders', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify(orderData)
        });
        
        const result = await response.json();
        
        if (!response.ok) {
            throw new Error(result.message || 'Request failed');
        }
        
        return { success: true, data: result };
    } catch (error) {
        console.error('Order submission failed:', error);
        return { 
            success: false, 
            error: error.message || 'Network error occurred' 
        };
    }
}

調整完這些內容後，接下來會再進行一次測試，確認新的規範是否有效改善之前的問題。