No.91 Kaiyi几十场AI面试后的总结：怎么成为懂 AI 的人
节目简介 本期节目在中关村创业大街线下录制，迎来时隔一年多的重磅嘉宾开翼——刚从加拿大微软归来，带着 GitHub Copilot 团队的一线实战经验。四位技术人深度拆解大模型的工作原理：从 Temperature 参数如何影响创造力，到 Cache 机制为何能让 API 便宜这么多；从 RAG 的完整最佳实践，到为什么大公司做不好大模型；从 AI 时代"2000 行单文件"的新开发范式，到程序员未来 1-5 年的动荡期预判。这不是科普向的入门课，而是一线工程师用真金白银试出来的实战经验分享。 本期要闻 1. Temperature 参数的真相：创造力与稳定性的博弈 开翼从大模型的基本原理讲起：模型本质是"下一个词预测器"，每次生成时会输出多个候选词及其概率。Temperature 参数决定了选词策略——设为 0 时模型会 100% 选择概率最高的词，输出稳定但呆板；设得越大，模型越可能选择低概率词，创造力提升但不确定性增加。 "如果你的 temperature 设成 0，它百分之百会选择概率最大的词。所以它表现出来给我们的感觉就它变得呆板，创造力低，但是非常的稳定。" —— Kaiyi 实战经验表明：翻译、数学题等需要精确输出的场景应将 temperature 设到最低；而写小说、创意文案等需要发散思维的场景则应调高。这个参数揭示了 AI 应用的核心权衡：没有万能配置，只有场景适配。 2. Cache 机制：为什么击中缓存能便宜这么多 大模型的生成是迭代过程：每生成一个词，都要把已生成的所有词重新送回模型预测下一个。这就是为什么早期 ChatGPT 是"一个词一个词蹦出来"。Cache 机制缓存了已处理的 token，下次请求时可以复用前面的计算结果，大幅降低算力消耗。 "你会发现我所有大模型 API 都会告诉你，如果你击中了 cache 是多少钱，如果你没有击中缓存是多少钱。" —— Kaiyi "它缓存的就是我们'今天早上吃'这四个词，它就缓存在里边了。你下次再来，你是在后面又加了词，那就可以把之前那些结果拿出来去复用。" —— Kaiyi 这解释了为什么 DeepSeek 等模型的缓存价格能降低"非常多"——不是慈善，而是真实的成本节省。开发者应该主动设计对话流，最大化缓存命中率。 3. Top-k 与 Top-p：另一个影响创造力的旋钮 除了 temperature，Top-k 参数同样影响模型的选词策略。Top-k=2 意味着只从概率最高的前 2 个词中选择，Top-k=10 则从前 10 个词中选。OpenAI 官方文档明确建议：不要同时调整 temperature 和 Top-k，因为它们本质上影响同一件事，同时调整会让效果变得不可预测。 "OpenAI 的官方文档会告诉你，不要同时调整 temperature 和 Top-k，因为这两个本质影响是一个事儿，所以它会让你的调整变得没有那么的正交。" —— Kaiyi "一般是固定好了某一个再去调另一个。" —— Kaiyi 这是典型的工程实践智慧：当两个参数相互耦合时，应该采用控制变量法，而不是盲目调参。 4. "贵但好用"的 Codex 与"快但冒烟"的 Claude 开翼分享了在加拿大微软的实战经验：团队同时使用 Codex、Claude 和 Kimi，发现各有千秋。Codex 响应慢但生成的代码"直接可用"；Claude 在 plan mode 下快速输出大量代码，但常因"兢兢业业干得太快"导致不可用。这种取舍让工程师不得不混用工具——有朋友直接充值 200 刀 Codex。 "Codex 的问题是速度特别慢，但实际生成效果确实不错。" —— Kaiyi "Claude 有时候就是兢兢业业干活特别快，给你代码特别多，但是有时候不可用。" —— Kaiyi 这场工具之争揭示了当前 AI 编程的核心矛盾：速度与可靠性的永恒博弈。没有银弹，只有权衡。 5. 哈利波特测试：上下文塞满后的智能崩塌 开翼抛出一个经典测试：将整本《哈利波特与魔法石》塞进模型上下文，再询问细节问题。结果令人意外——尽管模型拥有全部答案，却因上下文过载导致"召回能力急剧下降"。这个实验直指当前技术痛点：token 成本不仅关乎金钱，更影响模型的核心智能表现。 "当上下文塞满了之后，它的召回能力有些可能就看不到，以及它的智能一定会下降。" —— Kaiyi "把整本哈利波特塞进模型里问细节，他肯定有所有答案，但有时候回答不对。" —— Kaiyi 这个残酷测试提醒我们：在追求长上下文能力时，开发者需警惕"塞得越多，忘得越快"的隐性陷阱。真正的智能或许不在于吞吐量，而在于精准提取。 6. RAG 最佳实践：从 Query 重写到 Re-rank 开翼系统讲解了当前 RAG 的标准流程：首先用 embedding 模型将文档转为向量存入数据库；针对代码场景，应该同时 embed 代码本身和 LLM 生成的代码解释，双向量索引提升召回率；用户 query 进来后先做重写，将"这个城市"补全为"北京"，并生成 3-5 个同义改写；每个改写检索 3-5 条文档，共得到 15 条候选；最后用 re-rank 模型重新排序，选出最相关的 3-5 条喂给大模型生成回复。 "如果你在 embedding 代码的时候，我们会先用一个小模型去给这个代码解释这个代码是干什么的。我在 embed 代码的时候生成一个向量，我在 embed 解释这段代码的地方生成一个向量，这两个向量同时可以索引这段代码。" —— Kaiyi "Query 重写也可以，因为单词有多义性，一般我们会把它重写成 3 到 5 个同意但是写法不同的句子，然后再把这 3 到 5 个向量去数据库里检索。" —— Kaiyi 这套流程已经是业界共识，但每个环节都有优化空间——关键是理解原理，而不是照搬代码。 7. 为什么大公司做不好大模型 开翼以亲身经历解释：大公司的决策链路太长，一个刚毕业的博士研究员提出天才想法，需要 1000 万美元训练资金时，在大公司的审批体系里"是不可能的"——每一层都要背书，失败了要背锅。而 OpenAI 这种创业公司可以把巨大资金和算力直接投给几个天才，甚至是博士实习生，让十个人试，成一个就沿着这个方向走。 "当我有一个天才的想法，我说我现在要需要 1000 万美元的训练资金，我要去验证我这个想法，在大公司的决策链路里是不可能的。" —— Kaiyi "OpenAI 这种创业公司，他们可以去把巨大的资金、巨大的算力去投入给几个天才的人，甚至是博士的实习生。而且他们的算力和钱实在太多了，他可以让十个天才去试，就有一个事成了，那他们就沿着这个方向整个方向往走。" —— Kaiyi 这就是为什么苹果、亚马逊、微软这些巨头都没有成功做出自己的大模型，基本都是创业公司做成的。组织结构决定创新能力。 8. AI 时代的新开发范式：2000 行单文件与即用即抛 开翼观察到一个有趣现象：一些"很牛的人"现在喜欢写 2000-3000 行的单文件代码，所有工具函数放在一起，打破了传统"超过 100 行就应该拆分"的规范。原因很简单：现在是 AI 在干活，你要服务于 AI。代码复用的成本收益比已经改变——高质量代码的生成成本极低，那就不复用了，随便改，甚至"即用即抛"都可以。 "我发现一个很有意思的风格，就是他们现在喜欢写一个文件，2000-3000 行的代码甚至更长。我们之前有个说法是超过 100 行或 150 行代码就应该被拆了。" —— Kaiyi "现在代码，特别是高质量代码的成本变得极低了，那我就不复用了。我如果要修改这个工具函数，我就随便改。因为我知道你不会影响到任何其他的地方，那甚至即用即抛都可以。" —— Kaiyi 这是范式转换的信号：从"为人类可读性优化"转向"为 AI 协作优化"。复制三次以下的代码不再抽取，因为 AI 能轻松处理重复。 9. 软件工程的复兴：瀑布式开发在 AI 时代的回归 开翼提出一个大胆观点：本科学的软件工程（需求-架构-开发-测试的瀑布式流程）曾被认为"非常繁琐、非常死板"，但如果换成 AI 来执行呢？当 AI 强到我们要把自己看作老板时，就需要思考如何让"员工"以某种死板的形式一步步做，产出的文档和结果可以快速 review。 "如果 AI 已经强到我们要把自己看作老板，那么就需要思考如何让我们的员工以某种非常死板的形式去一步一步做。但是这个死板形式产出的文档或者产出的结果，我可以非常快速的 review。" —— Kaiyi "我如果带一个团队，我不会去一行行代码 review。我只是去看你的测试表，你的架构文档我能看懂，你的架构文档我觉得合不合适，有问题我再改。" —— Kaiyi 未来的开发方式可能就是这样：像 CEO 一样只关注目标能否完成，而不在意代码里有多少 bug。验收标准从"代码质量"转向"功能达成"。 10. AI 会带来大失业吗：1-5 年动荡期后的新平衡 讨论到 AI 对就业的影响，开翼给出判断：未来 1-5 年是动荡期，AI 不断侵蚀岗位，开发者不断发明新范式提高效率。但 5 年后，程序员的平均工资可能不会降甚至会升，但岗位数量一定会越来越少。原因是 AI 这波革命"没有创造新的技术岗位，只减少了"——客服、前台等岗位已经在被取代。 "我觉得五年之后，程序员的整体的工作岗位平均工资可能不会降，甚至可能会升。但是工作岗位的量一定会越来越少。" —— Kaiyi "AI 这一波革命很有意思，一波新的技术革命它没有创造新的技术岗位，它只减少了。" —— Kaiyi 现实案例：产品经理用 AI 写 PRD，前端工程师也用 AI 理解 PRD 并生成代码——"中间商"开始多余。有公司已经要求产品经理直接出高保真图，前端的作用变成"把数据填成真的"。岗位二合一正在发生。 金句摘录 "Codex 的问题是速度特别慢，但实际生成效果确实不错。有人认为 Claude 最好，也有人认为 Codex 最佳。" —— Kaiyi "当上下文塞满了之后，它的召回能力有些可能就看不到，以及它的智能一定会下降。" —— Kaiyi "前端转型 AI 的真相：不是学算法，而是学会和 AI '啰嗦'对话。" —— Kaiyi 🤔 思考与启发 本期节目展现了 AI 工具落地的现实图景： 1. 工具选择的务实哲学: 工程师不再迷信单一"最佳模型"，而是根据场景混用 Codex（可靠但贵）、Claude（快但需校验）、Kimi（成本低且前端友好），证明技术选型应回归业务本质。 2. 上下文的隐形成本: 哈利波特测试揭示 token 消耗不仅是金钱问题，更会导致模型智能衰减。开发者需建立"上下文预算"意识，在 prompt 设计中主动做减法。 3. 转型路径的认知升级: 前端开发者切入 AI 的关键不是补数学短板，而是掌握"对话式开发"新范式——像操作文件系统般调度 AI 能力，把"啰嗦"转化为生产力。 延伸思考: 当你的 AI 助手开始输出冗长解释，是该优化 prompt 精简对话，还是接受这种"必要的啰嗦"以换取准确性？
节目简介 本期节目在中关村创业大街线下录制，迎来时隔一年多的重磅嘉宾开翼——刚从加拿大微软归来，带着 GitHub Copilot 团队的一线实战经验。四位技术人深度拆解大模型的工作原理：从 Temperature 参数如何影响创造力，到 Cache 机制为何能让 API 便宜这么多；从 RAG 的完整最佳实践，到为什么大公司做不好大模型；从 AI 时代"2000 行单文件"的新开发范式，到程序员未来 1-5 年的动荡期预判。这不是科普向的入门课，而是一线工程师用真金白银试出来的实战经验分享。 本期要闻 1. Temperature 参数的真相：创造力与稳定性的博弈 开翼从大模型的基本原理讲起：模型本质是"下一个词预测器"，每次生成时会输出多个候选词及其概率。Temperature 参数决定了选词策略——设为 0 时模型会 100% 选择概率最高的词，输出稳定但呆板；设得越大，模型越可能选择低概率词，创造力提升但不确定性增加。 "如果你的 temperature 设成 0，它百分之百会选择概率最大的词。所以它表现出来给我们的感觉就它变得呆板，创造力低，但是非常的稳定。" —— Kaiyi 实战经验表明：翻译、数学题等需要精确输出的场景应将 temperature 设到最低；而写小说、创意文案等需要发散思维的场景则应调高。这个参数揭示了 AI 应用的核心权衡：没有万能配置，只有场景适配。 2. Cache 机制：为什么击中缓存能便宜这么多 大模型的生成是迭代过程：每生成一个词，都要把已生成的所有词重新送回模型预测下一个。这就是为什么早期 ChatGPT 是"一个词一个词蹦出来"。Cache 机制缓存了已处理的 token，下次请求时可以复用前面的计算结果，大幅降低算力消耗。 "你会发现我所有大模型 API 都会告诉你，如果你击中了 cache 是多少钱，如果你没有击中缓存是多少钱。" —— Kaiyi "它缓存的就是我们'今天早上吃'这四个词，它就缓存在里边了。你下次再来，你是在后面又加了词，那就可以把之前那些结果拿出来去复用。" —— Kaiyi 这解释了为什么 DeepSeek 等模型的缓存价格能降低"非常多"——不是慈善，而是真实的成本节省。开发者应该主动设计对话流，最大化缓存命中率。 3. Top-k 与 Top-p：另一个影响创造力的旋钮 除了 temperature，Top-k 参数同样影响模型的选词策略。Top-k=2 意味着只从概率最高的前 2 个词中选择，Top-k=10 则从前 10 个词中选。OpenAI 官方文档明确建议：不要同时调整 temperature 和 Top-k，因为它们本质上影响同一件事，同时调整会让效果变得不可预测。 "OpenAI 的官方文档会告诉你，不要同时调整 temperature 和 Top-k，因为这两个本质影响是一个事儿，所以它会让你的调整变得没有那么的正交。" —— Kaiyi "一般是固定好了某一个再去调另一个。" —— Kaiyi 这是典型的工程实践智慧：当两个参数相互耦合时，应该采用控制变量法，而不是盲目调参。 4. "贵但好用"的 Codex 与"快但冒烟"的 Claude 开翼分享了在加拿大微软的实战经验：团队同时使用 Codex、Claude 和 Kimi，发现各有千秋。Codex 响应慢但生成的代码"直接可用"；Claude 在 plan mode 下快速输出大量代码，但常因"兢兢业业干得太快"导致不可用。这种取舍让工程师不得不混用工具——有朋友直接充值 200 刀 Codex。 "Codex 的问题是速度特别慢，但实际生成效果确实不错。" —— Kaiyi "Claude 有时候就是兢兢业业干活特别快，给你代码特别多，但是有时候不可用。" —— Kaiyi 这场工具之争揭示了当前 AI 编程的核心矛盾：速度与可靠性的永恒博弈。没有银弹，只有权衡。 5. 哈利波特测试：上下文塞满后的智能崩塌 开翼抛出一个经典测试：将整本《哈利波特与魔法石》塞进模型上下文，再询问细节问题。结果令人意外——尽管模型拥有全部答案，却因上下文过载导致"召回能力急剧下降"。这个实验直指当前技术痛点：token 成本不仅关乎金钱，更影响模型的核心智能表现。 "当上下文塞满了之后，它的召回能力有些可能就看不到，以及它的智能一定会下降。" —— Kaiyi "把整本哈利波特塞进模型里问细节，他肯定有所有答案，但有时候回答不对。" —— Kaiyi 这个残酷测试提醒我们：在追求长上下文能力时，开发者需警惕"塞得越多，忘得越快"的隐性陷阱。真正的智能或许不在于吞吐量，而在于精准提取。 6. RAG 最佳实践：从 Query 重写到 Re-rank 开翼系统讲解了当前 RAG 的标准流程：首先用 embedding 模型将文档转为向量存入数据库；针对代码场景，应该同时 embed 代码本身和 LLM 生成的代码解释，双向量索引提升召回率；用户 query 进来后先做重写，将"这个城市"补全为"北京"，并生成 3-5 个同义改写；每个改写检索 3-5 条文档，共得到 15 条候选；最后用 re-rank 模型重新排序，选出最相关的 3-5 条喂给大模型生成回复。 "如果你在 embedding 代码的时候，我们会先用一个小模型去给这个代码解释这个代码是干什么的。我在 embed 代码的时候生成一个向量，我在 embed 解释这段代码的地方生成一个向量，这两个向量同时可以索引这段代码。" —— Kaiyi "Query 重写也可以，因为单词有多义性，一般我们会把它重写成 3 到 5 个同意但是写法不同的句子，然后再把这 3 到 5 个向量去数据库里检索。" —— Kaiyi 这套流程已经是业界共识，但每个环节都有优化空间——关键是理解原理，而不是照搬代码。 7. 为什么大公司做不好大模型 开翼以亲身经历解释：大公司的决策链路太长，一个刚毕业的博士研究员提出天才想法，需要 1000 万美元训练资金时，在大公司的审批体系里"是不可能的"——每一层都要背书，失败了要背锅。而 OpenAI 这种创业公司可以把巨大资金和算力直接投给几个天才，甚至是博士实习生，让十个人试，成一个就沿着这个方向走。 "当我有一个天才的想法，我说我现在要需要 1000 万美元的训练资金，我要去验证我这个想法，在大公司的决策链路里是不可能的。" —— Kaiyi "OpenAI 这种创业公司，他们可以去把巨大的资金、巨大的算力去投入给几个天才的人，甚至是博士的实习生。而且他们的算力和钱实在太多了，他可以让十个天才去试，就有一个事成了，那他们就沿着这个方向整个方向往走。" —— Kaiyi 这就是为什么苹果、亚马逊、微软这些巨头都没有成功做出自己的大模型，基本都是创业公司做成的。组织结构决定创新能力。 8. AI 时代的新开发范式：2000 行单文件与即用即抛 开翼观察到一个有趣现象：一些"很牛的人"现在喜欢写 2000-3000 行的单文件代码，所有工具函数放在一起，打破了传统"超过 100 行就应该拆分"的规范。原因很简单：现在是 AI 在干活，你要服务于 AI。代码复用的成本收益比已经改变——高质量代码的生成成本极低，那就不复用了，随便改，甚至"即用即抛"都可以。 "我发现一个很有意思的风格，就是他们现在喜欢写一个文件，2000-3000 行的代码甚至更长。我们之前有个说法是超过 100 行或 150 行代码就应该被拆了。" —— Kaiyi "现在代码，特别是高质量代码的成本变得极低了，那我就不复用了。我如果要修改这个工具函数，我就随便改。因为我知道你不会影响到任何其他的地方，那甚至即用即抛都可以。" —— Kaiyi 这是范式转换的信号：从"为人类可读性优化"转向"为 AI 协作优化"。复制三次以下的代码不再抽取，因为 AI 能轻松处理重复。 9. 软件工程的复兴：瀑布式开发在 AI 时代的回归 开翼提出一个大胆观点：本科学的软件工程（需求-架构-开发-测试的瀑布式流程）曾被认为"非常繁琐、非常死板"，但如果换成 AI 来执行呢？当 AI 强到我们要把自己看作老板时，就需要思考如何让"员工"以某种死板的形式一步步做，产出的文档和结果可以快速 review。 "如果 AI 已经强到我们要把自己看作老板，那么就需要思考如何让我们的员工以某种非常死板的形式去一步一步做。但是这个死板形式产出的文档或者产出的结果，我可以非常快速的 review。" —— Kaiyi "我如果带一个团队，我不会去一行行代码 review。我只是去看你的测试表，你的架构文档我能看懂，你的架构文档我觉得合不合适，有问题我再改。" —— Kaiyi 未来的开发方式可能就是这样：像 CEO 一样只关注目标能否完成，而不在意代码里有多少 bug。验收标准从"代码质量"转向"功能达成"。 10. AI 会带来大失业吗：1-5 年动荡期后的新平衡 讨论到 AI 对就业的影响，开翼给出判断：未来 1-5 年是动荡期，AI 不断侵蚀岗位，开发者不断发明新范式提高效率。但 5 年后，程序员的平均工资可能不会降甚至会升，但岗位数量一定会越来越少。原因是 AI 这波革命"没有创造新的技术岗位，只减少了"——客服、前台等岗位已经在被取代。 "我觉得五年之后，程序员的整体的工作岗位平均工资可能不会降，甚至可能会升。但是工作岗位的量一定会越来越少。" —— Kaiyi "AI 这一波革命很有意思，一波新的技术革命它没有创造新的技术岗位，它只减少了。" —— Kaiyi 现实案例：产品经理用 AI 写 PRD，前端工程师也用 AI 理解 PRD 并生成代码——"中间商"开始多余。有公司已经要求产品经理直接出高保真图，前端的作用变成"把数据填成真的"。岗位二合一正在发生。 金句摘录 "Codex 的问题是速度特别慢，但实际生成效果确实不错。有人认为 Claude 最好，也有人认为 Codex 最佳。" —— Kaiyi "当上下文塞满了之后，它的召回能力有些可能就看不到，以及它的智能一定会下降。" —— Kaiyi "前端转型 AI 的真相：不是学算法，而是学会和 AI '啰嗦'对话。" —— Kaiyi 🤔 思考与启发 本期节目展现了 AI 工具落地的现实图景： 1. 工具选择的务实哲学: 工程师不再迷信单一"最佳模型"，而是根据场景混用 Codex（可靠但贵）、Claude（快但需校验）、Kimi（成本低且前端友好），证明技术选型应回归业务本质。 2. 上下文的隐形成本: 哈利波特测试揭示 token 消耗不仅是金钱问题，更会导致模型智能衰减。开发者需建立"上下文预算"意识，在 prompt 设计中主动做减法。 3. 转型路径的认知升级: 前端开发者切入 AI 的关键不是补数学短板，而是掌握"对话式开发"新范式——像操作文件系统般调度 AI 能力，把"啰嗦"转化为生产力。 延伸思考: 当你的 AI 助手开始输出冗长解释，是该优化 prompt 精简对话，还是接受这种"必要的啰嗦"以换取准确性？