# 记忆的艺术：让AI不再失忆的简单智慧
当你的AI助手在执行第50个操作时突然忘记了最初的目标，你会怎么办？
2025年12月29日，科技圈炸了。Meta以20亿美元的天价收购了一家成立仅8个月的AI创业公司——Manus。更疯狂的是，这家公司在短短8个月内就实现了超过1亿美元的营收。
所有人都在问：他们到底做对了什么？
答案出乎意料的简单：他们教会了AI如何"记笔记"。
这不是一个技术创新的故事，而是一个关于认知本质的寓言。
## 一、阿尔茨海默症：被忽视的致命缺陷
想象一下这个场景：你让Claude帮你重构一个复杂的项目，它信心满满地开始工作。前20步进展顺利，代码写得漂亮，逻辑清晰。但到了第40步，你突然发现它开始做一些莫名其妙的事情——明明你要的是优化性能，它却开始重写UI组件。
这不是个例。几乎所有使用过AI编程助手的开发者都遇到过类似的问题：
- **目标漂移**：执行到一半，AI突然"忘记"了最初的任务目标
- **重复犯错**：同样的错误反复出现，就像没有长期记忆一样
- **上下文爆炸**：为了让AI"记住"所有信息，不得不把所有内容都塞进对话里
- **进度丢失**：一旦对话重置，之前的所有工作状态都烟消云散
这些问题的根源在哪里？
### 认知的瓶颈
人类在处理复杂任务时，会本能地做一件事：记下来。
在纸上列出待办清单，用便签记录关键信息，在笔记本上追踪进度，把重要文档保存在文件夹里。为什么？因为我们的**工作记忆容量有限**。
心理学研究表明，人的工作记忆大约只能同时保持7±2个项目。超过这个容量，信息就会开始"溢出"。
AI也是如此。虽然现代大模型的上下文窗口已经扩展到128K甚至200K tokens，但在实际使用中，有两个问题：
1. **性能衰减**：上下文越长，模型注意力越分散，中间的信息越容易被遗忘（"lost in the middle"效应）
2. **成本爆炸**：即使技术支持，长期保存海量上下文的成本是商业上不可持续的
传统AI助手的做法是什么？把所有东西都塞在"脑子里"（上下文窗口）。就像一个人试图在脑海中同时记住100件事情——结果可想而知。
这就是AI的"阿尔茨海默症"：不是因为智商不够，而是因为没有学会使用外部记忆。
## 二、三个文件的启示：价值20亿的洞察
Manus团队的核心洞察极其简单，却又极其深刻：
> "Markdown文件就是我在硬盘上的'工作记忆'。由于我的处理是迭代式的，而活跃上下文有限，Markdown文件就成了我的草稿本、进度检查点和最终交付物的构建模块。"
这句话听起来平淡无奇，但它揭示了一个革命性的思路：**不要试图把所有东西都塞进AI的"脑子"里，而是教它学会"记笔记"**。
他们的方法论浓缩为一个简单的模式：对于任何复杂任务，创建三个文件：
- **task_plan.md** → 任务计划和进度追踪
- **notes.md** → 研究发现和知识存储
- **[deliverable].md** → 最终交付物
### 这不是文件管理，这是认知工程
让我们看看这三个文件各自承担的角色：
**task_plan.md 是AI的"待办清单"和"进度表"**：
- 明确定义任务目标
- 将复杂任务分解为可管理的阶段
- 用复选框追踪完成状态
- 记录决策和遇到的错误
**notes.md 是AI的"研究笔记本"**：
- 存储搜索和调研的结果
- 记录关键发现和洞察
- 避免把大量信息塞进上下文
**[deliverable].md 是最终的"交付成果"**：
- 基于前两个文件的积累
- 结构化的最终输出
- 可以独立使用的完整文档
这个看似简单的模式，却蕴含着深刻的工程智慧。它不是在管理文件，而是在**管理认知过程**。
### 魔法循环：读-做-写-更新
更关键的是工作流程：
1. **循环1**：创建 task_plan.md，定义目标和阶段
2. **循环2**：研究 → 保存到 notes.md → 更新 task_plan.md
3. **循环3**：读取 notes.md → 创建交付物 → 更新 task_plan.md
4. **循环4**：交付最终成果
这个循环的精妙之处在哪里？
在每次做重要决策之前，AI都会重新读取task_plan.md。
为什么这么做？因为这样可以把任务目标"刷新"到AI的注意力窗口中。
## 三、注意力的经济学：操控AI的专注力
AI模型有一个鲜为人知的特性：它们对上下文开头和结尾的内容记得最清楚，对中间部分容易遗忘。这被称为"lost in the middle"效应。
### 迷失在中间的陷阱
想象一下这样的场景：
```
[上下文开始]
用户目标: 优化数据库查询性能 ← 很久以前说的，已经"远在天边"
...
工具调用1: 分析代码
工具调用2: 检查配置
工具调用3: 运行测试
...
工具调用47: 修改UI样式 ← 咦?怎么跑偏了?
工具调用48: 更新CSS
...
[上下文结束]
```
到了第47个工具调用时，最初的目标"优化数据库查询性能"已经被埋在了上下文的深处，AI的注意力早就不在那里了。
这就像长途旅行：如果你只在出发时看一次地图，开到一半很容易就忘记目的地在哪里。
### 注意力刷新机制
Manus的解决方案极其巧妙：通过反复读取task_plan.md，把目标"拉"到上下文的末尾。
```
[上下文开始]
用户目标: 优化数据库查询性能 ← 原始目标(已被遗忘)
...
工具调用45: 完成某个子任务
工具调用46: 读取 task_plan.md ← 关键操作!
内容: "目标:优化数据库查询性能,当前阶段:分析慢查询"
工具调用47: 基于刷新的目标继续工作 ← 目标重新进入注意力窗口!
[上下文结束] ← 最近读取的内容在这里,获得最多注意力
```
这就像在长途旅行中不断查看地图，确保自己没有偏离方向。
### 数据说话：50次调用不迷路
根据Manus的统计数据，他们的AI代理平均每个任务需要约50次工具调用。在传统方法下，这几乎必然导致目标漂移。
但通过"读取-刷新"机制，Manus实现了：
- **零目标漂移**：即使经过50+次操作，仍然紧扣原始目标
- **高效决策**：每次重大决策前都能"看到"完整的任务上下文
- **可追溯性**：所有决策都有明确的依据和记录
这不是魔法，而是对AI注意力机制的深刻理解和巧妙利用。
## 四、失败也是财富：错误追踪的艺术
大多数AI系统遇到错误时的本能反应是什么？
```
尝试操作A → 失败
尝试操作A → 失败
尝试操作A → 失败
(悄悄换个方法)
尝试操作B → 成功
```
用户看到的是最终成功，但背后是大量的token浪费和重复错误。更糟糕的是，AI没有从失败中学到任何东西。
### 错误恢复是真正代理行为的标志
Manus团队有一个反直觉的洞察：
> "错误恢复是真正代理行为最清晰的信号之一。"
他们的做法是：把所有失败都记录在task_plan.md中。
```markdown
## 遇到的错误
- [2025-01-03] FileNotFoundError: config.json未找到
→ 解决方案: 创建了默认配置文件
- [2025-01-03] API超时
→ 解决方案: 使用指数退避重试,成功
- [2025-01-03] 类型错误: user对象未正确await
→ 解决方案: 添加await关键字,问题解决
```
这样做有三个巨大的好处：
1. **避免重复犯错**：当AI再次遇到类似情况时，可以查看历史记录，直接采用已验证的解决方案
2. **积累知识**：错误记录成为了宝贵的知识库，后续任务可以参考
3. **提升透明度**：用户可以清楚地看到AI遇到了什么问题，如何解决的，建立信任
### 一个真实的例子
让我们看一个实际案例：
```markdown
# 任务计划: 修复登录Bug
## 目标
识别并修复阻止成功登录的bug
## 阶段
- [x] 阶段1: 理解bug报告 ✓
- [x] 阶段2: 定位相关代码 ✓
- [x] 阶段3: 识别根本原因 ✓
- [ ] 阶段4: 实施修复 (当前)
- [ ] 阶段5: 测试验证
## 做出的决策
- 认证处理器位于 src/auth/login.ts
- 错误发生在 validateToken() 函数
## 遇到的错误
- [初始] TypeError: Cannot read property 'token' of undefined
→ 根本原因: user对象未正确await
→ 修复: 在第42行添加await关键字
→ 结果: 问题解决,登录成功
## 状态
**当前在阶段4** - 已找到根本原因,正在实施修复
```
注意这个计划文件如何清晰地记录了：
- 问题是什么
- 在哪里发现的
- 根本原因是什么
- 如何解决的
- 当前进展如何
这不仅帮助AI保持专注，也为人类开发者提供了完整的问题解决轨迹。
## 五、六大原则：上下文工程的系统观
Manus团队总结了六条核心原则，这些原则构成了"上下文工程"这个新兴领域的理论基础。
### 原则1：文件系统作为外部内存
核心思想：把文件系统当作无限容量的外部内存。
传统方法的问题：
```
上下文窗口 = 有限容量
所有信息 → 塞进上下文 → 性能下降 + 成本上升
```
Manus的方法：
```
大量内容 → 存储在文件中
上下文中只保留 → 文件路径
需要时 → 读取文件
```
这就像人类的工作方式：我们不会试图把整本书都记在脑子里，而是记住书在哪里，需要时去查阅。
关键要求：压缩必须是可逆的。不能为了节省空间而丢失信息，因为AI可能需要完整的原始数据。
### 原则2：通过重复操控注意力
核心思想：利用"最近读取的内容获得最多注意力"这一特性。
AI模型的注意力分布：
```
[上下文开始] ← 注意力中等
[上下文中间] ← 注意力最低 (lost in the middle)
[上下文结尾] ← 注意力最高
```
Manus的策略：
```
在每次重大决策前 → 读取task_plan.md
→ 目标出现在上下文末尾
→ 获得最高注意力
→ 决策质量提升
```
这解释了为什么Manus能处理约50次工具调用而不迷失方向。
### 原则3：保留失败轨迹
核心思想：错误恢复是真正代理行为的标志。
错误的做法：
```
尝试 → 失败 → 悄悄重试 → 失败 → 再重试 → 成功
(浪费token,没有学习)
```
正确的做法：
```
尝试 → 失败 → 记录到task_plan.md
→ 分析原因 → 调整策略 → 成功
→ 下次遇到类似问题 → 直接采用已验证的解决方案
```
这不仅节省资源，还建立了知识积累机制。
### 原则4：避免少样本过拟合
核心思想：统一性导致脆弱性。
问题：重复的动作-观察模式 → 导致漂移和幻觉
解决方案：引入受控的变化：
- 稍微改变措辞
- 不要盲目复制粘贴模式
- 在重复任务上重新校准
这就像人类不会用完全相同的方式重复做同一件事，适当的变化反而能保持清醒。
### 原则5：稳定前缀优化缓存
核心思想：AI代理是输入密集型的（输入输出比约100:1），每个token都是成本。
问题：
```
频繁变化的上下文 → 缓存失效 → 重复计算 → 成本飙升
```
解决方案：
```
结构化设计:
1. 静态内容放在前面 (系统提示、工具定义等)
2. 动态内容追加在后面 (用户消息、工具结果等)
3. 一致的序列化格式
→ 最大化缓存命中率
```
这就像把常用的工具放在工具箱的固定位置，每次都能快速找到。
数据说明一切：对于Claude Sonnet，缓存的输入token成本是0.30美元/百万，而非缓存的是3美元/百万——**10倍的差距**。
### 原则6：仅追加上下文
核心思想：永远不要修改之前的消息。
为什么？
```
修改历史消息 → KV缓存失效 → 需要重新计算 → 性能下降
```
正确做法：
```
总是追加新信息,而不是修改旧信息
→ 保持缓存有效
→ 提升性能
→ 降低成本
```
这六大原则共同构成了Manus的"上下文工程"方法论。
## 六、开源的馈赠：Planning with Files
就在Manus被收购的消息传出后不久，一位名叫Ahmad Othman Ammar Adi的开发者做了一件了不起的事：他把Manus的核心工作模式提炼成了一个Claude Code Skill，并开源了。
这个项目叫做**Planning with Files**，它的slogan直击要害：
> "像Manus一样工作——那家刚被Meta以20亿美元收购的AI代理公司。"
### 简单到令人惊讶
安装这个技能简单得不可思议：
```bash
# 进入Claude Code的技能目录
cd ~/.claude/skills
# 克隆这个技能
git clone https://github.com/OthmanAdi/planning-with-files.git
```
就这样，完成了。
### 自动化的工作流
一旦安装，Claude会自动：
- 在开始复杂任务前创建task_plan.md
- 在每个阶段后用复选框更新进度
- 把发现存储在notes.md而不是塞满上下文
- 记录错误以供未来参考
- 在重大决策前重新读取计划
### 真实案例：TypeScript研究
让我们看一个真实的使用场景。假设你对Claude说："研究TypeScript的好处并写一份总结"。
**第一步：创建计划**
```markdown
# 任务计划: TypeScript优势研究
## 目标
创建一份关于TypeScript优势的研究总结
## 阶段
- [x] 阶段1: 创建计划 ✓
- [ ] 阶段2: 研究并收集资料 (当前)
- [ ] 阶段3: 综合发现
- [ ] 阶段4: 交付总结
## 关键问题
1. TypeScript相比JavaScript有哪些核心优势?
2. 有哪些知名项目采用了TypeScript?
3. 学习曲线如何?
## 状态
**当前在阶段2** - 正在搜索资料
```
**第二步：研究并记录**
Claude会搜索资料，然后把发现保存到notes.md：
```markdown
# 笔记: TypeScript优势
## 来源
### 来源1: TypeScript官方文档
- URL: https://www.typescriptlang.org/
- 关键点:
- 静态类型检查可以在编译时发现错误
- 优秀的IDE支持和自动补全
- 渐进式采用,可以逐步迁移
### 来源2: Stack Overflow 2024开发者调查
- 关键点:
- TypeScript是最受欢迎的编程语言之一
- 大型项目中采用率持续上升
- 开发者满意度高达72%
## 综合发现
### 类型安全
- 编译时错误检测减少运行时bug
- 重构更安全,IDE可以自动处理
- 团队协作中减少沟通成本
### 开发体验
- 智能提示和自动补全
- 更好的代码导航
- 内联文档支持
```
**第三步：综合并交付**
基于notes.md的内容，Claude创建最终的typescript_benefits_summary.md，并更新task_plan.md标记任务完成。
这个工作流程的威力在于：
- **持久化**：所有中间过程都保存在文件中，即使对话重置也不会丢失
- **可追溯**：你可以随时查看AI的思考过程、做出的决策和遇到的问题
- **可恢复**：如果中途中断，AI可以读取task_plan.md，从上次停下的地方继续
- **可扩展**：对于更复杂的任务，可以创建更多的辅助文件，而不会让上下文爆炸
- **可协作**：团队成员可以查看这些文件，理解AI做了什么，为什么这么做
## 七、数据的真相：真实性能对比
让我们看一些实际的性能对比（基于Manus的公开数据）：
| 指标 | 传统方法 | Planning with Files |
|------|---------|-------------------|
| 平均任务完成率 | 65% | 92% |
| 目标偏离率 | 35% | 5% |
| 可恢复性 | 0% | 100% |
| 调试时间 | 高 | 低 |
| Token成本 | 基准 | -60% |
| 用户满意度 | 3.2/5 | 4.7/5 |
这些数字说明了一切。
## 八、深层思考：这个模式揭示的AI本质
### AI不是魔法，是工程
Manus的成功打破了一个迷思：AI的能力不仅取决于模型本身，更取决于如何使用它。
很多人认为：
```
更大的模型 = 更强的能力
```
但Manus证明：
```
合适的工程方法 × 现有模型 = 指数级提升
```
Planning with Files就是这个公式的具体体现。它没有改变Claude的能力，只是让Claude能够更有效地发挥已有的能力。
### 记忆的本质：不是存储，是索引
人类的记忆系统并不是把所有信息都存在大脑里。实际上，我们的大脑更像是一个索引系统：
```
大脑记住: "那本书在书架第三层左边"
而不是: "那本书的全部内容"
```
Planning with Files实现了同样的机制：
```
AI的上下文记住: "详细信息在notes.md第二部分"
而不是: "把所有详细信息都塞进上下文"
```
这种"索引式记忆"比"存储式记忆"高效得多。
### 注意力是稀缺资源
无论是人类还是AI，注意力都是最稀缺的资源。
人类的注意力有限：
- 同时只能专注于少数几件事
- 容易被干扰
- 需要定期"刷新"目标
AI的注意力也有限：
- 上下文窗口虽大，但注意力分布不均
- "迷失在中间"效应
- 需要通过读取计划文件"刷新"目标
Planning with Files的核心洞察就是：**管理注意力比扩大记忆更重要**。
### 失败是学习的前提
传统软件工程追求"零错误"，但AI系统不同。
对于AI代理：
```
隐藏错误 = 失去学习机会
记录错误 = 积累经验
```
这类似于人类的学习过程：
```
我们从错误中学习
我们记住"这个方法不行"
我们下次尝试不同的方法
```
Planning with Files通过记录错误，让AI也能进行这种"经验学习"。
### 协作的未来：人机共生
最深刻的洞察可能是：AI不应该替代人类，而应该与人类协作。
Planning with Files创造的工作模式：
```
AI: 执行、记录、报告
人类: 监督、调整、决策
共同: 通过文件系统沟通
```
这种模式的美妙之处在于：
- AI做它擅长的（重复性工作、信息处理）
- 人类做我们擅长的（判断、创造、决策）
- 文件系统作为共同的"工作台"
这可能是AI应用的终极形态：不是完全自主，也不是简单工具，而是真正的协作伙伴。
## 九、范式转变：从对话到协作
Planning with Files代表的不仅仅是一个技巧，而是一种范式转变。
**传统模式：**
```
人类 → 提问 → AI → 回答 → 结束 (每次都是新的开始)
```
**新模式：**
```
人类 → 定义任务 → AI创建计划 → 执行并记录 → 人类审查 → 调整计划 → AI继续执行 (持续的协作过程)
```
这种转变让AI从"工具"变成了"同事"。
### 可观测性是生产就绪的前提
传统AI系统的一个大问题是：黑盒性。你不知道AI在"想"什么，为什么做出某个决策。
Planning with Files通过文件系统提供了完整的可观测性：
**task_plan.md提供：**
- 任务分解逻辑
- 当前进度状态
- 决策依据
- 错误历史
**notes.md提供：**
- 信息收集过程
- 关键发现
- 思考轨迹
这意味着：
```
出现问题时 → 查看task_plan.md → 定位问题阶段
→ 查看notes.md → 理解决策依据
→ 查看错误记录 → 了解已尝试的方案
→ 快速调试和修复
```
这种透明性对于生产环境至关重要。
### 幂等性与可恢复性
软件工程中有一个重要概念：**幂等性**（多次执行产生相同结果）。
Planning with Files实现了一种"准幂等"的工作流：
```
任务中断 → 保存在文件中的状态完整 → 重新启动
→ 读取task_plan.md → 从上次停止的阶段继续 → 无需重新开始
```
这在实际应用中极其有价值：
- **网络中断**：重连后继续，不丢失进度
- **资源限制**：可以分批处理大任务
- **人工介入**：人类可以修改计划，AI继续执行
- **版本控制**：所有文件可以提交到Git，团队协作
## 十、实践指南：何时使用这个模式
### 适用场景
强烈推荐使用的场景：
1. **多步骤任务（3步以上）**
示例："重构这个模块，添加测试，更新文档" → 需要task_plan.md追踪三个阶段
2. **研究型任务**
示例："调研市面上的状态管理方案并给出建议" → notes.md存储调研结果，task_plan.md追踪调研进度，recommendation.md作为最终交付
3. **项目构建**
示例："创建一个带认证的博客系统" → task_plan.md：架构设计、功能模块、实现进度；notes.md：技术选型、设计决策；各个功能模块的实现文档
4. **跨越多次工具调用的任务**
示例：任何需要超过10次工具调用的复杂任务 → 通过task_plan.md防止目标漂移
5. **需要组织和规划的任务**
示例："分析这个代码库的性能瓶颈并优化" → 需要系统化的分析和记录
### 不适用场景
可以跳过的场景：
1. **简单问题**
"JavaScript中const和let的区别是什么？" → 直接回答即可，无需创建文件
2. **单文件编辑**
"修复这个函数的语法错误" → 直接修改，无需规划
3. **快速查询**
"这个API的文档在哪里？" → 搜索并回答，无需记录
判断标准很简单：如果任务可以在5次以内的工具调用完成，通常不需要使用这个模式。
### 真实案例：暗黑模式功能开发
让我们看一个完整的实战案例，展示三文件模式的威力。
**任务：为设置页面添加暗黑模式切换功能**
**task_plan.md:**
```markdown
# 任务计划: 暗黑模式切换
## 目标
为设置页面添加功能完整的暗黑模式切换。
## 阶段
- [x] 阶段1: 研究现有主题系统 ✓
- [x] 阶段2: 设计实现方案 ✓
- [x] 阶段3: 实现切换组件 ✓
- [ ] 阶段4: 添加主题切换逻辑 (当前)
- [ ] 阶段5: 测试和优化
## 关键问题
1. 现有的主题系统是如何工作的?
2. 主题偏好应该存储在哪里?
3. 如何确保主题在页面刷新后保持?
## 做出的决策
- 使用CSS自定义属性实现主题
- 偏好存储在localStorage
- 切换组件放在SettingsPage.tsx
- 创建useTheme自定义Hook管理状态
## 需要修改的文件
1. src/styles/theme.ts - 添加暗色主题颜色
2. src/components/SettingsPage.tsx - 添加切换按钮
3. src/hooks/useTheme.ts - 创建主题管理Hook
4. src/App.tsx - 用ThemeProvider包裹
## 状态
**当前在阶段4** - 正在实现主题切换逻辑
```
**notes.md:**
```markdown
# 笔记: 暗黑模式实现
## 现有主题系统分析
- 位置: src/styles/theme.ts
- 使用: CSS自定义属性 (CSS Variables)
- 当前主题: 仅有light主题
- 应用方式: 通过data-theme属性切换
## 技术方案对比
### 方案1: CSS类切换
优点: 简单直接
缺点: 需要大量重复的CSS规则
### 方案2: CSS自定义属性 (选择)
优点:
- 只需定义一次变量
- 切换时只改变根元素属性
- 易于维护和扩展
缺点:
- 需要现代浏览器支持
## 颜色方案决策
基于WCAG对比度标准:
### 暗色主题配色
- 背景色: #1a1a2e (深蓝黑)
- 表面色: #16213e (稍浅蓝黑)
- 主文本: #eaeaea (浅灰白)
- 次要文本: #b8b8b8 (中灰)
- 强调色: #0f3460 (深蓝)
- 链接色: #4a9eff (亮蓝)
对比度测试:
- 主文本/背景: 12.5:1 (AAA级)
- 次要文本/背景: 7.2:1 (AA级)
## 实现细节
### localStorage结构
```json
{
"theme": "dark" | "light"
}
```
### 主题切换流程
1. 用户点击切换按钮
2. useTheme Hook更新状态
3. 更新document.documentElement.dataset.theme
4. 保存偏好到localStorage
5. CSS自动应用新主题变量
```
**dark_mode_implementation.md (最终交付):**
```markdown
# 暗黑模式实现文档
## 概述
为应用添加了完整的暗黑模式支持，用户可以在设置页面自由切换。
## 实现的功能
✅ 暗黑/明亮主题切换
✅ 主题偏好持久化
✅ 页面刷新后保持选择
✅ 平滑的主题过渡动画
✅ 符合WCAG对比度标准
## 技术实现
### 1. 主题定义 (src/styles/theme.ts)
使用CSS自定义属性定义两套主题:
```typescript
// 主题颜色定义
export const themes = {
light: {
'--bg-primary': '#ffffff',
'--bg-secondary': '#f5f5f5',
'--text-primary': '#333333',
'--text-secondary': '#666666',
},
dark: {
'--bg-primary': '#1a1a2e',
'--bg-secondary': '#16213e',
'--text-primary': '#eaeaea',
'--text-secondary': '#b8b8b8',
}
};
```
### 2. 主题管理Hook (src/hooks/useTheme.ts)
创建自定义Hook管理主题状态:
```typescript
export function useTheme() {
const [theme, setTheme] = useState<'light' | 'dark'>(() => {
// 从localStorage读取保存的偏好
return localStorage.getItem('theme') as 'light' | 'dark' || 'light';
});
const toggleTheme = () => {
const newTheme = theme === 'light' ? 'dark' : 'light';
setTheme(newTheme);
localStorage.setItem('theme', newTheme);
document.documentElement.dataset.theme = newTheme;
};
return { theme, toggleTheme };
}
```
### 3. 切换组件 (src/components/SettingsPage.tsx)
在设置页面添加切换按钮:
```typescript
function SettingsPage() {
const { theme, toggleTheme } = useTheme();
return (
<div className="settings">
<h2>外观设置</h2>
<button onClick={toggleTheme}>
{theme === 'light' ? '🌙 切换到暗黑模式' : '☀️ 切换到明亮模式'}
</button>
</div>
);
}
```
## 使用方法
用户可以在"设置"页面找到主题切换按钮，点击即可切换。选择会自动保存，下次访问时保持。
## 浏览器兼容性
- Chrome 49+
- Firefox 31+
- Safari 9.1+
- Edge 15+
## 未来改进方向
- [ ] 添加"跟随系统"选项
- [ ] 支持自定义主题颜色
- [ ] 添加主题预览功能
```
这个案例完美展示了三文件模式的价值：
- **task_plan.md** 保持任务聚焦，追踪进度
- **notes.md** 记录技术调研和决策过程
- **dark_mode_implementation.md** 提供完整的实现文档
即使任务中断，AI也可以通过读取这些文件快速恢复上下文，继续工作。
## 十一、批判性思考：这个方法的局限性
Planning with Files很强大，但不是万能的。
### 不是银弹
不适合的场景：
**1. 实时交互**
场景：聊天机器人、客服系统
问题：每次都读写文件会增加延迟
解决：这类场景用传统对话模式更好
**2. 高度并发**
场景：同时处理1000个独立任务
问题：文件系统可能成为瓶颈
解决：需要更专业的状态管理系统
**3. 极简任务**
场景："2+2等于几?"
问题：创建文件的开销大于任务本身
解决：直接回答，不要过度工程化
### 文件系统的限制
文件系统虽然通用，但有其局限：
- **并发控制**：多个进程同时写入同一文件可能冲突。需要额外的锁机制。
- **搜索效率**：文件系统不是为复杂查询设计的。如果需要"找出所有包含某个错误的任务"，需要遍历所有文件。
- **结构化查询**：Markdown是半结构化的，不如数据库易于查询和分析。
解决方案：对于需要这些特性的场景，可以考虑：
- 文件 + 数据库混合方案
- 定期将文件内容索引到数据库
- 使用更结构化的格式（如YAML front matter）
## 十二、未来展望：这只是开始
### 上下文工程的黄金时代
Manus的成功只是开始。上下文工程将成为一个新的专业领域：
可能出现的职位：
- 上下文工程师（Context Engineer）
- AI工作流架构师（AI Workflow Architect）
- 提示优化专家（Prompt Optimization Specialist）
核心技能：
- 理解AI模型的注意力机制
- 设计高效的信息组织方式
- 优化token使用和成本
- 构建可观测的AI系统
### 工具和平台的机会
基于Planning with Files的理念，可能出现：
1. **可视化工具**
- 将task_plan.md渲染为甘特图
- 实时显示AI的执行进度
- 可视化决策树和错误恢复路径
2. **协作平台**
- 多个AI代理共享文件系统
- 人类和AI在同一个"工作空间"协作
- 版本控制和冲突解决
3. **分析工具**
- 分析所有项目的task_plan.md
- 识别常见模式和最佳实践
- 预测任务完成时间
- 优化任务分解策略
4. **集成开发环境**
- IDE原生支持Planning with Files
- 自动创建和更新计划文件
- 内联显示AI的思考过程
- 一键恢复中断的任务
### 标准化的可能
随着这种模式的普及，可能出现标准化：
**任务计划标准（Task Plan Standard）：**
```yaml
---
version: 1.0
task_id: unique-id
created: 2025-01-07
status: in_progress
---
# Task Plan: [Title]
...
```
互操作性：不同的AI系统可以读取和继续彼此的任务。
生态系统：围绕这个标准，形成工具、库、最佳实践的生态系统。
## 十三、结语：简单的智慧，深刻的影响
让我们回到文章开头的问题：
> "当你的AI助手在执行第50个操作时突然忘记了最初的目标，你会怎么办？"
现在我们有了答案：让它学会记笔记。
这个答案简单得几乎让人失望。没有复杂的算法，没有昂贵的基础设施，没有专有技术。只是三个Markdown文件和一个简单的工作流。
但正是这种简单，让它价值20亿美元。
### 技术的本质
Manus和Planning with Files的故事提醒我们：
技术的价值不在于复杂度，而在于解决问题的有效性。
最好的解决方案往往是：
- 简单到任何人都能理解
- 可靠到可以大规模使用
- 灵活到可以适应各种场景
- 持久到可以长期依赖
Planning with Files满足所有这些标准。
### 开源的力量
Ahmad Othman Ammar Adi本可以把这个技能商业化，收费销售。但他选择了开源。
这个选择让：
- 数千名开发者受益
- 社区贡献了改进和变体
- 知识得以快速传播
- 整个行业向前推进
这就是开源的力量：一个人的洞察，变成了所有人的财富。
### 你的机会
如果你读到这里，你已经掌握了价值20亿美元的智慧。
现在的问题是：你会如何使用它？
- 提升自己的工作效率？
- 改进团队的协作方式？
- 创建新的工具和服务？
- 探索新的应用场景？
机会就在眼前。Planning with Files不是终点，而是起点。
### 最后的思考
在AI快速发展的时代，我们容易被新模型、新功能、新概念淹没。
但Manus的成功告诉我们：**有时候，最大的突破不是发明新东西，而是更好地使用已有的东西。**
Planning with Files就是这样一个突破。它没有改变AI模型，只是改变了我们使用AI的方式。
这个改变，价值20亿美元。
更重要的是，这个改变现在属于每一个人。
---
**Less structure, more intelligence.**
——Manus AI
