EP127 从 Skills 到自动化工作流，论 Agent 如何接管真实生产力

概览

本期围绕 Skills 如何真正进入日常工作流展开，核心问题是：哪些 Skills 值得安装、哪些适合自己写，以及它们如何从“提示词补丁”变成 Agent 自动化生产力的一部分。

讨论者反复强调，判断 Skill 价值的关键不在于它是否热门，而在于它是否解决重复性工作，或补足自己不熟悉领域的能力。Coding 场景中，大家更看重能帮助 Agent 完成真实验证、测试闭环、需求澄清和发布流程的 Skills。

节目后半段把话题扩展到非 Coding 场景，包括播客知识管理、微信读书笔记、邮件处理、流量分析、服务器成本监控、投资信息整理等。大家也讨论了 Skills 变多后带来的失控感、权限与责任问题，以及为什么真正有价值的 Skills 往往来自日常琐事的自动化。

分段落总结

[00:00] 开场与本期问题设定

[事实] 本期节目由 Podwise 赞助，开场介绍了 Podwise 可以对播客进行转录、提取、总结和分析，并与 Notion、Readwise 等工具打通知识管理流程。 [事实] 主持人提出本期核心问题：自从 Skills 概念推出后，哪些 Skills 真正改变了大家日常工作流，如果从零搭建 Agent 工作流，应该保留哪些 Skills。 [事实] 讨论从“如何判断一个 Skill 是否值得用”开始，强调不能把所有 Skill 都试一遍，需要有筛选标准。

[00:01] 用 Agent 找 Skills，并只安装必要项

[事实] 讨论者提到自己会在初始化工程时，让 Agent 使用 find skills 之类的能力去寻找适合当前工程的 Skills。 [事实] 他会要求 Agent “只选必要的”，避免把相关但不必要的 Skills 全部安装进来。 [事实] 技术栈相关的 Skills，例如 React best practices、shadcn 相关能力，通常会放在工程目录下，而不是全局目录，因为它们和具体项目绑定。 [事实] 这类 Skills 的价值在于给 Agent 提供最佳实践，减少奇怪代码、安全问题和边界问题。

[02:42] 在实际卡点中发现 Skill 需求

[事实] 讨论者以 Podwise iOS app 测试验收为例，说明直接让 Codex 操作时也能尝试执行，但会在模拟点击、CLI 操作等环节遇到阻碍。 [事实] 他发现 build iOS app 相关 Skills 和 Codex 内置 computer use 中的能力，可以帮助 Agent 操作模拟器和完成测试流程。 [事实] 他认为应在使用过程中观察 Agent 缺失什么能力，或哪些流程需要反复写提示词，再去找 Skill 或自己做 Skill。 [推测] 这里隐含的判断是：Skill 更像是对稳定流程和常见卡点的固化，而不是一次性任务的临时提示词。

[04:03] 判断 Skill 是否值得用的两个标准

[事实] 主持人总结，值得使用的 Skill 首先要解决每天、每周或每月都会重复出现的工作。 [事实] 第二类值得关注的 Skill 是能帮助用户进入不熟悉、不擅长的领域，例如营销推广、SEO、销售相关 Skills。 [事实] 讨论中提到有专门收集 marketing skills 的网站，适合在营销、销售等非技术强项领域提供辅助。 [事实] 对自己擅长的重复性工作，讨论者更倾向于自己写 Skill，并且这些项目内 Skills 生命周期可能很短，会经常删除或修改。

[06:37] Coding 场景中的前端、设计与自动化 Skills

[事实] 在 Coding 场景里，有人最关注前端和设计方向的 Skills，因为这是自己不擅长的领域。 [事实] 被提到的工具或资源包括 Frontend Design、相关设计 Skill，以及 Design.md 这类本质上类似 Skill 的设计指南仓库。 [事实] 另一类高价值 Skills 是 CICD、构建、部署、跑测试和自动修复 bug 等重复性开发流程。 [事实] 讨论者认为测试尤其适合写成 Skill，因为它可以让产品跑起来并由 Agent 自己验证。

[10:21] 真实验证比技术栈知识更关键

[事实] 讨论者提到 skills.sh 上安装量靠前的大多是 Coding 相关 Skills，且很多是特定技术栈知识。 [事实] 他认为最有用的不一定是技术栈知识，而是能让 Agent 对迭代结果进行真实验证的 Skills，例如 Playwright 和 Codex 内置 computer use。 [事实] 只有 Agent 能自己做真实验证，开发任务才更可能形成完整闭环。 [事实] 讨论中提到“现在不写提示词，而是写 loops”，强调用循环流程驱动 AI 编码。

[12:00] 用 Grill Me 澄清需求

[事实] 主持人提到 Matt Pocock 的 skills for real engineers，其中的 grill me 用于在开发前不断追问需求细节。 [事实] grill me 会围绕模糊需求提出问题，直到需求被澄清，并可生成 context.md 供后续开发使用。 [事实] 讨论者认为需求描述不清会导致 AI 长时间执行后偏差很大，尤其是在 Codex go 或 loop 类长任务中。 [推测] 这一段把 Skill 的价值从“执行更快”扩展到了“前期对齐更清楚”，减少后续返工。

[14:43] Codex 编码工作流：讨论、计划、执行、Review、发布

[事实] 一位讨论者目前主要使用 Codex，工作流大致包括先与 Agent 讨论需求，复杂需求用 plan mode 做计划，再执行计划。 [事实] 计划中会包含如何验证需求已经完成。 [事实] 执行后会让 Codex 自己从安全、性能、边界条件等角度 review，并修掉发现的问题。 [事实] 最后根据任务复杂度进行人工复核或只看最终结果，再让 Codex 提交、发版，并验证线上环境是否正常。 [事实] 从 Codex 视角看，agents.md 和 Skills 会约束它执行格式化、diff 检查、编译、静态类型检查、单测和端到端测试等多个小步骤。

[17:20] 从零做产品时，先让 AI 生成技术栈与架构地图

[事实] 另一位讨论者分享了从零构建工具或产品的流程：先拿 idea 和 AI 讨论，确定技术栈方向。 [事实] 他认为今天技术栈不一定像过去团队项目那样固定，AI 可能会给出超出原有经验范围的技术选择。 [事实] 确定技术栈后，会让 Agent 初始化 repo 架构，划分 DB 层、API 层、插件层等模块。 [事实] 他把初始架构文档称为“架构地图”，用于让后续功能开发遵守模块边界，但这个地图后续也会调整。

[20:18] AI Coding 让人从代码细节转向架构和结果

[事实] 讨论者说自己越来越敢把更大粒度的功能交给 Agent 一次性完成，包括前端、后台和 DB 全链路。 [事实] 他现在不再细看代码细节，而是看 Git diff 涉及哪些文件，以及这些修改是否落在架构地图的正确模块中。 [事实] 过去会在意命名、API 定义等细节，现在这些细节在 AI Coding 中被弱化。 [事实] 他通常在功能做出七八成后，再集成测试和设计系统，并让 AI 统一调整前端视觉、主题和页面。 [推测] 这反映出 AI Coding 可能改变程序员的关注点：从局部代码洁癖转向系统边界、功能验收和整体体验。

[24:13] Landing Page 的图片先行设计流程

[事实] 主持人分享 Podwise 官网新版前端的制作方法：先从 Dribbble、推特等地方找参考图，再让 ChatGPT 结合参考风格和现有网站内容生成 landing page 图片。 [事实] 在选出效果较好的图片后，会让 ChatGPT 对图片进行分层，提取其中的素材。 [事实] 随后把设计图和素材交给 Claude Code 或 Codex 实现前端。 [事实] 他还会让 ChatGPT 同时生成 Web 版和 Mobile 版响应式效果图，再交给 Codex 实现。 [推测] 这种流程把设计探索交给图像生成，把工程实现交给编码 Agent，适合对视觉要求较高但结构相对简单的页面。

[27:54] 非 Coding 场景：播客、笔记和数字资产管理

[事实] 跳出 Coding 后，一位讨论者说自己最常调用的是 Podwise Skill，甚至不太再打开 Podwise 网站浏览播客。 [事实] 他还围绕自己的笔记系统积累了知识管理相关 Skills，希望把超过 100 期播客节目作为数字资产保存和盘活。 [事实] 他提到过去使用笔记软件时，很多长期不看的笔记最终会随软件更换一起被放弃。 [事实] 微信读书 Skill 也被提到，用于查看书架、笔记情况，并把读书笔记同步到自己的笔记系统中。

[30:34] Automation 让日常事务定时运行

[事实] 另一位讨论者在非 Coding 场景中主要使用日常事务类 Skills，并搭配 Codex Automation 定时运行。 [事实] 例子包括每天检查邮件、分析自家流量、监控服务器成本、监控美股持仓变化和相关股票新闻、监控行业趋势。 [事实] 主持人补充，Codex Automation、Poe 或 OpenCloud 里的定时任务，本质上都能让 Skills 定期运行。 [事实] 他自己写过 Podwise 相关 Skill，用 Podwise popular 找热门播客，再用“解密”的方式整理内容并发布到 X Article。

[32:47] 热门但不一定有用的 Skills

[事实] 讨论中提到一些曾经很火的 Skills，例如通四点 skill、女娲点 skill、POA/PVS 类 Skills。 [事实] 一位讨论者安装后发现自己没有对应需求，尤其没有“和 AI 聊天”的需求，只需要讨论具体工作或产品，因此最后删除了。 [事实] 他认为这些 Skills 中仍有值得学习的地方，例如提炼表达习惯、写作风格或个人数字资产，用来构建自己的风格化 Skill。 [事实] 另一位讨论者装 Skills 比较保守，担心装多后 Agent 行为更乱、消耗更多 token，因此通常只在发现 Agent 知识缺失时才安装。

[36:30] 失控感、权限和责任的变化

[事实] 讨论者围绕“失控感”展开，提到一年前大家会担心把个人内容交给 AI 像是在给自己装监控。 [事实] 他认为经过一年后，人们对权限、隐私和 AI 读取电脑内容的心理接受度正在变高。 [事实] 主持人补充，知道 OpenCloud 由一个人用 AI 写、且作者不看代码后，自己也更少 review AI 生成代码。 [事实] 他们也提到交叉 review：例如让 Codex 写完后交给 Claude Code review，再把 review 结果交回 Codex 判断和修复。 [事实] 讨论者提醒，信任 Agent 的隐含代价是人仍然要为 Agent 的错误承担现实责任。

[41:40] Superpowers、Grill Me 与 TDD 的取舍

[事实] 主持人提到 Codex 官方推荐过 superpowers 这类火热 Skill 合集，但自己装了之后觉得太复杂、不太会用。 [事实] 相比之下，他更适应 skills for real engineers 里的 grill me，以及其中 TDD 相关能力。 [事实] 他认为自己主要把控两点：先把需求讲清楚，再要求用 TDD、单测和端到端集成测试来保证结果。 [事实] 他会让 Agent 梳理用户故事和用户旅程，以便后续做完整测试。

[43:32] 自己写 Skills：内容解密、CI/CD 和知识编译

[事实] 主持人写过一个 X“解密”Skill，用来把 Podwise transcript 整理成解读文章。 [事实] 另一位讨论者自己写的 Skills 主要分两类：一类是 Coding 里的个人环境和 CI/CD 流程集成，另一类是个人笔记和数字资产管理。 [事实] 他会让 Skill 定时同步播客文字稿，再把每期文字稿编译成结构化知识，例如人物、产品和主题，方便未来检索。 [事实] 他还提到 Podwise 运维场景中，Skill 可以帮助定位 AI 任务失败，减少手动到多个网站查询数据的麻烦。

[46:00] Skill 最适合处理无趣但重复的日常事务

[事实] 讨论者认为 Skill 真正发挥价值的地方，往往是看似不起眼、重复发生、每天不得不做但又无趣的日常事务。 [事实] 他认为宏大、有创意的事情未必适合 Skill，反而是无趣琐碎的事情更应该被自动化。 [事实] 写 Skill 本身也可以交给 AI Agent，只需要告诉它工作流、数据获取方式和可使用程序，让它编排 Skill。 [推测] 这里的观点接近“Agent 自我进化”：通过把反复出现的流程沉淀成 Skills，Agent 的可用能力会逐步积累。

[47:13] 邮件、代码同步和投资类 Skills

[事实] 一位讨论者自己写的 Skills 分为三类：日常工作、Coding 和投资。 [事实] 日常工作中，邮件 Skill 会检查 Gmail，把待回复 support 邮件翻译成中文，再根据原文语言、问题分类和用户情绪润色回复。 [事实] Coding 中，Podwise 网站版本和 App 共用部分代码但不是同一工程，因此他把同步代码、检查差异和判断 override 文件的流程做成了 Skill。 [事实] 投资类 Skill 会读取持仓、历史价格、期权链数据和新闻事件，给出当天操作建议，但他认为这一类不如前两类好用，因为自己相关知识不足。 [事实] 最后总结到 DRY 原则：过去重复三次以上可能写 shell 脚本，现在可以写 Skill。

播客点评/总结

本期的价值在于，它没有把 Skills 当成单纯的“插件推荐清单”，而是放回真实工作流里讨论：什么时候该装、什么时候该写、什么时候该删除，以及如何和 Codex、Claude Code、Automation、TDD、Playwright、computer use 组合成闭环。

[推测] 对程序员、独立开发者、产品型创业者来说，这期尤其有参考价值，因为它展示了 AI Coding 从“帮我写一段代码”走向“帮我澄清需求、规划、实现、测试、发布和监控”的完整过程。

[推测] 本期的局限是讨论高度依赖几位嘉宾自己的工具栈和工作方式，例如 Codex、Podwise、微信读书、X Article 等场景；如果听众没有类似的数字资产或自动化需求，部分案例需要自行迁移。

[推测] 最值得带走的结论是：不要因为某个 Skill 热门就安装它，而要从自己的重复工作和薄弱领域出发。真正能提升生产力的 Skill，通常不是最炫的，而是那个每天帮你少做一遍无聊流程的。