把需求放进Figma Specs，可以让设计、说明和Agent共享上下文，但“Agent读到了”不等于“验收标准已经明确”。一条“支持CSV导入”的需求，仍然可能被实现成十几种互不相同的行为。真正减少返工的，是把输入范围、边界、失败结果和待定问题写到可以核对。

下面以一个虚构的工件数量导入功能为例，演示如何从一句需求推到可执行的边界用例。它不是Figma产品实测，也不是完整导入服务；重点是哪些决定必须先由人说清。Read in English。

Specs提供共享载体，不替团队做决定

Google News收录的DevOps.com 10月16日报道讨论了Figma的Specs与开发协作更新。追溯Figma 10月15日原始公告，Specs是画布上的协作上下文容器，可以承载Markdown，并引用设计、图表等内容；编码Agent可通过MCP获得相关上下文。公告称其面向付费计划逐步开放Beta。

这些是产品提供的上下文组织能力，不是对生成代码正确率或交付速度的独立保证。把同一份说明连接到设计对象，可以减少资料散落，但不会自动解决“哪个版本有效”“遇到冲突听谁的”“怎样算完成”。

对开发者更实用的变化，是可以把问题留在它描述的设计旁边，再把同一组决定交给实现者。接下来讨论的是本文建议的写法与验证方法，不是厂商要求的固定格式。

一句“支持CSV导入”藏了哪些分歧

先只列三项：文件不得超过5M、包含工件编号和数量、数量必须有效。即使实现者没有任何恶意，5M可能被解释为5,000,000字节或5×1024×1024字节；字段可能按名字匹配，也可能按列序；01可以被视为有效整数，也可以被当作格式错误。

如果团队没有决定这些问题，Agent只能补全假设。生成了漂亮界面、成功导入一张样例表，都不能证明它采用了产品想要的规则。让Agent列出歧义是有用的，让它替团队悄悄决定业务语义则会把问题推到验收阶段。

本例选择一组明确但非通用的规则：文件原始字节数必须大于0且不超过5 MiB；表头恰好按item_id、quantity顺序；数量为1到9999的ASCII十进制，不允许前导零。这些是教学选择，不是CSV标准对所有产品的要求。

先把单位、边界和失败结果写成句子

“5 MiB”还应写出5,242,880字节，说明恰好等于上限时允许，超过1字节时拒绝。这个决定可以用字节数比较验证，不必真的生成一个大文件来证明运算规则。

本例表头大小写敏感，也不自动去除空格；因此Item_ID与item_id不是同一名称。表头决定了额外列、顺序与命名是否接受；数量规则决定了0、负数、空白、全角数字与前导零怎样处理。与其只给一张正常样例，不如把最容易产生分歧的相邻输入放在一起。

失败结果也应确定：展示哪类错误，指出哪一行，已有数据是否保持不变，修正后能否重试。这里不把这些尚未实现的行为混进下面的谓词测试；它们需要独立的界面、解析与存储验证。例如“任一行失败则不写入任何行”和“只跳过错误行”都合理，但不是同一个产品行为，必须先选定。

把边界写成12个可运行用例

下面使用Python标准库，验证大小、表头和数量三个谓词。代码不解析CSV，也没有连接Figma、上传文件或修改数据库；它的作用是把规则变成可讨论的真假判断。

# Original acceptance predicates; not a full CSV importer or Figma API.
import re
MAX_BYTES = 5*1024*1024  # 5 MiB

def size_allowed(n):
    return type(n) is int and 0<n<=MAX_BYTES

def header_allowed(columns):
    return columns == ["item_id","quantity"]

def quantity_allowed(text):
    # ASCII decimal1..9999, without signs, spaces or leading zeros.
    return isinstance(text,str) and re.fullmatch(r"[1-9][0-9]{0,3}",text) is not None

cases = [
    ("size boundary",size_allowed(MAX_BYTES),True),
    ("size over",size_allowed(MAX_BYTES+1),False),
    ("empty",size_allowed(0),False),
    ("MB is not MiB",size_allowed(5_100_000),True),
    ("header exact",header_allowed(["item_id","quantity"]),True),
    ("header reordered",header_allowed(["quantity","item_id"]),False),
    ("minimum",quantity_allowed("1"),True),
    ("maximum",quantity_allowed("9999"),True),
    ("zero",quantity_allowed("0"),False),
    ("leading zero",quantity_allowed("01"),False),
    ("non-ASCII",quantity_allowed("１２"),False),
    ("too large",quantity_allowed("10000"),False),
]
for label,actual,expected in cases:
    assert actual is expected,label
print("12 acceptance cases passed")

本地执行的12个用例全部通过。其中5,100,000字节在5 MB十进制限制下会超限，在本例5 MiB限制下却允许。这个输入比一个远低于两种上限的小文件更能揭示单位歧义。

测试通过只说明谓词符合这组期望值。若期望值本身来自误解，测试也会稳定地证明错误规则。验收示例需要由负责业务决定的人确认，不能只由同一个生成过程同时编规则、写实现、写期望。

可运行示例之后，还有哪些空白

真实CSV导入还涉及编码、BOM、引号、分隔符、换行、空行、重复表头、重复工件编号以及错误行处理。本例只处理三个规则，不能因为测试文件是绿色就宣称“CSV导入完成”。

可以给每条要求一个稳定编号，并分别标记已决定、待决定、已验证。待决定不是默认允许，也不是默认拒绝；它意味着实现者应提出问题或限制范围。若允许先做原型，交付说明应保留这些空白。

示例只验证输入形状与数量格式，不验证item_id是否存在、是否重复，也不验证导入权限。把未覆盖项明确写出来，能防止下一位读者把局部证据当作完整功能承诺。

文档变了，测试与实现怎样跟上

假设下一轮评审决定允许额外CSV列，旧的“表头恰好两列”就过期了。不能只修改说明，继续保留旧测试，然后让Agent以通过测试为目标把新行为改回去。

一次规则变更应同时说明为什么改、影响哪些用例、哪些实现路径需要重新核对。版本标识与设计节点引用的作用，是让审读者知道代码对应哪一份意图；最新的画布不天然等于一次历史构建当时读到的内容。

不必把每个草稿都变成沉重流程，但真正决定边界的内容应有明确归属。多个并行草稿、评论和Agent建议冲突时，应有一个被确认的结论，而不是把所有文本一次性塞进上下文，期待模型自行猜出优先级。

长说明要围绕决策组织

增加上下文并不意味着越长越好。一个有效段落应该回答一个实现问题，给出必要的设计引用，并说明如何观察结果。重复背景、过时结论和互相矛盾的示例，会消耗注意力而不是提升可靠性。

把“目标”与“非目标”写清，能帮助Agent停止无关扩展。比如本轮只验证本地文件并给出预览，不自动写入库存；如果后来需要入库，再另写权限、失败回滚和并发规则。不能让一个“导入”词语承担所有未说明的动作。

关联到设计图时，还应覆盖窄屏、长错误文本、空状态与失败状态，不能只附一张正常页面。本文的验收谓词没有验证这些体验，它们需要实际页面与交互证据。

给Agent一份能说明“还没完成”的交付要求

除了输出代码，可以要求它逐条列出：实现了哪条规则、用哪个用例核对、哪里仍未覆盖。对不确定项，允许明确报告，而不是用流畅的总结把空白盖住。

站内完成声明核查文章讨论如何把声明追溯到执行证据；Specs更早一步，负责让“应该完成什么”有清楚边界。需求和证据两端都清楚，才有条件判断一次Agent交付是否符合目标。

如果这组边界例子帮你把一条模糊需求改成了可验收的决定，欢迎通过文末支持区自愿支持。

来源与验证范围

新闻发现来自Google News收录的10月16日报道，产品功能以10月15日Figma原始公告为准。两幅图、虚构导入规则和代码为原创教学内容；未做Figma服务或完整导入系统实测。