当你的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中。

## 遇到的错误

- [2025-01-03] FileNotFoundError: config.json未找到
  → 解决方案: 创建了默认配置文件

- [2025-01-03] API超时
  → 解决方案: 使用指数退避重试,成功

- [2025-01-03] 类型错误: user对象未正确await
  → 解决方案: 添加await关键字,问题解决

这样做有三个巨大的好处：

1. 避免重复犯错：当AI再次遇到类似情况时，可以查看历史记录，直接采用已验证的解决方案
2. 积累知识：错误记录成为了宝贵的知识库，后续任务可以参考
3. 提升透明度：用户可以清楚地看到AI遇到了什么问题，如何解决的，建立信任

一个真实的例子

让我们看一个实际案例：

# 任务计划: 修复登录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代理公司。"

简单到令人惊讶

安装这个技能简单得不可思议：

# 进入Claude Code的技能目录
cd ~/.claude/skills

# 克隆这个技能
git clone https://github.com/OthmanAdi/planning-with-files.git

就这样，完成了。

自动化的工作流

一旦安装，Claude会自动：

• 在开始复杂任务前创建task_plan.md
• 在每个阶段后用复选框更新进度
• 把发现存储在notes.md而不是塞满上下文
• 记录错误以供未来参考
• 在重大决策前重新读取计划

真实案例：TypeScript研究

让我们看一个真实的使用场景。假设你对Claude说："研究TypeScript的好处并写一份总结"。

第一步：创建计划

# 任务计划: TypeScript优势研究

## 目标
创建一份关于TypeScript优势的研究总结

## 阶段
- [x] 阶段1: 创建计划 ✓
- [ ] 阶段2: 研究并收集资料 (当前)
- [ ] 阶段3: 综合发现
- [ ] 阶段4: 交付总结

## 关键问题
1. TypeScript相比JavaScript有哪些核心优势?
2. 有哪些知名项目采用了TypeScript?
3. 学习曲线如何?

## 状态
**当前在阶段2** - 正在搜索资料

第二步：研究并记录

Claude会搜索资料，然后把发现保存到notes.md：

# 笔记: TypeScript优势

## 来源

### 来源1: TypeScript官方文档
- URL: https://www.typescriptlang.org/
- 关键点:
  - 静态类型检查可以在编译时发现错误
  - 优秀的IDE支持和自动补全
  - 渐进式采用,可以逐步迁移

### 来源2: Stack Overflow 2024开发者调查
- 关键点:
  - TypeScript是最受欢迎的编程语言之一
  - 大型项目中采用率持续上升
  - 开发者满意度高达72%

## 综合发现

### 类型安全
- 编译时错误检测减少运行时bug
- 重构更安全,IDE可以自动处理
- 团队协作中减少沟通成本

### 开发体验
- 智能提示和自动补全
- 更好的代码导航
- 内联文档支持

第三步：综合并交付

基于notes.md的内容，Claude创建最终的typescriptbenefitssummary.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追踪三个阶段

1. 研究型任务

示例："调研市面上的状态管理方案并给出建议" → notes.md存储调研结果，task_plan.md追踪调研进度，recommendation.md作为最终交付

1. 项目构建

示例："创建一个带认证的博客系统" → task_plan.md：架构设计、功能模块、实现进度；notes.md：技术选型、设计决策；各个功能模块的实现文档

1. 跨越多次工具调用的任务

示例：任何需要超过10次工具调用的复杂任务 → 通过task_plan.md防止目标漂移

1. 需要组织和规划的任务

示例："分析这个代码库的性能瓶颈并优化" → 需要系统化的分析和记录

不适用场景

可以跳过的场景：

1. 简单问题

"JavaScript中const和let的区别是什么？" → 直接回答即可，无需创建文件

1. 单文件编辑

"修复这个函数的语法错误" → 直接修改，无需规划

1. 快速查询

"这个API的文档在哪里？" → 搜索并回答，无需记录

判断标准很简单：如果任务可以在5次以内的工具调用完成，通常不需要使用这个模式。

真实案例：暗黑模式功能开发

让我们看一个完整的实战案例，展示三文件模式的威力。

任务：为设置页面添加暗黑模式切换功能

task_plan.md:

# 任务计划: 暗黑模式切换

## 目标
为设置页面添加功能完整的暗黑模式切换。

## 阶段
- [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:

# 笔记: 暗黑模式实现

## 现有主题系统分析
- 位置: 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结构

{ "theme": "dark" | "light" }

### 主题切换流程
1. 用户点击切换按钮
2. useTheme Hook更新状态
3. 更新document.documentElement.dataset.theme
4. 保存偏好到localStorage
5. CSS自动应用新主题变量

darkmodeimplementation.md (最终交付):

# 暗黑模式实现文档

## 概述
为应用添加了完整的暗黑模式支持，用户可以在设置页面自由切换。

## 实现的功能
✅ 暗黑/明亮主题切换
✅ 主题偏好持久化
✅ 页面刷新后保持选择
✅ 平滑的主题过渡动画
✅ 符合WCAG对比度标准

## 技术实现

### 1. 主题定义 (src/styles/theme.ts)
使用CSS自定义属性定义两套主题:

// 主题颜色定义 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管理主题状态:

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)
在设置页面添加切换按钮:

function SettingsPage() { const { theme, toggleTheme } = useTheme();

return ( 外观设置 {theme === 'light' ? '🌙 切换到暗黑模式' : '☀️ 切换到明亮模式'} ); }

## 使用方法
用户可以在"设置"页面找到主题切换按钮，点击即可切换。选择会自动保存，下次访问时保持。

## 浏览器兼容性
- Chrome 49+
- Firefox 31+
- Safari 9.1+
- Edge 15+

## 未来改进方向
- [ ] 添加"跟随系统"选项
- [ ] 支持自定义主题颜色
- [ ] 添加主题预览功能

这个案例完美展示了三文件模式的价值：

• task_plan.md 保持任务聚焦，追踪进度
• notes.md 记录技术调研和决策过程
• darkmodeimplementation.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的执行进度
• 可视化决策树和错误恢复路径

1. 协作平台

• 多个AI代理共享文件系统
• 人类和AI在同一个"工作空间"协作
• 版本控制和冲突解决

1. 分析工具

• 分析所有项目的task_plan.md
• 识别常见模式和最佳实践
• 预测任务完成时间
• 优化任务分解策略

1. 集成开发环境

• IDE原生支持Planning with Files
• 自动创建和更新计划文件
• 内联显示AI的思考过程
• 一键恢复中断的任务

标准化的可能

随着这种模式的普及，可能出现标准化：

任务计划标准（Task Plan Standard）：

---
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