即刻App年轻人的同好社区
下载
置顶
做了一套产品经理必备的 Skill，共 13 个，我最近一直在用原型绘制和数据分析，都挺不错的，开源给各位：
地址在这里：github.com
13 个 Skill，产品经理的工具箱：
pm-prd-writer — 模糊需求转 PRD
pm-analytics — 数据分析 + 可视化报告
pm-experiment-designer — A/B 实验方案设计
pm-competitor-deconstructor — 竞品四维拆解（策略/功能/体验/增长）
pm-roadmap-planner — 版本路线图规划
pm-image2proto — 截图复刻成 HTML 原型
这些仓库都是 public 的，直接 clone 就能修改或调用。
地址在这里：github.com
13 个 Skill，产品经理的工具箱：
pm-prd-writer — 模糊需求转 PRD
pm-analytics — 数据分析 + 可视化报告
pm-experiment-designer — A/B 实验方案设计
pm-competitor-deconstructor — 竞品四维拆解（策略/功能/体验/增长）
pm-roadmap-planner — 版本路线图规划
pm-image2proto — 截图复刻成 HTML 原型
这些仓库都是 public 的，直接 clone 就能修改或调用。
61 236
今天最有意思的事是 Claude Code 源码泄露，算是 A 厂最大的一次开源了
各种隐藏功能已经有很多人在聊了，简单过一下：AI 宠物 Buddy、24 小时主动助手 Kairos、闲置时自动整理记忆的 Auto-Dream、后台常驻的 Daemon 模式、跨设备传送会话、云端 Bug 舰队审代码。
我更好奇的是另一个问题： Claude Code 比其他同类工具优秀在哪里？
花了半天时间，查资料，看架构，和 AI 对话，到现在砍得越来越兴奋。它工程设计值得每个做 Agent 的团队学习。下面是我的七个总结：
1 prompt 每次都在变，根据场景实时拼装。
大部分 Agent 产品的 prompt 就是一大段固定文本。Claude Code 有个函数像流水线一样工作：先拼固定模块（身份、规范、行为准则、工具规则、语气），再根据当前状态加料（记忆、环境、语言、连了哪些插件、开没开精简模式）。
同一个用户前后两次对话，喂给模型的指令完全不同。而且这个拼装顺序是精心设计过的，前半段稳定的内容能被缓存，后半段会变的内容放后面，这样每天几万次请求能省下大量 token 费用。写 prompt 的时候考虑缓存节省 token，这个意识很多团队还没有。
2 一套写死的“不要做清单”
用过别的 coding agent 会发现让它改个 bug 它顺手重构半个文件，让它测一下它说"通过了"但根本没跑。CC 为了管住了这些毛病，逐条列好不要做清单：不加用户没要求的功能、不过度抽象、不瞎重构、不乱加注释、先读代码再改代码、不轻易建新文件、方法失败了先诊断再换策略、结果如实汇报不能假装测过了。
3 六个 Agent 分工，做事的、查事的、规划的权限完全隔开
至少六个内建角色各司其职。Explore Agent 只能读文件，连创建文件都不行。Plan Agent 也只能读，只管理解需求、分析架构、输出计划。Verification Agent 是"想尽办法做边界测试"：强制跑 build，前端改动要验页面，后端要实测响应。
4 为防止工具调用错误，设立一条安检线
模型想调一个工具，中间要过好几道关卡：先校验输入对不对，再预判这个操作有没有风险，然后走权限审批，全部通过了才真正执行。执行完还有后续检查，失败了有专门的兜底逻辑。
还有个 Hook 机制，能在执行前改写输入、直接拒绝、补充上下文，但 Hook 放行不能绕过系统级的拒绝规则。很多 agent 翻车就是模型用错了工具直接执行了，比如一条 sed 命令正则写错整个文件就废了。这条线在动手前把风险拦住了。
5 子 Agent 调度的省钱策略
很多 Agent 系统第一天跑得挺好，跑一百天就一堆泄漏，一个子任务从触发到完成要走十几步：解析输入、判断类型、构造 prompt、组装工具、创建上下文、注册插件、进入执行循环、记录日志、清理资源。
CC 的子任务会继承主线程的 prompt 前缀，目的是复用缓存少烧 token。执行完还会自动清理 shell 进程、MCP 连接、临时状态，不留垃圾。
6 三套扩展机制，重点是模型自己知道该用什么
Skill、Plugin、MCP 三套扩展能力装上去之后，都会通过各种通道告诉模型"我现在多了什么能力、什么场景该用"。
很多平台也有插件市场，装完之后模型根本不知道有这回事。Claude Code 把清单和说明书都摆在模型看得见的地方，Skill 按需加载，MCP 指令按连接状态注入，需要什么上什么，不需要的不占空间。
7 从目录结构看，这就是一个小型操作系统
入口层、提示词系统、工具定义、运行时服务、命令系统、协调器、记忆系统、插件、Hook、任务系统。
四个入口：CLI、初始化流程、MCP 模式、SDK。同一套内核跑四种界面。大部分开源 Agent 就是 main 加几个 tool 文件，这个复杂度完全不在一个级别。
拿模型做产品的朋友可以参考上面方法，用工程系统设计弥补模型的不可控。模型会偷懒，就把规矩写死。模型会用错工具，就在中间加安检。模型自己验不好自己的活，就拆一个专门找茬的角色出来。上下文会爆，就从 prompt 拼装到子任务调度每一层都在省。
谁先把这些层补上，谁的产品手感就会好一个台阶。
各种隐藏功能已经有很多人在聊了，简单过一下：AI 宠物 Buddy、24 小时主动助手 Kairos、闲置时自动整理记忆的 Auto-Dream、后台常驻的 Daemon 模式、跨设备传送会话、云端 Bug 舰队审代码。
我更好奇的是另一个问题： Claude Code 比其他同类工具优秀在哪里？
花了半天时间，查资料，看架构，和 AI 对话，到现在砍得越来越兴奋。它工程设计值得每个做 Agent 的团队学习。下面是我的七个总结：
1 prompt 每次都在变，根据场景实时拼装。
大部分 Agent 产品的 prompt 就是一大段固定文本。Claude Code 有个函数像流水线一样工作：先拼固定模块（身份、规范、行为准则、工具规则、语气），再根据当前状态加料（记忆、环境、语言、连了哪些插件、开没开精简模式）。
同一个用户前后两次对话，喂给模型的指令完全不同。而且这个拼装顺序是精心设计过的，前半段稳定的内容能被缓存，后半段会变的内容放后面，这样每天几万次请求能省下大量 token 费用。写 prompt 的时候考虑缓存节省 token，这个意识很多团队还没有。
2 一套写死的“不要做清单”
用过别的 coding agent 会发现让它改个 bug 它顺手重构半个文件，让它测一下它说"通过了"但根本没跑。CC 为了管住了这些毛病，逐条列好不要做清单：不加用户没要求的功能、不过度抽象、不瞎重构、不乱加注释、先读代码再改代码、不轻易建新文件、方法失败了先诊断再换策略、结果如实汇报不能假装测过了。
3 六个 Agent 分工，做事的、查事的、规划的权限完全隔开
至少六个内建角色各司其职。Explore Agent 只能读文件，连创建文件都不行。Plan Agent 也只能读，只管理解需求、分析架构、输出计划。Verification Agent 是"想尽办法做边界测试"：强制跑 build，前端改动要验页面，后端要实测响应。
4 为防止工具调用错误，设立一条安检线
模型想调一个工具，中间要过好几道关卡：先校验输入对不对，再预判这个操作有没有风险，然后走权限审批，全部通过了才真正执行。执行完还有后续检查，失败了有专门的兜底逻辑。
还有个 Hook 机制，能在执行前改写输入、直接拒绝、补充上下文，但 Hook 放行不能绕过系统级的拒绝规则。很多 agent 翻车就是模型用错了工具直接执行了，比如一条 sed 命令正则写错整个文件就废了。这条线在动手前把风险拦住了。
5 子 Agent 调度的省钱策略
很多 Agent 系统第一天跑得挺好，跑一百天就一堆泄漏，一个子任务从触发到完成要走十几步：解析输入、判断类型、构造 prompt、组装工具、创建上下文、注册插件、进入执行循环、记录日志、清理资源。
CC 的子任务会继承主线程的 prompt 前缀，目的是复用缓存少烧 token。执行完还会自动清理 shell 进程、MCP 连接、临时状态，不留垃圾。
6 三套扩展机制，重点是模型自己知道该用什么
Skill、Plugin、MCP 三套扩展能力装上去之后，都会通过各种通道告诉模型"我现在多了什么能力、什么场景该用"。
很多平台也有插件市场，装完之后模型根本不知道有这回事。Claude Code 把清单和说明书都摆在模型看得见的地方，Skill 按需加载，MCP 指令按连接状态注入，需要什么上什么，不需要的不占空间。
7 从目录结构看，这就是一个小型操作系统
入口层、提示词系统、工具定义、运行时服务、命令系统、协调器、记忆系统、插件、Hook、任务系统。
四个入口：CLI、初始化流程、MCP 模式、SDK。同一套内核跑四种界面。大部分开源 Agent 就是 main 加几个 tool 文件，这个复杂度完全不在一个级别。
拿模型做产品的朋友可以参考上面方法，用工程系统设计弥补模型的不可控。模型会偷懒，就把规矩写死。模型会用错工具，就在中间加安检。模型自己验不好自己的活，就拆一个专门找茬的角色出来。上下文会爆，就从 prompt 拼装到子任务调度每一层都在省。
谁先把这些层补上，谁的产品手感就会好一个台阶。
33 212
skill 用的越多越觉得，Skill 会被大模型进化掉
我现在做了上百个skill，今天把上百个 skilk 给我分成了几个类型，这几个类型我发现它们都是对应到了职业的需求。
就是说，这些skill的上级应该还有一个形态，可以把它们包揽起来，然后打包去创造或分享或出售。
这种形式其实可以做在模型里面，如果模型突然可以加载一个比方说设计、测试、产品经理这样的一个角色，就能把这些 skill 能力都笼揽了，这样子对于企业，对于个人来说，它的价值会更大，也更容易模块化交付。
我现在做了上百个skill，今天把上百个 skilk 给我分成了几个类型，这几个类型我发现它们都是对应到了职业的需求。
就是说，这些skill的上级应该还有一个形态，可以把它们包揽起来，然后打包去创造或分享或出售。
这种形式其实可以做在模型里面，如果模型突然可以加载一个比方说设计、测试、产品经理这样的一个角色，就能把这些 skill 能力都笼揽了，这样子对于企业，对于个人来说，它的价值会更大，也更容易模块化交付。
8 21
未来 token 肯定会降价，但是降价的速度赶不上用户消耗速度
最近就发现了 codex、claude 单次任务消耗量巨大，几次对话就被限制了。如果 Agent 自主运行了，那是十倍百倍的增长
所以订阅价 20 美金的价格肯定不会少，但 token 量增多，对用户来说肯定还是不够用的
最近就发现了 codex、claude 单次任务消耗量巨大，几次对话就被限制了。如果 Agent 自主运行了，那是十倍百倍的增长
所以订阅价 20 美金的价格肯定不会少，但 token 量增多，对用户来说肯定还是不够用的
3 10
产品经理能力的变化
如果我能直接拿到生产环境的代码，复刻产品就不需要了。
产品经理能直接基于生产代码做设计，在提给开发测试来评审。
那么如果用户有编辑代码的权限呢？是不是每个人都能定制化自己的产品了。
现在很多SAAS 产品开始 CLI 化，飞书前两天刚这么做了而且还开源了，用户拿到 CLI 的能力，就可以随意调用产品功能，也可以基于 CLI 的能力自组装一个定制化的界面。
不再通过统一的界面操作产品不是未来，是现在就能实现了。
当 Agent 可以接管代码甚至直接访问产品功能时，产品经理的价值还有什么？
有一点我非常确信产品经理最不稀缺的能力就是“把需求画出来”。
稀缺的能力是把团队有限资源放在最该做的事上：判断优先级、定义目标、拿到商业结果。
把用户需求转成产品功能，只是表层动作；更关键的是先回答三件事：
1 现在的核心问题是什么？
2 现在做是否时机正确？
3 做完能否提升业务价值？
随着 AI 发展更成熟需求会越来越多，有需求就需要产品经理，AI 不会替代产品经理，但会重排产品能力结构：低阶执行被自动化，高阶能力被放大。
从初级到高级的路径会变短，“画图仔”会减少；
但洞察、分析、决策、协同与领导力，会成为产品岗位的硬要求。
如果我能直接拿到生产环境的代码，复刻产品就不需要了。
产品经理能直接基于生产代码做设计，在提给开发测试来评审。
那么如果用户有编辑代码的权限呢？是不是每个人都能定制化自己的产品了。
现在很多SAAS 产品开始 CLI 化，飞书前两天刚这么做了而且还开源了，用户拿到 CLI 的能力，就可以随意调用产品功能，也可以基于 CLI 的能力自组装一个定制化的界面。
不再通过统一的界面操作产品不是未来，是现在就能实现了。
当 Agent 可以接管代码甚至直接访问产品功能时，产品经理的价值还有什么？
有一点我非常确信产品经理最不稀缺的能力就是“把需求画出来”。
稀缺的能力是把团队有限资源放在最该做的事上：判断优先级、定义目标、拿到商业结果。
把用户需求转成产品功能，只是表层动作；更关键的是先回答三件事：
1 现在的核心问题是什么？
2 现在做是否时机正确？
3 做完能否提升业务价值？
随着 AI 发展更成熟需求会越来越多，有需求就需要产品经理，AI 不会替代产品经理，但会重排产品能力结构：低阶执行被自动化，高阶能力被放大。
从初级到高级的路径会变短，“画图仔”会减少；
但洞察、分析、决策、协同与领导力，会成为产品岗位的硬要求。
10 22
作为产品，我还在画原型，还在接收业务人员的需求，虽然有 AI 来处理这些事情，这对我一个重度 AI 使用者来说依然是在浪费时间。
如果产品经理能拿到生产环境的代码，直接拿生产环境出原型，甚至业务人员也能拿代码，直接根据需求来提 PR 。可以提效至少五倍。
产品的代码，应该下放给所有参与这个产品的人，这才是验证一个组织是否 AI native 的关键。
如果产品经理能拿到生产环境的代码，直接拿生产环境出原型，甚至业务人员也能拿代码，直接根据需求来提 PR 。可以提效至少五倍。
产品的代码，应该下放给所有参与这个产品的人，这才是验证一个组织是否 AI native 的关键。
10 11
我自己做的加收藏别人的有 145 个 Skill，经常都记不住有哪些，总结了几个办法来提升使用的效率。
1 把常用的 skilk 内置在 .claude 里
写作风格、审稿标准这种每次都要的，我直接写在 CLAUDE.md 里。AI 启动就自带，不需要手动调用。
2 为同一类型的 Skill 做 前端界面
我的写作类 Skill 有 30 多个，命令行敲名字太麻烦，而且经常记不住该用哪个。我做了个 writeflow 的Web 界面，本地启动，左边粘贴原始内容，右边一排按钮，"公众号文章""即刻动态""小红书文案""播客脚本""标题优化"。
点一下，后台调 Claude Code 跑对应 Skill。
30 多个 Skill 变成 30 多个按钮，不用记名字。
3 能自动化尽早自动化
大部分 Skill 还需要人审一眼，但有些场景可以放手。播客处理工作流我跑了几十次，输出质量已经稳定了，基本不用改。每天早上 Clawdbot 推送更新，我说一句"处理第 2 个"，后面全自动。
我的判断标准：连续用了 20 次不需要手动改输出，就可以自动化。
4 轻的放手机，重的放电脑
信息总结、快速改写这些轻量级的，放在 OpenClaw 上，连接手机端飞书来办公。在地铁上刷到好内容，掏手机跑一下就行。代码生成、图片生成、原型制作这些要看效果做调整的，在 Claude Code 里跑。
5 GitHub 统一管理，软链接同步
这些 Skill 散在不同工具里会乱。全部放一个 GitHub 仓库：
github.com/zephyrwang6/myskil
用软链接挂到各个工具的 Skill 目录。改一处，所有地方生效。
ln -s ~/github/my-skills/x-post ~/.claude/skills/x-post
6 用环境变量管理 API Key
有些 Skill 会调用外部 API，飞书开放平台、图片生成服务。API Key 不能直接写在 SKILL.md 或脚本
我的做法是统一用环境变量管理。Skill 的脚本里写 os.environ['YOUTUBE_API_KEY']，Key 本身存在 .env 文件里，.gitignore 把 .env 排除掉。
这样 Skill 开源的时候只需要告诉别人"把你的 Key 填进 .env 就行"，不用担心泄露。
7 主动迭代Skill
我做了一个 skill-logger 和 skill-analyzer 自动记录 Skill 使用情况。
每周看一次数据，发现哪个 Skill 满意度下降了，打开看看是规则过时了还是场景变了。
用着用着会越来越好
8 自动迭代 Skill
有些 Skill，比如写作类的，每次输出完成品，还要对话几轮，才觉得满意，于是就在 Skill 里加一个说明，每次在我使用 Skill 结束后，把我们制作好的成品，进行的修改讨论的内容，写进 Skill 里，避免下次做同样的修改
Skill 做的好，它可让你突破时间的限制。纳瓦尔提到的代码、自媒体的复利，都是 Agent 最擅长的内容形式，现在 Skill 就是它能力的单元。
每一个 Skill，都是你给未来的自己存下的一笔利息。Skill 越多，复利越厚，终有一天，你会发现时间不再是你的约束。
关于 Skill 更多的制作技巧和进阶用法，可以看我的 AI 生产力系统专栏，那里有更系统的拆解。
1 把常用的 skilk 内置在 .claude 里
写作风格、审稿标准这种每次都要的，我直接写在 CLAUDE.md 里。AI 启动就自带，不需要手动调用。
2 为同一类型的 Skill 做 前端界面
我的写作类 Skill 有 30 多个，命令行敲名字太麻烦，而且经常记不住该用哪个。我做了个 writeflow 的Web 界面，本地启动，左边粘贴原始内容，右边一排按钮，"公众号文章""即刻动态""小红书文案""播客脚本""标题优化"。
点一下，后台调 Claude Code 跑对应 Skill。
30 多个 Skill 变成 30 多个按钮，不用记名字。
3 能自动化尽早自动化
大部分 Skill 还需要人审一眼，但有些场景可以放手。播客处理工作流我跑了几十次，输出质量已经稳定了，基本不用改。每天早上 Clawdbot 推送更新，我说一句"处理第 2 个"，后面全自动。
我的判断标准：连续用了 20 次不需要手动改输出，就可以自动化。
4 轻的放手机，重的放电脑
信息总结、快速改写这些轻量级的，放在 OpenClaw 上，连接手机端飞书来办公。在地铁上刷到好内容，掏手机跑一下就行。代码生成、图片生成、原型制作这些要看效果做调整的，在 Claude Code 里跑。
5 GitHub 统一管理，软链接同步
这些 Skill 散在不同工具里会乱。全部放一个 GitHub 仓库：
github.com/zephyrwang6/myskil
用软链接挂到各个工具的 Skill 目录。改一处，所有地方生效。
ln -s ~/github/my-skills/x-post ~/.claude/skills/x-post
6 用环境变量管理 API Key
有些 Skill 会调用外部 API，飞书开放平台、图片生成服务。API Key 不能直接写在 SKILL.md 或脚本
我的做法是统一用环境变量管理。Skill 的脚本里写 os.environ['YOUTUBE_API_KEY']，Key 本身存在 .env 文件里，.gitignore 把 .env 排除掉。
这样 Skill 开源的时候只需要告诉别人"把你的 Key 填进 .env 就行"，不用担心泄露。
7 主动迭代Skill
我做了一个 skill-logger 和 skill-analyzer 自动记录 Skill 使用情况。
每周看一次数据，发现哪个 Skill 满意度下降了，打开看看是规则过时了还是场景变了。
用着用着会越来越好
8 自动迭代 Skill
有些 Skill，比如写作类的，每次输出完成品，还要对话几轮，才觉得满意，于是就在 Skill 里加一个说明，每次在我使用 Skill 结束后，把我们制作好的成品，进行的修改讨论的内容，写进 Skill 里，避免下次做同样的修改
Skill 做的好，它可让你突破时间的限制。纳瓦尔提到的代码、自媒体的复利，都是 Agent 最擅长的内容形式，现在 Skill 就是它能力的单元。
每一个 Skill，都是你给未来的自己存下的一笔利息。Skill 越多，复利越厚，终有一天，你会发现时间不再是你的约束。
关于 Skill 更多的制作技巧和进阶用法，可以看我的 AI 生产力系统专栏，那里有更系统的拆解。
6 01