Agent 返工少不下来，通常不是模型不够聪明

这次导航站改版里，最初反馈只有一句：站点卡片太大，上下留白多。它没有像需求文档一样写出 68 像素、五列网格和断点规则，却给出了截图与明确的不适感。第一步不该追问十个参数，应先打开页面，找出高度来自 padding、图标尺寸还是行高。

真正容易返工的是把主观感受直接翻译成一个孤立数字。卡片压低后，标题可能截断；列数增多后，右侧热门榜会被挤窄；搜索栏改完，下拉菜单又可能脱离输入框。一个视觉问题往往牵着三个邻居。

比“把卡片高度改成 64px”更有用的约束是：保留图标、标题和一行简介；2K 屏下提高信息密度；移动端仍可读；热门榜不被主列表覆盖。前者只控制一个 CSS 值，后者定义了修改边界。

任务描述可以短，但最好包含四项：读者能看到的结果、允许修改的区域、不能破坏的行为、验收证据。缺少某一项不一定失败，四项全没有时，剩余空白只能由执行者的审美填补。

为了写趣味网站推荐，我请求了站内网站接口。接口一次返回 315 条记录，完整 JSON 超过十万字符；文章真正需要的只是趣味分类的 19 条。把全部响应原样留在会话里，不会让判断更准确，只会让后续每一步背着无关数据。

更好的交接只保留：候选网站的 ID、名称、URL、访问结果和未确认问题。Claude Code 的子代理文档把隔离大量搜索与日志作为独立上下文的典型用途；关键在于只带回结论和证据，数量并不重要。

页面分析只需要读取和浏览；资料核验不需要生产环境密钥；文章渲染不应顺手发布。发送、删除、部署和修改权限一旦混在普通研究里，结果不仅更危险，也更难复盘。

同样地，不要把所有步骤都拆成子任务。卡片样式与页面验证高度耦合，交给同一条工作流更省交接；几十个互不依赖的网站核验才适合并行。拆分的目标是隔离噪音和风险，不是制造组织架构。

本次文章接入后，生产构建生成了 45 个页面，目标文章返回 200，HTML 里也能找到标题、封面和正文图片。这证明页面可生成、资源路径存在，却不能证明封面裁切好看、2K 屏字体清晰或下拉菜单能点击。

代码任务至少需要三层证据：静态检查或构建、目标路径访问、关键交互或视觉检查。内容任务再加来源核验和断链检查。OpenAI 的 Evals 指南强调用代表性任务和明确标准评估工作流；一次“看起来成功”不等于可以稳定复用。

如果结果不对，先判断是理解、实现还是验收失败。需求理解错了，补一张截图或一个反例；实现影响了邻近布局，缩小修改范围；构建通过但菜单点不开，就增加交互验证。不要把原提示复制一遍，再加一句“请认真一点”。

沿着证据继续工作，是这类工具最稳定的状态。给它一个能被观察的终点，通常比更多鼓励有效。