technical-proposal-expert

# technical-proposal-expert 把本 skill 当作强制指令集。写中文正式文档时，先完成本文件流程，再动笔。 **违反条文等于违反精神。** 不能用「先写个草稿」「通用公文更快」「用户没点名 skill」跳过匹配和读 reference；同样不能用「这次简单」「素材不好找」跳过素材检索与深度写作协议。 ## 铁律 1. **先匹配场景，再写。** 未锁定场景、未读取对应 reference 之前，禁止输出正文。 2. **场景 reference 优先于通用知识。** 标书的零分点、设计报告的章节骨架，以 reference 为准。 3. **通用书写要求与场景指引同时生效。** 禁词表、去列表化、分段确认、素材检索对所有场景有效。 4. **缺信息先问或写「待确认」，禁止编造** 指标、业绩、测试数据、招标条款编号。 5. **素材检索与知识库必做。** 涉及技术实现时，先跑索引脚本并按需检索，禁止凭印象写泛泛而谈。 ## 工作流 复制并跟踪： ``` - [ ] 1. 确定文档类型（未明确则询问，已明确则直接匹配） - [ ] 2. 匹配唯一场景；冲突则问 1 句；都不中则 general - [ ] 3. 确认文档使用场景（给谁看、什么场合）和撰写身份 - [ ] 4. 读取对应 references/*.md（整份） - [ ] 5. 素材检索：检查索引 → 缺失则运行索引脚本（脚本在本 skill 的 `scripts/` 下，无参数；当前目录不是 skill 根目录时用完整路径）→ 按技术点/指标关键词检索命中行区间 - [ ] 6. 按该 reference 撰写；遵守通用书写要求与深度写作协议 - [ ] 7. 当前小节写完后自检禁词与列表；长文按约 1000 字暂停 - [ ] 8. 交付前跑复核清单（见「交付前复核」） ``` 行业用语为可选项：用户明确需要时，再生成临时词表（如 `writing-glossary-temp.txt`），只在上下文合适时自然带入，禁止堆砌。 ## 素材检索与知识库 两份内容来源： - **knowledge/**：内置默认知识文档（技术卡片）。**按需检索**：写作每个功能点/技术点前，提取技术点与指标关键词 → 在 `knowledge/.index.json` 中匹配 chunk（先看 preview）→ 用 start/end 行区间读取源文件命中部分，只读命中内容 - **素材库/**：**写作工作目录下**的用户素材（仅 md/txt），**不设全局素材库**。把招标文件摘编、技术规范、历史标书等放入当前写作目录的 `素材库/`；**命中相关即全文读取**（用户素材通常体量小且直接相关）。项目写完素材随项目保留或清理，不跨项目混用 流程： 1. 若 `knowledge/.index.json` 或 `素材库/.index.json` 不存在，或素材有新增/变更，先运行索引脚本（无参数，自动生成两个索引）：`python scripts/index_materials.py`。脚本位于本 skill 的 `scripts/` 目录；当前工作目录不是 skill 根目录时，用该脚本的完整路径运行（仍无参数）。脚本只索引「skill 的 `knowledge/`」与「当前工作目录的 `素材库/`」 2. 读取两份索引，确认素材清单与结构 3. 写作前按技术点/指标关键词检索 knowledge 索引；用户素材全部读取 4. 把「素材使用清单」记入 plan.md 或草稿：功能点 → 使用了哪份素材的哪一节（保留来源以便核验） 5. 规则：项目素材与内置知识冲突时以项目素材为准；索引只指向行区间，检索后必须回到源文件读原文，禁止凭索引编造内容；交付正文不出现「参考了某文档」痕迹（除非用户要求） ## 技术路由（knowledge/） | 技术点关键词 | 默认知识目录 | |---|---| | 微服务、中台、服务治理 | knowledge/微服务与中台 | | 大数据、离线/实时计算 | knowledge/大数据 | | 视频AI、图像识别、算法 | knowledge/AI与视频分析 | | 物联网、传感器、边缘计算 | knowledge/物联网与感知 | | 信创、国产化、自主可控 | knowledge/信创与国产化 | | 等保、安全、密码、数据安全 | knowledge/安全与等保 | | 高可用、容灾、备份、集群 | knowledge/高可用与容灾 | | 数据治理、数据交换、共享 | knowledge/数据治理与交换共享 | | 低代码、BPM、流程引擎 | knowledge/低代码与BPM | | 移动端、小程序、App | knowledge/移动端 | | 云原生、K8s、容器、Redis、Kafka、Istio | knowledge/云原生与开源组件 | | 测试方案、测试金字塔、质量模型 | knowledge/测试与质量 | | 文档模板、SRS、SDD、DBDD、GJB 438C | knowledge/文档模板 | | 标准引用、合规核对 | knowledge/合规与标准 | 未命中则跳过，不强行套用。目录内文件按「技术卡片」格式组织，见 [knowledge/README.md](knowledge/README.md)。 ## 深度写作协议（技术点必答六问） 每个关键技术点（选型、算法、架构决策）写作前强制回答，正文据此展开： 1. **解决什么问题**：对应哪个需求/指标/招标条款 2. **为什么这么选**：备选方案与取舍（禁止用「业界主流」「成熟稳定」搪塞） 3. **关键机制与数据流**：组件、协议、时序、核心算法 4. **工程化落地**：配置、部署、监控、灰度、回滚等可执行细节 5. **如何验证**：指标、测试方法、验收方式 6. **风险与降级**：失败模式、边界与应对 写完后自查：若一段话去掉修饰词后没有实质技术内容（组件、机制、数据流、数字），即为泛泛而谈，重写。 ## 场景路由 | 用户说法 | 场景 | 必须读取 | |---|---|---| | 技术标书、投标、招标、投标书、标书 | technical-proposal | [references/technical-proposal.md](references/technical-proposal.md) | | 方案设计报告、设计报告、系统设计、研制方案 | design-report | [references/design-report.md](references/design-report.md) | | 测试报告、测试总结、测试说明 | test-report | [references/test-report.md](references/test-report.md) | | 周报、周总结、工作周报、周度汇报 | weekly-report | [references/weekly-report.md](references/weekly-report.md) | | 其他、未明确、通用、一般文档 | general | [references/general.md](references/general.md) | **歧义**：只说「技术方案」、未提投标/设计时，问一句是「投标技术标」还是「方案设计报告」，不要两套一起写。 同一对话锁定场景后不要中途更换，除非用户明确要求切换。 未说明类型时，用下面这段询问（不要先写正文）： > 已加载 technical-proposal-expert。支持：技术标书、方案设计报告、测试报告、周报；其他按常规文档处理。本次要写哪类文档？ ## 撰写前必确认 - **使用场景**：给谁看、什么场合（对外投标、内部汇报、甲方验收、留档等） - **身份**：撰写者或代表方（乙方技术负责人、项目经理、测试负责人等） 据此调整语气、详略与称谓。用户没给就简短追问，不要默认成空泛「我司」。 ## 通用文本书写要求 ### 禁词 | 禁止 | 改为 | |---|---| | 总的来说 / 总之 | 综上所述 / 基于上述… / 鉴于此 | | 首先/其次/最后 | 第一，…；在此基础上，…；最终，… | | 我们致力于 | 本方案旨在 / 项目组将重点投入 | | 这是一个… | 该模块被定义为… / 该子系统主要承担… | | 可以/能够 | 具备…能力 / 实现…功能 / 支持…操作 | 「可以/能够」指技术能力时改写；若表示允许性或条件成立（如「在X前提下可以…」）则保留，不机械替换。 ### 去列表化 正文避免纯分点。优先叙述或「总—分—总」。表格、接口、参数、库表、清单可用列表或表。场景若规定「零分点」（标书），以该场景为准。 ### 逻辑 段落用「基于上述分析」「在…前提下」「针对…场景」衔接。层级是否强制（`一、` / `1.1`）看场景 reference。 ### 输出 - 每次输出完整小节或模块，不写半截；若小节自然结束时不足约 1000 字，先交付完整小节，不强行灌水 - 长文档约每 1000 个中文字符暂停，等用户确认再继续 - 写入文件时增量追加，不一次写完全文 ## 交付前复核（每次交付前必做） 1. **待确认清零**：所有「待确认/待确认条款」从交付正文收敛为一份问题清单（单独文件或 plan.md 附录），正文清零后再交付；交付时附问题清单 2. **禁词扫描**：全文检查禁词表 3. **需求/条款响应核对**：标书逐条核对招标需求，设计报告核对需求与指标 4. **指标一致性**：指标数值与支撑设计一一对应，不允许「写了指标没写实现」或「写了实现没写指标」 5. **素材来源核验**：正文关键事实能在素材使用清单中找到来源；无来源内容已标「待确认」 6. **完整性**：章节骨架无缺漏（设计报告不合并删章） ## 找借口对照 | 借口 | 事实 | |---|---| | 用户只要一段正文 | 仍要先匹配场景并读 reference | | 先按通用 SRS/方案写 | 场景骨架在 reference 里 | | 禁词太严、先写后改 | 按禁词表直接写 | | 标书用 bullet 更清晰 | 标书零分点；表结构除外；招标文件明确要求分点响应时例外 | | 没说身份也能写 | 未提供则追问，不编造甲方/乙方口吻 | | 这次简单，不用检索素材 | 素材检索是铁律；先看索引，命中才读，不增加负担 | | 检索太麻烦，凭经验写 | 泛泛而谈的根源就是跳过检索；索引有 preview，能快速定位 | ## 红旗 — 停下重来 - 还没读对应 reference 就开始写 - 标书正文出现 `-` / `*` 分点（招标文件明确要求除外） - 编造招标条款号、通过率、性能指标 - 没跑索引脚本就写技术实现，或技术点只有概念词没有机制与数据流 - 正文残留「待确认」就交付 - 长文一次倒出数千字且不暂停 ## 最小示例 用户：「写一份政务监管平台的技术标书，模块有一张图和告警。」 1. 路由 → technical-proposal → 读 `references/technical-proposal.md` 2. 确认场合=对外投标、身份=乙方技术负责人（若未说则问） 3. 跑索引脚本（若索引缺失；脚本在 skill 的 `scripts/` 下，无参数）→ 读两份索引；若工作目录有 `素材库/` 则用户素材全文读取；涉及视频/图像技术点检索 knowledge 对应卡片 4. 默认大文本模式：建 `plan.md`，先收架构与需求清单，再按模块叙述撰写 5. 每个功能点按六问协议展开（机制、数据流、指标支撑），正文零分点，并响应招标条款 6. 交付前跑复核清单（待确认清零等）