有个场景我猜你肯定不陌生上午让 AI 改了一段排序逻辑当时它给的理由清清楚楚参数边界、性能考量、为什么不直接用现成库都说得头头是道。下午你继续写代码想按那个思路再改另一处发现上午的对话窗口已经找不到了翻遍 commit 历史也只有一句“modify sort”你对着代码看五分钟愣是想不起来当时到底在防什么坑。这其实就是“AI 改完代码下一次还能找到当时的依据吗”这个问题的真实写照。很多人把把自己被 AI 编程工具“带飞”之后遗留的混乱甩锅给模型记忆短但其实根子在于你压根没把“依据”当成工程资产去管理。代码是 AI 写的可决策是你拍板的如果下一次连自己为什么这么决定都问不出个所以然那代码就成了一堆没有来源的符号改起来迟早翻车。这篇文章不聊什么高大上的架构也不推销花哨工具就讲一套我在日常项目里反复验证过的保守做法。核心思路把 Git 当正文把 AI 对话当素材把需求约束当索引。看完你就能知道怎么让“当时的依据”像坐标一样随时能被翻出来。1. 先承认AI 辅助编码的“依据”天生容易丢1.1 AI 写代码的本质是即时生成不是项目记忆很多人误以为接入 AI 之后它就是你项目的“第二大脑”。实际用下来你会发现它更像一个随叫随到的外包工程师你给它上下文它给你产物你换一个会话窗口它就把上一轮当成从未发生过。这不是模型笨而是它的工作方式决定了“记忆”很廉价随时可以被新的上下文冲掉。模型在一个对话窗口里能记住你的需求、代码片段、甚至是你的偏好可窗口一关这段交互就成了无主数据。你当然可以把对话导出成文件但事实是项目代码库不会自动记录“这个函数为什么改成这样”AI 生成的 commit message 也常常只是“fix bug”这种废话。于是下一次接手时你面对的是改过之后的代码而不是改代码之前的决策现场。我见过更极端的案例有人在一个 Cursor 会话里让 AI 重构了三个文件AI 顺手改了一个公共函数的返回类型当时对话里写明了“调用方所有地方都已经适配过了”。两周后另一个同事接手只看到了函数的返回类型变了找不到任何依据于是改了一处老旧调用点结果运行时炸了。不是代码写错是当时那句“已经适配过”没有落到仓库里成了隐形负债。1.2 丢依据的三个典型环节结合我自己多次踩坑和观察团队里的场景“依据”丢失通常发生在下面三个环节第一需求输入阶段。原始需求描述是一堆散落在微信群、工单、口头沟通里的自然语言你把这些提炼成 Prompt 喂给 AI 之后原始描述就被丢弃了。AI 按照它的理解完成了代码但你的理解、AI 的理解、实际情况三者之间可能存在偏差偏差只存在于对话上下文中。第二修改决策阶段。AI 给了两套方案你选了 A理由是“A 对现有测试影响小”。这句话不会出现在最终代码里也不会自动出现在 commit message 里除非你主动写。项目里的每个人最后只会看到 A 方案的结果下一次有人想换 B 方案时根本不知道该拿什么当权衡的出发点。第三迭代关联阶段。这次 AI 改动的代码影响了另一个模块的正常运行你让 AI 又做了一次修复这次修复是基于“上一轮改动的副作用”才做的。但代码历史里只记录了两条独立的 commit你找不到“第二轮修复是为第一轮补锅”这种关联关系。于是一个带着因果链条的决策被拆成了两个孤立的片段。只要这三环里有一环没落到可检索的地方下一次就基本等于从零开始猜。2. 把“依据”当业务输入管理而不是零散聊天2.1 把需求描述变成可引用的编号先别急着教 AI“怎么写代码”先教自己“怎么描述问题”。我现在的做法是所有 AI 改动任务开工前先建一个短编号。比如在项目根目录的 docs/decisions 文件夹下建一个编号文件或者直接在项目工单系统里创建一个高优先级任务。编号规则很简单202505-A-001这种就行关键是这个编号能在整个工作流中被反复引用。为什么要这么做因为 AI 会话是易失的而编号是稳定的。你把需求描述、验收标准、已知约束写进这个编号对应的文档里然后在 AI 对话里直接说“按编号 202505-A-001 的需求改”。改完之后commit message 里带上编号代码注释里也可以带上编号下次任何人看到这段代码都能顺着编号找到完整的需求依据。空口说白话不容易坚持这里分享一个我常用的模板--- AI 改动任务202505-A-001 - 需求列表页的筛选条件需要支持多选 - 验收标准选中多个条件时 URL 参数用逗号连接 - 已知约束不能破坏现有的单选 URL 兼容逻辑 - 关联文件src/views/ListPage.vue, src/utils/filter.js - 期望方案...这份文档不是写论文只是让 AI 和未来的你都能明确“这一次改动到底要满足什么”。你可能会觉得多一步很麻烦但一次多花两分钟能省掉后来两天排查“当初到底想要啥”的时间这笔账划算得很。2.2 让 AI 的决策过程有“文件落点”在实际操作中我发现一个特别好用的习惯当 AI 提出两套及以上方案时不要只在聊天里追问把它整理进同一个决策文件里。比如在任务文档末尾加一段“方案对比”把 AI 给的方案摆在上面再把你选择的理由写清楚。这段内容不需要写多长两三段话足够。但它的价值很大下一次你或者别人看到 git blame发现某行代码是从 A 方案来的就可以回去看“为什么不选 B”而不用对着代码猜。至少我这段时间实操下来凡是做过方案对比记录的功能后续维护时基本都能快速定位方向不会陷入“这代码怎么这么丑但是好像又能跑”的纠结。有人说这太啰嗦AI 都替你干了你还记笔记干嘛问题是 AI 不背锅啊。代码上线之后出了问题系统不会报错说“这是 AI 的决策”只会说这里逻辑不对。没有依据记录的代码就是裸奔的代码AI 只是加速器加速你奔向未知。2.3 为 AI 会话做“快照”凭心而论做到前面两点已经超过不少人但还有个更隐蔽的坑同一段代码可能在不同时间、不同会话里让 AI 改过好几轮。你这次改完觉得没问题三个月后同样一个函数另一个需求又来了你顺手让 AI 继续改发现它给出的方案跟三个月前完全不一样——因为新的对话里没有三个月前的决策痕迹。所以我现在养成了一个习惯每当改动达到一个稳定状态比如通过了本地测试就立刻把当前对话里最关键的几段 Prompt 和 AI 的关键回答复制到一个 txt 文件里放到仓库根目录的.ai-contexts/文件夹下文件名用任务编号 日期命名。这不优雅但非常有用。这个文件夹我通常会用 .gitignore 排除掉不强制提交到仓库但会同步到团队内部网盘或 Notion 里。为什么不大张旗鼓提交进仓库因为大部分 AI 对话内容噪音很大真正有保留价值的只有那几段提交进去反而污染仓库。你需要的是“快照”不是“录像”。3. 在 Git 历史里埋下“依据”的坐标3.1 Commit Message 要写“为什么”而不是“改了什么”这是老生常谈可当引入 AI 之后这个要求反而被很多人放弃了。AI 工具写 commit message 的能力很强但它擅长的只是“根据 diff 描述改了什么”真要它写出“为什么改”还是得有人的判断。你直接用 AI 的默认 message大概率得到的是fix: optimize sorting algorithm这种信息量基本为零。我要求自己在 AI 辅助代码落库之后手动重写 commit message至少包含触发这次改动的需求编号如果有的话为什么选择现在这种方式有没有进一步补充说明比如这样fix: 优化排序逻辑支持多级字段 依据任务编号 202505-A-001原排序在二级字段缺失时抛异常 方案切换到稳定排序算法保留原始顺序作为回落 注意依赖 custom-compare 函数的调用方需同步检查这样一来git log 里每一行都不再是干巴巴的状态流转而是一条有迹可循的项目播报。下次你想找“当时给这个排序加回落机制的原因”一条 git log 就定位到了。这比翻 AI 聊天记录高效得多。3.2 用关联编号对抗“多文件改动”AI 改动常常横跨好几个文件光看 commit message 还不够最好在改动文件的关键函数顶部留一行简短注释比如// 依据: 202505-A-001。不要小看这行注释当代码量大了之后git blame 很难追到 Reason因为 blame 通常只告诉你当前这一行最后是谁改的并不会告诉你“为什么这个函数被拆成两半”。带编号的注释相当于给代码装了一个外挂导航。你可以在 IDE 里全局搜索202505-A-001立刻就能列出所有受这个任务影响的文件比任何可视化依赖图都好使得多。而且搜索是零成本的任何编辑器、终端都支持。有人担心注释污染代码整洁度。这个担心可以理解但我建议你把这种注释视作“契约标记”它本身也是架构的一部分。一个函数如果经历过超过两次 AI 修改且没有依据标记那它本身就是需要治理的技术债标记只是把债标出来不是把债藏起来。3.3 把 AI 参与的变更单独标记出来团队协作时最好统一一个 commit 类型前缀比如在 Conventional Commits 基础上加一个ai:类型。我目前的习惯是feat:功能改动fix:修复refactor:重构ai:表示这个 commit 的重点是“基于 AI 辅助做出的关键决策”ai:类型不意味着这不是人写的代码而是提醒后来人“这里可能有超出常规模式的决策路径”。比如 AI 建议把某个循环改成递归这个决策的主观性较强就需要额外留意。实际使用中我还会在ai:commit 里顺带贴一段简短的对话摘要通常是几行文字说明当时的关键词、约束条件。比如ai: 用递归改写目录树遍历 依据任务 202505-A-003树深度实测未超过 50递归内存可接受 注意目录数可能膨胀后续可考虑迭代式这么做的另一个好处是方便统计 AI 在项目里的实际贡献。你用git log --grep^ai:可以看到 AI 辅助决策一共有多少条多数情况下能帮你在周报里说清楚价值也能让你意识到依赖是否过重。4. 可落地的工作流一套实战过的一站式流程4.1 动手前 Checklist先建索引再写代码很多人在“让 AI 改代码”之前压根没想过先做一个检查清单。直接打开 IDE把功能代码一并抛给 AI让 AI“帮我看下这段代码怎么优化”然后 AI 就会在一大段模糊需求下自由发挥。这样产出的代码即便是对的依据也几乎为零。所以我在项目里强制自己过下面这套 checklist是否已有一个可引用的任务编号当前问题是否描述为“现象 预期行为 约束条件”是否已确定需要改动的文件清单是否了解现有测试覆盖情况本次改动是否存在两套以上可选方案如果有是否已经想好选择标准看起来像项目经理在催你补文档但这套清单能最大限度地防止“AI 自由发挥跑偏”。跑偏的代码比不改更危险因为你要么得花时间重新掌握它的逻辑要么直接回滚但 AI 会话里的一切都烟消云散你就只能靠内存去回忆原始需求。4.2 让 AI 修改代码的五个实操步骤我标准化之后的流程大家可以照着试第一步写清楚问题背景。不要只说“帮我优化这段代码”至少要讲清楚这是哪个业务场景、现状是什么、期望达到什么效果。如果你给的信息含混AI 就会用自己的上下文补充而它补充的那些假设不会留在你的代码库中。第二步把约束条件列全。比如“不能改变公开 API 的签名”“必须兼容 IE11 这样的场景就不用提了框架已经不支持了但如果你真的依赖旧浏览器就得写进约束”。约束越具体AI 的改动越可控后续你追溯的依据也就越实质。第三步要求 AI 先给方案不急着写代码。我通常会这么问“先不要直接改代码给我两个可能的方案并说明各自的成本和风险。”这能逼着 AI 把它内部推理的过程外显出来你留在记录里的人手动判断也就有了依据。第四步确认后再让 AI 动手。很多人的误区在于觉得 AI 改完代码就结束了其实你应该再让它做一遍“变更摘要”也就是列出它到底改了什么文件、什么函数、为什么改。这份摘要直接可以作为你写 commit message 的素材。第五步把摘要固化到文本里。打开任务文档先把摘要存下来然后写 commit 时带上任务编号和摘要要点。整个过程五分钟但它的价值能持续存在三个月以上。4.3 第二天如何找到依据一个实际场景假设第二天你打开项目发现昨天让 AI 改过一个文件但你已经记不清当时为什么要把一个函数拆成三个内部函数。如果按照上面的流程你至少有三种方式找回依据在 IDE 里搜索任务编号立刻定位到相关文件和注释。查看 git log 里任务编号对应的 commitcommit message 里写了当时方案对比和风险考虑。如果没有编号则搜索.ai-contexts/下对应日期文件找到原始的 Prompt 与 AI 响应片段。这三条路径不需要你记住任何细节你只需要记得任务编号或者大概日期。哪怕两样都忘了你还能用git log --diff查看那个文件的修改记录再顺着改动时间反推任务文档。相比以前“翻聊天记录找半天找到了发现只是问了个 Hello”这个体验要好太多了。5. 常见问题与排查技巧实录5.1 你可能已经踩过的四个坑问题现象根因排查思路你问 AI “上次怎么改的”它答不上来新会话不携带旧上下文依赖 Git 历史 任务编号别指望模型记住约定commit message 写的是“fix bugs”AI 自动生成的信息不含决策原因手动补写“为什么”至少要有关联编号同一个函数让 AI 改一次就翻一次车每次对话输入的需求不一致建立稳定任务文档复制粘贴同样的约束再扩充增量部分代码里找不到当初的边界条件处理需求约束没有被写在代码或注释里关键分支注释里加一行依据编号下次全局检索这张表几乎涵盖了 AI 辅助编码落地时最常见的“失忆”情况。重点是搞清楚AI 对话不是存储系统只有文本文件、Git 历史、任务系统才是稳定存储。5.2 踩过坑之后我修正的两个使用习惯第一个习惯修正不再让 AI 在同一个会话里连续处理多个不相关的任务。以前我经常把“优化 A 函数”和“修复 B bug”全放在一个对话里AI 确实都能干但最后记录的时候两个决策混在一起commit 都无法单独拆分。后来我强制自己一个任务开一个新会话如果中途换了需求宁可先总结上一段内容再开新的。第二个习惯修正每次让 AI 修改一个有测试覆盖的函数前后我一定会跑一遍关联测试并把测试结果通过/失败记录到任务文档里。为什么因为测试结果就是“下一次能不能找到依据”的一道保险索。当你拿到一段被 AI 改过的代码你第一个问题往往是“这样改会不会破坏功能”如果当时记录里写了“测试全过”你的信心值会高很多反之就只能靠直觉判断那就失去了追溯的意义。5.3 团队协作场景下的同步要点如果你不是单独开发团队场景更需要这套机制。推荐在项目 README 里加一个小节叫做“AI 辅助编码约定”里面写上三条承认的规则所有重要 AI 修改必须关联任务编号所有 commit message 必须包含“为什么”所有 AI 对话的关键摘要落到.ai-contexts/或团队知识库落到实处后“AI 改的代码”就不再是团队里的灰色地带。成员之间互看代码时也能快速从依据编号跳到同一个上下文页面而不是靠口口相传。只要有一个人用了这套流程其他人很容易跟上毕竟谁都希望自己下次接手的是有线索的代码而不是一堆天才发明的未解之谜。6. 关于“依据”这件事我最后的个人体会说真的“AI 改完代码下一次还能不能找到依据”这个问题本质上是问我们自己你愿不愿意为 AI 的产出装上“来处”和“去处”。AI 让写代码变得更容易了但它也让代码里潜藏的“因为所以”变得更容易消逝。你可以在无数生成长短代码之后继续过着“改了再说忘了再猜”的日子但这就像在流沙上盖房子迟早要返工补地基。我个人实操下来的最大体会是好的依据管理就是你在每次让 AI 动手前多花十分钟给自己“备忘”并在代码落库前多花三分钟给未来留坐标。这几个动作本来就不难难的是稳定执行。建议你从今天一个最小的粒度开始选一个任务编号开一个对话让 AI 先给方案再动手提交时重写 commit message 带上编号。持续一个星期你再回头看会发现“顺着依据找回现场”比“翻记忆拼凑原因”舒服太多了。最后再分享一个小技巧把任务编号写在终端 prompt 上。我用的是包含当前分支名的自定义提示符里面带上关联任务编号每次开终端就知道自己在做哪件事关闭终端后也不会忘了来源。工具不分贵贱好用才是真。你的项目以后肯定还有无数轮 AI 修改每多留一条依据下一次你就能少一次抓狂。
