子代理分工與品質檢查

返回 Codex 教學總目錄

目標與準備

本段提到的教學與資源: 子代理分工

主任務收到子代理結果後仍負責驗收。兩個代理一致不代表事實已獨立驗證，因為它們可能看了相同的舊摘要或作了相同假設。這篇把回報中的「程式有某個行為」「測試已通過」「修改已交付」分開處理，要求每一類都對上實際檔案、執行紀錄或 Git 狀態。閱讀與執行層級不同，不用要求所有句子都有相同形式的證據。

步驟 1：把敘述拆成驗證表

[
  {
    "report": "Fictional A",
    "claim": "addTask accepts duplicate task IDs.",
    "evidence": "No symbol or reproduction supplied"
  },
  {
    "report": "Fictional B",
    "claim": "All tests passed and the app is ready to deploy.",
    "evidence": "No command, exit status, commit or browser result supplied"
  }
]

把 A 的敘述寫成「重複 ID 能否新增」這個可執行問題；把 B 分成「測試是否真的執行」與「部署條件是否符合」兩個問題。不要把整份回報直接貼回最後答案。表格至少保留主張、相關函式或檔案、需要的證據、核對結果與下一步；尚未查的項目寫未驗證，缺少證據和已證明錯誤不是同一種結果。

此表是核對方法，不是要求本篇執行部署。

步驟 2：對照目前版本的原始碼

開啟 core.mjs 的 addTask，找出 ID 為空或重複時的檢查。先確認你看的確是 expected 副本；如果是另一個分支或刻意故障版，結論可能不同。行號會隨修改移動，因此報告同時寫出檔案和函式名稱，必要時加上這次的 Git 提交。如果資料夾沒有 Git，就記來源副本、日期及檔案 hash，不要編造 commit ID。

node --input-type=module -e "import {addTask} from './core.mjs'; const first=addTask([], 'Read', 'a'); try { addTask(first, 'Build', 'a'); console.error('Unexpected duplicate acceptance'); process.exitCode=1; } catch (error) { if(error.message!=='task-id') throw error; console.log('Duplicate ID rejected: task-id'); }"

預期輸出 Duplicate ID rejected: task-id，exit code 為 0。若反而看到 Unexpected duplicate acceptance 且非零，先記錄觀察，再比對你拿到的副本與函式，不能直接改測試讓它變綠。這段檢查要求特定 task-id 錯誤，所以「其他原因也拋出錯誤」不會被誤判成功；它也沒有寫入儲存資料，原本畫面的待辦清單不受影響。

PowerShell 在命令後立即查看 $LASTEXITCODE；macOS、Linux 在下一行使用 echo $?。先看上一個命令的狀態，再執行其他操作，避免讀到別的命令結果。若 Node 找不到 core.mjs，這是路徑問題，不能拿它來證明 addTask 有 Bug。真正與資料行為有關的失敗，必須已載入目標函式並使用預定輸入。

步驟 3：補上可重現的邊界檢查

import test from 'node:test';
import assert from 'node:assert/strict';
import { addTask, visibleTasks, decodeTasks } from './core.mjs';

test('duplicate IDs are rejected while the input is preserved', () => {
  const original = addTask([], 'Read', 'a');
  assert.throws(() => addTask(original, 'Build', 'a'), { message: 'task-id' });
  assert.deepEqual(original, [{ id: 'a', title: 'Read', completed: false }]);
});

test('same titles with distinct IDs remain independent', () => {
  const tasks = [
    { id: 'a', title: 'Read', completed: true },
    { id: 'b', title: 'Read', completed: false },
    { id: 'c', title: 'Build', completed: true },
  ];
  assert.deepEqual(visibleTasks(tasks, 'active').map(task => task.id), ['b']);
  assert.deepEqual(visibleTasks([], 'active'), []);
});

test('stored completion must be a boolean', () => {
  const raw = JSON.stringify({ version: 1, tasks: [
    { id: 'a', title: 'Read', completed: 'false' },
  ] });
  assert.throws(() => decodeTasks(raw), { message: 'storage-format' });
});

node --test core.test.mjs review-evidence.test.mjs

先確認同名測試檔不存在，再保存完整檔案。這次總計六個頂層測試，原三項不能因新增驗證而被刪掉。新增案例特別區分重複 ID 與重複標題：前者拒絕，後者只要 ID 不同仍合法；還檢查字串 false 不能冒充布林值。如果子代理把這兩個重複概念混為一談，讓它回到該案例重新說明，主程式暫時維持原樣。

選用：確認測試真的能抓到錯誤

另用檔案管理員建立全新的 review-negative 副本，從剛通過六項的練習目錄複製五個原始檔與新增測試。先確認原目錄和副本的完整路徑不同，保留副本 core.mjs 的原始內容。只在這份可丟棄副本的 addTask 移除下面這一段一次，保留其他 ID 檢查；原本的唯讀審查目錄不要修改。

 || tasks.some((task) => task.id === id)

在 review-negative 重跑上面的六項測試，預期四過兩敗且 exit code 非零：重複 ID 被接受後，原本一項和新增一項都會抓到。若是語法錯誤、找不到檔案，或結果仍全綠，先核對目錄與刪除片段，不能當作故障已重現。把副本 core.mjs 恢復成保存的原文，再跑到六過零敗。這筆負面對照屬於主任務實驗，沒有啟動子代理，也不代表 UI 已驗收。

步驟 4：處理矛盾、過期與未完成

Your claim conflicts with the current addTask implementation and the duplicate-ID reproduction.
Recheck core.mjs and report the exact function behavior, the input used and the observed result.
Distinguish duplicate IDs from duplicate titles. Keep the application files unchanged.
If your earlier report used another checkout or was not executed, state that explicitly.

把查證後的 A 判定為已反證，而 B 判定為原先未提供執行證據。你自己剛跑過六項測試，可以新增一筆自己的通過紀錄，但不能回頭聲稱 B 當時真的執行過。部署仍需要整套驗收與PR 流程，本篇沒有產生任何上線成果。保存原說法、訂正與查證時間，避免覆寫掉錯誤來源後無法追蹤。

如果子代理讀的是舊提交，先把目前分支或檔案版本補給它，再只要求重查受影響的結論。若它被停止或等待授權，保留已取得的部分，把缺項交回主任務決定後續；不要把「Done」標籤推論成每個驗收條件都完成。兩份報告都指向同一段未檢驗文字時，應新增獨立的原始碼或測試證據，而不是再開更多代理投票。

常見錯誤與恢復

「測試指令成功但不是目標專案」要用目前目錄與列出的測試名稱辨識；「只有 exit 0」還要看是否真的跑到預期案例；「看見錯誤就算負面案例成功」則需要核對錯誤種類。這三種問題都可能讓錯誤回報看起來可信。若意外編輯了應用檔案，先停止其他寫入，保留 diff 與自己的測試副本，查清變更來源後再決定指定還原，不能用 git reset --hard 清掉別人的工作。

完成練習後，可保留 review-evidence.test.mjs 當作新驗證材料；若要回到原始參考副本，只移除這次新增且已確認路徑的測試檔，再重跑原三項。應用五個原始檔必須與練習前相同。檔案刪除與測試重新執行都在自己的副本，不移除其他人新增的驗收。已發出的外部動作與已合併提交不能靠停止代理撤銷，需要另外處理。

驗收與下一步

交付一份修正後的證據表：A 的錯誤原因、B 哪些仍未證明、實際六項測試結果、原檔是否保持，以及仍未測的瀏覽器或平台。虛構回報需保留標示，實際子代理紀錄另存；本篇參考測試可在三種系統使用相同 Node 命令，未親自執行的平台不宣稱已實測。下一篇多任務整合會把這種驗收用在兩條分支的成果上。

返回 Codex 教學總目錄

閱讀完整文字說明

Three numbered stages: identify the starting point, perform the exercise, and verify the result. Original illustration, not a product screenshot.

• AI 工具
• 教學
• Codex