我今天没急着让 AI 写代码,而是先给项目搭了一个上下文入口

很多人用 AI 写代码，第一反应是：

“来，帮我改这个 bug。”
“来，帮我加个功能。”
“来，帮我分析一下这个项目。”

但我今天做项目时，反而先停了一下。

我没有一上来就让 AI 去翻代码、查数据、改页面，而是先做了一件看起来很小、但后面很省命的事：

给项目搭一个稳定的上下文入口。

这件事如果不做，AI 很容易变成一个“很勤快但没记性的新同事”。

它可以一次性读很多文件，也能帮你改代码，但它不知道这个项目的默认入口在哪里，不知道哪些文档重要，不知道当前任务做到哪一步，也不知道哪些业务规则是历史上反复踩坑踩出来的。

最后结果就是：

它越努力，越可能乱。

---

一、我今天遇到的真实问题

今天这个项目不是一个干净的新项目，而是典型的长期业务项目。

里面有后台页面，有业务模块，有自动化脚本，也有很多历史遗留逻辑。

更麻烦的是，它不是“代码即全部”。

项目里还有很多隐藏上下文：

• 哪些环境是测试用的，哪些是正式用的
• 常用分支是什么
• 修改页面时，是否要同步相关前端文件
• 不同业务模块之间的口径是什么
• 当前 todo 记录在哪里
• 已完成事项怎么归档
• 哪些文件不能随便提交
• 用户说的某些习惯性表达，到底代表什么操作

这些东西如果只靠聊天记录记，一旦上下文丢了，下一次 AI 进来又要重新摸索。

所以我今天先做的不是“让 AI 多读几个文件”，而是把它变成一条固定路径。

---

二、我的核心结论

AI 项目初始化，不是让模型多读文件，而是给它建立一套可重复进入项目的上下文链路。

读文件只是动作。

上下文链路才是系统。

如果没有链路，AI 每次都是临时发挥。

有了链路，AI 每次进入项目，才像一个知道规矩、知道历史、知道当前任务边界的协作者。

这两者的差别非常大。

前者叫“聊天”。
后者才叫“工程化协作”。

---

三、为什么这件事重要

我以前也很容易陷入一个误区：

觉得只要把问题讲清楚，AI 就能干活。

但在真实项目里，问题本身往往不是孤立的。

比如一个后台详情页显示异常的问题。

表面看，只是某个字段展示得不好看。

如果只是简单修页面，很可能会把这个字段随便格式化一下。

但真正的问题可能是：

这个字段本身是历史遗留字段，它背后对应的是一组业务含义，而不是一个单独的展示值。

也就是说，这不是纯技术问题，而是业务口径问题。

如果 AI 不知道项目上下文，不知道这个系统里字段、表、页面之间的历史关系，它很容易“看起来修了”，但其实修歪了。

---

四、我今天的做法

我把项目入口整理成了几层。

第一层是项目入口文档。

它的作用不是写给人看的漂亮 README，而是写给“下一次进入项目的 AI”看的导航图。

里面集中说明：

• 项目定位
• 默认阅读顺序
• 根目录上下文文件
• 常用提示词
• todo 任务结构
• 关键模块
• 数据入口
• 最近项目变更脉络

第二层是 AI 协作规则文档。

这里定义 AI 每次开始必须先读什么。

比如：

长期记忆文档
项目入口文档
相关业务文档
当前任务记录
已完成任务记录
待处理任务记录
会议或沟通记录

这相当于给 AI 写了一份“入职第一天 SOP”。

第三层是长期记忆文档。

它更像项目记忆。

不是记录所有细节，而是告诉新会话：

如果你没上下文，先从哪里开始。

第四层是任务目录。

这里不是普通待办，而是项目执行账本。

当前任务记录正在做什么。
完成记录记录今天做完了什么。
待处理记录放后续需求。

这样做的好处是：

聊天记录丢了，但项目记忆还在。

---

五、我没有只写文档，而是用真实修复验证了一遍

我觉得很多“流程优化”最虚的地方在于：

只整理流程，不经过实战。

所以今天我没有停在文档层面。

我接着处理了一个后台详情页展示异常的问题。

原来页面把一个历史字段的原始值直接显示出来了，用户看到的是一串没有业务含义的内容。

修复后，我没有简单地“美化字符串”，而是根据真实业务口径，把它拆解成用户能理解的信息。

这次修复也顺便验证了一件事：

如果 AI 先读了项目入口、长期记忆、当前任务和相关业务说明，它就更容易理解：

• 这个字段为什么存在
• 这个页面应该怎么展示
• 哪些内容不应该继续暴露给用户
• 修复时要注意哪些历史兼容问题

这才是长期项目里真正有价值的修复。

不是只把页面改到“不报错”。

而是把它改到“符合业务”。

---

六、这套上下文链路的结果

今天这个动作带来的结果，不只是“多了几个文档”。

真正的结果是：

以后一个新模型进入项目，不用从零猜。

它会先知道：

先读项目入口
再读长期记忆
再读当前任务
再看最近完成记录
再根据任务找相关文档
最后才动代码

这会直接减少几类问题：

• AI 不会一上来乱扫无关模块
• AI 不会忽略历史业务口径
• AI 不会把临时文件、缓存文件、生成物一起提交
• AI 不会误判测试环境和正式环境
• AI 不会把“还在初始化阶段的脚本”，当成已经上线的功能
• AI 不会把“做到一半的事情”，理解成“已经完成的事情”

这一点非常重要。

项目管理里，最怕的不是没做完。

而是：

做了一半，但没人知道它是一半。

所以我现在会尽量把任务状态写清楚：

哪些是已完成。
哪些是进行中。
哪些只是初始化。
哪些还没进入正式执行。
哪些只是方案，不是结果。

这样，下一次 AI 接手时，不会误判项目状态。

---

七、我对提示词的认知也变了

以前我会把提示词理解成一句话：

“你是一个资深开发，请帮我……”

现在我越来越觉得，真正有价值的提示词不是一句话，而是一套工作基础设施。

提示词应该长在项目里。

它应该和 README、todo、提交记录、业务文档、数据口径放在一起。

这样 AI 才不是靠临场发挥，而是沿着项目沉淀下来的路径工作。

这也是我今天最大的感受：

不要只优化 AI 的回答，要优化 AI 进入项目的方式。

因为回答是一次性的。

进入方式是可复用的。

---

八、最后一句话

如果你也在用 AI 维护长期项目，别急着让它先写代码。

先给项目搭一个上下文入口。

这不是慢。

这是在给后面的每一次协作提速。