大模型能力越强，业务问题反而越要拆小

我不赞成因为模型能力变强，就把需求扩大成“让它负责销售”“让它接管客服”“让它做运营”。以下论证不是某个真实客户项目的复盘，而是一组基于常见工作流约束的合成场景，用来检验宽泛目标怎样失去完成边界。

我的判断是：强模型降低了单个动作的实现门槛，却放大了业务目标的歧义。能力越强，团队越要把问题拆成小而可验收的责任单元。

“负责客户运营”其实包含多种责任

一个看似完整的角色，至少会跨过意图识别、历史查询、策略选择、回复生成、承诺审批、消息发送和结果回写。这里有7类动作，也有完全不同的错误后果。

分类错了可以由人改；价格承诺错了会影响交易；消息发错对象还涉及隐私。模型都能参与，不等于这些责任可以交给同一个黑盒。

这个例子说明，角色名称不能当作需求边界。

长上下文没有消除事实冲突

模型能一次读取更多资料，但合同草案、现行条款和历史邮件可能互相冲突。把3类材料都塞进上下文，只是把“找不到信息”变成“该相信哪一份”。

真正需要的是文档状态、所有者、生效时间和冲突处理规则。模型能力解决阅读规模，业务规则决定事实优先级。

这个例子说明，输入容量扩大以后，知识治理要更细。

工具调用把错误带到了系统外部

只生成草稿时，错误还停留在屏幕上；一旦连接邮件、CRM 或审批系统，输出就会变成外部动作。读取、建议、写入和发送是 4 种不同权限。

团队应该先允许“读取并生成建议”，再验证“人工确认后写入”，最后才讨论有限自动执行。工具越强，越需要把每一步的中止点写清楚。

这个例子说明，执行能力扩大以后，权限要更小。

我把这种拆法叫“最小责任单元”

最小责任单元不是技术函数，而是一项能独立回答 5 个问题的业务动作：输入事实来自哪里，只做哪一个判断或动作，输出由谁接收，哪类错误不可接受，失败后回到哪个人工节点。任何一问答不上来，都说明责任仍然大于团队的验收能力。

一句话概括：模型可以拥有更大的能力面，但每次只承担一个可追责的动作。

一个宽需求怎样被拆成可验收动作

假设需求是“让 AI 跟进沉默客户”。直接做端到端 Agent，团队会同时面对客户分类、历史总结、优惠判断、文案生成、发送权限和 CRM 回写。任何一处失败，项目只会得到一个模糊结论：跟进效果不好。

按最小责任单元重写后，第一版只做“根据最近一次沟通，生成下一步建议”。输入限定为已授权的沟通记录与客户状态，输出只有建议类型、理由和证据位置，不生成价格承诺，也不自动发送。销售可以接受、修改或拒绝，并留下原因。

这样至少出现3个可分别检查的证据：状态是否取对，建议是否被原文支持，销售修改集中在哪类问题。若状态经常错误，应修数据映射；若理由缺证据，应修上下文；若建议正确但销售仍拒绝，才回到业务策略。一个“大模型效果”问题被拆成了能分派的责任。

第二版是否增加邮件草稿，要看第一版的修改记录，而不是看模型又发布了什么能力。第三版是否允许写回 CRM，又要单独验证字段、权限与重复写入。拆小没有降低目标，只是让每一次扩大都由上一轮证据支持。

这里还要防止一种假拆解：把“客户运营 Agent”改名为检索模块、规划模块和执行模块，看似分成3层，业务责任仍然没有变化。真正的拆解要让业务人员能独立判断一个动作是否完成。比如“找到最近一次有效沟通”可以核对来源，“提出下一步建议”可以比较销售修改，“发送消息”可以检查授权与写回。技术模块服务这些责任，不能代替这些责任。

验证拆解是否有效，也不必先做完整系统。团队可以拿一组去敏样本人工走完新流程，记录每一步需要的事实、决定和退回原因。若两个相邻动作总要共享同一个判断，可以合并；若一个动作失败后无法确定由谁修，就继续拆分。粒度由证据决定，而不是由架构图的美观决定。

这一步做得越早，后续模型升级越容易被真正转化为业务能力，而不是扩大一个无人能验收的承诺。

小任务不是把流程切得越碎越好

过度拆分会增加状态同步和交接成本。判断粒度是否合适，要看一个单元能否被真实样本独立测试，能否给出明确完成状态，以及失败时是否保留上下文。

例如“生成跟进建议”可以单独验收；“理解客户”无法验收；“提取所有信息”又可能把不同风险字段混在一起。小的标准是责任清楚，不是字数更短。

常见失败是用技术模块代替业务拆解

团队常把系统拆成模型层、Agent 层、数据库层和前端层，却没有说明“谁确认退款资格”。技术结构完整，业务决定仍然悬空。

另一种失败是把一次成功演示当作端到端能力。成功样本没有覆盖缺字段、冲突资料、权限不足和外部服务失败，项目自然无法说明何时应该停。

边界：探索任务可以暂时保持开放

头脑风暴、研究方向发现和低风险创意草稿，不必在开始前定义唯一正确答案。它们的价值本来就来自开放性。

但只要结果会写入正式系统、发送给外部用户或触发资源变化，就应回到最小责任单元。开放探索和业务执行需要两套不同的控制方式。

下一步用一张动作表收口需求

拿当前最宽泛的 AI 需求，逐行写出动作、输入、输出、权限、确认人和失败出口。先选择一个低风险单元，用真实样本验证，再决定是否串联下一步。

面对“让 AI 负责一个部门”这样的需求，评审重点不应是模型能覆盖多少动作，而应是团队能否说清第一个动作由谁负责。模型能力越宽，这个问题越不能省略。