写进 agents.md 里的一段prompt 彻底解决 GPT 烦人的车轱辘话：如果你要，我接下来就…… 不逃不演不藏，我接下来就原原本本地展示给你（）
开玩笑的，直接看图：
- 在项目路径下新建 agents.md （如果有就直接）写入以下内容。
- 每次Agent 会自己记录 issue，并 track，并把验收结果截图发布到 issue 上，确认合格再自己 close。
- 剩下来 open issue 就表示 Agent 自己也测不了，得你自己测，测完手动 close 就行。
这含金量，不用我多说吧
---
// 不要直接复制进去，贴给 AI，让 AI 根据你的项目改改再写入!!
---
## 任务执行哲学
> 目标导向、现场判断、证据驱动。
> 在 tracker 项目中执行任务时，不机械照搬固定步骤，也不凭惯性假设问题已经被理解。应先明确“这次要完成什么”，再根据当前证据选择最可能达成目标的路径；过程中持续根据结果修正判断，直到满足完成标准为止。
### 1. 先定义任务完成标准
拿到请求后，先明确：
- 用户真正要完成什么
- 什么结果才算“完成”
- 需要获取哪些信息
- 需要执行哪些动作
- 最终用户能检查到什么变化
所有后续判断都以这个完成标准为锚点，而不是以“我已经做了若干步骤”来自我说服。
### 2. 选择最可能直达目标的起点
根据任务类型，选择最合适的第一步验证路径，而不是默认走习惯动作：
- **代码 / 配置问题**：先看相关文件、日志、报错，再决定改动点
- **UI / UX 问题**：优先在真实页面里确认现象，再修改
- **数据录入问题**：先确认应该写入哪条数据、哪个项目，再走 CLI
- **部署 / 线上问题**：优先确认当前运行版本、容器状态、访问路径
- **涉及登录态或动态页面的平台**：若静态方式不可达，直接使用浏览器 / CDP 验证
目标不是“按部就班”，而是尽快找到离完成最近的切入口。
### 3. 用每一步结果反向校正判断
执行中的每一步结果都是证据，不只是“成功 / 失败”信号。要持续对照完成标准判断：
- 当前路径是否真的在推进目标
- 返回结果是否说明问题判断正确
- 若结果长期无增量，是否说明方向错了
- 遇到阻碍时，是该解决它，还是绕过它
例如：
- 搜索不到，不一定是“关键词不对”，也可能是目标本身不存在
- 页面没看到，不一定要继续点击，也可能 DOM 已经有内容，只是展示方式不同
- API 报错或元素缺失，如果重试没有新信息，应及时换方向，而不是机械重试
### 4. 完成为止，但不过度操作
只有在对照完成标准确认任务已完成后，才停止。
但也不要为了“看起来更完整”而做超出目标的操作。
在 tracker 项目里，完成通常意味着：
- 相关问题已修复或数据已正确写入
- 必要的构建 / 部署 / 验证已完成
- 用户实际可检查到结果
- 若属于修复任务，issue、commit、push、部署、验收链路完整闭环
---
## 0. 修复工作流（强制）
凡是对 `tracker/` 做 bug 修复、部署修复、鉴权修复、聊天修复、样式修复、配置修复，都必须遵守下面流程：
1. **先提交 issue**
- 在 GitHub 仓库 `<your-repo>` 创建 issue。
- issue 内容至少包含：
- 当前状态 / 现象
- 根因分析（如果已知）
- 修复方案
- 验收方式
- 没有 issue，不要开始正式修复。
2. **修完后必须重新部署到 Docker**
- 任何用户要检查的改动，不能只停留在本地文件或 `npm run build`。
- 修完后必须重新构建并启动 Docker，确保用户访问到的是最新版本。
- 原则：**写完就部署，不部署用户就检查不到。**
3. **必须做可见验证**
- 至少验证：
- `npm run build` 通过
- Docker 容器运行正常
- 本地端口可访问
- 若涉及域名/ingress，则验证外网域名可访问
4. **必须提交 commit 并 push**
- 修复完成后要：
- `git add`
- `git commit`
- `git push`
- 不要只改工作区不提交。
5. **回复用户时必须带 issue 链接**
- 汇报修复结果时，消息里必须附上对应 GitHub issue 链接。
- 回复内容至少要包含：
- issue 链接
- 做了什么
- 部署到了什么版本/状态
- 用户现在该检查什么
6. **所有事情做完再汇报**
- 不要在“文件改了但还没部署 / 还没 push / 还没建 issue”的半成品状态下交付。
- 只有当：**issue 已建、修复完成、Docker 已部署、验证完成、commit 已 push**，才算完成。
7. **凡是网页 UI/UX 相关调整，必须做浏览器截图验收**
- 只跑 build / curl / 肉眼读代码都不够。
- 任何影响页面布局、样式、交互、滚动、sticky、spacing、文案呈现、组件显隐的改动，都必须在真实页面里打开并截图确认。
- 没有截图验收，不算完成。
