即刻App年轻人的同好社区
下载
置顶
OpenAI 很会做（chāo）产品，他们只是不如 Anthropic 那么懂 LLM harness🌚
栗噔噔: 发现Codex的新版本加了个新功能，你可以通过旁边的黑色短线快速定位到某一次你下发的需求，这确实很有效的解决了我之前做教程的时候总是要非常努力才能翻到自己之前某次下命令的地方…… 真是神奇，居然能被他们发现这个需求，看看这下谁还说OpenAI不会做产品（我不知道其他家有没有哦反正我是先在Codex体验到的）
2 00
谁负责 PMF 谁就是产品经理角色，无所谓挂不挂那个无聊的 title 🌚
具体来说：LLM 是生产力革命，尤其是直接改变 coding 和通过 coding 改变其他领域生产，所以早期 PMF 都是由有用户 sense 的coder 蹚出来的，这很正常。
另一方面，消费端还有很多场景交互，暂时不是语音、文字能替代掉的。
具体来说：LLM 是生产力革命，尤其是直接改变 coding 和通过 coding 改变其他领域生产，所以早期 PMF 都是由有用户 sense 的coder 蹚出来的，这很正常。
另一方面，消费端还有很多场景交互，暂时不是语音、文字能替代掉的。
ziya_: 现在每天都在怀疑（非评测方向的）产品经理的价值 之前是觉得部分传统产品的经验失效了，所以大家喜欢年轻人喜欢ai-native。 但是anthropic很多老登，workbuddy也全是老登，看起来效果也不错，因为里面的老登都是研发背景的。 比如上一份工作在workbuddy，产品基本都是研发转的，（所以产品会值班修bug写架构写tool之类的），没有设计师也没有交互，做出来的也不错。 至少现在看起来有点产品sense的研发做出来的产品，比大多数产品主导的ai产品做得好，技术品味太重要了。
4 00
多 Agents 协作经验教训：机制协议化任重道远 meloneating.feishu.cn
-前情提要：m.okjike.com
- Codex 的总结（不代表个人态度）：Agent 群聊协作适合作为研发期的可观察调试界面，但不适合作为中长期主流产品形态；真正有产品价值的，是把群聊里暴露出的协作协议、交接规则、失败恢复和用户确认点，沉淀成模型主导的 Orchestration 机制。
-前情提要：m.okjike.com
- Codex 的总结（不代表个人态度）：Agent 群聊协作适合作为研发期的可观察调试界面，但不适合作为中长期主流产品形态；真正有产品价值的，是把群聊里暴露出的协作协议、交接规则、失败恢复和用户确认点，沉淀成模型主导的 Orchestration 机制。
9 32
同一集团内不同事业群/部的产品之间，关系要比不同集团的竞对产品之间，关系差得多。
竞对产品做起来了，可能还会给我抬咖；
兄弟事业部产品做起来了，可是会把我干掉的。
竞对产品做起来了，可能还会给我抬咖；
兄弟事业部产品做起来了，可是会把我干掉的。
一乐一乐也: 有个疑问，请教： 阿里既有JVS Claw和QoderWork，腾讯也是有Qclaw和Workbuddy。都是同一家公司两个Agent，有什么主要区别吗？为什么要有两个呢？
6 00
即使 Claude 新版本模型愈发惊艳
Loop Engineering 的理念看上去进一步闭环
但它们的成本实在是太贵
大厂的 Capex 在放缓（即使裁员也是降本不增效）
C端 AI 应用商业化也几乎毫无进展
再加上：二级市场 AI 供应链的暴涨泡沫+一级市场世界模型和 Agents Team 创投泡沫
这里可能就是这一轮 LLM 生产力革命的愚昧之巅了
往后就是超级 App 卷白领办公场景的无情红海
以及 C端 AI 应用商业化的萌芽
Loop Engineering 的理念看上去进一步闭环
但它们的成本实在是太贵
大厂的 Capex 在放缓（即使裁员也是降本不增效）
C端 AI 应用商业化也几乎毫无进展
再加上：二级市场 AI 供应链的暴涨泡沫+一级市场世界模型和 Agents Team 创投泡沫
这里可能就是这一轮 LLM 生产力革命的愚昧之巅了
往后就是超级 App 卷白领办公场景的无情红海
以及 C端 AI 应用商业化的萌芽
11 121
花了一天一夜做了个多 agents 协作实验（其实还没结束），勉强跑通了 Hermes(GLM-5.2)、Claude、Codex 3 个 agents 在飞书群里【自动化（？）协作共创、迭代主题性 LLM Wiki】
此前背景：核心是想用 LLM Wiki 那套方案管理维护一个垂类项目参考笔记。过去一个月历经 Claude 初始化、 OpenClaw 云端、OpenClaw 本地、Hermes 本地，最后想尝试本地三个 agents 在飞书群协作完成（这样可观测、不黑盒；Hermes 比 OpenClaw 更稳定负责）
核心思路：让 Hermes 管理、同步（相当于 CEO 助理），让 Claude/Codex 用 graphify 拆解 GitHub 项目
工作空间：本地文件夹，飞书文件夹，飞书群聊
日常流程大纲：
1. 我（用户）分享 GitHub 项目链接/微信公众号文章/其他网址或内容@Hermes；
2. Hermes 接收我发的内容，执行符合 LLM wiki 标准的 ingest， 沉淀在本地文件夹，然后：如果是 GitHub 项目，则一定单独发项目链接@Claude/Codex；如果是其他形式，酌情寻求 Claude/Codex 协助；
3. Claude/Codex 对 GitHub 项目执行 graphify（其他形式内容则是视具体情况调用工具），沉淀在本地文件夹（同一个项目的内容，命名需要有关联），然后告知 Hermes 位置和命名
4. Hermes 最终整合一个项目相关的全部笔记，同步到云端飞书文件夹
初始化工作（必须严格按顺序执行）：
1. Claude 将本地文件夹已记录的 GitHub 项目，依次执行 graphify，沉淀在本地文件夹（同一个项目的内容，命名需要有关联），然后告知 Hermes 位置和命名
2. Claude 将全部已有 GitHub 项目 graphify 完毕后，Hermes 再将本地文件夹已有内容，按 LLM wiki 标准整合更新
3. Hermes 将本地文件夹第一次整合更新后的内容，首次同步到飞书文件夹
4. Hermes 设置定时任务，每周六早上 5 点浏览、整理本地文件夹和飞书文件夹，检查是否同步统一、是否有遗留问题或任务，把结果发到本群，如果有需要做的事情则分工、有需要做的决策则讨论
整体原则：
- 后续都在飞书群协作，我（用户）、agents 通过互相@来协作
- 协作方式和经验教训，可以按实际情况沉淀和更新
- 如果遇到依赖缺失、外部需要、决策分歧、结果汇报，找我（用户）
一路上遇到了巨多问题，让 agents：
- 设计了每个 agent 自己的工作指南文档
- 共创并持续更新了多 agents 协作 SOP 文档
- 串流程的 Hermes（主持人角色） 沉淀并更新了自己的经验教训文档
最后不到半天花光了价值 198 一个月的阿里百炼 token plan，勉强完成了：全部初始化工作（17 个项目 20 多篇笔记）+2 个 新增项目的解构、提炼、总结、借鉴
短期结论（后续可能再更新）：
想实现真正【便宜又实用】的【跨 workspace 多 agents 协作】，【目前】条件还不具备，得再等等
（但感兴趣又不差钱的，可以开始烧钱研究了
（subagent 和 agent swarm 在当下实操可行性明显更高
此前背景：核心是想用 LLM Wiki 那套方案管理维护一个垂类项目参考笔记。过去一个月历经 Claude 初始化、 OpenClaw 云端、OpenClaw 本地、Hermes 本地，最后想尝试本地三个 agents 在飞书群协作完成（这样可观测、不黑盒；Hermes 比 OpenClaw 更稳定负责）
核心思路：让 Hermes 管理、同步（相当于 CEO 助理），让 Claude/Codex 用 graphify 拆解 GitHub 项目
工作空间：本地文件夹，飞书文件夹，飞书群聊
日常流程大纲：
1. 我（用户）分享 GitHub 项目链接/微信公众号文章/其他网址或内容@Hermes；
2. Hermes 接收我发的内容，执行符合 LLM wiki 标准的 ingest， 沉淀在本地文件夹，然后：如果是 GitHub 项目，则一定单独发项目链接@Claude/Codex；如果是其他形式，酌情寻求 Claude/Codex 协助；
3. Claude/Codex 对 GitHub 项目执行 graphify（其他形式内容则是视具体情况调用工具），沉淀在本地文件夹（同一个项目的内容，命名需要有关联），然后告知 Hermes 位置和命名
4. Hermes 最终整合一个项目相关的全部笔记，同步到云端飞书文件夹
初始化工作（必须严格按顺序执行）：
1. Claude 将本地文件夹已记录的 GitHub 项目，依次执行 graphify，沉淀在本地文件夹（同一个项目的内容，命名需要有关联），然后告知 Hermes 位置和命名
2. Claude 将全部已有 GitHub 项目 graphify 完毕后，Hermes 再将本地文件夹已有内容，按 LLM wiki 标准整合更新
3. Hermes 将本地文件夹第一次整合更新后的内容，首次同步到飞书文件夹
4. Hermes 设置定时任务，每周六早上 5 点浏览、整理本地文件夹和飞书文件夹，检查是否同步统一、是否有遗留问题或任务，把结果发到本群，如果有需要做的事情则分工、有需要做的决策则讨论
整体原则：
- 后续都在飞书群协作，我（用户）、agents 通过互相@来协作
- 协作方式和经验教训，可以按实际情况沉淀和更新
- 如果遇到依赖缺失、外部需要、决策分歧、结果汇报，找我（用户）
一路上遇到了巨多问题，让 agents：
- 设计了每个 agent 自己的工作指南文档
- 共创并持续更新了多 agents 协作 SOP 文档
- 串流程的 Hermes（主持人角色） 沉淀并更新了自己的经验教训文档
最后不到半天花光了价值 198 一个月的阿里百炼 token plan，勉强完成了：全部初始化工作（17 个项目 20 多篇笔记）+2 个 新增项目的解构、提炼、总结、借鉴
短期结论（后续可能再更新）：
想实现真正【便宜又实用】的【跨 workspace 多 agents 协作】，【目前】条件还不具备，得再等等
（但感兴趣又不差钱的，可以开始烧钱研究了
（subagent 和 agent swarm 在当下实操可行性明显更高
10 13