Google内部有个叫Anti Gravity的项目，名字听着像反重力装置，实际是套给开发者用的IDE（集成开发环境）工具链。2023年低调上线，2024年逐步开放，到现在也没开过一场发布会。但过去18个月，一个奇怪的现象在硅谷工程师圈子里蔓延：越来越多的人开始往代码库里塞.md文件，不是写文档，是给AI下指令。
这事最早是Google自己的Angular团队传出来的。他们开发新功能时，不再跟Gemini（谷歌的大语言模型）闲聊式对话，而是直接丢过去一份结构化指令。效果诡异得明显——同样一个代码审查任务，用对话模式平均要来回6-7轮，用指令文件一轮出结果，且格式固定得像印刷品。
这不是什么新功能，是旧习惯的失效。
Angular技术负责人Minko Gechev去年在内部技术分享里提过一句：「我们花了太多时间教AI理解上下文，其实该做的是把上下文写成代码能调用的配置。」当时没人在意。直到今年Q1，Google Developer Blog披露了一组数据：使用结构化指令文件的团队，代码审查周期缩短了34%，AI生成代码的采纳率从41%提升到67%。
数字背后是一套被刻意藏起来的工作流。Anti Gravity的设计理念很直白——让开发者留在「心流」里。但真正实现这点的，不是IDE本身，是你怎么架构跟AI的交互方式。
从「聊天」到「配置」：一个文件格式的迁移
传统用法里，开发者打开侧边栏，输入需求，等AI回复，再补充细节，循环往复。这像什么？像你去餐厅点菜，每次都要重新介绍自己的口味偏好、过敏原、辣度承受力。而.md指令文件相当于一张预制菜单，把「我是谁、我要什么、我不要什么」写死在里面。
具体操作上，Angular团队的做法是把提示词当成Angular组件来管理。每个.md文件有明确边界：一个目的、一套规则、一种输出格式。比如他们内部流传最广的pr-assistant.md，专门用来生成GitHub PR（Pull Request，代码合并请求）评论。
文件结构极其朴素。Goal（目标）栏一句话：通过git CLI起草并发布高质量的PR评论。Rules（规则）栏三条：反馈必须可执行、专业、简洁；不确定的地方明确标出，禁止猜测；结构固定为Context→Suggestion→Reasoning。Execution（执行）栏再补一刀：输出走git CLI，不用IDE内联注释，把评论当成给Reviewer和未来维护者的笔记。
整个文件不到30行。但放进Anti Gravity的上下文窗口后，Gemini的行为被锁死在轨道上。不会出现「我觉得」「也许可以考虑」这种模糊表达，不会突然改用列表格式，不会忘记标注不确定的改动。输出像被模具压过，每次长得一样。
这种一致性在团队场景下价值翻倍。
一个Angular项目通常有十几个贡献者，每个人跟AI对话的风格不同。有人习惯详细描述，有人喜欢极简指令，有人总忘了提代码规范。结果同一套代码库，AI生成的注释质量方差极大，Reviewer得重新适应每个人的「AI口音」。而共享的.md文件相当于团队层面的普通话推广，把个人习惯压平成集体协议。
Prompt Drift：为什么对话模式必然失效
Google内部有个术语叫Prompt Drift，中文环境里没人统一翻译，大意是「提示词漂移」。现象很普遍：你今天跟AI交代清楚的需求，下周再提时，描述方式变了，AI的理解也偏了。更隐蔽的是情绪污染——你刚开完一个糟糕的会，语气急躁，AI跟着输出更激进的代码建议。
这种漂移在对话场景里无法避免。人不是机器，同一件事每次表述都有微妙差异。而AI对措辞极度敏感，「优化这段代码」和「重构这段代码以提高可维护性」指向的结果可能完全不同。
.md指令文件的核心作用，是把易变的自然语言冻结成稳定的配置。你不再每次重新发明轮子，而是引用、微调、版本控制。Anti Gravity的架构设计恰好放大了这个优势——指令文件直接躺在代码库里，跟业务代码一起被Git追踪，团队成员随时能看到变更历史。
一个细节：Angular团队把指令文件放在项目的.ai/目录下，跟src/平行。这不是Google官方推荐，是他们自己摸索出来的组织方式。好处是代码审查时，.md文件的改动会出现在PR里，团队可以讨论「这条规则是不是太严格了」「新加的输出格式有没有必要」。指令本身也成了被协作的对象。
这种元层面的透明，在对话模式里几乎不可能实现。
你跟AI聊了什么、怎么聊的、中间改过哪些条件，除非手动截图或复制粘贴，否则无迹可寻。而.md文件天然解决审计问题——谁改了、什么时候改的、为什么改，Git log里一行行清楚得很。
Angular原则的回溯：分离、复用、一致
把提示词组件化，听起来像强行套用前端框架的概念。但Angular团队的设计确实暗合了框架本身的哲学。
分离关注点（Separation of Concerns）：每个.md文件只做一件事。pr-assistant管PR评论，test-generator管测试用例生成，migration-guide管老版本迁移。不会出现一个文件既管代码审查又管文档生成，结果两头都做不好的情况。
复用性（Reusability）：同一份pr-assistant.md，从Angular核心库复制到企业级应用项目，只需改两行上下文描述。规则、格式、输出方式完全不变。这跟Angular组件跨项目复用的逻辑一模一样。
一致性（Consistency）：标准化输出，每次触发都 predictable（可预测）。开发者不需要在脑子里维护「这次AI会怎么回」的模型，可以专注在代码本身。
这种对应关系不是巧合。Anti Gravity的早期版本就是Angular团队给自己造的轮子，后来才慢慢推广到Google其他部门。工具的设计基因里，写满了这个框架的思维方式。
一个反直觉的发现：越是资深的Angular开发者，转向.md指令文件的速度越快。新手反而更依赖对话模式，觉得「聊天更自然」。但三个月后，两组人的效率曲线交叉——用指令文件的团队开始指数级省时间，纯对话团队还在线性堆叠重复劳动。
Google内部有个非正式统计：采用结构化指令半年后，开发者平均每周与AI的「对话轮次」下降了62%，但有效代码产出量上升了28%。
不是跟AI聊得越多越有用，是聊得越精准越有用。而精准的前提，是把模糊意图翻译成机器可解析的配置。
从个人习惯到团队基础设施
Anti Gravity的真正野心，不只是让单个开发者更快，是把AI交互变成可规模化的团队资产。
代码库里的.md文件可以继承、覆盖、组合。团队层面定义基础规则，项目层面叠加特定约束，个人层面保留微调空间。这跟Angular的模块系统异曲同工——顶层Module提供全局配置，子Module按需覆盖，组件内部再细化。
一个实际案例：Google Cloud的某个内部工具团队，把安全审查规则写成security-audit.md，强制要求所有AI生成的代码必须经过特定检查点。规则文件本身被CI（持续集成）流程引用，AI输出如果不符合格式要求，自动触发人工复核。这不是建议，是硬约束。
更激进的用法出现在测试生成场景。Angular团队维护了一份test-spec.md，定义了单元测试的命名规范、覆盖率阈值、断言风格。新功能开发时，开发者直接引用这份文件，AI生成的测试用例一次性通过CI检查的概率从53%提升到89%。剩下的11%失败，也不是格式问题，是业务逻辑边界条件没覆盖到——这本来就需要人脑判断。
这种「人机分工」的清晰度，在对话模式里很难建立。
你跟AI说「写个测试」，它不知道你的命名规范、不知道你的Mock习惯、不知道你对Given-When-Then结构的偏好。结果每轮输出都要人工修正，修正的过程又没法沉淀成可复用的知识。而.md文件把修正前置成了规则，一次写好，持续受益。
版本控制是另一个被低估的维度。指令文件的演进跟代码演进同步，你可以回滚到三个月前的AI行为，对比不同规则集的效果，甚至在A/B测试里同时跑两套提示策略。这种实验能力，在聊天窗口里几乎不存在。
Google Developer Blog今年2月的一篇文章里，有个细节被很多人忽略：Anti Gravity团队正在测试「指令文件市场」功能，允许团队之间共享和复用经过验证的.md模板。目前内测的模板库已经有200+份文件，覆盖从React迁移到性能调优的十几个场景。
这意味着什么？提示词工程正在从个人手艺变成可交易的模块化组件。就像早年开发者从手写CSS转向Bootstrap，从自建服务器转向云服务，AI交互也在经历类似的抽象层上移。
不是每个人都会写高效提示词，但每个人都可以引用一个写得好的。
回到开头那个问题：为什么Google把这套工作流藏了这么久？
答案可能很简单——它从来不是被设计出来的，是被逼出来的。Angular团队最初只是厌倦了重复解释同样的需求，随手把常用提示词存成文件。效果意外得好，才慢慢形成方法论。Anti Gravity的产品经理去年承认：「我们花了两年时间优化IDE的响应速度，最后发现开发者最大的痛点是每次都要重新教AI怎么帮忙。」
这个认知翻转，现在正在从Google向外扩散。VS Code的Copilot Chat、JetBrains的AI Assistant、Cursor的Composer，都在以不同形式支持类似的「提示词即配置」模式。但Anti Gravity的独特之处在于，它从底层架构就把.md文件当成一等公民，而非后期补丁。
一个值得观察的信号：Angular v18的路线图里，有一条「AI-native workspace」的模糊描述，预计Q3公布细节。内部人士透露，核心就是把指令文件系统深度集成到框架的CLI（命令行工具）里，让`ng generate`命令可以直接调用带上下文的AI能力。
如果这成为现实，开发者运行`ng generate component`时，AI不仅知道Angular的组件规范，还知道你们团队的具体约定——因为那些约定就写在项目根目录的.ai/component-gen.md里。
这种「框架即协议」的思路，可能是AI辅助开发下一个阶段的雏形。不是AI变得更聪明，是AI被嵌入到更聪明的系统结构里。
你现在的工作流里，有多少重复的解释正在消耗你的心流时间？那些重复，有多少可以被写成一份30行的配置文件？
热门跟贴