注册并分享邀请链接,可获得视频播放与邀请奖励。

卡颂
@kasong2048
🥴 OPC 5 年 📖《React设计原理》作者
166 正在关注    12.9K 粉丝
matt/skills 最终结局会怎样呢?他的理念会被 Agent Harness 吸收,导致装机率逐渐减少 因为:类似 codex App(现在叫 chatGPT App)的迭代方向都是:把 coding Agent 作为底座,在上面增加办公场景的抽象层。下一个被加入的抽象层应该是「基于 issue 的流程 kanban」 那么 issue 从哪来呢?Plan Mode 就需要加入「从需求转issue 的 tooling」 那 issue 怎么分类呢?根据需求类型分类,比如: - 需要与其他同事讨论的 - 需要自己做原型的 - 需要联网调研的 这些其实就对应 matt/skills 现在的一系列 skill
显示更多
0
66
43
4
转发到社区
办公领域的 AI 工作流最理想的状态就是 chat 了,因为办公领域最大的瓶颈是「交流」 工种内的工作流最终会收敛到不同 tag 的 issue chat 与 issue,一个管即时交流,一个任务管理
显示更多
AI 编程 接下来的趋势是:需求对齐侧会越来越厚,需求实现侧会越来越薄 需求对齐侧: 从 /grill-me 拷问需求,到 /prototype 画需求原型,这些是“我自己该怎么对齐需求” 再到 /to-questionnaire 是“为了对齐需求,我需要采访别人什么问题” 再往下的发展,就是“更多工种(比如 设计、产品)参与其中,作为 需求对齐侧 的一个环节” 需求实现侧: 随着 Agent 长程执行能力、编码能力 越来越好,很多防御性的流程(比如 Spec 拆成 详细的 Plan)变得没必要 最终 需求实现 将退化成一个 /goal 命令
显示更多
0
75
97
6
转发到社区
总结下 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!
显示更多
0
63
97
7
转发到社区
很多人放弃 Superpowers,问题的表象是:执行速度太慢。 但“速度慢”可以靠“并行开发”弥补。 最核心问题在 brainstorming 的设计上,为了减少上手门槛他会留下很多需求缺口没对齐,Agent 为了完成需求会自行脑补代码设计。 “脑补的代码设计 与 开发者实际需求”之间的偏差就是软件腐败的根源。这意味着长期使用 Superpowers 迭代的应用会更快腐败,更早需要重构 当然,其实大部分人的项目还没触及到腐败的点 就被砍了 🥴🥴🥴
显示更多
0
67
21
1
转发到社区
关于 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
显示更多
0
48
26
2
转发到社区
很多人诟病 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
显示更多
0
45
135
13
转发到社区
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来回答。
显示更多
0
19
13
1
转发到社区
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 再链接各个工种的工作流
0
13
14
1
转发到社区
AI 编程 的核心目标:让软件长期保持较高的迭代效率 手段主要有 2 个: 1. 提高开发效率,但开发效率提高 200% 整体迭代效率可能只提高 30% 2. 抹平工种之间的沟通瓶颈,这才是最大的效率瓶颈
显示更多
0
29
22
1
转发到社区
很多人将这篇文章解读为“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.
0
33
52
4
转发到社区
在小红书上看到设计师们讨论“Figma 2 Code 怎么弄效果最好” 都上 AI 了,就别困在一亩三分地了,直接用 tailwind 验收设计系统,用 storybook 验收 组件、布局 ,留着 Figma 这个中间环节干嘛
显示更多
0
13
34
1
转发到社区
发现个有趣的对比, @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、不讨论这个业务是什么,能干就执行,不能干就换下一个
显示更多
0
28
33
1
转发到社区
模型上下文限制对很多人来说是种保护, 当你对齐需求阶段都经历了 compact,很难说你知道最终实现出来是个啥
打工人想在公司搞 AI 需要了解的 2 点: 1. 怎么做? 做自己想做的 AI -> 别人不用 -> 推不动 帮别人做他想做的AI -> 符合他人利益,推得动 2. 为啥做? 错误:为了保住这家公司的饭碗 正确:为了简历好看,跳槽驱动决策
显示更多
0
14
16
1
转发到社区
今天学员群讨论面试被问到“如何 100% 还原UI”该怎么答 我的建议是:不要陷在细节里。从公司角度出发, 前端、设计都是成本部门,在 效果上做 1% 的妥协(不100%还原设计稿)换取 50% 效率提升,是很棒的 具体来说,前端、设计都应该服务于 AI First,做 e2e 的解决方案(比如 基于 Design System,映射到前端 Tailwind CSS,再到通用组件、布局)
显示更多
0
42
56
6
转发到社区
真诚请教:如果 需求是在 AI 辅助下你对齐的、 代码是 AI 写的、AI review 的 你对项目把控的底气来源于哪?
0
77
55
2
转发到社区
最近车险到期,陆续有 10+ 保险经理加微信给我方案和报价。花半小时搭好 Agent工作流程,跑了 2 个小时,帮我谈下来 400 块优惠 技术栈: - IM交互:微信机器人 - Agent:一个负责调度的codex + 每个经理一个沟通的codex - Agent 通信:smux 聊天是按轮推进的,调度Agent 发起“开始新一轮”指令给所有经理Agent后,每个经理Agent基于: - 自己上一轮与保险经理的对话 - 核心砍价策略 - 上一轮其他经理的聊天记录 生成这一轮的目标和“要给 经理说的话”,调度Agent负责在微信上发给对应的保险经理。 整个过程我完全没有干预,虽然有些插曲,比如一些经理发现是 AI 在说话,但完全不影响流程推进,他们还是会正经回复(图2) 我的感受是:很魔幻。 从我的视角看:我可以同时和几十个保险经理比价而不耽误工作,需要做的仅仅只是启动个codex进程。 从保险经理视角看:他花费2小时时间与我(实际是Agent`)沟通,仅仅是贡献了Agent工作流中的一点数据。 这种“用 AI 与 不用 AI 的效率对比”,实在是魔幻。
显示更多