深度解读:非工程师用 AI 自建内部工具的做法已在多个行业出现,维护与出错责任的归属决定自建边界

AI 编码工具把写软件的门槛降到会描述需求就能上手。从国外的施工公司、机器人公司到国内的工厂，多份一手叙述显示，把工具做出来这一步已经不构成障碍；问题出现在工具积累到一定数量之后：坏了由谁来修、出了错由谁负责、哪些适合自建、哪些适合购买。自建能不能长期走下去，取决于维护与出错责任有没有明确的归属，以及自建与购买的边界有没有事先划出来。

施工公司与工业企业的两个内部应用

2026 年 10 月 21 日，Hacker News 上出现一个讨论帖，问大家是否观察到一种新趋势：公司员工用 vibe coding（用自然语言向 AI 描述需求、由 AI 生成代码）做出内部应用。

用户 255kb 在回帖里给出两家公司的例子。一家电力线路施工公司里，非开发人员做出了帮助施工规划的内部应用：自动连接土地登记系统，给新线路沿线的所有居民发函。另一家工业企业里，员工做出了一个内部社交网络。255kb 的评价是，两个应用「毛边粗糙但能用，用的人满意」。

他补充说，这样的专用软件如果交给外包定制，报价通常在 10 万美元上下，这些公司大概宁可先自己做出来，之后再处理错误。他预期，在购买与用 vibe coding 自建之间做取舍的情况会越来越多。

ERP 团队的 Web 应用与机器人公司的表单

同一个帖子里，用户 sntran 讲了客户处的见闻。他被请去讨论「做一个自动化审计的应用」，客户指给他看一个已经在用的内部 Web 应用，ERP（企业资源计划）团队里某位成员自己做的，客户称它「很棒」。sntran 查看代码后发现「到处都是 Claude 的痕迹」，他没有阻止，让客户继续用。

机器人公司的案例来自另一个帖子。2026 年 9 月 7 日，Hacker News 上有人问「怎么向知识工作者铺开智能体」，用户 rossng 回复介绍了自己所在的机器人公司：公司搭建了一个很简单的平台，用来发布只能内部访问的静态 Web 应用，应用连接一个文档数据库做存储；平台配了一个 Claude 技能（skill，写给 AI 的工作指引文档），写清楚应用怎么编写、怎么部署。非工程师很快找到了各种用途，做出库存管理、排班这类专用表单和数据库。

rossng 补充，平台上的写入被隔离在特定范围内，读取没有限制。他说，公司变大之后，访问控制很快变成最复杂的事。

Ramp 与 Stripe 已为自建建成内部平台

行业通讯 Pragmatic Engineer 在 2026 年 10 月 8 日的一期里报道了这个趋势：Ramp（美国的企业支出管理软件公司）与 Stripe（支付基础设施公司）已经建成让非工程师自建内部网站与工具的内部平台，两个平台都在各自公司里推开，作者预期更多公司会跟进。这期全文在付费墙后，引用限于其公开导语的内容。公开导语没有展开两家平台的具体做法。

维护与出错责任的争论

用户 melbeesgames 在回帖里写道：内部应用的大问题不在创建，而在维护、扩展与提供支持；未来很多公司将受困于「无人维护、不再能用的 vibe coding 应用」。用户 Daishiman 拿 Excel 宏表格作类比：每家公司都有一批超出任何个人理解范围的宏表格，vibe coding 应用大概率会占据同样的位置。

用户 paj26 写道：代码变便宜之后，工程团队强的公司能管得住，其余公司手里会剩下成堆的坏代码，或者更糟：错误的代码；业务上的关键决策将建立在这样的代码上。「错的时候，责任算谁的？」（"When it's wrong, do we blame the vibe coder?"）

在 255kb 的施工公司案例下面，用户 artnap 追问：这些应用坏了由谁来修，是做它的人，还是 IT 部门？跟帖的回答是一句玩笑：再用 vibe coding 修一次。

用户 bemeeker 认为压制不是办法。他写道，AI 越强、越容易获得，这类应用的出现就越不可避免，应该有一个能把员工引导过去的地方。他开源了 Pando，给这类内部应用一个受控出口。

Deriv One 的治理做法：技能按岗位门控，发布前审核

Deriv 是一家受监管的金融公司，设有支付、财务与合规团队。2026 年 10 月 21 日，公司把内部 AI 平台 Deriv One 开源，许可证为 MIT（允许自由使用与修改的开源许可证）。首席技术官 Rotimi Akinyele 等三人在公司的复盘文章里讲了这套平台的来由。

首席执行官最初想要一个技能注册表，即一个能找到所有技能的目录。复盘写道，没有人缺技能用，真正的问题是谁能运行哪一项：一项技能碰到内部系统或财务数据，就不能和一个无关紧要的健康检查脚本放在同一个开放仓库里。复盘里的原话是：「技能发现从来不是难点，控制才是」（"Discovery was never the problem. Control was."）。

具体做法体现在技能上。一项技能是一份 Markdown 文档，写清楚某件事怎么做、什么时候用、什么时候不用；审核人逐项批准后才能进入目录，目录保留全部版本历史，每个人只能看到自己岗位允许的技能。平台由四个部分组成（对话工作区、技能目录、注册过的智能体、无代码应用构建器），共享同一个核心：统一身份、密钥管理、沙箱（sandbox，隔离运行代码的环境）与用量追踪。

这组数字来自公司自述：221 个技能由全公司的 54 人创建，不是一个部门把守着入口。几乎全部智能体交互都通过团队共享频道里的 @ 提及完成，不在私聊里进行。

团队也考虑过用砍掉能力的办法换取安全，复盘里写了没有那样做的理由：把能力从工具里拿走，人们就会回到各自私下用的工具上，那里没有人看得见，也没有人能审核；所以他们把控制做进平台，并保证获得批准的路径同时也是最容易的路径。

一家工厂的 ERP 与被取消的测试环节

国内也有对照案例。2026 年 10 月 26 日，V2EX（国内开发者社区）用户 wises 发帖描述朋友工厂里的事；发帖人说明这个项目基本由他引导，以下为转述，未经独立核实。

按帖子描述，厂主 7 月还是编程新手，做了几个月 vibe coding 之后，工厂的 ERP 上线，并被当作生产力工具使用，与工厂的所有流程吻合。日常流程是：员工在 ERP 内置页面提交 issue（工单与功能请求），工单直接进入 GitHub 的 issue 列表；厂主在 ERP 里查看工单状态，批准后由 Claude 直接接手修改代码，再经 GitHub Actions（GitHub 的自动部署服务）自动部署；拒绝的工单打回后不执行修改，但工单留档，将来可以回顾评估。

原本 Claude 改完代码后还有测试和预览环节。几个月下来，厂主发现测试和预览环节对这类修改来说是「杀鸡用牛刀」，于是取消了这个环节：按发帖人的说法，框架和流程已经基本定型，要做的只是配色、布局、拼写纠错这类小修改。回帖里有人质疑这一步：用户 spike0100 写道，开发环节可能用 AI 一遍就过，「测试应该不能全部交给 AI 吧」。

帖子还描述了下一阶段的进展：算力服务器已组装完成，正在测试本地部署的大模型能否替代 Claude Code；同时在评估把 GitLab（可自行部署的代码托管平台）与 runner（执行自动部署任务的组件）部署到工厂内网，目标是全流程在内部封闭运行，不依赖任何外部服务。

信源说明：Hacker News 两个讨论帖（2026 年 10 月 21 日、9 月 7 日）与 V2EX 帖（2026 年 10 月 26 日）的内容均为发帖人自述或转述，工厂主案例由项目引导者转述，未经独立核实。Pragmatic Engineer 该期全文在付费墙后，引用限于其公开导语。Deriv One 的平台形态，以及 221 个技能、54 人这两组数字，均来自该公司官方复盘的自述。