---
name: technical-proposal
version: 1.0.0
description: |
  基于客户需求、产品事实和项目约束编制完整技术方案，覆盖需求分析、总体架构、
  详细设计、实施、交付、质量、安全、风险和验收。用于投标技术方案或客户解决
  方案；不负责制定招标参数，也不替代逐条招标响应矩阵。
allowed-tools:
  - Read
  - Grep
  - Glob
  - Execute
compatibility: Markdown；可配合 longdoc-docx 导出 Word（PDF 仅用于核验）
---

# 技术方案

## 必要输入

- 客户需求原文及编号、评分点或验收目标。
- 产品事实与证据、功能状态、参数和限制。
- 部署环境、现有系统、接口、数据、安全和合规约束。
- 项目范围、责任边界、计划、交付物和非范围项。

不确定内容进入“假设与待确认事项”，不能默认为客户已具备或产品已支持。

## 编制顺序

1. 建立需求追溯表，为每项需求分配稳定编号。招标场景下
   `tender-response-matrix` 是需求编号、响应状态和偏离结论的唯一权威来源，
   本技能只派生视图，不得另建一套编号或改写其状态。
2. 区分业务目标、功能需求、非功能需求、接口约束和验收要求。
3. 先确定范围、假设和总体架构，再展开模块设计。
4. 对每个设计说明采用的产品能力、依赖条件和限制。
5. 将设计落实到实施任务、交付物、质量措施和验收方法。
6. 最后编制摘要，不能先写宣传性摘要再反推正文。

## 章节建议

复制 `templates/technical-proposal.md`，按项目裁剪：

- 方案摘要
- 项目理解与需求分析
- 范围、假设与责任边界
- 总体技术架构与数据流
- 详细功能和接口设计
- 部署、安全、性能和运维设计
- 实施计划、组织和质量保证
- 交付物、培训和知识转移
- 验收方法、风险和偏离说明
- 需求追溯矩阵

## 写作门禁

- 需求 → 设计 → 产品能力 → 交付物 → 验收方法必须可追溯。
- 规划能力必须使用将来时，并说明是否属于本项目交付范围。
- 架构图与正文必须使用相同组件名称和边界。
- 不把客户责任、第三方依赖或人工复核要求隐藏在脚注中。
- 不编造团队人数、工期、性能、案例、资质或承诺。
- 方案正文以系统和动作陈述为主，减少“我方/我们”堆叠。

## 导出与审校

如已安装相关技能：

1. 用 `deai-writing` 扫描并定向改写 Markdown。
2. 用 `longdoc-docx` 生成 DOCX，并借助临时 PDF 做空白页、乱码和 300 DPI 视觉复核。

未安装时仍应交付结构完整、可追溯的 Markdown。

## 完成标准

需求无遗漏；架构、功能、实施、交付和验收闭合；事实与产品版本一致；图表和编号
连续；假设、偏离、风险和非范围项明确；所有数字和承诺可定位到输入依据。