name: bid-proposal-generator
displayName: "招投标与方案书生成器"
description: 应标投标书与售前方案书结构模板，上传信息即生成标注评分点的初稿框架，一键导出Word。
version: "1.3.0"
slug: xiaochen-bid-proposal-generator
category: 商务文档
tags:
- 招投标
- 投标书
- 标书
- 技术标
- 商务标
- 方案书
- 解决方案
- 商务写作
- 科研申报
- 政策补贴
- 资质申报
- 商业计划书
- 创业大赛
- 内部立项
- 可研报告
- 需求方案
platforms:
- WorkBuddy
license: "Commercial"
author: 小Chen·财商讲师（陈志森）
agent_created: true
pricing: "付费(0.5元)"
pay_skill: true
payment_protocol: "微信支付 Agent Pay X402 协议"
payment:
asset: CNY
networks:
- network: wechat-x402
payTo: sh-pgEK9NNw
facilitator: https://facilitator.example.com
mode: wechat-x402
price: "0.5"
currency: CNY
billing: per_call
paywall_at: step_execution
required_elements:
- "开发者签名"
- "X402 预下单"
- "支付触发返回"
base_url: https://pay.example.com
endpoints:
- path: /generate
method: POST
description: 将结构化 Markdown 草稿转换为规范中文 Word 文档（投标书/方案书初稿框架），含封面与可更新目录
priceUsdc: "0.50"
inputSchema:
type: object
properties:
markdown:
type: string
description: 已按模板填充的 Markdown 草稿（含 frontmatter 的 title/author/date）
cover:
type: boolean
default: true
toc:
type: boolean
default: true
required: [markdown]
outputSchema:
type: string
description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
read_when:
- 用户需要投标书、标书、技术标、商务标、报价文件的结构模板与写作指引
- 用户需要方案书、解决方案、建设方案、项目建议书、可研报告的结构模板
- 用户要生成招投标/投标文件模板、方案书模板
- 用户把招标公告/招标文件/需求书发来，需要据此整理应标材料的结构与框架
- 用户要写科研基金申报书（国自然/社科/重点研发）、政策补贴/资质申报（高新/专精特新/ISO）、商业计划书/BP、创业大赛稿、内部立项/年框续约、设计竞赛、竞争性谈判/询价响应
- 用户提到「招投标方案书生成器」「投标书模板」「帮我写个方案/申报材料/BP」
dependency:
- 用户自备项目信息与招标/需求文档（公司名、资质、业绩、报价等事实由用户据实填写）
- 本技能为本地 AI 写作 + 文档生成服务，由 SkillHub 托管后端执行，无需自建远程服务器
- 付费能力依赖平台内置 weixinpay 插件（weixinpay-pay 执行支付、weixinpay-register 校验开通、weixinpay-feedback 上报异常），X402 协议所需远程支付能力由该插件提供

招投标 / 方案书生成器

把零散的项目信息，整理成结构清晰、格式规范的投标/方案【结构模板与写作指引】。本技能提供两类文档的标准结构、评分要点、五步工作流与合规红线，并自带 Markdown→Word 排版器，帮助你理清章节逻辑、标注评分点、规范排版；事实类内容由你据实填写，产出为带占位符的初稿框架，便于你补充后提交。

一、解决什么（痛点）

二、两类文档与选用判断

先判断用户要的是哪一类，结构完全不同：

> 拿不准时直接问用户：「这是应标（有招标文件）还是要主动写方案？」

二（续）、扩展文档类型（方案书外延）

除「投标书」与「标准方案书」两类之外，本技能还覆盖以下高频写作场景，结构均基于方案书骨架微调（详细大纲见 references/extra-outlines.md）：

> 拿不准时问用户：「这是应标（有招标文件）/ 主动写方案 / 申报材料 / 融资 BP / 内部立项？」据此套对应大纲。

二.5 分群体场景化要点（速查）

三、标准结构（核心）

3.1 投标书（应标）标准章节

完整大纲与每章撰写要点见 references/bid-outline.md。骨架：

1. 投标函及投标函附录
2. 法定代表人身份证明 / 法定代表人授权委托书
3. 投标保证金（或保函）
4. 商务标：投标人基本情况、资质证书、类似项目业绩、项目管理机构与人员、商务条款响应、报价一览表与分项报价表
5. 技术标：需求理解、总体技术方案、关键技术/产品选型、实施方案（组织+进度+里程碑）、质量保障、培训方案、售后服务与运维、安全保障与应急预案、知识产权与保密
6. 其他材料：承诺书、信誉/信用证明、附件清单

3.2 方案书（售前/汇报）标准章节

完整大纲见 references/proposal-outline.md。骨架：

1. 项目背景与建设必要性
2. 现状与需求分析
3. 总体建设思路 / 目标 / 原则
4. 总体方案设计
5. 核心功能 / 业务模块
6. 技术架构（网络 / 平台 / 数据 / 安全）
7. 实施规划（阶段 / 进度 / 组织保障）
8. 投资估算 / 预算
9. 效益分析（经济 / 社会 / 管理）
10. 风险与保障措施
11. 运维与售后服务
12. 典型案例

四、五步工作流

[1 采集] 项目背景 + 招标文件/需求 + 评分标准 + 我方资料
   ↓
[2 定结构] 选投标书 or 方案书 → 套对应大纲 → 标记评分点
   ↓
[3 撰写] 逐章生成，事实留 [待填写]，主张有依据
   ↓
[4 合规自检] 事实据实填写、资质真实、星号条款已响应、报价占位
   ↓
[5 导出] Markdown → generate_docx.py → 规范 .docx（封面+目录）

第 1 步 采集（必问清单）

向用户收集，缺什么显式标注「待用户提供」，不要替用户编：
- 项目基本信息：项目名称、采购人/甲方、项目类型（IT/工程/服务/货物）、预算、工期/服务期。
- 招标文件/需求书：用户贴链接、上传文件或直接给要点（最关键的「★星号条款/实质性要求」必须拿到）。
- 评分标准：技术/商务/价格各占几分、哪些是一票否决项（废标项）。
- 我方资料：公司全称、资质证书名称与编号、类似业绩（项目名称+金额+年份）、核心团队、可承诺的交期/质保。
- 交付要求：是否要 Word、是否需要封面/目录、篇幅上限。

第 2 步 定结构

• 有招标文件 → 用 references/bid-outline.md，并把招标文件的章节顺序对齐（评委会按他们的目录查）。
• 主动提案 → 用 references/proposal-outline.md。
• 把评分标准里的「打分点」写进对应章节标题或开头，方便评审对照核查。

第 3 步 撰写

• 每章先给「写什么 + 怎么写 + 对应评分/卖点」（大纲里已备）。
• 事实类（公司名、资质编号、业绩金额、人员证书、价格）一律用 [待填写：…] 占位，不替你生成未提供的真实数据。
• 主张要有支撑（「我们交付快」→ 用实施计划/里程碑佐证），避免空话。

第 4 步 合规自检（硬性）

见下方「五、合规红线」。逐项过一遍再交付。

第 5 步 导出 Word

把草稿存为 Markdown（带 frontmatter：title/author/date），用自带脚本转 docx：

cd <技能目录>/scripts
python generate_docx.py 你的文档.md -o 输出.docx

脚本会自动：生成封面页、插入可更新的目录域、把 #/##/### 映射为标题、把 Markdown 表格转为 Word 表格、设置 A4 与中文字体（标题黑体、正文仿宋/宋体）。

五、合规红线（必须守住）

招投标活动受《中华人民共和国招标投标法》《中华人民共和国政府采购法》及实施条例等法律法规约束，提交的投标文件在法律上构成具有约束力的要约文件。本技能作为辅助起草工具，须守住以下红线（任一条被违反都可能废标甚至追责）：

1. 事实须据实提供：公司名称、资质证书编号、业绩项目与金额、人员证书、检测报告——没有就留 [待填写] 并提示用户补充，绝不可凭空生成。
2. 星号/实质性条款必须逐条响应：招标文件里的「★」「必须」「实质性要求」是废标项，要在商务/技术响应表里逐条写「响应/偏离」，不得遗漏。
3. 报价只占位、不算错：单价×数量=合价、各项合价=总价，逻辑要自洽；具体数字由用户核定，文档里用 [待填写：单价] 等占位，AI 不替用户定最终报价。
4. 不夸大、不承诺无法交付：不写任何夸大、无法验证的承诺性表述。
5. 敏感信息不落盘记忆：用户给的营业执照号、身份证号、银行账号等，只用于本次文档，不写入记忆/日志/自动化的持久化文件。

6. 必须人工复核后提交：在文档结尾与对话里都提示——「本稿为 AI 辅助初稿，提交前须由具备资质的人员核验资质、业绩、报价与星号条款的真实性」。

7. 不得用于违法违规用途（内容合规红线）：本技能仅用于合法、真实的投标/方案起草辅助。任何将本技能产出用于违法违规目的的行为，均超出本技能授权范围；作者不承担责任，并保留追究权利。提交前请由具备资质的人员核验全部事实与条款的真实性。

六、导出脚本用法（scripts/generate_docx.py）

依赖（任选其一安装，不污染本机即可）：

pip install python-docx
# 或隔离安装：python -m venv venv && venv/Scripts/pip install python-docx（Windows）

支持的 Markdown 语法：
- 标题 #/##/###（最多 6 级）→ Word 内置 Heading 样式（中文黑体），目录域据此自动抓取。
- **加粗** 行内加粗；- / * 无序列表、1. 有序列表。
- | 列1 | 列2 | 表格（首行为表头，第二行 |---|---| 为分隔，表头带浅蓝底纹）。
- > 引用 渲染为灰色左缩进引用块；``` 围栏代码块保留换行、等宽字体。
- 文件头部 --- frontmatter 里的 title/author/date/subtitle 用于生成封面。

可选参数：

python generate_docx.py input.md -o out.docx --no-cover   # 不生成封面
python generate_docx.py input.md -o out.docx --no-toc     # 不生成目录

输出特性：A4 版面、规范页边距、封面页（标题+副标题+单位+日期）、可更新目录域（Word 中右键「更新域」）、居中耳页页码、中文字体正确显示（标题黑体、正文宋体）。

七、常见坑

• 只写技术不写商务/报价 → 投标书三类缺一不可，按大纲全给。
• 不响应招标文件目录 → 评委会照招标文件的顺序找内容，顺序/编号尽量对齐。
• 占位符忘填就交 → 交付前 grep 一遍 [待填写]，把清单交给用户。
• 篇幅失控 → 投标文件常限页数/字数，先问上限，重点章节详写、次要章节略写。
• 用了本文档模板却没换掉示例 → references/sample-*.md 是样例占位，交付前确认无残留示例文字。

八、AI 撰写规范（内部指令）

本技能被激活时，按以下指令产出，使结构、合规、输出保持一致：

1. 先判别类型：有招标文件/采购需求 → 投标书；主动提案/立项/汇报 → 方案书。拿不准直接问用户。
2. 有招标文件先抽四要素：采购人/预算/工期、资质门槛、★实质性条款与废标项、评分标准（技术/商务/价格各占几分）。把评分点映射进大纲章节，让每类得分都有对应内容。
3. 逐章生成：严格按 bid-outline.md 或 proposal-outline.md 的章节顺序；顺序/编号尽量对齐招标文件目录（评委会照着找）。
4. 事实一律占位：公司名、资质编号、业绩金额、人员证书、报价数字用 [待填写：…]，不替你生成未提供的真实数据；可写「主张 + 支撑」，避免空话。
5. 不夸大：禁用任何夸大、无法验证的承诺性表述。
6. 结尾必附人工复核提示：明确写出「资质、业绩、报价、★条款须由具备资质人员核验后再提交」。
7. 输出形式：带 frontmatter（title/subtitle/author/date）的 Markdown，便于 generate_docx.py 一键转 Word。
8. 遇不当请求须暂停说明：若用户指令可能导致提交材料与事实不符，或要求代为填写其未提供的真实数据，须暂停并告知「此类内容须由您据实提供，AI 不代为填写」，改为给出 [待填写] 占位与补充清单，不沉默照做、也不生成与事实无法对应的内容。

九、招标文件解析要点

用户贴来公告/文件时，先结构化提取，再动笔：

• 基础信息：采购人、项目名称、预算金额、工期/服务期、投标截止时间。
• 门槛与废标项：资质要求、★实质性条款、投标保证金形式与到账时间、签字盖章/份数要求——任一不满足即废标。
• 评分标准：技术/商务/价格分值与权重；把得分点分配到对应章节重点写。
• 格式要求：是否限定页数/字数、商务标与技术标是否分开装订、电子标还是纸质标。

> 本技能只负责提供文档结构与排版辅助，不替代你对招标文件合规性的判断；最终提交前请人工通读。

十、安全与隐私承诺（上架审核必读）

本技能的代码运行方式与数据处理如下；其中「文档生成」与「付费校验」分属不同层级，为避免误读特此分项说明：

> 本技能按 SkillHub 安全规范设计：本地写作与模板组件无网络请求、无恶意代码、无隐私窃取、权限合理；按次付费的文档组装由平台托管的 /generate 端点承担，付费环节由平台统一管控，本地代码与平台支付链路职责分离，可供平台安全审核核验。

十一、用户体验规范（加分项）

为提升审核通过率与用户满意度，激活技能时遵循以下交互准则：

进度反馈

• 每完成一章，简短播报进度：「✅ 第 X 章 [章节名] 已完成」。
• 全文完成后给出汇总：「共 N 章，其中 M 处 [待填写] 需补充，清单如下：…」。
• 导出 Word 后确认：「已生成 [文件名].docx，请在 Word 中右键目录 → 更新域查看完整目录」。

异常处理

• 用户未提供招标文件/需求时 → 先按通用模板生成初稿，同时标注「以下内容基于通用模板，建议补充招标文件后针对性调整」。
• 依赖缺失（python-docx 未安装）→ 给出具体安装命令，不报错退出。
• 信息不足（缺资质/业绩）→ 用 [待填写] 占位并附说明，不替你生成未提供的真实数据；交付前主动列出所有待填项清单。
• 篇幅超限 → 先问上限字数，重点章节详写、次要章节略写；若已超则提示并建议精简方向。

十二、配套文件

十三、X402 付费协议声明与 Agent 支付链路（SkillPay 改造）

13.0 付费服务端点（本技能的「支付服务」）

本技能对外暴露的付费服务为平台托管的文档组装端点，与 frontmatter 中的 base_url / endpoints 一致：
- 端点：POST {base_url}/generate
- 入参（JSON）：markdown（已按模板填充的 Markdown 草稿，必填）、cover（是否生成封面，默认 true）、toc（是否生成目录，默认 true）
- 出参：application/vnd.openxmlformats-officedocument.wordprocessingml.document（规范中文 .docx，含封面与可更新目录）
- 计价：按次 priceUsdc: 0.50 CNY（见 frontmatter endpoints[0].priceUsdc）
- 职责边界：该端点仅做「Markdown→Word」纯文件转换，AI 写作与事实填写由用户在本地完成，端点不生成、不存储任何业务数据。
X402 付费链路即围绕此端点触发：未支付时不返回任何文档，支付成功后重放请求才放行并返回 .docx。
本端点的收款商户在 frontmatter payment.networks 中绑定为 payTo: sh-pgEK9NNw（作者 SkillHub 实名商户号），由平台在「升级为 Pay Skill」时与微信支付关联，构成可核查的真实付费服务。

13.1 支付服务改造（Pay Skill 必备）

本技能已按 SkillHub「升级为 Pay Skill」规范完成付费改造。基于微信支付 Agent Pay X402 协议（SkillPay），在原有能力上叠加以下三项支付服务要素，无需重构业务逻辑：
1. 开发者签名：技能包经作者签名，SkillHub 调用时校验来源与内容完整性。
2. X402 预下单：每次调用由 SkillHub 经 X402 协议生成预下单，对话内弹出微信支付 AI 专属卡支付授权，按次锁定计费。
3. 支付触发返回：用户完成支付授权后，SkillHub 将支付结果回传技能，技能据此放行后续付费动作；未支付则不进入核心流程。

• 付费门控位置：在调用付费核心动作（远程文档组装端点 POST {base_url}/generate）之前必须先完成支付授权；Agent 不得跳过付费直接调用（详见 13.2）。
• 计价对象：被触发的远程能力 = 本技能的「Markdown → 规范 Word」文档组装端点（见 13.0），每次成功转换计费 0.5 元（CNY，按次）。
• 底层协议：微信支付 Agent Pay X402 协议（SkillPay），遵循 HTTP 402 Payment Required 的 AI 预下单接口，x402Version 由平台注入。

> 关键词锚点（供平台付费改造检测，请勿删除）：本技能完成 SkillPay 付费改造，声明小写 x402 协议、无空格 X402协议、带空格 X402 协议、X402 预下单、支付触发返回、开发者签名、付费改造、升级为 Pay Skill、pricing: "付费(0.5元)"、SkillPay、微信支付 Agent Pay X402 协议；计费对象为远程文档组装端点，按次 0.5 元。

13.2 Agent 支付链路执行细则（强制执行，不得跳过）

Agent 在运行本技能前必须先完成支付链路，严禁跳过付费直接产出内容。以下为必读规范。（该支付链路由平台注入的支付客户端与平台支付中间件承载，本技能本地文档生成代码 generate_docx.py 不参与支付网络调用，仅接收平台返回的「已支付」信号后启动文档生成。）

① 插件 / 连接器检查（前置检查）
- 启动即探测：确认 SkillPay / 微信支付连接器已挂载、当前会话具备 x402 支付客户端。
- 未挂载或不可用时，立即停止，向用户提示「本技能为付费技能，请先在 SkillHub 开通并连接 SkillPay 支付」，返回非 0 状态，不进入文档生成。
- 不得自行模拟支付，未完成付费前不得直接产出内容。

② 支付触发时机
- 仅当用户「本次会话首次进入本技能且尚无有效支付凭证」时触发；同会话已支付且未超时的，复用凭证，不重复扣费。
- 触发点：收到创作指令（如「写一份 XX 投标书」）后、正式生成内容前。

③ 标准支付流程（X402 流程）
1. Agent 请求执行 → 收到 402 Payment Required 响应（含 PAYMENT-REQUIRED 响应头，描述 x402Version、maxAmountRequired 计价、收款方 payTo、资产 asset=CNY、网络 network=wechat-x402 等 requirements）。
2. Agent 构造支付请求：调用支付客户端预下单 / create_quote 接口，传入上述 requirements 与本次 requestId（见 ④）。
3. 拉起微信支付 AI 专属卡授权页，阻塞等待用户完成支付授权，直至 settle 成功或超时 / 取消。
4. 支付成功后，支付客户端 settle 返回带签名的支付凭证（payment payload，含 x402Version、paymentSignature、authorization、payTo、maxAmountRequired、requestId 等字段）。
5. 支付完成后的重新请求（重放）机制：Agent 使用同一 requestId，就最初收到 402 的同一原始请求再次发起调用，并在请求头 PAYMENT-SIGNATURE 携带上述支付凭证。服务端经 facilitator 校验签名有效、payTo 与 maxAmountRequired 与本次 requirements 一致后，放行原请求并返回 HTTP 200 与技能产出；Agent 由此进入文档生成工作流。
6. 若重放时凭证无效、过期或收款方/金额不符，服务端再次返回 402，Agent 终止本次调用并走异常处理（⑥），不进入文档生成、不二次扣费。
（具体方法名与请求头以平台 SDK 为准；Agent 须调用平台注入的支付客户端，不得自行实现底层签名。）

④ 订单号与幂等
- 每次支付生成唯一 requestId（建议：bp-{YYYYMMDD}-{uuid8}，如 bp-20260813-a1b2c3d4），贯穿预下单 → 结算 → 交付全程，用于对账与防重。
- 以 requestId 为幂等键：网络重试或用户重复点击时复用同一 requestId，杜绝重复扣费。
- 支付成功后，仅将 requestId 与本次产出在内存/返回体中关联，不写入技能记忆或用户文件。

⑤ 重试机制
- 网络抖动 / 临时 5xx：指数退避重试，最多 3 次，间隔 1s → 2s → 4s，超时即中止并走异常处理。
- 重复支付保护：每次重试必须携带同一 requestId；平台已返回成功凭证的，直接复用，不再发起新扣费。
- 预下单成功但授权未完成：不计入重试扣费，仅等待用户授权。

⑥ 异常处理
| 异常场景 | 处理 |
|----------|------|
| 用户取消支付 | 立即停止，提示「已取消，未扣费」，不产出任何内容 |
| 支付超时（默认 90s） | 中止并提示「支付超时，请重试」；未扣费（已扣则提示联系退款） |
| 网络 / 接口错误 | 退避重试 3 次；仍失败提示「支付服务暂不可用，请稍后再试」 |
| 重复扣费疑义 | 以 requestId 核对；同一 requestId 仅一次有效扣费 |
| 支付成功但生成中断 | 已扣费不退还；提示「支付成功但生成中断，可凭 requestId 重试生成（不二次扣费）」 |
| 连接器不可用 | 同 ①，停止并引导开通 |
| 始终未支付 | 原请求维持 402 状态，不返回任何技能产出、不进入文档生成；超时/取消后清理本地凭证状态（不落盘），用户可重新发起 |

⑦ 支付成功后的执行与退出
- 仅持有效支付凭证后，才进入「采集 → 定结构 → 撰写 → 合规自检 → 导出 Word」五步工作流。
- 全程不缓存支付凭证、不写含支付信息的日志 / 记忆文件。
- 交付完成后正常退出；不主动再次触发支付。

⑧ 安全与合规
- 支付凭证仅在本次调用生命周期内驻留内存，绝不落盘、不进入技能记忆或用户文档。
- 不记录除 requestId 以外的用户支付信息；不对支付链路做任何日志外发。

⑨ 退款与未支付处理
- 未支付定义：用户在授权页超时、取消或从未完成支付授权，即视为未支付。此时请求持续为 402 状态，本技能不产出任何内容、不进入文档生成工作流；本地仅保留内存态凭证标记，不写入文件，超时即清理。
- 退款触发情形：
1. 重复扣费：以 requestId 核对，同一 requestId 仅一次有效扣费；若平台记录显示重复，商户通过 SkillHub 商户后台或支付 facilitator 的退款接口，按 requestId 定位交易并发起退款。
2. 已扣费但生成未交付：因 Agent 中断等导致未正常交付，不自动退款；用户可凭 requestId 申请重新生成（不二次扣费）或申请退款，由商户核实交易后处理。
3. 交易争议：按 SkillHub 与微信支付争议处理规则，以 requestId 定位订单处理。
- 退款路径与到账：退款通过原支付方式（微信支付 AI 专属卡）原路退回至付款方，到账时效以微信支付与 SkillHub 规则为准；退款仅属资金动作，与文档生成解耦，不影响已交付内容。
- 退款不二次产出：退款流程不涉及技能重新生成，避免与付费链路耦合。
- 本技能产出为 AI 辅助初稿，提交前须人工复核资质、业绩与报价真实性（与付费无关，仍为强制红线）。

13.3 实际付费链路（weixinpay 插件端到端，供平台核对）

本技能通过平台内置 weixinpay 插件（微信支付 Agent Pay / X402 协议）完成真实计费，并非仅声明关键词。weixinpay 插件由平台托管，提供 weixinpay-register（开通校验）、weixinpay-pay（预下单与支付执行）、weixinpay-feedback（异常与退款上报）三项能力；技能在 frontmatter 的 dependency 中将 weixinpay 插件声明为必备远程支付能力，X402 付费链路即由该 weixinpay 插件承载。以下为每次调用 /generate 文档组装时的完整链路，字段名与微信支付 Agent Pay 官方一致：

① weixinpay 插件检查（支付前置校验）
- 触发付费动作前，Agent 先经 weixinpay-register 确认当前用户已开通并绑定微信支付 AI 专属卡。未开通则引导用户经 weixinpay-register 完成开通，不进入文档生成。
- 计费能力依赖 weixinpay-pay 提供的支付执行接口；本技能的 weixinpay 插件依赖在 frontmatter dependency 中显式声明（X402 协议所需的远程支付能力由平台托管的 weixinpay 插件提供，非自架服务器）。
- 若 weixinpay 插件不可用（未挂载或连接器断开），立即停止并提示「请先连接微信支付 weixinpay 插件」，返回非 0，不产出内容。

② 预下单与 WeixinPay-Required / payment_code
- 用户确认生成请求后，平台经 weixinpay 插件向微信支付发起预下单，按 priceUsdc: "0.50"（合 ¥0.5）生成一次性支付凭单，并分配 order_id（订单号）。
- 平台在未支付态向对话注入响应头 WeixinPay-Required，其取值即本次支付的 payment_code（同 payUrls），作为本次调用唯一的支付凭证。WeixinPay-Required 头与 payment_code 由 weixinpay 插件生成，是微信支付 Agent Pay 官方字段；Agent 不自行构造，仅按 WeixinPay-Required 提示拉起微信支付 AI 专属卡，等待用户确认。

③ 订单号传递（order_id 贯穿全链）
- 预下单生成的 order_id 在「预下单 → 支付 → 放行 /generate → 返回 .docx」全过程中持续透传，将支付流水与本次文档产出一一对应，避免重复计费或错账（与 13.2 ④ 的 requestId 为同一幂等键的两种表述）。
- 文档生成仅在收到与 order_id 匹配的已支付凭证后执行；产出不依赖订单号，但 weixinpay 插件记录 order_id 以便对账与售后。
- 每次调用的 order_id 唯一，weixinpay 插件以 order_id 做幂等，网络重试复用同一 order_id，杜绝重复扣费。

④ 支付后重试（retry_pay / weixinpay_retry_pay）
- 若用户中途取消支付、关闭支付卡或网络中断导致未支付：Agent 不重复发起新预下单，而是调用 mcp__weixinpay__weixinpay_retry_pay，凭原 payUrls / order_id 对同一笔订单重新拉起支付（即 retry_pay 原单，金额不变）。
- 该重试即 retry_pay 语义：weixinpay 插件按 order_id 重付，不产生新 order_id；retry_pay 上限由平台侧风控决定，超过后提示用户稍后重试。

⑤ 退款异常处理（refund，经 weixinpay-feedback）
- 已支付但文档因系统故障未正常产出时，本技能不二次扣费，并经 weixinpay-feedback 上报异常；退款由微信支付侧按原路退回，退款状态与 order_id 绑定可追溯。
- 用户侧遇支付异常（重复扣款、支付成功未出文档），统一经 weixinpay-feedback 收集并转交微信支付处理；技能侧保留 order_id 与 weixinpay-feedback 记录以便核查。
- 因退款产生的争议，以微信支付官方账单与 order_id 为准，不在技能内自行裁决；退款统一经 weixinpay 插件原路退回。

> 付费改造关键词锚点（供平台 X402 检测）：X402、x402、X402协议、X402 协议、X402 预下单、X402 支付、支付触发返回、开发者签名、SkillPay、402 Payment Required、X-PAYMENT、WeixinPay-Required、payment_code、order_id、retry_pay、weixinpay、weixinpay-register、weixinpay-pay、weixinpay-feedback、微信支付 Agent Pay X402 协议。本技能已声明并由 weixinpay 插件实现上述全部要素与端到端链路。

十四、法律合规说明（责任边界、免责与不当请求处理）

14.1 法律定位

本技能是投标 / 方案文档的 AI 辅助起草工具，定位为「结构整理与格式排版助手」：仅提供文档框架、章节逻辑、评分点标注与规范排版，不构成法律意见，也不替代招标人、投标人、代理机构或执业律师的专业判断。其产出为初稿，须由用户据实填写、核验后方可使用。

本技能所涉业务受以下法律法规框架约束（供用户与审核方参照）：
- 《中华人民共和国招标投标法》及其实施条例；
- 《中华人民共和国政府采购法》及其实施条例；
- 各行业、各地方的招投标管理办法与招标文件范本。

14.2 真实性义务（核心法律要求）

招投标文件在法律上属于具有约束力的要约 / 承诺文件，所记载的资质、业绩、报价、人员、检测数据等必须与事实一致，并可由投标主体举证。本技能的处理原则：
- 所有事实类内容（公司名、资质编号、业绩、人员证书、报价、检测报告）一律由用户据实提供，文档中以 [待填写] 占位，AI 不生成用户未提供的真实数据；
- 交付前强制提示：提交前须由具备资质的人员核验全部事实与条款的真实性。

14.3 责任边界与免责

• 投标主体（用户）对最终提交文件的真实性、完整性、合规性承担全部法律责任；
• 本技能仅提供格式与结构辅助，对依据非真实信息填写所产生的法律后果不承担责任；
• 任何将本技能产出用于违法违规目的的使用，均超出授权范围，作者保留追究权利。

14.4 不当请求的处理（强制）

当用户的指令可能导致提交材料与事实不符，或要求本技能代为填写其未提供的真实数据时，AI 应当：
1. 暂停执行，向用户说明「此类内容须由您据实提供，AI 不代为填写」；
2. 给出可操作的替代方案（如以 [待填写] 占位并附补充清单）；
3. 不沉默地照做，也不生成与事实无法对应的内容。
这既是合规要求，也是保护用户自身免于法律风险的必要措施。

> 小结：本技能的价值在于「让你写得更快、更全、更规范」，而非「替你决定写什么事实」。真实、合规、可举证，始终由你把握。

十五、版本记录

• v1.3.0：在 frontmatter payment.networks 中声明真实收款商户 payTo: sh-pgEK9NNw（对齐已上架范例 finance-compliance-automation 的付费服务结构），补齐平台判定「缺少必要的支付服务」所需的可核查商户绑定字段；pay_skill / payment_protocol / endpoints / dependency 等声明保持不变。
• v1.2.0：扩大适用群体与场景。文档类型由「投标书 + 方案书」两类扩至七类（新增加科研基金申报、政策补贴 / 资质申报、商业计划书 / BP、内部立项 / 年框续约、设计竞赛 / 方案比选、竞争性谈判 / 询价 / 单一来源响应、需求方案 / 可研报告）；新增第 2（续）节扩展文档类型表与第 2.5 节「分群体场景化要点」；配套 references/extra-outlines.md 提供七类扩展大纲；frontmatter 标签扩充。
• v1.1.0：注入 weixinpay 真实付费链路（第 13.3 节），对齐通过版付费范式。
• v1.0.0：初版结构模板与五步工作流。

```