如何為編碼智能體交付提供足夠審閲證據

A delivery message saying “fixed and tested” leaves the reviewer with the hardest part: reconstructing what changed, which check ran, and whether the screenshot matches the patch. A small evidence packet makes AI task handoff for teams easier to inspect.

This tutorial was prepared with AI assistance for Wagglet-related marketing work. The example is a deliberately small local fixture. It does not describe a production incident or claim that a screenshot has already been captured.

Start with one reviewable behavior

Suppose a level-tool report lists objects in the order it receives them. Two exports of the same level produce different row order, so a designer cannot compare reports reliably. The requested behavior is stable ordering by object ID. The tool must report empty labels while leaving the input level untouched.

The designer prepares the expected report and sample level. An authorized technical teammate uses their own development tools and, if useful, a coding agent to implement the change. A qualified engineer judges the code; the designer confirms the report is useful. Those responsibilities belong in the brief before anyone begins.

Here is a standalone fixture. Save it as report-check.mjs and run node report-check.mjs with Node 22:

import assert from 'node:assert/strict';

function audit(level) {
  return [...level.objects]
    .sort((a, b) => a.id.localeCompare(b.id))
    .map(o => ({
      id: o.id,
      label: o.label.trim(),
      warning: o.label.trim() ? '' : 'empty label'
    }));
}

const level = { objects: [
  { id: 'b', label: ' Exit ' },
  { id: 'a', label: ' ' }
] };
const before = JSON.stringify(level);
assert.deepEqual(audit(level), [
  { id: 'a', label: '', warning: 'empty label' },
  { id: 'b', label: 'Exit', warning: '' }
]);
assert.equal(JSON.stringify(level), before);
console.log('PASS: stable report; input unchanged');

The copied array matters: sorting the original array would modify the input. Trimming belongs in the report, not in the source level. These are concrete boundaries a reviewer can inspect without reading an entire game project.

Attach evidence to claims

The corresponding local sample check was run under Node 22.23.2. It confirmed stable ordering, the empty-label warning, and unchanged input. That supports only this fixture. It does not establish file permission safety, large-level performance, or compatibility with a studio's editor.

For an actual patch, collect four items:

1. Test result: exact command, runtime version, exit code, and full output. Include the failing baseline if the change fixes a regression. A cropped green badge cannot show which tests ran.
2. Changed files: the revision and a short explanation for each file. For this example, the proposed scope is tools/audit.mjs, fixtures/level.json, and tests/audit.test.mjs. These are illustrative paths, not claims about an existing repository.
3. Screenshot: a real capture of the report opened in the delivered build. Its caption should identify the build and sample. Suggested capture: “Level audit showing object a with an empty-label warning above object b, Exit.” This is a capture specification; no image is being presented as evidence here.
4. Known limits: tests not run, environments not checked, and behavior intentionally excluded. Keep these beside the positive results.

Use a delivery template with a reviewer action

Task/revision: [ID and commit]
Requested behavior: stable report order; unchanged input
Changed files: [actual paths and purpose]
Reproduce: [clean setup and exact command]
Baseline: [failure command/output or not applicable]
After: [command, exit code, output]
Visual evidence: [real capture, build, fixture, effect age if relevant]
Known limits: [specific unchecked cases]
Reviewer: [person authorized to accept]
Requested decision: accept scope / request changes

A screenshot cannot prove that a script leaves files untouched. A unit assertion cannot prove that a report is readable at the designer's normal display scale. Match each piece of evidence to the claim it can support.

Keep delivery separate from acceptance

The executor submits the packet. The engineer checks that the implementation matches the stated scope and reproduces the result. The designer checks whether the ordering and warnings solve the original problem. Acceptance is recorded by the authorized reviewer; merge and deployment remain separate decisions.

Wagglet's request-to-review workflow provides context for making those handoffs explicit. The useful practice is portable: a task should arrive with the information needed for its next human decision.

Before accepting, check that the revision matches the screenshots, the commands run from a clean checkout, and every unchecked environment is still listed. If an artifact is missing, request that artifact specifically. “Please rerun the report with the included level and attach the output” gives the implementer a bounded next action.