AI会写代码了，软件人的经验该用在哪里？

假如你正在参与一套报价系统的开发。销售录入需求，技术确认图纸，采购核算成本，生产确认排期，再交给主管审批。把这些环节做成页面、表单和流程，是企业软件从业者很熟悉的工作。

现在换一个要求：常规订单由AI读取资料、调用现有系统，在既定规则内生成报价，只有例外才交给人。原来围绕录入、流转、汇总设计的功能，还需要保留多少？

这件事落到我们身上，就变成了一个很具体的问题：过去花了很多时间练熟的工作，接下来还值多少？

和一位做SaaS的朋友聊AI后，我一直在想这个问题。我更看重的一类经验，是它能帮助我们判断：客户的工作为什么这样做，哪些交接可以减少，哪些事情仍然需要人决定。

先看一笔报价怎样完成

我之前研究企业AI落地时，接触过制造企业的报价场景。那些交接承担着补齐资料、核对数据、确认例外的作用。

沿着原来的流程做优化，我们会想到让AI识别图纸、整理物料清单、查询历史价格、生成报价初稿。这些改进很有价值。但如果只是每一步更快了，原来的交接方式可能仍然保留。

再往前想一步，企业能否把常规订单的规则整理出来，让系统直接读取库存、成本和产能，在授权范围内完成报价，并把价格异常、资料缺失、交期冲突的订单交给对应人员？

这里变化最大的是人的参与方式。原来每笔订单都要逐岗确认，现在需要先把常规处理规则定清楚，再把注意力放到例外上。效率提升也可能推动这种重组，我更关心的是：工作本身有没有随之改变。

原来的业务知识仍然要用，只是使用的位置发生了变化：从每次亲手做一遍，转向决定什么可以自动做、什么条件下要停下来。

这也解释了我为什么不想把讨论停在“AI写代码有多快”。如果客户需要的人工操作变少，我们得重新判断，哪些功能还值得做，原来积累的经验又该用来解决什么问题。

这也不意味着企业不再需要软件。库存、成本、权限和执行记录仍然要有可靠的承载。一部分软件可能退到后台，由Agent成为新的操作入口。能生成一个应用，距离让它长期支撑经营，还有数据、规则和运行问题要解决。

沿着这笔报价，重新看自己的岗位

做产品的人，过去可能把大量精力放在需求字段、录入页面和审批流上。现在，需求讨论需要往前走一步：一张图纸资料不全时，系统该继续计算，还是先向客户补问？原材料价格更新后，已经发出的报价是否跟着变？老客户的特殊价格由谁确认？

这些问题会决定哪些订单能自动完成、哪些需要人工处理。把它们问清楚，才知道还需要什么界面。原来那个复杂的录入页，也许可以简化；例外订单的处理入口，反而需要认真设计。

做研发的人，AI可以协助生成字段、接口和页面，但生成的代码仍要进入一套能持续运行的系统。沿着报价往下看：读取到的是哪一版成本？一次调用超时后重试，会不会重复生成报价？业务人员发现价格有误，能否找回当时用过的数据和规则？

这些地方会用到系统设计、数据一致性、故障处理和测试经验。可以让AI多承担实现工作，把自己的时间移到决定方案、审查关键逻辑、定位失败原因上。客户最终接收的是持续可用的报价服务，代码生成速度只解释了其中一部分成本。

做售前的人，也需要调整讨论的起点。客户说“给报价系统加个Agent”，可以继续问：目前最耗时的是找资料、等成本，还是等人确认？标准订单和特殊订单各卡在哪里？先弄清楚希望减少的工作，方案才有依据。

演示时也值得放进一张资料不全、成本发生变化或交期冲突的订单，和客户一起看系统怎样处理。它能把“加了什么AI功能”的介绍，推进到“这项业务准备怎样运行”的讨论。

实施和交付人员往往最接近这些细节。同一项报价规则，销售、采购和生产可能各有一套理解。过去可以靠人在中间协调，自动执行后就需要把分歧讲清楚：哪些成本进入报价，哪些订单必须确认，出现争议由谁处理。

你熟悉客户的工作习惯，知道信息实际放在哪里，也知道哪些流程只写在制度里。这些经验可以用来整理规则、打通系统、组织验收，并在上线后追踪哪些例外仍需要人反复处理。

对测试人员来说，异常订单同样是切入口。除了检查一份正常资料能否算出报价，还要看资料矛盾、价格过期、权限不足时会发生什么，再把这些失败情况留成可重复验证的用例。

公司的变化，会影响你的选择

个人看见这些变化，所在公司未必会立刻调整。对一家已经有成熟产品的软件公司来说，给现有功能增加AI辅助，通常更容易向老客户解释；减少原有功能、改变交互和交付方式，则会触及客户习惯、研发投入和已有收入。

按账号收费的产品还会遇到另一层问题：如果客户用更少的人完成原来的业务，账号需求就可能减少；如果业务规模扩大，也可能出现新的需求。不能直接从效率提高，推导出软件收入一定下降。

厂商需要重新考虑交付什么价值、怎样计费，以及怎样和客户验收。对个人来说，值得留意的是团队实际在做什么：有没有人在重新梳理客户希望完成的事情？你有没有机会接触规则讨论、系统衔接和上线后的反馈？

先改一段自己能碰到的工作

回到报价场景，不一定一开始就追求全流程自动报价。可以先选一个小环节，例如检查销售提交的资料是否齐全，把缺失项和矛盾信息集中反馈出来。它需要的资料、交接对象和完成标准都比较容易说清楚。

先记录原来怎样检查、会漏掉什么、来回补问几次；再让AI参与，把一批正常资料和缺项资料都跑一遍，比较处理时间、漏项与后续返工，也把人工复核花掉的时间算进去。

如果只是初步检查变快，后面的人却要花更多时间纠错，就继续改检查方式。哪些情况需要直接退回补资料，哪些可以让业务人员确认后往下走，都可以在这个小环节里逐步弄清楚。

做完以后，留下一份别人能看懂的记录：原来的工作、调整后的做法、仍然出错的情况，以及业务人员的反馈。这份记录能帮助下一次改进，也能让同事具体看见，你的经验解决过什么问题。

我过去长期从事项目管理和软件交付，越来越觉得，熟悉软件功能只是起点。更值得往下追问的是：客户为什么需要这项操作，它解决什么问题，还有没有更省力的完成方式。

下次需求评审，除了讨论增加什么功能，还可以把客户正在做的那件事摆到桌上：哪些操作可以省掉，哪些规则需要先定，剩下的例外由谁接手？从这里开始，软件人的经验就有了新的用处。