和 AI 写代码几个月后,我发现最大的问题不是代码质量

你有没有过这种感觉？

AI 刚开头的几个回复还正常，过了十几轮对话之后，它开始忽略之前说好的约定。你翻回去看，发现它确实写了你要的东西——但那是三屏以前了。现在的它，像换了个脑子。

不是它换了脑子。是上下文窗口里的信号已经淹没在噪声里了。

这几个月我一直在用 AI 写代码，从最初的新鲜感到后来的失控感，再到慢慢摸索出一些门道。这篇文章不是什么成熟的方法论，只是一个实践者的复盘——如果你也在经历类似的困惑，可能会有点用。

01｜先说说那个根本性的不对称

传统软件开发的基本单元是 “变更”——一个 commit，一次 diff。人的工作记忆是连续的，你知道自己在做什么，也知道做过的约定。

AI 开发的基本单元变成了 “会话”——一个 Session，一次上下文窗口。

这就产生了一个不对称：

人：时间连续，记忆持久 ←→ AI：时间离散，每次重启

你吃过的大部分苦头，根源都在这里。

最关键的认知转变：不要把 AI 当工具用，要把它当协作者管。协作者的认知边界是一个会话，不是一个项目。

02｜那个最容易忽视的概念：上下文债务

技术债务你应该很熟了——代码写得不干净，后面改起来就越来越慢。

上下文债务是一个平行概念：

上下文债务 = 每次启动新会话时，需要重新加载的信息总量。

债务越高，启动成本越高。每写一个文件，就产生一笔债务——下个会话必须知道它的存在。最可怕的是，上下文债务的累积速度比技术债务快得多。一个晚上就能产生十几个文件，但每个新会话都要求你把它们重新”教会”AI。

怎么管理这笔债务？几个思路：

1. 集中债务，不扩散
把关键约定写到一个地方（比如项目根目录的一份备忘录），而不是分散在几十个源文件里。这样每次新会话只需要读这一个文件，而不是翻遍代码库。

2. 定期清理，不等觉得”该清了”
大多数人的习惯是”等觉得上下文脏了再清理”。但问题在于——你察觉到”脏了”的时候，上下文已经污染了 2-3 轮对话。察觉延迟本身就是成本。 固定节奏清理（比如每 3-4 次对话强制做一次），比靠感觉更靠谱。

3. 做懒加载
每次只加载当前任务需要的信息，而不是整个项目。这和代码里做懒加载的道理一样——不要让 AI 为它不需要的信息腾出上下文空间。

4. 已完成的模块应该可以”关掉”
一个模块写完了、测试过了、不再改了——它的知识就应该归档，不再占用后续会话的上下文。存档的意义不是留着以后看，而是让当前工作空间变干净。

03｜怎么拆任务才合理

这是最实操的部分，也是我花最久才搞明白的。

一个简单标准：一个会话应该刚好能完成一个独立可验证的任务。 什么叫”独立可验证”？

• 这个任务可以单独测试（有明确的通过条件）
• 这个任务可以单独回退（不依赖其他还没写的代码）
• 这个任务应该在一个会话内能完成（上下文窗口塞得下）

如果预估要做的事情超过某个阈值（比如会改动超过 200 行代码），就拆。

拆任务是一件反直觉的事——你觉得自己在”浪费时间切分”，但实际是在为 AI 腾出上下文空间。一个塞得太满的会话，质量会断崖式下跌。

最终你会发现，整个开发的节奏感是这样的：

第 1 次对话：拆任务 → 读约定 → 写测试 → 实现 → 验证 → 记录
第 2 次对话：（同上）
第 3 次对话：（同上）→ ★ 同步记忆 → 开启新会话
...
第 N 次对话（模块完成时）：生成存档 → 关闭模块

不是”需要的时候做”，是”固定节奏做”。 时钟驱动比事件驱动更可靠——事件驱动的反馈太慢了。等你觉得”该同步了”，上下文已经脏了好几轮。

04｜关于信任，你需要一个阶梯

你对 AI 写的代码放心吗？

大部分人其实是不放心的，但迫于效率压力，又不得不让它写。这种矛盾感很消耗精力。

我后来想明白一件事：信任不是二元的（信/不信），它是分级的。

L1 - 完全不信：AI 写草稿，人重写  → 验证成本最高
L2 - 审阅式信任：AI 写，人 review → 验证成本中高
L3 - 测试验证信任：AI 写，测试验证 → 验证成本中
L4 - 规格验证信任：AI 写，测试验证，人只看需求是否满足 → 验证成本最低

每升一级都有明确的条件，不是靠感觉：

从 L1 到 L2（你可以只 review，不再重写）：

• 代码行数不超过一次 review 的合理负荷（比如 500 行以内）
• 没有超过 3 层嵌套
• 变量名能表达意图，没有遗留的调试代码
• 文件功能单一，一个文件不超过 300 行

从 L2 到 L3（你可以让测试来验证，不再人工逐行 review）：

• 自动化测试覆盖率 ≥ 80%
• 边界条件已覆盖（空值、异常输入等）
• 测试可以独立运行（不依赖外部服务）
• 所有测试全部通过

从 L3 到 L4（你只需要看”需求是否满足”，不再看代码细节）：

• 每个功能都能追溯到对应的需求文档
• 需求文档精确到可验证（不仅仅是”用户登录”，还包括输入/输出/异常处理）
• 每次改动涉及的文件可以枚举
• 没有”需求里没有的”功能被实现

这个阶梯不是理论——它回答了一个很实际的问题：我到底要在哪个环节花时间验证？

05｜还有两个小的体会

1. 写测试不只是为了质量

这是让我最意外的一个发现。TDD（测试驱动开发）在 AI 开发里有一个额外的价值——测试是最精确的上下文锚点。

当你写”用户应该能登录”这个需求时，AI 可以有很多种理解。但当你写”给定用户名和密码，调用 login 接口，返回 token”这个测试时，AI 只有一个理解方向。

测试比自然语言精确得多。它既规范了 AI 的行为，也作为下个会话的上下文锚点——新会话不需要重读你写的需求描述，只需要读测试就知道要做什么。

2. AI 开发的主要挑战不是”写代码”，而是”保持结构的完整性”

这个”结构”有三层意思：

• 任务结构
  
  ：模糊的需求需要被拆解为可验证的原子单元
• 知识结构
  
  ：信息需要分层存储（长/中/短期记忆各有各的位置）
• 节奏结构
  
  ：固定节奏做维护，而不是”等出问题了再修”

一个好的信号：当你不再纠结”AI 这次写得对不对”，而是自然地知道”什么时候该新建对话、什么时候该同步记忆”时，这个节奏就养成了。

写在最后

几个月前我也在踩这些坑——总觉得 AI 写的代码”飘”，不受控，有时候甚至不如自己写。后来意识到问题不在 AI，在我自己的管理方式。

AI 开发本质上不是新的编程范式，而是一种新的知识传递方式。你从一个”写代码的人”，变成了一个管理 AI 认知边界的人。写代码还是你在写，但节奏感和结构感需要重新学习。

用一句不太恰当但贴切的话总结：写代码的能力没变，管理上下文的能力得重新练。

这篇文章来自一个 AI 开发实践者的复盘。如果你也在用 AI 写代码，有类似的困惑或相反的体会，欢迎留言交流。