写命令行工具说明时，最怕那种“输出帮助信息”的通用模板——拿过来改改就敢往GitHub README里贴，结果用户一跑就卡壳。要让ChatGPT生成的文档真正能落地，必须把真实终端环境、用户操作路径、错误反馈链都嵌进去。举个例子：用户刚git clone完项目，兴冲冲地敲./cli --help，结果直接弹个Permission denied。这种卡点，必须在提示词里提前锚死。

下面拆成三个关键维度来聊，每个维度都对应一套可复用的提示词写法。

把本地执行路径写进提示词

第一步：明确声明当前工作目录为项目根目录，且 CLI 已通过 chmod +x ./cli 赋予可执行权限。不加这句话，ChatGPT 默认按“全局已安装”处理，生成的示例就会是 mytool --version——而实际用户第一次接触时根本没装，只会看到 command not found。

第二步：要求所有命令示例必须以 $ 开头，且紧接真实路径前缀，例如：$ ./cli upload --file config.yaml --env prod。禁止出现 mytool 或 toolname 这类虚构别名——它们会让新用户反复翻源码，就为了确认二进制名叫什么。

第三步：强制包含一次失败场景的说明。比如：“当用户未传 --file 参数时，CLI 应输出 Error: missing required flag: --file 并返回非零退出码”。不写这句，ChatGPT 生成的帮助页永远只展示“怎么成功”，不教人“为什么失败”。

绑定具体运维动作

方法一：用「运维动词」替代功能描述。别说“支持配置加载”，改成“用户在 CI 流水线中执行 ./cli sync --config-path ./ci/deploy.yml 后，自动触发 Kubernetes ConfigMap 更新”。这样读者一眼就知道这行命令在真实场景里是干啥用的。

方法二：指定错误日志真实截断位置。要求 ChatGPT 在“常见问题”部分写明：“若输出末尾出现 context deadline exceeded，请检查 ~/.cli/config 中的 timeout_sec 是否小于 30”。这比泛泛而谈“网络超时”有用十倍——因为后者连排查入口都没给。

方法三：插入真实环境变量依赖。例如：“该工具依赖 CI_REGISTRY_TOKEN 环境变量，若缺失则直接退出并打印 FATAL: CI_REGISTRY_TOKEN not set”。漏掉这个依赖声明，DevOps 同事会在半夜收到告警却查不出原因。

注入终端交互细节

第一步：要求所有交互式命令（如 ./cli init）必须标注光标停靠位置。例如：“执行后显示 Enter project name: _，下划线处为输入光标，回车后继续提示 Select region [us-east-1]: _”。用户照着敲，每一步都知道自己该在哪输入。

第二步：定义颜色与符号含义。明确写入提示词：“成功状态行用绿色 ✅，失败用红色 ❌，警告用黄色 ⚠️；所有颜色均通过 ANSI 转义序列实现，不依赖外部库”。这样文档里写“执行后看到绿色 ✅”，用户就知道不是靠猜的。

第三步：限定输出宽度适配 80 列终端。指令中必须含“每行不超过 76 字符，自动换行点优先选空格或等号后，避免在 JSON 键名中间截断”。一个简单的约束，能避免文档示例在窄终端里彻底跑偏。