撰写技术文档时，许多人第一反应是“直接把需求丢给AI就能搞定”——结果往往事与愿违：术语前后不统一、操作步骤残缺不全、逻辑衔接生硬混乱。实际上，要让Nova AI稳定输出可直接使用的技术文档，关键并不在于AI工具本身，而在于你提供的提示词是否足够精准、足够“到位”。

用一句话概括：角色定位、任务范围、格式规范、关键细节，每一项都不可或缺。下面我们逐一拆解、深入讲解。

定义AI角色与专业背景

提示词开头，先用一句话锁定AI的专业身份。不要写“你是一个技术文档工程师”——这种描述太过笼统。要精确到具体领域和职级，例如：“你是一名拥有5年嵌入式Linux驱动开发经验的高级技术文档工程师，现为ARM Cortex-A系列芯片SDK编写用户指南”。

这一步决定了术语的专业颗粒度。写“嵌入式Linux驱动”比写“软件文档”更能触发精准的知识库调用；写“ARM Cortex-A系列”比写“处理器”更能激活架构级别的表述习惯。如果跳过角色定义，Nova AI默认会走通用IT写作模型，很可能把“device tree binding”简写成“设备树配置”，直接遗漏Linux内核文档中的标准命名规范。

声明文档类型与读者画像

以下两种方法，任选其一即可。

方法一：直接声明文档类型 + 读者层级
例如：“输出一份面向固件工程师的‘SPI Flash烧录失败排查清单’，要求包含现象→原因→验证命令→修复动作四段式结构。”

方法二：用否定排除法收紧范围
例如：“不要写成培训PPT讲稿，不解释SPI协议原理，不列出所有Flash型号参数表，只聚焦J-Link烧录时出现‘Verify failed’报错的3种现场可判别原因。”

这里有一个容易踩的坑：读者层级错位会导致操作指令失效。比如给FAE（现场应用工程师）写的文档里混入“请检查arch/arm64/boot/dts/下的dtsi文件”，但FAE现场没有源码权限，这条指令根本无法执行。因此，读者画像绝不能只是走过场。

指定结构与格式硬约束

这一步操作起来并不复杂，但漏掉任何一个约束都会让AI跑偏。记住三个要点：

第一步：用冒号分隔标题层级，强制生成带编号的步骤链
例如：
“1. 现象描述：用≤15字概括报错信息 → 2. 必检项：列出3个硬件连接检查点 → 3. 命令验证：给出带sudo权限说明的shell命令 → 4. 日志截断：标注dmesg输出中必须高亮的关键词”

第二步：对关键字段加引号，锁定字面值
“所有‘ERROR’‘timeout’‘CRC mismatch’必须原样保留，不得替换为‘错误’‘超时’‘校验失败’”——这个约束如果不写，AI很可能会自作主张翻译成中文，导致用户复制后命令对不上。

第三步：禁用AI自由发挥的表达方式
“禁止使用‘一般来说’‘建议您’‘可以考虑’等模糊措辞；每个操作动词必须是‘执行’‘断开’‘重置’‘替换’等可立即落地的强动作词。”这一步能直接砍掉AI那些模棱两可的“车轱辘话”，让文档变成可执行的操作清单。

直接把上面这种格式模板粘贴进提示词，就能生效。但漏掉引号约束，AI很可能把“dmesg -t | grep -i ‘spi’”改成“查看系统日志并搜索spi关键字”——虽然意思一样，但失去了可复制性，用户没法直接粘贴执行。

注入真实上下文片段

把实际报错日志、截图文字描述、硬件连接拓扑图的文字转译，作为提示词的最后20%内容。举个例子：
“附现场日志：‘[ 124.892105] spi-nor spi0.0: unrecognized JEDEC id bytes: 00, 00, 00’；硬件连接：STM32F767 + W25Q32JV + 3.3V供电，CS线经10kΩ上拉”

没有上下文的时候，Nova AI会按概率生成最常见场景——比如Linux主机 + Generic SPI controller。但你的实际环境是裸机 + 自定义GPIO模拟SPI，那整个排查路径就是错的。上下文必须全部是纯文本，别写“见附件截图”，Nova AI解析不了图像或文件。