核心观点 功能范围需要一个非代码、非对话的物理边界。Agent X-Ray 的边界是 20 块设计画板加一个可交互原型；两条硬规则让它成为约束：样式零改动，画板上没有的功能不许实现。扩边界有三条路径——先改画板、明示的例外、只换数据源——每条都有判据。边界本身也要维护：编号只增不改，计数三处一致，云端为正本。
一个能干的 agent 遇到没有明说的地方，会用自己的判断补上。多加一个参数，多做一层防御，顺手把「看起来应该有」的功能做了。每一处补充单独看都有道理，累积起来就是范围失控——项目做了很多没人裁定过的东西，而真正要做的反而没做完。
人也会范围蔓延，但 agent 蔓延得更快、更安静。它不会在站会上说「我顺便加了个功能」，它只是把代码写了。
围栏是画板做的。画板上没有的东西，再好也进不来。
对付范围蔓延，提示词写得更细没有用。有用的是让边界可查证：「这个功能画板上有没有」是一个能被任何人、任何 agent 用同一种方法回答的是非题。
Agent X-Ray 的 design/ 目录里有三样东西：
CLAUDE.md 的项目定位里写着：「功能范围的唯一边界是设计稿。」ROUNDS.md 开头也写着：「本 roadmap 与各轮任务卡严禁新增设计稿没有的功能。」审查者的速记第一条：「设计稿没有的功能一律判超范围。」
三处说同一件事，三种角色（所有者、实现者、审查者）依据同一个载体。
规则 7：非必要不得修改前端页面样式，不做视觉 review。 画板已是终稿且前端已实现，接后端只许换数据源（demo 数据 → API / SSE），不许动样式、布局、className、token、动画参数。确因接线需要改结构时，任务卡写明理由与影响范围，且不得偏离对应画板。
规则 8：严禁实现设计稿没有的功能。 站点访客功能范围等于画板加原型；管理功能有单独的裁定清单；文档里的安全与部署要求是约束不是功能。新功能想法进 BACKLOG 等所有者裁定，不进任何轮次任务卡。
两条规则合起来的效果：实现 agent 的自由度被收窄到「把画板上画的东西用真实数据跑起来」。它不需要做视觉判断（所以不做视觉 review），也不需要做产品判断（所以不加功能）。它需要做的是工程判断——这正是它擅长的。
边界不是不能变，而是变的方式要有规则。项目里长出了三条路径：
正门是先画后做；侧门是写明理由的例外；小门是只换数据源不动样式。
| 路径 | 判据 | 实例 |
|---|---|---|
| 先改画板，再进轮次 | 访客可见的新功能或新视觉 | R-TOOLS 加工具面板（画板 1f–1g）；R-SKILLS 加技能库 tab（2f–2h）；R-PERF 加加载态与错误态（2i–2k）；R-TOOLCARDS 加折叠态与展开态（2l–2m） |
| 明示的例外，写明理由 | 不是产品功能，是隐私、合规或运维需要；形态取对画板偏离最小的 | R-VISITOR 会话删除入口（隐私）；R-TABS 顶部 tab 呈现开关（备案审核窗口期的合规运维动作）；R-TITLE 会话命名工具（前端零改动，新增的是「标题由谁写」） |
| 只换数据源或渲染时机 | 规则 7 明确允许的 | R-PERF 的 T1：详情页只预渲染当前文件，不碰设计稿 |
第一条路径是正道。ROUNDS.md 里的原话：「扩边界的正确顺序是先改设计稿、再进轮次——本条不是被绕过，是先被改了。」R-TOOLS 之后的每次扩边界都按这个顺序：所有者在画布上画好新画板，拉回 design/，画板计数更新，然后才开轮次。
第二条路径是例外，条件很严：它不是产品功能。R-VISITOR 的删除入口是「站点公开可访问之后，访客需要一条自己清掉对话的通路」——隐私功能；R-TABS 的呈现开关是「备案审核窗口期要求内容可撤下，靠发版一来一回是两次构建加传镜像加重建容器」——合规运维动作。例外的形态要对画板偏离最小：删除入口是行 hover 时露一个复用既有按钮样式的叉，绝对定位不占布局宽度，不 hover 时该行与画板一字不差；呈现开关是三个 tab 全部可见时前端与画板一字不差，不新增画板。
第三条路径最窄：只换取数来源与渲染时机，像素不变。R-PERF 的详情页原来把整包 markdown 全部预渲染，改成只渲染当前文件——载荷降了九成，画面一样。
三条路径都要写进 ROUNDS.md 的修订记录：走的是哪条、为什么、是不是例外。到 2026-09-03，修订记录有十次。
例外最容易被滥用，所以它的写法要固定。以 R-TABS 为例，CLAUDE.md 规则 8 下面的子条目是这样写的：
写法的要点是把例外的边界画得比功能本身还清楚。例外一旦没有边界，它就会变成下一个功能的借口。
边界是一个活的东西，维护它有成本，这些成本也要工程化。
编号只增不改。 画板编号与硬性规则编号同一约定：3a–3e（原来的管理后台五页）废弃后，号段作废不复用，新画板从后面顺延。任务卡、审查记录、代码注释里引用过的编号永远指向同一块画板。
三处计数一致。 「共 N 块画板」在 design/README.md、CLAUDE.md 规则 8、ROUNDS.md 功能边界三处出现，每次增删都要三处一起改。项目里画板数量的变化：15（设计冻结）→ 12（删 5 加 2）→ 15 → 18 → 20。每次变化三处同步，漏一处就自相矛盾。
云端为正本，本地只拉不改。 设计稿在设计工具的云端项目里，本地 design/ 是存档。所有者曾经明确要求「不要直接用设计稿覆盖本地，请注意合并」——那时云端稿落后于本地（本地有两次提交的动画优化没写回云端），实现 agent 用 git 的三方合并把两边并起来，再把合并稿写回云端。之后的口径：本地只拉不改；拉新稿时先跑一个 diff 计数（新稿相对本地有没有删掉任何一行），为零就直接覆盖，不为零才找 base 三方合并并核验。后来两次拉稿判据都是零，直接覆盖。
画板落后代码时要补。 R-SKILLS-2 给工具面板加了第四组，画板 1f/1g 上还没画。前端按任务卡的建议值先接上，所有者裁定「正常展示出来就好了」，补画记 BACKLOG。这是边界暂时落后于实现的例子，处理方式是记下来，而不是假装画板已经有了。
新画板由设计 agent 在画布上画。给它的提示词也有固定写法，项目里留了两份（rounds/round-perf/design-prompt.md、rounds/round-toolcards/design-prompt.md）。结构是：
这份提示词的核心是约束优先于自由。设计 agent 和实现 agent 一样会自己加戏；给它 token 表和「不新造视觉语言」的硬约束，它产出的画板才能被实现 agent 逐像素对照。
R-PERF 的三块画板带来了全站唯一的新语汇——错误态的品牌色实心主按钮（既有按钮语汇只有 ghost）。它是画板明确定为出口层级的，不是实现自造。这一点在 ROUNDS.md 修订记录和 design/README.md 里都写了。
画板上没有、所有者也没裁定过的想法，去 rounds/BACKLOG.md 的「功能提案（需所有者裁定）」区。项目里的例子：Skills 页要不要显示「agent 可用」徽标（画板没有，不做）；会话区卡片与右栏 Timeline 互相定位（技术上现成，画板没画，等裁定）；生图工具要不要给访客一个尺寸入参（属机制扩面，等裁定）。
这些条目的共同格式：想法是什么、技术上难不难、画板上有没有、要做需要先改什么。它们不是被拒绝的，是在等一个裁定。等到裁定「做」，就走第一条路径：先画，再进轮次。
agent 顺手加功能。 边界可查证之后，这类改动在审查时会被判超范围。审查者速记第一条就是干这个的。
画板落后代码而没人记。 补画记 BACKLOG，不假装画板有。
把例外当常态。 例外要写边界，边界要比功能清楚。三个例外之后，项目里的每一次扩边界都回到了「先画后做」。
本地改了设计稿不写回。 云端与本地分叉，下次拉稿覆盖掉本地改动。口径是本地只拉不改，或者改完立刻写回。
给自己的项目定义功能边界的物理载体——设计稿、接口契约、需求文档都可以，但必须是一个能被查证的东西，不是对话记忆。然后写下扩边界的三条路径各自的判据，以及例外的写法（至少包括：为什么是例外、边界到哪、与载体的关系）。
苏公网安备32011402012723号