行业背景
不是“先做一个更聪明的聊天机器人”，而是先用 aily 补齐飞书进入企业业务系统所需的构建能力：让企业把既有数据、流程、API 与权限组织成可运行的智能体，再由 CUI 降低业务人员使用复杂系统的门槛。业务价值优先，AI 与 Low Code 都是实现手段。
“打造数字员工平台，让企业拥抱 AI”
大模型能力变化与竞品研究
自然语言、长上下文、工具使用、多模态和结构化输出持续增强，多模型与本地化接入也成为现实需求，企业智能体由此获得更多交互、任务和部署选择。
ChatGPT 已建立“用自然语言委托工作”的基础期待，但用户仍不信任 AI 的结果。
- OpenAIGPT-4、GPT-4 Turbo、Assistants API
长上下文、Function Calling、JSON Mode 与助手开发原语，让“理解意图—选择工具—返回结构化结果”第一次具备可产品化基础。
- AnthropicClaude 2／2.1／3
长上下文、早期 Tool Use 与多模态能力，增强了企业文档理解和复杂输入处理，但可靠工具执行仍处在早期阶段。
- GoogleGemini 1.0／1.5
多模态和更长上下文继续抬高对跨文档、图片与长材料理解的预期。
- 国内模型Qwen、ERNIE 4.0、豆包
使国内企业具备更多部署与供应商选择，也让私有化、多模型接入和模型治理成为平台必须预留的能力。
行业没有可直接复制的完整标杆，团队从不同产品中提取低门槛构建、办公与业务系统结合、完整生命周期和场景化引导等设计线索。
- 通用定制助手与开发 APIOpenAI GPTs、Assistants API
证明“低门槛创建助手”会迅速成为用户基线，但企业场景还需要补齐数据、权限、调试、发布与运营生命周期。
- 办公／协同与低代码 AI BuilderMicrosoft Copilot Studio、钉钉 PaaS
说明企业 AI Builder 的低门槛不等于隐藏全部复杂度：连接数据与动作可以被引导，但权限、测试、发布和运行状态仍需在关键节点可见、可验证。
- 企业软件内生智能体Salesforce Einstein Copilot Studio、SAP Joule
说明企业智能体必须长在既有数据和业务流程里，设计对象不是孤立聊天界面，而是从构建到治理的完整系统。
- 云平台与企业级 Agent BuilderAWS Agents for Bedrock、Google Vertex AI Agent Builder、百度千帆 AppBuilder、阿里云百炼
说明企业级产品必须同时处理模型、工具、知识、评测与治理；设计需要把技术控制面转译为按角色组织、可调试、可观测的构建流程。
- 跨应用自动化与轻量 BuilderZapier Central、MindOS、Botstudio、Voiceflow、Aurora／myAI
提供连接器、轻量搭建和流程引导参考；aily 不能只追求更轻，还要让结构化数据、确定性 Skill、细粒度权限与白盒调试共同成立。
先保障企业任务可构建、可验证，再逐步降低业务用户的理解门槛，在企业复杂度与上手成本之间建立平衡。
产品定位与目标
aily 是专注 To B 场景的 AI Agent Builder，帮助企业和开发者快速开发符合场景要求的 AI Agent。
连接既有世界：接入企业数据、API、表格与非系统化信息；让 CUI 在需要时展开 GUI／动态界面。
让软件更容易被构建：降低构建门槛，同时保留复杂场景所需的能力、性能和可维护性。
让 Agent 更聪明但不失控：提供调试、评测、调优和观测工具，持续降低“选错工具、执行错误、表现愚蠢”的概率。
产品架构、界面
第一版主体是“应用构建器＋数据／Skill＋发布 Bot”，不是后续能够自主规划、长期运行和 Multi-Agent 协作的 Agent Runtime。aily Studio 承载能力配置与交付；能力域、产品界面与 Maker→User 生命周期的关系如下：
定义智能体
- 能力
- Persona（形象、介绍、通用指令、原则、欢迎语） · Data／Knowledge（结构化与非结构化、在线与离线、读取与写回、持续更新） · Core Model（通用模型与企业模型） · Memory（短期与长期记忆；应用级与跨系统记忆是长期方向）
- 界面
- 首页 · 应用开发 · Framework 配置 · 数据配置
赋予执行能力
- 能力
- 内置 Skill · API Skill · Flow Skill · Sample · Trigger · Debug
- 界面
- Skills 配置 · 自定义 Workflow Skill
承载用户交互
- 能力
- Conversation Framework · On-demand App／UI
- 界面
- Bot／终端对话 · On-demand UI
生命周期与持续运营
- 配置
- 调试与权限检查
- 发布
- 终端使用
- 日志与反馈
- 再发布
设计目标与挑战
先定义要达成什么
- 建立智能体用户心智
让构建者和业务用户理解 aily 是什么、能做什么，以及能力边界和反馈方式。
- 梳理 CUI × GUI 的混合设计范式
让自然语言承担意图表达与开放任务，让 GUI 承担结构化信息、确定性操作和结果确认。
- 降低构建与使用门槛
通过渐进式配置、默认能力、模板和调试反馈，让懂业务的人也能把需求转化为可运行的 Agent。
- 建立可信、可控的反馈机制
把权限、运行状态、执行过程和结果验证转化为用户能够理解和判断的体验。
再看什么阻碍目标
- 产品形态未知
行业没有成熟直接标杆；内部对 Agent、aPaaS 3.0、AI-native 应用等概念也在变化。
- 技术边界快速变化
模型、RAG、工具调用和生成式 UI 的能力与局限持续变化。
- 两端体验同时成立
既要让 Maker 能构建复杂系统，也要让业务用户知道 Agent 能做什么、怎样使用以及是否可信。
设计判断
先做专家用户和真实业务闭环
选择能明确理解业务、数据和 AI 的专家型构建者，先验证高价值场景，而不是一开始把产品做成任何人都能玩的通用 Bot Builder。
先做可控执行，再扩大自主性
1.0 更偏单轮对话、Data、确定性 Skill／Flow、权限与调试。用预设流程和已授权工具降低模型误选、跳过工具和错误执行的风险。
CUI 与 GUI 混合
CUI 用于意图、开放问题、长尾和个性化；GUI 用于高密度信息、明确结构和高效操作。
Demo-first 与快速收敛
这一过程证明形态并非一次设计正确，而是通过 Demo、内部反馈和实际构建不断改写。
上线只是开始， 构建与运营必须闭环
Dogfooding 显示，Agent 需要持续发布、运营、训练与维护；单次构建完成并不等于可持续使用。
设计策略与动作
让 CUI 与 GUI 各自承担长项
KEY TRADE-OFF · 关键取舍自然语言承接意图与长尾问题；结构化界面承载数据浏览、复杂配置、批量操作和高密度结果，不把“AI-native”误解为取消 GUI。
DESIGN ACTIONS · 核心动作建立 CUI×GUI 交互骨架：对话负责意图，结构化界面负责数据、配置、参数确认与结果，并探索 On-demand UI。
按生命周期组织应用工作台
KEY TRADE-OFF · 关键取舍设计对象从单次搭建扩展到持续运营，以开发、授权、发布、运营和调优组织产品，而不是沿用后台菜单。
DESIGN ACTIONS · 核心动作将各阶段收进统一应用工作台并推动发布轻量化；显式呈现 Skill 选择、输入输出、权限、运行状态、日志和反馈，使错误可定位、结果可确认。
用 Demo 与 Dogfooding 校准未知形态
KEY TRADE-OFF · 关键取舍不押注一次性完美架构，通过真实构建和阶段里程碑暴露问题，再逐步收敛产品形态。
DESIGN ACTIONS · 核心动作持续 Demo、Dogfooding 与里程碑验证，推进 Workflow 节点 UI、模型选择器、全局状态、组件与设计范式改造，并用 AI 头像生成等工具提高局部素材效率。
aily 1.0 的关键界面与交互结果
阶段结果
完成企业智能体构建平台的 0→1 与初步内部／客户验证，证明“数据 + Skill／Flow + 权限 + CUI／GUI”能够形成端到端产品；但尚未证明长期留存、规模化客户价值或商业成功。
复盘
- 快速学习必须来自真实实践，而非趋势判断。
- Demo 优先，最高峰保持每日 1 个；早期快速产出，中段比较多种框架，再以内部反馈和实际构建逐步收敛。
- Leader 的价值不是替团队做完，而是建立方向、节奏、判断机制并让团队完成复杂交付。