Kimpo使用指南
v1.0当前版本
文档版本当前使用指南
v1.0当前版本2026-10-18 · 1.0.0-standard-betav1.0 更新日志

当前仅提供 1.0 使用指南

探索完整手册按场景查找更多操作方法

从最小闭环开始增量开发 ​

本章目标：把完整蓝图拆成一系列可以独立验证的小步，每一步都得到真实业务反馈，避免所有功能完成后才发现基础方向错误。

1. 什么是最小闭环 ​

最小闭环不是“只做半张表单”，而是用最少内容完整走通一项业务：

text
创建记录 → 填写核心信息 → 保存 → 重新打开 → 查看结果

采购应用的第一个最小闭环可以只有：

  • 一个“采购申请”模板；
  • 申请用途；
  • 一行简单明细；
  • 总金额；
  • 保存；
  • 我的申请视图；
  • 一个测试用户能够创建并重新打开。

它暂时没有复杂流程和通知，但已经能验证：

  • 应用结构是否合理；
  • 主信息与明细是否正确；
  • 用户是否理解表单；
  • 数据能否按预期保存和查询。

2. 为什么不要一次性全部开发 ​

一次性开发的风险：

  • 早期的数据设计错误影响所有动作和流程；
  • 业务人员直到最后才看到真实使用体验；
  • 出现问题时难以判断是哪一部分造成；
  • 权限、动作、流程相互叠加，排查困难；
  • 范围容易在开发中继续扩大。

增量开发让每一阶段都有明确产物和停止条件。

3. 开发前准备 ​

3.1 确认蓝图版本 ​

记录本次开发使用哪一版：

  • 需求范围；
  • 数据字典；
  • 表单草图；
  • 规则表；
  • 流程图；
  • 权限矩阵；
  • 测试场景。

3.2 准备测试角色 ​

至少准备：

  • 申请人；
  • 直属主管；
  • 行政采购员；
  • 行政负责人；
  • 应用管理员。

不要一直用应用管理员账号开发和测试。

3.3 准备示例数据 ​

使用接近真实但不含敏感信息的样例：

  • 普通金额申请；
  • 恰好边界金额；
  • 高金额申请；
  • 多行明细；
  • 退回后修改；
  • 缺货和作废。

3.4 建立开发清单 ​

每项记录：

  • 对应需求编号；
  • 要配置什么；
  • 完成后怎样验证；
  • 依赖什么；
  • 当前状态；
  • 发现的问题。

4. 阶段一：建立应用骨架 ​

完成：

  1. 创建应用；
  2. 设置清楚的名称和说明；
  3. 建立第一版目录；
  4. 创建核心模板；
  5. 配置最小字段；
  6. 保存并试填一条记录；
  7. 重新打开确认内容；
  8. 建立最简单的“我的申请”入口。

此阶段不急着做：

  • 完整样式；
  • 所有字段；
  • 复杂动作；
  • 多条流程；
  • 正式通知；
  • 管理看板。

操作可参考从零创建一个应用和应用主页与目录树。

阶段一验收 ​

  • [ ] 测试申请人能进入应用；
  • [ ] 能创建一条最小申请；
  • [ ] 保存后重新打开内容一致；
  • [ ] 能在列表中再次找到；
  • [ ] 未授权测试用户看不到应用；
  • [ ] 业务用户认可基本结构和词语。

5. 阶段二：完成数据与表单 ​

按数据字典逐步加入：

  1. 主信息；
  2. 采购明细；
  3. 字段类型和显示格式；
  4. 默认值；
  5. 分组和布局；
  6. 新建、修改和查看行为；
  7. 基础校验；
  8. 必要附件和说明。

建议每增加一组相关字段就试填，不要一次加完几十个字段。

具体操作参考：

阶段二验收 ​

  • [ ] 正常申请可以快速填写；
  • [ ] 草稿可以保存；
  • [ ] 提交所需信息能够完整表达；
  • [ ] 明细新增、修改和删除符合预期；
  • [ ] 查看状态下不会误导用户以为可以编辑；
  • [ ] 申请人和审批人都能找到所需信息；
  • [ ] 保存并重新打开后表单仍然正确。

6. 阶段三：加入计算、校验和动作 ​

推荐顺序：

  1. 行金额计算；
  2. 总金额汇总；
  3. 输入校验；
  4. 提交前完整性检查；
  5. 必要的数据带出；
  6. 业务按钮和提示；
  7. 异常反馈。

一次只加入一类动作，验证通过再继续。操作参见动作设计器和动作调试。

阶段三验收 ​

  • [ ] 单行、多行、修改和删除后的金额都正确；
  • [ ] 空值、零、负数和边界值处理正确；
  • [ ] 动作失败时用户知道哪里错、怎样改；
  • [ ] 重复点击不会产生重复业务结果；
  • [ ] 保存后重新打开，计算结果仍符合业务规则；
  • [ ] 动作之间没有互相覆盖。

7. 阶段四：加入角色、权限和基础视图 ​

先做权限，再让更多测试用户进入：

  1. 创建业务角色；
  2. 分配测试成员；
  3. 配置应用和模板访问；
  4. 配置新增、查看、修改等操作；
  5. 配置数据范围；
  6. 创建“我的申请”“部门申请”“待采购”等视图；
  7. 用每个角色账号验证。

操作参见权限与授权和视图设计器。

阶段四验收 ​

  • [ ] 每个角色能完成自己的任务；
  • [ ] 看不到与自己无关的入口；
  • [ ] 申请人不能查看他人记录；
  • [ ] 主管只能在职责范围内查看和处理；
  • [ ] 行政能看到待采购但不能修改申请内容；
  • [ ] 未授权操作不只是按钮隐藏，实际也不能完成；
  • [ ] 视图默认范围和排序支持日常工作。

8. 阶段五：加入审批流程 ​

推荐顺序：

  1. 先做最简单的主管审批；
  2. 发布并用于采购申请；
  3. 走通提交、同意和结束；
  4. 加入退回、拒绝和撤回；
  5. 加入高金额分支；
  6. 加入通知和超时规则；
  7. 测试人员缺失和重复提交。

不要一开始就加入所有高级节点。先证明主路径可靠。

操作参见审批流程快速上手、审批人规则和监控与排错。

阶段五验收 ​

  • [ ] 普通、高金额和边界金额进入正确路线；
  • [ ] 处理人正确；
  • [ ] 退回后能修改并按约定重提；
  • [ ] 拒绝、撤回和作废状态正确；
  • [ ] 流程结束后进入待采购；
  • [ ] 无处理人时明确失败；
  • [ ] 重复点击不会形成重复审批。

9. 阶段六：补齐输出和管理能力 ​

根据第一版范围加入：

  • 管理视图；
  • 超时和异常清单；
  • 月度统计；
  • 导出；
  • 打印或 PDF；
  • 必要通知；
  • 定时提醒；
  • 应用日志和问题排查入口。

只实现已经有业务使用者、口径和验收标准的输出。

10. 每一小步都执行“五步验证” ​

配置一项功能后：

  1. 保存：确认配置保存成功；
  2. 重新进入：关闭后再次打开，确认配置仍在；
  3. 实际使用：以目标角色完成真实操作；
  4. 验证反例：输入错误或使用无权限账号；
  5. 检查业务结果：确认状态、数据、待办和视图真正变化。

“配置界面上看见了”不等于业务运行时已经生效。

11. 发现设计错误时怎么办 ​

暂停扩建，先判断：

  • 是配置错误；
  • 是蓝图遗漏；
  • 是业务规则冲突；
  • 是当前能力差距；
  • 还是新需求。

处理顺序：

  1. 记录复现场景；
  2. 回到对应设计产物；
  3. 确认是否需要业务决定；
  4. 修改设计和追踪表；
  5. 修正当前阶段；
  6. 重新执行已经受影响的测试；
  7. 再继续下一阶段。

不要为了让演示继续，临时加入没有记录的绕行配置。

12. 开发过程中的范围控制 ​

遇到新想法时记录到变更清单：

新想法是否阻塞核心闭环价值影响决定
加供应商比价否中新对象、新流程后续
增加退回原因是高表单、流程、测试本阶段加入
做彩色看板否低视图与样式暂不做

只有阻塞第一版目标或修复严重遗漏的内容，才应进入当前开发。

13. 常见错误 ​

  • 一开始就完成所有字段和流程；
  • 全程只用管理员账号；
  • 配置保存后不重新进入检查；
  • 页面上有变化就认为业务结果正确；
  • 每发现问题都继续加补丁，不回到蓝图；
  • 新想法不经评估直接加入；
  • 只测成功路径，不测错误和越权；
  • 最后才让真实用户试用。

14. 本章完成标准 ​

  • [ ] 开发被拆成可独立验证的阶段；
  • [ ] 第一阶段已经形成最小闭环；
  • [ ] 每阶段都有明确包含、不包含和验收条件；
  • [ ] 目标角色账号参与验证；
  • [ ] 每项关键配置都经过保存、重开、使用、反例和结果检查；
  • [ ] 新需求进入变更清单，没有悄悄扩大范围；
  • [ ] 设计错误会回写蓝图和测试，而不是只修当前页面。

下一步 ​

应用能够运行后，还需要安全地发布和持续修改。下一章学习版本、发布与变更管理。

使用者 · 应用开发者 · 实例管理者

Kimpo 使用指南