软件外包的询价，甲方的问题非常直接：这个需求你们能不做、用什么技术、几个人、多久、多少钱。这些问题答不上来，或者答得含糊，甲方就会去找下一家。
而多数外包公司的网站写的是「专注企业信息化、技术团队雄厚、服务客户数百家」。甲方看完既不知道你擅长什么技术，也不知道你的交付流程长什么样。
本文讲四块内容怎么写：技术栈说明、交付流程、报价结构、案例写法。
甲方在核的四件事
外包决策看起来复杂，实际就四关。
第一，能不能做：有没有做过同类系统、用什么技术栈、团队有没有相关经验。第二，靠不靠谱：交付流程是否规范、有没有项目管理、出问题怎么处理。第三，多少钱：报价结构是否清楚、有没有隐藏成本。第四，后续怎么办：上线后谁维护、源码归谁、能不能接手二次开发。
这四关里，第二关和第四关最容易被忽略，但恰恰是甲方最担心的 —— 外包行业的名声问题主要出在这两块。
| 关卡 | 甲方在核什么 | 你要提供什么 |
|---|---|---|
| 能不能做 | 同类经验、技术栈 | 能力清单与案例 |
| 靠不靠谱 | 流程、管理、沟通 | 交付流程说明 |
| 多少钱 | 报价结构与隐藏成本 | 报价说明 |
| 后续 | 维护、源码、接手 | 售后与知识产权说明 |
技术栈：写清「用什么」和「为什么」
技术栈是外包公司的能力标签，但多数公司只列一堆名词，不说用途。
有效写法是分层：前端（框架与适配范围）、后端（语言与框架、并发能力）、数据库（关系型与缓存）、部署（云、私有化、容器化）、移动端（原生、跨平台）、集成（第三方接口与支付、短信、地图等）。每层写清用什么、适用什么场景。
更重要的是「为什么选它」。比如「管理后台用 Vue 而非 React，因为团队在该栈上有更成熟的组件库，交付周期更可控」。这种说明让甲方看到判断力，而不是一份技术词表。技术栈谁都能列，选型理由才是经验。
| 层级 | 写什么 | 价值 |
|---|---|---|
| 前端 | 框架 + 适配范围 | 判断体验与兼容 |
| 后端 | 语言、框架、并发 | 判断性能上限 |
| 数据 | 数据库与缓存方案 | 判断数据规模 |
| 部署 | 云/私有化/容器 | 判断运维方式 |
| 集成 | 已对接的第三方 | 减少重复开发 |
交付流程：外包行业最该公开的东西
甲方对外包最大的担心是「做到一半烂尾」。交付流程写得越清楚，这个担心越小。
可写的阶段：需求梳理（产出需求文档与原型）、技术方案（产出架构设计与工期评估）、开发（分迭代交付，每迭代可验收）、测试（功能、兼容、性能）、上线（部署、数据迁移、培训）、维护（质保期与响应时限）。
每个阶段写清三件事：产出什么文档、需要甲方配合什么、大概多长时间。特别是「需要甲方配合什么」—— 外包项目延期，八成原因在甲方侧的需求变更或资料不到位。提前写清配合事项，能显著降低后期扯皮。
| 阶段 | 产出 | 甲方配合 |
|---|---|---|
| 需求梳理 | 需求文档、原型 | 业务确认、决策人参与 |
| 技术方案 | 架构设计、工期评估 | 确认范围与优先级 |
| 开发 | 迭代版本 | 按迭代验收 |
| 测试 | 测试报告 | 参与 UAT |
| 上线 | 部署与培训 | 提供环境与账号 |
报价结构：把「为什么差这么多」讲清
外包报价的差异极大，甲方最大的困惑是「同样的需求，为什么一家报 8 万一家报 30 万」。
要拆开讲：人力成本（人天 × 单价，按角色分：产品、设计、前端、后端、测试）、项目管理成本、需求变更的处理方式、第三方费用（服务器、短信、支付、地图接口）、维护费用（质保期后怎么算）。
「需求变更怎么算」这一项最值得写。外包纠纷多数源于变更，写清变更的评估方式（按人天折算、需签补充协议）能避免大量争议。愿意把这条写在前面的公司，通常项目管理更规范。
| 报价项 | 写法 | 注意 |
|---|---|---|
| 人力 | 按角色给人天单价 | 区分角色 |
| 管理 | 占比或固定 | 不要隐藏 |
| 变更 | 评估方式与流程 | 提前约定 |
| 第三方 | 按实际或预估 | 明确承担方 |
| 维护 | 质保期 + 后续费率 | 写清起算点 |
案例与知识产权：两个必须写清的点
案例写法：不写客户名（多数有保密约定），写清行业、系统类型、核心功能、技术栈、团队规模、周期、遇到的难点与解决方式。难点这一段最有说服力，因为它证明你处理过复杂情况。
知识产权写法：源码是否交付、交付范围（全部还是部分）、是否可二次开发、是否限制转售、文档是否齐全。这几项在外包谈判里经常被含糊过去，结果是上线后甲方发现拿不到源码。提前写清，反而更容易成交 —— 因为它解决了甲方最大的不安全感。
| 项目 | 写什么 | 价值 |
|---|---|---|
| 案例 | 行业、类型、难点、周期 | 证明能力 |
| 源码 | 是否交付、范围 | 消除顾虑 |
| 二次开发 | 是否允许、限制 | 明确边界 |
| 文档 | 交付哪些文档 | 便于接手 |
团队与协作：甲方最担心「人换了」
外包项目的常见失败原因不是技术不行，而是人换了。前期对接的是资深架构师，实际开发换成新人，需求理解断层，返工不断。
可写的内容：项目团队的构成（产品、设计、前端、后端、测试各几人）、核心成员的经验与角色分工、对接方式（谁是对接人、多久同步一次进展）、人员变动时的交接机制。
「人员变动时的交接机制」这一项最能让甲方安心。写清代码规范、文档要求、交接流程，说明即使换人也不会失控。这类内容看起来不性感，但对甲方来说是真实顾虑，写出来的公司极少，写清就是差异化。
| 内容 | 写什么 | 价值 |
|---|---|---|
| 团队构成 | 角色与人数 | 判断投入 |
| 核心成员 | 经验与分工 | 判断能力 |
| 同步机制 | 对接人与频率 | 降低沟通成本 |
| 交接机制 | 文档与流程 | 消除换人顾虑 |
边界说明
本文给的是信息呈现方法，不涉及对签约量或交付质量的承诺。软件项目受需求清晰度、变更频率、甲方配合程度多重因素影响。
技术栈、交付周期、报价与知识产权条款的对外表述，须与实际能力和合同约定一致；不得对未确定的需求作固定工期与固定总价承诺。
常见问题
外包公司做 GEO，甲方真的会搜吗？
会。甲方在立项阶段会先做一轮供应商筛选，看技术栈、案例类型、交付流程。这一轮的信息缺失，往往连演示机会都拿不到。
技术栈写太细会不会暴露底牌？
不会。技术栈是公开信息，同行本来就知道。真正的竞争力在团队、流程与行业理解。写清选型理由反而是加分项。
案例不能写客户名怎么办？
写行业、系统类型、功能范围、技术栈、周期、难点与解决方式。这些足以证明能力，也不违反保密约定。难点部分尤其有价值。
工期怎么承诺才安全？
给区间并注明前提（需求确认后、甲方配合到位）。不建议给固定日期，需求变更是外包项目的常态，写死日期会带来履约风险。
源码要不要交付？
建议交付，或至少写清交付范围。甲方最担心的是被锁定，写清知识产权归属能显著提高信任。不交付的，要在报价和合同里明确说明。
多久能看到效果？
内容上线后通常 6–10 周开始出现在「XX 系统开发」这类问句里。外包决策周期通常一到三个月。
延伸阅读
- 软件开发公司做 GEO 优化多少钱？外包、SaaS、行业方案商的预算差别
- Android开发公司拓客、智慧园区方案商询盘：AI 如何读取并采信你的技术内容
- SaaS 厂商怎么让采购在 AI 里找到你？功能对比与选型清单怎么写
- 南京软件与SaaS企业GEO：在企业数字化选型中脱颖而出
关于本文 本文由南京千百顺信息技术有限公司 GEO 研究组整理，用于帮助企业判断自身在生成式搜索场景下的信息呈现问题。文中涉及的价格区间为公开市场常见结构，用于判断量级，不代表任何服务商的正式报价；平台机制描述依据各平台公开帮助文档与公开可观察结果（整理时点 2026 年 11 月），平台规则可能调整，请以实际查询为准。本文不构成对任何平台收录结果、推荐位置或商业收益的承诺。针对自身业务做诊断，可联系 gaojian@gjsk.cn。