正在加载陈远的个人网站

用会话复盘提示词提升仓库导航性以节省 Token

Matt Pocock 分享一条让编码 Agent 复盘近 10 次会话、改进仓库导航以节省 Token 的提示词。

提示词软件工程提示词技能代码库导航上下文管理会话复盘研发效能

原始内容

Matt Pocock@mattpocockuk

Prompt of the day: /retro read my last 10 coding agent sessions and find ways to make my repo easier to navigate. Find where agents take too long to find relevant information, or rely on out-of-date docs. Improving navigability is such an underrated way to save tokens.

中文译文

机器翻译，保留原文供核对。

今日提示词： /retro 读取我最近 10 次编码智能体会话，找出能让我的代码库更易于导航的方法。找出智能体在哪些地方花费太长时间才找到相关信息，或者依赖过时文档。 提升可导航性，是一种被严重低估的节省 token 的方式。

深度解析

是什么 Matt Pocock（TypeScript 社区知名教育者）分享了一条可直接复制的编码 Agent 提示词：通过 /retro 命令让 Agent 回读最近 10 次会话，找出仓库中 Agent 定位信息过慢、依赖过时文档的位置，进而改进仓库导航性。

核心逻辑 它把软件工程中经典的 retrospective（复盘）实践移植到人机协作场景：历史会话记录本质上是 Agent 在真实仓库中"迷路"的完整日志，回读这些记录能把隐性的导航成本转化为一份可执行的改进清单，形成"使用—复盘—优化—再使用"的闭环。

关键洞察 作者点出"提升导航性是被低估的省 Token 方式"——Agent 每次找不到文件、读错文档，都会消耗额外上下文与费用；而改善目录结构和入口文档（如 README、AGENTS.md）是一次性投入、长期摊薄的高杠杆动作。这也印证了"上下文工程"的趋势：与其反复打磨提示词措辞，不如优化 Agent 所处的信息环境本身。

边界与风险 /retro 依赖具体工具对会话记录的读取能力，跨工具未必可移植；10 次会话样本有限，可能遗漏低频路径；"导航性"判断也依赖模型主观评估，结论仍需人工验证后再落地。

精选追评与案例

  1. Matt Pocock@mattpocockuk · 查看追评

    原作者补充上一条相关提示词，便于串联阅读。

    Prev: https://t.co/FkgjYCP6VF

    中文译文 · 机器翻译

    前一条： https://t.co/FkgjYCP6VF

  2. Matthew Rowean@MRowean · 查看追评

    给出规则文件因导航缺失而失效的具体数据，以及分类地图加限量匹配的修复参数。

    @mattpocockuk The same problem hit my rules file. My /retro has written 394 rules for Claude Code. Only 18 were reaching the agent. The fix was navigation: a category map up front, then up to four matched rules per request. That took it to 298. 2:20 on what changed. Your /retro is in it: https://t.co/K9IW5qlZPR

    中文译文 · 机器翻译

    @mattpocockuk 同样的问题也击中了我的规则文件。 我的 /retro 为 Claude Code 写了 394 条规则。 只有 18 条真正到达智能体。 修复方法是导航： 前面放一张分类地图，然后每次请求最多匹配四条规则。这让触达数提升到了 298。 关于改了什么，2:20 处有说明。你的 /retro 也在其中：https://t.co/K9IW5qlZPR

    在 X 上查看原视频
  3. Rubén@enrub_en · 查看追评

    展示用 LLM 轨迹批量跑 /retro、沉淀半年复盘报告的实操方案。

    I pushed that even further. I have @0xSero’s https://t.co/nWV5BdDOMj project that collects LLM traces (Claude removes them after ~30 old ones or so). I wrote a script that runs the /retro pass on each conversation (previously cleaned of metadata). So I get a solid report of failures and improvements from the last 6 months, and I revisit it now and then to apply the recommendations that feel most meaningful to me.

    中文译文 · 机器翻译

    我把它又推远了一步。 我用了 @0xSero 的 https://t.co/nWV5BdDOMj 项目来收集 LLM 轨迹（Claude 大约在 30 条旧记录后就会删除它们）。 我写了一个脚本，对每个对话运行 /retro 流程（事先清理掉元数据）。 这样我就能得到一份关于过去 6 个月失败与改进的扎实报告，并不时回看，应用那些我觉得最有意义的建议。

  4. Stephen Rayner@stephen_rayner · 查看追评

    补充用 GritQL 检索冲突设计模式、避免智能体沿用旧模式的实操方法。

    Matt you should look at GritQL I use it and git so the agent can find design patterns in the codebase and conflicting newer design patterns. An LLM will often pick the older pattern that it sees more often than the new one. And GritQL makes it easier to find all occurrences of a design pattern (think of it as a more capable Regex).

    中文译文 · 机器翻译

    Matt，你应该看看 GritQL。我用它和 git，让智能体能在代码库中找到设计模式，以及与之冲突的更新设计模式。LLM 往往会选择它更常看到的旧模式，而不是新模式。GritQL 也更容易找出某个设计模式的所有出现位置（把它想成一个能力更强的 Regex）。

  5. Srijan Saket@srijanskt2 · 查看追评

    给出用 ai-context 与 STATUS.md 沉淀代码库上下文的具体结构。

    @mattpocockuk Maintaining tribal knowledge has been really helpful for me. I maintain an ai-context folder with a STATUS.md, capturing the latest repo status along with PR descriptions & design docs. https://t.co/INUHW5VBRI is an extension along the same dimension.

    中文译文 · 机器翻译

    @mattpocockuk 维护部落知识对我真的很有帮助。我维护一个 ai-context 文件夹，里面有一个 STATUS.md，记录最新的代码库状态，以及 PR 描述与设计文档。https://t.co/INUHW5VBRI 是同一方向上的一个扩展。