项目交付能力扫描（简版）

结论

不是都能解决。有代码的 45 个项目里，22 个的后端用了平台检查不到或交付不了的技术，另有 2 个已交付项目需要返工。

为什么会这样

09-28～09-29 集中生成了一批架构。那时平台还没限定技术栈，38 个架构里 31 个选了 Node.js，3 个选了 Java，1 个选了 Python。09-29 起平台只做 Go，开发提示词也按 Go 来写。结果这些项目的代码里出现了两套后端：一套按架构写的 Node／Java／Python，一套按平台约定写的 Go 胶水代码。而平台的检查只验证 Go 那一半。

09-30 之后生成的架构都是 Go 路线，不再有这个问题。

需要马上处理

需要拍板的三件事

分项目清单

可交付 4 个

已交付，但不可用 2 个

Go 路线，继续开发 11 个

卡点都是普通的编译错误或审核意见，补充说明后重跑即可。

Go 为主，夹带不会运行的 Node 代码 6 个

要做两件事：把架构说明改成 Go；逐个核对已完成任务，只写了 JS 后端的，那部分功能在交付物里并不存在。

Node.js 后端有启动脚本 7 个

平台新增的 Node.js 交付能识别它们。还要做两件事：在架构里声明数据库（postgres／redis）；页面要由 Node 服务自己提供。

Node.js 后端无运行入口 11 个

业务接口写在 Node 代码里，但没有 package.json 或启动脚本，平台从未运行过。按现状交付出去，会是页面能打开、接口全部 404 的空壳。等「拍板」第 1 条。

Java／Python 后端 4 个

平台不支持这两种后端。等「拍板」第 2 条。

尚无代码 16 个

这些项目会按现在的 Go 路线生成架构，不会再出现两套后端。例外是「智慧场馆数字孪生一体化管控平台」（prod_02）：它的架构已经按 Node.js 生成，开始开发前要重新生成。

另外，其中 4 个是测试或演示项目，还有几组同名或近似名的项目，建议负责人确认是否清理。

其他注意

• prod_06 名下 11 个项目的运行从 09-30 起一直暂停。prod_06、dev_06 账号已于 10-01 停用，需要管理员给项目加开发成员或恢复账号后，才能继续。
• 13 个项目写了 Vue／React 组件，却没有前端工程（package.json），页面构建不出来。
• 13 个因编译失败阻塞的任务里，有 5 个是平台能自动预防的：根目录文件的包名写成了 app；用了标准库却没写 import。

平台改进（按收益排序）

1. 交付物启动失败时，阻止项目进入 UAT。
2. 开发提示词跟随项目的实际技术栈，不再对 Node 项目要求 Go 写法。
3. 检查阶段识别两类问题：没有运行入口的后端代码；没有前端工程的组件。
4. 冒烟测试增加接口探测：前端调用的接口在交付物上返回 404 时，给出提示。
5. 编译前自动补全 import；提示词写明根目录文件统一用 package main。