Application Legibility 是什么
文章原文这样定义它：
“我们的瓶颈从代码吞吐量变成了人工 QA 能力。我们通过让应用的 UI、日志、指标对 Codex 直接可读，来向 agent 增加能力。”
核心思想： Agent 在运行时能访问的信息，才真实存在于它的世界里。凡是需要人类中转的信息（截图给 agent 看、复制日志、描述 UI 状态），都是 agent 的盲区，也是人类注意力的消耗点。
Application Legibility 就是消除这些盲区，让 agent 能自主感知应用的状态。
OpenAI 的三层实施
层 1：UI 可读性
- 做法： 每个 git worktree 启动一个独立 app 实例
- 工具： 接入 Chrome DevTools Protocol (CDP)
- 能力： Agent 可以自己截图、读取 DOM 快照、导航页面
结果：
- Prompt: “复现这个 bug” → Agent 自己打开 app 操作
- Prompt: “验证 fix” → Agent 自己驱动 UI 检查
层 2：日志可读性
- 做法： 每个 worktree 有独立的临时可观测栈（worktree 销毁后自动清除）
- 工具： LogQL 查询接口暴露给 agent
- 能力： Agent 可以直接查询运行时日志
结果：
- Prompt: “确保服务启动在 800ms 内” → 可执行（agent 能看日志数字）
- Prompt: “确保这 4 个核心用户路径无 span 超 2 秒” → 可执行
层 3：指标可读性
- 做法： PromQL 查询接口暴露给 agent
- 工具： 临时 metrics 栈（per worktree）
- 能力： Agent 能查询性能指标、做回归判断
映射到当前项目（Lofty FE Harness）
| 维度 | 当前状态 | 覆盖度 |
|---|---|---|
| UI 可读性 | Playwright MCP 已集成（截图、DOM、导航） | 70% |
| Per-worktree 隔离 | Worktree 命令存在，但 dev server 不自动启动 | 20% |
| 日志可读性 | 无（agent 无法查看 Lofty CRM 运行时日志） | 0% |
| 控制台错误 | 无（需人工描述给 agent） | 0% |
| 网络请求 | 无 | 0% |
最大缺口
Per-worktree dev server 自动化。这是 UI Legibility 的前提——Playwright 能截图，但它看的是哪个 URL？需要先有一个正在运行的 app。
对这个项目的具体含义
当 agent 在执行 /ui-dev 或 /implement 任务时，理想状态是：
- Agent 开始任务
- 自动启动该 worktree 的 dev server
- Agent 用 Playwright 打开本地 URL 截图/验证
- Agent 读取浏览器控制台日志发现 JS 错误
- Agent 自主修复，无需人工”运行看一下”