你这个问题本质上是在问：

“系统有没有 canonical source / single source of truth（SSOT）”

但很多 AI 不会主动做 architecture audit。
你得用一种会逼它：

• 追数据流

• 查入口

• 查 fallback

• 查 shadow state

• 查 duplicated truth

的问法。

否则它只会：

已更新 README
已同步代码

但根本没验证：

真正运行时是不是还存在第二真源

最有效的一句（直接复制）

请不要只检查文档和声明。

我要你做的是：

“唯一真源（Single Source of Truth / Canonical Source）审计”。

请逐层验证：

1. 当前功能真正的 runtime source 是什么

2. 是否还存在：

   • fallback source

   • duplicated state

   • shadow cache

   • legacy path

   • derived snapshot 被误当真源

   • UI 仍引用旧入口

   • build artifacts 残留旧逻辑

3. 哪些文件仍然能绕过 canonical path

4. 是否存在：

   • README 已更新但运行时未切换

   • 页面入口已改但内部组件仍直连旧数据

   • embed 已上线但旧 external link 仍可见

   • 新状态和旧状态同时生效

5. 请明确输出：

   • canonical source

   • deprecated source

   • compatibility layer

   • runtime mirror

   • cache layer

   • generated artifact

6. 不要只 grep 名字。
   要沿着：
   用户入口 → state → data flow → render → runtime behavior
   实际追踪。

7. 最后给我：

   • 仍违反唯一真源原则的位置

   • 可以删除的旧路径

   • 还没真正完成迁移的部分

   • 哪些只是“文档完成”但系统实际上没完成

为什么这句有效

因为它强迫 AI：

从：

“代码存在”

变成：

“系统真实运行行为”

这是两个完全不同的层级。

你还可以加一句（非常重要）

不要把：

“新系统已经存在”

误判为：

“旧系统已经失效”。

我要的是：
验证旧路径是否真的已经失去 runtime authority。

这个特别关键。

很多 AI 会犯：

发现新逻辑存在
=
认为迁移完成

但实际上：

旧逻辑还在运行

再高级一点的问法（强烈推荐）

这是架构师级 prompt。

请做 canonical architecture audit。

目标不是“代码是否存在”，
而是：

系统当前到底由什么在真正驱动。

请找出：

• source of truth

• runtime authority

• derived data

• synchronization layer

• cache mirror

• compatibility adapter

• stale path

• dead path

• hidden coupling

• implicit fallback

尤其检查：

“表面迁移完成，
但 runtime authority 仍在旧系统”

的问题。

你这个项目现在最容易出的问题

你已经开始：

• Pinterest shell

• visual partition

• runtime mirror

• visual manifest

• embed layer

• OpenList layer

这种系统。

所以最危险的是：

“看起来改完了，其实 authority 还在旧地方”

例如：

README:
Pinterest 是 canonical
 
实际上：
/visuals/ 还在读 static JSON

或者：

首页按钮:
Pinterest embed
 
实际上：
Command Palette 还在 external link

你应该重点让 AI 查的

1. Runtime authority

真正驱动页面的是谁？

不是：

谁定义了 schema

而是：

谁最后 render 了 UI

2. Derived snapshot

很多项目会：

DB
↓
snapshot.json
↓
UI

结果：

snapshot 变成了真源。

这是经典灾难。

3. Compatibility layer

很多：

visualItems

名义是 compatibility。

但：

某个组件还在直接引用。

于是：

它又重新变成真源。

4. Hidden fallback

最容易漏。

比如：

pins || localPins || staticPins

你以为 Pinterest 是真源。

其实：

运行时 fallback 到 localPins。

最后一条（非常关键）

你一定要逼 AI：

“列出仍可删除的旧路径”

因为：

真正完成迁移的系统，

一定会出现：

这些东西已经能删了

如果 AI 不敢删：

说明它也知道：

authority 还没真正迁走。