2026年重新开始写技术博客：我的AI编程工作流实践

距离上一次认真更新博客，已经过去了很久。

中间并不是没有新的技术输入，也不是没有值得记录的东西。相反，这几年工具、框架、开发方式都变化得很快，尤其是 AI 编程工具出现之后，很多原来习以为常的开发流程都被重新改写了。只是越忙越容易把“记录”这件事往后放，最后博客就慢慢停在了某个时间点。

今天重新打开这个 Hexo 博客，整理配置、补文档、检查部署流程的时候，我突然觉得：与其等到准备好一整套宏大的内容计划，不如先写下一篇真实的、和当下工作方式有关的文章。

这篇文章就从我现在的 AI 编程工作流开始。

为什么现在重新开始

以前写技术博客，更多是为了系统整理知识。比如学一门语言、读一个框架、解决一个问题，然后把过程整理成文章。这个模式当然仍然有效，但现在我更想记录的是“真实开发过程中的判断”。

因为 AI 工具让写代码变快了，但也让工程判断变得更重要了。

现在的问题不再只是“这段代码怎么写”，而是：

• 这个需求应该拆成什么粒度？
• 哪些部分可以交给 AI 快速完成？
• 哪些地方必须自己审查和兜底？
• 生成的代码是否符合项目原有风格？
• 测试、文档和部署流程有没有跟上？

这些问题很难靠一段提示词一次性解决。它们更像是一套持续运行的工作流。

我现在如何使用 AI 辅助开发

我会把 AI 当成一个高效的协作者，而不是一个完全自动驾驶的程序员。

在开始一个任务之前，我通常先让 AI 帮我做三件事：阅读项目结构、找出关键文件、总结现有约定。比如一个老项目很久没动，第一步不是马上改代码，而是先确认它用的框架、脚本、目录结构、生成产物和部署方式。

这一步看起来慢，其实是在避免后面的返工。

当项目上下文清楚之后，我会把任务拆成几个具体动作：

1. 先确认目标和边界。
2. 再让 AI 修改小范围文件。
3. 修改后立刻检查 diff。
4. 能跑测试就跑测试，不能跑测试也要做本地构建或预览。
5. 最后再整理提交说明和后续注意事项。

在这个过程中，AI 最擅长的是加速“已有模式下的执行”。比如补一个文档、写一个模板、根据现有代码风格扩展一个功能、总结错误日志、生成初版测试用例。这些事情如果完全手写，可能会消耗不少时间；交给 AI 起草，再由自己审查，会轻松很多。

但我不会把所有判断都交给 AI。

AI 适合做什么，不适合做什么

AI 很适合做明确、局部、可验证的任务。

比如：

• 根据现有代码补充文档。
• 按项目风格生成一个组件初稿。
• 分析报错信息并给出排查方向。
• 把一段重复逻辑整理成更清晰的结构。
• 为已有函数补测试用例。

这些任务的共同点是：上下文明确，结果可以检查。

AI 不太适合在缺少约束时直接替你做架构决策。尤其是老项目、线上项目、多人协作项目，很多约定并不写在代码里，而是藏在历史原因、部署流程和使用习惯里。AI 可以提供建议，但最终还是需要开发者判断取舍。

我现在更倾向于把 AI 放在“副驾驶”的位置：它负责提高速度，我负责方向、边界和质量。

我的一个实践原则

最近我给自己定了一个很简单的原则：

凡是 AI 生成的内容，都必须经过人类可解释的验证。

代码要能解释为什么这么改，文档要能对应项目事实，命令要能在本地跑通，页面要能实际打开看效果。不能因为“看起来像是对的”就直接接受。

这个原则听起来保守，但它能让 AI 真正进入工程流程，而不是变成一个偶尔带来惊喜、偶尔制造混乱的工具。

技术博客接下来写什么

重新开始之后，我不想把博客写成很重的负担。更现实的方式是围绕自己正在做的事情持续记录。

接下来可能会写这些方向：

• AI 编程工具在真实项目中的使用记录。
• iOS、Swift 和客户端工程实践。
• 老项目维护、依赖升级和部署流程整理。
• 个人知识管理和技术写作方法。
• 一些小而具体的问题排查复盘。

每篇文章不一定都很长，但要尽量真实、有上下文、有结论。

写在最后

这篇文章算是一个重新开始的标记。

技术博客最难的地方，往往不是搭建，也不是部署，而是持续把自己的思考留下来。AI 可以帮我更快地整理资料、生成初稿、检查结构，但真正决定文章价值的，仍然是我是否认真经历、认真判断、认真复盘。

希望下一次更新，不会再隔这么久。