Agent 工作流：从调研到验证的闭环

Agent 可以很快，但没有边界的快，只会把问题扩散得更快。

一次可靠的 Agent 开发循环，应该从事实确认开始，经由计划拆解、模块实现、自动检查和视觉验收收尾。真正省时间的不是跳过步骤，而是让每一步都有可验证的出口。

我现在会把 Agent 当成一个 会写代码的协作者，而不是一个许愿池。你给它上下文、边界和验收标准，它才不容易把项目改成一堆看似努力的废料。

第一步是确认事实

Agent 最容易犯的错是听完需求就开始写。正确做法是先读项目：路由在哪里、样式在哪里、已有组件怎么复用、哪些文件已经有未提交改动。

如果是 Next.js 项目，我还会顺手对照 Next.js 文档 确认路由和构建行为，别靠记忆硬猜。

可以先跑这些只读命令：

git status --short
rg --files
rg -n "Callout|detail-body|article-row" app styles content

这些命令能快速确认变更边界。尤其是 git status --short，能避免把用户已有改动当成自己的垃圾一起卷进去。

事实确认的出口

• 明确要改哪些文件。
• 明确哪些文件不能碰。
• 明确当前页面怎么验证。
• 明确有没有现成模式可以复用。

第二步是拆成可验收模块

计划不需要写成论文，但每一步都要有出口。比如“改文章排版”太虚，“补 .detail-body 的标题、列表、代码块和 Callout 样式，并验证两篇 MDX”就能执行。

我会按这个顺序拆：

1. 数据或文件结构。
2. 页面或组件逻辑。
3. 样式和响应式。
4. 自动检查和浏览器验收。

第三步是把验证写进循环

实现完成以后，至少要跑项目自己的检查命令。对这个站点来说，常规组合就是：

bun run lint
bunx tsc --noEmit
bun run build

如果改的是视觉，还要打开浏览器看实际页面。工具输出通过只能说明代码大概率没炸，不能说明用户看见的页面舒服。

闭环才算完成

一轮 Agent 工作不应该以“我觉得好了”结束，而应该以“哪些检查通过、哪些页面验过、还剩什么风险”结束。把这个闭环固定下来，Agent 才能从会写代码，变成真的能交付。

闭环验收表

• 每轮先看 git status --short。
• 用 Enter 执行前复核命令范围。
• 把 剩余风险 写进最后回复。