fix: focus built-in skill defaults

The Skills catalog exposed nine product-marketing recipes as independent capabilities and enabled every marketing package for every Runtime by default. It now keeps five top-level Skills, loads the nine recipes on demand through the product-marketing package, and leaves the three marketing Skills disabled until users enable them. Existing saved Skill settings remain authoritative. Release note: 内置 Skills 已从 14 个顶层入口精简为 5 个；去 AI 味和长文工具默认启用，产品营销类默认停用，已保存的用户设置保持不变。
2026-09-02 00:44:44 +08:00
parent 4f3e0bdcfd
commit 06c1123caa
28 changed files with 209 additions and 162 deletions
@@ -0,0 +1,46 @@
+# 竞品与定位分析
+
+基于公开、可定位且有日期的来源生成竞品矩阵、差异化定位和销售边界。用于市场
+分析、产品定位和受控销售准备；不允许推断竞品“不支持”或生成无证据攻击性话术。
+
+## 必要输入
+
+- 本产品事实与证据。
+- 明确的竞品名称、版本、目标市场和比较日期。
+- 竞品官方文档、发布说明、公开价格页或经批准第三方来源。
+- 比较目的、受众和允许公开的范围。
+
+## 公平比较规则
+
+1. 比较同一时间、版本、部署模式和授权范围。
+2. 所有产品使用同一组维度和判定标准。
+3. 每个单元格标记：
+   - `verified`：来源明确支持该结论。
+   - `inferred`：基于有限信息的推论，不能作为确定事实外发。
+   - `unknown`：未找到可验证信息。
+4. 未公开的信息写 `unknown`，不能写“不支持”。
+5. 价格必须注明日期、地区、计费单位、版本和附加条件。
+6. 安全、合规和性能结论必须使用原始证书或测试条件。
+
+## 输出
+
+使用 `templates/competitive-positioning.md` 生成：
+
+- 比较范围和方法。
+- 竞品能力矩阵。
+- 来源台账。
+- 本产品适合赢得和不适合争夺的场景。
+- 经证据支持的差异化表述。
+- 销售问答与禁止话术。
+
+## 定位原则
+
+- 定位说明“对特定受众，在特定场景下为什么适合”，不是宣布全面领先。
+- 差异点必须对应用户决策标准和可验证产品事实。
+- 明确本产品限制，避免销售把定位扩张成产品承诺。
+- 竞品材料过期、版本不明或来源撤回时，相关结论立即失效。
+
+## 完成标准
+
+每个比较结论有来源和日期；未知与不支持严格分开；比较维度一致；没有贬损性、
+法律风险或未经批准的价格信息；定位与当前产品版本、功能状态和适用边界一致。
@@ -0,0 +1,39 @@
+# {{产品名称}}竞品与定位分析
+
+**比较日期**：{{YYYY-MM-DD}}
+**比较范围**：{{市场、版本、部署和授权范围}}
+**使用限制**：内部 / 受控销售 / 可公开
+
+## 一、评价维度与方法
+
+| 维度 | 判定标准 | 数据来源要求 |
+|---|---|---|
+| {{维度}} | {{统一标准}} | {{官方文档/测试报告}} |
+
+## 二、竞品矩阵
+
+| 维度 | 本产品 | 竞品 A | 竞品 B |
+|---|---|---|---|
+| {{维度}} | {{结论 [verified]}} | {{结论 [verified/inferred/unknown]}} | {{结论}} |
+
+## 三、来源台账
+
+| 来源 ID | 产品 | 标题 | URL/文档 | 版本 | 日期 | 访问日期 | 权威性 |
+|---|---|---|---|---|---|---|---|
+| SRC-001 | {{产品}} | {{标题}} | {{来源}} | {{版本}} | {{日期}} | {{日期}} | 官方 |
+
+## 四、定位
+
+### 适合优先争取的场景
+
+- {{目标受众 + 场景 + 可验证差异}}
+
+### 不适合或需谨慎的场景
+
+- {{本产品限制或竞品明确优势}}
+
+## 五、销售问答与禁止话术
+
+| 客户问题 | 有依据的回答 | 来源 | 禁止表述 |
+|---|---|---|---|
+| {{问题}} | {{回答}} | {{SRC/CLM ID}} | {{无依据绝对化说法}} |
@@ -0,0 +1,45 @@
+# 客户案例
+
+基于客户授权、实施记录和可复核指标生成客户案例、成功故事和案例摘要。用于公开
+宣传、销售材料或受控投标引用；没有披露授权或历史结果时不得生成可发布案例。
+
+## 发布前硬门禁
+
+必须具备：
+
+- 客户名称、Logo、引语和项目范围的书面披露授权，或明确匿名化要求。
+- 实施前基线、实施后结果、测量周期、样本和统计口径。
+- 产品版本、部署范围、客户责任和第三方条件。
+- 对最终文案、数字和图片的审批责任人。
+
+缺少任一项时只能输出内部案例草稿和缺口清单，不得生成“已发布”版本。
+
+## 叙事结构
+
+1. 客户背景，只保留获准披露的信息。
+2. 具体任务和实施前状态。
+3. 方案范围、实施过程和双方责任。
+4. 产品如何参与工作流，不夸大为单一成功原因。
+5. 结果、测量方法和限制。
+6. 客户引语，仅使用获批原文。
+7. 可复用经验和适用边界。
+
+使用 `templates/customer-case-study.md` 起草。
+
+## 指标规则
+
+- 同时给出基线和结果，不能只给改善百分比。
+- 说明周期、样本、排除项、数据来源和计算方法。
+- 区分相关性与因果性，不把同期其他变化归功于产品。
+- 预测收益、POC 目标和真实生产结果不能混写。
+- 小样本、人工评分或模型评估必须明确说明。
+
+## 匿名化
+
+匿名案例仍需授权。删除或泛化名称、地点、项目编号、截图账号、内部系统名和可
+反向识别组合信息；匿名化不能改变事实、行业范围和测量口径。
+
+## 完成标准
+
+授权范围覆盖全部文字、数字、Logo、引语和图片；案例描述与实施记录一致；指标可
+复算；产品贡献不过度归因；限制清楚；公开版不含客户隐私、合同信息或内部路径。
@@ -0,0 +1,47 @@
+# {{客户授权名称或匿名描述}}：{{案例主题}}
+
+> 发布状态：内部草稿 / 客户审核中 / 已批准公开
+> 授权记录：{{授权文件与范围}}
+> 产品版本：{{版本}}
+
+## 客户背景
+
+{{只写获准披露的行业、规模和业务范围。}}
+
+## 实施前任务与基线
+
+| 指标 | 基线 | 周期与样本 | 数据来源 |
+|---|---:|---|---|
+| {{指标}} | {{数值}} | {{周期、样本}} | {{来源}} |
+
+## 方案与实施范围
+
+- 产品参与：{{工作流中的具体作用}}
+- 客户责任：{{数据、流程、人员或审核}}
+- 第三方条件：{{依赖}}
+- 非范围项：{{不属于本案例的内容}}
+
+## 实施过程
+
+{{阶段、关键动作和变更，不写无法核验的戏剧化叙事。}}
+
+## 结果与测量方法
+
+| 指标 | 基线 | 结果 | 变化 | 测量条件 | 证据 |
+|---|---:|---:|---:|---|---|
+| {{指标}} | {{值}} | {{值}} | {{值}} | {{口径}} | {{EVD-001}} |
+
+## 客户引语
+
+> “{{仅使用获批原文}}”
+
+## 适用边界与经验
+
+{{限制、样本边界、人工复核要求和可复用经验。}}
+
+## 发布审批
+
+| 内容 | 授权范围 | 审批人 | 日期 | 状态 |
+|---|---|---|---|---|
+| 客户名称/Logo | {{范围}} | {{审批人}} | {{日期}} | {{状态}} |
+| 指标与引语 | {{范围}} | {{审批人}} | {{日期}} | {{状态}} |
@@ -0,0 +1,46 @@
+# 产品功能列表
+
+基于产品事实与证据生成结构化功能列表、模块树和版本能力矩阵。用于产品规划、
+售前交流、招标附件或交付范围梳理；重点回答产品有什么功能、谁使用、产生什么
+结果，不负责撰写技术参数或长篇方案。
+
+## 必要输入
+
+- `product-evidence.json`，至少包含 `product`、`features`、`limitations`。
+- 输出用途：内部全量、公开产品、指定版本或投标范围。
+- 目标受众和所需粒度：模块、功能或子功能。
+
+没有事实清单时不要自行拼凑：先用 `product-evidence` 建立并校验清单，或输出输入
+缺口清单等待补齐；任何情况下都不得根据产品名称猜测功能。
+
+## 生成流程
+
+1. 按版本、公开级别和用途筛选功能。
+2. 建立“产品域 → 一级模块 → 功能 → 子功能”层级，层级只服务导航，不凑数量。
+3. 每条功能写清用户角色、触发动作、系统行为和可观察结果。
+4. 标注 `released`、`beta`、`planned`、`deprecated`，规划能力不能混入现有功能。
+5. 补充版本范围、依赖、限制和证据 ID。
+6. 合并同义功能，拆开一行中包含多个独立用户动作的复合功能。
+
+## 输出
+
+复制并填写 `templates/feature-catalog.md`。默认输出两部分：
+
+1. 面向读者的功能目录，只保留必要列。
+2. 追溯附表，保留功能 ID、状态、证据和限制，供内部审核。
+
+## 写作规则
+
+- 功能名使用“对象 + 动作”或稳定名词，不用“强大、智能、高效、全方位”。
+- 功能说明写能力边界，不写架构实现、性能参数和竞争结论。
+- “支持”后必须接具体对象或动作，避免“全面支持”“灵活支持”。
+- 同一功能在不同版本有差异时拆行或使用版本矩阵，不能用模糊脚注掩盖。
+- 公开清单不得带出 `restricted`、`internal` 证据内容。
+
+## 完成标准
+
+- 每条功能可追溯到事实清单 ID。
+- 当前能力、试用能力和规划能力明确分开。
+- 模块树无重复、孤立节点和伪造层级。
+- 功能粒度基本一致，名称、术语和版本范围统一。
+- 限制条件没有因表格精简而丢失。
@@ -0,0 +1,27 @@
+# {{产品名称}}功能列表
+
+**产品版本**：{{版本}}
+**适用范围**：{{版本/部署方式/授权范围}}
+**清单日期**：{{YYYY-MM-DD}}
+
+## 功能目录
+
+| 一级模块 | 二级模块 | 功能名称 | 使用角色 | 用户动作与结果 | 版本范围 | 状态 |
+|---|---|---|---|---|---|---|
+| {{模块}} | {{子模块}} | {{对象+动作}} | {{角色}} | {{触发动作；系统行为；可观察结果}} | {{版本}} | released |
+
+## 版本能力矩阵
+
+| 功能 ID | 标准版 | 专业版 | 企业版 | 依赖条件 |
+|---|---:|---:|---:|---|
+| {{FEAT-001}} | ✓ | ✓ | ✓ | {{依赖}} |
+
+## 限制与说明
+
+- {{功能 ID}}：{{适用边界、依赖或人工复核要求}}。
+
+## 内部追溯表
+
+| 功能 ID | 功能名称 | 状态 | 证据 ID | 复核结果 |
+|---|---|---|---|---|
+| {{FEAT-001}} | {{功能}} | released | {{EVD-001}} | {{通过/待核验}} |
@@ -0,0 +1,47 @@
+# 产品一页纸
+
+将已核验产品信息压缩为一页纸产品概览、宣传彩页或官网下载页文案。用于首次触达、
+展会资料和销售跟进；不替代完整功能清单、技术规格或技术方案。
+
+## 必要输入
+
+- 产品定位、目标受众和本次一页纸唯一目标。
+- 3 至 5 项核心能力、一个典型工作流、适用范围和限制。
+- 可公开的参数、案例、标识、截图和行动入口。
+- 页面尺寸、语言、品牌规范和发布渠道。
+
+## 内容预算
+
+一页纸不是把长文缩小字号。默认预算：
+
+- 主标题 1 个，副标题 1 段。
+- 目标问题 2 至 3 条。
+- 核心能力 3 至 5 项。
+- 工作方式或架构图 1 张。
+- 参数、案例或验证结果最多 3 项。
+- 部署与适用边界 1 个区域。
+- 行动入口 1 个。
+
+超过预算时删减次要内容，不缩成无法阅读的小字。
+
+## 生成流程
+
+1. 用一句话回答“面向谁、提供什么、适用于什么范围”。
+2. 选择与目标受众最相关的能力，不按后台菜单罗列。
+3. 每项能力写“动作 + 结果”，避免形容词。
+4. 将必要条件和人工复核要求放在正文可见区域。
+5. 选择明确行动入口，例如项目咨询、申请演示或下载规格。
+6. 使用 `templates/product-one-pager.md` 起草，再进入视觉排版。
+
+## 禁止事项
+
+- 编造客户 Logo、案例、认证、排名或性能数字。
+- 使用“领先、唯一、全面、百分之百”等无依据绝对化表述。
+- 首屏写成实施教程、需求调查表或接口配置说明。
+- 将 `restricted`、`internal` 内容放入公开彩页。
+- 用二维码或短链掩盖未经审核的外部地址。
+
+## 完成标准
+
+打印或 100% 缩放时仍可读；读者在一分钟内能说出产品定位、核心能力、适用范围
+和下一步；所有数字和主张有证据；没有因压缩而删除关键限制。
@@ -0,0 +1,37 @@
+# {{产品名称}}
+
+## {{面向目标角色，提供具体产品能力}}
+
+{{一句话说明产品类别、主要用途和适用范围。}}
+
+### 目标场景
+
+- {{角色需要完成的具体任务}}
+- {{现有流程中的可验证问题}}
+
+### 核心能力
+
+| 能力 | 用户动作与结果 |
+|---|---|
+| {{能力一}} | {{动作；结果}} |
+| {{能力二}} | {{动作；结果}} |
+| {{能力三}} | {{动作；结果}} |
+
+### 工作方式
+
+{{一张架构图、流程图或三步工作流。}}
+
+### 已核验参数或结果
+
+- **{{数值}}**：{{指标、版本、条件与口径}}
+- **{{数值}}**：{{指标、版本、条件与口径}}
+
+### 部署与适用范围
+
+{{部署方式、数据条件、依赖、限制和人工复核要求。}}
+
+### 下一步
+
+{{项目咨询 / 申请演示 / 获取技术规格}}
+
+<!-- 内部追溯：列出本页使用的 FEAT/PAR/CLM/EVD ID，发布前删除此注释。 -->
@@ -0,0 +1,47 @@
+# 售前演示套件
+
+生成可执行的产品演示故事线、环境清单、操作脚本、讲解词、失败回退和演练检查表。
+用于售前 Demo、POC 汇报或验收演示；不负责制作通用产品介绍 PPT。
+
+## 必要输入
+
+- 演示目标、受众、时长和希望获得的下一步。
+- 可用产品环境、版本、账号角色、测试数据和网络限制。
+- 允许展示的功能、参数、客户数据和日志范围。
+- 已知不稳定点、恢复方法和备用材料。
+
+不得把真实密码、令牌、私有主机名或客户数据写进演示包。
+
+## 设计演示
+
+1. 选择一个完整用户任务作为主线，不按菜单逐页点功能。
+2. 为每一步写前置状态、操作、预期结果、讲解重点和事实 ID。
+3. 明确哪些结果实时产生，哪些是预置数据或截图。
+4. 为外部依赖、模型不稳定、网络异常和数据污染准备回退。
+5. 定义演示结束后的环境重置步骤。
+6. 将可选深挖问题放入问答分支，不打断主流程时间预算。
+
+## 输出
+
+复制 `templates/demo-kit.md`，形成：
+
+- 演示故事线和时间分配。
+- 环境、账号角色和测试数据清单。
+- 逐步运行手册。
+- 讲解词与常见问答。
+- 失败回退、备用截图和重置步骤。
+- 演练与现场检查表。
+
+## 演练门禁
+
+- 在与现场相同版本和权限下完整跑通至少一次。
+- 每一步的预期结果可观察、可截图、可恢复。
+- 不依赖浏览器历史、个人缓存或未记录的人工准备。
+- 所有示例数据可公开或已匿名化。
+- 规划能力不得通过预制截图伪装成实时功能。
+- 讲解数字和产品介绍 PPT、技术方案保持一致。
+
+## 完成标准
+
+演示能在时间预算内重复执行；关键步骤有备用路径；失败不会暴露敏感信息或破坏
+环境；操作脚本、讲解词和事实证据一致；现场人员知道何时停止、切换备用和重置。
@@ -0,0 +1,49 @@
+# {{产品/场景}}演示套件
+
+## 一、演示目标
+
+- 受众：{{角色}}
+- 目标：{{希望受众理解或同意的事项}}
+- 时长：{{分钟}}
+- 产品版本：{{版本}}
+- 不展示范围：{{范围}}
+
+## 二、环境与数据
+
+| 项目 | 要求 | 检查方法 | 状态 |
+|---|---|---|---|
+| 演示环境 | {{环境，不写真实密钥}} | {{检查命令或页面}} | 待检查 |
+| 账号角色 | {{角色}} | {{权限确认}} | 待检查 |
+| 示例数据 | {{匿名数据集}} | {{完整性检查}} | 待检查 |
+
+## 三、演示故事线
+
+| 时间 | 阶段 | 目的 | 讲解重点 |
+|---:|---|---|---|
+| 0-2 分钟 | 场景说明 | {{目的}} | {{重点}} |
+
+## 四、逐步运行手册
+
+### STEP-01 {{步骤名称}}
+
+- 前置状态：{{状态}}
+- 操作：{{具体动作}}
+- 预期结果：{{可观察结果}}
+- 事实依据：{{FEAT/CLM ID}}
+- 讲解词：{{简短讲解}}
+- 失败判断：{{何时判定失败}}
+- 回退：{{备用页面、截图或替代步骤}}
+
+## 五、常见问答
+
+| 问题 | 回答要点 | 依据 | 不应承诺 |
+|---|---|---|---|
+| {{问题}} | {{回答}} | {{证据 ID}} | {{边界}} |
+
+## 六、重置与现场检查
+
+- [ ] 清理上次演示数据。
+- [ ] 恢复初始账号和权限。
+- [ ] 验证网络、依赖和备用材料。
+- [ ] 确认屏幕无通知、密钥和客户信息。
+- [ ] 完整计时演练并记录问题。
@@ -0,0 +1,51 @@
+# 解决方案白皮书
+
+编写解释行业问题、技术原理、参考架构、实现方法、测试证据和适用边界的产品或
+解决方案白皮书。用于技术传播和决策评估；不编制客户项目计划，也不把宣传口号
+当作技术论证。
+
+## 必要输入
+
+- 白皮书主题、目标读者、研究问题和发布范围。
+- 产品事实、技术来源、测试报告、标准和第三方参考。
+- 可公开的架构图、数据、案例和限制。
+- 引用格式、目标篇幅和评审要求。
+
+## 论证结构
+
+1. 明确问题范围，不用泛化行业背景凑篇幅。
+2. 定义术语、对象和评价标准。
+3. 解释方法、原理和参考架构。
+4. 用产品实现或参考流程说明方法如何落地。
+5. 给出测试方法、条件、结果和不确定性。
+6. 说明安全、部署、治理和人工复核边界。
+7. 总结适用场景、限制和后续研究，不做空洞升华。
+
+使用 `templates/solution-whitepaper.md` 建立章节。
+
+## 证据规则
+
+- 标准、论文、第三方观点和产品事实分开引用。
+- 指标必须说明样本、版本、环境、周期和计算方法。
+- 实测结果、设计目标和规划能力使用不同标签。
+- 无法访问原始来源时标记二手来源，不把摘要转述成原始结论。
+- 第三方图表必须检查许可并保留出处。
+- 参考文献编号、正文引用和图表来源必须一一对应。
+
+## 写作规则
+
+- 标题说明对象或结论范围，不写“我们如何理解”“结果说明了什么”。
+- 先给定义和条件，再给结论。
+- 架构章节解释边界与数据流，不罗列产品菜单。
+- 限制章节必须保留，不能在营销审校时被删除。
+- 技术白皮书可以有观点，但必须区分事实、推断和建议。
+
+## 导出
+
+如已安装 `deai-writing`，在最终通读前扫描中文套路表达；如已安装
+`longdoc-docx`，用其生成 DOCX 并借助临时 PDF 执行高分辨率视觉复核。
+
+## 完成标准
+
+研究问题得到回答；术语统一；关键结论有来源；测试可复核；架构图与正文一致；
+限制、依赖和适用范围完整；参考文献无缺失、重复或无法定位条目。
@@ -0,0 +1,42 @@
+# {{白皮书标题}}
+
+## 摘要
+
+{{研究对象、问题、方法、主要结论和适用边界。}}
+
+## 1. 问题范围与目标读者
+
+## 2. 术语、对象与评价标准
+
+| 术语 | 定义 | 范围 |
+|---|---|---|
+| {{术语}} | {{定义}} | {{适用范围}} |
+
+## 3. 方法与技术原理
+
+## 4. 参考架构与关键数据流
+
+## 5. 产品实现与典型工作流
+
+## 6. 测试方法与结果
+
+### 6.1 测试环境
+### 6.2 数据、样本与统计口径
+### 6.3 测试结果
+### 6.4 不确定性与结果解释
+
+## 7. 安全、治理与部署考虑
+
+## 8. 适用场景与限制
+
+## 9. 结论
+
+## 参考文献
+
+1. {{作者/机构}}，《{{标题}}》，{{版本或日期}}，{{来源定位}}。
+
+## 内部主张追溯
+
+| 章节 | 主张 ID | 证据 ID | 公开级别 | 复核 |
+|---|---|---|---|---|
+| {{章节}} | {{CLM-001}} | {{EVD-001}} | public | 通过 |
@@ -0,0 +1,63 @@
+# 技术方案
+
+基于客户需求、产品事实和项目约束编制完整技术方案，覆盖需求分析、总体架构、
+详细设计、实施、交付、质量、安全、风险和验收。用于投标技术方案或客户解决
+方案；不负责制定招标参数，也不替代逐条招标响应矩阵。
+
+## 必要输入
+
+- 客户需求原文及编号、评分点或验收目标。
+- 产品事实与证据、功能状态、参数和限制。
+- 部署环境、现有系统、接口、数据、安全和合规约束。
+- 项目范围、责任边界、计划、交付物和非范围项。
+
+不确定内容进入“假设与待确认事项”，不能默认为客户已具备或产品已支持。
+
+## 编制顺序
+
+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。
+
+## 完成标准
+
+需求无遗漏；架构、功能、实施、交付和验收闭合；事实与产品版本一致；图表和编号
+连续；假设、偏离、风险和非范围项明确；所有数字和承诺可定位到输入依据。
@@ -0,0 +1,71 @@
+# {{项目名称}}技术方案
+
+## 方案摘要
+
+{{项目目标、方案范围、核心路径和验收结果，完成正文后编写。}}
+
+## 一、项目理解与需求分析
+
+### 1. 业务目标
+
+### 2. 需求分类
+
+| 需求 ID | 原始要求 | 类型 | 关键约束 | 验收目标 |
+|---|---|---|---|---|
+| REQ-001 | {{原文}} | 功能 | {{约束}} | {{可验证结果}} |
+
+## 二、范围、假设与责任边界
+
+### 1. 项目范围
+
+### 2. 非范围项
+
+### 3. 假设与待确认事项
+
+### 4. 双方及第三方责任
+
+## 三、总体技术方案
+
+### 1. 总体架构
+
+### 2. 组件职责与边界
+
+### 3. 关键数据流
+
+### 4. 部署与集成关系
+
+## 四、详细设计
+
+### 1. {{能力模块}}
+
+- 对应需求：{{REQ-001}}
+- 产品能力：{{FEAT-001 / CLM-001}}
+- 处理流程：{{输入、动作、输出}}
+- 依赖与限制：{{条件}}
+- 验收方法：{{步骤和证据}}
+
+## 五、非功能设计
+
+### 1. 安全与审计
+### 2. 性能与容量
+### 3. 可用性、备份与恢复
+### 4. 兼容性与可维护性
+
+## 六、实施、质量与交付
+
+### 1. 实施阶段与里程碑
+### 2. 项目组织与沟通
+### 3. 质量保证与变更管理
+### 4. 交付物、培训与知识转移
+
+## 七、验收、风险与偏离
+
+### 1. 验收方案
+### 2. 风险及应对
+### 3. 技术偏离
+
+## 八、需求追溯矩阵
+
+| 需求 ID | 方案章节 | 产品事实 ID | 交付物 | 验收方法 | 状态 |
+|---|---|---|---|---|---|
+| REQ-001 | {{章节}} | {{FEAT-001}} | {{交付物}} | {{方法}} | 已覆盖 |
@@ -0,0 +1,51 @@
+# 招标响应矩阵
+
+将招标文件技术要求逐条拆解并生成符合性响应矩阵、缺口清单和方案章节映射。用于
+投标前要求解析、响应检查和技术偏离管理；不制定采购参数，也不代写整篇方案。
+
+## 必要输入
+
+- 招标文件原文及可定位的章节、页码或条款编号。
+- 产品事实、参数、证据、限制和规划能力。
+- 拟提交技术方案的章节结构。
+- 招标方规定的“响应、偏离、证明材料”格式。
+
+## 解析规则
+
+1. 保留原始条款，不用概括替代原文。
+2. 将一条中多个独立判定条件拆成子要求，同时保留父条款关系。
+3. 标记要求类型：功能、参数、接口、安全、服务、交付、验收或商务边界。
+4. 识别强制词、阈值、证明材料、评分点和截止条件。
+5. 每项只允许以下状态：
+   - `compliant`：完全满足且有证据。
+   - `partial`：仅部分满足或有范围限制。
+   - `not-compliant`：当前不能满足。
+   - `clarification-required`：原文歧义或缺少必要输入。
+6. `planned` 能力不能用于判定当前 `compliant`，除非招标明确允许项目期内交付。
+
+## 输出
+
+使用 `templates/tender-response-matrix.md` 生成：
+
+- 逐条响应矩阵。
+- 技术偏离和澄清清单。
+- 证明材料清单。
+- 要求到方案章节、产品事实和验收方法的映射。
+
+## 响应纪律
+
+- “完全响应”必须有事实 ID、证据 ID和方案位置。
+- 原文要求高于已知产品能力时如实标记偏离，不得弱化原文。
+- 响应说明写具体实现、范围和条件，不重复“满足、响应”。
+- 尚未定稿的承诺标明审批责任人和截止时间，不能进入最终交付版。
+- 招标文件中的客户名称、项目编号和保密内容不得进入可复用技能模板。
+
+## 两阶段使用
+
+1. **方案编制前**：识别缺口，决定方案结构和需补充的证据。
+2. **方案完成后**：回填最终章节号、证明材料和验收方法，检查是否遗漏。
+
+## 完成标准
+
+原始要求覆盖率 100%；每个 `compliant` 有证据；偏离与澄清未被隐藏；条款编号、
+阈值和方案引用准确；矩阵与最终技术方案使用相同版本和术语。
@@ -0,0 +1,28 @@
+# {{项目名称}}技术响应矩阵
+
+## 一、逐条响应
+
+| 要求 ID | 原条款位置 | 原文 | 类型 | 强制/评分 | 响应状态 | 具体响应 | 条件/偏离 | 事实与证据 | 方案章节 | 验收方法 |
+|---|---|---|---|---|---|---|---|---|---|---|
+| REQ-001 | {{章节/页码}} | {{完整原文}} | 功能 | 强制 | compliant | {{具体能力与范围}} | 无 | {{FEAT-001 / EVD-001}} | {{3.1}} | {{操作或材料核验}} |
+
+## 二、偏离与澄清
+
+| 要求 ID | 状态 | 问题 | 影响 | 建议处理 | 责任人 | 截止时间 |
+|---|---|---|---|---|---|---|
+| REQ-002 | clarification-required | {{歧义或缺失信息}} | {{影响}} | {{澄清问题}} | {{责任人}} | {{日期}} |
+
+## 三、证明材料
+
+| 材料 ID | 材料名称 | 对应要求 | 来源 | 公开级别 | 是否齐备 |
+|---|---|---|---|---|---|
+| MAT-001 | {{测试报告/证书/截图}} | REQ-001 | {{EVD-001}} | restricted | 是 |
+
+## 四、覆盖统计
+
+- 原始要求数：{{数量}}
+- 已拆分子要求数：{{数量}}
+- 完全满足：{{数量}}
+- 部分满足：{{数量}}
+- 不满足：{{数量}}
+- 待澄清：{{数量}}
@@ -0,0 +1,58 @@
+# 招标技术参数
+
+将已核验产品能力转写为可采购、可测试、可验收的招标技术规格和参数表。用于编制
+招标文件技术要求、采购参数或技术规格书；不负责判断投标方是否符合，也不负责
+撰写整篇投标技术方案。
+
+## 必要输入
+
+- 产品事实与证据清单，尤其是功能、参数、限制、部署和兼容性。
+- 本次采购范围、部署规模、适用环境和验收阶段。
+- 强制项、推荐项和可选项的标记规则。
+- 是否允许品牌、专利或特定实现方式出现在参数中。
+
+## 编制原则
+
+1. 参数描述采购目标和可验证结果，避免锁定非必要的内部实现。
+2. 每项只表达一个可判定要求，不能把多个条件塞入一行。
+3. 数值必须包含单位、适用版本、测试条件和统计口径。
+4. 使用“应、须、不得”表示强制要求，“宜、可”表示推荐或可选要求。
+5. 为每项定义验收方法和所需证据，避免“支持、具备、先进”等无法判定的表述。
+6. 无证据或需采购方确认的内容进入待确认表，不得补造门槛值。
+7. 安全、兼容性、部署和服务要求分别成组，不能混入功能参数。
+
+## 参数分类
+
+- 总体与部署
+- 功能能力
+- 接口与集成
+- 性能与容量
+- 安全与审计
+- 兼容性与信创环境
+- 运维、备份与升级
+- 服务、培训与交付
+- 验收与材料
+
+只保留与本次采购目标有关的分类。
+
+## 输出
+
+复制 `templates/tender-technical-spec.md`，生成：
+
+1. 技术规格正文。
+2. 可机读或可复制到表格的参数明细。
+3. 待确认参数与风险清单。
+4. 参数到事实证据的内部追溯表。
+
+## 风险检查
+
+- 是否把规划能力写成强制现有参数。
+- 是否为体现“先进”而编造性能阈值。
+- 是否把特定品牌或架构写成唯一实现路径，造成不必要排他性。
+- 是否存在无法复现的“高、快、强、稳定”等主观指标。
+- 是否遗漏测试数据、环境、并发模型、持续时间或误差范围。
+
+## 完成标准
+
+每项要求具备唯一编号、级别、参数内容、适用条件、验收方法和证据；全文无互相
+冲突的阈值；待确认项没有混入正式参数；公开与保密边界符合输入约束。
@@ -0,0 +1,32 @@
+# {{项目名称}}招标技术规格
+
+## 一、采购范围与适用条件
+
+- 采购对象：{{产品/服务范围}}
+- 部署环境：{{环境}}
+- 适用版本：{{版本}}
+- 验收阶段：{{阶段}}
+
+## 二、技术参数
+
+| 编号 | 分类 | 级别 | 技术要求 | 条件与口径 | 验收方法 | 证据/材料 |
+|---|---|---|---|---|---|---|
+| TP-001 | 功能能力 | 强制 | 系统应{{可验证行为}} | {{版本、环境或前提}} | {{操作、测量或材料审查}} | {{EVD-001}} |
+
+## 三、交付与服务要求
+
+| 编号 | 级别 | 要求 | 验收方式 |
+|---|---|---|---|
+| SV-001 | 强制 | {{交付物、培训或服务要求}} | {{材料或现场验收}} |
+
+## 四、待确认事项
+
+| 编号 | 待确认内容 | 缺少依据 | 责任方 | 截止时间 |
+|---|---|---|---|---|
+| TBD-001 | {{参数或范围}} | {{需要补充的证据}} | {{责任方}} | {{日期}} |
+
+## 五、内部追溯表
+
+| 参数编号 | 事实/主张 ID | 证据 ID | 复核结论 |
+|---|---|---|---|
+| TP-001 | {{CLM-001/PAR-001}} | {{EVD-001}} | {{通过/待确认}} |