本次介绍：AI 软件工厂 · 阶段一、二、三（共六个阶段）
软件研发最容易垮在前半程：需求含糊，架构就返工；架构摇摆，编码就跑偏。把“一句话需求”稳定地变成“可运行代码”，靠的不是某个更聪明的模型，而是一条被约束清楚的工序。
需求分析最易被一句“做个类似某某的系统”带过，结果后面每一步都在补前面的漏。
软件工厂把这道工序固化下来：给一句话需求，设备按既定方法，产出一份结构化PRD，作为后续所有工序的唯一共同输入。这一步解决的，是“需求到底要什么”的确定性—没有它，后面的智能都是空中楼阁。
以MiniBMC Simulator为例，PRD含7项功能需求、8个API、阈值规则（CPU 温度 / 风扇转速 / PSU 电压）、电源操作幂等约定（目标态=当前态即返回200且不记事件）、4类错误码、14条验收标准、3个模拟场景、9条非目标。
“非目标”清单是一道墙：把“不该做”钉死，需求层保持干净；否则模型天性补全发挥，会自作主张加认证、把模拟器写成真服务。方法已沉淀在软件工厂里，不用客户自己琢磨怎么写提示词。
跳过它，架构师只能凭感觉画框，编码者按自己的理解补需求—三个角色对“要做啥”理解不一致，后面全错。在便携式智力工厂上，这道工序离线完成，代码不出设备。
第二阶段把需求落成可落地的技术骨架。
产出架构文档：7个模块职责与依赖方向、dataclass 数据结构、API请求到响应的处理流程、统一错误信封（{error:{code,message}}）、FakeClock+固定种子测试策略、需求→模块→测试映射。好的架构不追炫技，追“易测试、易接手”。
约束写在前：只做MVP，不引入数据库、不堆复杂认证、不实现真实工业协议——把范围框死，避免架构膨胀、把简单问题做重。
PRD 是架构的输入：前一阶段产物自动成为本阶段上下文，信息不重猜、不丢失；架构文档因此能直接交给编码阶段，而不是再写一遍需求。
跳过它，代码直接堆在函数里，模块边界模糊，半年后没人敢动；测试也无法定位该测什么。便携式智力工厂让架构与需求同源，现场改需求也能当场重画结构。
第三阶段才动手写代码。产出代码包（12个源文件）、57项单元测试、3 个场景 JSON（normal / cpu_hot / fan_fault），以及开发依赖清单。实现要求明确：用标准库、实现全部 API、电源操作幂等、错误返回正确状态码、内存态保存、为核心逻辑写测试；启动用 python -m bmc_sim.server --port 8080，测试用 unittest discover。
硬规矩：只有实际运行测试后，才报告测试结果。代码不是“看起来能跑”，而是“跑过了”——这条把“能编”和“能用”切开。
边界由工序保证：不连真实硬件、不访问外网、不实现需求之外功能，靠的是阶段提示词里的硬约束，而非人的自律。编码阶段最怕“跑通即交付”，软件工厂要求测试先过、场景齐全、命令可复现，才视为这一阶段完成。
跳过它，需求里的幂等、错误码、阈值全靠编码时临场发挥，交付即埋雷。在便携式智力工厂上，编码与测试一体完成，专家带着设备外场也能出可运行代码。
三道工序的产物同源：PRD是架构的蓝图，架构是编码的依据，每一步的输出自动成为下一步的上下文输入。没有这套约束，需求、架构、代码会各说各话，返工从第一阶段就开始。过去，把一句话需求做成可运行代码，需要一个团队在办公室与现场之间反复往返；现在，便携式智力工厂把这三道工序连同方法、算力、私有化运行环境，打包进一台能随身带去现场的机器——专家带着它，外场也能把一句话需求，当场变成可运行代码。后半程怎么把“能跑”变成“可交付”。
