最新资讯
dev.to 部署 Underdog Bark 3.0 Pro:逐字转写、自定义后端与分块设置 dev.to 为艰难对话构建 AI:五个 Agent、一条安全正则与一位盲评监督者 techcrunch.com Palo Alto Networks 洽谈以 5 亿美元收购 AI Agent 安全初创公司 Clutch theinformation.com 黄仁勋被要求就涉华间谍指控向国会作简报 www.infoq.com Edera 推出 Object Capability Bounded Authority,试图将凭证与 AI Agent 工作负载隔离 wechat 这波杀疯了!旗舰级模型不限量、1个月视频额度免费领 bloomberg.com AI 抛售蔓延至信用市场,软银领跌亚洲美元债 dev.to 如何在专用 GPU 服务器上用 OpenAI 兼容 API 部署 LLM dev.to 审计 153 份 Claude Code 与 Codex 会话记录:User-Agent 与 URL 中的邮箱泄露 dev.to 你的 Agent Harness 应具备的 17 项能力 dev.to 离线 AI 记忆中 0.8 余弦阈值为何失效 dev.to Kimi K3.1 Pro 开放权重:自托管 2.8T 模型前的开发者清单
多元动态
登录 注册
智能体 x.com · @meng shao(@shao__meng)

Base44 Base Code 实测:非工程师参与生产代码库的边界与 PR 审查风险

原文 我的收藏

转述 @Sumanth_077 对 Base44 Base Code 的实测:不让工具从零建应用,而是接入已有 GitHub 仓库(因无写权限在 fork 上操作),自动检查项目、安装依赖、修复端口配置并运行 Streamlit 个人财务 Agent(88 笔交易,总支出 $4,907.03)。用自然语言提出增加“最高支出类别”指标,要求独立分支、实时预览与 PR,结果直接出现在运行中的应用界面(Shopping,$1,439.67),工具创建分支 base44/setup-00fa13b0 并开启 PR #1,未自动合并。关键发现是需求虽小,PR 却改动 4 个文件、跨 2 次提交,除 app.py 外还包含 docker-compose.base44.yml、.base44/environment.json 以及不应出现在 PR 中的 finance.db,说明即使可见结果正确,生成式实现仍可能夹带需工程师检查或排除的配置与数据变更。作者认为工具改变的是“谁能在最终审查之前参与”,合并权、分支保护与 CI 检查仍由工程团队掌握。

AI推荐理由 转述 @Sumanth_077 对 Base44 Base Code 的实测:让非工程师接入已有 GitHub 仓库(fork 上操作),用自然语言提出增加“最高支出类别”指标,工具自动检查项目、装依赖、修端口并跑起应用,生成独立分支 base44/setup-00fa13b0 与 PR #1,未自动合并。具体新信息是 PR 实际改动 4 个文件、跨 2 次提交,除 app.py 外还夹带 docker-compose.base44.yml、.base44/environment.json 以及不应出现的 finance.db,说明生成式实现可能夹带配置与数据变更,PR 审查不可省略。对 AI 编码工具与工程管控流程有参考价值。局限:为个人实测转述,非官方评测,样本单一,效果与风险结论不能推广。

70

正文

非工程师也能安全参与生产代码库开发:Base44 Base Code 实测 来自 [@Sumanth\_077](https://x.com/Sumanth_077) 对 [@Base44](https://x.com/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 检查、审查策略全部照旧生效。对于小而边界清晰的需求,这消除了大量来回沟通。 ![Tweet Image](https://pbs.twimg.com/media/HTbZ5hKbgAAzVmP.jpg) ![Sumanth](https://pbs.twimg.com/profile_images/1777698745108606976/NH-IIitW_normal.jpg) Sumanth@Sumanth\_077 [x.com/i/article/2104…](https://x.com/i/article/2104801612430786560) [🔗 View Quoted Tweet](https://x.com/Sumanth_077/status/2104940061657895289) 💬1🔄0❤️1👀361📊1

来源报道 · 1 篇 · 以下链接均前往原始媒体

← 返回精选动态 原文

更多内容