编程开发 编辑复核
CLI 帮助转操作手册
把命令行帮助、参数和实际限制整理成安全的操作手册，覆盖预检查、示例和失败处理。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名开发者工具文档工程师。请基于真实帮助输出和脚本行为编写安全操作手册，不要凭空增加参数或默认值。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 命令用途、权限和不可逆操作
2. 安装、环境和预检查
3. 按场景的命令、参数和预期输出
4. 常见错误、诊断和停止条件
5. 回滚、审计记录和升级联系人
输入变量：
- CLI 帮助（{{help}}）：提供完整帮助输出和版本。
- 脚本或配置（{{scripts}}）：提供可公开的脚本片段和配置变量名。
- 操作人（{{audience}}）：说明经验、权限和责任范围。
- 安全边界（{{safety}}）：列出删除、写入和生产限制。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 手册中的命令先在测试环境逐步验证，再交给值班人员。
- 危险命令必须显式标注影响和恢复方式。
WHEN IT FITS
适用判断
适合这些情况
- 工具的 help 输出很长，需要整理成按任务组织的操作步骤。
- 团队里只有少数人会用某个命令行工具，需要沉淀文档。
- 要把常用操作固化成可复制的命令序列。
换个做法更好
- 官方已有质量不错的操作文档：直接链接过去。
- 命令只有一两个参数：不需要手册。
- 你没有实际的 help 输出：模型会按记忆编参数，很可能不对。
FAILURE MODES
常见翻车与修正
- 生成的命令包含实际不存在的参数。
模型对 CLI 参数的记忆经常与版本不符。要求所有参数都来自你粘贴的 help 输出，缺失的标注「help 中未见」。
- 手册里的示例命令带有破坏性操作但没有警告。
要求识别出会删除数据、覆盖文件或影响生产的命令，单独标注并加上执行前的确认步骤。
- 按参数罗列，而不是按任务组织。
要求以「我要完成什么」为标题组织内容，每个任务给出完整的命令序列而不是参数说明。
ACCEPTANCE
怎么判断输出合格
- 所有参数都能在你提供的 help 输出里找到。
- 破坏性命令有明确警告和确认步骤。
- 按任务组织，每个任务有完整可复制的命令。
- 标注了工具版本，方便日后核对是否过期。
SAFETY BOUNDARY
使用边界
- 手册里的命令会被人直接复制执行，破坏性操作要加显著警告和前置确认步骤。
- 示例中的主机名、密钥和环境变量要替换成占位符，运维手册常被广泛分享。