写方案最难受的一幕，是在会上被人一句话问住：这个措施为什么这么定？当时为什么没考虑另一种情况？我以前吃过不少这样的亏。后来我改了一个习惯：方案在定稿之前，先让 AI 当一次"找茬的人"。这件事做了大半年，比我学任何一个新工具都管用。
一开始我也让 AI 帮我写方案，出来的东西四平八稳，专业词一个不少，但落到我们这个具体项目上经常是错的——因为它不知道现场条件、不知道我们的资源、不知道甲方的脾性。方案的价值恰恰在那些具体条件里。
后来我把用法改了一下：方案草稿我自己写，AI 只负责提问。它会问出一些我确实漏掉的东西：工期紧的时段资源怎么组织、异常天气怎么办、相邻标段的接口谁负责、临时用电的负荷算过没有。这些问题我未必全采纳，但被问过一次，会上就答得出来。
第一组是条件核对：把项目条件（规模、地质、周边环境、既有设施、工期节点）列给 AI，让它找出"方案里没有回应的条件"。这一组能揪出最典型的漏项。
第二组是反向论证：直接问它"如果这个方案失败，最可能的原因是什么"，让它列三条以上。这一组的输出质量明显好于普通提问，因为它被要求站在对立面。
第三组是检查表核对：把行业通行的检查要点交给它，让它逐条对照我的方案说"有/无"。这一组用来自查，不用来给自己打分，因为 AI 的判断不能当依据。
第一，凡涉及数字、规范条文、验收标准，一律自己核原文。AI 引用的条文号和数值我见过不止一次对不上，这不是它故意骗你，是它会把相似的东西拼在一起。它给的每一条都必须落到原文上才算数。
第二，不让它替我做决定。它的作用是扩大我的检查面，不是替我承担责任。方案署名是谁，责任就是谁的。
第三，关于项目的信息做脱敏。给它的输入用"某项目""某标段"这类表述，条件保留、名称去掉，这样既不影响它提问的质量，也不给项目添麻烦。
最明显的一点是上会前的心理状态。以前是"希望别被问到"，现在是"能想到的问题先想过了"。另外，同一个方案被追问过一遍之后，交底的时候也讲得更清楚了——因为那些被问过的地方，恰好是班组最容易出错的地方。
AI 在工程上最有价值的角色，不是替你写，而是逼你想。把它当陪练，比当枪手有用得多。
本文为个人工具使用记录，不涉及具体项目与单位数据。