Vibe 编码时代，提示应作为意图元数据保存，而非替代源代码；AI 生成内容需明确标注，以保障可追溯性与协作效率。
Vibe 编码时代，我们真的需要“git blame”AI 吗？
在人工智能深度融入软件开发流程的 2026 年，“Vibe 编码”已经不再是极客圈里的新奇概念，而是许多开发者日常工作的默认模式。所谓 Vibe 编码，就是通过自然语言提示（Prompt）与大模型交互，让 AI 自动生成代码、修复 Bug、重构模块，甚至撰写完整的功能模块。
但随之而来的问题也愈发尖锐：如果一段 Python 代码是由你用英文写下的指令生成的，那么到底哪一部分才算真正的“源代码”？是那句模糊又充满个人风格的提示，还是 AI 输出的、可被编译执行的程序文本？
波兰机器学习专家皮奥特·米格达尔（Piotr Migdał）在他最新发表于 Quesma 博客的文章中，直指这一行业正在面临的根本性困惑——当提示成为人机交互的新界面，我们是否应该将它们像源代码一样纳入版本控制系统？
更重要的是，当代码出问题时，我们能否对 AI 进行“git blame”？
git blame啥意思？
“git blame” 是 Git 版本控制系统中的一个命令，它的作用是查看某一个文件的每一行代码，分别是由谁、在哪个提交（commit）中、于什么时间修改的。
举个例子，如果你在一个团队项目里看到一段奇怪的代码，想知道“这行是谁写的？什么时候加的？”，就可以在终端运行：
bash
git blame filename.py
输出会类似这样（每行前面显示提交哈希、作者、日期）：
^abc1234 (张三 2025-12-01 10:23:45 +0800 1) def calculate(x):
def9876 (李四 2026-01-05 14:12:30 +0800 2) return x * x + 2
这样你就知道第 2 行是李四在 1 月 5 日改的。
虽然名字叫 “blame”（指责），但实际用途不是为了甩锅，而是为了：
- 快速定位代码变更的历史上下文；
- 找到最了解某段逻辑的人（方便请教或 code review）；
- 追溯 bug 引入的时间点。
所以，“git blame” 本质上是一个代码溯源工具，中文常被戏称为“甩锅命令”，但专业场景下它是协作和维护的重要帮手。
“We should be able to (git) blame AI” 的意思是：当代码是 AI 生成的，我们也应该能像追踪人类开发者一样，明确知道“这一行是 AI 在某次提示下生成的”，从而保留责任链和可解释性。
提示到底算不算源代码？别被浪漫想象迷惑了
传统软件工程里，源代码是人类写的，机器码是计算机执行的。中间通过构建工具链（Build System）完成确定性的转换。只要环境一致、依赖锁定，今天编译出来的二进制文件和三年后一模一样——这是软件可靠性的基石。
然而，在 Vibe 编码范式下，流程变成了“提示 → 代码 → 构建产物”。表面看只是多了一环，实则颠覆了整个确定性逻辑。因为从提示到代码这一步，本质上是非确定性的。哪怕你把温度参数设为零，使用同一个模型、同一段指令，Claude Opus 4.5 在两次运行中生成的 HTML 文件也可能略有不同：一个用了 div 嵌套，另一个用了 section；一个加了动画，另一个只做了静态布局。
这种差异在小型任务中尚可容忍，但在大型项目里，同一个“修复登录漏洞”的提示，可能这次成功堵住漏洞，下次却引入了新的越权风险。
更麻烦的是，大模型本身并不具备长期稳定性。今天你用的 Cursor 内置模型，明天可能就升级了底层架构；昨天还能完美解析你“用 React 写一个带拖拽排序的待办列表”的指令，今天更新后却开始输出 Vue 语法。这不像 npm 或 pip 那样可以锁定具体版本号。你无法像 pin 住 lodash@4.17.21 那样，永久冻结某个 AI 模型的快照。
再加上 LLM 的上下文理解高度依赖对话历史、工具调用记录、甚至截图或 MCP 服务器返回的数据，这些动态要素根本无法被完整捕获进一次 Git 提交里。
因此，把提示当作新一代“源代码”来提交，看似理想，实则危险——它会让构建过程重新滑向“只在我电脑上能跑”的黑暗时代。
提示的本质是“意图笔记”，不是构建输入
与其幻想提示能取代代码，不如认清它的真正角色：提示其实是开发过程中的“意图记录”或“设计草图”。就像建筑师画在餐巾纸上的草图，虽然粗糙、充满涂改，但能反映最初的构想。
自然语言的优势在于灵活、包容模糊性，这恰恰也是它的致命缺陷——它无法被“编译”。
法律条文写得再严谨，也需要法院解释；数学公理系统再完备，仍需形式化验证工具辅助。
同样，一句“优化数据库查询性能”可以被理解成加索引、改写 SQL、引入缓存，甚至重构整个数据模型。
当前的大模型远未达到能百分百忠实执行复杂指令的水平。有时候，连“把这段文字首字母大写”这种基础任务，不同模型实例都会给出不同结果。Gemini 3 Pro 在 Cursor 中并行运行四次，对同一篇博客做语法修正，输出的版本居然各不相同——有的改了标点，有的调整了语序，有的干脆删掉了一整句话。
正因为如此，提示不应被视为可靠的构建输入，而应作为辅助理解代码演进脉络的上下文信息。当你在三个月后回看某段神秘的异步函数，如果旁边附带了当初生成它的提示：“用 asyncio 实现非阻塞的第三方 API 调用，注意处理超时和重试”，那排查问题的效率会高得多。
这就像考古学家发现陶器时，如果同时找到制作它的模具和工匠笔记，复原工艺就容易多了。
所以，关键不是要不要保存提示，而是如何以安全、规范的方式将其与代码变更关联起来。
给 AI 代码打上“身份标签”，是技术债管理的新刚需
文章提出一个极具操作性的建议：所有由 AI 生成的代码变更，都应在 Git 提交中明确标注来源。
这不是出于道德评判（比如认为 AI 代码低人一等），而是纯粹的技术治理需求。
越来越多的开源项目已开始要求披露 AI 贡献——Ghostty 项目强制声明，Gentoo 社区甚至计划全面禁止 AI 提交。原因很简单：知道某段逻辑是人类深思熟虑的结果，还是 AI 瞎猜出来的，直接影响审查策略。
比如用户认证模块，必须逐行人工核验；而一个简单的 UI 按钮样式，完全可以信任 AI 生成。StarCraft II 平衡时间线可视化项目就是一个典型案例：作者用 Claude 全程生成代码和提交信息，每次 package.json 的依赖更新都对应一条清晰的意图说明，使得版本回溯和影响分析变得异常高效。
这种“可归因性”在未来只会越来越重要。随着 AI 代理在团队中扮演更主动的角色——自动提 PR、自测、自修复——如果没有机制标记哪些是 AI 行为，调试将变成一场噩梦。
想象一下，凌晨三点线上服务崩溃，日志指向一段三天前合并的代码，而提交者显示是你的同事张三。结果一查，张三根本没动过这行，是他的 AI 助手在半夜自动优化“性能”时引入了竞态条件。
如果 Git 历史里能直接看到“此提交由 Claude 生成，原始提示为：‘减少内存占用’”，排查路径就清晰多了。这不仅是工程效率问题，更是责任边界问题。
保存提示的现实障碍：脏、私、怒、傲
当然，理想很丰满，落地很骨感。
直接把开发过程中写的所有提示都塞进 Git，会遇到一堆人性层面的阻力。
首先，提示往往写得极其随意——满屏错别字、情绪化表达、甚至夹杂着“你这个蠢模型怎么又搞错了！”之类的抱怨。这就像程序员本地的草稿笔记本，布满涂鸦和半截思路，根本不适合公开。
其次，隐私风险极高。有人习惯在提示里粘贴自己的 API 密钥做测试，或者写“参考我上周五发给客户的邮件内容”，这些敏感信息一旦泄露后果严重。
再者，人们对 AI 的态度比对同事粗鲁得多。
有研究显示，用户对 LLM 使用侮辱性语言的频率远高于人际沟通，部分人甚至相信“骂得越狠，模型越听话”——著名的 Windurf 泄露提示就充满脏话。
最后还有心理因素：很多资深开发者视编码为手艺活，觉得靠 AI 生成代码“不够体面”，不愿暴露自己依赖提示的事实；社区里对“AI 烂代码”的鄙视链也真实存在，导致开发者宁愿隐藏 AI 使用痕迹。
因此，解决方案不能是“全盘保存”，而应是“可 redacted 的 curated prompts”。就像开发者会在推送前 squash 掉那些“尝试1”“再试一次”“终于搞定了”的脏提交，提示也应该经过清洗、脱敏、提炼后再与正式提交绑定。
“可 redacted 的 curated prompts” 就是指：
那些经过人工或工具清洗、提炼过，同时支持一键隐藏或删除敏感信息的高质量提示。它们既保留了原始开发意图，又适合安全地存入 Git、分享给团队，甚至公开到开源项目中。
我们不能直接把开发过程中那些“脏乱差”的原始提示扔进代码仓库，但也不能完全丢弃。理想做法是建立一套机制，让提示能像提交代码一样，被整理、脱敏、关联到具体变更，并随项目一起版本化管理。这就是 “可 redacted 的 curated prompts” 的核心价值。
IDE 或 Git 插件或许会内置这样的工作流：自动生成初始提示 → 开发者编辑润色 → 自动移除密钥/脏话 → 选择性关联到特定代码块 → 最终随 commit 一起存储为元数据。Quesma 团队透露他们正在开发开源工具来支持这一流程，值得期待。
从“vibe coding”到“vibe committing”：别让提交信息拖后腿
文章结尾点出一个常被忽视的细节：既然允许用 AI 写代码，就该允许用 AI 写提交信息。现实中太多开发者图省事，把几十个 AI 生成的文件一次性提交，消息栏只写“fixed it”或“update”。
这种懒惰行为极大削弱了 Git 的历史价值。好的提交信息应该像新闻标题，清晰说明“为什么改”“改了什么”“影响范围”。如果 AI 能根据本次变更的代码差异和原始提示，自动生成类似“根据用户反馈，重构支付回调逻辑以支持多币种结算”的描述，那协作效率将大幅提升。
Cursor、GitHub Copilot 等工具其实已具备此能力，只是尚未成为默认行为。推动“vibe committing”成为新规范，或许是降低 AI 协作成本最简单有效的第一步。