上一章摸清了数据、部署、测试三件事的底，手里有了一张现状清单：哪些表大、有没有测试、写入路径怎么走、软删除怎么标。清单不是拿来交差的，它要回答一个更实际的问题——这一堆可以接 AI 的地方，第一个先动哪。

判断直接放开头：第一个落地点的标准只有一条，只读、低风险、收益能数得出来。满足不了这三条的需求，再性感也往后放。

候选清单

先把清单翻成候选。老系统里最常见的几类需求，按风险从低到高排一遍：

  • 数据问答：让模型读订单、读客户、读库存，回答「这个客户最近三笔订单是什么」。只读，不碰写路径。
  • 字段补全：根据已有字段推断缺失字段，比如给客户记录补行业标签。半只读，写进一张独立的补全表，不动原表。
  • 摘要与分类：把工单、评论归个类、抽个摘要。只读输入，输出进新表。
  • 代码辅助：让模型帮忙写测试、补注释。不碰运行时数据，但产物要人审。
  • 自动写数据：让模型直接改订单状态、发通知。风险最高，绝对不进第一批。

这份排序本身就是取舍。写数据的需求收益最大，但它要求你把事务边界、软删除、字段漂移这些坑全部吃透才敢动，起步阶段根本扛不住。

先跑数据问答

把候选排完之后，最稳的起步是数据问答，而不是字段补全或摘要。原因有三个：它最纯粹，输入一个查询、输出一个答案，没有中间状态要维护；它最好验证，答案对不对一眼能看出来，方便后面接评测；它最容易止损，效果不好停掉旁路就完事，不留任何脏数据。

问答的收益也最容易量化。老系统里「查一个客户最近的订单历史」这种操作，可能要客服翻三四个页面，模型直接一句话给全。这个时间差，就是你能向业务方交代的第一笔账。

只读优先

为什么第一个落地点必须只读？因为老系统最贵的是回归成本。上一章说过，老系统大概率没有测试兜底，你改任何一行主链路代码，坏了都不知道坏在哪。只读需求把故障面锁在一个旁路里：模型挂了、答错了，老系统照常跑，最坏结果是答案不对，而不是数据被写坏。

只读还有个隐藏好处：它把「模型能力」和「数据质量」剥离开了。数据问答做得差，你能一眼看出是模型不行还是字段没核对清。一旦掺进写操作，出错原因就糊成一团，排查成本翻倍。

一个最小接入点

第一个落地点，我建议选一张字段含义稳定、查询量大的表，做「只读问答」。下面这段代码做一件事：把模型挂到一个只读查询工具上，让它能查订单状态，但工具内部只开放 SELECT，写操作在入口处直接拦掉。

# ro_agent.py —— 第一个落地点：只读问答
import sqlite3

READONLY_PREFIX = ("select", "with")  # 只放行查询

def query_orders(customer: str, limit: int = 5) -> str:
    # 入口白名单校验，任何非只读语句直接拒绝
    sql = (
        f"select id, status, created_at from orders "
        f"where customer = ? order by created_at desc limit {int(limit)}"
    )
    if not sql.lstrip().lower().startswith(READONLY_PREFIX):
        return "拒绝：只读工具不执行写操作"
    conn = sqlite3.connect("legacy.db")
    rows = conn.execute(sql, (customer,)).fetchall()
    conn.close()
    return "\n".join(f"订单 {r[0]} 状态 {r[1]} 时间 {r[2]}" for r in rows)

这里的关键不是工具本身，而是那个 READONLY_PREFIX 白名单。模型输出是不可信输入，你永远不能把模型生成的 SQL 原样交给数据库，入口拦一道比事后审计强得多。换成 MySQL 或 Postgres，思路不变，只是把驱动和占位符换掉。

写回单独走

问答跑起来之后，用户很快会提「那能不能让模型帮我改一下这个订单状态」。这时候别急。写回必须单独走一条通道：模型产出的是「建议」，落库的是另一段受控代码，中间隔着校验。

具体说，写回通道做三件事：一是字段白名单，模型只能改你列出的那几个字段；二是值域校验，状态值必须落在枚举里；三是留痕，每次写回记一条审计日志，谁改的、改成什么。模型直接写库，等于把老系统的最后一个安全垫抽掉。

字段漂移的坑

第一个落地点选表时，有一个坑比别的都隐蔽：字段含义漂移。同一个字段在不同历史时期可能存了不同含义，早期 status=3 表示「取消」，后来改成了「退款中」。模型按现在的枚举理解老数据，就会把一堆历史记录读错。

所以选第一张表，挑字段含义稳定的，别挑那种 status 被反复改过语义的。拿不准的字段，宁可先让模型说「我按当前枚举理解，历史值可能有歧义」，也不要让它拍胸脯给结论。

下一章

第一个落地点跑通之后，你会立刻撞上第二个问题：模型答得对不对，怎么知道。只读问答的效果如果靠肉眼逐条核对，一周就撑不住。下一章解决它——给这个只读问答接一套不用人工逐条看的评测。