一个承包商三天后发来技术文档回复：四十页，光鲜的流程图，每隔一段就出现“AI智能体”。三个月后，项目耗尽了预算，两次推迟截止日期，承诺的AI功能不过是会议间隙用聊天模型复制粘贴出来的东西。根据Standish CHAOS 2020的报告，在对5万多个项目进行分析之后，只有31%的软件项目按时、按预算、按范围完成，另有50%以超支告终，还有19%彻底失败。
项目并非在第三个月才宣告失败，而是从一开始的那份文档里就已经埋下了伏笔。那份技术文档中缺少了关键的章节——那些能够让你一眼看穿承包商究竟是真正会运用AI，还是仅仅精于撰写漂亮回复的衡量标准。文档的基本框架早已标准化，神经网络一个晚上就能生成一份草稿。这正是陷阱所在：用同样的一个晚上，它也能生成一份金玉其外的空壳。而区分这两者的，正是接下来要谈及的七个关键部分。
在这场筛选游戏中，最昂贵的环节就是需求文本的拟定。据ContextQA估计，一个完整的AI工具招标流程需要6到10周，消耗团队120到200小时的内部时间（按每小时75美元的费率计算，成本在9000到1.5万美元之间），其中整整两周被花在了撰写需求和制作评分卡上。不过，同一个需求简报，如果通过像俄罗斯版OpenRouter这样的神经网络聚合器provod.ai去执行，一晚上就能转化成三份各具特色的竞争性草稿：GPT和DeepSeek在同一个窗口里给出回复，并且支持卢布支付。现在剩下的问题，就是搞清楚到底该向模型提什么要求。
简单来说，需求不完整是软件项目失败的第二大常见原因，而跳过实战检验环节，则会把挑选承包商的过程变成一场文案比赛。一份缺乏可衡量标准的文档，筛选不了任何人。这个教训从1994年第一份CHAOS报告分析3682个项目时就已经显现：当时项目失败的首要原因中，缺乏用户参与占12.8%，需求不完整占12.3%，需求变更占11.8%。三十年过去了，根据同一份CHAOS 2020的汇总数据，大型项目的成功率甚至跌破了10%。需求，是项目在尚未进入代码编写之前，就开始流失资金的地方。
ContextQA对此的论断一针见血：跳过最终的实战比武环节，遴选就变成了“签下最佳写作能手，而不是最佳工具”。一份无可挑剔的回复，只能证明供应商擅长撰写回复，除此之外什么也证明不了。这种判断的必要性，在麦肯锡2025年的AI现状报告中也能找到更深层的注脚。那份报告调查了1993名受访者，发现虽然有88%的组织至少在一个职能部门中经常使用AI，但报告看到了AI对息税前利润产生影响的组织却只有39%。将AI转化为商业价值的主要因素在于对工作流程的重新设计，而非工具本身。一个属于那88%“在用AI”的承包商，未必在那39%真正将AI转化为金钱的行列里。而一份合格的任务书，理应能将前者和后者区分开来。
简短地总结一下结构规范：现行标准规定了十个必备章节，但其条款4.2明确允许合并和删减子章节。本文所论述的七个实战章节，正是对国家标准规范的合法浓缩与定制，旨在服务于采购任务。自2021年1月1日起生效的ГОСТ 34.602-2020“自动化系统技术任务书”定义了这十个章节，并在第4.2条中明确指出，可以引入额外章节，或将子章节进行拆分与合并；如果某个章节下没有对应需求，则应保留该章节并注明其内容为空。以下内容，便是基于该标准结构所做的一次采购适配。
热门跟贴