从 idea 到可提交：黑客松交付流水线
来源：2026-11 Aholo 黑客松仓（yhyu13/Hackthon_Aholo_20261107）实战蒸馏。
文中每条主张都带记录位置：仓内文件路径，或 issue 评论链接——两轮独立评审的原始结论只存在于
issue 评论，PR 的 review 区是空的，所以这里直接给出评论链接。逐条映射见 references/evidence-map.md。
（v1.1.0 合并了两个并行会话的产出：手法 7/8 与「单文件交付」一节，以及路径锚定与证据映射。）
一句话：先把「能答的问题」找出来，再把答案写成可验证的文档，最后把文档变成能演的东西。 顺序不能倒，倒在哪一步，后面全部返工。
何时调用
- 用户说「做个选题 / 写大纲 / 写正文 / 写 PRD / 做路演 / 做 demo / 明天就比赛」
- 用户拿到赛题、评分表、课程 PPT，要判断「我们该做什么」
- 用户问「我们比别人新在哪」「怎么讲才不被问倒」
不调用：已有冻结 spec 的实现任务（直接做代码）；纯文案润色；没有截止时间的探索。
五个阶段与各自的验收门
| 阶段 | 产出 | 验收门（不过不许进下一阶段） |
|---|---|---|
| 1 收敛 | 三栏表：发散项 / 为什么砍 / 留下什么 | 每个留下项都能回答「有可判定的对错吗」「截止前跑得完吗」「非这个技术不可吗」 |
| 2 大纲 | 分页大纲，每页一句话结论 | 每页标题本身就是结论，不是「关于 XX」 |
| 3 正文 | 按赛方结构写的完整文稿 | 每个事实带来源级别；每个未验证项带状态标记 |
| 4 评审 | 独立上下文的批评意见 + 修订版 | 至少一轮外部批评；每条阻塞项有回应 |
| 5 交付 | PRD / 夜班交接 / demo 排期 | 接手者读完一页就能开工，不需要问原作者 |
八个硬手法
1 状态标记，防「把假设写成完成」
全文只允许三种状态：已核实（有 2–3 级来源）/ 计划（方案定了没验证）/ 待补（依据未定）。
写作时不许混用，交稿前只改状态、不改措辞。
为什么这条最值钱：它可以被机器查。状态标记不是靠人眼盯，而是写成反例断言—— 把违规措辞当反例喂给验收器，验收器必须拒绝它。
证据：本项目出现过同一件事在两份正本里口径相反——docs/pitch/topic-body-v7.md §2.2 写
「Lux3D 管线还在验证」，而 docs/pitch/topic-outline-v5.html 的「5 总结与展望」写
「证明了：约束是真的、Lux3D 管线能跑通、代价可以被看见」。正文改了状态、大纲没跟着改，
就变成「未验证写成已完成」。这类问题肉眼最容易放过，所以要用验收器拦。
本仓把它落成了可执行断言：PRD 语义验收器（specs/005-hackathon-prd/validate_prd.py）
把「已解除 / 已满足 / 已完成」直接列为 U-10 未决项的违规措辞并拒绝，
同时禁止「把旧 QA 当新证据」、禁止在提交时间未核对时写死日期。
2 正本单一化
每个决策只留一份正本，其他文档引用它，不复制它。 决策变化写进决策记录的「定案」一节，标明影响哪几份正本。
证据：中途出现过大纲 v5、正文 v5.2、PRD v1.2 三份口径互相矛盾，实现方读哪份都可能错。
收口办法是《选题大纲决策记录》八节结构：口径定稿 / 版本演进 / 关键决策与被否决的方案 /
逐项核实 / 评分对齐 / 未决事项 / 文件清单 / 来源（docs/pitch/decisions.md）。
「被否决的方案」一节最值钱：它保存了「为什么不选另一条路」，避免下一届重新讨论同一个问题。
3 风险前置：先验证不可降级的东西
找出「一旦失败，整个方案归零」的那一件事，放到排期第一小时。 其余部分都可以缩，这一件不能缩。
证据：本项目是「Lux3D 能不能出可用资产」，定在 H2。排期原则是风险倒序，不是功能倒序。
落地形态是 48 小时 Go/No-Go 闸门（docs/review-gate/README.md）：闸门对象唯一化到 U-10，
三步最小验证、总耗时 ≤48 小时、明确「不写产品代码」，并配「判定与降级」与三条闸门纪律。
关键差别：闸门对象只有一个。列三个闸门等于没有闸门。
4 独立上下文评审
自己写的东西自己看不出来。用独立上下文的评审者，给它可检查的标准（不是「好不好」）， 每轮只修阻塞项。典型能抓到的：
- 数字前后不一致（87 米与 60.8 米并存）
- 交叉引用指向不存在的小节
- 计数错误（表格里 4 条待补，正文写「三条」）
- 口径偷换（用「设计保留面积」论证「法定保护面积」）
- false-green：某个编号非法或带空格时校验器本该失败，实际却通过了
记录位置：两轮真实评审的原始结论在 issue #25 的评论里——
第 1 轮（PR #47，REQUEST_CHANGES，四项可检查型问题）：
2026-11-06T17:15:25Z 评论；
第 2 轮（PR #76 / #77，DSH 只读沙箱，changes_requested，1 critical + 4 major + 4 minor，
其中 critical 是「评审期间 worktree 脏」——评审对象本身不干净）：
2026-11-07T10:56:03Z 评论。
5 用真实案例定坐标
至少两类对照，缺一类就说不清自己新在哪：
- 同类产品（真实存在、可查证、最好亲自用一遍）
- 同题材参考件（往届作品、方案论证片、行业案例）
做成一张四列对照表：形态 / 代价 / 判据 / 用户角色。 最后压出一句话核心价值，这句话要能直接当答辩第一句。
证据：竞品形式对比与「我们欠缺清单」（docs/competitor-review/README.md +
docs/competitor-review/team-gap.md，对照表列头是「维度 / 我们 / 他们 / 判断」）给同类产品坐标；三案例横评
（docs/video-ref/design/04-cross-case-comparison.md）是三支 B 站设计类视频
（王封矿 / 浦东水泥厂 / 西安六村堡）的论证骨架与驱动类型横评，给同题材参考件坐标，两者并列才成立。
6 版本留档，永不覆盖
每改一版另存新号（v1 → v2 → …），旧版原样留着。 不覆盖的理由不是洁癖：评审回路需要对比，事故复盘需要追溯，换人接手需要看到演进。
证据：docs/pitch/decisions.md 第二节逐版留档大纲 v1 → v5 的演进与每次改动的原因；
PRD v1.1 未另存文件，只存在于 git 历史（PR #47 / #61）；当前版本是 v2.1
（docs/prd/product-prd-v2.1.md），旧版要对比得回 git 历史查。
7 核心机制必须是动词链
- 反例：「提供沉浸式体验」「赋能文化传承」——形容词，不可验
- 正例：「做选择 → 看代价 → 对比现实 → 理解判断」
- 检验：每一步能否在屏幕上指到一个 UI 落点。指不出来的那一步，就是没做。
证据：本项目核心机制写成形容词版时答辩无法自证；改成动词链后，四步分别对得上结果页的一个区块，缺哪块一眼看得出。
8 承诺降级：能答几个就承诺几个
写「用户能收获什么」之前，逐条问：屏幕上有没有对应的落点？没有的删掉。 宁可承诺三问全部答得上，不要列五问三问含糊——多承诺一个答不出的，就是三分钟说教。
证据：原本列五问，其中「钱谁出」「改完谁被挤走」两行在时限内排不进结果页，降为三问；降级理由写进决策记录，不偷偷删。
单文件交付：HTML 与图
- 内联 CSS / JS / SVG，零外部请求，双击即开，断网可放映
- mermaid 竖排超过 4 个节点，在横屏投影上通常难以辨认：改
flowchart LR并缩短节点标签；flowchart.padding调到 30+ 可防中文标签溢出节点框 - 渲染办法：内联 mermaid.js 起一页，无头 Chrome 跑
--dump-dom，把<svg>抠出来内联进文档——比在文档里引用 3 MB 的库轻，也不怕断网 - 查外链：
grep -o 'https\?://[^"]*' 文件 | sort -u，只剩w3.org命名空间才算干净（xmlns不是网络请求）
三条红线
- 不编造来源。产品是否真实存在、数字是否有出处、图片是否本人可授权，逐条落实； 落实不了就标「未亲验」。
- 不用生成图冒充实景。AI 图只能放示意位，每张标「AI 生成」。 一旦拿它当现场证据，整节论证会被一句「这是实拍吗」问穿。
- 不把没做的写成做了。成果章节写「计划态」，等验收后只改状态标记。
排期模板（黑客松 12 小时）
| 时段 | 比例 | 做什么 |
|---|---|---|
| 前 20% | 方向 + 技术验证 | 只验证最大风险那一条，拿到可打开的产物 |
| 中间 40% | 制作 | 主回路跑通，范围可缩，机制不缩 |
| 后 30% | 测试 | 真跑五遍、录屏、抓报错；这段最容易被压缩，也最容易翻车 |
| 最后 10% | 展示 | 演示视频、海报、PPT、掐表排练 |
课程若给的是别的比例，按课程来；课程没给，用这个。
路演顺序（多数赛制通用）
- 先演：第一屏就给可操作画面，不要开场讲背景
- 再讲问题：什么场景、什么问题、谁的问题
- 讲机制：核心链路四步，技术栈承担哪一环
- 收在局限：做到了什么、没做到什么
局限要主动写。评委问「你们怎么知道用户有这个问题」，答案最好是「我们不知道，这是待验证的假设」， 而不是现编一个数据。
何时失效
- 赛制没有明确评分表，也没给课程材料：先要评分口径，否则整条流水线没有靶子
- 团队没有决策人：正本单一化会退化成「谁都能改」
- 交付周期长于两周：这套节奏是为 8–12 小时压缩设计的，长周期要换成迭代制
本仓落地样例（均为 Aholo 仓 main 上已存在的路径）
| 产物 | 路径 |
|---|---|
| 决策记录（八节正本） | docs/pitch/decisions.md |
| 选题大纲（单文件 HTML，23 页，左右翻页） | docs/pitch/topic-outline-v5.html |
| 路演 deck 与逐字稿 | docs/pitch/roadshow/ |
| PRD 正文（v1.2，已被 v2.1 取代） | docs/prd/product-prd.md |
| PRD 语义验收器（反例断言） | specs/005-hackathon-prd/validate_prd.py |
| 评审对账 + 48h Go/No-Go 闸门 | docs/review-gate/README.md |
| 讲师四张卡（空间 / 问题 / Lux3D / 项目）→ 价值映射 | docs/onboard-value/README.md |
| 竞品形式对比与欠缺清单 | docs/competitor-review/README.md |
| 案例横评（坐标用） | docs/video-ref/design/04-cross-case-comparison.md |
| 选题正文长文 | docs/pitch/topic-body-v7.md |
| PRD v2.1 | docs/prd/product-prd-v2.1.md |
| 夜班交接 | NIGHT-SHIFT.md（+ 同名单文件 NIGHT-SHIFT.html） |
表内路径均已在 Aholo 仓
main上存在（选题正文 v7 / PRD v2.1 / 夜班交接 于 2026-11-07 合入）。 若某条路径在别的仓里不存在，说明该产物还没落地——不要把未合入的产物写进本表， skill 指向不存在的文件比少列一条更糟。
参考
references/evidence-map.md—— 八个手法各自对应哪份可查证据、当时抓到了什么， 以及本项目真实踩过的反面清单。