这一步真正要收的，不是文档，而是决策#

拿到 PRD 后最常见的误判，是把它当成“可以直接开始实现”的输入。

这在没有 AI 的年代就已经危险，只是当年问题暴露得慢；到了 AI 时代，这个问题会被瞬间放大。因为 AI 很擅长把一份看起来像样的需求翻译成页面、接口、目录结构，甚至顺手把很多没写清的地方也补齐。坏消息是，这种补齐往往不是在帮项目推进，而是在替项目偷做决策。

一旦 PRD 还是粗的，AI 会自然做三件事：

• 把模糊表述补成具体实现
• 把未来阶段才该讨论的能力提前带进当前版本
• 把本来应该继续讨论的边界，快速固化成仓库事实

最后表面上看，项目“动起来了”；实际上，最难改的部分已经被写死了。因为真正出错的往往不是某个函数，而是版本目标、阶段边界和实现路径。

所以“需求收敛”这一步，核心根本不是润色文档，而是先收四类决策：

• 这个版本到底只回答哪个问题
• 这个版本明确不回答什么
• 当前阶段切到哪一层为止
• 什么结果才算做成

如果这四件事还没收住，后面的技术选型、仓库起盘、任务拆分、Spec、Rules、Skills，都会一起漂。因为它们本质上都在放大当前这轮判断。

粗糙 PRD 的正确用法，是先让 AI 暴露问题，不是暴露代码#

很多项目的起点都不是一份成熟 PRD，而是一份只能看见方向、还远远不够直接实施的粗糙定义。这件事本身完全正常，问题只在于团队后面怎么使用这份粗糙。

错误用法很直接：把粗糙 PRD 丢给 AI，让它先写一版看看。
更稳的用法刚好相反：先让 AI 帮你把问题暴露出来。

这一步至少要让 AI 产出两层东西：

1. 当前正式开发前，哪些问题不讨论清楚就不能开工。
2. 从起盘到交付，这个项目后面大概率还会在哪些地方继续遇到分歧。

第一层决定“现在卡点在哪”。第二层决定“这条线以后会长成什么样”。这两层都重要。因为项目起盘阶段真正缺的，不是功能样稿，而是问题地图。

问题地图的价值，不是保证 AI 第一次就把答案说对，而是先把“哪些地方其实还没定”显形出来。只要问题已经显形，团队就能继续追问、继续反驳、继续收紧；如果连问题都没被写出来，后面所有实现都只是在赌。

案例链路：GraphSpec 的“问题地图”不是凭空来的

这本书里的 GraphSpec 就是一个很典型的例子。

它在 《把主线项目亮出来》 那一章里，仍然只是一个粗糙定义，不具备直接开工条件。后面真正先发生的，不是实现，而是先把问题地图拉出来。

如果按时间顺序看，这条链路更接近下面这样：

1. 前一章的粗糙 PRD： 《把主线项目亮出来》
2. 第一版面向“项目开始前必须讨论什么”的问题地图： Feishu 文档 1
3. 后面继续收成更聚焦的讨论： Feishu 文档 2
4. 再把其中最关键的三组问题公开收进 GitHub Discussions：
   • [Vision] GraphSpec V0.1：当用户敲下 graphspec 时，我们到底要帮他解决什么痛点？ #6
   • [Scope] 防微杜渐：明确 V0.1 的“绝对不做”清单 (Non-Goals) #7
   • [Architecture] 核心契约：.graphspec/ 里面的数据长什么样？（第一版数据契约脑暴） #8

这条链路最关键的，不是“AI 一次规划得很准”，而是它先把痛点切口、非目标、基础契约这三层问题拉出来了。

需求对齐最难的地方，不是补细节，而是纠正 AI 的产品理解#

很多人一看到 AI 理解偏了，第一反应是继续补提示词细节。这个动作当然有用，但很多时候它治不了根。

因为 AI 出错，未必是“有个字段没说明白”，而是它脑子里想的根本不是同一个产品。

举个通用例子。假设想做的是“团队知识工作台”，核心价值是把一组业务事实组织成可查询、可协作、可审查的资产。可如果提示词写得不够准，AI 很可能会把它理解成另一种同样合理、但完全不同的东西：一个 crawler 驱动的搜索系统。于是它会自然往这些方向推：

1. 先抓数据。
2. 先建索引。
3. 先做搜索入口。
4. 再讨论知识视图。

这条路本身不荒唐，问题在于它已经把产品理解成“搜索工具”了，而不是“知识工作台”。

需求对齐最难的地方，就在这里。不是把一句话润色得更优雅，而是先纠正 AI 当前脑子里那套产品心智模型。因为只要心智模型还是错的，后面所有 plan 都会错得很努力：结构可能很完整，逻辑可能很自洽，但方向还是偏的。

所以真正的需求对齐，至少要把三件事钉住：

1. 这个产品真正维护的主资产是什么。
2. 哪些东西是主资产，哪些只是解释材料、校验材料、辅助证据。
3. 人和 AI 后面到底是围绕什么对象协作，而不是围绕什么副产物协作。

只要这三件事没对齐，AI 很容易把副产物当主线，把辅助层当产品本体。

一个简单判断：AI 现在理解的是不是另一个产品

如果 AI 给出的方案虽然“逻辑很顺”，但你一看就觉得它一直在优化另一个东西，那大概率不是方案细节有问题，而是产品理解偏了。

这时候最需要补的，不是更多实现约束，而是更上位的一层：

1. 主资产到底是什么。
2. 主入口到底是什么。
3. 哪一层是主线，哪一层只是辅助层。

第一轮 AI 规划最重要的，不是终局正确，而是可反驳#

对 AI 规划最没用的一种期待，就是希望第一轮答案一次终局正确。

项目起盘不是考试，没有标准答案埋在后面等着一次选中。真正有效的第一轮规划，只需要做到一件更现实的事：可反驳。

也就是说，它至少要把项目从一团雾里压成几条可以讨论的判断：

1. 当前主切口是什么。
2. 这版严格不做什么。
3. 最小契约先锁哪一层。
4. 哪些问题现在要拍板，哪些问题后面再谈。

只要这些锚点已经被写出来，第一轮规划就已经有价值。因为团队终于可以围绕同一组问题继续推进，而不是每个人在自己的脑内各自起草一版项目。

这一步的坑也很清楚：第一轮规划一旦写得太像“第一版怎么实现”，AI 下一步就会自然往实现上滑。解决方式不是否定第一轮规划，而是立刻收紧它的职责。

需求收敛的第一个正式产物，不是施工图，而是项目章程#

这一步是很多团队最容易走偏的地方。

在做完第一轮讨论和第一轮 AI 规划之后，特别容易自然滑向一种写法：既然方向开始清楚了，那就顺势把 proposal 写成一份详细施工图，把第一版怎么做、后面怎么长、任务怎么排，一次全部说透。

这种写法的问题，不是它不细，而是它细得太早。

起盘阶段真正需要的，不是一份替未来每个局部问题做决定的文档，而是一份项目章程。这份章程的职责很明确：

1. 给产品下定义：它是什么，不是什么。
2. 给当前版本下定义：这一版只回答哪个问题。
3. 给边界下定义：当前阶段明确不做什么。
4. 给讨论下定义：哪些已经定了，哪些还是待讨论议题。
5. 给后续推进下定义：issue 应该按什么规则继续长出来。

这就是为什么全局 proposal 更适合被理解成一种“项目章程型总纲”。它不是总施工图，而是整个项目后续收敛的坐标系。

如果这份文档写得像实现说明书，它会自然诱导 AI 直接往下写代码。
如果它写得像项目章程，它会自然把后续工作流拉向“继续切问题、继续细化、继续验证”。

案例锚点：GraphSpec 后来为什么要从“scanner-first”改成“graph-asset-first”

GraphSpec 的第一轮 plan 并不是一句空话式的“先讨论再说”。它其实已经给出了一个相当具体的 V0.1 方向，例如：

1. CLI + 本地视图
2. 本地、只读、JS/TS、静态依赖
3. graphspec init / graphspec view
4. 本地数据快照
5. 先回答“改这个底层模块会影响谁”

这版 plan 的价值，在于它先把项目从“模糊想法”压成了几个可以继续讨论的锚点。

但它后来暴露出一个更大的问题：AI 当时其实把产品理解成了另一种东西。它理解的是“scanner 驱动的图工具”：

1. 主图来自扫描结果。
2. 视图围绕文件树和 import/export 组织。
3. AI 主要是去读扫描出来的结构。

这条路本身不荒唐，但它和后面真正对齐的产品定位不是一回事。因为 GraphSpec 后来收准的方向是：

1. 主资产是架构图，不是扫描结果。
2. CLI 是主入口。
3. 数据文件是兜底入口。
4. scanner 只是证据层、解释层和校验层。
5. 整体图、模块图、节点相关内容视图才是产品主线。

所以后面的多轮 prompt，真正做的不是继续补 scanner 细节，而是纠正产品理解：

1. 不要直接写代码，只保留 hello world 级骨架。
2. proposal 要有长线规划，但不要把未来阶段一次写死。
3. GraphSpec 和 OpenSpec 的关系要重新定义。
4. tasks 不能只是实现顺序，而要服务后续多 issue 创建。
5. 架构图是主资产，scanner 只能降级为证据层。

最终重构出来的，不只是“更完整”的 proposal，而是一份已经把产品心智模型纠正过来的项目章程。

当前这版总纲可以直接看：

1. proposal.md
2. design.md

这里真正变化的不是文档厚度，而是需求终于对齐了：产品到底维护什么主资产，scanner 到底是什么角色，这两件事终于不再混着写。

范围裁剪最难的地方，不是少做几个功能，而是把阶段切开#

范围裁剪最容易被讲成一句正确但没什么用的话：先少做一点功能。

这句话的问题，不是它错，而是它经常把真正难的部分藏掉了。项目之所以失控，很多时候不是因为功能列表太长，而是因为不同阶段的问题被混在一起了。

举个通用一点的例子。假设要做一个 AI 会议助手，需求里同时出现了：

• 录音转写
• 要点总结
• 与会议内容对话
• 团队协同批注
• 会后自动生成任务

如果只按“少做一点功能”去裁，团队很容易机械地删掉两个功能，保留三个功能。但保留下来的这三个功能，可能仍然横跨三类完全不同的问题：

• 音视频采集和转写可靠性
• 摘要质量和上下文组织
• 多人协作和状态一致性

这时项目虽然 feature 少了，阶段边界却一点没清。后面一样会漂，因为当前版本其实还在同时解决三种不同性质的风险。

所以范围裁剪最核心的问题，不是“现在少做哪几个功能”，而是：

这一阶段到底只优先解决哪一类风险。

通常可以先按下面几类风险去拆：

• 价值风险：用户到底在不在乎这个能力
• 交互风险：产品体验到底应该怎么走
• 契约风险：底层数据、接口、命令面到底怎么定
• 治理风险：护栏、审计、回滚和验证需要到什么程度

只要一个阶段同时在正面解决这四类风险，它大概率已经切太大了。

真正合理的阶段，通常只做一件事：优先消掉当前最贵、最容易让后面返工的那种风险。等这一层站住，再把下一层问题放进来。

所以需求收敛里最硬的一刀，不是删几个 feature，而是切清楚：

当前阶段到底只验证哪一类问题。

只有这刀切清，版本目标、非目标、验收口径和后续 issue 才会一起对齐。对很多项目来说，这比“做或不做某个功能”更重要。因为问题往往不是功能不该存在，而是它不该现在进场。

task 的职责，不是排施工顺序，而是孵化 issue#

这句话真正想反对的，不是“排顺序”这件事本身，而是反对把 tasks 写成一种默认已经可以直接开工的施工表。

最常见的坏味道，就是这种写法：

1. 先做后端。
2. 再做前端。
3. 再补测试。
4. 最后接入部署。

或者稍微细一点：

1. 先定义数据结构。
2. 再写接口。
3. 再写页面。
4. 再补验证。

这类清单最大的问题，不是顺序一定错，而是它把任务写成了“施工动作”，却没有写出“为什么现在要做这件事”。它默认项目已经完成了需求收敛，只差开始干活。可起盘阶段最缺的，恰恰不是干活顺序，而是问题边界。

所以 tasks 在这个阶段更合理的职责，不是安排施工，而是把后续值得单独收敛的问题先孵化出来。

这里最关键的转换是：不要把 issue 理解成一个功能块，而要把它理解成一次可收敛的不确定性。

什么叫“可收敛的不确定性”？就是这个问题满足三件事：

• 它单独拿出来讨论，有机会在一轮或几轮对话里把边界收住
• 它一旦不先收住，后面很多实现会一起漂
• 它收住之后，能为后续一批实现提供共同前提

这样定义之后，很多任务的切法会立刻变化。

比如做一个订阅制产品，粗暴的 tasks 很容易写成：

1. 做登录。
2. 做订阅页。
3. 做支付。
4. 做用户中心。

但更像 issue 的切法，往往会变成：

1. 身份体系和账号绑定规则。
2. 套餐、权益和计费状态的基础契约。
3. 支付成功、退款、过期这些状态怎么流转。
4. 哪些页面要消费这些状态，哪些地方只读，哪些地方可写。

这两种切法的差别，不在于名字，而在于前一种是在排施工顺序，后一种是在先收会卡住后续实现的关键问题。

所以起盘阶段的 tasks 至少应该先回答四件事：

1. 后面哪些问题值得独立开 issue。
2. 这些 issue 各自消解的是什么不确定性。
3. 每个 issue 下面需要哪些子任务，才能把边界说清。
4. 哪些 issue 还存在前置决策，没有资格直接进实现。

只有这样，tasks 才是在为后续收敛服务，而不是在诱导 AI 提前进入大规模实现。

这里还有一个决定 issue 质量的关键部分：背景。

很多 issue 写到最后，只剩下目标、非目标、验收标准。这样当然比没有强，但还是不够。因为接手的人依然可能不知道：为什么偏偏是这个问题现在必须先做？它到底卡住了后面哪条链路？

所以一个合格的起盘 issue，至少要有四块内容：

1. 背景：这个问题为什么现在必须先解决。
2. 目标 / 非目标：这次到底只处理什么，不处理什么。
3. 验收口径：什么结果才算成立。
4. 未决点：哪些问题还没拍板，不能被实现者擅自补完。

这样写的结果，不只是“issue 更完整了”，而是 issue 从一个任务条目，变成了一个真正可以继续 SpecDriven 细化的收敛单元。

案例锚点：GraphSpec 的 tasks 为什么后来改成“后续 issue 的种子清单”

如果 tasks 只是一串粗粒度标题，它更像实现目录。
但当它开始变成 issue + 子任务树，味道就完全不同了。

直接看当前 change 的任务结构就很明显：

• tasks.md

这里面已经不只是“做什么”，而是在回答：

1. 哪个问题值得独立开 issue。
2. 每个 issue 的输入输出和边界是什么。
3. 哪些子任务只是为了把目标说清。
4. 哪些问题还在待决策问题池里，不能偷偷带进实现。

也正因为这样，像“数据契约”这种 issue 就不能只写“定义字段”。它必须先把背景写出来：为什么这个问题是当前阶段的基石，它会约束扫描器、查询面、前端视图和未来 AI 接入；为什么如果它继续模糊，后面的 API 和交互都会一起漂。

还没想清楚的数据模型，不应该在总纲里假装已经想清楚#

起盘阶段特别容易出现一种“文档很专业、判断却很空”的错觉：为了让 design 看起来完整，先摆出一排模型名和接口名。

问题在于，模型名从来不是答案，它只是答案的外壳。

比如做一个订阅产品，团队可能很快写出这些词：

1. Plan
2. Subscription
3. Invoice
4. Entitlement

看起来像已经建模了，实际上最关键的问题可能一个都没回答：

1. 权益是跟套餐绑定，还是跟用户当前状态绑定？
2. 免费试用结束时，状态是直接过期，还是进入宽限期？
3. 退款之后，权益立刻回收，还是保留到当前周期结束？
4. 前端看到的“是否可用”，到底来自支付状态、权益状态，还是另一个投影状态？

也就是说，团队真正没想清楚的从来不是“模型该叫什么”，而是这套模型要表达什么现实约束。

所以起盘阶段判断“数据模型到底有没有收敛”，不能看名字多不多，而要看三件事有没有回答：

1. 它的事实来源是什么：这份数据到底由谁产生、谁维护、谁消费。
2. 它的生命周期是什么：哪些状态会变化、变化由什么事件触发。
3. 它服务的场景是什么：后面的接口、页面、自动化流程到底会依赖它的哪一部分。

如果这三件事还没讲清，过早在总纲里摆一排模型名，通常只会制造一种危险错觉：团队误以为建模已经完成，后面的 issue 只是去补字段。

这也是为什么起盘阶段更稳的写法，不是先写“我们已经有一套模型”，而是先把模型问题写出来。例如：

1. 这个阶段至少需要一份什么样的本地契约，才能让扫描器、查询面和视图共享同一事实来源？
2. 关系是否需要独立表达，而不是继续塞在某个节点字段里？
3. 稳定 ID 为什么重要，它到底服务哪些后续能力？
4. 哪些概念现在只是候选层次，还不能在总纲里直接锁死？

这时候后续“数据契约” issue 才是在回答一个真实问题，而不是去实现一个假装已经决定好的答案。

一个简单判断：什么时候模型名写早了

如果一个模型名字换掉以后，团队对系统应该怎么工作完全没有影响，那这个名字大概率写早了。

比如把 Entitlement 改成 AccessGrant，如果讨论完全不受影响，说明真正该讨论的不是名字，而是：

1. 权益何时生成。
2. 权益何时失效。
3. 权益和支付状态是什么关系。
4. 哪个接口负责把它投影给前端。

模型名只有在这些问题已经开始收住之后，才会真正有意义。

验收口径必须出现在 issue 之前，因为它会反过来决定怎么切问题#

很多团队把验收理解成开发后期的事情：先做出来，最后再检查。这在 AI 时代会带来一个特别现实的问题，AI 很容易把“生成了很多东西”误判成“已经做成了这件事”。

但工程上的闭环从来不是靠输出数量定义的，而是靠“最初那个问题有没有被回答”定义的。

所以验收口径必须提前，而且要提前到 issue 之前。因为验收口径不是收尾动作，它其实是反向切分问题的工具。

举个通用例子。假设现在要做“用户可以分享文档”。

如果没有验收口径，这个需求很容易一路膨胀成：

• 分享链接
• 权限控制
• 链接过期
• 下载控制
• 审计日志
• 协同评论

最后 issue 会切成一堆看起来合理、实际上边界混乱的任务。

但如果先写验收口径，事情会完全不一样。比如当前阶段的验收如果是：

1. 用户可以生成一个只读分享链接。
2. 未登录用户可以通过链接查看文档。
3. 所有者可以手动关闭链接。
4. 不处理多人协作、不处理细粒度权限、不处理审计。

这时候 issue 其实已经开始自己浮出来了：

1. 分享链接的底层状态和生命周期。
2. 文档公开访问接口。
3. 关闭链接后的失效行为。
4. 最小的分享入口和关闭入口。

这就是为什么验收口径必须出现在 issue 之前。因为它决定了这一阶段的最小闭环长什么样，也决定了哪些问题值得独立成 issue，哪些问题应该明确留到下一阶段。

如果验收口径还写不出来，说明“做成”这件事本身都没收住。那这个时候去写 issue，通常只会得到一堆松散任务。
反过来，如果验收口径已经能写清楚，第一批 issue 往往会自然浮出来。

这也是判断一轮需求收敛有没有做成的最直接标准之一：

收敛完之后，第一批 issue 有没有变得更容易切。

如果答案还是没有，那说明这轮收敛大概率还没真正落地。

一个实用判断：验收口径是不是还太空

如果验收标准里充满这些话：

• 用户体验流畅
• 功能基本可用
• 页面能正常展示
• 系统支持后续扩展

那它大概率还没法用来切 issue。

真正能用来切 issue 的验收口径，通常会同时说清三件事：

1. 当前阶段一定要成立什么。
2. 当前阶段明确不成立什么。
3. 哪种行为一旦出错，就说明这轮闭环没打通。

Harness 不是一次性大建设，它应该跟着项目阶段一起长#

起盘阶段还有一个特别容易高估的东西，就是 Harness。

很多团队一意识到“AI 写代码很快，必须要有护栏”，下一步就会本能地想把 lint、test、E2E、回归、审计、Playwright、workflow regression 一次全部规划进去。动机当然没问题，但做法经常会走向另一个极端：项目主线还没跑起来，验证基础设施先成了大工程。

Harness 真正合理的长法，不是一开始就把所有验证层一次铺满，而是跟着项目阶段一起长。因为不同阶段，最容易漂移的东西根本不一样。

比如一个典型 Web 产品，大致会经历这样的验证重心迁移：

1. 起盘阶段最容易乱的是工程秩序，所以先要 format / lint / typecheck / smoke test。
2. 契约开始稳定之后，最容易漂的是输入输出边界，所以要补 fixture、契约测试、CLI 或 API 行为测试。
3. 开始出现状态流和副作用以后，最容易出事的是回滚、确认、审计，所以要补流程级验证。
4. 前端交互已经有真实复杂度时，才值得引入 Playwright 这种端到端验证。

这个顺序不是“节省工作量”那么简单，而是避免验证层和主线开发脱节。

如果一开始就上全套 Harness，常见结果通常有两个：

1. 最该先收的产品和契约问题还没定，团队先把时间花在验证基建上。
2. 真正当前阶段最脆弱的点，没有被针对性约束，反而被“我们已经有很多测试”这种幻觉掩盖掉了。

所以 Harness 什么时候该加，不应该看“业界是不是都这么配”，而应该看：

当前阶段最容易漂的是哪一层，哪一种验证最能卡住这层漂移。

只要能回答这个问题，Harness 就会长得很自然。回答不了，它大概率就只是“看起来完整”。

一个简单的阶段判断法

如果当前阶段最大的风险是“大家对数据契约理解不一致”，那最值钱的 Harness 不是 E2E，而是契约测试和 fixture。

如果当前阶段最大的风险是“状态流容易走错”，那最值钱的 Harness 不是再多一层 lint，而是流程级回归检查。

如果当前阶段最大的风险是“交互闭环经常断”，那这时候 Playwright 才开始真正值钱。

Harness 不是荣誉勋章，它应该始终盯着当前最贵的那种失败模式。

所谓 IssueDriven 和 SpecDriven，本质上就是前后咬合#

很多人会把 IssueDriven 和 SpecDriven 讲成两套路线，好像选了一个就不要另一个。真到项目里，这种分法其实没什么帮助，因为它把两个本来就是前后衔接的动作，硬拆成了对立关系。

更准确的理解应该是：

1. IssueDriven 负责把问题切出来。
2. SpecDriven 负责把切出来的问题收紧。

也就是说，issue 解决的是“先把哪一个问题拿上台面”，spec 解决的是“把这个问题收敛到什么程度才允许进入实现”。

如果只有 issue，没有 spec，团队很容易停留在这种状态：

1. 这里要补一个权限系统。
2. 这里要做一个搜索功能。
3. 这里要支持分享。

这些问题都像问题，但其实都太大，谁接手都能朝不同方向理解。

如果只有 spec，没有 issue，团队又很容易空转。因为没有被切开的真实问题，spec 往往会越写越像宏大蓝图，最后反而失去抓手。

真正稳的流程，通常更像下面这样：

1. 先暴露问题，形成 issue 候选。
2. 选出当前最值得先收的一类问题，形成独立 issue。
3. 再用 spec 去压缩这个 issue 的边界、非目标、验收和未决点。
4. 问题收住之后，再进入实现和验证。

这个顺序看起来更慢，实际上更稳。因为它承认了一件很现实的事：

项目起盘阶段不可能一次把所有判断都做对。

所以真正有效的流程，不是指望第一版文档终局正确，而是让 issue 和 spec 形成一种稳定循环：

1. issue 把模糊问题显形。
2. spec 把显形的问题收紧。
3. 实现和验证再反过来暴露下一轮问题。

这时候 IssueDriven 和 SpecDriven 不再是术语标签，而是项目持续收敛的节奏本身。

一个通用例子：什么时候该先开 issue，什么时候该先补 spec

假设团队发现“搜索体验很差”。

这时直接写代码通常太早，因为“搜索体验很差”可能指的是三种完全不同的问题：

1. 搜索结果本身不准。
2. 搜索速度太慢。
3. 搜索结果虽然对，但用户根本不会点。

更合理的顺序是：

1. 先把“搜索体验很差”切成一个明确 issue，例如“当前搜索结果排序逻辑不稳定”。
2. 再写这个 issue 的 spec：排序到底基于什么信号、明确不做什么、什么样的结果算通过。
3. 收住之后，再进入实现。

这时 issue 负责切题，spec 负责收题。两者缺一个，项目都会继续空转。

这一步做对了，后面的快才不是幻觉#

AI Native 开发最容易制造的一种错觉，就是“很快出现了很多东西”，于是大家误以为“项目推进得很快”。

真正的速度，不是输出冒得快，而是后面不用反复返工。

这里其实可以顺手插一句很反直觉的话：在 AI 加持下，按理说开发速度好像应该提升几十倍，但真实项目里，最后能稳定落到三五倍提速，往往已经很不错了。

这不是因为 AI 不够强，而是因为项目不是短跑题。真正吃时间的，从来不只是“把代码敲出来”，而是方向有没有收准、边界有没有钉住、后面会不会大面积返工。愿意在起盘阶段多花时间收边界，看起来像是在拖慢速度，实际上是在保质量，也是在保 ROI。

反过来，盲目追求速度的代价通常特别现实：代码会迅速膨胀，bug 会迅速堆积，团队很快就会进入一种“越写越难改、越修越像屎山”的状态。像 OpenClaw 这种几十万行的项目，就是很典型的反例。真要说它想实现的核心能力，可能不到一万行代码就够了，但因为前面缺少规划，后面又持续让 AI 直接按需求堆实现，最后换来的不是几十倍效率，而是极低的 ROI：token 花了很多，代码质量却很差，bug 还像漏水一样到处冒。

所以 AI 时代真正该追的，不是“这周多生成了多少行代码”，而是“每一次生成之后，项目是不是更可控了”。如果答案是否定的，那所谓速度往往只是把混乱提前兑现。

所以“拿到 PRD 后先做什么”这件事，最后收回来其实很朴素：

1. 先让 AI 暴露问题，不要急着暴露代码。
2. 先把产品定位、阶段边界、非目标和验收口径收紧。
3. 先产出一份宏观 proposal，把它当成项目章程，而不是施工图。
4. 再把 tasks 写成 issue 孵化器，而不是实现顺序清单。
5. 然后让后续每个 issue 再进入自己的 spec-driven 落地。

对 GraphSpec 来说，这一步真正买到的，不是更漂亮的文档，而是项目终于不再依赖每一轮对话重新定义方向，而开始具备持续收敛的能力。

对读者自己的项目来说，这一步同样成立。项目起盘阶段最需要的，不是“马上有一版能跑的东西”，而是先拥有一套不会把错误边界快速固化的推进结构。

这一步一旦做对，后面的快才是有效的。
否则所有“高效”，都只是在提前透支返工。

顺着往下读

下一篇：《技术栈定盘》

当版本目标、非目标、阶段边界和验收口径都收紧之后，技术选型才不再是拍脑袋下注，而会变成对当前问题的理性回应。