背景：售前方案的痛点
做过APS售前的同行应该都有体会：每次拜访客户做完调研，回来要把数小时的访谈转化成一份专业的方案 PPT，这个过程往往比调研本身要耗时得多。你需要整理纪要、提炼痛点、匹配产品能力、组织方案逻辑、编写汇报 PPT——一套流程走下来，一个资深顾问也要花 3-5 天。
过去一段时间，我开始尝试用 Claude Code来系统化解决这个问题。经过几轮尝试，现在已经形成了一套输出成果相对可用的流程。本文是对这套流程的设计思路与具体方法的总结与分享。
整体思路：分阶段、可审核、人机协作
之前用其他 AI 工具尝试过通过输入整理后的调研纪要，妄想让 AI "一步到位"直接生成 PPT。实践证明那条路走不通——AI 缺乏对客户语境的判断力， 缺少对APS 产品能力的理解，一次性输出的内容往往"看起来专业但经不起推敲"，并且输出的风格也不太适用于严肃的售前方案汇报。
这次在 Claude Code 中的做法是把整个过程拆成 5 个阶段，每个阶段有明确的输入、输出和质量检查点，人在关键节点做审核和决策：
阶段 0：材料盘点与事实摘要 → 阶段 1：模块归纳 → 阶段 2：现状文章 → 阶段 3：方案文章 → 阶段 4：PPT 生成
每个阶段完成后暂停，等我 对输出材料确认后再进入下一阶段。这样做的好处是，如果某个阶段的输出有问题，修正成本很低，不会污染后续产出。
项目目录结构
在对具体阶段做详细说明前，先看一下整个项目的目录组织结构：
aps_presales/
├── CLAUDE.md # 项目宪法：AI 每次工作前必读
│
├── knowledge/ # 【只读】长期沉淀的知识库
│ ├── aps-capabilities.md # 产品能力库（AI 写方案的能力边界）
│ ├── module-library.md # 标准模块库（可选APS模块清单）
│ ├── pain-point-patterns.md # 痛点模式库（常见痛点归纳）
│ └── industry/ # 按行业细分的知识（汽车/汽配/电子等）
│
├── templates/ # 【只读】写作规范模板
│ ├── writing-style.md # 动词库、禁用词、行文风格
│ └── article-structure.md # 两篇文章的章节结构规范
│
├── reference/ # 【只读】标杆方案参考
│ └── xx客户APS售前方案V13.pptx # PPT 生成的母版（视觉金标准）
│
├── prompts/ # 【只读】各阶段的标准提示词
│ ├── 00-inventory-and-facts.md # 阶段 0：材料盘点
│ ├── 01-extract-modules.md # 阶段 1：模块归纳
│ ├── 02-write-status-article.md # 阶段 2：现状报告
│ └── 03-write-solution-article.md # 阶段 3：方案报告
│
└── projects/{客户名}/ # 【可读写】每个客户独立工作区
├── 01-source/ # 原始一手材料（人工录入）
│ ├── records/ # 调研记录（必有）：转录稿/纪要
│ └── docs/ # 客户辅助材料（可选）：需求说明/流程图/数据包
│
├── 02-facts/ # 阶段 0 产物
│ ├── inventory.md # 材料清单 + 覆盖度评估
│ └── facts.md # 结构化事实摘要（带 [来源-定位] 引用）
│
├── 03-modules/ # 阶段 1 产物
│ └── modules.yaml # 模块契约（后续所有产出的锚点）
│
└── 04-content/ # 阶段 2-4 产物
├── article-status.md # 阶段 2：现状与需求理解报告
├── article-solution.md # 阶段 3：详细解决方案报告
├── gen_ppt_ch2.py # 阶段 4：PPT 生成脚本
└── {客户}-APS方案.pptx # 阶段 4：最终 PPT 产物
这个结构有几个设计考虑：
只读区 vs 可读写区的分离。knowledge/、templates/、reference/、prompts/ 是跨项目复用的资产，任何单个项目都不应该修改它们——这些是"基础设施"。每个客户的所有产出都收敛在 projects/{客户}/ 下，与其他客户完全隔离。
按阶段编号的子目录。01-source → 02-facts → 03-modules → 04-content，数字前缀直接反映了阶段顺序。AI 在任何时候都知道"我现在处于哪个阶段、应该读什么、应该写什么"。
一个项目宪法文件。CLAUDE.md 放在根目录，是 AI 每次工作前必读的"项目宪法"——定义了角色、工作流、硬性约束、写作风格、目录约定。有了这份文件，哪怕换一个新对话窗口，AI 也能快速进入角色。
提示词独立成文件。每个阶段的标准提示词（prompts/0X-xxx.md）单独维护，不埋在代码或 CLAUDE.md 里。这样迭代某个阶段的提示词不会影响其他阶段，也便于版本管理。
阶段 0-1：从调研记录到结构化事实
输入是客户调研的一手材料——会议转录稿、访谈纪要、客户提供的需求说明文档等。AI 的第一个任务不是直接写方案，而是先基于输入的信息整理事实。
具体地，AI 会输出两份文件：一份是材料清单（覆盖了哪些维度、哪些信息还缺），一份是按主题归集的事实摘要（每条事实都标注来源，比如"转录稿-39:40"或"URS-UR-PP-003"）。
这一步的关键约束是：禁止编造。AI 只能从材料中提取事实，不能自行推断客户没说过的数字或细节。如果信息不足，主动告知"这个维度缺信息，建议补一次调研"。
事实确认后，AI 从标准模块库中选取适合该客户的业务模块组合（比如"主生产计划 + 车间排程 + 物料计划"），输出一份 modules.yaml 作为后续所有产出的指导。
阶段 2-3：两篇结构化长文报告
接下来 AI 撰写两篇 Markdown 报告：
文章 1（业务现状与需求理解）：按模块梳理客户当前业务现状，提炼核心痛点（每个痛点都能追溯到事实），拆解项目目标与实现前提。
文章 2（详细解决方案）：针对每个痛点展开方案，每条功能要点都标注对应哪个痛点（比如 [PAIN-01]），确保方案与痛点一一闭环。
这两篇报告有几个硬性约束：模块数量/顺序/命名必须完全一致；所有客户细节必须能在事实摘要中找到来源；方案能力必须来自产品能力库，不能承诺不存在的功能。
写作风格也有明确规范：用"承接、编制、下达、拉动、协同"这类专业动词，禁止"赋能、抓手、业界领先"这类空洞营销词；痛点描述遵循"现状→后果→根因"三段式；方案要点遵循"动作+对象+价值"模式。
阶段 4：PPT 生成——最关键的一步
有了两篇结构化报告，最后一步是生成 PPT。这一步我踩了不少坑，最终找到了一个效果很好的方案。
踩坑经历：最初尝试过调用一些评价较高的 PPT 生成 Skill，但是生成的方案 PPT 效果与风格完全不适用；后来尝试用 python-pptx 从空白生成 PPT，结果发现无论怎么调参数，输出的 PPT 在配色、字体、版式上都和公司标准模板差距很大。。
最终方案：复制一份已有的标杆方案 PPT 作为母版，用代码只做文字替换，完全保留原有的设计资产（母版、配色、字体、图形、装饰元素）。
具体技术实现：
- 2. 删除不需要的页面（封面、目录、不相关模块页、Thanks 页）
- 3. 用 python-pptx 遍历每张幻灯片的 shapes，按 shape name 或文本内容定位，替换为本项目的内容
- 4. 表格单元格使用
buAutoNum（PPT 原生自动编号），不手写序号 - 5. 每条内容拆为"加粗小标题 + 正常正文"两个 run，与参考 PPT 的格式完全一致
这个方案的效果是：输出的 PPT 在视觉上与参考方案几乎一致，只是文字内容换成了新客户的。
关键设计决策
回顾整个流程，有几个设计决策是成败关键：
1. 人审核、AI 执行。AI 负责"从材料中提取事实、按规范组织内容、按模板填充 PPT"这些重复性工作；人负责"确认事实是否准确、痛点提炼是否到位、方案逻辑是否成立"这些判断性工作。
2. 用约束代替期望。与其告诉 AI "写得专业一点"，不如明确规定"禁止编造客户未提及的数字""禁止承诺能力库之外的功能""禁止使用营销话术"。约束比期望更容易被执行和检查。
3. 标杆驱动而非规则驱动。与其写一百条排版规则，不如直接给一份标杆 PPT 说"照这个来"。AI 通过分析参考 PPT 的 XML 结构，能精确复刻其编号方式、加粗规则、字号配置。
4. 知识库沉淀。产品能力库（aps-capabilities.md）、标准模块库（module-library.md）、痛点模式库（pain-point-patterns.md）、写作风格规范（writing-style.md）——这些是跨项目复用的资产，每做一个项目都在完善它们。
为什么只让 AI 输出"客户现状与需求理解"章节的 PPT
完整的售前方案通常至少包含两大部分：客户现状与需求理解、详细解决方案。但在 PPT 生成这一步，我目前只让 AI 输出第一部分。之所以这么做，原因有两个：
第一，客户现状章节的 PPT 格式高度统一。 不管是什么行业、什么客户，这一章的页面结构几乎不变——业务现状三列表（模块/现状/痛点）、核心痛难点总结、项目目标以及未来总体业务架构。具体内容会随着客户变化，但骨架不需要改变变。这恰好是"复制母版 + 替换文字"方案最擅长的场景。
第二，这一章是售前顾问调研后最耗时的"苦力活"。 调研结束后，顾问需要把数小时的访谈转化为结构化的现状梳理、痛点提炼、目标拆解——这个过程本质是"从非结构化材料中提取事实并按固定框架组织"，而这正是 AI 的强项。让 AI 承担这部分工作，顾问的时间就能释放出来聚焦在更有价值的事情上。
而详细方案章节则不同。不同客户的方案差异较大，PPT 的页面布局因客户而异，很难用一套母版覆盖。更重要的是，方案部分涉及大量产品细节和场景适配，这些需要顾问基于对产品的深度理解来把控，AI 在这里的角色更适合做"内容草稿"（也就是阶段 3 输出的 article-solution.md），而非直接输出 PPT。
所以当前的分工是：AI 负责从调研到现状 PPT 的全链路自动化（阶段 0-4），详细方案部分 AI 输出结构化长文作为素材，PPT 制作由顾问基于素材手工完成。 这个边界划在"格式可统一"和"格式因客户而异"的分界线上，是当前投入产出比最优的切分点。
适用边界与局限
这套方法不是万能的，有几个前提条件：
- • 需要有一份质量较好的标杆方案 PPT 作为母版
- • 需要前期投入时间建设知识库（产品能力库、模块库、写作规范等）
- • 调研材料的质量直接决定输出质量——"garbage in, garbage out"
但在这些前提满足的情况下，这套流程确实能把售前方案输出从"依赖个人经验的手工活"变成"有标准流程的半自动化产线"。
希望这个分享对同行有参考价值。如果你也在探索 AI 辅助APS项目实施与售前的实践，欢迎交流。
