我对 Cursor 工作流所做的最佳改进
Source: Dev.to
tl;dr: 让编码代理访问运行时输出
我几乎可以肯定这并不新颖，而且我几乎可以肯定已经有很多人以某种形式在使用它，但它是我在本地使用 Cursor 进行 AI 辅助开发时最大的解锁点，而且它如此简单，我想分享出来。
如果你的编码代理看不到程序在做什么，它就无法调试
Cursor 并没有什么神奇的能力可以读取你机器上发生的所有事情。除非你显式地暴露输出，否则代理基本上是盲目的。
当我让它看到我的程序输出后，我发现它能够在大约 30 秒内解决原本需要我花 30 分钟才能解决的问题，从而把时间释放出来去处理创业的其他方面。
问题
我的本地开发环境有三个活动部件：
- 一个 Python FastAPI 后端
- 一个 React 前端
- 一个与 WorkOS 对接以实现身份验证的 Python FastAPI 授权路由
这三者都会产生日志，可能会独立失败，并且可能需要调试才能恢复运行。
Cursor 可以运行你要求的命令，甚至可以建议有用的命令，但它无法：
- 附加到你自己打开的终端窗口
- 读取实时的 stdout/stderr
- 监视热重载的服务器
- 神奇地看到浏览器的控制台日志
当代理尝试通过杀掉你正在运行的服务器或客户端来“修复”某些问题时，它会摧毁整个热重载设置，迫使你重新启动所有东西，严重影响生产力。
解锁点
编码代理的能力往往超出你的想象，有时最好的做法就是直接询问你所好奇的事情是否可行。曾有一次我问：“你能读取 screen 会话中的内容吗？”
令我惊讶的是，Cursor 回答说：
如果你运行
screen -X hardcopy，我就能读取输出。
随后我让 Cursor 使用 screen -ls 检查当前运行的 screen 会话，并获取服务器最近 50 行的输出。它做到了。
这让代理拥有了除代码之外的可观察对象。
我的实现方式
我使用 runnem，这是我为完全不同的目的构建的一个小工具：记住你的运行配置并让你在多个项目之间无缝切换。
它把每个服务都放在自己的 screen 会话中，这使得上述解锁成为可能。你也可以使用任何提供类似访问方式的工具：
- 独立的
screen tmux- Docker（日志文件或
docker logs） - 将日志写入磁盘文件
原理是通用的。
有了 runnem，Cursor 可以：
- 使用
screen -ls列出会话 - 辨认出后端和前端会话
- 将相关会话的输出转存到磁盘而不打断它们
- 在保持一切运行并准备好热重载的情况下分析日志
我的 .cursor/rules 片段
为了引导代理，我在 .cursor/rules 文件中加入了以下内容：
# Example command to fetch the last 200 lines of the backend logs
screen -S 94383.runnem-flow-myna-server -X hardcopy /tmp/backend_logs_200.txt && \
tail -200 /tmp/backend_logs_200.txt- 带有
-server后缀的 screen 是后端。 - 带有
-app后缀的 screen 是前端。
有时我仍会明确告诉代理“使用 screen -ls 检查日志”，这足以让代理进入一个循环，修复错误直到服务器重新运行。
需要 runnem 吗？
不需要。你可以使用任何你喜欢的设置。
Runnem 之所以让工作流非常轻松，是因为：
- 每个服务都有自己的命名 screen
- 我在两种语言之间运行了三个服务
- 代理需要交叉检查所有服务
- 所有服务都保持运行，热重载不受影响
我一直想找个机会实验 MCP，所以可能会尝试为 runnem 添加一个 MCP 工具，让 Cursor 能更直接地与之交互（例如，将“获取后端日志”暴露为单一工具调用）。目前，这个基于 screen 的简单设置已经足够。
最终结论
一旦你的代理能够看到程序的输出，它就会从：
基于猜测编辑文件
转变为更强大的：
响应现实
如果你在本地运行多个服务并希望代理能够发挥作用：
- 暴露输出。
- 给它视野。
这只是一个微小的设置改动，却彻底改变了我与 AI 的协作方式。
其他编码代理已经在这么做了吗？
我目前没有足够的时间去实验其他编码代理，所以可能已经有类似的内置设置，或者有办法让你进入相似的工作流。如果你找到让代理能够看到浏览器控制台日志的好办法，欢迎在评论区分享。
更详细的文章可以在这里找到：