DEV Community: 朱峰

opus 5.5 video guide: Triage DOM, Seek, and Voice Failures in a Complete Living Screencast

朱峰 — Sun, 04 Oct 2026 02:56:58 +0000

Disclosure: This article was prepared with AI assistance for the H3Max operations team. The LemoLab film is a third-party reference, and no local reproduction is claimed.

Open the H3Max entry for this debugging reference as a context reference, while keeping it separate from the local debugging workflow. The page does not establish that H3Max can run this repository, control a terminal, or reproduce the film.

The reference case is LemoLab’s Clawd Moves In, a 59.4-second unofficial fan film. Compare against the distributed film for the debugging baseline and the retained movie alongside the symptom comparisons. The production repository for classifying debug evidence attributes it to Claude Opus 5.5, but those model sessions have not been independently verified here. This is not an H3Max benchmark.

Original frame at 7.128 seconds from Clawd Moves In. Credit: LemoLab. Unofficial fan film.

For debugging, use one chain for every problem:

symptom → reproduction comparison → suspected layer → smallest fix → new evidence

Do not start with “change the animation.” Start by classifying what changed.

The visual specification for the debugging triage says the UI is rebuilt in HTML/CSS/SVG, the cursor represents the user, and Clawd represents software activity. Plan/diff/test figures are authored demo content, not benchmarks.

Hypothetical failure 1: a layout change moves Clawd off the edge

This is a hypothetical debugging example, not a reported observation.

Symptom: after a font or pane-layout change, Clawd appears slightly above or below the intended UI edge.

Reproduction comparison: compare the same landing before and after the layout change, including neighboring frames and camera framing.

Suspected layer: font metrics → DOM geometry → measured anchor → sprite contact.

Smallest fix: re-measure or correct the affected anchor logic. Do not start by adding an arbitrary sprite offset.

New evidence: fresh boundary frames showing the corrected contact, plus confirmation that readable text and captions are still clear.

Hypothetical failure 2: backward seeking produces another state

Again, this is a hypothetical case.

Symptom: timestamp T looks correct in normal playback but shows another theme, pane, camera, or Clawd state after seeking backward from a later time.

Reproduction comparison: compare T through fresh/direct/forward and backward paths.

Suspected layer: accumulated state, timer behavior, class mutation, or missing reset.

Smallest fix: make the affected scene state derive from absolute time rather than playback history.

New evidence: matching observable state at T across the different seek paths.

The scene chronology used for the seek comparison helps define what Prompt, Plan, Review, and Self-check should look like at a given part of the timeline.

Original frame at 28.512 seconds. It is reconstructed interface animation, not evidence of a live coding session.

Hypothetical failure 3: regenerated voice leaves fixed captions or foley behind

This is also hypothetical, not an observed defect in the source film.

Symptom: narration changes, but a landing, caption hold, camera cue, or foley event still behaves as if the old timing were active.

Reproduction comparison: compare old and regenerated word timings, then inspect every relevant W(id, word) dependency.

Suspected layer: compare the voice/word timings/W(id, word) chain with captions and foley fixed to absolute time. A fixed event may stay behind while a word-linked cue moves.

Smallest fix: update only the downstream cue that is genuinely stale. Do not compensate for a timing defect by changing unrelated geometry.

New evidence: reviewed word timings, fresh boundary frames, caption duration check, and listening confirmation around important word onsets.

A transcript match is not enough if foley masks the speech or the caption disappears before it can be read.

Reproduction and evidence appendix

Before running commands, confirm Git, Node 20+, FFmpeg/ffprobe, and Python 3.11–3.13 or uv. Use a fresh clone or reviewed copy, preserve the lockfile and actual local source, and do not overwrite an existing project.

git clone https://github.com/lemomo-ai/lemo-opuscar.git clawd-case
cd clawd-case
export LEMO_OPUSCAR_HOME="$PWD"
sh plugin/skills/lemo-opuscar/scripts/setup.sh deps voice
for BANK in salamander freepats karoryfer vcsl vsco2ce; do
  sh tools/fetch.sh instruments "$BANK"
done
mkdir -p evidence
D=styles/living-screencast/demo
git rev-parse HEAD > evidence/clawd-commit.txt
npm ls --depth=0 > evidence/clawd-dependencies.txt

Preserve all five banks: salamander, freepats, karoryfer, vcsl, and vsco2ce.

Verify the current source before relying on 59.4 seconds at 30 fps. If unchanged, the expected picture count is 1,782 frames.

This prompt is newly written for this tutorial and is not recovered from the author’s original prompt or session:

Reproduce and analyze Clawd Moves In from the living-screencast demo source.
Inspect the current commit, locks, STYLE.md, DEMO.md, CREDITS, core APIs,
and demo/build.sh. Read the author MP4 and actual local files first.

Keep it an attributed unofficial fan-film reproduction. Do not claim the
reconstructed UI is a real recording or that its tests ran on H3Max. Preserve
Clawd's terminal-to-app journey, the existing chapters, and coherent demo data.
Report discrepancies with current product documentation without inventing new
features. No replacement stock footage or external image/video generation.

Inspect film.js, ui.js, clawd.js, main.js, voice files, word timings, and sound.py.
Explain the dependency plan and source duration/fps before building. Use the
source's 59.4 seconds and 30 fps only after checking them.

Keep crisp pixel-grid acting, a smoothly moving cursor, and a continuous camera.
Measure DOM anchors so Clawd lands on real element edges. Reserve text-free
space for the mascot and captions. Derive all scene state from absolute time;
reverse and arbitrary seeks must reproduce the same state in this environment.

If speech is regenerated, review every line and its word times before relying
on W(id, word) cues. Preserve original credits and fan-film disclosure. Use the
actual build/export interfaces. Save model/provider/effort logs, prompts,
modifications, frame checks, and the full output. Do not publish or report
an untested reconstruction as successful.

For intentional narration regeneration, use the narration build path for reproducing cue changes:

sh styles/living-screencast/demo/build.sh --vo

--vo regenerates narration. Review the generated audio and word timings before accepting them. Without it, usable existing voice assets are required. Current source uses 30 fps and six capture workers; do not invent another worker CLI flag.

Generate comparison stills:

node core/render/still.mjs "$D" 0 8.9 23 32 40.9 56 \
  --out evidence/clawd-stills

For each symptom, add adjacent frames around the actual boundary being investigated. A still alone cannot reveal teleporting or audio masking.

Finally validate the artifact:

ffprobe -v error -count_frames -show_streams -show_format -of json \
  styles/living-screencast/living-screencast.mp4
ffmpeg -v error -i styles/living-screencast/living-screencast.mp4 -f null -

Original frame at 48.114 seconds from the published LemoLab film. Animated interface and live operation remain separate.

Record actual duration, frame count, narration, subtitles, and the unofficial-fan-film disclosure. Do not claim byte identity with the web release unless supported by actual evidence.

Close the debug handoff with the asset inventory to retain with the debug evidence. MIT covers the repository code, not automatically Anthropic’s character/interface identity, OFL fonts, or third-party instrument samples.

The debugging discipline is therefore: reproduce the symptom, classify its layer, change the smallest responsible dependency, then create new evidence for that specific fix.

opus 5.5 video guide: Debug Destinations, Cues, and Narration in Tidy’s Dark Tech Launch Film

朱峰 — Sat, 03 Oct 2026 05:52:11 +0000

Start here: prepare a Tidy debugging brief through H3Max.

Use the author artifact for tracing Tidy’s sorting behavior, or the matching Feishu archive for inspecting the reference. Tidy is fictional: this is a code-animated launch film, not desktop footage, SaaS verification, or evidence of H3Max performance.

The upstream project’s account of its author and model credits Claude Opus 5.5. Those sessions have not been independently verified. These commands are reader instructions, not our run log; the entry page does not establish local-terminal access.

LemoLab author-film frame at approximately 5.04 seconds, also the cover.

1. Diagnose the destination before changing the easing

Preserve the reference unchanged. Watch the story, then inspect cursor movement, reading holds, and sound. Compare the intended layout and dark-stage hierarchy with the documented relationship between elements and sorting cues.

The generator contains 264 mixed-category elements, not 264 application windows. Fictional product figures are not measured benchmarks.

Separate wrong destinations, mistimed cues, and obscured narration. Record the timestamp and source before editing. These are diagnostic categories, not reported failures.

2. Preserve an identifiable environment

Prepare Git, Node 20+, FFmpeg/ffprobe, and Python 3.11–3.13 or uv. Use a new directory, without overwriting existing work:

git clone https://github.com/lemomo-ai/lemo-opuscar.git tidy-case
cd tidy-case
export LEMO_OPUSCAR_HOME="$PWD"
sh plugin/skills/lemo-opuscar/scripts/setup.sh deps voice
sh tools/fetch.sh instruments vcsl
mkdir -p evidence
D=styles/dark-keynote/demo
git rev-parse HEAD > evidence/tidy-commit.txt
npm ls --depth=0 > evidence/tidy-dependencies.txt

Keep locks/Python versions; check fonts, source, Kokoro/transcription and VCSL samples. Separate reference and output. Setup is not acceptance.

3. Give the agent a testable reproduction brief

New prompt—not the author’s original instructions:

Reproduce and debug LemoLab's Room to Think from existing dark-keynote source.
Read commit, locks, STYLE.md, DEMO.md, demo/CREDITS, core/README.md, build.sh,
reference and assets. Report missing dependencies; otherwise follow the
documented build without extra approval gates.

Preserve fictional Tidy, dark staging, original mixed-category elements,
cursor-led sorting, shared sound cues and credits. The 264 items are not
264 windows. No real screenshots, fabricated benchmarks, desktop-success
claims or external media-generation APIs.

Inspect timeline.js, world.js, film.js, engine, voice lines, score and mix.
Verify 42 seconds/24 fps from source; record release differences without
silent retiming. Use absolute render(t), fixed seeds, stable identities
and destinations, and shared note/event tables. No wall-clock state.

Test forward, reverse and arbitrary seeks. Save repeated-time comparisons
separately so a later capture cannot overwrite the earlier evidence.
Check destinations, cue alignment, click, flights, landing, captions,
reading holds, narration, intentional silence and complete ending.
Save actual model/provider/effort/session records, prompts, dependencies,
diffs and genuine checks. Do not infer success from the author film,
publish, or identify the reproduction as an H3Max original.

Original-release frame at approximately 20.16 seconds; not a local debugging capture.

4. Build, isolate, and repeat the same check

Run the checked-in implementation of Tidy’s full build:

sh styles/dark-keynote/demo/build.sh
node core/render/still.mjs "$D" 0 14.9 16.45 26 41.9 \
  --out evidence/tidy-stills

The script builds narration, score, events, checks, mix, subtitles, and a 24 fps/two-worker render, then muxes. Still arguments are seconds; inspect press/landing neighbors. Do not mix renderer flags.

Revisit a time after seeking elsewhere. Changed destinations suggest playback-history dependence; inspect shared state, not camera tricks. Restore missing fonts before adjusting coordinates.

Read the final ASR spot-check and listen: its failure need not stop the script. Resolve Chromium or missing voice/sample dependencies explicitly; never silently remove audio.

Repair only the observed destination, cue, caption or narration defect.
Preserve the fictional case and source timing. Show the responsible data
and code diff, repeat the original seek/frame/audio checks, and replay the
whole action. Do not conceal jumps with cuts or report untested fixes as passed.

5. Validate the complete artifact

OUT=styles/dark-keynote/dark-keynote.mp4
ffprobe -v error -count_frames -show_streams -show_format -of json "$OUT"
ffmpeg -v error -i "$OUT" -f null -

Unchanged 42-second/24 fps settings imply 1,008 picture frames. Check dimensions, rate, audio, and ending; watch and listen throughout. Decoding does not certify cue alignment, and web/local encodes need not be byte-identical.

LemoLab reference frame at approximately 34.02 seconds.

Archive source, inputs, versions, prompts, session records, edits, checks, and MP4. Retain the credited origins of Tidy’s lettering, samples, and voices: MIT code, OFL fonts, CC0-credited VCSL samples, and separate voice licenses.

GPT IMAGE 2 in practice：Generate Reviewable App and Web Mockups from Explicit UI Prompts

朱峰 — Fri, 02 Oct 2026 17:16:25 +0000

Codex teaching montage, not a H3Max execution result. Its phone uses April 23 and one-of-three completion; the main fixture uses September 29 and zero completion. Web copy is illustrative, not a literal prompt result. “Free” in the fictional Today artwork is not a H3Max access claim.

A generated UI image should be treated as a candidate against a specification. Its visual plausibility does not make its state correct, and its import into a design application does not create an implementation.

This exercise defines fictional Today across mobile, SaaS dashboard, and landing-page surfaces. Each prompt describes one complete static image. Keep the brief, candidate, revision, and accepted reference distinguishable.

Define an invariant before choosing a style

The mobile fixture contains exactly three incomplete tasks:

Read 10 pages — Personal · 20 min
Walk for 20 minutes — Health · 20 min
Plan tomorrow — Planning · 10 min

Required relationships: three empty circular checkboxes; 0 of 3 complete; 0%; an empty pale ring; fixed date Tuesday, 29 September; and Tue 29 selected.

The primary action is Add task. Mobile navigation is Today, Projects, Calendar, Profile, with Today active. The active navigation item is not a task completion.

The example behind this UI specification provides the worked context. These values are fictional display inputs, not analytics.

Codex static teaching plate, not H3Max output. Alternative states and web wording are included. Measurements are illustrative, not values extracted from a running layout.

Generate the mobile candidate

Produce a raster candidate from an explicit screen contract with Text to Image, GPT Image 2, 9:16, and 1K.

The October 2, 2026 interface check found 9:16 and 16:9, 1K/2K/4K, and JPEG as the only visible output format. Review credits before submitting. Do not encode assumed timing, success rates, fixed costs, or free access into the workflow.

Create one complete static mobile UI concept for the fictional Today app.
Use a flat 9:16 portrait canvas. No device frame or surrounding scene.
Cream background, charcoal text, white task cards, deep-teal accents,
subtle borders and shadows, readable typography, generous safe margins.

Header:
Today
Tuesday, 29 September
A small avatar circle containing AL.

Progress card:
0 of 3 complete
0%
A little focus goes a long way.
An empty pale progress ring with no completed green segment.

Seven-day strip:
Mon 28, Tue 29, Wed 30, Thu 1, Fri 2, Sat 3, Sun 4.
Highlight Tue 29.

Exactly three task cards, all with EMPTY circular checkboxes:
Read 10 pages — Personal · 20 min — book icon
Walk for 20 minutes — Health · 20 min — walking icon
Plan tomorrow — Planning · 10 min — calendar icon
Checkbox left; title and metadata middle; category icon right.

One prominent deep-teal Add task button beneath the cards.
Bottom navigation: Today, Projects, Calendar, Profile. Select Today.
Align repeated components and preserve every word.
Keep all content visible. No extra tasks, checked states, navigation,
or claims of working interaction.

Codex-generated teaching reference, not an executed H3Max test. It represents September 29 and zero-of-three completion. Controls are pixels; the WebP file does not establish another output format.

The hierarchy is header, progress, dates, tasks, creation action, navigation. Review the repeated checkbox/text/icon positions and the distinction between primary action and section selection.

Create a desktop-specific contract

Use 16:9, preserving vocabulary and palette but replacing the information architecture.

Create one static 16:9 desktop SaaS dashboard for fictional Today.
Use cream surfaces, charcoal text, white panels, and deep-teal accents.
Sidebar: Overview, Projects, Calendar, Files. Select Overview.
Heading: Today. Greeting: Hello, AL.
Label the workspace Example data.
Summary cards: Tasks 3 / Complete 0 / Remaining 3.

Task table columns: Task, Project, Status, Due.
Exactly these rows:
Read 10 pages | Personal | Incomplete | Tue 29
Walk for 20 minutes | Health | Incomplete | Tue 29
Plan tomorrow | Planning | Incomplete | Tue 29

Secondary column:
A chart titled Completed tasks and labeled Example data.
Mon 28=0, Tue 29=0, Wed 30=0, Thu 1=0,
Fri 2=0, Sat 3=0, Sun 4=0. Do not invent nonzero activity.
A compact calendar for those seven dates; highlight Tue 29.

Place greeting and summaries above the main workspace.
Keep table headings, statuses, and chart labels readable.
No extra records, unsupplied metrics, or mobile device frame.

All-zero analytics are deliberately supplied fixture values, not real history or forecasts. Check summary totals and labels against the rows.

Define the landing surface separately

Create one static 16:9 desktop landing page for the fictional Today app.
Use warm ivory surfaces, charcoal text, deep-teal accents,
and restrained readable typography.

Headline: Make room for focused work
Primary CTA: Start planning
Include a product preview and exactly three benefit cards:
Stay organized
Focus on what matters
Make real progress

The preview shows Today's three incomplete tasks:
Read 10 pages, Walk for 20 minutes, Plan tomorrow.
Use empty checkboxes, 0 of 3 complete, and 0%.
Keep headline and CTA readable at ordinary browser display size.
Separate the hero, product preview, and benefit cards clearly.
Do not invent customer logos, testimonials, prices, performance statistics,
or working links. No device frame.

Generate individual surfaces for review. A combined presentation allocates fewer pixels to each interface and is not a set of independently full-resolution screen exports.

Reject semantic failures before polishing geometry

Review strings, counts, state relationships, and visual placement separately. Zero completion must agree with all three empty boxes and the ring. Confirm the date, four navigation items, and single Add task action.

Then inspect spacing, clipping, safe margins, contrast, and readability at the intended size. A higher resolution does not repair a wrong state.

For the second label, select Image to Image or test a correction against the stored candidate with the actual image attached.

Correct only the second task label to Walk for 20 minutes.
Preserve Health · 20 min, the other copy, three empty checkboxes,
0 of 3 complete, 0%, the empty progress ring, Tuesday 29 selection,
layout, colors, four navigation items, and the Add task button.
Do not introduce a completed task or a new card.

The requested scope is not a region lock. Recheck the whole candidate and reject regressions. Use real editable text for persistent copy errors and manual layout reconstruction when counts or geometry remain unstable.

Keep the accepted JPEG, specification, prompts, and open issues. This is a manual review record, not an automatically executed test suite. Native components, licensed fonts, responsive rules, keyboard navigation, contrast, and actual interactions still need to be built and verified. A static concept is a reference for implementation—not implementation itself.

GPT IMAGE 2 in practice：Prepare a Transparent PNG through Extraction, Validation, and Delivery

朱峰 — Wed, 30 Sep 2026 21:02:04 +0000

Opaque Codex-generated teaching cover. It is not a H3Max output or a transparent validation asset.

A transparent-image workflow benefits from explicit acceptance conditions. The input is a source picture. The output is a file whose intended background is transparent and whose foreground still matches that source.

Neither the filename nor the most recent processing operation establishes acceptance.

This guide uses a watering can to describe the full workflow: check generation support, derive a cutout when necessary, inspect the exported pixels, repair defects, and validate the delivery derivative. It is a manual procedure, not a claim of automated testing.

Define the output conditions

The background outside the can and through its handle must reveal an underlying layer. The body, spout, handle rim, and leaves must remain intact. Edges must work on contrasting backgrounds and at the intended display size.

MDN’s reference for an image file’s transparency capability distinguishes format support from content: PNG has transparency-capable modes, JPEG does not support alpha, and PNG can still be fully opaque.

Alpha stores opacity values. A file may have that channel while every background pixel stays opaque. Real transparent pixels also do not prove the foreground is complete.

Direct transparent generation therefore requires actual workflow support and an alpha-capable output format. A prompt containing “transparent,” a PNG extension, or a checkerboard preview does not prove success.

If the chosen interface offers only JPEG or lacks confirmed transparency controls, preserve the image and use background removal as postprocessing.

Keep an immutable reference for visual decisions

Use the clearest original, not a screenshot of a small preview. Retain an untouched copy and keep the entire subject inside the frame.

Opaque source illustration generated by Codex for teaching. It is not a H3Max extraction result.

The outer gray and handle opening are background. Shadows on the can and visible interior surfaces may be foreground. Do not classify them purely by brightness.

The original is the reference for expected shape. A shortened spout in a candidate must not redefine the source geometry.

Derive a foreground candidate through local extraction in H3Max: select the source, run local background removal, and download the PNG. Store it separately from the original.

This operation requires no generation prompt and assumes no unverified masks or restore brushes.

Validate the saved candidate

GIMP’s breakdown of the transparent-export workflow separates alpha preparation, content deletion, and export. Use the same distinction when reviewing the result.

Open the actual downloaded PNG above a white layer in an editor. Change only the lower layer to deep navy.

Both the outside region and the handle opening should reveal the new background. The solid can should remain orange.

Codex-generated instructional comparison, not a H3Max result or an alpha-test file. Its opaque examples explain how to inspect your own PNG.

A fixed white or gray patch is a failure to investigate. A checkerboard that persists while the lower background changes may be stored picture content. A white preview alone cannot distinguish viewer background from opaque white pixels.

Keep test backgrounds separate from the exported asset.

Then compare foreground with the source at 100% zoom. Check the spout to its tip, handle inner rim, leaf tips and gaps, and the body’s perimeter and base. Inspect suspicious areas more closely, then return to the destination size.

Do not replace natural softness with an unnecessarily hard boundary. The target is faithful extraction, not maximum edge sharpness.

Classify failures before repairing

Failure	Recovery source and action
Entire background is opaque	Confirm the opened file is the actual download. Return to the original and remove the background through a transparent-export workflow if necessary. Renaming is not repair.
Handle opening retains background	Clear only the residue externally, protecting the rim. Do not substitute white paint.
Foreground detail is missing	Recover it from the original and refine the selection. Do not invent the lost contour from the candidate.
Pale fringe appears on navy	Compare with source highlights, identify contamination, and treat the affected edge selectively.

Manual corrections require an external editor with selection and transparency controls. They are not unverified H3Max interface instructions.

Adobe’s edge-pixel treatment for remaining fringe documents a specified-width operation. Check that it preserves valid foreground color, delicate parts, and legitimate softness.

Save repairs to a new PNG. Reopen and rerun the background and foreground checks before accepting the version.

Validate downstream transformations independently

If the existing dimensions and framing suit the destination, avoid unnecessary changes.

When extra canvas impedes positioning, derive a compact canvas after foreground validation. Keep the full spout, handle, and highest leaves, with room for their soft edges.

For a specified output size, derive destination dimensions from the accepted asset, retaining its proportions.

Neither transformation should inherit approval automatically. A transparent input does not guarantee a transparent output. Reopen the derivative, test it over white and navy, and inspect it at final size.

If a solid background appears, restart from the last verified transparent file. Do not repeatedly process a flattened derivative as though it still met the original conditions.

Record the file that actually passed

Keep the original, accepted cutout, and delivery copy distinguishable. A brief manual record can note the outgoing filename, dimensions, last transformation, and completed checks. Record only what was actually inspected.

The final file must have transparent surroundings and handle opening, complete foreground, appropriate edges and dimensions, and no embedded review background.

This is a file acceptance process, not a format-name check. The useful deliverable is the export that still meets the conditions after the last operation.

我造了个子站来纪念刘欢：做这个子站，是因为有些作品早已参与了我的人生

朱峰 — Sun, 27 Sep 2026 09:19:03 +0000

一、先做一件真正惦记的事

我造了个子站来纪念刘欢。

这次动手，不是因为先列出了一张漂亮的功能清单，而是因为有些歌在我的生活里待得太久了。它们让我想到的，不只是演唱者和作品名称，还有我爸、我妈、姥姥家附近的小胡同，以及一些曾经在北京相聚、后来又四散而去的人。

网站的上线顺序，甚至有点反过来了。为这次建站先行上线的 wesing.ai 是工具主站，却是为了这个子站才仓促上线的。主站的音乐功能尚未添加，现在不能在上面生成音乐。我想做的工具还没准备周全，自己一直惦记的这件事倒先有了着落。

在我亲手搭起的刘欢纪念子站，我收录了现场演出与MV、综艺高光、纪录片和访谈。登录后，可以留下60秒的歌，再留一小段话，共同纪念刘欢和他的作品。

我不希望它只有内容，没有听内容的人。把一首歌放在页面上，和知道这首歌为什么被某个人记住，是两件不同的事。前者让我能再听一次，后者让我知道，它曾经怎样经过一个人的生活。

下面这些，就是我自己的那一部分。

二、真正催我动手的，是这些具体得不能再具体的记忆

我爸年轻时候做电视剧制片主任。有部剧叫《第三军团》，讲九十年代高中生的故事，我记得豆瓣8分多，男二是年轻时期的王砚辉。刘欢献唱的主题曲叫《他们我们》。

我们都是一步一步跋涉过来/他们也要一步一步奋斗下去/当年我们也像他们现在一样/以后他们是否也像现在我们

那时我上小学，对这首歌的感受却不完全跟着剧情走。故事结束，片尾曲响起来，我总觉得里面有一种另外的苍凉意境。小学生讲不清它为什么苍凉，也不懂它和剧情之间那点距离，只是记住了这种不同。

再往后，音乐在我生活里留下的东西，就十分好笑了。

1998年下岗潮，北京当时社会上刮起一股彩票风。我爸带我上街买彩票，常见的场地是一大片空旷的黄土地，用铁皮围挡圈住，里面摆着长条桌子，桌上全是彩票。

在我当年的印象里，北京所有这样的彩票站，大喇叭都只循环放刘欢的《从头再来》。

心若在/梦就在/天地之间还有真爱/看成败/人生豪迈/只不过是重头再来

我爸听上头了，一直买，一直重头再来。我妈都急了。结果这场不断重来的购买，最后还真的换来了一套家庭组合音响。

我印象挺深，我爸刮出来的是个黑桃，也不是草花K。

在刘欢的歌声里，我俩挥舞着彩票冲向领奖台。别人听见这首歌会想到什么，我不知道；我听见的时候，总绕不开我爸那股上头的劲儿、我妈的着急和我们中奖后的兴奋。作品就这样和一件家庭小事绑在一起了。

播《水浒传》的时候，我五年级，经常住在姥姥家。记忆里的阜成门，那时候还没被国企集团们拥挤占据。春节，我和表弟表妹提着灯笼跑过小胡同，烛光暖融融，影子拖得长长的，一路忽闪。

表弟每到一集结束，就跟着刘欢唱：

大河向东流哇/天上的星星参北斗哇

他当时五音不全，不知道现在有没有好些，我们已经多年没有相见了。至于那时候留在记忆里的刘欢，上次又在我眼前鲜活起来，也还是因为《喜人奇妙夜》里的《越狱的夏天》。那个故事真的好，唢呐一响，我掉眼泪了。

同一段旋律里，既有刘欢的声音，也有表弟的声音。专业和跑调，在我的回忆里并不互相排斥，缺了哪一个都不是当时的样子。

初中回宁波老家过新年，是另一种电视记忆。按我在老家过年的经验，浙江人睡觉极早，春晚从没有一年能看完，我却总执着于多看几集《西游记后传》。

剧情现在不记得了，出乎意料地好看这件事记得，打斗粗糙得离谱也记得。对，我心目中伟大作品里粗糙到离谱的两件事，就是《西游记后传》的武打和《天道》的背景音乐。

《西游记后传》的音乐偏偏很好。刘欢唱：

我欲成仙/快乐齐天/变化出神话在风中流传/真心走过/每个瞬间/才能对孩子款款笑谈/我欲成仙/快乐齐天/让自己对得起美丽寓言/天降我在/天地之间/总得有故事让后人看

这些是我默写的，已经过去26年，哪里记错了很正常。一部剧留在脑子里的东西，有时就是这么不均匀：情节忘了，音乐还在，连吐槽武打的心情也一起留下来了。

还有两部作品，我连观看都没完成：《宝莲灯》从没看过，《甄嬛传》也没看完。但《天地在我心》和《凤凰于飞》，在我这里不是简单的好听，而是定义了什么叫高级的好听。

服气归服气，槽也得吐。他是懒吗？主歌近关系转调之后，直接就是副歌了。哈哈，怎么还能这样，而且还真的可行？这个问题我一直想吐槽。

可能人家那个创造太结实了吧，懒得有恃无恐。你在这边琢磨他是不是省了一步，人家那首歌已经好好地立在那里了。

到了《中国好声音》《中国好歌曲》那阵，我已经在国企上班，正好出一个很闲的闲差。那些新面孔带着无比高妙的原创作品扑面而来，我又恰好有充足时间泡在里面，精神世界无比充实幸福。

那是2010年代。因为音综被选中的歌手和唱作人，从五湖四海汇聚到北京：在百子湾，在北京像素，在欧尚羽毛球馆，在刘欢的战队，还有常石磊的“歌不动听请退群”微信群。

我高中、大学在金帆团唱了多年的合唱和阿卡贝拉。那个群里很多唱作人都是朋友，我却一次没敢提过申请入群。

音乐就是这样。不懂时觉得就那样儿，你上你也行；等你懂了，也努力过，听三秒钟，你就知道这人、这作品，自己是不是得跪着听。认识朋友和面对作品，是两回事。

2018年，我去金韩一的追悼会。北京的歌手圈子已经四散而去，大家为了曾经的回忆，短暂地再次聚在一起，看看那些熟悉的面孔如今是否还好。很多人喝了通宵，吐在酒馆里，睡在马路上。

杯子碰在一起，都是梦想破碎的声音。

写到这里，就没必要替回忆加一层好看的滤镜了。精神世界充实幸福是真的，后来的四散和苦涩也是真的。我不愿意只保留其中比较适合展示的那一半。

今天我的价值观里，竞争获得的零和胜利不值一提，人生的成就全部来自创造。以这个角度看刘欢，他不只唱过，不只写过，还扶持过不知多少有才华的后辈，造过属于几代人的时事。

有些创造会进入别人的家庭、童年和生活，甚至影响一个人后来怎样理解才华、怎样看待自己。在我心里，这样的创造，此生足矣。

三、接下来做什么，想先把问题问清楚

这些日子，解释了我为什么愿意先做这个子站。它还不是一个什么都有的产品，也不必为了显得完整，把还没做的事情写成已经实现。

现在，影像内容和登录后留下60秒的歌、一小段话，是已有的部分。接下来是否需要作品时间线，是否要把同一首歌的不同演出版本集中整理，是否应该让个人故事和歌曲之间有更清楚的联系，我想请大家一起讨论。

这些都只是建议中的方向。主站音乐功能也尚未添加，不会因为写进一篇文章，就算作已经上线。

欢迎留言告诉我，你会怎样使用这个地方。你最想找什么，在哪一步容易绕路，什么模块真正值得做？比起一句“再丰富一点”，我更想听一个具体场景，哪怕它只涉及一件很小的事。

我造了个子站来纪念刘欢，也是想回应自己曾经从作品里得到的东西。先留住这些歌和这些日子，再和愿意来的人一起，把它做得更好。

Awesome MiniMax H3 Max Prompts — A video prompt as an acceptance checklist

朱峰 — Wed, 16 Sep 2026 09:33:33 +0000

For a parkour brief, I would specify the takeoff, obstacle, landing and camera path separately. The H3 Max collection uses visible decisions like these to make failures easier to describe and revisions easier to isolate.

A useful technical exercise is to turn a brief into a small acceptance checklist before invoking a model. For a parkour shot, separate takeoff, obstacle clearance, landing and camera position. Then log a failure against one item instead of calling the output generally bad. Store the checklist with the inputs and output. It makes the next prompt edit reviewable, even though nondeterministic generation means the same inputs may not produce identical frames.

What we actually collected

the open-source H3 Max collection contains 30 cases from 15 public accounts across seven creative categories, with English and Chinese documentation. The categories cover camera movement and action, character performance, animation, short narratives, documentary-style atmosphere, reference continuity, and production workflows. The examples include rooftop combat in the rain, drifting astronauts, clay-style comedy, character showcases, and Blender-based camera previsualization. These are different production questions, so a category should help a reader choose a task rather than imply a ranking of models or creators.

Keeping the collection maintainable

The repository stores cases as structured JSON and generates the individual pages and both READMEs from those records. Automated checks cover duplicate cases, required metadata, local references, and stale generated files. That helps preserve attribution when the presentation changes, but a successful check does not validate the creative output. The large-preview layout lets people scan the shots before opening long instructions. There is also the browser-based prompt gallery, a separate website selection; its contents are not identical to the GitHub collection.

Following the evidence

We searched public X posts, inspected creator threads and replies, and looked for disclosed prompts, input materials, and workflow notes. We also reviewed sampled video frames to describe the visible action and composition. Each entry keeps its author and original source. Finding a compelling clip was only the beginning: we tried to separate what the creator actually disclosed from what an editor could reasonably infer. Unknown inputs stay unknown. A missing seed, an undisclosed reference image, or an unclear editing step should not quietly become an invented setting.

Three kinds of entry

An adapted prompt draws on instructions the creator made public, with a link to the original wording. A reconstructed prompt proposes an approach based on the visible result; it is not the recovered original. A workflow entry describes a process involving references, previsualization, editing, or related endpoints that cannot be reduced to one text instruction. This classification matters because the same final shot can result from different inputs and repeated attempts. Copying a reconstruction does not establish that the source clip was generated with that text.

Describe something a camera can observe

For a parkour scene, a useful brief specifies the starting position, obstacle, takeoff, landing, and camera path. That gives a reviewer several separate checks. If the landing is wrong, change the action description before adding more style words. If the camera crosses the subject, revise its path while keeping the action stable. This is an editing method for making experiments understandable, not a measured claim that every detailed prompt performs better. A short clip also needs enough time for each event to register.

A small experiment to keep

Start with one case and prepare the inputs it calls for. Record the model or endpoint, duration, resolution, aspect ratio, prompt, and seed when available. Decide what success means before generating: perhaps the subject stays recognizable, an object remains in the same hand, or the camera reaches a particular final position. Review the result, identify one important mismatch, and change one variable. Keep unsuccessful attempts with their settings. A history of revisions is more useful than a folder containing only the best-looking exports.

Match the workflow to the model

H3, H3 Max, and related endpoints must be distinguished. A case using several reference assets or an existing-video editing step should not be treated as proof that every H3 Max interface supports those inputs. The repository includes model-boundary notes for that reason. If you try a brief in the video creation workspace, compare the selected model and input mode with the entry first. Parameters in an editorial breakdown are suggested starting points unless the creator explicitly published them; they are not hidden facts recovered from the video.

Ownership and the limits of this release

The collection is maintained by the independent H3Max project I maintain. It is a commercial project, and the collection can be read and downloaded independently without a website account. The original repository contributions use MIT; linked creator videos, thumbnails, and source material retain their existing rights. The previews are the creators' outputs, not independent reproductions using our edited prompts. The launch collection is explicitly marked as not independently generation-tested, and sampled-frame inspection does not verify sound or every frame of a finished clip.

The contribution I would find most useful

The next improvement is a reproducibility record rather than a larger headline count. A useful contribution would pair a result with its inputs, model, settings, attempt count, revisions, and any editing performed afterward. Failed attempts deserve space too. They can show which constraints were difficult and which changes did not help. If you try one of these entries, a documented comparison or a correction to the source attribution would teach the next reader more than an unqualified claim that the prompt works.

Awesome GPT Image 2.5 Prompts — Turn visual expectations into acceptance checks

朱峰 — Tue, 15 Sep 2026 16:04:08 +0000

Awesome GPT Image 2.5 Prompts contains 30 visual studies and 20 editing recipes, with English and Chinese notes. Adaptations are not guarantees of reproducing the source pictures. I also maintain gptimage25.ai, the website behind this open-source collection.

Start with a reference in the visual case collection; when you have adjusted the brief, try it in the image creation tool. For a product image, “commercial quality” is difficult to debug. Label spelling, bottle shape and fingers covering the brand are concrete checks. I put this kind of review note next to the prompts in my new repository.