上下文工程：给AI一个持久记忆的工作空间

又新建了一个对话窗口。

"我在搭建一个人生管理系统，涵盖七个维度，健康、意义、家庭……" 讲到第三个维度时我停了下来。这段话上周讲过两次，上上周讲了三次。

AI 确实聪明。但每次开启新对话，它就像刚入职的天才新人，对你的情况一无所知。你得从头说明自己是谁、在做什么项目、进展到哪一步、有什么偏好。

问题不在 AI 的智能。问题在于它没有一个"可以安顿下来"的地方。

这篇文章探讨的是：如何打造一个 AI-native workspace，让 AI 能够持续深耕你关注的领域，而不是每次都从空白状态起步。

Notion、Obsidian、飞书文档，这些工具的设计前提是：人作为执行者，工具作为记录者。文档排版精美、供人阅读没问题。

但当 AI 成为执行层，这个前提就颠倒过来了。AI 需要的不是精致排版，而是精准指令。它需要了解：这个 workspace 管理哪些领域？每个领域的当前状况怎样？待办事项在哪个文件？状态变化时要同步哪些地方？

Shopify CEO Tobi Lütke 在 2025 年 6 月给了一个精准的定义：context engineering 是"the art of providing all the context for the task to be plausibly solvable by the LLM"。Karpathy 补充道，这是"filling the context window with just the right information for the next step"。

Context window 是稀缺资源。往里填什么，决定了 AI 能完成什么。

传统工具从未为这个问题设计过。你需要一套 AI 能理解、能运行、能精准针对你的领域执行的操作系统。

AI-native workspace 分三层：基础层定义系统如何运转，组件层提供可组合的能力模块，领域配置层定义你具体管什么。

基础层是所有场景都必需的底层架构。它不关心你管什么领域，只关心系统的运行规则：

基础层的作用是约束所有上层行为。无论你添加什么组件、接什么 skill，这些规则始终生效。

组件层提供 8 个可组合模块，每个解决一个明确问题：

组件按需启用。学习系统不需要集成层，工作管理不需要习惯层。每个组件有明确的输入输出接口，组件之间通过文件系统协作，不依赖 API 或数据库。

领域配置层定义"管什么"。同样的组件层，配上不同的领域配置，就是完全不同的系统。

领域配置包含：

组件不是孤立运作的。一个典型的信息处理流程：

一封邮件进来，信息层按领域分类提取——客户 A 提到了新需求（写入客户 baseline 的 Change Log）、提到了下周二的会议（写入执行层的行动项）、提到了一个技术方案的反馈（触发知识层的认知沉淀）。

执行层的行动项状态变更时，强制检查点自动触发：更新执行层数据源（唯一真相）→ 同步 dashboard → 检查关联项目 index → 如果影响领域状态则更新状态指标。一次状态变更，多个文件同步，AI 在一次交互中完成。

回顾层定期扫描所有 area 的状态，发现哪里偏离了预期。回顾的产出又反哺执行层——新的行动项、调整的优先级。

整个系统有一个核心约束：文件系统是唯一接口。AI 通过读写 Markdown 文件操作 workspace，人类通过同样的文件（或其可视化）观察和介入。没有数据库，没有私有 API，没有锁定。

同一套基础层和组件层，通过不同的领域配置，适配完全不同的场景：

人生管理：领域是七个维度——健康、意义、家庭、赚钱、提升、关系、投资。三个地基支撑四根支柱。回顾节奏是周+月+季，AI 驱动问答式。知识层启用内容输出管线，洞察可以变成公众号文章。

工作管理：领域是客户、伙伴、团队、管理、跨部门协作。回顾节奏是日+周，AI 自动生成报告。执行层启用阻塞标注——[推进中]、[待确认]、[等XX]，因为多人协作需要知道球在谁手上。集成层连接 Notion、Jira、GitLab。

学习系统：领域按学科分——编程、设计、语言。每个学习目标是一个项目，知识层是核心组件。不需要集成层，不需要阻塞标注，简单干净。

三个场景，同一套原则约束，同一套组件可选，完全不同的领域配置。

现在打开一个新 session。AI 读一下 steering 文件——30 秒，它知道你是谁、管什么领域、每个领域当前状态、有哪些活跃项目、行动项在哪。

你不再需要每次重新介绍自己。针对你关注的 area 和对应的处理原则和流程，都已经固化到当前的 workspace 之中了，agent 已经完全可以从从容容游刃有余地处理好所有的事情了。