https://ttf248.life/tags/topic-selection/ Recent content in 选题 on 向叔记事簿 Hugo -- gohugo.io zh-cn https://ttf248.life/p/next-8-ai-topics-after-reviewing-two-years-of-posts/ Mon, 30 Mar 2026 22:20:00 +0800 https://ttf248.life/p/next-8-ai-topics-after-reviewing-two-years-of-posts/ <p>最近回头翻了下博客里这两年和 AI 相关的文章，发现内容已经不是最开始那种“某个模型好不好用”的简单体验了，而是逐步形成了一条比较清晰的主线：<strong>AI 如何真正进入我的开发工作流，以及它带来了什么效率、代价和新的约束。</strong></p> <p>这里说的“近两年”，按当前时间往前看，大致是从 <code>2024-03-30</code> 到 <code>2026-03-30</code>。实际翻下来，一个很明显的现象是：<code>2024</code> 年几乎没有真正意义上的 AI 主题文章，密集产出主要从 <code>2025-01</code> 才开始。</p> <p>这件事本身就很有意思。它说明对我来说，AI 并不是一开始就进入了稳定使用期，而是先在工作和写作中慢慢渗透，等到真正碰到合适的工具和任务形态以后，才开始形成持续记录。</p> <h2 id="这两年的-ai-文章大致可以分成三个阶段">这两年的 AI 文章，大致可以分成三个阶段 </h2><h3 id="第一阶段工具尝鲜先看能不能用">第一阶段：工具尝鲜，先看能不能用 </h3><p>这一阶段的代表文章有：</p> <ul> <li>《Cursor AI 编程 IDE 试用》</li> <li>《ollama 本地部署 deepseek-R1》</li> <li>《不写代码，设计开发自选股模块》</li> <li>《AI发展两年：有点类似Docker发布前的状态》</li> </ul> <p>这个阶段的核心问题很朴素：<strong>AI 到底能不能帮我做事？</strong></p> <p>那会的关注点，更多还是工具层面：</p> <ul> <li>IDE 形态是否顺手</li> <li>本地部署是否能跑起来</li> <li>模型生成代码是否能省时间</li> <li>遇到复杂需求时，AI 会不会卡壳</li> </ul> <p>回头看，这一阶段的文章，像是在给后续的重度使用铺路。很多结论现在依然成立，比如：AI 可以明显提高基础开发效率，但复杂任务依然要靠人工拆分；本地模型可以尝鲜，但真正进入高频工作流，稳定性和速度才是关键。</p> <h3 id="第二阶段开始进入工作流但副作用也一起出现">第二阶段：开始进入工作流，但副作用也一起出现 </h3><p>这一阶段的代表文章有：</p> <ul> <li>《AI用多了，有点后遗症》</li> <li>《Claude4发布，尝试开发：hugo标签、超链接翻译助手》</li> <li>《近期大模型的一些使用经验》</li> <li>《字节AI编码新范式 SOLO》</li> </ul> <p>到了这里，AI 已经不只是“偶尔试一下的工具”，而是开始直接参与：</p> <ul> <li>博客工具链开发</li> <li>翻译缓存与批处理流程</li> <li>UI 设计与代码往返</li> <li>模型分工与场景选择</li> </ul> <p>与此同时，问题也越来越具体。</p> <p>以前的疑问是“AI 能不能写代码”，后来的疑问变成了：</p> <ul> <li>代码是写出来了，但怎么验收？</li> <li>文章是生成出来了，但有没有烟火气？</li> <li>文档是同步更新了，但我自己是否真的理解了？</li> <li>工具越来越强，但人的思考强度是不是在下降？</li> </ul> <p>这也是我觉得这批文章里最有价值的部分。相比空谈“AI 很强”，这种带有一点不适感的记录，反而更真实。</p> <h3 id="第三阶段从单工具体验走向协议流程稳定性和成本">第三阶段：从单工具体验，走向协议、流程、稳定性和成本 </h3><p>这一阶段的代表文章有：</p> <ul> <li>《基于命令行的AI编码交互》</li> <li>《从协议约束到智能释放：深度对比 MCP 与 Skill》</li> <li>《重度AI编程的一段日子》</li> <li>《低价 API 中转站的终局：三月份的大模型体验与不可能三角》</li> </ul> <p>到了这个阶段，关注点已经明显升级了。</p> <p>不再是“哪个模型回答更聪明”，而是：</p> <ul> <li>终端交互和 IDE 交互，哪种更适合持续开发</li> <li>MCP、Skill 这类能力扩展方式，到底有什么边界差异</li> <li>重度 AI 编程时，人工应该在哪些地方介入</li> <li>成本、稳定、质量之间，怎么做现实选择</li> </ul> <p>这类话题已经不再是简单的产品测评，更接近于<strong>工作流设计</strong>。这也是目前博客里 AI 主题最稳定、最有辨识度的一条线。</p> <h2 id="这批文章最大的优势不是追热点">这批文章最大的优势，不是追热点 </h2><p>回头看，博客里已有的 AI 文章，真正有辨识度的地方，不是你比别人更早写了某个模型，也不是参数、榜单、跑分写得更全，而是下面这几个点：</p> <h3 id="1-都是从真实使用场景长出来的">1. 都是从真实使用场景长出来的 </h3><p>无论是自选股模块、博客翻译工具、命令行编码，还是 API 中转站折腾记录，几乎都不是凭空凑出来的题材，而是自己在实际使用中碰到问题以后才写的。</p> <p>这种内容的好处是，不容易空洞。</p> <h3 id="2-关注的是怎么把-ai-接进流程">2. 关注的是“怎么把 AI 接进流程” </h3><p>很多 AI 文章只写模型能力，但现有这批文章更关心的是：</p> <ul> <li>如何拆任务</li> <li>如何接入项目</li> <li>如何维护文档</li> <li>如何控制上下文</li> <li>如何在不同模型之间做分工</li> </ul> <p>这类内容的生命周期通常比单纯的模型测评更长。</p> <h3 id="3-已经开始意识到副作用和成本">3. 已经开始意识到副作用和成本 </h3><p>从《AI用多了，有点后遗症》到《低价 API 中转站的终局》，其实已经形成了一条很完整的思考线：</p> <ul> <li>AI 能提效</li> <li>但会改变人的搜索和思考习惯</li> <li>便宜不等于真正省钱</li> <li>质量、稳定、划算很难同时成立</li> </ul> <p>这类判断是有个人使用沉淀的，不是单纯复述网上观点。</p> <h2 id="但也有几个明显的内容缺口">但也有几个明显的内容缺口 </h2><p>现有文章虽然已经有主线了，但如果继续往下写，我觉得还有几个缺口比较明显。</p> <h3 id="1-缺少系统性的验收方法论">1. 缺少系统性的“验收方法论” </h3><p>已经写了很多 AI 编程体验，也提到了单元测试、性能测试、文档同步，但还没有一篇文章专门把“AI 写的东西如何验收”这件事完整讲透。</p> <h3 id="2-缺少团队视角">2. 缺少团队视角 </h3><p>目前大多是个人开发和个人工作流视角。这个角度很好，但如果继续往下写，完全可以扩展到：</p> <ul> <li>多人协作时如何限制 AI 修改范围</li> <li>code review 怎么看 AI 代码</li> <li>文档、提交日志、测试记录怎么配合</li> </ul> <h3 id="3-缺少安全与权限边界的讨论">3. 缺少安全与权限边界的讨论 </h3><p>最近这波趋势已经越来越明显了，AI 不再只是聊天框，而是在接管：</p> <ul> <li>终端命令</li> <li>仓库读写</li> <li>浏览器操作</li> <li>第三方工具调用</li> </ul> <p>能力越强，权限边界就越值得写。</p> <h3 id="4-缺少长期知识库方向">4. 缺少“长期知识库”方向 </h3><p>现在文章里已经有翻译缓存、slug、标签这些基础能力，但还没系统去写：如果博客本身就是个人知识库，那么怎样把它整理成更适合 AI 消费、检索和加工的内容资产。</p> <h2 id="接下来我觉得最适合写的-8-个选题">接下来我觉得最适合写的 8 个选题 </h2><p>下面这 8 个方向，我是按“最贴合现有写作风格”和“最容易写出一手内容”来排的。</p> <h3 id="1-ai-编程的验收体系怎么建">1. AI 编程的验收体系怎么建 </h3><p>这是我最推荐优先写的一篇。</p> <p>可以重点写下面这些内容：</p> <ul> <li>哪些修改必须补单元测试</li> <li>哪些模块必须跑回归测试</li> <li>哪些重构需要性能对比</li> <li>哪些文档应该同步维护</li> <li>人工 review 时重点看什么</li> </ul> <p>这篇文章一旦写好，后面很多 AI 编程文章都可以反复链接回来。</p> <h3 id="2-mcp-真正有用的场景不是接得越多越强">2. MCP 真正有用的场景，不是接得越多越强 </h3><p>现在 MCP 已经越来越热了，但大多数讨论仍然停留在概念层面。</p> <p>更值得写的是：</p> <ul> <li>哪些工具接入后真的提升效率</li> <li>哪些只是看起来很酷，实际没必要</li> <li>本地文件、文档、issue、监控、设计稿，哪些最值得优先打通</li> <li>协议化接入和“塞一大段提示词”相比，差异到底在哪里</li> </ul> <h3 id="3-claude-codecodexgemini-cli国产-cli-模型的横向实战">3. Claude Code、Codex、Gemini CLI、国产 CLI 模型的横向实战 </h3><p>不是简单写“哪个好”，而是统一一个任务集做横评。</p> <p>比如固定比较：</p> <ul> <li>需求拆解能力</li> <li>指令遵循度</li> <li>代码修改范围控制</li> <li>测试补充能力</li> <li>文档同步能力</li> <li>成本和等待时间</li> </ul> <p>这种文章读者最容易直接拿来参考。</p> <h3 id="4-ai-编程里的上下文管理">4. AI 编程里的上下文管理 </h3><p>很多时候，并不是模型不够强，而是上下文已经脏了、长了、漂了。</p> <p>这篇可以专门写：</p> <ul> <li>什么时候该清空上下文</li> <li>什么时候应该开新线程</li> <li>什么时候应该把任务切小</li> <li>什么时候适合多 agent 并行</li> <li>什么情况下必须人工重新总结一次当前状态</li> </ul> <p>这个题目很具体，也很容易结合自己的真实案例。</p> <h3 id="5-从-ide-到终端再到多-agent-协作">5. 从 IDE 到终端，再到多 Agent 协作 </h3><p>过去一年，AI 编程交互的重心已经明显变化了。</p> <p>以前更多是 IDE 内补全、聊天、局部改代码；现在越来越多工具开始强调：</p> <ul> <li>终端交互</li> <li>仓库级理解</li> <li>多线程上下文</li> <li>并行 agent</li> <li>worktree 隔离开发</li> </ul> <p>这个选题适合把过去的 Cursor、Trae、Claude Code、Codex 这些文章串起来。</p> <h3 id="6-ai-编程的安全面正在扩大">6. AI 编程的安全面正在扩大 </h3><p>这个方向很值得写，而且现在还没怎么覆盖。</p> <p>可以从这些角度切：</p> <ul> <li>自动执行命令的风险</li> <li>第三方 MCP 服务的信任边界</li> <li>私有仓库和敏感信息泄露问题</li> <li>提示词注入和恶意上下文污染</li> <li>自动化脚本与人工确认的边界</li> </ul> <p>如果只写“AI 很能干”，文章会慢慢趋同；把安全边界写进去，内容层次会明显更高。</p> <h3 id="7-本地模型的真实位置">7. 本地模型的真实位置 </h3><p>以前更多是在问“本地模型能不能跑”，现在更值得问的是：</p> <ul> <li>它适合什么任务</li> <li>它不适合什么任务</li> <li>隐私、离线、低成本这些优势什么时候真的成立</li> <li>什么时候继续坚持本地方案，反而是在浪费时间</li> </ul> <p>这比单纯的部署教程更有后续价值。</p> <h3 id="8-博客如何整理成-ai-友好的知识资产">8. 博客如何整理成 AI 友好的知识资产 </h3><p>这个方向和现有博客体系结合得最紧。</p> <p>可以写：</p> <ul> <li>slug、标签、摘要、分类如何统一设计</li> <li>多语言内容如何减少链接漂移</li> <li>文章元数据如何帮助后续检索</li> <li>如何让历史文章更适合被 AI 检索、总结、引用</li> </ul> <p>这篇如果写出来，既是 AI 主题，又能反过来服务整个博客体系。</p> <h2 id="未来一段时间值得继续盯着的趋势">未来一段时间，值得继续盯着的趋势 </h2><p>最近行业里有几个变化，也会影响后续选题判断。</p> <p>第一，AI 编程已经越来越明显地从“补全工具”走向“agent 工作流”。像 <code>Codex</code>、<code>Claude Code</code> 这类产品，强调的已经不是单次回答，而是任务拆解、工具调用、并行处理和上下文持续维护。</p> <p>第二，MCP 这类协议化接入方式，正在从“新概念”变成基础设施。以后真正有价值的文章，不会是再解释一遍协议定义，而是写清楚：<strong>哪些接入场景真的有效，哪些只是看起来很先进。</strong></p> <p>第三，设计稿、文档、代码、命令行之间的往返正在变多。过去工具之间是割裂的，现在 AI 在尝试把这些链路接起来，这也意味着“工作流设计”会比“模型榜单”更值得长期写。</p> <p>第四，稳定性、成本和权限风险不会消失。相反，模型能力越强，这几个问题只会变得更重要。</p> <h2 id="最后的判断">最后的判断 </h2><p>如果继续写 AI，我觉得最应该坚持的一件事，不是追着每次模型发布去做测评，而是继续围绕一个更具体的问题展开：</p> <p><strong>AI 到底是怎么一步步进入真实开发与写作流程的，它在哪些地方真正提高了效率，又在哪些地方把问题重新丢回给了人。</strong></p> <p>这条线，你其实已经写出来了，只是还没有完全显形。</p> <p>接下来最合适的做法，不是把题材铺得更散，而是沿着“实战工具、流程设计、边界控制、长期知识资产”这四条支线，继续往下挖。这样写出来的东西，时间久了，反而更容易沉淀成自己的东西，而不是一批很快过时的热点记录。</p>