第一次生成的系统，几乎总有一些地方不符合预期。这很正常——重要的是接下来的处理方式。
先诊断：是哪种"不满意"
| 类型 | 表现 | 根源 | 改法 |
|---|---|---|---|
| 方向错 | 整个系统的结构、流程与预期完全不同 | 需求描述不清或方案未确认 | 需要重新来 |
| 字段错 | 某些字段缺失、多余、命名不对 | 字段定义未仔细核对 | 增量修改，成本低 |
| 细节错 | 布局、顺序、文案、某个按钮位置 | 个人偏好差异 | 增量修改，成本极低 |
| 流程错 | 某个环节走不通、缺少分支 | 异常场景未描述 | 增量修改，中等成本 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
最重要的一步是判断属于哪一类。方向错要重来，其他三类都是增量修改。很多人把"细节错"当成"方向错"，直接推倒重来，浪费了大量时间。
类型一：方向错 —— 什么时候该推倒重来
判断标准
以下情况属于方向错：
- 核心业务流程完全不对（如你要的是"先报价后下单"，系统做成"先下单后报价"）
- 主要使用者不是你设想的那批人（如给业务员用的，做成了给管理者看）
- 数据结构根本性不符（如你需要一个客户多个联系人，系统做成一个客户一个）
怎么改
不要在原系统上硬改，重新走一遍需求确认流程。这次重点补上上次遗漏的信息：
| 上次可能漏了什么 | 这次补什么 |
|---|---|
| 没说清楚业务流程 | 画一遍流程图或写清楚状态流转 |
| 没说清楚使用者 | 明确角色和使用场景 |
| 没说清楚数据结构 | 列出你的 Excel 列名 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
如何避免下次发生
认真看方案文档。 方向错的问题在方案阶段 100% 能发现——因为方案里会写明流程和数据结构。
类型二：字段错 —— 最常见的修改
常见情形
- 少了一个字段（如没有"客户等级"）
- 多了一个用不到的字段
- 字段命名与内部习惯不符（如系统叫"客户类型"，你们叫"客户分类"）
- 取值范围不对（如状态少了"已关闭"）
怎么改
用自然语言描述即可：
“"客户表增加一个'客户等级'字段，取值 A/B/C，默认 B。"”
“"订单状态增加'已关闭'，可以从'已报价'和'谈判中'转过来。"”
这类修改通常是分钟级到小时级。
一个技巧：描述修改时，说清楚"在哪里、加什么、取值范围、默认值"。 four 要素齐全，一次就能改对；含糊描述（"加个等级"）往往要来回两三次。
类型三：细节错 —— 不要忍，直接改
常见情形
- 列表的字段顺序不符合使用习惯
- 常用功能藏得太深
- 按钮文案不准确
- 颜色、字号、间距不合偏好
为什么不要忍
小问题积累起来会严重影响使用体验。使用者说不出"哪里不好"，但会感觉到"不好用"，然后慢慢减少使用。
这类修改成本极低，应该立刻改。
怎么提
具体描述位置与期望：
“"客户列表页把'最近跟进时间'移到第二列。"”
“"报价单页面的'导出 PDF'按钮改成主按钮样式，放在右上角。"”
类型四：流程错 —— 需要说清楚分支
常见情形
- 某个状态无法流转到另一个状态
- 缺少取消/退回的路径
- 审批流程不对
怎么改
描述清楚"在什么情况下、应该能做什么"：
“"已报价状态的订单，客户取消时应该能直接转为'已取消'，需要填写取消原因。"”
描述流程修改时的一个要点：说明触发条件和结果。只说"要能取消"不够，要说"在什么状态下、由谁操作、取消后变成什么状态、需要记录什么"。
增量修改是怎么工作的
理解这一点，能让你更高效地提修改需求。
| 步骤 | 说明 |
|---|---|
| 定位 | 系统在已有结构中定位相关模块 |
| 修改 | 只改动相关部分，其余保持原样 |
| 验证 | 确认修改没有影响其他功能 |
| 发布 | 只更新变更的部分 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
这就是"增量发布"的价值：改一个字段不需要重新生成整个系统，也不需要停机。
一个重要的前提：备份
重大结构调整前，先备份当前版本。这样如果改完不满意，可以退回。
什么时候该"忍一忍"
不是所有不满意都要立刻改。以下情况建议先观察：
| 情况 | 为什么 |
|---|---|
| 只是不习惯 | 用一周后可能就习惯了 |
| 不影响核心流程 | 优先级低，可以排到后面 |
| 涉及多人使用习惯 | 先收集其他使用者的意见 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
一个实用的做法：建一个"待改清单"，把发现的问题记下来，但不立刻改。积累一周后集中处理，效率更高，也能区分出"真的重要"和"其实无所谓"。
修改的优先级排序
| 优先级 | 类型 | 理由 |
|---|---|---|
| P0 | 导致核心流程走不通 | 必须立刻改 |
| P1 | 字段缺失或错误，影响数据记录 | 尽快改 |
| P2 | 常用功能入口太深 | 影响日常效率 |
| P3 | 视觉偏好、文案细节 | 有空再改 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
按这个顺序处理，能把有限的精力用在刀刃上。
“生成完不满意，说明流程正在起作用——因为你在验收，而不是盲信。”— 初元AI 团队
改一次需求要多久？+
取决于改动范围。改字段、改布局、加流程分支，通常是分钟级到小时级。改变整体数据结构或核心流程，可能需要数小时到一天。对比之下，传统开发模式下任何改动都要走"提需求 → 排期 → 开发 → 测试"的流程，周期以天或周计。差距主要来自增量修改机制——只改变化的部分，不需要重新生成整个系统。
改来改去会不会把系统改乱？+
有可能，如果改动没有记录。建议的做法是：每次重要修改前备份，并记录改了什么、为什么改。这样一方面可以退回，另一方面能追溯"当初为什么这么设计"。另外，避免频繁推翻性改动——如果同一处改了三次以上，通常说明需求本身没想清楚，应该停下来重新梳理，而不是继续试。
改完之后需要重新验收吗？+
需要，但可以只验改动相关的部分。重点确认两点：一是改动是否达到预期；二是改动有没有影响其他功能（尤其是与该模块有数据关联的模块）。养成"改完就验"的习惯，能避免问题累积。小改动验一遍核心流程即可，大改动建议完整走查。
本文修改策略基于增量修改机制的通用工作方式，具体操作方式因方案而异。