先说几个核心判断。很多人使用 Microsoft Copilot 将旧代码整理为说明文档时，最常见的误区就是“反复修改提示词但效率依然低下”。根本原因往往不在 Copilot 本身，而在于初始提示词没有锁定核心信息结构和输出边界。

明确文档用途再写提示词

动手之前先问自己：这份文档究竟给谁看？是给新同事快速理解业务逻辑，还是给测试人员核对路径覆盖，或是给产品经理了解功能边界？不同受众决定了你在提示词里需要突出什么。例如，目标用户是运维团队，就应重点标注异常处理路径和依赖的外部服务；如果读者是前端开发，那么 API 入参格式和状态码含义就必须写清楚。

在这个问题没想明白之前，直接写提示词，Copilot 大概率会生成类似“该模块负责处理用户请求”这种泛泛而谈的空话。结果就是，后续还得靠人工一句句删改，效率反而更低。

用三段式模板固定提示词骨架

方法一：角色+任务+约束

一种比较稳妥的写法是：明确告知 Copilot 它应该扮演什么角色、完成什么任务、受到哪些硬性约束。举个例子——

“请以资深后端开发工程师身份，将以下 Python 函数转换为技术说明文档。要求：①开头用一句话概括函数核心职责；②参数列表必须标注类型、是否必填、示例值；③用「正常流程」「异常分支」两个小标题分述执行逻辑；④禁止出现‘可能’‘通常’等模糊表述；⑤输出纯 Markdown，不加解释性文字。”

方法二：输入-输出对照表驱动

另一种方式是直接定义输入与输出的解析格式，让 Copilot 像填空一样工作：

“请严格按以下格式解析代码：
【输入】列出所有入参名+类型+业务含义；
【处理】用带编号的步骤描述主干逻辑（每步不超过15字）；
【输出】说明返回值结构+各字段含义+典型错误码。不要补充任何代码外的信息。”

这里有一个很现实的问题——Copilot 对模糊指令的容忍度真的非常低。如果你没有在提示词里明确写上“禁止出现‘可能’”，它大概率会默认加入推测性描述，而这些推测往往偏离代码的实际行为。

精准喂代码前做两件事

第一步：删掉无关注释和调试用的 print 语句。Copilot 缺乏判断力，它会把“# TODO: 优化缓存”当成待办事项写进文档，也会把“print(‘debug’, x)”误判为关键日志行为。所以，给 Copilot 的代码，越“干净”越好。

第二步：把函数签名单独提炼出来，放在代码块最上方。比如：def calculate_discount(user_id: str, order_amount: float, coupon_code: Optional[str] = None) -> Dict[str, Any]:。Copilot 优先抓取第一行内容，如果函数签名缺失，参数类型和返回结构几乎必然出错。

第三步：如果函数内部调用了某些工具函数，而这些函数的源码你并未提供，那必须在提示词末尾追加一句：“若遇到未提供实现的函数调用，请标注‘[需查阅XXX模块]’并停止展开。”否则 Copilot 会自动脑补那些缺失的逻辑，甚至凭空生成不存在的实现。

说到底，Copilot 是个好工具，但它需要被严格“驯化”。提示词里每一条约束，都是为它画出的安全边界。边界越清晰，产出的文档就越接近你真正想要的样子。