wjjjjjjjjjjj 售前方案编写
把方案写成客户可判断、供应商可兑现、后续可验收的正式文本。不要把功能清单扩写成方案。
协同关系
先完整读取并遵循 presales-consultant-persona。本 Skill 负责方案内容主线和质量总控；按任务叠加专用 Skill：
- 创建或编辑正式 Word：使用
documents；只需文本稿时不强制生成 DOCX。用户提到“公文格式”“仿宋”“政府正式呈报”或“大理州政协那套格式”时，必须读取 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，并运行。该文件不得放入客户输出目录或投标提交包：
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 时，先报告范围和拆分建议并请求确认。
按以下优先级取材：
- 用户本轮明确提供或确认的事实
- 当前项目摘要和既有正式成果
- 公司产品知识库、白皮书和功能清单
- 官方政策、标准、客户公开材料
- 通用行业经验
登记每项来源的用途。采购需求只能证明客户要求，不能证明供应商具备相应能力；客户原话也不能自动变成产品承诺。
对可能变化的政策、标准、行业前沿、产品信息或公开事实进行联网核验，优先使用官方或一手来源，并保留可追溯链接。
3. 建立安铂产品能力映射
用户提供需求内容、功能要求、URS、需求清单或交流纪要时，必须在起草方案前完成内部映射：
- 拆分客户需求，保留原始业务含义。
- 优先检索安铂现有产品、组件和已验证功能。
- 建立“客户需求 → 安铂产品/组件 → 已验证能力 → 匹配程度 → 方案写法”关系。
- 匹配程度使用“标准能力、扩展能力、能力缺口、第三方依赖”。
- 标准能力直接纳入方案；扩展能力说明边界；能力缺口和第三方依赖不得伪装成现成功能。
需求是业务输入，安铂现有产品能力是供给边界。先用现有能力形成可兑现的方案底座，再围绕客户场景、流程和价值组织文字；不要先按照客户措辞创造新平台或新产品。
该映射表属于内部分析材料，除非用户明确要求，不直接放入客户成稿。
4. 重构需求
在写目录前完成五项判断：
- 客户表面提出了什么。
- 背后真正影响业务、管理或决策的问题是什么。
- 操作层、管理层、战略层分别受到什么影响。
- 项目为什么现在做，不做的机会成本是什么。
- 最可能导致项目失败或决策人被追责的点是什么。
把功能描述反向翻译为“业务场景 + 管理问题 + 能力诉求”。不要把后文章节中的功能原句复制到需求分析。
5. 选择方案类型
根据受众与用途选结构，不套固定模板。读取 structure-playbook.md：
- 领导决策或立项报告
- 营销型解决方案
- 技术建设方案
- 小型正式呈报材料
- 既有方案增补或重构
先回答“为什么建、解决什么、如何落地、如何控制风险”，再决定功能展开深度。
5.1 建设方案与解决方案的行业化写法
只要用户要求编写“建设方案”或“解决方案”，且任务不属于完整投标、逐项技术响应、独立报价或纯主题研究，就默认按高质量行业建设方案组织，不将“需要做什么”的功能、任务或表格清单扩写后直接交付。
- 先从客户所属行业、组织层级、业务链、管理责任和既有约束中重构问题，再说明建设目标、总体方法、系统与应用如何协同落地、实施质量如何保障以及建成后如何持续运行。
- 用“业务事实或痛点—管理风险—建设路径—可验收结果—前提边界”完成核心论证。功能是支撑建设路径的证据，不是方案的起点和主体。
- 架构、流程和场景承担解释复杂关系的责任。用户要求系统框架、功能架构、应用架构、接口、实施或安全时，分别展开相应设计并保证术语、对象、责任和数据流一致；不要用一张泛化架构图替代所有设计内容。
- 正文以连续段落和必要图示为主，体现行业问题如何被治理、业务如何闭环、责任如何落实。表格只用于阶段计划、责任分工、验收清单、价格或同字段对比，不能把背景、总体思路、技术路线和建设内容压缩成“事项—功能—说明”式表格。
- 避免全篇从“模块一、模块二”或“建设内容如下”开始。确需展示功能时，先说明其服务的业务场景、处理对象、上下游关系和管理结果，再按能力链展开。
涉及集团型、多单位、多来源系统的电子档案或电子会计档案建设时，读取 group-electronic-archive-pattern.md，并将专项模式与当前客户事实、已验证能力和项目范围结合，不照搬为固定目录。
6. 编写内容主线
默认采用以下逻辑，可按项目裁剪：
- 背景与建设必要性
- 业务现状与核心问题
- 目标业务结果
- 总体思路与实现路径
- 建设范围与建设内容
- 实施路径与组织保障
- 预期成效与验收关注点
- 投资估算与范围口径
- 风险、前提与责任边界
执行以下写作规则：
- 先写业务结果，再写系统目标和功能。
- 每项能力至少对应一个业务场景、一个问题和一个可感知结果。
- 用连续段落完成论证；只在报价、实施计划、对比关系或重复性结构中使用表格。
- 建设方案和解决方案默认以“问题—方法—架构—场景—实施保障—运行成效”形成论证闭环。功能清单仅用于内部能力核验或作为正文中相应建设路径的支撑，不得替代行业方案的叙事和设计。
- 站在客户视角写正式文本，优先使用客户或项目全称；减少“贵司”“我方”“本次沟通”等供应商或过程性措辞。
- 对外正式稿删除沟通痕迹、写作说明、占位式套话和内部判断过程。
- 优先使用安铂知识库中的正式产品名称和已验证功能。客户需求超出已有能力时，写成扩展功能、第三方依赖、待评估事项或不在本期范围，不自造产品。
- 客户成稿直接陈述项目能力和业务作用，不得出现“参照安铂功能清单”“根据安铂知识库”“依据产品白皮书”“内部产品资料显示”“按 Skill 要求”等暴露内部工作依据的话语。
- 技术内容必须落到具体档案业务链、数据对象、参与角色、处理步骤和验收结果，不写空泛平台概念。
- 修订既有文件时只改用户授权范围；不顺手重写其他章节，不覆盖用户无关修改。
6.1 客户直呈版规则
当用户明确表示材料要直接呈现给客户、领导或采购方时，将成稿视为客户最终阅读版本处理：
- 删除内部工作痕迹，包括产品清单、知识库、内部参照、能力映射、方案生成过程、Skill 名称和“根据资料/参考清单”等供应商内部表述。客户可见稿只保留面向客户的事实、建议、边界和交付说明。
- 方案摘要不是默认章节。只有用户明确要求摘要、执行摘要或领导摘要时才保留；否则从封面直接进入目录和正文。
- 交付 DOCX 且包含目录时，使用 Word 动态目录字段，并设置打开文档时更新字段；不要用手工输入的目录页码替代动态目录。Markdown、纯文本或 PPT 内容稿不套用该规则。
- 项目没有明确分期时，不使用“一期、二期、本期、后续阶段”等人为分段。使用“本项目、项目范围、约定场景、实施顺序”等表述；只有用户确认了分期计划，才写入分期名称和阶段边界。
- 用户未提供实际数据量时，必须区分“计价测算基准”和“实际数据范围”。例如“迁移费用暂按1TB数据量测算4万元，1TB仅为报价基准，不代表实际数据量或迁移总费用；实际数据量和费用以数据盘点及双方确认结果为准”。禁止把1TB基准写成客户已有数据量。
- 报价表的“范围与交付口径”每项用一段自然语言说明该项解决什么问题、交付什么结果；不要把功能名称、参数和子功能用逗号堆成清单。金额、计价基准和验收边界另行写清。
- 客户已明确不关注的替代路线或历史方案，不在正文反复写成“本项目不建设……”。只有当排除项会直接影响报价、接口、责任或验收时，才保留必要的范围边界说明，并使用客户当前确认的范围表述。
交付前再检查：全文不含“方案摘要”（除非用户要求）、未经确认的“一期/本期”分期残留、未确认的数据量断言、手工目录页码或内部参照词；DOCX 包含目录时，必须检查 TOC 字段和 updateFields=true。
详细措辞与反模式见 writing-and-review.md。
7. 控制事实、承诺和责任边界
读取 evidence-and-boundaries.md，将重要主张区分为：
- 已确认事实
- 有来源的产品能力
- 基于现状的合理推断
- 建议方案
- 待客户或第三方确认
禁止编造客户名称、项目编号、案例、价格、性能指标、兼容性、实施周期、接口条件、PoC 结果和法规结论。信息不足时使用“【待确认】”“需以……为前提”“建议在……后确定”等明确口径。
所有金额必须同步写清范围、数量、计价依据、交付物、验收口径和不包含项。所有接口承诺必须写明接口开放、网络连通、测试环境、第三方配合及额外改造费用边界。
集团型、多系统建设方案还应区分平台建设范围、上游业务或财务系统责任、基础设施与安全责任以及第三方组件责任。对依赖上游形成质量、电子凭证验签验真、格式解析、外部平台服务或历史数据治理的能力，先确认已有能力和可用条件；不能把客户需求、行业设想或第三方能力写成平台原生能力。
档案 AI 场景默认遵守“先治理再智能、结果可追溯、关键判断人工复核”。AI 不替代分类、开放审核、鉴定、销毁等责任性判断；部署域、数据密级和模型使用边界必须明确。
8. 执行决策者反向质询
初稿完成后，强制执行 presales-consultant-persona 的 C+：
- 从客户决策人视角提出 3 个指向具体段落、数字或承诺的尖锐问题。
- 至少覆盖落地风险、责任边界、机会成本中的两个方面。
- 将真实缺口直接修回正文，不另建敷衍式问答附录。
- 无法解决的约束标为已知限制和待决策事项。
- 最多两轮。
对集团、多来源系统、电子档案或长期保管类方案，三项质询中至少一项检查上游数据、接口或第三方依赖的可获得性和责任归属，至少一项检查安全、持续运行或长期保管责任是否有可执行安排。
一般方案不展示内部质询过程，只交付修正后的正文和简短修正说明；投标场景按对应投标 Skill 保留自检记录。
9. 完成交付门禁
交付前逐项确认：
- 方向正确：受众、用途、载体和篇幅匹配。
- 需求成立：表象需求已转化为真实业务问题。
- 价值闭环：问题、目标、能力、成果和验收能够对应。
- 证据可靠：重要事实和产品主张有来源，推断与建议未伪装成事实。
- 范围清晰：项目范围、已确认阶段以及客户、供应商和第三方责任可区分。
- 文字正式：无供应商自嗨、功能堆砌、空泛口号、沟通痕迹和客户名称残留。
- 内外分离：内部可使用功能清单、知识库和白皮书完成能力核验；客户成稿不暴露这些内部依据名称。
- 载体合格：DOCX/PDF/PPTX 完成结构校验和逐页渲染检查；“能够打开”不等于完成视觉验收。
生成 Word 后至少检查：标题层级、目录、分页、表格跨页、页眉页脚、字体替换、空白页、孤行和溢出。目录更新会改变页码，更新后必须重新渲染全篇。
对 Markdown、纯文本或 DOCX 客户成稿运行内部依据扫描：
python "<skill-dir>/scripts/validate_customer_facing_text.py" "<output-path>"
公文格式方案还必须按 official-document-format.md 检查字体、字号、行距、颜色和表格样式；发现字体缺失时不得静默替换。
10. 交付与沉淀
交付时简要说明：
- 采用的方案定位和结构
- 主要假设、待确认事项和责任边界
- 已完成的结构与视觉验证
- 成果文件路径
仅当用户明确说“补充到知识库”“沉淀到知识库”或“归档这个项目”时，按当前项目 AGENTS.md 规定的知识库沉淀流程执行。不要自动沉淀。