给旧项目建一张能用的索引

记得以前做过一个类似的视觉效果，却想不起项目名、作者和文件位置。歸藏在第六期讲到，自己借助 Memory 找回这些线索，再让 Agent 判断能否复用，接着做出了 Demo。杨攀也提到，有时连在哪个 Agent 里讨论过都忘了。

乔木提出的设想是给项目建一张 Map：以后在一个入口说出需求，由 Agent 去找相关项目。要支持这种寻找，索引得能接住“以前做过一个什么东西”这种模糊描述。

先记用途，再给出能打开的入口

仓库名往往是临时代号，过一阵子连作者也未必能想起来。“视频里给物体画框”“把长录屏裁成竖屏”更接近再次使用时脑中的线索。可以保留正式名称，再加一句实际做成过的用途。

以一个虚构的图片画框组件为例，索引可以这样写：

“支持实时视频跟踪”如果只是当时讨论过的想法，就不要写进用途栏。索引用于寻找已经存在的东西，未来计划可以另外标注。

开始时挑几个近期还会使用的项目就够了。复用时发现目录搬了、启动命令过时，顺手更正；这些修正会直接减少下一次寻找的时间。

演示能运行的版本可能在实验分支里，主分支还没有相应功能。同一个仓库也可能有多个 worktree，目录相近但状态不同。

git worktree list --porcelain 可以列出工作目录、提交和分支，帮助核对它们的关系，格式见 Git 文档。它不能代替检查各目录当前的未提交改动，也不能证明项目现在可运行。准备复用时，还需要读当前说明、查看本地状态并启动相关入口。

如果索引写着某个提交跑通过，而现场已经往后改了几十次，可以先比较需要的部分发生了什么变化。这样不用在“相信旧记录”和“把全部项目重读一遍”之间二选一。

找回图片画框项目后，新需求也许只需要其中的坐标换算。先确认这段代码依赖哪些类型和配置，再决定复制小模块、抽成公共组件，或直接调用旧项目的接口。

整仓复制容易把原来的界面、部署设置和临时假设一起带走。一个小函数能独立使用，就没有必要为了它启动旧项目的全部服务。反过来，功能与原有数据关系很紧，也不宜强行拆成一个看似通用的工具。

复用完成后，在原条目补上新项目的位置和使用部分。下一次搜索“图片缩放后画框偏了”，Agent 就有机会找到最近修过这个问题的实例，而不只是最初的演示。