把 DER 项目申请直接翻成公用事业公司可开研究的案例，不再在邮件来回里耗上几个月的并网工作台。

1. 并网延误现在已经能被清楚看成工程工作流问题，而不只是电网容量问题，因为这组信号明确把“研究流程”点成拖慢新能源接网的核心环节。
2. 代理式软件已经直接打进电网规划工作，让“研究准备”和“队列分流”的自动化第一次在这个长期靠手工推进的领域里变得可信。
3. 平台同时向公用事业公司和开发商扩张，说明两边之间确实存在值得用共享工作流软件来补的协同断层。
4. 强调更深的电网智能层，意味着创始人可以从队列和研究结果里堆出一笔耐久数据资产，而不是跟别人一起卷一个通用 AI 助手。

催化因素。 Piq 拿到种子轮融资，并明确要把代理式电网规划软件扩到更多公用事业公司和开发商，说明并网研究自动化正从小众咨询活，跨进可售卖的软件品类。

产品卡在项目申请进入和公用事业老旧研究环境之间。它会解析单线图、负荷或发电曲线、保护设定和历史往来函，标出缺失输入，并先拼出一份工程师可审批、可修改的首版研究包，而不是让工程师从零开始搭。公用事业公司可以用它给队列做分流、统一研究假设，并起草改造函或补件函；后续开发商也能在镜像门户里先看到自己缺了什么，再决定是否重提。第一条工作流聚焦分布式能源和柔性负荷项目从受理到研究启动，因为这里的延误常常不是卡在硬核电网物理，而是卡在申请包不完整和模型搭建反复。时间越久，每个审过的案例都会沉淀成训练数据：哪些申请模式、馈线条件和设计选择更容易触发改造、延误或审批。

差异化。 老牌规划工具擅长在数据已经结构化后做潮流分析；咨询公司和队列追踪表，则在前面那段脏活——把申请包翻成可研究案例——硬扛过去。通用 AI 助手会总结文档，但不懂各家公用事业的并网规则、回函模板和建模假设。这家公司能赢，在于它把这层翻译层拿住：每个通过、拒绝或触发改造的案例都会反哺系统；同时它是嵌进现有规划软件，而不是逼公用事业公司整套替换。

待完成任务

flowchart LR
  Buyer[公用事业并网团队] --> Pain[申请积压，研究启动慢]
  Pain --> Product[并网工作台]
  Product --> Outcome[研究启动更快，审批更顺]

高管要点

• 最锋利的切口不是整套替换公用事业模型，而是把申请包翻成研究案例的那段交接。
• 市场上已经有门户、研究引擎和咨询公司，但申请包到可研究案例之间那层翻译层还很碎。
• 各地监管差异很大，所以每个审过的案例都会沉淀成一笔能复用的工作流和规则资产。
• 最容易批预算的卖法，不是泛 AI 提效，而是工程吞吐提升和少用咨询公司的软件。

市场定义

美国优先的一套软件与工作流基础设施，服务配电公用事业公司的并网团队，处理 DER 和新兴大负荷申请。这个品类卡在受理门户和馈线研究工具之间：它负责把申请包数据结构化、执行各家公用事业的要求，并产出可开研究的案例和利益相关方沟通草稿。

用户与买方

主要用户是公用事业并网经理、配网规划人员，以及审核太阳能、储能、EV 充电和其他分布式能源申请的工程团队。经济买方通常是并网、电网规划或工程运营总监；在公用电力和合作社体系里，还往往要再经过治理或采购层的把关。

购买触发点

• 队列量还在涨，但公用事业公司对外描述的并网工作流，仍然是手工、纸质或碎片化的。 [1][2][24][33]
• 完整性审查会吃掉工程时间，因为在研究正式开始前，公用事业公司就要求齐备的一线图、站点图、保护设定和本地化表格。 [11][12][13][19]
• 来自 EV 基础设施和数据中心式需求的大负荷增长，把新的申请类别压进了同一批本就紧张的团队里。 [2][9][35]

支付意愿

公用事业公司今天已经在为门户、研究、咨询和电网数据刷新买单。只有当一套新工作台能明确减少手工完整性审查、缩短研究启动时间，并在不逼着公用事业公司拆掉现有研究引擎的前提下提升队列透明度时，预算才最容易松动。 [19][20][24][25][27][29][30]

品类动态

增长信号 未来十年峰值需求预计增长 15-18%

验证信号

• Piq Energy 拿到种子轮，说明投资人已经开始把 AI 驱动的电网规划和并网工具当成可投的品类。
• DOE 支持的 iQMS 明确把软件、预测、GIS 和 AI 用来减少 DER 队列的手工摩擦。
• GridUnity 披露，PG&E 在一次软件驱动的数据刷新后，公开的承载容量提高了近 400%。
• Gridtwin 声称在 Eversource 的并网门户上已有 1000+ 用户，说明公用事业公司确实会规模化采用外部并网软件。

监管与技术约束

• IEEE 1547 规定了 DER 并网的基础互操作、测试、性能和异常工况要求。
• 加州 Rule 21、纽约 SIR 等州级 / 公用事业规则，决定了产品必须按辖区编码工作流逻辑，而不可能只有一套全国通用清单。
• 如果申请包缺少单线图、站点图、保护细节或储能专属假设，公用事业公司完全可以直接退件或拖延。
• 很多公用事业公司已经把申请人引到 CIT、PowerClerk 这类具名门户里，所以新软件必须和这些前台表面共存。
• 研究导出仍然要贴合现有分析与遥测生态，而不是再发明一套全新的操作环境。

竞争对手来自公用事业门户、自动化研究引擎、地图优先筛选工具、输电积压平台和咨询替代方案。真正的空白不是泛泛的“面向电网的 AI”，而是把一堆脏申请包翻成工程师可审研究案例的、公用事业专用翻译层。

为什么现有厂商不会默认胜出

• 公用事业申请门户. 它们把受理和状态跟踪数字化了，但把图纸、设定和往来函翻成可研究案例这一步，往往还是靠人完成。
• 自动化研究引擎. 一旦输入已经结构化，它们可以自动跑影响研究；但它们并不真正盯着申请包完整性和申请人与公用事业之间的来回补件。
• 地图优先筛选工具. 它们提升的是选址筛选和承载容量可见性，重心更偏规划洞察，而不是公用事业后台把申请拼成案例的那段操作。
• 工程咨询公司. 它们能顶住高峰工作量和定制化研究，但知识停留在项目人工里，沉淀不成可复用的工作流数据集。
• 规划与建模工具. 它们仍然是下游真正的记录引擎；也正因为如此，一层翻译层更容易贴着它们落地，而不是上来就替换。

这家公司应该先从一套并网研究工作台切入，目标是中型配电公用事业公司：它们的 DER 和柔性负荷队列增长速度，已经超过小型工程团队把申请包翻成可研究案例的速度。真正痛的不是潮流计算本身，而是 PDF、表格、邮件线程和咨询公司溢出工作之间那段手工的“申请包 → 研究案例”交接，这会拖慢公用事业公司的回复 SLA，也会打乱开发商项目排期。第一款产品必须收得很窄：一层由工程师把关的“受理到研究启动”工作台，负责检查申请包完整性、拼出首版研究包、起草补件函或改造函，并把结果导出到公用事业公司现有的研究环境。GTM 也要沿着这条工作流来打：先向一个积压 150+ 申请的公用事业辖区卖付费试点，按辖区或团队加申请量定价，并把咨询公司或系统集成商当成背书与落地伙伴，而不是主交付模式。之所以要贴着现有门户和研究工具起步，核心是更快拿到证明：公用事业公司本来就在为消化积压和少用咨询公司预算，而整套模型替换只会把销售周期拖得更慢、可信度也更低。这个切口如果跑通，真正沉淀下来的资产是规则与结果数据：它覆盖申请包缺陷、工程师修改、往来函模式、触发改造的条件和研究结果，而这些数据现有厂商天然抓不成可复用资产。最主要的反证风险是，各地规则、脏源文件和模型栈差异太大，最后把部署拖成重服务项目，或者让工程师迟迟不敢在生产里用。当前建模的 SAM 和 SOM 分别是 $48.0M 与 $4.8M；而真实申请量、主流模型栈，以及公用事业公司对 AI 起草函件的容忍度都还没坐实，所以这是不是一笔风险投资级的软件生意，取决于公司能否在扩编前先证明跨第二个辖区也能重复部署，并且能顺着相邻模块继续扩。

问题

• 只有 3-15 名工程师的公用事业并网团队，今天还是要花上几天，把申请包里的一线图、保护设定、站点图纸和往来函件，翻成各家公用事业自己的研究假设，馈线分析这才刚刚开始。
• 现有门户、研究引擎和咨询公司，要么只把受理流程数字化，要么只跑下游分析，但都没真正砍掉积压的根源：完整性审查、补件往返和首版案例组装的循环。

解决方案

• 提供一套工作台：吃进 DER 和柔性负荷申请包，按各家公用事业规则做完整性和规则检查，把技术数据结构化，并生成一份工程师可审的研究包和利益相关方沟通草稿。
• 先作为贴在现有门户和研究工具旁边的附加层切入；只有等公用事业侧的受理层先跑出信任，再把同一套数据模型扩到开发商预检、改造基准和大负荷并网工作流。

为什么我们会赢

• 这个切口正好打在现有厂商留下的断点上：门户负责收件，研究引擎负责分析结构化案例，真正把申请包翻成可研究案例的那一段，今天仍靠咨询公司和人工硬接。
• 产品可以贴着现有规划栈落地，不必要求公用事业公司整套替换；这更符合受监管买家采用新软件的方式，也更容易量化“少用咨询公司”的 ROI。
• 每一份通过或被改正的草稿，都会继续堆厚一套专有的规则、缺陷和工程师编辑数据集，既能提高准确率，也能跨公用事业公司做基准分析。

里程碑

flowchart LR
  Wedge[门户到研究的翻译切口] --> MVP[工程师在环工作台]
  MVP --> Proof[周期时间证明]
  Proof --> Expansion[开发商预检与大负荷扩张]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少有 100-120 个第一波公用事业辖区，年申请量和积压痛点足以支撑超过 $200k 的经常性软件支出。
• 一套工程师在环工作台，能把中位“研究就绪启动时间”至少砍掉 50%，同时不抬高合规或审计风险。
• 已经在用 PowerClerk、CIT 或类似门户的公用事业公司，仍会买一层翻译层附加件，而不是等现有厂商自己补工作流。
• 前 3-5 个部署能靠标准化规则库和导出适配器上线，而不是每单都做项目制集成。
• 公用事业侧的缺陷、编辑和结果数据，能在 24 个月内值钱到足以撑起开发商预检或基准扩张。

待尽调问题

• 在研究列出的第一波地区里，今天到底有哪些具体公用事业辖区符合“年申请量 100-1,000、工程师 3-15 人”的滩头画像？
• 公用事业买家到底更常为新工作流软件拨款，还是扩展 PowerClerk、GridUnity、咨询公司或内部流程？
• 滩头市场的主流模型、GIS 和导出栈到底是什么？不写定制代码的前提下，能覆盖几套？
• 如果工程师仍然保留签字权，法务、合规和档案团队会不会放行 AI 起草的回复信？
• 有多少试点客户愿意让公司保留匿名化编辑和结果数据，用来搭护城河？

模型合理性

• 收入引擎. 基准收入来自 Y1 的 3 个试点，逐步滚到 Q4Y2 的 7 个付费辖区和 Q4Y3 的 12 个；综合 ARPU 末值约 $31K / 月。
• 必须跑顺的环节. 导出优先部署和可复用辖区模板必须站住，这样毛利率才能从试点期的 50% 多，爬到 Q4Y3 大约 74%。
• 模型会失效的情况. 如果生产环境转化晚一个季度、集成又让毛利率低 5 个点，下行情形在 Y3 结束前会把现金打到约 -$370K。
• 下一轮融资证明点. 一旦公司做到 6-8 个生产辖区、标准部署低于 6 周，并在 1 个在线账户里跑出基准分析或预检扩张，就有理由讲下一轮 seed。

情景

敏感性

flowchart LR
  TargetAccounts[目标公用事业账户] --> PaidPilots[付费试点]
  PaidPilots --> ProductionTerritories[生产辖区]
  ProductionTerritories --> Revenue[综合 ARPU]
  Revenue --> GrossProfit[毛利润]
  GrossProfit --> Cash[现金跑道]

警示项: 基准情形仍押在前 12 个月拿下 3 个付费试点上；而公用事业采购本身就慢，一旦销售晚一个季度，Y3 收入就会少约 $351K，现金少约 $401K。 · 毛利率直到 Y2 / Y3 才穿过 70% 目标，所以只要定制集成或重人工复核超预期，Y3 就会重新翻回 EBITDA 为负。 · $2.0M 这轮融资落在 BP 区间下沿，而基准情形的现金低点只有约 $0.4M，所以 seed 融资要在 Q2Y3 之前就启动。 · 第 3 年上行情形仍依赖基准分析或预检扩张来抬 ARPU，而不只是多拿客户，因为第一波可拿下的客户池也就约 120 个辖区。

• 公用事业采纳阻力. 公用事业公司可能不愿意让软件碰受监管的工程工作流，最后还是回到咨询公司或内部老流程。 缓解措施: 先把产品定位成工程师审核层：产出研究包草稿和审计日志，同时嵌进现有规划栈，而不是上来就替换。
• 老旧模型集成. 只有真正塞进那些杂乱的文档仓库、馈线研究环境和资产数据系统里，产品才跑得起来，而这些系统每家公用事业公司都不一样。 缓解措施: 先盯住一小组常见数据格式，优先发一批有明确倾向的适配器，并把早期部署和范围清晰的实施支持一起卖。
• 双边聚焦失控. 如果从第一天就想同时把公用事业公司和开发商两边都服务好，路线图很容易发散，核心切口也会被削弱。 缓解措施: 先拿下公用事业侧受理工作流；等公用事业产品真正粘住之后，再开放开发商预检门户。