Appearance
织信 x Workbuddy 实战开发（三）从零搭建可闭环的销售管理系统
用 AI Agent 对接织信 Informat，从一句话需求做到上线可跑：6 张表、1 条带金额分支的审批流、10 张看板卡、2 条自动化，外加一个会自己上网查客户情报的按钮。
- 项目织信 Informat「销售管理」——线索、客户、跟进、合同、回款、开票，外加审批流和看板，全部由一段对话搭建而成
- 周期11 月 2 日上午 11:35 提出需求 → 下午 16:15 最后一版上线，中间隔 4 小时 40 分；真正动手的时间是 148 分钟
- 难点
- 这套系统不难搭——6 张表、1 条审批流、10 张看板，平台原生的配置半小时就能立起来。真正花时间的是另一件事：把销售部门脑子里的规矩，一条一条问出来、摆进系统里。
- 一句话需求只说了"销售在线索层面跟进，直到签单"。可签单之后谁接手、10 万以上要不要总监批、签约后哪些字段还能改、销售能不能看同事的客户——这些没人写在需求里，但每一条都决定这套系统明天能不能真用。业务方自己也常常是看到系统之后才想起来"对，这个也得管"。
- 所以这类项目真正的难点是把隐性规矩显性化：问得够不够细、理解得够不够准、改得够不够快。这一次，这三件事压在了同一个下午。
目录
- 需求与背景 — 一句话开出的系统
- 时间轴 — 六步，148 分钟
- 实操 — 每一步人做什么、AI 做什么
- 需求细化实录 — 七次从"能跑"到"好用"
- 提问模板库 — 九组说法对照
- 能力补充 — 十二条写进工具的规则
第 1 章 需求与背景
这个项目没有需求文档，也没有原型评审。全部输入就是 23 条对话，第一条就把业务讲完了，后面二十来条都在补细节、纠偏差。
1.1 第一句话就是设计方案
11:35 · 第一条需求，387 个字
"我要创建一个销售管理应用来管理我们销售部门的工作。核心需求如下：1、要有线索管理，我们的线索主要是来自于官网主动填写的表单，极小部分来自于线下拓客。销售主要在线索层面跟进，直到签单。2、签单后，转为我们的客户，所以要有客户管理。客户要能绑定对应的合同，付款以及开票管理。3、线索管理分为：待跟进、跟进中、暂停中、已签约、关闭，这5种状态。4、每个线索有一个跟进记录管理。记录销售每一次的跟进行为和内容。跟进行为分为：电话跟进、微信跟进、线上/线下会议、商务洽谈、项目投标、合同签约。请先根据这些需求出一个设计方案"
这段话里其实已经藏好了整张数据模型：线索是主线（"销售主要在线索层面跟进，直到签单"），签单是一次身份转换（"签单后，转为我们的客户"），客户下面挂合同、付款、开票，跟进记录挂在线索下面。剩下的只是枚举值和显示顺序。
三分钟后，四条编号答复把最后几个岔路口一次拍完：需要审批、客户维护也记进跟进记录、不建月度目标表、线索来源精简成两项。11:52 又定了一条边界——不铺 23 个成员，应用里只留自己一个人。这条决定省掉了一整套成员导入和权限矩阵，也顺手埋下了后面第六个问题（审批人解析为空）。
1.2 每句话背后的意思
把 23 条对话按时间排开，能看出一个规律：用户很少说"要什么功能"，说的都是"我在什么场景下要看到什么"。下面这张表是这次全部对话的归纳——左边是原话，中间是这句话真正要的东西，右边是它对方案构成的硬约束。
| 时间 | 原话（节选） | 背后要的是 | 锁死了什么 |
|---|---|---|---|
| 11:35 | "线索主要是官网表单…销售在线索层面跟进，直到签单""签单后转为客户" | 一条线索的生命周期，和它变成客户的时刻 | 6 张表的主从关系；签约是状态值，也是一个触发点 |
| 11:38 | "1、需要审批。2、是的，也放在跟进记录里。3、暂时不建。4、精简成2项" | 四条岔路一次拍完，不要来回问 | 有审批流；客户维护也算跟进；砍掉一张表；来源只留 2 项 |
| 11:52 | "不需要把23个人都加进去，先我在里面就可以了" | 先自己试跑，不铺开 | 不调成员接口；审批人只能落到本人，不能靠上级关系 |
| 11:56 | "客户相关信息是在已签约的时候才显示的""客户表单，应该先填写客户基本信息，而不是看到合同、回款、开票" | 表单要按销售真实的操作顺序排，不按数据库结构排 | 字段要能按状态条件显示；分组顺序=业务顺序 |
| 13:34 | "所属行业…用列表选择来管理""默认状态为待跟进，默认线索日期是今天，默认销售负责人是当前用户""字段分组采用页签展示形式" | 少点几下、别填错、别在一屏里翻三页 | 枚举字段；三个默认值用表达式；页签（这一条平台写不进去，后述） |
| 13:56 | "我发现商机表里没有关联客户的字段了，是不是之前你给删掉了…一旦签约，我是需要从商机能够直接跳转到客户表的" | 不是要加字段，是要"跟进时看不见、签约后能跳" | 条件显示（不是隐藏）；字段要可点击跳转 |
| 13:57 | "跟进记录不需要绑定客户，只需要绑定商机即可" | 别为了数据完整多挂一条关系 | 跟进表只留 leadId，删掉 customerId |
| 14:24 | "1、两个按钮…放到详情页里。2、新增销售总监和销售人员角色…做2个数据页签来过滤。3、查找列表类字段全部100%展示。4、写一份html使用手册…放在第一个菜单" | 四件事一次说完：入口、权限、版面、文档 | 表单工具栏按钮；两个角色；LookupList 宽度 100；网站模块排首位 |
| 14:53 | "提交签约转客户审批，线索名称和客户公司名称没有自动带出来""所有的子表里面都应该可以直接访问对应记录的详细信息" | 审批时要看见是哪个单子；子表要能点开看 | 发起方式要绑已有记录；子表要有查看入口 |
| 15:11 / 15:35 | "发起审批时系统报错：提示错误:参数错误工作流定义不存在""他是两条分支同时再走…又出现了一个重复的确认建档节点" | 流程要走得通，还要走得对 | 发起参数必须是 key；两条出线都要有互斥条件 |
| 15:48 | "根据线索里「客户公司」名称，去网上搜集相关信息，填入到富文本里，包括但不限于，客户规模，核心产品，行业地位" | 点一下就有可用情报，不要人去搜 | 输入字段、输出字段、内容口径三样都落到具体字段 |
这张表最有用的一栏，是"背后要的是"
13:56 那条如果按字面理解，是"把字段加回来"；按背后的意思理解，是"跟进阶段看不见、签约之后能跳过去"。两种理解对应两种做法：前者会加一个重复字段，后者是把
hidden和可见表达式配对使用。照字面做会返工，照意思做一次就对。
1.3 这个项目的三个难点
难点不在建表。6 张表、4 个审批节点、10 张卡片，平台原生的配置动作加起来只花了 31 分钟。真正耗时间的是下面三件事。
**第一，业务是一条首尾咬合的链。**线索的 5 个状态看着简单，它同时决定了看板口径、销售考核和跟进节奏；"签单"也不是打个标记，是换成客户身份——客户下面才挂得上合同、回款和开票。这类结构只要有一处定错，后面每张表都要跟着返工。所以动手前把数据模型定对，比快速开工更值钱。
**第二，真正的规则藏在人脑子里，需求里不会写。**金额多大要上级批、签约之后哪些字段该锁死、销售能不能看同事的客户——这些没有人写在需求里，但每一条都决定这套系统明天能不能真用。整个下午追问了 23 轮，把它们一条条挖出来，再变成审批分支、可见性规则和角色权限。
**第三，交付标准是"明天销售就能上手"，不是"表建完了"。**所以要灌像真的种子数据、做业务看得懂的看板、写一页能照着做的手册、把角色配好。真正花时间的从来不是建表那 31 分钟，而是让它在真实业务里站得住。
三件事叠在一起，说明这类项目的成本不在"搭"，在"问"和"对"
搭建是确定的：表怎么建、流程怎么画，都有标准答案。而"这条规则到底该怎么算"没有标准答案——只有业务方说了才算。所以真正决定交付速度的，是能不能一次问对、改得够快。这一次的答案是：23 轮问清，148 分钟上线。
1.4 三个没想到，和当时的处理
计划内的东西都顺利，真正需要现场判断的是这三处。它们不是坑，是只有跑起来才会知道的机制细节——知道了，下次提前十分钟就能定下来。
| 没想到的地方 | 原来的理解 | 实际的机制 | 怎么处理 |
|---|---|---|---|
| 脚本里拿不到 AI 助手的联网插件 | 助手配了联网插件，脚本调一下就能拿到网页内容 | 插件能力运行在助手对话里，脚本是另一个执行上下文，取不到那份配置 | 把职责切开：脚本负责检索和抓正文，AI 只做归纳。附带好处是模型只能基于给定材料写，天然抗编造 |
| "打开发起表单"会先新建记录 | 这个动作就是"弹出表单让人填" | 它会先在启动表里插一条空白记录，再基于它发起——所以表单永远是空的，提交后主表多一条重复数据 | 改用预填表单 + 脚本按记录发起，把流程绑在已有商机上，不产生新记录 |
| 多出口时那条"兜底线"一定会走 | 留一条不写条件的出线当"否则"，是常见做法 | 平台的多出口语义是「条件成立的分支 + 无条件分支全部触发」，所以默认线不是"否则"，是"总是" | 两条出线都写条件并且互斥，空值短路兜底。三种金额各跑一遍确认为止 |
这三个都指向同一件事：跑一遍，比读十遍文档快
它们没有一个是"不会用"造成的，全都是说明书讲的是能力，运行时给的是具体行为。中间的差别，一次真实调用就能确认——成本通常只有几十秒。这也是为什么这次每个功能做完都当场跑一遍：跑过的东西才敢写进手册交给销售。
第 2 章 时间轴：六步，148 分钟
以 11:35 那条需求为起点，到 16:15 最后一次发布，中间按实际发生的顺序切成六步。这张图能直接看出时间花在哪：搭出第一版只用了 50 分钟，剩下 98 分钟都花在把业务规则一条条对清楚——这也是这类项目真正的成本所在。
2.1 逐步详解
第 1 步 · 骨架搭建 — 31 分钟
做了什么：先把 11:35 那段话翻成设计方案（表结构、关联、流程、看板），给你过一眼；确认后串行建 6 张表，主表先建，跨表关联和汇总统一在最后补一次；再搭 4 节点审批流、10 张看板卡、监听器和定时任务，然后首次发布。
产出物：一个完整上线的 v1。发布返回 finish，草稿数 0，平台自检是空清单。
核心要点：写操作必须串行。并行建表会互相覆盖，这是低代码平台最常见的自伤方式。另外是先给结构再问细节——如果一开始就逐个字段确认，光对齐就得多花半小时。
第 2 步 · 表单压测 — 19 分钟
做了什么：按三条要求改字段（行业改 18 项列表选择、补三个默认值、分组顺序按业务流排）；灌入 100 条线索、25 个客户、260 条跟进、34 份合同、102 笔回款、46 张发票，一共 517 条；批量写入不触发汇总字段重算，所以六个汇总值自己算好回写。
产出物：已签约金额 2,591.9 万、待回款计划 1,165.8 万；25 条签约线索 100% 能跳到对应客户；10 张看板卡全部有数。
核心要点：造数据不是为了好看，是为了验图表。没有数据的看板就是十张空白卡，看不出任何问题。数据还要铺开日期、负责人、状态，否则趋势线是平的、饼图只有一块。
第 3 步 · 角色与手册 — 34 分钟
做了什么：四条一起做——按钮从列表工具栏搬进线索详情页；建销售总监和销售人员两个角色并配权限；6 个查找列表字段全部改成 100% 宽；把手写成网站模块，排到应用第一个菜单。中间查清了"关联客户字段没了"其实是字段被隐藏，改成"仅已签约可见"；补了签约后自动建档客户的监听器。
产出物：可考核、可培训的 v2。手册有独立地址、三页内容，在第一个菜单能打开。
核心要点：这两个要求超出了标准配置的范围（角色权限管"能进哪张表"，视图页签要单独配）。当场把边界说清、同时给一条能用的替代路径，比闷头做一轮再回头解释要省时间得多。
第 4 步 · 审批打通 — 32 分钟
做了什么：把发起方式换成"预填表单 + 脚本按记录发起"，让表单自动带出商机的名称和金额；给 6 个子表加行内「查看详情」；确定发起流程要用流程标识（key）而不是内部 ID 之后，改成按流程名称动态解析、失败回退常量；最后补上审批节点的状态回写，并把三个节点指派给你本人，方便一次走完。
产出物：审批能发起、能走完、走完状态变「已签约」、客户自动建档。
核心要点：流程定义的 id 和 key 都是 11 位乱码，肉眼看不出区别；节点配置又没有读接口。这种地方只能靠"跑一遍看结果"，靠猜一定猜错。
第 5 步 · 分支校准 — 11 分钟
做了什么：读流程 XML 核对两条出线的实际条件，发现一条带「≥10 万」、另一条是空的；给两条出线都写上条件并保持互斥（空值短路兜底），用条件表达式实现"二选一"的排他效果；发布后按 85.1 万、5 万、空三种金额各跑一遍；旧版本留下的实例一并作废。
产出物：三种金额下，每一步的待办数都恰好是 1；模块待办归零。
核心要点：只测一种金额，永远发现不了另外两条路走成什么样。"走通了"和"走对了"是两件事。
第 6 步 · 客户情报 — 21 分钟
做了什么：加富文本字段；建 AI 助手；先测出网能力（Bing 返回 200/99,346 字节，百度返回 227 字节的跳转页，另一个源直接超时）；发现助手插件在脚本上下文不可用后，把联网交给脚本自己做——抓检索结果、按相关性排序、补一段官网正文，AI 只负责归纳；最后清洗 HTML 写回字段，详情页挂按钮。
产出物：点一下按钮，6–10 秒输出六段结构化情报（基本盘、规模、核心产品、行业地位、近期动态、切入建议）。
核心要点：需求给得越具体，实现路径越窄。这条需求把输入字段、输出字段、内容口径全写明了，还留了"包括但不限于"的扩展口，所以一次就做到位。
2.2 各步骤投入统计
下面的数字不是事后估的，是从会话记录里 1,210 次工具调用的时间戳反推的。口径：取该步第一个实际动作到最后一条产出的墙钟时间，含人工核对，不含步骤之间的等待。
| 步骤 | 时间窗 | 耗时 | 占比 | 核心工作事项 |
|---|---|---|---|---|
| 1 骨架搭建 | 11:38–12:12 | 31′ | 21% | 6 张表 + 4 节点流程 + 10 张看板卡 + 首次发布 |
| 2 表单压测 | 13:31–13:55 | 19′ | 13% | 字段类型改造、三个默认值、517 条种子数据 |
| 3 角色手册 | 13:57–14:41 | 34′ | 23% | 隐藏字段排查、手册三页、两个角色、按钮迁移 |
| 4 审批打通 | 14:48–15:30 | 32′ | 22% | 发起方式重做、key/id 定位、子表查看入口、状态回写 |
| 5 分支校准 | 15:35–15:46 | 11′ | 7% | 读流程 XML、补互斥条件、三种金额实跑、清脏实例 |
| 6 客户情报 | 15:48–16:15 | 21′ | 14% | 出网测源、插件换路、检索+归纳、三道兜底 |
| 合计 | 11:35 → 16:15 | 148′ ≈ 2.5 小时 | 100% | 共 11 次发布，跨度 4 小时 40 分 |
读完这张表，两件事值得记住
**一是平台原生的动作确实快。**6 张表 + 4 个审批节点 + 10 张卡片 = 31 分钟，这就是低代码最直接的价值：第一版几乎不占时间。
**二是剩下的时间几乎全在"规则对齐"上，不在"搭"上。**那个下午的 43 分钟，花在让审批真的走通、让金额分支真的只走一条、让状态真的会变。这部分时间压不掉——因为业务规则只有跑起来才知道对不对；但因为方法对，它被压到了 43 分钟，而不是几天。
第 3 章 实操：每一步，人做什么，AI 做什么
第 2 章讲的是时间，这一章讲的是分工。六个步骤对应六张卡片，每张卡片三行：你出手的地方、AI 出手的地方、最后拿到了什么。
看完会发现一条规律：你出手的地方全是判断题（要不要这个功能、先给谁看、哪种理解才对、什么情况下算做完），AI 出手的地方全是执行题（建表、试接口、跑用例、查证据）。判断题交给 AI 会跑偏，执行题交给人会变慢。
第 1 步 · 骨架搭建
- 你：387 个字把业务讲完，没有一句是在讲字段。三分钟后又用四条编号答复，把"要不要审批""客户维护记在哪""要不要月度目标""来源留几项"一次拍死。顺手定了主题色。
- AI：先把那段话翻成设计方案给你看，避免闷头建表；确认后串行建 6 张表、补关联与汇总、搭 4 节点流程和 10 张看板卡；建完跑平台自检，空清单才发布。
- 结果：11:53 首次发布返回 finish，草稿数 0，自检空清单。6 张表、流程、看板全部可打开。
- 要点：先给结构、再问细节。如果反过来，光对齐字段名就能花掉半小时。
第 2 步 · 表单压测
- 你：三条要求都在讲"少点几下"：行业要能选不要手打、新建时三个字段自动填好、分组按业务顺序排。然后给了一个很具体的量——"大约 100 个商机线索"，并说明目的："我要看看整体看板效果"。
- AI：改字段类型时把类型和 18 项选项一次带上；三个默认值全写成表达式而不是常量；分组更新按目标顺序正序执行（每次调用会把分组追加到末尾，倒序会得到反向结果）；灌 517 条数据后，自己算好六个汇总值写回去——这个平台的汇总字段在批量写入后不会重算。
- 结果：看板十张卡都有数，已签约 2,591.9 万、待回款 1,165.8 万；25 条签约线索 100% 能跳客户，抽查三个汇总值与子表对得上。
- 要点：数据要铺开才有意义。日期全填今天，趋势图就是一根竖线；状态全填一个，饼图就是整块。
第 3 步 · 角色与手册
- 你：四条一起提，每条都带对象和位置：哪个按钮搬到哪个页面、哪两个角色、哪些字段改成多宽、手册放在哪。没有一条是"优化一下"。中间还纠正了一次误解："我之前的意思是跟进过程中不需要展示，一旦签约，需要能直接跳转。"
- AI：先把"字段没了"当定义问题查，而不是当数据丢失查——字段在，属性是隐藏，25 条历史数据 100% 有值；然后改成"隐藏 + 可见表达式"；建两个角色配功能权限；手册做成网站模块排到首菜单。
- 结果：可考核、可培训的 v2。手册三页有独立地址；两个角色可用；6 个查找列表字段全部 100% 宽。
- 要点：这一轮有两个要求超出标准配置：按角色做行级隔离、以及用页签切换视图。当场说清边界、同时给出能用的替代（按负责人的筛选视图），比闷头做一轮再回头解释要好。
第 4 步 · 审批打通
- 你：三个动作：报清楚现象（"名称没有自动带出来，目前是空白的"）、贴原样的报错（"参数错误工作流定义不存在"）、提出测试要求（"把所有流程的审批节点都加上我，我可以直接走一遍流程"）。第三条看似是便利需求，实际暴露了一个上线就会卡死所有审批的问题。
- AI：读动作文档，确认它会新建空白记录，于是换方案；在设计器里注入临时探针函数，逐个接口试探（列流程定义能列出、取启动设置能取到、只有发起实例报错），把范围收窄到一个参数；定位后改成按流程名称解析 key、失败回退常量；补节点的状态回写；三个审批人改成你本人。
- 结果：用一笔真实商机重新发起：实例创建成功 → 节点表单带出原记录数据 → 走完 status 落为 signed → 客户自动建档。四步都验过。
- 要点：贴原文的报错省一半时间。"打不开"要猜十个方向，"工作流定义不存在"只剩一个方向。
第 5 步 · 分支校准
- 你：没有说"分支有问题"，而是把时序完整讲了一遍：经理通过后同时出现总监审批和确认建档两个节点，总监通过后又出现一个重复的确认建档。一句话把"并行"和"重复进入"两个特征同时暴露了。
- AI：节点配置接口读不到条件，改读流程 XML，看到一条有条件一条没有；确认平台节点类型里没有排他网关；给两条出线都写互斥条件，空值用
== null ||短路；发布后按三种金额各跑一遍，再作废旧版本留下的脏实例。 - 结果：85.1 万 → 经理→总监→建档；5 万 → 经理→建档；金额为空 → 经理→建档。三条路上每步待办数都是 1，模块待办归零。
- 要点：按取值组合回归，不是按"能跑通"回归。三条路至少三条用例，空值也必须算一条。
第 6 步 · 客户情报
- 你：一条需求把三件事说全了：从哪取（线索里的"客户公司"）、放到哪（富文本字段）、要什么（客户规模、核心产品、行业地位，"包括但不限于"）。
- AI：先探测而不是先编码：量了三个搜索源的可用性，确认插件在脚本上下文不可用；然后把联网交给脚本（抓结果页标题与摘要、按相关性排序、补一段官网正文），AI 只做归纳；清洗 HTML 后写字段；加三道兜底——检索为空写"未检索到公开信息"、模型异常降级原始摘要、完全无结果给核实提示。
- 结果：真实公司点击后 6–10 秒输出六段情报；检索不到时明确说没找到，不编。
- 要点：需求写得越具体，实现路径越窄。"加个客户信息查询"会来回改三轮，"从哪个字段取、放到哪个字段、要哪几类内容"一次就对。
一个可以照搬的分工原则
你说要什么、不要什么、什么算做完；AI 说能不能做、怎么做、拿什么证明做完了。这三句话之外的，都别互相代劳。
本次真正省时间的几句，都是你在定边界："不需要把 23 个人都加进去""暂时不建""跟进记录只需要绑定商机""包括但不限于"。每句话都直接砍掉一整块设计。
第 4 章 需求细化实录：七次从"能跑"到"好用"
第一版上线的时候，六张表、审批流、十张看板卡全都在，点得开、填得进。但"能打开"和"业务真的能用"之间，还隔着你后来提的这七条要求。
七个案例按你提出的时间排，全部来自真实对话。每一个都写清四件事：你要的是什么、当时卡在哪、怎么补上的、补完验到什么程度。其中两条属于"超出标准配置、需要换一条路走"，也照实写出来——把边界讲清楚，本身就是交付的一部分。
01 · 13:56 · "商机表里没有关联客户的字段了，是不是之前你给删掉了"
- 你要的：11:56 你说过"客户相关信息是在已签约的时候才显示的，线索阶段不显示"。13:56 补上了半句关键的话："一旦签约，我是需要从商机能够直接跳转到客户表的，后续也好做商机转化率的统计。"
- 当时的盲区：我按"隐藏"实现了这个要求，而隐藏的语义是所有视图都不显示。于是销售在跟进阶段看不到（这部分对了），签约之后也看不到——你看到的现象就是"字段没了"，自然会怀疑被删。
- 怎么补上：先当定义问题查，不当数据丢失查：字段在，25 条已签约线索 100% 有值，数据一点没丢。然后改成隐藏 + 可见表达式：
hidden=true配合visibleExpression = ${formRecord.status == 'signed'}，宽度 100%，可点击跳转。 - 结果：分别拿一条已签约和一条跟进中的商机各看一次表单：前者字段出现、点击能跳到客户，后者不显示。25 条历史签约记录回填率 100%。
- 边界说明："点整行跳转"是另一个开关，只能在设计器界面里点，脚本改不到。所以最终交付的是"点字段跳转"——功能达到目的，交互形态是次优选，这一点当时就说清了。
02 · 14:24 · "销售人员只能看到自己负责的项目，销售总监可以看到全部，做2个数据页签来过滤"
- 你要的：两件事：角色之间看到的数据范围不同；用两个页签来切换，而不是让人自己去筛。
- 边界在哪：这两条都超出标准配置的范围：角色权限管的是"能不能进这张表、能不能改"，不细分到行；视图页签要在表格设置里单独配，脚本里没有对应的写入口。
- 怎么补上：能做的全部做完：建销售总监、销售人员两个角色并配好功能权限；在 5 张表上配好按负责人的筛选视图，销售打开就只看到自己的；"页签需要在界面里点一下"这一步写进交付说明，不含糊过去。
- 结果：两个角色可用，销售与总监的视角按视图区分开；页签手动一步即可。这里给的是数据可见范围，不是权限隔离——两者用途不同，当时就跟你讲清了，没有留到最后才发现。
03 · 14:53 · "所有的子表里面都应该可以直接访问对应记录的详细信息"
- 你要的：在商机详情里看到跟进记录、合同、回款、开票这些子表时，能直接点开某一行看它的完整内容，不用再跳到那张表去搜。
- 边界在哪：设计器里有一个「点击行看详情」的开关，但它是界面上的属性，脚本写入不进去。也就是说这条路只能手工点，不能随方案一起交付。
- 怎么补上：换实现：在 6 个查找列表的列配置末尾追加一列「操作」，放一个行内「查看详情」按钮。点了之后先由脚本判断这一行的 ID 属于哪张表（子表行按钮里
record的语义不明确），再用记录详情动作弹窗。 - 结果：6 个子表都能点开详情，跟进、合同、回款、发票四种记录的弹窗都验证过。形态是多一列按钮，比"点整行"多一次精确点击，但功能完全达到。
04 · 14:53 · "提交签约转客户审批，线索名称和客户公司名称没有自动带出来，目前是空白的"
- 你要的：点「提交签约审批」之后，弹出来的表单应该已经带着这条商机的名称和公司名，只需要填金额和日期。
- 当时的盲区：我选了"打开发起表单"这个动作，理解是"弹出表单让人填"。它实际做的是先在启动表里插入一条空白记录，再基于这条新记录发起——所以带出来必然是空的；提交之后，商机表里还会多出一条重复记录。字段映射怎么配都救不了，因为源头就是一条空记录。
- 怎么补上：整条路换掉：改成"预填表单 + 脚本按记录发起"。表单只放 4 个字段，两个名称只读、用
Record.getFieldValue()预填；提交后走脚本调发起接口，把流程绑在已有商机记录上，不再新建。中间还遇到一个细节：预填表单必须传tableId，漏了会报「模块【null】不存在」。 - 结果：点开弹窗，两个名称已带出 → 提交 → 主表没有新增重复记录，审批实例绑在原商机上，节点表单显示的就是这条商机的数据。
05 · 15:11 · "发起审批时系统报错：提示错误:参数错误工作流定义不存在"
- 你要的：点按钮就能发起，不报错。
- 当时的盲区：发起接口的第二个参数要的是流程的标识符 key（
signToCustomer），我传的是查询接口返回的内部 ID（wykl95ko468iu）。两者都是 11 位字符串、名字里都带 Id，肉眼分不出来。更绕的是"取启动设置"这个接口恰好接受 ID——它查得通，反而让我以为参数没问题。 - 怎么补上：不再猜，改成逐个排除。在设计器里注入一个临时探针函数，把三个接口排成一列逐个试：列流程定义（能列出，说明模块对）、取启动设置（能取到，说明流程对）、发起实例（只有它报错）。范围一收窄，问题就只剩参数本身。改法是运行时按流程名称解析 key，解析失败回退固定常量，同时补一条"发起人为空"的可读报错。
- 结果：用一笔真实商机重新发起：实例创建成功 → 节点表单带出原记录 → 走完 status 落为 signed。三步都验过才收工。探针函数用完已删除，线上脚本和验证过的一致。
06 · 15:27 · "为了方便测试，请把所有流程的审批节点都加上我，我可以直接走一遍流程"
- 你要的：字面上是测试便利：你想自己走一遍，不想等人。
- 后来才发现：改的时候才看清这不是"方便不方便"。应用里只有你一个成员，而且没有上级，节点原来的审批人写的是
${Array.first(User.superiorUsers(initiator))}——解析结果为空。任务能生成，但没有人能办。这套配置上线，每一笔审批都会停在第一个节点，而且界面上看起来"流程正常发起了"。 - 怎么补上：三个审批节点的指派统一改成固定成员（你本人），并在节点配置里留了注记：上线前改回上级审批表达式。同时说明为什么现在必须这么写——不是图省事，是这个应用里暂时没有第二个可选的人。
- 结果：整条流程能走完，待办落到你名下。这条也成了第 6 章的一条硬规则：审批人表达式必须有兜底，宁可落到固定的人，也不能解析为空。
07 · 15:35 · "他是两条分支同时再走…又出现了一个重复的确认建档节点"
- 你要的：金额 ≥10 万走总监，<10 万直接建档。按条件只走一条。
- 当时的盲区：经理节点有两条出线，我只给一条写了条件，另一条留空。这个引擎对"多出口"的语义是：条件成立的分支 + 无条件分支全部触发。那条空着的出线不是"否则"，是"总是"。于是两条都走了，总监节点走完再进一次建档，就出现了第二个建档任务。
- 怎么补上：两条出线都写条件，且互斥：
${form.signAmount >= 100000}和${form.signAmount == null || form.signAmount < 100000}。后半段的== null是为了不填金额时不至于两条都不匹配、把流程卡死。用条件表达式本身实现"二选一"的排他效果。 - 结果：85.1 万 → 经理→总监→建档；5 万 → 经理→建档；金额为空 → 经理→建档。三条路上每一步待办数都是 1。旧版本留下的 4 个旧待办已整笔作废，模块待办归零。
- 沉淀成规则：多出口必须每条都写条件、互相排斥，空值要短路兜底。这条已经写进第 6 章第 2 条，下一个人不必再试一遍。
还有一个，没等你开口就发现
七个要求之外有一个例外：查 key 的时候顺手翻了商务建档确认节点的配置，发现它的「完成后要写哪些字段」是空的。这意味着审批全部通过、流程正常结束，但商机状态不会变成「已签约」——状态不变，那个"签约后自动建档客户"的监听器就永远不触发，客户表永远是空的。
补法很简单，加一条 {fieldId:"status", expression:"${'signed'}"}。但它说明一件事：**流程走完和业务完成是两码事。**流程引擎负责把节点走完，"走完要改什么"得单独配。这类问题不会报错、不会卡住，看起来一切正常，只有去查数据才会发现。
七件事的共性，一句话说清
没有一件是"功能没做"，全部是业务规则只有在真实数据上跑一遍才看得出来的细节：字段什么时候该出现、谁能看谁的数据、发起时该带哪条记录、金额分到哪一级、走完状态该变成什么。
它们能在一个下午全部落地，靠的是同一条方法：**用真实数据跑一遍，看结果，不看提示。**这也是那 43 分钟花得值的地方——花完，这套系统才真的能交给销售用。
第 5 章 提问模板库：九组说法对照
同一个需求，问法不同，产出差别很大。下面九组全部来自这次真实对话，左边是更常见的说法，右边是当时实际说过的话。
| 说法 | 说明 | |
|---|---|---|
| ❌ 差 | "审批发起不了，你看看" | 没有报错原文，AI 只能从十个方向里猜。 |
| ✅ 好 | "发起审批时系统报错：提示错误:参数错误工作流定义不存在" | 15:11。一句话把范围从"表单配置"缩到"发起参数"。 |
| 说法 | 说明 | |
|---|---|---|
| ❌ 差 | "流程分支有问题，走错了" | "走错了"有三种可能：走了不该走的路、该走没走、两条都走了。三种的修法完全不同。 |
| ✅ 好 | "他是两条分支同时再走，即通过销售经理审批后，直接创建了，销售总监审批和确认建档2个节点，然后总监审批后，又出现了一个重复的确认建档节点。" | 15:35。按时序描述，一举暴露"并行"和"二次进入"两个特征，直接指向无条件出线。 |
| 说法 | 说明 | |
|---|---|---|
| ❌ 差 | "把审批人改成我" | 没说这是临时措施，照做之后没人知道上线前要改回去。 |
| ✅ 好 | "为了方便测试，请把所有流程的审批节点都加上我，我可以直接走一遍流程。" | 15:27。说明目的与用途，于是配置里能留下"上线改回上级表达式"的备注。 |
| 说法 | 说明 | |
|---|---|---|
| ❌ 差 | "表单再调一下，顺便把权限也加上" | 两件事塞一句，验收时无法判断哪件做完了。 |
| ✅ 好 | "1、…按钮不要放在工具栏上，放到对应线索的详情页里。2、新增销售总监和销售人员角色…3、检查一下所有表单…4、…写一份html版本的使用手册" | 14:24。四件事编号，每件都有对象、位置、验收口径，可以逐条回执。 |
| 说法 | 说明 | |
|---|---|---|
| ❌ 差 | "关联客户怎么没了" | 只说现象。对方可能去猜"要加一个字段"，也可能去找备份——两条路都可能白走。 |
| ✅ 好 | "我之前的意思是在跟进过程中不需要展示，一旦签约，我是需要从商机能够直接跳转到客户表的。后续也好做商机转化率的统计。" | 13:56。原始意图、期望行为、业务目的三样一起给，修法自然就是"条件显示"。 |
| 说法 | 说明 | |
|---|---|---|
| ❌ 差 | "权限你看着配一下" | "看着配"会得到一个看起来合理但不符合业务分工的矩阵，回头还要重做。 |
| ✅ 好 | "销售人员只能看到自己负责的项目，销售总监可以看到全部。做2个数据页签来过滤。" | 14:24。给了角色差异 + 实现方式，于是能对着「数据范围」这个方向找；超出配置范围时也敢直接说清，并给出筛选视图的替代。 |
| 说法 | 说明 | |
|---|---|---|
| ❌ 差 | "加一个客户信息查询功能" | 输入从哪来、结果放哪、要什么内容，三个都空着，实现全凭猜。 |
| ✅ 好 | "根据线索里「客户公司」名称，去网上搜集相关信息，填入到富文本里，包括但不限于，客户规模，核心产品，行业地位等内容。" | 15:48。输入字段、输出字段、内容口径三样齐全；"包括但不限于"还留了扩展空间。 |
| 说法 | 说明 | |
|---|---|---|
| ❌ 差 | "造点测试数据看看效果" | "点"可能是 10 条也可能是 1000 条；没说看什么效果，数据可能全挤在一个状态上。 |
| ✅ 好 | "帮我创建大约100个商机线索和客户信息，包含其中各种子表内容的测试数据，我要看看整体看板效果" | 13:45。量级 + 目的都给了，于是数据要铺开日期、负责人、状态，图表才有起伏。 |
| 说法 | 说明 | |
|---|---|---|
| ❌ 差 | "按钮位置不太对，调一下" | "调一下"可能被理解成换顺序，也可能被理解成换容器，返工一轮才发现理解错了。 |
| ✅ 好 | "客户表单，应该先填写客户基本信息，而不是看到合同、回款、开票等内容。" | 11:56。用"应该先看到什么 / 而不是看到什么"把要求说成可判定的标准。 |
三个高效习惯
| 习惯 | 为什么有效 | 本次实例 |
|---|---|---|
| 编号回答决策点 | 多决策一次拍完，不产生来回 | "1、需要审批。2、是的…3、暂时不建。4、精简成2项" |
| 报错贴原文 | 保留字符级线索，往往是根因所在 | "参数错误工作流定义不存在"直接指向发起参数 |
| 按时序描述异常 | 把"哪里不对"变成"第几步开始不对" | 15:35 那条把"并行"和"重复"两个特征一次说清 |
一个反直觉的经验
**提需求时"少说要什么功能，多说不要什么"。**这次真正省时间的几句都是排除句："不需要把23个人都加进去""暂时不建""客户相关信息…线索阶段不显示""跟进记录只需要绑定商机"——每一句都直接砍掉一整块设计。排除项比需求项更能锁定实现路径，也更容易验收。
第 6 章 Skill 能力补充：十二条规则
下面这十二条，每一条都来自这一天的真实操作，都是可以直接照抄的写法约定。没有凑数——写不出来的就没写，所以只有十二条，不是整齐的"五加五"。
01 发起流程认 key，不认 id——而且同一套 SDK 里分工不一致
来自案例 05：发起实例这一步认的是流程标识（key），不是内部 ID。而同一套接口里，列流程定义、查版本、发起实例都按 key，只有取启动设置接受 ID——分工记下来，不用猜。
// 按名称解析，失败回退常量
const list = informat.bpmn.getBpmnProcessDefineList(moduleId)
const key = (list.find(p => p.name === '签约转客户审批') || {}).key || 'signToCustomer'02 多出口必须每条都写条件、互相排斥，空值要短路兜底
来自案例 07：空着的出线不是"否则"，是"总是"，会和条件分支一起并行触发。这个引擎的多出口靠条件表达式控制，两条出线写成互斥，就等价于"二选一"。
Flow_A = ${form.amount >= 100000}
Flow_B = ${form.amount == null || form.amount < 100000}
// 不要留"默认线"，它一定会被走03 「条件显示」不等于 hidden，必须 hidden + 可见表达式一起用
来自案例 01：只设 hidden 会让所有视图都不显示，签约后也看不到，用户会以为字段被删了。
{ hidden: true,
visibleExpression: "${formRecord.status == 'signed'}" }04 选动作之前先读副作用：名字像的两个动作，一个只读、一个会写数据
来自案例 04："打开发起表单"会先新建一条空白记录再发起，导致表单永远空白 + 主表多条脏数据。要绑已有记录，得用脚本调发起接口。
05 平台开关类字段，写完必须回读校验，返回 finish 不算数
来自案例 03：tableEnableShowDetail、enableShowDetail 这类属于界面属性，脚本写入不生效；pieSetting 里带 label/itemStyle 会让整张卡保存失败。两种情况的共同点是：调用不报错，只能靠回读确认。
await updateField(...)
const back = await queryField(...) // 改完立刻读回来比对
if (back.enableShowDetail !== true) {
// 走替代方案，别假设成功
}06 审批人表达式必须有兜底，宁可落到固定的人
来自案例 06：${Array.first(User.superiorUsers(initiator))} 在没有上级的账号里解析为空。任务能生成，但没有人能办，而且界面看起来"流程已发起"。
07 批量更新是整条替换，没传的字段会被置空
回滚测试数据时踩到：只传了要改的几个字段，结果标题、负责人、金额全被清掉。回滚必须带上所有要保留的值，先读全文再整条写回。
08 汇总字段在批量写入、脚本写入后不会自动重算，要自己算好回写
灌完 517 条数据，六个汇总字段全是 0。脚本写入不触发监听器，所以汇总要自己算好再回写。
09 脚本上下文没有 AI 插件运行时：联网自己做，AI 只做归纳
来自客户情报：脚本跑在独立上下文里，助手侧配置的插件到不了这里。所以把职责切开——脚本自己抓检索结果和官网正文，AI 只做归纳。拆开之后反而更稳：模型只能基于给定材料写，天然抗编造。
const resp = informat.http.request({
url, method: 'GET', timeout: 8000,
header: { 'User-Agent': UA }
})
// 自己抓、自己排序，把材料丢给模型只做总结10 有实例在跑时，任务是流程的一部分，清数据要整笔作废
清测试实例时报 The task cannot be deleted because is part of a running process——单个待办不能抽出来删。改用 deleteInstance 作废整个实例，再重新发起一笔干净的。
11 发布是一个会改变运行时行为的动作，发完必须重跑同一个用例
AI 助手在发布前跑通过一次，发布后同一条路径就变了行为，助手侧的配置也被重置。"一次跑通"不等于"稳定可用"，发布后拿同一个用例再跑一遍，成本不到一分钟。
12 临时探针用完就删，删完重新保存，保证线上脚本和验证过的一致
排查 key 时在设计器里注入了 debug 函数。用完不删，线上就会留一个绕过业务校验的入口——这比当初那个问题本身更值得警惕。
_execute_informat_script_designer // 注入 → 试探 → 删除 → 重新保存这十二条可以归成三类
第一类（1、2、3、4、6）是语义类：同一个词，配置里的含义和口头理解不一样。key 不是 ID，空条件不是"否则"，隐藏不是"条件显示"，"打开发起表单"不是"打开表单"。
第二类（5、7、8、10）是回读类：写完要看结果。界面属性要回读、批量更新会清空未传字段、汇总不自动重算、跑着的实例不能单删任务。
第三类（9、11、12）是环境类：换个执行上下文，能力范围就变了。脚本里没有助手插件、发布后助手配置会重置、探针会留在线上。
AI × 低代码：一天搭出能真跑的销售管理系统 · 织信 Informat 项目实录 V1.4
V1.4 改版：难点改为业务视角（把隐性规矩显性化），全篇去掉「平台短板」式表述；问题复盘改为「需求细化实录」，七个案例统一为「你要的 → 当时卡在哪 → 怎么补上 → 结果」；能力补充按「写法约定」重写。
基于 2026-11-02 11:35–16:15 的完整协作过程整理；对话原话 23 条，工时取自 1,210 次工具调用时间戳。