David的AI全景图

一篇关于FDE(Forward Deployed Engineer)前沿部署工程师的深度报告。 摘要： 一，FDE 不是驻场工程师，也不是咨询顾问。 三者的分水岭在"反馈去向"：没有反馈闭环的 FDE 就是外包，没有落地承诺的 FDE 就是咨询。咨询赚认知的钱，外包赚效率的钱，FDE 赚复利的钱。 二，它的爆发不是因为 AI 变强了，而是因为 AI 落地失败得太惨。 MIT 的调研显示，企业在生成式 AI 上投入 300 至 400 亿美元后，约 95% 的组织没有看到任何可衡量的损益变化。而这些失败极少输在模型能力上。 三，挡在 AI 和业务之间的是三道非技术的墙：语言错位、隐性知识未被数字化、组织层面的人的抵制。FDE 的全部工作就是拆这三道墙。 四，这个模式最著名的支持者，也是它最严厉的警告者。 FDE 模式的发明人之一 Bob McGrew 被问到创业者是否该复制它时，回答是"不要"——它极容易滑成一家低毛利的咨询公司。 五，重模式在中国算不过账，但一个轻模式的变体正在出现。 中国企业服务市场的付费习惯、最低价中标制度和行业鄙视链，共同否决了"由高毛利软件公司长期供养驻场团队"这套打法。但 AI 编程和 Agent 基础设施把定制成本打穿之后，"一个人加一组 Agent"构成一条完整交付线成为可能——养 FDE 的角色从公司换成了 AI 本身。 六，FDE 是一个以让自己过时为目标的岗位。 每解决一个问题，方案就被沉淀，下一个客户需要的定制就更少。做得越好，行业对它的需求就越少。 来源：https://getperspective.ai/blog/state-of-forward-deployed-engineering-2026-survey-report-1500-fdes；Codex深度调研报告

Moonshot 发布的 Kimi K3 技术报告：一个 2.8 万亿参数、1M 长上下文、原生多模态、完全开源权重的前沿 MoE 大模型。 摘要： 1. 在类似规模的预训练基础上反复堆叠，开源进展有收敛风险，而与最强闭源系统之间的差距却在继续拉大。」「Kimi K3 试图在两条轴线上同时冲到前沿：把预训练基础扩展到前所未有的 3T 级参数规模，同时把强化学习、推理努力和 100 万上下文长程交互一并拉满。」 2. 「我们训练了一个 2.8T 参数的原生多模态 MoE 模型，激活参数 104B，支持 100 万 Token 上下文，并通过架构、数据和训练配方的改进，相比 Kimi K2 实现了约 2.5× 的整体缩放效率提升。」 3. 「Kimi K3 的后训练阶段被明确地设计为服务于 100 万上下文的测试时扩展：跨长程代码、通用 Agent、推理与知识任务做强化学习，并覆盖多个推理努力等级。」 4. 「在长程代码、Agent、知识、推理与视觉任务的基准上，Kimi K3 在整体上仍落后于最强的闭源系统——Claude Fable 5 与 GPT-5.6 Sol——但在我们评估的其它开源与闭源模型中，它表现最为稳定且总体领先。」 5. 「Kimi K3 结合了三大系统挑战：混合 KDA 注意力、3T 级稀疏多模态训练与推理、以及百万 Token 级的 Agent 工作负载——我们的基础设施在这三条战线上做了联合协同设计。」 来源：https://github.com/MoonshotAI/Kimi-K3

大学毕业提交论文时，我连邮箱都没有。 很多年后，我却回到母校，劝一群外语专业的学弟学妹去做开发者。 这期节目来自一次两个半小时的母校分享。我回头整理了自己从俄语生、翻译、产品经理，到AI创业者和builder的几次转变，也试着回答一个对文科生越来越重要的问题： 当自然语言开始成为编程语言，我们曾经学过的文学、历史、文化和审美，究竟是过时的知识，还是新的创造力？ 你会听到： * 一个“文科生中的文科生”，为什么开始靠近技术 * 对于曾经做翻译模型的我们，The Bitter Lesson为什么如此苦涩 * 为什么翻译的昨天，可能就是Coding的今天 * 文科生做软件，真正的优势是什么 * 为什么非要做“作品型产品” * 为什么说未来没有人问你的title，只问你有什么独特作品 这不是一个文科生终于变成技术人的故事，只是我又找到了一支新的毛笔，而我想把它，传递给更多曾经的自己。 相关内容： * 公众号文字版：《毕业时连邮箱都没有，今天我却回母校劝文科生做开发者》 * 草诀歌AI Labs官网：https://www.caojuege.com 说明：音频的开头是我录的，后面是AI用我的音色生成的。

Thariq 是 Anthropic 的产品与工程实践者，长期在一线用 Claude 做「代理式编码」和复杂工程协作。这是他分享的Fable 5经验：用 Claude Fable 5 做「代理式编码」时，真正的瓶颈不是模型，而是你有没有搞清楚自己的「未知（unknowns）」。作者把整个工作流程拆成前、中、后三个阶段，重点都围绕一件事：系统性地发现和澄清 unknowns，让模型在真实「领地」（代码、业务约束）里少踩坑，多发挥。 1. 模型的极限，不在于它能做什么，而在于你有没有看见自己的未知。 2. Prompt 是地图，代码库是真实领地，卡住的地方，永远藏着你没说清的未知。 3. 与其让 Claude 乱猜，不如先让它做一轮『盲区巡检』，帮你把不会问的问题问出来。 4. 真正的高手，不是没有 unknowns，而是把 unknowns 变成可以被发现、被记录、被迭代的资产。 5. 当长链路任务跑偏时，大多数时候错的不是 Claude，而是你从一开始就没画对地图。 6. 一段改动只有在你能通过 Claude 给你的『闭卷测验』时，才算真正被你掌握。 7. 越强大的模型，越逼着我们承认：最大的不确定性，从来不在机器，而在自己。 来源：https://x.com/trq212/status/2073100352921215386