AI 时代，程序员该怎么理解"富在术数，不在劳身；利在势居"
AI 时代，程序员该怎么理解“富在术数，不在劳身；利在势居” 富在术数，不在劳身；利在势居，不在力耕也。 一、先说我的结论：在 AI 时代，正确使用 AI 不是把思考和责任交给它，而是让它处理重复、检索、整理和初稿，把问题定义、边界判断、结果验证和最后负责留在自己手里。我需要同时做目标设计者和成果验收者：先想清楚要解决什么，再让 AI 多想几种办法、多试几次，最后由我判断结果是否合格。这个顺序不能反过来：如果我连问题是什么、什么结果算完成都没有想清楚，就算 AI 很快生成了一大段代码，也只是把模糊变成了更难检查的复杂。带着这个结论再读这句话，会更容易看清它的意思。这句话出自西汉桓宽整理的《盐铁论·通有》，不是《韩非子》。原文讨论燕地的涿、蓟，赵地的邯郸等名都为什么富裕。它们不一定拥有最肥沃的土地，却处在交通要冲，货物、商人和消息从那里经过，远方的资源可以在那里交换。这里的“术数”不是一个人凭空想出的小聪明，而是经营、组织和交换的方法；“势居”也不是今天常说的追风口，首先是你处在什么位置，是否连接着货物、需求和交易。这个背景很重要，因为《盐铁论》并没有单纯赞美商业。贤良文学马上反驳：商业繁盛可能带来奢侈、逐利和农业荒废；后面的争论又回到盐铁、均输、平准，讨论国家要不要介入资源和交易。也就是说，这句话真正提醒我们的不是“不要劳动”，而是：财富不会按照体力和工时一比一地分配，分工、流通和位置同样会决定劳动能产生多大结果。我以前读到这句话时，很容易把它理解成“方法比努力重要”；现在我更愿意把问题再往前推一步：一个人的劳动，怎样才能不只完成一次任务，而是进入一套更大的协作关系，留下以后还能使用的东西。 二、放到程序员身上，“劳身”不只是敲键盘，也包括那些只能随着工时增加、任务结束就归零的工作：接一个需求、写一组接口、改一个页面、处理一次线上故障、给别人解释一次项目结构。这些工作当然有价值，没有它们系统不会运行，用户的问题也不会解决；但如果我的收入和影响力永远只取决于“今天完成了几个任务”，就会遇到一个很现实的上限：一天只有这么多时间，注意力也会疲劳。我自己处理重复问题时经常掉进这个循环：某个接口出错，我查日志、改代码、补测试，问题解决；过几周同类问题再次出现，我又从头查一遍。每次都很忙，但忙完没有留下什么，下一次仍然要拿当天的时间重新换结果。AI 把这个问题放大了。生成样板代码、补充测试、解释报错、转换接口格式，这些工作正在变快，也正在变便宜。如果我只把优势建立在“比别人多写一点普通代码”上，这部分优势很容易被工具追平。AI 首先压低的是“写出一段代码”的价格，不是“让一个系统可靠运行”的价格。后者还包括判断问题值不值得做、把模糊需求说清楚、处理旧系统的限制、验证生成结果、控制权限和成本，以及出了问题之后能够定位、回滚并负责。代码越容易生成，程序员越不能只证明“我能写出来”，而要证明“我知道为什么这样写、怎样确认它没有伤害原来的系统”。 三、我现在理解的“术数”，不是几个提示词，而是把一次解决问题的经验变成下一次可以重复使用的办法。比如我让 AI 修改一个功能时，不再只说“帮我改好”，而是先写清楚目标、不能改变的行为和验收条件，再让它给出两三种实现思路，说明各自的风险。我会多用 AI 去 try：试不同的拆分方式，试几组边界输入，试着找出自己方案里的漏洞；但这些尝试只是帮我扩大选择范围，最后仍由我判断哪种方案值得做，运行测试、查看差异、检查权限和回滚路径，再决定是否验收。这个流程看起来比直接生成代码慢一点，但它减少了我最怕的那种返工：代码已经写了很多，最后才发现需求根本没有定义清楚。类似地，一个故障处理完以后，我可以只说“已经修好了”，也可以留下排查路径：先看哪类日志，哪些指标能排除某种原因，什么情况需要回滚，修复后补哪一条测试。下一次遇到同类故障，这份记录就不只是文档，还能成为人和 AI 都能照着执行的步骤。再往前一步，我会把重复的接口规范、错误处理、权限检查和测试方式整理成模板或自动检查，让团队其他人也能用。第一次做这些整理确实会增加时间，但第二次、第三次开始，我不必重新解释、重新试错、重新检查。这才是我理解的“术数”：不是让自己看起来更聪明，而是让一件事情下次更容易做好，并且不再完全依赖某个人临场发挥。AI 最适合参与的，也正是已经想清楚的流程：生成重复部分、收集失败案例、补齐检查项，而不是替我决定问题是什么。 四、“势居”对程序员的意义，是不要永远停在代码生产的末端，而要逐渐靠近问题、数据、使用者和运行结果。我以前也把“势”理解成热点：哪个模型发布了就赶紧试，哪个概念流行了就做一个 Demo。但热点往往只带来注意力，不一定带来位置。一个更实际的判断是：我是否知道用户每天反复遇到什么麻烦？是否看过真实输入和错误案例，而不是只拿几个漂亮样例测试？我写的东西是否进入持续运行的系统，而不是演示页面？上线后出了问题，我是否能看到结果并继续修改？比如临时帮别人总结一份日志，完成一次就结束；如果我长期处理同一类系统的日志，知道哪些错误最常见、哪些指标最有用、哪些修复会影响其他服务，再把这些经验做成团队每天使用的工具，我接触到的就不只是一次任务，还有问题的历史、数据的变化和用户的反馈。真正的“势”不是你站在风口上，而是一个重要问题长期存在时，别人会因为你的经验、工具和判断而经过你。但我也不想把这句话写成“只要努力就能占据有利位置”。一个人能不能接触用户、拿到数据、决定方向，还取决于组织、平台和资源。不是每个程序员都能马上拥有入口；有些人一开始就在交通要道，有些人只能按别人的订单计时。因此更诚实的问法是：我是否比半年前更接近问题源头、更了解运行结果，是否积累了一些可以带走的经验，而不只完成过一串无法复用的任务？如果一个 AI 机会只让我承担更多重复劳动，却不让我接触问题、反馈和决策，那么它可能只是把旧的劳身换了一个更时髦的名字。不能因为“势居”听起来有道理，就把所有结构性的差距都解释成个人不够努力。 五、如果把这句话落到我自己的工作安排里，我不会先问“下一个最热的 AI 工具是什么”，而会先看最近一个月的任务记录：哪些工作出现次数最多，哪些地方最容易出错，哪些问题每次都要重新解释。然后选一个结果容易检查、出错代价不高的任务，先由我写清楚目标和验收条件，再让 AI 多给几种方案、多试几组输入、多模拟几种失败情况；我不把第一次生成的结果当答案，而是把它当一个可以继续追问、修改和推翻的草稿。连续使用几次后，重点记录它在哪些地方误判，以及我自己的目标是否写得不够清楚；最后把稳定下来的步骤整理成脚本、测试、说明或团队工具，并找真正使用它的人确认是否减少了麻烦。这个顺序对我很重要，因为一个只在顺利样例里工作的 AI 流程没有多少价值，真正有用的东西往往来自失败、误判和人工接管。回到原句，我的理解不是“努力没用”，也不是“找到风口就能成功”，而是：如果劳动只完成一次任务，回报容易被时间限制；如果劳动被整理成方法、工具、系统和信任，才有机会被重复使用；如果我只站在代码生产的末端，容易被比较和替代；如果我逐渐靠近真实问题、用户反馈和系统结果，就更可能形成自己的位置。先把基本功练好，再把重复工作交给 AI；先在真实项目里待久一点，再判断自己的位置；先积累能复用的东西，再谈所谓的风口。给读者的启示：1. 多思考目标、边界和验收条件；2. 多尝试，不把 AI 的第一次答案当结论；3. 多用 AI 去 try，让它提供方案、反例和试验；4. 自己做目标设计者和成果验收者；5. 让 AI 放大判断，而不是替代判断，生成越快，越要重视测试、监控、回滚和对结果负责。