让反馈循环保持紧凑

你越快能看到一个改动是否有效，你和 AI 就越快收敛到正确的东西上。一个缓慢的循环——你要等上几分钟才知道有没有搞坏什么——会悄无声息地把每一个错误成倍放大。

• 让"跑起来"变成一条命令。npm run dev、make test，无论是什么，把它记在你的上下文文件里，这样 AI 也能跑它。
• **依靠快速的测试。**哪怕只有少数几个单元测试，都能给 AI 一种验证自己工作的方法，而不用你盯着。
• **使用 linter 和格式化工具。**它们能瞬间抓住一整类错误，并把风格之争挡在你的审查之外。
• **把错误回传给 AI。**当出问题时，把真实的错误信息贴回去。具体的反馈产出具体的修复；"它不工作"只会产出猜测。

AI 工作空间的各个部件构成一个相连的循环——智能体编辑仓库，编辑器和语言服务器报告问题，终端运行代码，而每一个结果都流回智能体：

        ┌──────────────────────────────────────────────┐
        │                                               │
        ▼                                               │
   ┌─────────┐     编辑       ┌──────────┐    运行   ┌──────────┐
   │  代理   │ ─────────────▶ │  编辑器  │ ────────▶ │   终端   │
   └─────────┘                └────┬─────┘           └────┬─────┘
        ▲                          │                      │
        │                          ▼                      ▼
        │                    ┌──────────┐           ┌──────────┐
        │                    │   LSP    │           │   REPO   │
        │                    │  (错误)  │           │  (提交)  │
        │                    └────┬─────┘           └────┬─────┘
        │                         │                      │
        └─────────────────────────┴──────────────────────┘
                          反馈回流

这个想法最深的版本，是让 AI 自己把循环闭合。与其由你来运行命令、读取失败、再转述回去，不如给智能体权限，让它在每次改动后运行测试和类型检查器，并对自己看到的东西做出反应。循环于是变成：编辑、运行、读取失败、修复、再运行——全程没有你卡在中间。你的角色从信使转为导演：你设定目标和护栏，然后看着循环转起来。当 AI 能够编辑、运行、看到失败、并自行修复时，你就建好了一个能干真正活儿的循环，而你稳坐导演椅。