即刻App年轻人的同好社区
下载
excalidraw mcp 来画插图，真的蛮好用的～～
我最近在做 Agent 课程，所以需要画大量插图来辅助讲明白一些概念。
之前用 chatgpt-image-2 来生成，但是有几个问题：
1. 速度会慢一些
2. 我最近遇到生图失败的概率越来越高了
现在给 codex 安装了 excalidraw mcp 来画插图，效果好很多，并且风格也更加一致。
画出来的图大概是如图 style～～
我最近在做 Agent 课程，所以需要画大量插图来辅助讲明白一些概念。
之前用 chatgpt-image-2 来生成，但是有几个问题：
1. 速度会慢一些
2. 我最近遇到生图失败的概率越来越高了
现在给 codex 安装了 excalidraw mcp 来画插图，效果好很多，并且风格也更加一致。
画出来的图大概是如图 style～～
1 10
通过最近的一个案例，分享一下使用 AI 的一个小技巧，关于提问时的「升纬」～
因为最近我在做一档面向开发人员的 Agent 课程，需要写非常多相关的课程代码和实验。其中有一个项目是关于智能客服 Agent 的例子，我当时让 AI 去帮我搜“Agent 客服”相关开源项目，并且要符合我各种各样的限制条件，比如必须有 Human-in-the-loop（人工环路）、必须用 LangGraph 和 LangChain 以及 Eval 等等。
但找了一圈之后，并没有找到完全符合我预期的项目，很多项目只能满足其中的几个点，如果我需要分散去投入去读这几个项目，然后再去写这个代码，就会很麻烦。
在这种情况下，我把我的问题往上升了一维。我想了下之所以要做这个事情，本质上是要通过这个项目把十几个知识点串起来，并且满足我对特定开发框架的偏好，至于它是不是“智能客服”其实并没有那么重要。
所以我重新修改了问题，让 AI 重新去执行，结果就找到了一个非常符合预期的项目。接下来，我只需要自己把这个项目的业务故事线改成智能客服系统就可以了，但是整体框架可以用这个项目作为很棒的参考。
因为最近我在做一档面向开发人员的 Agent 课程，需要写非常多相关的课程代码和实验。其中有一个项目是关于智能客服 Agent 的例子，我当时让 AI 去帮我搜“Agent 客服”相关开源项目，并且要符合我各种各样的限制条件，比如必须有 Human-in-the-loop（人工环路）、必须用 LangGraph 和 LangChain 以及 Eval 等等。
但找了一圈之后，并没有找到完全符合我预期的项目，很多项目只能满足其中的几个点，如果我需要分散去投入去读这几个项目，然后再去写这个代码，就会很麻烦。
在这种情况下，我把我的问题往上升了一维。我想了下之所以要做这个事情，本质上是要通过这个项目把十几个知识点串起来，并且满足我对特定开发框架的偏好，至于它是不是“智能客服”其实并没有那么重要。
所以我重新修改了问题，让 AI 重新去执行，结果就找到了一个非常符合预期的项目。接下来，我只需要自己把这个项目的业务故事线改成智能客服系统就可以了，但是整体框架可以用这个项目作为很棒的参考。
0 00
最近因为在做一门面向开发者的 Agent 课程，所以在 Codex 开了上百个 session 去做调研、跑 benchmark、写代码、准备各种素材。
但问题是 session 太多了，每个 session 关掉之后，我得想办法把它留作后续所用。我现在想到了一个简单的方法：
每个 session 结束之后，我就会让它大概总结一下这个 session 的内容（一般是 200 字以内），并带上 session ID。总结出这么一段话后，帮我放在 Obsidian 的一篇统一的素材管理文档中。
每个 session 都这么处理，这样也便于我非常方便地去整理这么多 session 积累下来的素材。
我觉得这个方法虽然简单，但还是蛮好用的。
之前离开 codex 用了一些的一些 agent，比如 raft 等等，发现真的很不成熟不稳定，小问题不断，并且做的有点复杂了，还是 codex app 稳一些。
但问题是 session 太多了，每个 session 关掉之后，我得想办法把它留作后续所用。我现在想到了一个简单的方法：
每个 session 结束之后，我就会让它大概总结一下这个 session 的内容（一般是 200 字以内），并带上 session ID。总结出这么一段话后，帮我放在 Obsidian 的一篇统一的素材管理文档中。
每个 session 都这么处理，这样也便于我非常方便地去整理这么多 session 积累下来的素材。
我觉得这个方法虽然简单，但还是蛮好用的。
之前离开 codex 用了一些的一些 agent，比如 raft 等等，发现真的很不成熟不稳定，小问题不断，并且做的有点复杂了，还是 codex app 稳一些。
0 00
之前看李诞的一本书，他提到“人都是为别人活着”，我觉得说的不错。
从我的经验来看，回忆起来有意义感的那些时刻或者事情，幸福指数都挺高的。其实在工作中和生活中，我都是能够收获挺多意义感的人，所以我觉得我还挺幸福的。
在生活中，我花了大量的时间去陪伴孩子，没有目的地去玩，所以现在小孩的性格非常开朗，即使我对他很严格，是经常扮演红脸的那个人，他也跟我非常亲近。
在工作中，我曾解决过前两任负责人都没有解决过的一个技术突破，留住了我们最大的一位客户。
因为我一直想的是不上班嘛。那我比较确定的一个是，虽然我要坚定地走不上班的路，但是通过我给家人或者更大的范围，做一些更有意义的事情，是不会停下的～
从我的经验来看，回忆起来有意义感的那些时刻或者事情，幸福指数都挺高的。其实在工作中和生活中，我都是能够收获挺多意义感的人，所以我觉得我还挺幸福的。
在生活中，我花了大量的时间去陪伴孩子，没有目的地去玩，所以现在小孩的性格非常开朗，即使我对他很严格，是经常扮演红脸的那个人，他也跟我非常亲近。
在工作中，我曾解决过前两任负责人都没有解决过的一个技术突破，留住了我们最大的一位客户。
因为我一直想的是不上班嘛。那我比较确定的一个是，虽然我要坚定地走不上班的路，但是通过我给家人或者更大的范围，做一些更有意义的事情，是不会停下的～
0 00
最近接触某些创业团队的产品，给我的一个感觉是：创始人的背景确实蛮好，但我觉得他们只想做一个很酷的产品，而不是：
1. 从用户视角出发，能让用户用起来觉得很顺畅、舒服，带来幸福感的产品
2. 从商业角度出发，能够带来持续、合理的商业回报的产品
所以你会看到，他们的定价策略奇奇怪怪，然后用户群里大家反馈的 bug 跟进之后就没下文了。
整体给我的感觉是：OK，你们很牛，但是我觉得从我的角度看来，你们没有那么靠谱
这种情况，即时产品形态看起来还不错，但我是不愿意花费时间在上面的～
1. 从用户视角出发，能让用户用起来觉得很顺畅、舒服，带来幸福感的产品
2. 从商业角度出发，能够带来持续、合理的商业回报的产品
所以你会看到，他们的定价策略奇奇怪怪，然后用户群里大家反馈的 bug 跟进之后就没下文了。
整体给我的感觉是：OK，你们很牛，但是我觉得从我的角度看来，你们没有那么靠谱
这种情况，即时产品形态看起来还不错，但我是不愿意花费时间在上面的～
1 50
其实 GPT Image 2 只要在提示词中稍微加一些修饰和引导，就能产出非常精美、让人赏心悦目的图片。
但是现在刷 Twitter 或者是刷公众号，看到的配图绝大部分还是那种默认的蓝色，配上一些 icon 以及文字，而且排版又非常稠密。现在这种图片看多了之后，整个人甚至都有种生理不适了。
但是现在刷 Twitter 或者是刷公众号，看到的配图绝大部分还是那种默认的蓝色，配上一些 icon 以及文字，而且排版又非常稠密。现在这种图片看多了之后，整个人甚至都有种生理不适了。
0 10
昨天还是这么多年来，第一次一天看两场电影。
第一场是中午那会儿趁宝宝睡午觉看的《欢迎来到龙餐馆》
，我觉得拍的真的很棒，无论是故事、画面还是声音，反正我觉得都挺难挑剔的。
第二场是趁宝宝睡觉之后去看的《奥德赛》，但我真的看不下去，坐了一个小时就提前走了。因为我真的看不太懂它要表达啥，叙事有点乱糟糟的，而且古希腊跟荷马的神话故事我也早就忘光了。对我来说看起来挺无聊的，想想不值得为它熬夜看，就提前撤了。
第一场是中午那会儿趁宝宝睡午觉看的《欢迎来到龙餐馆》
，我觉得拍的真的很棒，无论是故事、画面还是声音，反正我觉得都挺难挑剔的。
第二场是趁宝宝睡觉之后去看的《奥德赛》，但我真的看不下去，坐了一个小时就提前走了。因为我真的看不太懂它要表达啥，叙事有点乱糟糟的，而且古希腊跟荷马的神话故事我也早就忘光了。对我来说看起来挺无聊的，想想不值得为它熬夜看，就提前撤了。
0 00
今天看到刘小排发了一篇文章，标题是《AI 什么都会，我们为什么还要学习？》，我也来谈一下我的看法。
就拿我所在团队的一个例子来说，我们正在做一个 AI agent 的产品。后端跑一个 agent 去做事情，然后前端需要实时展示一些进展。
当时我们的工程师在和 AI 协作之后，产出的方案是：在 agent 的容器中把日志打印到容器，然后用另外一个进程去采集部分日志并存入数据库，最后前端再从数据库里面去轮询输出。
这样设计存在几个明显的问题：
1. 对用户来说体验不好：因为这不是流式输出，前端看起来会有非常明显的卡顿。
2. 日志丢失：很多日志其实没有被日志收集组件收集起来存入数据库，导致部分步骤能展示，部分步骤却无法展示。
但如果这个工程师有更好的架构视野，就会知道像这种工程问题，更合理的方案应该是：
1. 前端通过一个 API 向一个消息队列中投递任务。
2. 由一个任务的 worker 去消费这个消息，从而启动 agent。
3. agent 把实时的 chunk append 到 Redis stream 里面。
4. 给前端提供一个 SSE 接口，直接从 Redis stream 里面去读数据，实现实时流式输出。
之所以举这个例子，我是想说明两点：
第一，在一个领域内，如果你去学习、去看到的优秀方案足够多，你就大概会知道一个正确的、或者说一个好的方案应该是什么样子的。
第二，如果没有学习的积累，你其实无法很好地判断 AI 给出来的方案到底是一个优秀的方案，还是一个三流的方案，这完全就是把思考外包出去了。
就拿我所在团队的一个例子来说，我们正在做一个 AI agent 的产品。后端跑一个 agent 去做事情，然后前端需要实时展示一些进展。
当时我们的工程师在和 AI 协作之后，产出的方案是：在 agent 的容器中把日志打印到容器，然后用另外一个进程去采集部分日志并存入数据库，最后前端再从数据库里面去轮询输出。
这样设计存在几个明显的问题：
1. 对用户来说体验不好：因为这不是流式输出，前端看起来会有非常明显的卡顿。
2. 日志丢失：很多日志其实没有被日志收集组件收集起来存入数据库，导致部分步骤能展示，部分步骤却无法展示。
但如果这个工程师有更好的架构视野，就会知道像这种工程问题，更合理的方案应该是：
1. 前端通过一个 API 向一个消息队列中投递任务。
2. 由一个任务的 worker 去消费这个消息，从而启动 agent。
3. agent 把实时的 chunk append 到 Redis stream 里面。
4. 给前端提供一个 SSE 接口，直接从 Redis stream 里面去读数据，实现实时流式输出。
之所以举这个例子，我是想说明两点：
第一，在一个领域内，如果你去学习、去看到的优秀方案足够多，你就大概会知道一个正确的、或者说一个好的方案应该是什么样子的。
第二，如果没有学习的积累，你其实无法很好地判断 AI 给出来的方案到底是一个优秀的方案，还是一个三流的方案，这完全就是把思考外包出去了。
0 50