matt/skills 最终结局会怎样呢?他的理念会被 Agent Harness 吸收,导致装机率逐渐减少
因为:类似 codex App(现在叫 chatGPT App)的迭代方向都是:把 coding Agent 作为底座,在上面增加办公场景的抽象层。下一个被加入的抽象层应该是「基于 issue 的流程 kanban」
那么 issue 从哪来呢?Plan Mode 就需要加入「从需求转issue 的 tooling」
那 issue 怎么分类呢?根据需求类型分类,比如:
- 需要与其他同事讨论的
- 需要自己做原型的
- 需要联网调研的
这些其实就对应 matt/skills 现在的一系列 skill
顯示更多
办公领域的 AI 工作流最理想的状态就是 chat 了,因为办公领域最大的瓶颈是「交流」
工种内的工作流最终会收敛到不同 tag 的 issue
chat 与 issue,一个管即时交流,一个任务管理
顯示更多
AI 编程 接下来的趋势是:需求对齐侧会越来越厚,需求实现侧会越来越薄
需求对齐侧:
从 /grill-me 拷问需求,到 /prototype 画需求原型,这些是“我自己该怎么对齐需求”
再到 /to-questionnaire 是“为了对齐需求,我需要采访别人什么问题”
再往下的发展,就是“更多工种(比如 设计、产品)参与其中,作为 需求对齐侧 的一个环节”
需求实现侧:
随着 Agent 长程执行能力、编码能力 越来越好,很多防御性的流程(比如 Spec 拆成 详细的 Plan)变得没必要
最终 需求实现 将退化成一个 /goal 命令
顯示更多
总结下 mattpocock/skills v1.2 更新背后的底层逻辑
除了一些实用功能(比如 文档、/wizard),更新主要集中在需求对齐侧,比如:
- /grilling 采用 BFS 的顺序按批次提问,而不是一次问一个
- /to-questionnaire 将 grilling 过程中“你不会回答的问题”转化为“供你和同事讨论的文档”
- /wait-what 将 Agent 的话用你的行业术语重新翻译下,方便你理解
背后的底层逻辑是:AI 编码能力不是瓶颈,真正的瓶颈在于需求对齐。
如果你疑惑“如果AI编程 不是瓶颈,为啥写出的代码还有 bug?”
因为需求没对齐,Agent 需要脑补需求,这就是偏差的源头
bug 不是因为“实现有问题”,而是“实现 和 需求 不一致”造成的
顯示更多
mattpocock/skills v1.2 is out!
We're now the 19th most-starred repo of all time. 13.5m downloads on skills.sh. Thanks for your support!
Here's what's new:
- Docs: the community's biggest ask. Every skill documented, with explanations of the main flows + troubleshooting
- Claude Plugin: install via Claude's official marketplace
- Codex Support: full Codex support via agents/openai.yaml files
Updated Skills:
- /grilling now asks you questions in rounds, not one-by-one
- /prototype now uses HTML instead of a TUI for building logic prototypes - easier to share and far richer
- /writing-for-agents renamed from /writing-great-skills, use it for ANYTHING your agents read (AGENTS.md, system prompts, docs)
New Skills:
- /wizard: tired of provisioning infra? Get your agent to build you a TUI to walk you through it
- /to-questionnaire: hit a grilling question you can't answer? Turn the session into a doc you can walk through on a call with a colleague
- /wait-what: no idea what the model said? Refocus it in your domain language and simplify with ASD-STE100
Full changelog + docs below. Video soon!
顯示更多
很多人放弃 Superpowers,问题的表象是:执行速度太慢。
但“速度慢”可以靠“并行开发”弥补。
最核心问题在 brainstorming 的设计上,为了减少上手门槛他会留下很多需求缺口没对齐,Agent 为了完成需求会自行脑补代码设计。
“脑补的代码设计 与 开发者实际需求”之间的偏差就是软件腐败的根源。这意味着长期使用 Superpowers 迭代的应用会更快腐败,更早需要重构
当然,其实大部分人的项目还没触及到腐败的点 就被砍了 🥴🥴🥴
顯示更多
关于 Code Review 一个有意思的点:
很多人以为 AI Review 的目的是“找出 bug 和代码质量问题”,这是从 人类Review 的视角来审视 AI Review
AI Review 更多是发掘出“你在对齐需求时没有讨论到的点”,这些点在实现阶段被放大为“bug、代码质量问题”等形态
顯示更多
用其他模型去对抗式review是最好的
1.codex原生就支持通过chatgpt-codex-connector[bot] 配置github项目级别的Review,可以发起PR就自动Review,完整没有任何comments之后才允许合入
2.以及本地coding-agent也有很多原生方案,比如codex-plugin-cc这个原生插件就可以用/codex:review命令来对claude的代码进行review
顯示更多
很多人诟病 Superpowers 执行太慢,纷纷倒戈 Mattpocock/skills
这一切的源头是 subagent-driven-development 这个 skill,新版 Superpowers 优化的主要也是他
很多人疑问:为啥不直接移除他,改成类似 Mattpocock 的 /implement 实现?
实在是做不到呀~~~
subagent-driven-development 存在的意义主要有 2 点:
1. 以前 agent 长程执行能力不行,需要详细计划,以防 compact 后执行锚点丢失
这一点当下已经不是问题。核心问题是下一条:
brainstorming 没法完全对齐需求,所以需要靠 writing-plans 补齐实现细节。问题是“你在真正写代码前,是没法脑补所有实现细节的”
所以执行时得靠 subagent-driven-development 的 review 流程保证实现细节落地。
根源在 brainstorming 这块就决定了。
Superpowers 要改,只能把 brainstorming 改成 grill-me
顯示更多
4类需求缺口:
1. 已知的已知
2. 未知的已知
3. 已知的未知
4. 未知的未知
grill-me 用来对齐 1 和 2,暴露 3 和 4。 用另一个 AI 就失去意义了。 即使 AI 给出的都是当下的最佳实践,但过度依赖 AI 完成 3 和 4 会加速项目腐败
顯示更多
做了一个有趣的实验,/grill-me (拷问我),如果这个“我”是AI 会怎么样?
也就是用A harness来拷贝我,B harness来代替人类回答问题。
herdr 真的是伟大的发明,天生支持Harness之间互相调用。
提示词:
1. /herdr 开右边pane,启动grok
2. read grill-me skill, understand it. 你扮演人类回答问题,在右侧使用/grill-me skill,我们的目标是clone
最后问了 16 个问题达成共识,形成文档,效果还不错。😂
当然我感觉可以改进下/grill-me skill,让subagent来回答。
顯示更多
agent wiki 不可替代的价值是啥?
wiki本身不是 Single Source of Truth,Agent 读了文档后执行过程中还是得核查事实
那如果只把“不容易变、项目中没法直接查到”的知识保存 wiki,其实这部分工作量并不大,改动频率也不高,定时手动维护即可
顯示更多
兜兜转转发现 飞书 是最合适的,啥都有。 没有的也高度定制化
我也是一向喜欢一把梭 把 数据监控, kanban,CRM,站内信,邮件工具, 文档页 全部自己 vibe。但是今天把内部任务看板整个迁去 Linear 之后,觉得项目管理工具确实还是有相当复杂度的。。。
好在因为之前自己一把梭,所有历史数据都在,所以我可以很方便的用 linear 的 MCP 几分钟内 backfill 几百个任务。
顺便想清楚一个问题:拿 Linear(或任何任务工具)当 CRM 用,是不是坏主意?
结论:当客户关系的「记录系统」,是;只放从 deal 派生出来的任务,不是。
根本原因是生命周期对不上。Issue 的宿命是走到 Done;deal 是长周期关系——会冷、会回温、会复购,永远没有「完成」。「跟进某客户」一旦建成卡,结局就是在 In Progress 里烂着。
这些做不完的卡还有个副作用:把团队的在途负载读数搞失真。迁移时做了一轮容量分析:在途最重的同事,虚高来源几乎全是客户跟进卡——挂了两周、零完成。不是人不行,是把「关系」错建模成了「任务」。
合理的分工:
· CRM 做记录系统:阶段、金额、往来记录、联系人
· 任务工具只放「本周期内有明确交付物、能勾掉」的派生任务,卡里带回链
一客户一卡、常驻的「跟进 XX」卡,都是反模式。
两套系统必然有 gap,所以我们在中间加了一层 context layer:以上次同步的快照做三方合并基准,单边变更自动搬运,双边冲突不自动裁决、进报告人工定。
工具可以随时换,上下文不能断。
顯示更多
AI软件开发 的未来在「issue + 基于 Agent 的 issue分拣」
通过 issue 再链接各个工种的工作流
AI 编程 的核心目标:让软件长期保持较高的迭代效率
手段主要有 2 个:
1. 提高开发效率,但开发效率提高 200% 整体迭代效率可能只提高 30%
2. 抹平工种之间的沟通瓶颈,这才是最大的效率瓶颈
顯示更多
很多人将这篇文章解读为“AI Coding 以后不需要 mattpocock/skills 、 superpowers 这样的 Skill框架”
事实是,这类框架会一直存在,只不过随着 Agent 发展不断新老更替罢了
比如 superpowers 出现的时候 Agent 还没有 /goal 这样的长程执行能力,当下很多人抛弃 superpowers 转投 matt skills,也是因为 Agent Harness 本身在进步
但这类框架永远不会消失,举个很小的例子:Agent Harness 会内置“先对齐需求再实现”的流程。
但对于“如何对齐需求”,是采用 grill-me 这样的 BFS ?还是 brainstorming 这样的只对齐模糊的方向? 亦或其他对齐路径,这都是场景相关的
Agent 没法内置
顯示更多
We removed ~80% of the Claude Code system prompt for our newest models, this is what we've learned about writing system prompts, skills and Claude.MDs for them.
在小红书上看到设计师们讨论“Figma 2 Code 怎么弄效果最好”
都上 AI 了,就别困在一亩三分地了,直接用 tailwind 验收设计系统,用 storybook 验收 组件、布局 ,留着 Figma 这个中间环节干嘛
顯示更多
发现个有趣的对比,
@dontbesilent 和
@mattpocockuk 都在各自领域推广自己的 Skill 体系
Matt 的 Skill 爆火的支点是「grill-me 这种模式的提出和推广」,后续 Skill 都是在这个支点基础上的延伸
DBS 的 Skill 体系 中也有个潜在的爆火支点 —— 找对标
顯示更多
现在渐渐发现大家都是相似的“创业”路径
做生意第一天想找个对标,从哪开始找呢?就从自己现有的“资产”开始找
我做过房产,我就看看有没有房产自媒体 IP
我卖 AI 账号,我就看看别人是怎么宣传的
找了一圈发现都跟自己不一样,于是放弃了对标
【核心 1:对标是我模仿别人,不是别人模仿我】
找不到对标之后,就开始东抄一点西抄一点,看看有没有遇到什么阻碍,什么负反馈。凭直觉和 AI 聊聊,修正一下
然后就开始搞流量。大概率也搞不到什么流量,但偶尔火一条又能有一堆咨询的
咨询之后卖啥呢?随便找个看起来做的比较好的人抄一下
抄完了之后发现不对劲。要么发现人家卖那个东西不赚钱,是个引流款。要么发现人那个产品只是看起来简单,实际上很复杂
【核心 2:产品和流量必须匹配,产品抄 A、流量抄 B,基本没戏】
这时候想起来,可能还是要找个对标,自己探索不是个正事。可是账号已经做起来了,这时候想改就更难了
难道要放弃一切重新起个账号吗?
想想也很难下这个决心。食之无味,弃之可惜
【核心 3:沉没成本,不是成本】
这时候觉得创业真难呀。要不然还是看看“成功人士”怎么做的吧。对标谢胜子、对标曲曲
可是我问:为啥谢胜子的短视频不是 9:16 的比例?
答:不知道
我问:曲曲被封脸之后,主要是怎么搞流量的?谁负责生产内容?谁负责分发内容?不同的平台分别有多少账号?不同平台的账号流量表现如何?运营账号的人拿的是工资还是佣金?
答:不知道
这时候发现这么耗下去也不是个事,还是先动起来吧。先搞流量,先发爆款
然后就开始发:
- 使用 codex 的 100 个技巧
- 身弱高敏感女生如何赚到第一个 100w
- ……
空有流量不变现
此时心灰意冷。走在大街上,感觉 38 度的热风都带着刺骨的寒冷。这时突然在地上看见一本书
书名写着:《不问五诀》
作者还是英文名,叫 dontbesilent
书里写到:
找对标的五个标准
1、他赚钱(利润是你预期的 10 倍)
2、你能看懂
3、你能模仿
4、不讨论现有业务、现有资源、成长经历、个人偏好、个人优劣势、兴趣爱好
5、不讨论这个业务是什么,能干就执行,不能干就换下一个
顯示更多
模型上下文限制对很多人来说是种保护, 当你对齐需求阶段都经历了 compact,很难说你知道最终实现出来是个啥
打工人想在公司搞 AI 需要了解的 2 点:
1. 怎么做?
做自己想做的 AI -> 别人不用 -> 推不动
帮别人做他想做的AI -> 符合他人利益,推得动
2. 为啥做?
错误:为了保住这家公司的饭碗
正确:为了简历好看,跳槽驱动决策
顯示更多
今天学员群讨论面试被问到“如何 100% 还原UI”该怎么答
我的建议是:不要陷在细节里。从公司角度出发, 前端、设计都是成本部门,在 效果上做 1% 的妥协(不100%还原设计稿)换取 50% 效率提升,是很棒的
具体来说,前端、设计都应该服务于 AI First,做 e2e 的解决方案(比如 基于 Design System,映射到前端 Tailwind CSS,再到通用组件、布局)
顯示更多
真诚请教:如果 需求是在 AI 辅助下你对齐的、 代码是 AI 写的、AI review 的
你对项目把控的底气来源于哪?
最近车险到期,陆续有 10+ 保险经理加微信给我方案和报价。花半小时搭好 Agent工作流程,跑了 2 个小时,帮我谈下来 400 块优惠
技术栈:
- IM交互:微信机器人
- Agent:一个负责调度的codex + 每个经理一个沟通的codex
- Agent 通信:smux
聊天是按轮推进的,调度Agent 发起“开始新一轮”指令给所有经理Agent后,每个经理Agent基于:
- 自己上一轮与保险经理的对话
- 核心砍价策略
- 上一轮其他经理的聊天记录
生成这一轮的目标和“要给 经理说的话”,调度Agent负责在微信上发给对应的保险经理。
整个过程我完全没有干预,虽然有些插曲,比如一些经理发现是 AI 在说话,但完全不影响流程推进,他们还是会正经回复(图2)
我的感受是:很魔幻。
从我的视角看:我可以同时和几十个保险经理比价而不耽误工作,需要做的仅仅只是启动个codex进程。
从保险经理视角看:他花费2小时时间与我(实际是Agent`)沟通,仅仅是贡献了Agent工作流中的一点数据。
这种“用 AI 与 不用 AI 的效率对比”,实在是魔幻。
顯示更多