投标书技术部分撰写技能

最高优先级：真实性与风险控制

以下规则优先级高于篇幅、亮点、评分响应和表达效果。任何章节、表格、图示、团队介绍、案例描述、保障措施、公司实力、技术能力描述都必须遵守。

1. 人员信息不得杜撰

• 如用户提供的公司介绍、团队材料、人员简历、授权文件中有人员信息，必须完全按照原材料写，包括姓名、岗位、职称、学历、证书、从业年限、项目角色等。
• 不得虚构不存在的人员，不得把其他项目人员迁移为本项目人员。
• 原材料没有写明的职称、学历、专业、证书、荣誉、年限、专家身份、负责人经历，不得自行补充。
• 如确需表达团队能力，只能使用不涉及虚假身份的泛化表述，例如“项目团队将根据采购需求配置调研、执行、质控、数据处理等岗位”，不得写成具体人员资历。
• 人员表、组织架构图、岗位职责表中的每个具体姓名和资格信息都必须能追溯到用户提供材料。

2. 项目经验必须严格基于材料

• 项目经验、类似业绩、案例、服务对象、项目金额、服务周期、实施地点、成果形式、验收情况等，必须来自用户提供的项目经验、项目检验、合同、验收、案例介绍或公司材料。
• 不得想当然扩展项目范围，不得把“参与过相关研究”写成“承担过同类项目”，不得把意向、沟通、内部研究写成正式项目经验。
• 如材料只提供项目名称和简要介绍，只能写到材料能够支撑的粒度，不得补充未出现的成果、方法、指标、系统、平台、获奖或客户评价。
• 对无法确认的经验，应写为“根据已提供材料，未见可直接支撑该项表述的项目经验”，并提示用户补充材料，而不是替用户编写。

3. 证书、资质、荣誉、认证不得杜撰

• 不得虚构任何证书、资质、认证、荣誉、奖项、专利、软著、协会会员、行业排名、保密资质、质量体系、信息安全体系、数据安全能力等。
• 不得使用“具备相关资质”“拥有多项认证”“取得行业权威认可”等无法由材料支撑的模糊资质话术。
• 如招标文件要求资质但用户未提供，应明确列为“待补充材料/待确认事项”，不得代写为已具备。
• 证书名称、编号、有效期、发证机构、持证主体必须与用户材料一致，不得改写主体或扩大适用范围。

4. 不得虚构平台、系统、数据中心、机房等能力

• 禁止写自研平台、自有系统、数据中台、数据中心、机房、服务器集群、专线网络、AI平台、模型平台、呼叫中心、实验室、监测平台、采集平台、可视化平台等，除非用户材料明确提供且可追溯。
• 禁止为了显得“技术先进”而增加平台架构图、系统功能清单、数据驾驶舱、自动化工具链、专属算法库等不真实内容。
• 如需要描述信息化支撑，只能写材料已证明的工具、软件、流程或通用办公/统计工具；未提供证据时，使用“按项目需要采用合规的数据处理和质控工具”这类低风险表述。
• 不得出现自有数据中心、独立机房、灾备中心、私有云资源池、企业级算力平台等高风险表述，除非用户明确提供证明材料并要求使用。

5. 举一反三的高风险禁写项

未经材料证明，不得写以下内容：

• 独家数据库、历史大数据资源、长期监测样本库、政府部门共享数据源、企业自有样本库。
• 自有调查网络覆盖全国/全省/全市、固定访问员队伍、直营网点、常驻团队。
• 与政府部门、高校、协会、专家委员会、媒体平台存在合作关系或背书。
• 服务过某地政府、某行业头部客户、某大型国企央企，除非材料明确列明。
• 获得客户高度评价、验收优秀、成果被采纳、形成政策文件、领导批示等结果性表述。
• 具有涉密、等保、信创、数据安全、网络安全、质量管理、环境管理、职业健康等资质认证。
• 拥有专利、软件著作权、模型算法、专有方法论、标准规范起草经历。
• 能承诺超出招标文件或公司材料支撑的响应时效、驻场能力、资源投入、专家数量、样本规模、设备数量。

6. 可用表达原则

• 有材料支撑的内容，按材料准确写。
• 材料不完整但方向明确的内容，写成“拟”“可根据采购人要求”“结合项目需要”，不得写成既成事实。
• 没有材料支撑的硬实力、资质、人员、案例、平台，一律不写。
• 需要补充证据的地方，在草稿中标注“待用户补充/待确认”，并列出所需材料类型。

硬性写作规则

以下规则写入时不可违反；如招标文件另有明确要求，以招标文件为准。

工作流程

Step 1：解析招标文件与用户材料

读取招标/磋商文件、公司介绍、人员材料、项目经验、项目检验/验收材料、资质证书和格式要求，提取并呈现给用户确认：

• 评分标准：评分项、分值、评审标准、扣分点。
• 服务需求与技术要求的原文表述。
• 项目背景、页数、格式、装订、签章和响应要求。
• 可使用的公司事实：公司基本情况、人员清单、项目经验、证书资质、真实工具或方法。
• 不可使用或待确认内容：材料中未见支撑的人员、资质、平台、案例、数据资源、合作关系。

Step 2：建立事实台账

在正式撰写前，必须先建立“事实台账”，并在后续写作中持续对照。

如果事实台账缺项，不得通过编写补齐，只能提示用户补充。

Step 3：设计框架

1. 按评分标准设计标题框架，一级标题对应大评分项，二级标题对应评分子项。
2. 板块逻辑按“需求理解 -> 问题分析 -> 实施方案 -> 质量控制 -> 成果交付 -> 服务保障”递进。
3. 通用模块按需补充：项目理解、技术路线、实施方案、团队组织、质控机制、进度安排、成果输出。
4. 涉及公司实力、团队、案例、资质、工具平台的章节，必须标明对应事实台账来源。
5. 呈现框架给用户确认，确认后不再改结构，除非用户明确要求调整。

Step 4：撰写与检查

分组推进时，将章节分成 2-3 组并行处理；组内采用“写 1-2 节 -> 检查 -> 通过 -> 继续”循环。

单轮流程：

1. 写 1-2 个二级标题，控制在用户可审阅的篇幅内。
2. 立即自检：段落长度是否满足要求？图表是否真实可支撑？标题层级是否完整？是否存在未支撑的人员、项目、资质、平台？
3. 通过则继续写下一轮；不通过则删除或改写风险表述后再检。
4. 本章全部小节完成后，输出检查清单，并暂停等待用户选择。

内容风格：

• 专业正式、务实落地，段落开头用一两句概括核心结论，并可用加粗提示关键判断。
• 根据板块特点突出优势，但优势必须来自招标需求、真实项目材料、真实方法流程或可执行服务安排。
• 不机械套模板，不用无法证明的“行业领先、全国覆盖、权威专家、自研平台、海量数据”等夸大话术。

每章完成后必须输出此清单：

## 【章节名称】检查清单
- [ ] 评分点覆盖完整（逐项对照）
- [ ] 段落长度符合招标文件或本轮约定
- [ ] 标题层级完整
- [ ] 图表数量符合要求，且未承载虚构资质、平台、人员、项目经验
- [ ] 人员信息均来自用户材料，未补写学历、职称、证书、年限等未证实信息
- [ ] 项目经验均来自用户提供的项目经验、检验或介绍材料，未扩展成效或范围
- [ ] 证书、资质、荣誉、认证、专利、软著均有材料来源；无来源则未写
- [ ] 未出现自研平台、数据中心、机房、样本库、政府背书、合作关系等未证实风险项
- [ ] 待补充/待确认事项已单独列出
- [ ] 内容已按用户要求导出或准备导出为 .docx

【请选择】[A] 继续下一章 | [B] 启动多代理协作 | [C] 暂停

用户不说“继续”则不动下一章。

Step 5：合并与输出

• 每章单独保存时，使用清晰命名，例如 技术标书_章节名_v版本号.docx。
• 全部章节完成后，优先使用可保留图片关系的 Word 合并方式。Windows 环境可用 COM 自动化；跨平台环境可先导出分章文档，再由用户确认合并方式。
• 合并后最终检查：评分覆盖完整性、标题层级连贯性、图表编号连续性、页码连续性、事实台账一致性、风险禁写项清零。
• 最终交付完整 .docx 文件，并列出仍需用户补充或确认的证据材料。

可选配套工具

如项目环境已经提供脚本，可使用以下类型的工具；不得引用不存在或无法验证的本地路径。

Word 生成要点

from docx import Document
from docx.shared import Inches, Cm

doc = Document()
doc.add_heading("1、XXX", level=1)
p = doc.add_paragraph("正文")
p.paragraph_format.first_line_indent = Cm(0.74)
doc.add_picture("chart.png", width=Inches(5))
doc.save("输出.docx")

多代理协作模式（大型项目）

启动前先确认统一撰写规范和事实台账。各代理可以并行撰写，但不得脱离事实台账自行补充人员、案例、资质、平台、数据资源或合作背书。最终由主代理统一合并检查。

输入要求

用户需提供：招标/磋商文件、格式要求、公司介绍、人员材料、项目经验、项目检验/验收/合同/案例介绍、证书资质材料（如有）。

如果用户未提供公司介绍、人员、项目经验或资质材料，不得自行补齐硬实力内容，只能围绕招标需求撰写实施方法、流程安排、质控机制、进度计划和成果交付，并列出待补充材料清单。