PDF 色彩保真工程实践【7】需求交给 GPT，实现交给 Github Copilot

本文是系列文章的最后一篇。前六篇讲清了"做什么"和"怎么做"，这一篇跳出代码回答一个 问题：让这个功能"快而准"落地的，其实是一条双 AI 流水线——我用一句意图加一条关键事实，让 GPT 把它扩写成规格书 myprompt.md，再让 Copilot 按它逐阶段把工程实现出来。

先附上本系列的完整资料：

• 完整源码：https://github.com/AmyLin2013/pdf-cmyk-image
• 本系列文章专栏：PDF 色彩保真工程实践
  - PDF 色彩保真工程实践【1】：聊聊 CMYK 色彩损失：为什么你的 PDF 图片“变色”了？
  - PDF 色彩保真工程实践【2】：用底层 PDF Object API 精准控制 PDF 色彩空间
  - PDF 色彩保真工程实践【3】上手实践：工程结构、依赖集成与一键构建运行
  - PDF 色彩保真工程实践【4】核心实现（上）：从 TIFF 解码到 Flate 流构造
  - PDF 色彩保真工程实践【5】核心实现（下）：拼装 Image XObject、页面资源与内容流
  - PDF 色彩保真工程实践【6】怎么证明“真的无损“？——SHA-256 校验与三个真实踩坑

下面说说怎么做到的,

先还原真相：一条"双 AI"流水线

很多人以为 AI 写出这么一个"保留 ICC 的 CMYK 无损插入"工程，靠的是跟它反复调教对话。
真相是三方接力，而我只在最前面做了两件小事。

第 1 步（人）——写一句意图，外加一条关键事实。 我最初的话很短，但补了一条自己已经
踩出来的领域结论：

我想用福昕 SDK 向 PDF 插入 CMYK 的 TIFF，并保持图像对象仍是 CMYK。我已经确定，
福昕 SDK 的高级图像导入接口不能保留 ICC Profile。 目录下 foxitpdfsdk_11_1_win 是完整
SDK 包……希望在 cmykimage 下放一个 vs2022 能直接编译运行的完整工程。

这条"高级接口保不住 ICC"的事实，就是整份规格书的锚点——后面所有约束都是围着它长出来的。

第 2 步（GPT）——让它把我的意图"续写"成规格书。 我没有自己手写那份长长的
myprompt.md，而是把上面这段话丢给 GPT，只加了一句元指令：

我想在本地用 GitHub Copilot 实现完整功能，已写的要求和提示词如下：[上面那段意图]。
请续写我后续需要给 AI 的提示词，让我能顺序通过 Copilot 完成这样一个代码工程。

GPT 就把它扩写成了那份带"已确认前提 / 固定技术路线 / 目标对象结构 / API 纪律 /
13 个执行阶段 / 22 条完成标准"的规格书 myprompt.md。

第 3 步（Copilot）——执行规格书。 最后我发给 Copilot 的聊天消息几乎只有一句
（真实原文，AIASK.txt 再加一句挂载）：

……我希望用 vs2022 打开直接编译运行。请按照 myprompt.md 中的要求完成任务。

聊天负责"启动"，myprompt.md 负责"定义正确"，Copilot 负责"逐阶段落地"。

📌 一句话结论：真正的杠杆不在聊天框里反复措辞，而是——先用一个 AI 把需求扩写成
可执行、可验收的规格书，再用另一个 AI 去执行它。你只需守住两个人类环节：给出锚定
正确性的关键事实，以及审阅这份规格。

一份好规格书长什么样：拆解 myprompt.md

myprompt.md 不长，但它把"容易翻车的地方"全部前置说清了。它的骨架可以归纳成六块，
每一块都直接对应一类返工风险。

① 已确认的前提——不让 AI 重新"发现"你已知的坑

规格书开头就钉死了事实，省掉 AI 试错：

福昕高级图像导入接口能插入 CMYK TIFF，但不能保留内嵌 ICC，插入后只会是
/ColorSpace /DeviceCMYK。因此本工程不得使用 foxit::common::Image /
ImageObject::SetImage() / PDFPage::AddImage()，也不需要再测试高级路径。

把"此路不通"写死，AI 就不会花半天证明一条你早知道走不通的路。

② 固定的技术路线——给出唯一正式管线

规格书直接画出从 TIFF 到已验证 PDF 的流水线，不留"你看着办"的空间：

CMYK TIFF → libtiff 解析标签 → 提取 ICC → 解码 C/M/Y/K 四通道
   → 用 PDF Object API 造 ICC Profile Stream → 造 [/ICCBased ref]
   → 造 Image XObject → 挂到页面 Resources/XObject → 更新 Contents
   → 保存 → 重新打开验证对象结构

技术路线一旦固定，后面每个阶段都只是"填空"，而不是"选路"。

③ 目标产物结构——把"验收标准"画成靶子

这是整份规格书最值钱的部分。它不描述"我要 CMYK"，而是直接贴出期望的 PDF 对象长相：

% ICC Profile Stream（间接对象）
<< /N 4 /Alternate /DeviceCMYK /Filter /FlateDecode /Length ... >>
% ColorSpace
[/ICCBased 10 0 R]
% Image XObject
<< /Type /XObject /Subtype /Image /Width 1253 /Height 865
   /ColorSpace [/ICCBased 10 0 R] /BitsPerComponent 8 /Filter /FlateDecode ... >>
% 像素排列
C M Y K | C M Y K | C M Y K ...

有了这个靶子，"做对了没有"从主观感觉变成逐字段比对。AI 知道往哪打，你也知道怎么验。

④ API 使用纪律——根治 SDK 幻觉

对付大模型编造不存在的 SDK 接口，规格书立了一条硬规矩：

以 foxitpdfsdk_11_1_win 为唯一依据；用任何 API 前必须在 头文件 / API Reference /
Sample 中确认；禁止凭经验虚构；每个用到的 API 记录：命名空间、类名、函数签名、
参数、返回值、所在头文件、在哪个 Sample 验证过。找不到就明说缺失，不许编近似名字。

这条规矩的直接产物就是仓库里那份 FOXIT_OBJECT_API.md 清单——既堵住幻觉，又成了
后续维护的活文档。

⑤ 分阶段执行计划——把大任务切成可审的闸门

规格书把工程拆成 13 个阶段（分析 API → 设计方案 → 建工程 → 集成依赖 → TIFF 解码 →
ICC 流 → ICCBased → Image XObject → 页面资源 → 内容流 → 控制台 → 验证器 → 编译实测），
并规定：

每完成一个阶段，先汇报实际检查结果、修改文件、编译状态和未解决问题，再进入下一阶段。

这就是"阶段闸门"：AI 每次只推进一小步，你每一步都能 review，bug 也永远只藏在最近一个
阶段里（第 6 篇那三个坑都能精确归位）。

⑥ 可判定的完成标准——一张能打勾的清单

规格书结尾列了 22 条完成标准，条条可判定，例如：

ICC Stream /N == 4；/Alternate == /DeviceCMYK；Image XObject 使用 /ICCBased；
TIFF ICC 与 PDF ICC 字节一致；TIFF CMYK 像素与 PDF 解码数据一致；验证器全部 PASS；
不使用高级图像导入接口；不经过 RGB/RGBA/Bitmap。

"完成"不再是感觉，而是这张清单是否全部打勾。

为什么"规格书 + 短指令"比"反复对话"更好

• 可复现：换个人、换台机器，把同一份规格书喂给 AI，结果趋同；聊天记录做不到。
• 可 review：规格书是静态文档，能像代码一样被评审、被 diff、被沉淀进仓库。
• 成本低：规格书由 GPT 续写，人只需给出锚定事实并逐条审阅前提与完成标准——同样把
  "哪里会翻车"过了一遍，却不必从零手写。
• 自带文档：任务做完，规格书 + FOXIT_OBJECT_API.md + TEST_RESULTS.md 就是这份
  工程的说明书。

一句话：聊天是易失的，规格书是可积累的资产。

AI 与人的分工，一张表说清

规律很清晰：AI 负责"把事做出来"（GPT 写规格、Copilot 写代码），人负责"定义什么算做
对"——给出那条锚定正确性的关键事实，并守住验收标准。

收尾即用：先让 AI 生成规格，再让 AI 执行规格

第一步，用一句元提示词让 GPT（或任意强模型）把你的需求续写成规格书，你只需提供
意图和你已知的关键事实：

我想在本地用 GitHub Copilot 实现一个完整功能。我的意图和已知前提如下：
- 目标：[一句话要做什么]；
- 我已确定的关键事实：[能锚定正确性的领域结论，例如某捷径接口不满足要求]；
- 环境与产物：[SDK/版本、目录、能直接编译运行的工程等]。
请续写我后续需要发给 Copilot 的提示词，整理成一份规格书，包含：已确认前提与禁止事项、
固定的技术路线、目标产物结构（验收靶子）、API 使用纪律（禁止虚构+记录出处）、
分阶段执行计划（每阶段先汇报再推进）、逐条可判定的完成标准。

第二步，把生成的规格书另存为 SPEC.md 并通读审阅（重点核对"关键事实"和"完成标准"），
它的骨架大致如下：

# 一、已确认的前提（不必重新验证）
- [已知结论，例如某捷径接口无法满足要求]；因此禁止使用 [接口名]，也不必再测试。

# 二、固定的技术路线
[输入] → [步骤1] → [步骤2] → … → [产物] → [重新打开/复核]

# 三、目标产物结构（验收靶子）
[贴出期望的对象结构 / schema / 输出样例，越具体越好]

# 四、API 使用纪律
- 以 [SDK 目录/版本] 为唯一依据；用任何 API 前在 头文件/手册/Sample 确认；
- 禁止虚构；每个 API 记录 命名空间/类名/签名/参数/返回值/头文件/验证出处；找不到就明说。

# 五、分阶段执行计划
1. [阶段1] 2. [阶段2] … N. [编译实测]
- 每阶段完成后先汇报"检查结果 + 改动文件 + 编译状态 + 未解决问题"，再进入下一阶段。

# 六、完成标准（逐条可判定）
- [ ] [结构性断言，如 /N==4]
- [ ] [字节/数值一致，如 SHA-256 相等]
- [ ] [自动验收命令全部 PASS]

第三步，在 Copilot 里只说一句"请按照 SPEC.md 完成任务"，然后逐阶段验收。

四个支柱：前提钉死、靶子明确、API 有出处、阶段可审。把它们写进规格书，你就能只发
一句话，然后放心让 AI 逐阶段跑完——每一步都可审、每一条都可验。

结语

回头看，这个 CMYK 无损插入功能真正的"源代码"，其实有两份：一份是仓库里的 C++，另一份
是 myprompt.md 这样的规格书。前者是 Copilot 写的结果，后者是 GPT 帮我写的、让结果
"快而准"的原因。而我这个人类，只做了两件事：给出那条锚定正确性的关键事实，以及审阅
这份规格。

当你学会用一个 AI 把需求扩写成可执行、可验收、可积累的规格，再用另一个 AI 去执行它，
AI 辅助编程就不再是碰运气的对话，而是一条可复现的工程流水线。 福昕 PDF SDK 的底层对象
能力提供了"精确控制"的地基，这条双 AI 流水线提供了"高效可靠"的过程——这就是本系列想
留给你的最后一条经验。

完整源码已开源：https://github.com/AmyLin2013/pdf-cmyk-image ，也欢迎你把这套"一个 AI 写规格、另一个 AI 写代码"的模式套到自己的下一功能上，看看它能不能同样帮你把 AI 用得又快又准。

关于本系列

• 💻 完整源码：https://github.com/AmyLin2013/pdf-cmyk-image
• 本系列文章专栏：PDF 色彩保真工程实践
• 🧩 关于福昕 PDF SDK：可以看开发者站点 版式文档基础软件与智能文档处理能力提供方，试用免费。
• 🆓 免费试用申请：https://developers.fuxinsoft.cn/free-trial/