用AI调查复杂技术问题的四个文档-夜雨聆风

用AI调查复杂技术问题的四个文档

01 一个让人头大的问题

最近我在调查一个显示系统的问题：图层叠加后，透明度失效了。

系统架构是 QNX + Hypervisor + Android，链路从 App 到 Framework 到 HAL Composer，再到 VitroIO 的 FE 和 BE 以及 OpenWFD。强时序要求的生产消费 Pipeline，每一层都可能出问题。

琢磨了三天多了，还没有解决，最近运气不大好的样子，天道酬勤技能不触发。

很多内容，特别是代码细节已经超出了我的知识范围。得一层层拆开看。

一边慨叹全栈工程师的要求越来越多了，一边研究用 AI 辅助的方法。几天下来，有些心得可以跟诸君分享。

我整理的第一份文档，叫项目约束。

里面写清楚了几件事：

这相当于给 AI 一张地图，让它知道自己在什么样的地形里工作。

如果不交代这些，AI 会按通用情况推理，但车载系统的显示架构和普通 Android 差别很大，容易跑偏。

第二份文档是Bug现象描述。

我尽量写得具体：

给 AI 定义清楚目标，是讨论调查问题的基础。

第三份文档是调查记录，这是我和 AI 一起维护的。

每次讨论完或进行了某个验证后，要把确认的点、排除的假设、下一步方向记下来。下次再问 AI，先把这份记录给它看。

好处是调查有延续性，不会重复问同样的问题。AI 也能基于之前的结论继续推理，而不是从头开始。

这有点像团队里的 Wiki，大家都能看到调查到哪一步了，避免信息孤岛。

第四份文档是设备操作。

我把硬件设备的连接方式写进去：adb 怎么连、串口怎么配、怎么 dump 信息、怎么安装测试程序、怎么编译烧写。

如果能提供一个软件控制的电源，甚至可以让 AI 自己断电重启。

当然，这些操作都有风险，所以要在文档里写清楚约束：什么情况下可以做什么，哪些操作需要人工确认。

相当于给 AI 配了一套工具，同时给它安全规范。

看完这四份文档，你可能觉得眼熟。

没错，这其实也是我们给程序员安排开发或调查任务时需要提供的信息：项目背景、需求描述、历史记录、环境操作。

以前这些信息可能散落在邮件、聊天、口头交代里，现在整理成文档，既给 AI 用，也给人看。

你可以让开发或 AI 自己去查，但明显会增加时间成本，而且有错误的风险。

目前 AI 的能力还是有限的，上面这些文档其实都是为了让 AI 按照我们的要求进行工作。

我觉得主要限制就是上下文长度，输入过多或压缩后导致的注意力问题，如遗忘、幻觉等。

AI 无法替代人，至少目前不行。它不懂业务场景，不懂项目历史，不懂哪些改动是最近加的、哪些是历史遗留。

但它可以辅助我们，提高效率，扩展能力边界。

我们软件开发者的角色应该从”亲自排查每一行代码”转变为”设计排查策略、准备上下文、判断 AI 的输出是否可信”。

AI 与人互相评审，共同进步。