2026-07-03 20:57:08
在Superpowers 为什么能执行长任务且确保交付质量？一文中我解释过superpowers这套skills的原理，我也用了一段时间。
这套skills的设计是希望用一套强制的流程规范整个软件工程的迭代过程。由于用了hooks，用户不需要是一位资深软件工程师，也能被动地“自动”调用各个阶段所需的skill，强行帮你完成一次从brainstorming到利用subagents + worktree实现的过程。
这套skills非常好，也很适合不太熟悉软件工程流程的人。用这套skills写出来的plan甚至可以派发给一些更便宜的coding agents
After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow. It emphasizes true red/green TDD, YAGNI (You Aren't Gonna Need It), and DRY.但这也是superpowers的缺点: 强制，且费token。
上次我提到@Clu 给我推荐了mattpocock/skills这个skills。我也开始用了。但是有一段时间我是两套skills同时用。
一开始我发现superpowers能自己独立运行1hr以上我很开心，但后来我发现它也很容易把简单问题复杂化，所以我首先做的事情是，让我的coding agent把superpowers的hooks全部删掉。这样除非我手动调用，否则coding agent不应该随便启动superpowers的流程。
这样我结合mattpocock的/grill-with-docs和superpowers一起用。我感觉mattpocock的问答比superpowers的brainstorming更省token，效果也不差。当然后者的visual companion能提供一些demo效果我觉得也是一种很好跟Agent对齐视觉和交互效果的方式，但就是太费token了。在Fable 5回归以后我根本用不上了。
所以如果有复杂的视觉交互效果需要agent提前沟通对齐的，那么我们可以用/prototype先快速实现一个简单的原型，近似替代一下。这个原型是用于测试新idea的，不合适可以throwaway。
Mattpocock的这套skills在两周前实现v1.0.0，还改了其中一些skills的命名，增加了ask-matt，可以在初次安装后调用这个skill，他会告诉你典型的场景应该如何使用这套skill。
使用这套skills的基本流程和superpowers其实是类型的:
superpowers:
brainstroming => write-spec => write-plans => execute-plan
mattpocock skills:
grill-with-docs => to-prd => to-issues => implement上述是基本流程，但实际使用过程中还有些不同的变数。
我的个人项目在github所以使用GitHub issues作为issue tracker，prd和issues都放在上面。好处是可以用Fable 5这种很贵的高智商模型来写PRD，然后交给codex 5.5这种靠谱的顶流模型去写代码。并且因为东西都记录下来了，我就不会忘记上次跟Agent做了什么，做到哪一步了。
使用mattpocock的这套skills，能够把什么时候应该调用什么skill这个决策权交回到我手上。毕竟他说这是 Skills For Real Engineers。
Matt在repo中写到，这套Skills存在的原因是:
/grill-with-docs跟Agent进行问答让Agent真正理解我们要的东西。/grill-with-docs，Agent会自己把一些术语和当前项目转述的东西记录下来，以便未来查询，实现我们跟Agent之间的高效沟通。/tdd，并且配套debug skill /diagnosing-bugs
/to-prd也会在动手之前确认哪些模块应该被动到。但即使再小心翼翼，项目开发久了之后还是难免一团浆糊，这时候/improve-codebase-architecture就很适合项目重构。不仅会产出详细的报告文档，还会给出一个html展示可视化图表。这套skills严格区分了user-invoked和model-invoked，像主流程的skills都是主动调用的，而查bug和code review那些可以自动调用。
另外/handoff也很好用，有时候claude和codex互换的时候我就用/handoff转交过去，诸如此类。
所以最近我已经用mattpocock这套skills替代superpowers了，节省token而且省时间，又能实现不错的效果，还能在github issues上留档拯救我这被太多个项目折磨的记忆。
现在AI圈很喜欢造词，前有harness现有loop engineer。但无论是造的什么词，都离不开基座大模型的能力增强，以及我们在工程实现上如何约束大模型的走向。在工程约束实践和大模型能力还不太强的情况下，我们强调harness，也就是如何让大模型按照我们想要的方向走，别跑偏。在harness工程逐步发展，大模型的能力越来越强，指令遵循更准确以后，我们开始强调长任务的稳定交付，也就转向了loop engineering。
今年已经过去半年，AI的发展之迅速仿佛已经更替了好几代。短剧领域的全自动流水线印钞机模式应该已经基本跑通，一些低成本复制山寨的链路也层出不穷。但是我们生产严肃产品的领域还有不少需要提升的地方，比如一直有人说Taste是Human in the loop中非常关键的部分，打磨产品仍然消耗不少时间。但随着Fable 5的发布，我开始看到了产品打磨阶段也能被提效的曙光。那么下一代软件将会变成什么样子呢？真是个令人期待的未来。
2026-07-03 16:57:05
北京时间2026年7月2日凌晨3:31，Anthropic在X上发了一条Tweet，正式解禁Fable 5模型。
主播们也是第一时间开始用，确实感觉智商和任务完成质量有不错提升，很适合用来讨论和写Spec。当时Fable 5刚发出的时候没有好好珍惜，现在很后悔。因为Fable 5给订阅用户只能用套餐额度的50%，消耗比Opus 4.8快，并且只能用到7月7日，这几天看来都不用睡了。
P.S.节目中提到的两个Skills
fyfyFM进群推荐使用苹果Podcast, 小宇宙等播客客户端搜索“枫言枫语”来订阅收听本节目。
2026-06-10 15:58:56
2026年的高考结束了。不晓得我们的听友里面有没有今年高考的呢？如果有的话，先恭喜你获得了一段特别长的假期。另外现在高考成绩还没出，所以我们也先预祝大家高考顺利，都能取得好成绩，考上自己理想的大学。
在本期节目中，两位主播聊了当年高考的填志愿的情况，以及AI时代的当下，高校教育与技术进步的Gap，以及我们该如何应对这个风云变幻的世界。
两位主播早已离开校园多年，当时的高考志愿填报技巧早已作不得数。但这个世界仍有些事情是不变的，比如保持好奇，比如追随自己内心的渴望。
无论是否今年高考的听友，希望你都能活出自己想要的人生。
Elon Musk那句话是: Life is too short to spend it doing something you don't like.
以及另一句: If you're creating something you love and think other people will love, it's much easier to sacrifice the time and effort. If it doesn't work out, you won't regret it.
Steve Jobs那句话其实是:"Don't waste your life" 来自乔布斯1974年抄写给朋友的一句诗，来自禅宗大师铃木俊隆。
这首诗完整如下:
Listen well everyone
Great is the problem of Life and Death
No forever gone gone
Awake awake each one
Don't waste your life!
本期节目我们受小宇宙高考特别企划邀请，欢迎大家点击👉给普通小孩的志愿填报指南👈收听更多节目。
fyfyFM进群推荐使用苹果Podcast, 小宇宙等播客客户端搜索“枫言枫语”来订阅收听本节目。
2026-06-10 03:08:55
WWDC26 已于北京时间 6 月 9 日凌晨 1 点顺利开幕，今年自力是去到了WWDC现场，给我们带来了Tim Cook在苹果担任CEO的最后一届WWDC的现场报道。
今年的发布会内容跟往届比起来显得不太“丰富”，一半是在讲重头戏Siri AI，那么这个迟到了几年的作业，及格了吗？让我们一起在节目里聊聊吧。
fyfyFM进群推荐使用苹果Podcast, 小宇宙等播客客户端搜索“枫言枫语”来订阅收听本节目。
2026-06-04 16:22:07
年初我在做自己的Agent时想到是否可以用Github issues的方式来写PRD和任务拆分，以此实现长任务的agent orchestration。当时我自己做着玩的agent架构跟OpenClaw相似，但是llm core以acp方式接入codex。
但是当时步子迈得太大，因为初衷是觉得我的$200 cc和$200 codex用不完太浪费，想在我睡觉前提个需求，我睡醒了他们就把任务完成。结果让agent写PRD和拆分子任务这一步还算顺利，最终派发subagent执行的时候出了问题没能解决。后来转去Vibe别的东西了就没再继续。
结果我最近一直在用的obra/superpowers在去年底就已经“解决”了这个问题，只是不是通过OpenClaw的方式来派发Subagents，而是作为Skills，在Claude Code/Codex等具备Subagent环境的Cli中直接执行。
这个Skill set可以非常好地满足让Agent执行一个大需求的场景，但是他不适用于小需求，会把事情变得更复杂。当然后者我们手搓/口喷就能让AI完成，所以我们可以更关注前者。
想要最终实现“睡前给AI一个任务，它跑一晚上执行，我早上起来验收”这个目标，非常核心的一点是，我们要确保足够详细地，明确地跟AI讲述清楚需求。
这点要靠人工手写prompt一次完成非常困难，Superpowers通过几个巧妙的设计帮助我们解决这个问题。
brainstorming跟人类反复确认好细节，甚至提供了Visual Companion用来编写一个粗糙的web demo跟人类视觉确认即将进行的方案设计。在这个过程中，一次只确认一个问题，visual comapnion可以提供多个可选项，YAGNI原则（尽可能简单只保留真正有用的部分），探索更多可行选项以供用户选择，增量确认（先给出初稿设计，再逐步确认细节），灵活性（如果出了大问题可以重新讨论重新开始）。这一步的产物是输出spec文档，跟AI聊好这一步就已经完成了人类的一大步。writing-plans。第一步我们把一个足够大的需求写成了Spec，接下来的Plans需要将其拆分成足够小的Tasks。这些Tasks是sub-projects，有明确的边界。每一步是2-5分钟的原子动作（写一个失败的测试用例/跑一遍确认失败/写一个最小实现/跑测试确认通过用例检查/提交代码），贯彻DRY/YAGNI/TDD/频繁Commit等原则（学会好多缩写黑话😂），同时禁止TODO/add appropriate error handling/similar to Task N等常见AI偷懒行为。并且最终Plan写完了需要self-review，确认Spec覆盖度/占位符扫描/一致性检查等等。这一步写出来的Plans质量很高。executing-plans，默认是保底的一个Session从头跑到尾（如果当前环境不支持Subagents），但是Claude Code/Codex Cli都支持Subagents，所以通常我们会选择subagent-driven-development。在执行的过程中，先读Plans，然后Review，然后开始执行，如果有卡住的时候就停下来问，不让AI自己猜。subagent-driven-development。他给每一个Task都创建一个新的Subagent，每个Subagent会有两个阶段的Review保证输出。这个Skill里还带有implementer-prompt.md spec-reviewer-prompt.md和code-quality-reviewer-prompt.md三个prompt，分别用于执行和Review。因为每个Subagent都只用自己的context所以不会撑爆主Session context，并且他们按照TDD实现，有一些任务甚至可以并行执行。同时Skill里还写了一堆Red Flags，不让AI跑偏，比如不要未经允许就在main/master开始写代码（正常一个大需求会开一个worktree来写，有另一个skill，不做赘述）；不要还没修完issues就跳过开始执行下一步；不要让Subagent去读Plan file，Subagent只需要被告知足够的context的就行，读Plan file是主Session的工作，等等等等，非常harness。如此superpowers就完成了一套核心的软件开发流水线:
brainstorming → writing-plans → executing-plans / subagent-driven-development前一步的输出是下一步的输入。Subagent不继承主Session的context，使得每个Subagent可以独立不受污染。同时明令禁止AI在执行任务时停下来问要不要继续，这是能持续跑1hr以上的关键。在质量保证方面，先严格Follow Spec，然后再做Code Quality Review，要先把事情做对了，再来考虑做得好不好。之前我在做我的Agent orchestration的时候，跑一个任务的时长能上去，但是超过20min之后任务的质量就断崖式下跌，就是没有严格Follow Spec，这点非常重要。
最近很流行Harness这个词，虽然没人能说清楚这个词究竟是啥意思。我觉得superpower的设计就是一种非常不错的Harness实践。
@RoCry前两天给我分享一个视频，Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI - YouTube，说里面提到一个观点: "What if the large language model is good enough?"
@RoCry觉得，如果LLM现在的实力像一个毕业生，基础能力和智商已经达标，那接下来如果想带他写代码，就只要交给他具体的编码规范和方法，只要他掌握了这些，就几乎所有的事情都能交给他去做了，我们只需要做好harness就好了。（大意如此，我做了修改）
我觉得很有道理。现在（2026年6月）的Frontier模型已经非常好了，Opus 4.8/4.7, Codex GPT-5.5已经能胜任大部分工作。我们目前遇到最棘手的问题是AI总是不听使唤，而Superpowers的Skill实践就是Harness的一种，通过前期明确清晰的沟通写出可置信的Spec/Plan，并以此作为判断的依据，从而让即使廉价的模型也能变得可靠，产出可用的结果。
在Superpowers的设计中，“Never/HARD-GATE/
前阵子和朋友聊，他觉得如果Harness做得足够好，我们完全可以用便宜的AI来实现必须LLM才能做的工作。当时我们在聊基于Agent的产品设计，还不是软件工程。我觉得很有启发，所以我也把我的Agent工具的基座模型从Gemini换成了DeepSeek。在产品上的Harness我是把所有可能可以用工程师实现的部分，全部使用工程实现，只留下文本理解，文本处理等需要LLM的部分才利用LLM API。而且现在DeepSeek v4 pro不仅实力有不错提升，价格还贼亲民，线上产品用更便宜的模型就是节省了一大笔成本，何乐而不为。
Superpowers只是同类Skill set中的一种，前两天 @Clu 给我推荐了mattpocock/skills这个skills，/grill-me。我还没去尝试，打算也试试看。
superpowers有他的局限，比如简单任务如果被AI判断要自动调用superpowers就会很浪费token和时间，把简单问题复杂化，所以使用的时候也要小心，判断好适用他的需求再给他。
2026-05-28 17:55:41
科技快乐星球46，本期新闻攒的有点久，很多已经是旧闻我们已经剔除了，只聊最近四五月的新闻。
本期封面来自日本摄影师杉本博司的作品《相模湾、江之浦》
fyfyFM进群推荐使用苹果Podcast, 小宇宙等播客客户端搜索“枫言枫语”来订阅收听本节目。
