为什么项目刚起步时，我反而更关心控制面资产有没有先长出来#

如果按很多人对“快速起盘”的直觉，GraphSpec 现在最应该做的，似乎是尽快把图渲染出来，再往上叠 AI 能力。毕竟一个可见的界面，总比几份文档和几条规则更容易让人产生“项目开始了”的感觉。

但我现在越来越不吃这一套。因为 AI Native 项目里，最危险的从来不是起步慢，而是带着错误边界起步很快。

一旦边界没钉住，AI 会把模糊的意图放大得非常快。今天多写出来的是几个文件，明天固化下来的就是错误的包边界、错误的命令面、错误的任务切分方式。等团队意识到方向不对时，返工的已经不是某个模块，而是整条协作链路。

所以我现在看项目起盘，第一关注点根本不是“功能有没有先冒出来”，而是：

• 有没有一份能钉主线的 Spec
• 有没有一组长期稳定的 Rules
• 有没有开始区分未来哪些能力该进 Skills，哪些该进 SOP
• 有没有模板和校验基线，避免每一轮都从聊天记录重新发明流程

这些东西在传统项目里很容易被误判成“后面再补的文档层”。但在 AI 协作环境里，它们其实是一套真正的控制面资产。没有这套东西，后面的代码越多，项目只会越玄。

先分清一件事：OpenSpec 和 GraphSpec 根本不是一层东西#

如果这一层不先分开，后面再谈 Spec、Rules、Skills，几乎一定会串味。

GraphSpec 现在最容易被误解的一点，就是名字里也带一个 Spec。很多人下意识会把它理解成“一个更图形化的 OpenSpec”，或者“给 OpenSpec 套了个图形壳”。这条理解路径非常危险，因为它会直接把产品定位带歪。

我现在更愿意用一种很硬的方式去区分它们：

• OpenSpec 负责文本化 change/spec 流程
• GraphSpec 负责结构化架构上下文控制面

OpenSpec 更适合承载 proposal、design、tasks、验收口径、变更历史这类线性资产；GraphSpec 更适合承载结构关系、影响半径、graph 草稿、结构差异、空间化浏览这类网状资产。

这两者不是替代关系，而是互补关系。

如果把项目推进链路写完整一点，我现在更愿意把它写成：

Issue -> Spec -> Graph -> Code -> Validation

这里最关键的一点是，Graph 不是“文档配图”，而是一层独立资产。它存在的意义，是为了回答文本 spec 很难稳定回答的问题：

• proposal 里定义的边界，和仓库里的真实结构是不是已经漂了
• 这个底层模块一改，会波及到哪些包、哪些文件、哪些依赖边
• AI 现在拿到的到底是一整个仓库，还是一个 blast radius 的局部切片

如果没有这层结构化资产，OpenSpec 再清楚，AI 也仍然会在“空间认知”这件事上天然吃亏。

实战切片：为什么 GraphSpec 不能被写成“OpenSpec 的图形界面”

如果把 GraphSpec 定义成“给 OpenSpec 做一层图形界面”，后面很容易出现两个后果：

• 产品会不断往“把文本 spec 画出来”这条路上滑
• 团队会默认 GraphSpec 的职责是展示，而不是控制结构上下文

而现在更稳的写法是：

• OpenSpec 继续负责 change/spec 流程
• GraphSpec 负责把结构上下文变成一等资产
• 两者后面通过 bridge 互相校验、互相增信，而不是互相吞掉

这个差异看起来像概念区分，实际上决定了后面到底是做一个辅助视图，还是做一个真正的架构控制面。

Spec 先行，不是让你先写一份更大的总施工图#

很多团队一说“规范先行”，脑子里其实想的是另一件事：先写一份巨长的 proposal，把未来几个月的功能、阶段、路径全部摊开，然后直接把这份总纲交给 AI 执行。

这种做法在人类单线程时代都经常失真，到了 AI 协作时代只会更危险。因为 AI 很擅长把一份模糊但气势很大的文档，执行成一坨边界已经漂掉的实现，而且它越高效，回滚代价越高。

GraphSpec 这轮起盘真正让我想明白的，是另一个更稳的判断：

项目早期最需要的 Spec，不是“全量实施说明书”，而是“program seed”。

也就是说，第一份 Spec 的主要职责不是替未来所有细节拍板，而是先做四件更重要的事：

• 钉住产品定位
• 钉住阶段路线
• 钉住当前阶段的非目标和验收口径
• 钉住后续 issue 应该怎么切

这时候 Spec 的价值，不在于“已经把未来都想透了”，而在于“让后面的细化不再反复重定义项目”。

所以我现在看 GraphSpec 那份总纲 change，不会把它理解成总施工图，而会把它理解成路线图锚点。它负责告诉后面的 issue：你们该沿着哪条主线继续长，而且哪些方向虽然重要，但现在不要混进来。

实战切片：program seed 到底值钱在哪

GraphSpec 当前的总纲 change 如果只负责“解释 Phase 1 怎么做”，它的价值其实有限，因为后面大家还是会反复问：

• writable graph 什么时候进来
• Skill 调 CLI 要怎么接
• OpenSpec bridge 是不是也算当前范围

但当它被写成 program seed 之后，它就能多承担一层职责：

• 先把 phase map 钉住
• 先把“当前只正式规格化哪一段”钉住
• 先把未来阶段留在粗粒度，不让它们污染当前实现

这时候后面的每个 issue，才知道自己应该长在什么位置上。

Rules 的价值，是把聊天里的临时脾气变成长期约束#

很多人对 Rules 有一种误解，觉得它不过是“把一些注意事项写进 AGENTS.md”。这话不算错，但太低估它的作用了。

我现在越来越觉得，Rules 真正值钱的地方，在于它把原本只存在于聊天语境里的判断，变成了未来所有执行默认要遵守的边界。

比如在 GraphSpec 里，这类规则其实都很关键：

• 架构层变更需要人工确认
• 不要顺手做无关重构
• 删除超过一定规模的代码要人工确认
• 每个新增 package 至少要有 README、导出说明、最小示例和验证方式

这些要求如果只出现在一次对话里，下一个 Agent、下一个 issue、下一轮执行，很可能就全部丢了。可一旦它们被写进长期规则，项目的协作重心就会发生变化：AI 不再只是“每次重新揣摩作者这次大概想要什么”，而是在一个更稳定的护栏里工作。

所以 Rules 不是文档装饰，而是协作基线。

它的作用非常直接：减少反复解释，降低每轮对话的上下文成本，并把一些必须反复提醒的判断，变成默认成立的工程条件。

实战切片：GraphSpec 里哪些东西应该沉淀成 Rules

我现在会把下面这些内容优先视为 Rules，而不是临时说明：

• 哪类变更需要人工确认
• 新增 package 的 README 最低完整度要求
• 开发前先读最近层级 AGENTS.md / README.md
• 不允许顺手做无关重构
• 完成后必须说明改了哪些文件、怎么验证

这些规则一旦稳定下来，后面的每轮协作就不用再从“先对齐工作方式”开始。

Skills 和 SOP，看起来像一类东西，其实职责完全不同#

这是很多 AI Native 团队后面必然会踩的坑。

大家一开始都会说“把流程沉淀下来”，但沉淀着沉淀着，Skills、SOP、模板就会全部混成一锅。结果是：真正应该被工具化的能力没有被工具化，真正应该由人做判断的流程却被假装自动化了。

我现在更愿意这样分：

• Skills 是稳定执行面
• SOP 是稳定流程面

Skills 解决的是：某种高复用、低歧义、输入输出相对稳定的能力，能不能被封成一个明确接口，让 AI 以后不用每次重新组织动作。

SOP 解决的是：一条多步流程要不要有固定节奏，谁先判断，谁后执行，在哪一步该停下来做人类确认。

放到 GraphSpec 上，这个区别其实非常清楚。

未来“AI 通过命令面查询 graph、提交 graph 修改请求、读取执行结果”，这是 Skills 该接住的事。因为它要的是稳定输入、稳定输出、稳定副作用。

而“收到一个需求后，先归属 phase，再决定要不要新开 issue，要不要给这个 issue 补 proposal / design / tasks”，这更像 SOP。它不是一个单步动作，而是一条需要持续做判断的流程。

一旦两者混掉，团队就会特别容易做出两种极端：

• 把本来应该是流程判断的问题，硬塞给某个 Skill
• 把本来可以工具化的稳定动作，永远留在口头协作里

这两种情况都会让项目越来越难治理。

实战切片：GraphSpec 后面哪些更像 Skills，哪些更像 SOP

更像 Skills 的：

• 查询某个 cluster 的 children
• 查询某个 node 的直接入边和出边
• 提交一份 graph draft 变更请求
• 读取某次 graph 操作的结果和错误

更像 SOP 的：

• 收到新需求后先判断属于哪个 phase
• 判断当前问题是不是需要独立 proposal / design / tasks
• 判断这次 graph 变更是否必须走人工确认
• 判断某条 bridge 能力现在是方向描述，还是已经到可立项阶段

一个看的是稳定执行接口，一个看的是稳定决策顺序。

模板和代码生成真正该在什么时候上场#

项目刚起步时，大家通常都很想尽快拥有模板和代码生成。因为它们太像“效率已经开始飞轮化”的标志了。

但我现在的判断反而更克制：模板可以早，代码生成要晚。

模板之所以可以早，是因为它主要在降低空白页成本。issue 模板、proposal seed、评审清单、验收清单，这些东西越早出现，后面的沟通成本越低。

代码生成则完全不同。代码生成不是帮你思考问题，它只能放大已经被确认的结构。换句话说，只有当边界足够稳、契约足够清楚时，codegen 才会开始真正创造价值；否则它只会把猜测快速固化成仓库事实。

GraphSpec 当前阶段就特别适合拿来说明这个区别。

现在最该先定下来的，是：

• graph snapshot 的最小契约
• CLI 命令面的最小边界
• packages/cli、packages/core、packages/web 的基本职责
• 后续 issue 和小规格应该怎么长

这些东西在没定稳之前，越早做自动生成，后面返工越大。因为你不是在复制成熟结构，而是在复制还没收敛的误判。

实战切片：GraphSpec 当前最不该急着自动生成什么

我现在最不想在这个阶段看到的，不是“代码写得慢”，而是这些东西被过早批量生成：

• 一整套未来 Phase 2/3/4 的命令协议
• 还没定稳的 graph edit 数据模型
• 假装已经成熟的 MCP / Skill 接口层
• 一堆为未来多端准备、但当前根本没进入范围的壳子代码

这些生成看起来很忙，实际上都在提前锁死还没收敛的判断。

真正的控制面，不是把所有东西都文档化，而是知道什么该沉淀成哪一层资产#

到这里，Spec、Rules、Skills、SOP、模板和代码生成，其实已经不是一串并列名词了。它们各自对应的是不同层次的问题。

• Spec 负责定义当前 slice 的目标、边界、非目标和验收口径
• Rules 负责沉淀长期稳定的协作约束
• Skills 负责封装高复用、低噪声、可审计的执行能力
• SOP 负责把判断顺序和协作节奏固定下来
• 模板负责降低空白页成本
• 代码生成负责在结构稳定后放大产能

真正成熟的控制面，不是“每样都写一点”，而是知道当前项目最缺的是哪一层，然后先补那一层。

GraphSpec 现在之所以先长 Spec、Rules、README、基线测试和占位骨架，而不是先长一大堆炫目的功能，就是因为这条主线当前最缺的不是输出速度，而是判断不漂。

这也是为什么我越来越不愿意把“规范先行”理解成一种道德姿态。它根本不是为了显得更专业，而是为了让后面的每一次执行都不至于重新掉回混乱里。

看一个沉淀动作值不值钱，就看它能不能让下一个 issue 长得更稳#

我现在会用一个非常直接的标准判断沉淀有没有做对：

它有没有让下一个 issue 更容易、更准确地长出来。

如果某份规则、某个 Spec、某个模板写完之后，后面的协作还是要从头解释项目是什么、当前 phase 是什么、哪些东西不该做，那这个沉淀大概率还没真正发挥价值。

反过来，如果一轮沉淀之后，后面的 issue 已经自然能沿着同一条主线长出来，大家不再反复重定义边界，那这些资产就开始真正变值钱了。

对 GraphSpec 来说，这个变化其实已经很明显了。当前最重要的成果，不是某个功能被写完，而是：

• 项目定位已经不再漂成“单纯依赖图工具”
• 当前 phase 已经被收成 CLI-first 的只读 graph
• 后续路线已经被保留成粗粒度 phase map
• tasks 已经开始朝 issue seeds 的方向写，而不是巨型施工单

这意味着后面的推进终于可以从“每一轮都重新定义问题”，进入“沿着同一条路线逐步细化问题”。

这就是控制面资产真正开始工作的时候。

顺着往下读

下一篇：《任务拆解与执行节奏》

当 Spec、Rules、SOP 和执行面都开始长出来之后，真正的问题就变成了：第一批 issue 到底怎么切，怎么避免 AI 一上来又把事情做大。