有了 AI，还要学编程吗？试着用五种思维看同一个问题
这篇文章的起点，是一张标题为“五种顶级思维”的手写笔记。它把哲学、经济、政治、军事和历史放在一起，分别对应追问本质、权衡资源、理解权力、组织行动和借鉴过去。
这个分类很容易记住。但笔记里还有一个更强的判断：一个人同时具备这五种思维，才能到达社会金字塔的顶端。
我更愿意保留前面的提醒，放下后面的成功承诺。人生结果还受资源、环境、机会和运气影响，很难用五种思维解释。即使把五个名词背下来，遇到问题时也未必知道怎么用。
所以，我想换一种写法：拿一个具体问题，让这五个视角各问一次，再看看答案会发生什么变化。
这个问题就是：有了 AI，还要学编程吗？
先说明边界：下文借用的是五门学科提供的观察角度，并不是对这些学科的完整定义。文中的账单整理项目也是用于推演的假设案例，不是实际项目复盘。
一、哲学思维：我到底在学什么，为什么学？
“还要不要学编程”看起来是一个选择题，其实藏着几个不同的问题。
是要不要记住语言语法？要不要成为职业程序员？还是要不要拥有把想法变成工具的能力？
这几个问题的答案不会完全相同。
如果目的只是偶尔处理一个表格，把完整的后端开发体系从头学一遍，投入可能过大。如果目的是进入软件行业，只会让 AI 生成一段代码，又不足以说明自己能维护一个长期运行的系统。
哲学视角在这里首先帮助我们澄清概念和目的。“AI 能写代码”只回答了实现过程中的一部分，没有自动回答“什么值得做”和“怎样才算做对”。
假设我们想做一个账单整理工具。AI 很快生成了上传文件、分类、汇总和图表的页面，看起来功能齐全。
但我们真正需要的是什么？
也许只是每个月把不同来源的账单合并，排除重复项，看清支出构成。这样，第一版可能只需要读取几个文件，输出一份可核对的汇总表。漂亮的仪表盘可以稍后再做。
这里最先需要学会的，是把目标说清楚：输入是什么，输出是什么，哪些情况会让结果失真，怎样验证结果。
因此，我对这个问题的第一个回答是：是否学习，以及学到什么程度，应该从用途出发。不要因为工具会生成代码，就把“理解问题”和“编写代码”一起从学习计划里删掉。
二、经济思维：节省了哪种成本，新增了哪种成本？
假设 AI 帮我们把第一版脚本写得很快。最容易产生的判断是：编程已经变便宜了，学习编程的收益也就下降了。
这里少算了一笔账。
软件的成本包括生成、检查、修复、运行和长期维护。初稿生成时间缩短，只说明其中一个环节变快，不能直接推导出总成本按相同比例下降。
还是那个账单工具。如果它把一笔退款当成新的支出，汇总结果就可能出错。界面越像成品，我们反而越容易直接相信它。
此时，需要有人核对数据，定位问题，修改规则，再确认旧功能没有受影响。如果每次都只能把报错原样贴给 AI，反复尝试直到页面能打开，前面省下的时间可能在后面花回来。
经济视角关心的是资源、激励和机会成本。对个人来说，可以先问三件事：
- 这项任务会重复发生吗？重复得越多，学习和自动化的投入越容易摊薄。
- 一次错误的代价有多大？整理个人资料和处理真实资金，需要的验证强度不同。
- 我应该自己掌握哪一部分，哪一部分适合交给工具或专业服务？
这些问题也提醒我们，不必为了证明自己有技术能力，什么都从头实现。如果一个现成工具已经可靠地满足需求，购买或使用它可能更划算。
我的判断是：当代码初稿更容易获得时，定义需求、判断结果和维护系统就更值得关注。不过，这是一种对能力投入的判断，不能直接当成对工资或就业人数的预测。
学习的重点可以调整，验证结果所需的理解不能省。
三、政治思维：谁决定规则，谁承担责任？
提到政治思维，人们很容易想到“识人”和“博弈”。放到技术选择里，我更关心规则、权利和责任怎么分配。
一个工具能不能用，不只取决于功能，还取决于它允许我们做什么，以及我们对它有什么控制。
如果把账单交给一个在线 AI 服务，需要考虑：数据会经过哪些环节，服务条款允许怎样处理，结果能否导出，平台变化后是否还有替代路径。具体答案需要查看所选服务的实际设置和条款，不能凭“云端”或“本地”两个标签下结论。
如果这个工具开始供团队使用，还会出现新的问题：谁能看原始账单，谁能修改分类规则，谁批准上线，出了差错由谁处理？
这些问题往往比“选哪种语言”更早影响方案。
例如，假设团队约定原始账单只在受控设备上处理，那么让 AI 协助开发时，就可以先用虚构数据表达文件结构和计算规则。产品设计也要围绕这个约束展开，而不是做到最后才发现方案无法使用。
这里的政治视角，并不鼓励把协作理解成权术。它帮助我们看清：一个技术决定会影响谁，谁有决定权，相关的人是否知道并接受这些安排。
因此，学习编程还有一层价值：增加自己理解系统和选择方案的能力。哪怕最后仍然使用平台服务，能读懂数据流、接口和权限，也有助于判断依赖是否值得接受。
四、军事思维：时间有限，应该先完成哪一步？
前面三个角度能帮助我们判断方向，但方向清楚以后，还得行动。
这里借用军事视角中的目标、资源、情报和反馈来组织行动。学习和协作不必被理解成战争，更不需要把别人当成敌人。
对一个每周只有几个小时的人来说，“把编程全部学完”不是一个能执行的计划。先解决一个小问题，更容易建立学习和反馈之间的联系。
账单工具可以这样推进：
- 缩小范围。 第一版只支持一种文件格式，输出分类汇总和无法识别的记录。
- 建立基准。 准备一小份虚构账单，人工算好预期结果，包含正常支出、退款和重复记录。
- 让 AI 协助实现。 分别完成读取、清洗和汇总，每一步都能看到中间结果。
- 解释关键路径。 自己能说清楚金额怎么转换、退款怎么处理、重复项按什么规则识别，再继续扩展。
- 保留退路。 在输出经过核对之前，不覆盖原始文件，不自动修改真实账目。
这份计划的重点是让每一步都能判断对错。否则，一个步骤接一个步骤地生成代码，最后得到的可能只是更大的不确定性。
学习内容也可以随项目逐步补上：先理解变量、条件和循环，再理解文件、数据结构和异常处理；需要长期保存记录时，再学习数据库；需要多人访问时，再处理部署和权限。
这样的顺序适合以解决个人问题为目标的入门者。要承担职业开发工作，还需要系统补齐工程基础，不能把一个小工具跑通当作已经具备全部能力。
五、历史思维：过去的经验能解释多少？
谈到 AI 编程，常见的一种类比是：过去有了高级语言、框架和低代码工具，程序员也没有因此消失，所以这次也一样。
另一种说法则是：这次完全不同，过去的经验没有参考价值。
我觉得两种说法都跳得太快。
高级语言让人不必直接处理许多底层细节，框架封装了常见的软件结构。这些变化提醒我们：工具可以改变日常工作内容，我们应该区分长期需要的理解与可以交给工具的操作。
但这种类比也有边界。传统编译器按照既定语言规则工作，生成式 AI 可能给出看似合理、实际不符合需求的实现。它可以跨越多个步骤生成代码，也可能在多个步骤里重复同一个错误假设。
因此，过去的工具变化可以帮助我们提出问题，不能替我们证明这一次的结果。
比如：开发效率提高后，会不会出现更多原来不值得开发的小工具？哪些任务减少，哪些验证和维护任务增加？进入行业的门槛和承担责任的门槛，会不会向不同方向变化？
这些都值得持续观察。但仅凭历史类比，还无法准确预测未来的岗位数量、薪酬分布和变化速度。
对个人而言，比押注一个确定的行业结局更稳妥的办法，是持续做小项目，检查自己完成任务的能力有没有提高，再根据反馈调整学习投入。
六、把五个角度放回同一个决定
现在，再回到“有了 AI，还要学编程吗”。
对假设中的账单项目，五个角度带来的判断可以整理成一张表：
| 视角 | 最先要问的问题 | 对方案的影响 |
|---|---|---|
| 哲学 | 我到底想解决什么？ | 先做可核对的汇总，暂缓仪表盘 |
| 经济 | 值得投入多少，错误代价多大？ | 把核对和维护时间计入成本，先比较现成工具 |
| 政治 | 谁决定规则，数据和责任怎样分配？ | 明确处理范围、访问权限和平台依赖 |
| 军事 | 现有时间和能力支持哪一步？ | 从一种格式、小样本和明确预期开始 |
| 历史 | 过去的经验哪里适用，哪里不同？ | 借鉴工具变化的经验，同时重新验证 AI 的输出 |
五种视角也不总会得出同一个答案。为了减少平台依赖而选择本地方案，可能增加维护成本；为了加快上线而使用现成服务，可能减少可定制空间。这时仍然要根据目标作取舍，不能指望框架替我们做决定。
如果只是偶尔使用现成软件，可以不以成为程序员为目标。如果希望稳定地制作和维护自己的工具，就值得学习足以理解与验证结果的编程基础。如果选择职业开发，则需要在 AI 使用能力之外，继续建立系统设计、调试和协作能力。
对我而言，值得追求的是：借助 AI 做出东西以后，仍然知道它为什么这样工作，出了问题应该从哪里查起。
七、下次做决定，先写下这五个问题
这套方法也可以用在投资、创业、工具采购或团队管理上。不过，不必每个小决定都完整分析一遍；对投入较大、影响较久、后果较难撤回的决定，它更有用。
可以先写下：
- 目的： 我希望得到什么结果，怎样才算完成？
- 代价： 除了眼前投入，还要付出哪些时间和维护成本？
- 规则： 谁会受影响，谁能决定，谁负责后果？
- 行动： 最小可行的一步是什么，怎样验证，什么时候停下来？
- 经验： 过去有哪些类似情况，这一次的关键差异是什么？
这些问题的作用，是把原本藏在直觉里的假设写出来。能核实的就核实，暂时不知道的就保留不确定性，然后做一个与现有证据相称的决定。
回到那张手写笔记，我愿意保留的提醒是：遇到复杂问题时，多换几个角度看。至于它是否让一个人走到“顶端”，没有保证。能帮助我们把目的想清楚、少漏算一笔成本、把第一步做扎实，已经值得使用。
💬 评论