你每天对 AI 说的那些Prompt,其实是你最宝贵的资产

有一种现象，很多写代码的人都经历过：

明明用了好几个月的 AI，却总感觉效率没拉开差距。今天用得顺，明天又回到起点，来来回回，反复纠正，反复解释。

问题不是 AI 不够聪明，也不是你 Prompt 写得不好——问题是那些应该被记住的东西，从来没有被记下来。

这些话，表面上是 Prompt，但本质上是项目规则。你每次都要说，说明它们从来没被真正存下来。

这篇文章想聊的，就是这件事：哪些内容不该再停留在聊天框里，而是该升级成长期资产。

为什么"重复 Prompt"是一种隐形消耗

你以为自己在"纠正"它，但如果你已经说过很多次，这就不是纠正了，而是重复劳动。

更麻烦的是，这种劳动几乎没有积累性。当前会话也许记住了，下一个任务又全忘。于是产生一种错觉："AI 状态很不稳定，忽聪明忽笨。"

其实不是 AI 不稳定——是你喂给它的项目知识，从来没有真正沉淀下来。

5 类最值得"固化"的项目知识

如果把 AI 编程里最值得长期保存的知识拆开来看，大概可以分成 5 类：

下面逐一说说，为什么每类都值得单独重视。

① 项目事实：AI 的"入职手册"

这类信息不高级，但高频且稳定——搞错了，后面输出全会跑偏。

比如你每次都要提醒：我们用 pnpm，测试框架是 Vitest，组件在 src/components，API 在 src/services……

如果没说，AI 很容易吐一段 npm install，或者直接把请求逻辑塞进页面组件里。不是它不会写，是它没进入正确的上下文。

② 架构边界：最值钱的一类

AI 最容易犯的，往往不是语法错误，而是越界。

你让它"给订单页加个取消按钮"，它可能直接在页面组件里写一段 fetch('/api/cancel')，再顺手塞一些状态逻辑。功能跑起来了，但页面层、请求层、业务层全混在一起了。

如果你的规则里明确写了：API 一律走 services/order.ts，页面组件只调已有 action，状态更新走现有 store——AI 就更容易像一个熟悉这个仓库的人。

③ 工作流要求：让 AI "做事方式"对齐

真正有用的规则，往往是"一次合格的改动应该怎么完成"，而不是干巴巴的代码规范。

普通 AI 是"吐一段代码就完事"；配置了工作流规则的 AI，才像"真正能协作的开发者"。

④ 高频坑位：老手经验的显性化

这是我觉得最有价值的一类。

每个项目都有一些"说不清楚为什么，但就是不能动"的地方。一个看起来丑的老函数，可能被 8 个地方依赖，还有埋点系统在读它的返回格式。AI 出于"优化代码"的好意重构了它——结果你们花两天排查线上问题。

这类隐性经验，只存在于老成员脑子里，新人不知道，AI 更不知道。

⑤ 协作偏好：决定 AI 是不是好搭子

这类规则技术含量最低，但体验提升很明显。

有些 AI 一做改动，就顺手"优化"周边代码。你让它修一个 loading bug，它顺带把命名改了、把 hooks 抽了、把样式整理了。单看输出不差，但 diff 膨胀、review 变重、风险变高。

协作偏好规则不是技术约束，而是帮 AI 对齐"你们团队的做事节奏"。

这些知识，最后放到哪儿

工具不同，落点不同——但本质是同一件事：

这里有一个常见误区要避开：以为"建了这个文件，升级就完成了"。其实差得远。真正有价值的，是识别出哪些知识值得沉淀，然后持续维护它。

什么时候该开始做这件事

判断标准很简单：

回想一下，你最近是否总在说这些：

• 不要动这个目录

• 先看现有实现再动手

• 别引新依赖

• 改完先跑测试

• 不要做大重构

• 沿用现有组件体系

• 这个模块有历史包袱

这些内容基本上已经不再是临时 Prompt 了，而是项目规则。它们就等在那儿，只是你还没把它们写下来。