为什么我用一个 Git 仓库管理所有 AI 项目

做 AI 产品最容易死的方式,不是想法不够,而是想法太多——散落在十几个聊天窗口、几十段对话里,过两周,你自己都找不回来当初为什么那么决定。

我同时在推好几条产品线:高考志愿、学科提分、作文,还有一些工具和书。能不乱的唯一原因,是我很早给自己定了一条规矩:

不靠记忆管理项目,靠文件管理。

这句话听上去像句正确的废话。但它背后,其实是对"记忆"这件事的一次彻底不信任——既不信我的记忆,也不信 AI 的记忆。

记忆是会骗人的,尤其是和 AI 一起工作时

先说一个很多人没意识到的事实:你正在合作的 AI,几乎没有记忆。

每开一个新对话,模型基本都是从零开始的。上一次你和它吵了三轮、好不容易对齐的那套口径,那些"不能这么做"的禁区,那个最终定稿的 prompt——只要这段对话翻篇,它就忘得一干二净。你以为你在和一个"越来越懂你的助手"积累默契,其实你每次都在和一个失忆的天才,重新解释一遍。

举个我自己踩过的坑:有阵子我和 AI 一起,把某个学科教练的口径反复磨到很顺手——什么时候该追问、什么时候该拒绝、错题该怎么讲。磨完很满意,没存,觉得"我记得"。结果隔了一个多月想复用,翻遍聊天记录也拼不回那套完整口径,基本等于重做一遍。那次之后我才真正服气:没落进文件的"磨合",约等于没发生。

人的记忆也好不到哪去。两周前你为什么把那个专业从推荐里划掉?当时基于哪一版数据?你大概率只记得一个模糊的"好像有问题"。

所以当工作发生在聊天框里,它本质是写在沙子上的:看着热闹,潮水一过(对话关掉、上下文超限),什么都不剩。真正留下来的,只有你落进文件里的那部分。

一个总控仓库:让项目永远有一个"现在到哪了"

我的做法是,把所有项目放进同一个 Git 仓库当"工作台"。它不优先放业务代码,而是放这些东西:

每个项目当前的状态和优先级;
核心指令(prompt)的最终版,以及它是怎么一版版改过来的;
任务边界:目标、能改什么、坚决不能动什么、验收标准;
测试结果与交付物;
版本日志和操作记录。

这样,任何一个项目,我都能在同一个地方回答三个问题:它现在到哪了?下一步做什么?上次为什么这么决定?

第三个问题最值钱。一个决定的"理由",是最容易蒸发、也最贵的东西。把它写下来,等于给未来的自己(和未来那个失忆的 AI)留了一张可以回查的底牌。

为什么是"一个"仓库,而不是十个

有人会问:每个项目各开各的仓库,不更清爽吗?对我不行。因为我的几条产品线之间,共享了大量东西:一套学科类 Gem 的通用规则、一份"家长能读懂"的输出风格、一些反复用到的核查清单。放在同一个工作台里,这些才能被跨项目复用,而不是在每个项目里重新发明一遍。

更重要的是,当我想知道"我现在到底在做哪些事、各自到哪了",我只需要看一个地方,而不是在十个仓库之间反复横跳。一个工作台,给我一个"此刻的全貌"。

先把边界写下来,再让 AI 动手

我的流程是死板的三步:

先定义任务——在 issue 或 TODO 里,把目标、范围、禁区、验收标准写清楚。
再让 AI 执行——不让它自由发挥,它只能在我划定的边界里动。
最后人工复核——看有没有跑偏、改动是不是过大、要不要拆分重来。

很多人嫌第一步麻烦,上来就让 AI"先写个看看"。但这一步有个常被忽略的好处:把任务边界写清楚的过程,本身就是在思考。 当你被迫写下"什么不能动""怎样算做对了",你其实是在替这件事想清楚它到底是什么。写不清楚,往往说明你自己还没想明白——这时候让 AI 跑,只会跑出一堆看着像样、其实没用的东西。

AI 把"生成"变得几乎免费。于是瓶颈不再是"能不能写出来",而是"哪一份是当前的准稿、为什么是它、出了问题能不能退回去"。在一个生成过剩的时代,稀缺的从来不是产出,是出处和可回溯。

可能有人觉得这套很重。其实它很轻——核心就是 markdown 文件加 issue,不是上一套项目管理软件。重的从来不是工具,而是"把想清楚的东西写下来"这个动作本身。可这个动作你迟早要做;区别只是现在花十分钟写,还是两周后花两小时重新想一遍。

为什么这套对教育产品尤其重要

教育产品的容错率极低。一份高考志愿方案、一套作文提分逻辑,错了,是会落到某一个具体孩子头上的。

所以"可追踪、可复盘、可回滚",对我不是工程洁癖,而是对用户负责的最低要求。当一个家长照着我的方案做了决定,我必须能回答:这个建议是基于什么给的?哪一步可能错?如果错了,从哪里能纠回来?——这些答案,只可能存在于文件里,不可能存在于一段早就关掉的对话里。

把项目沉淀成资产,而不是留在聊天框里。这不只是为了我自己不乱,更是因为一句我越来越当真的话:

一个无法被回查的判断,不配落到别人的人生里。