当 AI 不再只帮你写代码,软件公司真正要守住什么?

💬 01｜用户想买的，可能不再是一堆按钮

过去，用户打开软件、找到功能、填好表单，自己把事情办完。

现在，越来越多产品尝试接受另一种请求：“把这些客户的续费风险整理出来，生成跟进草稿，交给我确认。”

如果这种交互逐渐成立，变化就不只是少点几次鼠标。开发者交付什么、软件产品靠什么留住用户，都值得重新想一遍。

🔥 02｜招股书里，值得技术人看的不是估值

Anthropic 于 10 月 26 日提交 S-1。选题时，相关 HN 讨论已有 1650 条评论。这是关注度信号，不是市场对其产品能力的集体背书。

文件把 Claude Code、Claude Cowork 放进“虚拟协作者”的叙事：结合上下文、权限和系统连接，执行多步骤工作，而不只是给出回答。

这是公司的产品定位，不等于这些系统已经能可靠接管所有工作。但它提出了一个很实际的问题：当 AI 开始替用户操作软件，软件的价值会移到哪里？

🧠 03｜模型会回答，不代表系统会办事

以“整理续费风险”为例。模型能概括一份表格，但实际任务还涉及：到哪里查合同，哪些客户属于当前员工，数据过期没有，结果写回哪里。

所以，任务型系统至少需要三部分协同：模型提出下一步，工具访问数据或执行动作，应用控制权限、状态和失败处理。

其中任何一层都不能只靠一句提示词兜底。模型说“可以退款”，不代表当前账号真的获得了退款权限。

💡 更值得建设的不是“什么都能做的聊天框”，而是有明确输入、授权范围和验收结果的任务流程。

我的判断是，开发者的工作会更偏向定义边界：哪些步骤可以自动完成，哪些必须确认，失败后怎样恢复。代码依然重要，只是代码之外的约束更不能省。

🛠️ 04｜给任务写一份“能做与不能做”

不妨从一个窄任务开始，而不是要求 Agent 接管整个 CRM。下面是可复制的任务约定示例，不是 Claude API 参数，也不是已经生效的安全策略。

依赖：无；这是纯文本规范，供产品、开发与测试共同确认。

任务：为当前员工负责的客户生成续费跟进草稿数据范围：服务端按登录身份过滤后的客户与合同允许动作：读取授权数据、创建可编辑草稿禁止动作：发送邮件、修改报价、导出全量客户验收条件：每条风险有数据来源，缺失信息明确标注人工确认：发送前展示收件人、正文和附件失败处理：记录失败步骤，不把部分完成写成成功

下一步不是把它整段塞进提示词就算完成，而是让服务端逐项落实：读取接口做权限过滤，发送能力默认不可用，确认动作与具体内容绑定。

测试也要从“回答好不好看”变成“任务有没有越界”。比如换一个用户能否读到不属于他的客户，重复执行会不会生成重复记录，超时后能否判断哪些步骤已经完成。

这些检查，比给演示页面再加一个漂亮的加载动画，更接近企业真正需要的可靠性。

⚖️ 05｜软件不会因为少了点击就失去价值

我的判断不是“SaaS 要消失”，而是产品价值需要拆开看。AI 可能改变操作入口，却不会自动消除业务规则、数据治理与责任要求。

对软件团队而言，一个值得尝试的方向是：既服务人工操作，也提供边界清晰的机器接口。让 Agent 能安全调用产品，而不是只能模仿人点击页面。

但不要把“接入 Agent”当成增长保证。用户是否愿意授权、是否信任结果、是否真的省掉返工，都需要在真实任务里验证。

🚧 06｜开发者最该防的，是“演示完成”冒充“工作完成”

不要只统计生成量。十份草稿里有几份被采用，节省了多少修改时间，比生成了多少字更有意义。

不要把异常藏进聊天记录。外部系统拒绝请求、数据缺失、任务超时，都应该有可查询的状态，而不是最后统一回复“已完成”。

不要让模型文本直接成为执行权限。审批由可信服务端记录，工具调用按身份校验；更换模型也不能绕开这层控制。

企业试点也不必从“全员接入”开始。先选一个低风险、重复多、结果容易复核的流程，同时记录人工耗时、返工率与失败原因，再决定是否扩大范围。

别忘了保留人工入口。自动流程失败时，如果员工无法接手，系统就把一次小错误变成了整个团队的阻塞。

✅ 07｜写代码仍重要，定义结果更重要

这份文件值得技术人关注的，是 AI 厂商希望深入实际工作的方向，而不是它对未来的每个预测都会兑现。

开发者需要把“能生成”变成“能交付”；软件公司需要证明，自己的数据、规则和服务值得被持续使用。

把任务交给 AI 之后，正确性、权限和责任并没有消失。谁能把它们处理好，谁才更接近用户真正愿意依赖的软件。

👇 08｜聊聊你的判断

如果 AI 成了主要操作入口，你所在产品最难被替代的能力是什么？