2026-04-03 · 为什么项目感知会话比再多一个 AI 功能更重要
发布时间：2026-04-03
标签：产品 项目上下文 AI 助手
很多 AI 编码工作流本质上都是基于 session 的。
无论是本地跑 Codex、Claude，还是在 UI 里持续和一个 agent 多轮协作，用户都会自然地把“一个 session”理解成“围绕某个项目或某个任务连续工作的上下文容器”。
问题在于，如果 session 不能真正绑定项目，这个容器就只剩“对话历史”，而没有真正的工作边界。
这就是为什么我认为，项目感知会话比再多一个 AI 功能更重要。它解决的不是表面上的交互问题，而是 session 到底能不能成为一个可用工作单元的问题。
没有这个能力时，用户到底会遇到什么问题
如果 session 不能稳定绑定项目，用户通常会遇到这几类问题：
- 新会话第一轮不能直接进入有效工作状态。
- 用户明明已经选了项目目录，但还得先发一条“占位消息”才能让状态真正落下来。
- 项目自己的
.agents/skills没有及时进入可选列表。 - 项目自己的
AGENTS.md或规则没有真正进入上下文。 - 同名的 project skill 和 workspace skill 容易混在一起。
- 切换项目后，UI 还可能继续显示旧的 skills 或旧的项目状态。
这些问题有一个共同点：用户以为自己已经在“这个项目里”工作了，但系统实际上并没有把这个语义贯穿到底。
这对本地 Codex / Claude 这类工作流尤其明显
在本地 Codex、Claude 这类使用场景里，用户很少把 session 当成一次性问答窗口。更常见的做法是：
- 一个项目开一个长期 session
- 一个任务开一个短期 session
- 在多个项目之间来回切换，但每个 session 都希望保留自己的工作边界
- 复用同一个 session 的历史、偏好、项目规则和技能集合
如果这时候 session 只有“消息历史”而没有“项目语义”，用户就会不断重复做三件事：
- 重新解释当前项目是什么
- 重新选择或确认哪些 skills 应该可用
- 重新校验模型当前拿到的上下文是不是对的
这不仅浪费输入成本，也会让第一轮真正有效的工作延后。用户本来是想直接开始干活，结果先要做一轮 session 校准。
这个能力实际提供了什么
这次能力补齐之后，session 会真正把“项目”当成自己的工作边界：
- 新会话可以在第一条真实消息之前先绑定项目目录。
- session skills 会按项目上下文加载，读取项目下
.agents/skills。 - workspace 已安装 skills 会保留，但不会覆盖项目 skills。
- 同名 skill 会通过稳定 ref 区分，而不是靠名字猜。
- 项目自己的
AGENTS.md与项目上下文会进入独立的Project Context区块。 - header 里的项目 tag 可以直接修改和移除项目目录。
- 项目切换后，skills 与展示状态会立即刷新，不再停留在旧状态。
这意味着“用户选了项目”这件事，不再只是 UI 上的一个字段，而是会真正影响后续整个 session 的运行语义。
对用户来说，前后区别是什么
有了这个能力之后，用户得到的不是一个新的按钮，而是一个更稳定的工作方式：
- 新 session 可以直接开始工作，不需要先做一轮“状态落盘”动作。
- 项目自己的 skills 和规则能从第一轮起生效。
- 多项目并行时，每个 session 的边界更清楚，不容易串上下文。
- 在本地 Codex / Claude 这类持续协作工作流里，session 的复用价值会明显变高。
- 用户切换项目、移除项目时，系统状态更可预测。
简单说，区别就是：
以前 session 更像“会记住聊天记录的对话框”。
现在 session 更接近“带着项目边界持续工作的工作单元”。
为什么这比再加一个新功能更值得优先做
对真实工作流来说，基础上下文能力会决定后面所有功能是不是好用。
如果 session 连项目都带不稳，再多加一个 skill、再多加一个工具、再多加一个模型入口，用户也仍然要花额外精力去校准上下文。
先把 session 的项目边界做对，后面的 skills、tools、automation、多轮协作能力，才有稳定落点。