每天写业务代码、修线上问题、参加评审的后端或全栈开发，日常工作里真正写代码的时间常被排查问题、写文档和同步进度挤占，很多重复性的文字和样板代码其实可以交给 AI 起草。文档是开发中最容易被拖延的部分，没有文档，新人上手和跨团队协作的成本都会很高。下面以程序员的真实场景为例，演示用 AI 写技术文档的完整流程：把代码、接口定义或口述设计交给 AI，让它按模板生成文档初稿，再由你补充设计决策和注意事项。

典型场景

程序员完成了“完成订单服务接口重构，接口平均响应从约 300ms 降到 120ms 左右（以压测为准）”相关的开发，需要给业务方同事写接口文档和使用说明。代码已经写完，但文档迟迟没动，大家只能来问。现实中，程序员还得兼顾“评审同事提交的 3 个合并请求”等日常事务，所以更需要一套拿来就能用的方法。

推荐工具

编辑器里的编程助手（GitHub Copilot、Cursor、通义灵码等）可以读取代码生成注释和文档；对话助手适合根据接口定义写说明；文档可以放在 README、Wiki 或 API 文档工具中。

举个例子

下面这个例子是虚构的：小郑遇到的难题是“依赖的第三方支付 SDK 下周升级，可能需要适配”。为了不让它拖慢“修复支付回调偶发超时问题”的进度，小郑决定借助 AI 写技术文档。第一次只写了一句简单的要求，结果很空泛；第二次把对象（技术负责人）、目的和限制条件都写清楚，输出就可用多了。这也是本文提示词模板要把背景写全的原因。

操作步骤

  1. 确定读者：使用接口的开发、测试还是业务同事
  2. 提供代码或接口定义，以及你想强调的约束
  3. 让 AI 按模板生成：用途、参数、返回、错误码、示例
  4. 请一位读者试读，根据疑问修订

可复用的提示词

下面的提示词可以直接复制，按程序员的实际情况替换细节：

【背景】身份：每天写业务代码、修线上问题、参加评审的后端或全栈开发；平时主要和业务方同事和技术负责人打交道。
请根据下面的接口代码生成接口文档，读者是调用这个接口的其他团队开发者。

接口用途：按服务名查询“接口调用记录”记录
（粘贴接口代码或定义）

文档结构：
1. 接口说明（一句话用途）
2. 请求方式和路径
3. 请求参数表：参数名 / 类型 / 是否必填 / 说明 / 示例
4. 返回字段表
5. 错误码说明
6. 请求和返回示例（JSON）
7. 注意事项（分页、频率限制等）

代码中无法确定的信息请标注“待补充”，不要猜测。

AI 输出示例（示意）

下面是演示用的输出示例，其中的人名、数字和事项均为虚构，实际使用时请以你自己的资料为准：

查询记录

按服务名分页查询“接口调用记录”记录。

GET /api/v1/records

参数类型必填说明示例
categorystring是服务名order-api
start_datedate否起始调用日期2026-10-01
pageint否页码，默认 11

错误码：400 参数错误；403 无权限；429 请求过于频繁（频率阈值：待补充）

返回示例

{"total": 2, "items": [{"id": 1, "category": "order-api", "amount": 120}]}

注意示例中所有内容都是虚构的。实际使用时，AI 的输出质量取决于你提供的材料是否完整、要求是否具体。

避坑指南

  • AI 会根据代码推断行为，但不知道设计意图，“为什么这样设计”要你来补。
  • 示例数据用虚构值，不要贴真实的密钥、内网地址、数据库连接串和用户数据。

给程序员的特别提醒

把报错堆栈、相关代码片段和运行环境版本一起贴给 AI，比只描述现象有效得多。另外，AI 生成的代码必须经过本地运行、测试和代码评审，不要直接合入主干。

很多程序员还会这样做：让 AI 先解释思路再给代码，便于你判断方向对不对。

举一反三

  • README：为项目生成安装、配置、运行和常见问题说明。
  • 代码注释：为复杂函数生成文档字符串。

相关阅读