规格住进画布之后：设计稿、说明文档与智能体引用的单一真相源怎么保
一、省事是真的，新问题也是真的
据公开报道，有设计工具推出了把说明文本、画布和智能体放进同一个工作区的能力。本篇不评价这个产品的功能完整度，也不去猜它有哪些没公开的字段与命令，只讨论它带来的一种工作方式：规格不再住在文档系统里，而是住在设计稿旁边。
这件事解决的老问题很实在。过去设计稿和说明文档是两套东西，改一边不改另一边，实现方拿到冲突信息只能靠问，问完还没有记录。两者同处一地之后，这种不一致至少在物理上变难了。但它同时把三个原本被文档分隔掩盖的问题推到台面上：谁改的、按哪一份实现、智能体读的是哪个时刻的版本。
这三个问题在只有人改稿的时候还不严重，因为有人的判断在场。改稿方从一种变成两种，另一种是程序，严重性就完全不同了。程序不会在改之前先问一句这个字段是不是刚被调整过，它按读取瞬间看到的内容执行；程序也不会区分哪一格是定稿、哪一格是顺手留下的草稿。所以规格住进画布之后，真正要补的不是排版，而是同步与验收机制。
我们的立场也很具体：这类工具改变的是协作载体，不是需求岗的工作内容。把规格写成可判定句子这件事，过去在文档里做，现在在画布里做，难度只增不减。
二、单一真相源的三种实现路径与各自的失效方式
同处一地不等于同源。按谁决定谁，有三种实现，每种都有自己的坏法。
| 路径 | 谁被当作权威 | 常见失效方式 | 适合的团队形态 |
|---|---|---|---|
| 画布为主，文档为辅 | 视觉对象与图层 | 文字条件写不进图层，状态与边界靠人脑记忆，实现方各自补全 | 视觉主导、交互简单的小团队 |
| 文档为主，画布为呈现 | 规格条目 | 画布走在前面试新东西，文档滞后，评审时出现稿上有、文里没有 | 流程成熟、评审严格的项目 |
| 两者同源于结构化规格 | 结构化条目本身 | 条目缺稳定编号，改一次就断引用；绑定关系只靠位置近似 | 有交付验收要求的外包或跨部门项目 |
第三种最理想，也最容易做得不像。所谓同源，画布上的对象应当是从同一份结构化规格投影出来，而不是复制一份文本粘在画布边上。判断方法很朴素：改规格里的一个值，画布上的对应对象是否必然变化；改画布上的对象，规格里是否留下可追溯的变更记录。两个方向都不需要人再抄一遍，才算同源；只要有一个方向靠人抄，就退化成第一种或第二种。
失效方式里最难防的是位置近似。人和智能体都会本能地用靠近来表示关联，但画布上的位置会变，图层会挪，分组的折叠状态会影响读到的内容。凡是靠位置建立的关系，都会在第一次大范围整理画布时静默断开。
三、条目要可寻址，不然改动无法被引用
要让别人能说我按第几条实现，规格条目必须先有稳定编号。这一节讲三件最小的事。
编号要跟着条目走，不能跟着标题走。以段落标题当引用，一旦调整顺序或者合并两节，所有引用就指向别的东西。稳定的做法是每条一个固定标识，标题可以随便改，标识不复用，废弃的标识保留占位。
改动要能被引用，意思是一次修改必须说清楚改了哪一条、从什么改成什么、影响到哪些绑定对象。只有一段变更说明的版本记录不够用，因为它没有主语。有了条目级标识，变更才有主语，评审才能问一句这条被谁批准了。
还有一条经常被漏：编号要出现在界面里，而不是只在数据结构里。设计评审时人是靠眼睛找东西的，如果每条规格旁边看不见标识，标注、评论、验收记录就会回到靠截图和位置来指认的老路。
四、设计对象与规格的绑定粒度分三档
绑太粗会漏，绑太细会维护不动，所以粒度要按团队现状选，并且写进协作约定。
屏幕级最省，一整屏对一段规格，适合还在讨论整体流程、状态尚未定型的阶段。它的代价是所有局部条件都写在段落里，实现方要自己判断哪句适用于哪个控件。组件级是多数团队的稳定档位，一个组件对若干条规格条目，好处是复用组件的改动天然带着影响范围。状态级最细，把默认、加载、错误、禁用、边界数据这类状态逐一绑定到条目上，适合交付验收严格、异常态容易被漏做的项目，代价是维护量随组件数线性增长。
三档之间应当允许切换，但切换要留记录。同一个画布上一半按组件级、一半按屏幕级，是最常见的混乱来源，通常出现在赶工阶段。规则可以简单：以定稿范围为单位选档，未定稿区域允许粗一档，定稿时补齐。
五、智能体读画布的三个坑与变更通知
工具接入智能体之后，读画布这个动作本身要设防，因为智能体不会主动怀疑自己读到的是不是最终值。
第一个坑是读到未定稿的草稿。画布上放着的常常同时有探索稿和定稿，界面对人是有视觉区分的，对程序未必。必须有机器可读的状态标记，让草稿区默认不进入被引用范围，而不是靠放在角落来表示。
第二个坑是读到隐藏图层。隐藏图层在人眼里是不看的，在读取里可能仍在结果集中，于是那些废弃方案会变成实现依据。读取范围要明确写清包含还是排除隐藏对象，两种都行，但不能默认。
第三个坑是把示例数据当约束。设计稿里的名字、金额、条数是为了画面好看填的，智能体很容易把这些当成业务规则，例如把示例里的最大显示条数写进实现。凡是稿面上的样例值，都要和真实约束分开标注。
变更通知则要回答三个问题：谁被影响、影响哪一条、要不要重新验收。通知不能只发一段摘要，它要落到条目标识和被绑定对象清单上，让被通知方能直接定位。要不要重新验收要有可判定的触发条件，通常三条里中一条就要重走：边界值变了、状态集合变了、被引用范围变了；其余的措辞修订不必打扰别人。
六、核心交付物：四列对照表与先做的三件事
下面这张表是我们建议直接抄走的形态，一格一条规格，四列互相引用。
| 规格条目 | 设计对象 | 验收点 | 引用方 |
|---|---|---|---|
| 条目标识加一句话规则，只写可判定的内容 | 组件或状态名，不用位置描述 | 写成能被判定通过与否的句子，含边界值与失败形态 | 谁按这条实现或校验，写明角色与批次 |
填写规则有三条硬要求。第一，验收点必须是可判定的句子：能回答通过与否，才叫验收点，像交互要流畅这种不算，得写成什么情况下不超过什么程度。第二，设计对象一栏只写名称和层级路径，不写在哪块区域；对象改名要留旧名映射，否则历史引用全部失效。第三，引用方一栏要带读取时刻，说明是按哪一版规格实现的；智能体产出的改动更要填这一格，事后才能区分是它读错了版本，还是版本本身没定。
落地时先做三件事，顺序不要变。第一件，给现有规格条目补编号，并且约定编号不复用。第二件，把验收点全部重写成可判定句子，这一步工作量最大，但跳过它，后面所有同步机制都只是在同步两份模糊。第三件，定义定稿标记与锁定规则，明确谁有权解锁、解锁后哪些引用方需要被通知。
规格住进画布，好处是消灭了两份东西不一致这件事；代价是把一致性变成了需要机制维持的状态。能不能守住，取决于条目有没有身份、绑定有没有粒度约定、读取有没有版本时刻这三件不那么显眼的事。洹拓在新项目里把这三件当作画布的开工条件，缺任何一件就不允许智能体进入引用范围，这条限制看着严，但它避免了一次又一次按错版本实现的返工。