开发原则:按需调用接口,及时反馈状态
好的产品实现不应该一上来就把所有重数据接口都打满,也不应该让用户操作后停在无反馈状态。接口调用要跟随用户真实交互,UI 状态要清楚表达进行中、成功和失败。
- Product
- Engineering
- UX
- Frontend
- React
文章归档
这里的文章默认按时间倒序排列。内容文件继续用 MDX 写,页面路由和后端能力则已经切到 Next.js App Router。
好的产品实现不应该一上来就把所有重数据接口都打满,也不应该让用户操作后停在无反馈状态。接口调用要跟随用户真实交互,UI 状态要清楚表达进行中、成功和失败。
AI 软件研发平台不是在 IDE 里接一个聊天框,也不是把代码生成做得更快。更本质的问题,是怎么把上下文、契约、验证、工作流和平台型领域知识一起组织起来。
比起先说产品文档还是技术文档,更重要的是先固定统一的分类轴。沿内容性质这条轴看,很多文档都在定义行为,或者定义怎么实现。
真正能把 AI 用好的关键,往往不是把提示词写得更花,而是先把上下文、边界条件、判断标准、验证方式和错误处理流程设计清楚。
在 AI 时代,产品设计不再只是写需求说明。场景和用例、页面 URL 与跳转关系、OpenAPI、E2E 测试、六边形 domain 逻辑与测试,以及可跑通的页面框架,都可以在设计阶段被直接定义和落地。
如果说 agent skill 解决的是单点任务经验复用,那么 GEM 要解决的是更完整的 AI 能力模块化问题:输入输出契约、模块协作关系,以及面向 UI 的适配定义。
想让 Chat 真正理解用户正在看的页面,不能只靠截图,也不能只靠后端数据。更稳的做法是把截图、页面数据接口和未提交状态数据联合起来,形成完整 context。
面向 HTML 转 PDF 的静态报告系统,真正要解决的不是按钮和卡片复用,而是文档级配置、页面系统、图表表格规范、分页约束和最终成品质量。
真正决定 AI 产出上限的不是模型本身,而是人的判断力、标准感、工作流设计和复盘能力。把 AI 放在“参谋 + 执行协作者”的位置,比把它当全自动指挥官更可靠。
设计这类库时,先固定 use case,再固定 pipeline,再定义阶段产物,最后才讨论 node 变体、代码结构和测试。
学数学、计算机这类抽象学科时,真正有效的不是更努力地盯定义,而是用例子、心智模型、可视化、反例和输出不断在具体与抽象之间往返。
对 6 岁孩子来说,加减乘除最好的学习顺序不是先刷题和背口诀,而是从生活情境、动手操作、画图表示和口头解释开始,逐步过渡到算式和迁移。