李继刚的提示词，从去年第一次见到觉得牛逼，到后来越来越觉得哪里怪怪的，直到今天豆瓣给我推了十多年前徐岑老师的这张专辑——看到这个名字顿时释然了。

倒是不认为评论中很多提到的「营销能力太强了」，而是「拿用户当傻子的勇气」及「拿自己羽毛当一次性雨衣的勇气」。

Structured Outputs 很实用，不过有个疑问，1.3.0 之后既然 HTTP 节点都支持 LLM 输出的 Object 了，为什么 Code 节点输出的 Object 还是不行呢？

「To start using gpt-image-1, verify your organization」，洗洗睡🙃

不能同意更多。

没错，刚好前几天 OpenAI 官方的 Cookbook 中也提到这个观点：AI engineering is inherently an empirical discipline——AI 工程本质上是一门经验学科。 cookbook.openai.com/examples/gpt4-…

从去年下半年的时候就开始思考企业在 AI 落地过程中 Human in the Loop or Human Out of the Loop 的问题，现在来看，过于激进的信奉 HITL 将要面对的不仅是技术、实现等细节问题，还要面临 AI 伦理如何平衡、长期竞争地位如何保持等宏观问题。

但是换个角度来考虑的话，在有大量文档的场景下，父子分块的意义就是通过子块提升检索的精准性，然后把父块内容给到模型，从而尽可能避免信息完整度的缺失。 换句话说，直接把文档给模型固然拥有完整的内容，但「正确的将哪一篇文章给到模型」，也是分块的意义之一。

去年才把 Mac 系列起步 RAM 提升到 16G，今年 Liquid Glass 就来了。

「ICL其实不是"学习新模式"，而是"唤起已记住的训练数据」这个总结的很精辟，请问方便发下来源吗，想去读一读全文。

+1 for "context engineering" over "prompt engineering". People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window

多轮对话场景中历史消息的提示位置效果：标准 API 多轮角色消息数组 > 填充到 User 中 > 填充到 System 中。

其实理论上讲，抛开模型层的训练或微调不说，当下的 LLM 应用开发者在工程层的所有努力，归根到底都是基于「模型是无状态的」这个第一定理做「上下文工程」，无论是 RAG 还是 Agent，无论是 Memory 还是 Toosl Call。

最初我也这么觉得，状态和上下文的维护做起来太麻烦。但现在觉得这种无状态的设定对开发者来说反而是提供了更大的灵活性，所以现在是倾向于工程层的东西模型层不要插手，开发者或第三方脚手架来做就行。

但 iOS 自带的 Photos 支持 iCloud，哪怕用了十年本地也可以只占 4GB 以下。

你当然可以拿「大多数人不懂 Markdown」为理由选择不做，但作为技术从业者，在不对「大多数人」造成打扰或增加心智负担的情况下，如果愿意花一些心思做一些可以「取悦自己和懂的人」的类似彩蛋的东西，那么会更受我的尊敬。 而且做到这一点至少技术上并不难。

一眼看上去像是背后有个毕赣在举着摄影机😂 让模型用毕赣的风格仿写了几句： 发明了电力就颠倒昼夜 发明了算法就真假难辨 像回到神谕通过铜线传递的年代 你模仿我的声音 有了智能就封存记忆 有了屏幕却瞎了双眼

这个分享真的很有价值，身边很多人好像都没思考过这一层，说到底一切的基础还是 completion，而 chat completion 只是新增了一层抽象，对开发者来说有时候是方便了，但又有很多时候失去了控制权。