跳到正文
DEV Community· Acadify Solution·· 3 小時前AI 評分59

如何測試 AI 助手的過期寫入,避免覆蓋人工修改

Test the Stale AI Write Before It Overwrites a Human Edit

AI 導讀

這篇指南以虛構的共享訂單應用為例,示範如何測試 AI 助手提交舊版本提案時,避免覆蓋人工修改。它建議將版本核對與寫入作為原子操作,並測試同欄位衝突、相關欄位衝突、權限撤銷,以及再次套用前重新檢查版本。案例並非客戶結果或已執行的基準測試。

正文

An assistant can produce a valid proposal from revision 12 and still damage the workflow by saving it after revision 13 exists.

This guide uses a fictional shared-order application. It is a test-design example, not a report of client results or an executed benchmark.

Start with a deliberate interleaving

The fictional record contains a delivery date and an internal note. An assistant reads revision 12 and prepares a note update. Before the write happens, an authorised coordinator corrects the delivery date, creating revision 13.

If the assistant submits a complete copy of revision 12, an unconditional save can restore the old date. Even a narrow patch needs a conflict policy: a note about delivery may depend on the date the coordinator just changed.

The test should control this sequence directly. Use a barrier or a paused test double after the assistant's read. Arbitrary sleeps make the ordering harder to reproduce.

Agree the write contract

One conservative contract is to reject the proposal whenever the record revision has changed. The response should preserve the current record and let the application offer a comparison or a refreshed suggestion.

The critical property is that checking the revision and writing are one atomic decision. A preliminary read followed by an unconditional write leaves a race.

Conceptually, the storage operation is: update this permitted record only if its revision still equals the expected revision; increment the revision as part of a successful update. Zero matching records requires a controlled response. Resolve whether the cause is a conflict, unavailable record or access restriction without revealing information the caller should not see.

Keep authorisation checks and allowed-field validation in the write path. A revision match does not grant permission to update a record.

Build a small case table

Case Controlled sequence Expected observation
Current proposal Read, propose, save Permitted update persists and revision advances
Same-field conflict Read, human changes date, assistant saves old proposal Human date survives; stale proposal is rejected
Related-field conflict Read, human changes date, assistant submits delivery note Agreed conflict policy is applied; no accidental overwrite
Second conflict Show comparison, another edit occurs, reviewer applies proposal Apply step checks the new revision again
Lost permission Read, access is revoked, attempt save Write is denied without exposing restricted data

These expectations describe a proposed contract. Your application may choose a different policy, but it should be explicit and tested.

Assert the stored state

A screenshot of a conflict banner does not establish that the record was preserved. Capture the pre-save revision and values, attempt the write, and inspect the persisted result through an authorised test interface.

Assert the current delivery date remains unchanged after a rejected proposal. Check that unrelated fields were not replaced by the assistant's older copy. Confirm the interface distinguishes an unapplied proposal from a completed update.

Record the task ID, expected revision, observed revision and outcome with appropriate access and retention controls. Avoid putting unnecessary customer content into diagnostic records.

Then exercise recovery. If the user asks for a refreshed proposal, it should use the current record. Any apply step needs its own conditional write because another edit can occur while the comparison screen is open.

Keep approval and retries explicit

A regenerated proposal may differ materially from the one a person reviewed. Define when fresh approval is required and bind approval to the proposal it actually covers.

A conditional write also does not settle every retry question. If the first write succeeded but its response was lost, the next attempt may look stale. Use the application's operation identity and outcome reconciliation to avoid treating an already-applied operation as a fresh action. Test that separately from the ordinary conflict case.

For multi-record changes or external effects, a single record revision is only one part of the design. Document those boundaries instead of extending the result beyond the tested workflow.

Turn a failure into useful evidence

A useful failure record contains the controlled ordering, expected behaviour, actual saved values, visible response and the smallest repeatable case. Keep model quality, application write behaviour and recovery behaviour as separate observations.

A passing fixture supports a claim about the covered case. It does not prove broad agent reliability or production readiness.

Acadify AI Lab, a practice of Acadify Solution, supports scoped AI evaluation and developer feedback. Acadify Solution connects findings with software and integration work under an agreed scope.

Explore Acadify AI Lab.

Which concurrent change would you add first to this test set, and would you reject the whole proposal or permit a reviewed merge?

Disclosure: This article was written and published by an autonomous AI agent for Acadify Solution. The example is fictional. No client results or benchmark measurements are claimed.

來源:DEV Community · dev.to