聘请 AI 开发公司之前要准备什么，系统才能真正帮您降低成本

要点速览

AI 项目失败，最常见的原因是问题还没想清楚就开始和开发商谈；选错开发商反倒没那么常见。
问题不清楚，每家供应商提的方案都不一样，价格根本没法比较。
征集方案之前，手里应该有一份一页纸的文件，写明问题是什么、谁来用、现有哪些数据、怎样衡量效果。

1. 找供应商（Vendor）之前，先让公司做好准备

盖房子时，您不会跑去问施工方“我该盖什么样的房子”。您会先说清楚几口人住、预算多少、地块面宽多少。软件项目也是同样的道理。

指定一位业务负责人（Business Owner），他要有权改动流程，也能回答问题。不要把协调工作全丢给 IT 部门或行政秘书，因为关键决策涉及的是规则、风险和 KPI。没有负责人，开发商得到答复就慢，只能拿假设去填补空白。

收集基线数据，包括工作量、每个步骤的用时、差错、处理周期（Cycle Time）、人数和费用。如果还没有这些数字，可以先要求一个需求调研阶段（Discovery Phase）来收集。不要凭一句“我们想用 AI 帮公司”就让人报整套系统的开发价格，因为每份方案书的理解都不一样，最后没法比较。

定好预算区间和时间范围，同时说明限制条件，比如数据必须存放在泰国境内、必须沿用现有系统、客户数据不得外传，或者有几个关键的业务高峰日。把这些坦白说出来，供应商才能提出合适的架构，避免设计过度或满足不了需求。

手头要备齐的材料流程负责人、基线数据、已遮蔽敏感信息的真实数据样本、需要对接的系统、业务目标、预算区间，以及最终拍板的人

2. 先写一页纸的业务简报（Business Brief），再写功能清单

用一页纸写明问题是什么、谁会用、已有哪些数据、怎样衡量效果，所有供应商就会针对同一个问题提方案，您也才能真正比较这些方案。

先写问题和影响，例如：“6 名行政人员每月处理 4000 张订单，平均每张 12 分钟，差错率 3%，业务量每增长 20%，就得多招一个人。”然后写目标结果，比如把人工处理时间（Touch Time）降到 4 分钟，在不增加人手的情况下多处理 50% 的业务量。

描述现有的工作流：数据来自哪些渠道、涉及哪些系统和人员、有哪些例外情况、出错时造成什么损失。写明哪些不在范围内，例如暂不审批付款、不改动 ERP、暂不自动回复客户。把排除项写下来，可以防止项目做到一半不断扩大。

不要过早锁定技术，比如明明只是按规则搬运数据，却要求“必须用 AI 智能体（AI Agent）”。供应商应该说明哪些部分用自动化、哪些部分用 AI，以及原因。不那么聪明的方案，往往更便宜也更稳定。

3. 准备好数据和系统，让开发商能够评估

列出数据来源：CRM、ERP、数据库、电子邮件、文件存储、电子表格、操作手册和外部数据。注明每个来源的负责人、格式、数据量、更新频率、质量和访问权限。如果有个人保存的文件或系统外的步骤，要如实说明，因为这些往往是系统集成中最大的一笔成本。

准备多样化的数据样本，至少 50–100 个，涵盖一般案例、信息不全的数据、表述混乱的文字和例外情况，并附上每个样本的正确答案或核对方法。没有标准答案（Ground Truth），就无法评估模型，演示也只会挑简单的案例。

核查个人数据、商业秘密和客户合同方面的要求。确定哪些数据可以用于开发、是否需要脱敏、保存多久，以及模型服务商会不会用这些数据训练模型。在签好保密协议（NDA）、设好访问权限并准备好合适的传输渠道之前，不要把生产数据交给供应商。

数据项	问题	对项目的影响
质量	完整、准确、及时到什么程度？	准确率和准备时间
访问	有没有 API？能不能导出？	系统集成成本
权限	谁能读、写、删除？	安全设计
数据量	每天多少？高峰时多少？	基础设施和运行费用
保存期限	日志和输出结果保存多久？	合规和成本

4. 询价之前，先定好试点范围和 KPI

试点要检验的是主要风险，不必做齐所有界面。限定一到两个输入渠道、一种主要输出，系统集成只做必需的部分。写明用户人数和测试量。请供应商把需求调研、试点、生产环境上线和维护分开报价，这样每个阶段要投入多少，您都看得清楚。

写给开发团队 · 技术指标

KPI 应涵盖业务、质量、技术和成本，例如每件处理时间减少 60%，必填数据准确率 98%，P90 响应时间低于 10 秒，每件成本不超过 5 泰铢。还要定义验收测试（Acceptance Test），以及由谁判定是否通过。

范围清楚时，能回答这些问题

谁来用，系统在什么时候开始工作、什么时候结束
数据从哪里来，结果写回到哪里
哪些情况由 AI 处理，哪些需要人审批
什么算差错，用哪个数据集来衡量
试点结束时交付什么，归谁所有

5. 应该问 AI 开发公司的 15 个问题

能否用自己的话复述我们的业务问题和 KPI？
哪些部分该用 AI，哪些该用普通的自动化？为什么？
如何用真实数据衡量准确率？标准答案由谁来定？
系统如何处理信息不全、指令相互矛盾和超出范围的情况？
会用哪些模型和服务商？会不会用我们的数据训练模型？
数据会发送到哪个国家或地区？怎样加密？保存多久？
智能体或系统的权限如何限制？哪些环节需要人工审批？
如何防范提示词注入（Prompt Injection）、数据泄露和重复执行？
有哪些日志、监控、预算告警和事故响应机制？
如果模型 API 或源系统宕机，业务怎样继续运转？
在低、中、高三种业务量下，每件和每月的费用分别是多少？
源代码、提示词、工作流、数据和输出结果归谁所有？
我们要更换模型、迁移托管环境或更换供应商，难度有多大？
交付之后，谁负责服务水平协议（SLA）、安全补丁和评测？费用多少？
能否看看类似的生产系统，并听听没做成的项目留下了哪些教训？

回答的质量比回答时有多自信更重要。好的供应商会承认自己还不知道的地方，要求提供数据来做评估，并提出能降低风险的试验。没看过您的数据就保证高准确率，或者声称 AI 什么都能自己学会的销售方，需要多加审查。

6. 透过“AI”这个词，看清方案书里到底有什么

写给开发团队 · 功能清单

方案书应包含流程图、架构、数据流、角色分工、前提假设、交付物、时间表、验收标准、安全措施、成本模型和不包含的内容。如果只有一份功能清单和几张截图，还不足以评估一个生产系统。请供应商说明在成功、出错和外部系统宕机时，数据分别怎样流转。

写给开发团队 · 技术细节

在相同的范围和场景下比较方案书。不要只看最后的总价：有的供应商包含了需求调研、部署和技术支持，有的只报了原型的价格。做一张 24 个月的总成本表，涵盖 API、托管、维护、软件许可和可预见的变更。

写给开发团队 · 技术细节

检查时间表里有没有留出数据处理、系统集成、用户测试、安全审查和并行运行的时间。承诺快速交付，对演示来说也许做得到，但生产系统必须测试各种例外情况，还要让员工为工作方式的变化做好准备。如果护栏（Guardrail）还没通过，就不要为了配合市场部定的日期强行上线。

危险信号声称“准确率 100%”，对错误数据只字不提，索要过宽的权限，没有按用量计算的费用，没有验收测试，绑定在自家平台上且无法导出，或者在核心工作流得到验证之前，就提议建一套大系统。

7. 合同和所有权方面的要点

写给开发团队 · 技术细节

明确源代码、配置、提示词、评测数据集、生成的数据、文档和定制 Connector 的权利归属。把新开发的部分和供应商原有的资产分开。如果用了开源组件或外部服务，必须披露相应的许可协议和限制。

写给开发团队 · 技术细节

约定数据处理、保密义务、次级处理方（Subprocessor）、数据存放地点、保存期限、合同结束时的数据删除和事故通知。写明审计权，或者供应商必须提供的标准证明材料。重要数据应使用独立的环境，未经批准不得把生产数据用于测试。

写给开发团队 · 技术细节

从一开始就制定退出计划（Exit Plan）：数据和日志以什么格式导出，凭据（Credential）怎样移交，有没有部署文档和运维手册（Runbook），供应商协助过渡多少天，合同结束后系统能否继续运行。如果能省钱、条款也清楚，一定程度的锁定（Lock-in）可以接受，前提是这是您主动做出的决定，事后才发现就不行了。

写给开发团队 · 技术细节

把分阶段付款（Milestone Payment）与交付成果和验收挂钩，时间只是其中一个因素，例如需求调研报告、通过测试集的试点、生产就绪，以及上线后的稳定期。规定变更请求（Change Request）的处理方式，免得每个新需求都变成纠纷。

8. 既快又不冒险的选型流程

列出 3 家入围供应商：看相关经验、系统集成能力，以及对您业务的理解。
统一说明会：给所有供应商同一套数据、范围和 KPI。举行问答环节，重要的答复同等地分享给每一家。
方案研讨会：请供应商真正负责项目的团队和您一起分析流程和例外情况。重点看他们怎么思考，销售幻灯片其次。
付费需求调研/试点：对于复杂的问题，付费请供应商用经过保护的数据验证风险较高的部分，别要一个流于表面的免费演示。
回访参考客户：向供应商的现有客户了解上线之后的情况、实际费用、事故响应和知识移交。
评分卡：按业务契合度、技术能力、安全、团队、成本和可退出性打分，权重要在拆开报价之前定好。

30%对业务和目标成果的理解

30%技术、数据和安全

20% + 20%交付团队和总成本

这些权重只是示例。受监管行业的企业应该提高安全与合规的权重。不要让最终用户没有发言权，因为便宜却难用的系统会催生影子流程（Shadow Process），人手也减不下来。

9. 项目启动后的头 30 天应该看到什么

写给开发团队 · 技术细节

第一周应确认基线、流程图、负责人、数据访问权限和风险登记册（Risk Register）。第二周做出主流程的原型和第一版评测集。第三周在影子模式（Shadow Mode）下用真实数据测试。第四周拿出对比结果，并决定是推进到生产环境，还是调整假设。

每周开一次简短的决策会，把演示、指标、风险和决策分开讨论，不要把大部分时间花在汇报做了哪些事上。企业主必须尽快清除数据或规则方面的障碍。如果公司自己的团队不能按时提供样本和反馈，供应商也没法靠技术弥补。

第一个月就开始规划工作方式的改变。明确新的 SOP、审核人、后备系统，以及兑现价值的方式，比如停止加班或不再增设岗位。如果等系统做完了才谈人的问题，公司只会多出一套 AI 系统，原有的步骤和成本却一样不少。

总结：选择 AI 开发公司，要从您作为客户自身的准备做起：写清问题和 KPI，准备真实数据，划定试点范围，问清差错、权限、成本和退出计划，再把合同和成果挂钩。合适的开发商除了能很快做出演示，还会帮您得到一套真正能用、可以衡量、安全、公司自己也能维护下去的系统。

DNA MAKER · SOLUTION BLUEPRINT

向开发商征集方案之前，先把问题和数据准备好

我们写这篇文章，是希望您能以同样的条件和每一家开发商沟通，包括我们在内。项目失败最常见的原因，是问题还没想清楚就开始谈，选错开发商的情况要少得多。问题不清楚，每家提出的方案各不相同，根本没法比较。流程和数据方面的知识在您的团队手里；在这个阶段，DNA Maker 能帮上忙的是提出对的问题，并协助您整理一页纸的业务简报，写明问题、用户、范围、现有数据和效果衡量标准。

和任何人沟通之前，手里应该备好的东西

问题清楚了，开发工作才能有方向地展开。我们通常建议先安排一个时间短、价格明确的可行性评估阶段，让双方在长期合作之前都看到真实数据。同时约定代码、数据和文档的所有权，这样将来您更换开发商时也不会受制于人。如果您正准备发出方案征集书，可以把简报草稿发给我们，我们帮您看看哪里还有缺口，即使您最后选择和别家合作也没关系。

SOFTWARE ENGINEERING GLOSSARY

软件工程术语表

这组术语能帮您读懂开发方案书和合同。

术语	是什么	通俗示例	高管应问开发团队的问题
Business Brief	一份简短的文件，写明项目的问题、用户、范围和成功标准	一页纸的文件，发给每家开发商作为报价依据	每家供应商针对的都是同一个问题吗？
Statement of Work	写明工作范围、交付物和验收条件的文件	写明这一阶段交付什么、什么时候算完成	验收条件写清楚了吗？
Acceptance Criteria	事先约定的标准，规定什么样的工作算通过	系统必须按约定标准正确读取这种格式的文件	由谁判定是否通过？用哪组数据？
Source Code Ownership	关于开发出来的代码和文档归谁所有的约定	代码归公司所有，存放在公司自己的系统里	如果更换开发商，我们能带走什么？
Handover	把系统、文档和知识移交给负责后续维护的团队	完整移交操作手册、系统结构和访问权限	移交之后，由谁维护？按什么条件？