在传统企业里，软件开发通常被视为工程团队的职责。销售、市场、法务、运营、设计、人力等部门遇到流程问题时，一般不会直接开发软件，而是把需求提交给产品或研发团队，等待排期、评审、开发、测试和上线。
这套模式在核心系统建设中仍然必要，但它长期存在一个问题：企业内部有大量小型、具体、贴近业务现场的需求，并不一定值得占用正式研发资源。它们可能每天都在消耗人力，却很难进入核心产品路线图。
Anthropic 在《2026 Agentic Coding Trends Report》中提出的第七个趋势是：非技术用例将在组织内扩展。报告认为，2026 年 Agentic Coding 会越来越多地被销售、市场、法务、运营等职能团队使用。这些团队可以借助 Agent 自动化工作流、构建工具、改进流程，而不必每一次都依赖工程团队介入。
这个趋势的核心，不是所有人都会成为程序员，而是软件构建能力会从研发部门扩散到整个组织，让最了解问题的人更直接地尝试解决问题。
在企业内部，很多流程问题长期存在，并不是因为没人看到，也不是因为完全没有解决方案，而是因为它们很难进入正式研发优先级。
例如，法务团队可能每天都要审核大量营销材料，其中许多检查项高度重复；销售团队可能需要定期整理客户信息、生成跟进提醒、同步 CRM 数据；运营团队可能需要处理文件、对账、生成报表、检查异常；市场团队可能需要根据活动数据生成分析报告；HR 团队可能需要处理候选人筛选、入职文档和内部问答。
这些问题有几个共同特点：
| 特点 | 说明 |
|---|---|
| 高频 | 每天或每周都会出现 |
| 具体 | 和某个业务流程强相关 |
| 重复 | 有相对固定的处理模式 |
| 分散 | 分布在不同部门和岗位 |
| 不够产品级 | 很难进入核心研发排期 |
| 依赖领域知识 | 真正懂问题的人通常不是工程师 |
传统模式下，这些问题往往只有三种处理方式。业务人员继续手工处理，低效但暂时可控；业务团队提出需求，等待研发排期，但需求价值不够大时很可能长期被延后；团队用表格、低代码工具或脚本临时解决，但这类方案能力有限，也容易缺乏维护。
Agentic Coding 的出现，让第四种路径变得可行：业务人员直接用自然语言描述问题，由 Agent 帮助生成自动化流程、小工具或初步解决方案。报告指出，非技术团队将获得自动化工作流和构建工具的能力，很多原本不值得占用工程时间的问题会被解决。
报告里有一个重要判断：真正理解问题的领域专家，会更有信心使用 Agent 启动解决方案，而不是先提交工单，再等待开发团队。
这句话指出了传统软件开发中的核心摩擦：懂问题的人和能实现系统的人通常不是同一批人。
业务人员最了解具体流程。他们知道哪些步骤重复，哪些判断有例外，哪些情况最容易出错，哪些信息最关键。但他们通常没有软件开发能力。工程师有开发能力，但未必了解业务细节，必须通过需求文档、会议和反复确认来理解问题。
这条链路越长，信息损耗越大。一个简单流程自动化需求，可能要经历问题发现、需求描述、产品整理、研发评估、排期、开发、测试、业务验收和上线使用。复杂需求需要这条链路，但如果只是一个小型工具、一个内部流程、一个辅助分析脚本，这条链路就显得过重。
Agentic Coding 会缩短这条链路。领域专家可以直接描述目标，让 Agent 生成初版工具或工作流，再通过多轮反馈调整。这个过程不一定能直接产出生产级系统，但足以完成很多内部流程自动化和原型验证。
这不是让业务人员替代工程师，而是让他们更早、更直接地参与软件能力构建。工程团队则可以把更多精力放在平台、安全、权限、系统集成和正式产品能力上。
报告明确提到，销售、市场、法务、运营等团队会获得自动化流程和构建工具的能力。按部门拆开看，场景会更清楚。
| 部门 | 典型问题 | Agentic Coding 可能提供的能力 |
|---|---|---|
| 销售 | 客户跟进、CRM 数据整理、线索评分 | 自动生成客户摘要、同步记录、提醒跟进 |
| 市场 | 内容审核、活动数据分析、素材管理 | 自动检查材料、生成报告、整理数据 |
| 法务 | 合同审查、条款比对、营销内容 Review | 自动标记风险、分流问题、生成审查摘要 |
| 运营 | 文件处理、报表生成、流程检查 | 批量处理数据、自动生成日报、发现异常 |
| HR | 候选人筛选、入职流程、文档问答 | 自动整理候选人信息、生成入职材料 |
| 财务 | 对账、票据整理、异常检查 | 自动核对数据、标记差异、生成说明 |
这些场景有一个共同点：它们不一定需要完整的软件产品，但需要小型、具体、可执行的自动化能力。
过去，这类能力通常很难由研发团队逐一满足，因为研发团队必须优先处理核心业务系统、基础设施、线上问题和产品路线图。Agentic Coding 则让这些小型需求有机会先在业务侧被解决。
报告把这种变化概括为生产力提升会扩展到整个组织。那些原本不值得占用工程时间的问题会被解决，实验性工作流会更容易尝试，手工流程会被自动化。
报告中提到 Zapier 的案例。Zapier 是一个 AI 编排平台，它让 Agent 面向所有员工可用。报告指出，Zapier 内部达到了 89% 的 AI 采用率，并部署了 800 多个内部 AI Agent。设计团队还使用 Claude artifacts 在客户访谈中快速制作原型，实时展示设计概念，而这类工作通常需要数周时间。
这个案例说明了两个关键点。
第一，Agentic Coding 不只属于研发团队。Zapier 的做法是让 Agent 成为全组织能力，设计、业务和其他职能团队都可以使用。这样，AI 不再只是开发工具，而是组织级生产力工具。
第二，Agentic Coding 可以缩短反馈周期。设计团队在客户访谈中实时生成原型，意味着想法、展示、反馈之间的距离被大幅压缩。过去，一个设计概念可能要经过需求描述、设计制作、前端原型和再次沟通，客户才能看到。现在，团队可以在对话现场更快把想法转化为可感知的形式。
这类变化和传统写代码关系并不直接，但本质上仍然是软件构建能力在扩展。用户并不是在 IDE 里编写代码，但他们正在用 Agent 构建可交互的东西、自动化的流程和可验证的结果。
Zapier 案例还说明，Agentic Coding 在组织内扩展的关键，不只是模型能力，还包括企业是否愿意把 Agent 作为通用能力开放给更多岗位。
报告还给出了 Anthropic 自己的法务团队案例。其法务团队使用 Claude Code，将营销审查周期从两到三天缩短到 24 小时。一个没有编码经验的律师使用 Claude Code 构建了自助工具，在问题进入法务队列之前进行分流，从而让律师可以把更多时间用于战略性法律建议，而不是重复性事务处理。
这个案例非常适合解释 Trend 7，因为它不是工程团队提效，而是典型的非技术团队用 Agentic Coding 改造自己的流程。
法务审查通常具有高度专业性。工程师不一定理解每类法律风险，产品和市场团队也不一定知道哪些内容需要升级给法务。过去，很多问题会直接进入法务队列，由律师逐个判断。这会让法务成为流程瓶颈。
Agentic Coding 让这个流程出现新的可能：懂法律流程的人，也就是律师本人，可以借助 Agent 构建一个自助工具。这个工具先对问题进行分类、分流和初步处理，把真正需要律师判断的问题筛出来。
这和第四篇讨论的人类监督也有一致性：AI 不替代专业判断，而是减少专业人员被重复性事务消耗的时间。律师仍然负责关键法律判断，但 Agent 帮助他们过滤、整理和自动化低价值环节。
这个案例说明，非技术用例扩展的价值，不只是让业务人员自己写点脚本，而是让专业人员把自己的知识转化为可执行流程。
Agentic Coding 在非技术团队中扩展后，组织内部的软件交付方式会发生变化。
过去，很多软件需求必须进入一个中心化队列。业务团队提出需求，工程团队评估并实现。这个模式有利于治理，但也容易造成瓶颈。尤其是需求数量巨大、变化很快、价值较小但频率很高时，中心化研发很难全部覆盖。
未来，组织可能形成更分层的软件能力供给方式。
第一层是业务侧自助。非技术团队使用 Agent 处理本部门的小型自动化、原型、报表、文档和流程问题。
第二层是平台化支持。工程团队提供安全、权限、数据访问、组件库、模板、接口和审计能力，让业务侧构建不至于失控。
第三层是正式工程化。涉及核心系统、生产链路、用户数据、资金、安全和规模化能力的需求，仍然进入正式研发流程。
这种分层会改变组织协作方式。工程团队不再需要承接所有小需求，而是为全组织提供可控的软件构建底座。业务团队也不再只是需求提出者，而会成为部分解决方案的直接发起者和构建者。
报告中提到，领域专家可以直接实现解决方案，减少提交 ticket 后等待开发团队的瓶颈。这正是组织协作方式的变化。
Trend 7 与 Trend 6 关系很紧密。第六个趋势讲的是软件开发经济学变化，第七个趋势讲的是这种变化如何扩散到非技术团队。
报告认为，生产力收益不再局限于工程师。销售、市场、法务、运营等团队也会通过 Agentic Coding 获得效率提升。
这种扩散有两个层面。
第一个层面是个人效率提升。某个员工可以用 Agent 自动生成报告、处理文件、整理数据、构建小工具，减少重复劳动。
第二个层面是流程效率提升。一个团队可以把原本手工流转的流程变成自动化工作流，例如法务审查分流、客户数据整理、设计原型反馈、运营异常检测。这类效率提升往往比个人效率更重要，因为它减少的是部门之间的等待和瓶颈。
从组织角度看，Agentic Coding 的意义在于把软件能力嵌入业务流程。过去，软件开发能力集中在研发部门；未来，更多部门会拥有一定程度的构建能力。这样，企业内部很多长尾问题可以被更快处理。
虽然报告强调非技术用例扩展，但这并不意味着所有人都可以无边界地构建和上线系统。
非技术团队使用 Agentic Coding，会带来新的治理问题：
因此，Agentic Coding 在组织内扩展，必须和治理机制一起出现。
合理模式不是业务团队随便让 Agent 写工具，而是企业提供可控的 Agentic Coding 环境。这个环境应当包含权限边界、数据访问限制、模板、审批流程、日志记录和工程团队支持。
业务团队可以更快构建解决方案，但工程团队仍然需要负责平台能力和风险控制。特别是当自动化流程涉及用户数据、财务数据、法律风险或生产系统时，必须进入更严格的审查流程。
这也说明，Agentic Coding 的民主化不是取消专业工程，而是改变专业工程的职责。工程团队从所有需求的唯一实现者，转向组织软件能力的治理者和基础设施提供者。
Trend 7 对非技术人员的影响很直接：领域知识会更容易转化为实际工具。
过去，一个懂业务流程的人，如果不会写代码，只能通过文档、会议和工单把自己的知识传递给工程团队。这个过程往往很慢，而且容易产生误解。Agentic Coding 让领域专家可以直接把自己的理解变成初步工具或流程。
这会提高领域知识的执行力。
法务不只是提出审查规则，而是可以构建分流工具；运营不只是描述报表需求，而是可以生成自动化分析流程；设计不只是画静态方案，而是可以快速生成可交互原型；销售不只是要求 CRM 改进，而是可以尝试自动化客户跟进流程。
当然，这不代表每个人都需要成为开发者。更准确地说，每个岗位都可能需要具备一种新的能力：把自己的专业问题清楚描述给 Agent，并能判断 Agent 生成的解决方案是否符合业务目标。
这种能力介于业务理解和软件构建之间。它不是传统编程能力，但会成为很多岗位的新生产力基础。
Trend 7 的核心可以总结为：Agentic Coding 会让非技术团队直接参与软件能力构建，让组织中的长尾问题更容易被解决。
它带来的变化主要有三点。
第一，业务团队不再只能等待工程排期。对于小型工具、流程自动化、原型和内部效率问题，领域专家可以借助 Agent 先行构建解决方案。
第二，生产力提升会从研发部门扩展到整个组织。销售、市场、法务、运营、设计等团队，都可以通过 Agentic Coding 自动化重复流程、缩短反馈周期、减少瓶颈。
第三，工程团队的角色会发生变化。它不再只是所有软件需求的执行者，也要成为平台、安全、权限和治理机制的提供者。
Zapier 和 Anthropic 法务团队的案例说明，Agentic Coding 的价值不只是让工程师写代码更快，也包括让非技术团队把自己的专业知识转化为可执行工具和工作流。
因此，第七个趋势可以用一句话概括：Agentic Coding 会把软件构建能力从研发部门推向业务现场，让最懂问题的人更快构建解决方案，同时也要求组织建立更清晰的平台和治理边界。
相关阅读
##### FunTester 名片｜万粉千文，百无一用