📢 แจ้งเตือน: leopold man/article/details/

本文聚焦于设计Agent驱动的前端确认流程，提出以差异清单为核心的状态机模型，明确划分‘建议—待确认—应用中—结果’四个阶段。强调差异内容（组件、属性、前后值）必须可核对，动效仅反映阶段而非结果，失败与部分成功需独立标识。指出Figma Specs用于协同说明变更范围，Web Animations API仅承担阶段可视化，不替代状态同步与原子性保障。

封面：待确认的设计差异清单与组件卡

让Agent一次修改十个组件，真正困难的未必是“确认”按钮放在哪里，而是用户确认的范围有没有在点击之前变化。预览看的是圆角，执行时却多改了颜色；这种错位再配上流畅动画，也只是更难发现。

10月Figma Specs把设计意图、引用与协作讨论放到同一画布，适合用来说明变更范围。这里进一步提出一条前端约束：确认针对的是一份具体差异清单，不是某个可能继续变化的任务。

先给出可核对的差异

清单应显示组件、属性、前值与后值，并允许打开相应状态。数量只能帮助估计影响面，不能替代差异内容。模型生成尚未结束时，可以显示建议草稿，但不要把尚会变化的内容直接送进应用阶段。

“建议—待确认—应用中—结果”是四个交互阶段。结果也不只有成功：部分失败、状态未知和已应用应逐项列出。下面内存样例让一项故意失败，用来检查显示逻辑，不模拟真实系统收益。

确认凭据绑定这份清单

保存为 confirm.mjs 后用Node运行。签名只是固定结构的规范化字符串，用于本地内容比较；它不是安全签名，也不承担鉴权。

import assert from 'node:assert/strict';
function signature(ops){
  const ids=ops.map(o=>o.id);
  if(new Set(ids).size!==ids.length)throw new Error('duplicate operation');
  return JSON.stringify(ops.map(({id,component,key,before,after})=>
    [id,component,key,before,after]).sort((a,b)=>a[0].localeCompare(b[0])));
}
async function applyConfirmed(ops, receipt, applyOne){
  if(!receipt.confirmed||receipt.signature!==signature(ops))
    throw new Error('confirm this exact change list');
  const result=[];
  for(const op of ops){
    try{await applyOne(op);result.push({id:op.id,status:'applied'});}
    catch(error){result.push({id:op.id,status:'failed',message:error.message});}
  }
  return result;
}
const ops=[
 {id:'a',component:'card',key:'radius',before:4,after:8},
 {id:'b',component:'button',key:'gap',before:8,after:12}
];
const receipt={confirmed:true,signature:signature(ops)};
let calls=0;
const result=await applyConfirmed(ops,receipt,async op=>{
 calls++;if(op.id==='b')throw new Error('teaching failure');
});
assert.deepEqual(result.map(x=>x.status),['applied','failed']);
await assert.rejects(()=>applyConfirmed(
 [{...ops[0],after:16},ops[1]],receipt,async()=>{}),/exact change/);
assert.equal(calls,2);
assert.equal(result[0].id,'a');
console.log('PASS: exact-list confirmation and per-operation results');

为了保持示例集中，这里把所有抛出错误记为failed。真实适配器遇到“请求已发出但结果查不到”时，应给unknown，不能因为本地超时就断言没有修改。也不能把部分成功自动回滚成“全部未应用”；那会掩盖实际产物。

前值比较应由有权写入的系统原子完成。前端凭据只能防止界面在用户不知情时更换清单，不能保证服务器没有并发写入。若应用阶段出现冲突，回到该组件的当前版本重新审阅。