Base44 Base Code 让非工程师安全参与代码开发
Base44 让产品经理直接修改代码，创建独立分支和 PR，但工程师审查仍必不可少，因为 AI 可能夹带奇怪配置。
Base44 Base Code 实测显示，非工程师可通过自然语言在 GitHub 仓库创建独立分支和 PR。该工具自动检查项目、安装依赖并运行应用，用户无需 API key 即可添加新功能。测试中产品经理成功添加"最高支出类别"指标，但 PR 包含 4 个文件修改，包括不应出现的数据库文件。
非工程师也能安全参与生产代码库开发：Base44 Base Code 实测 来自 @Sumanth_077 对 @Base44 Base Code 实测内容，一个经典场景：产品经理只想要一个小小的看板指标，但因为非工程师无法安全地在真实代码库上工作，需求照样要排进工程队列。他认为：难点不在于让 AI 写代码，在于让更多人参与开发流程的同时，不放弃工程管控。 实测过程 不让 Base44 从零建新应用，而让它接入一个已存在的 GitHub 仓库 (他自己的 Streamlit 个人财务 Agent)，并因无写权限而在 fork 上操作，这样能清晰看到生成的分支和 PR 落在哪里： · Base Code 自动检查项目、装依赖、修复端口配置并跑起应用(88 笔交易，总支出 $4,907.03); · 用自然语言提出需求：增加“最高支出类别”指标，要求走独立分支 + 实时预览 + PR,全程不碰 AI chat、不需要 API key; · 结果直接出现在运行中的应用界面里(Shopping,$1,439.67)，不是聊天窗口里的代码片段，而是活的应用，反馈闭环大幅缩短； · 工具创建分支 base44/setup-00fa13b0，开启 PR #1 ，没有任何东西被自动合并。 最有价值的发现：为什么 PR 审查不可妥协 需求虽小(一个指标)，PR 却改了 4 个文件、跨 2 次提交，其中包括： · 应用主文件 app. py (预期内) · docker-compose.base44.yml、.base44/environment.json(工具自加的配置) · finance.db 数据库文件(完全不该出现在 PR 里的东西) 结论是：即使可见结果看起来完全正确，生成式实现仍可能夹带工程师需要检查、清理或排除的配置和数据变更。评论区也有工程师回应：这种“隐藏的奇怪配置文件”正是最让人警惕的部分。 核心论点 工具改变的不是“要不要审查”，是“谁能在最终审查之前参与”： · 传统流程：提工单 → 口头/书面解释 → 工程师实现 → 审查 → 反复迭代 → 合并 · 新流程：产品人员描述需求 → 实现发生在分支上 → 产品侧直接预览 → 生成 PR → 工程师审查具体的东西 → 合并 工程团队仍然掌握合并权，GitHub 权限、分支保护、CI 检查、审查策略全部照旧生效。对于小而边界清晰的需求，这消除了大量来回沟通。 Sumanth @Sumanth_077 x.com/i/article/2104… 🔗 View Quoted Tweet 💬 1 🔄 0 ❤️ 1 👀 361 📊 1 ⚡
