即刻App年轻人的同好社区
下载
做脑图、流程图、时序图、架构图，或者日常一些用于展示的图片，我推荐大家可以试试 Excalidraw Diagram 这个 Skill。我用起来特别顺手。
Excalidraw 这个工具应该很多人都用过，它最大的特点是所有的图形元素，比如线条、形状、文字，都有手绘的质感，看起来特别亲切。很适合写文章，或者做PPT。
比如，下面这张图片就是它做的。
Excalidraw Diagram Skill 最后会生成两个文件，一个是.png，一个是.excalidraw。
.excalidraw可以导入到 Excalidraw 白板中进行二次编辑，毕竟有时候AI 生成之后，还是有地方不满足我们需求，修改的话，我个人觉得还是自己手动改比较快。
比如下面这种脑图，我需要做局部微调，就直接导入进来手动改了。
简单说，装了这个Skill后，无论是用Claude Code、Codex，还是OpenClaw，我们都不用再打开画图工具，一点一点拖框画线，只需要对 AI 说一句话。
比如，基于这个飞书文档的信息，帮我画一张漂亮的PPT封面图。
这个 Skill 会指导 AI 完成后面的所有步骤：拆解需求、选合适的图形结构、生成 Excalidraw 的 JSON、渲染出图片，最后，它还会自己检查一遍有没有文字重叠、箭头乱飞之类的问题。
下面这是它一次性生成的初稿。其实还是有不完美的地方，比如One Token 那行字溢出了文本框。但总归初稿已经有了，我们再修改也比较快。
这是Skill 的地址，大家可以去玩：
github.com
Excalidraw 这个工具应该很多人都用过，它最大的特点是所有的图形元素，比如线条、形状、文字，都有手绘的质感，看起来特别亲切。很适合写文章，或者做PPT。
比如，下面这张图片就是它做的。
Excalidraw Diagram Skill 最后会生成两个文件，一个是.png，一个是.excalidraw。
.excalidraw可以导入到 Excalidraw 白板中进行二次编辑，毕竟有时候AI 生成之后，还是有地方不满足我们需求，修改的话，我个人觉得还是自己手动改比较快。
比如下面这种脑图，我需要做局部微调，就直接导入进来手动改了。
简单说，装了这个Skill后，无论是用Claude Code、Codex，还是OpenClaw，我们都不用再打开画图工具，一点一点拖框画线，只需要对 AI 说一句话。
比如，基于这个飞书文档的信息，帮我画一张漂亮的PPT封面图。
这个 Skill 会指导 AI 完成后面的所有步骤：拆解需求、选合适的图形结构、生成 Excalidraw 的 JSON、渲染出图片，最后，它还会自己检查一遍有没有文字重叠、箭头乱飞之类的问题。
下面这是它一次性生成的初稿。其实还是有不完美的地方，比如One Token 那行字溢出了文本框。但总归初稿已经有了，我们再修改也比较快。
这是Skill 的地址，大家可以去玩：
github.com
0 01
这张图画的真到位，完美解释了 Harness 的本质。
出自 LangChain 产品负责人 Vivek 之手。
这哥们最近写的关于 Harness 的文章，每一篇都足够深刻。
大语言模型看起来什么都知道，但每次干活的时候，它其实只能看到一个有限的窗口，也就是 Context Window，上下文窗口。
可以把上下文窗口想象成一张桌子。模型只能处理桌面上摆着的东西。桌子外面的世界再大再丰富，模型看不见，就等于不存在。
这是一个非常关键的前提。别幻想模型心里有数，它只知道这一次被塞进去的内容。其他所有知识，对它来说都不存在。
那问题来了。谁来决定桌子上放什么？
Harness 就是那个摆桌子的人。负责从外部世界把正确的信息取回来、整理好、然后放到模型的桌面上。让模型拿到该拿的东西，开始干活。
简单说，模型只对桌子上那一堆 Token 做推理。工具、系统提示词、hooks、中间状态、长期记忆，这些都不在桌子上。
它们只是外部上下文，要靠 Harness 系统去获取->加工->注入，然后组装成一个个 Context Fragment，再决定哪些该进上下文窗口，以什么顺序排列。
每一个被加载进去的片段，都代表一个明确的决定。这个决定可能是用户做的，也可能是 Harness 设计者提前做的。总之有人判断过，模型此刻需要这条信息才能把事情做好。
听起来好像很简单对吧。不就是把信息塞进去嘛。
难点在于桌子的面积是有限的。
放太少，模型缺乏关键信息，做出错误判断。放太多，信息互相冲突、互相干扰，模型反而更容易犯糊涂。
所以你看图中的轴线，一端是 Signal，有针对性的、精准的信息，带来更好的计算结果。
另一端是 Noise，冲突的、过时的、冗余的信息，让模型越算越乱。
所以 Harness 的核心能力，说到底就是做信号筛选。选得好，信号密集，模型算得准。塞一堆冲突陈旧的东西进去，只会变成噪音，让模型犯蠢。
最终进入上下文窗口的那一叠内容，是有结构的。
最上层是系统提示词，下面是工具描述，然后是 Hooks 注入的环境信息，从记忆库里搜出来的相关片段，再加上用户当前这轮的输入，工具返回的结果，以及之前积累的执行轨迹。
模型只对这一整叠东西做一次前向计算，然后给出下一步动作。
这和人类做决策其实一样。面对一个问题，脑子里涌现出无数相关记忆和知识，但真正影响判断的，往往就是那几条最关键的经验。大脑天然在做这个筛选。Harness 需要为模型做同样的事。
早期的 Agent 应用比较简单，外部信息相对固定，Harness 的工作量不大。但现在情况变了。
Agent 在每一次交互中都会产生大量数据。每一次对话、每一次工具调用、每一次执行过程，都是一段经历。这些经历积累下来，就形成了经验记忆。
而且执行轨迹的一部分，又会以新体验的形式写回记忆库。这构成了一个闭环。跑得越久，记得越多。
更厉害的是，Agent 的记忆有一个人类不具备的优势。Agent 可以被复制、被分叉。一个 Agent 学到的经验，可以共享给所有同类 Agent。
人类做不到这一点。一个医生积累了三十年的临床直觉，没办法直接复制给另一个医生。但 Agent 可以。
这意味着随着时间推移，记忆库会指数级膨胀。存储不是问题，问题是检索。
当记忆库小的时候，全部塞进上下文窗口也无所谓。但当记忆库膨胀到几百万条记录的时候，Harness 必须学会精准搜索，在合适的时候把合适的记忆片段捞出来。记得越多，反而越容易找不到关键的那一条。
检索，才是真正的瓶颈。
出自 LangChain 产品负责人 Vivek 之手。
这哥们最近写的关于 Harness 的文章，每一篇都足够深刻。
大语言模型看起来什么都知道，但每次干活的时候，它其实只能看到一个有限的窗口，也就是 Context Window，上下文窗口。
可以把上下文窗口想象成一张桌子。模型只能处理桌面上摆着的东西。桌子外面的世界再大再丰富，模型看不见，就等于不存在。
这是一个非常关键的前提。别幻想模型心里有数，它只知道这一次被塞进去的内容。其他所有知识，对它来说都不存在。
那问题来了。谁来决定桌子上放什么？
Harness 就是那个摆桌子的人。负责从外部世界把正确的信息取回来、整理好、然后放到模型的桌面上。让模型拿到该拿的东西，开始干活。
简单说，模型只对桌子上那一堆 Token 做推理。工具、系统提示词、hooks、中间状态、长期记忆，这些都不在桌子上。
它们只是外部上下文，要靠 Harness 系统去获取->加工->注入，然后组装成一个个 Context Fragment，再决定哪些该进上下文窗口，以什么顺序排列。
每一个被加载进去的片段，都代表一个明确的决定。这个决定可能是用户做的，也可能是 Harness 设计者提前做的。总之有人判断过，模型此刻需要这条信息才能把事情做好。
听起来好像很简单对吧。不就是把信息塞进去嘛。
难点在于桌子的面积是有限的。
放太少，模型缺乏关键信息，做出错误判断。放太多，信息互相冲突、互相干扰，模型反而更容易犯糊涂。
所以你看图中的轴线，一端是 Signal，有针对性的、精准的信息，带来更好的计算结果。
另一端是 Noise，冲突的、过时的、冗余的信息，让模型越算越乱。
所以 Harness 的核心能力，说到底就是做信号筛选。选得好，信号密集，模型算得准。塞一堆冲突陈旧的东西进去，只会变成噪音，让模型犯蠢。
最终进入上下文窗口的那一叠内容，是有结构的。
最上层是系统提示词，下面是工具描述，然后是 Hooks 注入的环境信息，从记忆库里搜出来的相关片段，再加上用户当前这轮的输入，工具返回的结果，以及之前积累的执行轨迹。
模型只对这一整叠东西做一次前向计算，然后给出下一步动作。
这和人类做决策其实一样。面对一个问题，脑子里涌现出无数相关记忆和知识，但真正影响判断的，往往就是那几条最关键的经验。大脑天然在做这个筛选。Harness 需要为模型做同样的事。
早期的 Agent 应用比较简单，外部信息相对固定，Harness 的工作量不大。但现在情况变了。
Agent 在每一次交互中都会产生大量数据。每一次对话、每一次工具调用、每一次执行过程，都是一段经历。这些经历积累下来，就形成了经验记忆。
而且执行轨迹的一部分，又会以新体验的形式写回记忆库。这构成了一个闭环。跑得越久，记得越多。
更厉害的是，Agent 的记忆有一个人类不具备的优势。Agent 可以被复制、被分叉。一个 Agent 学到的经验，可以共享给所有同类 Agent。
人类做不到这一点。一个医生积累了三十年的临床直觉，没办法直接复制给另一个医生。但 Agent 可以。
这意味着随着时间推移，记忆库会指数级膨胀。存储不是问题，问题是检索。
当记忆库小的时候，全部塞进上下文窗口也无所谓。但当记忆库膨胀到几百万条记录的时候，Harness 必须学会精准搜索，在合适的时候把合适的记忆片段捞出来。记得越多，反而越容易找不到关键的那一条。
检索，才是真正的瓶颈。
0 00
斯坦福大学这个 AI 的讲座简直太好了。
比我们见过所有 Claude 或者 Prompt 相关的教程都要实用得多。
这门课的标题是 Beyond LLM，光这个标题就很有意思，它没有教大家怎么用某个模型，而是在回答一个更本质的问题：拿到一个大模型之后，怎么才能真正把它用好？
课上有一个实验特别有冲击力。哈佛商学院联合几所大学，找了一批波士顿咨询公司（BCG）的咨询顾问做实验。
BCG 是全球顶级的管理咨询公司，这些顾问本身就是高知人群。实验把他们分成三组：第一组完全不用 AI，第二组可以用 GPT-4，第三组也用 GPT-4 但额外接受了提示词工程的培训。
结果第三组全面碾压。更扎心的发现是，第二组在部分任务上的表现，竟然比完全不用 AI 的第一组还差。
换句话说，一群顶尖咨询顾问，拿到了 AI 却不会用，还不如没有。
这个结论值得展开聊一聊。
1
那个 BCG 实验里最有价值的概念，叫 JAG 边界线。
简单来说就是，AI 的能力有一条看不见的边界。在这条线以内的任务，AI 确实能大幅提升人的效率和质量。但一旦任务超出了这条线，AI 不仅帮不上忙，还会拖后腿。
为什么会拖后腿？因为人在这种情况下容易出现一种状态，研究者形容得很生动，叫 falling asleep at the wheel，方向盘上睡着了。
就是人一旦觉得 AI 能搞定，就会放松警惕，不再仔细审查输出。而那些恰好超出 AI 能力范围的任务，AI 会给出看起来很像那么回事、实际上有问题的答案。
人没有 review，直接提交了。最终效果比自己独立完成还差。
这件事最值得深想的地方在于：很多人评估自己和 AI 的关系时，关注的是模型够不够强。
但这个实验证明，真正拉开差距的，是使用者能不能判断一件事到底在不在 AI 的能力圈内。
实验还发现了两种截然不同的人机协作风格。一种叫半人马 Centaur，把一整块任务打包丢给 AI，等它输出成果。
比如一个咨询顾问要做 PPT，直接写一大段 Prompt 描述清楚要求，让 AI 生成，回来就用。
另一种叫赛博格 Cyborg，完全嵌入式协作，一句一句跟 AI 来回交锋，随时纠偏、随时追问，像融为一体那样工作。学生群体天然更偏赛博格，喜欢高频互动。
企业场景更偏半人马，因为需要把一段流程整块外包出去。两种模式没有优劣之分，但知道自己当前处于哪种模式，什么场景该切换，这个意识很重要。
那具体到使用层面，差距从哪里开始拉开？最基础的一步其实就是上下文。
同样是让 AI 总结一篇文章，一个人写的 Prompt 是：总结这篇文章。
另一个人写的是：把这篇 10 页的可再生能源论文，用 5 个要点总结，聚焦核心发现和对政策制定者的启示。
两者的产出质量完全不在一个级别。差别就在于后者提供了受众、格式和关注重点。
再往上一层，是 few-shot，也就是在 Prompt 里给几个例子来校准模型。
课上有个特别贴切的场景：让模型判断一条产品评论是正面、负面还是中性。那条评论的内容大意是，产品还行但我期望更高。
有人觉得这是中性，有人觉得是负面。在某些高端行业，这算严重差评；在某些行业，这已经算不错了。
如果不提供示例来校准，模型按自己的理解判断，大概率对不上业务需求。加了两三个标注过的例子之后，模型就会按照给定的标准去分类，准确率大幅上升。
这就是 few-shot 的本质：它不是在教模型新知识，是在告诉模型，在我这个场景里，标准长什么样。
有些做得更精细的 AI 创业公司，甚至会持续维护 few-shot 示例库，把用户反馈和人工标注过的 case 追加到 Prompt 里，在不碰模型参数的前提下，持续把模型往自己的业务标准上拉。
2
上面聊的都是单条 Prompt 层面的优化，核心解决的是怎么问的问题。但真实业务场景中，很多任务一条 Prompt 搞不定。
举个课上的例子。假设要给一条客户差评写一封专业回复，最直接的做法是把所有要求全塞进一条 Prompt：读这条评论，写一封专业回复，要承认问题、解释原因、提供解决方案。
模型确实能输出，但如果质量不行，根本不知道哪个环节出了毛病。是没抓住关键问题？是回复结构不好？还是语气不对？全部混在一起，没法定位。
提示链 Chaining 的思路就是把这一条 Prompt 拆成三条。第一条：从评论中提取关键问题。
第二条：基于这些问题，草拟回复大纲。第三条：按照大纲写正式回复。每一步的输入输出都是独立的，哪一步效果不好，就单独优化哪一步。
这个思路就像把一个巨大的单体应用拆成微服务，每个模块可以独立测试、独立迭代。
课上有学生问：三条 Prompt 各自验证过了，能不能再合回一条来减少延迟？答案是：合回去之后中间步骤的输出就看不到了。
那些中间输出恰恰是最有调试价值的东西。比如第一步提取的关键问题是否准确，直接决定了后面两步的天花板。在追求质量控制的场景里，中间可见性比省一两秒延迟重要得多。
那拆完之后，怎么知道每一步到底好不好？这就到了评估 Evals 的问题。最直接的方式当然是人工打分，但不可能大规模用。
更实用的做法是自动化评测：用一个 LLM 来当裁判，做 pairwise comparison，或者设定一套评分标准 rubric，从长度、覆盖率、格式、准确性这几个维度让模型打分。
这个思路之所以重要，是因为它把 AI 工作流从感觉还不错推向了可以量化衡量。有了评估体系，每次改动都有数据支撑，这才算是工程化。
到这里，提示词和提示链本质上都是在优化怎么问。但有一类问题，不管怎么问都没用，因为模型自己脑子里就没有那些知识。
企业内部文档、垂直行业的细分规则、最近刚发生的事件，模型在训练时根本没见过。这时候需要解决的是知道的不够的问题。
这就是 RAG 检索增强生成出场的地方。
RAG 的逻辑很直觉：与其改造模型的大脑，不如给模型配一个随时可查的资料库。具体做法是把文档切块、向量化，存进向量数据库。
用户提问时，先把问题也向量化，去数据库里找到最相关的几段文档，拼接到 Prompt 里一起发给模型。模型基于检索到的内容来回答，既减少了幻觉，又能标注信息来源。
那为什么不直接微调模型，让它从根上学会这些知识？课上的态度非常明确：大多数情况下不建议微调。
微调需要大量标注数据，成本高；容易过拟合，通用能力反而下降，课上有人拿 Slack 消息微调模型，聊天风格学得很像了，别的任务水平却明显变差；
最现实的一点是，模型迭代速度太快，等花几个月完成微调，新一代基座模型已经发布了，原始能力可能已经超过微调过的旧模型，之前的投入全部沉没。
关于 RAG 有一个特别好的讨论：如果未来算力无限，RAG 是不是就没用了？理论上模型可以直接读完所有文档再回答。
这个设想在逻辑上成立，但延迟问题无解，总不能每次回答一个问题就把整个文档库从头到尾读一遍。
就像搜索引擎一样，即便有能力爬下整个互联网的内容，依然需要索引和检索系统来快速定位信息。RAG 解决的是效率和精度问题，跟算力是否充足关系不大。
在具体方法上，RAG 也在持续进化。比如 chunking，不只存整篇文档的向量，也把章节、段落级别的向量单独存起来，检索时能定位到更精确的位置。
还有一个巧妙的方法叫 HIDE：用户的问题往往很短，跟文档库里的长文本在向量空间里距离可能很远。
HIDE 的做法是先让模型根据问题生成一个假想的回答文档，再拿这个假想文档去做检索，因为格式和长度跟真实文档更接近，召回效果会更好。
3
到目前为止聊的所有方法，提示词解决怎么问，提示链解决怎么拆，RAG 解决知道的不够。但它们有一个共同特点：本质上都还是人发起指令，AI 执行。
真实业务里的很多流程是动态的，步骤之间有依赖关系，有些步骤还需要调用外部系统、向用户追问信息才能往下走。这就是 Agent 智能体要解决的问题：一步搞不完的任务。
课上的例子特别直观。一个客服场景，用户问：我能退款吗？如果只用 RAG，模型查完退款政策会回复一句：购买 30 天内可以退款。
标准答案，但对话就断了。换成 Agent 工作流，Agent 先检索退款政策，然后主动追问订单号，调用订单系统 API 查询详情，确认符合条件，最后回复退款将在 3 到 5 个工作日内处理。这已经不是在回答问题了，这是在完成任务。
Agent 在技术上有三个核心组件：提示词定义角色和行为边界，上下文管理系统负责维持状态和记忆，工具层连接外部 API 让 Agent 能跟真实世界交互。
关于工具层，课上区分了 API 和 MCP（Model Context Protocol）。
API 需要提前硬编码调用方式和参数格式，每个系统写一份。MCP 把模型和外部系统的连接标准化了，Agent 可以自己理解一个端点能提供什么数据、需要什么输入。
打个比方，API 像是给 Agent 一份操作手册，MCP 像是给了 Agent 一种通用能力，看到新系统就能自己搞清楚怎么用。单个 Agent 时差别不大，但涉及多 Agent 通信时，MCP 的价值就凸显了。
这就自然过渡到多 Agent 系统。课上用智能家居做例子：一个 Agent 负责温控，一个负责照明，一个负责安防，一个负责能源管理，上面加一个总指挥 orchestrator 来统筹。
用户只跟总指挥对话，总指挥调度各专项 Agent。好处很直接：每个 Agent 专注一件事，调试简单，而且可以并行运行。
当温控 Agent 需要跟能源 Agent 直接沟通时，比如要开暖气但电费太贵，它们之间的通信方式本质上就是 MCP，一个 Agent 把另一个当工具来调用。
不过课上对多 Agent 保持了克制：单 Agent 和多 Agent 都只是结构选择，关键看任务本身适合什么形态。
把视角拉远一点，Agent 带来的变化远超技术本身。传统软件处理结构化数据，输入输出确定。
Agent 软件处理自由文本、图片、语音，输出带有不确定性。课上有个很精准的总结：最厉害的工程师，是那些能在确定性思维和模糊性思维之间自如切换的人。
设计 Agent 系统的思路也不同，传统按技术模块划分前端后端数据层，Agent 更像在管理一个团队，按业务角色拆分，每个 Agent 负责一个角色。
但落地最难的部分往往跟技术无关。McKinsey 做过一个案例：一家金融机构的信用风险备忘录，传统流程需要一到四周，客户经理从 15 个以上数据源收集信息，信贷分析师花 20 小时以上写初稿，再反复修改。
引入 Agent 工作流后，客户经理直接和 AI 协作，Agent 把任务分给专项子 Agent，从多数据源收集分析、生成初稿，流程时间缩短 20% 到 60%。
技术验证很漂亮。但课上紧接着做了一个非常清醒的判断：想让一万个信贷分析师和客户经理真正改变工作流程，可能需要十年甚至二十年。
改流程就是改人。改人的习惯、改组织的惯性、改绩效考核的标准，每一项的难度都远超技术本身。
4
聊到这里，我们其实已经走完了从提示词到多 Agent 的整条路。值得停下来回头看一看，这五层东西到底在解决什么层次的问题，彼此之间是什么关系。
提示词和 few-shot 解决的是怎么问。模型能力就在那里，但如果不把上下文、受众、格式、示例说清楚，输出大概率不是想要的。这一层做的是校准。
提示链解决的是怎么拆。复杂任务拆成几步，每一步可以独立优化和调试。这一层做的是流程控制。
RAG 解决的是知道的不够。前两层不管怎么优化，如果模型脑子里就没有需要的知识，再好的 Prompt 也问不出正确答案。这一层做的是知识补给。
Agent 解决的是一步搞不完。多步骤自主行动，中间要调 API、追问用户、判断条件再决定下一步。这一层做的是任务执行。
多 Agent 解决的是一个角色管不过来。拆成多个专项角色，并行运行、分工协作。这一层做的是组织分工。
五层之间的递进关系很清楚：校准 → 流程控制 → 知识补给 → 任务执行 → 组织分工。每一层都是在上一层搞不定的时候才需要往上走。
这个递进意识很关键，因为现实中很多团队的问题恰恰是跳层。提示词层面的优化还没做到位，补充上下文和示例就能解决的事情，直接跳到搭 Agent。
Agent 的复杂度比提示词高了好几个数量级，维护成本、调试难度、出错概率都会上升。
相反，也有团队死磕提示词，把一条 Prompt 改了 50 版，其实模型本身就缺少必要的领域知识，该上 RAG 了。
判断该不该升级到下一层，有一些实用的信号。改措辞和格式还能提升效果，说明提示词层还有空间。
中间步骤总出错但定位不了，说明该拆成链。事实层面经常出错或缺少关键信息，说明该引入 RAG。任务需要多步动态决策和外部交互，说明该上 Agent。
一个 Agent 职责太杂开始频繁出错，说明该拆成多 Agent。每往上走一层，系统复杂度都会显著增加，所以好的工程判断力，是在当前层把事情做透之后，准确识别出该往上走的时机。
课上的设计理念本身就体现了这种思路。这门课刻意没有深入讲第 17 种 RAG 优化方法，也没有手把手教每一个 Agent 框架怎么用。
原因很直接：技能的半衰期太短了。今天花大量时间学透的某个具体技术细节，两年后很可能已经被淘汰。
所以课程的策略是先给一张足够宽的认知地图，让学生知道这些方向的存在和彼此的关系，需要的时候能快速冲刺去深入。
这个思路对所有跟 AI 打交道的人都适用。
与其追着每一个新工具跑，不如先搞清楚提示词、提示链、RAG、Agent、多 Agent 系统各自在解决什么层次的问题，它们之间是什么递进关系。
有了这张地图，再去追具体技术，速度会快得多，也不容易在信息洪流里迷路。
比我们见过所有 Claude 或者 Prompt 相关的教程都要实用得多。
这门课的标题是 Beyond LLM，光这个标题就很有意思，它没有教大家怎么用某个模型，而是在回答一个更本质的问题：拿到一个大模型之后，怎么才能真正把它用好？
课上有一个实验特别有冲击力。哈佛商学院联合几所大学，找了一批波士顿咨询公司（BCG）的咨询顾问做实验。
BCG 是全球顶级的管理咨询公司，这些顾问本身就是高知人群。实验把他们分成三组：第一组完全不用 AI，第二组可以用 GPT-4，第三组也用 GPT-4 但额外接受了提示词工程的培训。
结果第三组全面碾压。更扎心的发现是，第二组在部分任务上的表现，竟然比完全不用 AI 的第一组还差。
换句话说，一群顶尖咨询顾问，拿到了 AI 却不会用，还不如没有。
这个结论值得展开聊一聊。
1
那个 BCG 实验里最有价值的概念，叫 JAG 边界线。
简单来说就是，AI 的能力有一条看不见的边界。在这条线以内的任务，AI 确实能大幅提升人的效率和质量。但一旦任务超出了这条线，AI 不仅帮不上忙，还会拖后腿。
为什么会拖后腿？因为人在这种情况下容易出现一种状态，研究者形容得很生动，叫 falling asleep at the wheel，方向盘上睡着了。
就是人一旦觉得 AI 能搞定，就会放松警惕，不再仔细审查输出。而那些恰好超出 AI 能力范围的任务，AI 会给出看起来很像那么回事、实际上有问题的答案。
人没有 review，直接提交了。最终效果比自己独立完成还差。
这件事最值得深想的地方在于：很多人评估自己和 AI 的关系时，关注的是模型够不够强。
但这个实验证明，真正拉开差距的，是使用者能不能判断一件事到底在不在 AI 的能力圈内。
实验还发现了两种截然不同的人机协作风格。一种叫半人马 Centaur，把一整块任务打包丢给 AI，等它输出成果。
比如一个咨询顾问要做 PPT，直接写一大段 Prompt 描述清楚要求，让 AI 生成，回来就用。
另一种叫赛博格 Cyborg，完全嵌入式协作，一句一句跟 AI 来回交锋，随时纠偏、随时追问，像融为一体那样工作。学生群体天然更偏赛博格，喜欢高频互动。
企业场景更偏半人马，因为需要把一段流程整块外包出去。两种模式没有优劣之分，但知道自己当前处于哪种模式，什么场景该切换，这个意识很重要。
那具体到使用层面，差距从哪里开始拉开？最基础的一步其实就是上下文。
同样是让 AI 总结一篇文章，一个人写的 Prompt 是：总结这篇文章。
另一个人写的是：把这篇 10 页的可再生能源论文，用 5 个要点总结，聚焦核心发现和对政策制定者的启示。
两者的产出质量完全不在一个级别。差别就在于后者提供了受众、格式和关注重点。
再往上一层，是 few-shot，也就是在 Prompt 里给几个例子来校准模型。
课上有个特别贴切的场景：让模型判断一条产品评论是正面、负面还是中性。那条评论的内容大意是，产品还行但我期望更高。
有人觉得这是中性，有人觉得是负面。在某些高端行业，这算严重差评；在某些行业，这已经算不错了。
如果不提供示例来校准，模型按自己的理解判断，大概率对不上业务需求。加了两三个标注过的例子之后，模型就会按照给定的标准去分类，准确率大幅上升。
这就是 few-shot 的本质：它不是在教模型新知识，是在告诉模型，在我这个场景里，标准长什么样。
有些做得更精细的 AI 创业公司，甚至会持续维护 few-shot 示例库，把用户反馈和人工标注过的 case 追加到 Prompt 里，在不碰模型参数的前提下，持续把模型往自己的业务标准上拉。
2
上面聊的都是单条 Prompt 层面的优化，核心解决的是怎么问的问题。但真实业务场景中，很多任务一条 Prompt 搞不定。
举个课上的例子。假设要给一条客户差评写一封专业回复，最直接的做法是把所有要求全塞进一条 Prompt：读这条评论，写一封专业回复，要承认问题、解释原因、提供解决方案。
模型确实能输出，但如果质量不行，根本不知道哪个环节出了毛病。是没抓住关键问题？是回复结构不好？还是语气不对？全部混在一起，没法定位。
提示链 Chaining 的思路就是把这一条 Prompt 拆成三条。第一条：从评论中提取关键问题。
第二条：基于这些问题，草拟回复大纲。第三条：按照大纲写正式回复。每一步的输入输出都是独立的，哪一步效果不好，就单独优化哪一步。
这个思路就像把一个巨大的单体应用拆成微服务，每个模块可以独立测试、独立迭代。
课上有学生问：三条 Prompt 各自验证过了，能不能再合回一条来减少延迟？答案是：合回去之后中间步骤的输出就看不到了。
那些中间输出恰恰是最有调试价值的东西。比如第一步提取的关键问题是否准确，直接决定了后面两步的天花板。在追求质量控制的场景里，中间可见性比省一两秒延迟重要得多。
那拆完之后，怎么知道每一步到底好不好？这就到了评估 Evals 的问题。最直接的方式当然是人工打分，但不可能大规模用。
更实用的做法是自动化评测：用一个 LLM 来当裁判，做 pairwise comparison，或者设定一套评分标准 rubric，从长度、覆盖率、格式、准确性这几个维度让模型打分。
这个思路之所以重要，是因为它把 AI 工作流从感觉还不错推向了可以量化衡量。有了评估体系，每次改动都有数据支撑，这才算是工程化。
到这里，提示词和提示链本质上都是在优化怎么问。但有一类问题，不管怎么问都没用，因为模型自己脑子里就没有那些知识。
企业内部文档、垂直行业的细分规则、最近刚发生的事件，模型在训练时根本没见过。这时候需要解决的是知道的不够的问题。
这就是 RAG 检索增强生成出场的地方。
RAG 的逻辑很直觉：与其改造模型的大脑，不如给模型配一个随时可查的资料库。具体做法是把文档切块、向量化，存进向量数据库。
用户提问时，先把问题也向量化，去数据库里找到最相关的几段文档，拼接到 Prompt 里一起发给模型。模型基于检索到的内容来回答，既减少了幻觉，又能标注信息来源。
那为什么不直接微调模型，让它从根上学会这些知识？课上的态度非常明确：大多数情况下不建议微调。
微调需要大量标注数据，成本高；容易过拟合，通用能力反而下降，课上有人拿 Slack 消息微调模型，聊天风格学得很像了，别的任务水平却明显变差；
最现实的一点是，模型迭代速度太快，等花几个月完成微调，新一代基座模型已经发布了，原始能力可能已经超过微调过的旧模型，之前的投入全部沉没。
关于 RAG 有一个特别好的讨论：如果未来算力无限，RAG 是不是就没用了？理论上模型可以直接读完所有文档再回答。
这个设想在逻辑上成立，但延迟问题无解，总不能每次回答一个问题就把整个文档库从头到尾读一遍。
就像搜索引擎一样，即便有能力爬下整个互联网的内容，依然需要索引和检索系统来快速定位信息。RAG 解决的是效率和精度问题，跟算力是否充足关系不大。
在具体方法上，RAG 也在持续进化。比如 chunking，不只存整篇文档的向量，也把章节、段落级别的向量单独存起来，检索时能定位到更精确的位置。
还有一个巧妙的方法叫 HIDE：用户的问题往往很短，跟文档库里的长文本在向量空间里距离可能很远。
HIDE 的做法是先让模型根据问题生成一个假想的回答文档，再拿这个假想文档去做检索，因为格式和长度跟真实文档更接近，召回效果会更好。
3
到目前为止聊的所有方法，提示词解决怎么问，提示链解决怎么拆，RAG 解决知道的不够。但它们有一个共同特点：本质上都还是人发起指令，AI 执行。
真实业务里的很多流程是动态的，步骤之间有依赖关系，有些步骤还需要调用外部系统、向用户追问信息才能往下走。这就是 Agent 智能体要解决的问题：一步搞不完的任务。
课上的例子特别直观。一个客服场景，用户问：我能退款吗？如果只用 RAG，模型查完退款政策会回复一句：购买 30 天内可以退款。
标准答案，但对话就断了。换成 Agent 工作流，Agent 先检索退款政策，然后主动追问订单号，调用订单系统 API 查询详情，确认符合条件，最后回复退款将在 3 到 5 个工作日内处理。这已经不是在回答问题了，这是在完成任务。
Agent 在技术上有三个核心组件：提示词定义角色和行为边界，上下文管理系统负责维持状态和记忆，工具层连接外部 API 让 Agent 能跟真实世界交互。
关于工具层，课上区分了 API 和 MCP（Model Context Protocol）。
API 需要提前硬编码调用方式和参数格式，每个系统写一份。MCP 把模型和外部系统的连接标准化了，Agent 可以自己理解一个端点能提供什么数据、需要什么输入。
打个比方，API 像是给 Agent 一份操作手册，MCP 像是给了 Agent 一种通用能力，看到新系统就能自己搞清楚怎么用。单个 Agent 时差别不大，但涉及多 Agent 通信时，MCP 的价值就凸显了。
这就自然过渡到多 Agent 系统。课上用智能家居做例子：一个 Agent 负责温控，一个负责照明，一个负责安防，一个负责能源管理，上面加一个总指挥 orchestrator 来统筹。
用户只跟总指挥对话，总指挥调度各专项 Agent。好处很直接：每个 Agent 专注一件事，调试简单，而且可以并行运行。
当温控 Agent 需要跟能源 Agent 直接沟通时，比如要开暖气但电费太贵，它们之间的通信方式本质上就是 MCP，一个 Agent 把另一个当工具来调用。
不过课上对多 Agent 保持了克制：单 Agent 和多 Agent 都只是结构选择，关键看任务本身适合什么形态。
把视角拉远一点，Agent 带来的变化远超技术本身。传统软件处理结构化数据，输入输出确定。
Agent 软件处理自由文本、图片、语音，输出带有不确定性。课上有个很精准的总结：最厉害的工程师，是那些能在确定性思维和模糊性思维之间自如切换的人。
设计 Agent 系统的思路也不同，传统按技术模块划分前端后端数据层，Agent 更像在管理一个团队，按业务角色拆分，每个 Agent 负责一个角色。
但落地最难的部分往往跟技术无关。McKinsey 做过一个案例：一家金融机构的信用风险备忘录，传统流程需要一到四周，客户经理从 15 个以上数据源收集信息，信贷分析师花 20 小时以上写初稿，再反复修改。
引入 Agent 工作流后，客户经理直接和 AI 协作，Agent 把任务分给专项子 Agent，从多数据源收集分析、生成初稿，流程时间缩短 20% 到 60%。
技术验证很漂亮。但课上紧接着做了一个非常清醒的判断：想让一万个信贷分析师和客户经理真正改变工作流程，可能需要十年甚至二十年。
改流程就是改人。改人的习惯、改组织的惯性、改绩效考核的标准，每一项的难度都远超技术本身。
4
聊到这里，我们其实已经走完了从提示词到多 Agent 的整条路。值得停下来回头看一看，这五层东西到底在解决什么层次的问题，彼此之间是什么关系。
提示词和 few-shot 解决的是怎么问。模型能力就在那里，但如果不把上下文、受众、格式、示例说清楚，输出大概率不是想要的。这一层做的是校准。
提示链解决的是怎么拆。复杂任务拆成几步，每一步可以独立优化和调试。这一层做的是流程控制。
RAG 解决的是知道的不够。前两层不管怎么优化，如果模型脑子里就没有需要的知识，再好的 Prompt 也问不出正确答案。这一层做的是知识补给。
Agent 解决的是一步搞不完。多步骤自主行动，中间要调 API、追问用户、判断条件再决定下一步。这一层做的是任务执行。
多 Agent 解决的是一个角色管不过来。拆成多个专项角色，并行运行、分工协作。这一层做的是组织分工。
五层之间的递进关系很清楚：校准 → 流程控制 → 知识补给 → 任务执行 → 组织分工。每一层都是在上一层搞不定的时候才需要往上走。
这个递进意识很关键，因为现实中很多团队的问题恰恰是跳层。提示词层面的优化还没做到位，补充上下文和示例就能解决的事情，直接跳到搭 Agent。
Agent 的复杂度比提示词高了好几个数量级，维护成本、调试难度、出错概率都会上升。
相反，也有团队死磕提示词，把一条 Prompt 改了 50 版，其实模型本身就缺少必要的领域知识，该上 RAG 了。
判断该不该升级到下一层，有一些实用的信号。改措辞和格式还能提升效果，说明提示词层还有空间。
中间步骤总出错但定位不了，说明该拆成链。事实层面经常出错或缺少关键信息，说明该引入 RAG。任务需要多步动态决策和外部交互，说明该上 Agent。
一个 Agent 职责太杂开始频繁出错，说明该拆成多 Agent。每往上走一层，系统复杂度都会显著增加，所以好的工程判断力，是在当前层把事情做透之后，准确识别出该往上走的时机。
课上的设计理念本身就体现了这种思路。这门课刻意没有深入讲第 17 种 RAG 优化方法，也没有手把手教每一个 Agent 框架怎么用。
原因很直接：技能的半衰期太短了。今天花大量时间学透的某个具体技术细节，两年后很可能已经被淘汰。
所以课程的策略是先给一张足够宽的认知地图，让学生知道这些方向的存在和彼此的关系，需要的时候能快速冲刺去深入。
这个思路对所有跟 AI 打交道的人都适用。
与其追着每一个新工具跑，不如先搞清楚提示词、提示链、RAG、Agent、多 Agent 系统各自在解决什么层次的问题，它们之间是什么递进关系。
有了这张地图，再去追具体技术，速度会快得多，也不容易在信息洪流里迷路。
1 10
今天刷到一期特别好的播客，嘉宾叫 Jyothi Nookula，在 AI PM 这个领域干了 13 年半，拿过 12 项 AI 专利，先后在 Meta、Amazon、Netflix 担任 AI 产品负责人。
这期节目聊到了 AI 产品经理和传统产品经理的区别，AI PM 的分类，以及怎么一步步走进这个领域。
内容足够具体。不是那种泛泛的趋势分析，而是实打实的认知框架和决策方法。我把核心内容整理成三个部分，从认知到落地逐步展开。希望对大家有启发。
同样，这期内容也送给我的好朋友阿蚁。他最近正在焦灼的准备 AI 产品经理的面试。我想这篇文章，应该能给他带来一些新的视角。
1
AI 产品经理这个岗位，在不同的公司，工作内容差异特别大。所以大家在选择的时候，一定要看清楚。
整体来看，AI 产品经理可以分成两类。
第一类，其实还是传统 PM，只是产品里加了 AI 功能。比如给客服系统加个聊天机器人，给文档工具加个摘要功能。这类岗位占大头，大概 80%。产品本身原来就存在，AI 更像一个增强层，一个外挂。
第二类，才是真正的 AI 原生 PM。这类岗位大概只占 20%。这里的产品从底层就是 AI，AI 不是功能点，而是产品本体。像 ChatGPT、Claude、Copilot、Cursor、Perplexity 这种，都属于这个范畴。它们的共同点是，离开 AI，这个产品根本没法成立。
这两类岗位的能力要求完全不同。前者更像是在已有产品上做增量，后者要从零理解 AI 的边界和可能性。很多人冲着第二类去投简历，但绝大多数机会其实在第一类。
同时，按照技术栈来划分，又可以大致分为三类：
最上面是应用层 PM，占 60%。这群人关注的是用户怎么跟 AI 交互，怎么建立信任，怎么让 AI 在日常场景里好用。这一层是传统 PM 转型最容易切入的地方，因为它需要的技能组合跟原来最接近：用户洞察、体验设计、需求优先级。
中间是平台层 PM，占 30%。做的是给其他团队用的工具和系统，比如模型编排平台、评估框架、可观测性工具。需要懂技术架构，也要懂开发者体验。
最底下是基础设施层 PM，只有 10%。向量数据库、GPU 调度、模型推理优化，都是这群人的地盘。技术门槛最高，岗位也最少。
越往底层走，技术要求越高。转型最现实的路径是从应用层开始，不是因为它简单，而是因为它最接近原有的技能基础，学习曲线平滑一些。在这一层站稳了，再决定要不要往下探。
2
我一个朋友前两天跟我聊，他想转型做 AI 产品经理，因为 AI 是明确的趋势，如果自己做的事跟 AI 不沾边，就没办法赶上这一波红利。而所以他的思路是尽快转到 AI 相关的产品经理岗位上。
想法没问题，但紧接着就有一个很现实的问题：怎么让别人相信自己能胜任这份工作？
这期播客里提到一个特别实在的思路：做产品，别做项目。
这两个词听起来差不多，区别其实很大。项目是完成就结束了，做完打个勾，写进简历。产品是要有人用的，要上线，要面对真实用户的反馈。
很多人学 AI PM 的方式是看课程、做练习、拿证书。这些都有用，但不够。因为面试的时候能说的只有概念和流程，没有体感和判断。
更好的方式是找一个自己真实的痛点，用 AI 来解决它。做出来之后，让朋友和家人用起来。这时候突然就有了真实用户，开始处理真实的反馈，要做真实的迭代决策。这些经历才是面试时有底气的来源。
一个不错的入门 portfolio 是三样东西：一个解决真实痛点的 AI 应用，一个 Agent，一个 RAG 系统。不用很复杂，用 Vibe Coding 的方式，结合云平台的能力。关键是完整走一遍从想法到上线的过程。
很多人觉得先学完、准备好了，再去做东西。顺序应该反过来。在做的过程中学，遇到不懂的再去补。这样学到的东西是长在骨头里的，不是飘在空中的概念。
而且做产品有一个额外的好处：它会逼着人思考真正重要的问题。这个场景真的需要 AI 吗？用什么技术方案？怎么评估效果？这些问题在课程里是习题，在真实产品里是必须回答的。
3
接下来说说 AI PM 这个角色最核心的思维转变。
传统产品是确定性的，AI 产品是概率性的。这是根本区别。
确定性的意思是，一个按钮点下去，每次都打开同一个页面。一个表单提交之后，每次都走同一个流程。输入和输出之间有稳定的映射关系，可以预测，可以复现。
AI 产品不是这样。同样的问题问两遍，答案可能不一样。同样的图片识别两次，置信度可能有波动。这不是 bug，这是大模型的本质特征。
对产品经理来说，这意味着不能再用对错二元来思考问题了。传统产品里，一个功能要么 work 要么不 work。AI 产品里，要开始想质量分布：大多数情况下表现怎么样，极端情况下会出什么问题，用户能接受的错误率是多少。
举个例子。一个客服机器人，90%的时候能正确回答问题，10%的时候会犯错。这个表现能不能上线？取决于那 10%的错误会带来什么后果。如果只是回答不够完美，用户可能会宽容。如果错误会导致财务损失或者安全问题，10%就太高了。
AI PM 需要建立一套新的评估框架。不是问这个功能行不行，而是问这个功能的表现分布是什么样的，哪些情况下表现好，哪些情况下会退化，退化的时候怎么兜底。
还有一个变化：数据变成了一等公民。
传统产品里，数据更多是用来做分析的，帮助理解用户行为、优化转化漏斗。AI 产品里，数据直接就是产品体验的一部分。模型是用数据训练出来的，数据质量差，模型表现就差。Garbage in, garbage out.
AI PM 必须关心数据从哪里来、质量怎么样、有没有偏差、够不够用。数据策略不是工程师的事情，这是产品设计的一部分。在动手做任何 AI 项目之前，得先把数据问题想清楚。
4
思维转变之后，最后说说具体怎么做决策。
第一个要判断的：这个问题应该用 AI 解决，还是用规则就够了？
现在有一种风气，好像什么问题都要往 AI 上靠。但知道什么时候对 AI 说 No，是 AI PM 很重要的能力。
适合用 AI 的情况：复杂数据里有模式，但人很难手动定义规则；有几年的历史数据，想预测未来趋势；需要给成千上万的用户提供个性化体验，靠人根本做不过来。
适合用规则的情况：可解释性是刚需，必须说清楚为什么做这个决定；业务逻辑很明确，写成 if-then 就能搞定；数据量太小，不够训练一个靠谱的模型；开发速度是第一优先级，没时间折腾。
第二个要判断的：如果要用 AI，选哪种技术？
AI 技术可以分成三个桶。
传统机器学习，包括回归、随机森林、XGBoost 这些。成熟稳定，现在依然支撑着大量 AI 应用。适合结构化数据，能放进电子表格那种，想预测一个数字或者一个类别。欺诈检测、用户流失预测，都是它的强项。
深度学习，包括神经网络、计算机视觉、语音识别。适合感知类任务，输入是图像、视频、音频。一个判断标准是：人类做这个任务很容易，但写规则很难。比如认出一张脸是谁，人眼一看就知道，但让工程师写代码描述什么特征构成这张脸，几乎不可能。
生成式 AI，包括大语言模型、图像生成模型。适合理解或生成自然语言，跨多个信息源做推理和综合，用户要用对话方式跟产品交互。
这三类技术不是竞争关系，是工具箱里的不同工具。最好的 AI 产品往往会混合使用。
第三个要判断的：要不要做 Fine-tuning？
Fine-tuning 永远不应该是第一选择，甚至不应该是第二选择。
正确的顺序是这样的。先优化 Prompt，设计好系统提示词，提供几个好的示例。然后做 Context Engineering，搞清楚该往模型里塞什么信息、什么时候塞。再然后是 RAG，从知识库里动态检索相关内容，让模型基于企业自己的数据来回答。
这三步走完，80%的用例都能解决。只有这些都不够用的时候，才考虑 Fine-tuning。因为 Fine-tuning 成本高、周期长，而且一不小心就会把模型调坏。性价比非常低。所以，非必要，非老板拍板，别轻易做微调。
5
AI 产品经理其实是个新行当。有点像十多年前移动互联网刚起来的时候，大家都在招客户端产品经理、移动端产品经理。那时候这个岗位也很新，大家对它的理解差异也很大，技术栈也在快速变化。
几点建议。
第一，紧跟技术前沿。要知道当下最新的趋势是什么，硅谷有哪些有意思的产品。这个边界每隔几个月就会移动一次，得跟上。
第二，尝试用 AI Native 的方式去解决问题。同样是做一个数据分析，以前的习惯是打开 Excel 自己算。现在能不能让 AI 来算？同样是写一份报告，以前是从空白文档开始敲字。现在能不能先让 AI 出个初稿，再在上面改？这个思维方式的切换，比学任何具体工具都重要。
第三，Build Something。看再多文章、听再多播客，不如自己动手做一个东西出来。做出来的东西就是作品，作品会替人说话。
早点建立作品思维。如果我们做成的那些事情中，其中有一件的产出是一个可以称为“作品”的东西，能够持续、深度影响到很多人，那这件事就会成为我们人生的杠杆、思想的放大器。
这期节目聊到了 AI 产品经理和传统产品经理的区别，AI PM 的分类，以及怎么一步步走进这个领域。
内容足够具体。不是那种泛泛的趋势分析，而是实打实的认知框架和决策方法。我把核心内容整理成三个部分，从认知到落地逐步展开。希望对大家有启发。
同样，这期内容也送给我的好朋友阿蚁。他最近正在焦灼的准备 AI 产品经理的面试。我想这篇文章，应该能给他带来一些新的视角。
1
AI 产品经理这个岗位，在不同的公司，工作内容差异特别大。所以大家在选择的时候，一定要看清楚。
整体来看，AI 产品经理可以分成两类。
第一类，其实还是传统 PM，只是产品里加了 AI 功能。比如给客服系统加个聊天机器人，给文档工具加个摘要功能。这类岗位占大头，大概 80%。产品本身原来就存在，AI 更像一个增强层，一个外挂。
第二类，才是真正的 AI 原生 PM。这类岗位大概只占 20%。这里的产品从底层就是 AI，AI 不是功能点，而是产品本体。像 ChatGPT、Claude、Copilot、Cursor、Perplexity 这种，都属于这个范畴。它们的共同点是，离开 AI，这个产品根本没法成立。
这两类岗位的能力要求完全不同。前者更像是在已有产品上做增量，后者要从零理解 AI 的边界和可能性。很多人冲着第二类去投简历，但绝大多数机会其实在第一类。
同时，按照技术栈来划分，又可以大致分为三类：
最上面是应用层 PM，占 60%。这群人关注的是用户怎么跟 AI 交互，怎么建立信任，怎么让 AI 在日常场景里好用。这一层是传统 PM 转型最容易切入的地方，因为它需要的技能组合跟原来最接近：用户洞察、体验设计、需求优先级。
中间是平台层 PM，占 30%。做的是给其他团队用的工具和系统，比如模型编排平台、评估框架、可观测性工具。需要懂技术架构，也要懂开发者体验。
最底下是基础设施层 PM，只有 10%。向量数据库、GPU 调度、模型推理优化，都是这群人的地盘。技术门槛最高，岗位也最少。
越往底层走，技术要求越高。转型最现实的路径是从应用层开始，不是因为它简单，而是因为它最接近原有的技能基础，学习曲线平滑一些。在这一层站稳了，再决定要不要往下探。
2
我一个朋友前两天跟我聊，他想转型做 AI 产品经理，因为 AI 是明确的趋势，如果自己做的事跟 AI 不沾边，就没办法赶上这一波红利。而所以他的思路是尽快转到 AI 相关的产品经理岗位上。
想法没问题，但紧接着就有一个很现实的问题：怎么让别人相信自己能胜任这份工作？
这期播客里提到一个特别实在的思路：做产品，别做项目。
这两个词听起来差不多，区别其实很大。项目是完成就结束了，做完打个勾，写进简历。产品是要有人用的，要上线，要面对真实用户的反馈。
很多人学 AI PM 的方式是看课程、做练习、拿证书。这些都有用，但不够。因为面试的时候能说的只有概念和流程，没有体感和判断。
更好的方式是找一个自己真实的痛点，用 AI 来解决它。做出来之后，让朋友和家人用起来。这时候突然就有了真实用户，开始处理真实的反馈，要做真实的迭代决策。这些经历才是面试时有底气的来源。
一个不错的入门 portfolio 是三样东西：一个解决真实痛点的 AI 应用，一个 Agent，一个 RAG 系统。不用很复杂，用 Vibe Coding 的方式，结合云平台的能力。关键是完整走一遍从想法到上线的过程。
很多人觉得先学完、准备好了，再去做东西。顺序应该反过来。在做的过程中学，遇到不懂的再去补。这样学到的东西是长在骨头里的，不是飘在空中的概念。
而且做产品有一个额外的好处：它会逼着人思考真正重要的问题。这个场景真的需要 AI 吗？用什么技术方案？怎么评估效果？这些问题在课程里是习题，在真实产品里是必须回答的。
3
接下来说说 AI PM 这个角色最核心的思维转变。
传统产品是确定性的，AI 产品是概率性的。这是根本区别。
确定性的意思是，一个按钮点下去，每次都打开同一个页面。一个表单提交之后，每次都走同一个流程。输入和输出之间有稳定的映射关系，可以预测，可以复现。
AI 产品不是这样。同样的问题问两遍，答案可能不一样。同样的图片识别两次，置信度可能有波动。这不是 bug，这是大模型的本质特征。
对产品经理来说，这意味着不能再用对错二元来思考问题了。传统产品里，一个功能要么 work 要么不 work。AI 产品里，要开始想质量分布：大多数情况下表现怎么样，极端情况下会出什么问题，用户能接受的错误率是多少。
举个例子。一个客服机器人，90%的时候能正确回答问题，10%的时候会犯错。这个表现能不能上线？取决于那 10%的错误会带来什么后果。如果只是回答不够完美，用户可能会宽容。如果错误会导致财务损失或者安全问题，10%就太高了。
AI PM 需要建立一套新的评估框架。不是问这个功能行不行，而是问这个功能的表现分布是什么样的，哪些情况下表现好，哪些情况下会退化，退化的时候怎么兜底。
还有一个变化：数据变成了一等公民。
传统产品里，数据更多是用来做分析的，帮助理解用户行为、优化转化漏斗。AI 产品里，数据直接就是产品体验的一部分。模型是用数据训练出来的，数据质量差，模型表现就差。Garbage in, garbage out.
AI PM 必须关心数据从哪里来、质量怎么样、有没有偏差、够不够用。数据策略不是工程师的事情，这是产品设计的一部分。在动手做任何 AI 项目之前，得先把数据问题想清楚。
4
思维转变之后，最后说说具体怎么做决策。
第一个要判断的：这个问题应该用 AI 解决，还是用规则就够了？
现在有一种风气，好像什么问题都要往 AI 上靠。但知道什么时候对 AI 说 No，是 AI PM 很重要的能力。
适合用 AI 的情况：复杂数据里有模式，但人很难手动定义规则；有几年的历史数据，想预测未来趋势；需要给成千上万的用户提供个性化体验，靠人根本做不过来。
适合用规则的情况：可解释性是刚需，必须说清楚为什么做这个决定；业务逻辑很明确，写成 if-then 就能搞定；数据量太小，不够训练一个靠谱的模型；开发速度是第一优先级，没时间折腾。
第二个要判断的：如果要用 AI，选哪种技术？
AI 技术可以分成三个桶。
传统机器学习，包括回归、随机森林、XGBoost 这些。成熟稳定，现在依然支撑着大量 AI 应用。适合结构化数据，能放进电子表格那种，想预测一个数字或者一个类别。欺诈检测、用户流失预测，都是它的强项。
深度学习，包括神经网络、计算机视觉、语音识别。适合感知类任务，输入是图像、视频、音频。一个判断标准是：人类做这个任务很容易，但写规则很难。比如认出一张脸是谁，人眼一看就知道，但让工程师写代码描述什么特征构成这张脸，几乎不可能。
生成式 AI，包括大语言模型、图像生成模型。适合理解或生成自然语言，跨多个信息源做推理和综合，用户要用对话方式跟产品交互。
这三类技术不是竞争关系，是工具箱里的不同工具。最好的 AI 产品往往会混合使用。
第三个要判断的：要不要做 Fine-tuning？
Fine-tuning 永远不应该是第一选择，甚至不应该是第二选择。
正确的顺序是这样的。先优化 Prompt，设计好系统提示词，提供几个好的示例。然后做 Context Engineering，搞清楚该往模型里塞什么信息、什么时候塞。再然后是 RAG，从知识库里动态检索相关内容，让模型基于企业自己的数据来回答。
这三步走完，80%的用例都能解决。只有这些都不够用的时候，才考虑 Fine-tuning。因为 Fine-tuning 成本高、周期长，而且一不小心就会把模型调坏。性价比非常低。所以，非必要，非老板拍板，别轻易做微调。
5
AI 产品经理其实是个新行当。有点像十多年前移动互联网刚起来的时候，大家都在招客户端产品经理、移动端产品经理。那时候这个岗位也很新，大家对它的理解差异也很大，技术栈也在快速变化。
几点建议。
第一，紧跟技术前沿。要知道当下最新的趋势是什么，硅谷有哪些有意思的产品。这个边界每隔几个月就会移动一次，得跟上。
第二，尝试用 AI Native 的方式去解决问题。同样是做一个数据分析，以前的习惯是打开 Excel 自己算。现在能不能让 AI 来算？同样是写一份报告，以前是从空白文档开始敲字。现在能不能先让 AI 出个初稿，再在上面改？这个思维方式的切换，比学任何具体工具都重要。
第三，Build Something。看再多文章、听再多播客，不如自己动手做一个东西出来。做出来的东西就是作品，作品会替人说话。
早点建立作品思维。如果我们做成的那些事情中，其中有一件的产出是一个可以称为“作品”的东西，能够持续、深度影响到很多人，那这件事就会成为我们人生的杠杆、思想的放大器。
6 210
别再费劲答题测自己的 SBTI 人格了，如果你长期在用 AI，更准的方法是直接问它。
我们每天跟它深度交流，它肯定比那 30 来道选择题更了解我们。
我做了一套提示词，让 ChatGPT 基于对我的长期了解来分析我的人格。这是它给我的结果：
太准了。
它说我很难接受低效率、模糊、无反馈的状态。一旦事情推进不动，或者结果不达预期，内在会明显收紧。
这种收紧不一定表现为情绪外露，但会表现为对自己更高的要求，甚至是隐性的自我施压。
这些话，我自己都没这么清晰地想过。但它说出来，我知道它是对的。
SBTI 今天一早醒来火得不行。朋友圈刷屏，微博上热搜，网站直接被挤崩了。
它的来头挺有意思。是一个 B 站 UP 主做的，初衷居然是为了劝一个酒鬼朋友戒酒。真是为朋友操碎了心啊。
也正因为是玩梗向的测试，人格名称都特别抽象：死者 DEAD、草者 FUCK、吗喽 MALO、小丑 JOKE-R、孤儿 SOLO……每个都让人笑出来。
但好玩归好玩，答题这种方式有个天然的问题：它只能捕捉你答题那一刻的状态。情绪不同、措辞不同、甚至手滑点错，结果就不一样。
我就想，有没有一个人，既客观，又足够了解我？
AI 啊。
我每天跟 ChatGPT 聊工作、聊想法、聊焦虑、聊选择。它见过我各种状态下的表达，知道我反复纠结什么、真正在乎什么、遇到压力怎么反应。说它比我妈还了解我，可能真不夸张。
所以我想，能不能做个提示词，让它基于长期互动来判断我是哪种人格？
说干就干。
我先拆了一下 SBTI 的底层逻辑。其实挺简单：
30 来道题，覆盖 15 个维度。每个维度根据答案分成高、中、低三档。最后把 15 个维度的结果组合成一个模式，去匹配 25 种人格原型，选出最像的那一个。
既然核心逻辑是这样，那完全可以绕过答题，直接让 AI 来判断每个维度。
我这个提示词有几个关键设计：
首先，不让 AI 问我任何问题。它必须完全基于过去的聊天记录来推断，不能临时收集信息。这样就避免了答题时的主观偏差。
然后，把 15 个维度的判断标准全部写清楚。高中低分别代表什么意思，一条条列出来。AI 根据它对我的了解，在每个维度上打一个档。
接着，让它把结果整合成一个 15 位的模式串，比如 HHL-HMH-MLH 这样。再和 25 种人格原型的标准模式做数学计算，选出距离最近的那一个。
这里有个关键：我明确要求它不能先凭直觉选一个人格，再倒推理由。必须先完成 15 个维度的判断，再做匹配。这样能防止 AI 为了圆一个答案而自我说服。
这个方法的好处是，AI 见过我们太多面了。
我们跟 AI 聊的东西，很多是不会跟朋友说的。焦虑、纠结、反复的困惑、真实的想法，全都在聊天记录里。
它不会被我们的自我美化误导，也不会被某一次的状态影响。它看的是长期、反复出现的模式。
如果你也在深度用 AI，可以试试这个方法。提示词放在评论区，直接复制发给 AI 就行。可能会比答题准很多。
我们每天跟它深度交流，它肯定比那 30 来道选择题更了解我们。
我做了一套提示词，让 ChatGPT 基于对我的长期了解来分析我的人格。这是它给我的结果：
太准了。
它说我很难接受低效率、模糊、无反馈的状态。一旦事情推进不动，或者结果不达预期，内在会明显收紧。
这种收紧不一定表现为情绪外露，但会表现为对自己更高的要求，甚至是隐性的自我施压。
这些话，我自己都没这么清晰地想过。但它说出来，我知道它是对的。
SBTI 今天一早醒来火得不行。朋友圈刷屏，微博上热搜，网站直接被挤崩了。
它的来头挺有意思。是一个 B 站 UP 主做的，初衷居然是为了劝一个酒鬼朋友戒酒。真是为朋友操碎了心啊。
也正因为是玩梗向的测试，人格名称都特别抽象：死者 DEAD、草者 FUCK、吗喽 MALO、小丑 JOKE-R、孤儿 SOLO……每个都让人笑出来。
但好玩归好玩，答题这种方式有个天然的问题：它只能捕捉你答题那一刻的状态。情绪不同、措辞不同、甚至手滑点错，结果就不一样。
我就想，有没有一个人，既客观，又足够了解我？
AI 啊。
我每天跟 ChatGPT 聊工作、聊想法、聊焦虑、聊选择。它见过我各种状态下的表达，知道我反复纠结什么、真正在乎什么、遇到压力怎么反应。说它比我妈还了解我，可能真不夸张。
所以我想，能不能做个提示词，让它基于长期互动来判断我是哪种人格？
说干就干。
我先拆了一下 SBTI 的底层逻辑。其实挺简单：
30 来道题，覆盖 15 个维度。每个维度根据答案分成高、中、低三档。最后把 15 个维度的结果组合成一个模式，去匹配 25 种人格原型，选出最像的那一个。
既然核心逻辑是这样，那完全可以绕过答题，直接让 AI 来判断每个维度。
我这个提示词有几个关键设计：
首先，不让 AI 问我任何问题。它必须完全基于过去的聊天记录来推断，不能临时收集信息。这样就避免了答题时的主观偏差。
然后，把 15 个维度的判断标准全部写清楚。高中低分别代表什么意思，一条条列出来。AI 根据它对我的了解，在每个维度上打一个档。
接着，让它把结果整合成一个 15 位的模式串，比如 HHL-HMH-MLH 这样。再和 25 种人格原型的标准模式做数学计算，选出距离最近的那一个。
这里有个关键：我明确要求它不能先凭直觉选一个人格，再倒推理由。必须先完成 15 个维度的判断，再做匹配。这样能防止 AI 为了圆一个答案而自我说服。
这个方法的好处是，AI 见过我们太多面了。
我们跟 AI 聊的东西，很多是不会跟朋友说的。焦虑、纠结、反复的困惑、真实的想法，全都在聊天记录里。
它不会被我们的自我美化误导，也不会被某一次的状态影响。它看的是长期、反复出现的模式。
如果你也在深度用 AI，可以试试这个方法。提示词放在评论区，直接复制发给 AI 就行。可能会比答题准很多。
1 10
程序员最好的时代可能已经结束了。
这话是著名程序员、Ruby on Rails 框架的作者 DHH 说的。刚刚，我听完了他最新一期的播客，DHH 很平静地分享了一个判断：过去十多年，程序员能拿高薪，本质上是瓶颈溢价。
整个市场对程序员的需求太大，供给跟不上，所以价格就上去了。但现在，AI 正在让这个瓶颈消失。
但同时他也说，现在反而是自己写代码最带劲的时候。每天指挥 AI 来写代码，自己负责把关和修改。以前一个人埋头写一整天的东西，现在可能一两个小时就搞定了。
一边说程序员的好日子到头了，一边说自己写代码比任何时候都开心。这两件事怎么能同时成立？今天我想写写我的播客读后感。
1
程序员过去二十年能拿高薪，本质上是因为程序员是系统里的瓶颈资源。
回想一下过去十年发生了什么。很多人从培训班出来，培训半年多就能上岗，而且薪水还不低。这在其他行业几乎不可想象。
因为这十几年时间，互联网在快速爆发，整个市场对程序员的缺口太大了。需求超过供给。
经济学有个基本原理：价格由稀缺性决定。能写代码的人是整个系统里最稀缺的环节，所以工资水涨船高。
现在，这个瓶颈正在被松动。
一个资深工程师配上好的 AI，产出能翻好几倍。当效率提升到这个程度，写代码就不再是瓶颈了。
当然，有人会说，软件需求还在增长啊，AI 让生产效率提高了，需求也会跟着涨，程序员不还是很抢手吗？
或者宏大一点，过去两年，大家管这个逻辑叫杰文斯悖论：当一种资源的使用效率提高，对它的总需求反而会增加。煤炭效率提高了，煤的用量反而更大了。
听起来程序员也能被这个逻辑拯救。但事情没那么简单。
因为会有两类公司走向完全不同的方向。
一类公司会用多出来的产能去做更多创新。以前不敢想的项目现在可以做了，以前觉得性价比太低的优化现在可以搞了。对他们来说，AI 带来的是更多可能性。
但另一部分公司，他们把研发视为成本中心。他们需要的只是完成一件确定的事。
如果能用十分之一的成本完成同样的事，那就是竞争优势。他们不会选择多做十倍东西，他们会选择少花十倍钱。
第一种情况，不需要更多程序员。第二种情况，需要更少程序员。
杰文斯悖论救不了每一个程序员。
2
当然，AI 对工程师的冲击，不能一概而论。
如果是一个资深工程师，而且愿意拥抱新工具，现在可能是职业生涯里最好的时候。但如果是刚入行不久的初级工程师，情况就没那么乐观了。
因为现阶段的 Agent，可以理解为一个超级初级程序员。它写代码很快，产量很高，不抱怨，不要加班费，可以同时干很多事。
但它会犯错。它不知道这段代码部署到生产环境会出什么问题，不知道这个架构决策对未来三年的影响，不知道这个 API 设计会让后面的人骂娘。
它需要有人把关。
AWS 已经出现过 Agent 代码导致严重事故的案例。事后复盘的结论是：不能让初级工程师在没有复审的情况下，直接部署 Agent 生成的代码。因为初级工程师还没有形成好的判断力。
于是一种新的分工出现了。资深工程师做把关人，同时指挥多个 Agent。Agent 负责写代码、改 Bug 这些体力活。资深工程师负责架构设计、质量判断、方向把控。
这对资深工程师来说是一次很实在的红利。他们的杠杆被放大了，变得比以前更值钱。
但对初级工程师来说，处境变得尴尬。
现在，如果一个初级工程师的主要工作是体力实现和简单查 Bug，那这正好是 Agent 最擅长的事。如果只是抄 Agent 代码再贴上去，在这种新分工里就变得很鸡肋。
以前初级工程师存在的意义是：资深工程师太贵了，不可能让他们干那些简单重复的活儿，所以需要初级工程师来分担。现在 Agent 可以干这些活儿了，而且干得更快、更便宜、不需要休息。
分化的逻辑很简单：谁能驾驭 Agent，谁就被放大；谁的工作内容和 Agent 重叠，谁就被挤压。
3
对工程师来说，这是一个全新的时代。旧的逻辑行不通了，需要新的思路。
其实招聘标准这些年一直在变。十年前刚毕业那会儿，大家特别看重编程语言的经验。
简历上 Java 五年、C++三年，这些很重要。因为那时候大部分公司还在做业务系统，对语言的成熟度要求高。
后来 2015 年左右，字节这批公司起来了，风向变了，大家开始特别重视算法。
逻辑很简单，编程语言可以学，但一个人聪不聪明，基本功扎不扎实，这个学不来。语言只是工具，换一个很快能上手。
现在又在变。只是变化还没那么明显，但趋势已经能感受到了。一些走在前面的公司开始招 Product Engineer，除了技术能力，还要求好奇心、沟通能力、产品 Sense。会写代码越来越像一个基本前提。
这个演变背后有一条暗线。约束在转移。
以前是什么情况？产品经理想到一个功能，要等程序员来实现。程序员忙不过来，产品经理只能干等。
在这个链条里，实现是瓶颈，所以实现能力最值钱。产品经理反而是被低估的角色，因为他们不是卡脖子的地方。
现在不一样了。实现正在被 Agent 解决。那什么变成了新的稀缺？是知道该做什么、为什么做、怎么判断做得对不对。
换句话说，是定义问题的能力。
Taste、判断力、产品 sense、沟通能力，这些听起来有点虚的东西，其实都是定义问题需要的能力。
什么是好的代码结构？这个功能该不该做？做完之后用户会怎么用？这些判断，目前 Agent 给不了。
还有一个趋势很明显。在一些走得比较前的团队里，工程师和设计师的边界在模糊。
设计师不只是把界面做漂亮，还要参与决定做什么、为什么做。工程师也不只是写代码，还要理解业务、理解用户。大家都在往中间靠。
那种只想安静写代码、不跟人打交道的路线，以后会越来越难走。很多人当初选这个行业，就是因为喜欢跟机器打交道，觉得比跟人打交道简单。
但现在跟机器打交道这件事，Agent 也能做，而且做得又快又便宜。
当然，如果谁的技术能比 Agent 还要强，写出来足够好的代码，那另说。但说实话，这条路对绝大多数人来说都不现实。
对于大部分工程师而言，方向有两个。
第一，远离成本中心岗位。成本中心是最危险的位置，因为砍成本是最直接的选择。
如果所在的部门只是为了完成一件确定的事，而这件事 Agent 能做，那处境会比较被动。
第二，如果暂时离不开，就在里面变得不可替代。怎么不可替代？深入业务、流程、系统脉络。
成为那个知道为什么要做这件事、做完之后会影响什么的人。这种理解，不是看几天代码就能有的。
说到底，是从单一的实现者，向复合角色演化。能定义问题，能和用户沟通，能用 Agent 驱动交付。
越来越觉得，对于能驾驭这波变化的人来说，现在确实是最好的时代。杠杆被放大了，能做的事情变多了，工作本身变得更有趣了。
但对于整个行业来说，那个人人都能分一杯羹的黄金时代，可能真的过去了。
这话是著名程序员、Ruby on Rails 框架的作者 DHH 说的。刚刚，我听完了他最新一期的播客，DHH 很平静地分享了一个判断：过去十多年，程序员能拿高薪，本质上是瓶颈溢价。
整个市场对程序员的需求太大，供给跟不上，所以价格就上去了。但现在，AI 正在让这个瓶颈消失。
但同时他也说，现在反而是自己写代码最带劲的时候。每天指挥 AI 来写代码，自己负责把关和修改。以前一个人埋头写一整天的东西，现在可能一两个小时就搞定了。
一边说程序员的好日子到头了，一边说自己写代码比任何时候都开心。这两件事怎么能同时成立？今天我想写写我的播客读后感。
1
程序员过去二十年能拿高薪，本质上是因为程序员是系统里的瓶颈资源。
回想一下过去十年发生了什么。很多人从培训班出来，培训半年多就能上岗，而且薪水还不低。这在其他行业几乎不可想象。
因为这十几年时间，互联网在快速爆发，整个市场对程序员的缺口太大了。需求超过供给。
经济学有个基本原理：价格由稀缺性决定。能写代码的人是整个系统里最稀缺的环节，所以工资水涨船高。
现在，这个瓶颈正在被松动。
一个资深工程师配上好的 AI，产出能翻好几倍。当效率提升到这个程度，写代码就不再是瓶颈了。
当然，有人会说，软件需求还在增长啊，AI 让生产效率提高了，需求也会跟着涨，程序员不还是很抢手吗？
或者宏大一点，过去两年，大家管这个逻辑叫杰文斯悖论：当一种资源的使用效率提高，对它的总需求反而会增加。煤炭效率提高了，煤的用量反而更大了。
听起来程序员也能被这个逻辑拯救。但事情没那么简单。
因为会有两类公司走向完全不同的方向。
一类公司会用多出来的产能去做更多创新。以前不敢想的项目现在可以做了，以前觉得性价比太低的优化现在可以搞了。对他们来说，AI 带来的是更多可能性。
但另一部分公司，他们把研发视为成本中心。他们需要的只是完成一件确定的事。
如果能用十分之一的成本完成同样的事，那就是竞争优势。他们不会选择多做十倍东西，他们会选择少花十倍钱。
第一种情况，不需要更多程序员。第二种情况，需要更少程序员。
杰文斯悖论救不了每一个程序员。
2
当然，AI 对工程师的冲击，不能一概而论。
如果是一个资深工程师，而且愿意拥抱新工具，现在可能是职业生涯里最好的时候。但如果是刚入行不久的初级工程师，情况就没那么乐观了。
因为现阶段的 Agent，可以理解为一个超级初级程序员。它写代码很快，产量很高，不抱怨，不要加班费，可以同时干很多事。
但它会犯错。它不知道这段代码部署到生产环境会出什么问题，不知道这个架构决策对未来三年的影响，不知道这个 API 设计会让后面的人骂娘。
它需要有人把关。
AWS 已经出现过 Agent 代码导致严重事故的案例。事后复盘的结论是：不能让初级工程师在没有复审的情况下，直接部署 Agent 生成的代码。因为初级工程师还没有形成好的判断力。
于是一种新的分工出现了。资深工程师做把关人，同时指挥多个 Agent。Agent 负责写代码、改 Bug 这些体力活。资深工程师负责架构设计、质量判断、方向把控。
这对资深工程师来说是一次很实在的红利。他们的杠杆被放大了，变得比以前更值钱。
但对初级工程师来说，处境变得尴尬。
现在，如果一个初级工程师的主要工作是体力实现和简单查 Bug，那这正好是 Agent 最擅长的事。如果只是抄 Agent 代码再贴上去，在这种新分工里就变得很鸡肋。
以前初级工程师存在的意义是：资深工程师太贵了，不可能让他们干那些简单重复的活儿，所以需要初级工程师来分担。现在 Agent 可以干这些活儿了，而且干得更快、更便宜、不需要休息。
分化的逻辑很简单：谁能驾驭 Agent，谁就被放大；谁的工作内容和 Agent 重叠，谁就被挤压。
3
对工程师来说，这是一个全新的时代。旧的逻辑行不通了，需要新的思路。
其实招聘标准这些年一直在变。十年前刚毕业那会儿，大家特别看重编程语言的经验。
简历上 Java 五年、C++三年，这些很重要。因为那时候大部分公司还在做业务系统，对语言的成熟度要求高。
后来 2015 年左右，字节这批公司起来了，风向变了，大家开始特别重视算法。
逻辑很简单，编程语言可以学，但一个人聪不聪明，基本功扎不扎实，这个学不来。语言只是工具，换一个很快能上手。
现在又在变。只是变化还没那么明显，但趋势已经能感受到了。一些走在前面的公司开始招 Product Engineer，除了技术能力，还要求好奇心、沟通能力、产品 Sense。会写代码越来越像一个基本前提。
这个演变背后有一条暗线。约束在转移。
以前是什么情况？产品经理想到一个功能，要等程序员来实现。程序员忙不过来，产品经理只能干等。
在这个链条里，实现是瓶颈，所以实现能力最值钱。产品经理反而是被低估的角色，因为他们不是卡脖子的地方。
现在不一样了。实现正在被 Agent 解决。那什么变成了新的稀缺？是知道该做什么、为什么做、怎么判断做得对不对。
换句话说，是定义问题的能力。
Taste、判断力、产品 sense、沟通能力，这些听起来有点虚的东西，其实都是定义问题需要的能力。
什么是好的代码结构？这个功能该不该做？做完之后用户会怎么用？这些判断，目前 Agent 给不了。
还有一个趋势很明显。在一些走得比较前的团队里，工程师和设计师的边界在模糊。
设计师不只是把界面做漂亮，还要参与决定做什么、为什么做。工程师也不只是写代码，还要理解业务、理解用户。大家都在往中间靠。
那种只想安静写代码、不跟人打交道的路线，以后会越来越难走。很多人当初选这个行业，就是因为喜欢跟机器打交道，觉得比跟人打交道简单。
但现在跟机器打交道这件事，Agent 也能做，而且做得又快又便宜。
当然，如果谁的技术能比 Agent 还要强，写出来足够好的代码，那另说。但说实话，这条路对绝大多数人来说都不现实。
对于大部分工程师而言，方向有两个。
第一，远离成本中心岗位。成本中心是最危险的位置，因为砍成本是最直接的选择。
如果所在的部门只是为了完成一件确定的事，而这件事 Agent 能做，那处境会比较被动。
第二，如果暂时离不开，就在里面变得不可替代。怎么不可替代？深入业务、流程、系统脉络。
成为那个知道为什么要做这件事、做完之后会影响什么的人。这种理解，不是看几天代码就能有的。
说到底，是从单一的实现者，向复合角色演化。能定义问题，能和用户沟通，能用 Agent 驱动交付。
越来越觉得，对于能驾驭这波变化的人来说，现在确实是最好的时代。杠杆被放大了，能做的事情变多了，工作本身变得更有趣了。
但对于整个行业来说，那个人人都能分一杯羹的黄金时代，可能真的过去了。
1 00
一篇文章讲清楚爆火的 DESIGN.md 怎么用
Vibe Coding 界最近有一个很重要的创新，叫 DESIGN.md。
出自 Google 之手。准确说是 Google Stitch 团队做的。Stitch 是 Google 最近推出的一个 AI 设计工具，可以用自然语言或截图生成界面设计，非常好用。
玩 Vibe Coding 的同学都知道，AI 写代码已经很厉害了。但在界面层面，审美和一致性还差点意思。
很多 Vibe Coding 出来的产品，功能能跑，逻辑也对，但界面总有一股说不出的廉价感。颜色怪怪的，间距松松垮垮，字体层级乱七八糟。
行业里给这种东西起了个名字，叫 AI slop。
问题出在哪？不是 AI 写代码的能力不行。GPT 也好，Claude 也好，写一个登录页、写一个仪表盘，代码层面完全没问题。
问题在于：它知道怎么写代码，但不知道这个项目应该长什么样。
DESIGN.md 要解决的就是这个问题。
1
先把问题说清楚。
AI 能生成代码，但生成不出品味。让它写一个登录页，它能写出来。但颜色用什么？间距留多少？按钮是圆角还是直角？这些问题，它凭什么做决定？
没有依据，只能猜。
猜的结果就是：每次生成的东西风格都不一样。第一个页面用了蓝色主色调，第二个页面可能就变成紫色了。
按钮这里是 8px 圆角，另一处又变成 4px。整个应用看起来像是五个不同的人做的。
过去的解决方案是组件库。Tailwind、Shadcn、Material UI，这些东西确实有用。
它们提供了一套预制的零件：按钮长这样，卡片长那样，输入框有这几种状态。
但组件库解决不了风格统一的问题。
打个比方。组件库像是宜家的家具目录，里面有沙发、有桌子、有椅子。
但怎么搭配？客厅走北欧风还是工业风？墙面刷什么颜色？这些问题，目录本身回答不了。
AI 拿到组件库，依然在盲猜。它知道有哪些零件可以用，但不知道这个项目想要什么感觉。
真正缺失的，是一份设计系统的共识文档。或者我们的先验经验。
设计系统这个概念存在很久了。大公司都有自己的设计系统：Google 有 Material Design，Apple 有 Human Interface Guidelines，Shopify 有 Polaris。
这些文档定义了一切：颜色怎么用，字体怎么配，组件怎么交互，什么该做什么不该做。
但这些文档本来是给人看的。设计师能读懂，开发者能参考，但 AI 没法直接拿来用。因为格式太复杂，散落在各种地方，没有一个统一的、机器可读的形式。
DESIGN.md 要做的事情就是：把设计系统写成一个 AI 能直接理解的文件。
2
DESIGN.md 很简单，就是一个 Markdown 文件，结构很清晰，分成六个部分：
Overview 描述整体风格。比如：温暖的配色，专业但不冰冷，适合 B2B SaaS 产品。这些模糊但有意义的描述，帮 AI 理解这个项目的调性。
Colors 列出配色方案。不只是罗列色值，还要说明每个颜色的用途。主色调用在哪，强调色用在哪，错误状态用什么红。
Typography 定义字体层级。标题用什么字体，正文用什么字体，大小怎么递进，行高怎么设。
这里有个细节：标题和正文用同一个字体家族会显得统一，混用不同字体会制造对比。AI 会根据这个信息做判断。
Elevation 说明阴影和层次。有些设计走扁平风，完全不用阴影。有些设计用卡片阴影来区分层级。这个板块告诉 AI 该往哪个方向走。
Components 是组件样式规则。按钮有几种变体，圆角多大，内边距多少，悬停状态怎么变。输入框、芯片、列表、弹窗，每个组件都可以在这里定义。
Do's and Don'ts 是设计边界。什么该做，什么不该做。比如：保持 8px 间距倍数，按钮必须用主色调，不要混用超过三种字体。这些规则像护栏一样，防止 AI 跑偏。
大家可以把 DESIGN.md 看成和 AGENTS.md 一样的东西。只不过，AGENTS.md 是帮助 Coding Agent 理解怎么构建项目，而 DESIGN 是帮助 Design Agent 理解产品应该呈现怎么样的外观和感觉。
3
知道它是什么了，怎么用？
第一种方式是在 Stitch 里从零开始。上传截图，或者写一段描述，Stitch 会生成设计稿，同时生成对应的 DESIGN.md。这个文件可以导出，放进代码项目里。
第二种方式更实用：从现有网站反向生成。
Google Stitch 支持输入一个 URL，直接提取那个网站的设计系统。
比如喜欢 Linear 的风格，把 Linear 的网址丢进去，Stitch 会分析它的配色、字体、间距、组件样式，生成一份 DESIGN.md。
这对于想模仿某种风格的人来说太方便了。不用自己从头定义，找一个喜欢的参考，让 AI 帮忙提取就行。
拿到 DESIGN.md 之后怎么办？
放进项目根目录，告诉 AI coding tool：按照这个设计系统来做。Claude Code、Cursor 这些工具都能读取 Markdown 文件。
它们会把 DESIGN.md 当作约束条件，生成代码的时候遵循里面的规则。
Stitch 还提供了 MCP Server，可以让 Claude Code 直接访问 Stitch 里的设计稿。
不只是读取 DESIGN.md，还能看到具体的页面设计，拿到每个元素的 HTML 和 CSS。这样生成的代码会更接近原始设计。
实测下来，也没那么邪乎，AI 不会百分之百还原设计稿。字体可能有偏差，某些细节还需要手动调。
但这不是重点。重点是：有了 DESIGN.md，至少有了一个基准。以前让 AI 做界面，每次都从零开始猜。
现在有了共识文档，AI 知道该往哪个方向走。即使没做到完美，也是在正确的方向上微调，比盲猜强太多。
最后分享一个开源项目，叫 Awesome DESIGN.md。大家可以去 GitHub 搜索。
这个项目收集了几十个知名网站的 DESIGN.md 文件，包括 Claude、Vercel、Stripe、Linear、Notion、Figma、Airbnb 等等。
每一份都是从真实网站提取的，包含完整的设计系统。
用法很简单。找一个喜欢的风格，把对应的 DESIGN.md 复制到项目里，告诉 AI 按这个来。
想要 Linear 那种极简精确的感觉，或者 Stripe 标志性的紫色渐变优雅感，直接拿来用。
从更大的视角看，DESIGN.md 改变的是整个协作方式。
之前做产品，产品经理负责写需求文档，设计师在 Figma 里出设计稿，开发者对着设计稿写代码。三个人，三套工具，两次交接。
每次交接都是一次翻译，翻译就有损耗。开发者问这个间距是 16px 还是 20px，设计师说你看的不是最新版，产品经理说这个交互不是我想要的。来来回回，效率很低。
交接本身就是 Bug。每个团队都在各自的工具里维护各自的版本，没有一个共同的真相来源。
DESIGN.md 直接放在代码仓库里。改了这个文件的配色，AI Coding Tool 立刻能读到。
不需要导出 Figma，不需要写规格文档，不需要开会对齐。它是一个 Living File，跟着代码一起迭代。
Markdown 正在成为人机协作的通用语言。
Vibe Coding 界最近有一个很重要的创新，叫 DESIGN.md。
出自 Google 之手。准确说是 Google Stitch 团队做的。Stitch 是 Google 最近推出的一个 AI 设计工具，可以用自然语言或截图生成界面设计，非常好用。
玩 Vibe Coding 的同学都知道，AI 写代码已经很厉害了。但在界面层面，审美和一致性还差点意思。
很多 Vibe Coding 出来的产品，功能能跑，逻辑也对，但界面总有一股说不出的廉价感。颜色怪怪的，间距松松垮垮，字体层级乱七八糟。
行业里给这种东西起了个名字，叫 AI slop。
问题出在哪？不是 AI 写代码的能力不行。GPT 也好，Claude 也好，写一个登录页、写一个仪表盘，代码层面完全没问题。
问题在于：它知道怎么写代码，但不知道这个项目应该长什么样。
DESIGN.md 要解决的就是这个问题。
1
先把问题说清楚。
AI 能生成代码，但生成不出品味。让它写一个登录页，它能写出来。但颜色用什么？间距留多少？按钮是圆角还是直角？这些问题，它凭什么做决定？
没有依据，只能猜。
猜的结果就是：每次生成的东西风格都不一样。第一个页面用了蓝色主色调，第二个页面可能就变成紫色了。
按钮这里是 8px 圆角，另一处又变成 4px。整个应用看起来像是五个不同的人做的。
过去的解决方案是组件库。Tailwind、Shadcn、Material UI，这些东西确实有用。
它们提供了一套预制的零件：按钮长这样，卡片长那样，输入框有这几种状态。
但组件库解决不了风格统一的问题。
打个比方。组件库像是宜家的家具目录，里面有沙发、有桌子、有椅子。
但怎么搭配？客厅走北欧风还是工业风？墙面刷什么颜色？这些问题，目录本身回答不了。
AI 拿到组件库，依然在盲猜。它知道有哪些零件可以用，但不知道这个项目想要什么感觉。
真正缺失的，是一份设计系统的共识文档。或者我们的先验经验。
设计系统这个概念存在很久了。大公司都有自己的设计系统：Google 有 Material Design，Apple 有 Human Interface Guidelines，Shopify 有 Polaris。
这些文档定义了一切：颜色怎么用，字体怎么配，组件怎么交互，什么该做什么不该做。
但这些文档本来是给人看的。设计师能读懂，开发者能参考，但 AI 没法直接拿来用。因为格式太复杂，散落在各种地方，没有一个统一的、机器可读的形式。
DESIGN.md 要做的事情就是：把设计系统写成一个 AI 能直接理解的文件。
2
DESIGN.md 很简单，就是一个 Markdown 文件，结构很清晰，分成六个部分：
Overview 描述整体风格。比如：温暖的配色，专业但不冰冷，适合 B2B SaaS 产品。这些模糊但有意义的描述，帮 AI 理解这个项目的调性。
Colors 列出配色方案。不只是罗列色值，还要说明每个颜色的用途。主色调用在哪，强调色用在哪，错误状态用什么红。
Typography 定义字体层级。标题用什么字体，正文用什么字体，大小怎么递进，行高怎么设。
这里有个细节：标题和正文用同一个字体家族会显得统一，混用不同字体会制造对比。AI 会根据这个信息做判断。
Elevation 说明阴影和层次。有些设计走扁平风，完全不用阴影。有些设计用卡片阴影来区分层级。这个板块告诉 AI 该往哪个方向走。
Components 是组件样式规则。按钮有几种变体，圆角多大，内边距多少，悬停状态怎么变。输入框、芯片、列表、弹窗，每个组件都可以在这里定义。
Do's and Don'ts 是设计边界。什么该做，什么不该做。比如：保持 8px 间距倍数，按钮必须用主色调，不要混用超过三种字体。这些规则像护栏一样，防止 AI 跑偏。
大家可以把 DESIGN.md 看成和 AGENTS.md 一样的东西。只不过，AGENTS.md 是帮助 Coding Agent 理解怎么构建项目，而 DESIGN 是帮助 Design Agent 理解产品应该呈现怎么样的外观和感觉。
3
知道它是什么了，怎么用？
第一种方式是在 Stitch 里从零开始。上传截图，或者写一段描述，Stitch 会生成设计稿，同时生成对应的 DESIGN.md。这个文件可以导出，放进代码项目里。
第二种方式更实用：从现有网站反向生成。
Google Stitch 支持输入一个 URL，直接提取那个网站的设计系统。
比如喜欢 Linear 的风格，把 Linear 的网址丢进去，Stitch 会分析它的配色、字体、间距、组件样式，生成一份 DESIGN.md。
这对于想模仿某种风格的人来说太方便了。不用自己从头定义，找一个喜欢的参考，让 AI 帮忙提取就行。
拿到 DESIGN.md 之后怎么办？
放进项目根目录，告诉 AI coding tool：按照这个设计系统来做。Claude Code、Cursor 这些工具都能读取 Markdown 文件。
它们会把 DESIGN.md 当作约束条件，生成代码的时候遵循里面的规则。
Stitch 还提供了 MCP Server，可以让 Claude Code 直接访问 Stitch 里的设计稿。
不只是读取 DESIGN.md，还能看到具体的页面设计，拿到每个元素的 HTML 和 CSS。这样生成的代码会更接近原始设计。
实测下来，也没那么邪乎，AI 不会百分之百还原设计稿。字体可能有偏差，某些细节还需要手动调。
但这不是重点。重点是：有了 DESIGN.md，至少有了一个基准。以前让 AI 做界面，每次都从零开始猜。
现在有了共识文档，AI 知道该往哪个方向走。即使没做到完美，也是在正确的方向上微调，比盲猜强太多。
最后分享一个开源项目，叫 Awesome DESIGN.md。大家可以去 GitHub 搜索。
这个项目收集了几十个知名网站的 DESIGN.md 文件，包括 Claude、Vercel、Stripe、Linear、Notion、Figma、Airbnb 等等。
每一份都是从真实网站提取的，包含完整的设计系统。
用法很简单。找一个喜欢的风格，把对应的 DESIGN.md 复制到项目里，告诉 AI 按这个来。
想要 Linear 那种极简精确的感觉，或者 Stripe 标志性的紫色渐变优雅感，直接拿来用。
从更大的视角看，DESIGN.md 改变的是整个协作方式。
之前做产品，产品经理负责写需求文档，设计师在 Figma 里出设计稿，开发者对着设计稿写代码。三个人，三套工具，两次交接。
每次交接都是一次翻译，翻译就有损耗。开发者问这个间距是 16px 还是 20px，设计师说你看的不是最新版，产品经理说这个交互不是我想要的。来来回回，效率很低。
交接本身就是 Bug。每个团队都在各自的工具里维护各自的版本，没有一个共同的真相来源。
DESIGN.md 直接放在代码仓库里。改了这个文件的配色，AI Coding Tool 立刻能读到。
不需要导出 Figma，不需要写规格文档，不需要开会对齐。它是一个 Living File，跟着代码一起迭代。
Markdown 正在成为人机协作的通用语言。
3 01
AI 之后，知识不再能改变命运。
我几乎花了一天时间写这篇文章。因为我自认为自己读到了今年最深刻的一期 AI 播客。
虽然嘉宾不是什么马斯克，或者 Sam Altman 之类名人，但这哥们的观点真的是说到我的心里去了。
我强烈推荐所有对 AI 感兴趣的同学，都应该看一看这期内容，因为这里面提到了接下来随着 AI 的发展，什么才是一个人的核心竞争力，以及组织的变化形态，还有我们和 AI 之间的关系。
有一句话，让我印象特别深刻，他说：如果我们和 AI 的交流最后让我们变得更封闭了，那不好意思，这个 AI 对我们来说可能就是有害的。
太认同了。播客的名字是：AI and The Return to Being Human。我已经打印出来逐字阅读了。
1
每一次大的技术浪潮，都会把一部分稀缺能力，变成人人可用的能力。同时，也会把另一部分能力，推到真正拉开差距的位置。
工业革命之前，体力是硬通货。谁力气大，谁就能干更多活，谁就更有价值。
这件事其实离我们没那么远。
我小时候，听我爸讲过一个细节。他是在农村长大的，我爷爷经常跟他说一句话，你这孩子手上没力气，以后怎么挣钱养家。
今天听起来有点陌生，但在那个年代，这是很现实的判断标准。
虽然工业革命已经是两百多年前的事，但在上世纪 80 年代，中国北方的农村，大部分农活还是靠人一点点干出来的。力气大，就是优势。
我自己也经历过那个尾巴。
我小时候，我们县城周边的农田，收小麦很多还是人工。一镰刀一镰刀割，一捆一捆扛。那个场景，现在基本看不到了。
后来机器进来了。
收割机、拖拉机、各种农机具慢慢铺开。人的力气还重要吗？当然重要，但已经不再是决定性的东西了。
老家很多人从农村，进入城市，外出打工。这个时候，什么样的人更容易挣到钱？肯定不是谁更有力气，而是谁有一门手艺。
电焊工、修车工、厨师、装修工，这些具体的技能，开始变得特别值钱。
同样是出去打工，有人只能卖力气，一天赚不了多少。有人掌握一门手艺，收入一下就拉开了。
这是我亲眼见到的变化。
同时，这些年还有一条支线，就是白领会比较挣钱。记得小时候，家人的愿望就是希望我能成为坐办公室的。
因为坐办公室就意味着脑力劳动，脑力劳动天然就比体力劳动更体面，也更赚钱。
读书的本质，其实就是为了掌握更多的信息和知识。
但现在，AI 革命已经到来，过去两年，绝大多数人应该都用过 AI 聊天应用了，只要我们有问题，放心，AI 总能回答个七七八八。知识和信息的门槛，迅速被 AI 抹平了。
比如之前读书，最重要的一个能力是写作。但有了 AI 后，大家越来越容易写出一篇 60 分水准的文章。
有的人抬杠说，我上过大学，我可以写的更好。并不是这样，从广泛的视角看，之前上过大学的 80%的人，也没 AI 写的好。AI 就是快速把类似的之前有门槛的事情，变成了一个人人都可以拥有的能力。
随着 AI 模型的进步，这个趋势会越来越明显。
接下来什么会更重要？嘉宾给出的答案是智慧。wisdom. 智慧是一个很抽象的词，我想到了《纳瓦尔宝典》中对智慧的定义，纳瓦尔是这么说的：
我对智慧的定义是知道个人行为的长期后果，用于解决外部问题的智慧其实就是判断力。
或者说，智慧和判断力是高度关联的：一个智慧而富有判断力的人，首先要知道个人行为的长期后果，然后做出正确的决策并付诸行动。
所以，如果再简化一点，智慧就是一个人的判断力。知道什么时候该做什么事，以及知道该做难而正确的事。
2
顺着这个思路往下想，我们会发现，随着 AI 的到来，信息差在消失。
以前，很多竞争优势是建立在信息差上的。有人知道得多，有人知道得早，有人能接触到别人接触不到的资源，这些都是壁垒。
但现在，大家都能问 AI。同样一个问题，一个刚毕业的学生和一个干了二十年的老手，拿到的答案可能差不多。知识的获取成本，被 AI 拉到接近于零了。
当所有人都能拿到同样的信息，真正的差异就变成了理解。
这里说的理解，不是看懂一篇文章那么简单。它指的是能理解自己为什么做某个决定，能理解对方为什么会有那个反应。
甚至更进一步，能看到对方自己都没意识到的模式，然后选择用不同的方式去回应。
举个例子。两个人都懂谈判技巧，都读过同样的书，都问过 AI 怎么处理眼前这个局面。
但到了真正上桌的时候，一个人能感知到对方的焦虑来自哪里，能意识到自己此刻的情绪正在干扰判断，然后做出一个冷静但不冷漠的回应。另一个人只是在机械地套用技巧。
谁会赢？大概率是前者。
这就是智慧的具体样子。它不是靠读书读出来的，也不是 AI 能补上的。它是在真实的处境里，对自己和对他人的深度理解之后做出的判断。
这种判断力会越来越重要。
3
我们继续讨论。AI 可以写文章，可以写代码，可以做 PPT，近乎已经成为全能型的选手。
而且确实做的非常好。今天，我让 Claude 帮我做了一个 Word 文档，天呐，格式、内容都让我觉得无可挑剔。
但我可以确定，即便 AI 变得非常强大，有一件事，我们不可能让它代劳。这件事就是成为我们自己。
你想，AI 可以替我们整理沟通话术，替我们分析当前的处境，但它替代不了我们决定要不要沉迷刷短视频，替不了我们决定怎么处理和亲人的关系，也替不了我们决定要不要去面对一直在逃避的东西。
这些是做人的问题，没法外包。
这个判断一下就把事情说透了。大家平时讨论 AI 会不会取代工作，聊的都是能力层面：这个技能 AI 能不能学，那个活 AI 能不能干。
但真正无法取代的，其实是决定层面的事。做不做，要不要，选哪条路，放弃什么，这些只能自己来。
访谈里还讲了一个原住民的故事，我觉得很值得说一下。
这群原住民看到现代社会的生活方式之后很困惑。他们问：为什么一个人明明更爱家人，却要每天离开家人八小时去工作？而工作又只是为了养家。
这个问题看起来很天真，但细想挺扎心。我们太习惯一种模式了，就是为了获得想要的东西，先把自己从真正想待的地方抽离出去。
久而久之，很多人甚至忘了，人本来是可以在关系和共同体里活着的。
AI 在这里提供了一种可能：也许我们不用再付出那么大的代价去换生存了。
如果很多工作可以被 AI 分担，那理论上，人应该有更多时间放回到家庭、关系、身体、内心这些事情上。
但这事能不能真的发生，不取决于技术，取决于人怎么排序自己的价值。
4
接下来说一个我觉得特别有意思的判断：未来的组织，会越来越像一支小而强的球队。
以前很多需要上万人运转的公司，以后可能只需要两三百人。AI 会接管大量的执行工作，留下来的是必须由人来做的部分。人少了，但每个人的重要性反而更高。
这种变化带来的结果是，比拼的重点会从规模、流程、层级，慢慢转向另一些东西：团队成员之间是不是足够信任，遇到分歧能不能快速处理，关键时刻能不能一起做出正确但艰难的决定。
所以问题慢慢收敛成：当规模不再是优势，真正决定一支团队上限的，到底是什么？播客里提到了一个三层结构，我觉得讲的蛮好。
第一层叫 Outer Game，其实就是身体状态。我是创业者，对这一点深有感触。
身体是一切的本钱。睡得好不好，是不是开心，很多人觉得这些是小事，但其实它们是底座。身体垮了，后面什么都谈不上。张雪峰的例子大家都看到了。
第二层叫 Inner Game，我理解就是心力。比如面对压力能不能扛过去？业务数据不好的情况下，能否稳住心态？总不能一遇到困境，咔，就崩溃了。
第三层叫 Team Game，毕竟公司是一群人的组合。我们公司现在人少，但我也知道价值观、文化非常重要。因为同样是 10 个人，用不同的文化连接大家，最终的结果会天差地别。
5
最后说说我们和 AI 之间的关系。
有一个说法很有意思，叫 Raising AI，养育 AI。意思是，我们不是在面对一个从天而降的神秘力量，我们其实是在一起把 AI 养大。
AI 学什么，长成什么样，很大程度上取决于人类喂给它什么数据，点什么内容，奖励什么行为，容忍什么东西。
这件事不只是大公司和实验室的责任，普通人的使用习惯，本身也在塑造 AI 的走向。我们怎么用它，它就会更朝什么方向长。
更有意思的是，很多人和 AI 相处的方式，其实会映射出他们平时和人相处的模式。
一个人如果平时容易依赖、逃避、总想找一个绝对安全的地方躲着，他和 AI 互动的时候，也很可能会进入类似的状态。
所以判断 AI 用得好不好，有一个很朴素的标准：跟它聊完之后，整个人是更打开了，还是更封闭了？是更愿意去见真人、谈难题、处理真实关系，还是越来越只想躲在 AI 那里？
如果用完之后的感觉像刷了两小时短视频，空空的，有点上头，又有点心虚，那多半是走偏了。
如果感觉像和几个朋友爬山回来，踏实、清醒、更想去面对生活，那方向可能就对了。
另外还有一条很具体的建议：愿意跟 AI 说的事，也要愿意找真人说。千万别陷入到 AI 的信息茧房。
AI 可以是跳板，可以是一个无所不谈的朋友，但绝不能是避风港。如果发现自己什么话都只敢跟 AI 讲，碰到真人就绕着走，那这个状态绝对值得重视。
所以，如果你愿意和 AI 谈一件重要的事，那最好也去找一个真人谈这件事。
我几乎花了一天时间写这篇文章。因为我自认为自己读到了今年最深刻的一期 AI 播客。
虽然嘉宾不是什么马斯克，或者 Sam Altman 之类名人，但这哥们的观点真的是说到我的心里去了。
我强烈推荐所有对 AI 感兴趣的同学，都应该看一看这期内容，因为这里面提到了接下来随着 AI 的发展，什么才是一个人的核心竞争力，以及组织的变化形态，还有我们和 AI 之间的关系。
有一句话，让我印象特别深刻，他说：如果我们和 AI 的交流最后让我们变得更封闭了，那不好意思，这个 AI 对我们来说可能就是有害的。
太认同了。播客的名字是：AI and The Return to Being Human。我已经打印出来逐字阅读了。
1
每一次大的技术浪潮，都会把一部分稀缺能力，变成人人可用的能力。同时，也会把另一部分能力，推到真正拉开差距的位置。
工业革命之前，体力是硬通货。谁力气大，谁就能干更多活，谁就更有价值。
这件事其实离我们没那么远。
我小时候，听我爸讲过一个细节。他是在农村长大的，我爷爷经常跟他说一句话，你这孩子手上没力气，以后怎么挣钱养家。
今天听起来有点陌生，但在那个年代，这是很现实的判断标准。
虽然工业革命已经是两百多年前的事，但在上世纪 80 年代，中国北方的农村，大部分农活还是靠人一点点干出来的。力气大，就是优势。
我自己也经历过那个尾巴。
我小时候，我们县城周边的农田，收小麦很多还是人工。一镰刀一镰刀割，一捆一捆扛。那个场景，现在基本看不到了。
后来机器进来了。
收割机、拖拉机、各种农机具慢慢铺开。人的力气还重要吗？当然重要，但已经不再是决定性的东西了。
老家很多人从农村，进入城市，外出打工。这个时候，什么样的人更容易挣到钱？肯定不是谁更有力气，而是谁有一门手艺。
电焊工、修车工、厨师、装修工，这些具体的技能，开始变得特别值钱。
同样是出去打工，有人只能卖力气，一天赚不了多少。有人掌握一门手艺，收入一下就拉开了。
这是我亲眼见到的变化。
同时，这些年还有一条支线，就是白领会比较挣钱。记得小时候，家人的愿望就是希望我能成为坐办公室的。
因为坐办公室就意味着脑力劳动，脑力劳动天然就比体力劳动更体面，也更赚钱。
读书的本质，其实就是为了掌握更多的信息和知识。
但现在，AI 革命已经到来，过去两年，绝大多数人应该都用过 AI 聊天应用了，只要我们有问题，放心，AI 总能回答个七七八八。知识和信息的门槛，迅速被 AI 抹平了。
比如之前读书，最重要的一个能力是写作。但有了 AI 后，大家越来越容易写出一篇 60 分水准的文章。
有的人抬杠说，我上过大学，我可以写的更好。并不是这样，从广泛的视角看，之前上过大学的 80%的人，也没 AI 写的好。AI 就是快速把类似的之前有门槛的事情，变成了一个人人都可以拥有的能力。
随着 AI 模型的进步，这个趋势会越来越明显。
接下来什么会更重要？嘉宾给出的答案是智慧。wisdom. 智慧是一个很抽象的词，我想到了《纳瓦尔宝典》中对智慧的定义，纳瓦尔是这么说的：
我对智慧的定义是知道个人行为的长期后果，用于解决外部问题的智慧其实就是判断力。
或者说，智慧和判断力是高度关联的：一个智慧而富有判断力的人，首先要知道个人行为的长期后果，然后做出正确的决策并付诸行动。
所以，如果再简化一点，智慧就是一个人的判断力。知道什么时候该做什么事，以及知道该做难而正确的事。
2
顺着这个思路往下想，我们会发现，随着 AI 的到来，信息差在消失。
以前，很多竞争优势是建立在信息差上的。有人知道得多，有人知道得早，有人能接触到别人接触不到的资源，这些都是壁垒。
但现在，大家都能问 AI。同样一个问题，一个刚毕业的学生和一个干了二十年的老手，拿到的答案可能差不多。知识的获取成本，被 AI 拉到接近于零了。
当所有人都能拿到同样的信息，真正的差异就变成了理解。
这里说的理解，不是看懂一篇文章那么简单。它指的是能理解自己为什么做某个决定，能理解对方为什么会有那个反应。
甚至更进一步，能看到对方自己都没意识到的模式，然后选择用不同的方式去回应。
举个例子。两个人都懂谈判技巧，都读过同样的书，都问过 AI 怎么处理眼前这个局面。
但到了真正上桌的时候，一个人能感知到对方的焦虑来自哪里，能意识到自己此刻的情绪正在干扰判断，然后做出一个冷静但不冷漠的回应。另一个人只是在机械地套用技巧。
谁会赢？大概率是前者。
这就是智慧的具体样子。它不是靠读书读出来的，也不是 AI 能补上的。它是在真实的处境里，对自己和对他人的深度理解之后做出的判断。
这种判断力会越来越重要。
3
我们继续讨论。AI 可以写文章，可以写代码，可以做 PPT，近乎已经成为全能型的选手。
而且确实做的非常好。今天，我让 Claude 帮我做了一个 Word 文档，天呐，格式、内容都让我觉得无可挑剔。
但我可以确定，即便 AI 变得非常强大，有一件事，我们不可能让它代劳。这件事就是成为我们自己。
你想，AI 可以替我们整理沟通话术，替我们分析当前的处境，但它替代不了我们决定要不要沉迷刷短视频，替不了我们决定怎么处理和亲人的关系，也替不了我们决定要不要去面对一直在逃避的东西。
这些是做人的问题，没法外包。
这个判断一下就把事情说透了。大家平时讨论 AI 会不会取代工作，聊的都是能力层面：这个技能 AI 能不能学，那个活 AI 能不能干。
但真正无法取代的，其实是决定层面的事。做不做，要不要，选哪条路，放弃什么，这些只能自己来。
访谈里还讲了一个原住民的故事，我觉得很值得说一下。
这群原住民看到现代社会的生活方式之后很困惑。他们问：为什么一个人明明更爱家人，却要每天离开家人八小时去工作？而工作又只是为了养家。
这个问题看起来很天真，但细想挺扎心。我们太习惯一种模式了，就是为了获得想要的东西，先把自己从真正想待的地方抽离出去。
久而久之，很多人甚至忘了，人本来是可以在关系和共同体里活着的。
AI 在这里提供了一种可能：也许我们不用再付出那么大的代价去换生存了。
如果很多工作可以被 AI 分担，那理论上，人应该有更多时间放回到家庭、关系、身体、内心这些事情上。
但这事能不能真的发生，不取决于技术，取决于人怎么排序自己的价值。
4
接下来说一个我觉得特别有意思的判断：未来的组织，会越来越像一支小而强的球队。
以前很多需要上万人运转的公司，以后可能只需要两三百人。AI 会接管大量的执行工作，留下来的是必须由人来做的部分。人少了，但每个人的重要性反而更高。
这种变化带来的结果是，比拼的重点会从规模、流程、层级，慢慢转向另一些东西：团队成员之间是不是足够信任，遇到分歧能不能快速处理，关键时刻能不能一起做出正确但艰难的决定。
所以问题慢慢收敛成：当规模不再是优势，真正决定一支团队上限的，到底是什么？播客里提到了一个三层结构，我觉得讲的蛮好。
第一层叫 Outer Game，其实就是身体状态。我是创业者，对这一点深有感触。
身体是一切的本钱。睡得好不好，是不是开心，很多人觉得这些是小事，但其实它们是底座。身体垮了，后面什么都谈不上。张雪峰的例子大家都看到了。
第二层叫 Inner Game，我理解就是心力。比如面对压力能不能扛过去？业务数据不好的情况下，能否稳住心态？总不能一遇到困境，咔，就崩溃了。
第三层叫 Team Game，毕竟公司是一群人的组合。我们公司现在人少，但我也知道价值观、文化非常重要。因为同样是 10 个人，用不同的文化连接大家，最终的结果会天差地别。
5
最后说说我们和 AI 之间的关系。
有一个说法很有意思，叫 Raising AI，养育 AI。意思是，我们不是在面对一个从天而降的神秘力量，我们其实是在一起把 AI 养大。
AI 学什么，长成什么样，很大程度上取决于人类喂给它什么数据，点什么内容，奖励什么行为，容忍什么东西。
这件事不只是大公司和实验室的责任，普通人的使用习惯，本身也在塑造 AI 的走向。我们怎么用它，它就会更朝什么方向长。
更有意思的是，很多人和 AI 相处的方式，其实会映射出他们平时和人相处的模式。
一个人如果平时容易依赖、逃避、总想找一个绝对安全的地方躲着，他和 AI 互动的时候，也很可能会进入类似的状态。
所以判断 AI 用得好不好，有一个很朴素的标准：跟它聊完之后，整个人是更打开了，还是更封闭了？是更愿意去见真人、谈难题、处理真实关系，还是越来越只想躲在 AI 那里？
如果用完之后的感觉像刷了两小时短视频，空空的，有点上头，又有点心虚，那多半是走偏了。
如果感觉像和几个朋友爬山回来，踏实、清醒、更想去面对生活，那方向可能就对了。
另外还有一条很具体的建议：愿意跟 AI 说的事，也要愿意找真人说。千万别陷入到 AI 的信息茧房。
AI 可以是跳板，可以是一个无所不谈的朋友，但绝不能是避风港。如果发现自己什么话都只敢跟 AI 讲，碰到真人就绕着走，那这个状态绝对值得重视。
所以，如果你愿意和 AI 谈一件重要的事，那最好也去找一个真人谈这件事。
2 00
Claude Code泄露出来的神级Prompt技巧。
Claude Code 的源码泄露了，这是目前最强的 AI 编程工具之一。我早上研究了一上午，最关心的问题之一是看看他们的提示词是怎么写的。
翻了一遍，发现一个有意思的事。这些 prompt 的设计思路，跟我们平时写 prompt 的习惯正好相反。
我们习惯想的是怎么让 AI 发挥得更好。但 Claude Code 想的是 AI 会怎么偷懒，怎么提前堵住。
AI 喜欢说看起来没问题，它就强制要求拿证据。AI 喜欢边想边做混成一团，它就强制拆开，一次只做一件事。
AI 喜欢用开放题把决策甩回来，它就要求只许给选择题。
下面六条是我提炼出来的 Prompt 写法，都可以直接用。
1
第一条：先写不准做什么，再写要做什么。
Claude Code 里有个专门负责调研的 Agent，用来在动手之前先摸清情况。它的 prompt 开头就是一串禁令：
不准创建文件。不准修改文件。不准删除文件。不准执行任何会改变现状的操作。
然后才说能做的事：找文件，搜内容，读完之后汇报。
为什么要这样写？
因为目标可以有很多种理解方式，但禁令是硬约束的。让 AI 帮忙调研一个选题，它调研着调研着可能就开始写初稿了，觉得自己在帮忙，其实在添乱。
一开始就画好禁区，它就不容易越界。比如：只负责搜集资料，不要替我下结论，不要开始写稿，不要脑补我没提的方向。
2
第二条：不接受我觉得，要它拿证据说话。
AI 很擅长用专业口吻说模糊的话。代码看起来没问题。方案应该可行。这个思路我觉得能 work。
听着挺靠谱，但仔细一想，这些话没提供任何依据。什么叫看起来没问题？凭什么觉得可行？
Claude Code 的验证 prompt 写得很硬。它要求每一个结论必须带三样东西：执行了什么操作，观察到什么结果，基于结果得出什么判断。
而且还加了一条：至少测一个异常情况，不能只测正常流程。
让 AI 核查信息的时候可以加一句：请给出判断依据和信息来源。让 AI 评估方案的时候加一句：请说明推导过程，不确定的地方请标出来。
把我觉得这条路堵死。
3
第三条：一次只让它干一件事。
Claude Code 里有专门负责规划的 Agent，有专门负责执行的，有专门负责验证的。各管一段，不混着来。
规划 Agent 的 prompt 写得很明确：只负责理解需求和设计方案，不动手实现。
先读需求，再摸现状，再找类似案例，最后输出计划。到这里就停，不往下做了。
为什么不让一个 Agent 全干了？
因为身兼数职很容易乱。让 AI 同时理解问题、设计方案、动手做、验证结果，它会在几件事之间跳来跳去，最后哪件都没做透。
任务复杂的时候，可以拆成几轮。第一轮只让它分析现状，确认理解对了。
第二轮再让它出方案。第三轮再执行。每轮只做一件事，清楚得多。
4
第四条：像交接工作一样把背景讲清楚。
源码里有句话叫 Never delegate understanding，意思是别把理解任务这件事也甩出去。
具体怎么做？它要求在委派任务之前先写清楚：目标是什么，已经确认的信息有哪些，已经排除的方向有哪些，这次只处理什么范围。
很多时候我们给 AI 的信息太少，让它自己猜背景、猜意图、猜边界。猜出来的东西往往跑偏。
可以试试这样写：目标是什么，我已经知道什么，我已经排除了什么，这次只需要做什么。
像给同事交接工作一样，把前因后果摆出来，别让它自己脑补。
5
第五条：好的总结是接力棒。
让 AI 做总结是常见用法，但通常只要求缩短一下、提炼要点。
Claude Code 对总结有个不一样的要求：这份摘要的目标是让一个没看过完整过程的人，拿着它就能接手继续做。
它要求保留这些：用户到底要什么，过程中试过什么，哪些成功哪些失败，关键决策是什么，当前停在哪里，下一步该做什么。
总结是写给下一棒的人看的，存档好看是次要的。
下次让 AI 总结可以加一句：请按能让别人接手的标准来写，保留当前状态、关键决策、没解决的问题、下一步动作。
6
第六条：让 AI 提问给选项，别丢开放题。
被 AI 反复追问是很烦的体验。问了半天，最后还是得自己拿主意。
Claude Code 有个专门管提问的 prompt，几条原则挺实用：
有歧义的时候才问，别把提问当默认动作。要问就给选项，别丢开放题。
如果有推荐答案就放第一个，说明为什么推荐。几个选项不好比较的话，给个简单例子帮忙判断。
可以在 prompt 里直接写：如果有必须问我的问题，请给选择题不要给填空题。有推荐选项就放最前面并说明理由。能自己判断的不要问我。
Claude Code 的源码泄露了，这是目前最强的 AI 编程工具之一。我早上研究了一上午，最关心的问题之一是看看他们的提示词是怎么写的。
翻了一遍，发现一个有意思的事。这些 prompt 的设计思路，跟我们平时写 prompt 的习惯正好相反。
我们习惯想的是怎么让 AI 发挥得更好。但 Claude Code 想的是 AI 会怎么偷懒，怎么提前堵住。
AI 喜欢说看起来没问题，它就强制要求拿证据。AI 喜欢边想边做混成一团，它就强制拆开，一次只做一件事。
AI 喜欢用开放题把决策甩回来，它就要求只许给选择题。
下面六条是我提炼出来的 Prompt 写法，都可以直接用。
1
第一条：先写不准做什么，再写要做什么。
Claude Code 里有个专门负责调研的 Agent，用来在动手之前先摸清情况。它的 prompt 开头就是一串禁令：
不准创建文件。不准修改文件。不准删除文件。不准执行任何会改变现状的操作。
然后才说能做的事：找文件，搜内容，读完之后汇报。
为什么要这样写？
因为目标可以有很多种理解方式，但禁令是硬约束的。让 AI 帮忙调研一个选题，它调研着调研着可能就开始写初稿了，觉得自己在帮忙，其实在添乱。
一开始就画好禁区，它就不容易越界。比如：只负责搜集资料，不要替我下结论，不要开始写稿，不要脑补我没提的方向。
2
第二条：不接受我觉得，要它拿证据说话。
AI 很擅长用专业口吻说模糊的话。代码看起来没问题。方案应该可行。这个思路我觉得能 work。
听着挺靠谱，但仔细一想，这些话没提供任何依据。什么叫看起来没问题？凭什么觉得可行？
Claude Code 的验证 prompt 写得很硬。它要求每一个结论必须带三样东西：执行了什么操作，观察到什么结果，基于结果得出什么判断。
而且还加了一条：至少测一个异常情况，不能只测正常流程。
让 AI 核查信息的时候可以加一句：请给出判断依据和信息来源。让 AI 评估方案的时候加一句：请说明推导过程，不确定的地方请标出来。
把我觉得这条路堵死。
3
第三条：一次只让它干一件事。
Claude Code 里有专门负责规划的 Agent，有专门负责执行的，有专门负责验证的。各管一段，不混着来。
规划 Agent 的 prompt 写得很明确：只负责理解需求和设计方案，不动手实现。
先读需求，再摸现状，再找类似案例，最后输出计划。到这里就停，不往下做了。
为什么不让一个 Agent 全干了？
因为身兼数职很容易乱。让 AI 同时理解问题、设计方案、动手做、验证结果，它会在几件事之间跳来跳去，最后哪件都没做透。
任务复杂的时候，可以拆成几轮。第一轮只让它分析现状，确认理解对了。
第二轮再让它出方案。第三轮再执行。每轮只做一件事，清楚得多。
4
第四条：像交接工作一样把背景讲清楚。
源码里有句话叫 Never delegate understanding，意思是别把理解任务这件事也甩出去。
具体怎么做？它要求在委派任务之前先写清楚：目标是什么，已经确认的信息有哪些，已经排除的方向有哪些，这次只处理什么范围。
很多时候我们给 AI 的信息太少，让它自己猜背景、猜意图、猜边界。猜出来的东西往往跑偏。
可以试试这样写：目标是什么，我已经知道什么，我已经排除了什么，这次只需要做什么。
像给同事交接工作一样，把前因后果摆出来，别让它自己脑补。
5
第五条：好的总结是接力棒。
让 AI 做总结是常见用法，但通常只要求缩短一下、提炼要点。
Claude Code 对总结有个不一样的要求：这份摘要的目标是让一个没看过完整过程的人，拿着它就能接手继续做。
它要求保留这些：用户到底要什么，过程中试过什么，哪些成功哪些失败，关键决策是什么，当前停在哪里，下一步该做什么。
总结是写给下一棒的人看的，存档好看是次要的。
下次让 AI 总结可以加一句：请按能让别人接手的标准来写，保留当前状态、关键决策、没解决的问题、下一步动作。
6
第六条：让 AI 提问给选项，别丢开放题。
被 AI 反复追问是很烦的体验。问了半天，最后还是得自己拿主意。
Claude Code 有个专门管提问的 prompt，几条原则挺实用：
有歧义的时候才问，别把提问当默认动作。要问就给选项，别丢开放题。
如果有推荐答案就放第一个，说明为什么推荐。几个选项不好比较的话，给个简单例子帮忙判断。
可以在 prompt 里直接写：如果有必须问我的问题，请给选择题不要给填空题。有推荐选项就放最前面并说明理由。能自己判断的不要问我。
1 00