先说清楚怎样算完成

完成需要证据

我越来越习惯在任务开始前说清楚怎样算完成。代码修改以后要跑测试，页面要看真实尺寸，资料要能追到来源，远端状态要和本地提交对得上。

这些检查听起来很基础，实际很容易被跳过。AI 能快速生成修改，也容易在看到文件变化以后宣布任务结束。验收标准提前写清楚，双方都会少走弯路。

排障也遵循同一件事

遇到故障时，我会先看真实版本、真实配置、日志、接口返回和最终输出。找到问题发生在哪一层，再决定改什么。

猜测可以帮助列出检查方向，不能直接当成结论。如果一个修复没有对应的状态变化、测试结果或可见输出，我不会把它写成「已经解决」。

把跑通的路径留下来

一次问题查清、修复并验证以后，我会把检查顺序和容易踩坑的地方记下来。复杂一些的写成 Skill，机械步骤写成脚本，短问题留一份复盘就够了。

这样做的目的很现实：下次再遇到相似问题，先走已经验证过、成本最低的检查路径。