需求进，软件出：把一条软件产线做成首页

一个被跳过的问题：谁在提需求

过去两年，「AI 写代码」这件事被验证了很多遍。Copilot、Cursor、Claude Code —— 效果都是真的，但它们服务的是已经会写代码的人。你得知道要什么架构、什么框架、什么接口，才能把 AI 用起来。

而在一家公司里，真正每天被软件折磨的往往不是工程师。是那个每月要在三个系统之间手工对账的财务、那个为了导一份数据要点 40 次的运营、那个因为某个字段不能筛选而多花两小时的销售。他们能极其精确地描述哪里疼，但没法描述该怎么修。

这中间的落差，通常由「提需求 → 排期 → 评审 → 开发」这条链路承担。链路本身没错，问题是它的最小单位太大了：一个「加个筛选条件」的需求，走完全流程的成本和一个中型功能差不多，于是它永远排不进去。

硅基软件工厂（anp.pub）想验证的就是这一件事：如果把提需求的成本压到两三分钟，这条链路会变成什么样。

首页就是操作台

打开 anp.pub，看到的不是产品介绍页，是两个输入框。

左边「提交需求」，右边「查询进度」。提交和查询都是真实数据，不是演示。

第一步是回答 9 个问题，大多是选择题，两三分钟。这九个问题的作用不是收集描述，是把「每天在疼」翻译成机读 PRD —— 一份机器可执行的结构化需求。你不需要知道什么叫 PRD，你只需要回答「这个操作你一天做几次」「现在要点几步」「你希望它变成什么样」这类问题。

提交完你拿到一个需求单号，需求进入 FDE 待审队列。

第二步是等。凭单号随时查它走到哪一步：待审 → 已通过 → 开发中 → 已交付。

中间发生的事你不用参与：FDE 审核确认后投产，Cloudflare 云端产线并行调度 AI 小队按工程纪律开发、验证、交付。

如果你已经有现成的需求文档，可以走「PRD 直投」—— 上传 PRD JSON 和参考资料（接口文档、字段对照表等），跳过九问直接进同一个待审队列。

最重要的设计：两级交付口径

这条产线上我认为最值得说的不是「AI 能写代码」，而是它承认自己可能写错了。

产物有两个状态：

• 模型评审通过 —— AI 认为写完了，自己审过了
• 已验证 —— 执行器把生成的测试真跑了一遍，回传了证据

第二个状态还有一个兄弟：执行未通过。

这个区分看起来只是加了一道流程，实际上是整条产线可信度的支点。「AI 说它写好了」和「代码真的能跑」之间的距离，是当前所有 AI 编程产品共同的软肋。大多数产品的做法是把这段距离藏起来——给你一个看起来完整的结果，你自己去发现哪里不对。

把它显式建模成两个状态的代价是：你会看到一部分需求停在「执行未通过」。这不好看，但它诚实，而且它让「已交付」这三个字真的有含义。

它现在是什么阶段

站上标的是 v0.9.0，我在站点上给它的状态是 beta，原因就是上面那条——两级口径意味着不是每个需求都能一次走到「已验证」。

想先看整条产线怎么跑而不提交真实需求，站上有产线演示（动画模拟，不写入任何数据）。想知道代码到底在哪台机器上生成、由谁真跑测试，看系统架构页。另有使用文档、Agent 指南和进展周报。

它想回答的问题

这个产品对我来说更像一个实验：当提需求的门槛降到两三分钟，需求的形态会变吗？

我的猜测是会。当提一个需求要走两周流程时，人们只会提「重要的大需求」；当它只要两分钟，那些一直忍着的、单独看都不值得排期的小痛点才会浮上来 —— 而那些才是每天真正消耗时间的东西。

这个猜测对不对，得靠真实提交的数据来验证。所以首页才是操作台，不是介绍页。