为什么这里必须把项目亮出来#

Part 1 的前四篇，讲了范式转移、讲了工具分工、讲了控制面、讲了产品判断。如果到这里就停，读者脑子里装了一堆"听起来对"的认知，但一落地就会回到老路。

因为没有一个真实项目在手里，所有判断都会停在抽象层面。

所以 Part 1 的最后一篇，不是继续讲道理，而是把项目正式摆上桌面。

GraphSpec 是什么#

上一篇文章讲了它从 ContextWeaver 到 SpecSync 再到 GraphSpec 的三轮收敛。这里不重复过程，只钉住方向：

GraphSpec 是一个可交互的架构态势感知工具。

它解决的核心痛点：AI 的上下文有限，改一个功能的时候它看不到全貌。 开发者需要一种方式，让自己和 AI 都能从一个宏观全貌逐步下钻到微观细节——不是暴力地把所有信息塞进去，而是按需加载、渐进披露。

但这里要特别说明：上一篇文章里展示的那个 PRD，只是一个非常粗糙的起点。 产品形态、功能边界、技术栈——这些都没有定，也不应该在这一步定。它们会在后面的开发过程中逐步收敛。如果现在就把一切都锁死，那恰好违反了前面四篇文章一直在讲的"先判断、再执行"的原则。

GraphSpec 不会一上来就做一个大而全的东西。按照 AI Native 的开发节奏，我计划的起点大概是这样的：

V0.1：一个本地 CLI，能做两件事就够了。

就这么简单。没有云端，没有 MCP，没有 Agent，没有多端。一个 CLI + 一个本地可视化页面。

然后从这个最小的起点开始，根据实际开发中遇到的问题，逐步往上加能力。

从 V0.1 往后，大致的方向是清晰的，但具体的路径会跟着实际开发走：

但这些都只是"可能会"。具体做什么、不做什么、先做什么后做什么，会在开发过程中根据实际需求一个一个决定。 这本身也是这本书想展示的：AI Native 开发不是先画完一张完美的蓝图再动手，而是从一个最小可用的东西开始，让 AI 帮你快速验证假设，然后在过程中不断收敛。

不是随便选的项目都能撑住一本书。GraphSpec 之所以适合，是因为它的方向天然会逼出 AI Native 开发的几条核心线索：

它是一个 Spec 工具。 它的本质是让 Issue、Spec、架构图、代码这几样东西保持同步。这意味着它天然适合作为前面那条主线的落点：开发模式不再只是“想到什么就直接写实现”，而是先把需求、约束、架构判断和交付结果收进同一条可追踪的链路里。

它需要渐进式披露。 无限嵌套的架构图不可能一次性全部塞给 AI，必须设计一套按需加载策略。这是 Context Engineering 最核心的教学场景。

它需要多种 AI 交互形态。 不只是 MCP——可能会有 CLI 命令、Skill、Sub-Agent。AI 不只是帮你改架构图，还可能帮你理解 Issue、生成 Spec、校验代码与架构的一致性。这是 Harness Engineering 和 Agent 编排的教学场景。

它需要护栏。 AI 能改架构图，但你不能让它随便改。人类确认、变更审计、回滚机制——这些都是 Guardrails 设计的教学场景。

它会持续演进。 从本地单机到云端服务，从 CLI 到 MCP 到各种 AI 接入形态。产品的功能和形态会在开发过程中不断迭代。这意味着长期治理、版本迁移、架构演进这些话题都有真实的载体。

把这些线索串起来，读完这本书并跟着做完 GraphSpec 之后，你不只是"学会了几个工具"，而是手里有一个完整的、你自己会用的开发者工具——以及一套可以迁移到其他项目的 AI Native 开发方法论。

项目亮出来了，方向有了，起点也清楚了。但还没开始建。

下一步不是直接开写代码，而是先把项目底板钉稳——PRD 怎么收敛、需求怎么裁剪、技术栈怎么选、仓库怎么搭、规范怎么立。这些事不做，后面一碰就会散。

这就是 Part 2 要做的事。

顺着往下读
下一篇：《拿到 PRD 后先做什么：需求收敛、范围裁剪与验收口径》
拿到 PRD 之后第一件事不是让 AI 生成代码，而是先把版本目标、主线需求、非目标和验收口径收紧。