个人技术随想:工具不是分水岭,交互模式才是;Cursor 和 Claude Code 都能写代码,但「一次性写脚本」和「渐进式对话处理」之间,隔着一层对「任务拆解」的理解。
一、问题背景:755台配电箱的公式噩梦
之前,我姐扔过来一个配电箱报价Excel,里面755台设备,元件小计和单台小计的SUM公式几乎每台都不一样。有的范围少算两行,有的顺序错乱——母排跑到了二次及辅件后面,成套费和税费的位置也不对。
先说说我最开始想到的笨办法——纯手动改。
打开Excel,一台一台看:这台的元件小计SUM范围到第几行?那台的单台小计有没有包含成套费?母排和二次及辅件的顺序对不对?每台设备底部有7行要核对,755台就是超过5000行数据。
我试着改了十几台,每台至少要:点开公式栏 → 核对SUM范围 → 拖动调整行号 → 检查顺序 → 复制格式。平均一台3分钟,755台就是37个小时。而且这还不包括——改到第200台时发现前面几十台的公式规律其实不一样,要返工;删了几行空行后,后面所有设备的公式行号全乱了,得重新来。
手动改Excel的噩梦不是"量大",而是"牵一发而动全身"。 你改了一台,可能影响了下一台的行号;你统一了规律,又发现有些设备是特例。更可怕的是,你根本不敢确定改完的是对的——眼睛看花了,SUM(G6:G15)和SUM(G6:G16)只差一个数字,却能让总价差几千块。
我最初的方案很直接:开Cursor,让AI写Python脚本,用openpyxl批量跑。
但问题不在Cursor,而在模式。我让Cursor一次性生成完整脚本,跑完发现:
文件是 .xls老格式,AI选的xlrd读不了公式格式复制时背景色全丢 写回文件后公式变静态值 改代码→重跑→再看结果,循环了五六轮
折腾了半天,我意识到:不是AI写代码的能力不行,是我一次性把整件事扔给它,中间出了偏差没法及时纠偏。
二、转折点:从「批处理脚本」到「渐进式对话」
后来我换了思路——不改工具,改交互方式。用Claude Code,把需求拆成一步一步的对话。
关键变化不是谁写的代码,而是什么时候写、怎么验证:
核心区别很清晰:批处理模式是「写完后祈祷」,渐进式模式是「每一步都确认」。AI写的代码片段是一样的,但人对过程的掌控感完全不同。
三、实战过程:为什么不能一次性说完
第一步:让AI「看懂」文档结构
我没有用文字长篇描述表格结构——之前试过,效率低还容易漏细节。而是直接截图+一句话:
我:[截图] 这是"明细沈开6.5"sheet第一台设备的信息, 你看看这个表格里面有多少台设备?AI:识别到755台。每台底部有「母排、二次及辅件、 元件小计、柜体、税费、成套费、单台小计」7行。 但顺序乱的——有的母排在二次及辅件后面。截图的价值:不用费脑子去描述"第几行是什么、列怎么对应",直接把图甩给AI,它自己看。准确率比纯文字描述高得多——尤其对这种行列交错的复杂表格。
这一步的另一个好处:如果是语音输入,直接对着截图说"这台柜子顺序不对",比打字描述快三倍。AI看图+听语音,上下文一次对齐。
第二步:第一台设备的规律
我:看看第一台设备的公式规律。AI:元件小计G = SUM(G6:G15),包含到二次及辅件行; 单台小计G = SUM(G16:G19); 二次及辅件G = I16(引用I列的元件小计)。我截图确认了——对的。第一台是对的,后面的都按这个来。
第三步:先处理一台,验证正确再批量
我没有说"按这个规律处理全部755台",而是:
我:先处理序号为9的设备,调整行的顺序。AI做完,我打开文件检查——顺序对了,但背景色丢了。原因是xlutils写xls时覆盖格式。这个坑如果一次性批量处理755台,后面根本没法回退。
换成xlsx格式,用openpyxl重新做单台验证,背景色保留成功。然后再说:
我:确认没问题了,处理剩余的。第四步:循环引用——AI走偏的典型场景
AI批量改了190台元件小计的SUM范围,把结束行统一扩到「二次及辅件行」。Excel打开,弹窗——循环引用。
我:为什么显示循环引用?AI:因为其他设备的二次及辅件G列公式是 `=G{元件小计}*0.08`, 直接引用元件小计G列。你把SUM范围扩到包含二次及辅件, 就形成了:二次及辅件 → 引用元件小计 → SUM包含二次及辅件。这是普通人最容易栽的地方。如果一次性让AI处理全部,看到循环引用只会懵。但因为我是一台一台验证过来的,知道前面正常,问题出在公式逻辑冲突上。
我选了方案B:二次及辅件统一改成 =I{元件小计行},和第一台保持一致。AI执行,再验证——0循环引用。
第五步:空行清理——又一个渐进发现的问题
我:处理完了,但我看到有空行。AI:发现226个空行,大多在封板和母排之间。删除后需要 全局调整公式行号引用。这又是另一个独立子任务。如果一次性给AI"修Excel+删空行+统一公式",空行删除导致行号变化的问题可能被淹没在一大堆输出里,根本发现不了。
四、三个真实难点:对普通人的门槛在哪
难点一:文件格式转换——AI会选错库,需要人判断
文件是.xls,AI第一反应用xlrd/xlwt。但实际处理发现:
xlrd2.0不读公式xlutils复制格式丢背景色写回 .xls公式变静态值
有经验的做法:手动把文件另存为.xlsx,告诉AI用openpyxl。
这个判断没有编程基础的人做不出来。普通人看到AI报错,只会反复说"再试试",而不是想到"换个文件格式"。
难点二:任务拆解——不能一次性给完需求
如果我把完整需求一次性给AI:
"帮我修这个Excel,要求:1)统一底部7行顺序 2)元件小计SUM范围统一到二次及辅件行 3)单台小计SUM统一 4)删除空行 5)调整所有公式行号 6)保留格式和背景色"
AI大概率会:
先写一个超长的脚本 跑完出问题 改来改去,每次修改都可能引入新问题 用户耐心被磨灭,觉得"AI不行"
不是AI不行,是沟通方式不对。渐进式的本质,是把一个复杂任务拆成AI能稳定执行的子任务,每步都给人验收的机会。
难点三:判断AI是否走偏——需要工程直觉
我姐不懂编程。如果她来操作:
xlrd处理xls | xlrd2.0不支持公式,应该转xlsx | |
G*0.08公式冲突 | ||
xlutils的问题,不是公式问题 |
AI替代的是打字和初稿,不替代「验收」。普通人能学会的是「怎么用AI」,但「怎么判断AI做得对不对」需要理解Excel公式的基本逻辑——这比学Python语法简单,但也不是零门槛。
五、沉淀:为什么一定要做成Skill
处理完这个文件后,我把整个流程写成了 Skill 文件excel-cabinet-repair。
不只是为了省打字。是为了避免每次重新「对齐上下文」。下次遇到类似的配电箱报价表,不需要再解释:
"什么是母排" "元件小计SUM范围应该到哪里" "空行删除后公式怎么调"
用户:帮我修这个配电箱文件,按之前的规律。AI:加载 excel-cabinet-repair Skill → 自动执行:识别设备 → 检查顺序 → 统一公式 → 删空行 → 验证Skill的本质是「固化验证通过的流程」。不是Prompt的堆砌,是带着边界条件和注意事项的可执行知识。
六、结论:门槛降低了,但没有消失
| 核心能力 | |||
我的结论是:
LLM处理Excel对普通人门槛确实降低了——不需要记语法、不需要配环境、不需要调库。但这个门槛从「编程能力」转移到了「任务拆解能力」和「过程判断能力」上。
如果你愿意花半天理解Excel公式的基本逻辑,再用一周养成「渐进式交付、每步验证」的习惯,AI处理文档的效率比手动写脚本高一个数量级。但如果你期望「一句话丢给AI,完美结果直接出来」,那大概率会在第三轮报错时就放弃。
七、我的实操建议
先给AI看,不给指令:让AI先分析文档结构,确认它「看懂了」再下指令 第一台/第一页当样本:明确告诉AI「按这个规律处理后面的」,先做一台验证 每步只做一件事:不要一次性提三个需求,做完一个确认一个 接受迭代:第一次的结果大概率有问题,对话修正比重写脚本快 遇到报错先暂停:让AI解释原因,而不是直接说"再试一次" 做完做成Skill:把验证通过的流程固化,下次直接复用,不用重复抽卡
延伸阅读
excel-cabinet-repair Skill Claude Code 文档
(系列:DMR 工程实践、AI 协作模式。)
夜雨聆风