高效标书自动化：AI技能处理1111页文档指南
一家传统企业的客户，带着1111页、总计超过60万字的标书文件找上门。客户所处的领域我完全陌生，但打开资料的一瞬间就确认——这绝非一个常规需求。整套投标材料，数据一目了然：1111页，60余万字。
这个数字背后，真正棘手的不是“撰写”，而是“修订”。此类工作的核心痛点，并不在于内容本身有多深奥。
流程大致如下：每次投标未必一次中标，可能流标。流标之后，二次、三次投标接踵而至。此时最消耗精力的不是从头重写——基础框架已经有了；真正的麻烦在于，你不得不改，因为新的投标信息、新增要求、新细节都必须逐一匹配。要在1000多页、60多万字里逐页翻查、逐段定位、逐条修改。方向一旦确定，后续几乎全是体力活，而且是那种极度消磨人的机械重复。
问题拆解：先想清楚哪部分能被AI接管
接到需求后，第一个冒出来的问题不是“这份标书该怎么写”，而是“这件事到底哪一部分可以让AI来接手”。思路逐渐清晰：要解决这个问题，至少需要满足两个前提。
第一，把整个流程做成自动化工作流。不是只解决某个片段，而是把读取资料、理解结构、生成内容、修改内容这条完整链路串起来。第二，必须拿到客户之前做过的标杆标书。想让AI生成高质量内容，前提不是空口告诉它“你写好一点”，而是先让它知道“好的标准到底长什么样”。只有让AI去读一份真正合格的标书，理解里面的结构、措辞、章节逻辑、内容组织方式，后续生成的东西才有可能达到业务可用级别。
客户发来的资料比较杂乱，包含Word、图片、各种附件格式，总计80多兆。不过这类情况比较熟悉，流程就是：先整理，再转换，再训练。
第一步：把1111页标书转成Markdown
拿到资料后，先把那份1111页的标书转成了Markdown。为什么？因为对AI来说，Markdown这种结构化文本更容易被读取、拆解、理解，也更方便后续拿去做Skill训练。如果一直守着原始Word，里面各种图片、样式、分页、表格干扰，模型处理起来很笨重。一旦转成Markdown，标题是什么、章节是什么、正文是什么、层级关系是什么，立刻就能拉开。这一步做完，真正核心的任务才开始。
核心环节：创建可复用的Skill
很多人对AI的理解还停留在“问一次，答一次”。但真要解决工作问题，只靠一次性对话远远不够。真正有价值的，是把解决问题的方法沉淀下来，变成一个以后可以反复调用的资产。
所以做的不是让Claude临时写几段内容，而是让它去学习这份标书，学习这个行业里一份“好标书”大概长什么样，再按照客户要求给这个Skill做约束：约束它该读什么，该怎么理解，该怎么输出，遇到不同投标要求时应该优先改哪些内容。这些约束都定下来后，再去定义最终产出的格式和质量标准。
中间调了几轮。有些地方约束太松，生成结果会跑偏；有些地方约束太死，Skill体积又变大，调用不够轻。几轮调试下来，这个Skill才算真正定型。
现实优化：给Skill“减肥”
刚开始做好的时候，Skill体积不小。原因很简单：里面塞了不少参考文件，很多内容是为了让它学得更稳。但Skill不是越大越好。约束不变的情况下，Skill越精简，调用效率越高，后续使用体验也越稳定。
后来让Codex做了一轮压缩：把Markdown内容精简一部分，冗余说明拿掉，SQL行数也尽量减少。目标是不牺牲核心约束的前提下，尽可能缩小体积。这个过程很像做产品——不是功能堆得越多越好，而是要找到那个真正能打的最小闭环。
意想不到的难题：环境适配
Skill做完之后，突然意识到一个问题：客户既没有Claude Code，也没有Codex。东西做出来了，对方根本没有能接住它的环境。很多技术人做工具，做到这里就停了——站在技术人的视角，会默认对方“装一下不就好了”。但现实不是这样。很多传统行业用户，别说装Claude Code，可能连这些名字都没听过。
后来尝试把这个Skill转成豆包、元宝、千问这些国内大模型平台也能调用的形式。思路没问题，但很快一个更硬的限制出来了：上下文字数太长。60多万字，1100多页。国内这些平台到底能不能完整吃下这么长的内容？客户也试了，推荐他用扣子去搭，但效果不理想。原因很简单：超长上下文场景下，很多平台不是完全不能做，而是做得不够稳、不够透，不够像在处理一份复杂业务文件。
落地执行：远程指导安装
最后没办法，客户付了一点咨询费，就直接远程指导他安装。约了一场一小时的WebEx会议，远程操控他的电脑，把Skill和Claude Code安装上。整个界面全是英文，但背后调用的模型是国内的，不需要访问国外网站——这一点特别关键。对很多传统行业用户来说，技术门槛未必只是“会不会用”，还有“敢不敢装”。只要提到英文界面、提到代码、提到网络环境，很多人心里就先退一步了。所以不能只告诉他“这个工具很强”，得真的帮他把第一步迈过去。
装完之后，按他的要求现场试了一轮。当天晚上跑下来，初步结果已经不错。时间比较晚了，就先收工，准备第二天再看。
反馈与感触
第二天，他单独发来感谢信，说这个东西确实帮他解决了很大问题，效率几乎是指数级提升。后来继续聊，也跟他说，传统行业里面重复性工作特别多。不是没人做，而是大家长期都在用很传统的方式一点点手搓。问题不在于这些人不努力，而在于他们没有真正接触过这套信息化和AI化的工作方式。很多本来可以交给模型去处理的繁琐活，最终还是落回到人肉身上。
到了晚上，他拿到了最终结果，非常高兴。亲口说这份标书写得非常好，改得也非常好。
赚到一点咨询费是一部分，但更重要的，是能明显感受到帮别人解决了一个非常具体、非常痛、原本很难解决的问题。这种反馈很直接——不是在讲概念，也不是在讲趋势，而是在帮一个真实的人，省掉大量重复劳动，让他的工作一下子轻很多。这件事本身就很有价值。
一个判断：传统行业里有大量AI机会
回过头来看，最大的感触是：站在IT行业、互联网行业里，很容易产生一种错觉——觉得大家都会写SQL，都会调各种智能体，都会用大模型，都会折腾自动化。可一旦把视角往下沉，沉到一个个具体传统行业里，你会发现不是这样的。很多人是真的不会用。不是他懒，也不是他不想学，而是没人带，没人讲，没人帮他迈过第一道门槛。
可偏偏，他们手上又有大量强需求。这些需求还特别具体、特别刚需、特别值得被AI改造。后面可能会花更多精力，去做一些面向传统行业的教程、讲解和案例分享。因为这里面的需求非常大，只是很多人痛了很久，还没找到真正能帮他的人。
最后
AI最有价值的地方，不是让会的人更炫，而是让原本很重、很慢、很笨的工作，终于有机会被重新做一遍。这次帮客户做标书Skill，就是一个特别具体的例子。他付出了一点咨询费，解决了最痛的问题；收到费用，也收到了感谢。这是一种很舒服的协作关系——互利，也是利他。
如果你现在所在的行业，也有大量这种重复、繁琐、规则清楚、但特别耗人的工作，真的可以认真想一想：这件事，是不是已经可以交给AI了？也许缺的不是更努力一点，而是一个合适的工具，和一个带你把它真正装起来、用起来的人。