软件老炮转 AI,最难的不是技术,是放下锤子

我做软件二十多年，碰到业务问题，第一反应通常是：这个功能要不要做出来？数据库怎么设计？接口怎么拆？

这是软件开发者的职业本能。做企业级 ERP、零售 ERP、电商直播系统、营销系统，后来做智慧校园、充电桩云平台和半低代码平台，很多事情确实要靠系统解决。需求来了，建表、写代码、联调、上线，问题被拆成一个个可以交付的模块。

但转到 AI，原来的这套本能有时会变成障碍。

我把它叫作"锤子思维"：手里有一把熟悉的锤子，看什么都像钉子。遇到一个问题，先想造工具；看到一个流程，先想上框架；听到一个新方向，先讨论技术深度、模型参数和架构先进不先进。至于谁来用、用什么数据、输出之后谁负责，反而往后放了。

— 手绘锤子对象卡片，隐喻锤子思维

AI 时代，很多工作不需要从零造一套软件。一个模型、几段规则、一些业务资料，就能先让一个岗位跑起来。难点不是把功能推出来，而是把工作说清楚：输入是什么，判断依据是什么，结果交给谁，错了怎么发现。

这对软件老兵并不容易。我们习惯掌控每个环节，习惯把需求翻译成确定的字段和流程，也习惯用"自己写出来"证明能力。模型的回答却带着不确定性。它可以很快给出一份采购建议，也可能漏掉一个业务限制；可以生成一篇文章，也可能把没有依据的话写得像真的。

于是，真正要放下的，不是代码能力，而是对"从零构建"的执念。

我现在研究垂直行业 AI 智能体，做的第一个行业智能体是"伽观-创作"，主要服务中小企业主和创业者的 IP 建设及产品推广内容。这个过程中，一个明显感受是：智能体不是聊天框，也不是把大模型接进系统就结束了。它更像一个岗位，需要有职责、有资料、有工作流程，还要有人验收。

— 手绘卡片堆叠对象卡，隐喻智能体像一个岗位

比如写一篇文章，不能只给模型一句"帮我写得专业一点"。作者是谁，经历过什么，哪些观点不能越界，文章要给谁看，字数和发布渠道有什么要求，这些都要先固定下来。作者档案不是装饰，它决定了模型能写什么、不能写什么。输出之后，还要检查事实、篇幅和 AI 味，不能因为文字顺滑就直接发布。

这套思路放到零售经营里也一样。库存不能只看总量。滞销、仓储成本、周转率、资金占用和缺货风险要放在一起看。SKU、颜色、尺码、首铺、补货、调拨、促销，也不能只凭某个人的经验拍脑袋。智能体可以根据规则和数据给出分层建议，但采购和经营负责人仍然要核对，特殊情况也要保留人工判断。

这就是软件人需要重新捡起来的东西：提问、校验和判断。

以前写程序，问题常常在上线前解决。现在和模型协作，问题会出现在每一次输入和输出之间。提问不是把话说得漂亮，而是把任务边界、资料来源和验收条件讲明白。校验也不只是测接口通不通，还要问：这个结论从哪来的？有没有漏掉关键条件？它能不能转成下一步动作？

判断力更重要。报表不是答案，分析、预警、归因和动作入口才有经营价值。智能体给出一张表，不能就算完成；它应该帮助负责人知道库存为什么积压、哪个环节需要调拨、促销是否改变了周转，最后由人决定做什么。

— 手绘放下的锤子与规则尺度，隐喻放下锤子重新定义规则

放下锤子，也不是把过去二十多年的经验清空。恰恰相反，行业经验是判断模型能否落地的基础。软件老兵熟悉系统、流程、数据和交付，知道一个看似简单的功能会在哪些地方卡住。只是现在要把这些经验从"我来做"改成"我来定义规则、组织协作、验收结果"。

写作分工也是这个道理。经理接题，写手成文，检查智能体审 AI 味和字数，每个角色各自负责，结果反而更稳定。一个人把所有事包完，看起来省事，实际很难持续。

所以，软件老炮转 AI，最难的不是学会又一个框架，也不是追着每个新模型跑。难的是面对问题时，先忍住造工具的冲动，问清楚这个岗位今天到底要完成什么。

手里的锤子还在，代码能力也还在。下一次接到需求，我会先把人、流程、数据和验收方式列出来，再决定哪些地方值得写代码，哪些地方交给模型，哪些地方必须由人确认。这个顺序变了，工作方式才算真的变了。