Useful Things Agents Can Do That Are Not Writing Code

Useful Things Agents Can Do That Are Not Writing Code

AI 代理除了写代码之外的实用功能

The discourse is abuzz with the wonderful (and horrendous) things you can do when you allow an AI coding agent to write code. People who allow an agent (née clanker) to write all the code in an application are often called “vibe-coders”. This article is not about vibe coding. In fact, this article is about all the things you can do with an AI agent that are separate from writing code. 目前,关于允许 AI 编程代理编写代码所能带来的奇妙(以及糟糕)结果,讨论正进行得如火如荼。那些允许代理(即“叮当机器”)编写应用程序中所有代码的人,通常被称为“氛围编程者”(vibe-coders)。本文并非讨论“氛围编程”。事实上,本文旨在探讨除了编写代码之外,你还可以利用 AI 代理完成的各种任务。

With each of these, I’ll go through the use-case, then include the latest version of the pi prompt that I use. I do not believe you should use my prompts precisely. I am not suggesting that you copy my workflow. The beauty of many of these tools is that they are flexible and can be adapted to your style of work. I offer my prompts as inspiration. Maybe there are things you could be using an agent for that are not writing code. 对于每一个案例,我将先介绍使用场景,然后附上我所使用的最新版 pi 提示词。我不认为你应该照搬我的提示词,也不建议你完全复制我的工作流。这些工具的魅力在于它们的灵活性,可以根据你的工作风格进行调整。我提供这些提示词仅供参考,或许你也能发现一些除了写代码之外,适合使用代理来完成的任务。

Fix Merge Conflicts

修复合并冲突

I often find myself needing to fix merge conflicts for my PRs because either myself or an open-source contributor has modified the code upstream. Almost always, these conflicts are formatting or boilerplate changes that do not need my full attention. In other words, it’s the perfect job for a clanker. Here is my prompt: 我经常需要为我的 PR(拉取请求)修复合并冲突,因为我自己或开源贡献者修改了上游代码。这些冲突几乎总是格式化或样板代码的变动,不需要我投入全部精力。换句话说,这是“叮当机器”的完美工作。以下是我的提示词:

---
description: Fix a merge conflict in a PR.
argument-hint: "<PR NUMBER>"
---
I want you to fix the merge conflict in PR #$@. If I have not provided a valid number, please ask me for it. Do so by checking out the PR using the `gh` command, and perform the merge. DO NOT push your changes until I have a chance to review them myself.

In pi, I can call this like a function: /fix-pr-conflict #4222. It does not matter if I have the relevant PR downloaded and checked out. The clanker figures it all out non-destructively. 在 pi 中,我可以像调用函数一样调用它:/fix-pr-conflict #4222。无论我是否已经下载并检出了相关的 PR 都不重要,“叮当机器”会以非破坏性的方式处理好一切。

Locate Relevant Issues

定位相关议题 (Issues)

When working on open source software, I often prioritize fixing bugs that I find annoying and introducing features that make my own life better. That’s natural. When I do, I want to know if I am accidentally solving someone else’s problem at the same time. If so, I can link the issue in my PR description or reach out to the person directly. To find these relevant issues, I use this pi command: 在开发开源软件时,我通常优先修复那些让我感到困扰的 Bug,并引入能改善我自身体验的功能。这很自然。但在这样做时,我想知道自己是否在无意中同时解决了别人的问题。如果是,我可以在 PR 描述中链接该议题,或直接联系相关人员。为了找到这些相关议题,我使用以下 pi 命令:

---
description: Find any issues relevant to this branch or a given PR number.
argument-hint: "<PR NUMBER>"
---
Please locate all issues that might be relevant to the current branch (unless a PR number is provided below). Please list:
- If the issue is solved by this PR.
- The link to the issue.
- Who wrote it.
If not the current branch, look at PR #$@.

Again, this can be called like a function: /fd-issue. 同样,这也可以像函数一样调用:/fd-issue

GH Actions Failures

GitHub Actions 失败诊断

90% of the time a GitHub Actions workflow fails, it is not due to a bug. It’s because I forgot to run my formatter or my static analysis tools (think Prettier or tsc). In this case, it is not a piece of functional code that is broken, but an annotation or missing carriage return. It is an easy one-line fix. Why not make the clanker do it? When a GitHub Actions run fails, I can use an agent with the following prompt to get it fixed tout suite. 90% 的情况下,GitHub Actions 工作流失败并非因为 Bug,而是因为我忘了运行格式化工具或静态分析工具(比如 Prettier 或 tsc)。在这种情况下,损坏的不是功能代码,而是一个注解或缺失的换行符。这是一个简单的单行修复,为什么不让“叮当机器”来做呢?当 GitHub Actions 运行失败时,我可以使用带有以下提示词的代理来迅速修复它。

---
description: Diagnose any existing GitHub Actions failures for this branch.
argument-hint: "<BRANCH>"
---
Diagnose any existing GitHub Actions failures for this branch, unless there is a different branch provided below. Once you have taken a look to identify the possible underlying problem, offer a plan to fix it. Do not implement this plan without express approval. If not the current branch, look at $@

It can be run as a command inside of pi: /diagnose-action-failure. 它可以在 pi 中作为命令运行:/diagnose-action-failure

Wrap-Up

总结

I offer these prompts as inspiration. Are there things that you could automate? If so, please let me know! 我提供这些提示词仅供参考。还有哪些事情是你能够自动化的呢?如果有,请告诉我!