需求澄清与业务方案
判断需求缺口、比较候选设计，区分 User Fact、AI Proposal 与未决问题，并避免将非阻塞未知变成无谓中断。
01 / UNDERSTAND
理解业务目标，保留重要的未知与决策边界
02 / BUILD
结合知识、工具与平台契约构建原生表单
03 / VALIDATE
用确定性机制与真实反馈判断交付资格
上方是面向用户的能力分组，不是模型必须依序执行的固定认知流程。产品功能的覆盖范围应以具体演示和测试记录为准。
PRODUCT CAPABILITIES能力来自两个世界：
能力来自两个世界：
智能的开放判断，与系统的可靠执行。
以下对应现有 Skill 工程与 Java 工程中的技术方向，而不是脱离项目的新发明。
文档证据理解
结合文档文本、对象声明及实际排版事实，理解原有结构与填写关系，并用于表单字段和布局设计。
领域知识与操作能力
组件属性、默认值、数据绑定、事件与函数等平台知识可按需访问；Action 声明与运行 Scope 形成动态可调用工具。
候选验证与产物发布
结构校验与实际 FormRender 反馈帮助识别问题；正式 Schema 和 Result 的一致性通过事务语义管理。
语义目标，而不是固定步骤
模型能够利用上下文调整设计、补查知识、使用工具；系统不以固定认知阶段替代原生能力。
可读知识，与机器契约尽量同源
领域事实帮助智能判断，Schema 与 Contract 由确定性系统验证，降低认知世界和执行世界的漂移。
交付资格，由真实机制决定
候选、验证、正式结果之间保留清晰边界。模型的提议不会因为“看上去合理”就自动成为系统事实。
反馈是证据，不是自动真理
接受、修改、预览和运行反馈有价值，但需要评价和验证后才能升级为长期知识或规则。
IMPLEMENTATION STATUS明确展示工程基础，
明确展示工程基础，
也明确保留未完成边界。
我们宁愿让能力介绍更精确，也不将技术设想包装成已经交付的商业成果。
已在工程清单中体现
Skill 与能力装配
领域 Skill、平台知识、Package/Action 元模型、任务宿主及动态工具装配。
已有工程建设方向
验证与发布机制
结构检查、受控浏览器渲染、可观察反馈与成对产物发布机制。
仍须逐场景验收
端到端自主修订
完整差量构建、稳定地址追踪、简化比较入口和自主修订效果，不能以模块存在代替验收证据。
关于功能成熟度：本站是根据现有设计与工程能力材料制作的产品官网原型。正式发布前应为关键陈述补充真实测试记录、运行截图或公开 Demo。查看工程边界 ↗
NEXT / EXPERIENCE用一个可操作的示例，
体验表单示例 ↗用一个可操作的示例，
理解结构化表单交付。
切换业务案例、调整字段、验证必填项并导出示例 Schema。