让 Agent 实现一个功能它一个问题都没问就开始写速度极快逻辑自洽代码跑通了。你一看完全不符合预期三轮对话纠正下来每次都推翻前面一半代码。逻辑自洽和符合预期是两件事。要求从未被精确定义所以那个自洽的模型不一定是你的。你心里的模型被静默覆盖没人发现直到代码跑起来。混杂语藏进了一个人的内部对话这不是 AI 时代才有的问题。用户、产品、开发者三方常常各持一个模型谁的模型都没被显式对齐过。Eric Evans 在《领域驱动设计》里描述过这种状态日常讨论所使用的术语与代码中使用的术语不一致。甚至同一个人在讲话和写东西时使用的语言也不一致这导致的后果是对领域的深刻表述常常稍纵即逝根本无法记录到代码或文档中。Evans 把它类比成混杂语pidgin不同语言背景的人凑在一起做生意没有公共语言就地造一种够用的话适合当前任务但不像母语那样详尽。双方都感觉在说同一件事各自脑补的那部分谁也没看见。三方在场时混杂语至少还有摩擦面。产品和开发者对同一个词理解不一致吵一架就暴露了。AI 把产品解读和开发实现塞进同一个人的内部对话摩擦面就没了。混杂语没有消失只是藏起来藏到代码跑起来才现身。混杂语怎么冒出来藏起来的混杂语会以几种固定方式冒头。Agent 问代码已经回答的事代码本身就是模型的表达已编码的决定是已确认的领域事实拿它当开放问题问浪费的是收敛时间。它也会东问一榔头西问一棒子或者一问一答打乒乓球没有反馈环的建模永远在发散。更贵的是聊完之后。聊的时候方案说得好好的一到编码阶段又回到原点grill 阶段锁定了叫vertical slice编码阶段变量名变成layer_unit。操作名称不来自领域语言模型就没有进入代码grill 等于白做。Evans 说UBIQUITOUS LANGUAGE 的更改就是对模型的更改那么词汇停在会话里没进代码模型也就停在会话里。共识只当会议记录存档不被当作模型的当前快照引用它就是死的。先问需求真不真以上都是词不对齐的毛病。但在词之前还有一道关这事该不该做。词汇表可以做得干干净净锁定的却是一个没人真正需要的功能三方这次是真对齐了一起对着空气。所以拷问分两层需求那层在前。词义那层问你说的导出是指哪种导出需求那层问的是四件事为这事谁已经做过的最具体的一件事是什么花过时间、付过钱、搭过 workaround能点名一个具体的人或窄场景吗上线后对 TA 具体改变了什么现在的 workaround 是什么哪怕很脏它的代价是什么还能交付同样价值的最小版本长什么样。这四问都在找同一样东西——已经发生过的事。我们需要一个导出功能是意愿运营每周三手动复制两小时表格是证据。前者随时可以被推翻后者推翻不了。四个问题命中哪条问哪条没命中不硬凑但命中了就必须问到用户回答不能自己替他想一个合理答案填上。开发者说加个 CSV 导出时他要的是马上开工不会先去做一轮需求调研等到有人想起该验证需求代码已经写完了。编码入口是这些问题唯一会被撞见的地方——不是因为这里最适合问是因为别处根本不会问。这套问法本身不新。它就是用户访谈里那套别问未来意愿问过去行为只是访谈拿它对客户grill 拿它对需求提出者包括你自己提的需求。解法逼出共识锁定词汇未达成共识前不写任何实现代码。接口签名、文件结构、伪代码都不算共识算实现。这是 Hard Gate护栏没过不放行编码。过护栏的路径是线性的。先读现有代码和项目文档把代码已经回答的列成一句从现有代码确认X、Y、Z只列与本次任务有决策影响的。剩下的才是开放问题产品取舍、边界未定、技术岔路加上前面那四个探针。追问按决策树走每轮不超过 2 问每问给不超过 3 个选项加推荐用户答完立即用领域词汇复述确认[术语] [决定]。开放问题关完锁 Ubiquitous Language优先沿用项目已定义的术语只把本次新增的写进共识格式是[术语][一句话定义含边界]。再基于锁定词汇把任务分解成领域动作每条等于一条 vertical slice按依赖拓扑排序排序是产品决定。最后落盘共识摘要写进docs/feature/spec.md不超过 100 行超了压缩重写不追加。编码阶段读文件作为硬约束不依赖会话上下文。定义是一次压缩这两层拷问里最容易被当成形式主义的是锁词汇不就是列个词汇表吗但定义不是给词加注释是把一堆分散的要素压进一个名字。vertical slice背后压着四件事一个领域动作、端到端跑通、可独立验证、依赖已排序。下次说第三条 slice这四件事同时在场不必重述。压缩完就成了接口调用方只要名字不必展开内部。同时它划出一道视界命名了 slice任务就只能按领域动作切不会滑回先写 model 再写 controller的技术分层。词汇选定的那一刻切分方式也就选定了后面的分解、落盘、实现全部沿着这道视界走。所以一个好定义是贯穿整体的观点把散在需求文档、聊天记录、代码注释里的要素串成一条线。Ubiquitous Language 因此是用一组名字撑起复杂结构的骨架。LLM 输出变短是这件事的副作用。骨架搭好了它不用每轮重搭一遍同义漂移也没了生存空间——一个概念只有一个名字前后表述就没法打架。以前代码是自己一行行敲出来的理解是敲的副产品敲完自然就懂了现在几秒钟生成一屏写这一步不再顺带产出理解理解得单独付费。生成越快你参与得越浅读懂它就成了新的瓶颈——瓶颈从写移到了读。统一语言压的正是这笔理解成本。读到第三条 slice不必回去逐行反推它为什么这么切名字里压着的四件事直接展开spec 里一行[术语][定义]替代的是把整段会话重读一遍。同一个压缩过的名字对 Agent 是约束对你是重新进入自己项目的入口。小任务要不要也走一遍有个反对意见值得认真回答写代码这么便宜先跑起来再纠正不行吗加一个字段而已也要走完这一串答案是仪式量该分级共识不该。小、边界清晰、低歧义的任务跳过读码直接锁词加切片spec 可省或极短常规 feature 走完整流程跨切面、高度歧义的任务四个探针逐条追。分级分的是读码和追问的深浅锁词那一步不分级。小任务照样在统一语言的约束下它之所以边界清晰、之所以往往一条探针都不命中前提是相关词汇已经锁过、这事的价值早就有人验证过。词汇还没锁的任务不叫小任务叫看起来小的任务。落盘之后spec 是下一棒的输入。用户要求讨论实现时才多产出一份plan.md每条 slice 不超过 3 行只写思路和模块不写代码实现过程中往 plan 补实际模块位置spec 里的 slice 打勾时指向 plan 的对应条目。两个文件一个管要做什么一个管怎么做都不靠会话记忆交接。三方的模型在写第一行代码之前通过 Ubiquitous Language 对齐剩下的才是执行。说不清用哪些词模型就还没成形这时候让 Agent 动手它只会替你把没想清的部分猜完。注本 skill 的设计遵循 write-skill。skill 不是教条只为铲除假设未对齐和混杂语这两个坏行为。坏行为消失skill 就该停止维护。开源地址grill-before-codinggrill-before-codingdescription: 编码前使用想清楚再动手。编码前锻造三方用户 / 产品 / 开发者的 Ubiquitous Language逼出共识锁定词汇再放行编码。你是提问的协调者产品取舍的回答权属于用户。Hard Gate未达成共识前不写任何实现代码。接口签名、文件结构、伪代码都不算共识算实现。共识的标志所有开放问题已关闭用户选择 / 用户说你定 / 从代码确认且领域词汇表已锁定。步骤评估 scope匹配仪式用任务描述 轻量代码扫描分级仪式量随 scope 走Lightweight小、边界清晰、低歧义改错别字、按已有模式加一个字段。→ 跳过步骤 1–3直接锁词步骤 4 切片步骤 5spec 可省或极短。Standard常规 feature 或有边界的重构有若干决策要定。→ 走完整 1–7。Deep跨切面、战略性、或高度歧义。→ 走完整 1–7步骤 2 探针逐条追步骤 7 方案发散必做。scope 不清时先问一个定位问题再继续。Done when: 分级已定用户未异议或已修正。读代码即读模型先读docs/CONTEXT.md如果存在确认项目已锁定的领域词汇和边界。再读目标代码库中与本次任务相关的现有实现。代码是模型的表达已编码的决定是已确认的领域事实。输出从现有代码确认X、Y、Z。按此推进。只列与本次任务有决策影响的。外部扫描Standard/Deep快速判断业内是否有成熟做法、开源方案或通用组件能覆盖本次任务——读别人的代码也是读模型社区已解决的问题不必重造。有则把复用现成 vs 自建作为一条[技术岔路]交给步骤 2。此处只判断复用/自建的岔路不做选型细节也不让外部库的命名倒灌进步骤 4 的领域词汇。读外部即读证据外部事实某库怎么用、某规格的约束、业内标准做法要追一手来源——官方文档、源码、规格不用二手转述或凭记忆。每条外部结论标来源分清 fact来源背书和 inference自己的推断。追不到就标待确认只当待验证的开放问题不进共识。Done when: 用户看到确认列表未提出异议或已修正。识别开放问题找出代码无法回答的产品取舍、边界未定、技术岔路。每个标注类型[产品取舍]/[边界未定]/[技术岔路]。不问代码已回答的。不问用户已在对话中说过的。拷问需求本身rigor probes不止找代码答不了的还要扫用户开场里想没想清楚的漏洞。词义对齐了对齐到的仍可能是没人真正需要的东西。命中哪条问哪条没命中不硬凑Lightweight 通常零条Deep 逐条追[证据]只说想要/需要但拿不出任何人已经为此做过的事花过时间、付过钱、搭过 workaround。→ 问为这事谁已经做过的最具体的一件事是什么[具体性]受益人描述得太抽象不脑补就没法设计。→ 问能点名一个具体的人/窄场景吗这东西上线后对 TA 具体改变了什么[反事实]没说清今天遇到这问题时怎么办、不做这事会怎样。→ 问现在的 workaround 是什么哪怕很脏它的代价是什么[依附]把某个具体方案当成要做的东西而不是它要交付的价值没对比过更小的形态。→ 问还能交付同样价值的最小版本长什么样[复用/自建]疑似已有成熟方案覆盖来自步骤 1 外部扫描。→ 问复用现成的还是自建现成的哪里不合身只定方向不陷入选型细节。Done when: 命中的探针都已列为开放问题进入步骤 3 追问。决策树追问优先级产品取舍 边界未定 技术岔路。提问机制见「提问约定」。用户回答后立即用领域词汇复述“确认[术语] [决定]。”用户回答引出新问题 → 追加到列表末尾不插队。Done when: 所有开放问题已关闭。锁定 Ubiquitous Language优先沿用docs/CONTEXT.md中已定义的项目级术语不重建。仅将步骤 1–3 暴露的、本次新增的术语加入共识摘要。格式[术语][一句话定义含边界]例vertical slice从 UI 到 DB 的完整用户故事切片不含横切关注点。后续所有输出含编码阶段的命名必须使用这些词汇不用同义替换。通过sync-project-knowledge沉淀到docs/CONTEXT.md。Done when: 词汇表已列出用户未异议。分解为 vertical slices基于已锁定词汇将本次任务分解为若干领域动作。每条 一条 vertical slice。格式[用户] [领域动词] [领域对象]必须使用步骤 4 锁定的词汇。对 slice 间的依赖做拓扑排序产出线性列表。依赖少→多、用户价值高→低。排序是产品决定。Done when: slice 列表已列出且命名使用领域词汇用户未异议。输出共识摘要落盘为 spec写入docs/feature-or-bug/spec.md。路径中的feature-or-bug用本次任务的领域词汇命名。格式Updated: YYYY-MM-DD HH:00 ## Problem 一句话说清要解决什么问题。 ## Decisions - 已确认从代码与项目文档... - 已确认用户决定... ## Vocabulary [术语][一句话定义含边界] × N ## Slices 1. [ ] [用户] [领域动词] [领域对象] 2. [ ] ... ## Out of Scope - ...[ ]为未实现标记实现后由 vertical-tdd 改为[x]并加 pointer。≤ 100 行。超过时压缩重写不追加。每行只保留决策信息删掉推理过程。此文件是模型的当前快照。编码阶段读此文件作为硬约束可以随时 handoff不依赖会话上下文。Done when: 文件已写入用户说开始或等价确认。可选产出 plan当用户要求讨论实现时触发。否则跳过spec 已足够交给 vertical-tdd。落 plan 前先做一次方案发散Deep 必做Standard 有多条岔路时做给 2–3 个 mechanism 级方案其中至少一个用非显然角度——inversion反着做会怎样/ constraint removal去掉某个限制会怎样/ analogy别的领域怎么解。步骤 1 外部扫描发现成熟方案时“复用开源/通用组件必须作为其中一个方案摆出来并明确本次是复用现成 / 扩展已有能力 / 自建三者中的哪一种。先摆全部方案再评优劣最后给推荐避免过早锚定。可再带一个高上限挑战选项”花小代价换更大价值/更低长期维护成本的相邻加法。方案只到 mechanism 层不写列名/文件路径/接口签名。写入docs/feature-or-bug/plan.md。格式Updated: YYYY-MM-DD HH:00 ## 1. [用户] [领域动词] [领域对象] 思路一句话 模块TDD 过程中补充每条 slice ≤ 3 行思路 模块。不写代码、不写接口签名。此文件是技术方案的骨架TDD 过程中由 vertical-tdd 补入模块位置。Done when: plan 已写入用户未异议。提问约定每轮 ≤ 2 问一次只推进一个决策。不把相关子问题堆进一条消息——堆问会稀释回答。默认用阻塞式提问工具本环境提供的选择/确认工具给 ≤ 3 个选项 推荐让用户点选而非从零写。选择题就用选择题的形式问。仅当问题本身是开放的才用开放式提问答案天然是叙述性的“讲讲你怎么走到这一步的”或问题是诊断/内省型、给了选项反而会诱导用户往那几个轴上想如你最担心什么——4 个选项会把用户从真正在意的点上带偏或你凑不出 3 个真正不同、都可能对的选项凑得很勉强 这题就是开放题。步骤 2 的 rigor probes 属此类用开放式问逼用户产出真实观察而不是勾选。开放式提问也遵守每轮 ≤ 2 问且问题要具体到能钓出实质回答不问你怎么看这种没抓手的。追问时不解释为什么问超过一句话。直接问。不说这是个好问题“让我想想”。用户说你定→ 给出选择 一句话理由。Context Pointersdocs/feature-or-bug/spec.md步骤 6 的落盘目标。编码阶段读此文件作为硬约束替代会话上下文。docs/feature-or-bug/plan.md步骤 7 的可选产物。技术方案骨架TDD 过程中补入模块位置。docs/CONTEXT.md项目已锁定的领域语言。步骤 1 先读步骤 4 优先沿用、不重建。vertical-tddspec 和 plan 的消费者。步骤 5 产出的 slice 列表是 vertical-tdd step 1 的直接输入vertical-tdd 实现后回写 spec画勾pointer和 plan补模块位置。sync-project-knowledge项目级知识同步。当需要把本次新增术语沉淀到docs/CONTEXT.md时触发。write-skill当 grill 对象是写一条 skill时尺子切换为 skill 格式规范。Eric Evans《领域驱动设计》第 2、3 章Ubiquitous Language 和 Model-Driven Design 的原始论述。当需要判断这个共识够不够深时参考。Done Whendocs/feature-or-bug/spec.md已写入包含## Slices段slice 命名使用领域词汇每条带[ ]标记。若用户要求讨论实现docs/feature-or-bug/plan.md已写入。命中的 rigor probes 都已问过并得到用户回答。进入共识的外部结论都有一手来源无来源的标为待确认不留在共识里。
让 Agent 实现一个功能它一个问题都没问就开始写速度极快逻辑自洽代码跑通了。你一看完全不符合预期三轮对话纠正下来每次都推翻前面一半代码。逻辑自洽和符合预期是两件事。要求从未被精确定义所以那个自洽的模型不一定是你的。你心里的模型被静默覆盖没人发现直到代码跑起来。混杂语藏进了一个人的内部对话这不是 AI 时代才有的问题。用户、产品、开发者三方常常各持一个模型谁的模型都没被显式对齐过。Eric Evans 在《领域驱动设计》里描述过这种状态日常讨论所使用的术语与代码中使用的术语不一致。甚至同一个人在讲话和写东西时使用的语言也不一致这导致的后果是对领域的深刻表述常常稍纵即逝根本无法记录到代码或文档中。Evans 把它类比成混杂语pidgin不同语言背景的人凑在一起做生意没有公共语言就地造一种够用的话适合当前任务但不像母语那样详尽。双方都感觉在说同一件事各自脑补的那部分谁也没看见。三方在场时混杂语至少还有摩擦面。产品和开发者对同一个词理解不一致吵一架就暴露了。AI 把产品解读和开发实现塞进同一个人的内部对话摩擦面就没了。混杂语没有消失只是藏起来藏到代码跑起来才现身。混杂语怎么冒出来藏起来的混杂语会以几种固定方式冒头。Agent 问代码已经回答的事代码本身就是模型的表达已编码的决定是已确认的领域事实拿它当开放问题问浪费的是收敛时间。它也会东问一榔头西问一棒子或者一问一答打乒乓球没有反馈环的建模永远在发散。更贵的是聊完之后。聊的时候方案说得好好的一到编码阶段又回到原点grill 阶段锁定了叫vertical slice编码阶段变量名变成layer_unit。操作名称不来自领域语言模型就没有进入代码grill 等于白做。Evans 说UBIQUITOUS LANGUAGE 的更改就是对模型的更改那么词汇停在会话里没进代码模型也就停在会话里。共识只当会议记录存档不被当作模型的当前快照引用它就是死的。先问需求真不真以上都是词不对齐的毛病。但在词之前还有一道关这事该不该做。词汇表可以做得干干净净锁定的却是一个没人真正需要的功能三方这次是真对齐了一起对着空气。所以拷问分两层需求那层在前。词义那层问你说的导出是指哪种导出需求那层问的是四件事为这事谁已经做过的最具体的一件事是什么花过时间、付过钱、搭过 workaround能点名一个具体的人或窄场景吗上线后对 TA 具体改变了什么现在的 workaround 是什么哪怕很脏它的代价是什么还能交付同样价值的最小版本长什么样。这四问都在找同一样东西——已经发生过的事。我们需要一个导出功能是意愿运营每周三手动复制两小时表格是证据。前者随时可以被推翻后者推翻不了。四个问题命中哪条问哪条没命中不硬凑但命中了就必须问到用户回答不能自己替他想一个合理答案填上。开发者说加个 CSV 导出时他要的是马上开工不会先去做一轮需求调研等到有人想起该验证需求代码已经写完了。编码入口是这些问题唯一会被撞见的地方——不是因为这里最适合问是因为别处根本不会问。这套问法本身不新。它就是用户访谈里那套别问未来意愿问过去行为只是访谈拿它对客户grill 拿它对需求提出者包括你自己提的需求。解法逼出共识锁定词汇未达成共识前不写任何实现代码。接口签名、文件结构、伪代码都不算共识算实现。这是 Hard Gate护栏没过不放行编码。过护栏的路径是线性的。先读现有代码和项目文档把代码已经回答的列成一句从现有代码确认X、Y、Z只列与本次任务有决策影响的。剩下的才是开放问题产品取舍、边界未定、技术岔路加上前面那四个探针。追问按决策树走每轮不超过 2 问每问给不超过 3 个选项加推荐用户答完立即用领域词汇复述确认[术语] [决定]。开放问题关完锁 Ubiquitous Language优先沿用项目已定义的术语只把本次新增的写进共识格式是[术语][一句话定义含边界]。再基于锁定词汇把任务分解成领域动作每条等于一条 vertical slice按依赖拓扑排序排序是产品决定。最后落盘共识摘要写进docs/feature/spec.md不超过 100 行超了压缩重写不追加。编码阶段读文件作为硬约束不依赖会话上下文。定义是一次压缩这两层拷问里最容易被当成形式主义的是锁词汇不就是列个词汇表吗但定义不是给词加注释是把一堆分散的要素压进一个名字。vertical slice背后压着四件事一个领域动作、端到端跑通、可独立验证、依赖已排序。下次说第三条 slice这四件事同时在场不必重述。压缩完就成了接口调用方只要名字不必展开内部。同时它划出一道视界命名了 slice任务就只能按领域动作切不会滑回先写 model 再写 controller的技术分层。词汇选定的那一刻切分方式也就选定了后面的分解、落盘、实现全部沿着这道视界走。所以一个好定义是贯穿整体的观点把散在需求文档、聊天记录、代码注释里的要素串成一条线。Ubiquitous Language 因此是用一组名字撑起复杂结构的骨架。LLM 输出变短是这件事的副作用。骨架搭好了它不用每轮重搭一遍同义漂移也没了生存空间——一个概念只有一个名字前后表述就没法打架。以前代码是自己一行行敲出来的理解是敲的副产品敲完自然就懂了现在几秒钟生成一屏写这一步不再顺带产出理解理解得单独付费。生成越快你参与得越浅读懂它就成了新的瓶颈——瓶颈从写移到了读。统一语言压的正是这笔理解成本。读到第三条 slice不必回去逐行反推它为什么这么切名字里压着的四件事直接展开spec 里一行[术语][定义]替代的是把整段会话重读一遍。同一个压缩过的名字对 Agent 是约束对你是重新进入自己项目的入口。小任务要不要也走一遍有个反对意见值得认真回答写代码这么便宜先跑起来再纠正不行吗加一个字段而已也要走完这一串答案是仪式量该分级共识不该。小、边界清晰、低歧义的任务跳过读码直接锁词加切片spec 可省或极短常规 feature 走完整流程跨切面、高度歧义的任务四个探针逐条追。分级分的是读码和追问的深浅锁词那一步不分级。小任务照样在统一语言的约束下它之所以边界清晰、之所以往往一条探针都不命中前提是相关词汇已经锁过、这事的价值早就有人验证过。词汇还没锁的任务不叫小任务叫看起来小的任务。落盘之后spec 是下一棒的输入。用户要求讨论实现时才多产出一份plan.md每条 slice 不超过 3 行只写思路和模块不写代码实现过程中往 plan 补实际模块位置spec 里的 slice 打勾时指向 plan 的对应条目。两个文件一个管要做什么一个管怎么做都不靠会话记忆交接。三方的模型在写第一行代码之前通过 Ubiquitous Language 对齐剩下的才是执行。说不清用哪些词模型就还没成形这时候让 Agent 动手它只会替你把没想清的部分猜完。注本 skill 的设计遵循 write-skill。skill 不是教条只为铲除假设未对齐和混杂语这两个坏行为。坏行为消失skill 就该停止维护。开源地址grill-before-codinggrill-before-codingdescription: 编码前使用想清楚再动手。编码前锻造三方用户 / 产品 / 开发者的 Ubiquitous Language逼出共识锁定词汇再放行编码。你是提问的协调者产品取舍的回答权属于用户。Hard Gate未达成共识前不写任何实现代码。接口签名、文件结构、伪代码都不算共识算实现。共识的标志所有开放问题已关闭用户选择 / 用户说你定 / 从代码确认且领域词汇表已锁定。步骤评估 scope匹配仪式用任务描述 轻量代码扫描分级仪式量随 scope 走Lightweight小、边界清晰、低歧义改错别字、按已有模式加一个字段。→ 跳过步骤 1–3直接锁词步骤 4 切片步骤 5spec 可省或极短。Standard常规 feature 或有边界的重构有若干决策要定。→ 走完整 1–7。Deep跨切面、战略性、或高度歧义。→ 走完整 1–7步骤 2 探针逐条追步骤 7 方案发散必做。scope 不清时先问一个定位问题再继续。Done when: 分级已定用户未异议或已修正。读代码即读模型先读docs/CONTEXT.md如果存在确认项目已锁定的领域词汇和边界。再读目标代码库中与本次任务相关的现有实现。代码是模型的表达已编码的决定是已确认的领域事实。输出从现有代码确认X、Y、Z。按此推进。只列与本次任务有决策影响的。外部扫描Standard/Deep快速判断业内是否有成熟做法、开源方案或通用组件能覆盖本次任务——读别人的代码也是读模型社区已解决的问题不必重造。有则把复用现成 vs 自建作为一条[技术岔路]交给步骤 2。此处只判断复用/自建的岔路不做选型细节也不让外部库的命名倒灌进步骤 4 的领域词汇。读外部即读证据外部事实某库怎么用、某规格的约束、业内标准做法要追一手来源——官方文档、源码、规格不用二手转述或凭记忆。每条外部结论标来源分清 fact来源背书和 inference自己的推断。追不到就标待确认只当待验证的开放问题不进共识。Done when: 用户看到确认列表未提出异议或已修正。识别开放问题找出代码无法回答的产品取舍、边界未定、技术岔路。每个标注类型[产品取舍]/[边界未定]/[技术岔路]。不问代码已回答的。不问用户已在对话中说过的。拷问需求本身rigor probes不止找代码答不了的还要扫用户开场里想没想清楚的漏洞。词义对齐了对齐到的仍可能是没人真正需要的东西。命中哪条问哪条没命中不硬凑Lightweight 通常零条Deep 逐条追[证据]只说想要/需要但拿不出任何人已经为此做过的事花过时间、付过钱、搭过 workaround。→ 问为这事谁已经做过的最具体的一件事是什么[具体性]受益人描述得太抽象不脑补就没法设计。→ 问能点名一个具体的人/窄场景吗这东西上线后对 TA 具体改变了什么[反事实]没说清今天遇到这问题时怎么办、不做这事会怎样。→ 问现在的 workaround 是什么哪怕很脏它的代价是什么[依附]把某个具体方案当成要做的东西而不是它要交付的价值没对比过更小的形态。→ 问还能交付同样价值的最小版本长什么样[复用/自建]疑似已有成熟方案覆盖来自步骤 1 外部扫描。→ 问复用现成的还是自建现成的哪里不合身只定方向不陷入选型细节。Done when: 命中的探针都已列为开放问题进入步骤 3 追问。决策树追问优先级产品取舍 边界未定 技术岔路。提问机制见「提问约定」。用户回答后立即用领域词汇复述“确认[术语] [决定]。”用户回答引出新问题 → 追加到列表末尾不插队。Done when: 所有开放问题已关闭。锁定 Ubiquitous Language优先沿用docs/CONTEXT.md中已定义的项目级术语不重建。仅将步骤 1–3 暴露的、本次新增的术语加入共识摘要。格式[术语][一句话定义含边界]例vertical slice从 UI 到 DB 的完整用户故事切片不含横切关注点。后续所有输出含编码阶段的命名必须使用这些词汇不用同义替换。通过sync-project-knowledge沉淀到docs/CONTEXT.md。Done when: 词汇表已列出用户未异议。分解为 vertical slices基于已锁定词汇将本次任务分解为若干领域动作。每条 一条 vertical slice。格式[用户] [领域动词] [领域对象]必须使用步骤 4 锁定的词汇。对 slice 间的依赖做拓扑排序产出线性列表。依赖少→多、用户价值高→低。排序是产品决定。Done when: slice 列表已列出且命名使用领域词汇用户未异议。输出共识摘要落盘为 spec写入docs/feature-or-bug/spec.md。路径中的feature-or-bug用本次任务的领域词汇命名。格式Updated: YYYY-MM-DD HH:00 ## Problem 一句话说清要解决什么问题。 ## Decisions - 已确认从代码与项目文档... - 已确认用户决定... ## Vocabulary [术语][一句话定义含边界] × N ## Slices 1. [ ] [用户] [领域动词] [领域对象] 2. [ ] ... ## Out of Scope - ...[ ]为未实现标记实现后由 vertical-tdd 改为[x]并加 pointer。≤ 100 行。超过时压缩重写不追加。每行只保留决策信息删掉推理过程。此文件是模型的当前快照。编码阶段读此文件作为硬约束可以随时 handoff不依赖会话上下文。Done when: 文件已写入用户说开始或等价确认。可选产出 plan当用户要求讨论实现时触发。否则跳过spec 已足够交给 vertical-tdd。落 plan 前先做一次方案发散Deep 必做Standard 有多条岔路时做给 2–3 个 mechanism 级方案其中至少一个用非显然角度——inversion反着做会怎样/ constraint removal去掉某个限制会怎样/ analogy别的领域怎么解。步骤 1 外部扫描发现成熟方案时“复用开源/通用组件必须作为其中一个方案摆出来并明确本次是复用现成 / 扩展已有能力 / 自建三者中的哪一种。先摆全部方案再评优劣最后给推荐避免过早锚定。可再带一个高上限挑战选项”花小代价换更大价值/更低长期维护成本的相邻加法。方案只到 mechanism 层不写列名/文件路径/接口签名。写入docs/feature-or-bug/plan.md。格式Updated: YYYY-MM-DD HH:00 ## 1. [用户] [领域动词] [领域对象] 思路一句话 模块TDD 过程中补充每条 slice ≤ 3 行思路 模块。不写代码、不写接口签名。此文件是技术方案的骨架TDD 过程中由 vertical-tdd 补入模块位置。Done when: plan 已写入用户未异议。提问约定每轮 ≤ 2 问一次只推进一个决策。不把相关子问题堆进一条消息——堆问会稀释回答。默认用阻塞式提问工具本环境提供的选择/确认工具给 ≤ 3 个选项 推荐让用户点选而非从零写。选择题就用选择题的形式问。仅当问题本身是开放的才用开放式提问答案天然是叙述性的“讲讲你怎么走到这一步的”或问题是诊断/内省型、给了选项反而会诱导用户往那几个轴上想如你最担心什么——4 个选项会把用户从真正在意的点上带偏或你凑不出 3 个真正不同、都可能对的选项凑得很勉强 这题就是开放题。步骤 2 的 rigor probes 属此类用开放式问逼用户产出真实观察而不是勾选。开放式提问也遵守每轮 ≤ 2 问且问题要具体到能钓出实质回答不问你怎么看这种没抓手的。追问时不解释为什么问超过一句话。直接问。不说这是个好问题“让我想想”。用户说你定→ 给出选择 一句话理由。Context Pointersdocs/feature-or-bug/spec.md步骤 6 的落盘目标。编码阶段读此文件作为硬约束替代会话上下文。docs/feature-or-bug/plan.md步骤 7 的可选产物。技术方案骨架TDD 过程中补入模块位置。docs/CONTEXT.md项目已锁定的领域语言。步骤 1 先读步骤 4 优先沿用、不重建。vertical-tddspec 和 plan 的消费者。步骤 5 产出的 slice 列表是 vertical-tdd step 1 的直接输入vertical-tdd 实现后回写 spec画勾pointer和 plan补模块位置。sync-project-knowledge项目级知识同步。当需要把本次新增术语沉淀到docs/CONTEXT.md时触发。write-skill当 grill 对象是写一条 skill时尺子切换为 skill 格式规范。Eric Evans《领域驱动设计》第 2、3 章Ubiquitous Language 和 Model-Driven Design 的原始论述。当需要判断这个共识够不够深时参考。Done Whendocs/feature-or-bug/spec.md已写入包含## Slices段slice 命名使用领域词汇每条带[ ]标记。若用户要求讨论实现docs/feature-or-bug/plan.md已写入。命中的 rigor probes 都已问过并得到用户回答。进入共识的外部结论都有一手来源无来源的标为待确认不留在共识里。
)
