经常看到有人说，用 Coding agent 写了一下午，最后人先累趴了，成果却没多多少。我自己的体验也差不多，试着把原因捋了一遍，也分享一下我正在做的开源 AI 助手 Pot。

先说最直白的部分：总有一些重复的小习惯要不断提醒 AI。

比如我会要求它在单独的 worktree 和 branch 里开发，每次开始前先让 main 分支同步 upstream，测试完成后再 open pr。Codex 能记住这套流程，下一次通常会照着做，但换会话，或者上下文压缩之后，偶尔又不记得了。现在 Codex 已经把新建 worktree 放进打开会话的流程里，worktree 这个问题算是缓解了，其他细节还是得每次重新交代。

这种事人来判断可能只要几秒，反复提醒却挺消耗耐心。后来我把一些明确场景写进 AGENTS.md，能解决一部分。非个人项目就不太方便直接改这个文件，我暂时也没找到特别顺手的处理方式。

另一个问题是需求没对齐。

每个人理解需求时都会带上自己的品味、知识和最近在想什么。以前常见的老板站在设计师后面指挥，按钮往左挪两个像素，现在看起来很像人在指挥 AI 干活。最后还是要把细节和 AI 对上。

我的做法是，开始前只对齐概念，尽量少在细节上来回拉扯。

比如做 agent 连接系统和 context 时，我会让它参考 Codex，再结合项目需求生成一张 ASCII 架构图，然后先根据架构图确认方向。做 UI 会更直接一点，让 agent 参考具体 app 的界面。我个人觉得，如果目标是做出有自己想法的东西，参考界面本身没必要背太重的心理负担。

至于代码没生成到想要的样子，我现在尽量不追着每一行代码改。

Pot 的开发流程是先用架构图对齐，让 AI 完成后自动 open pr，并在 pr 里附上具体实现的 ASCII 架构图和 UI 截图。这样我看 pr 介绍和截图，基本就能判断方向有没有跑偏。架构图没大问题就直接合并，偶尔扫一眼代码。遇到细节不对，再让 AI 解释并修改。

这套方法放在个人项目里还算省心。公司项目如果对代码质量有硬要求，人工核对还是躲不开。至于怎么把代码质量往上拉，我现在的懒办法是等新模型出来，再让它重构一遍。

我做 Pot 时总结出的想法有两点：人的介入尽量停在高层，只看结果，不要每个细节都亲自盯。让 Agent 慢慢记住用户的偏好，把能处理的事情多接过去。

用什么 agent 或 harness 都能做类似的事，但我想按自己的理解做一个 AI 助手，所以 Pot 就围绕这两点来设计。

目前我比较看好助手这种形式。聊天是异步的，没需要用户介入时可以先放着。助手又是持续会话，用户反复交代的习惯能慢慢沉淀下来，记忆也可以从对话里提取。

自动化也比较适合放进助手里。比如做一个负责项目运维的助手，每天检查线上服务日志里的异常，自动打开 Issue，再启动几个任务去排查和修复，修好后开 Pr。另一个开发助手负责 review，通过后自动合并和更新部署。助手之间的沟通、定时任务和代码托管服务的通知，都由 Pot 接起来，具体该做什么交给助手判断。

这里会用几个不同的助手。每个助手长期维护自己的会话，用户指令和习惯会留在对应的记忆里。一个助手只负责一个场景，上下文里也不会塞进太多无关内容。

Pot 的起因来自 ChatGPT Dot。Dot 让我感觉，现在的模型已经能支撑比以前更实用的 AI 助手了。可能又要回到养小龙虾的日子，只是这次希望它能替我盯住那些重复的活。

用 Agent 写代码，为什么还是这么累？顺便聊聊我做的 Pot