子代理分工与品质检查

返回 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