在 Spec 之前

当我们用 AI 做能力边界之外的事时，第一步往往就是和 AI 进行一轮又一轮的文字需求讨论。

Agent 不断提出看起来合理的建议，我们不断说“YES”，Spec 也越写越完整，可这种讨论很容易变成伪共创。

在写 Spec 之前，我们可能需要的不是继续聊，而是先看见。

我自己就经常掉进这个问题里。越是做自己不熟悉的东西，我越容易把需求讨论得很详细。

我会和 AI 一轮一轮地聊。功能怎么分，流程怎么走，异常怎么处理，什么放进第一版，什么留到以后。一个问题拆完，再追下一个问题。最后整理出来的 Spec 看起来很完整，我也会获得一种确定感：这次应该想清楚了。

可等东西真正做出来，我经常还是不满意。

有时我能马上看出它不对，却很难说清应该怎样才对。有时需求明明都实现了，流程、页面和验收也能一条条对上，最后放在眼前，仍然不是我想要的东西。

真正让我在意的是，我往往要到最后才知道自己不满意。走到这里之前，大量注意力和时间已经花在一轮轮讨论、确认和修改上了。

至少对我来说，现在最不缺的就是想法和需求。可如果每一个念头都要先走完长需求讨论、写成完整 Spec，最后等成品出现才判断要不要继续，注意力很快就会被耗光。

所以我想把 Demo First 当成一道注意力筛选器：不先把每个念头讨论成一套完整系统，而是把最关键的任务做成一个有边界、能完整体验的 Demo，先回答两个问题：这是不是我想要的？这件事还值不值得继续？然后再决定要不要投入完整讨论、写成 Spec。

它能让我更早停止不值得继续的方向，把注意力留给真正值得投入的事情。

我翻过以前留下的需求讨论流水账。缺的从来不是讨论。恰恰相反，很多时候的问题就是讨论得太完整了。

回头看那些流水账，我最常做的动作是确认：可以、继续、YES。真正属于我的判断反而很少。

我以前习惯先用 Superpowers 里的 brainstorming skill 把模糊想法展开，再用 Grill Me 沿着设计决策继续追问依赖、边界、异常和验收，最后收成 Spec。

这套流程一点也不草率。可当我对一个领域还没有足够经验时，AI 提出问题，也顺手给出几组听起来合理的答案。我从里面选一个，它再继续往下补。整个过程里我一直在做决定，但我判断的往往只是这段话是否合理，不是这种产品形态是否成立。

brainstorming 可以打开文字里的可能性，Grill Me 可以把一个方案问得更结实。但如果我还没有真正看过、用过几个差异足够大的成品，它们也可能只是在帮我把最早选中的那条路越问越完整。

这就是我以前忽略的一件事：Spec 可以整理判断，却不能替我生成判断。

在 Spec 之前，我需要先看见几个真正不同的东西，亲手试一下，知道自己保留什么、排除什么，愿意承担什么代价。否则，需求讨论越详细，只会让一个还没被验证的方向显得越来越确定。

需求写得很完整，人也可能根本没有形成判断

传统流程通常从需求讨论开始，再写 PRD、画原型、做架构、开发和验收。

方向清楚时，这条路没问题。我知道谁会用，知道核心任务是什么，也能判断某个功能改动会带来什么后果。AI 可以帮我补异常场景、整理规格、检查遗漏。

问题出在人已经走到自己的能力边界之外。

可能是在做一个从没做过的产品，也可能是不熟悉这个行业，甚至连合理的产品形态有哪些都不知道。这时让 AI 主持详细需求讨论，过程很容易变成这样：

AI 提出问题，也给出一组听起来很合理的答案。人从里面选一个。AI 再根据这个选择补出更完整的功能、流程和优先级。文档越写越像回事，人的参与感也很强。

可如果追问一句：“为什么一定选这个？换一种交互会发生什么？愿意为了它牺牲什么？”人往往说不清。

需求看起来明确了，其实只是未知被包装成了确定答案。

AI 把中间过程折叠得太快，人脑里没有长出关于这个问题的地图。结果能看懂，结构也像样，但只能判断它顺不顺眼，很难判断它为什么成立。

方向还没看清就写 PRD，往往只是把 AI 的判断盖上人的名字。

Demo 的工作，是把“说不清”变成“可以比较”

这里面还有一个很个人的判断：至少对我来说，凭空创造一个答案很难；但当几个不同的东西已经摆在面前，知道自己想要什么，或者指出哪里不对，会容易得多。

我未必能直接说出正确答案，但通常能在真实体验里进行比较、批判和选择。Demo First 利用的，正是这种“先看见，再判断”的差异。

先说明一下，这里说的 Demo 指一个能跑完核心任务的成品。几套前端页面，或者不同的布局、颜色和交互，都不足以承担这个角色。

面对同一个真实任务和同一份输入，一个人不需要制作者站在旁边解释，也能走完核心流程，得到一个可以判断的结果。比较时，我会看产品怎样理解输入、怎样完成任务、AI 在哪里做决定、人在哪里介入、结果是否可信，以及做错以后能不能恢复。页面好不好看排在后面。

但它是探索阶段的成品，不是生产阶段的系统。

它暂时可以不解决大规模并发、完整监控、复杂权限和长期维护。但核心机制必须真的发生：可以使用模拟数据和临时脚本，机制本身却必须从相同输入跑出实际结果。凡是会改变判断的环节，都不能停留在静态页面里，也不能靠制作者站在旁边解释。

几个 Demo 的差异也不应该只是界面。它们要代表不同的产品路径，例如全自动完成、关键节点由人确认、先展示建议和依据再由人决定。再把当前人工做法放进来当基线，所有版本接收相同输入、完成相同任务，而且都要真正产出结果。

比较结束后，只说“我更喜欢其中一个版本”还不够。

真正有用的判断应该能说成：“自动完成确实更快，但我不能接受错误结果无法撤销。我愿意多一次确认，换取依据可见和结果可恢复。下一版如果把这两个机制补上，我预计速度会慢一点，但返工会减少。”

这里已经出现了三样东西：评价变量、愿意承担的取舍、最低接受标准。

这个能完整跑完任务的成品，和由它生成的判断，才是 Demo 阶段的交付物。

我现在会把 Demo First 压成六步

研究稿里的完整流程有二十多步，真正动手时我会压成六步。压缩的是仪式和重复，不是判断。

先说清一件事：下面写的是一套完整工作流，不是一张要求人亲自执行的操作清单。

在探索阶段，人真正需要投入注意力的只有四类时刻：定义边界、选择值得比较的取舍、亲自体验成品、决定继续还是停止。整理材料、制作不同 Demo、保持同任务同输入、记录操作过程和生成对比，可以交给 Agent。方法写出每一步，是为了不漏掉判断，不代表每一步都要人做。

下面用我真实探索过的一类产品想法贯穿六步。

当团队里的每个人都有自己的个人 Agent，几个人临时组队时，能不能不再由人反复充当传话筒？能不能让 Agent 先交换任务、补齐信息、暴露分歧，再把少数必须拍板的问题交还给人？我曾经认真想过做一款这样的团队协作产品。

为了保护相关的人和项目，下面会隐去名称、对象和具体数字。还要说明的是：当时我并没有严格按照 Demo First 走完这六步。这是我用后来形成的方法回头重走一次，不把教学重构冒充成历史实录。

第一步：先写三行，不写完整需求

开工前，只需要形成三行：

1. 想看到的变化：谁的什么状态应该发生变化？
2. 明确不想要什么：哪些体验和结果不能接受？
3. 现实边界：时间、预算、数据、隐私和责任上，什么不能越过？

这三行不是解决方案。它只负责圈出探索场。

人在陌生领域里很难马上定义答案，却常常能认出明显错误的方向。所以“不想要什么”反而很重要。

放进这个例子里，三行可以这样写：

1. 想看到的变化：两三个各自深度使用个人 Agent 的成员临时组队后，一项跨角色任务可以从提出走到验收；日常澄清和依赖识别先由 Agent 处理，人只在范围、承诺和关键取舍上介入。
2. 明确不想要什么：不强迫所有人迁移到同一个共享大脑；不允许 Agent 未经确认替人承诺；不能只是把人的消息换成更多机器消息，最后仍由人负责整理和转述。
3. 现实边界：这一轮最多用两个晚上、最多做三个版本；只选一个小团队和一项真实任务；暂时不做全公司的权限体系、人才市场、计费和完整组织管理。

这三行确认后各有去向：第一行变成下一步的共同任务，第二行变成体验时的淘汰线，第三行变成探索预算。到这里就够了，不继续讨论页面、技术栈和完整功能。

分工：Agent 可以从前面的聊天里整理出三行草稿、指出缺失边界；人只负责改正和确认，尤其要亲自拍板“不想要什么”。

第二步：固定同一个真实任务

别直接说“给我三个方案”。

先选一个所有版本都要完成的任务，使用相同输入，再记录当前人工做法。任务要小到能在探索预算里做出核心机制，大到完成以后真的会改变判断。

这个例子的共同任务是：让一项需要两种角色配合的真实任务，完整走过“发起—补齐信息—确认承诺—交付证据—验收”。目标、上下文、边界、验收标准和依赖必须真正流转；出现分歧或越过授权时，必须回到人，而不是由 Agent 悄悄替双方谈妥。

当前做法就是零号线：A 先和自己的 Agent 整理任务，再把结果复制给 B；B 重新解释给自己的 Agent，发现缺信息后再回头问 A；任务变化时，整条转述链再走一遍。记录人搬运了几次信息、来回澄清了什么、在哪里等待、最后因为什么返工。没有这条零号线，协作产品很容易只是在制造更多状态和消息。

分工：人只需选定“哪项任务值得拿来比较”并确认零号线没有失真；输入准备、过程还原和基线记录交给 Agent。

第三步：让每个 Demo 押注一种不同取舍

取舍不是让 AI 随机想。先看第一步写下的“不想要什么”，再看零号线最费力的地方，从里面挑出真正影响判断的变量，例如速度、控制、信任、可恢复性和成本。

放进这个例子里，可以先准备三条不同的产品路径：

• 共享团队工作台：人和 Agent 都进入同一个平台，共享任务、上下文和进度，优先统一；代价是每个人都要迁移自己的工作方式，平台也容易越做越重。
• 个人 Agent 代理协作平台：每个人保留自己的 Agent，由中间层处理身份、授权、澄清和承诺，优先个体自主；代价是信任和授权机制复杂，冷启动成本很高。
• 轻量任务交接层：先用共享文件仓、标准任务单和状态约定跑通交接与验收，优先低成本接入；代价是很多动作仍然朴素，暂时不像一个宏大的平台。

三个版本都必须让同一项任务从发起走到验收，三套页面不算。回看当时的讨论，我后来才意识到：完整平台还不用急着证明，先看最窄的一层交接规则能不能减少人工传话。

也不必一开工就把三个全部做齐：先让一个 Demo 和零号线比较；如果已经足以判断“不想要”或“不值得继续”，直接去第六步，不为凑数继续做。

分工：Agent 可以提出取舍轴、制作和运行不同 Demo；人负责判断这些差异是否真的会改变产品方向，不参与每个实现细节。

第四步：先写预测，再动手体验

看到 Demo 之后马上操作，人很容易事后编理由。

体验前先写一句：“我预计它会在哪解决问题，又可能在哪里失败。”然后用相同输入完成相同任务。

体验时少写感受，多记事实：用了多久，在哪里停顿，返回看了几次，哪里返工，有没有求助，最后是完成还是放弃。

如果现在重走一次，在体验共享团队工作台之前，我会先写：

我预计统一平台最容易减少信息丢失，但成员可能要先花很多力气录入身份、权限和上下文，任务还没开始，接入成本已经超过了这次协作本身。

体验后只记发生了什么。例如：为了让第一项任务进入平台，我先配置了成员、权限和项目状态；对方仍要问两个关键边界；真正推进任务的，是一张写清目标、验收标准和授权范围的任务单，而不是完整仪表盘。先不急着把它解释成“平台路线错了”。

分工：预测和亲自体验不能外包；计时、点击路径、停顿、返回和返工记录可以由 Agent 自动完成。

第五步：体验后只回答四件事

• 第一个意外是什么？
• 这是实现没做好，还是原先把问题想错了？
• 哪些机制保留，哪些明确排除？
• 下一版只改哪个关键条件，我预计它会带来什么后果？

一轮只改一点。要是同时换交互、流程、数据和提示词，下一次变好也不知道是哪一刀起了作用。

这个例子的反思卡可以只有四行：

• 第一个意外：任务、承诺和验收证据有了共同格式以后，协作摩擦才真正下降。大家是否看着同一个界面，影响反而不大。
• 判断：团队协作这个问题没有错，但完整平台做得太早；核心价值可能在一层很窄的任务交接规则。
• 保留 / 排除：保留明确授权、人来确认承诺、交付证据可追溯；暂时排除统一工作台、身份画像和完整组织系统。
• 下一版只改一件事：只做一张能被双方 Agent 读懂的标准任务单，让它走完发起、澄清、交付和验收，其他平台能力都不加。

分工：Agent 可以把事实整理成反思卡草稿，也可以提醒前后矛盾；“我想保留什么、愿意放弃什么”必须由人回答。

第六步：过停止闸，再离开探索

Demo 不是越多越好。继续生成版本也会消耗注意力，还会把“再看看”变成不做决定的借口。

过闸之前，先对两个问题给出明确答案：这是不是我想要的？还要不要继续？答案允许是“还不知道”。

停止闸有三个出口：

• 值得继续：带着已经形成的评价标准进入验证；
• 信息不足：预算还有剩余时，下一轮只改一个关键条件，再回去体验；
• 不值得继续：已经确认“这不是我想要的”，或者探索预算已经用完，直接停掉。

停止不是失败。它意味着我用一次有边界的探索，省下了后面更长的需求讨论、实现和返工。

第一步写下的时间、预算和版本上限就是硬边界。预算花完还在说“再看看”，本身就是一个该停下来的信号。

下面五项不会替我做决定，只用来检查这个决定是不是拍脑袋：

• 能不能回答“是不是我想要的、还要不要继续”，并说出依据；
• 能不能稳定说出最重要的两三个评价变量、愿意承担的取舍和最低标准；
• 零号线和至少一个 Demo 有没有完成同一个任务；如果要在多条路径中选方向，有没有比较过两个核心取舍不同的版本；
• 体验前的预测有没有被真实操作修正；
• 如果继续，能不能说清下一轮只验证什么、还剩多少预算、什么结果会让我停止。

放进这个例子里，结论可以是：“减少跨 Agent 协作中的人工传话，是我想继续解决的问题；先做完整团队平台不是。我愿意先用一项真实任务试轻量交接层；如果它不能减少人的转述和返工，反而制造更多消息，我就停止这个方向。”

分工：Agent 负责检查证据是否齐、预算是否用完、结论有没有偷换标准；继续、再试一轮还是停止，只能由人决定。

退出探索，只代表终于知道该验证什么

这是最容易混淆的一步。

Demo 顺利跑完，不代表真实用户愿意用。自己操作起来顺手，也不代表核心价值成立。模拟数据和固定脚本能完成一次演示，更不能证明系统已经可靠。

它们之间隔着一条证据链。任何一段合理，都不能替整条链作证。

离开探索前，先留一份很短的方向选择记录：我暂时选了什么，为什么选，保留和排除了哪些机制，Demo 已经说明了什么，还有什么不能说明。这份记录只给验证 Loop 提供输入，不需要扩写成新的 Spec。

放进这个例子里，我暂时选择“轻量任务交接层”。Demo 说明我想保留授权、承诺和验收证据，也说明完整平台暂时不是我要的；但它还不能证明这层规则真的会降低团队协作成本。

这里有一道必须划清的边界：Demo 阶段主要是我用挑选过的任务判断“我想要什么产品”；验证阶段必须换成真实协作者和他们正在推进的任务，判断“这个产品在协作中是否成立”。

验证 Loop 可以压成五步。

这五步同样不是要求作者全程陪跑。人必须参加的是：选定最危险的假设、确认验证契约、处理涉及授权和责任的例外、在验证闸前拍板。真实任务由目标用户完成，产品机制由 Agent 运行，过程记录、证据汇总和反证搜索也主要交给 Agent。

第一步：只挑最危险的假设

一次不要同时证明“有人需要、效果很好、技术稳定、还能付费”。先问：如果哪件事不成立，这个方向就失去继续投入的理由？

Agent 可以列出假设、寻找反方观点并按风险排序，但最终押哪一个，必须由承担投入的人决定。

这个例子里，最危险的假设是：Agent 介入以后，人的同步和返工会真的减少，同时不丢信息，也不越权承诺。结构化信息能否发送只是实现问题。

第二步：冻结验证契约

开跑前写下四样东西：要验证的假设、什么事实算支持、什么信号算失败、这轮明确不验证什么。再给验证本身设一个时间、人数或轮次预算，避免结果不好时不断改口径。

验证契约可以由 Agent 起草和固化，人只需在开跑前确认一次；确认后，Agent 不能因为结果不好而替人修改标准。

例如可以先写：

如果任务单明确了目标、上下文、边界、验收标准和授权级别，双方的个人 Agent 应该能完成日常澄清和依赖识别，只把真正涉及承诺与取舍的问题交给人，从而减少人的重复同步、返工和等待。

失败信号也要提前写：如果人工转述没有减少，Agent 产生了更多需要人整理的消息，或者出现信息丢失、错误承诺和被隐藏的分歧，这个方向就不能算成立。具体阈值没有通用答案，但必须在看到结果之前定。

第三步：跑最小真实闭环

让一个小团队拿正在推进的真实任务进入产品，完整走过“发起—对齐—承诺—交付证据—验收”。漂亮界面、完整权限后台和自动通知可以先模拟，任务交接、分歧升级、人的确认和最终验收不能模拟。

到了这一步，人和输入都要变成真实的。精致程度并不重要。

作者不需要守在每一步旁边。目标用户照常完成任务，Agent 运行核心机制；只有遇到授权、责任或关键取舍，才把问题升级给人。

第四步：记录事实，并主动找反证

记录人亲自搬运了几次信息、出现了多少轮澄清、哪些问题等待拍板、因为什么返工、Agent 有没有越过授权。事实和解释分开写。

同时检查正向结果是不是因为团队本来就熟、任务过于简单、发起人在后台人工补齐信息，或者大家为了配合测试而改变了平时的工作方式。即使任务完成了，也要问另一种解释：是产品减少了摩擦，还是这次协作者自己把缺口补上了？如果说不清，就只能记作“证据不足”。

这一阶段默认由 Agent 做重活：汇总日志、找异常、整理失败案例和提出其他解释。反证最好交给没有参与 Demo 制作的评审 Agent，避免让同一个 Agent 既交卷又判卷。人只复核关键证据，不需要手工阅读全部过程。

第五步：过验证闸

验证结束只有三种结论：

• 证据支持：这个假设暂时过关，继续验证下一个关键风险；重大风险都过关后，再进入 Logic First。
• 证据不足：预算还有剩余时，只改一个关键条件再跑一轮，不能同时换用户、任务和机制。
• 假设被否定：回到探索换方向，或者直接停止，不用为了已经做出的 Demo 继续投入。

Agent 可以提交证据包和建议，不能替人宣布方向成立，更不能因为已经投入很多就自动选择继续。

验证只负责减少一个关键未知。每一轮都应该留下更清楚的证据，或者更明确的停止理由，Demo 漂不漂亮放在后面。

这也是它节省注意力的地方：人不再全程泡在需求讨论、Demo 制作和过程管理里，而是在 Agent 把材料准备好之后进入，完成一次不可委托的判断，再退出流程。

Logic First 没有消失，只是回到正确的工位

通过验证之后，团队才真正决定要不要承担长期交付责任。

这时 Logic First 应该回来，而且要比以前更严格。

把验证得到的证据收回来，重新写正式需求和业务规则，明确异常边界、数据、权限与非功能要求。再做架构、任务拆分、测试、监控、部署和维护机制。

Demo 代码也要单独拍板。只是认知探针的部分直接丢掉；能复用的界面壳可以留下；方向正确但结构不适合维护的核心代码就重写。不能因为已经能跑，默认让临时代码变成正式地基。

PRD、UI 规格和交接包当然仍然重要。它们只是不该被拿来解决“我还不知道自己想要什么”这个问题。

下一次遇到模糊想法，可以先判断自己在哪个阶段

想法很多，但还不知道是否值得投入，就先用一个有边界的 Demo 回答：这是不是我想要的？还要不要继续？

已经决定继续，但还不知道具体做成什么，就再做多个核心取舍不同的 Demo。目标是长出评价标准。

知道想做什么，但不知道它是否成立，就先写失败条件，再跑最小真实闭环。目标是获得证据。

已经决定长期交付，就回收证据，重写正式需求和架构。目标是可靠运行。

探索时让 AI 帮我看见，验证时让事实决定去留，生产时再由人掌握逻辑和责任。

手头如果正好有一个“AI 已经帮我做出来，但我其实说不清为什么这样做”的项目，不妨先别继续加功能。

先问一句：它现在究竟还在探索、正在验证，还是已经被误当成生产？