75 lines
2.9 KiB
Markdown
75 lines
2.9 KiB
Markdown
---
|
||
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。
|
||
|
||
## 完成标准
|
||
|
||
需求无遗漏；架构、功能、实施、交付和验收闭合；事实与产品版本一致；图表和编号
|
||
连续；假设、偏离、风险和非范围项明确；所有数字和承诺可定位到输入依据。
|