从业务问题到可用应用：Kimpo 应用设计与开发指南
一套面向 Kimpo 应用开发者的完整设计与开发指南。不需要编程能力，也不需要软件实施经验。所需的是理解业务、作出清晰的设计决定，并把这些决定落实为可工作的应用。
这套指南解决什么问题
很多人第一次搭应用时，会立刻打开设计器、创建字段、调整颜色。这样很快就能得到一张“看起来像表单”的页面，却不一定能得到一个真正可用的业务应用：
- 用户填完以后，不知道下一步由谁处理；
- 正常情况能运行，退回、作废、重复提交等异常情况没有设计；
- 所有人拥有相同权限，敏感信息暴露；
- 字段越加越多，但查询、统计和管理问题仍然没有解决；
- 上线后才发现业务部门对“完成”“审批通过”等词的理解并不一致。
这套指南从业务问题开始，依次讲清楚：
- 如何了解需求和发现真正的问题；
- 如何分析人员、业务对象、规则、状态和流程；
- 如何把分析结果转成 Kimpo 应用蓝图；
- 如何分阶段开发，不把所有功能一次堆完；
- 如何用真实业务场景验收、上线和持续迭代。
适合谁阅读
首次开发业务应用
请从第一章开始按顺序阅读。每章只引入当前阶段必须理解的概念，并用同一个案例反复演示。完成每章的“本章产物”，最后就能得到一套完整的应用设计。
已有产品、实施或低代码开发经验
本指南可作为检查框架：
- 需求不清楚时，重点阅读第一、二部分；
- 已经有需求文档时，从“应用蓝图”开始检查是否存在遗漏；
- 应用已经搭好但不好用时，重点看表单体验、权限、测试与迭代；
- 需要具体操作时，直接跳转到现有的功能参考教程。
贯穿案例：办公用品采购申请
整套指南使用一个小而完整的案例：
一家公司目前通过聊天消息申请办公用品，主管在群里回复同意，行政人员再把内容登记到 Excel。随着人数增加，经常出现申请遗漏、金额算错、重复采购、审批记录找不到等问题。公司希望建立一个采购申请应用。
最终应用将支持：
- 员工填写采购申请和多行物品明细；
- 自动计算每行金额和申请总额；
- 根据金额进入不同审批路线；
- 申请人查看自己的申请，主管查看本部门申请；
- 行政人员查看已批准、待采购和已完成事项；
- 保留退回、撤回、作废和修改记录；
- 提供查询、导出和打印能力。
案例只是学习载体。掌握方法后，同样可以设计费用报销、合同用印、客户跟进、设备巡检、库存盘点等应用。
完整学习路线
| 阶段 | 要回答的核心问题 | 主要产物 |
|---|---|---|
| 认识工作 | 应用开发者真正负责什么？ | 开发路线图 |
| 发现需求 | 为什么要做、谁在使用、现在怎么做？ | 业务目标、人员图、现状流程 |
| 分析业务 | 管理什么对象、有哪些规则和状态？ | 业务词汇表、对象清单、规则表、流程图 |
| 设计应用 | 如何组织模板、表单、动作、流程和权限？ | 应用蓝图、数据字典、权限矩阵 |
| 分步开发 | 先做什么、后做什么、怎样尽早验证？ | 可运行应用、版本记录 |
| 验证交付 | 怎样证明业务真的跑通？ | 测试剧本、验收记录、上线清单 |
| 持续迭代 | 上线后如何处理变化？ | 反馈清单、迭代计划 |
章节目录
第一部分：从问题到需求
第二部分：把业务分析清楚
第三部分：把业务转成应用设计
第四部分：在 Kimpo 中分步开发
第五部分：验证、交付和持续改进
第六部分：案例与练习
实用附录
每章怎么学习
每章都按相同方式组织：
- 先理解：用业务语言解释本章概念；
- 看案例：观察采购申请案例如何应用；
- 自己做：完成一个明确的分析或设计产物；
- 做检查：用完成标准和反例检查质量；
- 进入 Kimpo：需要实际配置时，跳转到对应功能教程。
不要跳过纸面分析
这里的“纸面”不一定真的是纸，可以是文档、白板或表格。它的意义是让业务决定先变得清楚，再进入设计器。修改一张分析表的成本，远低于应用搭好后重新改数据、权限和流程。
本指南刻意不讲什么
本指南只讨论业务开发者需要作出的决定，不解释平台内部如何保存、传输或执行数据，也不要求读者理解代码和技术架构。
需要了解“按钮在哪里”“某个控件怎么配置”时，查阅应用开发者功能章节；需要配置用户、组织、平台服务与系统运维时，查阅实例管理者手册。