文章归档

静态博客看起来是最轻的工程项目：Markdown 写内容，主题渲染页面，执行一次构建就能发布。但只要它依赖 Node.js、npm、主题包和渲染插件，它就不是一堆“永远可用”的文本，而是一条会随运行时变化而漂移的构建链。

很多博客维护问题并不来自文章本身，而来自环境变化：本机 Node 版本升级后主题样式编译失败，CI 镜像换代后依赖重新解析，旧插件在新运行时里触发弃用行为。越是低频维护的个人站点，越容易在下一次发布时才发现构建已经不稳定。

AI 工具最容易带来的错觉，是“写得更快”就等于“做得更快”。在真实工程里，速度只是表面，真正决定效率的是你能不能把一次对话变成一次可复现、可验证、可回滚的改动。

对 Android、Linux、脚本和日常工程来说，AI 最合适的位置不是“替你思考全部问题”，而是“帮你缩短搜索、整理和试错的路径”。前提是你给它一个稳定的工作流，而不是一段模糊的描述。

AI 工具进入日常工程之后，最容易被高估的是“生成答案”的速度，最容易被低估的是“把答案接入本地工作台”的成本。一个建议如果不能被复现、验证、回滚，它在 Android 项目、Linux 环境或后端服务里都只能算灵感，不能算工程动作。

真正稳定的效率提升，不是让 AI 替人多写几段代码，而是让它进入一条可控的本地流程：先理解目标，再读取有限上下文，提出可执行改动，最后通过命令、日志和测试闭环。这样做看起来慢一点，却能减少大量“回答正确但落地失败”的消耗。

AI 工具真正提升效率的地方，往往不是第一次回答，而是它能否接住一段正在推进的工程上下文。Android 构建、Linux 服务排障、脚本迁移、依赖升级这些工作，都不是孤立的一问一答。它们会经历观察、假设、验证、修改、回滚和复盘。如果上下文交接混乱，AI 很容易给出看似合理但实际脱离现场的建议。

很多团队把 AI 用得不稳定，并不是模型不会写代码，而是人没有把工程现场组织成可交接的状态。一次高质量交接，应该让后来者知道当前目标、已经确认的事实、不能碰的边界，以及下一步最小验证动作。这个后来者可以是同事，也可以是下一轮 AI 对话。

很多人使用 AI 工具时，习惯把它当成一个更会说话的搜索框：复制报错、等待解释、再去终端里尝试命令。这个方式能解决一部分问题，但在真实工程里经常不够稳定。日志会截断，环境会变化，命令有副作用，Android 和 Linux 的问题还常常夹在权限、进程、文件系统、网络和构建缓存之间。

更高效的做法，是把 AI 放进一套固定的排障工作流里。它不直接替你判断结论，而是帮助整理现场、收敛假设、设计下一步验证。人仍然负责执行命令、确认边界和决定是否修改系统状态。

很多团队已经习惯在排障阶段使用 AI：贴日志、问原因、要命令、整理结论。但更有价值的位置，其实是在变更进入主干之前。代码还没有合并，配置还没有发布，脚本还没有跑到生产环境里，这时 AI 能做的不是替我们拍板，而是把容易被忽略的风险提前摊开。

Android 与 Linux 工程尤其适合这种做法。前者经常受生命周期、权限、线程和设备差异影响；后者则容易被文件权限、环境变量、系统服务、路径和资源限制绊住。人工 review 很容易盯住业务逻辑，漏掉这些“边缘但常见”的运行条件。

AI 工具让写代码的速度变快了，但也更容易把一次变更做散：修 bug 的同时改了格式，补测试时顺手调整了命名，生成文档时又夹带了配置变动。最后 git diff 看起来很长，真正要审查的行为变化反而被淹没。

提交整理的目标不是把历史包装得漂亮，而是让每次变更都能被理解、被验证、被回滚。AI 很适合参与这件事：它可以帮助归类 diff、提炼意图、检查遗漏路径，并把提交说明写得更接近工程事实。

AI 工具已经能很快完成代码生成、文档整理、脚本编写和问题排查，但真正影响交付质量的，往往不是“能不能生成”，而是“生成之后怎么验证”。如果缺少验证闭环，AI 写出的内容看起来完整，实际可能改错边界、漏掉失败路径，或者让构建在最后一步才暴露问题。

更稳的做法，是把 AI 产出当成一次普通工程变更处理：先确认改动范围，再建立验证清单，然后用构建、测试、人工审查和回滚预案把结果闭环。这样 AI 负责提高产出速度，人负责控制风险。

调试最怕的不是问题复杂，而是信息散落在日志、配置、代码分支和环境差异里，最后只能靠猜。AI 工具能帮我们快速阅读日志、追踪调用链、整理假设，但如果一开始就问“这个问题怎么修”，它很容易跳过验证，直接给出看似合理的修改建议。

更稳的做法，是把 AI 放进一个可检查的调试流程里：先描述现象，再收集证据，然后缩小范围，最后产出最小复现和修复方案。这样 AI 不只是回答问题，而是参与工程排障。

AI 工具最常见的失效方式，不是不会写，而是一次接到的任务太大，导致它把目标、边界和验证混在一起处理。结果通常是：内容很多，改动很多，但最后很难判断到底完成了什么。

更稳定的做法，是把任务先切片，再交给 AI 执行。切片的核心不是拆得更细，而是让每一段都有明确输入、明确输出和明确验证方式。这样 AI 负责产出，人负责把关，整个过程会更接近工程交付。