判断一个 Skill 值不值得，就两条标准
一是它能不能替你解决每天/每周重复的活；二是它在你不擅长的领域能不能帮上忙。两条都不占，就删。
别自己翻 Skill，让 Agent 用 find skills 去找、你只做选择
初始化工程时让 Agent 自己找，并叮嘱"只选必要的"，避免它把相关的全装上。技术栈相关的放工程目录，不放全局。
安装量最高的是技术栈 Skill，但最有用的是"验证类"
Playwright、Codex 内置 computer use 这类能让 Agent 自己做真实验证的 Skill，才是整个 loop 闭环里最关键的一步。
Grill Me：让 AI 反过来审问你，把需求逼清楚
来自 Matt Pocock 的 skills-for-real-engineers。它不停追问直到需求澄清，产出一份 context.md，大幅减少信息损失。
龟龟的 Codex 工作流：讨论需求 → plan → 自 review → 修 → 发版
哪怕只让它自己 review，从安全/性能/边界视角也能查出不少问题。发版、验证线上是否跑起来它都能自己做。
一笑的工作流：先搭"架构地图"，再让 AI 全链路一次写完
从零初始化仓库的分层骨架并写成架构文档，之后每个功能从前端到 DB 一次写完，他几乎只看 git diff 落在地图哪一块。
前端别堆"AI 味"：参考图 → ChatGPT 出图 → 切素材 → Codex 实现
从 Dribbble / X 找参考风格，让 ChatGPT 泛化出 landing page 图并分层切素材，再交给 Codex 还原成代码。
跳出 Coding，最高频的是知识管理 + Automation 定时任务
查邮件、盯流量、监控服务器成本、盯美股持仓、同步播客/读书笔记进知识库——都做成 Skill 挂在定时任务上自动跑。
网红 Skill（女娲 / PUA）好玩但没用，装多了反而乱
Skill 装多了 Agent 行为更乱、更费 token、更有失控感。龟龟很保守：用的时候发现能力缺失，才去装。
"不看代码"的代价，是把担责转移给了自己
出事时 AI 只会"滑跪道歉"，现实里道歉的还是你。信任 AI 某种程度上就是替它背责任，怎么兜底是个问题。
"我个人感觉最好用的其实不是这些技术栈相关的 Skill，而是那些能够让你的 Agent 去对它的迭代结果进行真实验证的 Skill……才是整个 loops 里面最关键的那一步。"
— 龟龟
为什么非共识 · Skills 商店里安装量排前面的几乎全是技术栈 Skill（React best practices、shadcn 之类），大多数人也是这么推荐的。龟龟反过来说这些不是最有用的——能让 Agent 自己"跑完并验证"的 Skill 才让开发真正闭环。这呼应了"现在不写 prompt 了，改写 loops"的新范式。
"在我的工作流里面，今天我也不会去 review 这个代码细节了，我几乎完全不看代码……曾经这些可能都是我自己写代码里的洁癖之处，但是今天这些全都忽略了。"
— 一笑（做后端 / 系统出身）
为什么非共识 · 一个曾经对命名、API 设计有洁癖的系统工程师，主动放弃 code review，只看 git diff 是否落在架构地图的正确模块里。主流仍强调"AI 代码必须人工审查"，他给出的是相反的、且带着心理转变自觉的实践。
"实际上你在帮你的 Agent 背负责任，因为真的出事的时候，他是不可能帮你去负责的……他可以滑跪道歉，但是真正在现实世界里面要道歉的是你。"
— 龟龟
为什么非共识 · 当全场都在为"不看代码也能做出东西"兴奋、追求全自动时，龟龟冷静点破：信任 AI 本质是把担责转移到自己身上。这是对"盲目信任 AI"氛围的一记提醒，也是风控视角里最该记的一条。
"一年前我发的那条动态，评论区第一反应都是失控感，觉得你这不就是给自己装了个监控吗？但经过一年过后，到今天，几乎没有人在关心这件事了。"
— 一笑
为什么非共识 · 他观察到的不是技术进步，而是"隐私/权限焦虑"这一社会共识的悄然崩解：OpenCloud 出来后大家对电脑权限的在意迅速消失，人的心理接受度被 AI 的进步反向驱动着扩大。这是对"共识本身会变"的元观察。
"恰恰就是当我讲的事情他听着很无趣的时候，我相信他这种事情就是应该我们自己动手去写个 Skill 了。如果我讲一个非常宏大、很有创意的事情，它显然不值得用 Skill 做。"
— 一笑
为什么非共识 · 大家常想把 Skill 用在"高大上"的创新场景，一笑的判据正相反：越无聊、越重复、越"毫无意义却不得不做"的日常事务，才是 Skill 最该发挥价值的地方；真正宏大有创意的事，反而该自己动手。
赛托开场抛出全场母题：Anthropic 推出 Skills 半年多，每天写代码做产品的人时间宝贵，不可能每个都试，那怎么判断一个 Skill 值不值得真正用起来？
龟龟的做法是"让 Agent 自己找、我来选"：初始化工程时先让 Agent 用 find skills 去找合适的 Skill，但明确叮嘱"只选必要的"，免得它把相关的全给你装上。这一步通常会找到技术栈相关的 Skill（React best practices、shadcn 之类）——这也是安装量最高的一类——他会把它们放在工程目录而非全局目录，因为它们和技术栈绑定。这类 Skill 的价值在于给 Agent 提供 best practices，避免它写出有安全/边界问题的奇怪代码。之后再根据实际使用中的不满，针对性地补找。
一笑把两人的判据总结成两条标准：第一，这个 Skill 是不是在真正帮你解决每天、每周、每月重复性的工作；第二，在你完全不熟悉、不擅长的领域，它能不能带来帮助。他自己更关注第二类——比如做产品要做的 SEO、marketing（他提到有个专门收集 marketing Skill 的网站）这些他不擅长的领域，会主动花时间去找；而自己擅长的重复性工作，则倾向于自己写 Skill，这些自写的 Skill 生命周期往往不长，不好用就删或改，完全跟着自己的需求走，不会当产品长期迭代。
聚焦到 Coding 领域，一笑仍套用他的两条标准。他不擅长的前端和设计成了重点：常用 Frontend Design 这类配套 Skill，还有 GitHub 上很流行的 design.md 仓库——它虽没封装成标准 Skill 格式，但本质就是一个 Skill，他会把成熟网站的设计系统拉过来、调一调，变成自己的一套设计语言。这一块因为他"完全不擅长"，提升最明显。另一类是重复性的 CI/CD 自动化：构建、部署、跑测试、跑完直接 fix bug，他都写成了贴合自己环境的工作流，尤其像 Go、Rust 这些需要编译、缺少 NextJS 那种完善自动化的语言，他会写很多这类 Skill 来辅助。
龟龟顺着 skills.sh（Vercel 做的 Skill 网站、也是 skills npm 包背后那个）的安装量说：排前面的大部分是 Coding 相关、且不少是特定技术栈的，因为技术栈 Skill 就是一些特定领域知识，比较好写。但他抛出本期第一个非共识判断——
"最好用的其实不是这些技术栈相关的，而是那些能让你的 Agent 去对它的迭代结果进行真实验证的 Skill。"比如 Playwright、Codex 内置的 computer use——只有 Agent 能真正自己做真实验证，开发任务才能真的闭环跑完，这是整个 loops 里最关键的一步。他还提到看到"龙虾"（Open Cloud）的创始人等人在 X 上说"现在不写 prompt 了，改写 loops，用 loops 驱动 AI 写代码"——所以怎么把这个 loop 构建完整才是核心。而验证这一步对人来说本就繁琐、效率低，交给 Skill 最划算。
赛托把话题往前推到"项目前期设计"这一环：我们给 AI 一段 prompt，但那段 prompt 到底描述清楚了没有？你脑子里清楚，AI 未必清楚。他推荐一个专治这个问题的 Skill——来自 Matt Pocock 的 skills-for-real-engineers，其中最好用的叫 Grill Me（字面意思是"像烧烤一样把我串在签子上烤"，即反过来审问你）。
用法是：产品/你自己给一句"这里帮我改一下"，背后往往隐藏很多没考虑到的细节；把这个需求丢给 Grill Me，它会连环追问，直到你把事情澄清清楚，然后生成一份 context.md。开发（无论是你还是 AI）拿到这份 context.md，就更接近产品原生提出的需求。
赛托强调这背后是"信息损失"问题：过去公司大团队里"产品说了一、开发做成二、测试测成三"，靠写文档对齐；现在你一个人、团队很小，没法跟 AI 描述那么清楚，而描述清不清楚，AI 做出来的结果可能千差万别——尤其用 Codex 的 go 让它长时间做一件事时，前期需求不清，后面偏差会非常大。所以他现在给 Agent 提需求都会先让它 Grill Me 一下；还有个 grill-me --doc 变体，能烤完直接写进文档。
龟龟（以 Codex 为主）的流程其实就三四步：先跟 Agent 讨论需求（中间也会用 Grill Me）；复杂需求让 Codex 走一轮 plan mode，plan 里就包含"怎么验证需求做好了"；执行完让 Codex 先自己 review 一遍。他特别强调自 review 的价值——很多人讲交叉 review（让 Claude Code 审 Codex 的代码、或反过来），但哪怕只让它自己从安全/性能/边界视角看，也能查出不少问题。改完后他选择性地人工复核，简单需求甚至看都不看（Agent 自己会验证还会截图给他看），最后让 Codex 自己提交发版、并验证线上是否真的跑起来。看似三四步，Codex 每一步其实靠 AGENTS.md 和 Skill 约束，暗自做了格式化、diff 范围检查、编译、静态类型检查、单测、端到端测试等很多小步骤。
一笑的流程是"从后端到前端"、以架构为骨：拿到 idea 先和 AI 聊出技术栈方向（这点和过去不同——过去技术栈被团队固化，现在可以探讨出一些"奇奇怪怪"、超出以往范畴的技术栈，哪怕不熟他也愿意试）。然后让 Agent 顺着技术栈，把从零的仓库初始化成一个分层架构骨架（DB 层、API 层、插件层……），他把这当成一张"架构地图"，并让 AI 写成架构文档保存，未来加功能都遵守这张地图。
"我几乎完全不看代码……我只会去看 git diff 的修改落在哪些文件、是不是正确地落在我那张架构地图的版图里面。"越往后他交给 Agent 的功能粒度越大，如今是让 AI 从前端到后台到 DB 全链路一次性写完一个完整功能。API 设计好不好看、命名这些他一概不管——而这些在过去恰恰是他的"洁癖之处"，他坦言这是个挺大的、甚至有点莫名其妙的心态变化。设计系统（主题、light/dark 切换）他放到最后、功能做到七八成时才整体做，因为"AI 改起来快，几分钟就帮你改完"，不像人那样必须前期定好。
接着一笑"后端先行、前端最后"的话头，赛托补充了 Podwise 官网新版前端的做法，专治那种"一眼就看出是 AI 做的"landing page。他的观点是：Claude Code 自带的前端设计、design.md 这些只能帮你把风格固定下来，Frontend Design 内部支持的设计花样也不算多。
他现在常用的策略是一条"图片穿插"的流水线：先用图片生成想要的风格，再从图片里提取素材，最后用 Codex 把前端实现出来。具体是——从 Dribbble、X 上找符合自己想要风格的参考图，交给 ChatGPT（利用它 image gen 版本很强的拟真性）做泛化。因为 Podwise 本来就有网站，ChatGPT 会分析已有网站内容，把想要的风格和自有内容柔和成一套它觉得合理的 landing page 图。出几个版本挑到满意的之后，再让 ChatGPT 帮忙把图片"分层"、切出里面的图和文字素材。最后把图片和素材一起交给 Claude 或 Codex 去真正实现成代码。
他还会让 AI 先做完 web 版首页，再基于 web 版生成一套 responsive 的 mobile 版（同样先以图片形式），两张图一起给 Codex 就能真正实现。对 landing page 他对前端架构没什么要求（单页应用、可复用的东西不多），具体怎么写不关心，能实现风格就好。他把这个路径总结为"把设计外包给 ChatGPT 的 image gen"，挺推荐大家试。
赛托问：跳出 Coding，日常最有用的 Skill 是什么？三人答案汇成两大类——个人知识管理、和挂在定时任务上的 Automation。
一笑说 Coding 之外他电脑上被调用最多的是 Podwise 的 Skill（现在想浏览播客几乎不再打开网站），以及围绕自己笔记系统打造的知识管理 Skill。他们录了一百多期节目，希望把这些历史数字资产保存并"盘活"——过去换笔记软件时，那些长期不看的笔记连导出都懒得导、直接删了，因为知道再也不会打开；而有了 Skill 和 Agent，这些资产可以被重新盘活。他还很依赖微信读书的 Skill，把书架、笔记情况同步进统一的笔记系统（读书速度慢，不像播客每天有新内容，所以不是每天用）。
龟龟用得最多的是帮他完成日常事务的 Skill，搭配 Codex 的 automation 定时跑：每天查邮件、分析自家流量、监控服务器成本、监控美股持仓变化及相关个股新闻、监控 AI 行业趋势。凡是"每天都要干"的事，他就把过程做成 Skill 让它自动跑。
赛托补充 automation 不止 Codex 有，Hermes、Open Cloud 也能定时。他自己写了个叫"解密"的 Skill：问 Agent 今天 Podcasts 最热门的播客，挑感兴趣的一期让它用 X threads 的方式从头到尾解密成文章，整理后发到 X 的 article——他发的很多期阅读都能过十几万，同时给 Podwise 引流。
赛托问：有没有在 X 上被炒得很热、装了却"不明所以"最后删掉的 Skill？一笑点名前阵子各大自媒体到处发的几个——同事.skill、女娲.skill、PUA.skill：名字一看就懂、介绍看着强大、star 也多，出于好奇装了，但发现自己没这方面需求（他只想和 AI 讨论具体工作、产品，没有和 AI 聊天/角色扮演的需求），最后都删了。不过他也说这些 Skill 里定制表达习惯、写作风格的技巧值得借鉴，可以集成进自己的 Skill。
龟龟装 Skill 很保守：女娲、各种大厂风格的 PUA（阿里的、腾讯的）他都刷到过、觉得有创意，但连试都没试。他担心 Skill 装多了 Agent 行为反而更乱、消耗更多 token，有一种"失控感"——这些 Skill 往往很长，他不可能逐个去看里面到底是什么，所以倾向于用的过程中真发现 Agent 知识缺失，才去装。
顺着"失控感"，一笑讲了个故事：一年前他发动态说"想要一个笔记软件，我不想读它，只想把每天的内容发给 AI，AI 帮我消化，想看时再告诉我"，评论区第一反应都是"这不就给自己装了个监控吗"。"但是经过一年过后，到今天，几乎没有人在关心这件事了。"他观察到 Open Cloud 出来后，大家对电脑权限的在意迅速被打破——AI 的进步在不断驱动电脑权限越开越大、人的心理接受度也越来越大，隐私好像不怎么被提了。赛托也补充自己的体感：自从知道 Open Cloud 是一个人用 AI 写的、完全不看代码、bug 满天飞，"好像我们自己写代码也不看了"；他现在常让免费的 Claude Code 交叉 review Codex 的产出，交叉之后问题就解决了。这个转变从去年 10 月 Skills 出现后开始明显——"你什么都不看了，好像做什么东西都能做了"。
在"不看代码"的兴奋里，龟龟泼了盆冷水，也是本期最锋利的一条——
"实际上你在帮你的 Agent 背负责任，真的出事的时候他不可能帮你负责……他可以滑跪道歉，但现实世界里要道歉的是你。"信任 AI 一定程度上就是把担责转移到自己身上，这是跑不了的；AI 今天能力确实够、很多时候可以信任，但"到底怎么兜这个底"是个真问题。
赛托也补了个"踩坑"：Codex 官方推荐的 Superpowers（很火的 Skill 合集）他装了却"不明所以"，觉得太复杂、不会用；后来发现 Grill Me 更适合自己。他现在提需求只把控两点——第一，需求有没有讲清楚；第二，让它用 TDD 的方式做（单测 + 端到端集成测试，集成测试里让 AI 梳理清楚用户故事与用户旅程），至于用 subagent 还是别的方式实现他不关心；界面审美这种主观的东西，他最后自己调。
说到自己写的 Skill，一笑仍是两类：CI/CD 集成的个人环境 Coding Skill，和个人笔记/数字资产管理（定时扫自家播客→同步文字稿进笔记系统→再编译成结构化知识库，方便日后检索；以及 Podwise 运维中联合多数据源定位 AI 任务失败）。他给出本期又一条非共识判断：越是听着无聊、重复、毫无意义却不得不做的日常事务，越适合交给 Skill；真正宏大有创意的事反而该自己动手。而写 Skill 这件事本身也不用自己一行行写，告诉 Agent 工作流和可用程序，让它帮你编排、你再审一遍——Skill 或许正是 Agent 未来自我积累、进化的一种方式。
龟龟自写的 Skill 分三类：日常工作（查 Gmail，把待回复的 support 邮件译成中文、按语言/分类/用户情绪润色回复）、Coding（比如 Podwise 网站版和 App 共用大部分代码但不同工程，把代码同步 + 人工看 diff 判断差异的过程提炼成 Skill）、投资（读持仓、历史价格、期权链、新闻给当天操作建议——但他坦言这个远不如前两类好用，因为自己这方面知识不够，做出来的 Skill 也就那样）。
赛托用程序员那句"DRY——Don't Repeat Yourself"收尾：任何事做过三次以上，以前写 shell 脚本，现在写 Skill，因为 Skill 什么都能干。真正值得沉淀的，就是那些被你重复、值得自动化的工作。