<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AI on 工程师手记</title><link>https://junozee.com/tags/ai/</link><description>Recent content in AI on 工程师手记</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Mon, 31 Aug 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://junozee.com/tags/ai/index.xml" rel="self" type="application/rss+xml"/><item><title>AI 时代，工程师还值得写博客吗？</title><link>https://junozee.com/posts/ai-era-engineering-notes/</link><pubDate>Mon, 31 Aug 2026 09:00:00 +0800</pubDate><guid>https://junozee.com/posts/ai-era-engineering-notes/</guid><description>&lt;p&gt;基础概念、框架入门和 API 参数说明，正在快速变成随问随答的能力。把官方文档换一种说法，已经很难成为有价值的内容。&lt;/p&gt;&#10;&lt;p&gt;但工程实践里真正昂贵的部分，从来不是记住一个 API，而是判断：&lt;strong&gt;在当前规模、团队能力和历史包袱下，哪一种方案的长期成本最低。&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;AI 能给出方案列表，却不知道你的数据库有十年的数据债、核心链路不能停机，也无法替你承担一次错误架构决策的后果。这些现实约束，正是一名资深工程师可以持续记录的内容。&lt;/p&gt;&#10;&lt;p&gt;我希望这里留下的不是“标准答案”，而是可供复盘的判断过程：当时有哪些选择、为什么排除、上线后的结果是什么，以及下次会如何改进。&lt;/p&gt;</description></item></channel></rss>