为什么现在值得关注
“让 Agent 记住项目”听起来像是把所有聊天记录、会议纪要和历史决策都喂给它。但实际使用中，记忆越多不一定越好。旧规则、过时方案和互相冲突的偏好，会让 Agent 在关键时刻无法判断哪条信息优先。
一个真正有用的项目记忆，应该像办公室门口的值班手册：短、稳定、随流程变化而更新。它不负责讲完整历史，只负责告诉下一位协作者哪些约定不能忘、从哪里开始检查、出现问题该找谁。
核心观点：记忆应该服务于下一次决策
判断一条信息是否值得写进 Agent 的短卡片，可以问一句：“如果下次没有这句话，Agent 会做出不同的决定吗？”如果答案是否定的，它更适合留在归档资料，而不是每次都进入上下文。
短卡片最适合保存四类信息：目录和命名规则、测试或发布入口、不能触碰的边界、已经验证过的常见坑。临时需求、客户偏好和本轮目标应该放在任务卡里，最终事实则回到代码、数据或正式文档中。
真实场景：把项目说明压缩成一页
一个前端项目可能有几十个页面、多个脚本和一套不完全统一的历史组件。新人接手时常见的做法是复制一大段聊天记录，结果 Agent 读了很多背景，仍然不知道应该先运行哪个命令。
更有效的短卡片可以只保留：
- 入口：应用从
src/main.ts启动，页面路由在src/router/index.ts。 - 样式：优先使用
src/style.css的 token 和已有.btn类，不新建相近颜色。 - 验证：提交前运行
vue-tsc -b和npm run build。 - 边界：不要修改套餐价格、登录地址和公开 API 行为。
- 常见坑：SSG 页面必须确认动态路由被纳入
includedRoutes。
这张卡片不替代项目文档，它只是 Agent 每次进入任务时的方向标。随着仓库变化，卡片也应该像代码一样被 review，而不是一年不更新的“说明书”。
分步骤实践：建立一张会工作的短卡片
先收集重复出现的判断
翻看过去三到五次任务，找出 Agent 或新人反复询问的内容。不要把所有答案都抄进来，只保留那些会导致不同实现路径的规则。
给每条规则加来源或验证方式
“必须使用这个颜色”不如“颜色来自 --blue，在 src/style.css 定义”。规则有来源，过期时才知道应该去哪里更新。
把卡片按稳定程度分层
不常变化的项目结构放在顶部；经常变化的发布命令或负责人放在底部。对于容易过期的信息，写出最后确认日期，避免 Agent 把旧事实当成永久规则。
每次流程变化顺手更新
把更新短卡片放进重构、迁移和发布的完成清单。比起每季度安排一次“大整理”，在规则变化的那一刻更新更可靠，也更容易找到变更原因。
可复制的短卡片模板
# Agent 项目短卡片
## 先看哪里
- 应用入口：
- 路由入口：
- 核心数据/内容入口：
## 稳定规则
- 命名和目录：
- 样式与组件：
- 不可改变的边界：
## 如何验证
- 类型检查：
- 构建命令：
- 真实浏览器检查：
## 已知坑
- [问题] / [避免方式] / [最后确认日期]
常见失败与修正
第一种失败是把短卡片写成百科全书。卡片越长，团队越不愿意维护，Agent 也越难找到重点。遇到内容不断增长时，优先把解释移到独立文档，只在卡片里保留链接和一句决策规则。
第二种失败是记录个人偏好，却没有说明适用范围。“我喜欢这样写”不等于项目约束。把个人习惯标成可选建议，把真正影响兼容性、数据安全和发布流程的规则单独列出。
第三种失败是只更新卡片，不更新事实来源。短卡片不能成为代码和正式配置的第二个真相。它应该帮助 Agent 找到真实来源，而不是复制一份可能逐渐漂移的配置。
今天可以试
- 找出团队最近反复回答的三个问题。
- 将它们改写成带来源的决策规则。
- 删除不会影响下一次决策的背景段落。
- 把短卡片放进仓库，并在下一次任务中让 Agent 先阅读它。
来源与延伸阅读
本文结合 GitHub Copilot 的公开开发者资源和团队协作实践整理，重点讨论项目上下文的维护方法，不代表 GitHub 官方对本文全部观点的背书。