文章归档

终端排障最容易卡住的地方，不是缺少命令，而是缺少顺序。看到一个异常现象后，工程师往往会同时打开日志、进程、网络、磁盘和配置，信息量迅速膨胀；AI 也会在上下文混乱时给出看似合理、实际跳步的建议。

更稳妥的做法，是把 AI 放在“整理证据”和“生成下一步检查清单”的位置上。它不替代现场判断，也不直接给最终结论，而是帮助我们把 Android 与 Linux 环境里的零散输出，收敛成可复现、可解释、可交接的排障记录。

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

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

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

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

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

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

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

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

代码审查最重要的价值，不是把变量名挑得更整齐，而是尽早发现行为风险、边界遗漏和维护成本。AI 工具可以快速阅读 diff、追踪调用链、补充测试思路，但如果直接问“这段代码有没有问题”，得到的答案往往很泛，甚至会把风格偏好包装成严重缺陷。

更稳定的做法，是把 AI 放进一个明确的审查流程里：先限定审查范围，再按风险分层阅读，最后把发现的问题转成可执行的整改项。这样它不是替代人工判断，而是帮助维护者更快看清变化背后的影响面。

AI 编程工具的效果，很多时候不是由模型本身单独决定，而是由它拿到的上下文决定。同一个需求，如果只给一句“帮我修一下登录问题”，输出往往会很泛；如果补充项目结构、复现步骤、日志、约束和验证命令，AI 就更容易给出可落地的修改。

上下文工程不是写更长的提示词，而是把项目里真正影响判断的信息组织好，让 AI 在开始动手之前就知道边界、目标和验收方式。对个人项目和团队项目来说，这比临时追问更稳定，也更容易复用。

重构最怕的不是代码改得多，而是改完以后说不清楚行为有没有变化。AI 工具能很快移动代码、抽函数、改命名、补类型，但如果缺少边界和验证，大规模重构很容易从“改善结构”变成“引入不确定性”。

更稳妥的做法，是把 AI 当成一个执行力很强的工程助手，让它在明确目标、有限范围和可重复验证的约束下工作。重构不应该一次性追求“变得优雅”，而应该被拆成一组可以审查、可以回滚、可以证明行为不变的小步骤。

嵌入式项目很容易变成一堆 SDK 压缩包、临时补丁、手工改动和不可复现镜像。项目目录和协作方式如果不规范，团队越多人，问题越难追。

AI 工具已经可以很快生成一个功能、修复一个问题，甚至顺手补上测试。但在真实项目里，“能生成”不等于“能合并”。代码进入主干之前，仍然需要经过可读性、边界条件、兼容性、测试和运维风险的检查。

更实用的做法，是把 AI 生成代码后的审查过程固定成一张清单。这样每次变更都能从“看起来能跑”推进到“可以被团队维护”，也能减少人工 review 时反复追问上下文的成本。