McKinsey：32%企业跳过软件采购、改用agentic工具自建——GitClear数据显示这条路径正在积累可测量的技术债，一个"自建工具体检+加固"的窗口
2026年9月6日 · 今天不铺路径全景图，只深挖一个：McKinsey《State of AI 2026》（8月25日发布，1719名受访者）显示，近三分之一(32%)企业已经决定不买现成软件，改用agentic编码工具自己建功能，在McKinsey定义的"高绩效企业"（AI贡献至少5%EBIT且描述为"显著影响"的那6%）里，这个比例接近一半。几乎同时，GitClear发布的《The Maintainability Gap》报告（分析2023-2026年6.23亿行代码改动）显示，AI辅助编码规模化的同时，可维护性八项信号全线走低——重构活动降70%、代码重复度升81%、跨文件复用降35%、遗留代码维护降74%。企业越敢"自己建"，越可能悄悄欠下一笔将来要还的技术债，而这批企业往往还没有资深工程判断力来提前发现问题——这正是复用你原生移动端工程经验、又能借助AI快速交付的地方，而不是跟GitClear、SonarQube这类工程团队自用的分析工具正面竞争。
本文不构成投资、法律或税务建议；文中关于市场空当与竞争密度的判断为分析意见、非事实陈述，请自行核实。
先说清楚发生了什么
McKinsey State of AI 2026：32%企业跳过软件采购改自建，高绩效企业里这个比例接近一半
据McKinsey 8月25日发布的《State of AI 2026》调查（1719名受访者），37%的企业称AI对EBIT有"一定"贡献（与去年基本持平），其中仅6%达到"高绩效"标准（AI贡献至少5%EBIT且描述为"显著影响"）；营收超10亿美元的企业里，40%正在规模化AI agent（去年为27%）；近三分之一(32%)企业至少有一项软件功能选择用agentic编码工具自建、而非采购，高绩效企业里这个比例接近一半；同时20%的企业称AI相关运营成本已经在制约其使用，80%的AI使用者称个人生产力有提升。
McKinsey State of AI 2026：32%企业跳过软件采购改自建，高绩效企业里这个比例接近一半
据McKinsey 8月25日发布的《State of AI 2026》调查（1719名受访者），37%的企业称AI对EBIT有"一定"贡献（与去年基本持平），其中仅6%达到"高绩效"标准（AI贡献至少5%EBIT且描述为"显著影响"）；营收超10亿美元的企业里，40%正在规模化AI agent（去年为27%）；近三分之一(32%)企业至少有一项软件功能选择用agentic编码工具自建、而非采购，高绩效企业里这个比例接近一半；同时20%的企业称AI相关运营成本已经在制约其使用，80%的AI使用者称个人生产力有提升。
据The Register援引McKinsey官方报告分析，这次调查的基调是"企业对AI的信心增长速度，超过了它们能归因的实际财务回报"——更多企业相信AI会在未来三年重塑业务、并计划加大投入，但报告"实际拿到EBIT收益"的比例一年来几乎没有变化。McKinsey Quantum Black高级研究员Michael Chui回应称，"已经有一部分ROI在实现，我们预期会有更多"，但强调这需要组织层面的配套变革，不是"接上AI工具就等回报"。
这条数据的关键不在"AI有没有用"，而在"32%这个决定本身"。企业选择跳过采购、用agentic编码工具自己建功能，意味着大量原本会走"买成熟SaaS/找外包"路径的需求，现在变成了"内部团队（甚至非工程背景的人）用AI快速攒出一个能用的版本"。这批"自建"决定里，有相当一部分公司本身并没有资深工程团队来判断"能用"和"能长期维护"之间的差距——这正是下一节要说的具体缺口所在。
为什么这是具体缺口，不是又一句"AI代码要小心"的空话
GitClear《The Maintainability Gap》：6.23亿行代码改动显示，AI规模化的同时重构活动降70%、代码重复度升81%
GitClear今年最新报告追踪2023-2026年七项代码质量信号：重复代码块（每百万行改动）从40.3升到73.0（+81%）；"移动/重构"代码占比从2022年的21%一路跌到2026年至今的3.8%，同期复制粘贴占比从9.4%升到15.7%；新代码与既有代码的跨文件调用连接度降35%；"长期更新"（触碰一年以上未动代码的改动占比）从1.7%降到0.46%（-74%）。
GitClear《The Maintainability Gap》：6.23亿行代码改动显示，AI规模化的同时重构活动降70%、代码重复度升81%
GitClear今年最新报告追踪2023-2026年七项代码质量信号：重复代码块（每百万行改动）从40.3升到73.0（+81%）；"移动/重构"代码占比从2022年的21%一路跌到2026年至今的3.8%，同期复制粘贴占比从9.4%升到15.7%；新代码与既有代码的跨文件调用连接度降35%；"长期更新"（触碰一年以上未动代码的改动占比）从1.7%降到0.46%（-74%）。
GitClear是专注代码质量与开发者生产力度量的第三方数据公司，这份报告分析了2023至2026年间6.23亿次代码改动，是有连续方法论、每季度更新的一手研究，不是内容营销站点的二次转述。报告的结论概括为："今天默认的AI工作流，激励的是交付原子化的代码——一条happy path、一个通过的测试、一张关闭的工单——同时悄悄地对那些看不见、被推迟的工作收税：复用、整合、把错误暴露出来，而这些恰恰决定了一个代码库在第三年有多贵。"报告特别指出，重复代码块这一项风险信号已经是学术文献里与缺陷、连锁bug关联最直接的信号，且"重构"活动已经萎缩到只有"复制粘贴"活跃度的约五分之一。
这正是缺口所在：你在service-netsuite、service-finance这类系统里处理对账、结算、发票的经验，本质上是"知道一段业务逻辑长期跑下来该有哪些边界情况、幂等性、审计留痕"——把这份判断力用在"看一遍AI帮非工程背景团队攒出来的内部工具，找出最危险的那20%问题"上，是同一类工作，只是换了一个审查对象。
Stack Overflow数据佐证：开发者对AI编码工具采用率84%创新高，但只有29%信任其准确性
据Stack Overflow今年2月发布的分析文章，AI编码工具采用率达到创纪录的84%，但信任度却处于历史低点——只有29%的受访者表示信任AI工具（较2024年下降11个百分点），46%明确表示不信任，仅3%"高度信任"；经验丰富的开发者最谨慎，"高度信任"比例仅2.6%，"高度不信任"比例达20%。
Stack Overflow数据佐证：开发者对AI编码工具采用率84%创新高，但只有29%信任其准确性
据Stack Overflow今年2月发布的分析文章，AI编码工具采用率达到创纪录的84%，但信任度却处于历史低点——只有29%的受访者表示信任AI工具（较2024年下降11个百分点），46%明确表示不信任，仅3%"高度信任"；经验丰富的开发者最谨慎，"高度信任"比例仅2.6%，"高度不信任"比例达20%。
这条数据不是"AI编码工具不行"的证据，而恰恰说明信任缺口本身正在成为一个持续存在、有真实需求的市场信号：越是经验丰富、越清楚"能跑"和"能维护"区别的开发者，越不敢完全信任AI产出的代码——但McKinsey的数据显示，企业侧的"build"决定并没有因此放缓。两组数据放在一起看，缺口的形状很清楚：大量公司在加速自建，而最有能力判断这些自建代码是否可靠的人，恰恰是对AI代码最谨慎的那批资深工程师——这批人力目前并没有被系统性地引入到"决定自建"的中型公司里。
| 维度 | GitClear/SonarQube等现成代码质量工具 | 本期设想的窄服务 |
|---|---|---|
| 服务对象 | 已经知道自己有代码质量问题、想量化追踪的工程团队 | 刚决定"自建而非采购"、还没有资深工程判断力把关的中型公司管理层 |
| 解决的问题 | 给工程团队一套持续监测的度量仪表盘（工程视角） | "这个AI帮我们攒出来的工具，能不能撑过明年、该不该继续加功能"（决策/审计视角） |
| 交付形式 | SaaS订阅+仪表盘，需要团队自己解读数据 | 一次性人工诊断报告，直接给出"最危险的3件事+怎么修" |
| 门槛 | 需要工程团队主动采购、有能力解读度量指标 | 不需要客户先懂"重构率""跨文件连接度"这些术语 |
结论：不是要跟GitClear、SonarQube这类度量平台竞争技术能力，而是服务它们够不到的客户群——那些还没意识到自己需要度量、只知道"这个内部工具是不是能长期用"的非技术管理层。
三个具体切入点
① AI自建工具"体检"报告
最快验证面向已经决定"自己用AI建、不买软件"的中型公司，人工过一遍现有的内部工具代码，对照GitClear点出的几个风险信号（重复代码块、缺少错误处理、无测试覆盖、耦合过紧），出一份"最危险的3件事+怎么修"的诊断报告——不需要先写自动化工具，直接复用你的工程判断力。
② 财务/运营类内部工具专项加固
差异化核心你的NetSuite同步、结算、发票、对账经验，正好对应中型公司最容易"AI自建但没人把关"的那类系统——内部报销、简易发票、对账脚本。专门针对这类系统做加固：补齐幂等性、边界情况、审计留痕，这是你的经验里别人复制不了的部分。
③ "build vs buy"决策评审顾问
B端，天花板更高在公司决定"自建还是采购"之前介入，帮技术负责人评估"这个功能到底适不适合用agentic工具自建"、需要配套什么样的代码评审/测试规范——需求会随build-vs-buy浪潮扩大而增长，目前只是观察，建议在①②验证后再考虑。
①几乎零工程成本，是验证"中型公司愿不愿意为这份体检报告付费"最快的方式；②是你结算/对账经验最直接的复用，建议在①验证后再投入；③周期长、依赖客户已有一定工程成熟度，先记在观察清单里。
冷静基准线与竞争密度
独立开发变现的整体基准线依然值得摆在这里提醒自己：月入过$1,000的应用只占17.2%，过$10,000的只占3.5%，中位数低于$1,000/月，头部与底部差距约400倍。B2B诊断/加固服务的客单价通常更高，但客户数量也天然更少，不能直接套用消费应用的基准线，只能作为"别把预期定得太乐观"的提醒。
竞争密度提醒（判断，非事实，请自行核实）：代码质量/技术债度量赛道本身不是空白——GitClear、SonarQube、CodeScene等工具已经解决了"怎么持续量化代码质量"这个工程问题；这次机会不是要跟它们拼度量技术，而是服务它们默认客户画像之外的一群人：还没有资深工程团队、甚至不知道该问什么问题的中型公司管理层。需要留意的是，一旦这些成熟工具推出"给非技术管理者看得懂的报告"功能（目前主要面向工程团队自用），这个窗口会自然收窄，所以更适合作为"现在就能验证"的短期切入，而不是押注多年的主业。
合规边界与反直觉提醒
免责声明：本文不构成法律或投资建议。为客户审查代码、出具诊断报告不涉及证券投资咨询或创作者经济红线，风险相对较低，但涉及接触客户业务代码/数据时仍建议签署基本的保密协议(NDA)以保护双方。
反直觉提醒一（物理隔离）：你在NetSuite同步、结算、发票、对账模块的经验和②高度相关，但这次要做的是"审查别的公司的系统"而不是"财务系统集成"，仍建议按惯例用非工作设备、非工作时间、独立代码仓库开发，不要接触现雇主或前雇主的客户数据、内部系统或商业秘密相关信息。
反直觉提醒二（工程惯性，双重风险）：11年工程经验最容易让人一上来就想把①"体检报告"做成一个自动化扫描平台——这正是CLAUDE.md画像分析里点出的"最常见死法"，而讽刺的是，这次的服务对象本身就是"把自建做成了过度工程"的公司，如果你自己也踩进"先造平台再找客户"的坑，等于亲手示范了你要提醒客户避免的错误。正确顺序是先手工给2-3家公司做①的诊断报告，收集真实反馈。
反直觉提醒三（信任来自判断力，不是效率）：Stack Overflow数据显示资深开发者对AI代码最谨慎——你能提供的价值核心是"经验判断"，不是"用AI审查得比别人快"。收费逻辑应该按专业判断定价（一次性诊断费），而不是按处理的代码行数或自动化程度定价，否则容易在客户心里把自己降级成"另一个扫描工具"。
30天验证计划
- 第1周 · 定人群：列出身边或行业社群里最近半年内"决定自己用AI攒工具、没有另外招资深工程师把关"的3-5家中小公司或团队负责人，重点找有财务/运营类内部工具的（复用②的优势），而不是自己假设需求存在。
- 第2周 · 做最窄的一份诊断：对1-2家愿意配合的公司，手工过一遍它们现有的AI自建工具代码，对照GitClear报告点出的信号（重复代码、缺错误处理、无测试、耦合过紧），出一份纸质版"最危险的3件事"诊断报告，不写一行自动化扫描代码。
- 第3周 · 免费换反馈：把诊断报告免费提供给这几家公司，重点观察真实反应——是"确实该找人看看"还是"我们这个工具本来就是临时用用"，并记录他们最担心的具体场景是什么（是怕出错、怕维护不了、还是怕换人接手看不懂）。
- 第4周 · 分叉：如果有人主动问"能不能定期做"或愿意为报告付费（如一次性$300-1500，视公司规模和工具复杂度），把诊断流程模板化，考虑做②财务/运营类专项加固的最小版本；如果反馈冷淡，保留这套方法论，留到下一个更热的触发事件（比如某次"AI自建工具出大故障"的公开案例）时复用。