产品规格文档从来不是孤立的文本。它带着线框图、需要回应的监管PDF、必须遵守的API契约、还有人谈判过的利益相关者幻灯片。很长一段时间里，我的规格树里只有Markdown文件被Git追踪；而那些支撑它们的证据，却在Confluence里腐烂，在共享驱动器里迷失，在聊天窗口的粘贴截图里丢失。
这周我发布了维护的VS Code扩展v0.9.7版本。修复的形状才是我想写的——因为那个显而易见的版本会是错的。
先交代背景：我是SPECLAN的创建者，这是一个管理产品规格的VS Code扩展，用带YAML前置元数据的Markdown文件实现——Git原生，每个需求一个文件，按层级树组织。这个模式（Markdown + YAML + Git）没有工具也能工作；SPECLAN只是我观察并工程化解决下面这个设计问题的地方。
规格有生命周期：草稿→评审→已批准→开发中→测试中→已发布→已弃用。一旦规格获批，团队就对其内容达成一致；实现据此构建、测试和发布。自然的下一步想法是：附件也应该遵循同样的纪律。如果你不能悄悄重写已发布需求的正文，你也不能悄悄换掉附在上面的API契约。所以：一个通用的附件机制，处处实行变更请求治理。
我画了这个方案。没发布。测试两天后，我意识到这个显而易见的版本把仪式感强加给了根本不该走评审流程的材料。
看看一个项目一年实际积累的附件：
前两类是钉在特定实体上的证据，有特定生命周期，治理本身就是目的。后四类是参考资料——跨多个规格共享，不属于任何一方，不绑定任何规格的发布周期。
如果我强迫第二类走变更请求流程，每次架构图更新都需要一个4阶段评审，针对……哪个规格？它不属于任何一个。评审者会批准一个变更，却没有父实体可以对比。仪式感没有锚点。
所以我发布了两套故意不同治理机制的附件系统：
这个分裂来自一个观察：锁定适用于有状态的实体；项目文件夹没有状态。规格有状态。项目文件夹没有。不存在"已发布的项目"来把关变更，所以统一的治理机制对两种情况之一会没有锚点。
每个功能、需求或变更请求都在其.md文件旁边获得自己的artifacts/文件夹：
在所见即所得编辑器中，Artif
热门跟贴