前言

上一篇已經完成：MySQL → Flask → Gemini → AI 排序 → JSON

今天就來測試 AI 排出來的結果到底合不合理，因為現在我們已經知道「AI 能跑」，下一個問題就是：它真的有按照我們要求的條件在判斷嗎？

今天會測幾種情況：

情況 1：Deadline 很近，但重要程度低
情況 2：Deadline 很遠，但重要程度高
情況 3：條件幾乎一樣的兩個任務。

然後觀察 Gemini 的排序。

情況 1：Deadline 很近，但重要程度低

先用原本資料庫就有的任務測情況一

[
    {
        "priority": 1,
        "reason": "截止期限最急迫（2026-09-09 22:00:00），且為進行中的任務（剩餘 72 分鐘），需優先完成。",
        "task_id": 4
    },
    {
        "priority": 2,
        "reason": "截止期限為 2026-09-09 23:59:00，重要性高（3），且時間緊迫，必須在今天內完成。",
        "task_id": 1
    },
    {
        "priority": 3,
        "reason": "截止期限為 2026-09-10 23:59:00，重要性高（3），僅次於今天的任務。",
        "task_id": 3
    },
    {
        "priority": 4,
        "reason": "截止期限為 2026-09-12 18:00:00，重要性高（3），需提前準備複習離散數學。",
        "task_id": 5
    },
    {
        "priority": 5,
        "reason": "雖然截止期限較遠（2026-09-18），但重要性高（3）且為進行中任務（剩餘 72 分鐘），可持續推進。",
        "task_id": 8
    },
    {
        "priority": 6,
        "reason": "截止期限為 2026-09-16，重要性中等（2），時間尚算充裕。",
        "task_id": 7
    },
    {
        "priority": 7,
        "reason": "截止期限為 2026-09-24，時間充裕且僅需 30 分鐘，重要性為 2。",
        "task_id": 11
    },
    {
        "priority": 8,
        "reason": "截止期限雖遠（2026-09-26），但所需時間較長（180 分鐘）且重要性高（3），可逐步安排時間。",
        "task_id": 10
    },
    {
        "priority": 9,
        "reason": "截止期限最遠（2026-09-20），且重要性最低（1），建議排在最後處理。",
        "task_id": 9
    }
]

1 → task 4　Deadline 最近 + 進行中
2 → task 1　今天到期 + 重要程度高
3 → task 3　明天到期 + 重要程度高
4 → task 5　9/12 到期 + 重要程度高
5 → task 8　9/18 到期 + 重要程度高 + 進行中
...
9 → task 9　Deadline 較遠 + 重要程度最低

這其實符合我們目前 Prompt 的基本邏輯：

Deadline 越近 → 越優先
重要程度越高 → 越優先
已經開始的任務 → 要考慮進度

task 4

重要程度：2
Deadline：9/9 22:00
進度：20%
剩餘：72 分鐘

task 1

重要程度：3
Deadline：9/9 23:59
進度：0%
剩餘：120 分鐘

如果只看重要程度：

task 1 > task 4

但如果只看 Deadline：

task 4 > task 1

結果 AI 選：

task 4 → 1
task 1 → 2

這就代表目前 Gemini 沒有只看某一個欄位，而是有按照 Prompt 去綜合判斷。

情況 2：Deadline 很遠，但重要程度高

情況二要測一個更極端的情況：「重要程度 3，但是 Deadline 很遠」

這樣才能知道 AI 到底會不會把「重要程度」看得比「Deadline」重要。

在 MySQL 新增一個測試任務

INSERT INTO tasks
(title, description, estimated_minutes, importance, deadline, progress, status)
VALUES
(
    '測試高重要程度任務',
    'Day 18 AI 排序測試',
    60,
    3,
    '2026-09-10 23:59:00',
    0,
    'todo'
);

這個任務的條件是：

重要程度：3（最高）
Deadline：09/10
預估時間：60 分鐘
進度：0%

而 task 4：

重要程度：2
Deadline：9/9

所以現在故意製造：

Deadline：
task 4 比較急
重要程度：
測試任務比較高
得到：

[
    {
        "priority": 1,
        "reason": "Deadline 最近（2026-09-09 22:00:00），且已在進行中（剩餘 72 分鐘），需優先完成避免逾期。",
        "task_id": 4
    },
    {
        "priority": 2,
        "reason": "Deadline 與 Task 4 同日（2026-09-09 23:59:00），重要程度高（3），需緊接著處理。",
        "task_id": 1
    },
    {
        "priority": 3,
        "reason": "Deadline 緊迫（2026-09-10 23:59:00），重要程度高（3）。",
        "task_id": 13
    },

情況 3：條件幾乎一樣的兩個任務。

### 在 MySQL 新增一個與任務13相似的測試任務

INSERT INTO tasks
(title, description, estimated_minutes, importance, deadline, progress, status)
VALUES
(
    '測試條件相近任務',
    'Day 18 AI 排序測試',
    60,
    3,
    '2026-09-10 23:00:00',
    0,
    'todo'
);

得到:

  {
        "priority": 3,
        "reason": "Deadline 非常接近（2026-09-10 23:00:00），重要程度高（3分）。",
        "task_id": 14
    },
    {
        "priority": 4,
        "reason": "Deadline 為 2026-09-10 23:59:00，重要程度高（3分）。",
        "task_id": 3
    },
    {
        "priority": 5,
        "reason": "Deadline 與任務 3 相同（2026-09-10 23:59:00），重要程度高（3分）。",
        "task_id": 13
    },

最明顯的是 Task 14 確實被排在 Task 3、Task 13 前面。

因為：

Task 14 的 Deadline 是 23:00
Task 3、Task 13 的 Deadline 是 23:59

三個任務的重要程度都是 3，所以這次 AI 幾乎可以單純靠 Deadline 的差異來做判斷。

而且 Task 3 和 Task 13 的條件甚至完全一樣：

重要程度：3
Deadline：9/10 23:59

結果 AI 還是排成：

Task 3 → Task 13

並且 Task 13 的理由直接說：

Deadline 與任務 3 相同，重要程度高

這就出現一個很值得記錄的現象：

⚠️ AI 不一定能穩定處理「完全相同條件」

Task 3 和 Task 13 的資料條件相同，但 AI 還是硬排出 Priority 4、5。

AI 可以幫忙判斷，但如果條件太接近，它不一定能給出穩定、客觀的排序。

Day 18 的目的就是把問題測出來；之後 Day 19 的「輸出驗證」以及後面的排序邏輯，才有理由繼續處理它。