Solo dev 做设计，大多数时候 N=1——第一直觉就是唯一方案，因为做第二个版本要花一天。Claude Design 把这事拆了：一下午六个完全不同的视觉语言摆在面前。留下了什么、丢了什么、方向锁死之后 big-task 的 ui profile 接手怎么走——这篇讲这些。

For solo dev and small teams, design exploration is usually N=1 — you go with your first instinct because producing a second variant takes a day. Claude Design collapses that: six distinct aesthetic directions in an afternoon. What I kept from the pipeline, what I dropped, and how `big-task`'s UI profile takes over once a direction is locked.

先是裸跑 Claude Code。再是 GSD 多 agent 仪式。再是 superpowers 的 skill 库。最后在上面包了一个自己的 orchestrator。每一版崩盘都来自一个具体 session。最后我才想明白：solo dev 的 harness 跟团队的不是一个物种，而且真正的答案不是选一个默认引擎——是按工作形状路由。

Vanilla Claude Code. Then GSD's multi-agent ceremony. Then superpowers' skill system. Then a custom orchestrator on top. Each rewrite came from a specific session that broke. What I learned: solo dev harnesses and team harnesses are different species, and the right answer isn't a default engine — it's routing by work shape.

同一条流水线——Claude Design 出方向、HANDOFF.md 锁死、`big-task` 落地——但每个产品都把它掰成不一样的形状。ÉLAN 是空地，需要宽探索。识川 app 已经上线，要按类目一个个迁移。盘盘猫是 monorepo，v2 跑三个并行品牌表达而不是一个方向。变的是什么，不变的是什么。

Same pipeline — Claude Design explores, HANDOFF.md locks, `big-task` ships — but it bends around each product. ÉLAN is greenfield and needs wide exploration before converging. Shichuan has a live app and needs incremental category-by-category migration. Panpanmao is a monorepo with a v2 redesign that runs three parallel brand expressions instead of one. What changes and what doesn't.

看完 Trae 的 MTC 模式，我在 Claude Code 里做了个 /mtc skill。6 个阶段，不许跳步，先想清楚再让 AI 写代码。做游戏的时候效果比我预期好。

After seeing Trae's MTC mode in action, I built a /mtc skill for Claude Code. 6 phases, no skipping, think first, code second. Better results than expected on my game project.

两个账号都是企鹅，第二个还降级了。于是我用 Claude 逆向了它自己的宠物系统，0.2 秒出金。

Claude Code shipped a virtual pet Easter egg. Two accounts, two penguins — the second one downgraded from Rare to Common. So I used Claude to brute-force a Shiny Legendary Dragon in 0.2 seconds.

从发现 pretext 到在两个网站上线 7 个交互特效——爆炸物理、弹跳子弹、还有一只叫 Clawd 的像素螃蟹。一个 session 搞定。

From discovering pretext to shipping 7 interactive effects across two sites in one session — explosion physics, bouncing bullets, and an animated crab named Clawd.

有读者说我们的中文文章'用语很生硬'。我一看——确实，全是翻译腔。英文思维，中文外壳。于是我花了一周研究公众号爆款怎么写的，搞了 435 行写作指南，把整个中文写作管线推翻重建。这是那个过程的记录。

Our Chinese blog articles read like translated English — stiff, academic, lifeless. A reader noticed. We spent a week researching what makes Chinese 公众号 articles work, built a 435-line style guide, and rebuilt the entire writing pipeline. Here's what we learned about the gap between 'correct Chinese' and 'native Chinese.'

32GB 的 GCP 开发机——经过第三篇的升级和加固之后——又死了。一样的症状：SSH 超时，内核活着，用户态冻结。看门狗抓到了：五个 node 进程各占 2-2.7GB，合计约 13GB。我以为是 Claude Code，结果是 Cursor 远程服务器连续泄漏了 15 个小时。

The 32GB GCP devbox — upgraded and hardened after Part 3 — died again. Same symptom: SSH timeout, kernel alive, userspace frozen. The watchdog caught it: five node processes at 2-2.7GB each, totaling ~13GB. I assumed Claude Code. It was Cursor's remote server leaking memory for 15 hours straight.

一个 Claude Code session 里同时跑了三种协作模式：直接结对编程（用户反馈驱动三次生产部署）、后台 agent 并发更新文档、自治审查团队迭代三轮直到零问题——全部交叠进行。传统的 code-test-review-release 流水线被压缩成了并行流。

A single Claude Code session that combined direct pair programming (three production deploys from user feedback), a background docs agent running concurrently, and an autonomous review team iterating three rounds until clean — all overlapping. The traditional code-test-review-release pipeline collapsed into parallel streams.

GCP 开发机一天死了两次。第一次是 snap 包引发的无限崩溃循环，修完五项加固以为稳了。几小时后又死了——这次是内存管理的问题。Claude Code 两轮诊断、12 项加固、最后连机型都换了。一次关于 VM 运维纵深防御的完整记录。

My GCP devbox died twice in one day. First time: a snap package triggered an infinite crash loop. Applied five fixes, thought it was stable. Hours later it died again — unbounded memory was the real issue. Two rounds of diagnosis, 12 hardening measures, and a machine type swap. A complete field report on VM defense in depth.