演示之后，工作才开始。

9 月 5 日，几段交流留下的问题

今天的讨论从法律服务、制造业，一路聊到面向海外市场的互联网公司。有人分享自己搭了什么，接着就有人追问：员工怎么用，权限怎么管，客户为什么愿意持续付费。听着这些来回，我对一个演示距离日常使用还有多远，有了更具体的感受。

大家对起点有不同的判断。有人主张先搭企业共享的基础，有人倾向先解决客户已经认可的小问题。关于纸质单据和 OCR 的讨论，又把问题拉回到使用习惯：究竟需要改变多少现有流程？这些讨论让我更想先弄清每种做法成立的条件，再决定哪些值得借鉴。

先沿着一笔业务走一遍

我想先理解业务目标，再沿着一笔业务从头走到尾：输入是什么，要交付什么，经过谁的手，又在哪里等待。一笔具体的业务，往往能让部门、工具和预期之间的缝隙变得清楚。

这需要一点耐心。在判断 AI 应该放在哪里之前，我得先弄明白今天的工作是怎么完成的，包括那些没有写进流程图、却一直靠人维持的步骤。

现场有人建议从一张订单开始，让相关的人把每次交接演示一遍。另一位分享者讲到，律所想做标书工具，是因为这份重复劳动让员工难以长期留下来。这个例子提醒我，多问一句需求背后的原因。一项从外面看并不起眼的工作，可能正让做它的人承受很具体的困扰。

找到限制结果的那一环

一个环节变快，价值还要看最终结果。如果某项任务省了一半时间，交付却仍然卡在同一个队列里，整体改善可能很小。我更想追问：究竟哪一环限制了交付速度、质量稳定性或承接能力？

这也改变了我对验证的理解。工具里节省了多少时间，只是一部分证据。它投入使用之后，周围的流程有没有一起改善，才决定这次提效到底帮了多少忙。

制造业的一个例子让我记住了这一点。分享者介绍了一个 DFM（可制造性设计）演示：结合企业资料生成工艺评估草稿，再交给有经验的师傅修改。这项工作原本依赖少数专家，更快报价、承接更多订单是他们希望打开的空间。我还想继续看审核时间、错误情况和完整报价周期怎样变化，才知道这一步究竟改善了多少。

切口要小，视野要完整

从一个小试点开始，是比较踏实的学习方式，前提是始终看得见完整流程。第一步要小到能够交付，也要具体到能够判断效果，同时还能为下一步留下有用的认识。

共享数据、业务规则、工具和知识，可以从已经证明有用的做法里逐渐长出来。我喜欢这个顺序：先解决具体问题，看看结果，再决定哪些东西值得沉淀为共同能力。

让 AI 理解事情怎样运转

今天关于企业 Context 和 Ontology（本体）的讨论，涉及对象、关系、角色、动作和流程。现场有人问：销售和财务口中的“客户”，含义并不完全一样，系统怎么办？仅仅收集更多文档，解决不了这个分歧。真正使用这些定义的人，需要一起把差异说清楚。

对自己的实践，我想先从一个决定开始：它依据哪些事实，谁有权做，做完会触发什么动作，又在什么情况下改变状态？现有代码和数据库可以帮助我形成初步理解。业务人员修正这份理解时，我也想把修改的原因留下来。以后回看，才知道哪些地方是自己想当然，哪些才是事情实际运转的方式。

让责任进入设计

设计里需要说清楚，AI 可以做什么，哪些决定需要人确认，出了异常又由谁接手。如果这些问题没有答案，一个技术上能运行的系统，也可能让人不知道该不该信、该不该用。

真正做事的人还需要从采用中得到实际好处。少一些重复劳动，多一点时间或清晰度，才有理由继续使用、继续反馈。我想把这种日常感受也放进交付的考虑里。

一位来自制造业的参与者谈到，内部工具做出来后，同事仍然不愿意用：担心被替代，担心隐私，也担心生成之后还得重新检查。另一段关于 Token 用量的追问同样让我印象很深：有经验的人可能更少尝试就能完成任务。我更想看清，工具究竟让谁的工作变好了，有没有把省下的时间又变成审核负担。

在演示结束后留下来

我对 FDE 的理解正在变得具体：发现问题、讲清价值、完成工程实现、处理异常，再检验结果。对业务的理解，需要一路经得起实现和使用的检验。

演示是对这份理解的一次早期测试。我更想练习的是，在它结束之后仍然靠近问题，看到系统在哪里失效，人们实际需要什么，以及这次改变究竟有没有帮助。这是我希望通过实践慢慢建立的能力。

现场提出的会议流程给了我一个具体的想象：会前准备资料，会中由人决定，会后跟进执行，再回看结果。真要做出来，每次交接都需要落到实处：谁负责，有没有执行权限，怎样算完成，失败之后如何恢复。我尤其想学会把执行结果带回最初的判断，弄清当时对业务的理解哪里需要调整。

下一单与下一次续费

模板、工具和经验的复用，可以降低下一次交付的成本。持续收入则需要回答另一个问题：初次交付之后，还有什么值得客户持续付费？维护、更新和优化可能是答案，但这些价值需要一直被感受到。

我想同时记住这两个问题。一个关乎怎样少做重复劳动，把工作再做好一次；另一个关乎别人为什么愿意继续付费。它们需要分别得到验证。

这个区别来自现场一位从业者的追问：为什么每年的收入总像从零开始？回答更多谈到知识和组件的复用。我觉得这个问答之间的距离很值得留下来：交付复用有助于把服务生意做好，续费仍然需要一个对老客户有意义的理由。

接下来，我想怎样练习

下一次客户交流，我想请对方拿一笔正常业务和一笔发生过返工的业务，带我走一遍。先画清输入、输出、责任人和等待，再选一个能看清结果的小环节。

我也想给自己的原型换一份输入，拿掉一个关键事实，再放进一个异常。那时，我还能解释它为什么这样输出、找到哪里出了问题，并把它修好吗？把客户最初的表达、自己的第一版理解和后来的修正放在一起，会比只留下最终演示更有助于复盘。

这些都是我接下来想练习的事，还有很多地方需要学习。今天的交流让我有了一个更具体的进步尺度：能否独立负责一件小事，跟到它真正被使用，并说清楚最后发生了什么变化。