--- title: "微型机构还是中型机构：2026 年合作方规模" canonical: https://wavect.io/zh/blog/micro-agency-vs-mid-size-software-partner-2026/ language: zh description: "软件开发合作方该有多大？团队规模的研究证据、2026 年机构利润数据、关键人员风险，以及如何评估一个 3 到 7 人的团队。" image: "https://wavect.io/img/blog/headers/header_micro-agency-vs-mid-size-software-partner-2026.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年8月18日 最近审核 2026年8月18日 [**下一篇**](/zh/blog/software-agency-proposal-teardown/) # 微型机构还是中型机构：2026 年你的软件合作方该有多大？ 要点速览 对于典型的定制开发，动你代码的团队应在三到七人之间，而这家公司要能为系统的每个关键部分指定第二个人。QSM 对 491 个已完成项目的分析发现三到七人团队表现最好，投入增长从约九人起明显转为非线性，Brooks 的 n(n-1)/2 解释了原因。AI 改变的是小团队能产出多少，而不是协作的数学：Google 2025 年的 DORA 研究发现 AI 采用度与吞吐量正相关、与交付稳定性负相关；2026 年第一季度一项针对 250 家机构的调研发现，预测智能体能否进入生产的是创始人姿态而非人数。一人机构失败的地方不是产出，而是校准与延续性，因为单人合作在合同上保证了 truck factor 为 1。四个合同条款可以填补这一缺口：每个关键组件有指定的第二人、披露分包方并向下传导义务、每个领域有指定评审人，以及代码仓库、云与许可都在你自己的账户下。 代理机构行业眼下正吵得很热。一派认为一人机构才是未来，因为一个人加上自主智能体就能覆盖策略、设计、编码与 QA。另一派认为真正的赢家是微型机构：三到五位有经验的人，用 AI 交付过去需要四十人公司才能交付的东西；而带着部门、流程和交接规则的中型机构才是被夹住的那一类。 两派争的都是自己的商业模式。如果你是买软件的一方，问题应该换个提法，也更有用：**你的合作方到底需要多少人，每一种规模你又会失去什么？**本文用交付研究的证据、2026 年的机构经济数据，以及决定「小团队是便宜货还是单点故障」的合同条款来回答。 ## 软件开发合作方应该有多大？ 对于典型的定制开发，真正动你代码的团队应在三到七人之间，同时这家公司要大到能为系统的每个关键部分指定第二个人。低于这个规模，你买的是一个人的可用时间。高于这个规模，多出来的人头主要买到的是峰值产能、专家储备和采购上的安全感，而不是交付速度。AI 改变的是小团队能产出多少，它不改变协作的数学，也不能替代那个愿意反驳第一个人的第二位资深人士。 ## 关于团队规模，交付研究到底说了什么？ 这场辩论里最有力的数字比 AI 周期早了十多年。Quantitative Software Management 分析了 **491 个已完成项目**，代码规模在 35,000 到 95,000 行新增或修改的源代码之间，平均项目规模 57,412 有效 SLOC，并按团队规模分成五档。 | 团队规模 | 491 个项目样本呈现的结果 | | --- | --- | | 1.5 至 3 人 | 总投入低，但工期表现弱于中间档 | | 3 至 5 人 | 生产率指数最好，工期表现紧随其后 | | 5 至 7 人 | 工期表现最好，生产率紧随其后 | | 7 至 9 人 | 生产率明显下降，投入上升 | | 9 至 11 人 | 投入增长明显转为非线性 | QSM 的结论很直白：对中等规模的信息系统，三到七人的团队表现最好，较小的团队比较大的团队高出两个或更多生产率指数，而极端的非线性投入增长要到团队接近九人以上才出现。QSM 另一项对比最佳与最差项目的研究发现，表现最好的项目所用团队平均小约四倍。 机制既古老又不炫目。Brooks 在 1975 年就写过：两两沟通路径按 n(n-1)/2 增长，而软件任务很少能干净地切分。在读一份承诺十二个人的报价前，值得先把这个公式记住。 | 交付团队人数 | 两两沟通路径 | | --- | --- | | 3 | 3 | | 5 | 10 | | 7 | 21 | | 12 | 66 | | 40 | 780 | 四十人的公司当然不会真的进行 780 场对话。它用流程、部门和交接把大部分对话压掉，而这种压制恰恰是客户体验到的：变更控制迟缓、客户经理从未写过这份代码、一个开发者十分钟就能回答的问题要等两周。 ## 为什么 AI 在 2026 年压缩了机构的人头？ 因为 AI 接走了原本用来支撑初级岗位的大量常规执行工作，而且速度快于机构自我改造的速度。Forrester 的 2026 年预测给出了数字：在 2025 年平均裁员 8% 之后，它预测 **2026 年机构岗位再减少 15%**，并预期机构会改变商业模式而不只是缩编。 利润数据指向同一方向。Promethean Research 于 2026 年 2 月对数字机构的所有者与管理者进行了调研（N=119），发布了《2026 State of Digital Services》。样本中的平均机构规模为 31 人，2025 年平均税后净利率为 13%。按规模拆开看才是关键。 | 机构规模 | 2025 年平均税后净利率 | | --- | --- | | 10 人以下的小工作室 | 19% | | 行业平均 | 13% | | 50 人及以上的机构 | 8% | Promethean 还统计出北美有超过 71,000 家数字机构，其中 87% 员工少于 50 人。所以「中型被夹住」这个说法背后是有真实数字的，而且小规模早已是常态，不是例外。 **请诚实地读这些数字。**Forrester 的预测和 Promethean 的调研覆盖的都是营销与数字机构，而不是软件工程公司，而且 Promethean 的样本是 119 份自选择回答。它们能告诉你经济性倾向何方，但不是软件交付合作方的基准；谁把它们当基准报给你，就是在夸大。 ## 机构规模能预测它用 AI 的水平吗？ 不能，而这正是买方应该采取行动的发现。2026 年第一季度一项针对 250 家、员工规模 8 到 180 人的机构的调研发现，41% 至少有一个智能体投入生产，一年前这个比例是 9%，自报 ROI 中位数为 3.2 倍。它自己的结论是：区分领先者的是创始人的姿态和重建交付流程的意愿，而不是营收或人数。同一样本中两家四十人规模的机构，智能体部署情况完全不同。 这份调研本身也是一堂「如何读 AI 宣传」的课。作者用 47 家机构的账单数据核对自报数字后发现，ROI 被高报约 18%，token 支出被低报约 24%，而且样本本身偏向已经对智能体感兴趣的机构。无论出自单人操作者还是中型公司，任何「我们用 AI 交付十倍」的说法都该被当成需要证据的主张。我们自己关于 [在 token 预算内运行编码智能体](/zh/blog/smarter-token-usage-with-your-ai-coding-agent/) 的实践记录说明了真正的杠杆是什么：缓存设计、路由与上下文纪律，而不是一个抢眼的倍数。 Google 2025 年的 DORA 研究，样本接近 5,000 名技术从业者，为这一切划出了上限。约 90% 的人在工作中使用 AI，超过 80% 认为它提升了生产率，但约 30% 表示对 AI 生成的代码几乎没有信任。DORA 发现 AI 采用度与交付吞吐量正相关，与交付稳定性负相关。其核心结论是：AI 是放大器，它放大组织本来的样子。一个有纪律的微型团队放大纪律；一个评审习惯薄弱的合作方放大的则是那份薄弱，而且更快。 ## 一人机构真正会在哪里出问题？ 不在产出，而在校准与延续性。 **校准。**METR 在 2025 年初的对照研究中，让熟悉自己代码库的资深开源开发者使用 AI 辅助，结果他们多花了 19% 的时间，而事前预期是加速 24%，事后感知是加速 20%。无论今天真实效应有多大（METR 2026 年的更新解释了为什么这已很难干净测量），这个感知落差是持久的发现。AI 提升信心的速度快于提升正确性的速度。最便宜的纠偏方式，是第二位有经验的人愿意说出「这个设计撑不过第二个客户」。这是「两位或更多资深人士」的结构性理由，也是微型机构论点中最站得住的部分。 **延续性。**研究上的术语是 truck factor，或 bus factor：需要多少人突然消失，项目才会停摆。Avelino 等人对 133 个热门 GitHub 应用做了估算，发现**65% 的项目 truck factor 不超过 2**，其中 46% 为 1。在验证回复中，他们的估算与开发者的实际情况在 84% 的情况下一致。一人机构不只是让你的项目面临 truck factor 为 1 的风险，而是在整个合作期内以合同形式保证了这一点。 对某些工作来说这是可以接受的。一次四周的集成、一个原型、一个范围清楚的内部工具：强的单人操作者往往是最快也最便宜的路径，硬说不是反而不诚实。但对一个需要在生产环境运行数年、需要移交给别人、或需要通过技术尽调的系统，就不可接受。这两种情形之间的差距，就是整个采购决策。 ## 单人、微型、中型、大型：买方视角的对比 | 合作方形态 | 你实际得到什么 | 会在哪里失效 | 最适合 | | --- | --- | --- | --- | | **单人操作者** 1 人 | 直接接触真正干活的人，没有协作成本，同等资历下费率最低 | truck factor 为 1，没有同级评审，生病或另有客户时无人接手，缺少专业深度 | 原型、单一服务集成、范围明确的短期工作、为已有资深评审的团队补充人力 | | **微型机构** 3 至 7 人 | 团队内部有资深同级评审，处于 QSM 的生产率最优区间，界定范围的人也是动手构建的人 | 峰值产能有限，专业空缺靠分包补齐，难以满足采购问卷与认证要求 | 定制产品、必须上生产的 MVP、由小型固定团队维护多年的系统、救援与接管工作 | | **中型机构** 20 至 80 人 | 多条并行工作流、正式角色、成文流程 | 协作开销、你这个客户上的资历被稀释、投标团队很少是交付团队、2026 年数据中利润最薄 | 需要多支并行团队的项目群，采购要求组织纵深的买方 | | **大型公司** 200 人以上 | 人力保证、认证、值班轮岗、合同上的谈判力、多国上线 | 成本、变更延迟，以及你的工作可能交给最初级的可用人员 | 受监管的多年期项目群、有正式供应商要求的招标、任何需要在数周内投入 20 人以上工程师的场景 | 如果你还没决定前置的采购模式问题，我们的 [自由职业者、机构与自建团队对比指南](/zh/software-development-guide/freelancer-vs-agency-vs-in-house/) 用奥地利的成本情景讲了那个决策。本文假设你已决定向外部公司采购，现在只需决定这家公司该有多大。 ## 小型合作方失败的四种方式，以及各自对应的条款 反对雇用三到七人团队的所有顾虑，都可归为四类风险。每一类都有具体、可核查的合同答案。如果小型合作方不能把这四点写下来，顾虑是成立的；如果能，规模之争基本就消失了。 | 风险 | 你要求什么 | 真正的回答长什么样 | | --- | --- | --- | | 关键人员不可用 | 每个关键组件都有指定的第二人，以及有文档记录的当前状态 | 数据库、部署、认证与集成各有两个人名；架构决策记录放在代码仓库里；主要负责人无法联系时的书面响应时限 | | 峰值产能 | 在合作方自己的 [工作说明书](/zh/glossary/sow/) 下披露分包方，并向下传导义务 | 列明专家的姓名、角色、所在地与访问级别；保密、安全、知识产权与 GDPR 第 28 条处理者条款向下传导；一份合同、一张发票；合作方仍对质量负责 | | 专业深度 | 由谁评审安全、隐私与扩展性，要有姓名也要有证据 | 每个领域有指定评审人及其产出的交付物，并诚实说明公司没有哪些认证 | | 这家公司消失了 | 所有权与可运维性不依赖合作方 | 版本控制、云与 CI 都在你机构的账户下，许可在你名下，凭据在你的密钥库中，交接包经过实测而不是一句"会提供文档" | 第四行是买方最常跳过、日后付出代价的一行。我们的 [软件交接清单](/zh/software-development-guide/software-handover-checklist/) 是它的交付物级版本，而 [软件机构报价拆解](/zh/blog/software-agency-proposal-teardown/) 展示了这些义务如何在一份读起来很顺的报价里被悄悄谈掉。如果你已在合作中途而这些答案缺失， [30 天更换供应商计划](/zh/blog/software-project-takeover-provider-change/) 是恢复路径。 ## 如何在一次通话中评估一家微型机构？ 十个问题，按这个顺序。要听的模式是：回答里有没有具体的人、交付物或日期。由形容词组成的回答不算回答。 1. **我的项目由谁写代码，这个人在这次通话里吗？** 真正的微型机构答案是「在」；中型公司通常不在。 2. **谁评审他的工作，你们两人在设计上意见不一致时会怎样？** 没有指定评审人，是小团队交付最大的缺口。 3. **把你上一次的交接给我看看。** 做过脱敏没问题。这里含糊，就预示着锁定。 4. **AI 智能体在你的交付流程里跑在哪一段，合并前由人检查什么？** 要看评审关卡、测试和对生成代码的策略，而不是工具名称。 5. **针对我这类系统，你的测试与发布流程是什么？** 把回答对照 [上线前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) ，而不是对照对方的自信。 6. **这个项目里有哪些部分超出你的深度，谁来补？** 声称没有短板的公司，一定有一块没告诉你。 7. **如果你的主力工程师缺席三周，我的项目会怎样？** 要机制，不要安慰。 8. **代码仓库、云、CI 和域名在谁的账户下？** 从第一周起就该是你的。 9. **什么情况下你会拒接这个项目？** 没有拒接标准的合作方，卖的是产能。 10. **变更如何计价与审批？** 固定价和 [按工时计费](/zh/glossary/time-and-material/) 都能行，无人负责的变更控制不行。 更完整的评估流程，包括参考访谈与如何筛选短名单，见我们的 [软件机构选择指南](/zh/software-development-guide/how-to-choose-a-software-agency/) 。 ## 什么时候更大的合作方仍然是对的答案？ 小并不自动更好，微型机构论点的诚实版本也有边界。以下情况选择规模： - 你需要在数周内让大约二十名以上工程师并行工作，而工作确实可以切分； - 采购要求认证、经审计的流程或保险额度，而小公司并不具备； - 你需要合同约定的全天候值班，而不是尽力而为的资深可用性； - 项目群同时涉及多个国家、监管机构或业务单元； - 你自己的组织不会指派一个能拍板的人。这种情况下你买的是流程和客户管理，那就有意识地去买。 最后一点值得说清楚。小型资深团队之所以快，是因为决策在一次对话里就完成。如果你这一侧没人能做这些决策，速度优势就消失了，而你省掉的那层协作，必须在合同的你这一侧重新建起来。 ## Wavect 是如何组织的，以及为什么 Wavect 是有意做成创始人主导的工作室。两位董事总经理都亲自交付，所以界定范围的人就是动手构建的人，设计上的分歧发生在两位资深人士之间，而不是落到你的代码里。此前已与我们一起交付过生产工作的专家，以分包方身份在 Wavect 自己的工作说明书下加入：一份合同、一张发票、一个负责方，而不是把你转介给一个网络。代码仓库、云与 CI 从一开始就在客户的账户下。 我们没有 ISO 27001，也不提供合同约定的全天候 SLA。如果你的采购流程要求其中任何一项，更大的公司才是正确选择，我们会在第一次通话时直说。如果并不要求，你做的取舍是：人更少，换来资深连续性与直接接触。想看这在真实系统上是什么样子，可以看 [Bond Analytics 案例](/zh/case-studies/bond-analytics/) ，或与 [通用型开发机构](/zh/compare/wavect-vs-dev-agencies/) 以及 [通过自由职业平台采购](/zh/compare/wavect-vs-freelance-platforms/) 逐项对比。 ## 常见问题 ### 什么是微型机构？ 微型机构是由大约三到七位有经验的从业者组成、且没有独立交付层的公司：卖出这份工作的人也在做这份工作。它与单人操作者的区别在于，同级评审、人员替补和第二位资深意见都存在于团队内部；与中型机构的区别在于，客户与真正构建的人之间没有部门、客户经理或内部交接。 ### 一个软件项目应该有多少名开发者？ 对中等规模系统，交付团队三到七人是有证据支持的区间。QSM 对 35,000 到 95,000 行代码区间内 491 个已完成项目的分析发现，三到七人团队表现最好，三到五人在生产率上最强，五到七人在工期上最强，而极端的非线性投入增长要到约九人才出现。 ### 一人机构能交付生产级软件吗？ 对范围窄、周期短的工作，往往可以。结构性问题在于校准与延续性：设计决策没有同级评审，整个合作期的 truck factor 为 1。一项针对 133 个热门开源应用的研究发现，其中 65% 的 truck factor 已不超过 2，所以这是常见失效模式而非假设。对必须运行多年或需通过尽调的系统，请坚持要有指定的第二人。 ### 小型软件机构比大公司风险更高吗？ 它承担的是不同的风险。小公司集中了关键人员风险与峰值产能风险；大公司集中了成本、变更延迟，以及你的工作落到最初级可用人员手上的风险。两者都能靠合同管理。对小型合作方，请覆盖四个具体点：每个关键组件有指定的第二人、披露分包方并向下传导义务、每个领域有指定评审人，以及代码仓库、云与许可的所有权在你这一侧。 ### AI 是否意味着小机构能交付过去大公司交付的东西？ 部分意味着，但原因不是人数。2026 年第一季度一项针对 250 家机构的调研发现，区分「已有智能体投入生产」的机构的是创始人姿态与重建交付流程的意愿，而不是营收或人数。Google 2025 年的 DORA 研究发现 AI 采用度与交付吞吐量正相关、与交付稳定性负相关，并得出结论：AI 放大组织既有的强项与弱项。小而有纪律扩展得很好；小而无纪律失败得更快。 ### 为什么中型机构承受的压力最大？ 它们承担了规模带来的协作成本，却没有规模带来的合同优势。Promethean Research 于 2026 年 2 月对 119 位机构负责人的调研发现，10 人以下的工作室 2025 年平均税后净利率为 19%，而 50 人及以上的机构为 8%；Forrester 预测 2026 年机构岗位减少 15%，此前 2025 年平均已减少 8%。两组数据覆盖的都是营销与数字机构而非软件工程公司，所以请把它们当方向读，而不是当软件基准。 ### 什么是 bus factor 或 truck factor，买方为什么该关心？ 它是指多少人突然不可用就会让项目停摆。它之所以重要，是因为这是合同语言能低成本修复、而买方几乎总是发现太晚的那一类供应商风险。请要求每个关键组件两个人名、代码仓库内的决策记录，以及经过实测的交接包，而不是一句提供文档的承诺。 ### 如何比较微型机构与中型机构的报价？ 把两份报价都归一到首年可比成本，以及谁真正做这份工作。把被排除的工作、托管、许可、你自己团队需要投入的工作量和预期的退出成本加回去。然后比较实际分配人员的资历、评审安排、列明的分包方以及交接义务。大公司较低的表面报价，往往反映的是更初级的分配团队。 ## 参考来源与核对 本文所有数据均于 2026 年 8 月 18 日在原始来源核对。Forrester 与 Promethean 的数据描述的是营销与数字代理机构，而非软件工程公司：可作方向参考，不可当作软件交付基准。 - [QSM《Team Size Can Be the Key to a Successful Software Project》](https://www.qsm.com/team-size-can-be-key-successful-software-project) ：491 个已完成项目，35,000 至 95,000 SLOC，团队规模分为 1.5 到 11 人五档，3 到 7 人表现最佳。 - [QSM《Top Performing Projects Use Small Teams》](https://www.qsm.com/blog/2012/top-performing-projects-use-small-teams) ：表现最好的项目平均使用的团队规模约小四倍。 - [Forrester《Predictions 2026: Marketing Agencies Resign Their Agency》](https://www.forrester.com/blogs/predictions-2026-marketing-agencies-resign-their-agency/) ：2025 年平均裁员 8% 之后，预测 2026 年再减少 15%。 - [Promethean Research《2026 State of Digital Services》](https://prometheanresearch.com/2026-state-of-digital-services-digital-agency-industry-research/) ：2026 年 2 月调研，N=119，平均规模 31 人，2025 年税后净利率 13%。 - [Google DORA《State of AI-assisted Software Development 2025》](https://dora.dev/dora-report-2025/) ：近 5,000 名从业者，AI 是放大器，与交付吞吐量正相关、与交付稳定性负相关。 - [METR《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) ：实际耗时增加 19%，而事前预期与事后感知均为加速；另见 [2026 年 2 月的更新](https://metr.org/blog/2026-02-24-uplift-update/) 。 - [Avelino、Passos、Hora 与 Valente《A Novel Approach for Estimating Truck Factors》](https://arxiv.org/abs/1604.06766) ：133 个热门 GitHub 应用中，65% 的 truck factor 不超过 2，其中 46% 为 1。 - [Digital Applied《Agentic AI Adoption Survey Q1 2026》](https://www.digitalapplied.com/blog/agentic-ai-adoption-survey-2026-250-agencies) ：250 家 8 到 180 人的代理机构，41% 已有代理投入生产，自报数据与 47 家机构的账单数据交叉验证。 ## 最终思考 一人机构与微型机构之争，是卖方之间的辩论。买方版本更简单，也比 AI 周期更古老：三到七人是交付研究认为工作进行得最好的区间，而真正重要的门槛是，能否有第二位有经验的人承担你系统的每个关键部分。 AI 改变了小团队能产出多少，它不改变协作的数学，而且证据显示它拉大了「人们认为自己交付了什么」与「实际交付了什么」之间的差距。这是支持资深同级评审的理由，而不是取消第二个人的理由。按评审与延续性来给合作方定规模，把四类风险写进合同，人头这个问题基本就自己有答案了。 ## 你可能也喜欢.. [**软件机构报价拆解：改变价格、范围与所有权的 12 个条款** 定好规模之后，去读那份文件。决定价格、可用范围与所有权的十二个条款，附评分表。](/zh/blog/software-agency-proposal-teardown/) [**Wavect 对比通用型开发机构** 创始人主导的资深连续性与产能导向交付，逐项对比。](/zh/compare/wavect-vs-dev-agencies/) AI 增强团队 ## 继续浏览此集群 当 AI 改变软件工作方式时的团队设计、采用与管理。 [从核心文章开始**如何在 2026 年把 AI 落地到团队内部**](/zh/blog/internal-ai-adoption-2026/) - [Vibe Coder 是新一代初级开发者吗？](/zh/blog/vibe-coders-new-junior-developers/) - [如何在 2026 年把 AI 落地到团队内部](/zh/blog/internal-ai-adoption-2026/) - [专注力是新的瓶颈](/zh/blog/focus-bottleneck-orchestrating-ai-agents/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年8月18日 最近审核 2026年8月18日 [**下一篇**](/zh/blog/software-agency-proposal-teardown/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/micro-agency-vs-mid-size-software-partner-2026/#webpage", "@type": "WebPage", "dateModified": "2026-08-18", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-18", "url": "https://wavect.io/zh/blog/micro-agency-vs-mid-size-software-partner-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "对于典型的定制开发，动你代码的团队应在三到七人之间，而这家公司要能为系统的每个关键部分指定第二个人。QSM 对 491 个已完成项目的分析发现三到七人团队表现最好，投入增长从约九人起明显转为非线性，Brooks 的 n(n-1)/2 解释了原因。AI 改变的是小团队能产出多少，而不是协作的数学：Google 2025 年的 DORA 研究发现 AI 采用度与吞吐量正相关、与交付稳定性负相关；2026 年第一季度一项针对 250 家机构的调研发现，预测智能体能否进入生产的是创始人姿态而非人数。一人机构失败的地方不是产出，而是校准与延续性，因为单人合作在合同上保证了 truck factor 为 1。四个合同条款可以填补这一缺口：每个关键组件有指定的第二人、披露分包方并向下传导义务、每个领域有指定评审人，以及代码仓库、云与许可都在你自己的账户下。", "articleBody": " 博客概览/领导力与团队/AI 增强团队 微型机构还是中型机构：2026 年你的软件合作方该有多大？ 要点速览 对于典型的定制开发，动你代码的团队应在三到七人之间，而这家公司要能为系统的每个关键部分指定第二个人。QSM 对 491 个已完成项目的分析发现三到七人团队表现最好，投入增长从约九人起明显转为非线性，Brooks 的 n(n-1)/2 解释了原因。AI 改变的是小团队能产出多少，而不是协作的数学：Google 2025 年的 DORA 研究发现 AI 采用度与吞吐量正相关、与交付稳定性负相关；2026 年第一季度一项针对 250 家机构的调研发现，预测智能体能否进入生产的是创始人姿态而非人数。一人机构失败的地方不是产出，而是校准与延续性，因为单人合作在合同上保证了 truck factor 为 1。四个合同条款可以填补这一缺口：每个关键组件有指定的第二人、披露分包方并向下传导义务、每个领域有指定评审人，以及代码仓库、云与许可都在你自己的账户下。 代理机构行业眼下正吵得很热。一派认为一人机构才是未来，因为一个人加上自主智能体就能覆盖策略、设计、编码与 QA。另一派认为真正的赢家是微型机构：三到五位有经验的人，用 AI 交付过去需要四十人公司才能交付的东西；而带着部门、流程和交接规则的中型机构才是被夹住的那一类。 两派争的都是自己的商业模式。如果你是买软件的一方，问题应该换个提法，也更有用：你的合作方到底需要多少人，每一种规模你又会失去什么？本文用交付研究的证据、2026 年的机构经济数据，以及决定「小团队是便宜货还是单点故障」的合同条款来回答。 软件开发合作方应该有多大？ 对于典型的定制开发，真正动你代码的团队应在三到七人之间，同时这家公司要大到能为系统的每个关键部分指定第二个人。低于这个规模，你买的是一个人的可用时间。高于这个规模，多出来的人头主要买到的是峰值产能、专家储备和采购上的安全感，而不是交付速度。AI 改变的是小团队能产出多少，它不改变协作的数学，也不能替代那个愿意反驳第一个人的第二位资深人士。 关于团队规模，交付研究到底说了什么？ 这场辩论里最有力的数字比 AI 周期早了十多年。Quantitative Software Management 分析了 491 个已完成项目，代码规模在 35,000 到 95,000 行新增或修改的源代码之间，平均项目规模 57,412 有效 SLOC，并按团队规模分成五档。 团队规模491 个项目样本呈现的结果 1.5 至 3 人总投入低，但工期表现弱于中间档 3 至 5 人生产率指数最好，工期表现紧随其后 5 至 7 人工期表现最好，生产率紧随其后 7 至 9 人生产率明显下降，投入上升 9 至 11 人投入增长明显转为非线性 QSM 的结论很直白：对中等规模的信息系统，三到七人的团队表现最好，较小的团队比较大的团队高出两个或更多生产率指数，而极端的非线性投入增长要到团队接近九人以上才出现。QSM 另一项对比最佳与最差项目的研究发现，表现最好的项目所用团队平均小约四倍。 机制既古老又不炫目。Brooks 在 1975 年就写过：两两沟通路径按 n(n-1)/2 增长，而软件任务很少能干净地切分。在读一份承诺十二个人的报价前，值得先把这个公式记住。 交付团队人数两两沟通路径 33 510 721 1266 40780 四十人的公司当然不会真的进行 780 场对话。它用流程、部门和交接把大部分对话压掉，而这种压制恰恰是客户体验到的：变更控制迟缓、客户经理从未写过这份代码、一个开发者十分钟就能回答的问题要等两周。 为什么 AI 在 2026 年压缩了机构的人头？ 因为 AI 接走了原本用来支撑初级岗位的大量常规执行工作，而且速度快于机构自我改造的速度。Forrester 的 2026 年预测给出了数字：在 2025 年平均裁员 8% 之后，它预测 2026 年机构岗位再减少 15%，并预期机构会改变商业模式而不只是缩编。 利润数据指向同一方向。Promethean Research 于 2026 年 2 月对数字机构的所有者与管理者进行了调研（N=119），发布了《2026 State of Digital Services》。样本中的平均机构规模为 31 人，2025 年平均税后净利率为 13%。按规模拆开看才是关键。 机构规模2025 年平均税后净利率 10 人以下的小工作室19% 行业平均13% 50 人及以上的机构8% Promethean 还统计出北美有超过 71,000 家数字机构，其中 87% 员工少于 50 人。所以「中型被夹住」这个说法背后是有真实数字的，而且小规模早已是常态，不是例外。 请诚实地读这些数字。Forrester 的预测和 Promethean 的调研覆盖的都是营销与数字机构，而不是软件工程公司，而且 Promethean 的样本是 119 份自选择回答。它们能告诉你经济性倾向何方，但不是软件交付合作方的基准；谁把它们当基准报给你，就是在夸大。 机构规模能预测它用 AI 的水平吗？ 不能，而这正是买方应该采取行动的发现。2026 年第一季度一项针对 250 家、员工规模 8 到 180 人的机构的调研发现，41% 至少有一个智能体投入生产，一年前这个比例是 9%，自报 ROI 中位数为 3.2 倍。它自己的结论是：区分领先者的是创始人的姿态和重建交付流程的意愿，而不是营收或人数。同一样本中两家四十人规模的机构，智能体部署情况完全不同。 这份调研本身也是一堂「如何读 AI 宣传」的课。作者用 47 家机构的账单数据核对自报数字后发现，ROI 被高报约 18%，token 支出被低报约 24%，而且样本本身偏向已经对智能体感兴趣的机构。无论出自单人操作者还是中型公司，任何「我们用 AI 交付十倍」的说法都该被当成需要证据的主张。我们自己关于在 token 预算内运行编码智能体的实践记录说明了真正的杠杆是什么：缓存设计、路由与上下文纪律，而不是一个抢眼的倍数。 Google 2025 年的 DORA 研究，样本接近 5,000 名技术从业者，为这一切划出了上限。约 90% 的人在工作中使用 AI，超过 80% 认为它提升了生产率，但约 30% 表示对 AI 生成的代码几乎没有信任。DORA 发现 AI 采用度与交付吞吐量正相关，与交付稳定性负相关。其核心结论是：AI 是放大器，它放大组织本来的样子。一个有纪律的微型团队放大纪律；一个评审习惯薄弱的合作方放大的则是那份薄弱，而且更快。 一人机构真正会在哪里出问题？ 不在产出，而在校准与延续性。 校准。METR 在 2025 年初的对照研究中，让熟悉自己代码库的资深开源开发者使用 AI 辅助，结果他们多花了 19% 的时间，而事前预期是加速 24%，事后感知是加速 20%。无论今天真实效应有多大（METR 2026 年的更新解释了为什么这已很难干净测量），这个感知落差是持久的发现。AI 提升信心的速度快于提升正确性的速度。最便宜的纠偏方式，是第二位有经验的人愿意说出「这个设计撑不过第二个客户」。这是「两位或更多资深人士」的结构性理由，也是微型机构论点中最站得住的部分。 延续性。研究上的术语是 truck factor，或 bus factor：需要多少人突然消失，项目才会停摆。Avelino 等人对 133 个热门 GitHub 应用做了估算，发现65% 的项目 truck factor 不超过 2，其中 46% 为 1。在验证回复中，他们的估算与开发者的实际情况在 84% 的情况下一致。一人机构不只是让你的项目面临 truck factor 为 1 的风险，而是在整个合作期内以合同形式保证了这一点。 对某些工作来说这是可以接受的。一次四周的集成、一个原型、一个范围清楚的内部工具：强的单人操作者往往是最快也最便宜的路径，硬说不是反而不诚实。但对一个需要在生产环境运行数年、需要移交给别人、或需要通过技术尽调的系统，就不可接受。这两种情形之间的差距，就是整个采购决策。 单人、微型、中型、大型：买方视角的对比 合作方形态你实际得到什么会在哪里失效最适合 单人操作者 1 人 直接接触真正干活的人，没有协作成本，同等资历下费率最低 truck factor 为 1，没有同级评审，生病或另有客户时无人接手，缺少专业深度 原型、单一服务集成、范围明确的短期工作、为已有资深评审的团队补充人力 微型机构 3 至 7 人 团队内部有资深同级评审，处于 QSM 的生产率最优区间，界定范围的人也是动手构建的人 峰值产能有限，专业空缺靠分包补齐，难以满足采购问卷与认证要求 定制产品、必须上生产的 MVP、由小型固定团队维护多年的系统、救援与接管工作 中型机构 20 至 80 人 多条并行工作流、正式角色、成文流程 协作开销、你这个客户上的资历被稀释、投标团队很少是交付团队、2026 年数据中利润最薄 需要多支并行团队的项目群，采购要求组织纵深的买方 大型公司 200 人以上 人力保证、认证、值班轮岗、合同上的谈判力、多国上线 成本、变更延迟，以及你的工作可能交给最初级的可用人员 受监管的多年期项目群、有正式供应商要求的招标、任何需要在数周内投入 20 人以上工程师的场景 如果你还没决定前置的采购模式问题，我们的自由职业者、机构与自建团队对比指南用奥地利的成本情景讲了那个决策。本文假设你已决定向外部公司采购，现在只需决定这家公司该有多大。 小型合作方失败的四种方式，以及各自对应的条款 反对雇用三到七人团队的所有顾虑，都可归为四类风险。每一类都有具体、可核查的合同答案。如果小型合作方不能把这四点写下来，顾虑是成立的；如果能，规模之争基本就消失了。 风险你要求什么真正的回答长什么样 关键人员不可用 每个关键组件都有指定的第二人，以及有文档记录的当前状态 数据库、部署、认证与集成各有两个人名；架构决策记录放在代码仓库里；主要负责人无法联系时的书面响应时限 峰值产能 在合作方自己的工作说明书下披露分包方，并向下传导义务 列明专家的姓名、角色、所在地与访问级别；保密、安全、知识产权与 GDPR 第 28 条处理者条款向下传导；一份合同、一张发票；合作方仍对质量负责 专业深度 由谁评审安全、隐私与扩展性，要有姓名也要有证据 每个领域有指定评审人及其产出的交付物，并诚实说明公司没有哪些认证 这家公司消失了 所有权与可运维性不依赖合作方 版本控制、云与 CI 都在你机构的账户下，许可在你名下，凭据在你的密钥库中，交接包经过实测而不是一句\"会提供文档\" 第四行是买方最常跳过、日后付出代价的一行。我们的软件交接清单是它的交付物级版本，而软件机构报价拆解展示了这些义务如何在一份读起来很顺的报价里被悄悄谈掉。如果你已在合作中途而这些答案缺失，30 天更换供应商计划是恢复路径。 如何在一次通话中评估一家微型机构？ 十个问题，按这个顺序。要听的模式是：回答里有没有具体的人、交付物或日期。由形容词组成的回答不算回答。 我的项目由谁写代码，这个人在这次通话里吗？真正的微型机构答案是「在」；中型公司通常不在。 谁评审他的工作，你们两人在设计上意见不一致时会怎样？没有指定评审人，是小团队交付最大的缺口。 把你上一次的交接给我看看。做过脱敏没问题。这里含糊，就预示着锁定。 AI 智能体在你的交付流程里跑在哪一段，合并前由人检查什么？要看评审关卡、测试和对生成代码的策略，而不是工具名称。 针对我这类系统，你的测试与发布流程是什么？把回答对照上线前 QA 清单，而不是对照对方的自信。 这个项目里有哪些部分超出你的深度，谁来补？声称没有短板的公司，一定有一块没告诉你。 如果你的主力工程师缺席三周，我的项目会怎样？要机制，不要安慰。 代码仓库、云、CI 和域名在谁的账户下？从第一周起就该是你的。 什么情况下你会拒接这个项目？没有拒接标准的合作方，卖的是产能。 变更如何计价与审批？固定价和按工时计费都能行，无人负责的变更控制不行。 更完整的评估流程，包括参考访谈与", "articleSection": "Leadership", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "QSM《Team Size Can Be the Key to a Successful Software Project》", "url": "https://www.qsm.com/team-size-can-be-key-successful-software-project" }, { "@type": "WebPage", "name": "QSM《Top Performing Projects Use Small Teams》", "url": "https://www.qsm.com/blog/2012/top-performing-projects-use-small-teams" }, { "@type": "WebPage", "name": "Forrester《Predictions 2026: Marketing Agencies Resign Their Agency》", "url": "https://www.forrester.com/blogs/predictions-2026-marketing-agencies-resign-their-agency/" }, { "@type": "WebPage", "name": "Promethean Research《2026 State of Digital Services》", "url": "https://prometheanresearch.com/2026-state-of-digital-services-digital-agency-industry-research/" }, { "@type": "WebPage", "name": "Google DORA《State of AI-assisted Software Development 2025》", "url": "https://dora.dev/dora-report-2025/" }, { "@type": "WebPage", "name": "METR《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》", "url": "https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/" }, { "@type": "WebPage", "name": "2026 年 2 月的更新", "url": "https://metr.org/blog/2026-02-24-uplift-update/" }, { "@type": "WebPage", "name": "Avelino、Passos、Hora 与 Valente《A Novel Approach for Estimating Truck Factors》", "url": "https://arxiv.org/abs/1604.06766" }, { "@type": "WebPage", "name": "Digital Applied《Agentic AI Adoption Survey Q1 2026》", "url": "https://www.digitalapplied.com/blog/agentic-ai-adoption-survey-2026-250-agencies" } ], "dateModified": "2026-08-18", "datePublished": "2026-08-18", "description": "对于典型的定制开发，动你代码的团队应在三到七人之间，而这家公司要能为系统的每个关键部分指定第二个人。QSM 对 491 个已完成项目的分析发现三到七人团队表现最好，投入增长从约九人起明显转为非线性，Brooks 的 n(n-1)/2 解释了原因。AI 改变的是小团队能产出多少，而不是协作的数学：Google 2025 年的 DORA 研究发现 AI 采用度与吞吐量正相关、与交付稳定性负相关；2026 年第一季度一项针对 250 家机构的调研发现，预测智能体能否进入生产的是创始人姿态而非人数。一人机构失败的地方不是产出，而是校准与延续性，因为单人合作在合同上保证了 truck factor 为 1。四个合同条款可以填补这一缺口：每个关键组件有指定的第二人、披露分包方并向下传导义务、每个领域有指定评审人，以及代码仓库、云与许可都在你自己的账户下。", "headline": "微型机构还是中型机构：2026 年你的软件合作方该有多大？", "image": "https://wavect.io/img/blog/headers/header_micro-agency-vs-mid-size-software-partner-2026.svg", "inLanguage": "zh", "keywords": "机构选择, 团队规模", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/micro-agency-vs-mid-size-software-partner-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/micro-agency-vs-mid-size-software-partner-2026/", "wordCount": 613 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/leadership-teams/", "name": "领导力与团队", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/ai-teams/", "name": "AI 增强团队", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/micro-agency-vs-mid-size-software-partner-2026/", "name": "微型机构还是中型机构：2026 年合作方规模 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "微型机构是由大约三到七位有经验的从业者组成、且没有独立交付层的公司：卖出这份工作的人也在做这份工作。它与单人操作者的区别在于，同级评审、人员替补和第二位资深意见都存在于团队内部；与中型机构的区别在于，客户与真正构建的人之间没有部门、客户经理或内部交接。" }, "name": "什么是微型机构？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "对中等规模系统，交付团队三到七人是有证据支持的区间。QSM 对 35,000 到 95,000 行代码区间内 491 个已完成项目的分析发现，三到七人团队表现最好，三到五人在生产率上最强，五到七人在工期上最强，而极端的非线性投入增长要到约九人才出现。" }, "name": "一个软件项目应该有多少名开发者？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "对范围窄、周期短的工作，往往可以。结构性问题在于校准与延续性：设计决策没有同级评审，整个合作期的 truck factor 为 1。一项针对 133 个热门开源应用的研究发现，其中 65% 的 truck factor 已不超过 2，所以这是常见失效模式而非假设。对必须运行多年或需通过尽调的系统，请坚持要有指定的第二人。" }, "name": "一人机构能交付生产级软件吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它承担的是不同的风险。小公司集中了关键人员风险与峰值产能风险；大公司集中了成本、变更延迟，以及你的工作落到最初级可用人员手上的风险。两者都能靠合同管理。对小型合作方，请覆盖四个具体点：每个关键组件有指定的第二人、披露分包方并向下传导义务、每个领域有指定评审人，以及代码仓库、云与许可的所有权在你这一侧。" }, "name": "小型软件机构比大公司风险更高吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "部分意味着，但原因不是人数。2026 年第一季度一项针对 250 家机构的调研发现，区分「已有智能体投入生产」的机构的是创始人姿态与重建交付流程的意愿，而不是营收或人数。Google 2025 年的 DORA 研究发现 AI 采用度与交付吞吐量正相关、与交付稳定性负相关，并得出结论：AI 放大组织既有的强项与弱项。小而有纪律扩展得很好；小而无纪律失败得更快。" }, "name": "AI 是否意味着小机构能交付过去大公司交付的东西？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它们承担了规模带来的协作成本，却没有规模带来的合同优势。Promethean Research 于 2026 年 2 月对 119 位机构负责人的调研发现，10 人以下的工作室 2025 年平均税后净利率为 19%，而 50 人及以上的机构为 8%；Forrester 预测 2026 年机构岗位减少 15%，此前 2025 年平均已减少 8%。两组数据覆盖的都是营销与数字机构而非软件工程公司，所以请把它们当方向读，而不是当软件基准。" }, "name": "为什么中型机构承受的压力最大？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它是指多少人突然不可用就会让项目停摆。它之所以重要，是因为这是合同语言能低成本修复、而买方几乎总是发现太晚的那一类供应商风险。请要求每个关键组件两个人名、代码仓库内的决策记录，以及经过实测的交接包，而不是一句提供文档的承诺。" }, "name": "什么是 bus factor 或 truck factor，买方为什么该关心？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "把两份报价都归一到首年可比成本，以及谁真正做这份工作。把被排除的工作、托管、许可、你自己团队需要投入的工作量和预期的退出成本加回去。然后比较实际分配人员的资历、评审安排、列明的分包方以及交接义务。大公司较低的表面报价，往往反映的是更初级的分配团队。" }, "name": "如何比较微型机构与中型机构的报价？" } ] } ```