Star

记录时间：2026-06-15 10:16:21

问题

我通过了科目一考试。考试本身很简单，但考前我却异常焦虑，总觉得复习时间永远不够。这种感觉从高中就有了：我常常想一口气学很多东西，结果却什么都学不进去。我还发现，经常做错的题，无论怎么复习都还是容易错；有时候明明记住了，一到考场又出错。备考期间因为那种紧迫感，我几乎无法好好享受生活。我今年已经 35 岁，却还会经常回忆起高考的情形。我说不清原因——也许是小时候被父母逼着跟别人比较，也许是我天生胆小，永远没有勇气享受当下。我想从跨学科的角度理解这些问题，知道如何纠正，以及该读哪些书、做哪些实践。

先说一个判断：这不是几个毛病，而是一条因果链

你列出来的像是五六个独立的问题：考前焦虑、复习总觉得不够、错题反复错、记得却考错、活不在当下、总想起高考。但它们其实串在同一条链子上：

童年被植入的"表现 = 我是否有价值"的等式 → 每场考试都被升级成对自我价值的审判 → 审判带来过度焦虑 → 焦虑挤占了你考试时本该用来思考的脑力（于是"记得却考错"）→ 也让你无法活在当下（因为当下永远是"还没考好"的待审状态）。

而"错题反复错"是唯一一个纯技术问题——它和上面那条情绪链关系不大，是复习方法本身的漏洞。把它单独拎出来，反而是最容易、最快见效的突破口。

所以下面我分两块：先用四个学科把现象解释清楚，再给你分层的纠正方案。理解"为什么"本身就有疗愈作用——很多焦虑来自"我不知道我怎么了"。

跨学科诊断

1. 认知科学：为什么"错题反复错""记得却考错"

这两点几乎是学习科学里被研究得最透彻的现象，不是你笨，是方法和大脑的工作方式不匹配。

"记得却考错" = 流畅性错觉（fluency illusion）。 你复习时反复看题、看答案，会产生一种"我会了"的熟悉感。但心理学家 Robert Bjork 区分了两件事：存储强度（你脑子里有没有这个东西）和提取强度（你能不能在需要时把它调出来）。反复阅读只提升"熟悉感"，几乎不提升"提取能力"。考试考的恰恰是提取。于是你"觉得记住了"，一到考场要主动调取时却卡住——这不是记忆消失，是从没真正练过"调取"这个动作。

解药是"提取练习"（retrieval practice）/ 测试效应（testing effect）： 合上书，凭空把答案默写或说出来，再对照订正。每一次费力的回忆，都在给那条神经通路"加固"。看十遍，不如盖住默写两遍。

"错题反复错" = 错误的首次编码 + 干扰。 第一次记错时，错误答案会留下很顽固的痕迹；之后每次"复习"如果只是再看一眼正确答案，旧的错误痕迹并没有被覆盖，反而在易混淆的题目之间互相干扰（proactive interference）。所以你需要的不是"多看几遍正确答案"，而是：

• 主动写下**"我当初为什么会选错"**——把错误的逻辑揪出来，正面驳倒它；
• 做成卡片时，正面是问题，背面是**"正确答案 + 我的错误陷阱"**，而不是单纯抄答案；
• 用间隔重复（spaced repetition，见下文 Anki）让易错题在"快要忘记"的临界点反复出现——间隔效应（spacing effect）是记忆科学里最稳的结论之一。

"记得却考错"还有第二个原因，属于下一节：焦虑直接吃掉了你的工作记忆。

2. 心理学：为什么"复习总不够""考前焦虑""一下子想学很多却什么都学不了"

Yerkes-Dodson 定律： 焦虑和表现是一条倒 U 形曲线。一点点紧张能提升表现，但过度焦虑会断崖式损害表现——而且它专门损害"工作记忆"（你当场推理、调取、组织答案的那块临时内存）。芝加哥大学 Sian Beilock 的"压力下崩盘"（choking under pressure）研究证明：越是高焦虑的人，越容易在重要考试里把工作记忆"占满"，于是会的东西也做不出来。这就是"明明记得却考错"的第二层机制——焦虑本身就是干扰源。

"复习时间永远不够" 多半不是事实，而是焦虑制造的主观感受。 它背后是两个典型的认知扭曲：

• 完美主义 + 灾难化（catastrophizing）："没准备到 100% = 一定会出事"。于是无论复习多少，你都达不到那个不存在的"足够"。
• 全或无思维（all-or-nothing）：这正好解释了"想一下子学很多 → 结果什么都学不了"。当你给自己设的标准是"要么全学会，要么别开始"，大脑面对这个不可能完成的任务会直接决策瘫痪，用拖延来逃避。

"无法享受生活" = 经验性回避（experiential avoidance）。 你把"放松、享受"在潜意识里标记成了"危险/不负责任"，于是一备考就启动全面戒备。问题是，绷紧并不会让你学得更好（见上一条），它只是让你更累。

3. 发展心理学与家庭系统：为什么"35 岁还在重温高考"

这是整条链子的根，也是你自己已经隐约指向的地方——"小时候被父母逼着跟别人比较"。

条件性自我价值（contingent self-worth）。 心理学家 Jennifer Crocker 的研究指出：当一个人的自我价值"挂靠"在某个领域（比如学业成绩）上时，那个领域的每一次评价都会变成对"我这个人到底行不行"的全面裁决。你小时候被反复传递的信息是"考得好 → 你值得被爱/被认可；考不好 → 你不如别人"。于是几十年后，一场连你自己都觉得"很简单"的科目一，在你的神经系统里仍然被自动升级成生存级别的威胁。焦虑当然会爆表——身体以为你在为"我是否有价值"而战。

这也解释了"35 岁还反复想起高考"。 高考是那套"价值审判"机制最高强度的一次激活。当一段经历伴随强烈情绪、又从未被真正"消化"，它会以闪回、反刍的方式不断回来。这不是你矫情，是未完成的情绪在找出口。

它还是固定型思维（fixed mindset）的源头。 Carol Dweck 的研究区分了两种心态：固定型把每次表现当作"证明我聪不聪明"，成长型把它当作"学习与变强的机会"。被"和别人比较"养大的孩子，几乎必然内化成固定型——于是考试不是学习，是受审。

4. 哲学与存在：关于"活不在当下"和"我天生胆小"

"活不在当下" 在哲学里是个老问题：痛苦往往来自心智总在两个不存在的地方——懊悔的过去、担忧的未来。 你描述的"备考期间无法享受生活"，本质是注意力被未来的那场审判劫持了。斯多葛学派和正念传统给的答案惊人地一致：你能掌控的只有此刻的行动，把注意力交还给当下，焦虑会自动失去燃料。

关于"我天生胆小"——我想温和地挑战这个标签。 气质（temperament）确实有先天成分：Jerome Kagan 的研究发现，约 15-20% 的婴儿天生属于"高反应型"，长大后更敏感、更易紧张。所以你说的"天生"可能有一部分是真的。 但请注意两件事：

1. 气质不是命运。 同样是高反应型的孩子，成年后是否焦虑，高度取决于后天环境与所学的应对方式——它是高度可塑的。"胆小"是一个可以改写的习得反应，不是刻在骨头上的判决。
2. 敏感是有礼物的。 高反应型往往伴随更强的共情、更深的觉察、更高的责任心。你需要的不是"消灭敏感"，而是"给敏感装上调节阀"。

把"我天生胆小，永远没有勇气享受当下"这句话，换成"我天生敏感，而我正在学习如何与它共处"——这一个措辞的改变，本身就是治疗的开始（认知行为疗法里叫"去标签化"）。

如何纠正：三层手术

按"见效快慢"和"由表及里"排，建议你就按这个顺序来。

第一层（技术层，1 周见效）：让"错题反复错"停下来

• 停止反复阅读，改成主动回忆。 合上书默写/口述，再对答案。费力才有效。
• 错题做成"陷阱卡"。 正面=题目；背面=正确答案 + 我当初为什么错。复习的是"我的思维漏洞"，不是答案本身。
• 用 Anki 做间隔重复。 让易错题在临界遗忘点反复出现，这是对抗"反复错"最强的工具，没有之一。
• 交错练习（interleaving）。 不要把同类题扎堆刷，混着来——更接近考场的随机调取，提取能力更强。

第二层（情绪层，数周到数月）：把焦虑从敌人变成工具

• 考前 10 分钟"表达性书写"。 这是我最想推荐你的一招，有硬核证据：Ramirez & Beilock 2011 年发表在《Science》上的实验发现，高焦虑的学生在考前花 10 分钟写下自己的担忧，考试成绩显著提升。原理正是把占用工作记忆的焦虑"倒"到纸上，把脑力还给题目。下次考试前，找张纸把"我在怕什么"写满 10 分钟，然后进考场。
• 认知行为疗法（CBT）的思维记录表。 当"时间不够 / 我会搞砸"冒出来时，写下来，然后问：证据是什么？反证是什么？最坏会怎样、真发生了我能怎么办？把灾难化和全或无思维一条条拆掉。
• 生理层面先降唤醒。 焦虑是身体反应，可以用身体先按下去：4-7-8 呼吸或 box breathing（吸 4 秒、屏 4 秒、呼 4 秒、屏 4 秒），考前做几轮；规律运动是天然的抗焦虑药。
• 暴露与脱敏。 故意给自己安排一些"没完全准备好"的小测验、小挑战，体验"没准备到 100% 也不会天塌"。一次次小剂量地打破"不完美=灾难"的等式。

第三层（根部，以月与年计）：拆掉"考好 = 我有价值"的等式

这是真正的根，也是最慢但最值得的。

• 把自我价值从"表现"上解绑。 刻意练习"无条件的自我价值"：我的价值不取决于这次考多少分、是否比别人强。Kristin Neff 的自我关怀练习是具体抓手——在你想骂自己"怎么又错"的时候，改用对待好朋友的语气对自己说话。
• 改写童年那句脚本。 你被植入的是"和别人比较"，你可以有意识地替换成"和昨天的自己比较"（这正是成长型思维）。每天记一件"今天我比昨天进步/学到的一点点"。
• 认真考虑找一位咨询师。 "35 岁还反复重温高考"+ 价值感和原生家庭深度绑定，这类议题靠自助书能改善，但有一位 CBT 或 ACT 取向的心理咨询师陪着走，会快得多、稳得多。这不是软弱，是高效。

书单

挑你最有共鸣的 1-2 本开始，别一次买十本——那又会变成"想一口气学很多"的老剧本。

学习方法（解决"错题反复错"）

• 《认知天性》（Make It Stick）— Brown / Roediger / McDaniel：提取练习、间隔、交错的权威普及版。强烈建议第一本读这本。
• 《学习之道》（A Mind for Numbers）— Barbara Oakley：专注/发散模式、对抗拖延。

焦虑与完美主义（CBT）

• 《伯恩斯新情绪疗法》（Feeling Good）— David Burns：CBT 经典，专治完美主义、灾难化、全或无思维，附大量可做的练习。
• 《焦虑症与恐惧症手册》（The Anxiety and Phobia Workbook）— Edmund Bourne：工具书式，实操性强。

活在当下（正念 / ACT）

• 《幸福的陷阱》（The Happiness Trap）— Russ Harris：接纳承诺疗法（ACT）入门，专门对付"经验性回避"和"活不在当下"，非常对症。
• 《正念：此刻是一枝花》（Wherever You Go, There You Are）— Jon Kabat-Zinn：正念入门经典。

自我价值与原生家庭（根部）

• 《终身成长》（Mindset）— Carol Dweck：固定型 vs 成长型思维。
• 《自我关怀的力量》（Self-Compassion）— Kristin Neff：把价值感从表现上解绑。
• 《不成熟的父母》（Adult Children of Emotionally Immature Parents）— Lindsay Gibson：理解"被比较"的童年如何塑造了今天的你。

哲学（活在当下的底层支撑）

• 《沉思录》（Meditations）— 马可·奥勒留：斯多葛派关于"只掌控你能掌控的"。
• 《自控力 / 当下的力量》之类可选，但前面几本更对症。

实践清单

可以从打 ☐ 开始，不必全做：

• ☐ 今天起，复习改成"合上书主动回忆"，错题写"我为什么错"。
• ☐ 装 Anki，把易错题做成卡片，每天 10 分钟。
• ☐ 下次考试前，纸上做 10 分钟"担忧书写"再进场。
• ☐ 每天 10 分钟正念冥想（Headspace / Waking Up / 潮汐 App 任选）。
• ☐ 焦虑上来时，做 3 轮 4-7-8 呼吸。
• ☐ 每天睡前写一件"今天我比昨天进步的一点点"。
• ☐ 一周内开始读《认知天性》或《幸福的陷阱》其中一本。
• ☐ 一个月内，认真评估要不要找一位 CBT/ACT 咨询师。
• ☐ 把口头禅从"我天生胆小"改成"我天生敏感，正在学习与它共处"。

小结

• 你的几个问题不是孤立的，根在一句童年脚本："考好才有价值"。它把每场考试升级成对自我的审判，审判产生的焦虑又反过来吃掉你考试时的脑力，并让你活不在当下。
• "错题反复错"是纯方法问题，最容易先解决：用主动回忆 + 间隔重复 + "陷阱卡"替代反复阅读。
• 焦虑要被驯服而非消灭：考前书写、CBT 拆解、呼吸与运动，是有证据的工具。
• 真正的功课在根部：把自我价值从成绩上解绑，从"和别人比"换成"和昨天的自己比"，必要时请专业咨询师同行。
• 最后那句要送给你：你不是天生胆小，你是天生敏感——而敏感是可以驯服、甚至可以变成礼物的。 你今年 35 岁，这恰恰是一个人开始有能力重新养育自己的年纪。高考会慢慢退场的，前提是你愿意从今天起，一点一点把"我够不够好"这个问题，换成"我今天想学到什么、想体验什么"。

记录时间：2026-06-09 17:11:37

问题

使用 Claude Code 时，它有时会卡在某个环节迟迟没有反应——可能是一直在「处理问题」、卡在某个命令上、或者界面完全冻住。遇到这种情况应该如何处理？

处理方法

卡住的处理方式取决于它卡在哪一个环节，先判断属于哪一类。

1. 卡在某个工具调用上（最常见）

界面一直显示在跑某个命令，或停在 "Running…" 不动。

• 按 Esc——中断当前操作，回到输入框。这是最常用的方式，不会丢失会话上下文。
• 如果是某个 Bash 命令卡死（比如启动了一个不会退出的服务、或等待输入的交互式命令），Esc 中断后，把那个命令改成后台运行或加上超时限制再重试。

2. 完全无响应 / 界面冻住

• 连按两次 Ctrl+C 退出 Claude Code。
• 重新进入后运行 claude --continue（或简写 claude -c）恢复刚才的会话，上下文仍然保留。

3. 卡在「思考」很久不输出

通常是任务太大、或在反复检索信息。

• 按 Esc 打断。
• 把任务拆小一点再重新交给它，单步更容易完成。

4. 卡在权限确认

它在等待你批准某个工具调用，界面会停住等待 y/n 选择。

• 检查屏幕上是否有一个待确认的提示，做出选择即可继续。

小结

遇到卡住，第一反应是按 Esc 中断当前操作——这是最安全、不丢上下文的方式；只有在界面彻底冻住时才用 Ctrl+C 两次退出，再用 claude -c 恢复会话。日常预防上，把大任务拆小、给长跑命令加超时或放后台，可以显著减少卡死的概率。

记录时间：2026-06-09 16:54:55

问题

用 Seedream / 即梦这类图像生成模型做手帐风格的图片时，生成结果里的中文文字经常糊成「鬼画符」：标题还勉强、正文整段崩坏，连写在 prompt 里的水印（如「幸福笔记」）都被画歪。这是 prompt 写得不好，还是模型本身的局限？该怎么从根本上解决？

原因：模型是在「画」文字，不是「写」文字

图像生成模型把文字当成画面像素「画」出来，并没有真正的文字图层。它只是在模仿字形笔画，所以会出现以下现象：

1. 中文最难：汉字字形复杂、字库上万，模型只能近似笔画 → 不常见或笔画多的字就画成乱码。
2. 文字越长越糊：像 60 字左右的正文，字一多、字号一小，模型撑不住，整段崩坏。
3. 短词反而准：2–4 字的常见词（如「黑巧拿铁」「好喝」）模型见得多、字又少，能画对。
4. 水印也保不住：即使把「贴贴笔记 / PetaNote」写进 prompt，也会被画歪。

这是扩散类（diffusion）图像模型的通病，不是 prompt 的 bug——再怎么调措辞、提分辨率，长段中文都救不回来。

真正的解法：两层合成

核心思路是：别让图像模型画文字。把图和字分成两层处理。

第一层：图像模型只生成背景

让模型只画手帐背景 + 照片 + 贴纸 / 涂鸦装饰。prompt 里去掉所有具体文字，改成「预留文字区域 / 空白便签条」之类的描述，给后续叠字留出位置。

第二层：用真实字体叠加文字

标题、正文、小字都用真实字体在前端或后端叠加上去（Canvas / SVG / HTML 截图），用手写体中文字体渲染。

这样做的好处：

• 文字 100% 清晰正确
• 可以随时改字、换字体
• 能精准控制排版

市面上的手帐类 App 基本都是这么做的。

两套落地方案

小结

图像生成模型不擅长渲染文字，尤其是长段中文，这是底层机制决定的硬限制，无法靠调 prompt 解决。正确的工程做法是图文分层：模型负责画背景和装饰、预留空白区域，真实字体负责渲染文字。短期可先用 prompt 缩减文字量缓解，长期应上文字合成层彻底解决。

记录时间：2026-06-08 10:30:38

原文：Productivity — Sam Altman。本文为全文翻译，仅做排版，不对内容做增删改写。

我想我至少比一般人要高效一些，所以人们有时会问我关于效率的建议。于是我决定把它们全部写在一个地方。

复利增长常被当作一个金融概念来讨论，但它在职业生涯中同样有效，而且简直就是魔法。一个小小的效率提升，在 50 年里复利累积，价值惊人。所以，弄清楚如何优化效率是值得的。如果你每天比别人多完成 10% 的事、并且进步 1%，那么复利累积出来的差距会大得惊人。

做什么

如果方向毫无价值，那么你跑得多快都无所谓。挑选正确的事情来做，是效率中最重要的一环，却通常几乎被完全忽视。所以，要多花点心思去想它！独立思考很难，但它是一种可以通过练习变得更好的能力。

我认识的那些最令人印象深刻的人，对世界都有着强烈的信念，而这在普通人群中很罕见。如果你发现自己总是同意你最后交谈的那个人的观点，那就不妙了。你当然有时会判断错误，但要培养出坚持自己信念的自信。这能让你在某件重要的事情上看到了大多数人没看到的真相时，有勇气坚持下去。

我会确保在日程里留出足够的时间来思考该做什么。对我来说，最好的方式是读书、和有趣的人相处、以及在大自然中度过时光。

我已经认识到，对于自己不在乎或不喜欢的事情，我没法做得很高效。所以我尽量不让自己处在不得不做这些事的境地（通过委派、回避，或其他办法）。你不喜欢的事情，是对士气和势头的一种痛苦的拖累。

顺便提一个关于委派的重要经验：记住，其他每个人也都是在做自己喜欢的事情时最高效，所以你要像希望别人为你做的那样去做——试着弄清楚谁喜欢（并且擅长）做什么，然后据此来委派。

如果你发现自己很长一段时间都不喜欢正在做的事情，那就认真考虑一次重大的工作变动吧。短期的倦怠是会发生的，但如果休息一段时间后仍未化解，也许就该去做一些你更感兴趣的事情了。

我非常幸运，找到了自己如此热爱、以至于愿意免费去做的工作，这让保持高效变得很容易。

有一件事很重要，那就是去明白：你可以学会任何你想学的东西，而且你可以很快变得更好。头几次发生时，这感觉像是一个不太可能的奇迹，但最终你会学会相信自己确实能做到。

做出伟大的工作通常需要某种意义上的同伴。试着待在聪明、高效、快乐、积极、并且不会贬低你抱负的人身边。我喜欢和那些推动我、激励我变得更好的人在一起。在你力所能及的范围内，远离相反类型的人——让他们占用你的心智周期，其代价是可怕的。

你既要挑对问题，又要把工作做好。捷径并不多。如果你打算做一件真正重要的事，那么你很可能既要聪明地干、也要努力地干。最大的奖赏会被激烈地争夺。这并非在每个领域都成立（有些伟大的数学家每周从不花太多小时工作），但在大多数领域是成立的。

优先级

我的系统有三大支柱：「确保把重要的破事做完」、「别在愚蠢的破事上浪费时间」，以及「列很多清单」。

我强烈推荐使用清单。我会列出我每年、每月、每天想要完成的事情。清单非常聚焦人心，而且它们帮助我处理多任务，因为我不必在脑子里记住那么多东西。如果我没心情做某个特定的任务，我总能找到另一件我有兴致去做的事。

我更喜欢写在纸上的清单。增减任务都很容易。我可以在会议中查看它们，而不会显得失礼。我会频繁地重新誊抄清单，这迫使我去思考清单上的每一项，并给了我一个增删条目的机会。

我不去费心做分类、估算任务大小之类的事情（我最多就是在真正重要的条目旁边打个星号）。

我尝试以一种能产生势头的方式来排优先级。我完成得越多，感觉就越好，然后我就完成得更多。我喜欢用一件我真能取得进展的事来开始和结束每一天。

对于完成我最重要的项目，我是毫不留情的——我发现，如果我真的想让某件事发生、并且推得足够用力，它通常就会发生。

我尽量对各种事情狠下心来说「不」，并用尽可能快的方式去做那些非关键的事情。我大概把这一点做得太过了——比如，我几乎可以肯定，我回复邮件时简短到了近乎无礼的地步。

我通常尽量避免开会和参加会议，因为我发现时间成本巨大——我从待在办公室的时间里获得的价值最高。然而，至关重要的是，你要在日程里保留足够的空间，以容纳偶然的相遇、以及接触新的人和新的想法。拥有一个开放的人脉网络很有价值；尽管我接受的随机会面大概有 90% 是在浪费时间，但另外那 10% 真的能把这一切都补回来。

我发现大多数会议最好安排为 15-20 分钟，或者 2 小时。默认的 1 小时通常是错的，会导致大量时间被浪费。

我会把一天中不同的时段用于不同种类的工作。早晨最初的几个小时绝对是我一天中最高效的时间，所以我不让任何人在那时安排任何事情。我尽量把会议放在下午。每当我感到注意力开始消退，我就休息一下，或者切换任务。

我认为大多数人不够珍视自己的时间——我认识的很多人，时薪 100 美元，却愿意花上好几个小时去做一件自己不想做的事，只为省下 20 美元，这让我很惊讶。

另外，别掉进「效率色情」的陷阱——为了效率本身而追逐效率是没有帮助的。许多人花太多时间去思考如何完美地优化自己的系统，却远远没有花足够的时间去问自己是否在做正确的问题。如果你做的是错的事情，那么无论你用什么系统、是否榨干了每一秒，都无关紧要。

正确的目标是最优地分配你的一年，而不是你的一天。

身体因素

对我而言最优的，很可能对你来说并不最优。你得通过实验来弄清楚什么最适合你的身体。这绝对值得去做——它对生活的方方面面都有帮助，而且你会整体上感觉好得多、也更快乐。

为了找到最适合自己的方案，大概有几年时间里，我每周都要花上一点时间，但我的感觉是，如果下面这些我都做得不错，我至少比不做时高效 1.5 倍。

睡眠似乎是对我的效率而言最重要的身体因素。用某种睡眠追踪器来弄清楚如何睡得最好是有帮助的。我发现，唯一能让我坚持下去的，是那种「设置一次就不用管」类型的设备，我很喜欢 Emfit QS+Active。

我喜欢一个寒冷、黑暗、安静的房间，以及一张很棒的床垫（多年来我一直抗拒花一大笔钱买张好床垫，这很蠢——它对我的睡眠质量有着巨大的影响。我很爱这张）。睡前几小时不吃太多东西会有帮助。不喝酒帮助很大，尽管我并不愿意一直都不喝。

如果没法让房间够冷，我就用 Chili Pad 在睡觉时保持凉爽，它很棒但很吵（我把它的冷却装置安在了房间外面）。

旅行时，我会用眼罩和耳塞。

这一点很可能会有争议，但每当我睡不着时，我会服用低剂量的安眠药（大约是正常剂量的三分之一）或极低剂量的大麻。我整体上是个糟糕的睡眠者，旅行时尤其糟糕。这很可能有它的权衡代价，但睡不好也有代价。如果你本来就能睡得很好，我不会推荐这样做。

大多数早晨，我会在补回邮件的同时，用一盏全光谱 LED 灯照约 10-15 分钟。它很棒——如果这里的其他东西你都不试，这就是我会让你试的那一个。对我来说，它是个荒谬到夸张的收益。我喜欢这一款，而且它便于携带旅行。

锻炼大概是第二重要的身体因素。我尝试了若干不同的锻炼计划，每个试几个月，结果看起来最好的，是每周 3 次、每次 1 小时举重，再偶尔做高强度间歇训练。除了效率上的收益，这也是让我整体感觉最好的锻炼计划。

第三个领域是营养。我极少吃早餐，所以大多数日子我都有大约 15 小时的禁食（醒来时的一杯浓缩咖啡除外）。我知道这与大多数建议相悖，我也怀疑它对大多数人来说并非最优，但它对我确实很有效。

吃大量的糖是让我感觉最糟的事，也是我最努力去避免的。我还尽量避免那些会扰乱我消化、或激起炎症的食物（比如非常辛辣的食物）。在甜食面前我没什么意志力，所以我基本上就是尽量不让垃圾食品进家门。

我醒来后立刻喝一大杯浓缩咖啡，午饭后再喝一杯。我估计这一天总共大约 200 毫克咖啡因。我试过其他几种配置；这是远比其他都更有效的一种。除此之外，我会积极避免兴奋剂，但如果我极度疲惫、又真的需要把某件事做完，我会再多喝点咖啡。

我是素食者，从小就是，并且补充甲基 B-12、Omega-3、铁，以及维生素 D-3。我是通过大约一年左右的季度血液检查得出这份清单的；从那以后它一直对我很管用（我大概每一年半左右再检测一次）。有很多医生会很乐意为你做一次超全面的血液检查（也有像 WellnessFX 这样的服务）。我还会特意去喝大量的蛋白粉奶昔，我讨厌它，如果我不是素食者就不会喝。

其他

这是我在工作空间里喜欢的东西：自然采光、安静、知道在我不想被打扰时不会被打扰、长段的整块时间，以及舒适和放松（我在办公室里有一张漂亮的桌子，上面摆着几台 4k 显示器，但我几乎所有时间都是在沙发上抱着笔记本电脑度过的）。

对于那些我得频繁去做的烦人事情，我写了定制软件，这很棒。我还下功夫学会了打字打得很快、以及那些有助于我工作流程的键盘快捷键。

像大多数人一样，我有时会经历一两周完全没有任何动力去做任何事的时期（我怀疑这可能与营养有关）。这很糟糕，而且似乎总在不方便的时候发生。除了等待迷雾散去、并相信它最终总会散去之外，我还没弄明白该拿它怎么办。而且我通常会尽量避开那些让我心情变坏的人和处境，无论你是否在乎效率，这都是个好建议。

总的来说，我认为稍微「过度承诺」一点是好事。我发现自己通常能完成我所承担的事，而如果我手头的事稍微多了一点点，它会让我在每件事上都更有效率，这是一种训练自己避免分心的方式（一个很棒的习惯！）。然而，大幅度地过度承诺则是灾难性的。

不要为了效率而忽视你的家人和朋友——那是一桩非常愚蠢的交易（而且很可能是净的效率损失，因为你会变得不那么快乐）。也不要忽视去做那些你热爱的、或者能让你头脑清醒的事情。

最后，再重复一遍：错误方向上的效率根本一文不值。多想想该做什么。

记录时间：2026-06-06 22:24:37

问题

「这个世界是丰富多彩的，每个人都有存在的意义，不必成为任何人，不必成为任何人口中的自己，允许自己成为自己。」

这句话听起来像一句温柔的鼓励，但它真的站得住脚吗？如果只是心灵鸡汤，它经不起追问。本文尝试用跨学科的视角——把进化生物学、生态学、复杂系统、心理学、社会学、哲学和经济学摆在一起——来验证这句话是否成立。结论是：它不仅成立，而且是被多门学科反复证明的硬道理。

一、生物学：你的独特性是写进基因里的事实

进化生物学给出的第一个证据是冷峻而无可辩驳的：多样性不是缺陷，而是物种存活的前提。

一个基因高度同质化的种群是脆弱的。爱尔兰大饥荒的根源之一，就是当时种植的马铃薯品种过于单一，一种病菌便足以摧毁整片土地。反观一个基因多样的群体，总有一部分个体携带着抵御未知灾难的特质。换句话说，「与众不同」是自然选择刻意保留的保险机制。

落到个体层面：除同卵双胞胎外，地球上从未出现过两个基因完全相同的人，未来也不会有。你身上约 30 亿个碱基对的排列组合，是一次不可复制的事件。从这个意义上说，「成为别人」在生物学上是一个伪命题——你连复制另一个人的硬件都做不到。

二、生态学：每个物种都有自己的「生态位」

生态学里有一个核心概念叫生态位（niche）：每个物种在生态系统中占据的独特位置——吃什么、在哪活动、与谁共生。

竞争排斥原理（Gause's law）指出：两个生态位完全重叠的物种无法长期共存，一方终将被淘汰。生物的应对策略不是「打赢对方」，而是分化——通过占据不同的生态位来避免正面竞争。达尔文在加拉帕戈斯群岛观察到的雀类，正是用喙的形状差异，分别去吃不同的食物，从而各自安身立命。

这对人极有启发：**当你拼命去模仿一个已经做得很好的人，你是在主动挤进一个已被占满的生态位，那是最惨烈、最不划算的竞争。**真正的智慧是找到、甚至创造属于你自己的生态位。「存在的意义」在生态学里不是抽象口号，而是「你占据了一个别人无法替代的位置」。

三、复杂系统：多样性让整体更聪明、更稳健

把视角拉到系统层面，复杂科学提供了第三重论证。

研究群体智慧的学者发现，一个由「多元但能力中等」的人组成的团队，常常能胜过一个由「同质的顶尖高手」组成的团队。原因在于：同质的人会犯同样的错误，他们的判断高度相关，误差无法相互抵消；而多元的成员从不同角度切入，错误彼此独立，整体反而更接近真相。这就是所谓的「多样性预测定理」。

更宏观地看，一个生态系统、一个经济体、一个文明的韧性，都来自其内部的多样性。单一作物的农田、单一产业的城市、单一思想的社会，都格外脆弱。因此，你坚持做独特的自己，不只是为了你个人——你是在为你所处的整个系统贡献它赖以存活的「冗余」与「多样性」。 你的不一样，是系统的免疫力。

四、心理学：「假我」是会致病的

如果说前面是「外部」的论证，心理学则直指内部代价。

精神分析学家温尼科特提出过「真我」与「假我」的区分。一个孩子若总是被迫迎合他人的期待，就会发展出一套用于讨好、自我保护的「假我」，而真实的感受被压抑、被掩埋。假我能换来一时的认可，长期却带来空虚、抑郁与「我不知道自己是谁」的迷失。

人本主义心理学的马斯洛把「自我实现」放在需求的顶端——成为你能够成为的那个人。而自我决定理论进一步用大量实证指出：人类有三个基本心理需求——自主、胜任、联结。其中「自主」（autonomy）即「行为出于自己的意愿，而非外部强迫」，是幸福感与内在动机的根基。

这里有一个关键澄清：自主不等于自私或孤立。它指的是行为的来源是你自己认同的，而不是你切断了与他人的关系。研究反复显示：当人按内在价值生活时，心理健康水平更高；当人长期为「别人口中的自己」而活，付出的是真实的健康代价。「允许自己成为自己」不是一句鸡汤，而近乎一条心理卫生准则。

五、社会学：「别人口中的你」只是一面扭曲的镜子

那么，「别人口中的自己」究竟是什么？社会学家库利提出过**「镜中我」**（looking-glass self）：我们的自我认知，部分是通过想象他人如何看待我们而形成的。

这个机制本身是中性的、不可避免的——人是社会性动物。但它有一个危险的陷阱：**镜子会失真。**别人对你的评价，往往混杂着他们自己的投射、偏见、未被满足的期待，以及他们看你时所站的有限角度。把一面失真的镜子当成自己的全部真相，是大多数痛苦的来源。

社会比较理论也揭示：人天生倾向于通过与他人比较来评估自己，而社交媒体把这种比较放大到了病态的程度——你拿自己的幕后，去比别人精心剪辑的高光。理解了这层机制，你就能把「别人怎么说」放回它应有的位置：一份可供参考的、但绝不等于真相的二手信息。

六、哲学与经济学：意义是你创造的，优势是你独有的

存在主义哲学家萨特有一句名言：**「存在先于本质。」**意思是，人不像刀（被造出来就带着「用来切割」的本质）——人先存在，然后通过自己的选择来定义自己是谁。没有谁规定了你「应该」成为什么，意义不是被发现的，而是被创造的。尼采那句「成为你自己」，东方庄子笔下「曳尾于涂中」、宁愿在泥里摇尾也不愿被供奉的乌龟，说的是同一件事：生命的意义在于活出你自己的版本，而非活成一个被预设的模板。

经济学则补上最务实的一刀——比较优势理论。李嘉图证明：即便一个人在所有事上都不如别人（绝对劣势），只要专注于自己「相对最擅长」的领域，依然能通过分工创造价值、参与交换。这意味着：你完全不需要在任何维度上「成为最强的那个人」，你只需要找到并经营你的独特组合。世界的丰富，恰恰建立在每个人都不同、于是可以互补、可以交换的基础之上。

小结

把六门学科的结论叠在一起，那句温柔的话就有了坚硬的骨架：

• 生物学：你的独特是基因事实，「成为别人」根本不可能；
• 生态学：模仿是挤进满员的生态位，找到自己的位置才是出路；
• 复杂系统：你的不同，是整个系统的韧性与智慧来源；
• 心理学：活成「假我」要付出真实的健康代价，自主是幸福的根基；
• 社会学：「别人口中的你」是一面会失真的镜子，是参考而非真相；
• 哲学与经济学：意义由你创造，价值源于你独有的比较优势。

所以，「允许自己成为自己」不是逃避，也不是任性，而是顺应了从分子到文明各个层级都在反复印证的规律。这个世界之所以丰富多彩，正是因为没有两个人是一样的——而你要做的，只是不去抹掉那份本就属于你的不一样。

记录时间：2026-06-06 21:40:51

问题

如何在 2026 年真正建立起能坚持下去的习惯？《掌控习惯》（Atomic Habits，全球销量超 2500 万册）作者 James Clear 在 The Diary Of A CEO 的访谈中，系统拆解了习惯养成与戒除的底层逻辑：为什么我们总在突破前放弃、为什么目标不如系统、以及如何让"不可能的习惯"变得毫不费力。

本文提炼这场两小时对谈中的核心观点。

习惯的本质：结果是习惯的"滞后指标"

习惯既普世（人人都有）又私人（感觉是自己独有的）。它的影响远超表面：

你在生活中的结果，是先于它们的那些习惯的滞后指标（lagging measure）。

• 你的知识，是阅读与学习习惯的滞后指标
• 你的存款，是财务习惯的滞后指标
• 客厅的杂乱程度，是打扫习惯的滞后指标

所以不要执着于改变结果，改变输入，输出会自动改变。一个看似只花两秒的习惯（比如拿起手机），可能决定了你接下来一小时怎么过——它是进入其他行为的"入口匝道"。

让习惯"好玩"：Grit is fit

James 说如果重写这本书，他会加上一个问题：

如果这件事变得好玩，会是什么样子？（What would it look like if this was fun?）

为一个重要习惯花 10 分钟，列出所有可能的形式（想健身？健身房、皮划艇、攀岩、瑜伽、普拉提……），挑出对你最有趣的那一个。原因是：

• 觉得好玩的人，遇到困难时更可能坚持
• 一开始就把它当成苦差事的人，一旦变难就会放弃

朋友 David Epstein 的话总结得最好："Grit is fit"（毅力即契合）。人人都想有毅力，但毅力只在你擅长、适合、感兴趣的领域才会显现。所以最大的门槛不是自律，而是：你是否真的投入、是否觉得有趣。

创造成功的条件，掌握"开始的艺术"

James 有一年健身极不稳定，表面看是"训练出了问题"，实际上是没有创造成功的条件。后来他请了私教，每周四天固定上午 11 点上门——每次都觉得被打断、很烦，但条件保证了他一定会去练。

《掌控习惯》里大约 70% 的内容，都是帮你更容易"开始"的策略。

几个具体方法：

减少范围，但守住日程

Reduce the scope but stick to the schedule.

本来要写 30 分钟，结果只剩 15 分钟——别对自己说"今天没时间了"，而是进去做几组深蹲就好。关键是不要交白卷。只要不交白卷，习惯就维持住了；只要习惯维持住，剩下的只需要时间。坏日子比好日子更重要。

预置环境，让第一步变简单

• 写作前先写下第一句话留在文档里，第二天回来就"已经在状态里"
• 把要写的主题写在便利贴贴在键盘上
• 跑步的人前一晚把跑鞋和衣服放在床边（有人甚至穿着跑步服睡觉）

走进你常待的房间，问自己：这个空间是被设计来鼓励什么行为的？ 你想要的好习惯，是这里阻力最小的那条路吗？

两分钟法则

如果只能记住一条原则，那就是 make it easy（让它简单）。把任何习惯缩小到两分钟以内：

• "一年读 30 本书" → "读一页"
• "每周四天瑜伽" → "把瑜伽垫拿出来"

书中的 Mitch 头六周给自己定规矩：去健身房待不超过 5 分钟。听起来很蠢，但他在掌握"出现"这件事，成为"每周去四次健身房的人"。

习惯必须先被建立，才能被改进（A habit must be established before it can be improved）。

健身房里最重的器械，是那扇大门。——Ed Latimore

习惯塑造：从"尴尬地小"开始

习惯塑造（habit shaping）就是逐步放大：想跑半马，第一天只是穿上跑鞋，第二天走出家门，第三天绕街区一圈。

野心大的人容易犯的错，是去想象"巅峰状态下我能做到的一切"。更好的提问不是"我状态最好时能做什么"，而是：

即使在最糟的日子，我能坚持的最低标准是什么？

把它当作地基。人最有动力的感受之一就是进步感——哪怕很小。很多人却成了自己期待的受害者：花太多时间设计完美计划，前几天没达标就全盘崩溃。

Hats, Haircuts, and Tattoos：决策框架

决策最大的成本往往不是做错，而是做决定时浪费的时间。James 用三类东西区分决策：

本质是问：这个选择可逆还是不可逆？ 可逆就快速行动。现实里大多数决策是帽子和理发，但我们却都当成纹身来对待。

系统 vs 目标：决定 2026 的核心

目标关乎你想达成的结果，系统关乎抵达的过程。

• 目标是靶子；系统是你每天遵循的习惯集合
• 一旦目标和系统出现落差，每天的习惯永远会赢
• 你当前的习惯，被完美地设计来交付你当前的结果

关键结论：

目标适合只想赢一次的人；系统适合想反复赢的人。

我们不会上升到目标的高度，而会下降到系统的水平（We don't rise to the level of our goals, we fall to the level of our systems）。

设定方向后，把目标"放上书架"，把绝大部分精力放在打磨系统上。判断该建什么系统，可以问：

• 我当前的习惯，能把我带到想要的未来吗？
• 我想要的不只是结果，而是那种生活方式吗？想要结果却不想要对应的生活方式，是一种自我折磨。
• 做新项目时，先问"我想怎么度过我的每一天"，画一个框，在框内追求最大影响力——而不是反过来。

目标的陷阱：赢家和输家有相同的目标

100 个人应聘同一个职位，每个人的目标都是"得到这份工作"；奥运赛场上每个选手都想夺金。

既然赢家和输家有相同的目标，目标就不可能是造成差异的原因。差异来自系统。

目标还会限制幸福感：你总在内心承诺"等我达到 X 就会快乐"，于是把幸福一再推迟到下一个里程碑。更好的方式是爱上过程本身。

James 用橡果的比喻回应"是否必须不满才能有动力"：橡果长成橡树的过程中，从不因为"还不是树苗"而自责，它在每个阶段都是完美的，却始终在生长——因为它本就被编码为生长。人可以同时既满足于当下，又被驱动着前进。

关于比较：

比较是技能的老师（窄处用），却是快乐的小偷（宽处用）。

比较小事（营销策略、深蹲姿势、开头第一句）能磨练技能；比较大事（婚姻、净资产）只会让人不快乐，因为尺度越大越模糊，你看到的只是别人的一小片切面。

先做哪个习惯：找"上游"的锚点习惯

想养成的习惯太多时，问自己：哪些习惯位于其他好事的上游？

James 的两个锚点：健身和阅读。健身带来的连锁反应——专注力提升、睡得更好、吃得更好——都是自然结果，他从没专门去建"专注/睡眠/饮食"习惯。

还有一个凌驾于所有习惯之上的元习惯：反思与复盘。

如果你工作努力到一定程度，努力会变成拐杖——遇到问题就想"再拼一点"。但努力有上限，做对的事却能带来 100 倍、1000 倍的回报。

只有留出时间思考，才能判断下一步该聚焦什么，才能排查并调整你的习惯与系统。

系统会过期：习惯按"季节"变形

最被忽视的一点：人们默认"成功的习惯=做一辈子"，一旦停下就觉得失败了。但事物有季节，习惯需要随时间改变形状。

James 的写作习惯演变：前三年每周一、四各写一篇 2000 字文章（共 150 篇）→ 写书的三年 → 现在每周一封更短的 newsletter。形式一直在变，但"写作习惯"始终维持着。

四个炉灶理论（Four Burners Theory）

把生活比作炉灶上的四个灶头：工作事业、家庭、朋友、个人健康。想让它们都烧得旺，你无法同时开满四个——开三个只能中等火力，想真正做好只能同时开两个。

核心是承认：生活的根本是取舍，你无法同时擅长所有事。

James 进一步提出人生的"序列"：大的人生阶段约为 10 年一段，成年后大概只有五六段。有些事更适合按特定顺序排（20 多岁创业比 50 多岁容易；想环游世界很难等到 60 多岁；生育有生理窗口）。他现在主动把"事业"那一格调小，因为孩子只会五岁一次。

66 天是个误解：习惯是生活方式，不是终点线

"66 天养成习惯"来自一项研究的平均值，但区间很宽：简单如"午餐喝杯水"可能两三周，复杂如"下班后跑步"可能七八九个月。

养成一个习惯要多久？我的答案是——永远。

因为一旦停下，它就不再是习惯。

习惯不是一条要跨越的终点线，而是一种要去过的生活方式。

昨天去了健身房，不会给今天加分；昨天是个好伴侣，不代表今天可以不再关心对方。真正重要的事都是没有尽头的战斗。

为什么习惯会越来越容易

学术意义上的"习惯"是刷牙、系鞋带那种无意识自动行为；但我们口中想养成的"健身/写作"其实是有意识的例程与仪式，不会变得像反射一样自动。坚持一两个月后变轻松，靠的是三股力量：

1. 一次性成本已解决：去哪个时间、走哪条路、带不带水壶——这些小摩擦早期搞定后就不再耗神（别小看水壶，有人因为忘带水壶就跳过训练）
2. 熟悉感/领地感：像狼圈定领地一样，那个空间逐渐变成你的"主场"
3. 身份认同：重复越多，越强化"我是这种人"

身份认同：每个行动都是一张选票

建立习惯的最深层钥匙——让习惯强化你想成为的身份。

与其问"我想达成什么"，不如先问"我想成为谁"。

每一个行动，都是为你想成为的那种人投下的一票（a vote for the type of person you wish to become）。

• 做一个俯卧撑不会改变体型，但它为"我是不会翘掉训练的人"投了一票
• 写一句话写不完小说，但它为"我是个作家"投了一票

不是"假装直到成真"，而是让行动先行：先做一个销售电话、冥想一分钟、做一个俯卧撑，让那一刻成为你就是这种人的证据。坚持足够久，你会越过一道无形的门槛，不得不承认"这已经是我的一部分"。

戒烟的经典例子：被递烟时，第一个人说"不了，我在尽量不抽"（仍视自己为吸烟者）；第二个人说"不了，我不是抽烟的人"——身份已经改变，行为更容易维持。

身份反馈也有研究支撑：用身份（"你是个善良的人"/"我是一个投票者"）而非形容行为（"那件事很善良"），更能促成对应行为。James 因此常对团队说"你是个创新者""你是敢做实验的人"。

认知失调与社会关系

我们不擅长同时持有两个矛盾的信念，所以会保护自己的身份（认知失调，Leon Festinger）。而身份很大程度上系于关系——父亲、丈夫、朋友——社会纽带塑造了我们对自己的画像。

环境设计：把自己放进"想要的行为是常态"的群体

习惯可以定义为绑定在特定情境上的行为（沙发 + 晚 7 点 = 看 Netflix）。所以：

• 在新环境里更容易建立新习惯。想开始写日记，可以在角落放一把"日记椅"，坐上去只做这一件事，创造新情境
• 不必"开除朋友"，而是为习惯找到能茁壮生长的地方：家里没人陪你做瑜伽，就去瑜伽馆，那一小时里你想要的行为就是常态

加入那些"你想要的行为是正常行为"的群体，然后一起进步。

James 早年没有创业者人脉，就发了 300 封冷邮件给比自己领先一两年的人，约 30 人回复，半年后线下见面，再办起作者退修会（租 Airbnb 分摊成本）——有时你得鼓起勇气，自己创造这个空间，因为大家都在等别人来牵头。

给"困在原地的人"的建议

很多人困在不喜欢的工作里，被房贷、父母期待、疲惫拖住，梦想一直只是梦想。James 的回答：

1. 不要沉溺于诉说它有多难——抱怨只会让糟糕的处境更糟
2. 用现有的优势去换取新的优势：早期他唯一的优势是"时间"，于是用时间每周写两篇文章、做兼职糊口；两年后有了邮件列表（新优势）→ 拿到书约（再一个新优势）……这是一场不断累积的游戏
3. 它比你想要的慢：上面 20 秒讲完的事，其实是他七年的人生

1% 复利：关注轨迹，而非位置

每天进步 1%，一年后是 37 倍（1.01^365）；每天退步 1%，一年后趋近于零（0.99^365）。这条复利曲线揭示两件事：

1. 所有最大的回报都被延迟：你要走到曲线 80% 的位置，它才真正起飞，早期毫不起眼
2. 第一天 0.99 和 1.01 的差距极小：今天午餐吃健康还是不健康，几乎没区别——正因如此才容易被忽视

时间会放大你喂给它的东西。好习惯让时间成为盟友，坏习惯让时间成为敌人。

这条曲线真正的功课不是纠结具体百分比，而是一种态度：强调轨迹而非位置。我们对"位置"（存款、体重、股价）有太多度量，达不到就自责；不如问——箭头是朝右上方，还是已经走平了？ 轨迹对了，剩下的只需要时间。

累积的 1% vs 蒸发的 1%

小改进既可能累积成大东西，也可能白白蒸发。分界线是：这个行动会累积成更大的东西吗？

人生最重要的两个时间尺度，是 10 年和 1 小时。

10 年是"你真正在乎的大事"（创业、家庭、婚姻、健康）的简称。如果今天能花 1 小时做一件 10 年后会回报你的事，往往两三年就开始显现复利。

一切的最上游：人

最重要的洞察之一——人/关系是最上游的因素：

• 几乎每个商业问题，底层都是人的问题，或有某个人能解锁它
• 人生最重要的决定之一，是和谁结婚
• 没有任何机会是不依附于人的——机会通过人而来。所谓"幸运的突破"，往往是某个携带着机会的人，你需要去认识、去对接

我这辈子做过的最好的决定都是关于人，最糟的决定也都是关于人。

所以"furthest upstream（最上游）"的工作，常常就是关于人：与其周末加班想点子，不如把下一个小时花在招对的人上——它修正的是 10 年后的结果。

小结

这场对谈可以浓缩成一句话：别盯着目标和当下的位置，去打磨每天的系统、设计你的环境、并用每个微小行动为"你想成为的那个人"投票。

四个行为改变的法则贯穿始终——让它显而易见（obvious）、让它有吸引力（attractive）、让它简单（easy）、让它令人满足（satisfying）；配合习惯叠加（在已有习惯之后接上新习惯，如"早上煮完咖啡，就冥想 60 秒"）。

而决定 2026 的，不是你定下的新年目标，而是你愿意日复一日维持的那套系统——因为结果会修复自己，只要你修复习惯。

记录时间：2026-06-06 21:27:15

这期播客在聊什么

投资人郑兰对话技术人郝培强（Tinyfool）的一期播客访谈。郝培强早年是硬核程序员、技术大 V，如今高频产出 AI 视频（主用 Sora 2）。两人围绕一个问题展开：当 AI 把「实现」的门槛拉平后，工作版图、创作方式、乃至个体的焦虑，会被如何重写。

视频原标题《当人人都能当导演：AI 时代的工作版图将被彻底重写？》，来源频道「Tinyfool的胡说八道」。以下是核心观点的整理。

核心观点：AI 带来的不是替代，而是角色的变化

这是贯穿全场的主线。郝培强的判断是——AI 不会简单地「替代」一个人，而是改变这个人扮演的角色。

• 写程序时：以前 90% 的时间花在具体实现代码上（登录、查询、增删改查这些重复劳动）。有了 AI 编程工具后，关注点从「怎么写」上移到「到底要做什么样的产品」——角色从编码工变成了产品经理 / 产品 owner。
• 做视频时：同理。任何视频都有大量重复套路（opening、特写、转场），这些和剧本要表达的核心其实关系不大。把这些交给 AI 后，人就回到了更本质的问题：我到底要的是什么样的作品。角色变成了编剧和导演。

「你似乎把演员去掉了，把场记去掉了，去掉了很多角色，但是编剧和导演并没有被去掉。核心灵魂还在。」

人们害怕的「AI 取代」，本质是害怕一种变化——自己熟悉的角色不再存在。但能不能适应「从一线执行抽离、变成导演 / 策划」，才是关键。

关于 AI 创作工具的实战体会

Sora 2 的冲击：用最简单的提示词得到好结果

郝培强不推崇复杂的「提示词工程」（一堆 JSON、镜头推拉的复杂描述）。他的做法是：

1. 先用最简单的一句话描述场景；
2. 出一个版本后，看它和想要的哪里不一样；
3. 再针对性地补充提示。

Sora 2 让他震撼的点在于它的泛化能力——你给一个极简提示，它会自动延展剧情、把中间的动作、台词甚至表情合理化。比如他只写「我和一个超级大美女拥抱在一起」，没有设置任何台词，AI 自动补出了台词和表情，效果出人意料。这让他更能理解 Sora 所说的「世界模型」是什么。

「创建角色」即「无痛入镜」

Sora 2 创建角色的过程极简：对着屏幕念几个数字、摇头张嘴，约 30 秒完成。之后只要 @ 自己的 ID 加一句话（如「TinyFu 正在爬酋长岩 Free Solo」），就能生成精准的、把自己放进去的视频。扔到抖音后引发大量「这是真的还是假的」的讨论。

「抽卡」就是选角，「补拍」变得极廉价

• 抽卡 = 选角 / 多拍几遍：同一个提示词跑十遍，挑最满意的那一版再去修饰（比如改头发颜色），本质就是选演员。
• 补拍极容易：一个 20 分钟视频由大量 10 秒片段拼成，中间哪段不好，把相关信息拿回来重新生成即可。Sora、Veo（Google）都支持。Google 还把 Nano Banana 塞进 Veo——可以从生成的视频里取一帧，用 Nano Banana 改图后再作为素材回去生成视频。

关键的隐性工作：研究与交叉验证

这是常被忽略、但郝培强反复强调的部分——AI 创作不是「一句话躺平出片」。

以他做的「蒸汽机历史」3 分钟科普视频为例，工作流是：

1. 让 ChatGPT 写一篇详细的蒸汽机历史（含瓦特之前的人物等他自己也不了解的细节）；
2. Review 后，让它转成分镜头脚本（拆成七八个镜头）；
3. 进一步让它直接产出每个镜头的 Sora 提示词 + 画外音文案；
4. 自己只做「执行」：把提示词扔进 Sora，得到 30-40 个片段，再和画外音整合、补动画。

他在中间做的是创意 + 决策：教 AI 怎么 break it down。

但交叉验证不可省：AI 会有幻觉。蒸汽机的机械原理 AI 一定生成错（它不懂曲轴、连杆怎么运动），他要去 Wiki 找最古老机器的图纸 → 喂给 Nano Banana 还原成真实机器 → 再用 Sora/Veo 做运转动画。「这个工作做得很辛苦。」

谈 AI 创作时大家很少讲后面这些：它需要研究、需要知识储备、需要交叉验证，不能完全相信生成结果。

AI 时代最重要的能力

郑兰把对话中的要点概括为三条：

1. 想象力：新技术 / 新浪潮出现时，你的想象力边际有多大，就能做到多大的事。
2. 重构的能力（把自己清零）：很多人有习惯性思维、固定路径不愿改。做风险投资养成的好习惯是「把自己清零」，在清零状态下看一件事的本质、看接下来往哪个方向有机会。
3. 拥抱变化 + 适度的「懒」：郝培强补充——「专业精神」有时会拘泥于「怎么完成」的方式方法，而 AI 时代不断告诉我们：核心不是方式方法，而是结果，能不能最快得到结果。每次「重复自己」时的厌烦，正是该把活交给 AI 的信号。

投资人视角：不预测行业，看注意力在哪

郑兰分享了她的方法论：不去预测行业未来（多数人没这个能力），而是看 C 端消费者把注意力放在哪——谁抢占了用户注意力，哪里就有机会。

当下的事实是：内容信息从图文走向视频，短视频已占主导；内容供给方有大量提效诉求；而现在工具已经成熟。所以——能把创意快速实现出来，就是关键的入场点。

门槛被拉平后，技术大牛 vs 文艺青年谁更有优势

郝培强认为这不是问题，两者殊途同归：

• 以前的门槛是「实现的门槛」（2012-2013 年人人想做 iOS/安卓却找不到程序员）。今天实现已经不难。
• 视频同理：以前要搭团队、找好演员，今天「AI 就是好演员，它做演员、我们做导演」。
• 核心是你 focus 在哪个点。他 focus 的是结果，所以不在乎门槛下降——「门槛下降反而让我有机会入场去玩」。

他还把这点和电影史联系起来：乔治·卢卡斯早期的飞船是纸壳子，「你说 AI 做的飞船是假的，那纸壳子不是假的吗？」电影本就是「让观众相信」的艺术，用 AI 还是用纸壳子，本质都是怎么把一个信息、一种感觉传达给人。

快问快答里的几个判断

• 影视行业谁最先被取代、谁活到最后：最后可能都被淘汰，只剩导演。
• Sora 像抽盲盒，失控感让你抓狂还是兴奋：只有简单任务能完全掌控；做任何复杂的东西本就充满随机因素。类比：以前拿砖块盖房子，现在用预制件直接拼一层楼——真正完成作品时仍有大量细节要调适，并非「无法精准控制」。
• 朋友圈/抖音会不会被「精致的垃圾」填满：问题不在创作端，在消费端——平台最终充斥什么由用户喜欢什么决定，算法会做过滤。
• AI 用现有数据训练，是否只是重复过去的审美：理论上工具能做任何事（就像用人去演），最终选哪段、用什么提示词是你的选择；把成本降低后，反而能让想象力占据更多空间。
• 一个人就是一支队伍，会孤独吗：没问题，想做团队照样可以分工，只是角色都收敛成了导演和编剧这两个最重要的角色。
• 「眼见为实」是否作废：「真实本来就不存在」——互联网兴起后他认识的 90% 的人先在网上认识，世界本就是大脑在调用数据。新技术来临必然伴随新鲜感、争议与焦虑，但人作为个体总能用智慧消化新东西并在上面开花结果。

一个更大的图景：人类终将走向「互相娱乐」

郝培强引用了一条历史脉络来安放这次 AI 浪潮：

• 圈地运动（羊吃人）开始，全球农民数量锐减；今天美国仅约 1% 人口务农，一个农民管约 1000 公顷——说明「不需要那么多人来种地」。
• 工业革命有 30-100 年好坏参半的阵痛（污染、工人贫困），但结果是今天我们吃得更饱、活得更好。工业化才催生了真正意义上的都市、餐饮住宿成为行业。
• 电与收音机出现后，娱乐产业才真正变大——从一个剧场几百人，到上百万人同时听一档广播；再到电视、视频网站、抖音。

他的推论：这一次可能是「终极问题」。如果 AI 和机器人达到想象中的水平，5-10 年甚至 20 年后，很可能 90% 的实体制造工作、70-80% 的 office job 都会消失，物质生产高度自动化。而抖音是一个「先声」——所有人娱乐所有人，人类最终可能去做的一件事，就是互相娱乐。

关于焦虑：本质是「时间不够」的错觉

郑兰分享了一个化解焦虑的视角：35-40 岁的人常因迷茫而焦虑，但如果假设寿命是 150 年或 300 年，当下的烦恼大多就不成立。焦虑的根源在于「认为自己没那么多时间了」或陷在「本该如何却没有」的懊悔里。

由此她对「会不会被 AI 取代」的回答是：只要你的技能随着行业、产业、技术向上迭代，就不会被淘汰；被淘汰的是技能停在原地、只在侧端发展的人。「永远知道这个时代往前走的主流是什么，抓住它就可以了。」而善用 AI 工具，本质是拓宽了生命的宽度，让生活更精彩。

小结

整场对话可以收敛成一句话：AI 拉平的是「实现」的门槛，而非「创意、决策与品味」的门槛。

• 角色上移：从执行者变成编剧 / 导演 / 产品经理，聚焦结果而非过程；
• 隐性功夫仍在：研究、知识储备、交叉验证决定作品上限，AI 不能无脑相信；
• 心态上：把自己清零、拥抱变化、允许自己「懒」于重复劳动；
• 焦虑可解：跟随主流技术向上迭代，把节省下来的时间还给想象力。

记录时间：2026-06-05 16:21:02

问题

ECC（Claude Code 增强工具集）注册了数量庞大的 skills。需要把这些 ecc: 开头的技能系统地列举出来并简要说明，弄清它们各自的用途，方便按需调用。

ECC Skills 的两大类型

ECC 的 skills 分为两类：

• 命令型 skills：通过 /ecc:xxx 显式调用的工作流或操作命令。
• 知识型 skills：按当前任务领域自动加载的领域知识，不需要手动触发。

一、命令型 skills（工作流 / 操作命令）

规划与开发流程

构建 / 审查 / 测试（按语言）

质量 / 安全 / 重构

会话 / 状态管理

自动化 / 学习 / 钩子

项目 / 文档 / 集成

二、知识型 skills（领域知识，按需自动加载）

语言 / 框架模式

• 前端：react-patterns, react-performance, react-testing, nextjs-turbopack, vite-patterns, nuxt4-patterns, angular-developer, frontend-patterns, frontend-a11y, ui-to-vue
• 后端：backend-patterns, fastapi-patterns, django-patterns, django-celery, nestjs-patterns, laravel-patterns, springboot-patterns, quarkus-patterns, golang-patterns, rust-patterns, python-patterns, kotlin-patterns, dotnet-patterns
• 数据库：postgres-patterns, mysql-patterns, redis-patterns, prisma-patterns, jpa-patterns, clickhouse-io, database-migrations
• 移动端：swiftui-patterns, swift-concurrency-6-2, android-clean-architecture, compose-multiplatform-patterns, dart-flutter-patterns

架构 / 工程实践

api-design, architecture-decision-records, hexagonal-architecture, error-handling, deployment-patterns, docker-patterns, coding-standards, git-workflow, github-ops, mcp-server-patterns

AI / Agent 工程（ECC 特色）

agentic-engineering, agentic-os, ai-first-engineering, autonomous-agent-harness, autonomous-loops, continuous-agent-loop, agent-architecture-audit, agent-eval, agent-introspection-debugging, team-agent-orchestration, prompt-optimizer, context-budget, token-budget-advisor, cost-aware-llm-pipeline, eval-harness, continuous-learning(-v2)

测试 / 质量

tdd-workflow, e2e-testing, browser-qa, ai-regression-testing, production-audit, security-review, security-scan, security-bounty-hunter，以及各语言 *-testing

行业 / 业务领域

• 物流贸易：customs-trade-compliance, logistics-exception-management, carrier-relationship-management, returns-reverse-logistics, inventory-demand-planning
• 医疗：healthcare-emr-patterns, healthcare-cdss-patterns, healthcare-phi-compliance, hipaa-compliance
• 金融 / Web3：defi-amm-security, evm-token-decimals, prediction-market-*, llm-trading-agent-security, finance-billing-ops
• 科研：scientific-db-pubmed-database, scientific-db-uspto-database, scientific-thinking-literature-review

网络 / 运维 / Homelab

cisco-ios-patterns, network-bgp-diagnostics, network-config-validation, netmiko-ssh-automation, homelab-*（VLAN / WireGuard / Pi-hole / DNS 等）

内容 / 营销 / 设计

article-writing, brand-voice, content-engine, seo, marketing-campaign, market-research, design-system, liquid-glass-design, motion-*（动效系列）, manim-video, remotion-video-creation, investor-materials, investor-outreach

工具集成 / 平台

exa-search, fal-ai-media, videodb, x-api, google-workspace-ops, email-ops, messages-ops, nutrient-document-processing

小结

ECC 技能总数超过 200 个，核心思路是「命令型负责怎么做（工作流），知识型负责知道什么（领域模式）」。日常使用时只需记住几个高频命令型 skill（如 plan、feature-dev、code-review、save-session），领域知识型 skill 会在匹配任务时自动加载。

对当前这个 Nuxt 3 内容站点，最相关的知识型 skills 是 nuxt4-patterns、seo、frontend-a11y 与 frontend-patterns。

记录时间：2026-06-05 15:58:27

问题

我想用一个端到端的真实案例，把 Superpowers（以及 BMAD、ECC）的 Skills 串起来：假设要做一个包含 前端 Vue、移动端 Flutter、后端 Java 的项目，从立项一直到完整上线，每个阶段应该一步步 显式调用 哪些 Skill？最好有具体的提问和回答。

说明：下文所有 Skill 调用都用「显式调用」的方式呈现——即明确写出 /skill-name 或在对话里点名 Skill: xxx，并附上当时的提问（你说）与 Claude 的回答要点。示范项目代号 ReadTogether（读书打卡社区）：Java（Spring Boot）后端 + Vue3 管理后台/Web + Flutter 移动端。

这条链路刻意分成两段：阶段 0–12 是「开发生命周期」（想清楚 → 写出来），阶段 13–23 是「交付与运维生命周期」（验证 → 上线 → 守护 → 复盘）。很多人只做前半段，把「合并 PR」当成「上线」，这正是项目翻车的高发区。

---

阶段总览

---

阶段 0 — 立项：先想后做

你说： 我想做一个「读书打卡」社区 App，能记录读书进度、打卡、和朋友互相督促。但说实话需求还很模糊，先别写代码。

显式调用：

/superpowers:brainstorming

Claude 回答要点：

brainstorming 是「先想后做」的流程性 Skill，它不会直接给方案，而是一次问一个问题、逼你把假设挖出来。对话大致是这样推进的：

• 它问： 这个 App 的「一句话价值主张」是什么？谁会在什么场景下用它？
• 你答： 上班族通勤路上读电子书，想有轻量的打卡 + 好友监督，不想要又重又社交化的产品。
• 它问： 「监督」具体指什么？是好友能看到你的进度，还是有强提醒/惩罚机制？
• 你答： 第一版只要好友能看到彼此的打卡日历 + 评论鼓励就够了。
• 它问： 为什么需要原生移动端（Flutter）+ Web（Vue）两套？能不能先只做一端验证？

最终 brainstorming 帮我收敛出 MVP 边界：

• 核心闭环：登记书籍 → 每日打卡（页数/分钟）→ 好友动态流 → 评论。
• 移动端 Flutter 做用户主场景；Vue 先只做运营管理后台（书籍审核、用户管理、数据看板），不做 Web 端用户产品。
• 砍掉：积分商城、AI 荐书、付费会员——都进 backlog。

关键收获：brainstorming 的产出不是代码，而是一份「我们决定做什么 / 不做什么」的共识，这是后面所有阶段的输入。

---

阶段 1 — 市场：验证需求与竞品

你说： 在投入三端开发之前，先确认这个方向值不值得做——市场有多大、竞品怎么做、我们的差异点在哪。

显式调用：

/bmad-market-research

Claude 回答要点：

market-research 以分析师角色，结构化地帮你输出一份市场与竞品报告（落到 docs/market-research.md），避免「拍脑袋立项」：

• 市场规模与趋势： 读书类 / 习惯打卡类 App 的用户体量、增长曲线、付费意愿。

• 竞品矩阵： 微信读书、藏书馆、各类「habit tracker」——各自的核心卖点、定价、薄弱环节。

• 差异化定位： 我们的切口是「轻量 + 好友强督促」，而不是「内容平台」或「纯个人工具」。

• 风险信号： 社交督促类产品的留存高度依赖「好友密度」，冷启动是最大风险。

• 它问： 竞品已经很多了，你的「好友督促」凭什么留住用户？冷启动阶段没有好友密度怎么办？

• 你答： 第一版主打「小圈子共读」——3~5 人小组，靠真实关系链而非陌生人社交。把这条写进 PRD 的核心假设。

想更系统地做市场+用户调研，可改用 /ecc:market-research；要把调研结论转成对外材料，可接 /ecc:investor-materials。

---

阶段 2 — 需求：产出 PRD

你说： 共识有了，把它写成正式的产品需求文档（PRD），团队和后面的开发都要照着它做。

显式调用：

/bmad-create-prd

Claude 回答要点：

bmad-create-prd 会以 PM 的角色，结构化地引导你填出一份 PRD。它逐节追问并落盘成文件（通常是 docs/prd.md）：

# ReadTogether PRD
## 1. 背景与目标
## 2. 目标用户与画像
## 3. 用户故事（按优先级 P0/P1/P2）
   - P0: 作为用户，我能添加在读书籍并每日打卡
   - P0: 作为用户，我能看到好友的打卡动态并评论
   - P1: 作为运营，我能在后台审核违规内容
## 4. 功能需求（FR）/ 非功能需求（NFR）
## 5. 验收标准 / 指标（次日留存、人均打卡天数）
## 6. 范围之外（Out of Scope）

• 它问： P0 的验收标准是什么？比如「打卡」要不要支持补卡？
• 你答： 当天 24 点前可补当日，不能补历史。
• 它把这条写进 FR-03 的验收标准里，避免开发阶段口头约定丢失。

也可以用 /ecc:plan-prd 走 ECC 体系的 PRD 流程，二选一即可。BMAD 更偏「敏捷文档资产」，ECC 更偏「直接驱动后续 plan」。

---

阶段 3 — 架构：三端技术设计

你说： PRD 定了，现在设计技术架构。后端 Java，管理后台 Vue，移动端 Flutter，三端怎么分层、怎么通信？

显式调用：

/bmad-create-architecture

Claude 回答要点：

它读取 docs/prd.md，以 Architect 角色产出 docs/architecture.md，包含：

• 系统上下文图（C4 Level 1）：Flutter App / Vue Admin → API Gateway → Spring Boot 服务 → PostgreSQL + Redis。

• 技术选型表：

  层	选型	理由
  后端	Spring Boot 3 + JPA + PostgreSQL	团队熟悉、生态成熟
  缓存	Redis（动态流、计数）	好友动态读多写少
  移动端	Flutter + Riverpod	一套代码双平台
  后台	Vue3 + Nuxt + Pinia	团队已有 Nuxt 站点经验
  通信	REST + JWT，OpenAPI 契约先行	三端共享同一份 API 契约

• 关键决策记录（ADR）： 为什么 REST 不上 GraphQL；为什么动态流用「写扩散 + Redis ZSet」。

• 它问： 三端共用的 API 契约谁来定？建议 契约先行——先在后端用 OpenAPI/springdoc 定义接口，Flutter 和 Vue 据此生成客户端。

• 你答： 同意，把「OpenAPI 契约作为三端 single source of truth」写进架构约束。

想给关键决策留痕，可额外调用 /ecc:architecture-decision-records 把每个 ADR 单独落盘。

---

阶段 4 — 设计：UX 与交互

你说： 架构定了，但前端/移动端不能上来就写代码。先把核心界面的交互和视觉方向定下来，避免开发完再返工。

显式调用：

/bmad-ux
/ecc:frontend-design-direction

Claude 回答要点：

bmad-ux 以 UX 设计师角色梳理信息架构、用户流程与关键界面；frontend-design-direction 负责定「视觉方向」（排版、间距、色彩、质感），让产品看起来专业、不像 AI 默认样式。产出 docs/ux-spec.md：

• 关键用户流程： 注册 → 建/入共读小组 → 添加在读书籍 → 每日打卡 → 看好友动态 → 评论鼓励。

• 核心界面线框： 打卡页（一键打卡 + 进度环）、好友动态流、打卡日历、运营后台审核台。

• 设计方向： 安静克制的阅读感——大留白、衬线标题、低饱和强调色；用字重和留白区分层级，而不是大色块。

• 无障碍基线： 对比度、可点区域尺寸、动态字号支持。

• 它问： 「打卡」是 App 里最高频的动作，要不要做成首页一步可达、带即时正反馈（动效 + 连续天数）？

• 你答： 要。打卡按钮放首页中心，打卡成功有日历点亮 + streak 自增动效。这条直接影响阶段 11 的 Flutter 实现。

设计稿/HTML 已经有了、要直接转成代码时，前端可用 /ecc:ui-to-vue，移动端参照 /ecc:dart-flutter-patterns。无障碍要做深可上 /ecc:accessibility。

---

阶段 5 — 拆分：Epics 与 Stories

你说： 架构和设计都有了，把它拆成可执行的开发任务。

显式调用：

/bmad-create-epics-and-stories

Claude 回答要点：

它把 PRD + 架构 + UX 拆成 Epic → Story 层级，每个 Story 带验收标准，落到 docs/stories/：

Epic 1: 账号与好友体系
  Story 1.1 手机号注册/登录（后端 JWT）
  Story 1.2 加好友 / 好友列表
Epic 2: 打卡核心闭环
  Story 2.1 添加在读书籍（后端 + Flutter）
  Story 2.2 每日打卡（含当日补卡规则 FR-03）
  Story 2.3 好友动态流（Redis 写扩散）
Epic 3: 运营后台
  Story 3.1 内容审核列表（Vue）
  Story 3.2 数据看板（Vue + 图表）

• 它问： Story 2.3 涉及后端 + 移动端 + 可能的后台展示，要不要拆成「按端」的子任务？
• 你答： 拆。每个 Story 内部再分 后端 API、Flutter UI、联调 三步，方便并行。

单条 Story 临开发前可用 /bmad-create-story 细化成「开发就绪」状态（含技术上下文、文件清单）。

---

阶段 6 — 隔离环境：开工作分支

你说： 准备开发 Epic 2（打卡闭环），别污染主分支。

显式调用：

/superpowers:using-git-worktrees

Claude 回答要点：

using-git-worktrees 建议为这个 Epic 起一个独立 worktree，让三端代码改动隔离、可随时丢弃：

git worktree add ../readtogether-epic2 -b feat/epic2-checkin
cd ../readtogether-epic2

这样后端、Flutter、Vue 的改动都在 feat/epic2-checkin 分支里，主分支保持干净，多任务并行时互不干扰。

---

阶段 7 — 写实现计划

你说： 先别写代码，把 Story 2.2「每日打卡」的实现步骤写成一份计划，我 review 后再执行。

显式调用：

/superpowers:writing-plans

Claude 回答要点：

writing-plans 产出一份给「失忆的工程师」也能照做的计划：每步都有明确动作、验证方式、完成标志。docs/plans/story-2.2-checkin.md 大致是：

## Story 2.2 每日打卡 — 实现计划
### 数据库
0. 迁移：新增 checkin 表（user_id, book_id, pages, checkin_date, tz_offset）
### 后端（Spring Boot）
1. 写测试：CheckinServiceTest — 当日首次打卡成功
2. 写测试：当日补卡（24点前）成功；补历史日期 → 抛 BizException
3. 实现 CheckinService 使之通过
4. 暴露 POST /api/checkins，更新 OpenAPI 契约
### Flutter
5. 据更新后的 OpenAPI 重新生成 api client
6. 打卡按钮 → 调用 → 乐观更新本地状态
### 联调
7. 起后端 + 模拟器，跑通真实链路；验证补卡边界
### 验证标准
- 后端测试全绿；补历史日期返回 422；模拟器能看到打卡日历点亮

• 它问： 「当日」是按服务器时区还是用户本地时区？这会影响补卡边界测试。
• 你答： 按用户本地时区，请求带 tzOffset，测试要覆盖跨时区 case。计划据此补了一条测试项。

计划写好后，正式执行时可调用 /superpowers:executing-plans，它会逐条勾选、不允许跳步。

---

阶段 8 — 建模：数据库迁移

你说： 后端逻辑要落到 PostgreSQL，先把打卡相关的表结构用迁移管起来，别手改库。

显式调用：

/ecc:database-migrations

Claude 回答要点：

database-migrations 强调 schema 变更必须版本化、可前进可回滚，而不是在数据库里手动改表。它用 Flyway/Liquibase 风格生成迁移脚本（src/main/resources/db/migration/）：

-- V3__create_checkin.sql
CREATE TABLE checkin (
    id            BIGSERIAL PRIMARY KEY,
    user_id       BIGINT      NOT NULL REFERENCES app_user(id),
    book_id       BIGINT      NOT NULL REFERENCES book(id),
    pages         INT         NOT NULL,
    checkin_date  DATE        NOT NULL,        -- 用户本地日期
    tz_offset_min INT         NOT NULL,        -- 本地 - UTC，分钟
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);
-- 同一用户同一天只能有一条，支撑「补卡」幂等
CREATE UNIQUE INDEX uq_checkin_user_date ON checkin(user_id, checkin_date);
-- 动态流按时间倒序读
CREATE INDEX idx_checkin_user_created ON checkin(user_id, created_at DESC);

• 它问： checkin_date 用 DATE 而不带时区，但你的补卡规则依赖「用户本地当日」——是否需要把 tz_offset 一起持久化，否则事后无法复算边界？
• 你答： 对，加 tz_offset_min 字段一起存。这条直接预防了阶段 15 那个时区 bug 的「数据层根因」。
• 它提醒： 上线迁移要可回滚——每个 Vx__up 都要有对应回滚思路，生产环境严禁 drop 列不留备份。

迁移与后端代码强相关，本阶段常常和阶段 9 交替进行：先加迁移 → 再写依赖该表的测试与实现。

---

阶段 9 — 后端 Java：测试驱动开发

你说： 表结构有了，开始写后端打卡逻辑，严格 TDD。

显式调用：

/superpowers:test-driven-development
/ecc:springboot-tdd

Claude 回答要点：

TDD Skill 强制 红 → 绿 → 重构，先写失败的测试，绝不先写实现。springboot-tdd / java-coding-standards 提供 Spring Boot 的测试与代码规范。

红（先写失败测试）：

@Test
void 当日补卡_24点前_应成功() {
    var cmd = new CheckinCommand(userId, bookId, 30, todayLocal);
    var result = checkinService.checkin(cmd);
    assertThat(result.status()).isEqualTo(CheckinStatus.DONE);
}

@Test
void 补历史日期_应抛业务异常() {
    var cmd = new CheckinCommand(userId, bookId, 30, yesterdayLocal);
    assertThatThrownBy(() -> checkinService.checkin(cmd))
        .isInstanceOf(BizException.class)
        .hasMessageContaining("CANNOT_BACKFILL");
}

跑测试 → 红（CheckinService 还不存在）。

绿（最小实现让测试通过）：

public CheckinResult checkin(CheckinCommand cmd) {
    if (!cmd.date().isEqual(LocalDate.now(cmd.zone()))) {
        throw new BizException("CANNOT_BACKFILL");
    }
    var entity = checkinRepo.save(Checkin.from(cmd));
    redisFeed.fanout(cmd.userId(), entity); // 写扩散到好友动态
    return CheckinResult.done(entity.getId());
}

跑测试 → 绿。重构 阶段再抽出时区计算、补充 OpenAPI 注解。

• 它问（TDD 纪律）： 你想直接加「连续打卡天数」字段，但当前没有对应失败测试——要不要先补测试？
• 你答： 对，先写 连续打卡天数_应正确累加() 测试，再实现。坚持不写没有测试覆盖的逻辑。

后端写完可调用 /ecc:springboot-verification 或 /ecc:java-review 做一次专项检查。

---

阶段 10 — 前端 Vue：管理后台

你说： 后端审核接口好了，做 Story 3.1 运营后台的「内容审核列表」。

显式调用：

/ecc:nuxt4-patterns
/frontend-design:frontend-design

Claude 回答要点：

nuxt4-patterns 给出本项目（Nuxt + Pinia）的目录约定与数据获取范式；frontend-design 负责把界面做得专业、不像 AI 默认样式。

<!-- pages/admin/moderation.vue -->
<script setup lang="ts">
const { data, refresh } = await useFetch('/api/admin/moderation', {
  query: { status: 'pending' },
})
async function approve(id: string) {
  await $fetch(`/api/admin/moderation/${id}/approve`, { method: 'POST' })
  await refresh()
}
</script>

• 它问（frontend-design）： 审核列表是高频操作界面，要不要支持键盘流（j/k 上下、a 通过、r 驳回）来提升运营效率？
• 你答： 要，加键盘快捷键 + 批量选择。frontend-design 据此给出无障碍焦点管理与视觉层级建议（用留白和字重而非大色块区分状态）。

如果是把一张设计稿/HTML 转成 Vue 组件，可改用 /ecc:ui-to-vue。

---

阶段 11 — 移动端 Flutter：用户主场景

你说： 做 Flutter 端的打卡页，调阶段 9 的后端接口。

显式调用：

/ecc:dart-flutter-patterns
/ecc:flutter-test

Claude 回答要点：

dart-flutter-patterns 给出 Riverpod 状态管理与项目结构约定；flutter-test 负责 widget/单元测试。坚持「契约先行」：后端 OpenAPI 更新后，重新生成 Dart api client，再写 UI。

// 打卡控制器（Riverpod）
class CheckinController extends AsyncNotifier<CheckinState> {
  Future<void> checkin(int pages) async {
    state = const AsyncLoading();
    state = await AsyncValue.guard(() async {
      final res = await ref.read(apiProvider).checkin(
        CheckinRequest(pages: pages, tzOffset: localTzOffset()),
      );
      return CheckinState.done(res.streak); // 乐观更新连续天数
    });
  }
}

对应 widget 测试：

testWidgets('点击打卡按钮后日历当日点亮', (tester) async {
  await tester.pumpWidget(makeApp(overrides: [fakeApi]));
  await tester.tap(find.byKey(const Key('checkin_btn')));
  await tester.pumpAndSettle();
  expect(find.byKey(Key('cell_today_active')), findsOneWidget);
});

• 它问： tzOffset 要和后端约定方向一致（你传的是「本地 - UTC」还是「UTC - 本地」？），否则跨时区补卡边界会差一天。
• 你答： 统一为分钟数 localToUtcMinutes，并在联调时用一个 UTC+14 的假数据专门验证边界。

编译/依赖报错时调用 /ecc:flutter-build；提交前用 /ecc:flutter-review 做 Dart 代码评审。

---

阶段 12 — 加速：三端并行开发

你说： 三端任务相互独立，能不能并行推进省时间？

显式调用：

/superpowers:dispatching-parallel-agents

Claude 回答要点：

当后端 API 契约已冻结、三端任务彼此无依赖时，dispatching-parallel-agents 可以把后端、Vue、Flutter 三块分派给独立 subagent 并行执行，每个 agent 在自己的 worktree 里干活，最后汇总。

• 它提醒（关键纪律）： 并行的前提是任务真正独立。如果 Flutter 依赖后端还没定的接口，就不能并行——会基于错误假设白干。所以必须等阶段 3 的 OpenAPI 契约确定后再 fan-out。
• 你答： 后端契约已定稿，三端按契约各自实现，联调阶段再合。

若任务是「一个主线 + 多个探索分支」，也可考虑 /superpowers:subagent-driven-development。

---

阶段 13 — 联调：端到端 E2E 测试

你说： 三端各自的单元/widget 测试都绿了，但真实链路（注册 → 加好友 → 打卡 → 好友看到动态）从没整条跑过。补 E2E。

显式调用：

/ecc:e2e-testing
/bmad-qa-generate-e2e-tests

Claude 回答要点：

单元测试只证明「每块零件没坏」，E2E 才证明「整机能跑」。e2e-testing 针对跨端真实链路设计用例，bmad-qa-generate-e2e-tests 据 PRD 的验收标准生成测试场景。落到 e2e/：

场景 1：打卡闭环（跨三端 + 真实后端）
  1. 用户 A、B 互为好友（API 准备）
  2. A 在 Flutter 端添加在读书籍并打卡 30 页
  3. 断言：后端 checkin 表新增一条；Redis 动态流写入
  4. B 刷新动态流 → 看到 A 的打卡卡片
  5. B 评论「加油」→ A 收到
场景 2：补卡边界
  - 当日 23:59 打卡成功；改系统时间到次日补「昨天」→ 返回 422
场景 3：运营后台
  - 违规内容出现在 Vue 审核列表 → approve → 列表移除、内容上线

• 它问： E2E 跑在哪个环境？用真实 PostgreSQL+Redis 还是容器化的一次性环境？建议用 docker-compose 起一套隔离依赖，避免污染开发库、也保证可重复。
• 你答： 用 docker-compose 起一次性 PG+Redis，CI 里每次全新拉起。这一步正好为阶段 20 的 CI 打了基础。
• 它发现： 场景 2 跨天补卡偶发失败——但不稳定复现。这条线索直接交给阶段 15 系统性定位。

纯前端/后台的浏览器侧验证可用 /ecc:browser-qa；要把 E2E 固化进流水线参见阶段 20。

---

阶段 14 — 压测：性能与负载

你说： 功能跑通了，但好友动态流是「写扩散 + Redis ZSet」，担心高峰打卡时扇出把后端压垮。上线前压一压。

显式调用：

/ecc:benchmark
/ecc:latency-critical-systems

Claude 回答要点：

benchmark 帮你建立可重复的压测基线，latency-critical-systems 针对热点路径给出优化与容量判断。重点压三条路径：打卡写入、动态流读取、写扩散扇出。

压测目标（晚高峰 21:00 打卡潮）：
  - 打卡 POST /api/checkins   : p99 < 200ms @ 500 RPS
  - 动态流 GET /api/feed      : p99 < 100ms @ 2000 RPS（读多）
  - 写扩散：一个大 V（2000 好友）打卡，扇出不能阻塞主请求
结果：
  - 读路径达标（Redis ZSet 命中率 98%）
  - 写扩散在大 V 场景把打卡接口拖到 p99 1.2s —— 不达标

• 它问： 大 V 写扩散同步执行会拖垮打卡接口——是否改成「打卡先返回、扇出异步化」（写 MQ / 后台任务），并对超大好友数走「读扩散」兜底？
• 你答： 改。扇出移到异步队列，打卡接口只管落库 + 入队；好友数 > 1000 的账号读时合并。压测复跑 → 打卡 p99 回到 120ms。
• 它提醒： 把这组压测脚本和阈值固化下来，作为阶段 21 监控告警的基线。

算法/单函数级的微基准可结合 /ecc:benchmark-optimization-loop 做迭代优化。

---

阶段 15 — 调试：定位联调 bug

你说： 联调发现：UTC+14 时区的用户，当日打卡偶尔被判成「补历史日期」而失败。别瞎改，系统性定位。

显式调用：

/superpowers:systematic-debugging

Claude 回答要点：

systematic-debugging 强制「先复现、先定位根因，再改」，禁止凭猜测打补丁：

1. 复现： 写一个 UTC+14、本地时间 00:30 的测试用例 → 稳定复现失败。
2. 定位： 后端用 LocalDate.now(cmd.zone())，但 cmd.zone() 其实是用服务器默认时区构造的——tzOffset 没真正传进去。根因是 DTO 映射漏了字段，不是逻辑算错。
3. 最小修复： 在 CheckinCommand 构造处正确注入 ZoneOffset.ofTotalSeconds(tzOffset*60)。
4. 回归： 阶段 9 的补卡测试 + 新增的 UTC+14 边界测试全绿。

• 它问： 这个 bug 在 Flutter 端有没有对称问题（本地也算了一次日期）？建议两端各加一个边界测试锁住。
• 你答： 加。两端测试都覆盖 UTC+14 / UTC-11 两个极端。

根因定位清楚后，这类「时区」陷阱值得用 /ecc:learn 沉淀成经验，避免复犯（见阶段 23）。

---

阶段 16 — 代码审查

你说： 三端都开发完了，提 PR 前先做一轮代码审查。

显式调用：

/superpowers:requesting-code-review
/ecc:code-review

Claude 回答要点：

requesting-code-review 会把改动整理成可评审的形态并触发审查；ecc:code-review 针对当前 diff 找正确性 bug 与可简化点。本轮发现：

• 后端： redisFeed.fanout 没做幂等，重复打卡可能给好友动态写两条 → 建议加去重 key。
• Flutter： 乐观更新失败后没回滚 streak 计数 → 状态会和服务端不一致。
• Vue： 审核列表 approve 后只 refresh()，并发审核同一条会重复请求 → 建议禁用按钮 + 乐观移除。

收到评审意见后，用对应的「接受评审」流程逐条处理：

/superpowers:receiving-code-review

• 它的纪律： 每条意见要么修，要么明确说明为什么不修，不能默默忽略。
• 你答： 三条全修，并各补一个测试锁住回归。

各端也有专项评审 Skill：后端 /ecc:springboot-verification、Flutter /ecc:flutter-review、前端可迁移 /ecc:react-review 的思路到 Vue。

---

阶段 17 — 安全：上线前的安全审查

你说： 这是个带注册登录、好友关系、用户内容的社交 App，上线前必须过一遍安全。

显式调用：

/ecc:security-review

Claude 回答要点：

security-review 以攻击者视角审一遍认证、授权、输入、敏感数据，重点盯「越权」和「注入」。本轮发现：

• 越权（最高危）： GET /api/users/{id}/checkins 只校验登录、没校验「是否为好友」→ 任意用户可拉取陌生人打卡记录。修：加好友关系校验。

• JWT： access token 有效期 7 天且无法吊销 → 改短时效 access + refresh，登出/改密可失效。

• 内容安全： 评论直出到 Vue 后台未转义 → 存储型 XSS 风险（运营点开就中招）。修：输出转义 + 审核侧 CSP。

• 越权 #2： 运营后台审核接口只靠前端隐藏按钮，后端未校验 admin 角色 → 加服务端鉴权。

• 它问： 打卡接口对 pages 没有上限校验——会不会被刷出「单日读 999999 页」污染排行榜/动态流？

• 你答： 加业务校验（单次 ≤ 合理上限）+ 频率限制。每条安全问题都补一个测试或集成用例锁住。

想要更系统的扫描可叠加 /ecc:security-scan；做漏洞赏金式深挖可用 /ecc:security-bounty-hunter。

---

阶段 18 — 验证：宣称「完成」之前

你说： 我觉得可以上线了。

显式调用：

/superpowers:verification-before-completion

Claude 回答要点：

verification-before-completion 不允许「我觉得好了」，要求用证据证明完成。它拉了一张清单逐项核对：

• 后端 ./mvnw test 全绿（贴输出）

• Flutter flutter test 全绿

• Vue npm run typecheck 通过

• E2E 三个场景全绿（阶段 13）

• 压测达标（打卡 p99 120ms，阶段 14）

• 安全四项已修并有用例（阶段 17）

• PRD 里 P0 的三条验收标准逐条对照 → 满足

• 阶段 15 的时区 bug 有回归测试覆盖

• ⚠️ 数据看板（Story 3.2）尚未实现 —— 属于 Epic 3，不在本次 Epic 2 范围

• 它指出： 别把「Epic 2 完成」说成「项目完成」。本次只交付打卡闭环，数据看板要单独走流程。

• 你答： 对，PR 标题限定为「Epic 2: 打卡闭环」，看板留到下个迭代。

---

阶段 19 — 合并：收尾与 PR

你说： 验证通过，提 PR 准备合并。

显式调用：

/superpowers:finishing-a-development-branch
/ecc:pr

Claude 回答要点：

finishing-a-development-branch 负责干净收尾：确认测试绿、commit 信息规范、清理 worktree、确认要不要删分支；ecc:pr 生成结构化的 PR（含变更摘要、测试说明、风险点）。

# 收尾检查（由 Skill 引导）
git status            # 工作区干净
./mvnw test && flutter test && npm run typecheck  # 三端全绿
# 生成 PR
gh pr create --base master --head feat/epic2-checkin \
  --title "Epic 2: 打卡闭环（后端+Flutter+Vue）"

PR 描述自动包含：

## 变更摘要
- 后端：打卡 API（当日补卡规则 + 时区修正）、Redis 异步写扩散动态流
- Flutter：打卡页 + 乐观更新 + 日历点亮
- Vue：运营后台内容审核列表
## 测试
- 后端 42 / Flutter 18 / Vue 类型检查 / E2E 3 场景 全绿
- 压测：打卡 p99 120ms @ 500 RPS
## 安全
- 修复好友越权、JWT 时效、存储型 XSS、后台鉴权
## 范围之外
- 数据看板（Story 3.2）下迭代交付

合并后，worktree 清理掉，主分支拿到一个经过测试、经过审查、经过验证的功能。但这还不是上线——代码进了主干，离用户用上还差部署。

---

阶段 20 — 部署：CI/CD 与发布

你说： 代码合进 master 了，现在真正发到生产环境——三端怎么构建、怎么发布？

显式调用：

/ecc:deployment-patterns
/ecc:docker-patterns

Claude 回答要点：

deployment-patterns 设计从「合并」到「生产」的流水线，docker-patterns 负责后端服务的容器化。三端的发布形态不同，分别处理：

# CI 流水线（合并到 master 触发）
后端 Spring Boot:
  - mvn test → 构建可运行 jar → 打 Docker 镜像 → 推镜像仓库
  - 跑数据库迁移（Flyway，先在 staging 验证回滚）
  - 部署到 staging → 自动 E2E（阶段 13）→ 人工放行 → 生产
Vue 运营后台:
  - npm run generate → 静态产物 → 部署到 Cloudflare Pages / Nginx
移动端 Flutter:
  - flutter build apk/ipa → 上传到内测渠道（蒲公英/TestFlight）→ 审核 → 商店
环境与密钥:
  - .env 不进仓库；生产密钥走 secrets 管理（JWT 密钥、DB 口令、Redis）
  - staging / prod 配置分离

• 它问： 数据库迁移和应用部署谁先谁后？如果新代码依赖新列，但迁移失败、应用已上 → 直接 500。建议「先迁移、向后兼容、再发应用」，且迁移要能独立回滚。
• 你答： 采用「扩展-收缩」式迁移：先加列（兼容旧代码）→ 发新代码 → 下个版本再清理旧列。绝不在一次发布里做破坏性变更。
• 它提醒： 移动端不能像后端一样「随时回滚」——用户装了旧版就回不去了。所以 App 必须保证「旧客户端 + 新后端」兼容，API 加字段而非改字段。

容器编排 / 自托管可参考 /ecc:uncloud；进程守护用 /ecc:pm2。

---

阶段 21 — 守护：监控与灰度回滚

你说： 发上线了，但我怎么知道它在生产上是不是真的好的？万一出问题怎么快速止损？

显式调用：

/ecc:canary-watch
/ecc:production-audit

Claude 回答要点：

「部署成功」不等于「上线成功」。canary-watch 做灰度发布 + 自动盯盘，production-audit 体检生产配置与可观测性缺口。

灰度发布：
  - 新版本先放给 5% 用户（或先发内测组）
  - 盯关键指标 10~30 分钟：错误率、打卡接口 p99、写扩散队列积压
  - 指标正常 → 逐步放量 25% → 50% → 100%
  - 任一指标越过阈值（阶段 14 的压测基线）→ 自动回滚 / 暂停放量
可观测性（production-audit 检查清单）：
  - [x] 日志：结构化、带 traceId，能从一次打卡串到写扩散
  - [x] 指标：打卡成功率、动态流延迟、Redis 命中率、队列深度
  - [x] 告警：打卡错误率 > 1%、p99 > 阈值、队列积压 → 通知
  - [ ] ⚠️ 缺少「冷启动留存」业务看板 —— 列入下迭代

• 它问： 回滚预案演练过吗？真出事时手忙脚乱地回滚，和提前演练过、一条命令回滚，差别是「5 分钟」还是「2 小时」。
• 你答： 在 staging 演练一次「发布 → 触发告警 → 一键回滚」全流程，并写进 runbook。
• 它指出： 灰度期发现写扩散队列在真实流量下偶有积压（压测没覆盖的长尾好友分布）——暂停放量、扩容消费者、确认消化后再继续。这正是灰度的价值：在 5% 暴露问题，而不是 100%。

单个发布后的持续盯盘可用 /ecc:canary-watch 起守护循环；要做长期成本/资源体检见 /ecc:production-audit。

---

阶段 22 — 文档：交付沉淀

你说： 功能上线、稳住了，把这次的接口、架构决策、运维手册补全，别让知识只留在脑子里。

显式调用：

/ecc:update-docs

Claude 回答要点：

update-docs 扫描本次改动，更新/补齐三类文档，让下一个人（包括三个月后的你）能接手：

• API 文档： OpenAPI 契约导出成可读文档，标注打卡/动态流/审核接口的鉴权要求与时区约定。

• 架构/决策： 把「写扩散改异步」「扩展-收缩式迁移」「JWT 短时效 + refresh」沉淀进 docs/architecture.md 的 ADR。

• 运维 runbook： 部署步骤、回滚命令、告警处置预案、关键指标看板入口。

• README： 三端本地启动方式、环境变量清单、docker-compose 起依赖。

• 它问： 时区约定（tzOffset 是「本地 - UTC」分钟数）这种「踩过坑的隐性约定」有没有写进文档？不写，下个迭代很可能再踩一次。

• 你答： 写进 API 文档的醒目位置，并附阶段 15 的 bug 作为反例。

想生成可视化的代码地图/导览，可用 /ecc:update-codemaps 或 /ecc:code-tour。

---

阶段 23 — 复盘：迭代回顾

你说： Epic 2 整条链路走完了，做个复盘，把经验固化下来，下个 Epic 少踩坑。

显式调用：

/bmad-retrospective
/ecc:learn

Claude 回答要点：

retrospective 引导团队回顾「做得好 / 做得不好 / 下次改什么」；ecc:learn 把具体的技术教训沉淀成可复用的经验（甚至生成 hook/规则防止复犯）。

## Epic 2 复盘
### 做得好
- 契约先行让三端真正并行（阶段 12），没出现「等接口」空转
- 灰度发布在 5% 拦下了写扩散积压（阶段 21），没酿成线上事故
### 做得不好
- 时区 bug 本可在阶段 8 建模时就预防（tz_offset 字段晚加了）
- 压测漏了「长尾好友分布」，灰度才暴露 → 压测场景要更贴近真实分布
### 下次改进
- 新功能涉及时间/日期 → 默认先列时区测试矩阵
- 压测数据要从生产采样，而非均匀假设

• ecc:learn 沉淀： 把「时区处理三件套」（存 tz_offset / 两端边界测试 / 文档醒目标注）固化成项目经验，下次涉及日期逻辑自动提醒。
• 你答： 采纳，并把「破坏性 DB 变更必须走扩展-收缩」也加进团队约定。

想把经验导出/复用到别的项目，可用 /ecc:instinct-export；要把复盘结论变成下个迭代的待办，回到阶段 5 重新拆 Story。

---

小结

把整条链路串起来，会发现它其实是两个生命周期的拼接：

• 开发生命周期（0–12）： 想清楚 → 设计 → 拆分 → 写出来。
• 交付与运维生命周期（13–23）： 联调 → 压测 → 审查 → 安全 → 验证 → 合并 → 部署 → 守护 → 文档 → 复盘。

很多人只做前半段，把「合并 PR」当「上线」，结果在没监控、没灰度、没安全审查的情况下裸奔。这套方法的价值，就是把后半段也变成有纪律、可复现的显式流程。

贯穿始终的设计哲学是四条：

1. 先想后做 — brainstorming / market-research / writing-plans 在写代码前敲定方向与方案。
2. 先测后写 — test-driven-development + 各端 *-tdd / *-test，逻辑一律先有失败测试再有实现。
3. 先验证后宣称完成 — systematic-debugging 不靠猜、verification-before-completion 不靠感觉、E2E / 压测 / 安全用证据说话。
4. 上线不是终点 — deployment-patterns 真正发布、canary-watch 灰度守护、retrospective + learn 把每次踩坑变成下次的护栏。

而 三端协作的关键抓手始终是「OpenAPI 契约先行」：架构阶段冻结契约，后端、Vue、Flutter 才能在 dispatching-parallel-agents 下真正并行，否则并行只会放大「基于错误假设白干」的风险。

显式调用每个 Skill 的好处是：流程可复现、纪律不被「就这一次先写代码 / 就这一次先不上监控」绕过——这正是这套方法相对「凭手感开发」的价值所在。

记录时间：2026-06-05

问题

在寻找类似 Superpowers 的、能覆盖「从项目开始 → 调研 → 产品 → 设计 → 开发」完整流程的 Claude Code 工具时，BMAD-METHOD 是其中最贴合「全流程」需求的一个。本文全面介绍 BMAD 是什么、如何安装、它提供哪些能力，以及该如何选用。

什么是 BMAD-METHOD

BMAD（Breakthrough Method for Agile AI-Driven Development，敏捷 AI 驱动开发的突破性方法）把 AI 从「一次性写代码的助手」变成一条结构化、可审计的工作流，模拟一个真实的产品团队。

它要解决的核心问题是「抽象但失控」：自然语言 prompt 加速了产出，却隐藏了意图、决策历史和约束，导致难以治理的黑盒代码。BMAD 用三件事来重建控制力：

• 角色化 Agent：把开发拆给一组专业「人格」(分析师、PM、架构师等)
• 强规划文档：每一步产出文档，喂给下一步
• 版本化治理：决策可追溯、可复盘

GitHub 约 37,000 stars，是仅次于 GitHub Spec Kit 的主流 spec-driven 框架。

核心工作流：PRD → 架构 → 开发

BMAD 最大的特点是一条专业 Agent 流水线，每个角色产出一个文档作为下一步的输入：

分析师(项目简报)→ PM(写 PRD)→ 架构师(系统设计)
→ UX(用户流程)→ Scrum Master(拆 Sprint 故事)
→ 开发(实现故事)→ QA(验收)→ 迭代(回到故事，进入下一 Sprint)

这种「先把所有必要文档建好并验证，再写第一行代码」的方式，确保每一步都有明确目的。

关键机制：文档分片(sharding)

传统 AI 编码工具会随项目变复杂而出现「上下文坍塌」—— 理解力逐渐下降，开发者不得不反复向 AI 重新解释需求，导致实现不一致、架构漂移。

BMAD 通过 epic sharding 解决：把规划阶段产出的完整 PRD 系统性地拆成聚焦的、自包含的开发单元，每个单元上下文独立，互不干扰。

新项目 vs 已有代码库

• Greenfield(新项目)：从高层想法一路走到成品
• Brownfield(已有代码库)：两种切入方式
  • Code-First：先分析现有代码，再规划改动
  • PRD-First：先定义想改什么，再映射到现有架构
  • 还提供 Flattener 工具，帮 AI 快速「吃透」现有代码库

安装步骤

前置要求

• Node.js 20+(安装时唯一强制要求)

基础交互安装

在项目目录下运行：

npx bmad-method install

按提示选择：

1. Installation Type → Complete installation (recommended)
2. IDE → Claude Code

一行非交互安装(CI/CD 或一键装)

npx bmad-method install --directory . --modules bmm --tools claude-code --yes

可用 --set <module>.<key>=<value> 覆盖任意配置，例如：

npx bmad-method install --yes --modules bmm --tools claude-code \
  --set bmm.project_knowledge=research --set bmm.user_skill_level=expert

装完生成的目录

常用补充命令

npx bmad-method install --list-tools   # 查看支持的所有工具
npx bmad-method@next install           # 最新预览版(更新频繁)
npx bmad-method install                # 再跑一次即可更新，不丢自定义

提示：匿名 GitHub API 每小时限 60 次，装多了报错时设置 GITHUB_TOKEN 环境变量可提到 5000 次/小时。

全部 Skill 一览(共 44 个)

装好后 BMAD 会在 Claude Code 中注册一批 skill，按生命周期分类如下。

角色 Agent（可切换的「人格」）

1. 调研 / 发现阶段

• bmad-market-research — 市场调研
• bmad-domain-research — 领域调研
• bmad-technical-research — 技术调研
• bmad-brainstorming — 头脑风暴
• bmad-advanced-elicitation — 深度需求挖掘
• bmad-investigate — 调查
• bmad-document-project — 给已有代码库做文档(brownfield 用)
• bmad-generate-project-context — 生成项目上下文

2. 产品 / 规划阶段

• bmad-product-brief — 产品简报
• bmad-create-prd / bmad-prd — 创建 PRD
• bmad-edit-prd — 编辑 PRD
• bmad-validate-prd — 校验 PRD
• bmad-prfaq — 亚马逊式 PR/FAQ
• bmad-spec — 规格

3. 设计阶段

• bmad-ux — UX 设计
• bmad-create-architecture — 架构设计

4. 拆解 / Sprint 计划

• bmad-create-epics-and-stories — 拆 Epic 和用户故事
• bmad-create-story — 创建单个故事
• bmad-sprint-planning — Sprint 规划
• bmad-shard-doc — 文档分片(把大 PRD 拆成小单元)
• bmad-index-docs — 文档索引

5. 开发阶段

• bmad-dev-story — 按故事开发
• bmad-quick-dev — 快速开发
• bmad-check-implementation-readiness — 检查是否可以开工
• bmad-checkpoint-preview — 检查点预览

6. 评审 / 质量阶段

• bmad-code-review — 代码评审
• bmad-review-adversarial-general — 对抗式评审
• bmad-review-edge-case-hunter — 边界情况猎手
• bmad-editorial-review-prose — 文字润色评审
• bmad-editorial-review-structure — 结构评审
• bmad-qa-generate-e2e-tests — 生成端到端测试

7. 迭代 / 管理

• bmad-sprint-status — Sprint 状态
• bmad-correct-course — 纠偏(中途调整方向)
• bmad-retrospective — 复盘
• bmad-customize — 自定义配置
• bmad-party-mode — 多 agent 协作模式

入口

• bmad-help — 从这里开始，它会告诉你当前该做什么、下一步是什么。也可以直接提问，例如「bmad-help 我刚做完架构，下一步干嘛？」

完整实战：从立项到上线再到维护

光看 skill 列表很难体会流程，下面用一个虚构但完整的项目走一遍：「晨间习惯打卡」Web App（用户每天打卡晨跑/冥想/读书，看连续天数和统计）。这是一个 greenfield（全新）项目。

心智模型：四个阶段 + 一个故事循环

BMAD 把工作分成四个带编号的阶段（外加随时可用的 anytime 工具），每个阶段有「必做（required，硬门槛）」和「选做」之分：

1-分析 → 2-规划 → 3-方案设计 → 4-实现(故事循环) →(上线)→ 维护(回到某个阶段重来)

贯穿全程的两条铁律

1. 每个 skill 都开一个全新的 context window 跑——这是 BMAD 避免「上下文坍塌」的关键，别在一个长对话里把所有阶段做完。
2. 每个阶段之间先调 bmad-help——它会读 _bmad-output/ 里已生成的产物，判断你走到哪、还差什么必做项，并直接提议下一步。下面每个阶段我都从它开始。

产物分两类落盘：规划类（PRD、架构、epics…）进 planning_artifacts，实现类（story、测试、复盘…）进 implementation_artifacts（即 _bmad-output/ 下对应目录）。

阶段 1 — 立项 / 分析（1-analysis）

目标：把「我想做个打卡 App」这句话，变成一份经得起推敲的产品简报。全是选做项，但 greenfield 强烈建议至少做简报。

实操示例：

（新开对话）→ bmad-help            # 它说：你在 1-analysis，建议先 BP/MR，最终产出 CB 简报
（新开对话）→ bmad-brainstorming   # 跑完，记录落到 planning_artifacts
（新开对话）→ bmad-product-brief   # 拿前面的调研当输入，产出 product-brief

决策点：CB（产品简报，已笃定概念时用）和 WB（PRFAQ，亚马逊式「working backwards」，想被狠狠质疑时用）二选一即可。

阶段 2 — 产品规划（2-planning）

打卡 App 有明显界面，所以 ⑥ 也要做：

（新开对话）→ bmad-prd     # 产出 prd.md（必做的第一个硬门槛）
（新开对话）→ bmad-ux      # 产出 UX 设计：打卡首页、连续天数视图、统计页

bmad-prd 是整条流水线第一个 required=true 的门槛。PRD 没定稿，后面架构和拆故事都会落空。

阶段 3 — 方案设计（3-solutioning）

这一阶段三步全是必做，且严格按顺序（后一步以前一步为前置）：

（新开对话）→ bmad-create-architecture        # 产出 architecture.md
（新开对话）→ bmad-create-epics-and-stories    # 产出 epics-and-stories
（新开对话）→ bmad-check-implementation-readiness  # 产出 readiness 报告——绿灯才动手写代码

这正是「先把所有文档建好并验证，再写第一行代码」的体现。IR 报告就是开工前的总检查。 如果 PRD/架构文档超过 ~500 行变得难管，用 SD（bmad-shard-doc）把它分片成自包含小单元——也就是前文说的 epic sharding，给开发阶段提供独立上下文。

阶段 4 — 实现（4-implementation，核心是「故事循环」）

先做一次 Sprint 规划，之后就是对每个故事重复一个固定循环。

先规划（必做一次）：

（新开对话）→ bmad-sprint-planning   # 产出 sprint 状态文件，排好所有故事的实现顺序

然后每个故事跑一遍「故事循环」：

CS 创建故事 → VS 校验故事 → DS 开发(写代码+测试) → CR 代码评审
   ├─ 评审有问题 → 回到 DS 修
   ├─ 评审通过 + Epic 还没完 → 下一个 CS
   └─ 评审通过 + Epic 完成 → ER 复盘

以「打卡核心」Epic 的第一个故事「用户能为今天打一次卡」为例：

（新开对话）→ bmad-create-story        # 取出该故事并补全上下文
（新开对话）→ bmad-create-story (VS)    # 校验：验收标准清楚吗？依赖齐了吗？
（新开对话）→ bmad-dev-story            # 写 Nuxt 组件 + composable + 测试
（新开对话）→ bmad-code-review          # 评审；不过则回 DS，过了进下一个 CS

随时可用的辅助：

• SS（bmad-sprint-status）——忘了进度时看一眼当前 sprint 走到哪、下一步该干嘛。
• CK（bmad-checkpoint-preview）——给某次 commit / 分支 / PR 做人类可读的变更走查，适合上线前的人工 review。
• IN（bmad-investigate）——开发中遇到诡异 bug，做证据分级的取证式调查。

上线（Launch）

BMAD 本身不负责部署（部署仍走你自己的 Nuxt npm run generate + Cloudflare/Vercel 那套），但它提供上线前的质量收口：

（新开对话）→ bmad-qa-generate-e2e-tests   # QA：补齐关键路径的 E2E 测试
（新开对话）→ bmad-checkpoint-preview       # CK：对准备上线的 PR 做最终人工走查
（新开对话）→ bmad-retrospective            # ER：Epic 收尾复盘，沉淀经验
→ 你自己的 CI/CD 部署

ER（复盘）在每个 Epic 结束时做最有价值：回顾完成的工作、教训，并决定进入下一个 Epic，或者——如果发现大方向出了问题——转去 CC 纠偏。

维护与迭代（上线后）

上线后代码库已经存在，这时项目从 greenfield 变成 brownfield（已有代码库），BMAD 有专门的切入工具：

典型的「加个新功能（比如『好友排行榜』）」迭代路径：

（新开对话）→ bmad-generate-project-context  # 先让 BMAD 理解现在的代码长什么样
（新开对话）→ bmad-help                       # 问它：我要加排行榜功能，从哪开始？
（新开对话）→ bmad-prd                        # 用编辑模式把新需求并入 PRD
（新开对话）→ bmad-create-epics-and-stories   # 为新功能补 Epic / 故事
（新开对话）→ bmad-sprint-planning            # 排新 sprint
   → 再走一遍 CS → VS → DS → CR 故事循环

小修小补不必每次都走完整流水线——单个 bug 修复或一次性小需求，QQ（Quick Dev）一步到位即可；只有当变更足够大、会动到产品/架构层面时，才值得回到 PRD 重新走流程。

一图流总览

立项  →  BP/MR/TR  →  CB 简报
规划  →  PRD(必)   →  CU UX
方案  →  CA 架构(必) → CE 故事(必) → IR 就绪检查(必)
实现  →  SP 规划(必) → [ CS → VS → DS → CR ]×N → QA → ER
上线  →  QA + CK 走查 → 你的 CI/CD
维护  →  GPC/DP 吃透代码 → CC 纠偏 / QQ 快速开发 → 回到对应阶段
        ↑ 每一步都开新 context、阶段间先问 bmad-help

与 Spec Kit、Superpowers 的对比

三者哲学一致：都反对「vibe coding」，用文档/规格当唯一事实来源。社区共识是「原型用 vibe code，生产代码用 spec-driven」。

小结

• BMAD 是「一整个产品团队装进盒子」，最适合需要完整流程(调研/PRD/架构/UX 都有专门角色)、且重视治理和可追溯的复杂项目。
• 安装只需一条 npx bmad-method install，选 Complete + Claude Code 即可。
• 不必记 44 个 skill 名，装完直接调用 bmad-help，让它带你走流程。
• 代价：这类 spec-driven 流程每个 feature 的 token 消耗比直接写代码高约 20–40%(每轮要读 spec/plan/tasks)。
• 对中小型项目(如内容驱动的静态站)而言 BMAD 可能偏重；想给单个具体功能走完整流程时，Spec Kit 或 Superpowers 往往已经够用。

记录时间：2026-06-05

本文翻译并整理自 Anthropic 博客 Lessons from building Claude Code: How we use skills，作者 Thariq Shihipar（Anthropic 技术团队成员，Claude Code 方向）。

概述

Skills 已经成为 Claude Code 中最常用的扩展方式之一。在 Anthropic 内部，我们大量使用 Skills，目前有数百个 Skill 处于活跃使用状态。本文分享我们在用 Skills 加速研发过程中积累的一些经验。

简单来说，Skill 是一组指令、脚本和资源的集合，agent 可以发现并使用它们，从而把事情做得更准确、更高效。

最大的误区：Skills 不是「一堆 markdown 文件」

关于 Skills，最常见的误解是认为它们「只是一些 markdown 文件」。

实际上，Skill 是文件夹，里面可以包含脚本、资源文件、数据等，agent 能够发现、浏览并操作这些内容。在 Claude Code 里，Skill 还有一系列配置选项，比如注册动态 hooks。一些最有效的 Skill，恰恰是充分利用了这些配置选项和文件夹结构。

换句话说：把整个文件系统当作一种**上下文工程（context engineering）和渐进式披露（progressive disclosure）**的手段。

九大类别框架

把内部所有 Skill 都整理一遍后，我们注意到它们大致聚成九个类别。最好的 Skill 都干净地落在某一个类别里；那些想做太多事情的 Skill 往往横跨多个类别，反而让 agent 困惑。

这不是一份权威清单，但它是一个有用的框架，可以帮你发现自己 Skill 库里的空白。

1. 库 / API 参考（Library & API Reference）

讲清楚如何正确使用某个库、CLI 或 SDK——既包括内部的库，也包括 Claude Code 有时处理不好的常见库。这类 Skill 通常会带一个参考代码片段文件夹，以及一份「坑点清单」帮 Claude 规避错误。

• billing-lib：你们内部计费库的边界情况、隐藏陷阱等
• internal-platform-cli：内部 CLI 封装的每一个子命令，附带何时使用的示例
• frontend-design：让 Claude 更好地适配你们的设计系统

2. 产品验证（Product Verification）

描述如何测试或验证代码是否正常工作，通常会搭配 Playwright、tmux 等外部工具来完成验证。验证类 Skill 对于确保 Claude 输出正确极其有用——值得让一名工程师花上一周时间，专门把验证 Skill 打磨到极致。技巧包括：让 Claude 录下它运行结果的视频，方便你看清它到底测了什么；或者在每一步对状态做程序化断言。

• signup-flow-driver：在无头浏览器里跑通 注册 → 邮箱验证 → 引导流程，每一步都有 hook 断言状态
• checkout-verifier：用 Stripe 测试卡驱动结账 UI
• tmux-cli-driver：用于需要 TTY 的交互式 CLI 测试

3. 数据获取与分析（Data Fetching & Analysis）

连接你们的数据栈和监控栈。这类 Skill 可能包含带凭证拉取数据的库、特定的 dashboard ID，以及常见工作流或取数方式的说明。

• funnel-query：「要看 注册 → 激活 → 付费，应该 join 哪些事件」
• cohort-compare：比较两个 cohort 的留存或转化，标记出有统计显著性的差异
• grafana：数据源 UID、集群名、「问题 → dashboard」的查找表

4. 业务流程与团队自动化（Business Process & Team Automation）

把重复的工作流自动化成一条命令。这类 Skill 的指令通常比较简单，但可能依赖其他 Skill 或 MCP。对它们来说，把以往执行结果保存到日志文件有助于模型保持一致，并能反思过往的执行。

• standup-post：聚合你的工单系统、GitHub 动态和此前的 Slack，输出格式化的站会汇报
• create-<ticket-system>-ticket：强制工单 schema，并执行创建后的后续流程
• weekly-recap：每周回顾

5. 脚手架与模板（Scaffolding & Templates）

为代码库中某类特定功能生成框架样板代码。可以把这类 Skill 与可组合的脚本结合起来。当你的脚手架带有「无法纯靠代码覆盖的自然语言需求」时，它们尤其有用。

• new-<framework>-workflow：按你们的约定脚手架出一个新 service / workflow / handler
• new-migration：你们的迁移文件模板，外加常见坑点
• create-app：预置好鉴权、日志、部署配置的新内部应用

6. 代码质量与评审（Code Quality & Review）

在组织内部强制代码质量、并帮助评审代码。这类 Skill 可以包含确定性的脚本或工具以求最大鲁棒性。你可能想把它们作为 hooks 自动运行，或放进 GitHub Action 里。

• adversarial-review：派出一个「全新视角」的 subagent 来批判代码，实现修复并迭代，直到剩下的只是吹毛求疵的小问题
• code-style：强制代码风格，尤其是 Claude 默认做不好的那些风格
• testing-practices：测试实践

7. CI/CD 与部署（CI/CD & Deployment）

帮你在代码库里拉取、推送和部署代码。这类 Skill 可能会引用其他 Skill 来收集数据。

• babysit-pr：盯着一个 PR → 重试不稳定的 CI → 解决合并冲突 → 开启自动合并
• deploy-<service>：构建 → 冒烟测试 → 逐步放量，出现回归时自动回滚
• cherry-pick-prod：隔离的 worktree → cherry-pick → 解冲突 → 按模板提 PR

8. 运行手册（Runbooks）

输入一个「症状」（比如一条 Slack 讨论串、一个告警、一段错误签名），走完一套多工具的排查流程，最后产出一份结构化报告。

• service-debugging：为你们流量最大的服务建立「症状 → 工具 → 查询模式」的映射
• oncall-runner：拉取告警 → 检查常见嫌疑点 → 格式化结论
• log-correlator：给定一个 request ID，从所有可能经手过它的系统里拉取匹配日志

9. 基础设施运维（Infrastructure Operations）

执行例行维护和运维流程——其中一些是破坏性操作，特别需要护栏（guardrails）。这类 Skill 让工程师在关键操作中更容易遵循最佳实践。

• resource-orphans：找到孤立的 pod / volume → 发到 Slack → 静默观察期 → 用户确认 → 级联清理
• dependency-management：你们组织的依赖审批流程
• cost-investigation：「为什么我们的存储 / 出口流量账单暴涨」，附带具体的 bucket 和查询模式

编写 Skill 的最佳实践

不要陈述显而易见的内容

Claude Code 已经很懂你的代码库，整体编码能力也不错，还自带很多默认观点。所以 Skill 的重点应该放在能把 Claude 推出默认思维定式之外的信息上。

frontend-design 就是个好例子：它由 Anthropic 的一名工程师与客户反复迭代打磨而成，专门提升 Claude 的设计品味，避开诸如 Inter 字体、紫色渐变这类「一眼 AI」的套路。

把 Gotchas（坑点）章节放在最高优先级

任何 Skill 里信号最强的内容就是 Gotchas 章节。它应该从 Claude 使用该 Skill 时反复踩的坑中积累出来——理想情况下，你会随时间不断更新 Skill，把新发现的坑都收进去。

利用文件系统做渐进式披露

Skill 是文件夹，不是单个 markdown 文件。把整个文件系统当作上下文工程和渐进式披露的工具：告诉 Claude 你的 Skill 里有哪些文件，它会在合适的时机去读。最简单的形式就是指向其他 markdown 文件，比如把详细的函数签名和用法示例拆到 references/api.md 里。

不要把 Claude 框死在轨道上

正因为 Skill 高度可复用，要小心指令写得过于具体。给 Claude 它需要的信息，同时留给它根据情境灵活调整的空间。

想清楚初始化设置

有些 Skill 需要用户提供初始化上下文。一个好做法是把这类设置信息存在 Skill 目录下的 config.json 里。如果配置还没设置好，agent 可以向用户询问；你可以指示 Claude 用 AskUserQuestion 工具来问结构化的多选题。

description 字段是写给模型看的

Claude Code 启动会话时，会把每个可用 Skill 及其 description 列成一份清单。Claude 正是扫描这份清单来判断「这个请求有没有对应的 Skill」。所以 description 不是内容摘要，而是「何时触发这个 Skill」的描述。请为模型而写。

进阶技巧

记忆与数据存储

有些 Skill 可以通过在内部存储数据来实现某种「记忆」——简单到一个 append-only 的文本日志或 JSON 文件，复杂到一个 SQLite 数据库都可以。

例如 standup-post 可以维护一份 standups.log，记录它写过的每一条汇报；下次运行时，Claude 读取自己的历史，就能判断相比昨天有哪些变化。

注意： 存在 Skill 目录里的数据在你升级该 Skill 时可能被删除。所以应使用 ${CLAUDE_PLUGIN_DATA}——这是每个插件专属的稳定目录——来存放数据。

按需触发的 Hooks

Skill 可以携带 hooks，这些 hooks 仅在该 Skill 被调用时激活，并在本次会话期间持续生效。这对于那些「不想一直跑、但偶尔极其有用」的较强约束性 hook 很合适。

例如 /careful 通过对 Bash 的 PreToolUse matcher，拦截 rm -rf、DROP TABLE、强制推送（force-push）和 kubectl delete。

如何分享 Skill：去中心化的市场

在 Anthropic，没有一个中心化的团队来决定哪些 Skill 进入市场；我们让最有用的 Skill 自然地涌现。

如果有人想让大家试用某个 Skill，可以把它上传到 GitHub 的一个沙盒文件夹，并在 Slack 里把链接发出去。等这个 Skill 获得一定关注度后，再提一个 PR 把它移进正式市场。

小结

这篇文章的核心可以浓缩为几点：

1. Skill 是文件夹，不是 markdown——把文件系统当作上下文工程的手段。
2. 九大类别框架（库参考、产品验证、数据分析、流程自动化、脚手架、代码评审、CI/CD、运行手册、基础设施运维）可以用来盘点你 Skill 库的空白；好 Skill 只做一类事。
3. 写作要点：别说废话、把 Gotchas 放第一位、用渐进式披露、别框死 Claude、description 是写给模型的触发条件。
4. 进阶：用文件实现记忆、用按需 hooks 加护栏。

Anthropic 还发布了 Skill Creator，让在 Claude Code 里创建 Skill 更加简单。

记录时间：2026-06-05

问题

ECC（Everything Claude Code）是什么、怎么安装和使用？它提供的 skills、agents、hooks、命令分别是干什么的？能否给出一个从需求规划到提交 PR 的完整实战用例，把这些能力串起来？

ECC 是什么

ECC 自我定位是「a harness-native operator system for agentic work」——一套面向 AI agent 的操作系统，而不只是一堆配置文件。它把作者 10 个多月每天用 AI 写真实产品的工作流，沉淀成可复用的 skills、agents、hooks、rules、MCP 配置和遗留命令 shim。

关键特征：

• 跨 harness：同一套能力可在 Claude Code、Codex、Cursor、OpenCode、Gemini、Zed、GitHub Copilot 等多种 agent 宿主里使用。
• 能力规模大：当前 OSS 版本约 251 个 skills、63 个 agents、79 个遗留命令 shim，外加一批 hooks 和 MCP server。
• MIT 开源：仓库永久免费；另有付费的 ECC Pro（托管 GitHub App，处理私有仓库）和赞助渠道供养护项目。

三个公开标识符不可互换：GitHub 源仓库是 affaan-m/ECC，Claude 插件标识是 ecc@ecc，npm 包是 ecc-universal。

安装

推荐：插件方式（2 分钟）

# 1. 添加 marketplace
/plugin marketplace add https://github.com/affaan-m/ECC

# 2. 安装插件
/plugin install ecc@ecc

# 3. 重载使其生效
/reload-plugins

安装后会看到类似 Reloaded: ... skills · ... agents · ... hooks · ... MCP servers 的提示，说明各能力面已加载。

重要原则：不要叠加安装方式

最常见的故障是先 /plugin install、又跑 install.sh --profile full（或 npx ecc-install --profile full），会把同样的 skills/hooks 复制进用户目录，造成重复。插件路径下只手动拷你需要的 rules/ 目录即可：

git clone https://github.com/affaan-m/ECC.git && cd ECC
mkdir -p ~/.claude/rules/ecc
cp -R rules/common ~/.claude/rules/ecc/        # 通用规则，建议必装
cp -R rules/typescript ~/.claude/rules/ecc/    # 再按需加一个语言包

低上下文 / 不要 hooks

如果觉得 hooks 太「全局」，用最小手动 profile（不含 hooks-runtime）：

./install.sh --profile minimal --target claude

不确定装哪个？问内置顾问

npx ecc consult "security reviews" --target claude

它会返回匹配的组件、相关 profile 以及预览/安装命令。

五大能力面

其中 skills 是规范的工作流入口，命令 shim 只是迁移期的兼容层；新工作流优先以 skill 形式落地。

Hooks 是什么感觉

Hooks 会在你操作时主动拦截。例如 ECC 的 GateGuard 会在本会话第一次跑 Bash 前要求你先声明「这条命令验证/产出什么」（fact-forcing gate），逼你把意图讲清楚再执行。可用 ECC_GATEGUARD=off 或 ECC_DISABLED_HOOKS 临时关闭。

常用命令速查

/ecc-guide 本身是一张「能力地图」：无参数给菜单，/ecc-guide skills 看 skills 概览，/ecc-guide find: oauth 跨 skills/commands/agents/rules 搜索。

完整实战用例：给本站加一个「笔记标签」功能

下面把 ECC 的能力面串成一条从零到 PR 的开发流程，以本 Nuxt 内容站为例。

第 0 步：熟悉项目

/project-init

让 ECC 做 stack 感知的 onboarding，识别出这是 Nuxt 3 + Vue 3 + Markdown 内容站，把约定（content collections、file-based routing）摸清楚，避免后续乱改。

第 1 步：规划

/ecc:plan "给 notes 集合加 tags 字段，并新增 /tags/[tag] 标签聚合页"

planner agent 会产出实现蓝图：要改 content.config.ts 的 Zod schema、加 frontmatter 字段、写 app/pages/tags/[tag].vue、用 queryCollection() 过滤、补 sitemap。先看蓝图、确认方向，再动手。

第 2 步：测试先行

tdd-workflow skill

tdd-guide 强制「先写失败测试（RED）→ 最小实现（GREEN）→ 重构（IMPROVE）→ 验证覆盖率」。哪怕本项目没有现成测试框架，这一步也会先把「标签过滤应返回哪些笔记」的预期固化下来。

第 3 步：实现

按蓝图改 schema、页面、查询逻辑。期间若构建报错：

/build-fix

build-error-resolver 用最小 diff 把 TypeScript / 构建错误修绿，不做架构性改动。

第 4 步：自审与安全

/code-review
/security-scan

code-reviewer 检查正确性、复用与简化空间；security-reviewer 扫注入、SSRF、密钥泄漏等。内容站重点关注 Markdown 渲染与动态路由是否引入 XSS。

第 5 步：文档与提交

/update-docs
/pr

doc-updater 同步 README / 文档，/pr 整理出规范的 PR 标题与描述。

这条链路的核心顺序：先想（plan）→ 先测（tdd）→ 再写 → 后审（review/security）→ 才提（pr），与 ECC 的设计哲学一致——把意图前置、把验证前置，而不是写完再补。

小结

ECC 不是单纯的配置集合，而是一套把「真实 agent 开发工作流」产品化的操作系统：用 skills 承载工作流、agents 承载专职角色、hooks/rules 承载护栏、MCP 承载外接能力。

实用建议：

• 用插件方式安装，不要再叠加 full 安装，rules 按需手动拷。
• 不确定用什么就 /ecc-guide find: 或 npx ecc consult。
• 真正干活时，让 /ecc:plan → tdd-workflow → /code-review → /security-scan → /pr 这条链路替你把流程跑顺。