夜雨聆风封面图Prompt：A minimalist desk scene with a glowing green Excel spreadsheet on monitor, alongside a dimmed code editor, warm ambient lighting, wooden desk, coffee cup, calm studio atmosphere, professional workspace photography style, deep greens and warm ambers. no text, no words, no letters, no characters
我见过最荒诞的一幕：
一个刚入行两年的程序员，花了两周时间，用React + Node.js + MongoDB搭了一个"员工请假审批系统"。功能齐全：申请、审批、流转、通知——麻雀虽小五脏俱全。
系统上线一周后，公司换了套OA。
那个系统，永远停留在了V1.0。
两周的开发时间，换成一张Excel表格，加上几个数据验证和条件格式，半小时搞定。
这不是段子，是每天都在发生的事。
我甚至见过有人自己写了一个"开票记录系统"。前后端分离，数据库设计，API接口，全部自己撸。问他为什么不用Excel？他说："Excel太不专业了。"
可他做的东西，本质上就是一个带筛选功能的表格。
这事得从程序员的"底层操作系统"说起。
你学的是编程，你的核心竞争力是写代码。遇到任何问题，你的第一反应就是："我能写个程序解决它。"
这个思维本身没错。但问题在于——不是所有问题都值得写代码。
我给你算笔账：
写一个小型管理系统的隐性成本：
- • 搭建：2周开发 + 1周测试
- • 维护：每次需求变更，改代码、改数据库、重新部署
- • 技术债：路由、鉴权、错误处理——每一样都可能出bug
- • 交接成本：别人离职你得接手，新人看不懂你的代码，又没文档
那张Excel表格的成本呢？
- • 创建：30分钟
- • 修改：双击单元格，重新排序
- • 交接：发个文件就行
- • 试错：删了重来，不心跳加速
一个是重型工程机械，一个是瑞士军刀。
你非要用挖掘机开啤酒，那只能说明你手上只有挖掘机，以及你享受那种"专业"的感觉。
但专业不是目的，解决问题才是。
Excel能做什么？比你想象的要多
很多人对Excel的认知还停留在"做表格+求和"。这是天大的误解。
Excel能做的事情清单，比你想象的要长：
数据录入与管理
- • 小型客户管理系统（CRM）：筛选、排序、条件格式，超期未付款的客户自动标红
- • 库存跟踪：库存+在途+预警线，公式一拉，一目了然
- • 项目排期：画个甘特图模板，几行条件格式就出来了
数据处理与分析
- • 数据清洗：去重、格式统一、模糊匹配，不需要写SQL
- • 财务对账：两列数据直接对比，差异自动标红
- • 销售报表：透视表拖一拖，按区域、时间、品类自由切片，比SQL还快
流程协同
- • 团队任务看板：条件格式+下拉菜单，一秒看懂谁在做什么
- • 预算跟踪：实际 vs 预算对比，超支直接预警
- • 排班表：日期、人员、班次交叉，改一个格子全表联动
一个真实案例：
我认识一个做跨境电商的朋友。他所谓的"ERP系统"就是一张Excel表。
这张表干了四件事：
- 1. 供应商管理——谁供了什么货、多少钱、交期
- 2. 库存跟踪——当前库存、在途、库存预警
- 3. 订单记录——已下单、已发货、已签收
- 4. 毛利计算——自动算每个SKU的净利润
他靠这张表撑到了月流水50万。
技术负责人来问他："什么时候上正经系统？"
他说："等月流水500万再说。"
这是我认为一个程序员该有的觉悟：能被Excel满足的需求，就别用代码解决。等它长到Excel撑不住了，再写代码也不迟。
Excel不能做什么？
说了这么多，我也得说清楚——Excel不是万能的。
这些问题，别指望Excel：
需要多人实时协作修改
- • 两个人同时打开一个文件，后保存的那个会把前面的数据覆盖
- • 用SharePoint/OneDrive在线编辑？数据量大一点就卡死
- • 没有版本管理，谁改了什么都查不到
数据量太大
- • 超过几十万行就开始卡
- • VLOOKUP在十万级数据表上，每次刷新等一分钟
- • 超过104万行，直接罢工
需要完整的事务逻辑
- • 一笔订单涉及：扣库存、扣余额、生成物流单、更新报表
- • 中间任何一个环节出错，整个流程都得回滚——Excel做不到回滚，靠人眼排查
需要安全性
- • 没有用户权限控制。谁都能改
- • 没有操作日志。谁删了数据？不知道
- • 一个误删，Ctrl+Z也不一定救得回来
判断标准就一句话：
如果这个系统死机一小时，公司会不会停产？
不会 → 用Excel。
会 → 该上系统了。
什么时候该用代码？
我有个"三问法则"，写代码之前先问自己三个问题：
第一问：这个需求会变多少次？
- • 答案"超过5次"——用Excel，改起来快，双击就行
- • 答案"稳定的核心流程"——可以考虑写代码
第二问：用这个的人有几个？
- • 1-5个人 —— Excel足够
- • 5-20个人 —— Excel+共享文档，勉强能撑
- • 20人以上 —— 真的该考虑系统了
第三问：出错会死人吗？
- • 会死人（医疗、金融核心系统）—— 必须代码，必须审计
- • 不会死人（内部管理、报表、统计）—— Excel是你的好帮手
三问都指向代码，那就好好写。
但只要有一个指向Excel，就先用Excel。
我知道这话说出来得罪人。多少程序员靠"一切皆代码"来建立身份认同。但事实就是——代码不是银弹，Excel不是耻辱。
不懂Excel的程序员，和不懂SQL的程序员一样，都在假装自己很专业。
铁三角法则：Excel · 低代码 · 纯代码
现在你还多了一个选择：低代码/无代码平台。
最佳实践是这样的组合：
Excel： 个人/小团队的临时需求、数据探索、一页纸就能管完的事
低代码（Airtable / Notion / 飞书多维表格）： 需要多人协作、复杂权限、但还不想写代码的场景
代码： 核心竞争力、对外产品、高并发、复杂商业逻辑
这三个工具不是替代关系，是互补关系。
关键就一条：不要因为"我是程序员"就跳过前两个选项。
很多人嘴上说"效率至上"，实际上写代码只是为了让自己爽。
代码写得爽不爽不重要，问题解决得快不快才重要。
写代码的快感，不是真正的效率
很多程序员抗拒Excel，理由很一致：
"写Excel太low了。"
"这不符合工程规范。"
"Excel的性能太差了。"
我完全理解。写代码是舒服的——IDE提示、语法高亮、类型检查、Git版本控制、单元测试覆盖。
但舒服不等于高效。
真正高效的工程师，在打开编辑器之前，会先问自己一个问题：
"这个问题，值得我花一整天写代码来解决吗？"
如果答案是"不值得"，他关掉编辑器，打开Excel，半小时搞定。
然后他去做下一件更重要的事。
效率哲学的核心就一句话：
用最省力的工具解决当前的问题，而不是用最擅长的工具。
你擅长用锤子，不代表所有问题都是钉子。你擅长写代码，不代表所有需求都需要系统。
Excel带来的不是工具选择问题。
Excel带来的是认知问题。
当你真正意识到"Excel能搞定"的那一刻，你的视角变了。你不再是一个"只会写代码的程序员"——你变成了一个"会用所有工具解决问题的工程师"。
代码是你的武器，但不是唯一的武器。
高手和新手最大的区别，不是代码写得更好。而是高手知道什么时候不写代码。
有一句话我一直记得：
"对于手里只有锤子的人来说，所有的东西看起来都像钉子。"
但真正的工匠，知道工具箱里还有扳手、螺丝刀、钳子。
Excel就是那把最好用的螺丝刀。
下次打开编辑器之前，先打开Excel。
如果是10分钟能搞定的事，别花10天去写代码。
省下来的时间，去看需求、去聊客户、去想想那些真正值得写的东西。
那才是你作为程序员最值钱的能力。
不是写代码。
是做选择。
