AI 标书撰写：把“写”变成“控”。我的tender-writing skill 开源了

2026-07-19 / 产品 / 2浏览

先说结论

我把这几年写技术标书攒下来的方法,整理成了一个能直接用的 skill,开源放在 GitHub 上了。仓库叫 myskills,目前里面就一个:tender-writing。地址在文末。

标书这个东西,写过的人都不想写第二次。结果我不但写了很多次,还顺手把它拆成了流程。

做这个 skill 的起因很简单:标书是我见过最适合交给 AI、也最不能随便交给 AI 的文体。

适合,是因为它体量大、结构死、大量内容本质上是"按要求组装"。不适合,是因为 AI 在这件事上翻车的方式特别隐蔽——它不是写不出来,是给你编。编一个不存在的业绩,编一本没有的证书,编一句"年可用性99.99%"的承诺。文字通顺,格式漂亮,评委一查,废标。

所以这个 skill 的核心设计,不是"怎么让 AI 写得更好",是"怎么让 AI 不能瞎写"。

写过标书的人都知道:评委不是读者,是打分员。

他手里有张评分表,一项一项对。你方案写得再漂亮,他在目录里找不到对应那一项的章节,那一项就是零分。不会有人替你翻遍三百页找亮点。

所以这个 skill 干的第一件事不是写,是建一张评分项映射表:招标文件里每一条评分项,对应目录里哪个章节,打算怎么响应,需要什么证据材料,现在是什么状态。

目录先对着评分表长出来,正文再往里填。顺序不能反。

反过来的写法我见得太多了:先洋洋洒洒生成一版"完整方案",再回头对评分表,发现漏了三项。补上的那三项,跟全文完全不是一个味儿,评委一眼就能看出来是后贴上去的。

标书动辄几百页,AI 分章节生成,问题就来了:第三章说工期 90 天,第七章变成 60 天;前面项目经理还姓张,后面就换了个人;运气差的时候,连公司名字都能给你换一个。

每一章单看都没毛病,拼起来就是废标现场。

所以 skill 里强制了一个东西,叫全局事实底稿:项目名称、公司名、工期、服务期、质保、人员、设备、指标、响应时间,动笔前先统一登记。后面所有章节只能引用底稿,不许自己现编。

材料里没有的怎么办?写 [待确认],留着,等人补。

这是整条红线里我最看重的一句:缺真实材料就占位。占位不丢人,编数据才要命。

最后还有一道审计,过不了审不许交付:评分项覆盖齐不齐,全文事实一致不一致,有没有残留别的项目名称,日期对不对,签字盖章的位置有没有列进检查范围,"尽量""争取"这类不敢承诺的词清干净了没有。

废标很少死在方案不行,大多死在低级错误。模板里残留上一个项目的名字这种事故,谁踩过谁知道。

所以交付物里除了正文,还有占位项清单和人工复核清单。AI 能确认的它确认,不能确认的,明明白白告诉你哪些要人来看,而不是默认通过。

整个 skill 拆下来其实就一句话:把"写标书"从一次性的生成,变成一套可检查的流程。

读文件、建底稿、定目录、逐章写、全文审计、汇总交付。六步,每步都有产出物,每步都能停下来核对。

AI 负责苦力,人负责事实。这个分工不能反。

拿去就能用。要是它帮你避开了一次废标,记得回来点个 star。