LouLou 方法

同事又收到一份报价。供应商名字似乎见过，产品也很熟悉，但上一次为什么没选、当时报价包含什么、样品有没有问题，散落在不同的表格和聊天里。

AI 可以很快整理眼前这份文件。但如果找不到过去的依据，它仍然不知道这次该怎样比较。

我想解决的，就是这两段工作之间的断层： 把一次采购中用过的资料、作过的判断和留下的问题，整理成下一次可以找回、核对和更新的记录。

我是 Louis。LouLou 是我给 AI 工作搭档取的共同名字。LouLouis.ai 把 Louis 和 LouLou 放在一起，也可以读作 “LouLou is AI”：我负责业务判断与交付责任，LouLou 帮我研究、整理和推进工作。

这里的“LouLou 方法”，是我正在从真实项目中整理的一套工作方法，不是一个已经能替人完成全部采购的软件，也不是一套固定不变的行业标准。

工厂数据库保存事实和历史；业务知识库说明它们的含义与使用条件；工作流组织这次任务；复核和更新把经验留给下一次。

1. 工厂数据库：不只保存一个名字和电话

一张可用的供应商档案，应该能回答：这个名字属于哪个主体？我们核查过什么？谁联系过？报过什么条件？实际合作留下了什么记录？

我的内部工厂库已经把供应商、联系人、项目关系、报价、证据和结果分开组织。这里有几个重要区别：

• 核查过，不等于合作过。 公开资料、供应商自述与实际项目经历，需要各自记录。
• 名字相似，不等于同一家。 中文名、英文名、店铺名和其他抬头，只有在身份关联有依据时才归到一起。
• 一笔报价，不是一个孤立数字。 规格、数量档、计价单位、币种、贸易条件、日期和原件需要跟着它走。
• 没有采用，不一定是供应商不好。 客户换方向、规格不合适、条件未谈妥，都应保留具体原因，避免下次误判。

新的报价不应悄悄覆盖旧报价；新的建议也不应覆盖负责人原来的决定。每次变化都要能解释。

2. 本体知识库：让 AI 知道，什么和什么有关

“本体”听起来很技术化，我的解释很简单： 让 AI 知道，一条报价属于哪家供应商、哪个产品和哪个项目；用它作判断前，需要检查哪些条件。

项目需求 → 产品规格 → 供应商报价
                         ↓
                    来源与适用规则
                         ↓
                   人工决定 → 项目结果

这是方法示意，不代表每个环节都已自动同步。

只有关联还不够，还要把不同性质的信息分开：客户明确要求的、我们暂时推测的、尚未提供的，不能写成同一种“已知”。旧规则被替代，要留下版本；两份资料冲突，要保留冲突和待确认人，不能让 AI 自行挑一个顺眼的答案。

例如，“只有规格和报价条件足够一致，才能直接比较价格”，是一条带适用条件的规则。它应当出现在比价这一步，而不是埋在某次聊天的第几十条消息里。团队有不同规则，也需要明确谁能确认和修改。

3. 工作流：给 AI 一段能验收的任务

我通常不从“帮我完成这个项目”开始，而是把任务拆成可以检查的单元。

一张工作流卡至少写清楚：

• 输入： 需要哪些资料，哪些字段缺了就不能继续判断。
• 动作： 读取、整理、交叉核对，还是生成方案草稿。
• 输出： 交付什么表、什么卡，依据放在哪里。
• 边界： 哪些只能建议，哪些必须停下来请人确认。
• 更新： 完成后什么内容值得留存，由谁复核后写回。

选品研究可以交给 AI 扩展方向、整理候选和检查链接；我负责取舍、纠正规则以及决定哪些内容可以进入客户材料。报价比较可以让 AI 找差异，但条件缺失时，正确的输出可能只是“暂不能直接比较”。

Prompt 和 Skill 是执行这些任务的载体。真正需要持续打磨的，是业务规则和验收方式，而不只是提示词的长度。

4. 质量与更新：把错误变成可以再检查的问题

当 AI 把店铺能力当成某款产品的规格，修正那一行还不够。我会把它转成一个检查问题： 这项结论有产品级依据，还是只有店铺级描述？

当不同预算条件被套用同一套筛选规则，就要把规则的适用范围补上。

我已经有内部业务题和评测记录，用来检查来源、缺失项、规则适用和判断边界。它们帮助发现体系里的问题，不代表任何公开的准确率承诺。更新规则之后，也需要用旧问题重新检查，而不是只看新答案是否写得流畅。

以下全部为虚构教学示例，不对应任何真实供应商、报价或项目，也不是已上线功能的操作录像。

问题：同事收到“供应商甲”的新报价，想知道是否值得继续谈。

这次任务的价值，不一定是立刻得到一个“选这家”的答案。也可能是及时发现，现在还没有足够依据。

这不是“把所有聊天记录倒进知识库”。我更愿意从一个具体动作开始，例如复核一份新报价或一条工厂能力主张。

1. 先固定来源与时间。 保存原件位置、收到日期、提供方和本次使用权限。AI 摘录出来的字段旁边保留来源编号，不用一段流畅总结替代原件。
2. 再确定业务对象。 明确这是哪家法定主体、哪个产品版本、哪次项目需求、哪一档报价；名称或型号对不上时先不合并。
3. 把主张拆成可核查的问题。 例如“支持定制”要继续问：是哪一款、哪种工艺、什么数量条件、是否有书面回复或样品。
4. 记录人的决定及理由。 AI 可以建议“继续询价／暂缓／排除”，但负责人要留下决定、适用条件和待办；不能只存最终一个状态。
5. 确认后才写回，并用旧题复测。 新证据补齐时保留旧版本；如果这次出现误判，增补一条验收问题，再看过去类似问题是否也会被拦住。

这五步的最小产物可以只是一张表： 来源 ID、对象 ID、主张、依据、状态、缺口、负责人、决定日期 。团队先把这些字段用稳，比先追求“AI 全自动工厂评分”更可检验。

已有内部实践： 工厂库的结构与工作文件、业务对象和规则的组织、部分工作流实现、人工确认点、历史更新记录，以及内部评测材料。两个匿名案例展示了其中部分方法怎样用于研究和客户提案。

仍需完善： 历史资料的持续整理、不同工具之间的读写衔接、规则与实现的一致性，以及日常维护方式。这里不承诺所有业务数据已经实时同步，也不把一条写在文档里的规则当作已自动执行的功能。

下一步要验证： 其他团队能否在自己的品类、客户要求和协作习惯下稳定使用。先做小范围实施和复盘，再决定哪些部分适合成为通用产品。

我想继续检查，这些方法换一个品类、一个项目，或一位使用者以后，是否还能够讲得清、用得上。

我会从少量已获授权的资料开始，检查四个具体问题：同事找不找得到依据，AI 会不会误合并资料，缺失条件能不能被保留下来，新的结果能不能经过确认后留存。

范围、权限、负责人和验收方式仍然需要先明确。这不默认包含自动外联、对客报价、下单或替代采购负责人的决定。

新的发现和修正会继续记录在这里。比起先给体系起一个更大的名字，我更在意它能不能经得起下一次真实工作。

相关实践：选品研究如何变成可评审提案 · 样品记录与客户方案如何保持一致 · 四条更多实践笔记 · 试用工厂证据分层卡