如何透過可審核的差異檢視 AI 對專案檔案的修改

A helper that can edit a project directory can save a lot of typing. The awkward moment comes when its response says that it updated the right files, but you still need to find out which files changed and whether the edits match your request. A reviewable diff gives you a specific object to inspect before you accept the result.

Consider a small documentation repository. The request is to rename a field in two examples, while preserving older examples in an archive. The assistant finds several occurrences of the name. Search is useful here, but the list of matches is broader than the list of approved changes. Treat those as two separate pieces of work.

Make the write boundary explicit

Start with a clean working tree or a disposable copy that contains only the files the exercise needs. If there are unrelated local changes, preserve them and record their locations before starting. A clean baseline makes it possible to tell the assistant's edits from work already in progress.

Describe the allowed scope using paths and a concrete change. For example, allow updates to two example files and ask the assistant to report matches elsewhere. The archive can be useful context without becoming part of the write operation. A restriction written only as a broad preference is harder to check after the fact.

Read the changed paths first

For a repository managed with Git, git status --short gives a compact inventory of changed and untracked paths. Follow with git diff --stat to see where tracked edits are concentrated. These checks answer a simple question before you spend time reading individual lines: did the operation touch the expected part of the repository?

Keep the distinction between the two commands in mind. A normal diff can omit an untracked file. It can also omit staged changes, which you can examine with git diff --cached. Look at the inventory and the relevant diffs together so that a plausible patch does not distract you from an unexpected new file.

Review the boundary and the meaning

Open the diff for each approved path. Check that the field name changed where it should and that the surrounding example still works. A repeated label might be part of a comment, a key in an example object, or a literal value that should remain. The same spelling does not give all occurrences the same role.

Read each hunk as an editor would. An indentation change may be irrelevant in prose but important in a structured example. A broad rewrite may make a tiny naming change harder to review. Ask for a narrower patch if the original request can be satisfied with fewer changes.

Compare tools at the review point

When surveying AI workflows, keep a distinction between proposing an edit, applying it, and approving the result. For this trial, compare whether each candidate can present a change that the reviewer can reproduce and understand. A fast response is only part of the elapsed work.

Use the same small repository and instruction for each candidate. Record the changed paths, the edits that met the request, and the corrections you needed before accepting the result. If you have not tested a product's write controls or permission settings, leave those observations open.

Test the result through its normal entry point

Run the smallest check that actually exercises the edited example. If the example is meant to parse, parse it. If it appears in rendered documentation, render the relevant page and read the changed section. A successful formatting check can be useful evidence, but it may not prove that an example still teaches the correct behavior.

Compare the final status with the permitted path list again after the check. Some tools create local output while validating a change. Distinguish expected output from files that belong in the patch, and keep generated files out of a change unless the project requires them.

Leave a short acceptance record

Record the request, the approved paths, and the check you ran. If an archived example was deliberately kept, state the reason in the review record. The next person can then understand the scope without reconstructing your conversation with the assistant.

A good editing workflow leaves a trail a reviewer can follow in a few minutes. That trail starts with a known baseline, shows the proposed effect, and ends with a check through the normal project entry point. It is also useful when the assistant's patch is almost right: you can point to the exact file or hunk that needs another pass.