做工业设备的 HMI 项目，免不了要跨好几个层面：下位机通信、上位机软件、数据库，再加一层给别人看的网页看板。这类项目一旦认真做起来，跟 AI 助手的对话很快就会超过一次会话能装下的量——不是因为对话轮数多，而是因为项目本身横跨的东西太杂，硬塞进一个对话里，越到后面上下文越乱，AI 也越容易把三天前讨论过的方案当成没讨论过。
这篇写的不是怎么用 AI 写代码，而是怎么把一个跑得比较久的项目，拆成多个对话去做，又不让它散架。
先说信号：什么时候该拆
不是所有项目都需要拆。真正该拆开的信号，通常是这几种：
- 项目里有几个几乎不相关的子系统，比如下位机通信协议和网页前端，讨论其中一个几乎用不到另一个的上下文；
- 单次会话已经长到要频繁提醒 AI「我们之前说过 xxx」；
- 项目会隔几天甚至几周才回来继续做一次，中间很容易忘记上次停在哪；
- 涉及的密钥、账号、服务器地址这些「事实性信息」，比讨论过程本身更值得留存。
如果符合两条以上，拆开会话通常比硬撑在一个对话里划算。
核心思路：把状态和过程分开存
一次对话结束后会留下两类东西：一类是讨论过程——为什么选 A 方案不选 B，踩过什么坑，这些是过程，过一阵子就没必要细看；另一类是状态——现在系统长什么样，密钥放在哪，下一步要做什么，这些是状态，新开一个对话第一件事就要能拿到。
问题就在这里：AI 助手的每一次新对话，默认是看不到上一次对话内容的。如果只是把状态混在几十轮的讨论记录里，新对话开始时既没法快速定位，也没法保证信息是最新的。
解决办法是单独维护一份「交接文档」，只写状态，不写过程：
- 一句话概览——这个项目是干什么的；
- 地址与账号位置——各个系统的入口在哪，账号在哪，只写位置，不写密码本身；
- 整体架构图——哪怕是文字画的箭头图，也比一段话描述清楚；
- 密钥与配置放在哪——同样只写位置；
- 各模块现状——按子系统分小节，写清楚当前做到哪一步；
- 运维手册——常见问题先看哪里；
- 待办与已知问题——列成清单，而不是散在记忆里；
- 协作约定——比如「涉及密码的地方由本人手动输入」这类边界，写一次，以后每次新对话都遵守。
每次新开一个对话，第一步不是直接开始干活，而是让 AI 先读这份文档。每次一段工作告一段落，再让它把文档更新一遍。文档本身放在项目里长期存在，对话可以开了关、关了开，文档不会丢。
举个例子：一个 HMI 项目怎么拆
拿一个典型的工业设备监控 HMI 项目来说，它至少能拆成这几块，每块开单独的对话去推进：
- 下位机通信——设备的通信协议、数据采集逻辑，专注在协议本身，不需要知道网页长什么样；
- 上位机软件——现场用的客户端程序，涉及界面交互和本地数据处理；
- 数据管理与同步——数据库结构、跨库同步工具，这部分的讨论跟上面两块几乎不重叠；
- 网页看板——给管理层或运维看的可视化界面，关心的是数据怎么展示，不关心协议细节。
这四块各自开对话，各自推进，共用同一份交接文档做「总控」。文档里按模块分小节，每个小节记录这个模块现在的状态、用到的技术栈、下一步计划。遇到跨模块的决策——比如数据库表结构变了，上位机和看板都要跟着改——就在文档里单独记一条待办，提醒自己下次在对应的对话里同步处理。
如果 AI 助手本身还带有跨对话的长期记忆，可以把长期不变的事实（比如「这个项目用的是 C#/.NET」「设备通过 CAN 总线通信」）交给记忆去存，把会频繁变化的当前状态交给交接文档去存。两者分工不同：记忆管「不常变的事实」，文档管「现在进行到哪」。
容易踩的坑
- 文档写完就不更新了。交接文档只有在每次对话结束前认真更新，才有意义。写完扔在一边，几周后它比没有还误导人。
- 把密钥值直接写进文档。只写「密钥放在服务器的 .env 里」，不要把值本身粘贴进去——文档往往比想象中更容易被分享出去。
- 一份文档塞进所有细节。子系统一多，交接文档会越写越长。到了某个规模，不如把每个子系统单独开一份状态文档，交接文档本身只做索引，链接到各个子文档。
- 忘了写"协作约定"。哪些操作需要先确认、哪些密码不能代填、发布前要不要过一遍人工确认——这些边界写进文档里，比每次对话里重新强调更可靠。
一份可以直接抄的交接文档模板
# <项目名> 交接文档
更新日期：
## 1. 一句话概览
## 2. 地址与账号位置
## 3. 整体架构
## 4. 密钥与配置放在哪（只写位置）
## 5. 各模块现状（按子系统分小节）
## 6. 运维手册（出问题先看这里）
## 7. 待办与已知问题
## 8. 协作约定这套模板不复杂，核心就是逼自己把「状态」从「过程」里剥离出来，单独存一份，让每一次新对话都能在几分钟内接上上一次的进度——不管中间隔了一天还是一个月。