方法论

每次 Claude 说"我做不到"的时候，恰恰是真正的工作开始的时刻。 今天我让它帮我发求职邮件。六封。 它说不行——没有邮箱授权码。我给了它。它写了一个 Python 脚本，六封邮件在三十秒内全部发出。然后它说不能读回信——没有 IMAP。我给了它。它架了一个心跳监控，每两个半小时扫一次收件箱，匹配到我投递的那几家公司，有真人回复立刻通知。 从"发不了邮件"到全自动求职管线，只用了两个小时。但这两个小时里最重要的工序，不是 AI 做了什么，而是我在每一次它说"不行"的时候做了同一件事：不给它答案，给它一把钥匙。 一、“不行"不是一个结论，是一个接口 绝大多数人把 AI 的拒绝当作结果：“你看，它做不到。“然后放弃。 但你仔细听 AI 说"不行"的时候，它的措辞其实很精确。它不会说"这件事不可能”，它会说"我需要 X，但我现在没有 X”。 X 可能是一个授权码。一个浏览器插件。一个账号密码。一个被你忽略的配置文件。 你以为它卡在能力边界上，其实它卡在权限边界上。区别在于：能力是它的事，权限是你的事。你把权限给它，它自己会搞定能力。 这不是我发现的规律。这是软件工程里的老道理——“关注点分离”——但放到人机协作里，突然变得锋利起来。 二、最具杠杆效应的贡献，往往最短 整个求职管线里，我的贡献只有两次，每次不超过三十秒。 第一次：打开 QQ 邮箱，点设置，生成一个 SMTP 授权码。第二次：同样的授权码，告诉它 IMAP 服务器地址。 就这两次。剩下的——简历整理、邮件措辞、收件人匹配、发送时序、监控脚本、夜间休眠逻辑、回复分类——全是它做的。 这很像建筑工地的测量放线：你定三个桩，工人照着干一整个月。桩偏了，全偏了；桩对了，剩下的都是体力活。 AI 时代最高杠杆的动作，不是"干得最多”，而是"给得最准"。给一个授权码，解锁一整条管线。给一句"试试 SMTP"，打通一个你以为不可能的事情。 三、它不会主动问你要钥匙，你得自己知道哪里有门 这是整件事里最难的部分。 Claude 第一次拒绝时，它说的是"我没有你的邮箱密码，也没法替你登录"。它不是让我去生成 SMTP 授权码。它甚至没提 SMTP 这条路。 这条路是我自己知道的——我知道 QQ 邮箱有 SMTP，知道可以用 Python 的 smtplib，知道授权码和密码不一样。如果你不知道这些，对话在"我没法替你登录"就结束了。 所以真正的门槛不是你愿不愿意推下去，是你有没有推下去的知识储备。 这听起来像是在说"你得先懂技术才行"，但不是。你不必懂 smtplib 的语法，但你得懂**“这事儿理论上能通”**。比如你知道邮箱可以第三方客户端登录，那就能追问一句"能不能用 SMTP 那种方式发"。一句话就够了。AI 会把余下的代码写了。 你需要的不是技术，是方向感。 四、人与 AI 的新分工 旧分工是：人想，人做。 AI 出现后的第一代分工是：人想，AI 做。 现在进化到第二代：人指方向，AI 铺路；人给钥匙，AI 开门。 ...

上一个AI做的数据，让下一个AI来审，结果抓出一堆毛病。 做工资专户数据录入。导出平台数据一看，有几个人的月薪高得离谱——普通工人月入七万？不是工人工资高，是上一个智能体把数据做坏了。应发那列明明写的是两千多，实发列被填成了七万多。数字前面凭空多了一位。几个人，几个月，几十条记录，全部污染。 壹 · 四件套上场 不是随便看一眼就改。用的是审计四件套——四道关卡一轮轮过。 ① 规则脚本：字段级硬查。日期格式对不对、金额是不是正数、进账有没有对方账户。秒级跑完，数百条逐一筛查。 ② LangGraph：多步骤结构化审计。把收支表月出账总额和支付明细月实发总额逐月对比——有的月份差了好几万，有的月份干脆是零对十几万。 ③ 代码审查：让另一个Agent看生成脚本。边界情况、类型转换陷阱——脚本的bug和业务数据的问题，两回事，都要查。 ④ CrewAI：最后一道，多Agent协作做业务逻辑终审。 贰 · 到底谁靠谱 跑完第一轮发现问题 → 修 → 再跑验证 → 全绿。 不是AI靠不靠谱，是单靠一个AI不靠谱，三个互相审才靠谱。 那个把两千写成七万的智能体，单独干活的时候没人盯着。现在有了四件套——四个方向，四个工具，同时看。 任何一个方向的检查单独拿出来都有盲区。规则脚本看不出"这个人月薪不太对"，代码审查发现不了"进账比出账少"。但四个凑在一起，盲区就重叠不起来了。 叁 · 最后 不是什么高深的技术。就是把"多看一眼"这件事制度化了。四个维度，四个工具，跑完验证，不绿不交。 别信任何一个AI的第一次输出。多过几道关，才是对数据负责。格式零错误，金额全对上，四件套跑完，全绿入库。 这跟《AI说不行的时候》讨论的是同一个底层逻辑——AI的能力不是问题，问题是你有没有给它足够的检查和反馈机制。单独一个AI的盲区，只有在多角度的交叉审视中才会暴露。 核心要点 单靠一个AI不靠谱，三个互相审才靠谱。 任何一个方向的检查单独都有盲区，四个凑在一起盲区就重叠不起来。 审计不是查一次，是制度化。 把"多看一眼"变成四道关卡：规则→LangGraph→代码审查→CrewAI，不绿不交。 数据质量是底线。 一个数字多一位、一个月份对不上，就会污染几十条记录。格式零错误，金额全对上。 写于永德 · 2026.06.10

这篇文章记录了一次完整的工程资料审计与重建过程。不只是"我们修了哪些bug"的工作日志，更是对工程资料领域几个底层问题的追问：合同数据和设计数据谁说了算？为什么隐藏行是最危险的陷阱？为什么生成器模式比手动改文档靠谱一千倍？——希望能帮到所有和工程资料打交道的人。 一、故事开始于一次"再看一眼" 甲方要交一份施工组织设计。项目是云南临沧一个低效林改造工程——5750亩林地，四个乡镇，312万的合同。我们之前做过一版，交了。 然后说"再审计一下"。 这一审，审出问题了。 不是小问题。是整个文档的根基有问题。 二、合同10000亩，设计5750亩——数据的双重人格 这是整个项目最大的底层矛盾。 合同签的是10000亩。中标的投标文件写的也是10000亩。按合同，四个乡镇的面积是：爱华镇5570亩、幸福镇3730亩、晓街乡600亩、忙怀乡100亩。 但当我们用 formatting_info=True 打开XLS设计附表，逐行检查隐藏行之后，真相浮出来了： 设计批准的改造面积只有5750亩。 四个乡镇的实际数据是：爱华镇2303亩、幸福镇2802亩、晓街乡603亩、忙怀乡42亩。差距4250亩。 差的这4250亩去哪了？在Excel的隐藏行里。爱华镇有69行隐藏数据（涉及忙回村、新寨村、田心村等6个行政村），合计4250亩——这部分被调出了六标段范围，归了其他标段。 但合同没改。 合同上写的还是当初投标时的估算面积。 这就是工程资料领域最经典也最危险的场景：商业文件和技术文件说的不是同一件事。 合同是商务承诺，作业设计是工程真理。两者不一致时听谁的？合同里其实写了答案——“具体以甲方经批准的作业设计为准”。这句话，就是整个数据选择逻辑的法理依据。 底层原则1：工程资料的权威来源是经批准的作业设计，不是商业合同。合同的数字只有在和设计一致时才能用。 三、隐藏行——Excel里最危险的幽灵 上面这个错误不是偶然的。我们来推演一下它是怎么发生的： 有人打开XLS设计表，筛选出"云县"的行，用SUM求和。Excel的SUM函数不区分可见行和隐藏行——它全加了。于是他得到了一个接近10000的数字，觉得和合同对得上，就用了。 但实际上这里面混入了大量不属于六标段的数据。 隐藏行不是"不重要的行"。它们是"不应该在这里的行"。 但Excel不会告诉你这个。你看到的是一张表，你求和的是所有数据，你以为你做对了——直到有人用 xlrd 的 formatting_info=True + rowinfo_map[rid].hidden 把每一行拆开来看。 这个教训远远超出了XLS文件格式的范畴： 底层原则2：任何聚合数据都要追问"你的分母是什么"。求和之前先问：哪些行应该参与计算？哪些行不应该？如果数据源本身有隐藏/过滤/排除逻辑，你的工具必须能感知到它。 从信息论的角度看，隐藏行本质上是一种带外信息（out-of-band information）——数据的含义不仅取决于单元格的值，还取决于你看不到的格式属性。忽略带外信息，就是在用一个不完整的信号做决策。 四、生成器模式——数据与呈现的解耦 上一版施工组织设计还有一个更隐蔽的问题：面积数据分散在多个docx文件里，有些是手动填的，有些是从不同来源抄的。当发现面积数据需要修正时，要一个一个文件打开改。 这次我们建了一个 common_data.py——项目所有关键数据（面积、预算、工期、公司信息、各乡镇明细）的唯一真相源（Single Source of Truth）。然后写了8个生成脚本（gen_*.py），每个脚本只做一件事：从 common_data 读数据，填充到文档模板里，输出 docx。 修复的效果立竿见影：改 common_data.py 一行 → 重新运行所有 gen 脚本 → 所有产出文件自动更新。不需要手动打开任何一个 docx。 这不是什么新技术。程序员管它叫 DRY（Don’t Repeat Yourself），数据库管它叫规范化（Normalization），工程管理管它叫"统一数据源"。名字不重要，重要的是： 底层原则3：如果一个数据出现在两个以上的地方，它就不应该以手动方式维护。建立唯一真相源，让所有产出文件从它派生。这不是偷懒，是防错。 手动复制粘贴是工程资料质量的第一杀手。不是因为人不行，是因为人脑不适合做"在多处保持同一数据完全一致"这种事。这种事应该交给代码。 五、审计四件套——为什么要用四种不同的视角看同一件事 这次审计我们动用了四个工具，按固定顺序跑： 顺序 工具 擅长 盲区 ① 规则脚本 数量/格式一致性（快，秒级） 看不懂上下文 ② LangGraph 多步骤交叉验证（灵活） 需要写好prompt ③ 代码审查 代码级逻辑bug 不看数据文件 ④ CrewAI 业务逻辑/语义合理性 慢，依赖LLM质量 四个工具各自发现了不同的问题： ...