让 AI 先同步现状，再开始工作

我最早开始意识到这件事时，正在看一个知识空间可视化页面。

页面上有一组层级节点。远处只显示少量重要标签，放大以后，父节点会被更细的子节点替代；点击节点，还应该能继续看到对应的业务信息。这个想法听起来并不复杂，甚至每一个局部要求都很合理。

但真正进入实现现场后，我先撞上的并不是模型够不够聪明，而是这些局部规则放在一起以后，开始互相打架：父节点什么时候消失？子节点出现后，原来的语义还成立吗？用户点击一个当前看不清的节点时，下一层到底应该打开什么？动画、颜色、层级和交互是不是在说同一件事？

那一刻我才发现，AI 之前读到的项目，已经不是当前正在发生的项目。

我以前遇到这种情况，第一反应通常是继续补提示词：再补一点背景，再补一段交互约束，再把前面的讨论重新整理一遍。但这一次，继续补材料只会让一个已经落后的上下文变得更完整。

所以我后来更认可一个执行前动作：让 AI 先同步现状，再开始工作。

问题不是提示词太短，而是起点已经错了

如果 AI 输出得不对，人很容易先怀疑自己的提示词：是不是背景没写全？是不是约束没列清？是不是还缺一个例子？

这些问题有时确实存在。但在存量项目和持续变化的任务里，还有一种更隐蔽的情况：提示词本身并不短，资料也不少，只是它们描述的是不同时间点的项目。

实现已经变化，旧文档没有同步；

需求方向已经收窄，早期讨论仍然被当成当前约束；

页面已经换了一套交互，AI 还在按照原来的层级关系继续生成。

这时 AI 不是完全没有理解。它只是认真地理解了一个过期版本。于是输出会出现一种很危险的状态：结构完整、表达顺畅、局部都说得通，但合在一起无法和当前项目对齐。

一个页面为什么会把上下文问题放大

回到那个匿名的可视化页面。

它至少同时包含四类规则：

页面上看起来只是一个小问题	实际需要确认的现实
远处只显示少量标签	当前用户在这个距离上到底需要看见什么
放大后父节点被子节点替代	父子节点的业务语义是否真的支持替换
点击节点进入下一层	当前节点是否有稳定的详情和下一步上下文
动画表现层级变化	动画规则是否和数据结构、交互逻辑一致

这张图不是在定义某个具体页面，而是把问题压缩成三个必须同时成立的关系：远景看什么，放大后如何展开，点击之后还能不能进入同一套业务语义。

早期材料把其中一套层级和交互假设写得很完整，但实现已经在变化。AI 如果继续按照旧材料生成页面说明、交互方案和配置，产物只会越来越完整，却越来越难和当前实现对齐。

当时真正需要回答的，不是“再给 AI 一段什么提示词”，而是：

当前真实的数据层级和节点关系是什么；
当前实现已经支持哪些缩放、展开和点击行为；
哪些标签规则已经确认，哪些只是讨论中的想法；
这次到底要解决页面展示、交互语义，还是先补齐上下文。

我后来先暂停继续生成，做的不是重新写一份更长的说明，而是把这些问题逐项对齐。对齐之后，下一步才重新变得清楚：有些内容应该进入需求，有些内容应该进入设计，还有一些内容根本不该继续生成。

我现在会先同步哪些现实

这次经历之后，我把“开始工作前先同步现状”压缩成四件事。

1. 先确认当前主线和主要资产

先确认这次工作属于什么主线，当前真正有效的需求、方案、实现和关键产物在哪里。

这不是要求 AI 把整个仓库读一遍，而是先回答：这次应该从哪里开始看？

如果入口都没有选对，后面的详细分析越认真，偏差可能越大。

2. 再确认最近已经成立的决定

项目里最容易被忽略的，不是旧资料，而是最近刚刚改变方向的决定。

例如：

某条路线已经被放弃；
某个范围已经明确排除；
原本的实施任务改成了验证任务；
某个问题已经从“要不要做”变成了“怎么收口”。

这些决定如果没有进入当前上下文，AI 就会把历史讨论和当前方向混在一起。

3. 把当前风险先说出来

同步现状不能只报“现在有什么”，还要说明“现在最容易在哪里出错”。

风险可能来自：

上下文已经过期；
来源之间互相矛盾；
需求还有歧义；
实现和文档没有同步；
上一步交付没有留下可回查证据。

把风险先摆出来，能避免 AI 把风险当成普通背景，继续沿着错误路径向前推进。

4. 最后选择工作模式

同一个项目，在不同时间点需要的动作可能完全不同：

现状不清，先同步现实；
需求不稳，先收敛边界；
边界稳定，再做方案设计；
方案确认，才进入实施；
结果产生，最后做验证和收口。

如果每次都默认“直接开始做”，AI 会把所有问题都翻译成执行问题。很多时候，正确的下一步其实是先不要执行。

现状同步不等于把所有资料读一遍

我不认为现状同步应该变成另一种重量级文档工程。

它不是把所有历史资料重新读一遍，也不是生成一份更长的项目日报，更不是用一份摘要替代需求判断、方案设计或人的最终决定。

我更愿意把它理解成一次入口检查：

我们现在在哪；
哪些信息仍然有效；
哪些决定已经成立；
最大风险是什么；
这次应该把问题交给哪个阶段处理。

它的价值不在于让 AI 立刻产出更多内容，而在于让 AI 不要在还没选对入口之前就开始产出。

这也是我现在理解入口同步的方式：它不是工作流里的装饰步骤，而是决定任务应该进入哪一个阶段。

如果只保留五个问题

如果不想引入完整流程，我觉得至少可以先问：

当前真正要推进的主线是什么？
最近有哪些决定已经改变了原来的方向？
当前最重要的风险和未闭环是什么？
这次缺的是现状、需求、方案、实施还是验证？
在开始执行前，还需要谁确认哪个边界？

这五个问题不一定需要写成复杂模板。重要的是，它们要发生在 AI 认真生成内容之前，而不是生成一大段方案之后，才发现入口选错了。

结尾：先把 AI 拉回现实，再让它开始工作

我现在不再把“给 AI 更多上下文”简单等同于“让 AI 更了解项目”。

真正有用的上下文，不是资料越多越好，而是当前现实、有效决定、风险和下一步之间的关系足够清楚。

AI 可以帮助我们分析、设计和执行，但它不应该替我们假定项目当前是什么状态。开始工作之前，先把人和 AI 拉回同一份现实，往往比继续补充提示词更重要。