用 Coding Agent 复盘 PR 评论，沉淀团队编码规范
Matt Pocock 分享可复用提示词：让 Agent 扫描团队 GitHub PR 评审评论，归纳更新 CODING_STANDARDS.md。
原始内容
Prompt of the day: /retro take a look at as many GitHub PR review comments as you have access to from my team. Create suggestions for updates to CODING_STANDARDS.md (breaking into multiple files as needed). Makes your PR comments inform the code going forward.
中文译文
机器翻译，保留原文供核对。
今日提示词： /retro 查看你所能访问到的、来自我团队的所有 GitHub PR 评审评论。为 CODING_STANDARDS.md 的更新创建建议（视需要拆分为多个文件）。 让你的 PR 评论为今后的代码提供依据。
深度解析
是什么：Matt Pocock 分享的一条“每日提示词”，核心指令是以 /retro 命令触发 Coding Agent，扫描团队尽可能多的 GitHub PR review 评论，归纳出对 CODING_STANDARDS.md 的更新建议，并在必要时拆分为多个文件。
核心设计：它构建了一个反馈闭环——代码评审中零散、一次性的意见，被系统化沉淀为长期生效的规范文档。Agent 扮演“知识萃取者”角色：读取历史评审 → 归纳共性规则 → 输出文档修订建议，实现“让 PR 评论指导未来的代码”。
关键洞察：工程团队的知识往往埋在评审评论里，新人看不到，时间久了作者自己也会遗忘。这条提示词把 LLM 擅长的长文本归纳能力，用在组织内部知识资产化上；“拆分为多个文件”则体现了 docs-as-code 的维护思路，避免单一规范文件无限膨胀。
边界与风险：效果依赖 Agent 能访问足够的私有仓库数据，涉及权限与隐私；Agent 可能过拟合个别争议性评论，把个人偏好写成团队规范；产出仍是“建议”，需人工审核后再合并，否则规范体系可能失真或冗余。
精选追评与案例
给出可操作的筛选门槛与规则过期管理方法。
I'd filter hard before it writes anything. A lot of PR comments are one reviewer's taste on one afternoon, and once they land in CODING_STANDARDS.md the agent treats that nitpick like law. I'd only promote stuff that came up 3+ times from different reviewers, and put a date on each rule so the stale ones are easy to prune.
中文译文 · 机器翻译
在它写任何东西之前，我会严格筛选。很多 PR 评论只是某位评审人在某个下午的个人品味，而一旦它们进入 CODING_STANDARDS.md，智能体就会把这种吹毛求疵当成法律。我只会把来自不同评审人、出现 3 次以上的内容提升为标准，并给每条规则标上日期，这样过时的规则就容易清理了。
补充规则溯源与排除单人偏好的具体机制。
@mattpocockuk worth adding to /retro: tag each suggested rule with the PR comments behind it, and skip anything only one reviewer said. otherwise CODING_STANDARDS.md ends up as one person's taste
中文译文 · 机器翻译
值得给 /retro 加上：给每条建议规则标注其背后的 PR 评论，并跳过只有一位评审人提过的内容。否则 CODING_STANDARDS.md 最终会变成一个人的品味。
指出标准需要同步淘汰，避免旧架构规则固化。
@mattpocockuk i think /retro should suggest rules to delete too. a review comment tied to the old architecture can be perfectly reasonable and still make a lousy permanent standard.
中文译文 · 机器翻译
我认为 /retro 也应该建议删除哪些规则。一条与旧架构绑定的评审评论可能完全合理，但作为永久标准却很糟糕。
提供无团队场景下复用该提示词的实操替代方案。
@mattpocockuk Solo, so no team PR comments to mine. I'd point it at my own code-review findings instead, those are literally my repeat mistakes. The standards file writes itself from where I keep slipping.
中文译文 · 机器翻译
我是单干，所以没有团队 PR 评论可挖掘。我会让它改为分析我自己的代码评审发现，那些正是我反复犯的错误。标准文件会从我不断出错的地方自动写出来。
给出已实际运行并处理大量评审线程的案例。
@mattpocockuk This is precisely what I did with the /retro command. It read over 500 threads and constructed a repository-specific coding standard pattern.
中文译文 · 机器翻译
这正是我用 /retro 命令做过的事。它读了 500 多个讨论串，并构建出一套针对特定仓库的编码标准模式。