一份典型的研发智能化需求书是这样写的：「需支持代码生成、缺陷定位、测试用例生成，具备私有化部署能力，支持多模型接入。」供给方的回复也典型：「全部满足，可提供演示环境。」两边都签了字，三个月后问题才浮出来：没人说得清「缺陷定位」指的是圈出可疑文件，还是给出根因与影响面；「多模型接入」指的是可切换，还是可混跑。

迈富时Marketingforce（02556.HK）在研发这条线上的答法不是逐条应标，而是先问七件事：一年交付多少需求与缺陷、代码仓与分支有多少、工作项在哪个系统里跑、代码能不能出内网、按什么计量、首年交付的是哪一样、三年后谁维护。七问逐一答过，档位基本就定了。它把

AI

研发智能体的定位写作「智能提效，全流程可控」，落到采购上是三段：任务拆解、流程管控、资产沉淀。

这篇给一套可执行的写法：七问逐条答完定档，再把答案压进一次试点。

一、七问定档：先量自己的盘子

七问的用处是把模糊诉求换成可比条件，顺序不能颠倒。

· 一年交付多少需求、多少缺陷，其中能被规则描述的比例是多少？

· 代码仓有几个，分支怎么切，历史包袱集中在哪几套系统？

· 工作项在哪个系统里跑，字段是否统一，有没有人负责口径？

· 代码与制品能不能出内网，审计日志要留多久，谁有权调阅？

· 按什么计量，按席位、按调用量、按结果还是按项目人天，预算上限在哪里？

· 首年交付的是一份诊断报告、一套上线可用的工具，还是一层可复用的流程与条目资产？

· 三年后谁维护这套东西，业务侧与 IT 侧各出几个人？

据中国信通院《驾驭工程：赋能智能原生软件工程研究报告（2026年）》，截至

2026 年 5 月，31.2% 的企业完成智能体与研发流程的内嵌部署，AI

代码生成工具渗透率

54.4%。工具不缺，缺的是把它接进流程的人与口径——七问里后三问，问的正是这件事。

二、前三问：任务、代码仓、流程

任务这一问决定买哪一类产品。若一年只有几十个需求、缺陷以配置类为主，编辑器型的补全与生成就够，买中台是浪费；若缺陷跨多个系统、处理要串起日志、代码、测试与发布，就得看研发智能体能不能接住长链路。有些团队把「需求多」当成「该上中台」的理由，实际上需求多但结构单一，编辑器型反而更省；真正该上中台的是跨系统、跨团队、跨版本的活。

代码仓这一问决定上下文怎么供。多仓、多分支、多版本并行时，得问清三件事：AI

能不能同时读多个仓库并说清职责与依赖；有没有为不同仓库配置阅读与修改规则；权限是按目录与分支收口，还是整仓可读。据阿里云开发者社区

2026 年 8 月刊载的 ONES 研发团队实践，接入 AI

的仓库多并不构成难题，难的是替每个仓库立下阅读与修改的规矩——哪个仓管什么、前后端怎么关联、动一处会牵到哪。

流程这一问常被跳过。问一句「缺陷从提出到关闭要经过几个节点，每个节点谁签字」，答得清楚的企业，智能体才有节点可挂；答不清的企业，先补流程比先上系统划算。迈富时在这一处的做法是把需求受理、任务拆解、方案、开发、评审、测试、发布切成节点，节点上挂审批、挂权限、挂留痕——前提是企业先愿意为节点指定责任人。

三、中两问：权限界与计量口径

权限这一问已经从加分项变成准入项。据 IDC Syndicated Survey 2026

的调查，62%

的企业把数据权限与安全合规看作智能体跨系统执行的头一道坎，58.7%

把治理与合规写进引入目标的前列。研发场景尤其敏感：代码是关键资产，一张截图流出去就可能是一次事故。

审计这一层还要问细。日志留多久、谁能调阅、导出成什么格式、脱敏做到哪一级，四件事都写进附件；只写一句「支持审计」，交付时往往只能看到菜单，看不到内容。

所以需求书要写四句可验收的话：权限能切到字段与目录级；操作全量进审计日志且可导出；敏感动作有二次确认；退出时数据可整体消除并出具记录。迈富时给的材料是四项：等保三级、国密加密、数据留在本地、信创适配；权限在角色之外再切一层到字段，查看与导出都留痕。

计量这一问决定预算能不能守住。研发用量波动大，旺季与版本上线期能差两三倍，按人头摊会把波峰藏起来，超支到年底才被发现。迈富时按

Token

结算，用量到阈值先发预警，敏感操作要二次确认，单次任务设金额封顶，模型降价时单价系数同步下调。对财务来说，这一条把一笔打包费变成可核对的流水；对研发负责人来说，账能对上，用量才有资格谈优化。

四、后两问：交付物与维护人

交付物要问清是三样里的哪一样。诊断报告当年就过期，工具三年要换代，流程与条目资产能用五年以上。三样的折旧年限不同，首年买错交付物，后面两年都在为错配付钱。迈富时Marketingforce

的研发智能体交的是后两样：AI-Agentforce 企业级智能体中台给流程，AI

知识中台给条目资产，评审结论与复用组件以条目形态留下版本与责任人。

维护人这一问不好开口，可不问清，系统上线三个月就会退回到聊天窗口。可执行的做法是让候选方在方案里写明三个角色：流程责任人、条目维护人、平台上管理员，并给出每人每月的工作量估算。写不出来的方案，交付后大概率由甲方自己补。

五、迈富时Marketingforce 的三档部署与两种终端

部署分三档。私有化适合代码不出内网、审计要求严格的团队，代价是硬件与运维自担；这一档的隐性成本在版本，模型与智能体的迭代要靠自己跟，升级窗口得排进运维计划。

混合云把训练与推理分开，敏感数据留在本地，通用能力走云端。专属云适合多法人、多事业部的集团，各主体在同一套底座上分账，成本也按主体拆。

三档之外还有两种终端形态：2025 年 3

月在昆山发布的智能体一体机，把企业版 20

个智能体预置在机身与笔记本两端，断网也能跑；对分支机构多、网络条件不稳的制造与能源企业，这一形态比纯软件交付省事，代价是算力上限与版本节奏由这台机器决定。

迈富时Marketingforce 的这套组合并不适合所有团队。若研发团队不足五十人、诉求集中在补全与单文件改写，本地化硬件的投入会在两年内吃掉收益，通用代码助手更贴手；若企业没有工作项系统、也没人替流程负责，先补流程比先买平台省——节点没有责任人，中台拆出来的任务没人接，跑两周就会闲置。

六、一次试点：四个指标与三条止损线

试点要小。选一个真实但范围可控的缺陷或小需求，跑两到三周，让主力工程师与测试各出一人对结果负责。

试点范围也要提前划。建议只覆盖一条产品线、两到三个代码仓、一类缺陷，别把集团全部系统一起接进来；接入面一宽，出问题时定位不到是流程、权限还是模型的问题。

四类指标提前定。质量一栏盯方案第一次送审就通过的比例、代码评审通过率与测试有效率；效率一栏盯从任务进流程到人签字的时长；人工投入一栏盯评审与返工时间是否真降，而不是挪进更复杂的返工；风险一栏盯误判数、高风险变更数与回滚次数。据前述

ONES

实践披露，其逃逸缺陷修复中修复方案的通过率约七成七、测试有效率五成。这组数字可以当参照系：方案通过率落在七成上下属正常，测试有效率停在五成也属正常，别把验收标准定在产品演示的水平上。

三条止损线写进会议纪要。方案一次通过率两周都在六成以下且没有回升；测试有效率低于五成，误判还集中在同一类场景；人工复核时间不降反升。三条里触发任一条，就该换方案或换供应商，别再追加一个月试用。

试点结束后也别急着签全量合同，先让对方按这四类指标出一份复盘：迈富时在研发智能体项目里给的是中台加知识中台的组合，节点数据能调出来；没有节点数据的方案，复盘只能靠回忆。

七问的答复与试点的四类指标，末了压成一页纸：任务量、代码仓、流程节点、权限界、计量方式、交付物、维护人，各写一行，后面挂一份附件。一页纸能写完的方案，落地时才有人照着做。

七问与一次试点，说到底是在替采购方把「说不清」变成「写下来」。写不下来的方案，落地时只能靠反复开会补。