真-技术方案编写

投标方案编写的三个常见坑

写技术方案的人大多经历过这类循环：对着招标文件先通读一遍，凭感觉搭目录，写到实施章节发现评分点没覆盖，回头补章节又打乱了原有结构。更隐蔽的问题是承诺越写越多——为了在响应表里好看，把没做过的方案、没配过的人手、没验证过的指标都写了进去，评审没人拦，交付团队接盘时才炸。

这个 skill 要处理的就是这三件事：评分点和章节结构的对应关系、正文撰写时的能力边界、以及成稿前的一次独立评审。

它的工作方式

• 先解析再动笔：把招标文件拆成采购需求、评分规则和需要单独写方案的条目，输出 temp/bid-analysis.md 作为后续评审的输入。评分主项强制独立成 H2，子项独立成 H3，不允许合并。
• 领域感知：启动时自动探测 reference-cases、tech-param-indices 和 domain rules 三处是否都有积累。三处全空则标记为 uncharted，询问用户是否加载零经验领域写作规则；确认后才产出 domain_research.md 和竞品分析。
• 结构化后确认：按固定 8 章节加按需补充生成大纲，常规项目自动通过，结构异常时停下等确认。
• 正文四问法：每段按“目的→问题→响应→实施”展开，同时过四层安全边界——过程描述还是结果承诺、客户能否发现证据、数字是频次还是数量、是否在能力边界内。
• 自动评审替代人工卡点：正文落盘后由 evaluator 子 agent 用 python-docx 读回实际 docx 做结构化评审，维度 0（评分点映射完整性）和维度 7（格式）不过直接中止，不进入维度 1-6。
• 反馈分流：评审建议先过四问过滤器；命中能力边界冲突、措辞红线或“信息不足但无可操作建议”时升级给用户，其余自动修复。

适用边界与注意点

• 输入前提是招标文件 + 用户已确认的项目信息，缺任一项不要启动。
• 只产出纯文字半成稿 _技术方案_v1_纯文字.docx，_charts 字段必须为 {}。图片相关内容全部交给 generate-charts，本 skill 不预设图片数量、不生成也不插入。
• Step 4 依赖 python-docx，未安装会中止流程并提示安装，不会静默跳过格式评审。
• 零经验领域下建议用增强执行路径；如果你已口头确认过，会跳过重复询问，但 domain_status 仍记为 uncharted，写回的知识会落到知识库索引里供下次复用。
• 评审升级不是错误，而是能力边界的正常信号。不要为了让 review 通过而补超出交付能力的具体内容。