# Presales Proposal Builder

> 面向政企、集团企业和档案信息化项目的售前方案内容总控。用于编写、重构、审查解决方案、建设方案、立项或可行性报告、客户呈报材料以及 AI、数据治理或产品方案；负责需求重构、安铂能力映射、客户叙事、证据和承诺边界，并协调载体 Skill。完整投标、技术标、独立报价、纯主题研究、演示数据和单纯文件转换不由本 Skill 主控。

- Skill: `wjjjjjjjjjjj/presales-proposal-builder` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add wjjjjjjjjjjj/presales-proposal-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wjjjjjjjjjjj/presales-proposal-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wjjjjjjjjjjj (https://skillmd.com/u/wjjjjjjjjjjj)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/wjjjjjjjjjjj/presales-proposal-builder

---


# 售前方案编写

把方案写成客户可判断、供应商可兑现、后续可验收的正式文本。不要把功能清单扩写成方案。

## 协同关系

先完整读取并遵循 `presales-consultant-persona`。本 Skill 负责方案内容主线和质量总控；按任务叠加专用 Skill：

- 创建或编辑正式 Word：使用 `documents`；只需文本稿时不强制生成 DOCX。用户提到“公文格式”“仿宋”“政府正式呈报”或“大理州政协那套格式”时，必须读取 [official-document-format.md](references/official-document-format.md)。
- 创建或重大重构 PPT：使用 `amber-pptx-style` 和 `presentations`。先提交完整逐页内容稿，取得明确确认后再生成 PPT。
- 完整投标或响应文件：交给 `bid-document-builder` 总控。
- 技术标、技术响应或评分技术项：使用 `bid-technical-proposal`。
- 档案信息化报价清单或预算分配：使用 `archive-quotation-builder`。
- 外部主题深度研究：`research` 只提供事实、观点和来源；本 Skill 决定客户叙事、产品口径和承诺边界。
- 演示数据或 PoC 样本：`demo-data-builder` 负责样本和验证数据；本 Skill 只描述演示目标、业务价值和边界。
- 明确要求转成 Markdown：使用 `markitdown-converter`；单纯阅读、总结或高保真编辑使用对应文档 Skill。
- 读取本地 PDF、Word、PPT、Excel：按文件类型使用对应读取 Skill。

不要复制这些专用 Skill 的排版、报价或投标流程。

## 强制工作流

### 1. 建立方案任务卡

先确认或合理推定以下信息：

- 项目或客户名称
- 决策场景：立项、采购、交流、汇报、实施、升级改造
- 主要受众：领导决策层、业务管理层、档案部门、信息化部门、技术评审
- 交付载体、预期篇幅、正式程度
- 是否采用公文格式、客户模板或指定字体版式
- 客户现状、表象需求、已知约束
- 可用来源、产品口径、预算口径
- 本次允许修改的范围和明确不做的内容

信息不足时，先形成最可能正确的工作假设并标注，只问一个会实质改变方案方向的关键问题。不要一次抛出问题清单。

正式方案预计超过 4 页或涉及多个来源时，在内部工作目录建立 `proposal_manifest.json`，字段见 [manifest-contract.md](references/manifest-contract.md)，并运行。该文件不得放入客户输出目录或投标提交包：

```powershell
python "<skill-dir>/scripts/validate_proposal_manifest.py" proposal_manifest.json
```

将 `<skill-dir>` 替换为本 Skill 的实际目录，不要假定当前工作目录就是 Skill 目录。

### 2. 读取与登记来源

遵守项目级上下文规则。优先读取现有 `summaries/` 和知识库。对 `docs/`、`archive/` 中 20 页以内的原始文件，读取前先询问用户；20 页以上按下段生成摘要。只有用户明确要求读取原文时，才完整采用相应原文。

原始材料超过 20 页且没有可用摘要时，先生成任务摘要存入 `summaries/`；摘要上限服从项目 `AGENTS.md`，无项目规则时不超过 2000 个中文字符。摘要是导航层而非证据替代品，须保留文件、页码或章节等定位信息；用户明确要求核对原文时回到相应原文。预计单次任务上下文超过 150K token 时，先报告范围和拆分建议并请求确认。

按以下优先级取材：

1. 用户本轮明确提供或确认的事实
2. 当前项目摘要和既有正式成果
3. 公司产品知识库、白皮书和功能清单
4. 官方政策、标准、客户公开材料
5. 通用行业经验

登记每项来源的用途。采购需求只能证明客户要求，不能证明供应商具备相应能力；客户原话也不能自动变成产品承诺。

对可能变化的政策、标准、行业前沿、产品信息或公开事实进行联网核验，优先使用官方或一手来源，并保留可追溯链接。

### 3. 建立安铂产品能力映射

用户提供需求内容、功能要求、URS、需求清单或交流纪要时，必须在起草方案前完成内部映射：

1. 拆分客户需求，保留原始业务含义。
2. 优先检索安铂现有产品、组件和已验证功能。
3. 建立“客户需求 → 安铂产品/组件 → 已验证能力 → 匹配程度 → 方案写法”关系。
4. 匹配程度使用“标准能力、扩展能力、能力缺口、第三方依赖”。
5. 标准能力直接纳入方案；扩展能力说明边界；能力缺口和第三方依赖不得伪装成现成功能。

需求是业务输入，安铂现有产品能力是供给边界。先用现有能力形成可兑现的方案底座，再围绕客户场景、流程和价值组织文字；不要先按照客户措辞创造新平台或新产品。

该映射表属于内部分析材料，除非用户明确要求，不直接放入客户成稿。

### 4. 重构需求

在写目录前完成五项判断：

1. 客户表面提出了什么。
2. 背后真正影响业务、管理或决策的问题是什么。
3. 操作层、管理层、战略层分别受到什么影响。
4. 项目为什么现在做，不做的机会成本是什么。
5. 最可能导致项目失败或决策人被追责的点是什么。

把功能描述反向翻译为“业务场景 + 管理问题 + 能力诉求”。不要把后文章节中的功能原句复制到需求分析。

### 5. 选择方案类型

根据受众与用途选结构，不套固定模板。读取 [structure-playbook.md](references/structure-playbook.md)：

- 领导决策或立项报告
- 营销型解决方案
- 技术建设方案
- 小型正式呈报材料
- 既有方案增补或重构

先回答“为什么建、解决什么、如何落地、如何控制风险”，再决定功能展开深度。

### 5.1 建设方案与解决方案的行业化写法

只要用户要求编写“建设方案”或“解决方案”，且任务不属于完整投标、逐项技术响应、独立报价或纯主题研究，就默认按高质量行业建设方案组织，不将“需要做什么”的功能、任务或表格清单扩写后直接交付。

1. 先从客户所属行业、组织层级、业务链、管理责任和既有约束中重构问题，再说明建设目标、总体方法、系统与应用如何协同落地、实施质量如何保障以及建成后如何持续运行。
2. 用“业务事实或痛点—管理风险—建设路径—可验收结果—前提边界”完成核心论证。功能是支撑建设路径的证据，不是方案的起点和主体。
3. 架构、流程和场景承担解释复杂关系的责任。用户要求系统框架、功能架构、应用架构、接口、实施或安全时，分别展开相应设计并保证术语、对象、责任和数据流一致；不要用一张泛化架构图替代所有设计内容。
4. 正文以连续段落和必要图示为主，体现行业问题如何被治理、业务如何闭环、责任如何落实。表格只用于阶段计划、责任分工、验收清单、价格或同字段对比，不能把背景、总体思路、技术路线和建设内容压缩成“事项—功能—说明”式表格。
5. 避免全篇从“模块一、模块二”或“建设内容如下”开始。确需展示功能时，先说明其服务的业务场景、处理对象、上下游关系和管理结果，再按能力链展开。

涉及集团型、多单位、多来源系统的电子档案或电子会计档案建设时，读取 [group-electronic-archive-pattern.md](references/group-electronic-archive-pattern.md)，并将专项模式与当前客户事实、已验证能力和项目范围结合，不照搬为固定目录。

### 6. 编写内容主线

默认采用以下逻辑，可按项目裁剪：

1. 背景与建设必要性
2. 业务现状与核心问题
3. 目标业务结果
4. 总体思路与实现路径
5. 建设范围与建设内容
6. 实施路径与组织保障
7. 预期成效与验收关注点
8. 投资估算与范围口径
9. 风险、前提与责任边界

执行以下写作规则：

- 先写业务结果，再写系统目标和功能。
- 每项能力至少对应一个业务场景、一个问题和一个可感知结果。
- 用连续段落完成论证；只在报价、实施计划、对比关系或重复性结构中使用表格。
- 建设方案和解决方案默认以“问题—方法—架构—场景—实施保障—运行成效”形成论证闭环。功能清单仅用于内部能力核验或作为正文中相应建设路径的支撑，不得替代行业方案的叙事和设计。
- 站在客户视角写正式文本，优先使用客户或项目全称；减少“贵司”“我方”“本次沟通”等供应商或过程性措辞。
- 对外正式稿删除沟通痕迹、写作说明、占位式套话和内部判断过程。
- 优先使用安铂知识库中的正式产品名称和已验证功能。客户需求超出已有能力时，写成扩展功能、第三方依赖、待评估事项或不在本期范围，不自造产品。
- 客户成稿直接陈述项目能力和业务作用，不得出现“参照安铂功能清单”“根据安铂知识库”“依据产品白皮书”“内部产品资料显示”“按 Skill 要求”等暴露内部工作依据的话语。
- 技术内容必须落到具体档案业务链、数据对象、参与角色、处理步骤和验收结果，不写空泛平台概念。
- 修订既有文件时只改用户授权范围；不顺手重写其他章节，不覆盖用户无关修改。

### 6.1 客户直呈版规则

当用户明确表示材料要直接呈现给客户、领导或采购方时，将成稿视为客户最终阅读版本处理：

- 删除内部工作痕迹，包括产品清单、知识库、内部参照、能力映射、方案生成过程、Skill 名称和“根据资料/参考清单”等供应商内部表述。客户可见稿只保留面向客户的事实、建议、边界和交付说明。
- 方案摘要不是默认章节。只有用户明确要求摘要、执行摘要或领导摘要时才保留；否则从封面直接进入目录和正文。
- 交付 DOCX 且包含目录时，使用 Word 动态目录字段，并设置打开文档时更新字段；不要用手工输入的目录页码替代动态目录。Markdown、纯文本或 PPT 内容稿不套用该规则。
- 项目没有明确分期时，不使用“一期、二期、本期、后续阶段”等人为分段。使用“本项目、项目范围、约定场景、实施顺序”等表述；只有用户确认了分期计划，才写入分期名称和阶段边界。
- 用户未提供实际数据量时，必须区分“计价测算基准”和“实际数据范围”。例如“迁移费用暂按1TB数据量测算4万元，1TB仅为报价基准，不代表实际数据量或迁移总费用；实际数据量和费用以数据盘点及双方确认结果为准”。禁止把1TB基准写成客户已有数据量。
- 报价表的“范围与交付口径”每项用一段自然语言说明该项解决什么问题、交付什么结果；不要把功能名称、参数和子功能用逗号堆成清单。金额、计价基准和验收边界另行写清。
- 客户已明确不关注的替代路线或历史方案，不在正文反复写成“本项目不建设……”。只有当排除项会直接影响报价、接口、责任或验收时，才保留必要的范围边界说明，并使用客户当前确认的范围表述。

交付前再检查：全文不含“方案摘要”（除非用户要求）、未经确认的“一期/本期”分期残留、未确认的数据量断言、手工目录页码或内部参照词；DOCX 包含目录时，必须检查 `TOC` 字段和 `updateFields=true`。

详细措辞与反模式见 [writing-and-review.md](references/writing-and-review.md)。

### 7. 控制事实、承诺和责任边界

读取 [evidence-and-boundaries.md](references/evidence-and-boundaries.md)，将重要主张区分为：

- 已确认事实
- 有来源的产品能力
- 基于现状的合理推断
- 建议方案
- 待客户或第三方确认

禁止编造客户名称、项目编号、案例、价格、性能指标、兼容性、实施周期、接口条件、PoC 结果和法规结论。信息不足时使用“【待确认】”“需以……为前提”“建议在……后确定”等明确口径。

所有金额必须同步写清范围、数量、计价依据、交付物、验收口径和不包含项。所有接口承诺必须写明接口开放、网络连通、测试环境、第三方配合及额外改造费用边界。

集团型、多系统建设方案还应区分平台建设范围、上游业务或财务系统责任、基础设施与安全责任以及第三方组件责任。对依赖上游形成质量、电子凭证验签验真、格式解析、外部平台服务或历史数据治理的能力，先确认已有能力和可用条件；不能把客户需求、行业设想或第三方能力写成平台原生能力。

档案 AI 场景默认遵守“先治理再智能、结果可追溯、关键判断人工复核”。AI 不替代分类、开放审核、鉴定、销毁等责任性判断；部署域、数据密级和模型使用边界必须明确。

### 8. 执行决策者反向质询

初稿完成后，强制执行 `presales-consultant-persona` 的 C+：

1. 从客户决策人视角提出 3 个指向具体段落、数字或承诺的尖锐问题。
2. 至少覆盖落地风险、责任边界、机会成本中的两个方面。
3. 将真实缺口直接修回正文，不另建敷衍式问答附录。
4. 无法解决的约束标为已知限制和待决策事项。
5. 最多两轮。

对集团、多来源系统、电子档案或长期保管类方案，三项质询中至少一项检查上游数据、接口或第三方依赖的可获得性和责任归属，至少一项检查安全、持续运行或长期保管责任是否有可执行安排。

一般方案不展示内部质询过程，只交付修正后的正文和简短修正说明；投标场景按对应投标 Skill 保留自检记录。

### 9. 完成交付门禁

交付前逐项确认：

- **方向正确**：受众、用途、载体和篇幅匹配。
- **需求成立**：表象需求已转化为真实业务问题。
- **价值闭环**：问题、目标、能力、成果和验收能够对应。
- **证据可靠**：重要事实和产品主张有来源，推断与建议未伪装成事实。
- **范围清晰**：项目范围、已确认阶段以及客户、供应商和第三方责任可区分。
- **文字正式**：无供应商自嗨、功能堆砌、空泛口号、沟通痕迹和客户名称残留。
- **内外分离**：内部可使用功能清单、知识库和白皮书完成能力核验；客户成稿不暴露这些内部依据名称。
- **载体合格**：DOCX/PDF/PPTX 完成结构校验和逐页渲染检查；“能够打开”不等于完成视觉验收。

生成 Word 后至少检查：标题层级、目录、分页、表格跨页、页眉页脚、字体替换、空白页、孤行和溢出。目录更新会改变页码，更新后必须重新渲染全篇。

对 Markdown、纯文本或 DOCX 客户成稿运行内部依据扫描：

```powershell
python "<skill-dir>/scripts/validate_customer_facing_text.py" "<output-path>"
```

公文格式方案还必须按 [official-document-format.md](references/official-document-format.md) 检查字体、字号、行距、颜色和表格样式；发现字体缺失时不得静默替换。

### 10. 交付与沉淀

交付时简要说明：

- 采用的方案定位和结构
- 主要假设、待确认事项和责任边界
- 已完成的结构与视觉验证
- 成果文件路径

仅当用户明确说“补充到知识库”“沉淀到知识库”或“归档这个项目”时，按当前项目 `AGENTS.md` 规定的知识库沉淀流程执行。不要自动沉淀。