🔧 阿川の電商水電行

Shopify 顧問、維護與客製化

💡

小任務 / 單次支援方案

單次處理 Shopify 修正／微調

⭐️

維護方案

每月 Shopify 技術支援 + 小修改 + 諮詢

🚀

專案建置

Shopify 功能導入、培訓 + 分階段交付

👉 瞭解詳情 / 免費諮詢

小編精選 - 技術文章翻譯 · 12月26日

禁止新型人工智慧及其結果

前言

你好，我是和田。在いえらぶGROUP擔任開發部執行役員。
我們公司同樣也在今年非常注重AI的應用。我們為所有工程師導入了Cursor，並向技術負責人配發Claude Code，以推進業務效率、加強實現速度及提升準確性。

在這樣的公司中，我對一位新進工程師下了「禁止使用AI」的決定。
近日，有點成為話題的就是這位工程師的故事。

我這位在公司內部是堅定AI推進派的工程師，為何會做出這樣的判斷呢？而三個月後，那位新進工程師又發生了怎麼樣的變化？在這篇文章中，我將從我的視角，整理一下這段過程的經緯和結果。

開始時「讓他繼續使用AI」

新人剛入職時，我讓他使用Cursor，甚至也讓他使用Claude Code。原因很簡單。

實現速度會提高（應該）
能學到最新的最佳實踐（應該）
代碼品質會提升（應該）

事實上，他完全沒有經驗，但還是相對地快速地實現了功能。CRUD功能和數據庫操作，也都做出了一些「可以運行的東西」。

「這可能是個不錯的進展呢～」我當時這麼想。

830條評審意見的衝擊

當我第一次進行大功能的代碼評審時，
評審意見達到了830條（實際上包括靜態解析自動生成的評論）。

主要問題包括：

Model層直接生成HTML（完全無視MVC架構）
除錯代碼混入正式環境（大量的error_log殘留）
超過500行的大規模內聯JavaScript
沒有任何測試代碼
變量名和函數名與現有代碼模式完全不同

實際上，當我看到Model層直接生成HTML的代碼時，「啊，這家伙是使用AI的」一眼就能看出來。

之前: Model層直接生成HTML（違反MVC）

<?php
class Product_Model_Service_AiDescriptionService
{
    public function generateCategorySelectHtml($keyword)
    {
        // ❌ Model層直接生成HTML
        $htmlOutput = '';
        foreach ($categories as $category => $items) {
            $htmlOutput .= '<div class="category-group">';
            $htmlOutput .= '<h3 class="category-title">類別: ' . htmlspecialchars($category, ENT_QUOTES, 'UTF-8') . '</h3>';
            $htmlOutput .= '<ul class="product-list">';

            foreach ($items as $item) {
                $htmlOutput .= '<li class="product-item">';
                $htmlOutput .= '<input type="checkbox" name="products[]" value="' . htmlspecialchars($item['sku'], ENT_QUOTES, 'UTF-8') . '">';
                $htmlOutput .= htmlspecialchars($item['name'], ENT_QUOTES, 'UTF-8');
                $htmlOutput .= '</li>';
            }
            $htmlOutput .= '</ul></div>';
        }
        return $htmlOutput;
    }
}

不過，代碼是「能運行的」呢。然而，從我們公司的規範來看，推崇的可維護性、擴展性及與現有系統的一致性方面，這種代碼的狀態讓我不得不說：「好吧，給我重新做」。

「他認為AI是神」

在評審時我問他
「為什麼在Model層生成HTML呢？」
他的回答讓我震驚不已。

「因為AI這樣實現，所以我認為是正確的。」

「（哇，真的發生這種事啊）」我心想。

接著他又說
「老實說，輸出的代碼實際上比我自己想的更正確。我覺得這就像是神一樣。（誇張）」

「原來如此～」我瞬間理解了。果然，如果沒有判斷AI輸出結果的「基礎」，會變得相當糟糕。

AI禁令

因此，我下達了「禁止使用AI！觸碰的話手會融化。讓自己動腦筋進行肌肉訓練時間」的命令。

禁止期間內要完成的事項

閱讀官方文檔
- 框架的官方文檔
- PHPUnit/PSR的規範
閱讀現有代碼
- 理解過去實現了類似功能的代碼
- 發現代碼的「模式」
將設計語言化
- 實現前撰寫設計書
- 以圖表表達職責分離

提問質量的顯著變化

禁止之前：

「出現這個錯誤，我該怎麼辦？」
「不動作」

禁止之後：

「這個設計似乎會讓Controller集中實現，是否應該切分到Service層？」
「現有的ProductHelper與此次的ProductService命名規則不同，哪個比較好呢？」

禁止期間的階段性反饋

單純禁止AI作為管理者是簡單粗暴的（我真的這麼認為）。因此，在每週的專案進度反饋時，我設計了逐步實現的進展。

第一步: 僅寫類名和函數名進行評審

最初我要求的是，只寫類名和函數名，先進行評審。

讓他完全不寫代碼內部的實現，僅提交「會創建什麼樣的類」「需要什麼樣的函數」。這樣可以針對實現的整體概念提供反饋。

即使如此，最初也還是無法一次通過。因為他的理解中，整體設計與現有系統並不相符。不過，正是透過這一階段的修改，大大減少了之後的返工。

第二步: 只寫註解進行評審

當類名和函數名與我的認知一致後，我要求他在函數內部的實現僅寫註解，而不是代碼。

<?php
public function registerProducts($csvData)
{
    // CSV數據的驗證
    // 若存在驗證錯誤則拋出異常
    // 逐行數據進行循環處理
    //   根據SKU查找現有商品
    //   若存在則更新，否則新建
    //   應用AI生成的描述文
    //   儲存處理
    // 記錄處理結果
    // 返回成功的件數
}

我將根據這些註解內容（類似伪代碼）進行評審。總之，就是要追踪處理的流程的感覺。

在這裡也進行了幾次修改，「這個順序不一致」「這個驗證應該放在Service層而不是Model層」等的交流也有很多。當這些認知一致後，才可開始實現。

第三步: 先無視CSS和布局的實現進行評審

然而即使是實現，這次是先無視CSS和布局的實現。

專注於業務邏輯和數據的傳遞。我的體驗告訴我，如果工程師開始考慮CSS，會花費大量時間。

「與其細細調整外觀，不如先專注於數據是否正確流動，業務邏輯是否正確，僅僅這幾點就足夠了。」

接下來的過程感覺就像是普通的代碼評審。不過，既然已經按照這樣逐步進行，進展明顯比以前更順利。因為不需要擔心CSS的問題，彼此都能專注於本質部分。

第四步: 最後處理CSS和布局

當數據的傳遞和基本的業務邏輯實現完成的時候，我們才開始使用CSS來調整整體布局的工作。

這是理所當然的，但當專注於布局時，似乎也更容易理解現有CSS類別的命名規則和布局模式，因此進展比較順利。

階段性方法的成功

讓新人進行AI實現後，就很難對這一系列流程進行逐步反饋了，這是我個人獲得的啟示。

AI會一次性輸出所有，無法進行「設計→邏輯→外觀」的階段性反饋。類名、函數內邏輯和CSS都是同時出現。

即使請求進行評審，我真的無法確定從哪裡下手，而新人也無法理解「哪裡是根本的問題」。

因此我堅信，能夠一個一個詳細反饋的情況下，禁止使用AI的效果是存在的。

三個月後的評審結果

經過禁用AI的期間，他實現的「優惠券管理功能（假）」最終達到了合格水平。

改進之處

1. 適當的職責分離（理解MVC原則）

<?php
// Model層: 僅返回數據
class Product_Model_Service_AiDescriptionService
{
    public function getCategoryCandidates($keyword)
    {
        return $categories; // 純粹的數據數組
    }
}

// ViewHelper: 生成HTML
class Product_View_Helper_CategoryProductList extends View_Helper_Abstract
{
    public function categoryProductList(array $categories)
    {
        $html = '';
        foreach ($categories as $category => $products) {
            $html .= $this->view->partial(
                'partials/category-products.phtml',
                ['category' => $category, 'products' => $products]
            );
        }
        return $html;
    }
}

2. 使用DataProvider模式的單元測試

<?php
class Coupon_Model_Service_CalculatorTest extends TestCase
{
    public function provideCalculateDiscountCases(): array
    {
        return [
            '固定金額折扣：普通案例' => [
                'subtotal' => 10000,
                'discountType' => 1,
                'discountValue' => 500,
                'expected' => 500,
            ],
            '百分比折扣：端數去除' => [
                'subtotal' => 1999,
                'discountType' => 2,
                'discountValue' => 15,
                'expected' => 299,
            ],
        ];
    }

    /**
     * @dataProvider provideCalculateDiscountCases
     */
    public function test_calculateDiscount($subtotal, $discountType, $discountValue, $expected): void
    {
        $result = $this->calculator->calculateDiscount($subtotal, $coupon);
        $this->assertSame($expected, $result);
    }
}

3. 其他改進點