这是一个虚构但很典型的案例：小孙是一位每天写业务代码、修线上问题、参加评审的后端或全栈开发，最近手头在忙“完成订单服务接口重构，接口平均响应从约 300ms 降到 120ms 左右（以压测为准）”，同时还要准备“上线订单服务灰度”。这次小孙需要整理一份给技术负责人的技术方案文档，决定试试 AI 评分标准打分。

背景

对小孙来说，真正写代码的时间常被排查问题、写文档和同步进度挤占，很多重复性的文字和样板代码其实可以交给 AI 起草。偏偏这次还遇到一个变数：依赖的第三方支付 SDK 下周升级，可能需要适配。技术方案文档需要尽快交给技术负责人，时间并不宽裕。

第一次尝试：问题出在哪

小孙一开始只写了一句话：

帮我写一份关于“订单服务从单体拆分为微服务”的技术方案文档。

结果 AI 给出的内容四平八稳却用不上。复盘下来，主要有两个问题：

  • 没有等级描述只说打 1-10 分。
  • 不同批次用不同标准。

改进后的提示词

小孙按照评分标准打分的思路重写了提示词，核心是为每个维度写出 1 分、3 分、5 分分别是什么样子：

请按下面的评分标准，评价程序员写的这份技术方案文档。
| 维度 | 1 分 | 3 分 | 5 分 |
| 结论清晰 | 找不到结论 | 有结论但靠后 | 开头即给出结论 |
| 依据充分 | 没有依据 | 部分有依据 | 每个判断都有依据 |
| 读者友好 | 术语堆砌 | 偶有难懂之处 | 技术负责人一读就懂 |
输出：每个维度的分数 + 引用原文的理由；最后给出两条最值得优先修改的建议。
材料：[粘贴]

结果（示意）

下面的效果为虚构演示，用来说明这类改进通常带来的变化：

示例输出（虚构）：结论清晰 3 分——结论出现在第三段“建议推迟上线”，应移到开头；依据充分 4 分——成本数据有来源，但用户影响缺少数据；读者友好 2 分——“灰度”“回滚”未解释。

拿到结果后，小孙没有直接转发，而是先检查关键事实和数字，再补上 AI 不知道的背景。

复盘：这次用到的方法

  • 把评分标准和待评对象一起交给 AI。
  • 要求每个维度给分并引用原文说明理由。
  • 汇总分数后让 AI 给出最优先的两条改进建议。
  • 为关键分数写出具体描述，AI 打分才有依据。

之后小孙发现，同样的方法也适用于另一类场景：对比修改前后的版本是否真的变好。

复盘时小孙还想到一个问题：可以给自己的作品打分吗？答案是：可以，这是自我检查的好办法，但要意识到 AI 不了解你的全部背景。

给程序员的提醒

把报错堆栈、相关代码片段和运行环境版本一起贴给 AI，比只描述现象有效得多。AI 生成的代码必须经过本地运行、测试和代码评审，不要直接合入主干。另外，对话里不要出现密钥、内网地址、数据库连接串和用户数据。

一个额外的小技巧：同一份材料修改前后各打一次分，直观看到改进效果。

换成你的场景

把案例中的技术方案文档换成你手头的材料，把技术负责人换成你的读者，提示词结构基本不用改。真正需要花心思的是背景描述：写得越贴近实际，结果越可用。

相关阅读