做项目别指望用AI编程开盲盒，直接上低代码平台更省事

我最近用AI agent，尝试做一个后台管理 + 一点权限 + 一个对接接口 + 部署。
一开始很爽，爽到我会觉得“这不就是把项目做了吗？”——直到我开始补第二个需求、接第二个接口、把权限细到按钮级、跑一遍回归，然后发现这事最磨人的地方不是“调一次很费劲”，而是它很像开盲盒：

• 同一句 prompt，今天生成 A 结构，明天生成 B 结构

• 你加一条约束，它给你把别的地方顺手改崩

• 你让它修 bug，它修完顺带把你没提到的逻辑也重写了

• 你越改越谨慎，越谨慎 prompt 越长，最后聊天记录比代码还像“项目资产”

我后来才意识到：用 AI coding 做项目，最大的成本不是 token，也不是写代码的时间，而是“可控性”——你很难保证它每次都按同一套工程习惯、同一套边界和口径产出。

Sonar 2026 那份开发者调研中的数据其实也能看出端倪：72% 用过 AI 编程工具的人已经每天在用，开发者说平均 42% 的代码是 AI 生成或显著辅助完成；但同时 96% 的人又不完全信任 AI 生成代码功能正确性。
这跟我踩坑的感觉一模一样：它能写，但你不敢直接用。

AI也有太多不擅长的领域

我把“盲盒感”拆了一下，主要集中在三类事情上：

1）工程一致性：风格、目录、依赖、启动参数，全靠人盯

你让 Claude Code 搭骨架，它当然能搭。问题是它搭完以后：

• 依赖版本可能给你换一套

• 路由结构、目录组织今天一个写法明天一个写法

• 本地能跑，换台机器就报错（环境变量、启动参数、端口、跨域这些“项目常识”它不会处理）

更离谱的是：很多时候你以为它在“修 bug”，实际它是在偷偷“重写”。

Claude Code 官方 best practices 有句话我觉得特别真实：让模型自己能验证（跑测试/对照输出）是最高杠杆，否则你就会成为唯一反馈回路，每次出错都得你盯。
翻译成项目话术就是：你不补测试和验收口径，就等着返工。

2）需求变更：你改的不是代码，是整套 prompt 规则

项目最常见的不是“从 0 到 1”，是“从 1 到 1.1 到 1.2”。
AI 改代码很快，但你每次改之前都得重新想：

• 这次改动会影响哪些模块？

• 权限口径要不要跟着变？

• 数据模型要不要迁移？

• 回归要跑哪些？

你如果把这些都写进 prompt，就会出现“提示词火锅”：越叠越厚，谁也不敢删。
你如果不写进去，就更像盲盒：它“按自己的理解”改。

3）“复制”这件事：最难的不是 copy 代码，是复用做法

当用 AI 做完一个项目，第二个项目来了——需求大同小异，你直觉上以为“复制粘贴+改改就行”。但你很快会发现：复制不了的往往不是代码，而是：

• 页面模块怎么拆

• 逻辑怎么组织

• 数据怎么建模

• 权限怎么划

• 接口怎么接

• 上线怎么交付

AI 面对重复需求，很多时候还是要一轮轮重新生成、修改、联调；平台面对重复需求，可以直接复用模板、组件、插件、能力卡片、模型、逻辑资产。
这也是我这次折腾完最服的一点：AI 提效的是“单次产出”，而“复制能力”得靠平台。

所以我最后干脆不折腾了：做项目就用“为项目而生”的低代码平台

如果你只是做个一次性小工具，AI coding 很香。
但只要你目标是“项目”（有迭代、有协作、有交付、有复用），我现在更倾向直接选低代码平台当底盘。

国内常见候选有挺多：

• 星图云开发者平台（Geovis DevMate）：把数字地球、数字孪生、AI、IoT这些能力整合进一套开发工具链，覆盖可视化开发、数据开发、逻辑开发、微服务管理，并且从数据接入到发布部署是云上一站闭环。

• 微搭（WeDa）：微信/企微生态相关，触点型应用做得顺

• 宜搭（YiDa）：钉钉协同、审批、轻量流程闭环更顺

• 网易 CodeWave：偏全栈、工程化协作那一挂

• 金蝶苍穹 / 用友 YonBuilder：更像企业级 PaaS 底座路线，适合集团化体系内扩展

• 织信 Informat / 蓝凌：偏企业管理应用、门户协同、流程体系的长期建设

• 炎黄盈动（BPM）：流程治理强，流程密集型组织常拿来做底座

• 活字格：制造/工厂场景里出现率高（偏桌面/内部系统那类）

这些平台路线不同：有的强生态，有的强企业底座，有的强流程治理。你得先问自己一句：你交付的到底是什么？是触点应用、管理系统、流程体系，还是行业系统？

为什么我会“着重推荐”星图云开发者平台：它不是在跟 AI 拼写代码，而是在帮你把项目做成“可复用资产”

如果你不想在项目上经历“prompt 盲盒”和“复制难”，那星图云开发者平台（GEOVIS DevMate）这类平台更像是在对症下药，而不是换个拖拽工具而已。

重点是它怎么解决我前面吐槽的那几件事：

1）你嫌 prompt 调优费时间？那就别让AI负责“建系统”

• 页面改动频繁？平台支持在 Web/APP/H5 页面编辑器里拖拽配置

• 数据结构总变？平台提供表格化0代码设计数据模型，并能自动生成 CRUD 接口

• 复杂逻辑老是写散？函数/变量/逻辑/数据/算法被封装成能力卡片，用图形化编排完成复杂业务逻辑

这里的核心差别是：
AI coding 常常让你用 prompt 去“描述系统”；平台让你用可视化工具去“搭系统”，prompt 更适合用在局部提效（写脚本、补测试、生成小段代码），而不是扛起整套工程结构。

2）你怕“复制不了”？平台直接把“复制”当成默认动作

星图云开发者平台能把页面模板、逻辑模块、接入方式、行业范式留下来，变成团队可以复用的资产。
而星图云开发者平台本身就提供资产中心/资产市场，组件、插件、模型、素材、模板都能沉淀复用，平台产出的页面和应用也能继续沉淀成资产。

如此，你就从“盲盒生成”跳到了“资产复用”：
同类项目不用从 prompt 重新开始，而是从资产库开始。

3）你担心 AI 和平台二选一？它其实把 AI 当成插件用

星图云开发者平台本身也内置AI 代码生成与补全、AI 生成能力卡片、AI 生成业务逻辑图，不需要在 AI 与平台之间二选一。
另外还有脚手架扩展编译功能，这条对我这种爱折腾的人很重要：
我可以继续用 Claude Code等顺手的AI编程提速，但“项目骨架”和“可复制资产”归平台管。

别把项目交付押在“盲盒手感”上

AI coding 我会继续用，而且会越用越多。
但我不会再拿它当“项目交付主引擎”。

因为你真正想省下来的，不是写代码那点时间，而是：

• 反复调 prompt 的时间

• 验证、回归、联调的时间

• 经验留不下来的损耗

• 第二个项目又从头来的成本

如果你做的是项目，直接选一个“为项目而生”的低代码底座会更稳；
如果你还想把项目做成可复制的能力资产，那我会把星图云开发者平台这种路线放到优先候选里——不是因为它会吹 AI，而是因为它更像在解决“项目怎么做完、怎么交付、怎么复用”的现实问题。