内容写作 编辑复核
技术文档可读性改写
在不改变技术事实的前提下重排文档结构、步骤、前置条件和错误处理。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名技术文档编辑。请把技术文档改写成读者能按步骤完成任务的版本，不要为了流畅而猜测接口字段或环境配置。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 目标读者、任务和前置条件
2. 按成功路径重排标题和步骤
3. 命令、参数、返回值与示例的核对点
4. 错误处理、回滚和常见失败
5. 缺失信息、过期信息和需要开发确认的项
输入变量：
- 原文档（{{draft}}）：提供需要改写的文档正文或章节。
- 读者（{{reader}}）：说明读者经验和操作环境。
- 成功标准（{{success}}）：说明读者完成后应看到什么结果。
- 文档限制（{{constraints}}）：说明版本、语言、长度和格式限制。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 改写后让真实读者按文档跑一遍，记录首次失败点。
- 敏感配置和密钥只写变量名，不写真实值。
WHEN IT FITS
适用判断
适合这些情况
- 文档内容正确但读者反馈看不懂。
- 文档是由开发写的，充满实现视角的表述。
- 需要保持技术准确性的前提下改善可读性。
换个做法更好
- 文档内容本身有错：先修正内容。
- 你要写的是新文档：用《README 与交接文档草稿》。
- 读者本来就是资深开发：过度简化反而啰嗦。
FAILURE MODES
常见翻车与修正
- 为了通俗把技术表述改得不准确了。
准确性优先于易懂。要求每处改写标注原文，涉及技术含义变化的必须保留原表述并加解释。
- 改写时把代码示例也「优化」了，结果跑不通。
要求代码块原样保留，只改注释和说明文字；确实需要改代码的单独列出让你验证。
- 加了大量背景介绍，文档变得冗长。
要求补充的背景放在可折叠的补充说明里，主线保持简洁，并控制总长度增幅。
ACCEPTANCE
怎么判断输出合格
- 技术含义没有在改写中失真。
- 代码示例原样保留，改动单独标出。
- 文档长度没有明显膨胀。
- 每处改写都有原文对照，便于核对。
SAFETY BOUNDARY
使用边界
- 改写时模型会顺手「修正」参数名和默认值，所有技术细节必须对照代码或官方文档核对。
- 文档示例里的密钥、内网地址和真实账号要替换成占位符再发布。