平台
面向严肃 AI 软件交付的全栈控制台
日志、数据库、网络与错误——在对话旁边可见,让你用证据来调试应用,并把发现的问题直接放进下一条提示词。
全栈控制台是 Ciao Builder 内部的诊断界面:日志、数据库状态、网络请求与错误,都在对话旁边可见。与那些在出问题时让你只能猜测的 AI 构建工具不同,这个控制台展示了整个技术栈上究竟发生了什么——因此下一条提示词携带的是证据,而不是猜测,修复也会落在真正的原因上。
发布日期 2026-07-03 · 最近更新 2026-07-03
调试一个不是你亲手写的应用
当一个你用 AI 构建的应用出现问题时,最糟糕的处境就是靠猜。bug 是出在界面、查询、API 调用,还是数据本身?没有可见性的情况下,一行的修复会变成一个下午投机式的提示词尝试——对着一个黑盒尝试各种措辞,祈祷其中一个能命中。
全栈控制台在 Builder 内部提供了工程师期望拥有的可见性:服务器与浏览器日志、数据库表与行、网络请求与响应,以及带上下文的错误——全都在对话旁边。你能看到究竟发生了什么,然后把证据放进下一条提示词。
这不是一个小众的高级用户专属功能。一旦有东西出了问题、而平台却无法告诉你原因,“用简单语言构建软件”这整个承诺就会崩塌。可见性正是让这份承诺保持诚实的关键。
控制台是如何工作的
一切都发生在对话旁边——重点是让证据和行动待在同一个地方。
1. 在对话旁边打开它
没有独立的工具,没有上下文切换。控制台就位于对话和实时预览的旁边。
2. 阅读日志
来自运行中应用的服务器与浏览器输出,让“它没有正常工作”变成某个具体时间点的某一行具体记录。
3. 检查数据库
查看应用背后真实的 Supabase 表和行。确认那条记录是否真的被写入了,写入了什么值。
4. 查看网络情况
请求、响应、状态码与耗时——在涉及集成和外部 API 时尤其有价值。
5. 在上下文中查看错误
失败会连同产生它的周边活动一起出现,而不是被剥离了来龙去脉的一条裸消息。
6. 把证据变成修复
在下一条提示词中引用你发现的东西。对于线上生产环境的问题,只读的 AI SRE——Doctor——会探测应用、DNS 与 CDN,诊断根本原因并草拟修复方案。
为什么这很重要
带着证据提示,胜过凭感觉提示。“POST 到 /api/orders 返回了 400,那一行也从未出现在 orders 表里”——这样的描述能在一轮之内产出正确的修复;而“订单那个东西坏了”这样的描述,只会产出一次对从来都不是问题所在的东西的重写。控制台让第一种提示词对所有人都成为可能,而不只是工程师。
这在很大程度上正是 AI 辅助工程和满怀希望的闲聊之间的分野:系统展示自己的状态,人来做推理,修复方案则建立在这套技术栈实际做了什么的基础之上。久而久之,这会带来一个更安静的代码库——更少投机性的重写、更小的差异对比,以及一个信任这个应用的团队,因为他们始终能看清它的内部。
它也改变了谁能为一个应用提供支持。一家代理机构或一个运营团队,能用数据而不是升级上报来回答“那笔订单发生了什么?”这样的问题,因为这个问题就在应用所在的同一个地方是可以被检查的。
谁在使用全栈控制台
这个控制台服务于每一个曾经不得不回答“到底发生了什么”这个问题的人。
- 技术型创始人 — 几分钟内诊断自己的应用,而不是每次小故障都升级上报,或盲目地重新提示。
- 代理机构 — 专业地为客户应用提供支持——复现问题、阅读证据、发布经过审核的修复方案。
- 开发者 — 在把生产数据托付给 AI 编写的后端行为——查询、写入、API 调用——之前先验证它。
- 运营团队 — 确认应用和现有系统之间的数据流,确实在做集成所承诺的事情。
安全与治理说明
可见性是强大的能力,因此它随附有相应的控制:
- ✓ 包括控制台在内的工作区访问权限,遵循基于角色的访问控制。
- ✓ 由控制台证据驱动的修复,依然要经过 Guardrails 审核和 QA 关卡才能发布。
- ✓ Security 会在标记漏洞前,先针对真实应用确认它们——只呈现发现,而非噪音。
- ✓ Doctor 保持只读运行:它探测、诊断并草拟修复方案,但变更依然通过受治理的闭环发布。
- ✓ 每一次修复背后的提示词、合并与部署都会落入只增不减的审计日志。
控制台展示什么
四个界面覆盖了大多数从头到尾的调查过程:
| 界面 | 你能看到什么 | 它回答什么问题 |
|---|---|---|
| 日志 | 来自运行中应用的服务器与浏览器输出 | 执行了什么,报告了什么 |
| 数据库 | Supabase 的表、行与数值 | 数据是否真的发生了变化,如何变化的 |
| 网络 | 请求、响应、状态码、耗时 | 应用和外部系统之间说了什么 |
| 错误 | 带有周边上下文的失败信息 | 哪里坏了,以及之前发生了什么 |
常见问题
我需要外部工具来调试一个 Ciao 构建的应用吗?
对于日常工作,不需要——日志、数据库、网络与错误都可以在 Builder 内部检查。因为应用是你拥有的标准 React、TypeScript 与 Supabase 代码,你的工程师也可以接入他们偏好的任何外部工具。
我能查看真实的数据库吗?
可以。控制台展示你应用背后的 Supabase 表和行,因此你可以确认一次流程实际写入了什么。这通常是区分界面 bug 和数据 bug 最快的方法。
控制台和 Doctor 是什么关系?
控制台是你亲自查看技术栈;Doctor 是一个只读的 AI SRE,替你去查看——探测线上应用、DNS 与 CDN,诊断根本原因并草拟修复方案。两者搭配使用效果最好:Doctor 负责生产环境事故,控制台负责构建期间的调查。
团队里谁能看到控制台?
访问权限遵循工作区上基于角色的访问控制,因此由你决定谁能检查日志和数据。企业计划还在此之上增加了通过 SAML 与 OIDC 实现的 SSO 以及可选的多因素认证。
使用控制台会在我发布修复方案时绕过治理流程吗?
不会。控制台为修复方案提供信息;这次修复依然要在 Guardrails 之下合并并记录人工审核,发布前通过 QA 冒烟测试关卡,并被记录进只增不减的审计日志。